Code signing was supposed to be the part of cybersecurity you didn’t have to think about.

Microsoft disclosed on May 19 that it disrupted Fox Tempest, a financially motivated operation running malware-signing-as-a-service through abuse of Microsoft’s own Artifact Signing service. Customers included Vanilla Tempest and various Storm-numbered ransomware crews. They paid, Fox Tempest produced fraudulent code-signing certificates, and the resulting binaries sailed past the trust checks that endpoint tooling, browsers, and operating systems treat as authoritative.

That’s the part of the security stack you don’t usually inspect. Now you have to.

The trust chain just got commoditized

Code signing has always had a quiet assumption baked in: that the signer is who the certificate says, and that the signer’s process is hard enough to abuse that bad guys can’t get a clean signature on demand. Both halves of that assumption are softening.

Fox Tempest is not the first signing abuse story, but the productization matters. When you can buy a signature the same way you buy bulletproof hosting, signed binaries stop being a positive indicator and become a neutral one. The signature tells you the file was processed by a signing pipeline. It does not tell you anyone vouched for the contents.

BleepingComputer’s reporting confirmed the same operation abused Microsoft’s Artifact Signing service to mint certificates used by ransomware affiliates. Microsoft yanked the infrastructure. The customers will find another pipeline. That’s how every previous signing-abuse takedown has gone.

And signing is only one of several trust signals quietly being eroded this week.

Signed binaries aren’t a verdict

Cisco Talos disclosed eight TP-Link vulnerabilities, plus one each in Adobe Photoshop, OpenVPN, and Gen Digital’s Norton VPN. All patched. All in software you would have happily executed because the signature checked out and the vendor name is familiar. Photoshop and Norton are the kind of binaries that get allow-listed in EDR for performance reasons, and an OpenVPN client sits in the privileged TUN/TAP path on every machine it runs on.

Drupal announced an upcoming “highly critical” patch with explicit warning that exploit code is expected within hours of release. Drupal core updates ship signed. Your update pipeline trusts them because that’s the model. The signature has nothing to say about whether the patched bug is now being mass-exploited before your maintenance window.

Then there’s PureLogs. Fortinet’s writeup shows the infostealer arriving via a phishing email with a TXZ archive, then unpacking JavaScript that hides encrypted payloads inside cat photos using steganography. Image files are another trust signal: most secure email gateways and SOC analysts treat JPEGs as inert. They’re not, and they haven’t been for a while, but the muscle memory persists.

Three different trust assumptions cracking in the same week. Vendor signature. Vendor reputation. File type. None of them are load-bearing on their own anymore.

Stop treating signatures as a stop sign

The defense in depth answer here is not “distrust everything signed,” because that breaks Windows. It’s to demote signature checks from a verdict to one input among several, and to invest the freed-up trust budget in behavioral controls that don’t care who signed the binary.

Concrete moves your team can make this week:

• Inventory what your environment auto-trusts. Anything in an EDR exclusion list, an AppLocker publisher rule, or a software-restriction policy that keys off a publisher CN. If Fox Tempest’s customers used a stolen Microsoft-adjacent cert, would your allow-list have caught them? Probably not.
• Watch for new publishers, not just unsigned binaries. A binary signed by a CA or publisher your environment has never seen before is the actual interesting event. Most SIEMs can do this with a simple first-seen aggregation on Sysmon EventID 7 or 1.
• Treat fresh patches as exposure windows, not safety windows. Drupal told you the exploit will exist in hours. Stage the patch, but also rank externally exposed Drupal instances for accelerated response and rate-limit or WAF-block known exploit paths during the gap.
• Detonate attachments in their actual nesting. A TXZ holding JavaScript pointing at a JPEG with embedded encrypted shellcode will defeat anti-virus that scans the outer file. Sandboxes need to unwrap each layer and follow the execution.
• Apply egress and identity controls regardless of binary provenance. Signed ransomware still has to talk to a key server. Signed infostealers still have to exfil. Brute-force protection at SSH, RDP, and SMB edges, plus host firewall hardening of the kind tools like IPBan or IPBan Pro handle for Windows servers, sits below the signature-trust layer entirely.

The point: every one of these stops works whether or not the binary on disk looks legitimate.

None of this is exotic. Most of it is security hardening that’s been on the recommended-practices list for a decade and gets pushed to next quarter because more visible problems exist. Fox Tempest is the reason it shouldn’t get pushed again.

Signed code is not a clean bill of health. It is a receipt. The receipt is forgeable, the forgery is now a service, and the service has paying customers.

Sources

• Exposing Fox Tempest: A malware-signing service operation
• Cybercrime service disrupted for abusing Microsoft platform to sign malware
• TP-Link, Photoshop, OpenVPN, Norton VPN vulnerabilities
• Drupal to Patch Highly Critical Vulnerability at Risk of Quick Exploitation
• PureLogs infostealer is stealing credentials worldwide