Microsoft 365 and Azure Social Engineering Threats You Need to Know About

Summarize with:

Vishing Google Report

Key Takeaways

  • Two active attack campaigns (Kali365 and Storm-2949) are targeting Microsoft 365 and Azure environments right now.
  • Both bypass MFA. Neither uses malware. Both exploit legitimate Microsoft features to stay invisible.
  • Storm-2949 turned a single social engineering call into a full Azure breach: SharePoint, OneDrive, Key Vaults, SQL databases, and virtual machines.
  • Kali365 is a turnkey PhaaS kit available on Telegram. Low-skill attackers can run MFA-bypass campaigns out of the box.
  • The entry point in both cases was a human decision. Technical controls help, but user awareness training is the most direct mitigation.

The Context: Attackers Have Stopped Needing to Hack In

Threat actors targeting Microsoft 365 and Azure have largely moved past malware and credential stuffing. The new playbook is simpler: find a legitimate Microsoft feature, combine it with a social engineering lure, and blend into normal IT activity until the damage is done.

Two campaigns documented in May 2026 show exactly how this works. The FBI warned of Kali365, a Phishing-as-a-Service platform that steals OAuth tokens and grants permanent M365 access without ever asking for a password. Microsoft detailed how Storm-2949 used a fake IT support call and one MFA approval to move laterally across an entire Azure environment.

💡 Neither attack required a software vulnerability. Both started with a user making a reasonable-seeming decision under false pretenses.

Ongoing Attacks

Kali365: A Phishing Kit That Steals M365 Access Without Your Password

Kali365 is a PhaaS platform distributed via Telegram since April 2026. It gives low-skill attackers everything they need to run an MFA-bypass campaign: AI-generated lures, automated templates, tracking dashboards, and OAuth token capture. No technical expertise required.

Kill chain:

  1. Phishing email impersonates a trusted cloud service and instructs the recipient to enter a device code on a legitimate Microsoft page
  2. The victim visits a genuine Microsoft URL and pastes in the code; unknowingly authorizing the attacker's device
  3. Kali365 captures the resulting OAuth access and refresh tokens
  4. The attacker gains persistent access to Outlook, Teams, and OneDrive. No password needed, no further MFA required

Microsoft's device code flow is a legitimate feature built for devices that can't display a sign-in page. Kali365 exploits it against everyday enterprise users. Because the victim completes the step on a real Microsoft page, standard MFA is already satisfied before the attacker collects their token.

Read more about how phishing kits are evolving:

"The InboxPrime Case: AI-Based Phishing Kits, Or The New Frontier of Credential Theft."

Storm-2949: One Phone Call, One MFA Approval, One Full Azure Breach

Storm-2949 is a financially motivated threat actor that turned a single social engineering interaction into a sprawling Azure data exfiltration; without deploying a single piece of malware.

Kill chain:

  1. Attacker impersonates an internal IT helpdesk rep and contacts a targeted user (IT staff or senior leadership)
  2. User is convinced to approve an MFA prompt as part of a "routine password reset"
  3. Attacker uses Microsoft SSPR to reset the account password, strip the user's authentication methods, and register their own device; locking out the legitimate user
  4. The process is repeated on three more accounts with privileged Azure RBAC roles
  5. With those identities, the attacker moves freely: OneDrive and SharePoint bulk downloads, Azure Key Vault secret extraction, SQL database access, Storage account exfiltration, and ScreenConnect installed on virtual machines for persistent remote access

The entire operation looked like normal administrative activity. Detection required correlating signals across identity, M365, and Azure simultaneously. The social engineering call was the only vulnerability that mattered. Everything else followed from one user approving one MFA prompt they didn't initiate.

Read more about how attackers abuse MFA and identity systems:

"VENOM: Inside a C-Suite Credential Theft Campaign That Neutralizes MFA"

What You Should Do: Action-Oriented Prevention

That's the first question to answer. Both attacks begin with social engineering, a phishing email or a fake IT support call. Technical controls don't stop a user who genuinely believes they're helping IT reset their account. Phishing simulation that includes device code lure scenarios trains employees to pause before they paste a code into any site, regardless of how legitimate it looks.

Not for these attacks. Standard push-based MFA is satisfied as part of the Kali365 token theft flow, and Storm-2949 tricks users into approving prompts themselves. Phishing-resistant MFA (FIDO2 keys or passkeys) closes the gap: it's domain-bound and can't be replayed by an attacker holding a captured token.

Yes, if accounts can trigger a reset without a pre-registered MFA method. Require existing MFA registration before SSPR can be initiated to block the Storm-2949 entry vector.

Storm-2949's blast radius (from one account to Key Vaults, SQL, Storage, and VMs) was directly enabled by over-permissioned RBAC roles. Audit custom Azure RBAC assignments, apply least privilege, and restrict high-risk operations (publishing profile retrieval, VM extension deployment, Run Command) to accounts that genuinely need them.

A new MFA device registration immediately after a password reset is a high-confidence indicator of compromise. Mass file downloads across multiple OneDrive accounts in a short window is another. Correlating SSPR events, authentication anomalies, and cloud resource access in one view is what catches these campaigns before they spread. Threat monitoring gives security teams that cross-domain visibility.

If not, do it. Create a Conditional Access policy blocking device authentication codes for all users, with tightly scoped exceptions only for processes that require it. This is the single most direct mitigation for Kali365-style attacks.

See How Your Team Holds Up Against Social Engineering

Both attacks in this article started the same way: a user made a decision that an attacker needed them to make. The most direct way to reduce that risk is to test and train your users before a real attacker does.


Can your team spot a vishing attack?

Test them and find your blind spots before attackers do.

Don't miss an article

No spam, ever. We'll never share your email address and you can opt out at any time.