A third-party app does not need to guess your employees’ passwords if your tenant has already granted it permission to act. That is the uncomfortable part of the ConnectWise Cloud Backup incident: the reported access path ran through application credentials and existing customer trust, not a fresh interactive login at every downstream organization.
Microsoft says the China-state-aligned actor it tracks as Storm-0940 used the open-source ARTEX agentic penetration-testing framework to accelerate activity after the ConnectWise compromise. It reports more than 2,250 tenant sign-in attempts, with follow-on actions in some environments that included Microsoft Graph reconnaissance and application credential or privilege changes. Microsoft also says the activity did not result from a compromise of, or vulnerability in, Microsoft systems, products, or services. Those distinctions matter: the report describes abuse of a compromised third-party application’s granted access, not a Microsoft platform breach.[1]
This is a report-based analysis, not a first-person incident-response story. The useful lesson is not that AI has invented a new kind of cloud attack. It is that automation can make an existing trust failure move faster than a manual review process.
The application was already inside the trust boundary
OAuth consent is easy to treat as a one-time setup screen. An administrator reviews a list of permissions, clicks approve, and the integration starts working. Months later, the app may feel like a background service rather than an identity with ongoing authority.
That mental model is risky. An enterprise application or service principal can authenticate without a human entering a password at that moment. Its access depends on the permissions, credentials, and grants already configured. If the vendor’s application credentials are compromised, an attacker may be able to use established trust to reach customers who authorized the app.
Microsoft describes that exact shape in the ConnectWise case: after gaining control of credentials for cloud applications, the actor used those applications to authenticate to customer environments with the access they had already been granted. Microsoft observed follow-on activity in multiple environments, including reconnaissance and attempts to modify credentials or privileges. The company cautions that an affected application or successful authentication does not, by itself, prove customer data was accessed or exfiltrated.[1]
ConnectWise’s own advisory describes unauthorized access to application credentials associated with Cloud Backup, formerly known as SkyKick. Its latest advisory update, published October 28, says phased restoration was beginning through a new, security-hardened application, with partner action required. Partners must reset their password, configure multifactor authentication if needed, and re-authorize each Microsoft 365 tenant through the new app. The advisory warns not to re-enable previously disabled applications unless ConnectWise specifically instructs them to, and says re-authorization alone does not confirm that backups have resumed. Once backup capabilities are available, partners should verify that new snapshots complete successfully.[2]
ConnectWise’s technical guide also says that vendor-side containment does not change enterprise-application settings inside each partner or customer tenant. Those tenants need separate review, including dormant connections, and the guide cautions that completing the workflow does not prove a tenant was unaffected or authorize reconnection.[3]
What AI changes, and what it does not
Microsoft says ARTEX helped automate scanning, reconnaissance, password spraying, and OAuth application abuse. The report says some attacks reached privileged cloud access in under three hours. It also describes a password-spray campaign between October 10 and 14 that generated more than 151,000 failed sign-in events across 327 accounts at eight organizations. Microsoft observed no successful authentication, token issuance, Graph call, or directory change from that particular password-spray campaign.[1]
That last sentence is not a footnote to skip. The 151,000 failed sign-ins belong to one described campaign phase; they are not evidence that 151,000 accounts were compromised. Microsoft separately reports downstream customer activity through the compromised applications. Collapsing those into one dramatic number would exaggerate what the source says.
The deeper change is operational tempo. An agentic workflow can test many paths and react to results without waiting for a person to review every step. That increases the value of controls that work continuously: short-lived credentials where supported, narrow permissions, anomaly alerts, and a tested way to revoke trust across tenants.
The incident does not show that a language model independently discovered a zero-day or that AI defeated a specific security product. It shows a threat actor used an agentic framework to accelerate an existing offensive workflow. The hard problem remains familiar: what can a trusted application do, where can it do it, and how quickly can an organization notice when that behavior changes?
The uncomfortable inventory problem
Most organizations can list their direct employees and core cloud subscriptions. Fewer can quickly answer a different set of questions:
- Which third-party applications have tenant-wide or high-impact permissions?
- Which integrations are still needed, and which are leftovers from a pilot or departed vendor?
- Who owns each application relationship?
- What is the expected sign-in pattern for each service principal?
- What is the emergency process for disabling an app without destroying evidence?
- Which customer or business processes stop if the integration is revoked?
A display name is not enough for that inventory. Microsoft’s response guidance tells affected customers to search by application ID rather than display name, review tenants where affected applications are currently or were previously installed, and record the local service-principal object ID. That is a useful general lesson: names are labels; stable identifiers are the better join key for investigation.[1]
This gets harder in service providers and other multi-tenant businesses. One integration can have many customer authorizations, and a single vendor-side credential incident can create a broad downstream review. A spreadsheet maintained only during onboarding will not stay accurate. The inventory needs an owner, a review cadence, and an offboarding trigger.
A practical third-party OAuth review
1. Build the inventory from identity data. Export enterprise applications, service principals, owners, credentials, consent grants, and app-role assignments from the identity platform. Include application ID, local object ID, tenant, permission scope, business owner, vendor contact, and last observed use. Do not treat a familiar product name as proof that the app is official or currently required.
2. Rank access by impact. Separate read-only access from write access, directory administration, mailbox access, key-vault access, and broad resource management. Mark permissions that can create credentials, assign roles, alter users or groups, or access sensitive data. Review the actual granted permissions, not only the vendor’s marketing explanation of what the integration needs.
3. Define expected behavior. For each important service principal, record the expected source ranges or service locations when available, normal sign-in frequency, APIs it should call, and the resources it should touch. Avoid a simplistic rule that every unfamiliar IP proves compromise. Use deviations as investigation leads and correlate them with audit activity and vendor guidance.
4. Alert on identity changes, not just logins. Monitor new application credentials, added owners, new consent grants, app-role assignments, privileged role changes, and unusual Graph activity. A successful app-only sign-in may be routine; an unexpected credential addition immediately afterward is a different signal. Microsoft’s report specifically recommends reviewing service-principal sign-ins alongside Graph activity and directory changes.[1]
5. Preserve before removing. During a suspected compromise, capture available sign-in and audit records, relevant SIEM events, app configuration, permissions, owners, and credential metadata. Then contain the access using an authorized response process. Microsoft advises preserving configuration and evidence rather than deleting enterprise applications as the first action in this incident’s guidance.[1]
6. Revoke with a recovery plan. Know how to disable or remove an integration, revoke its grants, rotate any dependent secrets, and validate downstream workloads. Include a vendor-contact path and a customer communication plan. For backup products, independently confirm that new snapshots are completing and that restores work. A green service page is not the same as a verified recovery point.
7. Re-check historical access. Removing the original application may not remove credentials or persistence created elsewhere. Review subsequent changes to users, groups, roles, app registrations, mailbox rules, and data access. Use the incident window supplied by the vendor and security researchers, but extend it if local evidence points earlier.
Do not turn indicators into a false all-clear
An IP address, user agent, or application ID can help prioritize a hunt, but it is not a complete detection strategy. Infrastructure changes. An attacker may use new addresses. A clean query can also mean that relevant telemetry was not enabled or retained.
Microsoft explicitly warns that the absence of results from one of its sample queries should not be treated as confirmation that no access occurred. It recommends considering Graph telemetry alongside service-principal authentication and application permissions.[1] That is a useful rule beyond this incident: negative evidence is only as strong as the visibility behind the query.
Likewise, do not assume every customer of a vendor experienced data theft. Microsoft says an affected application or successful authentication does not necessarily mean data was accessed or exfiltrated. The responsible response is to inspect the tenant’s evidence and follow vendor and Microsoft guidance, not to convert a broad exposure into a universal claim.[1]
The takeaway: treat OAuth consent like a production dependency
Teams already inventory databases, queues, and external APIs because those dependencies can break production. A powerful third-party application deserves the same treatment, plus an identity owner and a tested revocation path.
The useful checklist is short enough to keep near the incident runbook:
- Identify the application by ID, not just display name.
- Record every tenant, owner, permission, and credential.
- Alert on credential, consent, and role changes.
- Correlate service-principal sign-ins with API and directory activity.
- Preserve evidence before cleanup.
- Revoke access deliberately, then verify the business workflow and recovery path.
- Reauthorize only through the vendor’s current, explicit instructions.
The AI angle is real, but it should not distract from the architectural point. If one vendor-side identity can reach many customer tenants, the access boundary is part of your system whether or not your team wrote that integration. Machine-speed abuse makes stale assumptions more expensive.
I write about Java, Spring Boot, and AI every week. Subscribe if you want more engineering analysis grounded in what the sources actually say.
Have you reviewed the third-party OAuth applications in your cloud tenant recently? What permission or monitoring gap surprised you?
Sources
[2] ConnectWise Trust Center: Cloud Backup advisories
[3] ConnectWise Cloud Backup technical investigation and remediation guide
Top comments (0)