Signed By A Stranger: Why A Valid Code Signature Tells Your SOC Very Little

A new remote access tool found last week carries a hidden desktop, a browser stealer that gets Chrome to decrypt its own protected cookies, and a valid code-signing certificate. The certificate was issued to an individual about a week before the malware was signed. Windows would show a verified publisher, and many security tools would give the file a little extra trust because of it. That is the problem: in 2026 a valid signature tells you very little about whether software is safe.

What was found

Rogue Authority's analysis, published on 6 November and reported by GBHackers on 9 November, describes "Abe Office workstation helper", an agent called AbeAgent.exe. It presents itself as office software. In practice it copies itself into the user's profile and removes the Mark of the Web. It persists through a Run key and a scheduled task, and opens a hidden desktop that the operator can drive without the user seeing anything. Its browser module copies Chrome and Edge profiles and starts an off-screen browser with remote debugging enabled. It then injects a helper into the browser so that the browser decrypts its own protected cookie keys.

The main executable and its browser module were both signed. The certificate became valid on 26 October and the agent was signed on 4 November. The researchers saw an operator browse to password pages from a test machine. Delivery and attribution are still unknown.

Signed malware is routine now

This isn't an outlier. In the past month we've written about a genuine signed installer abused from a hostile folder, a signed installer used to sideload a fake AI app, and stolen intermediate CA keys that could sign anything. There are three common ways to get a signature onto malware:

• Buy a certificate in someone's name. Individual and small-business validation is a paperwork check. Stolen or rented identities can get through it.
• Borrow a genuine signed binary. Place a malicious DLL beside a legitimately signed program and let the program load it. The signed file is genuine. What it loads isn't. Our DLL sideloading explainer covers how.
• Steal the signing key. Rarer but more damaging, because the signature then belongs to a vendor you already trust.

Revocation catches up eventually. By then the campaign has usually run its course.

What a signature does and doesn't tell you

A code signature proves two things: the file hasn't changed since it was signed, and a certificate authority issued the certificate to someone. It doesn't tell you that the someone is who they claim to be in any meaningful sense, that they're trustworthy, or that the software does what it says. It is a tamper seal, not a reference.

The risk comes from treating it as a reference. Allow-lists that trust any signed file, application control rules that trust "any valid publisher", and analysts who downgrade an alert because the binary is signed are all in that position. Attackers know this, and that's why they pay for certificates.

Triage on behaviour, then ask who signed it

Our view is that a signature should change how fast you investigate, not whether you do. In practice:

1. Behaviour first. A process that removes Mark of the Web, starts a browser at off-screen coordinates with remote debugging, reads Login Data and Cookies from a browser profile, or creates a hidden desktop is suspicious whoever signed it. Those behaviours are what Abe Office gives away, and Defender for Endpoint telemetry can show most of them.
2. "Signed by whom?" is a triage question. A file signed by a large, established software vendor is a different case from one signed by an individual whose certificate is two weeks old. Signer name, certificate age and how widespread the file is in your estate are all quick to check and say far more than "signed: yes".
3. Application control should trust specific publishers, not signatures in general. App Control for Business and AppLocker can allow named publishers and products. A policy that trusts anything signed wouldn't have stopped this agent.
4. Prevalence is a signal. Business software that appears on one machine, signed by a certificate nobody else in your estate has ever seen, is worth a look.

Why this one matters for Microsoft 365

The browser stealer is the important part. Cookies decrypted from a user's own browser include sessions for Microsoft 365, and an attacker who replays a session from the victim's own machine, through that hidden desktop, looks to Entra ID like the user carrying on with their day. Location checks and impossible-travel alerts don't fire, because the traffic comes from the user's real device and network. That is why the endpoint is where this gets caught, and why endpoint and identity alerts need to be read together. If your SOC sees one without the other, it is missing half the story. Our explainers on infostealers and session hijacking go further.

The takeaway

Keep checking signatures. They're a useful fact. Stop treating them as a verdict. Build detections around what software does, make "who signed this, and when?" part of every triage, and tighten application control from "anything signed" to "these publishers". Wizard Cyber's SOCs are staffed 24/7, and on the managed service a senior analyst signs off investigations by default. A signed binary still gets investigated.

Want to know how much your controls trust a signature? Talk to our team.