Microsoft 365 & Okta Phishing: New Scam Targets SSO Users

3 mins read Praveen Shivkumar

I’ve lost count of how many times I’ve seen phishing evolve right under our noses. Just when you think you’ve got the filters tuned and the awareness posters plastered across the office, attackers find a new way to slip past. The latest campaign targeting Microsoft 365 and Okta single sign-on (SSO) is one of those “here we go again” moments.

Why I’m Writing About This

I’ve been running hybrid setups for years—Exchange on-prem with Office 365, Okta layered in for federated logins. It’s a neat combo when it works, but it’s also a juicy target. So when Datadog Security Labs dropped their findings about attackers hijacking session tokens through fake HR emails, I paid attention. Salary updates as bait? That’s devious, and not gonna lie, I’ve clicked faster on “bonus letters” than on patch advisories.

How the Attack Plays Out

Picture this:

  • You get an email that looks like it’s from ADP or Salesforce HR. Subject line screams urgency: “Action Required: Review 2026 Salary and Bonus Information.”
  • The link takes you to what looks like your company’s Okta login page. The branding, the tenant-specific URL—it all checks out.
  • But behind the curtain, a script called inject.js is quietly logging keystrokes and stealing session tokens.

I tested something similar in a dev lab once, and the fake login page was so convincing I had to triple-check the certificate chain. The scary part? These guys are using Cloudflare to mask their infrastructure, so your usual “block the domain” trick doesn’t cut it.

The Gotchas I’ve Seen

Back in 2019, I tried a phishing simulation on Server 2016 users. Half the team fell for a fake payroll update. The install screen for the “security patch” just sat there—black, silent, almost mocking me. That memory came rushing back when I read about this new campaign. Same psychology, just sharper tools.

Most guides will tell you to “train users not to click.” Sure, but in reality, people click. What I’ve found more effective is layering conditional access policies—if the login comes from an unexpected device or location, force MFA again. It’s annoying, but it saved me once when a contractor’s account was compromised.

Lessons Learned

  • Don’t trust branding alone. Attackers are preserving Okta customizations, so the page looks legit.
  • Encrypted PDFs with passwords in the email body are still a thing. I used to dismiss those as old-school, but they’re back in play.
  • Session hijacking beats password theft. Even if you rotate creds, the stolen token keeps the attacker logged in.

Final Thoughts

It was a rainy Tuesday in Bengaluru when I finally got my DNS role working after a typo-induced meltdown. That same persistence applies here: you can’t just rely on one layer of defense. Phishing will keep mutating, and our job is to stay one step ahead—or at least not three steps behind.

Ever spent an hour debugging a typo in a PowerShell script, only to realize the real issue was trust? Welcome to my world.

Praveen Shivkumar

Praveen Shivkumar

With over 12 years of experience in IT and multiple certifications from Microsoft, our creator brings deep expertise in Exchange Server, Exchange Online, Windows OS, Teams, SharePoint, and virtualization. Scenario‑first guidance shaped by real incidents and recoveries Clear, actionable breakdowns of complex Microsoft ecosystems Focus on practicality, reliability, and repeatable workflows Whether supporting Microsoft technologies—server, client, or cloud—his work blends precision with creativity, making complex concepts accessible, practical, and engaging for professionals across the IT spectrum.

📝 Leave a Comment