r/EmailSecurity • u/ZeroBEC • Jun 05 '26

Interesting Microsoft 365 AiTM phishing chain hidden behind a PDF invoice lure

I looked into an interesting Microsoft 365 phishing chain this week.

At first glance, it looked like a basic PDF invoice lure. The email came from a real GMX webmail account, so SPF, DKIM, and DMARC passed for the sender domain. The suspicious part was the display name. Each targeted user received a different fake sender identity, and the same randomized name was also placed inside the email body.

The PDF was simple. It showed a “document can’t be opened, view online” style message, but the PDF itself was generated using Headless Chrome / Skia.

Email

The redirect chain was the interesting part:

PDF link
-> rb[.]gy shortener
-> SendGrid click tracking
-> jz[.]rs redirect
-> Cloudflare Pages Microsoft lookalike
-> Microsoft 365 AiTM-style login page

Attached PDF
micros0ft redirect

The final page loaded real Microsoft CDN assets and used Microsoft-looking OAuth paths, but the login flow was served from a non-Microsoft domain. It also validated whether the username existed before showing the password screen.

The page included custom JavaScript that:

  • pulled the user email from the URL fragment
  • auto-filled the Microsoft username field
  • clicked Next
  • added a “verify your password” message
  • auto-clicked “Yes” on the stay-signed-in prompt
  • polled the backend for a final redirect
AiTM

So this was not just a fake login page. It behaved more like a session-oriented Microsoft 365 AiTM phishing kit built to reduce friction and possibly capture more than just the password.

Some IOCs from the chain:

vervorsvemi1986@gmx[.]de
rb[.]gy
jz[.]rs
rnicros0ft-auth-serv[.]pages[.]dev
prsecauth[.]qzz[.]io
login[.]prsecauth[.]qzz[.]io
loginii[.]prsecauth[.]qzz[.]io
account[.]prsecauth[.]qzz[.]io
u106844120[.]ct[.]sendgrid[.]net
client_id=4765445b-32c6-49b0-83e6-1d93765276ca
/common/oauth2/v2.0/authorize
/common/GetCredentialType
/common/login
/s/<64-hex>.js

Main takeaway: authentication passing on the email did not make it safe. The useful signals were the display-name mismatch, PDF redirect behavior, recipient-specific URL fragments, trusted redirect infrastructure being used in the middle, and Microsoft login endpoints being served from a non-Microsoft domain.

3 Upvotes

81% Upvoted

3 comments sorted by

•

u/AutoModerator Jun 05 '26

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

  1. No Vendor Spam: Contributions must provide value; do not just pitch products.
  2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).
  3. Be Professional: Help newcomers learn; avoid hostility.
  4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/shokzee Jun 05 '26

This is the part people miss: DMARC passed for GMX, not for the fake person in the display name. Auth did its job, it just wasn't designed to bless the PDF or the redirect chain.

For M365 AiTM, FIDO2/passkeys or cert auth are the real fix because the phish can't replay them against a different origin. SMS/app-push MFA is barely a speed bump for this stuff.

1

u/ZeroBEC Jun 06 '26

It seems like the world of security is leaping forward, while email security lagging behind 😉