Autoruns 14.3: When Signed Launchers Hide Unsigned Targets

We've relied on Autoruns during incident response for years. It can return a mountain of data, and target resolution and Authenticode verification have been useful ways to make that data manageable. When a signed Windows executable loads a DLL or script, we want Autoruns to inspect the file being loaded. That distinction helps us reduce the noise without losing the thing we need to investigate.

That's why this change concerns us. A workflow that previously filtered out trusted files can now filter out unsigned targets because Autorunsc reports their signed launchers instead. The commands are still present in unfiltered output, but the filtering techniques we've relied on can turn that change into a critical blind spot.

We ran into this while reviewing the persistence lab in Threat Hunting & Incident Response with Velociraptor (THVR), the DDI course taught by Whitney Champion and Eric Capuano. A scheduled task we expected to find was no longer showing up after filtering. The task was still there. The DLL it loaded was still named in the command line. But the usual query had removed the row.

The task used rundll32 to load a DLL from a user's Temp directory. Older Autoruns output identified the DLL and left the Signer field empty. The newer output identified Microsoft's signed rundll32.exe instead.

We compared versions and expanded the testing. The results went beyond that one scheduled task.

In our tests, Autorunsc 14.3 stopped following several Windows launchers to their script targets. With Microsoft entries hidden, the affected rows disappeared entirely.

We're referring specifically to Autorunsc, the command-line version of Autoruns. That's what Velociraptor's Windows.Sysinternals.Autoruns artifact runs. We haven't tested the GUI, so don't read this as a claim about every Autoruns interface or every Windows version.

Which file is Autorunsc actually inspecting? #

Take a command like this:

rundll32.exe "C:\Users\user\AppData\Local\Temp\updatelib.dll",StartW

There are two files that matter: the Windows executable doing the loading, and the DLL being loaded.

Microsoft documents that Autoruns can follow hosting processes such as rundll32.exe to their target files. That's useful! If the DLL is the interesting part of the persistence mechanism, its path, signature and hash are what we want to inspect. Microsoft Press

But the signature and hash fields describe the file Autoruns selected as Image Path. If Image Path is rundll32.exe, the signature and hashes belong to rundll32.exe.

A verified Microsoft signature on that executable tells us nothing about the DLL in its arguments. The same applies to a PowerShell executable launching a .ps1 file.

This distinction matters even before filtering. You could send the hash to VirusTotal and get a perfectly reasonable answer about the Windows launcher, while the file you meant to investigate never gets queried.

How this showed up in the lab #

Our lab includes a scheduled task named MSEdge Update Check, which uses rundll32 to load updatelib.dll from AppData\Local\Temp. The older results exposed that DLL directly. The 14.3 results exposed the signed launcher.

There was a second problem, too. A suspicious service named MSUpdate still pointed to C:\Windows\Services\svchost.exe, but its Signer field had changed from empty to:

(Not verified) (Not Verified)

Our notebook used this predicate:

AND NOT Signer

That checks whether the field is empty. It doesn't check whether a signature was successfully verified. The service now had a nonempty value, so the query removed it. The task had a verified value for its launcher, so the query removed that too.

Two interesting persistence entries, gone for two different reasons.

Whitney Champion first reproduced the version difference in a disposable Windows VM. We then expanded the comparison to find the boundaries and see whether other hosting processes were affected.

Testing the same entries with both versions #

We used a disposable Windows Server 2022 VM in GCP and ran the scans as SYSTEM. The final matrix contained 102 configurations: 71 scheduled tasks and 31 HKLM Run values.

The targets were harmless files: an unsigned native DLL with inert Start and StartW exports, plus PowerShell, VBScript, batch and HTA files. The tasks had no triggers and weren't started. All 71 task records confirmed they had never run.

We collected with:

autorunsc64.exe -nobanner -accepteula -t -a tl -s -c -h *

Here, tl selects Scheduled Tasks and Logon entries. We also compared scans without signature verification, with -m to hide Microsoft entries, and with the 32-bit executable.

The current Microsoft download on October 13, 2026 was version 14.3. We compared it with archived 14.2, verified the binaries' signatures, and recorded their SHA-256 hashes. The current 14.3 binary was byte-identical to the archived 14.3 binary from June.

These were direct Autorunsc scans. Velociraptor's notebook or CSV import couldn't explain the differences.

The rundll32 trigger is more specific than it first looked #

With a scheduled task whose Command was just rundll32.exe, and no WorkingDirectory set, the versions selected different files:

Stored Command:   rundll32.exe
Stored Arguments: "C:\AutorunsRepro\targets\fixture.dll",StartW
WorkingDirectory: absent

14.2 Image Path:   c:\autorunsrepro\targets\fixture.dll
14.2 Signer:       <empty>

14.3 Image Path:   C:\Windows\system32\rundll32.exe
14.3 Signer:       (Verified) Microsoft Windows

An absolute launcher path, such as C:\Windows\System32\rundll32.exe, resolved the simple DLL target correctly in both versions. So did the %windir% and %SystemRoot% forms in scheduled tasks.

Here's the surprising part: setting the task's WorkingDirectory also restored DLL resolution for the bare launcher in 14.3. All five nonempty values we tested did this, including directories that didn't contain rundll32.exe.

Setting WorkingDirectory to C:\AutorunsRepro, for example, caused 14.3 to display:

C:\AutorunsRepro\rundll32.exe "C:\AutorunsRepro\targets\fixture.dll",StartW

There was no rundll32.exe at that location, yet Autorunsc selected and hashed the DLL correctly. That points toward a command/path interpretation problem. We haven't reverse-engineered the internal code, so we can't name the exact function responsible.

Changing the DLL quoting, the export name, or the case of RUNDLL32.EXE didn't fix the bare-command/absent-WorkingDirectory case.

It also affects script launchers #

The expanded testing is where this became more concerning.

For example, a scheduled task with the following absolute Command and Arguments resolved to fixture.ps1 in 14.2:

Command:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Arguments:
-NoProfile -File "C:\AutorunsRepro\targets\fixture.ps1"

In 14.3, Image Path became the signed PowerShell executable. The same thing happened with conventional WScript, CScript, MSHTA and cmd.exe /c file-launch forms.

We reproduced those differences in both scheduled tasks and Run keys. Full launcher paths didn't repair them. Task WorkingDirectory didn't repair them either. Removing //B from the VBScript launchers or -NoProfile from PowerShell also didn't repair them.

These aren't all the same rundll32 edge case. The broader script-target behavior needs attention on its own.

Did it inspect the targets and just report them wrong? #

We used Process Monitor to check that question.

During the 14.2 scan, Autorunsc opened and read the PowerShell, VBScript, batch and HTA target files. During the 14.3 scan, we recorded zero accesses to those four script files. It still read the DLL controls, so file activity from the scanner was being captured.

That supports a failure to follow and inspect the script targets, rather than merely displaying the wrong signer after inspecting them.

The normal and traced scans produced matching target-selection results. We also matched the events' process IDs to the scanner executions.

Paths with spaces add another failure mode #

An absolute rundll32 launcher didn't solve every task case. With these arguments:

"C:\AutorunsRepro\targets with spaces\fixture.dll",StartW

14.2 selected the existing DLL. 14.3 reported:

File not found: with.exe

The corresponding Run-key entries resolved the DLL correctly in 14.3. Entry type matters.

Run keys also had their own environment-variable issue: %windir% and %SystemRoot% rundll32 forms selected the DLL in 14.2 and the launcher in 14.3. We checked both REG_SZ and REG_EXPAND_SZ, with the same version difference.

What this means for an investigation #

Unfiltered 14.3 output retained all 102 configured entries and their Launch Strings. The bigger visibility problem appeared when we added -m, which hides Microsoft entries. Rows associated with signed Microsoft launchers were removed, taking their target references with them.

Across the deliberately varied matrix, 59 unsigned-target cases were omitted by that filter after 14.3 selected their launchers. That number includes diagnostic configurations; it isn't a claim about how often this happens on real systems.

If your workflow filters verified entries, or enriches the row's hash without checking which file it belongs to, this can affect your investigation.

Here's what we recommend for now:

1. Keep an unfiltered collection. Apply noise reduction to a view of the results so you can revisit entries that a filter removed.
2. Read Image Path and Launch String together. If a host executable is launching a script or DLL, investigate that target separately.
3. Hash and verify the target file itself. A row's launcher hash won't answer questions about its payload. Use endpoint collection for endpoint files; don't try to hash a client's path on your analysis server.
4. Review signer predicates. “Not verified” is a nonempty value. Fixing an emptiness check is necessary, but it won't recover targets that have been assigned their launcher's verified status.
5. Test tool updates against examples you understand. Keep a few harmless persistence examples with known target paths and hashes, and verify which files the new version selects.

For a first look at a Velociraptor Autoruns collection, this keeps every enabled row and the fields needed to check the association:

SELECT Entry, Category, Signer,
       `Image Path`, `Launch String`, `SHA-256`
FROM source()
WHERE Enabled = "enabled"

It will be noisy. That's fine for preserving the evidence before deciding what to filter.

What we haven't established #

This comparison covers Autorunsc on one Windows Server build, under SYSTEM, for Scheduled Tasks and HKLM Run values. It doesn't establish the behavior of the Autoruns GUI, offline scanning, every persistence category, or every Windows release.

We also included negative controls and found some limitations that already existed in 14.2. We're not treating every unusual result as a new regression, and we haven't demonstrated successful execution of every diagnostic command form.

The narrow conclusion is well supported: for these unchanged entries, 14.3 inspects different files than 14.2, and Microsoft-based filtering can hide references to unsigned targets.

We've updated the live THVR lab to account for these results. The collection and filtering guidance above keeps the affected entries discoverable and explains which file each signature and hash describes. The next step is to report the separate minimal reproductions to Sysinternals. At the time of writing, we had not submitted that vendor report yet.

In the meantime, take a look at your collection and filtering pipeline. Before you clear an entry because its launcher is signed, check what it's launching.

If you want hands-on practice with this kind of investigation, THVR includes the persistence lab that led us here.

Happy hunting.

References #

• Microsoft Autoruns documentation
• Microsoft's explanation of Image Path and hosting processes
• Autoruns 14.3 release announcement