Active Directory Alert Triage

Question 1: Has the attacker obtained domain admin credentials? If the alert involves DCSync, pass-the-hash with a domain admin account, or golden ticket usage, the answer is yes or probable. This triggers emergency response, not standard triage. The incident team must assume the attacker can access any system and begin scoping from that assumption.

Question 2: Has the attacker obtained the KRBTGT hash? DCSync for the KRBTGT account is the specific indicator. If the IdentityDirectoryEvents show a replication request targeting the KRBTGT object from a non-DC source, the attacker can forge unlimited golden tickets. Containment requires a KRBTGT password reset (twice, per Microsoft's guidance): a disruptive action that invalidates all existing Kerberos tickets in the domain.

Question 3: Can the attacker persist beyond credential reset? Golden tickets forged before the KRBTGT reset remain valid for the ticket's lifetime (default 10 hours). Skeleton key attacks persist until the DC is rebooted. Backdoor accounts in privileged groups persist until discovered and removed. The triage responder flags these persistence possibilities for the investigation team.

FP patterns: Service accounts with expired passwords generating repeated failures. Users who forgot their password and are trying variations. Application servers with cached credentials for a changed password. Check the targeted account: if it is a service account and the failures occur at a regular interval (every 5 minutes, matching a service restart cycle), it is a misconfiguration, not an attack.

Triage decision: Zero successes from a single source = close as detected attack, document the source IP, add to watchlist. One or more successes = probable TP, run the 10-command triage (TR3.1) on the system that authenticated successfully, check for post-authentication lateral movement.

Account enumeration

What this means: The attacker is querying Active Directory for account information, typically through LDAP queries for user accounts, group memberships, service principal names (SPNs), or computer accounts. This is reconnaissance: the attacker is mapping the environment before attacking it.

Triage procedure: Account enumeration from a workstation is suspicious (users do not run LDAP enumeration tools). Account enumeration from a known IT admin system during business hours MAY be legitimate (AD administration). The source system determines the classification:

// KQL: LDAP enumeration from the alerting device
IdentityQueryEvents
| where TimeGenerated > ago(4h)
| where DeviceName =~ "DESKTOP-NGE042"
| where ActionType == "LDAP query"
| summarize QueryCount = count(), UniqueQueries = dcount(QueryTarget) by AccountName
| where QueryCount > 50  // Threshold for unusual volume

At NE, the CHAIN-PRIVILEGE attacker ran SharpHound (the BloodHound data collector) from a compromised workstation, generating thousands of LDAP queries in 3 minutes. The volume and diversity of queries (users, groups, OUs, GPOs, trusts) immediately distinguished it from legitimate admin activity.

FP pattern: IT administrators running AD administration tools (ADUC, ADSI Edit, AD PowerShell), SCCM discovery cycles, vulnerability scanners querying AD for host inventory. These produce LDAP query volume but with predictable patterns and from known admin systems.

At NE, the CHAIN-PRIVILEGE attacker Kerberoasted 15 service accounts from a compromised workstation. One service account (svc-backup) had a password that was crackable in 4 hours. The attacker used the svc-backup credentials to access the backup infrastructure and delete offsite backup copies before deploying ransomware.

FP pattern: Penetration testing (check for change tickets. TR0.7 Alert 5 covers this exact scenario). Some monitoring tools that enumerate service accounts. IT administrators auditing service account SPNs.

Triage decision: If the Kerberoasting came from a compromised endpoint (cross-reference with endpoint alerts): confirmed TP, probable credential compromise. The investigation team must assess: which service accounts were targeted, do any have weak passwords (the attacker will have cracked them), and do any have privileged access? The triage responder cannot determine whether the cracking succeeded, only the investigation team (or a proactive password audit) can assess that. But the triage report should flag: "Kerberoasting of 15 service accounts detected. Assume credentials compromised for accounts with weak passwords. Priority: identify which targeted accounts have administrative privileges."

NTLM relay

What this means: The attacker is relaying NTLM authentication from one system to another, capturing an authentication attempt and forwarding it to a different target to gain access. This is a network-level credential theft technique that does not require knowing the password.

Triage procedure: NTLM relay requires the attacker to be positioned on the network between the victim and the target (man-in-the-middle). The Defender for Identity alert identifies the relay pattern: the same NTLM authentication appears at two different targets within milliseconds. The source system that initiated the authentication may be compromised (the attacker triggered the authentication), or the attacker may be intercepting legitimate traffic.

Check: is NTLM signing enforced in the domain? If yes, relay attacks should fail (signing prevents the relayed authentication from being accepted). If no: this is a domain configuration weakness that the attacker is exploiting. Flag for the investigation team: NTLM signing should be enforced as a remediation action.

Pass-the-hash

What this means: The attacker is authenticating using a stolen NTLM hash rather than a password. The hash was obtained from a credential dump (LSASS, SAM database, or NTDS.dit). The attacker does not know the password, they use the hash directly for NTLM authentication.

Triage procedure: The critical question: WHOSE hash is being used? An attacker passing the hash of a standard user account has limited access. An attacker passing the hash of a domain admin account has unrestricted access. Check the account in the alert:

// KQL: Check if the passed hash belongs to a privileged account
IdentityDirectoryEvents
| where TimeGenerated > ago(30d)
| where ActionType == "Group Membership change"
| where DestinationDeviceOrGroup has_any ("Domain Admins", "Enterprise Admins", "Schema Admins")
| where TargetAccountUpn =~ "svc-backup@northgateeng.com"  // Account from the alert

If the account is a member of Domain Admins, Enterprise Admins, or Schema Admins: escalate as CRITICAL. The attacker has domain admin access via hash. If the account is a standard user: escalate as HIGH. The attacker has lateral movement capability but not domain dominance.

The KRBTGT check: If TargetAccountUpn includes "krbtgt", the attacker has obtained the KRBTGT hash and can forge golden tickets for any account. This is the worst-case Active Directory compromise. Escalate immediately. The investigation team must plan a KRBTGT password reset (twice: the first reset creates a new hash, the second invalidates the old hash which is still cached in the DC's history). This reset invalidates every Kerberos ticket in the domain and requires all users and services to re-authenticate: a significant operational disruption that must be coordinated with IT and business leadership.

At NE, the CHAIN-PRIVILEGE attacker executed DCSync from a compromised workstation at 01:30, targeting the KRBTGT account and 4 domain admin accounts. Rachel's triage classified this as CRITICAL within 3 minutes of the alert. The KRBTGT reset was executed at 02:15 (coordinated with Phil's IT team, who re-authenticated critical services over the next 4 hours).

FP pattern: Essentially zero for DCSync from non-DC sources. The only conceivable FP: a misconfigured tool that accidentally performs replication requests, extremely rare and easily verified by checking with the IT team.

Golden ticket usage

What this means: The attacker is using a forged Kerberos TGT (golden ticket) to authenticate as any user. Golden tickets are created using the KRBTGT hash obtained via DCSync. The ticket is valid for its configured lifetime (default 10 hours) and bypasses all authentication controls except Kerberos ticket validation.

Triage procedure: Defender for Identity detects golden tickets through anomalies in the Kerberos ticket: ticket lifetime exceeding policy, ticket issued by a non-existent or renamed KRBTGT account, or ticket with an impossible encryption type. The alert confirms the KRBTGT hash was compromised (you cannot forge a golden ticket without it).

Triage decision: If a golden ticket alert fires: the KRBTGT hash is compromised. This is a confirmed domain compromise regardless of any other alert context. The previous DCSync attack (which provided the hash) may have occurred days or weeks ago. The golden ticket is the EXPLOITATION of the stolen hash. Containment requires KRBTGT reset, but the golden ticket remains valid until its lifetime expires (up to 10 hours after the reset, for tickets forged before the reset).

Immediate actions: (1) Begin KRBTGT password reset coordination with IT. (2) Identify the account being impersonated by the golden ticket. (3) Isolate the system from which the golden ticket is being used. (4) Escalate to the CISO, domain compromise requires executive notification.

Skeleton key

What this means: The attacker has installed a skeleton key on a domain controller. A skeleton key patches the LSASS process on the DC to accept a master password for ANY account while still accepting the legitimate password. This means every account in the domain has a second password that only the attacker knows. Skeleton key attacks are rare but devastating.

Triage procedure: Skeleton key detection requires monitoring for unusual LSASS behavior on domain controllers. Defender for Identity detects it through specific anomalies in the DC's authentication processing. The alert is ALWAYS a TP, there is no legitimate reason for the LSASS process on a DC to be patched with an additional authentication provider.

Containment: Reboot the affected domain controller. The skeleton key exists only in memory, it does not survive a reboot. However, the attacker may reinstall it after the reboot if they retain access to the DC. The investigation team must determine how the attacker gained DC access and eradicate that access path before the reboot.

Credential theft alerts (Kerberoasting, NTLM relay, pass-the-hash): Escalate as HIGH. The attacker has credentials (or is attempting to obtain them). Even if the specific stolen credentials have limited privileges, the attacker is one escalation step from domain compromise. The investigation team must assess: which credentials were stolen, what access do they grant, and has the attacker used them to escalate further?

Domain dominance alerts (DCSync, golden ticket, skeleton key): Escalate as CRITICAL, immediate CISO notification. Domain compromise means the attacker can access every system, read every email, modify any configuration, and persist indefinitely. This is not a triage-and-close alert. This is an emergency response requiring: KRBTGT reset planning, full AD health assessment, and potentially a complete credential rotation for all accounts.

Worked artifact: AD alert escalation matrix