Microsoft Artifact Signing Abuse: The MSaaS Takedown and Trust Failures
Big news dropping today regarding Microsoft disrupting that 'Malware-Signing-as-a-Service' (MSaaS) operation run by Fox Tempest. It’s wild to see them weaponizing the Microsoft Artifact Signing system to deliver ransomware. The idea that they commercialized this as a service to bypass trust controls is concerning, especially given the number of global networks compromised.
This really highlights a massive blind spot in our defense-in-depth strategies. We often treat 'Signed by Microsoft' or a valid CA as a 'Get Out of Jail Free' card for executables. If the threat actor can sit in the middle of that trust chain, our signature validation effectively becomes useless.
For those hunting in your environments, I wouldn't just rely on the fact that a binary is signed. You might want to start hunting for anomalies in what is being signed and where it's running from. Here is a KQL query I’m using to flag signed binaries executing from suspicious paths (like user temp folders) which usually shouldn't host signed system tools:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where isnotempty(Signer)
| where FolderPath has @"\Temp\" or FolderPath has @"\Downloads\"
| where Signer !contains "Microsoft Corporation"
| project Timestamp, DeviceName, FileName, Signer, SHA256, InitiatingProcessFileName
| order by Timestamp desc
Has anyone else started implementing stricter certificate pinning or allow-listing for signers? Or is the operational overhead too high for most SOC teams?
Solid query. We actually caught something similar last month using a Sigma rule looking for 'Double-Extension' executables that were actually signed. The signature was valid, but the file naming convention (report.pdf.exe) was the dead giveaway.
The operational overhead of managing an explicit allow-list for signers is brutal, but it's becoming necessary. We've moved to a 'trust but verify' model where even signed binaries get sandboxed if they aren't on our known-good list.
From a sysadmin perspective, this is exactly why I pushed for WDAC (Windows Defender Application Control) across our fleet. Standard AppLocker isn't enough anymore because it relies too heavily on the Publisher rule.
With WDAC, we're scanning the specific hash and version. Even if Fox Tempest signs the malware, if the hash isn't in the policy, it doesn't run. It's a pain to set up initially, but it stops this specific attack vector dead in its tracks.
This 'Malware-Signing-as-a-Service' trend was inevitable. As soon as code signing became a primary heuristic for AV/EDR trust, criminals started finding ways to buy or steal that trust.
It reminds me of the Stewart/Fujack incidents years ago, but commercialized. The scary part isn't just the ransomware; it's the persistence mechanisms these signed binaries likely used. If you restore a backup but don't check the validity of the signed certificate chain on the restored tools, you're just re-infecting yourself.
That last point about buying trust hits home. On the red team side, we've seen that simply blocking unsigned code isn't sufficient. You have to validate the specific certificate thumbprint, not just the issuer. I recommend auditing your environment for unexpected Microsoft-signed binaries. You can use this quick PowerShell snippet to pull the signer's serial number for verification:
Get-AuthenticodeSignature "C:\Path\To\File.exe" | Select-Object SignerCertificate, Status
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access