Privilege Escalation Investigation

What Privilege Escalation Is and the Investigation Framework

• Privilege escalation is the process by which an attacker gains higher-level permissions than they were initially granted — typically elevating from a standard domain user to local administrator, then to Domain Admin (map AD paths with BloodHound).
• MITRE ATT&CK maps this to T1068 (Exploitation for Privilege Escalation) and related techniques T1134 (Access Token Manipulation), T1078 (Valid Accounts), and T1548 (Abuse Elevation Control Mechanism).
• Privilege escalation is the inflection point in most intrusions: before escalation, the attacker is contained to a single user account on a single workstation. After escalation, they own the domain.

Escalation Path 1: Local Admin via Service Exploitation

How it works: The attacker finds a Windows service running as SYSTEM (or a higher-privileged account) with a writable binary path, service binary that is not in a protected directory, or service permissions that allow the attacker to modify the service configuration.

Detection — Sysmon Event ID 1 combined with Service Events:

SPL query — detect service binary modification (Event 4697 — Service Installed):

index=windows sourcetype=WinEventLog:Security EventCode=4697
| search ServiceFileName="*Temp*" OR ServiceFileName="*AppData*" OR ServiceFileName="*Users\\*" 
| eval alert = "HIGH — Service installed from user-writable path — potential service abuse for escalation"
| table _time, Computer, SubjectUserName, ServiceName, ServiceFileName, alert

SPL query — detect service configuration changes (Event 4698 — Scheduled Task Created):

index=windows sourcetype=WinEventLog:Security EventCode=4698
| search TaskContent="*command*" OR TaskContent="*cmd*" OR TaskContent="*powershell*"
| eval alert = "MEDIUM — Scheduled task created with shell command — possible persistence or escalation"
| table _time, Computer, SubjectUserName, TaskName, TaskContent, alert

Event IDs to monitor for service-based escalation:

Escalation Path 2: Token Theft and Manipulation

How it works: The attacker steals an access token from a higher-privileged process (e.g., an admin’s running process) and uses it to execute commands in that security context. Tools: Incognito, Seatbelt, Meterpreter getsystem.

Detection — Sysmon Event ID 8 (CreateRemoteThread) — use Splunk for correlation:

SPL query — detect remote thread creation in privileged processes:

index=windows sourcetype=WinEventLog:Sysmon EventCode=8
| search TargetImage IN ("*lsass.exe", "*winlogon.exe", "*services.exe", "*svchost.exe*") SourceImage!="*svchost.exe"
| stats count, values(SourceImage) as SourceProcesses, values(StartFunction) as Functions by TargetImage, Computer
| eval alert = "CRITICAL — remote thread in privileged process " . TargetImage . " — token theft or privilege escalation"
| table _time, Computer, SourceProcesses, TargetImage, Functions, alert

Key Event IDs for token-based escalation:

Escalation Path 3: Privileged Group Assignment

How it works: The attacker is added to a privileged group — Domain Admins, Enterprise Admins, Backup Operators, Account Operators — or a local admin group on a server.

Detection — Event ID 4728 (Member Added to Security-Enabled Global Group):

SPL query — detect domain group membership changes:

index=windows sourcetype=WinEventLog:Security
| search EventCode IN (4728, 4732, 4756, 4746) TargetUserName IN ("Domain Admins", "Enterprise Admins", "Administrators", "Schema Admins", "Backup Operators")
| eval alert = "CRITICAL — member added to privileged group " . TargetUserName . " by " . SubjectUserName
| table _time, Computer, SubjectUserName, TargetUserName, SamAccountName, action=case(EventCode=4728, "Added to global group", EventCode=4732, "Added to local group", EventCode=4756, "Added to universal group")

All relevant group modification Event IDs:

KQL query (Sentinel/Azure) — detect privileged group changes:

SecurityEvent
| where EventID in (4728, 4732, 4756)
| where TargetUserName has_any ("Domain Admins", "Administrators", "Enterprise Admins")
| project TimeGenerated, Computer, Account, TargetUserName, MemberName
| sort by TimeGenerated desc

Escalation Path 4: UAC Bypass

How it works: Windows UAC (User Account Control) prevents standard users from making admin-level changes — but many techniques bypass it by tricking an auto-elevating process (like an installer) into executing the attacker’s code.

Common UAC bypass techniques and detection:

SPL query — detect Fodhelper UAC bypass registry modification:

index=windows sourcetype=WinEventLog:Sysmon EventCode=13 EventType="SetValue"
| search TargetObject="*ms-settings\\shell\\open\\command*"
| eval alert = "CRITICAL — UAC bypass via Fodhelper detected — registry key set for auto-elevation"
| table _time, Computer, Image, ProcessID, TargetObject, Details, alert

Escalation Path 5: GPO Abuse

How it works: An attacker who compromises an account with Group Policy management privileges (e.g., a delegated GPO admin account) adds a malicious scheduled task, startup script, or registry policy to a GPO that applies to all domain computers.

Detection — Event ID 5136 (Directory Service Object Modified):

SPL query — detect GPO modification events:

index=windows sourcetype=WinEventLog:Security EventCode=5136
| search ObjectDN="*CN=Policies,CN=System*" AttributeValue="*cmd.exe*" OR AttributeValue="*powershell.exe*" OR AttributeValue="*vbs*"
| eval alert = "CRITICAL — GPO modified with script content — potential lateral movement"
| table _time, Computer, SubjectUserName, ObjectDN, AttributeValue, alert

Other GPO abuse Event IDs:

Privilege Escalation Triage — Investigation Workflow

Step 1: Identify the Escalation Vector

When investigating a confirmed privilege escalation, these Event IDs tell you which path was used:

Step 2: Determine Scope

Step 3: Immediate Containment

1. Remove the escalated account from the privileged group immediately
2. Kill any processes running under the escalated account
3. Isolate the source system from which escalation was performed
4. Reset the escalated account’s password and any credentials it had access to
5. Check for persistence — if the escalation was via scheduled task or GPO, remove that mechanism too

Step 4: Find the Root Cause

The escalation event itself is a symptom. The root cause is how the attacker got the initial foothold:

• Was it a compromised credential that already had admin rights? (Missed in identity monitoring.)
• Was it a service exploitation from a standard user? (Patching gap.)
• Was it a privilege escalation from an unpatched CVE? (Vulnerability management gap.)

Related

• Cloud Threats — Credential Theft, IMDS Abuse, Hijacking, Privilege Escalation — detection and response for T1525, T1552, T1613 techniques
• Business Email Compromise Response — detection and response for T1566, T1114, T1098, T1586 techniques
• Cloud Incident Response — detection and response for T1525, T1526, T1078, T1530 techniques
• Active Directory Basics — covers the active directory basics concepts
• EDR Basics — detection and response for T1059, T1003, T1055, T1204, T1562 techniques

Sources

• MITRE ATT&CK T1068
• Microsoft — Monitor Privileged Group Modifications
• BloodHound
• Microsoft — UAC Bypass Detection
• MITRE ATT&CK T1548