Microsoft warns of ConnectWise OAuth abuse targeting Microsoft 365 tenants
News
Published 21 Oct 2026
Updated 21 Oct 2026
7 min read
Summarize with
Microsoft on October 21 attributed the ConnectWise multi-tenant application credential compromise and downstream Microsoft 365 OAuth abuse to Storm-0940, a China-state-aligned actor. Its threat-intelligence disclosure described attackers using stolen application identities to authenticate to customer tenants without interactive user sign-ins. ARTEX automation accelerated the activity; the immediate email-security concern is the access already granted to trusted applications.
I would prioritize Microsoft 365 tenants with current or historical consent for affected ConnectWise applications. Microsoft observed follow-on Microsoft Graph reconnaissance, application-credential changes and privilege modifications in some environments. Each tenant needs investigation to establish what happened after authentication.
Editorial date: October 21, 2026 (UTC).
Sign-in does not establish mailbox theft
An affected application, a successful sign-in or campaign targeting does not establish mailbox data access or exfiltration. Storm-0940 has historically stolen email through Microsoft Graph, but that history does not prove the same outcome in every tenant in this incident.
What changed on October 21
ConnectWise's initial disclosure was on October 16. Microsoft's October 21 publication added independent threat attribution and operational analysis, connecting the application compromise and downstream abuse to Storm-0940. These are separate disclosures: the October 21 report was not the first notification of the ConnectWise incident.
Microsoft said the actor used ARTEX automation during its operations. For mailbox security, I give greater weight to the permissions held by compromised identities and the actions recorded after sign-in than to the automation label. The operational issue is whether attackers used trusted application access to reach mail or create additional access paths.
Microsoft separately described a history of Storm-0940 stealing email and other data through Microsoft Graph. That background explains why application-credential changes deserve scrutiny. It remains separate from the evidence for this campaign: an established actor technique is a reason to investigate, not a finding that every tenant experienced it.
Failed password spraying is separate from downstream access
According to Microsoft's analysis, the October 10-14 password-spray subcampaign generated more than 151,000 failed logons against 327 accounts across eight organizations. Its peak of 2,900 failures per minute describes failed attempts. Microsoft observed no successful sign-in or Graph change in that subcampaign. Those figures are not counts of successful compromises.
Microsoft also described attempts to sign in to more than 2,250 tenants using compromised application identities. That is a targeting measure, not a breach total. The follow-on activity Microsoft observed in some environments requires separate assessment. I keep attempted authentication, successful authentication and evidence of resource access distinct when assessing exposure.
|
|
|
|---|---|---|
App present | Potential exposure | Actual app use |
Successful sign-in | Authentication | Mailbox reading |
Graph event | Recorded operation | Data exfiltration |
Successful mail read | Observed mail access | Complete mailbox theft |
Evidence supports different conclusions at each stage.
Why application identities matter for mailbox security
A service principal is an application's local identity in a tenant. Its granted permissions determine what it can do. When attackers hold usable application credentials, they can authenticate as the application and exercise its existing access. A familiar application name does not establish that a particular request was authorized.
This authentication path does not require an employee to complete an interactive sign-in. User MFA remains important, but an investigation confined to user sign-ins misses application activity. Resetting employee passwords alone does not remove application credentials or revoke application grants. Review the identity that actually authenticated and the resources it requested.
For each suspicious sequence, correlate the application identity with the requested resource, operation time and result. A directory-enumeration request and a successful message read support different conclusions. Where resource-level evidence is available, use it to determine the affected mailboxes and scope of access instead of treating every Graph event as email theft.
Application access
Stolen credentials let an application identity authenticate. Investigators need its application ID, local service principal and granted permissions.
A successful event establishes authentication. Mailbox impact needs evidence of subsequent operations.
Persistent access
Unauthorized credential or privilege changes create additional access paths. Removing the original connection alone is insufficient if those changes remain.
Responders must identify and remove confirmed unauthorized changes before treating the tenant as recovered.
What Microsoft 365 admins and MSPs should investigate
Start with every tenant where affected ConnectWise applications are currently or were previously authorized, including integrations no longer used. Inventory by application ID, not display name, and record the local service-principal ID. Use Microsoft's official guidance for the affected identities and live investigation details.
Review activity starting at least October 15. Where records are available, extend service-principal sign-in review to October 1. Examine successful and failed events separately, then correlate application activity with authorized administration. Preserve evidence before deleting applications or making other irreversible changes; urgent containment should not wait for every export to finish.
- Connections. Keep affected connections disabled until ConnectWise provides formal restoration instructions. An apparent return to normal operation is not sufficient authorization to reconnect.
- Evidence. Preserve service-principal sign-in records, Entra audit records and Microsoft 365 audit evidence. Save relevant application configuration and permission details before remediation changes the investigation context.
- Identity changes. Investigate unexpected credentials and owners, consent grants, application-role assignments and privileged-role changes. Check whether each change had legitimate administrative approval.
- Mailbox activity. Investigate unusual mail or file access, forwarding, inbox rules and transport rules. Review delegated mailbox permissions and correlate suspicious changes with the relevant application activity.
- Containment. Have authorized responders contain confirmed unauthorized access, rotate affected credentials and revoke unauthorized grants. Remove confirmed persistence, including access paths beyond the original compromised application.
- Backup impact. Assess interrupted backups and restore capability with vendor restoration guidance. Record gaps in protection and recovery dependencies while affected connections remain disabled.
Forwarding settings and delegated permissions need review because they define additional ways to receive or access messages. Check who authorized a change and whether it remained after the affected connection was disabled. These are investigation checks; they are not a statement that Microsoft observed every form of mailbox persistence in this campaign.
For MSPs, I would track the outcome separately for each customer tenant. Consent history and granted access differ between customers. One tenant showing only failed attempts does not establish the outcome elsewhere, and evidence of abuse in one customer does not establish mailbox theft across the customer base.
Document which records were available and which questions remain unresolved. Missing telemetry limits the conclusion investigators can support. A report should distinguish observed unauthorized operations from access that the application was permitted to perform, and should state when the available evidence does not establish a data-access outcome.
What DMARC can and cannot establish
DMARC, SPF and DKIM authenticate sender domains and signed messages. They do not revoke OAuth grants or prevent an already-authorized application from calling mailbox APIs. Microsoft announced no new sender requirement, DMARC policy, compliance deadline or authentication-protocol bypass. Changing a DNS record is not containment for a compromised application identity.
Suped's email tester checks authentication on a real message, while our domain health checker reviews email-authentication DNS configuration. I keep those checks separate from tenant incident response: neither result establishes whether an OAuth application accessed mailbox data. Authentication monitoring remains useful for sender-domain protection, with its scope clearly understood.
Restore connections only after tenant recovery
Before restoring an affected connection, I want a tenant-specific record of the credentials and grants reviewed, unauthorized changes removed, and remaining evidence gaps. Follow formal vendor restoration instructions and verify that remediation eliminated persistence. A rotated vendor credential alone does not settle whether attackers created another access path.
Assign responsibility for checking mailbox permissions and rules after remediation, and confirm the effect on backups and restores. Record what is known about mailbox access before closing the incident. Where the evidence remains inconclusive, retain that limitation in the customer or internal incident record.
Restoration also needs an operational owner: someone responsible for confirming that the recovered connection has only the access the service requires. Document the approved restoration changes alongside the preserved evidence, so investigators can distinguish recovery work from unauthorized changes made during the incident.
Frequently asked questions
No. Application presence establishes potential exposure, and a successful sign-in establishes authentication. Mailbox access and exfiltration require additional evidence. Microsoft observed follow-on activity in some environments, without establishing that every affected tenant lost email.
User password resets do not remove application credentials or revoke application permissions. Authorized responders need to investigate the compromised application identities and remove confirmed unauthorized grants, credentials and persistence. Address compromised user accounts separately where evidence supports it.
Yes. Review current and historical consent for affected applications in each tenant. Search by application ID rather than display name, preserve available evidence, and assess what permissions remained during the relevant period.
No. DMARC evaluates sender-domain authentication for email. It does not inspect OAuth permissions or establish whether mailbox API access occurred. A tenant needs its own application-identity and mailbox-activity investigation, even when legitimate messages pass authentication.
