The display name read [Display Name], M.S. OY-36463 DFQT-382 FWZT-320. Those alphanumeric strings look like internal reference numbers, the kind of shorthand a procurement contact might carry in a corporate signature. They are entirely fabricated. So is the identity. And the email behind it used three different domains to pull off a single scam.
SPF passed. DKIM passed. DMARC passed. The message landed in the inbox of a VIP recipient at a global manufacturing firm, dressed up as a routine Request for Quotation from a construction materials supplier. Everything about the authentication looked clean. Everything about the identity was a lie.
Most phishing attacks use one domain. This one used three, each serving a distinct purpose in the kill chain.
The From address pointed to KIM@hiltachk[.]com, a domain registered in 2008 with name servers on Cloudflare. It is a legitimate domain with a long operational history, and the attacker used it (or a compromised account on it) to send the message through Google Workspace infrastructure. SPF authorized the sending IP. DKIM was signed under hiltachk-com.20251104.gappssmtp[.]com. DMARC returned bestguesspass. From an authentication standpoint, the message was clean.
The Reply-To, however, pointed somewhere else entirely: aakowicz@fortacorsp[.]com. That domain is a character-for-character lookalike of a legitimate construction materials company, differing by a single inserted letter. It was recently registered through Hostinger with no public company profile, no web presence, and no operational history. Any reply to this RFQ would route straight to the attacker.
The third domain, 727fa93f[.]co, appeared as the relay origin. The message passed through Google SMTP relay infrastructure at 104[.]249[.]128[.]226 before reaching Microsoft Exchange Online Protection. Three domains, three roles: authentication, impersonation, and delivery.
This is not a blunt instrument. The FBI IC3 2024 Internet Crime Report documented over $2.9 billion in BEC losses, with vendor impersonation and procurement fraud among the fastest-growing subcategories. Attacks that separate the authentication domain from the impersonation domain are harder to detect because the technical signals (SPF, DKIM, DMARC) all check out against a domain that has nothing to do with the brand being spoofed.
The display name is where the social engineering gets interesting. [Display Name], M.S. OY-36463 DFQT-382 FWZT-320 is designed to look like a procurement contact carrying professional credentials and project codes. The M.S. suggests a graduate degree. The alphanumeric strings mimic the kind of internal tracking numbers that appear in vendor management systems.
None of it is real. But a procurement team member scanning a crowded inbox sees exactly what the attacker wants them to see: a credentialed professional from a known supplier, referencing an active project.
The email body reinforced the pretext. It used a branded header for the impersonated company, referenced an "upcoming project," and asked the recipient to review an attached document and provide pricing information, lead times, availability, and minimum order quantities. The tone was professional and low-urgency, the kind of request that procurement teams process dozens of times per week. According to Verizon's 2024 Data Breach Investigations Report, pretexting (which includes fabricated business scenarios like fake RFQs) now accounts for over 40% of social engineering incidents.
The body was duplicated, a full copy of the message repeated below the signature. This is a common artifact of hastily assembled phishing templates, and it is one of the few visual clues that something was off.
See Your Risk: Calculate how many threats your SEG is missing
Microsoft's 2024 Digital Defense Report notes that attackers increasingly use legitimate email infrastructure to send phishing messages, precisely because authentication protocols verify domain ownership rather than sender intent. In this case, the From domain (hiltachk[.]com) had valid SPF, DKIM, and DMARC records. The email was genuinely authorized by that domain. The problem is that the domain has no relationship to the company being impersonated.
Microsoft Exchange Online Protection flagged the message with an SCL of 5 (spam) and a safety score of 9.25, routing it toward the junk folder. But the authentication signals all said "pass." Organizations that configure mail flow rules to trust authenticated messages, or that weight DMARC pass as a strong positive signal, would have delivered this to the inbox.
IRONSCALES Adaptive AI flagged the message at 80% confidence through signals that authentication cannot provide. The VIP recipient targeting, the Reply-To domain mismatch (a recently registered domain answering for a known brand), and the first-time sender profile all contributed to the detection. Within the IRONSCALES community of over 35,000 security professionals, domain mismatch patterns like this are shared in real time, turning one detection into protection across thousands of organizations.
| Technique | ID | Application |
|---|---|---|
| Spearphishing Attachment | T1566.001 | RFQ email referencing an attached procurement document |
| Masquerading: Match Legitimate Name or Location | T1036.005 | Reply-To domain mimics legitimate brand; display name constructed to mimic a professional identity with fabricated credentials |
| Impersonation | T1656 | Full brand impersonation of a construction materials supplier via branded email template |
| Type | Indicator | Context |
|---|---|---|
| Domain | hiltachk[.]com | From/envelope domain (registered 2008, Tucows/Cloudflare) |
| Domain | fortacorsp[.]com | Reply-To lookalike domain (recently registered, Hostinger) |
| Domain | 727fa93f[.]co | Relay origin domain |
KIM@hiltachk[.]com | From address | |
aakowicz@fortacorsp[.]com | Reply-To address (attacker-controlled) | |
| IP | 104[.]249[.]128[.]226 | Google SMTP relay IP |
| DKIM Selector | hiltachk-com.20251104.gappssmtp[.]com | DKIM signing domain |
| Auth | SCL=5, SFTY:9.25 | Microsoft spam/safety scores |
| Display Name | [Display Name], M.S. OY-36463 DFQT-382 FWZT-320 | Fabricated identity with fake credential strings |
Inspect Reply-To before responding to any vendor RFQ. The From address and Reply-To do not have to match, and most email clients hide the Reply-To by default. Procurement teams should be trained to verify the reply destination, especially on first-contact messages.
Treat domain age as a first-class signal. Recently registered domains appearing in Reply-To headers are among the strongest indicators of impersonation. The CISA phishing guidance recommends organizations implement detection that accounts for domain registration age, not just authentication status.
Do not trust authentication as a verdict. SPF, DKIM, and DMARC confirm that a message was sent from authorized infrastructure. They say nothing about whether the sender is who they claim to be. When the From domain, Reply-To domain, and impersonated brand are three different entities, authentication answers the wrong question. The IBM Cost of a Data Breach 2024 report found that phishing-initiated breaches averaged $4.88 million, with BEC variants driving the highest per-incident losses.
Flag fabricated credential strings. Alphanumeric codes in display names (like OY-36463) are designed to project legitimacy. If those strings do not correspond to real internal reference numbers, they are a social engineering prop. Security awareness training should include examples of this technique alongside traditional display-name spoofing.