Office 365 Compromised
Unexplained sign-ins, OAuth apps you did not consent to, mailbox rules nobody created. Call 088 SECDESK (7323375). Senior Dutch responders run full tenant forensics on Azure AD (Entra ID), Exchange, and SharePoint.
We have cleared malicious OAuth consents, forwarding rules, and Power Automate flows for Dutch fintechs, an accountancy firm, and a regional municipality.
Signs your Microsoft 365 tenant is compromised
- 01
Enterprise applications or service principals you did not create
Check Azure AD (Entra ID) Enterprise Applications for recent OAuth consents. Attackers register a malicious app with Mail.ReadWrite or full_access_as_user, get one user to grant it, and then have permanent mailbox access that survives password resets and MFA resets. New service principals with broad Graph scopes are the same signal.
- 02
Impossible-travel sign-ins and sign-ins from residential proxies
Azure AD sign-in logs flag impossible travel, two successful sign-ins from countries no flight could cover. AiTM phishing and token theft also show up as sign-ins from residential proxy ranges (VPN-like IPs in consumer ISP blocks). The authentication details show token-based sign-ins without an MFA prompt, because the MFA already happened on the victim's side.
- 03
Mailbox rules, Power Automate flows, or Exchange transport rules that did not exist last week
Forwarding rules that ship mail to an external address, auto-delete rules that hide replies, Power Automate flows that copy attachments to OneDrive, or tenant-level transport rules that bypass anti-phishing, all appear after a tenant takeover. Check them across the tenant, not just the obvious victim.
Seeing any of these in your tenant? Call 088 SECDESK.
088 SECDESK (7323375)Immediate actions for M365 admins, and how SecDesk handles the incident
Immediate actions for admins
Disable the suspected user and sign them out of all sessions, revoke refresh tokens (Revoke-MgUserSignInSession via Microsoft Graph PowerShell, or the Entra admin action), export the Unified Audit Log for the past 30 days before retention rolls, and do not reset the password yet on admin accounts: a premature reset without session revocation leaves refresh tokens valid for the attacker.
Triage and scope
We pull Azure AD sign-in logs, the Unified Audit Log, Exchange mailbox audit logs, and admin activity logs. We review enterprise applications, OAuth grants, service principals, and recent role assignments. We look for impossible-travel sign-ins, sign-ins without MFA on accounts that require it (which points to token theft or conditional access gaps), and password spray patterns in failed sign-ins.
Containment
We revoke refresh tokens, remove malicious OAuth grants, delete attacker-registered MFA devices, remove mailbox rules and Power Automate flows, and tighten conditional access to block the attacker's location and device. Break-glass accounts are verified clean and kept in reserve. If a Global Admin role was touched, we reset it, rotate the password, and review all other admin roles.
Investigation, what most IT teams miss
We check places a typical IT team does not look: OAuth consent grants at user and tenant level, service principal credentials, Power Automate flows created under the user, SharePoint external sharing that was enabled on a site, Teams guest access, and mailbox delegation permissions. We also check for attacker-added conditional access exclusions, a common persistence trick.
Remediation and hardening
Credentials reset with session revocation, MFA re-registered on clean devices, OAuth app consent policies tightened (admin consent required for risky scopes), conditional access policies reviewed and hardened, Microsoft Defender for Office 365 anti-phishing tuned. If token theft was the vector, we harden session controls through conditional access, token binding, or equivalent protections supported by your environment. We do not touch your existing conditional access policies without walking you through each change.
Reporting and AVG support
You get a written report: timeline, scope, affected data, actions taken, specific recommendations. If personal data was exposed, the report contains what the Autoriteit Persoonsgegevens needs for the 72-hour meldplicht datalekken.
Common M365 attack patterns
AiTM phishing and token theft
The user clicks a phishing link, enters credentials on a spoofed page, and completes MFA. The attacker's proxy captures the session token. From then on the attacker signs in as the user without an MFA prompt. Classic M365 tenant takeover in 2026.
OAuth consent phishing
A user clicks a link that asks them to consent to a third-party app with wide mailbox scopes. The consent is real, the app is malicious, and from then on the attacker reads and sends mail without ever knowing the password.
Password spray against conditional access gaps
The attacker tries one common password across many accounts. On accounts without MFA, or with an MFA exclusion for legacy protocols, the spray succeeds. IMAP, POP, and basic auth are frequent weak points, even in 2026.
Global Admin compromise
The worst case. Once an attacker holds a Global Admin role, they can alter conditional access, register apps tenant-wide, create new admins, and exfiltrate at scale. Recovery requires break-glass accounts, role resets, and a full policy review.
Frequently asked questions
How do we know if our M365 tenant is actually compromised?
Look for enterprise applications or service principals that nobody on your team created, impossible-travel sign-ins in Azure AD logs, mailbox forwarding rules or Power Automate flows that appeared without a ticket, and sign-ins that completed without an MFA prompt on accounts that require MFA. Any one is worth a proper check. Two at once is a confirmed incident.
Is disabling the user account enough?
No. If the attacker consented to an OAuth app, that app holds its own tokens and still has access. If they registered an MFA device on another account, that account is still compromised. If they left a Power Automate flow running, it keeps running. Disabling the user is step one, not the whole response.
What about OAuth apps the attacker added?
We review every enterprise application and every service principal for recent consent, unusual Graph scopes, and credentials (certificates or secrets) added recently. Malicious apps are revoked, their tokens are invalidated, and we tighten the consent policy so users cannot grant wide scopes without admin approval.
Do we need to report this to Microsoft?
Microsoft expects abuse of their platform reported through the Microsoft Security Response Center. It is not a regulatory requirement, but it helps takedown of the malicious app or tenant on their side. We handle the report with you.
Will this affect our Conditional Access policies?
We review every conditional access policy for attacker-added exclusions and tighten gaps that enabled the compromise. We walk you through every change before we make it. Nothing is modified in production without your sign-off.
How long does full tenant recovery take?
A single-user compromise with no tenant-wide impact typically closes within two to five business days. A Global Admin compromise or a tenant with many consented OAuth apps takes longer. We scope this on the first call and update you daily.
Related reading
Call 088 SECDESK
Seeing any of these signs in your tenant? Call now. A senior responder picks up, and begins tenant forensics within two hours.
- Two-hour SLA
- Dutch senior responders