[DEEP RESEARCH] Verified for Hire: How Fox Tempest Turned Code Signing Into a Criminal Utility

The certificate was real. The identity behind it was fraudulent—and the signing pipeline was rented to other criminals.

Share
[DEEP RESEARCH] Verified for Hire: How Fox Tempest Turned Code Signing Into a Criminal Utility
Your malware has been signed. Please allow 3–5 business minutes for trust to collapse.

AlphaHunt

Stop doomscrolling, start decisioning. We chewed through the muck so your team doesn’t have to. → Subscribe!

Like this? Forward this to a friend!

(Have feedback? Did something resonate with you? Did something annoy you? Just hit reply! :))


How Fox Tempest Turned Code Signing Into a Criminal Utility

Fox Tempest did not steal a signing key or crack code-signing cryptography.

It sold customers the authority to invoke Microsoft’s legitimate signing infrastructure.

Through a portal called SignSpace—and later through preconfigured virtual machines—customers could submit malware and receive digitally signed files. Microsoft’s published material shows access tiers priced from roughly $5,000 to $9,500, with higher-paying customers receiving priority in the queue. ([Microsoft’s text and accompanying figure differ slightly on the exact top-tier prices, so the range is more defensible than a single figure.])

Microsoft tracks the operator as Fox Tempest, also associated with the name SamCodeSign. The company says the service had operated since at least May 2025, created more than 1,000 certificates across hundreds of Azure tenants and subscriptions, and supported malware and ransomware ecosystems including Oyster, Lumma Stealer, Vidar, Rhysida and several Microsoft-tracked threat clusters.

Here is what most people miss:

The cryptography could work exactly as designed while the trust decision surrounding it failed.

That is the story.

A note on the evidence

Many operational details come from Microsoft’s investigation and civil lawsuit.

On May 22, 2026, a federal court issued a preliminary injunction after finding “good cause to believe” that the defendants had created more than 580 fraudulent Microsoft tenants, abused Artifact Signing and distributed certificates through SignSpace and Cloudzy-hosted virtual machines. The defendants had not appeared or responded at that stage. This was a preliminary order, not a final judgment after a contested trial.

That distinction is worth preserving. Good intelligence work separates:

  • What a vendor observed
  • What a court found sufficient for preliminary action
  • What has been finally proven
  • What remains an analytical assessment

The certificate was real

Windows Authenticode signatures are intended to answer two narrow questions:

  1. Which publisher identity authorized this software?
  2. Has the software changed since it was signed?

During verification, Windows checks the digital signature and attempts to build the signer’s certificate chain to a trusted certificate authority. A valid result supports the integrity of the signed content and associates the signing operation with the publisher identity in the certificate.

It does not establish that:

  • The program is harmless.
  • The publisher was honest during enrollment.
  • The signer wrote the software.
  • The file should be allowed under every security policy.
  • Every file signed by that identity belongs to one threat actor.

The CA/Browser Forum draws the boundary clearly: a code-signing certificate identifies the publisher, not a particular piece of software. Its extended-validation guidelines go further, stating that a certificate does not warrant that code is safe, malware-free or trustworthy.

A useful analyst model is to separate five decisions:

LayerQuestion
IntegrityDid the file change after signing?
Signing identityWhich certificate identity authorized the signature?
ReputationWhat history exists for the file, publisher or source?
PolicyDoes this environment permit software matching those attributes?
BehaviorWhat does the program actually do?

Weak analysis compresses all five into one word:

Trusted.

Strong analysis keeps them separate.

When the math works but the identity fails

Artifact Signing is a managed Microsoft service. It handles certificate lifecycle operations inside certified hardware security modules and gives authorized customers a way to request signing operations without exporting the private signing keys.

That design protects legitimate developers from key theft.

It also creates an important distinction for this case:

The attacker does not need to possess the private key.

The attacker needs permission to invoke it.

According to Microsoft and the preliminary injunction, Fox Tempest created fraudulent Azure tenants and worked around identity-validation requirements using fabricated names, false contact details, fake identification, shell companies and impersonated organizations. Microsoft separately assessed that stolen U.S. and Canadian identities were probably used to obtain some of the necessary credentials.

Once the enrollment and authorization process had been defeated, the resulting signing operations could still be cryptographically valid.

The weak read is:

Attackers created fake signatures.

The stronger read is:

Attackers obtained real signing authority through identity fraud, then sold access to it.
Premium members: Below the paywall, we reconstruct Fox Tempest’s signing pipeline—from fraudulent identity to HSM-backed signature—and show how analysts can follow the service beneath rotating certificates without confusing the supplier for its customers.

Fox Tempest sold a pipeline, not a certificate

Fox Tempest’s original SignSpace model looked simple from the customer’s perspective: