The Attack Came Through the City's Own Contact Form

The message that landed in a municipal government office that morning was not pretending to be a bank, a courier, or Microsoft. It announced itself as a notification from the city's own website: somebody had filled out the public contact form, and here was what they wrote. The display name was the city's own name. The layout was the site's standard form-submission template, down to the page-builder credit line in the footer and a labeled field reporting the submitter's remote address. Everything about the wrapper was ordinary, because everything about the wrapper was genuine.

What the anonymous submitter had typed into the message field was not a constituent inquiry. It was a two-line advertisement for an Android installer package, an offshore betting app, followed by a live link and then several lines of garbled, non-Latin characters that were encoding artifacts rather than readable content. The link came back malicious when it was scanned. It had been delivered to a city employee by the city's own web server, over the city's own mail path, inside the city's own branded template.

No mailbox was compromised. No sending domain was spoofed. The attacker's entire interaction with the target was a text box on the target's public website.

The website was the delivery channel

A contact form is a mail-sending surface, and almost nobody inventories it as one. The pattern repeats across countless municipal, school-district, and small-business sites: a server-side mailer sits behind a public page, accepts free text from any anonymous visitor, wraps it in the organization's own branded notification template, and hands it to the organization's own outbound mail path addressed to internal staff. From the mail system's perspective that is first-party correspondence, generated by infrastructure it already trusts. From an attacker's perspective it is a free injection point requiring no stolen credentials, no lookalike domain, and no convincing pretext, because the only reader who has to be fooled is a filter, and the filter is looking at the wrapper.

The submission itself was built to be disposable. The submitter address was a random eleven-character local part on a throwaway domain registered eight days before the message went out, a domain whose only job was to satisfy whatever validation the form applied to its email field. Standing up cheap, short-lived domains just ahead of a campaign is MITRE ATT&CK T1583/001, Acquire Infrastructure: Domains, and eight days is a deliberate age. Old enough to resolve and pass a syntax check, young enough to carry no reputation history worth burning.

The remote-address line in the notification template deserves a second look too. It reported an address on a Netherlands virtual-server provider, and it is also, structurally, attacker-influenced data printed into a field that reads like an audit trail. A responder glancing at it would reasonably treat that value as forensic ground truth. It is nothing of the kind. When untrusted input is rendered into a trusted-looking template, the provenance metadata is part of the untrusted input.

What the link actually led to

The single URL in the message body pointed at an established blog domain, registered roughly a year earlier, with a privacy-redacted registrant and a recently refreshed registration record. The path resolved to a generic post page on what looked like an ordinary content-management install. Not a counterfeit sign-in screen, not a fake document portal, just a page positioned to hand off an Android installer package for the advertised betting app.

That target profile changes the detection problem. There is no forged login page to compare against a real one, no brand mismatch to catch, no credential-submission moment to interrupt. Delivery maps to T1566/002, Phishing: Spearphishing Link, and the payoff depends entirely on T1204/001, User Execution: Malicious Link. Sideloading an unvetted installer onto a phone that reads municipal email is a short path to an unmanaged device sitting inside an organization's mail flow, which is precisely the class of link that advanced malware and URL protection exists to intercept before somebody taps it.

See Your Risk: Calculate how many threats your SEG is missing

The authentication failures were the least interesting part

Read the headers cold and this looks like a textbook spoof. At the final hop, SPF failed. DKIM failed with no key found for the signature. The sending domain published no DMARC policy at all, and composite authentication returned no verdict.

None of that is the attack. The notification left the web host's own mail infrastructure, then transited a commercial security gateway on its way to the city's Microsoft tenant, and that forwarding hop is what broke SPF alignment and invalidated the signature. An earlier hop in the same chain shows SPF passing for the original sending address, and the ARC chain validated cleanly at the receiving end, which is the fingerprint of legitimate relaying rather than forgery. Nobody was impersonating that domain. It was doing exactly what it had been configured to do.

This is the trap the case sets. Chasing the alignment failures leads a responder toward hardening a mail record that was never the problem, while the actual defect, an unauthenticated public form that will email arbitrary attacker text and arbitrary attacker links to staff, goes untouched. Both CISA phishing guidance and the NIST definition of phishing frame the threat around the deception delivered to a person, not the transport that carried it. Here the transport was flawless and the deception was the cargo.

Caught after delivery, not at the door

The uncomfortable part of this case is the timeline. The gateway scored the message as low-risk spam. The receiving platform assigned it no threat category at all. It was delivered. It sat in an employee's mailbox looking like a routine website notification, and it was only pulled when an automated retroactive rescan re-evaluated the embedded URL and returned a malicious verdict. At that point Adaptive AI scored the message at 90% confidence as phishing on the strength of its language and structure, and the single affected mailbox was remediated.

Retroactive scanning is a real control and it worked here, but it is a control that only matters because the first pass missed. The 2024 Verizon Data Breach Investigations Report puts the median time from a phishing email being opened to a link being clicked at 21 seconds. Any post-delivery remediation window, however fast, is measured in units of time that user behavior does not respect. The gap between what a gateway decides in the first second and what becomes knowable an hour later is the specific reason behavioral analysis has to run alongside the gateway rather than behind it.

Three things to fix this week

Treat every public web form as an outbound mailer with an anonymous author, and three actions follow.

Inventory them. Contact forms, ticket intake, job applications, records requests, anything that auto-emails staff. Each is an unauthenticated path from the open internet into an internal inbox, and each usually lives with a web vendor rather than the security team.

Neutralize the content. Links inside submitted free text should be stripped or rendered inert before the notification is composed, and submissions should be rate-limited and challenged rather than accepted unconditionally.

Stop granting first-party trust by template. Mail from your own web infrastructure carries your branding and your reputation, but the words inside it were written by a stranger, so it deserves the same link inspection and content scoring as anything arriving from outside.

See you next time

Attack of the Day is our daily teardown of the real phishing our SOC intercepts. Details anonymized, tradecraft intact.

Indicators of Compromise

MITRE ATT&CK Mapping