About Author
Kristian Wright
Kristian Wright is CEO and co-founder of enhanced.io, a channel-only SOC-as-a-Service provider built for MSPs. He has over 30 years in IT leadership and has co-founded three service delivery businesses.
enhanced.io, the channel-only Open XDR SOCaaS for MSPs
No password. No MFA prompt. Access to everything the app was allowed to read.
That’s what happened to Microsoft 365 tenants this month, and plenty of them belong to MSP clients.
Attackers got hold of the credential for a Microsoft 365 backup application that many MSPs deploy for their clients. The Hacker News reports that they used it to sign in to customer tenants as the app itself, with their own tooling, and pick up tokens carrying the app’s existing permissions. A backup app needs to read mail and files. So the attacker got the same reach.
Nobody phished a user. Nobody typed a password. Every client control built around user sign-ins sat there and watched it go past.
What Microsoft says happened
On October 21, Microsoft attributed the campaign to Storm-0940, a China-state aligned actor active since 2021. Microsoft says the actor used an agentic AI penetration testing framework to run the operation at machine speed.
The numbers are worth reading twice. Microsoft says the actor attempted to sign in to more than 2,250 tenants at 2,900 sign-in attempts per minute. In multiple cases, the time from first targeting to privileged access to an organization’s cloud infrastructure was under 3 hours.
Inside some tenants it went further. Microsoft observed reconnaissance through Microsoft Graph, new credentials added to applications, and changes to identities, groups and privileged roles. One of its detections covers an application assigning itself the Global Administrator role.
Microsoft is careful on one point, and so should we be. An affected app, or even a successful sign-in, does not by itself mean data was accessed or taken.
Why no endpoint agent saw it
Think about where this attack lived. An app signed in to Entra ID. Tokens were issued. Calls went to Microsoft Graph. Roles and credentials changed in the directory.
None of that touches a laptop or a server. There is no process to watch, no file to scan, no endpoint to isolate. Endpoint agents are built to watch devices. This attack never needed one.
That’s the uncomfortable part for any MSP whose security story is built on endpoint agents. They’re necessary. They’re half the picture. The other half is identity and cloud, and that’s where this attack ran from start to finish.
It gets worse with persistence. Microsoft warns that credentials the attacker added to other applications keep working as a backdoor even after the original app is dealt with. Disabling the backup app closes one door. It doesn’t check the others.
The signals are on the identity and cloud surface
Microsoft’s guidance points to the same places every time, and they all sit in Entra and Microsoft 365 logs.
Service principal sign-ins from places they shouldn’t come from. Apps sign in too. Microsoft says to review successful and failed service principal sign-ins separately and to investigate unfamiliar sources outside the vendor’s expected infrastructure, not only the published IP addresses.
Credential and role changes. A new secret or certificate on an app, a new owner, an app-role assignment, a consent grant or a privileged role assignment. An app that grants itself admin rights is about as loud as it gets.
App-driven mailbox access. Microsoft flags high-volume mailbox access by an OAuth app after a suspicious role grant, along with unusual file access, forwarding, inbox or transport rules and delegated mailbox permissions.
Each one is an identity signal. None of them shows up on an endpoint.
What to do this week
Find every client tenant where the affected backup app is, or ever was, installed. Microsoft lists the application IDs. Search by application ID, not display name.
Keep the affected app connections disabled until the vendor gives formal restoration instructions. Don’t delete the enterprise app first; Microsoft says to preserve configuration and evidence.
Review service principal sign-ins from at least October 15, and back to October 1 where records exist.
Review Entra audit logs for credential additions, new apps or owners, app-role assignments, consent grants, privileged role changes and Conditional Access changes.
Review Microsoft 365 audit logs for unusual mail and file access, forwarding, inbox and transport rules and delegated mailbox permissions.
Then widen it. Apply least privilege to every third-party app with tenant-wide permissions, and monitor credential additions, privilege assignments and app-only activity for all of them.
Step 1 is quick for each client. Steps 3 to 5 take longer, because you are reading logs across every tenant you manage. Step 6 is the one that protects you from the next app, not just this one.
The outcome: caught where it happens
Do this and the next app compromise doesn’t go unseen. The odd service principal sign-in gets flagged. The new credential on an app raises a question. The app that grants itself admin rights gets escalated.
None of that needs an agent. It needs someone watching Entra and Microsoft 365 across every client tenant, at the speed Microsoft describes.
My advice would be to start with step 1 today. If you don’t know which client tenants hold which third-party apps, you don’t know your exposure.
That’s the half of the picture our Expert-led SOC watches: identity and cloud activity across the whole MSP estate, alongside the endpoint, so a service principal doing something it has never done gets detected and escalated to your team. It’s how you close the gap that endpoint agents leave.
Key takeaways
Attackers stole a Microsoft 365 backup app’s credential and signed in to client tenants as the app, with no password or MFA prompt.
Microsoft attributes the campaign to Storm-0940 and saw privileged cloud access in under 3 hours in multiple cases.
No endpoint agent sees an app signing in to Entra ID; the evidence sits in identity and cloud logs.
Watch service principal sign-ins, credential and role changes and app-driven mailbox access.
Disabling the affected app is not enough, because credentials added elsewhere persist.
About enhanced.io
enhanced.io is a channel-only Open XDR SOCaaS built exclusively for MSPs, with 400+ integrations across endpoint, network, cloud, identity and IoT/OT. We work only through MSP partners and never sell direct to end clients. To talk about how enhanced.io fits your stack, book a partnership conversation with Hannah Lloyd.
FAQ
How did attackers access Microsoft 365 tenants without a password or MFA?
They used a stolen credential belonging to a third-party Microsoft 365 backup application and signed in as the app. App sign-ins do not involve a user, so there is no password or MFA prompt, and the attacker inherits the permissions the tenant already granted the app.
Who was behind the Microsoft 365 backup app compromise?
Microsoft attributes the campaign to Storm-0940, a China-state aligned actor it says has been active since 2021.
Does a successful sign-in by the affected app mean data was stolen?
Not necessarily. Microsoft says the presence of an affected application, or even a successful authentication, does not by itself indicate that data was accessed or exfiltrated. Audit logs need reviewing to establish what happened.
Why can't endpoint security see an OAuth app signing in to Entra ID?
Because the activity happens entirely in the cloud. The sign-in, token issue, Microsoft Graph calls and directory changes never touch a laptop or server, so there is nothing for an endpoint agent to observe.
What should MSPs check in client tenants after a third-party app credential is stolen?
Service principal sign-ins, Entra audit logs for credential additions, role assignments and consent grants, and Microsoft 365 audit logs for unusual mail and file access, forwarding and inbox rules. Microsoft recommends searching by application ID rather than display name.