Fox Tempest Takedown: Analyzing the MSaaS Artifact Abuse
Has everyone caught the news on Microsoft's disruption of the Fox Tempest operation? They were running a literal 'Malware-Signing-as-a-Service' (MSaaS) racket by abusing the Microsoft Artifact Signing system. It’s chilling to think about how many networks were compromised simply because the malware carried a trusted signature.
The core issue here is the blind trust we place in code signing certificates. When the signing pipeline itself is weaponized, standard allow-listing practices crumble. We need to shift from trusting the signature to verifying the behavior.
I’ve started hunting for anomalies where signed binaries are executing from suspicious user-writable paths. Here is a KQL query I’m running in Sentinel to flag potential artifacts masquerading as legit updates:
DeviceProcessEvents
| where Timestamp > ago(3d)
| where isnotempty(Signer) and SignatureState == "Valid"
| where FolderPath contains "Users" or FolderPath contains "Temp"
| extend SigDetail = tostring(Signer)
| where SigDetail !contains "Microsoft Corporation" // Adjust based on your allow-list
| project Timestamp, DeviceName, FileName, FolderPath, SHA256, SigDetail
This isn't just a patch management problem; it's a supply chain identity crisis. How is your team handling the fallout? Are you planning to restrict execution paths for signed binaries, or just relying on Microsoft’s revocation list?
This is exactly why I advocate for 'Zero Trust' even for internal signatures. We saw a similar spike with signed tools being dropped in AppData last year. We've started enforcing stricter AppLocker rules so that even if a binary is signed by a trusted CA, it won't run if it's not in the Program Files or Windows directories. It breaks some dev workflows, but it stops this cold.
Solid query. I'd add a filter for process lineage. In the Fox Tempest cases we analyzed, the signed artifacts were often spawned by scripting hosts like powershell.exe or mshta.exe with parent processes that didn't match the usual update agents.
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} | Where-Object {$_.Message -match 'Signed=True' -and $_.Message -match 'CommandLine.*.exe.*C:\\Users\\'}
This Sysmon one-liner helps us catch the execution context faster than Defender logs sometimes.
Does anyone have the list of specific Subject CNs or serial numbers for the certs that Fox Tempest managed to compromise? We want to block them at the firewall level via IPS, but Microsoft's advisory was a bit vague on the specific certificate fingerprints that are now considered untrusted.
While blocking specific C/SNs helps, in OT environments we rely on strict versioning. The danger of Fox Tempest isn't just the cert, but the unusual path execution. A valid Microsoft cert shouldn't be running from a user's temp folder.
You can hunt for these anomalies in Defender using this KQL query to find signed executables outside trusted directories:
DeviceProcessEvents
| where IsSigned == true
| where FolderPath !contains @"C:\Program Files" and FolderPath !contains @"C:\Windows" and FolderPath !contains @"C:\ProgramData"
| project Timestamp, DeviceName, FileName, FolderPath, SHA256
This helps catch the valid-but-malicious artifacts regardless of the specific Subject CN.
Excellent discussion. While signature revocation is necessary, it’s often reactive. To catch these instantly, we rely heavily on Attack Surface Reduction (ASR) rules. Even if the artifact is signed, blocking Office from creating child processes stops the execution chain that Fox Tempest leverages for delivery.
You can audit your current rule set via PowerShell:
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
Great insights. Beyond the signature validation, we should monitor where these signed artifacts land. Valid system tools rarely execute from a user's Downloads or AppData. I run this KQL hunt weekly to flag anomalies that might bypass static allow-lists.
DeviceProcessEvents
| where FolderPath startswith @"C:\Users\" and IsSigned == true
| where InitiatingProcessFileName !in ("explorer.exe", "cmd.exe")
| summarize count() by DeviceName, FileName
Building on the need for behavioral analysis, we can't just rely on static revocation lists. We need to hunt for the 'trusted but unusual' execution patterns. Here is a KQL query we use to hunt for signed binaries running from user-writable directories, which effectively catches the abuse mentioned by Ivan and Alex:
DeviceProcessEvents
| where FolderPath has_any (@'AppData', @'Temp', @'Downloads')
| where SignerStatus =~ 'Valid' and IsCertValid == true
| project Timestamp, DeviceName, FileName, FolderPath, SignerSubject
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access