After code runs, an attacker wants two things: to still be there after a reboot, and to have more power than the account they landed in. The library spends about 80 rules on this, roughly 62 for persistence, 18 for privilege escalation and a few for file-permission tricks. They are grouped here by where the attacker writes.
A recurring theme: many of these settings are changed by legitimate software too. The rules therefore look at who made the change (signed installer, unsigned binary, script host, Office) and what the new value points at.
1. Startup and run keys
new entry in a startup-related key by a SIGNED process informational
new entry by an UNSIGNED process informational (more suspicious)
entry created by a commonly abused process (cmd, wscript, ...)
entry that is a SCRIPT file medium
Office adding a value to an autostart key low
The same registry location produces different severities depending on the writer, which is the right design. An installer adds run keys all day; Word adding one is an event.
2. Winlogon and logon-time hooks
- Winlogon Shell, UserInit and Notify: changing which program starts at logon is a classic persistence step; UserInit and Shell changes are rated medium.
- Logon scripts set through the registry (medium).
- Group-policy registry keys modified for persistence (medium).
- Default Windows startup path modified.
- Screensaver setting changed so the attacker's file runs when the machine idles.
Group policy persistence. One rule watches Software\Policies\...\GroupPolicy\PendingGPOs for new Path* and Section* values. Group policy runs with the machine's authority at every refresh, so a planted pending policy is a quiet way to get code run again and again. Expect legitimate noise from Internet Explorer's customisation installer (IeakInstall.Hkcu and seczones.inf are excluded), and treat anything else writing there as hostile until proven otherwise.
3. Hijacking how Windows loads code
AppInit DLL list changed every GUI process loads the DLL
shim database registered / .sdb written compatibility shim runs code in a target process
Application Verifier custom provider loaded into verified processes
shim cache modified by a commonly abused host process
print spooler set to load a new DLL on boot
Security Support Provider DLLs tampered / registered through the registry
MonitorProcess key manipulated code started when a process crashes
WerFault debugger key (see the execution post)
These are persistence and stealth, because the attacker's code runs inside a trusted process. A well-tuned library keeps every one of them enabled; legitimate use is very rare.
4. Services, tasks and start-up files
- Services: Persistence hunt: Startup foothold established with service installation (informational), new service created from the command line, PowerShell creating a service (low), and manipulation of a service's image path.
- Scheduled tasks: a new task is informational on its own, but Persistence hunt: Scheduled task starts an unsigned program is more interesting.
- Startup folder: an executable or script placed there.
- Autorun.inf created in the root of the C: drive (medium).
- System files related to autostart manipulated.
5. Application add-ons
Office default template created or replaced macros loaded in every new document
Persistence hunt: Internet Explorer toolbar configuration changes
Firefox plugins and extensions changed via the registry
Chrome extensions changed via the registry (and Chrome run with key security features disabled)
default file-association configuration changed
6. Accounts and remote access
Rules in this group assume the attacker will create a way back in that does not depend on malware.
new local user created from PowerShell medium
account creation through a command-line tool
user added to the local administrators group (PowerShell, net.exe) medium
RDP enabled through the registry
- by a script host or rundll32.exe medium
- by an unsigned process low
multiple RDP sessions allowed medium
RDP settings manipulated
web shell installation informational
BITS: PowerShell downloads via BITS (medium), bitsadmin used to download
The RDP rules are separated by writer because enabling RDP by hand is normal; enabling it through a script host or rundll32 is not.
7. Privilege escalation on Windows
Eighteen rules plus several tagged elsewhere. The biggest family is User Account Control bypasses.
Windows Store reset utility (WSReset) launching a child medium
IsolatedCommand registry value medium
control.exe registry key hijack medium
changepk registry key medium + unusual child spawned by changepk
sysprep used to bypass UAC
Event Viewer reading a hijacked registry key (file privilege group, medium)
MMC registry configuration manipulated low
The pattern: an auto-elevating Windows binary reads a registry location the user can write. Point that location at a command, run the binary, and the command runs elevated without a prompt. A rule that watches the specific key has almost no false positives.
Other escalation rules:
- Interactive
at.exe(two rules, medium) to run something as SYSTEM. - Sticky Keys file manipulation (medium): replacing the accessibility binary so a SYSTEM shell opens at the logon screen.
- WptsExtensions.dll created (medium): a DLL the Task Scheduler service tries to load, giving SYSTEM execution.
- PsExec running with SYSTEM (informational).
- SSP registered through the registry (two rules).
- Defense-evasion hunt: process launch privileges added to a temporary file and changing permissions or ownership of files, plus an administrator taking rights on a file with
icacls.
8. Triage guidance for this group
who wrote the value or file? (account, parent process, signer)
what does the new value point at? (path, signer, age of the file)
did a reboot or logon follow? (look for the persistence actually firing)
did a new administrator session appear shortly after?
Takeaways
- Alert on writer plus target, not on the key alone.
- Persistence rules that fire rarely and have low false-positive rates deserve high priority even if labelled informational.
- Review administrator-group membership changes daily; it is the cheapest high-value check in this post.
- Keep UAC enabled at the highest level you can tolerate; most bypasses are weaker against it.
Deep dive A: how a UAC bypass really works
Several rules above are really one idea. Some Windows programs are marked to auto-elevate: they start with administrator rights without a prompt, because Microsoft trusts them. A few of those programs read a configuration value from a registry location that a normal user can write (under the current user's own hive). That is the weakness.
1 the attacker's process (medium integrity) writes a command into a per-user registry key
2 the attacker starts an auto-elevating Windows program (event viewer, store reset, licence tool)
3 that program starts at HIGH integrity and reads the key the attacker just wrote
4 it launches the command from the key, now with administrator rights and no prompt
5 the attacker deletes the key to hide it
What a defender sees: a registry write by an ordinary process, followed within seconds by an auto-elevating binary starting an unexpected child. Both halves are rules in the library, which is why there is a rule for the registry value and a rule for the unusual child (changepk is the clearest example). Prefer pairing them: the registry write alone has a few legitimate sources, the child alone is odd, but both together are close to certain.
Mitigations: set UAC to the highest level, remove local administrator rights from daily accounts, and use application control so the spawned command cannot be an arbitrary unsigned file.
Deep dive B: investigating a persistence hit
A persistence alert is a dated promise: something will run later. Work through it in this order.
1 who wrote it? process, command line, parent, signer, user account
2 what does it launch? path, hash, signer, file age, how many other machines have it
3 has it already run? look for the program starting after a logon, reboot or schedule
4 where did the writer come from? mail attachment, browser download, remote session
5 contain remove the value, quarantine the file, isolate the host if the writer was malicious
6 hunt search the fleet for the same value name, file hash and path
Registry run keys in the current user hive do not need administrator rights, so they are the first thing malware tries. Keys in the local machine hive imply administrator rights and are therefore a stronger privilege signal.
Deep dive C: services versus scheduled tasks
Both give persistence, but they differ in what they tell you.
service runs as SYSTEM by default, appears in the service list, logs a "service installed" event
scheduled task can run as any user, can fire at logon / on a timer / on an event, logs a "task created" event
what to log turn on the audit policies that record service installation and task creation
cleanup removing the file is not enough; remove the service or task object itself
An unsigned process executing as a scheduled task is a better lead than a new task alone, because the task is only as suspicious as the file it runs.
Deep dive D: older escalation tricks that still work
- Sticky Keys. Pressing Shift five times at the logon screen runs a system accessibility program as SYSTEM. If an attacker with write access replaces that program, anyone with network or console access gets a SYSTEM shell without logging in. The rule watches for the replacement or the debugger redirection.
- Interactive
at.exe. The legacy scheduler could start an interactive program in the SYSTEM session. It is gone from current Windows, but old servers and lab machines still have it. - WptsExtensions.dll. The Task Scheduler service tries to load this library at start-up. When it is missing, a file planted in the expected location runs as SYSTEM every boot. A rule on the DLL being created catches both the planting and the persistence.
- Security Support Provider registration. SSPs load into the authentication process; a rogue one can capture passwords in plain text. The two SSP rules (one in persistence, one in escalation) cover registering a new provider.
Hardening checklist
application control (allow-list signed software)
UAC at maximum; no local admin for daily accounts
audit policies for service install, task creation, user creation, group changes
alert on any change to the local administrators group
restrict who can write to startup folders and shared autostart locations
review startup items on servers weekly; they should rarely change