A Real File-Transfer Alert With a Throwaway Reply-To

The notification looked like nothing worth a second thought. A file-transfer service had a document waiting, and a single button offered to download it. The service was real. Its domain was authenticated. Every signal a mail gateway inspects came back clean. The message reached the inbox of a chief operating officer at a mid-size professional services firm, and on paper there was no reason to stop it.

The reason to stop it was sitting in a header almost nobody reads.

A real platform doing the delivery

The email presented itself as an automated notification from a legitimate file-sharing SaaS platform, sent from that platform's own no-reply address on its own domain. That matters, because it means the authentication story is not a forgery. SPF passed. DKIM passed, signed by the platform's real domain. DMARC passed, and the platform publishes a strict reject policy, so alignment was genuine end to end. The composite authentication result came back as a full pass.

This is the uncomfortable truth that authentication-first thinking keeps running into. SPF, DKIM, and DMARC validate the infrastructure that sent a message and the domain stamped in the From header. They say nothing about the human who set the message in motion or the destination on the other side of a link. When an attacker abuses a real, reputable platform to do the sending, the platform's honest authentication becomes the attacker's borrowed credibility. Nothing was spoofed here. It did not need to be.

The tell in the Reply-To

The one place the message contradicted itself was the Reply-To header. The From address belonged to the file-sharing platform. The Reply-To pointed somewhere else entirely, to a disposable throwaway address on a Guerrilla Mail domain (hold56@guerrillamailblock[.]com).

Guerrilla Mail hands out temporary, no-registration inboxes designed to evaporate. A legitimate automated notification from a corporate SaaS platform has no reason to route replies to a throwaway consumer address, and it certainly has no reason to route them to a service whose entire value proposition is leaving no trace. From versus Reply-To divergence is a classic invoice-fraud and credential-theft signal, and this was a textbook instance: the visible sender identity and the actual point of contact were two different people wearing one uniform. A recipient who happened to expand the header would have seen the mask slip. Most recipients never expand the header.

A PDF that was never a PDF

Follow the download button and the platform served a landing page, not a document. The file it referenced was tiny, roughly one and a half kilobytes, far smaller than any real benefits document or contract. Its name carried a double extension, a pattern resembling a benefits summary ending in .pdf.html.

That naming trick is the heart of the attack. A double extension leans on the gap between what a filename looks like and what a system actually does with it. The eye latches onto the .pdf and reads document. The browser reads the true final extension, .html, and renders an interactive web page. So instead of a PDF opening in a viewer, a fake login and registration form opened in the browser, asking the executive to authenticate to retrieve the waiting file. The credential-harvest surface was never a downloaded payload sitting on disk for an antivirus engine to scan. It was a live page, hosted on trusted infrastructure, reached through a link that pointed at a domain with a spotless reputation.

The median time to click a phishing link is 21 seconds, and the median time to then submit data is 28 seconds, according to the 2024 Verizon Data Breach Investigations Report. Under a minute from open to credentials entered. A convincing login form on a trusted-looking domain does not need much of that minute to win.

Why the usual checks came up empty

Walk through what a conventional gateway had to work with. Authentication: clean, genuinely. Sender domain reputation: excellent, because it belonged to a real SaaS platform. Link destination: a page on that same reputable platform, so no malicious domain to block. Attachment: none, because the payload lived on the web rather than in the message. There was no forged header, no lookalike domain to age-check, no malware to detonate. Every lever a filter reaches for was either clean or absent.

What was left was a question no signature can answer: does this message's identity hold together? A file-transfer alert from a real platform, quietly redirecting replies to a disposable throwaway address, leading to a login form dressed as a document, is coherent only as an attack. This is the surface our Adaptive AI is built to reason over, analyzing sender-identity consistency, the From-versus-Reply-To mismatch, and behavioral context rather than trusting a clean authentication stamp at face value. The tell was behavioral, and behavior is what caught it.

What security teams should take away

Treat a passing SPF, DKIM, and DMARC result as evidence of who sent a message, never as evidence that the message is safe. Legitimate-platform abuse turns clean authentication into a weapon, so the meaningful checks move to identity consistency: does the Reply-To match the From, and if not, why. Flag disposable and throwaway mail domains wherever they appear, because they belong to no one who wants to be found. And teach people that a filename is a claim, not a fact, since a name ending in .pdf.html is an HTML page wearing a document's costume.

The wider gap this exposes, between what a gateway verifies and what actually lands in front of your executives, is worth measuring directly rather than assuming, which is what our SEG email security gap analysis is designed to surface. And because the endgame here was harvested credentials, layered account takeover protection is what keeps a single entered password from becoming a compromised mailbox.

Indicators of compromise

Authentication summary: SPF pass, DKIM pass (aligned to the platform domain), DMARC pass under a reject policy, composite authentication pass. Authentication validated the sending infrastructure, not the human behind the message.

MITRE ATT&CK mapping

• T1566.001 (Phishing: Spearphishing Attachment/Link): a file-transfer lure delivering a link to a credential-harvest page on abused SaaS infrastructure.
• T1204.002 (User Execution: Malicious File): the double-extension HTML file that renders as a login page when opened.
• T1585 (Establish Accounts): a disposable Guerrilla Mail account stood up as the untraceable point of contact.

See you next time

The strongest phishing does not break your defenses, it borrows them. A real platform, a real authenticated domain, and a filename that lies are enough when the only warning sits in a header nobody opens. The attacks worth studying next are the ones that pass every check you have and still do not add up.