Boot/Autostart Execution (T1547): Detect Registry, Startup Folder, and LSA persistence

What is Boot or Logon Autostart Execution?

Registry Run Keys and the Startup Folder are among the oldest persistence mechanisms in Windows. T1547 covers how adversaries configure programs to execute automatically when the system boots or a user logs on. Every category of threat actor uses this technique, from commodity malware that writes a single Run key to nation-state groups that install Authentication Packages and Security Support Providers for credential-harvesting persistence.

The primary sub-technique, T1547.001 (Registry Run Keys / Startup Folder), exploits Windows' built-in mechanism for launching programs at logon. When a program path is written to HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run or a shortcut is dropped in the Startup Folder, Windows automatically executes it at every logon without elevated privileges. The IBM X-Force 2026 Threat Intelligence Index identifies Run Key persistence in 28% of Windows-based intrusions. That makes it the most common persistence mechanism after scheduled tasks.

Part of the Persistence (TA0003) tactic in the MITRE ATT&CK® framework.

Key facts about T1547

How the attack works: attack scenario

Stage 1: Payload deployment

The attacker's payload is already executing on the victim host, typically via Execution (TA0002) techniques. The malware needs to survive beyond the current session, so it installs an autostart mechanism. For Run Key persistence, the payload calls reg add or the Windows API to write its binary path into a Run key. For Startup Folder persistence, it drops a shortcut (.lnk) or executable into %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup.

Stage 2: Registry or file system modification

The actual persistence installation is a single Registry write or file drop. What this looks like in Sysmon logs:

The indicators are clear: a process from a Temp directory writes a Run key value pointing back to itself. Without Sysmon, this Registry modification generates no Windows Security Event Log entry. Sysmon deployment is essential for T1547 detection.

Stage 3: Automatic execution

At the next logon, Windows reads the Run key values and launches each registered program. The attacker's payload auto-starts and re-establishes C2. The compromise continues even if the original execution context has been terminated.

Advanced sub-techniques

Beyond Run Keys, T1547 includes stealthier persistence mechanisms. T1547.002 (Authentication Packages) registers a malicious DLL as an authentication package in the LSA. The DLL gets loaded by lsass.exe at boot and gives the attacker access to all authentication credentials passing through the system. T1547.005 (Security Support Provider) works the same way: a DLL registered as an SSP intercepts credentials through the SSPI interface. State-sponsored groups favor these sub-techniques because they operate at the kernel-adjacent level and survive most cleanup actions.

Real-world attacks using T1547

How to detect T1547 with Log360 and Sysmon

Log360 does not ship prebuilt correlation rules for T1547 Registry persistence. This section covers the detection architecture: Sysmon deployment for telemetry, custom correlation rules for detection, and UEBA for behavioral anomaly analysis.

Sysmon deployment requirements

Install Sysmon across all Windows endpoints with a configuration that captures these event types:

• Event ID 13 (RegistryEvent - Value Set): Captures Registry value modifications. Filter on Run, RunOnce, Winlogon, and LSA key paths.
• Event ID 12 (RegistryEvent - Object Create/Delete): Captures new Registry key creation and deletion in autostart paths.
• Event ID 11 (FileCreate): Captures file creation in Startup Folder paths.
• Event ID 1 (ProcessCreate): Provides process context for the program that made the Registry or file modification.

Forward all Sysmon operational logs to Log360 via the Windows Event Log collection agent.

Custom correlation rule templates

Below are some of the custom correlation rule templates for additional T1547 sub-techniques:

Registry Run Key Persistence Monitor

This custom rule monitors Sysmon Event ID 13 for value writes to the Windows autostart Registry paths. When a non-installer, non-administrative process writes a value to a Run or RunOnce key, the rule fires with Trouble severity.

The detection logic targets: any Sysmon Event 13 where the TargetObject matches *\CurrentVersion\Run\* or *\CurrentVersion\RunOnce\* and the Image (the writing process) does not match an approved software installer or system management tool. In Log360, configure this as a custom correlation rule with the specific Registry path patterns and an exclusion list for known-good installers (msiexec.exe, setup.exe, software distribution agents).

Startup Folder File Drop Monitor

This custom rule monitors Sysmon Event ID 11 for new file creation in Startup Folder paths. When an executable, script, or shortcut file is created in any user's Startup Folder by a non-administrative process, the rule fires with Trouble severity.

Target paths: *\Start Menu\Programs\Startup\* for both per-user and all-users Startup Folders. File type filter: .exe, .dll, .bat, .cmd, .ps1, .vbs, .js, .lnk, .scr. Exclude approved software management tools and system updates.

Authentication Package and SSP Persistence Monitor

This custom rule monitors Sysmon Event ID 13 for modifications to LSA authentication-related Registry keys. Any modification to these paths outside of a Windows update or security product installation is a critical persistence indicator:

• HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages
• HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

Configure this rule with Critical severity. Modifications to LSA authentication mechanisms indicate sophisticated persistence with credential-harvesting capability.

Behavioral detection with UEBA

Log360's UEBA module adds another layer for T1547 detection. It baselines normal Registry modification patterns per user and per host, then flags first-time autostart key modifications even when the writing process appears legitimate. An endpoint that has never had its Run keys modified suddenly gaining a new autostart entry receives an elevated risk score. This provides detection even if the custom rule's exclusion list inadvertently permits the activity.

Investigation workflow in Log360

1. Identify the writing process: From the Sysmon Event 13 alert, examine the Image field to determine what process wrote the Registry key or dropped the Startup Folder file. Cross-reference the process hash against known-good and known-bad lists.
2. Check the payload path: Examine the Registry value data or the Startup Folder file to determine what binary or script will auto-execute. Is it in a user-writable directory? Is it signed? Does the filename mimic a legitimate program?
3. Trace execution origin: Use Log360's process chain view to trace backward from the writing process. Where did it come from? Was it spawned by a browser (possible drive-by download), by an Office application (possible phishing payload), or by a remote access tool?
4. Check for companion persistence: Attackers frequently install multiple persistence mechanisms. Search for scheduled tasks (T1053), services (T1543), and WMI subscriptions (T1546) created in the same time window.
5. Assess environment scope: Search for the same Registry key name or file hash across all monitored endpoints to determine if the persistence was deployed to multiple hosts.

How to remediate and prevent T1547 attacks with Log360

Immediate containment

1. Delete the autostart entry: Remove the malicious Registry value using reg delete "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "ValueName" /f or delete the Startup Folder file. Verify removal by querying the key or folder again.
2. Kill the payload: Terminate any running instance of the autostart payload before removing the Registry entry. Some malware monitors its Registry keys and recreates them if deleted while the payload is running.
3. Check for watchers: Sophisticated malware installs a "watchdog" process that monitors and recreates persistence mechanisms. Look for processes monitoring Registry keys or the Startup Folder.

Root cause remediation

• Identify the initial dropper: The autostart entry is persistence, not initial compromise. Trace backward to find what executed the payload that installed the Run key.
• Clean the payload binary: Remove the malicious binary from the path referenced in the Registry value. Verify by file hash that no copies remain.
• Scan for additional indicators: Use the payload's file hash, network indicators, and process behavior patterns to hunt for the same malware on other endpoints.

Long-term hardening

• Deploy Sysmon enterprise-wide: Sysmon is the primary telemetry source for T1547 detection. Without it, Registry persistence is invisible to SIEM. Use a hardened Sysmon configuration tuned for persistence detection following CIS Controls endpoint monitoring guidance.
• Restrict Registry key ACLs: Where feasible, tighten permissions on HKLM Run keys so only SYSTEM and approved installer accounts can modify them. HKCU keys are harder to restrict because the user owns them.
• Application allowlisting: Use AppLocker or WDAC to prevent unauthorized executables from running. This blocks autostart payloads even if the Registry key is successfully created.
• Regular autostart audits: Use tools like Autoruns (Sysinternals) to periodically audit all autostart entries and compare against a known-good baseline. The NIST CSF recommends continuous monitoring as a core function.

Log360 automated response configuration

Configure automated responses for the custom T1547 rules via Log360's SOAR framework:

• Alert escalation: For Run Key and Startup Folder alerts (Trouble severity), create a ServiceDesk Plus ticket and notify the endpoint security team.
• Critical containment: For Authentication Package and SSP persistence alerts (Critical severity), automatically disable the affected host's network access and escalate to incident response.
• Evidence preservation: Run a PowerShell script that exports the full Registry Run key contents, Startup Folder listings, and LSA authentication package Registry values for forensic analysis.

Need to explore ManageEngine Log360? Schedule a personalized demo

FAQ