Credential Access Detection Beyond LSASS — The Five Techniques Your Rules Are Missing

Every credential access detection post you will find online covers LSASS. It's the first technique red teamers learn, the first detection blue teamers write, and the first rule MDE's built-in analytics includes. If your detection program stops at "alert when something reads LSASS memory," you detect the attacker who runs default Mimikatz. You miss the attacker who Kerberoasts a service account, cracks the hash offline, and authenticates as a domain admin without touching LSASS at all.

This post covers five credential access techniques, each targeting a different data store, generating different telemetry, and requiring a different detection approach. The KQL rules are production-grade — not simplified examples, but the actual queries you would deploy as Sentinel analytics rules or run in Advanced Hunting. Each includes the false positive analysis and tuning guidance that determines whether the rule survives its first week in production.

1. LSASS memory access — the baseline you already have

LSASS stores NTLM hashes, Kerberos ticket-granting tickets, and cached domain credentials for every user who has authenticated to the endpoint. The Sysmon Event ID 10 (ProcessAccess) record captures the handle acquisition that precedes every memory read.

The detection signal is the GrantedAccess mask. Legitimate processes that interact with LSASS — like antivirus and backup agents — use PROCESS_QUERY_LIMITED_INFORMATION (0x1000). Credential dumping requires PROCESS_VM_READ (0x0010) at minimum, and most tools request PROCESS_ALL_ACCESS (0x1F0FFF). The query filters on access masks that include the read capabilities.

// Credential access — LSASS memory read via non-standard process
DeviceProcessEvents
| where Timestamp > ago(1d)
| where FileName =~ "lsass.exe"
| join kind=inner (
    DeviceEvents
    | where ActionType == "OpenProcessApiCall"
    | where AdditionalFields has "0x1010"
        or AdditionalFields has "0x1FFFFF"
    | where InitiatingProcessFileName !in~
        ("MsMpEng.exe", "csrss.exe", "svchost.exe",
         "lsass.exe", "WmiPrvSE.exe", "taskmgr.exe")
) on DeviceId
| project Timestamp, DeviceName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    InitiatingProcessParentFileName

False positive sources: Inventory scanning tools, some backup agents, AV products other than Defender. Each legitimate tool appears consistently from a known path and binary hash. An attacker's access appears once, from an unusual parent process (PowerShell, rundll32, a temp directory executable), and often during non-business hours.

Tuning: Add your environment's known legitimate LSASS accessors to the exclusion list by InitiatingProcessFileName. Do not exclude by path — an attacker can place their tool at the same path as a legitimate binary.

This rule is necessary but insufficient. An attacker who encounters LSASS protection (ASR rule, PPL, Credential Guard) pivots to techniques that never touch LSASS.

2. Kerberoasting — cracking service accounts offline

Kerberoasting requests Kerberos service tickets (TGS) for service accounts with SPNs, then cracks the ticket's encryption offline to recover the account's password. The attack uses legitimate Kerberos protocol operations — the TGS request itself is how Kerberos is supposed to work. The detection challenge is distinguishing an attacker requesting tickets for 50 service accounts in 30 seconds from a legitimate application authenticating to a service.

The Windows Security Event ID 4769 (Kerberos Service Ticket Operation) records every TGS request. The critical field is the encryption type. Modern Kerberos uses AES-256 (0x12) or AES-128 (0x11). Kerberoasting tools request RC4 encryption (0x17) because RC4 tickets are significantly faster to crack. A spike in RC4 TGS requests from a single source is the high-fidelity detection signal.

// Kerberoasting — RC4 service ticket requests at volume
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"  // RC4
| where ServiceName !endswith "$"  // exclude machine accounts
| where ServiceName != "krbtgt"
| summarize
    TicketCount = count(),
    TargetServices = make_set(ServiceName),
    ServiceCount = dcount(ServiceName)
    by IpAddress, AccountName, bin(TimeGenerated, 5m)
| where ServiceCount > 3
| project TimeGenerated, AccountName, IpAddress,
    ServiceCount, TicketCount,
    TargetServices = tostring(TargetServices)

Why ServiceCount > 3: A legitimate application requests one or two service tickets during authentication. An attacker running Rubeus kerberoast or Invoke-Kerberoast requests tickets for every SPN-bearing account in the domain — typically 10-50+ in a single burst. The threshold of 3 unique services within a 5-minute window catches the attack while allowing normal authentication patterns.

False positive sources: Service discovery tools, AD health monitoring, some ITSM platforms that enumerate service accounts. These typically use AES, not RC4. If your environment has legitimate RC4 usage (legacy applications), the false positive volume may be higher — but the volume + time window correlation still separates attack from normal.

The Sigma equivalent (for teams running Splunk, Elastic, or other SIEMs):

title: Potential Kerberoasting - RC4 Service Ticket Request Spike
id: 8f7d3b1a-credential-access-kerberoast
status: experimental
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769
        TicketEncryptionType: '0x17'
    filter:
        ServiceName|endswith: '$'
    condition: selection and not filter
        | count(ServiceName) by IpAddress > 3
level: high
tags:
    - attack.credential_access
    - attack.t1558.003

If you don't have Security Event Log data in Sentinel (Event ID 4769 requires forwarding domain controller Security logs), MDE's IdentityQueryEvents provides partial coverage:

// Kerberoasting via MDE identity tables (no DC log forwarding required)
IdentityQueryEvents
| where Timestamp > ago(1d)
| where ActionType == "LDAP query"
| where QueryTarget has "servicePrincipalName"
| summarize QueryCount = count()
    by DeviceName, AccountName, bin(Timestamp, 5m)
| where QueryCount > 10

This catches the SPN enumeration that precedes Kerberoasting — the attacker querying AD for accounts with SPNs — rather than the TGS request itself. It works without domain controller log forwarding, which makes it deployable in environments where DC event collection is not yet configured.

3. DCSync — replicating the domain controller's database

DCSync abuses Active Directory's replication protocol. An attacker with the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All permissions (held by Domain Admins, Domain Controllers, and accounts with delegated replication rights) can request the password hash of any account directly from a domain controller — including the krbtgt account, which enables Golden Ticket attacks.

The detection is Security Event ID 4662 (An operation was performed on an object) with the specific access rights GUIDs for directory replication. The critical distinction: domain controllers replicate with each other constantly (this is how AD works). DCSync is a non-DC device performing the same replication request.

// DCSync — AD replication from a non-domain-controller
SecurityEvent
| where EventID == 4662
| where AccessMask == "0x100"
| where Properties has "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"
    or Properties has "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
    or Properties has "89e95b76-444d-4c62-991a-0facbeda640c"
| where SubjectUserName !endswith "$"
| where Computer !in (
    "DC01.contoso.com", "DC02.contoso.com"
    // Replace with your DC hostnames
)
| project TimeGenerated, SubjectUserName,
    Computer, ObjectName, Properties

The three GUIDs represent: DS-Replication-Get-Changes (1131f6aa), DS-Replication-Get-Changes-All (1131f6ad), and DS-Replication-Get-Changes-In-Filtered-Set (89e95b76). Any non-DC requesting these operations is performing DCSync.

False positive sources: Azure AD Connect servers performing directory synchronization. These should be in a known, documented list. If you are not sure which servers run AAD Connect, the query results will tell you — the false positives are your AAD Connect infrastructure.

Tuning: Maintain an explicit allowlist of servers permitted to perform replication (domain controllers + AAD Connect). Any device not on the list triggering this rule is a confirmed incident, not a tuning task.

MDE's identity protection provides an additional detection layer:

// DCSync via MDE identity tables
IdentityDirectoryEvents
| where Timestamp > ago(1d)
| where ActionType == "Directory Service Replication"
| where DestinationDeviceName !in (
    "DC01", "DC02"  // Your DCs
)
| project Timestamp, AccountName,
    DestinationDeviceName, TargetDeviceName,
    AdditionalFields

4. SAM hive extraction — the offline credential dump

The SAM (Security Account Manager) registry hive stores local account password hashes. An attacker with SYSTEM privileges can extract the SAM hive using reg save HKLM\SAM sam.save, then crack the hashes offline. On domain controllers, the equivalent is extracting NTDS.dit — the Active Directory database containing every domain account hash.

The detection targets the specific commands and tools used for extraction: reg save targeting SAM or SECURITY hives, ntdsutil creating an IFM (Install From Media) snapshot, vssadmin creating shadow copies to access locked hive files, and esentutl copying NTDS.dit.

// SAM/NTDS extraction — suspicious registry save or database copy
DeviceProcessEvents
| where Timestamp > ago(1d)
| where (
    // reg save targeting credential hives
    (FileName =~ "reg.exe"
     and ProcessCommandLine has_any ("save", "export")
     and ProcessCommandLine has_any
         ("sam", "security", "system"))
    // ntdsutil IFM creation
    or (FileName =~ "ntdsutil.exe"
        and ProcessCommandLine has_any
            ("ifm", "snapshot", "activate instance"))
    // vssadmin shadow copy for hive access
    or (FileName =~ "vssadmin.exe"
        and ProcessCommandLine has "create shadow")
    // esentutl copying NTDS.dit
    or (FileName =~ "esentutl.exe"
        and ProcessCommandLine has_any
            ("ntds", "recovery"))
)
| project Timestamp, DeviceName, AccountName,
    FileName, ProcessCommandLine,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine

False positive sources: Legitimate backup operations (vssadmin), AD disaster recovery procedures (ntdsutil IFM), and GPO troubleshooting (reg save of the SECURITY hive). These are infrequent, documented, and performed from known admin accounts during known maintenance windows.

Tuning: This rule should have a very low threshold for alerting. reg save of the SAM hive from an interactive user session is almost never legitimate. Flag every hit for investigation and maintain a short exclusion list based on confirmed backup processes.

5. DPAPI credential extraction — the technique nobody detects

DPAPI (Data Protection API) protects sensitive data in Windows: saved browser passwords, WiFi credentials, RDP saved passwords, certificate private keys, and application credentials. The master key that encrypts this data is stored per-user in %APPDATA%\Microsoft\Protect\. An attacker who extracts the master key can decrypt every DPAPI-protected credential on the endpoint — without touching LSASS.

Most detection programs do not cover DPAPI extraction because it uses legitimate Windows APIs and the file access patterns look similar to normal application behavior. The detection requires monitoring for specific tools (SharpDPAPI, Mimikatz dpapi module) and anomalous access to the DPAPI master key directory.

// DPAPI master key access by suspicious process
DeviceFileEvents
| where Timestamp > ago(1d)
| where FolderPath has @"\Microsoft\Protect\"
| where ActionType in ("FileRead", "FileAccessed")
| where InitiatingProcessFileName !in~
    ("lsass.exe", "svchost.exe", "System",
     "SearchProtocolHost.exe", "explorer.exe",
     "OneDrive.exe")
| project Timestamp, DeviceName, AccountName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    FolderPath, FileName

Why this matters: An attacker blocked from dumping LSASS by Credential Guard still gets passwords through DPAPI. Browser-saved passwords, RDP credentials, and WiFi keys are all accessible. Credential Guard protects Kerberos and NTLM material. DPAPI is a separate system with its own key hierarchy — Credential Guard does not protect it.

False positive sources: OneDrive syncing encrypted files, Windows Search indexing, and some enterprise password managers. The exclusion list above handles the common system processes. Add your environment-specific password management tools.

What to deploy this week

These five rules cover the credential access techniques that appear in the majority of real-world attack chains. Deploy them as Sentinel analytics rules with a 24-hour lookback and 1-hour frequency. Start in audit — review the first week's results, build exclusions for your environment's legitimate tools, then promote to alert-generating.

Priority order:

1. LSASS — if you don't have this, start here. It catches the largest number of commodity attacks.
2. Kerberoasting — the most common alternative when LSASS is protected. High volume of real attacks targeting service accounts with weak passwords.
3. DCSync — high severity, low noise. Any non-DC replication request is a confirmed incident.
4. SAM/NTDS — catches the offline extraction path. Low noise on non-DC endpoints.
5. DPAPI — the gap in most programs. Deploy after the first four are stable.

The Sigma rule repository (SigmaHQ/sigma) contains community-maintained equivalents for techniques 1-4. The MITRE ATT&CK Navigator lets you visualize your credential access coverage. Atomic Red Team provides test scripts for each technique so you can validate your rules fire correctly.

The Endpoint Security course covers the OS internals behind each technique — why LSASS stores what it stores, how Kerberos authentication creates the material Kerberoasting exploits, and how DPAPI key hierarchy works. The Detection Engineering course walks through the full rule lifecycle for each technique: from hypothesis through specification, testing, deployment, and tuning. Both courses start with free modules — no account required.