Microsoft 365 red team.
Because MFA is being transferred, not broken.
The campaigns hitting Indian financial institutions do not defeat multi-factor authentication. They persuade someone to approve a genuine Microsoft prompt, take the resulting token, register a device, and stay. Your sign-in log records the MFA requirement as satisfied — because it was. We simulate that end to end and show you where it stops.
The gap
A clean pentest report and an open tenant are not contradictory.
Almost none of the Microsoft 365 attack surface is infrastructure you own or code you wrote. It is tenant configuration: which Conditional Access policies exist, which populations and client-app types they actually cover, which authentication flows bypass them, what a registered device can do, and what your audit configuration records when someone reads a file rather than downloading it.
A network penetration test does not go near any of that, and it is not supposed to. So the annual VAPT comes back clean, and the tenant is still one approved prompt away from a business email compromise.
Why now
The technique industrialised.
Device-code phishing is no longer bespoke tradecraft. It is sold as a subscription service, distributed through Telegram, and packaged with generated lures — the FBI issued a public service announcement on exactly this in May 2026. Separately, public research has documented M365 password-spraying campaigns on the order of 81 million login attempts.
Commodity tooling means the question is no longer whether your organisation is interesting enough to target. It is whether your tenant configuration holds when someone runs the standard playbook against it.
What we simulate
Six attack paths, each publicly documented.
We test the chain, not the individual tricks — initial access through to persistence and collection, because the controls that fail are usually further along than people expect.
Device-code phishing and OAuth token capture
The victim is led to a genuine Microsoft sign-in page and asked to approve a device code. Because the approval happens on Microsoft's own domain, MFA is not defeated — it is transferred. The attacker walks away with access and refresh tokens without ever seeing a password.
Why it is tested separately: A conventional phishing test measures who typed a password into a fake page. This measures who approved a real one, which is a different question with a much worse answer.
Publicly documented — FBI IC3 PSA I-052126-PSA
Rogue device registration and persistent refresh tokens
Within seconds of token capture, an attacker can register a device into the tenant and obtain a Primary Refresh Token — persistence that survives a password reset, because it never depended on the password.
Why it is tested separately: This is the control most incident responses miss. Resetting credentials and forcing MFA re-enrolment feels like containment and is not.
Publicly documented — Microsoft Threat Intelligence, Feb 2025
Legacy and non-interactive authentication paths
Password spraying and credential stuffing against authentication flows that Conditional Access does not cover. Public reporting has documented a single campaign generating on the order of 81 million login attempts against M365 tenants.
Why it is tested separately: Conditional Access is usually written for interactive browser sign-in. We test what happens on every other path, which is where the coverage gaps live.
Publicly documented — Huntress; public reporting, 2026
Session token replay
Authenticated session tokens lifted by infostealer malware, malicious browser extensions or cross-site scripting, then replayed. Authentication is already complete, so MFA is never re-evaluated.
Why it is tested separately: Determines whether your detection can tell a replayed session from a real one — most cannot, because the sign-in log looks satisfied.
Publicly documented — Microsoft Threat Intelligence
Post-access collection through Graph
Once inside, mailbox and file access via the Graph API rather than a browser: keyword search across mail, previews and page views of document libraries, and reading rather than downloading — activity that download-centric audit rules do not record.
Why it is tested separately: Tests whether your logging would have evidence at all. Repeatedly the answer is that exfiltration happened in a way the audit configuration never captured.
Publicly documented — Microsoft Threat Intelligence, Feb 2025
Mailbox rule persistence and internal trust abuse
Hidden or deliberately unremarkable inbox rules that auto-file and mark-as-read, concealing replies from the mailbox owner; and onward mail sent from a genuine internal account, which passes SPF, DKIM and DMARC because it is legitimate.
Why it is tested separately: Your mail security stack cannot flag this, by design. The only controls that work are behavioural, and this is how you find out whether you have them.
Publicly documented — FBI IC3 PSA I-052126-PSA
What you get
Six deliverables, none of them a scanner dump.
Attack-path narrative
The kill chain we achieved, step by step, with the identity artefacts at each hop — not a list of findings ranked by CVSS.
Conditional Access coverage matrix
Every policy against every user population, application and client-app type, with the gaps named. This is usually the single highest-value artefact.
Detection and logging gap report
What we did that produced no alert, and what your audit configuration did not record at all. Mapped to the sign-in and audit log fields that should have carried it.
Tenant hardening plan
Prioritised, with the specific policy changes — phishing-resistant authenticators, device-code flow restriction, legacy-auth blocking, device-compliance enforcement, sharing and audit configuration.
Purple-team walkthrough
A structured session with your SOC covering every technique used, what should have fired, and how to build the detection. Often the most valuable part of the engagement.
Regulator-ready evidence pack
Scope, methodology, findings, closure tracking and auditor independence, in the form a supervisory review or an IT Committee submission expects.
Where it lands in your obligations
No regulator names Microsoft 365. Your tenant is still in scope.
Indian regulators write requirements against control objectives, not vendor products, so you will not find a circular ordering you to red team M365. What you will find is scope language that already covers it: an internet-facing, business-critical, cloud-hosted identity and collaboration platform is a critical information system by any reading.
- RBI-regulated commercial banks — inside the mandatory VA/PT obligation for critical and internet-facing systems, and the documented-approach duty that expressly extends to cloud-hosted systems.
- SEBI-regulated entities — scopable within the half-yearly red teaming CSCRF DE.DP.S4 requires of MIIs and Qualified REs.
- CERT-In CISG-2025-02 — maps to several named engagement types, including red team assessment, cloud security testing and endpoint security assessment, inside the annual comprehensive ICT audit.
Common questions
Before you scope this.
How is this different from our annual VAPT?
Scope and plane. A network or application penetration test evaluates infrastructure you own and code you wrote. Almost none of the M365 attack surface is either — it is a tenant configuration problem living in an identity plane, and the attack paths that matter run through authentication flows, OAuth consent, device registration and Conditional Access coverage. A perimeter scan never touches them. We regularly find tenants that passed a clean external pentest and would fall to a device-code lure the same afternoon.
Do we need this if we already have MFA on everything?
MFA is necessary and it is not sufficient here. The dominant technique in current campaigns does not break MFA, it transfers it: the victim completes a genuine Microsoft challenge and hands the resulting token to the attacker. The sign-in log then records that the MFA requirement was satisfied, because it was. Phishing-resistant authenticators — FIDO2/WebAuthn or certificate-based — are the control that actually addresses this, and part of what we test is how far you are from being able to enforce them.
Will you phish our staff?
With written authorisation, yes — and that is the point, because the technique under test is a consent decision rather than a password entry. We agree the target population, the lure style and the escalation contacts in advance, and we keep an out-of-band channel open with your CISO so that if your SOC declares an incident we can confirm or deny within minutes. We do not run lures that would cause customer-facing harm or that misuse a real third party's identity.
Is our tenant safe to test in production?
Yes, and production is the only place the answer means anything — a test tenant does not share your Conditional Access exceptions, your legacy application estate or your sharing history. We work to a pre-agreed rules-of-engagement document: no destructive actions, no access to customer data beyond proof of reachability, no persistence left behind, and a documented rollback for every change. Any artefact we create, including registered devices and mailbox rules, is inventoried and removed at the end.
What does this satisfy from a compliance standpoint?
For RBI-regulated commercial banks it sits inside the mandatory VA/PT obligation for critical and internet-facing systems, and the documented-approach duty that expressly extends to systems hosted in a cloud environment. For SEBI-regulated entities it can be scoped as part of the half-yearly red teaming that CSCRF DE.DP.S4 requires of MIIs and Qualified REs. Under CERT-In's CISG-2025-02 it maps to several named engagement types including red team assessment, cloud security testing and endpoint security assessment. We set the mapping out explicitly in the report — see our note on what is actually mandated for the honest version of that picture.
How long does it take?
A focused identity attack-path assessment runs 2–3 weeks. A full objective-based red team using M365 as the initial access route runs 6–10 weeks, because time-on-target is the variable that makes it realistic. Most BFSI organisations start with the focused assessment, because it answers the urgent question quickly and its findings usually reshape the scope of anything larger.
Who conducts the engagement?
Full-time senior consultants, declared to CERT-In. We are CERT-In empanelled and have been since 2008. CERT-In's own audit guidelines are explicit that auditing organisations should not field freelancers, interns, freshers, moonlighters, third-party consultants or staff serving notice — and that verifying this is the auditee's responsibility. Ask us for that evidence, and ask everyone else bidding.
We received an advisory about this. Can you work from it?
Yes. Bring it to the scoping call and we will build the engagement around its recommended actions, so the output maps directly onto what you have been asked to address. If it carries restricted handling markings we will treat it accordingly — we will not reproduce it, quote it, or discuss its contents outside your team, and you should be wary of any vendor who does.
Find out before someone else does.
A scoping call takes thirty minutes and gives you a defensible answer on whether your tenant configuration holds. Bring your advisory if you have one.