What Autoruns’ (verified) Column Actually Means (And Why It’s Not Good News)

There’s a specific moment in an incident where somebody pastes an Autoruns screenshot into a ticket or a chat window and everyone collectively relaxes a little.

There’s a green tag. <verified>. Microsoft Corporation. It must be fine.

That moment is where I think Autoruns gets misread more than any other tool output in Windows, and the misreading is understandable: the column is right there, it’s colored, it looks authoritative, and the failures in both directions are both common.

Here’s the actual claim the column makes. It is much narrower than it appears.

What “(verified)” checks

Underneath, Autoruns is doing Authenticode validation via WinVerifyTrust with WINTRUST_ACTION_GENERIC_VERIFY_V2. That walks the PKI chain: the file carries a PKCS#7 signature over its image hash, the signing certificate chains to a root in the machine’s trusted store, and if there’s a countersignature timestamp, the certificate is judged valid as of the moment of signing rather than as of right now.

All of that is real, and it is genuinely useful. What it establishes is:

A file matching this hash was signed by a key whose certificate chains to a trusted root, at a time when that certificate was valid.

Now read that again. It is a statement about identity, not about behavior.

It says nothing about what the code does. A file can be authentically signed by the legitimate owner of that key and still be malware, which is exactly what happens when a vendor gets compromised. It says nothing about whether the signing was voluntary by the certificate holder. And it says nothing at all about the publisher name shown next to it.

That last one deserves its own section, but first: three cases that make this concrete, and the third one is the worst.

Case one: Microsoft’s own signing service, used for ransomware

In 2025, Microsoft Threat Intelligence disrupted a Rhysida ransomware campaign that used fake Teams binaries to deliver its payload. Those binaries were signed with digital certificates, including a large number issued by Azure’s Trusted Signing service. Microsoft revoked more than 200 of them.

Read that again. Not stolen keys from a 2012 breach. Not a phishing expedition for someone’s HSM. Certificates that Microsoft’s own cloud signing service issued, apparently validly, and that malware used to look like Microsoft software to every trust check on the machine.

Threat researchers at Expel tracked this as “OysterLoader” and noted the same actors using their own certificates to sign their own malicious files, not impersonating anyone, just signing malware with a certificate they’d legitimately obtained.

Trusted Signing exists because the old model of shipping a hardware token to a signing ceremony was slow and expensive. It also removed the physical barrier that used to make code-signing keys genuinely hard to steal. Whether that trade was correct is above my pay grade. It’s certainly not free.

Case two: the CA itself got breached

In 2026, DigiCert announced that certificates had been fraudulently obtained from its internal support portal after an attack. The intrusion started when a threat actor reached the support team with a malicious payload delivered through a customer chat channel, disguised as a screenshot.

So this one didn’t require stealing a key, compromising a build server, or phishring a developer. It required convincing a support agent to run an installer.

That’s worth sitting with. The code-signing PKI has a support-desk-shaped soft spot, and it’s not theoretical: it’s a CA that signs a very large fraction of the world’s code, and a social-engineering pretext of “screenshot” got in.

Case three: a completely legitimate signature on a malicious file

In late 2023, Microsoft detailed Diamond Sleet (also tracked as ZINC), a North Korean supply chain operation. What they compromised was a legitimate vendor: CyberLink Corp. The malicious file was a genuine CyberLink application installer, modified to include code that downloaded, decrypted, and loaded a second stage. It was signed with a valid CyberLink certificate.

Every trust signal on that machine fires green:

Valid signature ✓
Trusted certificate chain ✓
Real, correctly-issued vendor certificate ✓
Legitimate installer format ✓
Correct publisher name ✓

There is no signature check on earth that catches this. The vendor did produce that file, with that key, in a way that verifies. The attacker inserted themselves earlier in the pipeline and the signature did its job perfectly, which was never its job.

That’s the structural limit of the whole model. Authenticode answers “was this bitstream signed by this key,” and a supply-chain compromise means the bitstream was signed by the real key while containing something the signer never intended to ship.

This is not new. Stuxnet signed its kernel components with certificates stolen from real vendors. Flame went further: it needed an actual MD5 collision attack to forge a certificate that would validate on modern Windows, and Microsoft published a detailed explanation of why that was necessary and what it implied.

The researchers who tried to put a number on this published “Certified Malware: Measuring Breaches of Trust in the Windows Code-Signing PKI” at ACM CCS, precisely because the individual incidents were famous but the systemic rate wasn’t understood.

The publisher name is not part of the signature

One more thing, and this is the one that catches people out.

The signature covers the file’s image hash and the certificate chain. It does not cover the meaning of the strings in the file. A PE file’s version resource (the CompanyName, ProductName, FileDescription blob you see in Properties → Details) is plain, freely writable text in the resource section.

Anyone can write CompanyName = "Microsoft Corporation" into a file they built. Nobody signs those bytes, because there’s nothing to sign about their meaning. The signature is over the whole image as a blob; it guarantees the bytes weren’t altered after signing, not that the strings inside mean what they appear to.

Autoruns displays a publisher name whether or not verification succeeded, and that name can come from the certificate subject or from the version resource depending on the path. Either way, the name is not an assertion the signature makes.

The name is a hint about where to start looking. It is not evidence.

Now the part that’s genuinely useful

I want to be clear that I’m not arguing Autoruns is bad. It’s a Sysinternals tool from Mark Russinovich’s team, and for “show me every autostart location on this box in four seconds” it’s unmatched. The right mental model is narrower and more useful than “green means safe.”

The column is a filter, not a verdict. It’s a way to sort a large list cheaply, and sorting is exactly what it’s for.

A workflow that survives contact:

Don’t start at the signature column. Start from what the entry does: its location, its registry path, what binary it launches and with what arguments.
Use “(verified)” to eliminate, not to conclude. Unverified is a reason to look closer. Verified is a reason to stop looking at the signature and start looking at the payload.
Pay more attention to unverified Microsoft entries than most people do, but for the boring reason. Microsoft’s own support material and community threads note that it is normal for genuine Microsoft entries to show as unverified, and specifically calls out things like Windows Defender’s shell extension and PLUGScheduler on Windows 10. Not every unsigned thing is an intruder.
Check where the signature actually comes from. Is the chain expected for that publisher? Is the cert recently issued for a company with no software business? Is the signing time suspiciously recent relative to first appearance?
The path matters more than the signature. Persistence in a per-user Run key from a file in %APPDATA% is suspicious no matter who’s on the certificate. Persistence in HKLM\...\CurrentVersion\Services from a file inside a signed vendor directory is a different conversation entirely.
Verify independently. Take the hash to VirusTotal, check the signer’s reputation on a public transparency log, and look at the certificate’s issuance history.

Autoruns has a VirusTotal column that will help here, though it’s worth knowing that the “not signed” results people report from it are frequently a lookup artifact rather than a real finding.

Why I care about this column specifically

The reason this sits in my head more than most security trivia: the signer’s name is doing enormous psychological work in a screenshot. A green tag with a recognized publisher is the kind of evidence that ends an investigation early, and investigations that end early are how bad days turn into bad months.

The failure mode isn’t an admin being fooled by a fake screenshot. It’s an admin seeing something reassuring in a tool built by Microsoft, from Microsoft, and doing less looking than they would otherwise.

The signature is a real signal. It’s evidence about provenance. It is just not evidence about intent, and the gap between those two is where all of the cases above live.

Sources: Microsoft Threat Intelligence on Diamond Sleet / CyberLink; Dark Reading on Rhysida abusing Azure Trusted Signing certificates and Expel on OysterLoader; SecurityWeek on DigiCert’s support portal compromise; Threatpost on NVIDIA’s stolen certs; SecurityWeek on GitHub’s revoked certs; Quorum Cyber on AnyDesk; Microsoft MSRC on the Flame collision attack; the ACM CCS paper on measuring breaches of trust in the code-signing PKI; Microsoft’s Autoruns documentation for its stated purpose and limits.

[Note for Zach: you built a from-scratch Autoruns scan-engine reimplementation in a prior session; it decodes the same entry-type bitfields, and its enrichment path is exactly this: GetFileVersionInfoW/VerQueryValueW for the publisher string plus WinVerifyTrust for the tag. That’s a concrete, verifiable thing to say you can check, if you want to. Don’t claim more than that.]