Topic starter
27/06/2026 1:56 pm
TL;DR: A Teams-themed phishing campaign uses spoofed meeting invites, a fake Microsoft login path, and OAuth consent to bypass MFA, persist after password changes, and keep access visible as legitimate in audit logs, according to Abnormal AI.
Editorial analysis by NHI Mgmt Group, based on content published by Abnormal AI: “Fake Microsoft Teams Meeting Invite Used to Deploy Malicious OAuth App”.
Key questions
Q: What breaks when Teams phishing is used to drive OAuth consent instead of stealing passwords?
A: Password-centric phishing controls break because the attacker is not trying to capture a secret.
Q: Why do OAuth grants create risk even after offboarding, password resets, or MFA re-enrollment?
A: OAuth grants are separate authorization objects from user credentials.
Q: What are the signs that a Microsoft 365 OAuth app is being abused?
A: Look for unverified applications, consent requests that ask to maintain access, unexpected mailbox access patterns, and authorisations that appear in logs as normal delegated activity but have no business justification.
Practitioner guidance
- Audit OAuth consent grants Review Microsoft 365 third-party app permissions for unverified applications, long-lived grants, and tenants with broad consent rights.
- Tighten calendar-entry handling Detect and remove malicious meeting invites and embedded calendar events after quarantine, because deleting the email does not necessarily remove the calendar artefact or the user-facing lure.
- Block unsanctioned Azure Web App redirect paths Flag links that resolve through unapproved *.azurewebsites.net domains and inspect redirect chains that begin on legitimate Microsoft pages but end on external consent requests.
Bottom line: The article shows how a trusted Teams-style message can be converted into persistent cloud access through OAuth consent.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
27/06/2026 3:28 pm
OAuth consent has become an access-control boundary, not just a user-experience prompt. This attack succeeds because the real security decision happens inside Microsoft’s authorisation flow, after the email layer has already done its job. Traditional phishing controls are looking at the wrong control point when the compromise is created by delegated app permission rather than stolen credentials. The practitioner conclusion is that consent governance now sits alongside login governance.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: How should teams respond when a user consents to a malicious app?
A: Treat it as an identity incident, not just a phishing event. Revoke the application grant, inspect mailbox and calendar artefacts, review the scope of delegated permissions, and check whether the app has been used for impersonation or lateral phishing. The goal is to remove the access state, not only the message.
👉 Read our full editorial: Microsoft Teams OAuth phishing turns meeting trust into cloud access
This post was modified 4 days ago by NHI Mgmt Group