Fake IT Verification Notice Spoofs Internal M365 Routing to Deliver Cloudflare-Proxied Credential Harvest

# Fake IT Verification Notice Spoofs Internal M365 Routing to Deliver Cloudflare-Proxied Credential Harvest

An employee at an industrial-automation and distribution firm received what looked like an internal IT notification: "Your email account will be blocked in 48 hours unless you verify it now." The Sender field pointed to a SystemMailbox in their own organization's Microsoft 365 tenant. The visible From address was an external domain most recipients would never think to inspect. The link behind the "VERIFY EMAIL" button included their email address pre-loaded in the URL query string.

What the Attack Looked Like: Internal Branding, External Origin

The message was crafted to mimic the appearance of an automated IT governance alert from within the organization. The Sender header and Reply-To both referenced a SystemMailbox{...} address in the target organization's onmicrosoft.com tenant, which is the kind of automated mailbox designation that M365 uses for internal workflow notifications. The visible From header, however, read an external sender domain (anonymized), an external domain registered under privacy protection with no publicly verifiable business identity.

The body contained a 48-hour account-block threat, grammatical irregularities, and a single prominent "VERIFY EMAIL" button. The CTA resolved to hxxps://online[.]characteristics[.]today/introduction[.]html?plain=[recipient-email-redacted]. The recipient's email address was embedded in the plain= parameter, a technique that personalizes the landing page at the moment of click to pre-populate a fake login form and increase the appearance of legitimacy.

Why the Internal-Routing Disguise Is Effective

The technical detail that makes this attack notable is the SystemMailbox routing. Most users, and many filters, look at the Sender field and the display context of a notification rather than parsing the From header. A SystemMailbox designation in the onmicrosoft.com tenant reads as authoritative to anyone familiar with Microsoft 365's internal messaging. It creates the visual impression that the organization's own IT systems generated the alert.

The underlying From address, an external sender domain (anonymized), was the actual origin. The message traversed Microsoft 365's own infrastructure (internal Exchange transport hops) before reaching the recipient mailbox, which is consistent with cross-tenant routing patterns abused by attackers who submit messages through hosted approval or relay workflows in the target tenant.

Impersonation attacks that borrow legitimate internal routing signals are harder to catch with rules-based filtering because the message touches real organizational infrastructure. The malicious content is the destination URL, not the sending path.

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

How It Was Caught: Malicious URL Verdict and Header Identity Mismatch

The link online[.]characteristics[.]today was flagged malicious in the incident record. The domain resolves through Cloudflare proxying (172[.]67[.]217[.]195, 104[.]21[.]17[.]3), which obscures the real hosting origin. At analysis time, the landing page returned HTTP 404, indicating either a takedown, a time-limited campaign, or a gated page that only activates for known targets. The embedded recipient parameter in the URL (plain=[recipient-email]) is a standard indicator of targeted credential harvesting regardless of whether the form was reachable.

Themis (our Adaptive AI) surfaced the header identity mismatch (external From vs. internal SystemMailbox Sender) as a structural anomaly, combined it with the malicious link verdict, the 48-hour urgency language, and the high sender-risk score for [external-sender-domain] as a first-time external sender. No individual signal was sufficient alone; the behavioral cluster produced the phishing classification.

Defender Takeaways: Inspect the From Header, Not Just the Sender Display

This attack exploited the gap between what a user sees (internal Sender routing) and what the message headers record (external From address). Defenders should:

1. Train users to distinguish From vs. Sender. IT departments do not send email-verification notices from external domains. If a "your account will be blocked" notice comes from anything other than a known internal IT address, it is a social-engineering attempt.
2. Treat recipient-email in URL parameters as a strong IOC. Legitimate IT self-service portals do not pre-embed user credentials in public URLs. A ?plain= or ?email= parameter containing the recipient's address is a targeting signal.
3. Block credential harvesting lures that use urgency + single verification CTA. The "48-hour block" pretext is a well-documented template. Anti-phishing awareness programs should cover it explicitly.

See the MITRE ATT&CK technique references at https://attack.mitre.org/techniques/T1566/ and https://attack.mitre.org/techniques/T1598/.

Indicators of Compromise