Microsoft published an analysis of Storm-0940 abusing OAuth application identities associated with ConnectWise. The campaign used previously granted application trust to reach customer environments, with AI tooling accelerating parts of the operation. Microsoft Security official announcement
Applications can act without an interactive human sign-in. An investigation limited to user authentication can therefore miss service-principal access and later privilege changes. Identify integrations by application ID rather than relying on their display names.
On this page
OAuth application access is separate from an employee password
Enterprise SaaS integrations can receive permission to access a customer environment through an OAuth application. A service principal represents that application within a particular organization. Its credential-based activity can follow a different logging path from an employee’s interactive session. Changing employee passwords therefore does not automatically remove every application-based access path into the environment.
The supply-chain concern arises from that trusted connection. An already approved vendor application can become an access route even when the organization’s own servers are not the initial entry point. Review application identifiers and consent records rather than relying on display names. Previous approval and a continuing business need for the same permissions are separate questions.
Build an evidence chain before drawing an impact conclusion
AI-assisted automation is a significant part of the report, but investigation still depends on connecting authentication, permission changes, and actual operations. A successful authentication shows that an access path was used; it does not by itself prove that all available data was stolen. Equally, normal employee sign-ins do not rule out abuse performed through an application identity.
Arrange application authentication, added credentials, permission changes, and subsequent API activity on one timeline. Normalize time zones and identify differences in log retention so that missing evidence is visible. Preserve change approvals and administrator context as well, since distinguishing legitimate maintenance from malicious persistence requires more than a list of technically successful operations.
Separate evidence preservation, containment, and recovery
In a hypothetical response, first capture the application identifiers, granted permissions, sign-in records, and audit events, then compare them with the service owner’s expected activity. Restrict access and replace credentials according to the confirmed risk. Deleting an application can disrupt operations and remove useful context, so the response lead should determine the sequence of preservation and containment.
Recovery requires checking for additional credentials, owners, or permissions rather than only restoring the original integration. These are defensive investigation examples, not a finding that any particular organization was breached. Determine actual exposure from the vendor’s current guidance and evidence available in the affected environment, including the operations performed after authentication.
Preserve evidence while reviewing
- Collect relevant service-principal sign-in and audit records.
- Correlate added credentials, permission grants, and owner changes.
- Follow current ConnectWise restoration guidance and your response procedure.
Do not begin by deleting evidence-bearing application objects. Separate confirmed unauthorized changes from legitimate administration before containment and recovery.
Announcement reference date: 2026-10-21 · Checked: October 24, 2026
.jpg){kind=link}