Exposing Fox Tempest: How a Malware‑Signing‑as‑a‑Service Fueled Ransomware Campaigns

Microsoft’s Digital Crimes Unit dismantled Fox Tempest’s malware‑signing service, which used short‑lived Microsoft Artifact Signing certificates to make ransomware appear legitimate. The operation leveraged hundreds of Azure tenants, custom VMs on Cloudzy, and a paid portal to deliver signed binaries to ransomware affiliates. This analysis explains the service architecture, the financial model, the downstream impact on ransomware families, and practical mitigation steps for defenders.

What changed – the takedown of Fox Tempest’s signing service

In May 2026 the Microsoft Digital Crimes Unit (DCU), assisted by Resecurity, seized the infrastructure behind signspace.cloud, the front‑end for Fox Tempest’s Malware‑Signing‑as‑a‑Service (MSaaS). The disruption targeted three layers:

The public web portal used for credential collection and payment.
The Azure‑based Artifact Signing accounts that issued 72‑hour code‑signing certificates.
The Cloudzy‑hosted virtual machines (VMs) that customers used to upload malicious binaries for signing. By revoking more than a thousand fraudulent certificates and shutting down the VMs, Microsoft removed the primary conduit that allowed ransomware affiliates to distribute trusted binaries at scale.

Provider comparison – why Microsoft’s Artifact Signing became the attacker’s weak point

Feature	Microsoft Artifact Signing (Azure Trusted Signing)	Traditional commercial CAs (e.g., DigiCert, Sectigo)
Certificate lifespan	72 hours (short‑lived) – designed for CI/CD pipelines	1‑3 years – long‑term validity
Identity verification	Requires Azure AD‑linked verifiable credentials; MFA enforced	Manual KYC, often via phone or email verification
Automation support	API‑first, integrates with CI pipelines, can be scripted	API available but often gated behind manual approval
Cost model	Pay‑per‑certificate, low per‑cert cost	Annual subscription, higher per‑cert price
Revocation speed	Immediate via Azure portal or API	Typically 24‑48 hours after request

Fox Tempest exploited the short‑lived nature of Artifact Signing certificates: a 72‑hour window is enough to sign a payload, deliver it, and expire before many security products could flag the certificate as suspicious. The attacker bypassed the rigorous identity checks by reusing stolen U.S. and Canadian identities, a tactic that would be far harder with traditional CAs that demand more extensive documentation.

How the MSaaS operated – a step‑by‑step model

On‑boarding – Threat actors filled a bilingual Google Form (English/Russian) selecting a pricing tier ($5 k, $7.5 k, $9 k). Payment triggered an entry into a queue and a Telegram channel invitation.
Access provision – After payment, the actor received credentials for a pre‑configured VM on Cloudzy (US‑based VPS). The VM contained a small file set:
- metadata.json – points to the Azure signing endpoint and certificate profile.
- test.js – a signed sample binary used for demonstration.
- PS code sample.txt – PowerShell script that invokes the Artifact Signing API.
File upload – The attacker uploaded malicious binaries (e.g., trojanized Microsoft Teams installers) via the VM’s shared folder.
Certificate request – The PowerShell script called the Azure API, presenting the stolen identity’s verifiable credentials and receiving a 72‑hour code‑signing certificate.
Signing – The binary was signed, the certificate attached, and the signed file returned to the attacker via the VM’s download folder.
Distribution – Signed binaries were then delivered through malvertising, SEO poisoning, or compromised ad networks, allowing ransomware families such as Vanilla Tempest, Storm‑2561, and Rhysida to bypass many endpoint detections.

Business impact – why the service mattered to cyber‑crime economics

Revenue stream – With pricing up to $9 k per signing batch, Fox Tempest generated multi‑million‑dollar earnings, financing infrastructure, stolen‑identity procurement, and operational staff.
Scale – Over a thousand certificates and hundreds of Azure tenants were created, indicating a semi‑automated pipeline rather than a boutique operation.
Downstream damage – The signed payloads enabled ransomware attacks on healthcare, education, government, and financial sectors across the U.S., Europe, and Asia. In several incidents, the initial infection vector was a fake Microsoft Teams installer that appeared legitimate to both users and security tools.
Ecosystem effect – By providing a turnkey signing service, Fox Tempest lowered the technical barrier for low‑skill affiliates, expanding the ransomware talent pool and accelerating the frequency of attacks.

Mitigation recommendations – what defenders should do now

Monitor short‑lived certificate usage – Enable alerts for code‑signing certificates with lifespans under 7 days in Azure Sentinel or Microsoft Defender for Cloud.
Enforce strict Azure AD conditional access – Require MFA and device compliance for any account that can request Artifact Signing certificates.
Block known malicious domains – Add signspace.cloud and associated IP ranges to web‑proxy block lists.
Deploy tamper‑protection and ASR rules – Turn on tenant‑wide tamper protection and the following Attack Surface Reduction rules:
- Block executable content from email and web clients
- Require signed binaries for PowerShell scripts
Leverage Microsoft Defender XDR detections – Enable detections for the listed IOCs (e.g., SHA‑256 hashes 11af4566…, f0a6b89e…). The Defender for Endpoint detections such as Trojan:Win64/OysterLoader and Ransom:Win64/Rhysida already map to the observed payloads.
Educate users on signed‑binary deception – Emphasize that a valid signature does not guarantee safety, especially for binaries downloaded from unofficial sources.

Indicators of compromise (IOCs)

Type	Value	First seen	Last seen
Domain	`signspace.cloud`	2025‑05‑29	2026‑05‑05
Certificate SHA‑1	`dc0acb01e3086ea8a9cb144a5f97810d291020ce`	2026‑03‑18	2026‑05‑11
Certificate SHA‑1	`7e6d9dac619c04ae1b3c8c0906123e752ed66d63`	2026‑03‑21	2026‑05‑11
File SHA‑256	`11af4566539ad3224e968194c7a9ad7b596460d8f6e423fc62d1ea5fc0724326`	2026‑03‑19	2026‑05‑04
File SHA‑256	`f0a6b89ec7eee83274cd484cea526b970a3ef28038799b0a5774bb33c5793b55`	2026‑03‑12	2026‑04‑19

Looking ahead – lessons for cloud‑native security strategy

The Fox Tempest case demonstrates that trusted‑cloud signing services can be weaponized when attackers acquire legitimate identities. Organizations should treat code‑signing certificates as privileged assets, apply the same lifecycle management and monitoring as for privileged credentials, and incorporate short‑lived certificate telemetry into their SIEM. By coupling Azure policy controls with Defender XDR detections, enterprises can reduce the attack surface that a service like MSaaS otherwise creates.

For deeper technical details, see the Microsoft Threat Intelligence blog and the associated GitHub repository code-signing-service referenced in the original investigation.