LSASS PROTECTED USER
by Raphgui - Sunday June 18, 2023 at 03:03 PM
#1
Hello,
I recently did an active directory pentest. And I managed to go to the DC but the administrator user was in protected user. So impossible to do mimikatz to recover his hash nt. 

Anyone got any tricks?  Heart

[Image: UBXzEpIS_400x400.png]
Reply
#2
If any body have idea ?
Reply
#3
(06-18-2023, 03:03 PM)Raphgui Wrote: Hello,
I recently did an active directory pentest. And I managed to go to the DC but the administrator user was in protected user. So impossible to do mimikatz to recover his hash nt. 

Anyone got any tricks?  Heart

[Image: UBXzEpIS_400x400.png]
you didnt gave so much informations, so i assume you only have an user shell without any Administrator right.
There is 4 ways to interact with LSA :
processes; winlogon; kernel-mode; and CredUI.
In your case kernel an winlogon are ofc forbidden, so you will have to focus on credui.dll and processes.
taking a quick look at credui.dll reveals many things.
username@domain DOMAIN\username
are the credentials you should provide to interact efficiently with lsass and globally LSA from credui.
we can see the dll stores an username, a password, a PIN and a certificate.
You can try to abuse this dll, its not seriously protected, the imports table looks decent. You can also try to get more privileges by another way and then try a token impersonation or smth similar, maybe ProcDump, cme...
Reply
#4
(06-18-2023, 10:00 PM)god Wrote:
(06-18-2023, 03:03 PM)Raphgui Wrote: Hello,
I recently did an active directory pentest. And I managed to go to the DC but the administrator user was in protected user. So impossible to do mimikatz to recover his hash nt. 

Anyone got any tricks?  Heart

[Image: UBXzEpIS_400x400.png]
you didnt gave so much informations, so i assume you only have an user shell without any Administrator right.
There is 4 ways to interact with LSA :
processes; winlogon; kernel-mode; and CredUI.
In your case kernel an winlogon are ofc forbidden, so you will have to focus on credui.dll and processes.
taking a quick look at credui.dll reveals many things.
username@domain DOMAIN\username
are the credentials you should provide to interact efficiently with lsass and globally LSA from credui.
we can see the dll stores an username, a password, a PIN and a certificate.
You can try to abuse this dll, its not seriously protected, the imports table looks decent. You can also try to get more privileges by another way and then try a token impersonation or smth similar, maybe ProcDump, cme...

Thanks for ur answer. So i be admin with constrained delagation to s4u2self. But now i be Nc Authority system on the DC but the administrator user or krbgt be on the groupe protected user. So i look credui.dll.
Reply
#5
Dump all AD hashes, and use pass the hash.
Reply


Forum Jump:


 Users browsing this thread: 1 Guest(s)