What You'll Learn
- Enumerate all major Windows persistence mechanisms using Velociraptor artifacts
- Detect malicious Registry Run/RunOnce keys, Scheduled Tasks, and rogue Services
- Identify WMI event subscriptions, Startup folder modifications, and COM object hijacking
- Build a comprehensive Persistence Audit Matrix documenting each mechanism's status and risk level
- Differentiate between legitimate system persistence entries and attacker-planted backdoors
Lab Overview
| Detail | Value |
|---|---|
| Lab Profile | lab-velociraptor |
| Containers | Velociraptor Server, Velociraptor Client (Windows endpoint) |
| Estimated Time | 65–75 minutes |
| Difficulty | Advanced |
| Browser Access | Velociraptor Web UI |
| Pre-Loaded Data | 10+ planted artifacts: persistence in registry keys, scheduled tasks, services, WMI subscriptions, startup folder, and more |
| Deliverable | Persistence Audit Matrix documenting every mechanism checked, findings, and risk level |
Why Persistence Auditing Matters. An attacker who gains access once is a nuisance. An attacker who persists through reboots, password changes, and security patches is a catastrophe. Persistence mechanisms are how adversaries ensure they can return — and sophisticated actors plant persistence in multiple locations so removing one doesn't eliminate their access. A complete audit checks every known mechanism, not just the obvious ones.
The Scenario
Following the credential theft investigation (Lab OS.4), your incident response team needs to determine how the attacker ensured continued access to WIN-SERVER-01. Intelligence suggests this threat actor typically plants persistence in 3–5 different locations to survive remediation attempts.
Your mission is to conduct a full persistence audit — systematically checking every major Windows persistence mechanism. The attacker has planted backdoors in multiple locations, and missing even one means they can return. You'll use Velociraptor's built-in artifacts and custom queries to build a comprehensive Persistence Audit Matrix that the IR team can use for remediation.
Some persistence mechanisms will be legitimate (Windows Update, antivirus services). Others are clearly malicious. A few will be subtle — designed to blend in with normal system entries. Your job is to classify every finding.
Part 1: Registry-Based Persistence
Registry Run keys are the most common persistence mechanism — they execute programs automatically when a user logs in or the system boots.
Step 1.1: Enumerate Run/RunOnce Keys
Artifact: Windows.Persistence.PermanentWMIEvents
First, use the dedicated persistence artifact that checks multiple locations at once:
Artifact: Windows.Sys.StartupItems
Then manually verify the key registry locations:
Artifact: Windows.Registry.Hunter
Parameters:
KeyGlob: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\**
Also check the per-user Run keys:
Artifact: Windows.Registry.Hunter
Parameters:
KeyGlob: HKEY_USERS\*\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\**
Expected Results: You'll see a mix of legitimate entries (Windows Defender, system utilities) and suspicious ones. For each entry, record:
- Value name
- Data (the command that executes)
- Whether the binary path exists and is signed
- Risk classification: LEGITIMATE / SUSPICIOUS / MALICIOUS
Step 1.2: Check RunOnce Keys
RunOnce keys execute once then self-delete — a stealthier persistence option:
Artifact: Windows.Registry.Hunter
Parameters:
KeyGlob: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\**
Expected Results: RunOnce entries are less common. Any entry here warrants investigation, especially if it contains encoded commands, points to temp directories, or uses PowerShell/cmd.
Step 1.3: Check Additional Registry Persistence Locations
Advanced attackers use less-monitored registry locations:
Artifact: Windows.Registry.Hunter
Parameters:
KeyGlob: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\**
Check the Shell and Userinit values — these should be explorer.exe and userinit.exe respectively. Any additions indicate persistence.
Also check:
Artifact: Windows.Registry.Hunter
Parameters:
KeyGlob: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\**
Image File Execution Options (IFEO) can intercept process launches — an attacker could set a debugger for a common tool that redirects to their backdoor.
Don't Skip the Obscure Locations. Many persistence audits only check Run/RunOnce keys. Sophisticated attackers know this and plant persistence in Winlogon Shell, IFEO debuggers, AppInit_DLLs, or BootExecute. A thorough audit checks all of them — that's what separates a checklist from a real investigation.
Part 2: Scheduled Task Persistence
Scheduled Tasks can execute programs at boot, logon, or on a recurring schedule — and they persist through reboots by default.
Step 2.1: Enumerate All Scheduled Tasks
Artifact: Windows.System.TaskScheduler
Expected Results: The output will contain dozens of tasks. Focus on:
- Tasks with non-Microsoft publishers (or no publisher)
- Tasks pointing to scripts in temp directories, user profiles, or unusual paths
- Tasks with encoded PowerShell in the action command
- Tasks created recently (check registration date)
Step 2.2: Inspect Suspicious Task XML
For any suspicious task, examine the full task XML:
Artifact: Windows.Search.FileFinder
Parameters:
SearchFilesGlob: C:/Windows/System32/Tasks/**
Read the XML for suspicious tasks and document:
- Trigger type (boot, logon, timer)
- Action (what it executes)
- Run level (highest privilege?)
- Hidden flag (is the task hidden from Task Scheduler GUI?)
Step 2.3: Check for Tasks in Non-Standard Locations
Artifact: Windows.Search.FileFinder
Parameters:
SearchFilesGlob: C:/Windows/System32/Tasks/**/.*
Attackers sometimes create tasks with hidden names (starting with a dot) or place task files in subdirectories that don't appear in the Task Scheduler GUI.
Part 3: Service-Based Persistence
Windows Services run as SYSTEM by default, start automatically, and restart on failure — making them ideal for persistence.
Step 3.1: Enumerate All Services
Artifact: Windows.System.Services
Expected Results: Filter for services that:
- Have a Start Type of Automatic or Auto-Delayed
- Run as LocalSystem (highest privilege)
- Point to binaries in unusual locations (not System32 or Program Files)
- Have generic or misleading names designed to blend in
Step 3.2: Verify Service Binary Signatures
For suspicious services, check if the binary is signed:
Artifact: Windows.System.Services
Look at the CertinfoIssuer and CertinfoTrusted columns. Unsigned binaries running as services are high-priority findings.
Step 3.3: Check for Service DLL Hijacking
Artifact: Windows.Registry.Hunter
Parameters:
KeyGlob: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\**\Parameters
Check the ServiceDll values. An attacker could modify the DLL path for a legitimate service to load their malicious DLL instead.
Part 4: WMI Event Subscription Persistence
WMI event subscriptions are one of the stealthiest persistence mechanisms — they execute code in response to system events without visible processes.
Step 4.1: Enumerate WMI Subscriptions
Artifact: Windows.Persistence.PermanentWMIEvents
Expected Results: This artifact checks for:
- Event Filters — the trigger condition (e.g., "when system starts")
- Event Consumers — the action (e.g., "run this script")
- Filter-to-Consumer Bindings — connecting triggers to actions
Legitimate WMI subscriptions are rare. Most entries here are suspicious.
Step 4.2: Decode WMI Consumer Scripts
If you find a CommandLineEventConsumer or ActiveScriptEventConsumer, decode the script contents. Attackers often embed base64-encoded PowerShell in WMI consumers:
Artifact: Windows.EventLogs.EvtxHunter
Parameters:
EvtxGlob: C:/Windows/System32/winevt/Logs/Microsoft-Windows-WMI-Activity%4Operational.evtx
SearchRegex: (Consumer|Subscription|Binding)
Document the full WMI persistence chain: Filter → Consumer → Binding.
WMI Persistence is Underdetected. Many organizations don't monitor WMI event subscriptions at all. This makes them a favorite for advanced persistent threats (APTs). If you find WMI persistence in a real investigation, it often indicates a more sophisticated attacker than one using simple Run keys.
Part 5: Startup Folder & COM Object Persistence
Step 5.1: Check Startup Folders
Artifact: Windows.Search.FileFinder
Parameters:
SearchFilesGlob: C:/Users/*/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/**
Also check the all-users startup:
Artifact: Windows.Search.FileFinder
Parameters:
SearchFilesGlob: C:/ProgramData/Microsoft/Windows/Start Menu/Programs/Startup/**
Expected Results: Look for shortcut (.lnk) files, scripts (.bat, .ps1, .vbs), or executables that weren't present in the original baseline.
Step 5.2: Check for COM Object Hijacking
COM hijacking replaces legitimate COM class references with malicious DLLs:
Artifact: Windows.Registry.Hunter
Parameters:
KeyGlob: HKEY_USERS\*\SOFTWARE\Classes\CLSID\**\InprocServer32
Per-user CLSID registrations override system-wide ones. If a user has InprocServer32 entries pointing to DLLs outside System32 or Program Files, this is likely COM hijacking.
Part 6: Build the Persistence Audit Matrix
Compile all findings into a structured matrix:
PERSISTENCE AUDIT MATRIX
═══════════════════════════
Endpoint: WIN-SERVER-01
Date: [today's date]
Analyst: [your name]
| # | Mechanism | Location Checked | Finding | Risk Level | Notes |
|---|-----------|-----------------|---------|------------|-------|
| 1 | Registry Run (HKLM) | CurrentVersion\Run | [FOUND/CLEAN] | [LOW/MED/HIGH/CRIT] | [details] |
| 2 | Registry Run (HKU) | CurrentVersion\Run | [FOUND/CLEAN] | | |
| 3 | Registry RunOnce | CurrentVersion\RunOnce | [FOUND/CLEAN] | | |
| 4 | Winlogon Shell/Userinit | Winlogon | [FOUND/CLEAN] | | |
| 5 | Image File Exec Options | IFEO | [FOUND/CLEAN] | | |
| 6 | Scheduled Tasks | System32\Tasks | [FOUND/CLEAN] | | |
| 7 | Windows Services | CurrentControlSet\Services | [FOUND/CLEAN] | | |
| 8 | WMI Subscriptions | WMI Repository | [FOUND/CLEAN] | | |
| 9 | Startup Folder (User) | Start Menu\Startup | [FOUND/CLEAN] | | |
| 10 | Startup Folder (All Users) | ProgramData\Startup | [FOUND/CLEAN] | | |
| 11 | COM Object Hijack | HKCU\CLSID | [FOUND/CLEAN] | | |
| 12 | Service DLL Hijack | Services\*\Parameters | [FOUND/CLEAN] | | |
TOTAL MECHANISMS CHECKED: 12
MALICIOUS FINDINGS: [count]
SUSPICIOUS FINDINGS: [count]
CLEAN: [count]
REMEDIATION PRIORITY:
1. [Highest-risk finding first]
2. [Second highest]
3. ...
CONFIDENCE ASSESSMENT:
[ ] All known persistence mechanisms audited
[ ] Findings cross-referenced with baseline
[ ] Malicious entries have forensic evidence documented
Deliverable Checklist
Before completing the lab, ensure you have:
- Registry Run/RunOnce Keys — Both HKLM and HKU locations checked and documented
- Winlogon & IFEO — Shell, Userinit, and IFEO debugger values verified
- Scheduled Tasks — Full task list reviewed with suspicious tasks analyzed in detail
- Windows Services — All auto-start services checked, unsigned binaries flagged
- WMI Event Subscriptions — Permanent subscriptions enumerated and decoded
- Startup Folders — Per-user and all-users startup folders inspected
- COM Object Hijacking — Per-user CLSID overrides checked
- Persistence Audit Matrix — Complete matrix with all 12 mechanisms, risk levels, and remediation plan
Key Takeaways
- A thorough persistence audit checks at least 12 different mechanisms — Run keys are just the beginning
- Sophisticated attackers plant persistence in 3–5 locations to survive partial remediation
- WMI event subscriptions and COM object hijacking are undermonitored and favored by APT groups
- Every finding must be classified: LEGITIMATE, SUSPICIOUS, or MALICIOUS — not all persistence is evil
- The Persistence Audit Matrix is both an investigation deliverable and a remediation roadmap for the IR team
What's Next
In Lab OS.6 — Linux System Baseline, you'll shift from Windows to Linux — using Velociraptor to baseline a Linux system and detect anomalies in cron jobs, systemd services, SUID binaries, authorized_keys, and running processes. The same systematic audit approach applies, but the persistence mechanisms are entirely different.
Lab Challenge: Full Persistence Audit
10 questions · 70% to pass
Run the Windows.Sys.StartupItems artifact. How many registry locations does Windows have for auto-start programs (Run, RunOnce, at both HKLM and HKU scope)?
You find a Registry Run key entry pointing to 'C:\Users\admin\AppData\Local\Temp\svchost.exe'. What makes this entry suspicious compared to the legitimate svchost.exe?
Run Windows.System.TaskScheduler and look for recently created tasks. What attributes of a scheduled task indicate it was likely created by an attacker rather than the operating system?
Using Windows.System.Services, you find a service named 'WindowsUpdateHelper' with Start Type 'Auto' running as LocalSystem. The binary path is 'C:\ProgramData\update.exe'. Is this legitimate?
Run Windows.Persistence.PermanentWMIEvents. You find a WMI EventFilter with query 'SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA Win32_PerfFormattedData_PerfOS_System AND TargetInstance.SystemUpTime >= 240'. What does this filter trigger on?
You find a WMI ActiveScriptEventConsumer with a VBScript payload. Why are WMI event subscriptions considered stealthier than Registry Run keys?
Check the Startup folders for all users. You find a file 'update-check.lnk' in the All Users startup folder. What should you examine in the .lnk file to determine if it's malicious?
You check HKCU\SOFTWARE\Classes\CLSID and find a per-user InprocServer32 entry pointing to 'C:\Users\admin\Documents\helper.dll'. What persistence technique is this?
After completing your audit, you found persistence in 4 locations: a Registry Run key, a Scheduled Task, a WMI subscription, and a Startup folder shortcut. During remediation, the team removes the Run key and the Scheduled Task. What happens?
In your Persistence Audit Matrix, which mechanism should be classified as the HIGHEST risk and remediated first?
0/10 answered