Active Directory Defence and Detection

Active Directory is the backbone of enterprise identity — it controls authentication, authorisation, and access management for every user, computer, and service in the organisation. Attackers who compromise AD can move laterally to any system, persist indefinitely using forged credentials, and extract all credentials in the domain. Defending AD means detecting the specific attack techniques used against it: Kerberoasting, DCSync, Pass-the-Hash, Golden Tickets, and more — each of which leaves distinctive log artefacts that a well-configured SIEM can surface.

AD defence requires understanding both the attack techniques from the adversary's perspective and the specific Windows Security Event log entries each leaves behind. This is one of the most technically demanding areas of Blue Team work — and one of the most impactful, because AD compromise is the prerequisite for the worst-case outcomes in most enterprise breaches.

Why AD Attacks Are Especially Difficult to Detect

Active Directory attack techniques are particularly challenging to detect because many of them abuse legitimate AD protocols and functionality rather than exploiting software vulnerabilities. Kerberoasting uses the legitimate Kerberos service ticket request mechanism. DCSync uses the legitimate domain replication protocol. Pass-the-Hash uses legitimate NTLM authentication. BloodHound uses legitimate LDAP queries.

The result is that these attacks produce events that are indistinguishable from normal domain operations at the individual event level. Detection requires either contextual analysis (this is a legitimate event type, but from an anomalous account, source, or at an anomalous time), pattern recognition (this event type appearing in volume or in a specific sequence signals an attack), or the identification of specific field values that normal operations never produce (RC4 encryption on a modern domain that enforces AES, a Kerberos ticket with a 10-year lifetime).

Key AD Attack Techniques and Their Artefacts

Kerberoasting    T1558.003 -- Event 4769 (RC4 ticket request from non-service account)
AS-REP Roasting  T1558.004 -- Event 4768 (pre-auth not required, RC4 encrypted)
Pass-the-Hash    T1550.002 -- Event 4624 Type 3, NTLM auth, blank workstation name
DCSync           T1003.006 -- Event 4662 (DS-Replication-Get-Changes-All from non-DC)
Golden Ticket    T1558.001 -- Event 4769 anomalous ticket lifetime or disabled account
BloodHound enum  T1087.002 -- LDAP query volume spike, Event 4662 object access burst
Pass-the-Ticket  T1550.003 -- Event 4768/4769 from unexpected source addresses

The Windows Security Event Log Reference

Every AD attack detection maps to specific Windows Security Event IDs. Understanding which events to enable, where they are generated, and what fields within each event carry the detection signal is the foundation of AD monitoring. Most of these events are generated on Domain Controllers — DC log forwarding to your SIEM is a prerequisite for all of the following detections.

AD Attack Detection in Practice

Event 4769: Kerberos Service Ticket Requested
Time: 02:14:33  Account: jsmith@CORP.COM (normal user account)
Service: MSSQLSvc/sqlserver.corp.com
Ticket Encryption: 0x17 (RC4-HMAC)  <-- anomalous in modern AES-enforced AD
# Within 5 minutes: 12 more 4769 events from jsmith, all RC4
# Different services each time = Kerberoast sweep of all SPNs
# jsmith has no business reason to request SQL service tickets

Event 4662: Operation on Active Directory Object
Object Type: domainDNS
Accesses: Control Access
Properties: {1131f6aa-...} DS-Replication-Get-Changes-All
Account: jsmith  (not a DC or privileged sync account -- anomalous)
Source: CORP-WS-044  (a workstation -- DCs replicate from DCs, not workstations)
# Non-DC exercising replication rights = DCSync attack
# All domain password hashes are now in attacker hands

Event 4624: Successful Logon
Logon Type: 3 (Network)
Account: Administrator
Authentication Package: NTLM
Source: CORP-WS-044 (jsmith's workstation)
Workstation name: -  (blank -- PtH indicator; normal logins populate this)
# Pattern: NTLM + blank workstation name + privileged account + workstation source
# Legitimate network logons from workstations use Kerberos, not NTLM

# Normal user LDAP activity: a few queries per day (email lookups)
jsmith LDAP queries: 8/day (baseline)

# BloodHound run -- LDAP queries spike dramatically:
jsmith LDAP queries: 4,821 in 3 minutes
Querying: all users, all groups, all computers, all GPOs, all trusts
# BloodHound systematically enumerates every AD object type
# 4000+ LDAP queries in minutes is the unmistakeable BloodHound signature

Event 4769: Kerberos Service Ticket Request
Ticket Lifetime: 10 years  (default maximum is 10 hours -- massive anomaly)
Account: Administrator (but this account is disabled in AD)
Encryption: 0x17 (RC4)  (attacker used RC4 to avoid AES requirement check)
# 10-year lifetime + disabled account = Golden Ticket
# KRBTGT password must be reset TWICE (with replication delay between) to invalidate

What You Need to Know

Kerberos Architecture — Why Attacks Leave Specific Artefacts

Understanding why Kerberoasting, Golden Tickets, and AS-REP Roasting leave the specific detection signatures they do requires understanding how Kerberos authentication actually works. Defenders who understand the protocol rather than just the signatures can reason about novel variations on these attacks and understand what their SIEM alerts actually mean.

The Kerberos Flow in Three Steps

Kerberos authentication uses a trusted third party (the Key Distribution Centre, KDC, running on the Domain Controller) to enable clients and services to authenticate to each other without transmitting passwords over the network. The process has three distinct exchanges:

1. AS-REQ / AS-REP (Authentication Service): The client requests a Ticket-Granting Ticket (TGT) from the KDC, proving identity by pre-authenticating with a timestamp encrypted with the user's password hash. The KDC returns a TGT encrypted with the KRBTGT account hash — valid for 10 hours by default. This is where AS-REP Roasting targets accounts with pre-authentication disabled: the KDC returns the AS-REP without requiring the pre-authentication proof, giving the attacker encrypted material to crack offline.
2. TGS-REQ / TGS-REP (Ticket-Granting Service): The client presents the TGT and requests a Service Ticket (ST) for a specific service. The KDC issues the ST encrypted with the service account's password hash — without the service account being involved. This is the Kerberoasting opportunity: any domain user can request service tickets for any SPN-registered account, and the returned ticket is encrypted with that service account's hash, available for offline cracking.
3. AP-REQ (Application Protocol): The client presents the Service Ticket to the target service, which decrypts it with its own password hash to confirm validity. The service never contacts the KDC — it trusts the cryptographic chain.

The Golden Ticket attack forges Step 1's output — a TGT — using the KRBTGT hash obtained through DCSync. Because services only verify the cryptographic validity of tickets (Step 3), a mathematically valid forged TGT with arbitrary contents (any username, any group membership, any lifetime) is accepted as legitimate by every service in the domain.

# Detection: Event 4768 with pre-auth type 0
Event 4768: Kerberos Authentication Ticket (TGT) Requested
Account Name: svc_legacy
Pre-Authentication Type: 0  (pre-authentication disabled on this account!)
Ticket Encryption Type: 0x17 (RC4)
# The AS-REP is returned encrypted with the account's hash
# Attacker can crack this offline without any domain credential

# Immediate remediation query -- find all AS-REP roastable accounts:
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties *
svc_legacy, svc_oldapp, testuser  (3 accounts with pre-auth disabled)

# Fix: enable pre-authentication on all accounts unless explicitly required
Set-ADAccountControl svc_legacy -DoesNotRequirePreAuth $false

SIEM Rule Design — Reducing False Positives While Catching Attacks

Raw event log monitoring produces enormous volumes of noise. Effective AD detection requires tuned SIEM rules that alert on specific field combinations rather than event IDs in isolation, and that incorporate baseline context to distinguish anomalous from expected behaviour. The goal is high-confidence alerts with low false-positive rates — an alert that fires hundreds of times per day trains analysts to ignore it.

--- Kerberoasting detection ---
WHERE EventID = 4769
  AND TicketEncryptionType = "0x17"
  AND AccountName NOT LIKE "%$"   -- exclude computer accounts
  AND ServiceName NOT IN ("krbtgt", "host/*")
HAVING COUNT(*) BY AccountName, SourceIP OVER 5 minutes > 3
SEVERITY: High

--- DCSync detection (highest confidence -- zero legitimate false positives) ---
WHERE EventID = 4662
  AND ObjectType CONTAINS "domainDNS"
  AND Properties CONTAINS "1131f6aa"  -- DS-Replication-Get-Changes-All GUID
  AND SubjectUserName NOT IN [domain_controller_accounts]
SEVERITY: Critical — page on-call immediately

--- Pass-the-Hash detection ---
WHERE EventID = 4624
  AND LogonType = 3
  AND AuthenticationPackage = "NTLM"
  AND WorkstationName = ""           -- blank = PtH indicator
  AND TargetUserName IN [privileged_accounts]
SEVERITY: High

--- Golden Ticket detection ---
WHERE EventID = 4769
  AND TicketOptions CONTAINS "forwardable"
  AND (TicketEncryptionType = "0x17"
       OR AccountName IN [disabled_privileged_accounts]
       OR TicketLifetime > 600)     -- >600 minutes is anomalous
SEVERITY: Critical

Structural AD Hardening — Making Attacks More Difficult and More Visible

Detection capability is the response to attacks that occur. Structural hardening raises the cost and complexity of attacks, reduces the available techniques, and makes detection signals cleaner by eliminating the legitimate activity that masquerades as attacks. The most impactful hardening controls address the specific weaknesses each technique exploits.

Eliminating the Kerberoasting Surface

Kerberoasting succeeds because service accounts with SPNs use password-based encryption for service tickets, and those passwords are often weak. Three controls eliminate or dramatically reduce this attack surface:

• Group Managed Service Accounts (gMSA): gMSAs are AD accounts with automatically managed, randomly generated 240-character passwords that rotate every 30 days. Because the password is random and rotates automatically, cracking a gMSA Kerberos ticket is computationally infeasible — the attack is rendered useless. Migrate all service accounts to gMSA where the application supports it.
• AES enforcement: Configure the domain to require AES encryption for Kerberos tickets. This makes RC4 ticket requests immediately visible as anomalous and prevents older, faster RC4-based cracking from applying even if tickets are captured.
• Service account password complexity: For accounts that cannot use gMSA, enforce minimum 25-character random passwords stored in a secrets manager. At 400,000 attempts/second, a 25-character random alphanumeric password takes longer than the age of the universe to crack.

The Tiered Administration Model

Pass-the-Hash and credential theft attacks succeed because administrators use their privileged credentials on workstations and servers where credential-harvesting tools can extract them from memory. The tiered administration model prevents this by ensuring that privileged credentials are only ever used on machines of equivalent trust.

• Tier 0 (Domain Controllers and domain services): Only Tier 0 admin accounts log in. No internet access, no email, no general applications on DCs or Tier 0 admin workstations.
• Tier 1 (Member servers): Only Tier 1 admin accounts log in to servers. These accounts never log in to workstations or DCs.
• Tier 2 (Workstations): Standard user accounts and local admin accounts only. Domain admin credentials are never used on workstations — if a workstation is compromised, no credential harvesting yields Tier 0 or Tier 1 credentials.

Enforcement is through logon restrictions configured via Group Policy — Domain Admins group is specifically denied logon to workstations, preventing the credential from being used even if an admin attempts it. Microsoft's Privileged Access Workstations (PAW) documentation provides the implementation guidance.

Core Concepts Summary