Autoelevated task or installer abuse
A built-in Windows component that runs elevated without prompting was invoked with attacker-supplied input.
What it detects
A built-in Windows component that runs elevated without prompting was invoked with attacker-supplied input.
Two shapes, same idea — use something Windows already trusts to do the elevating:
* **Auto-elevating scheduled tasks.** \Microsoft\Windows\DiskCleanup\SilentCleanup is the well-known one: it is registered to run with highest privileges and can be triggered by any user with schtasks /run. Once running it invokes cleanmgr, whose behaviour is steerable through an environment variable the unprivileged caller controls. * **Answer files handed to system installers.** pkgmgr /n:<file> and dism /apply-unattend:<file> both take an XML that describes what to install and run. Pointing them at a file in a user-writable directory turns an elevated servicing tool into a command executor.
The tools are legitimate; the input location is what makes it an attack.
MITRE ATT&CK mapping
False positives and triage
Running a maintenance task on demand is ordinary administration, and OEM deployment workflows genuinely use pkgmgr and dism with answer files — but from a deployment share or a build directory, not from a user's temp folder.
To confirm: the answer-file path is the whole question. Recover the XML and read it — it names what was installed or run, and an unattend file that starts a shell is conclusive. For the scheduled-task path, look for a process starting seconds later with an unexpected parent, and check the environment or registry values the task reads, since that is where the payload is planted rather than in the command line itself.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 80%. Source: rules/windows/autoelevated_task_or_installer_abuse.yaml, licensed under the Apache License 2.0.
id: windows.privilege_escalation.autoelevated_task_or_installer_abuse
version: 1.0.0
status: stable
severity: high
confidence: 0.8
platforms: [windows]
mitre_techniques: [T1548.002, T1053.005]
description: |
A built-in Windows component that runs elevated without prompting was invoked with
attacker-supplied input.
Two shapes, same idea — use something Windows already trusts to do the elevating:
* **Auto-elevating scheduled tasks.** `\Microsoft\Windows\DiskCleanup\SilentCleanup`
is the well-known one: it is registered to run with highest privileges and can be
triggered by any user with `schtasks /run`. Once running it invokes `cleanmgr`,
whose behaviour is steerable through an environment variable the unprivileged
caller controls.
* **Answer files handed to system installers.** `pkgmgr /n:<file>` and
`dism /apply-unattend:<file>` both take an XML that describes what to install and
run. Pointing them at a file in a user-writable directory turns an elevated
servicing tool into a command executor.
The tools are legitimate; the input location is what makes it an attack.
match:
command_line_regex: '(?i)(/run\s[^|]*\\(DiskCleanup\\SilentCleanup|WindowsUpdate|Defrag)\b|/n:\s*"?[a-z]:\\(users|programdata|windows\\temp)|/apply-unattend:\s*"?[a-z]:\\(users|programdata|windows\\temp))'
correlation_keys: [hostname, user_name]
false_positive_guidance: |
Running a maintenance task on demand is ordinary administration, and OEM deployment
workflows genuinely use `pkgmgr` and `dism` with answer files — but from a
deployment share or a build directory, not from a user's temp folder.
To confirm: the answer-file path is the whole question. Recover the XML and read it —
it names what was installed or run, and an unattend file that starts a shell is
conclusive. For the scheduled-task path, look for a process starting seconds later
with an unexpected parent, and check the environment or registry values the task
reads, since that is where the payload is planted rather than in the command line
itself.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.