The Vendor Address Hiding in Plain Sight: How a Free Email Service Carried a B2B Impersonation Into a Real Thread

The email read like a routine follow-up. A Spanish-language request for shipment status on order LV-02-2025, addressed to the recipient by first name, written in the professional, clipped tone of someone in an accounting department checking on a delivery. Quoted below the new message sat a clean thread of legitimate vendor correspondence: corporate signatures, direct phone lines, real links pointing to the vendor's actual domain. SPF passed. DKIM passed. DMARC passed.

The From address was contabilidad2bascatcia@techie[.]com.

The vendor's real address, sitting right there in the quoted thread, was contabilidad2@bascatcia[.]com.

A Domain Name Buried in a Username

Look at those two addresses side by side. The attacker took the vendor's full email identity, contabilidad2@bascatcia[.]com, and collapsed it into a single string: contabilidad2bascatcia. Then they registered that string as a username on techie[.]com, a free email service that has been operating since 1996. The result is an address that contains every character of the real vendor email, just rearranged across the @ boundary.

This is not a typosquat. The attacker did not register a lookalike domain. They did not compromise the vendor's actual mail server. They signed up for a free account on a 28-year-old legitimate platform and crafted a username designed to pass a quick visual scan. In a busy inbox, especially on mobile where the full address may be truncated, contabilidad2bascatcia@techie[.]com looks close enough to contabilidad2@bascatcia[.]com that a recipient already expecting vendor correspondence could easily miss the swap.

This maps to MITRE ATT&CK T1036 (Masquerading). The attacker constructed an identity designed to be visually confused with a trusted entity, without touching any infrastructure belonging to that entity.

Authentication Worked Perfectly (and That Is the Problem)

Every authentication check returned clean:

• SPF: Pass for techie[.]com
• DKIM: Pass for techie[.]com
• DMARC: Pass for techie[.]com
• Sending IP: 74[.]208[.]4[.]200, with PTR record mout.mail[.]com (legitimate mail[.]com outbound infrastructure)

There is no spoofing here for authentication to catch. The email was genuinely sent from techie[.]com, by a real techie[.]com account, through techie[.]com's authorized mail servers. SPF confirmed the IP was allowed to send for the domain. DKIM confirmed the message was unmodified. DMARC confirmed alignment. From an authentication standpoint, this email was indistinguishable from any other legitimate techie[.]com message.

This is the fundamental limitation that the FBI IC3 2024 Internet Crime Report documented in BEC losses exceeding $2.9 billion: email authentication protocols validate domains, not people. They answer "did techie[.]com send this?" (yes) but not "is this person actually your vendor?" (no). For attacks where the sender genuinely controls the sending domain, traditional gateway defenses have nothing to flag.

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

Zero Payload, Maximum Patience

The email contained no attachments. No links. No credential harvesting page. No payment redirect. No urgency language demanding immediate wire transfers. It simply asked about the status of a shipment for an existing order number.

This is Phishing for Information (T1598). The attacker's immediate objective was not to steal money or credentials. It was to get a response. Once the recipient replies with shipment details, the attacker has confirmed the email address is active, the order number is real, and the recipient is willing to correspond. That reply becomes the foundation for the next message in the thread, which will carry the actual payload: updated bank details for payment, revised invoicing instructions, or a request to redirect the shipment.

The quoted thread below the attacker's message reinforced this setup. It contained real correspondence from a medical devices company: employee names (anonymized), job titles, direct phone numbers, and links to the legitimate vendor's website at bascatcia[.]com. Every link in the thread was clean. The thread itself may have been intercepted from a prior compromise or reconstructed from publicly available information. Either way, it gave the new message context and credibility that a cold email could never achieve.

The recipient's email client displayed two warning signals: an external email banner and a "Don't often get email from" notice. Both are standard for first-time senders. Both are routinely ignored in organizations that do business internationally with multiple vendors.

Where Behavioral Detection Changes the Equation

A secure email gateway evaluating this email finds nothing actionable. The domain is legitimate and aged. Authentication passes. There are no URLs to detonate, no attachments to sandbox, no keyword triggers in the body. The email is, by every static measure, clean.

Behavioral analysis operates on a different question: does this communication pattern fit this relationship? IRONSCALES Adaptive AI evaluates sender-recipient history, communication cadence, and contextual signals that static filters cannot assess. A first-time sender using a free webmail domain to continue a conversation that previously occurred on a corporate domain is a behavioral anomaly, regardless of what authentication says.

This is the Impersonation (T1656) detection surface. The attacker assumed an identity that does not belong to them, and the only way to catch it is to know what the real relationship looks like.

What Supply Chain Teams Should Verify

Compare the sending domain to prior correspondence. This attack survives every automated check. The control that catches it is a human (or an AI trained on relationship history) noticing that the domain changed from bascatcia[.]com to techie[.]com. When a vendor email arrives from a different domain than previous messages in the same thread, treat it as suspicious regardless of authentication results.

Treat zero-payload emails with the same scrutiny as payment requests. An email asking for shipment status seems harmless. It is not. It is the reconnaissance phase of a vendor email compromise operation. The attacker needs a reply to validate the relationship before escalating.

Verify out-of-band on domain changes. If a vendor contact appears to be emailing from a new address, call them using a number from your records. Do not use contact information from the email itself, even if it appears in a quoted signature block. Signatures in forwarded threads can be copied or fabricated.

Audit free email usage in your vendor population. Legitimate vendors in B2B supply chains rarely conduct business from techie[.]com, mail[.]com, or similar free services. Any vendor correspondence originating from a free email provider warrants immediate verification, particularly when it references active orders or financial transactions.

---

MITRE ATT&CK Mapping

Indicators of Compromise