---
title: Suspicious SeIncreaseBasePriorityPrivilege Use
description: Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process...
url: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/windows/privilege_escalation_thread_cpu_priority_hijack
products:
  - Elastic Security
---

# Suspicious SeIncreaseBasePriorityPrivilege Use
Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to
hijack execution flow of a process via threats priority manipulation.
**Rule type**: query
**Rule indices**:
- logs-system.security*
- logs-windows.forwarded*
- winlogbeat-*

**Rule Severity**: high
**Risk Score**: 73
**Runs every**: 
**Searches indices from**: `now-9m`
**Maximum alerts per execution**: 100
**References**:
- [[https://github.com/Octoberfest7/ThreadCPUAssignment_POC/tree/main](https://github.com/Octoberfest7/ThreadCPUAssignment_POC/tree/main)](https://github.com/Octoberfest7/ThreadCPUAssignment_POC/tree/main)
- [[https://x.com/sixtyvividtails/status/1970721197617717483](https://x.com/sixtyvividtails/status/1970721197617717483)](https://x.com/sixtyvividtails/status/1970721197617717483)
- [[https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4674](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4674)](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4674)

**Tags**:
- Domain: Endpoint
- OS: Windows
- Use Case: Threat Detection
- Tactic: Privilege Escalation
- Data Source: Windows Security Event Logs
- Resources: Investigation Guide
- Noise: Low
- Performance: Normal
- Rule Type: Custom Query (KQL)
- Platform: Windows

**Version**: 4
**Rule authors**:
- Elastic

**Rule license**: Elastic License v2

## Setup

Audit Sensitive Privilege Use must be enabled to generate the events used by this rule.
Setup instructions: [https://ela.st/audit-sensitive-privilege-use](https://ela.st/audit-sensitive-privilege-use)

## Investigation guide


## Triage and analysis


### Investigating Suspicious SeIncreaseBasePriorityPrivilege Use


#### Possible investigation steps

- What priority-change path did 4674 preserve?
  - Why: this privilege manipulates process or thread priority; the target object matters as much as the requester.
  - Focus: Security 4674 on `host.id`: `winlog.event_data.PrivilegeList`, `winlog.event_data.AccessMask`, `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, and `winlog.event_data.ObjectName`.
  - Hint: sparse or numeric-only `winlog.event_data.ObjectName` is the main visibility gap; keep the target unresolved and use same-session Security records, not assumed self-tuning.
  - Implication: escalate when the object is a "Process" or "Thread" tied to security tooling, LSASS, or another user's workload; lower suspicion only when requester, object, and `host.name` fit bounded tuning or testing.
- Is the requesting image path expected for priority control on this host?
  - Focus: `winlog.event_data.ProcessName`, `winlog.event_data.ProcessId`, `winlog.event_data.SubjectUserSid`, `host.name`, and `@timestamp`.
  - Hint: `winlog.event_data.ProcessId` is hexadecimal; use it only inside a tight host/time window; PID reuse can mislead.
  - Implication: escalate when the path is user-writable, temporary, renamed, or unrelated to local tuning; treat a recurring full path and SID as identity support, not closure, until object and session evidence align.
- Which subject and local session requested this privilege use?
  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, and `winlog.event_data.SubjectLogonId`.
  - Implication: escalate when a normal user, rare admin, machine account, or service account lacks a clear scheduling-priority role; matching SID, domain, and session support benignity only with matching requester and object evidence.
- Does the 4624 session origin fit a priority-tuning operator?
  - Focus: on the same `host.id`, match alert `winlog.event_data.SubjectLogonId` to 4624 `winlog.event_data.TargetLogonId`, then read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`.
  - Hint: query `event.code` 4624 with alert `host.id` and `winlog.event_data.TargetLogonId`; search backward from `@timestamp` because the session can predate 4674. $investigate_0 Missing 4624 or empty `source.ip` is unresolved, not benign.
  - Implication: escalate when source, logon type, or authentication method is rare for `host.name` or subject SID; matching origin supports authorized tuning only after requester path and target object fit.
- Do surrounding Security records show repeated or multi-target priority use by the same requester?
  - Focus: Security events around `@timestamp` on the same `host.id`, grouped by `winlog.event_data.SubjectLogonId`, `winlog.event_data.ProcessId`, `winlog.event_data.ProcessName`, and `winlog.event_data.ObjectName`.
  - Hint: start in the alert window with `event.code` 4674 and alert `winlog.event_data.SubjectLogonId`; expand only if the same session continues around `@timestamp`. Add `event.outcome` to separate failed attempts from successful use. $investigate_1
  - Implication: escalate when one session or requester touches multiple process/thread objects, repeats against security targets, or continues after failures; a single 4674 keeps scope local but still requires requester, object, and session answers for closure.
- If local evidence is suspicious or unresolved, do related alerts expand scope or urgency?
  - Focus: related alerts for the same `host.id`, prioritizing privilege abuse, defense evasion, security-tool interference, service-control, or authentication findings. $investigate_2
  - Hint: if the subject remains suspicious, use the subject pivot; use the `user.id` provider only after confirming it maps to `winlog.event_data.SubjectUserSid`. $investigate_3
  - Implication: broaden scope when the host or user also shows privilege escalation, defense evasion, or unusual authentication; keep scope local when related alerts are absent and 4674/session evidence supports bounded work.
- Escalate for unauthorized process/thread priority manipulation or security-tool interference; close only when object, requester, subject, session, and related alerts bind to one authorized tuning or troubleshooting workflow; preserve 4674 and recovered 4624 evidence and escalate when sparse object or session evidence leaves suspicious findings unresolved.


### False positive analysis

- Performance engineering, benchmark, QA, vendor, or internal support work can trigger when an administrator adjusts scheduling priority or CPU assignment for a test or latency-sensitive workload. Confirm only when `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` align with the same recognized host, accounts, and workload. If records are unavailable, require telemetry-only recurrence of the same full requester path, SID, object family, and host class before treating as benign.
- If the target object is sparse or numeric-only, do not close solely on tool name or user claim.
- Before creating an exception, validate that `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, `host.id`, and recovered `source.ip` or `winlog.logon.type` stay stable across known-benign occurrences. Build the exception from that minimum confirmed pattern; avoid exceptions on `winlog.event_data.PrivilegeList` or `user.name` alone.


### Response and remediation

- If confirmed benign, reverse temporary containment and document the validated `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, `winlog.logon.type`, and `host.id` values proving the tuning or troubleshooting workflow. Create an exception only after the same pattern repeats benignly.
- If suspicious but unconfirmed, preserve a case export of triggering 4674, recovered 4624 session record, surrounding same-session Security records, and related-alert links before containment. Record requester path and PID, subject SID, target object, session origin, and event time as case anchors.
- If suspicious but unconfirmed, apply reversible containment first, such as restricting the subject's remote access, pausing the support workflow, or raising monitoring on `host.id`. Escalate to host isolation or account disablement only if the target maps to a security-critical process, related alerts show additional privilege abuse or defense evasion, or the recovered session suggests credential misuse.
- If confirmed malicious, isolate the host when the object, requester, session, or related-alert evidence shows unauthorized priority manipulation of a security-critical process or another user's workload. Record the requester path and PID, subject SID, target object, recovered session origin, and event time before stopping processes or deleting tooling.
- Reset or suspend the implicated account only when the recovered session and related alerts show likely credential misuse, and review other hosts for the same `winlog.event_data.ProcessName`, `winlog.event_data.ObjectName`, or `winlog.event_data.SubjectUserSid` before eradicating artifacts so scoping finishes before evidence is destroyed.
- Eradicate only the unauthorized tuning or interference tooling and any persistence or launcher artifacts identified during the investigation, then restore affected security or service configurations to a known-good state.
- Hardening: restrict assignment of "SeIncreaseBasePriorityPrivilege" to the smallest admin cohort, retain Security 4674 and 4624 visibility, and record visibility gaps that limited the case decision.


## Rule Query

```kuery
event.category:iam and host.os.type:"windows" and event.code:"4674" and
winlog.event_data.PrivilegeList:"SeIncreaseBasePriorityPrivilege" and event.outcome:"success" and
winlog.event_data.AccessMask:"512" and not winlog.event_data.SubjectUserSid:("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
```

**Framework:** MITRE ATT&CK
- Tactic:
  - Name: Privilege Escalation
  - Id: TA0004
  - Reference URL: [[https://attack.mitre.org/tactics/TA0004/](https://attack.mitre.org/tactics/TA0004/)](https://attack.mitre.org/tactics/TA0004/)
- Technique:
  - Name: Access Token Manipulation
  - Id: T1134
  - Reference URL: [[https://attack.mitre.org/techniques/T1134/](https://attack.mitre.org/techniques/T1134/)](https://attack.mitre.org/techniques/T1134/)