The Bank Archive That Never Reached the Inbox

An EMEA security mailbox at a global IoT and connectivity technology manufacturer received a message advertising a bank-themed RAR archive named Bank Copy.rar. By the time the message reached the inbox, the archive was already gone. The mail platform's own attachment policy had removed it in transit, and the body the recipient actually saw was a wrapper notice, repeated several times over, stating that Bank Copy.rar was removed because it contains files that violate the mail server's policy. The subject line still read like a payment confirmation, a Proof Of Payment header with an appended note that unsafe content had been removed or modified.

On the surface, this looks like a win, and in one important sense it was. The malicious archive never touched the mailbox. But the message that remained was not harmless, and the story of how it got there is a useful reminder that attachment scanning is only one layer of a much larger detection problem.

A sender identity built on someone else's good name

The visible From address was an account alias at a real, unrelated Polish furniture company's domain, a legitimate business with no connection to the target and no evidence that its own infrastructure had been compromised. This was not a lookalike domain registered the week before, and it was not an account takeover. It was a straight identity spoof: the attacker simply stamped a real, established company's domain onto the From line and sent from infrastructure that had nothing to do with it.

That distinction matters for detection. There was no fresh domain age to flag, because the spoofed domain had been registered well over a decade earlier and carried a clean, ordinary history. A control that leans on domain reputation or registration recency would find nothing to object to in the name on the envelope. The abuse was in the disconnect between the name and the path the message actually traveled.

The gateway name masquerade

The most striking detail sits in the connection metadata. The connecting server introduced itself with a HELO string that falsely presented itself as the recipient organization's own inbound mail-gateway hostname. In other words, the attacker's system announced itself as if it were a piece of the target's own email infrastructure. This is a masquerade technique, mapping to MITRE ATT&CK T1036.005 (Masquerading: Match Legitimate Name or Location), and it is designed to slip past humans and loosely configured filters that treat familiar internal-sounding names as trustworthy.

The claim did not hold up under inspection. The connecting IP had no reverse DNS record at all. Its PTR lookup returned nothing, so the hostname it asserted was backed by exactly zero corroborating evidence. A HELO string is self-declared and never validated by the protocol, which is precisely why it makes such a convenient costume. When the name a server announces cannot be reconciled with the name its address resolves to, that gap is a signal in itself.

Authentication was soft, not silent

The authentication results tell a familiar story of gaps rather than a clean failure. SPF returned a softfail: the connecting IP was not authorized to send for the From domain, and the domain's policy discouraged but did not forbid that source. The message was unsigned, so there was no DKIM signature to verify. And the From domain published no DMARC record, which means there was no alignment policy to enforce and no instruction to reject or quarantine an unaligned message. Microsoft rated the message at a spam confidence level of 5 and classified it as suspicious.

This is the combination that lets an unauthenticated spoof survive. A softfail on its own is often treated as a nudge toward a spam folder rather than a hard block, and with no DMARC policy behind it, nothing escalates that nudge into a rejection. The 2024 Verizon Data Breach Investigations Report found that the human element factored into 68 percent of breaches, and phishing remains one of the primary ways attackers reach that human element. Messages engineered to look internal and financial are built specifically to shorten the distance between arrival and a click. NIST defines phishing precisely around that deception of a trusted identity, which is exactly what the From line and the HELO string were manufacturing here.

Why attachment hygiene alone was not the finish line

The removal of Bank Copy.rar was genuine and useful. The delivered body confirmed it in plain language, and a secondary clean-scanned wrapper was all that remained of the payload attempt. Note the honest framing: the archive's contents were never confirmed, and this was a policy-and-type strip of a RAR file, not a signature engine detonating known malware.

Because here is the residual risk. Even with the payload gone, the recipient still received a message carrying a spoofed identity, a financial lure theme, and a masquerade of their own gateway. That residue can seed a reply, invite a follow-up from a fresh path, or simply establish a plausible-looking sender the attacker returns to later, which is the same on-ramp that feeds business email compromise and payment-diversion fraud. This is the case for behavioral and identity-pattern detection layered on top of attachment hygiene, not instead of it. Our Adaptive AI email security platform, powered by Themis, flagged this message as a Credential Theft attempt at 56 percent confidence, working off the identity signals that survived after the archive was already stripped: the unauthenticated third-party sender, the reverse-DNS mismatch, and the internal-gateway impersonation.

Attackers who reach for real, unrelated business domains and financial-payment framing are running a well-worn playbook, one the mapping to T1566.001 (Spearphishing Attachment) captures, and one that CISA's guidance on stopping the phishing attack cycle walks through in detail. The lesson is not that attachment scanning failed. It is that attachment scanning succeeded and the attack still had a second act waiting in the identity layer.

Indicators of Compromise

How to reduce exposure to this pattern

Teams facing this class of spoof can close the gaps that let it land. Publish and enforce a DMARC policy so that unaligned mail claiming your identity is rejected rather than merely softfailed, and treat reverse-DNS and HELO mismatches as first-class risk signals rather than curiosities. Because attackers deliberately dress up in familiar names and payment themes, our email security gap calculator is a practical way to see where a gateway-only stack leaves openings. Attachment hygiene is necessary. It is not, on its own, sufficient.