On 9 September 2026, Microsoft Security Research published details of a campaign that should worry every business running Microsoft 365. It does not start with malware, a firewall flaw or an unpatched server. It starts with a phone call.

Quick answer: Attackers ring or text an employee on their personal mobile, claim to be the company IT helpdesk, and insist a passkey, MFA or SSO setting must be updated right now. The employee is walked onto a look-alike Microsoft sign-in page, the attacker captures a live session token, and within minutes they are reading SharePoint, OneDrive and mailboxes through the Microsoft Graph API. Microsoft says the activity has been running since May 2026. Standard MFA does not stop it. Phishing-resistant MFA, tight Conditional Access and a hard rule about how helpdesk resets are verified do.

How the attack actually works

Microsoft describes a consistent eight-step sequence. The details of the domains and IP addresses change weekly; the sequence does not, which makes it the thing worth defending against.

  • Step 1 — the call. The victim gets a call or SMS on their personal phone from someone claiming to be internal IT. There is urgency: update your passkey or MFA configuration now, or lose access. Attackers research targets beforehand from public professional profiles, so the pretext sounds informed.
  • Step 2 — the look-alike page. The employee is sent to a page that closely resembles a genuine Microsoft sign-in. A favourite trick is registering a generic domain and putting the target company's name in as a subdomain, so the URL reads convincingly at a glance — Microsoft's own illustrative example is contoso.add-passkey[.]com. Domains are stood up within hours and rotated, giving defenders almost no window to block them.
  • Step 3 — the token, not the passkey. Here is the twist: enrolling a passkey is usually not the attacker's real objective. The passkey story is simply a believable reason to walk the victim through an adversary-in-the-middle (AiTM) phishing flow or a device-code authentication flow. In the AiTM case the attacker proxies the session and captures the token after the victim completes MFA. In the device-code case the victim is persuaded to enter a code on the genuine Microsoft page — which issues a token to the attacker's client. Either way, MFA has been satisfied and bypassed in the same breath.
  • Step 4 — persistence. The attacker's first move after getting in is to register their own MFA method on the account: a new phone number, an authenticator app, or a software OTP token. Future challenges can then be answered without the employee ever knowing.
  • Step 5 — reconnaissance. Within minutes the session enumerates My Apps, My Profile, My Sign-Ins and approval workflows, then moves through Microsoft Graph to map users, groups, directory roles, service principals and SharePoint sites. In one investigated intrusion, the attacker had mapped internal applications and sensitive files inside the first hour.
  • Steps 6–8 — collection and exfiltration. High volumes of FileAccessed and FileDownloaded events across SharePoint Online and OneDrive, and in some cases mailbox content pulled through Exchange REST APIs. Microsoft saw the python-httpx user agent on much of it — automation, not a human clicking. Crucially, the pace was deliberately slow: generally fewer than 1,000 files or emails an hour, sustained over hours or days, precisely so it looks like ordinary business usage.

Microsoft attributes the initial-access activity to several tracked groups including Storm-3121 and Storm-3032. In a smaller number of cases, attackers used an already-compromised employee account to send the same passkey lure over Microsoft Teams — arriving from a trusted colleague, which pushes engagement rates up sharply.

Why this is a bigger problem in India than it looks

Four things make Indian organisations a comfortable target for this playbook.

Helpdesk culture is informal. In most Indian SMBs and mid-market firms, IT support genuinely does call staff on their personal numbers and genuinely does ask them to change a setting. The attack works because it is indistinguishable from a normal Tuesday.

Personal phones are outside the security perimeter. If the employee opens the phishing link on a personal handset that is not enrolled in endpoint management, the event leaves no endpoint telemetry at all. Microsoft notes that in many investigations the employee's memory of a phone call is the only evidence of how the breach began.

Most tenants run basic MFA and stop there. App-push or OTP MFA is treated as the finish line. Against a real-time proxy page, it is not.

The data sitting in SharePoint and OneDrive is now regulated. Under India's DPDP Act, personal data pulled out of a compromised mailbox or document library is a reportable breach with real financial exposure. An identity compromise is no longer just an IT problem — it is a compliance event. Our DPDPA compliance guidance covers what notification actually requires.

Microsoft disclosed a second, parallel campaign on 13 September 2026: attackers abusing third-party email delivery infrastructure to blast financial-fraud messages impersonating chief executives. Different mechanism, same target — the finance and identity layer of your business, not your firewall.

What to change this week

None of the following requires new licences for most tenants. All of it is configuration and process.

  • Enforce phishing-resistant MFA via Conditional Access. FIDO2 security keys, genuine passkeys or Windows Hello for Business. These are bound to the real domain and simply will not authenticate against a look-alike, which breaks the AiTM step outright. Start with admins, finance and leadership.
  • Block the device-code and authentication-transfer flows in Conditional Access unless you have a documented business need. Very few Indian SMBs do. This removes an entire attack path.
  • Lock down security-info registration. Require a managed, compliant device and a trusted location before anyone can add or change an MFA method, force a fresh interactive sign-in, and block registration entirely when sign-in risk is high. This is the single control that would have stopped Step 4.
  • Write a helpdesk verification rule — and alert on every reset. No credential or MFA reset happens without verifying identity through a defined, out-of-band process. Every such reset generates an alert someone reads.
  • Restrict unmanaged devices to web-only sessions with no download or sync, and turn off anonymous sharing links in SharePoint and OneDrive.
  • Restrict user consent for applications and review service principals holding high-privilege Graph permissions such as Mail.Read, Files.Read.All and Directory.Read.All.
  • Turn on Microsoft Graph activity logs and mailbox auditing, and alert on newly registered authentication methods, bulk directory enumeration and abnormal file or mail volume. Without these logs, an investigation later has nothing to work with.
  • Tell your staff about this specific script. Not generic "beware of phishing" — the actual scenario: a call about your passkey, from IT, on your personal phone, that cannot wait. Give them one verified internal number to check against, and make it socially acceptable to hang up.

If you suspect an account is already compromised

Patching mindset does not apply here — there is nothing to patch. Containment is: revoke active sessions and refresh tokens for the identity, reset credentials, remove every authentication method the attacker registered, delete any mailbox rules they created, and require secure re-registration. Then check what the session actually reached — Graph, SharePoint, OneDrive and Exchange signals together — before you decide whether this is a DPDP-reportable breach.

Frequently asked questions

What is passkey phishing?

Passkey phishing is a social-engineering attack in which someone posing as your IT helpdesk calls or texts an employee — usually on their personal mobile — and says a passkey, MFA or SSO setting must be updated immediately or they will lose access. The employee is sent to a page that looks like the normal Microsoft sign-in. In the campaign Microsoft published on 9 September 2026, enrolling a passkey was rarely the real goal: the passkey story was a pretext to walk the victim through an adversary-in-the-middle (AiTM) phishing page or a device-code authentication flow, so the attacker could capture a session token instead.

Does multi-factor authentication stop this attack?

Not on its own. Microsoft observed attackers completing MFA challenges because the victim approved them in real time on a proxy page, or because a device-code flow issued a token to the attacker's own client. Once a valid session token exists, MFA has already been satisfied. What does help is phishing-resistant MFA — FIDO2 security keys, real passkeys or Windows Hello for Business — enforced through Conditional Access, because those credentials are bound to the legitimate domain and cannot be replayed by a proxy.

How would we know a Microsoft 365 account was compromised this way?

The most reliable signal is a new authentication method appearing on an account shortly after an unusual sign-in. Microsoft reported that attackers registered their own phone number, authenticator app or software OTP token to keep access. Other signals: high-volume Microsoft Graph calls enumerating users, groups, roles and sites; SharePoint or OneDrive download spikes; a python-httpx user agent on file access; and Exchange REST activity pulling mail. Exfiltration was deliberately paced — typically under 1,000 files or emails an hour, over hours or days — so it blends into normal usage.

Should Indian businesses still roll out passkeys?

Yes. The attack abuses the word "passkey" as a lure; it is not a weakness in passkeys. Properly enrolled passkeys and FIDO2 keys are among the few credentials that defeat AiTM phishing outright, because they will not authenticate against a look-alike domain. The lesson is to control how enrolment happens — require a managed device, a trusted location and a fresh interactive sign-in before anyone can add or change security information.

Can Invitty help secure Microsoft 365 or Google Workspace for a business in Chennai?

Yes. As an authorized Microsoft 365, Google Workspace and Zoho partner we review tenant configuration, roll out phishing-resistant MFA and Conditional Access, block device-code and legacy authentication flows, tighten app-consent and external-sharing settings, enable Graph and mailbox auditing, and run security-awareness sessions for staff — with GST invoicing and on-site support across Chennai, Bangalore, Hyderabad, Coimbatore and Kochi.

Get your tenant reviewed

Most Microsoft 365 tenants we look at in South India have basic MFA switched on, device-code flow wide open, no restriction on who can register a new authentication method, and Graph auditing switched off. That combination is exactly what this campaign is built for. Book a free Microsoft 365 security review — our engineers will walk your Conditional Access, authentication methods, sharing settings and audit configuration and give you a prioritised fix list.

Related reading: Google's lawsuit against AI-powered phishing syndicates, our comparison of Microsoft 365 vs Google Workspace vs Zoho for Indian businesses, and email security gateways for the layer that catches the messages before they land. If identity is your weak point, a VAPT engagement that includes social-engineering testing is the honest way to find out.

This article summarises publicly available research published by Microsoft Security Research on 9 September 2026 (“Passkey-themed social engineering leads to identity and cloud compromise”) and related reporting on Microsoft's 13 September 2026 disclosure, for awareness purposes. It is accurate as of publication and is not affiliated with, endorsed by, or a statement on behalf of Microsoft.