Credential Access Forensics: LSASS, DCSync and Kerberoasting

Credential theft is the pivot of most Windows intrusions: the attacker turns one foothold into domain-wide access by dumping LSASS, copying hives or asking a domain controller for its secrets. This guide shows, from the defender's side, which traces each technique leaves in event logs, Sysmon, the file system and the registry. You will be able to confirm or rule out credential access on a host and on domain controllers, map each finding to MITRE ATT&CK, and scope which accounts must be reset.

It follows the RDP, PsExec and WinRM guide in the lateral movement series: credential access is usually what happens just before those logons.

Technique to evidence map

Sub-technique IDs are current at the time of writing; confirm them on attack.mitre.org before reporting.

LSASS access and dumping

Sysmon Event 10: GrantedAccess and CallTrace

lsass.exe holds NTLM hashes, Kerberos tickets and keys, and on older or misconfigured systems plaintext passwords (WDigest). Reading them requires opening a handle to LSASS with read access. Sysmon Event 10 (ProcessAccess) records the source image, target image, the access mask (GrantedAccess) and a CallTrace of the modules on the stack.

Masks commonly associated with credential dumping include 0x1010 and 0x1410 (query information plus PROCESS_VM_READ, classic Mimikatz sekurlsa), 0x1438, 0x143a and 0x1fffff (full access). Treat them as leads, not verdicts: antivirus, EDR, backup agents and system processes open LSASS all day, and attackers pick masks to blend in. A CallTrace passing through dbghelp.dll or dbgcore.dll (MiniDumpWriteDump), or containing UNKNOWN frames (code outside any loaded module), deserves more weight than the mask alone. Sysmon only logs this if the configuration includes a ProcessAccess rule for lsass.exe; many configurations filter it heavily.

# Sysmon 10 events targeting LSASS, excluding a known-good source
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=10} |
  Where-Object { $_.Message -match 'TargetImage: .*\\lsass\.exe' -and
                 $_.Message -notmatch 'SourceImage: .*\\MsMpEng\.exe' } |
  Select-Object TimeCreated, Message

Dumping tools and their traces

Common ways to produce a dump, and what they leave:

• ProcDump: procdump.exe -accepteula -ma lsass.exe out.dmp. Process creation with the command line (Security 4688 if command line auditing is on, Sysmon 1), Prefetch for PROCDUMP.EXE or PROCDUMP64.EXE, and HKCU\Software\Sysinternals\ProcDump\EulaAccepted for the user who ran it. Attackers often rename the binary; the Sysmon OriginalFileName field and the file hash still identify it.
• comsvcs.dll MiniDump: rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <PID> C:\Windows\Temp\x.dmp full. A LOLBin variant: look for rundll32 command lines containing comsvcs and MiniDump (or an ordinal such as #24), and for a Prefetch file for RUNDLL32.EXE whose referenced files include COMSVCS.DLL and DBGCORE.DLL.
• Task Manager: "Create dump file" on lsass writes lsass.DMP to the user's %LOCALAPPDATA%\Temp. It requires an interactive session and admin rights, so correlate with RDP logons.
• Silent process exit abuse: an attacker configures SilentProcessExit\lsass.exe in the registry so that WER writes a dump when LSASS is made to report an exit. Check HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\lsass.exe for LocalDumpFolder and DumpType, and the IFEO key for a GlobalFlag value.
• Custom tools (nanodump, direct syscalls, handle duplication) aim to avoid these traces. Expect EDR telemetry and memory analysis to carry more weight here.

The dump file is the crown jewel for the attacker and for you. Sysmon Event 11 (FileCreate) records .dmp creation, and the MFT and USN journal keep the name, path and timestamps even after deletion. Search for large .dmp files, and for archives created shortly after (dumps are usually compressed before exfiltration). Also review Windows Error Reporting and crash dump locations: an LSASS crash caused by a clumsy tool can itself leave a report.

Defender, ASR and LSA protection

Microsoft Defender detections such as HackTool:Win32/Mimikatz or Behavior:Win32/LsassDump appear as 1116 (detected) and 1117 (action taken) in Microsoft-Windows-Windows Defender/Operational, and in the MPLog files under C:\ProgramData\Microsoft\Windows Defender\Support. The attack surface reduction rule "Block credential stealing from the Windows local security authority subsystem" logs 1121 in block mode and 1122 in audit mode. Detection names change with signature updates, so search by family rather than exact string.

Check the configuration too. RunAsPPL under HKLM\SYSTEM\CurrentControlSet\Control\Lsa runs LSASS as a protected process, and Credential Guard isolates secrets in LsaIso.exe. An attacker setting UseLogonCredential = 1 under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest is re-enabling plaintext password caching, a strong indicator of intent. Each of these keys has a last write time you can place on the timeline.

SAM, SECURITY and SYSTEM hives

Local account hashes live in the SAM hive, protected by the boot key in SYSTEM. LSA secrets (service account passwords, the machine account secret, sometimes autologon passwords) and cached domain logons (DCC2) live in SECURITY. An attacker with admin rights exports them for offline cracking:

reg save HKLM\SAM      C:\Windows\Temp\s.hiv
reg save HKLM\SYSTEM   C:\Windows\Temp\y.hiv
reg save HKLM\SECURITY C:\Windows\Temp\e.hiv

Evidence: 4688 or Sysmon 1 for reg.exe with save and the hive name, Prefetch for REG.EXE, Sysmon 11 and MFT entries for the new files (often with misleading extensions), and archive creation or SMB transfers shortly after. Variants avoid reg.exe: copying the hives from a volume shadow copy (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\Windows\System32\config\SAM), esentutl.exe /y /vss, or the HiveNightmare (CVE-2021-36934) flaw that let non-admins read shadow copies of hives on vulnerable builds. See registry hives and SAM user accounts for the structures involved.

NTDS.dit extraction on domain controllers

NTDS.dit holds every domain account hash. It is locked while AD DS runs, so attackers use one of two routes.

ntdsutil IFM (Install From Media) creates a consistent copy together with the SYSTEM and SECURITY hives:

ntdsutil "ac i ntds" "ifm" "create full C:\Windows\Temp\ifm" q q

It leaves a process creation event with the full command line, and ESENT events in the Application log commonly cited for this activity: 216 (database location change), 325 (new database created), 326 (database attached) and 327 (database detached). The output folder contains Active Directory\ntds.dit and registry\SYSTEM/SECURITY, which are easy to spot in the MFT even after deletion.

Volume shadow copy: vssadmin create shadow /for=C: or WMI Win32_ShadowCopy.Create, then a copy of ntds.dit and SYSTEM from the shadow device path. Look for vssadmin, wmic shadowcopy or diskshadow process creations, Volume Shadow Copy service start events in the System log, and new shadow copies whose creation time matches nothing in your backup schedule. The volume shadow copies artifact page explains how to enumerate them. Detailed DC triage is covered in the domain controller forensics guide.

DCSync

DCSync abuses the directory replication protocol (MS-DRSR): any account holding the replication extended rights can ask a DC to replicate password data, with no code running on the DC. The DC-side evidence is Security 4662 (an operation was performed on an object) where the Properties field contains:

Domain controllers replicate constantly, so filter out subjects that are DC computer accounts (ending in $ and member of Domain Controllers). A user account or a non-DC machine account in SubjectUserName is a strong finding. The event only exists if Audit Directory Service Access is enabled and the domain object carries an auditing SACL; check both before concluding "no DCSync". Network evidence (DRSUAPI RPC from a workstation IP) and 4624 logons on the DC from the attacking host help attribute the source. Also check who was granted replication rights recently: a 5136 (directory object modified) on the domain root's nTSecurityDescriptor can reveal an attacker preparing DCSync persistence.

DPAPI, Credential Manager and browsers

DPAPI protects saved RDP credentials, Credential Manager entries, Wi-Fi keys and browser secrets. Per-user master keys live in %APPDATA%\Microsoft\Protect\<SID>\, credential blobs in %APPDATA%\Microsoft\Credentials and %LOCALAPPDATA%\Microsoft\Credentials, and vaults in %LOCALAPPDATA%\Microsoft\Vault. See DPAPI and Credential Manager.

Traces of theft include:

• Security 4692 (backup of data protection master key attempted) and 4693 (recovery attempted), when Audit DPAPI Activity is enabled. On DCs, retrieval of the domain DPAPI backup key lets an attacker decrypt every user's master keys; it is a high-severity finding and usually requires domain admin rights.
• Process creation of cmdkey /list, vaultcmd /listcreds:"Windows Credentials" or tools such as SharpDPAPI and Mimikatz dpapi:: modules.
• Non-browser processes reading Chrome or Edge Login Data and Local State, or Firefox logins.json and key4.db. Plain file reads are not logged by Sysmon; you need EDR file telemetry or object access auditing (4663) with a SACL. Recent Chromium versions add app-bound encryption, which pushes attackers toward injecting into the browser or abusing its elevation service, visible as unusual child processes or module loads. The browser forensics guide covers the stores themselves.

Attackers also go after credential containers left on disk: KeePass databases, password-protected Office files, SSH private keys. When one turns up in a triage collection and you need to know whether it was protected with a known or reused password, Hash Extractor produces the hashcat or John hash client-side, and Secretsdump does the same for SAM, LSA secrets and NTDS.dit hives so you can scope which accounts were exposed.

Kerberos attacks

These live in the Security log of domain controllers, so collect it from every DC. The event log guide covers collection and parsing.

Kerberoasting

Any domain user can request a service ticket for an account with a Service Principal Name; the ticket is encrypted with that service account's key and can be cracked offline. RC4 tickets crack far faster, so attackers request encryption type 0x17. On DCs, 4769 (service ticket requested) shows:

• Ticket Encryption Type = 0x17,
• Service Name not krbtgt and not a computer account ending in $,
• one Account Name requesting tickets for many different services within minutes, from a single Client Address.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} |
  Where-Object { $_.Properties[5].Value -eq 0x17 -and $_.Properties[2].Value -notmatch '\$$|^krbtgt$' } |
  Group-Object { $_.Properties[0].Value } | Sort-Object Count -Descending |
  Select-Object Count, Name

Field positions in Properties can vary between builds; confirm them against one event's XML before relying on the indices. Absence of RC4 does not clear an account, since AES tickets (0x12) can be roasted too, only more slowly.

AS-REP roasting

Accounts with "Do not require Kerberos preauthentication" (DONT_REQ_PREAUTH, UserAccountControl 0x400000) return an AS-REP encrypted with the user's key to anyone who asks. Look for 4768 with Pre-Authentication Type = 0, list which accounts have the flag, and check 4738 (user account changed) for an attacker enabling it on purpose to roast the account later.

Pass-the-hash, pass-the-ticket and forged tickets

• Pass-the-hash (T1550.002) with Mimikatz sekurlsa::pth produces a local 4624 with logon type 9, logon process seclogo and authentication package Negotiate, on the attacker's host. On targets, it appears as NTLM network logons (type 3) from hosts that normally use Kerberos.
• Overpass-the-hash shows as a 4768 TGT request with RC4 encryption for an account that normally uses AES.
• Pass-the-ticket (T1550.003) and forged tickets (T1558.001 golden, T1558.002 silver) are harder: look for 4769 requests without a preceding 4768 for that account and host, tickets with abnormal lifetimes, account names that do not exist, and Kerberos tickets in memory (memory forensics guide) that do not match the logged-on user.

Map every 4624 you find with its SID and source address; the goal is the list of compromised identities.

Common mistakes

• Concluding "no dump" from missing events. Sysmon ProcessAccess, command line auditing, DPAPI auditing and Directory Service Access auditing are often disabled. State which telemetry existed before stating what did not happen.
• Alerting on GrantedAccess alone. Security products generate most LSASS access events. Baseline sources per host role, then look at the outliers.
• Ignoring renamed binaries. procdump renamed to svchost.exe still has its original file name in the PE header and a known hash.
• Checking only one DC. Kerberos and DCSync events land on whichever DC answered. Collect all of them.
• Resetting too few accounts. A DCSync or NTDS.dit theft means every domain hash is compromised, including krbtgt, which must be reset twice with replication in between.
• Forgetting the dump's journey. Find where the .dmp or hive copies went: archives, shares, cloud uploads.

Investigation workflow

1. Inventory telemetry: which hosts have Sysmon (and does it log Event 10 for lsass), process command line auditing, DPAPI and DS Access auditing, EDR.
2. Hunt host-side: Sysmon 10 on lsass, process creations for procdump, comsvcs, reg save, ntdsutil, vssadmin, cmdkey, vaultcmd; Defender 1116/1117 and ASR 1121/1122.
3. Hunt the file system: .dmp files, hive copies, ifm folders, archives, in the MFT and USN journal, including deleted entries.
4. Hunt DCs: 4662 with replication GUIDs from non-DC subjects, ESENT 216/325/326/327, shadow copy creation, 4769 RC4 bursts, 4768 with preauth type 0, 4738 and 5136 changes.
5. Check configuration drift: WDigest UseLogonCredential, RunAsPPL, SilentProcessExit on lsass, accounts with preauth disabled, new replication rights.
6. Build the identity list: every account whose credentials were exposed on each affected host, plus all domain accounts if NTDS.dit or DCSync is confirmed.
7. Correlate with lateral movement: follow those identities through 4624/4648 logons to scope the spread, then plan resets together with containment. If the host is still running, capture memory first as described in the live response guide.