How Privilege Escalation Attacks Actually Work — and How to Detect Them

Almost every serious breach involving Active Directory follows the same arc: an attacker gets a foothold with an ordinary, low-value account, and then spends the rest of the intrusion turning that foothold into domain-level control. The initial entry point is rarely the damaging part. What actually decides whether an incident becomes a headline is what happens next — whether the attacker can climb from "compromised standard user" to "compromised domain admin" before anyone notices. That climb is privilege escalation, and understanding its mechanics is the difference between logs that just sit there and logs that catch an attacker mid-climb.

This guide walks through how a privilege escalation attack actually unfolds step by step, the specific AD misconfigurations that make the climb possible, a real ransomware incident that shows the whole chain end to end, and the practical detection options available to you — from the Windows Event IDs you can start watching today to the behavioral analytics that catch what those event IDs alone cannot.

Privileged accounts: why attackers want them

A privileged account is any identity that carries rights beyond what a standard user has — domain administrator accounts that control the entire directory, local administrator accounts scoped to a single machine, service accounts that run unattended processes, and emergency "break glass" accounts kept for contingencies. In a typical enterprise, these accounts are relatively few in number but disproportionately powerful: a single compromised domain admin credential can touch every workstation, server, and mailbox in the environment.

That combination — high value, comparatively low volume — makes privileged accounts the single most targeted asset class in AD. Microsoft's own vulnerability disclosure data backs this up: in its 2023 Vulnerabilities Report, elevation of privilege was the leading vulnerability category for the third year running, accounting for more than half of all disclosed Microsoft vulnerabilities that year. Separately, industry research from the Identity Defined Security Alliance found that poorly managed identities were the second most common root cause of breaches reported by surveyed organizations. Put simply: if an attacker can find one weak link in how you manage privileged identities, the payoff is usually worth the effort of finding it.

Anatomy of a privilege escalation attack

Privilege escalation attacks are rarely a single move — they're a chain, and each link depends on the one before it. The chain generally runs through four stages, and understanding each one tells you where to place detection.

1. Access exploitation

Every attack needs a way in. Attackers get their initial foothold through password guessing and brute force, phishing, credential stuffing against reused passwords, keylogging, man-in-the-middle interception, session hijacking, exploitation of unpatched software or zero-days, and simple misconfigured access controls left open to the internet. None of these require privileged access — they just require one weak point, and in a large organization there's almost always one somewhere.

2. Privilege escalation

Once inside with a low-privilege foothold, the attacker looks for a way to become someone more powerful. This is where AD-specific weaknesses come into play — insecure service permissions, unquoted service paths, weak registry permissions, overprivileged user accounts, and stale local admin passwords are all common escalation paths. The goal at this stage is rarely to stop at "slightly more access" — attackers push toward domain administrator, because that's the level of control that makes everything downstream possible.

3. Lateral movement

With elevated privileges in hand, the attacker starts moving sideways across the network rather than just up. Pass-the-hash and pass-the-ticket techniques let them authenticate to other systems without ever knowing the actual password, reusing captured hashes or Kerberos tickets instead. Commercial red-team frameworks like Cobalt Strike are frequently repurposed here, since they're built to mimic legitimate network activity while quietly pivoting from host to host.

4. Data exfiltration

The final stage is where the business impact lands — ransomware deployment, theft of sensitive records, or both. Attackers commonly plant backdoors during this stage as well, so that even if the ransomware is remediated and passwords are reset, they retain a way back in later. Many intrusions cycle back through reconnaissance and repeat this loop across additional systems before the payload finally detonates.

The initial compromise gets an attacker through the door. Privilege escalation is what gets them the keys to every room in the building.

The Active Directory vulnerabilities attackers exploit

The privilege escalation stage above doesn't happen by magic — it exploits specific, and usually preventable, weaknesses in how AD is configured and maintained:

• Unpatched software. Known vulnerabilities in the OS, in AD-integrated applications, and in supporting components give attackers a documented, often automated path to elevated code execution.
• Weak password policies. Short minimum lengths, no complexity requirements, and infrequent rotation make brute-force and credential-guessing attacks against AD accounts far more likely to succeed.
• Misconfigured permissions. Incorrectly delegated rights on organizational units, groups, or individual objects can let a low-privilege user modify something they were never meant to touch — including, in the worst cases, group membership itself.
• Overprivileged accounts. Accounts that accumulate access over time — through role changes, project work, or simple convenience — end up holding far more than they need, so a single compromised credential opens far more doors than it should.
• Insecure service accounts. Service accounts frequently run with excessive rights, use passwords that never expire, and aren't monitored the way human accounts are, making them an efficient target for attackers seeking Kerberoasting-style abuse.
• Group Policy misconfigurations. Incorrectly scoped GPOs can push insecure settings, weaken local security controls, or grant rights across far more of the environment than was intended.

Every one of these is a configuration problem, not a software flaw — which is exactly why they're both preventable and, in practice, so common. Hardening AD against privilege escalation is largely a matter of continuously auditing for these six patterns rather than fixing them once and assuming they'll stay fixed.

Case study: the UHS Ryuk ransomware attack

The 2020 ransomware attack against Universal Health Services (UHS), a large U.S. hospital and healthcare network, is a textbook illustration of the full chain described above, and it's worth walking through because every stage maps directly to a real event.

It started with social engineering: employees were lured into opening a spam email containing a link to what looked like an innocuous shared document. The document carried a PowerShell script that, once executed, dropped the BazarLoader trojan onto the endpoint. BazarLoader installed a backdoor, and through that backdoor the attackers deployed BloodHound — a legitimate AD reconnaissance tool, repurposed here to map out group memberships, trust relationships, and privileged accounts worth targeting. With high-value targets identified, the attackers used Cobalt Strike to pivot laterally between accounts and systems. Along the way, they ran Mimikatz to harvest credentials cached in memory, using the recovered passwords to escalate their own privileges further and reach additional accounts. Once they'd spread widely enough, they detonated Ryuk ransomware across the network, encrypting files on a large scale and locking staff out of clinical and administrative systems.

The financial impact was estimated at roughly $67 million, and the operational disruption to a hospital network carries obvious stakes beyond the balance sheet. What makes the case instructive is how ordinary each individual step was — a phishing email, a script, a legitimate recon tool, a legitimate red-team framework, a credential-dumping utility freely available online. No single stage required a novel exploit. The failure was that nothing in the chain got caught early enough to stop the escalation before it reached ransomware deployment.

Detecting escalation with Windows Event Viewer

Windows Event Viewer is the first line of defense most organizations already have, and a handful of event IDs carry outsized value for spotting privilege escalation in progress:

• 4672 / 4673 / 4674 — special privileges assigned at logon, a privileged service being called, or an operation attempted on a privileged object. Together these flag accounts exercising administrative rights, including rights they shouldn't normally use.
• 4728 / 4732 / 4756 — a user added to a privileged global, local, or universal security group respectively. Unexpected group membership changes are one of the clearest signals of an escalation attempt succeeding.
• 4719 — the system audit policy was changed, which can indicate an attacker weakening logging coverage to move more freely.
• 4648 — a logon using explicit credentials, a strong indicator of techniques like runas being used to move between accounts or systems.
• 4740 — an account was locked out, useful for spotting brute-force attempts against privileged or service accounts.
• 4624 / 4625 — successful and failed logon events, the baseline data for spotting unusual logon patterns, password-guessing attempts, and unauthorized access.
• 1102 — the security audit log was cleared, which is almost never a legitimate administrative action and typically signals an attacker covering their tracks.
• 4698 — a scheduled task was created, a common mechanism for establishing persistence after escalation.
• 4663 — an attempt was made to access an object such as a file or folder, useful for tracking unauthorized access to sensitive resources.
• 4735 — a security-enabled local group was changed, complementing the group-membership events above with modification detail.

Collecting these event IDs is a meaningful starting point, but Event Viewer has real limits. The logs carry little context about intent, they're easy for an attacker with sufficient access to tamper with or clear outright, and correlating dozens of discrete event IDs into a single coherent attack story is a manual, time-consuming process even for an experienced analyst — one that doesn't scale across a large domain with thousands of daily logon events.

Beyond Event Viewer: UBA-based anomaly detection

User behavior analytics (UBA) closes the gap that native logging leaves open by establishing a baseline of what normal looks like for each user and account, then flagging deviations from it. There are three complementary detection approaches worth understanding:

Time-based anomaly detection flags activity that falls outside a user's normal working pattern — a service account authenticating at 3 a.m. when it has only ever run during business hours, for instance, or a privileged logon from an account that has never previously been used outside a specific shift.

Pattern-based anomaly detection looks at sequences of events rather than single actions. Any one step in an attack chain — a logon, a group membership change, a software install — can look unremarkable in isolation. Strung together in an order or combination that deviates from the user's established pattern, the same events become a strong signal.

Count-based anomaly detection watches for volume spikes — a sudden surge in privileged actions, file modifications, or access attempts by a single account well beyond its typical frequency, even if each individual action would pass unnoticed on its own.

This is the layer where a purpose-built auditing platform earns its keep. ManageEngine ADAudit Plus is built specifically to close the gaps native Event Viewer logs leave open: it consolidates the event IDs above into a real-time, correlated audit trail, applies UBA to baseline normal behavior per user and account, and fires alerts the moment time-based, pattern-based, or count-based activity deviates from that baseline — turning what would otherwise be a manual log-correlation exercise into an automated early-warning system for exactly the kind of escalation chain the UHS case study walked through.

Frequently asked questions

What's the single most important event ID to start monitoring if I can only pick a few? Group membership changes — 4728, 4732, and 4756 — are hard to fake and directly indicate an account gaining privileged access. Pair them with 1102 for log tampering and 4648 for lateral movement, and you cover the highest-signal points in the chain with minimal noise.

Can privilege escalation happen without any malware being involved? Yes, and it's increasingly common. Techniques like pass-the-hash, Kerberoasting against weak service account passwords, or simply abusing a misconfigured delegation permission require no malicious binary at all — just legitimate Windows authentication mechanics used the wrong way. This is exactly why behavioral detection matters as much as signature-based antivirus.

How is privilege escalation different from lateral movement? Privilege escalation is about gaining more rights, typically on the system or account the attacker already controls. Lateral movement is about using those rights to reach additional systems. In practice they interleave — an attacker escalates just enough to move laterally, then escalates again on the new system — but they're distinct techniques worth tracking separately in your detection coverage.

Privilege escalation is the hinge point of nearly every serious AD compromise — the stage where a minor foothold either gets contained or turns into domain-wide control. Native Windows logging gives you the raw material to catch it, but only behavioral analytics turns that raw material into something that reliably fires before the damage is done. Building detection coverage for both is one of the highest-leverage investments a security team can make in AD.