Trust is the problem, not the solution. That paradox sits at the heart of a recent operation Microsoft dismantled: a service that weaponised the company's own code-signing infrastructure to distribute ransomware and other malicious code across thousands of machines. The threat actor, tracked as Fox Tempest, had figured out how to turn a system designed to prove legitimacy into a vector for delivering undetectable malware.
The Signing Problem
Code signing exists to answer a simple question: "Is this software genuine?" When a binary arrives with a valid signature from a known publisher, operating systems and security tools relax their guards. The signature proves the code came from someone trustworthy and hasn't been tampered with in transit. For most users and operators, a valid signature is permission to execute.
The catch is that signing itself must be protected. If an attacker gains access to signing credentials or a signing service, they can wrap malicious code in all the trappings of legitimacy. Microsoft's disruption of Fox Tempest's operation revealed exactly this scenario: an MSaaS (malware-signing-as-a-service) offering that let customers sign their ransomware, rootkits, and other payloads with credentials trusted by major operating systems.
The implications for network defenders are uncomfortable. A signed binary looks safe. Endpoint detection systems often allow signed code more latitude. Code that arrives on a vulnerable machine already wearing a legitimate signature can execute with fewer barriers. The attacker has essentially purchased insurance against being stopped.
Why This Matters for Infrastructure Operators
Infrastructure operators—those managing servers, VPS instances, or dedicated hardware—face a particular risk. Ransomware that can masquerade as legitimate code is harder to spot with traditional file-integrity monitoring. A signed payload might slip past behavioural detections that flag suspicious activity from unsigned executables. In environments where automation is common, a signed binary might even pass through deployment pipelines.
The scale Fox Tempest achieved suggests the service was accessible and affordable. Thousands of compromised machines indicates not a sophisticated, targeted operation but a self-service offering. Operators should assume this or similar services may still exist elsewhere. The question for anyone managing infrastructure is not whether signed malware will appear, but when.
Hardening against this threat requires thinking beyond signature verification. Monitor what signed code actually does, not just that it carries a valid signature. Watch for unusual process behaviour even from signed executables. Limit which accounts can execute code at all, signed or otherwise. Keep binaries on the system to an explicit whitelist rather than relying on signatures as the primary control.
The Broader Attack-Infrastructure Ecosystem
Fox Tempest's MSaaS offering is one node in a larger economy of crime-enabling services. Other operations sell access to infected networks, stolen credentials, zero-day exploits, and evasion tools. Code signing as a service is just another product in that catalogue. It works because trust is valuable, and trust can be commodified.
The fact that Microsoft could identify and disrupt this particular operation is encouraging. It suggests visibility into these ecosystems and the ability to act. But each disruption is a data point on a curve; others will emerge. The barrier to entry for someone wanting to offer signing-as-a-service is not high if they have access to credentials or infrastructure that can issue signatures.
Defenders should treat signed code with proportional suspicion. Signing is a control, not a guarantee. Verify what you can independently—does the binary match known hashes, does it come from the official source, does its behaviour make sense for what it claims to do—and don't let a signature short-circuit that analysis.
What to Watch
In the wake of this disruption, monitor your systems for any signed executables that behave oddly or connect to unexpected destinations. Check your endpoint-protection logs for signed files triggering detections; that's often where signed malware reveals itself. Review deployment pipelines to ensure signed binaries still go through behaviour-based scanning before they run.
The Fox Tempest case also underscores the value of keeping operating systems and security tooling up to date. Microsoft will have revoked the abused signing certificates, which means systems with current threat intelligence can now reject code signed with those credentials. If your infrastructure is running older tools that don't check revocation lists, you're at higher risk.
Trust, once undermined, is slow to rebuild. The work of disrupting services like Fox Tempest's is important, but it's defensive—a game of whack-a-mole. The structural problem—that signing infrastructure can be abused—remains. Until it becomes prohibitively expensive or risky to operate such services, they will exist. Operators must assume that and design their defences accordingly.
