Persistence is the phase where attackers ensure they survive a reboot, credential reset, or EDR detection of their initial access tool. Scheduled tasks and registry run keys are the two most common mechanisms because they are built into every Windows installation, require no additional software, and blend naturally into the noise of legitimate software installations.
The key signal is not the mechanism itself but who created it and what it executes. A scheduled task created by schtasks.exe spawned from PowerShell, pointing to a binary in %TEMP% or %APPDATA%, created outside business hours by a non-IT account — that combination is near-certain malicious persistence. This SOP guides analysts through the exact portal paths and event IDs to surface those signals quickly.
◈ Table of Contents
01
Background
CONTEXTB1MITRE ATT&CK Mapping & Persistence Mechanisms
| MITRE | Technique | Mechanism | Attacker Goal |
|---|---|---|---|
| T1053.005 | Scheduled Task/Job — Windows Task Scheduler | schtasks.exe /create; XML task file in C:\Windows\System32\Tasks | Execute payload on schedule (logon, startup, interval) — survives reboot without requiring re-exploitation |
| T1547.001 | Boot/Logon Autostart — Registry Run Keys | HKCU\Software\Microsoft\Windows\CurrentVersion\Run; HKLM\...\Run; RunOnce | Execute payload on every user logon — simple, no privilege required for HKCU keys |
| T1547.009 | Shortcut Modification | Modifying .lnk files in Startup folder | Execute payload when user opens the folder or on logon if placed in Startup |
| T1547.004 | Winlogon Helper DLL | HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon — Userinit, Shell values | Load malicious DLL through Winlogon process at logon — high privilege, very persistent |
B2Log Sources & Key Event IDs
| Event ID | Log | Meaning | Required Setting |
|---|---|---|---|
| 4698 | Security | Scheduled task created — contains task name, trigger, action (what binary/script runs), and creator account | Audit Object Access → Task Scheduler enabled (GPO) |
| 4702 | Security | Scheduled task updated/modified — important for detecting task hijacking where attacker modifies legitimate task | Same as 4698 |
| 4657 | Security | Registry value modified — captures changes to Run/RunOnce keys if registry auditing is enabled | Audit Registry Object Access in GPO; SACL set on Run key paths |
| DeviceRegistryEvents | MDE (Sentinel) | Registry modifications detected by Defender for Endpoint — more reliable than Event 4657; covers HKCU and HKLM Run keys | MDE onboarded |
| DeviceProcessEvents | MDE (Sentinel) | schtasks.exe /create or reg add executions with command-line arguments — captures the persistence creation in the process log | MDE onboarded |
02
Identification
DETECT & INVESTIGATE◈ Scheduled Task / Registry Persistence — Investigation Workflow
I1Identify the Persistence Mechanism — Task Scheduler & RegistryMANUAL + KQL
WHY
Persistence must be understood before it can be removed — deleting a scheduled task without knowing what binary it runs and where that binary came from leaves the payload on disk. The creator process, the binary path, and the creation timestamp are the three facts you need to scope this correctly and connect it back to the initial access event.
◈ Where to Check — Task Scheduler (local device)
taskschd.msc→Task Scheduler Library→Sort by Created date
- 1On the affected device (via Live Response or RDP), run
taskschd.msc. Navigate to Task Scheduler Library. Sort by Created column descending. Look for tasks created around the alert timestamp or during the initial access event window. - 2For each suspicious task: right-click → Properties. Check the Actions tab — this shows the binary or script that runs. If the path is under
%TEMP%,%APPDATA%,C:\Users\Public, orC:\ProgramData— treat as malicious. Legitimate software installs toProgram FilesorWindowsdirectories. - 3Check the Triggers tab — look for: trigger on logon (user-persistent), trigger at startup (system-persistent), or recurring schedule (beacon-style). Note the task name — attackers often use names mimicking legitimate tasks (e.g. "WindowsUpdateCheck", "GoogleUpdateHelper").
◈ Where to Check — Registry Run Keys
regedit.exe→HKCU\Software\Microsoft\Windows\CurrentVersion\Run
- 4Open
regedit.exe(or query via Live Response:reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"). Check both HKCU (current user) and HKLM (all users, requires admin). Each value entry = a program that runs at logon. Look for entries with paths in user-writable directories or with suspicious names. - 5Check additional autorun locations:
HKCU\...\RunOnce,HKLM\...\RunOnce,HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon(Userinit and Shell values — modifications here are Tier-0 persistence), and the Startup folder:C:\Users\[user]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.
Key Indicators — Malicious Persistence Patterns
| Indicator | Meaning | Analyst Action |
|---|---|---|
| Event ID 4698 | Scheduled task created. Check SubjectUserName (creator), TaskName, and TaskContent (XML containing trigger + action) | Extract binary path from TaskContent XML. Hash the binary. Check creator account for risk. |
| Event ID 4702 | Scheduled task modified — attacker may have hijacked an existing legitimate task (task hijacking) | Compare task before/after. If action binary changed to a user-writable path — confirmed hijack. |
| schtasks.exe /create /sc /tr | /sc = schedule type (ONLOGON, ONSTART, MINUTE), /tr = task run (the binary/script path). Command-line shows full persistence config. | Extract /tr argument — that is the payload path. Extract /ru to see run-as account (SYSTEM = high priv). |
| reg add ...Run | Registry run key added via reg.exe command — the /v is the value name, /d is the path that executes | Extract /d value — that is the payload path. Hash it. Check parent process of reg.exe. |
| Winlogon Userinit / Shell modified | Highest-severity registry persistence. Winlogon runs Userinit.exe at logon — appending a malicious binary here ensures execution as SYSTEM at every logon | IMMEDIATE SEV1. Restore Userinit to default (userinit.exe,) and Shell to (explorer.exe). Treat as advanced threat. |
DETECTS: All scheduled task creation events (4698) and schtasks.exe executions in the last 7 days where the task action binary path is in a user-writable directory — the strongest signal of malicious persistence creation.
KQL — Microsoft Sentinel: Suspicious scheduled task creation
// Via Security Events (Event 4698)
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4698
| extend TaskContent = tostring(EventData)
| where TaskContent has_any ("\\Temp\\","\\AppData\\","\\Public\\","\\ProgramData\\",
"powershell","cmd.exe /c","mshta","wscript","cscript")
| project TimeGenerated, Computer, SubjectUserName, SubjectDomainName,
TaskName = extract(@"(.+?)",1,TaskContent),
TaskContent
| order by TimeGenerated desc
DETECTS: schtasks.exe and reg.exe process executions creating persistence — captures the command-line used to register the task or run key, revealing the payload path and run-as account.
KQL — MDE: schtasks /create and reg add Run key
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where (FileName =~ "schtasks.exe" and ProcessCommandLine has "/create")
or (FileName =~ "reg.exe" and ProcessCommandLine has_any ("Run","RunOnce")
and ProcessCommandLine has "add")
| project TimeGenerated, DeviceName, AccountName, FileName,
ProcessCommandLine, InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by TimeGenerated desc
DETECTS: Registry write events to Windows autorun keys — captures both HKCU and HKLM Run/RunOnce modifications with the path written, enabling immediate payload identification.
KQL — MDE: Registry Run key modifications
DeviceRegistryEvents
| where TimeGenerated > ago(7d)
| where RegistryKey has_any (
@"SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
@"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",
@"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
)
| where ActionType in ("RegistryValueSet","RegistryKeyCreated")
| project TimeGenerated, DeviceName, AccountName, RegistryKey,
RegistryValueName, RegistryValueData, InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by TimeGenerated desc
SPL — Splunk: Scheduled task creation and run key persistence
index=windows (EventCode=4698 OR EventCode=4702)
| spath "EventData.TaskContent" output=TaskContent
| spath "EventData.SubjectUserName" output=Creator
| where TaskContent LIKE "%Temp%" OR TaskContent LIKE "%AppData%"
OR TaskContent LIKE "%powershell%" OR TaskContent LIKE "%cmd.exe%"
| table _time, ComputerName, Creator, TaskName, TaskContent
| sort -_time
I2Identify the Payload Binary & Trace to Initial AccessMANUAL + KQL
WHY
The scheduled task or run key is not the threat — it is only the survival mechanism for the actual payload binary. Identifying the binary's hash, creation timestamp, and how it arrived on the device connects the persistence mechanism back to the initial access event (phishing, LOLBin download, PowerShell drop). That connection is what determines scope: single device or active campaign.
◈ Where to Check — File Details of the Payload Binary
security.microsoft.com→Endpoints→[Device]→Timeline→Filter: File created + [payload filename]
- 1In the MDE device timeline, filter for File created events. Search for the binary filename from the task action or run key value. The SHA-256 hash is shown in the event detail — copy it for threat intel lookup.
- 2Check the Initiated by field on the file creation event — this shows what process wrote the payload to disk. This is your link to the initial access vector: if the binary was written by
certutil.exeorpowershell.exe— cross-reference SOP-24 or SOP-25 respectively. - 3Look up the SHA-256 hash in security.microsoft.com → Threat intelligence → File details — MDE shows the prevalence (how many other devices in the org have this file), MDE threat classification, and global threat intel matches.
DETECTS: File creation events for the specific payload binary — identifies when it was dropped, by what process, and the SHA-256 hash needed for threat intel lookup and org-wide blocking.
KQL — MDE: Find when and how the payload binary arrived
let payloadPath = @"C:\Users\username\AppData\Local\Temp\payload.exe"; // replace with actual path
DeviceFileEvents
| where TimeGenerated > ago(14d)
| where FolderPath =~ payloadPath or FileName =~ split(payloadPath,"\\")[-1]
| project TimeGenerated, DeviceName, ActionType, FileName,
FolderPath, SHA256, InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by TimeGenerated asc
DETECTS: All devices in the org that have executed the same payload hash — identifies whether this is a single-device incident or a campaign with multiple victims.
KQL — Org-wide hunt for same payload hash
let maliciousHash = "SHA256HASHHERE"; // replace with actual hash from I2 step 1
DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where SHA256 =~ maliciousHash or InitiatingProcessSHA256 =~ maliciousHash
| summarize Devices = dcount(DeviceName), DeviceList = make_set(DeviceName, 100)
by FileName, SHA256
| where Devices > 0
Attackers often name persistence binaries to mimic legitimate Windows processes: svchost32.exe, lsm.exe, csrss32.exe, wuauclt.exe. Always check the file path — the real svchost.exe lives in C:\Windows\System32, not in %TEMP%. A known process name in an unexpected path = masquerading (T1036).
03
Containment
STOP ITBased on Identification Findings:
Confirmed
Scheduled task or run key points to binary in user-writable path (TEMP/AppData/Public), OR creator process is a malicious chain (PowerShell/LOLBin), OR binary hash matches known malware, OR Winlogon Userinit/Shell value was modified → Execute C1 immediately.
Uncertain
Scheduled task created by a standard user account with unusual name, binary in semi-legitimate path (ProgramData), no hash match in threat intel, no obvious malicious parent process → Contact device owner and check if software was deliberately installed. Review binary digital signature (unsigned = strong indicator). Hold for maximum 20 minutes.
False Pos.
Task/key created by a known IT deployment tool (SCCM, Intune, chocolatey), binary is digitally signed by a trusted publisher, path matches approved software installation directory, creation timestamp matches a software deployment window → Document, close, tune the analytics rule to exclude the deployment tool account or binary path.
C1Delete Persistence & Kill Active PayloadImmediate
- 1Delete the malicious scheduled task: Via MDE Live Response:
schtasks /delete /tn "[TaskName]" /f. Confirm withschtasks /query /tn "[TaskName]"— should return "ERROR: The specified task name was not found." - 2Remove the registry run key entry: Via Live Response:
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "[ValueName]" /f. Repeat for HKLM if the entry exists there. Confirm removal withreg query. - 3Kill the payload process if currently running:
taskkill /F /IM [payload.exe]or by PID. Check whether the payload has spawned child processes and kill those too. - 4Delete the payload binary from disk:
del /F /Q "[payload_path]". If the file is locked (in use), kill the process first, then delete. - 5Block the payload hash org-wide: MDE → Threat intelligence → Indicators → File hash → Block and remediate. This prevents re-execution if the file was copied to other devices.
04
Eradication
CLEAN UPE1Full Persistence Audit & Org-Wide Hunt
- 1Audit all autorun locations on the affected device: Use Sysinternals Autoruns (run via Live Response) to enumerate every persistence mechanism — tasks, run keys, services, browser extensions, WMI subscriptions, boot sectors. Any unsigned entry in a non-standard path is suspicious.
- 2Hunt org-wide for the same task name or run key value name: Run the I1 KQL across all devices. Attackers deploying to multiple targets use the same task name — finding it on 5 devices means 5 devices are compromised.
- 3Hunt org-wide for the payload binary hash: Run the I2 org-wide hash hunt KQL. Any device that executed the same binary must be isolated and triaged.
- 4Remediate the initial access vector: The persistence mechanism was installed by something else (phishing email, LOLBin download, PowerShell). That vector must be closed — remove the delivery document, block the phishing domain, or fix the vulnerability that allowed the download. Without closing the initial access vector, the attacker will re-establish persistence within hours.
Eradication Complete When
- All malicious scheduled tasks deleted and confirmed absent via schtasks /query on device
- All malicious registry run key entries removed; Winlogon values restored to defaults if modified
- Payload binary deleted from disk; hash blocked org-wide in MDE Custom Indicators
- Org-wide hunt for same task name, run key name, and payload hash returns zero results
- Initial access vector (phishing doc / download mechanism) identified and closed
- Autoruns scan on affected device shows clean — no unsigned entries in non-standard paths
05
Escalation
TIERSESCEscalation Decision Table
| Tier | Trigger Condition | Who to Notify | Action |
|---|---|---|---|
| L1 → L2 | Single device, malicious task/run key confirmed, payload deleted, hash blocked, initial access vector identified — no lateral movement or credential harvesting evidence | L2 SOC Analyst | Hand off: device name, task/key name, payload path and hash, creator process chain, containment actions |
| L2 → IR | Multiple devices with same task/run key name or payload hash, Winlogon Userinit/Shell modified (high-priv persistence), payload is a known C2 implant, or credential dumping activity follows the persistence creation | IR Team | Declare SEV1 or SEV2. Enumerate all affected devices. Assess dwell time (when was the task first created vs now?). Map all actions taken by the payload during dwell period. |
| L2 → Security Engineering | No analytics rule detected task creation at creation time — alert only fired on execution; no audit policy generating Event 4698; AppLocker/WDAC not blocking unsigned binaries in user-writable paths | Security Architecture | Deploy Task Scheduler audit GPO (Event 4698). Consider AppLocker rules blocking binary execution from %TEMP% and %APPDATA%. Deploy Sentinel Scheduled Task Persistence analytics rule. |
Authorized security research & penetration testing only. Unauthorized use is illegal. Built by Rudra Verma | Senior Cyber Security Architect & Researcher | CyberHawk Threat Intel
◈ Stay Connected
Follow CyberHawk Threat Intel for threat intelligence, SOC playbooks, and detection engineering content.
"They can't exploit you if you are the Exploit."