SPF passed. DKIM passed. DMARC passed. CompAuth score: 100. The email arrived from real financial infrastructure, traversed legitimate corporate mail relays, and carried a valid cryptographic signature. Every link inside pointed to real corporate domains. And it was still phishing.
The campaign used a trade confirmation lure sent through a major financial institution's authenticated mail infrastructure. The subject line was simple: "You have a new trade confirmation." The CTA directed recipients to a legitimate brokerage portal login page. For any secure email gateway (SEG) relying on authentication headers to make trust decisions, this email was invisible.
According to the FBI IC3 2024 Internet Crime Report, investment-related fraud generated the highest total losses of any cybercrime category. Phishing campaigns that exploit financial services infrastructure are a growing piece of that problem.
See Your Risk: Calculate how many threats your SEG is missing
The email originated from my_merrill@ml[.]com and traversed Bank of America's internal mail relay chain before reaching the recipient's Microsoft 365 tenant. The authentication results were textbook clean:
171[.]159[.]227[.]167 authorized for ml[.]com)header.d=ml[.]com, RSA-SHA256 signature verified)The Return-Path aligned with the From address. The Message-ID referenced smtp_mail[.]bankofamerica[.]com. Internal relay hostnames like rtxppra03[.]sdi[.]corp[.]bankofamerica[.]com and vadmzmailmx05[.]bankofamerica[.]com confirmed the message traversed the institution's corporate mail environment. Proofpoint headers (X-Proofpoint-GUID, X-Proofpoint-Virus-Version) showed the email also cleared a leading enterprise email security gateway before delivery.
For any SEG that treats authentication as a proxy for trust, this email was categorically safe. The Microsoft Digital Defense Report 2024 documents how attackers increasingly exploit this assumption by weaponizing legitimate sending infrastructure rather than building their own.
The email's authentication was clean. Its content told a different story.
HTTP image loading from a third-party host. Every image asset in the email body loaded from hxxp://www[.]sepsemails[.]com/SEPSEmailApp/images/assets/. This included the brand logo, mobile app icon, and footer separator graphic. The assets were served over plaintext HTTP, not HTTPS. For a financial institution that enforces TLS across its own web properties, serving brand assets from an unrelated domain over an unencrypted protocol is an operational anomaly. DNS records for sepsemails[.]com include SPF and DMARC configurations referencing Bank of America infrastructure, suggesting a third-party email services vendor relationship. But the use of HTTP rather than HTTPS for image delivery and the lack of public documentation tying this domain to the institution create a mixed trust signal that behavioral detection models weigh heavily.
Duplicated footer paragraphs. The email's footer contained two identical copies of the same security disclaimer: "For your protection, we won't ask you to email personal or sensitive information..." One copy overlapped visually with the preceding paragraph. This kind of template assembly error is characteristic of phishing kits that reconstruct corporate email templates from captured samples. Legitimate transactional email platforms typically generate footers from a single template block, not duplicated HTML.
Doubled domain reference. The SIPC disclosure section contained the string "sipc.org,, sipc.org" with a double comma. Template variable interpolation failures like this appear frequently in phishing kits where attackers copy corporate disclaimers and fail to properly close template loops.
These are not authentication signals. They are behavioral signals. And they represent the only reliable detection surface for this class of attack.
| Technique | ID | Application |
|---|---|---|
| Phishing: Spearphishing Link | T1566.002 | Trade confirmation CTA directing recipient to brokerage login portal |
| Masquerading: Match Legitimate Name or Location | T1036.005 | Email structure, branding, and disclaimers replicate legitimate institutional communications |
| User Execution: Malicious Link | T1204.001 | Recipient expected to click through to "view trade confirmations" |
| Indicator | Type | Context |
|---|---|---|
my_merrill@ml[.]com | Sender address | Authenticated sender, full SPF/DKIM/DMARC pass |
171[.]159[.]227[.]167 | Sending IP | SPF-authorized IP for ml[.]com, resolves to rchemail[.]bankofamerica[.]com |
hxxp://www[.]sepsemails[.]com/SEPSEmailApp/images/assets/ | Image host | Third-party HTTP asset host with BofA-linked DNS records |
olui2[.]fs[.]ml[.]com/Records/TradeConfirmations[.]aspx | CTA destination | Legitimate brokerage portal (credential entry point) |
2108300988@smtp_mail[.]bankofamerica[.]com | Message-ID | Consistent with institutional mail infrastructure |
Note: Most indicators above reference legitimate corporate infrastructure. These are pattern signals, not blocklist candidates. Blocking these domains or IPs would disrupt real financial communications. This is precisely what makes infrastructure abuse attacks difficult to counter with traditional IOC-based defenses.
The email cleared SPF, DKIM, DMARC, Proofpoint, and Microsoft's anti-spam scoring (SCL=1, BCL=2). It should have reached the inbox uncontested.
It didn't. Community intelligence from security analysts who had resolved similar incidents flagged the pattern. The Verizon 2024 DBIR found that 68% of breaches involved a human element. In this case, the human element worked in reverse: trained analysts recognized the template anomalies and reported them, feeding community-driven detection that identified this email as phishing within seconds.
Four mailboxes received the email. All four were quarantined within 18 seconds of the first report. No user interaction with the CTA was recorded.
The IBM Cost of a Data Breach 2024 report found that organizations using AI and automation in their security operations identified and contained breaches 108 days faster than those without. For emails that pass every authentication check, the speed difference between "detected by community intelligence" and "detected after credential compromise" is measured in minutes, not months.
Authentication is a necessary layer. It is not a sufficient one. CISA has warned that email authentication standards are necessary but not sufficient for preventing sophisticated phishing. When attackers operate from within legitimate systems, or when compromised accounts send through authorized mail relays, SPF, DKIM, and DMARC become stamps of approval on malicious content.
The detection surface for this class of attack lives in behavioral anomalies: mixed-protocol asset loading, template assembly errors, sender relationship history, and the collective judgment of security analysts who have seen the pattern before. Organizations that rely exclusively on authentication-based filtering are operating with a structural blind spot that grows larger as attackers move further up the trust chain.
The email that passed every check still got caught. But only because something beyond authentication was watching.