What is Privilege Escalation?

Both kinds start from access the attacker already has: a phished laptop, a guessed password, a hijacked web session. Escalation turns that foothold into control, and on a SOC queue it shows up as a change in who can do what, far more often than as malware. (This page is about the attack. Handing an incident up to tier 2 is escalation in the SOC-process sense.)

Vertical vs horizontal privilege escalation

MITRE's weakness catalog draws the same line. CWE-639, the entry that lists IDOR as an alternate term, says the flaw allows horizontal escalation when the key a user controls points at another user's record, and vertical escalation when that key is really a flag that marks someone as an administrator. A broader entry, CWE-269 Improper Privilege Management, covers software that does not "properly assign, modify, track, or check privileges".

How attackers escalate: ATT&CK TA0004

In ATT&CK v20 the Privilege Escalation tactic (TA0004) holds 13 techniques. MITRE's own examples of the goal are SYSTEM or root, a local administrator, an account with admin-like access, and an account that can reach one specific system. The ones a Windows and Entra ID shop meets most:

• Exploitation for Privilege Escalation (T1068): a kernel or driver bug, or a setuid binary like pkexec. NVD records PwnKit's addition to CISA's Known Exploited Vulnerabilities catalog on 27 June 2022.
• Abuse Elevation Control Mechanism (T1548): UAC bypasses on Windows, sudo and setuid abuse on Linux.
• Access Token Manipulation (T1134): stealing or duplicating the token of a more privileged process.
• Valid Accounts (T1078) and Account Manipulation (T1098): signing in with a cracked admin password, or adding an account the attacker controls to a privileged group or role.
• Create or Modify System Process (T1543) and Scheduled Task/Job (T1053): a service or task that runs as SYSTEM.
• Domain or Tenant Policy Modification (T1484): changing Group Policy or tenant settings to grant rights everywhere at once.

MITRE notes that these techniques often overlap with persistence: a new service running as SYSTEM raises privileges and survives a reboot. Kerberoasting (T1558.003) is filed under Credential Access, but in Active Directory it is the classic way up. Any user holding a Kerberos ticket can request service tickets for accounts with an SPN, crack them offline, and log in as that service account with whatever rights it carries.

From technique to event: what the SOC sees

Each step leaves a specific record.

Microsoft's guidance for 4672 is to watch for accounts that are not LOCAL SYSTEM, NETWORK SERVICE, LOCAL SERVICE or an admin expected to hold those privileges. Every admin logon writes one, so the event only means something against a list of who should have it. The CommandLine field in 4688 stays empty until the "Include command line in process creation events" policy is enabled. And 4732 is written once per member added, usually right after a 4735 for the same group that shows no changes.

A simulated case

Simulated example generated by SOCSimulator Research. Users, hosts and times are invented; event IDs, field names and values are Microsoft's.

Time      Host   Event  Detail
09:14:02  DC01   4769   j.ortega requests a ticket for svc_sql      TicketEncryptionType 0x17
09:14:03  DC01   4769   j.ortega requests a ticket for svc_backup   TicketEncryptionType 0x17
09:14:03  DC01   4769   j.ortega requests a ticket for svc_web      TicketEncryptionType 0x17
          ...           no activity for svc_sql for five hours
14:41:19  DC01   4624   svc_sql  logon type 3  from WS-114 (j.ortega's workstation)
14:41:19  DC01   4672   svc_sql  SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege
                        SeTakeOwnershipPrivilege SeDebugPrivilege SeImpersonatePrivilege ...
14:42:50  DC01   4728   Group: Domain Admins  Member: CN=Jorge Ortega,...  Subject: svc_sql

j.ortega, whose job has nothing to do with SQL, requested RC4 tickets for three service accounts in two seconds. That burst is the Kerberoast. The five quiet hours are the cracking, done offline where no log can see it. Then svc_sql, an account that normally only authenticates from the SQL server, logs on to the domain controller from j.ortega's workstation (4624) and gets the sensitive privilege set. Ninety seconds later it adds j.ortega to Domain Admins. Service accounts do not add people to groups, so there is no change ticket to look for. Disable svc_sql, pull j.ortega out of the group, reset the service account's password, isolate WS-114 and hunt for every other logon as svc_sql since 09:14. The Kerberoasting playbook covers the scoping, and the lateral movement playbook covers what usually comes next.

Detecting it with KQL

The first query lists additions to privileged Active Directory and local groups over the last day.

// Members added to privileged AD or local groups in the last 24 hours
let privileged = dynamic(["Administrators", "Domain Admins", "Enterprise Admins",
    "Schema Admins", "Account Operators", "Backup Operators", "Server Operators"]);
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID in (4728, 4732, 4756)
| where TargetUserName in~ (privileged)
| project TimeGenerated, Computer, EventID, Group = TargetUserName,
    AddedMember = MemberName, AddedBy = SubjectUserName, AddedByDomain = SubjectDomainName
| order by TimeGenerated desc

The second finds Entra ID role assignments made directly instead of through a PIM activation. It is adapted from Microsoft's own Sentinel rule for privileged roles assigned outside PIM.

// Entra ID role assignments made outside PIM in the last day
AuditLogs
| where TimeGenerated > ago(1d)
| where Category =~ "RoleManagement"
| where OperationName =~ "Add member to role" and LoggedByService =~ "Core Directory"
| where Identity !in ("MS-PIM", "MS-PIM-Fairfax")
| mv-apply Target = TargetResources on (
    where Target.type =~ "User"
    | extend TargetUser = tostring(Target.userPrincipalName), Props = Target.modifiedProperties)
| mv-apply Prop = Props on (
    where Prop.displayName =~ "Role.DisplayName"
    | extend RoleName = trim('"', tostring(Prop.newValue)))
| extend Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName),
    tostring(InitiatedBy.app.displayName))
| project TimeGenerated, RoleName, TargetUser, Actor, Result

Both follow Microsoft's documented SecurityEvent and AuditLogs schemas and have not been run against a live workspace by SOCSimulator. In a tenant that does not use PIM, every assignment is direct and the second query becomes a plain list of role grants, which is still worth a daily look.

False positive or real?

Most hits are admins doing their job. Before you escalate, answer four questions:

1. Is there a change? A ticket or an approved PIM activation with a justification that matches the role and the time.
2. Who made it? A named admin account from an admin workstation is normal. A service account, a user who was added minutes earlier, or an account that has never touched group management is not.
3. From where? Check the source host of the session that made the change. A domain controller logon from an ordinary workstation is the detail that turned the simulated case above into an incident.
4. Did it stay? An add followed by a removal minutes later can be an admin fixing a mistake, or an attacker covering tracks after using the rights. Look at what the account did in between.

Prevention

• No standing admin rights. Microsoft Entra Privileged Identity Management gives just-in-time, time-bound roles with approval, MFA on activation and a written justification. This is least privilege applied to time as well as scope.
• Patch local privilege escalation bugs listed as exploited first. PwnKit needed nothing more than an ordinary local account.
• Make Kerberoasting pointless. ATT&CK's mitigation is service account passwords of 25 or more characters, or group managed service accounts.
• Turn on command-line auditing so 4688 records what ran, not only that something ran.
• Alert on privileged group and role changes with the two queries above, and route them to the on-call analyst.