T1212

Exploitation for Credential Access

Credential Access Last updated:

Adversaries may exploit software vulnerabilities in authentication systems, operating system components, or cloud infrastructure to collect credentials or obtain authenticated access without valid credentials. Exploitation targets include Kerberos protocol implementations (e.g., MS14-068 allowing domain user accounts to forge PAC data in TGTs and gain domain admin-equivalent access), authentication token validation weaknesses enabling replay attacks where intercepted tokens are reused, and cloud identity provider flaws permitting unauthorized token creation or renewal (e.g., Storm-0558 exploiting a Microsoft consumer signing key to forge Azure AD access tokens). Unlike credential dumping or brute force, exploitation techniques may yield highly privileged or long-lived credential material with fewer authentication failure artifacts. Successful exploitation may also result in privilege escalation depending on the targeted process or credentials obtained.

What is T1212 Exploitation for Credential Access?

Exploitation for Credential Access (T1212) maps to the Credential Access tactic — the adversary is trying to steal account names and passwords in MITRE ATT&CK.

This page provides production-ready detection logic for Exploitation for Credential Access, covering the data sources and telemetry it touches: Authentication: Authentication, Logon Session: Logon Session Creation, Process: Process Creation, Windows Security Event Log, Microsoft Defender for Endpoint. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Credential Access
Technique
T1212 Exploitation for Credential Access
Canonical reference
https://attack.mitre.org/techniques/T1212/
Microsoft Sentinel / Defender
kusto
let LookbackPeriod = 24h;
// Branch 1: Kerberos TGS requests using RC4 encryption for krbtgt service
// RC4-HMAC (0x17) for krbtgt TGS is a classic MS14-068 / forged ticket indicator in AES-capable environments
let KerberosTGSAnomalies = SecurityEvent
| where TimeGenerated > ago(LookbackPeriod)
| where EventID == 4769
| where TicketEncryptionType == "0x17"                    // RC4-HMAC — suspicious when AES-256 (0x12) expected
| where ServiceName =~ "krbtgt"                            // Forged TGTs always request krbtgt service ticket
| where TargetUserName !endswith "$"                        // Exclude machine accounts
| where TargetUserName !in~ ("ANONYMOUS LOGON", "")
| extend DetectionBranch = "Kerberos_RC4_TGS_Anomaly"
| project TimeGenerated, Computer,
          AccountName = TargetUserName,
          Detail = strcat("Service:", ServiceName, " EncType:", TicketEncryptionType, " SrcIP:", IpAddress, " Options:", TicketOptions),
          DetectionBranch;
// Branch 2: Known Kerberos exploitation and credential access tool signatures in process events
let ExploitToolExecution = DeviceProcessEvents
| where Timestamp > ago(LookbackPeriod)
| where ProcessCommandLine has_any (
    "kerberos::golden", "kerberos::silver", "kerberos::ptc", "kerberos::purge",
    "sekurlsa::kerberos", "lsadump::dcsync", "lsadump::lsa /patch",
    "goldenPac.py", "ticketer.py", "PyKEK", "ms14-068", "ms14_068",
    "Invoke-Kerberoast", "Request-SPNTicket", "Get-KerberosTicketGrantingTicket",
    "kerberos::list /export", "kerberos::ptt"
)
| extend DetectionBranch = "Exploit_Tool_Kerberos"
| project TimeGenerated = Timestamp, Computer = DeviceName,
          AccountName,
          Detail = ProcessCommandLine,
          DetectionBranch;
// Branch 3: Kerberos pre-authentication failure sweep — multiple failures across accounts from single source
let KerberosExploitSweep = SecurityEvent
| where TimeGenerated > ago(LookbackPeriod)
| where EventID == 4771
| where TargetUserName !endswith "$"
| summarize FailureCount = count(),
            AffectedAccounts = dcount(TargetUserName),
            Codes = make_set(Status, 5),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by IpAddress, Computer, bin(TimeGenerated, 10m)
| where FailureCount >= 5 and AffectedAccounts >= 2
| extend DetectionBranch = "Kerberos_Exploit_Sweep"
| project TimeGenerated = LastSeen, Computer,
          AccountName = strcat("Multiple (", tostring(AffectedAccounts), " accounts)"),
          Detail = strcat("Failures:", FailureCount, " Accounts:", AffectedAccounts, " SrcIP:", IpAddress, " Codes:", tostring(Codes)),
          DetectionBranch;
// Branch 4: Temporal correlation — Kerberos RC4 anomaly followed by high-privilege logon within 5 minutes
let RecentKerberosAnomaly = SecurityEvent
| where TimeGenerated > ago(LookbackPeriod)
| where EventID == 4769
| where TicketEncryptionType == "0x17" and ServiceName =~ "krbtgt"
| where TargetUserName !endswith "$"
| project KerberosTime = TimeGenerated, Computer, AnomalousUser = TargetUserName;
let PrivilegeEscalation = SecurityEvent
| where TimeGenerated > ago(LookbackPeriod)
| where EventID == 4672
| where PrivilegeList has_any ("SeDebugPrivilege", "SeTcbPrivilege", "SeAssignPrimaryTokenPrivilege", "SeTakeOwnershipPrivilege")
| where SubjectUserName !endswith "$"
| where SubjectUserName !in~ ("SYSTEM", "LOCAL SERVICE", "NETWORK SERVICE")
| project EscalationTime = TimeGenerated, Computer, EscalatedUser = SubjectUserName, Privileges = PrivilegeList;
let KerberosPrivEscChain = RecentKerberosAnomaly
| join kind=inner PrivilegeEscalation on Computer
| where EscalationTime > KerberosTime and EscalationTime <= KerberosTime + 5m
| where AnomalousUser =~ EscalatedUser
| extend DetectionBranch = "Kerberos_Exploit_PrivEsc_Chain"
| project TimeGenerated = EscalationTime, Computer,
          AccountName = EscalatedUser,
          Detail = strcat("Kerberos RC4 anomaly at:", tostring(KerberosTime), " — privilege escalation:", Privileges),
          DetectionBranch;
// Union all detection branches
union KerberosTGSAnomalies, ExploitToolExecution, KerberosExploitSweep, KerberosPrivEscChain
| sort by TimeGenerated desc

Multi-branch detection for T1212 Exploitation for Credential Access using Microsoft Sentinel SecurityEvent and Defender for Endpoint telemetry. Branch 1 identifies Kerberos TGS requests using RC4-HMAC (0x17) encryption against the krbtgt service — the hallmark of MS14-068 PAC forgery and golden/silver ticket attacks in modern AES-capable Active Directory environments. Branch 2 matches command-line patterns for known Kerberos exploitation tools including Mimikatz kerberos:: modules, goldenPac.py, PyKEK, and Kerberoasting scripts. Branch 3 detects automated exploitation sweeps by aggregating Kerberos pre-authentication failures (Event 4771) across multiple accounts from a single source within a 10-minute window. Branch 4 provides temporal correlation between Kerberos anomalies and subsequent high-privilege logon events (Event 4672) within 5 minutes, indicating a successful exploitation chain.

critical severity medium confidence

Data Sources

Authentication: Authentication Logon Session: Logon Session Creation Process: Process Creation Windows Security Event Log Microsoft Defender for Endpoint

Required Tables

SecurityEvent DeviceProcessEvents

False Positives

  • Legacy applications or domain-joined systems configured to only support RC4 Kerberos encryption that legitimately request krbtgt TGS tickets with TicketEncryptionType 0x17
  • Environments with mixed encryption policy (GPO: Network security: Configure encryption types allowed for Kerberos) where RC4 is explicitly permitted for compatibility with older systems
  • Authorized penetration testing or red team exercises using Kerberoasting, Mimikatz, or MS14-068 proof-of-concept tools — correlate with change management tickets and known testing windows
  • Monitoring, backup, or ITSM agents making frequent Kerberos service ticket requests that may trigger the pre-authentication failure sweep threshold
  • Domain controller promotion, demotion, or inter-site replication operations that trigger EventID 4672 with elevated privileges on DC accounts

Sigma rule & cross-platform mapping

The detection logic for Exploitation for Credential Access (T1212) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1MS14-068 Kerberos PAC Forgery Simulation (PyKEK)

    Expected signal: Security Event 4768 (TGT Request) from the affected user with anomalous PAC checksum values. Security Event 4769 (TGS Request) with TicketEncryptionType=0x17 (RC4) for krbtgt service. Sysmon Event 1: Process Create for python.exe with ms14-068.py in command line, followed by mimikatz.exe with kerberos::ptc. Network capture: oversized KRB_AS_REP packet containing the forged PAC structure.

  2. Test 2Golden Ticket Creation with Mimikatz (Requires krbtgt Hash)

    Expected signal: Sysmon Event 1: mimikatz.exe process create with 'kerberos::golden' and '/ptt' in command line. Security Event 4672 on the DC showing SeDebugPrivilege and SeTcbPrivilege for the injected Administrator ticket. Security Event 4624 (LogonType 3) on DC from localhost after 'dir \\dc\c$' succeeds. Security Event 4769 with EncType=0x17 for CIFS/HOST services on DC from non-DC workstation.

  3. Test 3Kerberos Replay Attack via Packet Capture and Ticket Injection

    Expected signal: Sysmon Event 1: tshark.exe capturing on network interface. Sysmon Event 1: mimikatz.exe with 'kerberos::ptc' injecting the stolen ticket. Sysmon Event 3: Network connections to KDC port 88 after ticket injection. Security Event 4769 with source IP matching the attacker's machine but user context matching the captured ticket's original owner.

  4. Test 4Cloud Authentication Token Replay (Azure AD - Storm-0558 Pattern)

    Expected signal: Azure AD Sign-In Logs: Successful authentication with the replayed token from an unexpected IP address, with UserAgent matching the attacker's tool (PowerShell/7.x or curl). Microsoft Purview Unified Audit Log: MailItemsAccessed operation for the target mailbox. Potential Microsoft Defender for Cloud Apps alert: 'Activity from anonymous IP address' or 'Impossible travel' if the replay IP differs significantly from the legitimate user's location.


Response Playbook

Triage

  1. Identify the detection branch that fired: RC4 TGS anomaly (Branch 1) is highest priority — query: SecurityEvent | where EventID == 4769 and TicketEncryptionType == '0x17' and ServiceName =~ 'krbtgt' | where TargetUserName == '<alert_user>' | project TimeGenerated, TargetUserName, IpAddress, TicketEncryptionType, TicketOptions
  2. Determine whether the source IP is a legitimate domain-joined workstation or an unexpected system: run 'nslookup <source_IP>' and check against AD computer objects. Workstations or non-DC servers requesting krbtgt TGS tickets with RC4 are highly suspicious
  3. Check the account's normal authentication patterns: SecurityEvent | where EventID in (4768, 4769) and TargetUserName == '<account>' | summarize count() by TicketEncryptionType, ServiceName, IpAddress | sort by count() desc — a sudden shift from AES to RC4 for the same account is a strong indicator
  4. If exploit tool execution was detected (Branch 2), immediately examine the full process tree: DeviceProcessEvents | where AccountName == '<account>' and DeviceName == '<host>' | where Timestamp > ago(1h) | project Timestamp, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine | sort by Timestamp asc — identify the parent process and the full attack chain
  5. Check for subsequent lateral movement: SecurityEvent | where EventID in (4624, 4648) and SubjectUserName == '<account>' | where LogonType in (3, 9, 10) | where TimeGenerated > '<alert_time>' | summarize count() by TargetServerName, TargetUserName, IpAddress — rapid access to multiple systems indicates the credential was immediately weaponized
  6. For cloud environments or Azure AD scenarios, review AADSignInLogs for the affected account: unusual UserAgent strings, impossible travel, or non-standard application IDs accessing mailboxes may indicate Storm-0558-style token exploitation

Containment

  1. If Kerberos forgery confirmed (MS14-068 / golden ticket): reset the krbtgt account password TWICE in succession (each reset invalidates all tickets issued under the previous key) — net use command: 'Set-ADAccountPassword -Identity krbtgt -NewPassword (ConvertTo-SecureString -AsPlainText -Force "<NewComplexPassword>")' — wait 10 minutes between resets to allow replication across all DCs
  2. Disable the affected user account immediately if exploitation of their credentials is confirmed: 'Disable-ADAccount -Identity <accountname>' and revoke all active Kerberos tickets for that account: 'klist purge' on affected sessions, or use 'Invoke-Command' to run klist purge on remote systems
  3. Isolate the source host identified in the Kerberos anomaly using EDR network isolation if malicious tool execution was confirmed on that endpoint — this prevents further lateral movement using forged tickets
  4. If domain-wide compromise is suspected (golden ticket scenario): force re-authentication of all domain accounts by resetting krbtgt twice AND enforcing a domain-wide password policy change for all privileged accounts — coordinate with domain admin team
  5. For cloud token exploitation (e.g., Storm-0558 pattern): revoke all OAuth tokens and sessions for the affected user through Azure AD: 'Revoke-AzureADUserAllRefreshToken -ObjectId <user_objectid>' and review conditional access policies to block token replay from unexpected IPs or device states
  6. Block the source IP at the perimeter firewall and domain controller firewall (netsh advfirewall) if exploitation originated from a known external or rogue internal host

Evidence Collection

  1. Windows Security Event Log from all Domain Controllers: collect events 4768, 4769, 4770, 4771, 4672, 4624, 4648 for the 24 hours surrounding the alert — these logs are the primary source of Kerberos exploitation evidence
  2. Kerberos ticket cache from affected systems: run 'klist' on the endpoint to enumerate currently cached tickets, noting any tickets with unusually long lifetimes, unexpected service principals, or suspicious encryption types
  3. Memory image of LSASS process if active exploitation is suspected: 'procdump -ma lsass.exe lsass.dmp' (with appropriate permissions) — contains credential material and in-memory Kerberos tickets that can be analyzed with Volatility or Mimikatz memory modules
  4. Network packet captures of Kerberos traffic (UDP/TCP port 88): tcpdump or Wireshark capture during active exploitation will show malformed PAC structures in AS-REQ/TGS-REQ packets characteristic of MS14-068; also look for oversized Kerberos tickets indicating padded PAC data
  5. Prefetch and execution artifacts for exploit tools: C:\Windows\Prefetch\MIMIKATZ.EXE-*.pf, GOLDENPA.EXE-*.pf, PYTHON.EXE-*.pf — timestamps indicate when tools were executed, file path entries show what modules were loaded
  6. Active Directory replication metadata: 'repadmin /showmeta CN=krbtgt,CN=Users,DC=<domain>' — check when the krbtgt password was last changed versus when the incident occurred; also 'repadmin /showvector /latency <dc_hostname>' to detect unusual replication patterns
  7. Sysmon logs from the endpoint where exploit tools were detected: Event IDs 1 (process create), 8 (CreateRemoteThread into LSASS), 10 (process access to LSASS), 17/18 (named pipe for privilege escalation)
  8. If cloud-based exploitation: Azure AD audit logs, unified audit log from Microsoft Purview, and signin logs — filter for the affected user's application access patterns in the 48 hours before the alert

Escalation Criteria

  • ! Confirmed RC4 Kerberos TGS request for krbtgt from a non-domain-controller source — this is the defining indicator of MS14-068 exploitation or golden/silver ticket use and requires immediate incident response
  • ! Exploit tool execution detected (Mimikatz kerberos modules, PyKEK, goldenPac.py) on any domain-joined system — treat as confirmed domain compromise until proven otherwise
  • ! Kerberos tickets observed with a lifetime exceeding 10 hours (default maximum) or valid outside normal business hours for the account — strong indicator of forged ticket with non-standard validity period
  • ! Lateral movement to domain controllers or critical systems (backup servers, CA servers, file servers with sensitive data) using the suspect account credentials within 30 minutes of the Kerberos anomaly
  • ! More than 3 domain accounts showing RC4 Kerberos anomalies within a 24-hour window from varied source IPs — indicates systematic exploitation or credential reuse campaign
  • ! Cloud authentication anomaly: token issued by non-standard endpoint or with unexpected claims scope — especially if the affected account accessed executive mailboxes, HR systems, or source code repositories

Investigation Guide

Forensic Artifacts

  • > Active Directory: NTDS.dit — if krbtgt hash was extracted, it enables unlimited golden ticket creation; check 'repadmin /showmeta CN=krbtgt' for unauthorized password reset timestamps
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos — encryption type policy settings; HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication — authentication package configuration
  • > File System: C:\Windows\Prefetch\ — execution artifacts for mimikatz.exe, python.exe (for PyKEK/goldenPac), cmd.exe; timestamps correlate with exploitation timeline
  • > File System: %TEMP% and %APPDATA% directories — Mimikatz output files (.kirbi ticket exports), debug logs, and temporary exploit tool artifacts
  • > Network: Wireshark/tcpdump capture of port 88 (KRB5) — malformed AS-REQ with unsigned PAC checksum (MS14-068), oversized TGS-REP tickets (forged PAC padding), or duplicate packet sequences (replay attacks)
  • > Event Log: Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational — KDC processing logs that show PAC validation failures before MS14-068 patch; Security event 4738 (user account changed) if account attributes were modified post-exploitation
  • > Event Log: Microsoft-Windows-Security-Auditing — Event 4964 (special groups assigned at logon) may appear when forged ticket presents unexpected group memberships
  • > Memory: LSASS process memory containing in-memory Kerberos tickets (klist /all on Windows), LSA secrets, and potentially the krbtgt NTLM hash if dumped
  • > Cloud: Azure AD sign-in logs — UserAgent field, TokenIssuedAt, IPAddress, ApplicationID; AAD audit logs for token refresh and revocation events; Entra ID risky sign-ins dashboard

Tuning Guidance

The primary source of false positives for Branch 1 (RC4 Kerberos TGS) is environments with legacy systems, printers, or applications that only support RC4 encryption. Before deploying, run the hunting query for 7 days to baseline RC4 usage in your environment. If RC4 is legitimately required, filter known legacy system hostnames and service account UPNs from the query — but never suppress the pattern entirely for the krbtgt service, as no legitimate client should request an RC4 krbtgt TGT in a patched modern environment. For Branch 2 (exploit tools), the command-line patterns are highly specific; false positives are rare but can occur from authorized security tooling like CrowdStrike threat hunting tools that may log similar strings. Allowlist by parent process hash and originating user account. For Branch 3 (sweep detection), tune the failure count and account diversity thresholds based on your environment's baseline Kerberos error rate — environments with large user populations or VPN-heavy access may see higher pre-auth failure rates. For Branch 4 (correlation), the 5-minute temporal window may need adjustment based on your mean time between Kerberos ticket request and actual service access in your environment. Enable KDC Audit Logging via GPO (Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy > Account Logon > Audit Kerberos Service Ticket Operations) to maximize Kerberos event coverage on all domain controllers. Ensure DCs forward Security events to your SIEM with minimal delay, as Kerberos exploitation often moves to lateral movement within minutes of successful ticket forgery.


Hunting Queries

Hunt for user accounts with disproportionate RC4 Kerberos ticket requests versus AES. A high RC4 ratio for a specific account, or RC4 tickets spanning many different services, suggests that forged tickets are being injected into the session rather than legitimately issued. Legitimate modern Windows clients use AES by default; RC4 usage at scale indicates either legacy misconfiguration or active ticket forgery.

Hunting — KQL
kql
// Hunt: Kerberos tickets with anomalous lifetime indicating forgery
// Legitimate Kerberos TGTs default to 10-hour maximum; forged golden tickets often set 10-year lifetimes
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4769
| where TargetUserName !endswith "$"
| where TicketOptions has "0x40810000"  // Forwardable, renewable, canonicalize — common in forged tickets
| summarize RC4Count = countif(TicketEncryptionType == "0x17"),
            AESCount = countif(TicketEncryptionType in ("0x11", "0x12")),
            TotalRequests = count(),
            DistinctServices = dcount(ServiceName),
            SourceIPs = make_set(IpAddress, 5)
    by TargetUserName, Computer
| where RC4Count > 0
| extend RC4Ratio = toreal(RC4Count) / toreal(TotalRequests)
| where RC4Ratio > 0.5 or (RC4Count > 0 and DistinctServices > 10)
| sort by RC4Count desc
Hunting — SPL
spl
index=wineventlog sourcetype="WinEventLog:Security" EventCode=4769
| rex field=_raw "Ticket Encryption Type:\s+(?<ExtTicketEncType>0x[0-9a-fA-F]+)"
| rex field=_raw "Account Name:\s+(?<ExtTargetAccount>[^\r\n]+)"
| rex field=_raw "Service Name:\s+(?<ExtServiceName>[^\r\n]+)"
| rex field=_raw "Client Address:\s+(?:::ffff:)?(?<ExtSourceIP>[^\r\n]+)"
| eval EncType=coalesce(TicketEncryptionType, ExtTicketEncType)
| eval TargetUser=coalesce(TargetUserName, ExtTargetAccount)
| where NOT match(TargetUser, ".*\$")
| stats count as TotalRequests,
        sum(eval(if(EncType="0x17",1,0))) as RC4Count,
        dc(ExtServiceName) as DistinctServices,
        values(ExtSourceIP) as SourceIPs
    by TargetUser, host
| eval RC4Ratio=RC4Count/TotalRequests
| where RC4Count > 0 AND (RC4Ratio > 0.5 OR (RC4Count > 0 AND DistinctServices > 10))
| sort - RC4Count

Hunt for RC4 Kerberos ticket requests targeting DC-specific service principals (LDAP, HOST, CIFS, RPC) from non-DC sources. Legitimate workstations may request these during normal AD operations, but RC4 encryption combined with targeting multiple DC service principals is suspicious — it may indicate a forged ticket being used to establish a connection to domain controllers for subsequent DCSync or NTDS dumping.

Hunting — KQL
kql
// Hunt: Kerberos ticket requests from workstations to sensitive service principals (DC services)
// Workstations should not request Kerberos tickets for LDAP, HOST, or cifs on Domain Controllers outside of normal operations
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4769
| where TargetUserName !endswith "$"
| where ServiceName has_any ("ldap/", "host/", "cifs/", "rpc/", "gc/")  // DC-associated service principals
| where TicketEncryptionType == "0x17"  // RC4 encryption
| join kind=leftouter (
    DeviceInfo
    | where Timestamp > ago(7d)
    | where DeviceType != "DomainController"
    | project DeviceName, DeviceType
    ) on $left.Computer == $right.DeviceName
| where isnotempty(DeviceType) and DeviceType != "DomainController"  // Request from non-DC
| summarize Count = count(), Services = make_set(ServiceName, 10) by TargetUserName, Computer, IpAddress, DeviceType
| where Count >= 2
| sort by Count desc
Hunting — SPL
spl
index=wineventlog sourcetype="WinEventLog:Security" EventCode=4769
| rex field=_raw "Service Name:\s+(?<ExtServiceName>[^\r\n]+)"
| rex field=_raw "Ticket Encryption Type:\s+(?<ExtTicketEncType>0x[0-9a-fA-F]+)"
| rex field=_raw "Account Name:\s+(?<ExtTargetAccount>[^\r\n]+)"
| rex field=_raw "Client Address:\s+(?:::ffff:)?(?<ExtSourceIP>[^\r\n]+)"
| eval EncType=coalesce(TicketEncryptionType, ExtTicketEncType)
| eval TargetUser=coalesce(TargetUserName, ExtTargetAccount)
| where EncType="0x17" AND NOT match(TargetUser, ".*\$")
| where match(ExtServiceName, "(ldap\/|host\/|cifs\/|rpc\/|gc\/)")
| stats count as ReqCount, values(ExtServiceName) as DCServices, dc(ExtServiceName) as ServiceCount by TargetUser, host, ExtSourceIP
| where ReqCount >= 2
| sort - ReqCount

Hunt for user accounts authenticating from 3 or more distinct source IP addresses within a single hour. This pattern is characteristic of credential replay attacks — where an attacker has obtained an authentication token and is using it from their infrastructure while the legitimate user also authenticates normally. High unique IP counts from a single account in a short window warrant investigation of whether authentication tokens are being replayed from unauthorized sources.

Hunting — KQL
kql
// Hunt: Authentication events with impossible geography or rapid source IP switching
// Credential exploitation may result in token replay from attacker infrastructure inconsistent with the legitimate user's location
let UserLoginHistory = SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4624
| where LogonType in (3, 10)  // Network and RemoteInteractive logons
| where SubjectUserName !endswith "$" and SubjectUserName !in~ ("ANONYMOUS LOGON", "")
| project TimeGenerated, Computer, SubjectUserName, IpAddress, LogonType;
UserLoginHistory
| summarize IPList = make_set(IpAddress, 20),
            IPCount = dcount(IpAddress),
            LoginCount = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by SubjectUserName, bin(TimeGenerated, 1h)
| where IPCount >= 3  // Three or more distinct source IPs in one hour for the same account
| sort by IPCount desc
Hunting — SPL
spl
index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624 (LogonType=3 OR LogonType=10)
| rex field=_raw "Account Name:\s+(?<ExtUser>[^\r\n]+)"
| rex field=_raw "Source Network Address:\s+(?<ExtSrcIP>[^\r\n]+)"
| eval AuthUser=coalesce(SubjectUserName, ExtUser)
| eval SrcIP=coalesce(IpAddress, ExtSrcIP)
| where NOT match(AuthUser, ".*\$") AND AuthUser!="ANONYMOUS LOGON" AND AuthUser!="-"
| bucket span=1h _time
| stats dc(SrcIP) as UniqueIPs, count as LoginCount, values(SrcIP) as IPList by AuthUser, host, _time
| where UniqueIPs >= 3
| sort - UniqueIPs

Atomic Red Team Tests

Test 1 MS14-068 Kerberos PAC Forgery Simulation (PyKEK)
windows

Simulates the MS14-068 Kerberos PAC forgery vulnerability using PyKEK (Python Kerberos Exploitation Kit). This exploit allows a domain user to forge a Privileged Attribute Certificate (PAC) in their TGT, claiming membership in the Domain Admins group without knowing the krbtgt hash. The attack requires: a valid domain user account, the user's password or NTLM hash, and network access to a domain controller on port 88. The forged ticket is saved as a .ccache file and can be injected into the session with kerberos::ptc in Mimikatz. WARNING: This will generate detectable Kerberos anomalies. Run only in authorized lab environments.

Command

powershell
python ms14-068.py -u <domain_user>@<domain> -p <password> -s <user_SID> -d <dc_hostname>
mimikatz.exe "kerberos::ptc TGT_<domain_user>@<domain>.ccache" exit

Cleanup

powershell
mimikatz.exe "kerberos::purge" exit
del TGT_*.ccache

Expected Telemetry

Security Event 4768 (TGT Request) from the affected user with anomalous PAC checksum values. Security Event 4769 (TGS Request) with TicketEncryptionType=0x17 (RC4) for krbtgt service. Sysmon Event 1: Process Create for python.exe with ms14-068.py in command line, followed by mimikatz.exe with kerberos::ptc. Network capture: oversized KRB_AS_REP packet containing the forged PAC structure.

Expected Detection

KQL Branch 1 fires: TicketEncryptionType=0x17 and ServiceName=krbtgt. KQL Branch 2 fires: ProcessCommandLine contains 'ms14-068' and 'kerberos::ptc'. Temporal correlation branch fires if privilege escalation follows within 5 minutes.

Test 2 Golden Ticket Creation with Mimikatz (Requires krbtgt Hash)
windows

Creates a Kerberos golden ticket using Mimikatz kerberos::golden module. A golden ticket is a forged TGT signed with the krbtgt NTLM hash, providing persistent domain access that survives password resets (until krbtgt is reset twice). This atomic requires the krbtgt NTLM hash (obtained via DCSync or NTDS.dit extraction in a prior step). The ticket is injected into the current session and immediately usable for lateral movement. Demonstrates the end-state of T1212 exploitation where the krbtgt hash is the target credential.

Command

powershell
mimikatz.exe "kerberos::golden /user:Administrator /domain:<domain_fqdn> /sid:<domain_SID> /krbtgt:<krbtgt_NTLM_hash> /id:500 /groups:512 /startoffset:0 /endin:600 /renewmax:10080 /ptt" exit
dir \\<dc_hostname>\c$

Cleanup

powershell
mimikatz.exe "kerberos::purge" exit

Expected Telemetry

Sysmon Event 1: mimikatz.exe process create with 'kerberos::golden' and '/ptt' in command line. Security Event 4672 on the DC showing SeDebugPrivilege and SeTcbPrivilege for the injected Administrator ticket. Security Event 4624 (LogonType 3) on DC from localhost after 'dir \\dc\c$' succeeds. Security Event 4769 with EncType=0x17 for CIFS/HOST services on DC from non-DC workstation.

Expected Detection

KQL Branch 2 fires immediately on 'kerberos::golden' command. KQL Branch 4 fires within minutes when 4672 appears on DC. SPL DetectionBranch=Exploit_Tool_Kerberos with SuspicionScore=5.

Test 3 Kerberos Replay Attack via Packet Capture and Ticket Injection
windows

Demonstrates a Kerberos replay attack by capturing a KRB_AP_REQ packet from legitimate network traffic and replaying it to impersonate the authenticated user. Uses Wireshark/tshark to capture Kerberos traffic on port 88, extracts the ticket from the capture, and converts it to .ccache format for injection. This simulates credential exploitation through authentication protocol weaknesses rather than hash extraction. In practice, services without replay detection or with clock skew misconfigurations are vulnerable.

Command

powershell
tshark.exe -i <interface> -f "port 88" -w kerberos_capture.pcap -a duration:30
python3 extract_kerberos_ticket.py kerberos_capture.pcap --output stolen_ticket.ccache
mimikatz.exe "kerberos::ptc stolen_ticket.ccache" exit
klist

Cleanup

powershell
mimikatz.exe "kerberos::purge" exit
del kerberos_capture.pcap stolen_ticket.ccache

Expected Telemetry

Sysmon Event 1: tshark.exe capturing on network interface. Sysmon Event 1: mimikatz.exe with 'kerberos::ptc' injecting the stolen ticket. Sysmon Event 3: Network connections to KDC port 88 after ticket injection. Security Event 4769 with source IP matching the attacker's machine but user context matching the captured ticket's original owner.

Expected Detection

KQL Branch 2: 'kerberos::ptc' in ProcessCommandLine. Network anomaly if the replayed ticket shows authentication from an unexpected IP. AAD Conditional Access or NLA may reject the ticket if device context checks are enforced.

Test 4 Cloud Authentication Token Replay (Azure AD - Storm-0558 Pattern)
windows

Simulates Azure AD token replay attack consistent with the Storm-0558 technique. An attacker who has obtained a valid OAuth2 access token (through phishing, memory extraction, or API exploitation) replays it from a different IP to access cloud resources. Uses PowerShell with the Az module or direct REST API calls with a stolen Bearer token to demonstrate unauthorized resource access. This does NOT forge tokens — it demonstrates replay of legitimately-issued tokens from unauthorized endpoints.

Command

powershell
$stolenToken = "<bearer_token_obtained_from_target_session>"
$headers = @{Authorization = "Bearer $stolenToken"; 'Content-Type' = 'application/json'}
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me" -Headers $headers -Method GET
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me/messages?$top=5" -Headers $headers -Method GET

Cleanup

powershell
# Revoke the token via Azure AD: Revoke-AzureADUserAllRefreshToken -ObjectId <user_objectid>

Expected Telemetry

Azure AD Sign-In Logs: Successful authentication with the replayed token from an unexpected IP address, with UserAgent matching the attacker's tool (PowerShell/7.x or curl). Microsoft Purview Unified Audit Log: MailItemsAccessed operation for the target mailbox. Potential Microsoft Defender for Cloud Apps alert: 'Activity from anonymous IP address' or 'Impossible travel' if the replay IP differs significantly from the legitimate user's location.

Expected Detection

AADSignInLogs alert on location anomaly or risky sign-in classification. Microsoft Sentinel Fusion alert correlating the token activity with prior suspicious activity. Custom KQL: AADSignInLogs | where UserPrincipalName == '<user>' | where IPAddress != '<known_corporate_range>' | where ResultType == 0 — fires on successful auth from unexpected IP.

Related Detections