The email came from a county government Office of Public Defense. SPF passed. DKIM passed against the county's .gov domain. DMARC passed. Composite authentication returned a perfect 100. The linked document sat on Azure Government blob storage, the FedRAMP-certified cloud infrastructure reserved for U.S. government agencies.
The request was simple: a W-9 form and invoicing instructions for a case file. Signature block included a real name, real phone number, and real office address. Everything about this email was either genuinely legitimate or indistinguishable from it.
That is exactly the problem.
The sender was an office manager at a county Office of Public Defense in the Pacific Northwest. The email address resolved to the county's .gov domain. The DKIM signature validated against the same domain. SPF confirmed the sending IP was authorized. DMARC alignment passed on both checks. The composite authentication score, Microsoft's aggregate trust signal, came back at 100, the highest possible value.
This was not a spoofed .gov domain. This was not a lookalike. The sending infrastructure was the real thing.
The subject line referenced a case file with a docket number: "[Case Party] 035-0053505 [Case Party]." The body asked for a W-9 and invoicing instructions, standard financial paperwork for a government vendor relationship. The signature carried the sender's full name, title, direct phone line, and physical mailing address, all verifiable against public county records.
For a forensics consulting firm that routinely works with government agencies, this email fit squarely within the expected pattern of inbound correspondence.
The linked document pointed to wakitsap[.]blob[.]core[.]usgovcloudapi[.]net, which is Azure Government blob storage. This is not the commercial Azure cloud that anyone with a credit card can provision. Azure Government (usgovcloudapi.net) is a physically isolated cloud environment that requires government agency affiliation or contractor verification to access. It undergoes FedRAMP High and DoD IL4/IL5 compliance audits. Security tools that maintain domain reputation databases generally classify this infrastructure as trusted.
The link included a Shared Access Signature (SAS) token with parameters specifying a storage version (sv=2022-11-02) and an expiration date (se=2026-05-13). SAS tokens are Azure's mechanism for granting time-limited access to specific storage objects without requiring the requester to authenticate to the storage account itself. They are widely used in legitimate government document workflows.
From a scanner's perspective, this link presented three layers of trust. First, the domain belongs to Microsoft's government cloud. Second, the path resolved to a PDF file matching the subject line. Third, the SAS token parameters were well-formed and not yet expired. URL reputation engines have no mechanism to evaluate what is inside a blob storage object behind a SAS token. The link itself is ephemeral, unique to each generation, and hosted on infrastructure that is trusted by design.
This maps to MITRE ATT&CK T1583.006 (Acquire Infrastructure: Web Services). The attacker, whether through a compromised government account or by leveraging government cloud access, positioned the payload on infrastructure that security tools are architecturally predisposed to trust.
See Your Risk: Calculate how many threats your SEG is missing
If this was a compromised .gov account being used to deliver a credential harvesting PDF disguised as a W-9, every technical control in the relay chain did exactly what it was designed to do and still missed it. SPF validated the sending server. DKIM validated the message integrity. DMARC confirmed alignment. The URL pointed to government cloud. The spam confidence level came back at 1.
The detection surface was entirely behavioral.
First-time sender. The county Office of Public Defense had no prior communication history with the recipient organization. For an unsolicited W-9 request, this is a risk signal that authentication cannot evaluate. According to the FBI's 2024 Internet Crime Report, W-9 and tax document fraud is a growing vector within BEC campaigns, with attackers using collected W-9 data for both payment diversion and tax identity fraud.
x-unsent header. The email carried an x-unsent header, which indicates draft-then-send behavior. In a compromised account scenario, this header can appear when an attacker accesses the mailbox, composes a draft (possibly from a template), and sends it in a separate action. Legitimate users occasionally produce this header, but in combination with other signals, it increases the risk profile.
Unverifiable external blob link. The linked PDF was hosted outside the email itself on cloud storage that no reputation engine could evaluate in real time. The SAS token made the link ephemeral: it would expire in May 2026, but there was no way for a scanner to determine whether the linked object was benign, a credential harvester, or malware without retrieving and detonating it behind the SAS gate.
W-9 as social engineering vector. A W-9 request is a low-friction ask. Accounting departments handle them routinely. The form itself collects taxpayer identification numbers, legal entity names, and addresses, exactly the data required for identity fraud or payment redirection. Attackers favor W-9 requests because they rarely trigger suspicion and the response contains high-value PII. CISA's phishing guidance specifically warns about tax document pretexts as a social engineering lever.
This case maps to T1078 (Valid Accounts) for the apparent use of a legitimate government account, and T1566.002 (Spearphishing Link) for the blob-hosted payload delivery.
| Type | Indicator | Context |
|---|---|---|
| Sending Domain | kitsap[.]gov | County government domain, full SPF/DKIM/DMARC pass, compauth=100 |
| Blob Storage Domain | wakitsap[.]blob[.]core[.]usgovcloudapi[.]net | Azure Government blob storage |
| SAS Token Expiry | se=2026-05-13 | Time-limited access, storage version sv=2022-11-02 |
| Linked File | [Case Party] 035-0053505 [Case Party].pdf | PDF hosted on Azure Gov blob |
| Header Anomaly | x-unsent: 1 | Draft/resend behavior indicator |
| SCL | 1 | Low spam confidence from Microsoft |
This case sits in a category that will only grow: attacks that derive their plausibility from government or government-adjacent infrastructure. The .gov domain, the Azure Government cloud, the FedRAMP trust chain. These are not signals an attacker fabricated. They are real trust markers that either belonged to the sender legitimately or were inherited through account compromise.
For security teams, the operational takeaways are specific:
Treat first-time .gov senders with the same scrutiny as any other first-time sender. Authentication tells you the infrastructure is authorized. It does not tell you the person behind it is who they claim to be. A .gov domain with a perfect compauth score and no prior sender history is still a first-time sender.
Flag W-9 and tax document requests from new contacts for out-of-band verification. Call the requesting office at a number from the agency's public website. Do not use the phone number in the email signature, even if it matches public records. Compromised accounts often preserve the original user's signature block intact.
Monitor for x-unsent headers in externally-sourced emails. While this header alone is not conclusive, its presence in combination with a first-time sender and a financial document request warrants elevated review.
Recognize that SAS-gated blob links are functionally opaque to URL scanners. If your security stack evaluates links by domain reputation alone, Azure Government blob storage will pass every time. Behavioral detection that considers the link's context within the email, the sender's history, and the request pattern is the only layer that can evaluate this class of payload.
Themis flagged this message at 80% confidence and reverted it across two mailboxes before either recipient engaged. The detection was not based on any single artifact. It was the combination: a first-time government sender, a W-9 request, an unverifiable blob link, and a draft-send header pattern. Authentication said trustworthy. Behavior said otherwise.