Overview

Registry Run Keys and Startup Folder persistence (T1547.001) is a technique where adversaries write entries to specific Windows registry keys or drop files into startup folders so that their malicious payload automatically executes every time a user logs in. The result is reliable, user-context persistence that survives reboots without requiring elevated privileges in the HKCU variant.

This is one of the most commonly abused persistence mechanisms in the wild — used by commodity malware, ransomware operators, and APT groups alike — because it is simple, effective, and blends with legitimate software behavior. Every SOC must have detection coverage here because a missed run key entry can mean weeks of undetected dwell time while an attacker moves laterally, exfiltrates data, or stages ransomware.

Attacker Perspective

Attackers use this technique to ensure their implant or loader survives reboots and user logoffs with minimal effort and no driver or service installation required.

• RAT/implant persistence via reg.exe: Malware like AsyncRAT or Agent Tesla drops a payload and then runs reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "WindowsUpdate" /t REG_SZ /d "C:\Users\Public\update.exe" /f to survive reboots.
• DLL sideloading via RunOnceEx: Attackers use reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\0001\Depend /v 1 /d "C:\ProgramData\evil.dll" to load a malicious DLL at next logon, bypassing many process-based detections.
• Startup folder file drop: Loaders like Emotet and IcedID copy a malicious LNK or script to C:\Users\[user]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ using native copy commands or PowerShell, avoiding registry writes entirely.
• Living-off-the-land registry modification via PowerShell: Attackers use Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "Updater" -Value "powershell.exe -WindowStyle Hidden -File C:\Temp\stage2.ps1" to avoid spawning reg.exe and evade process-based detections.

This technique is attractive because HKCU run keys require no administrative privileges, the behavior mimics dozens of legitimate applications, and the persistence survives reboots, making it ideal as a first-stage foothold before escalating access.

Detection Strategy

Required Telemetry

• Windows Security Event ID 4657 — Registry value modified: Requires enabling “Audit Registry” under Object Access in Advanced Audit Policy (auditpol /set /subcategory:"Registry" /success:enable /failure:enable). You must also set a SACL on the specific run key registry paths to generate events. Without SACLs on the keys, 4657 will not fire.
• Windows Sysmon Event ID 13 — RegistryEvent (Value Set): Recommended over 4657 for most environments due to easier deployment. Requires Sysmon installed with a config that includes <TargetObject condition="contains">CurrentVersion\Run</TargetObject> in the RegistryEvent filter block. This is the primary telemetry source for registry-based detection.
• Windows Sysmon Event ID 11 — FileCreate: Captures files written to startup folder paths. Configure Sysmon to monitor C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ and C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\.
• Windows Security Event ID 4688 — Process Creation (with command line logging): Captures reg.exe, powershell.exe, and other tools writing run keys. Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation. Also enable command-line auditing: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled = 1.
• Sysmon Event ID 1 — Process Creation: Preferred over 4688; captures full command line, parent process image, parent command line, and hashes. Requires Sysmon config with process creation logging enabled.
• PowerShell Script Block Logging (Event ID 4104): Captures PowerShell-based registry modifications that bypass reg.exe. Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Block Logging, or via registry: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Generates Event ID 4104 in the Microsoft-Windows-PowerShell/Operational log.
• Windows Security Event ID 4698/4702 — Scheduled Task Created/Modified: Useful for correlated persistence detection; attackers often combine run keys with scheduled tasks.

Key Indicators

• Sysmon EID 13 / Security EID 4657 — Unexpected registry write to run keys: Field TargetObject contains any of: HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\Software\Microsoft\Windows\CurrentVersion\Run, HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce, HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce, HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx, \Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Run. Field Details (the value data) pointing to suspicious paths such as %TEMP%, C:\Users\Public\, C:\ProgramData\, or script interpreters like powershell.exe, wscript.exe, mshta.exe, cmd.exe.
• Sysmon EID 1 / Security EID 4688 — reg.exe adding run key entry: Field Image ends with \reg.exe, CommandLine contains add AND any run key path string. Watch for value names designed to look legitimate: WindowsUpdate, SecurityHealth, OneDriveSetup, MicrosoftEdgeUpdate.
• PowerShell EID 4104 — Set-ItemProperty targeting run keys: ScriptBlockText contains Set-ItemProperty or New-ItemProperty AND contains CurrentVersion\Run. Also watch for [Microsoft.Win32.Registry] .NET calls and reg.exe called from within a PowerShell script block.
• Sysmon EID 11 — File created in startup folder paths: TargetFilename matches *\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\* or *\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\*. Flag especially non-.lnk extensions: .exe, .bat, .ps1, .vbs, .js.
• Suspicious parent process relationships: Run key writes where ParentImage is an unexpected interpreter — e.g., winword.exe, excel.exe, outlook.exe, mshta.exe, wscript.exe, or rundll32.exe spawning reg.exe is a high-confidence indicator of malicious macro or dropper activity.
• Value data pointing to LOLBins or encoded commands: Details field in Sysmon EID 13 containing -enc, -EncodedCommand, -w hidden, bypass, or IEX inside the payload string is a strong signal of malicious intent regardless of the key name used.

Detection Logic

Rule 1: Registry Run Key Write by Any Process — Broad catch for any process modifying standard run key locations.
IF EventID = 13 (Sysmon) OR EventID = 4657 (Security)
AND TargetObject CONTAINS_ANY ["CurrentVersion\Run", "CurrentVersion\RunOnce", "RunOnceEx", "WOW6432Node\Microsoft\Windows\CurrentVersion\Run"]
AND Image NOT IN [known_software_installer_list]
THEN alert(severity=MEDIUM)

This rule casts the widest net and will generate moderate volume. Expect significant false positives from software installers and IT management tools. Use primarily for baselining and tuning. Enrich with asset context — a hit on a server vs. a user workstation should be treated very differently.

Rule 2: reg.exe Run Key Modification with Suspicious Value Data — Catches the most common adversary pattern of using reg.exe with LOLBin or temp-path payloads.
IF EventID = 1 (Sysmon) OR EventID = 4688 (Security)
AND Image ENDSWITH "\reg.exe"
AND CommandLine CONTAINS "add"
AND CommandLine CONTAINS_ANY ["CurrentVersion\Run", "CurrentVersion\RunOnce", "WOW6432Node"]
AND CommandLine CONTAINS_ANY ["powershell", "wscript", "mshta", "cscript", "cmd.exe", "%temp%", "C:\Users\Public", "C:\ProgramData", "-enc", "bypass", "-w hidden"]
THEN alert(severity=HIGH)

High-fidelity rule with low false positive rate. Legitimate software rarely uses these interpreter or obfuscation patterns when setting run keys. This should be treated as near-confirmed malicious activity requiring immediate investigation.

Rule 3: Office Application or Browser Spawning Run Key Modification — Targets macro-delivered or drive-by persistence, very high confidence.
IF EventID = 1 (Sysmon) OR EventID = 4688 (Security)
AND Image ENDSWITH_ANY ["\reg.exe", "\powershell.exe", "\cmd.exe"]
AND ParentImage ENDSWITH_ANY ["\winword.exe", "\excel.exe", "\outlook.exe", "\powerpnt.exe", "\mshta.exe", "\wscript.exe", "\cscript.exe", "\rundll32.exe", "\msedge.exe", "\chrome.exe"]
AND CommandLine CONTAINS_ANY ["CurrentVersion\Run", "Startup"]
THEN alert(severity=CRITICAL)

Very low expected false positive volume — legitimate Office macros virtually never write run keys during normal operation. Any hit here should be escalated immediately. This covers macro-delivered malware, malicious LNK files, and drive-by download payloads.

Rule 4: File Created in Startup Folder with Executable or Script Extension — Catches startup folder abuse that bypasses registry-based detection.
IF EventID = 11 (Sysmon)
AND TargetFilename MATCHES ["*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\*", "*\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\*"]
AND TargetFilename ENDSWITH_ANY [".exe", ".bat", ".cmd", ".ps1", ".vbs", ".js", ".jar", ".dll", ".hta"]
AND Image NOT IN [known_software_installer_list]
THEN alert(severity=HIGH)

Catches adversaries who drop payloads to startup folders rather than writing registry keys. Moderate false positive volume from legitimate software that self-installs startup entries — tune against your baseline of known software by hash or signed publisher.

Tuning Guidance

• Software installers writing run keys during installation: This is the highest-volume false positive source. Build a baseline of known installer processes and their parent processes (e.g., msiexec.exe, setup.exe signed by known vendors). Exclude by adding Image IN [installer_whitelist] AND process is code-signed by trusted publisher. Do not exclude by image name alone — verify the signature.
• IT management and endpoint agents (SCCM, Intune, BigFix, Tanium): These platforms routinely write run keys during agent deployment and software pushes. Exclude by ParentImage IN ["ccmexec.exe", "BESClient.exe", "TaniumClient.exe"] or by the specific value names these tools write. Maintain a documented list and review it quarterly.
• Discord, Slack, Teams, Zoom, and other collaboration tools: These applications aggressively write run keys for auto-start. Baseline by value name and registry path — e.g., Discord always writes HKCU\...\Run\Discord pointing to a signed binary under %AppData%\Discord\. Exclude when Details matches the expected signed binary path AND the process is code-signed.
• Security and AV products writing their own run keys: EDR agents, AV scanners, and backup agents commonly write HKLM run keys. Exclude by the specific key value names and validate the target binary is signed by the expected vendor certificate.
• Developer tools and scripting environments: Tools like Anaconda, Python environments, and various IDEs write run keys. If your environment has developers, scope Rule 1 to servers and non-developer workstations, or add a separate lower-severity rule for developer machines with a broader exclusion list and require analyst triage rather than auto-escalation.

When the Alert Fires: Investigation Steps

1. Verify the alert is real by confirming the raw event: Pull the original Sysmon EID 13 or EID 1 event directly from your SIEM or EDR console and confirm the TargetObject, Details, Image, and User fields are populated as expected and not a parsing artifact. Cross-reference with Windows Security EID 4657 if available to double-confirm the registry write occurred.
2. Identify the affected host and user account: Note the ComputerName, User, and ProcessGuid from the alert, then check if the user account is privileged (admin, service account, or executive) in Active Directory — privileged account persistence is an automatic escalation trigger. Confirm whether the host is a workstation, server, or domain controller, as server-side hits are higher priority.
3. Pull the full process tree and command line: Using Sysmon EID 1 correlated by ProcessGuid and ParentProcessGuid, reconstruct the full parent chain going at least three levels up. Look for the chain breaking at an unexpected interpreter (e.g., svchost.exe → wscript.exe → cmd.exe → reg.exe) and capture the complete CommandLine value including the registry value name and data being written.
4. Examine the payload referenced in the run key value: Retrieve the binary or script path stored in the run key Details field. Check if the file exists on disk using Sysmon EID 11 file creation events, EDR file query, or endpoint live response. Hash the file and submit to VirusTotal or your internal malware sandbox — also check the file’s code signing status and creation timestamp against the user’s login history.
5. Check for network connections from the process or payload: Query Sysmon EID 3 (NetworkConnect) events for the ProcessGuid of the suspicious process and any child processes spawned from it. Look for connections to unusual IP ranges, non-standard ports, or domains registered recently. Cross-reference IPs and domains against your threat intelligence platform and check DNS logs for associated queries.
6. Search for additional persistence mechanisms on the same host: Query Sysmon EID 13 for all registry writes by the same User and ProcessGuid in the surrounding 24-hour window, covering scheduled tasks (EID 4698), service installations (EID 7045), and additional run key writes. Also query Sysmon EID 11 for files dropped to %TEMP%, C:\Users\Public\, C:\ProgramData\, and startup folder paths — attackers rarely deploy only one persistence mechanism.
7. Make the escalation decision: Treat as a confirmed incident requiring IR escalation if any of these are true: the payload is flagged malicious by threat intel or sandbox, the parent process is an Office application or browser, the run key value data contains encoded commands or LOLBin invocations, network connections to external IPs are confirmed, or there is evidence of lateral movement from the host. Treat as likely benign (close with documentation) only if the writing process is a known, signed installer, the payload binary is signed by a trusted vendor, and the value name matches a known application’s expected behavior.

Response Playbook

Containment

• Isolate the host from the network immediately but leave it powered on: Use your EDR platform’s network isolation feature (CrowdStrike Contain, Defender for Endpoint Isolate, Carbon Black Quarantine) to cut off all network communications while preserving volatile memory artifacts, running processes, and open file handles for forensic collection.
• Disable the affected user account in Active Directory: Run Disable-ADAccount -Identity [username] from a clean admin workstation or use the Active Directory Users and Computers console. If the account has active Kerberos tickets, also run Get-ADUser [username] | Set-ADUser -KerberosEncryptionType None and force a ticket revocation by resetting the password immediately.
• Kill the malicious process if still running: Use EDR live response or PsExec from your jump host to terminate the process by PID identified during investigation. On CrowdStrike: use Real Time Response kill [PID]. On Defender: use Live Response killprocess [PID]. Do not simply close the process from the affected host’s UI — use a remote trusted tool.
• Block identified C2 IPs and domains at the perimeter: Submit identified external IPs and domains to your firewall team and DNS security platform (e.g., Umbrella, Zscaler, Infoblox) for immediate blocking. Create a temporary EDR policy to block the malicious binary hash across all endpoints if your platform supports it (Carbon Black, Defender, CrowdStrike all offer hash-based blocking).
• Revoke active sessions and tokens: If the compromised user has active VPN sessions, SSO tokens, or cloud service sessions (Azure AD, AWS, GCP), revoke them immediately. In Azure AD: use Revoke-AzureADUserAllRefreshToken -ObjectId [user_object_id]. Check for any OAuth application consents the user may have granted and revoke those as well.

Eradication

• Delete the malicious registry run key entry: From a trusted admin context using live response or a remote registry tool, run reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "[malicious_value_name]" /f for the identified key. Verify deletion with reg query and check all four standard run key hives plus WOW6432Node variants for additional entries from the same campaign.
• Delete all identified payload files from disk: Using EDR live response, remove the binary or script identified in the run key value, plus any files dropped to %TEMP%, C:\Users\Public\, or C:\ProgramData\ that were created within the same timeframe. Collect copies of all deleted files to secure malware storage before deletion for continued analysis.
• Remove any startup folder persistence entries: Check and clear both C:\Users\[user]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ and C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\ for any files not present on a clean baseline image for this host type.
• Reset credentials for all accounts involved: Force a password reset for the compromised user account and any service accounts the malicious process ran under. If the process ran as SYSTEM or had privilege escalation, treat all credentials cached on the host (LSA secrets, DPAPI blobs, browser-stored passwords) as compromised and rotate them.
• Scan lateral movement targets for the same persistence: For every host the compromised user account authenticated to in the 72 hours prior to detection (query Windows Security EID 4624 and 4648), run the same registry and startup folder checks. Use your EDR’s bulk query capability to hunt for the malicious hash, run key value name, and file paths across the entire fleet.
• Check for additional backdoors and scheduled tasks: On the affected host, enumerate all scheduled tasks (schtasks /query /fo LIST /v), all services (sc query), all WMI subscriptions (Get-WMIObject -Namespace root\subscription -Class __EventFilter), and all HKLM and HKCU run keys to identify any secondary persistence mechanisms the attacker may have installed alongside the run key.

Recovery

• Verify the host is clean before reconnecting to the network: Run a full EDR scan and validate no malicious artifacts remain by comparing registry run keys, startup folders, scheduled tasks, and services against a known-good baseline. If confidence in the host’s integrity is below 100% — particularly if the attacker had extended dwell time or SYSTEM-level access — re-image the host from a trusted golden image rather than attempting remediation in place.
• Re-enable the user account only after full verification: Before re-enabling the account in Active Directory, confirm all persistence mechanisms are removed, the user’s password has been reset, their MFA devices have been re-registered, and any OAuth or application consents have been reviewed. Brief the user on the incident and provide phishing awareness guidance if social engineering was involved in initial access.
• Monitor the host and user intensively for 72 hours post-remediation: Create a temporary high-sensitivity detection rule in your SIEM scoped to the recovered host and user, alerting on any registry write to run key paths, startup folder file creation, new service installation, or outbound network connection to previously unseen destinations. Set a 72-hour review window with daily analyst check-ins.
• Document the full incident timeline and update detections: Record the complete attack timeline from initial access through containment, all IOCs (hashes, IPs, domains, registry value names, file paths), and any detection gaps identified. Submit new IOCs to your threat intelligence platform and update SIEM exclusion lists and detection rules with lessons learned from this specific incident.
• Review and harden run key monitoring across the environment: Use this incident as a trigger to audit your Sysmon deployment coverage across all endpoints, verify that registry SACLs are in place on all run key paths for EID 4657 generation, and confirm that startup folder monitoring is active. Present a brief summary to your detection engineering team to assess whether additional detection rules or EDR policies should be deployed fleet-wide based on the attacker’s specific techniques.