The Zero-Byte Contract That Impersonated a County

A case manager in a county government human-services department opened her inbox one morning to find what looked like the most routine thing in the world. It was a notification from the county's own eNotify system, and it carried an attachment titled to read like a signed, executed agreement. That is exactly the kind of message a government caseworker handles every week: contracts, service agreements, court notices, all of it arriving as PDFs from official-sounding automated systems. There was just one problem. The attachment was empty, and the sender was not the county at all.

The domain that wasn't the county's

The message displayed the friendly name "eNotify," a label chosen to echo the automated court and county notification systems that government staff are trained to trust. Behind that display name sat hfan@lexparkgroup[.]com, a domain with no relationship whatsoever to the county's own government domain. Nothing about lexparkgroup[.]com connects it to a county human-services office, a courthouse, or any government function.

The domain itself is not freshly minted attacker infrastructure. WHOIS records show it as a real, long-registered domain created well over a decade ago and kept in continuous renewal since. That profile points to a compromised or repurposed legitimate account rather than a throwaway registration, which is precisely why it carries some inherited trust. The mail was relayed through Google's own outbound infrastructure (mail-pj1-x1062[.]google[.]com), and, critically, it arrived carrying a valid DKIM signature.

When composite auth says "pass"

Here is where it gets uncomfortable. SPF for the sending domain was absent. DMARC was absent. On paper, a message from a domain that publishes no SPF record and no DMARC policy should be trivial to treat with suspicion. But the message was DKIM-signed by the Google relay (selector domain lexparkgroup-com[.]20230601[.]gappssmtp[.]com), and Microsoft's composite authentication check evaluated the message as compauth pass, reason code 106.

In plain terms, the receiving system decided the message was authentic enough to deliver. A single valid DKIM signature, riding on Google's trusted sending reputation, was sufficient to earn a composite pass for a domain that a strict, DMARC-enforced sender would have seen rejected outright. This is the gap worth sitting with: authentication told the filter that the message really came from lexparkgroup[.]com. It said nothing about whether lexparkgroup[.]com had any business impersonating a county government. Authentication verifies the envelope, not the intent.

A file with nothing inside it

The attachment is the part that should stop you cold. It was named to resemble a signed government contract, an executed agreement of exactly the sort a case manager is expected to open and file. Its size was zero bytes. Its MD5 hash was d41d8cd98f00b204e9800998ecf8427e, which is the canonical hash of a completely empty file, a value security teams recognize on sight. There was no document, no macro, no embedded link, no credential form, nothing. The body of the email was blank apart from the recipient's standard external-sender banner. The filename was the entire attack.

Why send a file with nothing in it? Because a zero-byte contract is a probe. It quietly asks two questions the attacker very much wants answered. Does this mailbox open unexpected attachments from unfamiliar senders? And will the caseworker, seeing a corrupt or empty official document, reply to ask "this came through blank, can you resend it?" Either response confirms a live, engaged human on the other end and opens the door for a follow-up carrying a real payload or a payment-diversion request. This is the opening move of a longer impersonation play, not the whole game.

Why nothing to scan is the point

Traditional email security is built to answer one question: is there something dangerous in this message? A secure email gateway detonates links in a sandbox, unpacks archives, flags weaponized macros, and matches payloads against signatures. Point all of that machinery at a zero-byte file and a blank body and it finds exactly nothing, because the danger here is contextual, not technical. There is no malicious URL to detonate, no macro to flag, no payload to fingerprint.

The 2024 Verizon Data Breach Investigations Report is a useful reality check on this point. The human element is a component of 68% of breaches, phishing appears in 15% of them, and the median time to click a phishing link is just 21 seconds. When an attacker strips out the payload entirely, that human click, or reply, is not merely the biggest risk. It is the only mechanism the attacker has. The attack lives or dies on whether one distracted caseworker trusts a filename.

What actually caught it

With no functioning link and no attachment content, there was nothing for a content or malware scanner to catch. The only available signal was identity: the sender domain was not the government entity named in the lure, and a crafted contract filename paired with zero actual content formed a behavioral pattern rather than any technical indicator. Catching that requires a system that reasons about who a sender claims to be versus who they actually are.

That is where IRONSCALES Adaptive AI operates. Rather than gating solely on gateway authentication and content inspection, Themis evaluates sender identity and relationship context, and it flagged the mismatch between the impersonated county identity and the unrelated sending domain. This is the same class of detection that stops business email compromise, where the payload is a request rather than a file and the attacker's entire toolkit is a trusted-looking name. Reinforcing that machine-layer catch with regular phishing simulation testing trains case managers to pause on the identity question, not just the attachment, so the reply the attacker is fishing for never gets sent.

The takeaway for anyone defending a government inbox: a message can pass authentication, carry no malware, and still be an attack. When the payload is an empty file and a borrowed identity, the mismatch is the malware.

Indicators of Compromise

MITRE ATT&CK Mapping

For broader context on how attackers weaponize attachments and how defenders can respond, see CISA's phishing guidance and the NIST definition of phishing.

See You Next Friday

Zero-byte lures are a reminder that the most dangerous phishing messages are sometimes the emptiest ones. When there is nothing to scan, identity is the whole game. Come back next Friday for another attack pulled straight from the SOC.