The Blocked-Messages Alert That Routed Through Google and Knew Your Email Address Before You Clicked

Six blocked messages. That is the entire threat claim in this email's body. No attachment. No fabricated invoice. No executive impersonation. Just a terse Microsoft 365 notification, a banner, and a red button: VIEW BLOCKED MESSAGES.

What sat behind that button was a three-layer misdirection: a trusted Google redirect, a recipient-personalized URL, and a throwaway domain that had existed for only a handful of days. The email passed boundary authentication checks. It reached an employee's inbox. IRONSCALES Adaptive AI caught it before anyone clicked.

The Urgency Pretext: Microsoft 365 Blocked Messages

The message opened with a bold Microsoft-365 banner: oversized, red, and visually dominant. Beneath it, a short note told the recipient that six incoming messages had been blocked due to a server error and that unwanted storage in the trash was being cleared "to protect mail accuracy." The tone was matter-of-fact, not dramatic. Real Microsoft system alerts carry exactly this kind of dry, administrative language.

The phishing message arrived with the subject line "Notifications", deliberately bland to avoid triggering keyword-based filters. The sender display name was not a human name but a long, URL-encoded query string embedded in the From header, a classic sign of automated template use. The sending domain was afisweden[.]se, a legitimate Swedish organization's domain that appears to have been abused as a relay rather than purpose-built for the campaign.

One additional detail undercut the Microsoft branding immediately: the email footer carried full legal boilerplate from a freight brokerage company. Below the alert, a lengthy thread from an unrelated community organization appeared: a realistic-looking set of forwarded replies, apparently appended to give the message conversational legitimacy. Neither the footer nor the thread had any connection to Microsoft or to the recipient.

According to the Verizon 2026 Data Breach Investigations Report, 39% of breaches involve credentials. Urgency-driven notification lures are among the most consistent mechanisms for initiating that theft.

The Mechanics: Google as a Trust Proxy

The CTA resolved to a maps.google[.]ch redirect URL. The q= parameter inside it pointed to the real destination: a path on dewabets[.]org. The key addition was a second parameter appended to the redirect: the recipient's address, base64-encoded, ensuring that the harvest page, if active, would arrive pre-populated with the target's username.

This technique is well-documented. The Microsoft Digital Defense Report 2024 notes that attackers consistently abuse trusted infrastructure, including major platform redirect services, to route malicious links through domains that appear reputable to both end users and automated scanners. When a reputation engine resolves this link, it reads google.ch. The actual destination, dewabets[.]org, gets no scrutiny at hover time.

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

The base64-encoded recipient component amplifies the technique. Rather than presenting a generic credential harvest page, the landing page was designed to receive a pre-decoded username and render it in the login form automatically. From the victim's perspective, a page that already knows your email address looks legitimate. It implies you authenticated somewhere earlier. The FBI IC3 2024 Annual Report documents credential theft as one of the highest-frequency cybercrime vectors, precisely because personalization removes the friction that would otherwise cause victims to hesitate.

The Destination: A Domain Registered Days Before the Campaign

dewabets[.]org was registered with IONOS SE a matter of days before this campaign ran. Its name servers pointed to generic shared hosting infrastructure. No public registrant details were visible. By the time IRONSCALES analyzed the link, the domain had already cycled to a suspended state, consistent with short-burst phishing infrastructure: activate, run the campaign, go dark.

A credential harvesting page on a brand-new domain presents a specific detection problem. Reputation-based systems score domains on history. A domain with no history has a neutral score. It is, in effect, invisible to reputation engines at the moment it matters most. The CISA guidance on recognizing phishing identifies newly registered domains as a consistent indicator of malicious intent, but only if that signal is actually checked.

Authentication: The Origin Tells the Real Story

The message arrived at the boundary with a clean authentication result. SPF, DKIM, and DMARC all showed pass verdicts at delivery. But those verdicts reflected the last hop in the relay chain, Microsoft's outbound protection infrastructure, not the origin.

The first recorded hop shows a different picture. The originating IP, 148.163.76[.]111, produced an SPF failure against afisweden[.]se at that initial relay. Its reverse DNS resolved to therdpsdaddy[.]store, a hostname unrelated to any Swedish organization. At that first hop, no DKIM signature was present.

The clean boundary result emerged because Microsoft's relay infrastructure re-signed and forwarded the message, and that re-signing passed. Downstream DMARC validation saw a Microsoft-attested signature and passed. This is a known gap in how boundary authentication is interpreted: a pass at the last hop can mask a failure at the origin. The MITRE ATT&CK framework categorizes this delivery pattern under T1566.002 (Spearphishing Link) with infrastructure abuse as the enabling mechanism.

DMARC is a necessary control. It is not sufficient when legitimate relay infrastructure sits between the attacker's origin and the boundary check.

Detection

IRONSCALES Adaptive AI flagged this message at 90% confidence, labeling it Credential Theft. The detection did not depend on the authentication result. Themis identified the link structure (a Google redirect wrapping an unknown destination with an encoded recipient parameter) as a behavioral pattern consistent with credential phishing. Community signals from similar-pattern incidents across the IRONSCALES customer base reinforced the verdict. The message was quarantined automatically, before any click.

This is the detection model that boundary-dependent systems miss. A rule that asks "did SPF pass?" would have released this message. A behavioral model that asks "does this link structure match known phishing campaign patterns?" does not.

Defensive Takeaways

• Treat Google redirect URLs as opaque until resolved. A link that begins with maps.google[.]ch/url?q= is not a Google link. Decode the q= parameter and score the destination domain, including registration age.
• Flag base64 or encoded parameters in email CTAs. Legitimate transactional mail rarely needs to encode a recipient's address into a URL. This pattern is a targeted-phishing indicator, not normal personalization.
• Check the first Received hop, not just the boundary result. An SPF pass at delivery can coexist with an SPF fail and missing DKIM at origin. Inspect the full relay chain.
• Score domain age independently. Destination domains registered within days of the campaign date warrant elevated suspicion even when the link itself appears to resolve cleanly.
• Behavioral detection is not optional. When authentication passes but behavioral signals point to phishing, behavioral signals should win.

---

Indicators of Compromise

---

MITRE ATT&CK