Privilege escalation detection on Windows: techniques and telemetry

Originally published on the ClearPath Security site: https://clearpathsecurity.co.uk/privilege-escalation-detection-on-windows-techniques-and-telemetry/

Privilege escalation on Windows is one of those problems that is easy to underestimate until it appears in your telemetry. In practical terms, it means a user, process, or service gains more rights than it should have. That might be a standard user becoming local administrator, a low-privilege process inheriting a higher token, or an attacker abusing a trusted mechanism to run code with elevated rights.

For defenders, the goal is not to prove every possible escalation path in the abstract. The goal is to collect enough reliable telemetry to spot suspicious elevation quickly, separate it from normal administration, and preserve enough evidence to understand what happened. That is especially important in smaller UK environments where the same team often manages endpoints, identity, and response. If you are already working on endpoint visibility, it is worth reading our article on tuning Sysmon configuration for high-fidelity process telemetry alongside this one.

Key takeaways

• Privilege escalation on Windows is best detected through correlated process, logon, service, task, and account telemetry rather than a single event.
• Sysmon, Security Event Logs, and PowerShell logging provide the most useful evidence when they are configured and retained properly.
• Strong detections focus on behaviour such as suspicious process ancestry, service abuse, scheduled task changes, and LSASS access precursors.
• Tuning is essential because legitimate administration, deployment tools, and remote support software can otherwise create excessive false positives.

What privilege escalation looks like on Windows

On Windows, privilege escalation usually shows up as a change in execution context rather than a single obvious event. A process may start as a standard user and then spawn a child process with an elevated token. A service may be modified so that it launches attacker-controlled code. A scheduled task may be created or altered to run as SYSTEM. In some cases, the activity is legitimate but unusual, such as an administrator using a remote management tool from an endpoint that rarely performs administration.

It helps to distinguish local privilege escalation from lateral movement. Local escalation is about gaining more rights on the same host. Lateral movement is about using those rights to move to another system. In real incidents, the two often happen together. A compromise starts with a low-privilege foothold, escalates locally, and then uses the new rights to access credentials, services, or remote administration channels.

From a detection perspective, the useful artefacts are the ones that reflect elevated execution. That includes process creation with an unexpected parent-child relationship, service control changes, scheduled task creation, token-related anomalies, and logon events that do not fit the normal pattern for the account or device. If you want a broader view of how these signals fit into operations, our article on detection engineering fundamentals for SOC teams is a useful companion.

Telemetry sources that matter most

The core telemetry sources for privilege escalation detection are the Windows Security Event Log, Sysmon, and PowerShell logging. Each covers a different layer of the activity chain. The Security log gives you authentication, account, and privilege-related events. Sysmon gives you richer process, network, registry, and image load visibility. PowerShell logging helps when elevation is followed by script-based administration or post-exploitation activity.

Process creation is usually the first place to look. Security Event ID 4688 can capture process start events if command line auditing is enabled. Sysmon Event ID 1 provides more detail and is generally more useful for detection engineering because it includes parent process, command line, hashes, and image path. For service activity, Security Event IDs 4697 and 7045 are useful, although 7045 is from the System log rather than the Security log. For scheduled tasks, Event IDs 4698, 4699, 4702, and the Task Scheduler operational log can show creation and modification. For registry-based persistence or configuration changes, Sysmon Event ID 13 and 12 can add context.

PowerShell logging is important because many elevation workflows end in script execution. Script Block Logging captures the content of executed PowerShell blocks, while Module Logging and Transcription can add more context depending on your environment. If you already use PowerShell heavily for administration, you need to tune for signal rather than volume. Our article on baselining and detecting anomalous PowerShell with script block logging covers that in more depth.

Supporting signals matter too. Registry changes, WMI activity, service control manager events, and remote management traces can all help confirm whether a suspicious process chain is part of a real escalation path or just routine administration. The more you can correlate across sources, the less you need to rely on any single event ID.

High-value detection techniques for defenders

A good detection strategy starts with process lineage. Suspicious parent-child chains are often the clearest indicator that something has changed in execution context. Examples include office applications spawning scripting engines, scripting engines spawning command shells, or unusual administrative tools launching from user-writable locations. The point is not that any one chain is malicious by itself. The point is that the chain is inconsistent with the host’s normal behaviour and the user’s role.

Process ancestry becomes more useful when you add context such as integrity level, command line, signer, and path. A signed Microsoft binary is not automatically safe, but a trusted binary launched from a temporary directory with unusual arguments deserves attention. In a SIEM, this often becomes a rule that looks for a combination of parent image, child image, command line pattern, and location rather than a single string match.

UAC bypass patterns are another useful area. User Account Control is meant to reduce the risk of silent elevation, but attackers often look for ways around it. Defenders should monitor for elevated shells or administrative utilities appearing without the normal user interaction pattern, especially when the parent process is unusual or the command line references known auto-elevating components. The detection should be behavioural rather than signature-only, because the exact technique changes over time.

Service abuse is a high-value signal because services often run with elevated privileges. Watch for service creation, modification, binary path changes, and suspicious service names that resemble legitimate Windows components. A service installed from a user profile, temp directory, or network share is especially worth investigating. Scheduled task abuse is similar. Tasks that run as SYSTEM, are created outside normal deployment windows, or point to unusual executables can indicate escalation or persistence. If you want a deeper operational view of task-related hunting, see our article on scheduled task persistence using KQL in Sentinel.

DLL hijacking indicators are harder to detect directly, but there are still useful clues. Unexpected image loads from writable directories, unsigned DLLs loaded by privileged processes, and abnormal application paths can all be useful supporting evidence. Sysmon Event ID 7 can help here, although you will usually need to combine it with process creation and file creation telemetry to get a reliable picture.

Telemetry for credential and token abuse

Privilege escalation is often accompanied by credential or token abuse. On Windows, access tokens define what a process can do. If an attacker can manipulate a token, impersonate a more privileged context, or steal credentials from memory, they may gain access without needing a classic exploit. That is why token-related telemetry and credential-access telemetry belong in the same detection strategy.

There is no single event that says “token theft happened”. Instead, defenders look for behaviour that often precedes or follows it. That includes suspicious use of impersonation-capable APIs, unusual logon types, elevated processes launched shortly after a low-privilege session, and access to sensitive processes such as LSASS. Sysmon Event ID 10, which records process access, is particularly useful when tuned to watch for access to LSASS and other high-value processes. It will not prove theft on its own, but it can provide a strong precursor signal.

Correlating logon events with privilege changes is equally important. Security Event IDs 4624, 4672, 4728, 4732, 4756, and related group membership events can show when an account receives privileged access or uses it. If a user suddenly appears in a local administrators group, or if a logon is followed immediately by privileged process creation from an unusual host, that is worth investigating. The same applies when an account that normally logs on interactively begins using remote logon types or service-style logons.

In practice, the strongest detections combine identity and endpoint telemetry. A local admin group change on its own may be legitimate. A local admin group change followed by a new service install, a suspicious PowerShell session, and a process tree that ends in a credential-dumping precursor is much more meaningful. That is why endpoint-only monitoring is rarely enough. If you are building the broader control set, our article on achieving centralised visibility across endpoints, identity, and network is relevant here.

Windows logging configuration for better fidelity

Telemetry quality is usually the deciding factor between a useful detection and a noisy one. Sysmon is often the most valuable source for privilege escalation hunting, but only if it is configured with care. At minimum, you want process creation, network connections, image loads, process access, file creation, registry events, and named pipe visibility where relevant. The exact configuration depends on your environment, but the principle is consistent: collect enough to reconstruct the chain without drowning the SIEM in low-value events.

For Sysmon, Event IDs 1, 3, 7, 10, 11, 12, 13, 22, and 23 are commonly useful in escalation investigations. Event ID 1 covers process creation. Event ID 10 helps with process access. Event ID 11 captures file creation. Event IDs 12 and 13 cover registry changes. Event ID 22 provides DNS queries, which can help when a suspicious elevated process reaches out for payloads or command-and-control. Event ID 23 can help with file deletion in some configurations. You do not need every event everywhere, but you do need enough coverage to support the hypotheses you care about.

Security auditing should also be enabled for the events that matter most. Process creation auditing with command line capture is essential. Account management auditing helps with group membership changes. Logon auditing helps with correlating elevation to user activity. Service installation and scheduled task auditing should be enabled where possible. If you are not already capturing these events centrally, the detection problem becomes much harder than it needs to be.

PowerShell script block logging and command line capture should be enabled on systems where PowerShell is used for administration. Without them, you lose a lot of context around post-elevation activity. That said, logging alone is not enough. You need retention, forwarding, and a parsing strategy that makes the data searchable in your SIEM. For teams using Microsoft Sentinel, our article on building Microsoft Sentinel analytics rules from MITRE ATT&CK techniques is a useful reference point for rule design.

Detection engineering approach in SIEM and EDR

A practical way to structure detections is to map them to MITRE ATT&CK techniques and then express them in your SIEM or EDR platform. For privilege escalation, the relevant techniques often sit across execution, persistence, privilege escalation, and credential access. That framing helps you avoid building isolated rules that miss the broader sequence.

Sigma is a useful starting point when you want portable logic. A Sigma rule can express the suspicious process chain, service creation pattern, or registry change in a vendor-neutral way before you convert it into KQL, Splunk SPL, or another query language. For example, a rule might look for a parent process such as a document viewer or script host spawning an administrative utility from a user-writable path. Another might look for service creation where the binary path points to temp, downloads, or profile directories. The important part is that the rule captures the behaviour, not just a known bad filename.

In KQL, you can enrich detections by joining process creation with account, device, and sign-in data. A simple pattern is to filter on suspicious process names, then join to recent logon events and group membership changes for the same account or host. You can also use time windows to correlate a low-privilege logon followed by privilege-related events within a short period. That reduces noise and makes the alert more actionable.

False positives are inevitable, especially in environments with software deployment tools, remote support tools, and endpoint management agents. The answer is not to suppress everything. The answer is to add context. Check whether the process is signed, whether the parent is a known management agent, whether the host is a jump box, and whether the activity occurred during a normal maintenance window. Our article on measuring detection quality and false positives for technical teams is useful if you want a more disciplined tuning approach.

How to tune detections for real environments

The first tuning step is separating legitimate administration from suspicious elevation. In many SMEs, the same handful of tools are used for patching, remote support, and software deployment. Those tools often run with elevated rights and can look noisy if you only inspect process names. Build allowlists around signed binaries, known management servers, and approved admin workstations, but keep the allowlists narrow. Overly broad exclusions are one of the fastest ways to lose detection value.

Next, baseline normal privilege use. Which accounts regularly use local admin rights? Which endpoints are used for administration? Which services are normally installed by your deployment tooling? Which scheduled tasks are created during patch windows? Baselines do not eliminate risk, but they make anomalies easier to spot. A local admin action from a finance laptop at 11:30 on a Tuesday may be normal for one organisation and highly unusual for another.

It also helps to separate device roles. Domain controllers, jump hosts, developer workstations, and standard user laptops should not share the same detection thresholds. A service creation event on a jump host may be expected. The same event on a receptionist’s laptop is more concerning. This is where asset context and identity context become essential to the rule logic.

Finally, review your exclusions regularly. A temporary exception for a deployment project should not become permanent by accident. If you are already using a detection-as-code workflow, version control and peer review make this much easier to manage. For a practical approach to that discipline, see building a detection-as-code pipeline with Sigma and CI/CD.

Response workflow when a privilege escalation alert fires

When a privilege escalation alert fires, the first question is whether the activity is expected. Check the user, host, time, parent process, and command line. Then ask whether the account normally performs administration, whether the device is a known admin endpoint, and whether there is a change record or maintenance window that explains the activity. If the answer is unclear, treat it as suspicious until you can confirm otherwise.

Preserve evidence early. Export the relevant event logs, Sysmon records, and EDR telemetry. Capture the process tree, command lines, hashes, and network connections if your tooling supports it. If the alert involves service or scheduled task changes, preserve the task definition or service configuration. If it involves a suspicious logon, preserve the source IP, logon type, and related account events. The aim is to keep enough context to reconstruct the sequence later.

Containment should be proportionate. In some cases, disabling the account and isolating the host is appropriate. In others, especially where the activity may be a false positive, a softer containment step such as revoking sessions, forcing a password reset, or collecting more telemetry may be enough. Avoid overreacting before you understand whether the activity is a genuine compromise or a legitimate admin action that simply looks unusual.

If you need a structured way to handle that decision-making, our article on incident triage and escalation workflows in SOC operations for UK SMEs aligns well with this stage of the process.

Practical coverage gaps to watch for

The biggest blind spot is missing endpoint telemetry. If Sysmon is not deployed consistently, or if process creation auditing is disabled, you will struggle to distinguish benign elevation from malicious activity. Another common gap is poor log retention. Privilege escalation investigations often need a short look-back window, but if logs roll over too quickly you lose the evidence before anyone reviews the alert.

Log ingestion delay is another issue. If endpoint events arrive late in the SIEM, correlation rules may miss the sequence or alert too late to be useful. This matters when you are joining process creation, logon, and group membership changes across a narrow time window. If you are using a cloud SIEM, measure ingestion latency and design your correlation windows accordingly.

Finally, do not rely on endpoint telemetry alone. Identity and endpoint correlation improves confidence significantly. A suspicious process chain is more meaningful when it lines up with a recent privileged logon, a group membership change, or a remote management session. That is the difference between a noisy endpoint alert and a defensible detection.

Privilege escalation detection on Windows is not about chasing every obscure technique. It is about building enough visibility to recognise abnormal elevation, then tuning that visibility so it works in your environment. For most UK SMEs, that means a combination of Security Event Logs, Sysmon, PowerShell logging, and a SIEM rule set that understands process lineage, account context, and normal administrative behaviour.

If you want help reviewing your Windows logging, detection coverage, or SIEM use cases, we can support that as part of a practical, risk-based security improvement programme. Speak to a consultant.

Frequently asked questions

Which Windows logs are most useful for detecting privilege escalation?

The most useful sources are the Windows Security Event Log, Sysmon, and PowerShell logging. In practice, process creation, logon, account management, service creation, scheduled task changes, and process access events provide the strongest signals when they are correlated together.

How do you reduce false positives in privilege escalation detections?

Use context rather than simple filename matching. Baseline normal admin activity, restrict allowlists to known management tools and hosts, enrich alerts with account and device context, and tune rules separately for different endpoint roles such as user laptops, jump hosts, and servers.