Master privilege escalation detection in Active Directory — understanding why Event 4728 on privileged groups is the highest-priority alert in any enterprise environment, tracing the session and account chain that made the change, assessing post-escalation damage in the 72-second window before credential dump, and executing the complete remediation sequence including the critical KRBTGT double reset.
Privilege Escalation in Active Directory
In an enterprise environment, privilege escalation means gaining elevated permissions — adding an account to Domain Admins, assigning privileged roles, or granting local admin rights. These changes are logged by Windows, but only a trained analyst knows which events matter and how to respond.
The Privilege Escalation Kill Chain
Privilege escalation in AD rarely happens in a single step. It typically follows a kill chain: initial access via phishing or exploitation, lateral movement to a host with cached privileged credentials, then use of those credentials to add an attacker-controlled account to a high-privilege group. Understanding the full chain is what allows an analyst to correctly scope the incident — finding only the final escalation event without understanding the prior steps leads to incomplete remediation.
The three most common escalation paths into Domain Admins are: Pass-the-Hash using a DA's cached NTLM hash from a compromised workstation; Kerberoasting a high-privilege service account and cracking the ticket offline; and direct credential theft via Mimikatz on a machine where a DA recently authenticated. In all three cases, the final forensic evidence is the same Event 4728 — but the remediation scope differs dramatically based on which path was used.
Active Directory privilege groups are like the master key cabinet in a large organisation. The Domain Admins group is the cabinet containing keys to every door in every building. Normal staff have individual keys for their specific areas. An attacker's goal is to get into that cabinet and make a copy. Event 4728 is the alert that fires when someone opens that cabinet and adds a new key. The alert at 2am tells you someone opened the cabinet outside of all business hours — but the investigation must trace back how they got into the building in the first place, and determine whether they already made copies before the alarm was raised.
Critical Privilege Event IDs
4728 Member added to security-enabled global group (e.g. Domain Admins) 4729 Member removed from security-enabled global group 4732 Member added to security-enabled local group (e.g. local Administrators) 4672 Special privileges assigned to new logon (admin session — DA logged in) 4720 New user account created (attacker backdoor account) 4738 User account changed (password, flags, lockout status modified)
Privilege Escalation Investigation
Event 4728 targeting Domain Admins at 2am — no legitimate administration happens at this hour from a standard user account. This is unconditionally a critical alert.
Event 4728 -- Member Added to Security-Enabled Global Group Time: 2026-05-15 02:14:33 Group: Domain Admins Member: CN=svc_backup,OU=Service Accounts,DC=corp,DC=com Changed By: j.doe Workstation: CORP-WS-047 IP: 10.0.5.47 # 02:14 -- j.doe has no administrative duties -- account is compromised # svc_backup is a service account, not a human -- ideal for stealth persistence # Escalate immediately regardless of any other context
Correlate the 4728 event with the logon session and process creation timeline to understand exactly how the change was made and confirm the account was not legitimately used.
02:10:12 Event 4624 -- j.doe logs into CORP-WS-047 (Type 10 -- Remote Interactive) 02:11:44 Event 4688 -- j.doe opens PowerShell (elevated, running as j.doe) 02:12:01 PowerShell: Add-ADGroupMember "Domain Admins" -Members svc_backup 02:14:33 Event 4728 -- svc_backup added to Domain Admins # j.doe session used at 2am via remote access -- account hijacked or credentials stolen # PowerShell command executed with j.doe's AD rights -- j.doe has DA already? # Check j.doe's group memberships -- how did they have rights to modify DA?
Once escalated, immediately check what the attacker did with Domain Admin access. The post-escalation window is measured in seconds.
02:14:33 svc_backup added to Domain Admins (Event 4728) 02:15:01 svc_backup authenticates to DC01 via network logon (Event 4672) 02:15:22 impacket-secretsdump / similar executed on DC01 02:15:45 NTDS.dit accessed -- all domain NTLM hashes extracted # 72 seconds from escalation to full domain credential dump # Every domain account password must now be treated as compromised # Golden Ticket may have been created -- KRBTGT must be reset twice
Immediate Remove svc_backup from Domain Admins Disable j.doe account (compromised credential vector) Isolate CORP-WS-047 from network (source of escalation) Short-term (within hours) Reset ALL domain account passwords (credential dump = all hashes exposed) Rotate KRBTGT account password twice with 10-hour delay between resets Force re-authentication across all systems and services Long-term SIEM real-time alert on Event 4728 for ALL privileged groups Implement Privileged Access Workstations (PAW) -- DAs never log into workstations Enable Just-In-Time admin access (JIT) -- no standing DA memberships
What You Need to Know
Active Directory Tiering Model and Why It Matters
The Active Directory tiering model is the foundational architecture that separates credential blast radius when a single account is compromised. Without tier separation, a single compromised workstation-level user account can be leveraged into Domain Admin — because DA credentials are cached everywhere. With proper tiering enforced, the blast radius of any single compromise is contained to that tier.
Assets: Domain controllers, AD replication partners, PKI servers, privileged identity management systems.
Accounts: Domain Admin, Enterprise Admin, Schema Admin, KRBTGT. These accounts must NEVER authenticate to Tier 1 or Tier 2 assets.
Workstations: Dedicated Privileged Access Workstations (PAWs) only — locked-down, no internet, no email, hardware-enforced separation. DA work happens only on PAWs.
Tier 1 assets: Member servers, application servers, file servers. Administered by Tier 1 admin accounts that have no rights over Tier 0 assets.
Tier 2 assets: User workstations and devices. Administered by helpdesk and desktop support accounts with local admin only — no rights over servers or DCs.
Why it works: A compromised workstation can only yield Tier 2 account credentials. Tier 2 accounts have no path to Tier 0. The blast radius is bounded at the tier boundary.
Privilege Event ID Reference Table
| Event ID | What It Records | Detection Signal | Priority |
|---|---|---|---|
| 4728 | Member added to global security group | Group = Domain Admins / Enterprise Admins / Schema Admins at any hour → Critical | CRITICAL |
| 4732 | Member added to local security group | Group = local Administrators, Remote Desktop Users on sensitive servers | HIGH |
| 4672 | Special privileges assigned at logon | DA logon outside business hours or from unexpected workstation | HIGH |
| 4720 | New user account created | New account outside change management window; account in privileged OUs | HIGH |
| 4738 | User account modified | Password change on service accounts; UserAccountControl flag changes; account enabled after disable | MEDIUM |
| 4729 | Member removed from group | Removal from privileged groups — attacker covering tracks or legitimate de-provisioning | MEDIUM |
| 4625 | Failed logon (repeated) | High volume against admin accounts — password spray or brute force targeting DA accounts | MEDIUM |
KRBTGT Reset — Why It Must Be Done Twice
The KRBTGT account is the Kerberos Ticket Granting Ticket account — its password is the secret used to sign all Kerberos tickets in the domain. When an attacker has Domain Admin, they can extract the KRBTGT password hash and use it to create forged Kerberos tickets (Golden Tickets) that grant them any access in the domain for up to 10 years, with no need for any live account or password.
A Golden Ticket is entirely offline — it does not require an active user account, it survives account deletions and password resets, and it cannot be detected by examining user accounts. The only way to invalidate Golden Tickets is to change the KRBTGT password, which rotates the signing key. But there is a critical catch: Active Directory keeps the previous KRBTGT password as a fallback for tickets still in circulation. A single reset invalidates tickets signed with the old key but the backup key (one rotation old) remains valid. The KRBTGT password must be reset twice, with at least 10 hours between resets, to ensure all in-flight tickets expire and the backup key also rotates.
Golden Tickets cannot be detected by examining user accounts — the attacker's account may have been deleted long ago. The forensic indicators are in Kerberos ticket properties.
# Golden Ticket indicators in SIEM / Windows Security log: Event 4769 -- Kerberos Service Ticket Request Account: [email protected] Ticket Encryption: 0x17 (RC4 -- legacy, unusual if AES enforced in environment) Ticket lifetime: 10 years (normal max is 10 hours) Service: krbtgt/corp.com (requests for krbtgt = ticket-granting-ticket) # A ticket lifetime exceeding domain policy is a Golden Ticket indicator # j.attacker account may not exist in AD -- the ticket was forged # KRBTGT double-reset procedure: # 1. Reset KRBTGT password (invalidates all tickets signed with old key) # 2. Wait minimum 10 hours (max Kerberos ticket lifetime) # 3. Reset KRBTGT password again (invalidates tickets signed with backup key) # After step 3, ALL forged tickets in circulation are invalidated
Domain Compromise — Full Investigation Chain
02:14 — Alert: SIEM fires Critical on Event 4728 — svc_backup added to Domain Admins. Changed by j.doe from CORP-WS-047. On-call analyst paged immediately.
02:16 — Tracing back j.doe: j.doe is an accounts payable clerk. No admin duties. Group memberships: standard user only — no Domain Admin rights. How did j.doe modify Domain Admins? Event 4624 shows j.doe logged into CORP-WS-047 at 02:10 via Remote Desktop (Logon Type 10) from IP 185.220.101.45 — an external IP. j.doe is asleep at home. Their credentials were stolen — phishing confirmed via IR01 ticket from two days prior.
02:18 — How did j.doe have DA rights? Checking Event 4672 history on CORP-WS-047: Domain Admin account corp\sysadmin authenticated to CORP-WS-047 last Tuesday to help j.doe with a printer driver issue. NTLM hash cached on the workstation. The attacker used Pass-the-Hash with the cached DA credential to execute the Add-ADGroupMember command in the context of corp\sysadmin — not j.doe.
02:19 — Post-escalation damage: svc_backup (now Domain Admin) authenticated to DC01 at 02:15:01 (Event 4672). Syslog on DC01 shows NTDS.dit accessed via VSS shadow copy at 02:15:22. All NTLM hashes extracted in 23 seconds. svc_backup removed itself from Domain Admins at 02:16:01 — attacker attempted to cover tracks.
Response — Immediate: svc_backup disabled. j.doe account disabled. CORP-WS-047 network quarantine. corp\sysadmin password forced reset. All active sessions revoked.
Response — Short-term: All 847 domain account passwords reset (credential dump = all hashes compromised). KRBTGT reset #1 at 03:00. KRBTGT reset #2 scheduled for 13:00 (10-hour gap). All service account passwords rotated. Kerberos ticket lifetime checked — max 10 hours confirmed in policy, so 13:00 reset covers all in-flight tickets.
Root cause: DA credentials cached on a standard user workstation — direct violation of AD tiering principles. Post-incident action: enforce credential guard on all workstations (prevents NTLM hash caching), begin PAW rollout for all Tier 0 admin work.
Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — IR05 Privilege Escalation→← Return to all labs