ConnectWise Breach: Why Microsoft 365 App Permissions Matter

Short read

This post covers the ConnectWise Cloud Backup supply chain compromise, which Microsoft attributes to Storm-0940. The attacker used apps that had already been granted access to reach Microsoft 365 tenants without anyone signing in, and AI automation let it target more than 2,250 tenants at machine speed.

You'll learn what to check in your own tenants, from finding the affected app IDs and preserving evidence to hunting for new app credentials, consent grants and role changes. We also explain why app activity needs watching around the clock, and how urgentic BLUE investigates every alert so a suspicious app sign-in gets an answer in minutes.

When a trusted app turns against you, nobody has to type a password. That's the uncomfortable lesson of the ConnectWise Cloud Backup supply chain compromise, and it's why Microsoft 365 app permissions and OAuth consent now deserve the same round-the-clock attention as user sign-ins. This article explains what happened, why the speed of the attack matters, and what to check in your own tenants, whether you run security in-house or look after customers as an MSP.

What happened in the ConnectWise Cloud Backup compromise

ConnectWise published its first advisory about attempted unauthorised access to Cloud Backup (the product formerly known as SkyKick) on 16 October 2026, and has since expanded its disclosures and containment guidance on the ConnectWise Trust Center.

On 21 October, Microsoft Threat Intelligence published its analysis. Microsoft assesses that Storm-0940, which it describes as a China-state aligned actor active since 2021, was responsible for the compromise of the multi-tenant application.

According to Microsoft:

• After gaining control of the identities of several ConnectWise cloud applications, the actor used them to authenticate to customer Microsoft 365 environments through apps that had already been granted access.
• Because the apps were already trusted, the actor didn't need an interactive user sign-in. No phishing, no stolen user password.
• In multiple environments, the activity moved on to Microsoft Graph: reconnaissance, changes to application credentials to keep access, and attempts to change identities, groups and privileged roles.
• Microsoft is careful to say that an affected app being present, or even a successful sign-in, doesn't necessarily mean data was accessed or taken.

Why the speed is the real story

The access route wasn't new. Microsoft notes that abusing OAuth applications has long been part of Storm-0940's toolkit. What changed was the pace.

Microsoft says the actor used ARTEX, an open-source, AI-driven penetration testing framework, to automate scanning, password spraying and OAuth app abuse. Using it, the actor attempted to sign in to more than 2,250 tenants at 2,900 sign-in attempts per minute. Across its wider ARTEX campaign, Microsoft saw several cases where the time from first targeting to privileged access to an organisation's cloud infrastructure was under three hours.

Microsoft also makes a point every security lead should sit with: activity at that volume generates plenty of log data and alerts, but the speed leaves defenders very little time to respond. As Microsoft puts it, AI agents "can work around the clock, on weekends, and on holidays."

An attack that moves from foothold to privileged access in an afternoon won't wait for Monday's alert review.

Why third-party apps are such an attractive way in

Over the years, many organisations have granted a long list of apps access to their Microsoft 365 data: backup tools, email security add-ons, CRM connectors, reporting tools. Many hold broad, application-level permissions so they can work without a user present.

That's exactly what makes them valuable to an attacker:

• They're trusted by design. Their sign-ins look like normal service activity, not a person logging in from somewhere odd.
• They sit outside MFA. Multi-factor authentication protects people. An app authenticating with its own credentials isn't prompted.
• They're rarely reviewed. Consent is often granted once during setup and then forgotten, even after the tool is no longer used.
• One vendor reaches many tenants. For an MSP, a single compromised management or backup tool can touch every customer it looks after at once.

Microsoft also warns that credential changes made by the attacker can act as a backdoor that survives even after the original compromised application has been dealt with. Removing the app isn't the same as removing the attacker.

What to check in your Microsoft 365 tenants

Microsoft's guidance is detailed, and if you use ConnectWise Cloud Backup you should read it in full alongside ConnectWise's own containment guidance. The essentials, based on Microsoft's mitigation advice, are:

1. Find the affected apps by application ID, not display name. Microsoft lists the IDs for ConnectWise Cloud Backup, ConnectWise - MS Teams and ConnectWise - MS Graph. Check every tenant where they are or ever were authorised, even if you've stopped using the integration.
2. Keep the affected connections disabled until ConnectWise gives formal restoration instructions.
3. Preserve evidence before you delete anything. Microsoft specifically advises against deleting enterprise applications as a first response. Keep Entra sign-in and audit logs, Purview audit records and SIEM data.
4. Review service principal sign-ins from at least 15 October, and back to 1 October where records allow. Look at successful and failed sign-ins separately, and don't limit the search to the published IP addresses.
5. Look for persistence. New credentials or secrets on apps and service principals, new owners, app-role assignments, consent grants, privileged role assignments, and changes to Conditional Access or authentication methods.
6. Check what happened to your data. Unusual mailbox or file access, downloads, forwarding and inbox rules, and delegated mailbox permissions.

Microsoft also publishes indicators of compromise and ready-made hunting queries for Microsoft Defender XDR and Microsoft Sentinel, which make the first pass much quicker. (urgentic's own platform is built on Sentinel.)

The longer-term fix: watch app activity, not just people

Once the immediate checks are done, the broader lesson applies to every organisation using Microsoft 365, ConnectWise customer or not:

• Apply least privilege to app permissions. Ask whether each app genuinely needs tenant-wide, application-level access.
• Review consent grants regularly, and remove apps that are no longer in use.
• Monitor app-only activity continuously. Credential additions, role assignments and unusual Microsoft Graph activity from service principals should raise alerts, and those alerts need someone to investigate them promptly.
• Hold your vendors to the same standard. If an IT provider manages your tenant, ask how they review app permissions and who responds to suspicious sign-ins at night and at weekends.

That last point is where many teams struggle. The detections exist; Microsoft lists a dozen relevant alerts across Defender XDR and Defender for Cloud Apps. The hard part is making sure each one is looked into quickly, at 3am on a Sunday as well as 10am on a Tuesday. That's the work urgentic BLUE is built for: investigating every alert, around the clock, so a suspicious app sign-in gets an answer in minutes rather than sitting in a queue.

Key takeaways

• Microsoft attributes the ConnectWise Cloud Backup compromise to Storm-0940, which abused already-trusted apps to reach Microsoft 365 tenants without a user signing in.
• AI automation pushed the attack to machine speed: more than 2,250 tenants targeted and, in some wider cases, privileged access in under three hours.
• Check every tenant for the affected app IDs, preserve evidence, and hunt for new app credentials, consent grants and role changes.
• Treat third-party app permissions as part of your attack surface, and make sure someone is watching them all the time.