Purpose-Built Look-Alike Sending Domain Passes Full Authentication to Impersonate Training Brand

A webinar invitation for "Electronic Records Retention" landed in an enterprise mailbox. The sender name matched a known vendor contact. The branding matched a legitimate professional training company. SPF passed. DKIM passed. DMARC passed with a compauth score of 100. The email carried CE credit details (ATAHR, HRCI, SHRM), a professional footer with a real physical address, and a functioning unsubscribe mechanism.

The sending domain was wrong. Not wrong in a way that screamed fraud. Wrong in a way that exploited how legitimate companies actually send email.

The IRONSCALES platform flagged the domain mismatch and quarantined the email across multiple mailboxes within seconds.

Exploiting the Separate Sending Domain Pattern

Most enterprise email programs use dedicated sending domains for marketing and transactional messages. A company operating as brand[.]com might send campaigns from brand-sending[.]com or brand-mail[.]com. Recipients are trained to accept this pattern. Email administrators whitelist these domains. Security tools learn to associate them with the primary brand.

This attack weaponized that expectation. The impersonated brand operates its primary domain at auroratrainingadvantage[.]com, registered in 2013 and hosted on Cloudflare. The attacker built a parallel infrastructure using two purpose-built domains:

• Sending domain: trainingadvantagesending[.]com (From address, DKIM signing)
• Mail relay domain: trainingadvantage-mail[.]com (MX/SMTP relay, HELO identity)

Both attacker domains were registered on the same day, July 31, 2023, through Dynadot with full WHOIS privacy. Both use the same nameservers. Both carry proper SPF, DKIM, and MX records. This is not a hastily assembled phishing kit. The infrastructure was purpose-built over two years before this attack landed.

The naming pattern is precise. The legitimate brand uses "aurora training advantage" while the attacker domains use "training advantage" plus a mail-function suffix ("sending" and "mail"). To a recipient scanning the From field, cindyfreeman@trainingadvantagesending[.]com looks like the marketing send variant of a familiar vendor.

Full Authentication on Attacker-Controlled Infrastructure

The email arrived from mx4.trainingadvantage-mail[.]com at IP 185[.]227[.]50[.]117 (geolocated to Canada). The complete authentication chain:

• SPF: Pass (trainingadvantagesending[.]com designates 185[.]227[.]50[.]117 as permitted sender)
• DKIM: Pass (d=trainingadvantagesending[.]com, selector smtpdkim, RSA-SHA256)
• DMARC: Pass, action=none
• compauth: 100 (Microsoft Composite Authentication, perfect score)

Every authentication check returned the best possible result. The domain aligned across envelope, headers, and DKIM signature. The DMARC protocol confirmed that the From domain matched the authenticating domain. The problem is that the authenticating domain was not the brand it pretended to be.

This is the structural limitation of SPF and DKIM. They verify that a domain owner authorized the sending server. They do not verify that the domain belongs to the brand the recipient thinks it represents. An attacker who registers their own domain and configures authentication correctly will pass every check, every time.

The Microsoft Digital Defense Report 2024 documented the growing sophistication of brand impersonation infrastructure, noting that attackers increasingly invest in long-lived domains with proper authentication to evade detection at scale.

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

Display Name Impersonation With Known Contact Match

The From header read: " Cindy Freeman " . The IRONSCALES platform had previously seen legitimate email from a contact named "Cindy Freeman" at cindyfreeman@trainingadvantagecampaign[.]com. The display name was an exact match. The local part (cindyfreeman) was identical. Only the domain differed.

This triggers a specific detection class: exact display name impersonation with domain mismatch. The attacker did not just copy a brand. They copied a specific person associated with that brand, using a domain close enough that the swap would not register on a quick visual scan.

The Verizon DBIR 2024 found that pretexting (which includes brand and identity impersonation) accounted for over 40% of social engineering incidents. The FBI IC3 2024 report documented $2.9 billion in BEC/fraud losses, with impersonation of trusted vendors as a primary attack vector.

Links Redirect Through Attacker Domain to Legitimate Event Platform

All embedded links pointed to trainingadvantagesending[.]com with click-tracking parameters, including /external_pages/clickTracker.aspx paths. These click-tracker URLs redirected to a legitimate Eventbrite registration page for a real Aurora Training Advantage webinar ($219-$599 tickets, CE credits, real event date).

This is the subtlety. The final destination is a real event on a real platform. The attacker is not harvesting credentials at the landing page. Instead, they are routing all clicks through their own tracking infrastructure first. Every click confirms an active mailbox, records the recipient's IP and user agent, and timestamps engagement. This maps to MITRE ATT&CK T1598.003 (Phishing for Information: Spearphishing Link), where the objective is intelligence gathering rather than immediate payload delivery.

The click-tracking URLs carried unique identifiers (cid=42072067, lid=4977080, sid=1592455) tied to specific campaigns and recipients. Combined with the X-Campaign and Feedback-ID headers, the attacker maintained full visibility into which mailboxes were active and which recipients engaged.

This case also maps to MITRE ATT&CK T1583.001 (Acquire Infrastructure: Domains) for the purpose-built look-alike domain registration, and T1036.005 (Masquerading: Match Legitimate Name or Location) for the brand naming pattern mimicry.

Why This Pattern Defeats Gateway Controls

Microsoft's own antispam engine assigned SCL=5 and a Bulk Complaint Level (BCL) of 8, routing the email to quarantine. But the detection was based on bulk mail heuristics, not the impersonation itself. The BCL=8 score reflects sender reputation patterns typical of mass marketing, not threat intelligence. An attacker sending lower volumes from the same authenticated infrastructure would likely achieve SCL=1, bypassing the quarantine entirely.

Legacy secure email gateways that rely on domain age, authentication results, and URL reputation would pass this email clean. The domain is 2.5 years old. Authentication is perfect. The link destinations are Eventbrite.

Detection required behavioral context: recognizing that a known contact name appeared on an unfamiliar domain, that the sending domain mimicked but did not match a known vendor, and that community threat intelligence had flagged similar patterns across organizations. The IRONSCALES Themis engine assigned 80% confidence and triggered automatic quarantine across affected mailboxes.

Indicators of Compromise