A Backdoor Hiding in Plain Sight
During a quarterly security review for a client running a 200-seat Windows environment, we found a DLL registered under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls that had been sitting there for eleven months. Their endpoint protection never flagged it. Their SIEM never alerted on it. It was a textbook persistence mechanism—MITRE ATT&CK T1547.001—and it had survived multiple patch cycles, two OS upgrades, and a full EDR rollout.
The tool that caught it? Autoruns.
Windows has over 100 Autostart Extensibility Points (ASEPs). Most security teams know about Run and RunOnce registry keys. Most miss the other 90+ locations where an attacker or unwanted software can establish persistence. If you are not performing a regular Autoruns autostart audit across your fleet, you have blind spots. That is not an opinion—it is arithmetic.
Why Manual Registry Checks Fall Short
I have seen teams try to script their own autostart audits using PowerShell registry queries. They typically cover five to ten locations. Maybe fifteen if they are thorough. The problem is that Windows persistence is not limited to the obvious keys.
Consider just the Logon category alone. Autoruns inspects all of these per-user ASEPs under HKCU\Software:
HKCU\Software\Microsoft\Windows\CurrentVersion\RunHKCU\Software\Microsoft\Windows\CurrentVersion\RunOnceHKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\LoadHKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell- Terminal Server install keys under
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install - Wow6432Node variants on 64-bit systems
- Group Policy-controlled keys under
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
And that is just the per-user side. The systemwide keys under HKLM\Software double the list—plus you get Active Setup components, ActiveSync hooks, SafeBoot alternate shells, and Terminal Server startup programs.
No one is maintaining a hand-rolled script that covers all of that. Autoruns does it automatically across 19 categorized tabs.
What Autoruns Actually Inspects
When you launch Autoruns, it immediately begins enumerating entries from every known ASEP on the system. The Everything tab shows the full list, but the real power is in the category tabs. Here is what each one covers:
Logon Entries
The standard startup locations: Run, RunOnce, RunOnceEx registry keys, Startup directories in the Start menu (both per-user under %APPDATA% and all-users under %ALLUSERSPROFILE%), plus Group Policy logon/logoff and startup/shutdown scripts. This is where most commodity malware lands, and where most defenders stop looking.
Explorer and Shell Extensions
Shell execute hooks, shell extensions, shared task schedulers, and shell service objects. Threat groups like APT29 have historically abused Explorer add-ons for persistence because defenders rarely monitor these locations.
Internet Explorer and Browser Helper Objects
BHOs, toolbars, and browser extensions registered under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects. While IE usage has dropped, these registry paths still exist on modern Windows and can still be weaponized.
Services and Drivers
Entries from HKLM\System\CurrentControlSet\Services. This covers both service image paths and driver entries. A malicious service hiding among hundreds of legitimate ones is harder to spot without Autoruns highlighting unsigned or suspicious entries.
Winlogon and Session Initialization
The Winlogon shell, userinit, notify, and taskman keys. These are high-value targets for attackers because they execute with SYSTEM-level privileges during the logon process. The HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell key should always point to explorer.exe—anything else is a red flag.
AppInit DLLs and Image Hijacks
The Appinit_Dlls key forces DLLs to load into every process that loads user32.dll. This is the persistence mechanism we caught at that client site. Image File Execution Options (IFEO) hijacks are also covered here—attackers set a debugger value for a legitimate executable so their payload runs instead.
Boot Execute Images
Programs that run during the boot sequence, before Windows fully loads. The BootExecute value under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion is rarely modified by legitimate software, making any unexpected entry here worth immediate investigation.
Scheduled Tasks, Codecs, and More
Autoruns also covers Winsock Layered Service Providers, media codecs, and scheduled scripts under Group Policy paths. Each one is a potential persistence vector that most teams overlook.
Running Autoruns at Scale with Autorunsc
The GUI is useful for one-off analysis. For fleet-wide auditing, you need autorunsc, the command-line version.
Here is the syntax that gives you the most actionable output:
:: Export all autostart entries as CSV, verify against VirusTotal, hide Microsoft-signed entries
autorunsc -a * -c -m -s -vt -accepteula > C:\Logs\autoruns_baseline.csvBreaking down those flags:
-a *— scan all autostart categories (you can filter with flags likebfor boot execute,dfor Appinit DLLs,hfor image hijacks,lfor logon,sfor services,wfor Winlogon)-c— CSV output (use-ctfor tab-delimited)-m— hide Microsoft-signed entries to reduce noise-s— verify digital signatures-vt— check hashes against VirusTotal
We deploy this across client environments using Group Policy startup scripts or scheduled tasks, collecting the CSV output to a central share for analysis. You can also use PowerShell loops to iterate over a list of machines and invoke autorunsc remotely via PsExec or WinRM.
Baselining and Diffing: Where the Real Value Lives
A single Autoruns snapshot tells you what is configured right now. Comparing two snapshots over time tells you what changed. That is where you catch persistence being established.
Here is a practical workflow we use in managed environments:
- Capture a baseline CSV on a known-clean image using
autorunsc -a * -c -m -s - Store the baseline alongside your Active Directory snapshots as part of your environment documentation
- Schedule weekly or daily scans across the fleet
- Diff the current scan against the baseline using PowerShell’s
Compare-Object - Investigate any new entries that were not part of an approved change
# Compare current autoruns against baseline — flag new persistence entries
$baseline = Import-Csv C:\Logs\autoruns_baseline.csv
$current = Import-Csv C:\Logs\autoruns_current.csv
Compare-Object $baseline $current -Property 'Image Path','Launch String' |
Where-Object { $_.SideIndicator -eq '=>' } |
Export-Csv C:\Logs\autoruns_delta.csv -NoTypeInformationAny entry appearing in the delta that was not deployed by your team or an approved software package warrants immediate triage.
What Autoruns Will Not Tell You
Here is my caveat: Autoruns is a detection and auditing tool, not a prevention tool. It shows you what is already configured. It does not block new entries from being written. If an attacker has the privileges to write to HKLM\Software\Microsoft\Windows\CurrentVersion\Run, Autoruns will show you the entry after the fact—not stop it in real time.
You still need proper endpoint detection, application whitelisting, and least-privilege controls. Autoruns is one layer in your defense. A critical one, but not the only one.
It also requires local admin rights to see all systemwide entries. Running it as a standard user gives you an incomplete picture. Plan your deployment accordingly.
The Opinionated Take: Autoruns Should Be in Every IR Playbook
I will state this plainly: if your incident response process does not include an Autoruns capture within the first 30 minutes of triage, your process has a gap.
Too many teams jump straight to memory forensics or network traffic analysis while persistence mechanisms sit undiscovered in the registry. Persistence is how attackers survive your remediation. It is the difference between a one-time cleanup and a recurring incident. Capturing autostart state is fast, lightweight, and immediately actionable.
After the third recurring Emotet infection at a client site, we made Autoruns baselining part of every onboarding engagement. The infections stopped recurring because we were finally catching the RunOnce keys and scheduled tasks that the malware re-established after each cleanup. We also ensured those baselines were stored alongside their Microsoft 365 backup configurations, giving us a single reference point for both endpoint and cloud environment states.
Integrating Autoruns Into Your Security Operations
Here is how to move from ad-hoc usage to systematic autostart auditing:
Step 1: Establish Golden Baselines
Build a clean reference image for each OS version and role in your environment. Run autorunsc -a * -c -m -s and store the output. This is your ground truth.
Step 2: Automate Collection
Deploy autorunsc via GPO, SCCM, Intune, or your RMM platform. Collect CSVs to a central location on a daily or weekly cadence. PowerShell alerting scripts can parse the results and flag anomalies automatically.
Step 3: Focus on Unsigned and Unknown Entries
Use the -s flag to verify signatures. Any unsigned entry in a location like Appinit_Dlls, Winlogon\Shell, or BootExecute should be treated as suspicious until proven otherwise. VirusTotal integration via -vt adds another layer of confidence.
Step 4: Map Findings to MITRE ATT&CK
Every autostart location maps to a MITRE technique. Run keys are T1547.001. Services are T1543.003. Scheduled tasks are T1053.005. This mapping turns raw Autoruns data into threat intelligence your SOC can act on. Reference the NIST Zero Trust Architecture framework for guidance on reducing the attack surface these persistence points expose.
The Practical Takeaway
Windows gives software—and attackers—over 100 places to establish persistence. Autoruns is the only tool that enumerates all of them in a single pass, with signature verification and VirusTotal integration built in. Deploy autorunsc across your fleet, baseline everything, diff weekly, and investigate every unexplained delta. If you need help building autostart monitoring into your security operations, reach out to our team—we have done this across environments ranging from 50 endpoints to 5,000.
