Active Directory Credential Attacks: A Field Reference
Kerberoasting, AS-REP roasting, gMSA, pass-the-hash, DPAPI, Credential Manager and LAPS: preconditions, validation and where impact actually grows.
Most Active Directory credential techniques share one shape: a legitimate interface hands out material tied to an account, and the account is the part that decides whether it matters. The notes below keep the precondition, the validation step and the impact ceiling separate for each one.
Modern Kerberoasting
Kerberoasting remains relevant because the real strength of the technique depends more on the service account than on the attack name. Kerberoasting requests legitimate service tickets for SPNs and tests cryptographic material tied to the backing service account offline. RC4 and AES change format and cracking cost. Long random passwords, gMSA and AES reduce practical viability significantly. I enumerate SPNs, account type, encryption types and password policy before requesting large numbers of tickets. Real risk appears around old service accounts with high privilege, human-chosen passwords and weak rotation practices.
1
impacket-GetUserSPNs lab.local/gabriel:'Password123!' -dc-ip 10.10.10.10 -request
AS-REP Roasting
AS-REP Roasting becomes simple once you understand which proof the KDC stopped requiring. Kerberos pre-authentication makes the client prove knowledge of key material before receiving useful AS-REP content. When an account has DONT_REQ_PREAUTH, the KDC may answer without that proof and return material that can be tested offline. I identify accounts without pre-auth, confirm the directory configuration and request a single AS-REP before thinking about cracking. Long random passwords reduce practical attack value. The unsafe account configuration still exists even when cracking is not feasible.
1
impacket-GetNPUsers lab.local/ -dc-ip 10.10.10.10 -usersfile users.txt -no-pass -format hashcat
gMSA
A gMSA can have an impossible-to-memorize password and still be vulnerable if the directory releases it to the wrong identity. Group Managed Service Accounts let the domain generate and rotate service account passwords. A protected attribute contains material that authorized principals may retrieve. The ACL controlling who may retrieve the managed password is the central offensive relationship. If a compromised principal is allowed, the password is no longer out of reach. I enumerate gMSAs, inspect PrincipalsAllowedToRetrieveManagedPassword and validate which controlled account has read rights. Impact depends on what the gMSA actually does. A narrow local service and an account administering SQL, backup or servers create very different risks.
1
nxc ldap 10.10.10.10 -u gabriel -p 'Password123!' --gmsa
Pass-the-Hash, Pass-the-Key and Overpass-the-Hash
An NTLM hash, an AES key and a Kerberos ticket are different materials. Mixing them is the fastest way to get lost during lateral movement. Pass-the-Hash uses NTLM material with protocols that accept compatible authentication. Pass-the-Key uses Kerberos keys such as AES. Overpass-the-Hash turns NTLM material into a Kerberos context by requesting a TGT. The viable technique depends on protocol, NTLM policy, encryption types and the target identity. I start by identifying exactly which material I possess and which protocol the destination service accepts. Then I choose tooling that does not silently change the flow. Modern Windows has reduced NTLM in several scenarios and environments may require AES. A decade-old command can fail because of hardening rather than bad credentials.
1
nxc smb 10.10.10.20 -u Administrator -H 8846f7eaee8fb117ad06bdd830b7586c --local-auth
DPAPI
DPAPI can protect a password with strong cryptography and still hand it to an attacker who captured the correct security context. Data Protection API protects user and machine secrets using master keys tied to Windows security context. Browsers, Credential Manager and applications use it. Decrypting a blob requires material related to the master key, the user password or hash or domain backup keys in some scenarios. I enumerate master keys, blobs and the user or machine protecting them before attempting decryption. Tools such as Mimikatz and impacket-dpapi help validate the path. Impact depends on blob content. A cookie, web credential, RDP password and application secret have very different values.
1
impacket-dpapi masterkey -file masterkey.bin -sid S-1-5-21-... -password 'UserPassword'
Windows Credential Manager
An application may hide a password behind a Windows interface while leaving the secret recoverable to the user who already controls that session. Credential Manager stores Web and Windows credentials using Vault and DPAPI mechanisms depending on type and version. cmdkey /list shows targets without necessarily revealing the secret. Decryption requires the right context, master keys or APIs. I inventory credentials in the user context and follow DPAPI only for entries relevant to the assessment objective. A finding should explain whether the attacker already needed control of the same account. Recovering a reused password may create new impact even when the vault belongs to the compromised user.
1
cmdkey /list
Windows LAPS
LAPS solves local-password reuse. The directory still needs to decide correctly who may read that password. Windows LAPS stores password or encrypted password attributes in Active Directory and rotates the managed local account. ACLs decide who may read or decrypt. Excessive OU delegation may expose credentials for many computers. I identify LAPS policy, present attributes and principals with relevant read rights before retrieving any password. Encrypted passwords improve protection, but decryption rights and authorized decryptors remain critical relationships.
1
Get-LapsADPassword -Identity APP01 -AsPlainText