Microsoft 365 security
If your organisation, or your MSP, ever connected ConnectWise Cloud Backup or a ConnectWise Cloud Management app to Microsoft 365, assume the app's access was in an attacker's hands in mid-October 2026, at least until ConnectWise began revoking it on 17 October. Check the service principal sign-in logs for those app IDs, and look in the audit log for new credentials, role assignments and consent grants made since 1 October. No user password or MFA prompt was involved, so a clean interactive sign-in log tells you nothing.
According to Microsoft's write-up of 21 October, Storm-0940 got control of the application identities behind several ConnectWise cloud apps. AI agents running on an open-source "agentic" penetration-testing framework called ARTEX then authenticated as those apps in customer tenants. Microsoft's figures: attempts against more than 2,250 tenants, and over 200 sign-ins in under four minutes using four application credentials.
Before that, from 10 to 14 October, the same infrastructure ran a password spray against 327 accounts in eight organisations. Microsoft logged more than 151,000 failed logons and saw no successful authentication from it. The app credentials were what worked.
Huntress first reported unauthorised Cloud Backup sign-ins across more than 160 partner and customer tenants (The Record, The Hacker News). In at least one tenant, the ConnectWise Cloud Management Teams app gave itself Global Administrator and added new client secrets to other applications so the access would survive. In some environments Microsoft also saw secrets read in bulk from Azure Key Vault.
ConnectWise disabled the affected app connections and suspended Cloud Backup, SaaS Security and Cloud Management. It began rolling out mitigations on 17 October at 05:00 UTC, and on 20 October said it had completed a credential reset and was preparing a phased restoration (The Hacker News). ConnectWise has also said it cannot see into customer tenants, so it can't tell you whether yours was touched. You have to check that yourself.
A multi-tenant SaaS app gets its access through consent. Once an admin approves its application permissions (for example Mail.Read or Files.Read.All for a backup product), the vendor's app can get tokens for your tenant using only its own secret or certificate. No user is involved, so your user MFA and user-based Conditional Access policies don't apply. Those sign-ins go to a separate log, the service principal sign-ins, which many teams don't even send to their SIEM.
A backup product needs to read every mailbox and every file, which is exactly why its credentials are worth stealing: one secret unlocks every tenant at once.
Search by application ID, not display name. Microsoft's hunting guidance lists these three:
506e08f9-6e9a-4da4-942b-a099a03644ae24205314-2b89-4e07-a2a4-579e898a56400de14c77-b9b0-4137-9360-34878a929827Reporting on the incident mentions further Cloud Management variants (Exchange Online, Partner Center, SharePoint Online). Also list anything with "ConnectWise" or "SkyKick" in its name, then use those apps' IDs from that point on.
# Microsoft Graph PowerShell, read-only
Connect-MgGraph -Scopes "Application.Read.All"
$ids = '506e08f9-6e9a-4da4-942b-a099a03644ae','24205314-2b89-4e07-a2a4-579e898a5640','0de14c77-b9b0-4137-9360-34878a929827'
foreach ($id in $ids) {
Get-MgServicePrincipal -Filter "appId eq '$id'" |
Select-Object DisplayName, AppId, Id, AccountEnabled
}
Get-MgServicePrincipal -All |
Where-Object DisplayName -match 'ConnectWise|SkyKick' |
Select-Object DisplayName, AppId, Id, AccountEnabledWrite down each service principal's object Id in your tenant. If you're an MSP, repeat this in every customer tenant, including ones where you stopped using the product. A consent nobody revoked still works.
Microsoft recommends reviewing from at least 15 October, and from 1 October where you have the logs. Review successful and failed sign-ins separately, and don't filter only on the published IP addresses. If you have Microsoft Sentinel or another Log Analytics workspace that collects Entra service principal sign-ins:
AADServicePrincipalSignInLogs
| where TimeGenerated >= datetime(2026-10-01)
| where AppId in ("506e08f9-6e9a-4da4-942b-a099a03644ae",
"24205314-2b89-4e07-a2a4-579e898a5640",
"0de14c77-b9b0-4137-9360-34878a929827")
| summarize Attempts = count(), Successes = countif(ResultType == "0"),
FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by AppId, ServicePrincipalName, IPAddress, ResourceDisplayName
| order by LastSeen descNext, check the directory changes. These are where persistence hides: new secrets, self-assigned roles and new consent grants.
AuditLogs
| where TimeGenerated >= datetime(2026-10-01)
| where OperationName matches regex @"(?i)member to role|service principal credentials|certificates and secrets|app role assignment|permission grant|consent to application|owner to (service principal|application)"
| extend Actor = coalesce(tostring(InitiatedBy.app.displayName), tostring(InitiatedBy.user.userPrincipalName))
| extend Target = tostring(TargetResources[0].displayName)
| project TimeGenerated, OperationName, Actor, Target, Result
| order by TimeGenerated descIf you collect Microsoft Graph activity logs, query MicrosoftGraphActivityLogs by the same AppId values to see which URIs were called and with what status codes. That is the closest you can get to proving what data the app read. If you didn't have them switched on, turn them on now. They need Entra ID P1 or P2 and a diagnostic setting sending them to a workspace, storage account or event hub. Don't expect to see activity from before you enabled them.
Also check the Microsoft 365 unified audit log for mailbox access, new inbox or forwarding rules, mailbox delegation and file downloads from unfamiliar IPs. Microsoft stresses that a successful app sign-in does not on its own mean data was taken.
Update-MgServicePrincipal -ServicePrincipalId <objectId> -AccountEnabled:$false (this needs Application.ReadWrite.All).ConnectWise is this month's example. Backup, archiving, e-signature, CRM sync and security tools often hold equally broad application permissions. This lists which apps hold which Microsoft Graph application permissions:
$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
$roles = @{}; $graph.AppRoles | ForEach-Object { $roles[$_.Id] = $_.Value }
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $graph.Id -All |
Select-Object PrincipalDisplayName, @{n='Permission'; e={ $roles[$_.AppRoleId] }} |
Where-Object Permission -match 'ReadWrite\.All|RoleManagement|AppRoleAssignment|^Mail\.|^Files\.|^Sites\.' |
Sort-Object PrincipalDisplayNameAny app holding RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All or Application.ReadWrite.All can promote itself, which is exactly what happened here. For each app, ask: do we still use it, does it need every permission, and would we notice if it signed in from a new IP? If not, alert on high-privilege service principal sign-ins from IPs or ASNs outside the vendor's usual range. That matches Microsoft's advice: least privilege for multi-tenant apps, and monitoring of credential additions, privilege assignments and unusual app-only activity.
Our free Microsoft 365 identity check covers the wider tenant baseline, and our Entra ID hardening guide includes app consent controls. Restricting user consent stops the next unwanted app getting in. It does nothing about apps an admin already approved, which is why the review above still matters. If you'd rather hand it off, that's what our Microsoft 365 security audit and managed SIEM cover.
It might be. Under NIS2, DORA or GDPR, a vendor's app acting inside your tenant is a supplier-security issue and, depending on what it touched, possibly a notifiable incident. Our incident clock puts the NIS2, DORA, CRA and GDPR deadlines on one timeline from the moment you became aware, and talk to your DPO or legal counsel before you decide it isn't reportable. Our NIS2 explainer covers what supplier risk management looks like in practice.
Only if a ConnectWise app (Cloud Backup, formerly SkyKick, or a Cloud Management app) was consented in your tenant, and even then only your service principal sign-in and audit logs can tell you. Search them by app ID from 1 October 2026. ConnectWise has said it cannot see into customer tenants.
Not as a first step. Microsoft advises disabling the apps and preserving logs and configuration first. Once the investigation is done, remove any unauthorised credentials, grants and roles, and only then decide whether to delete or reconnect following ConnectWise's restoration instructions.
The attackers authenticated as the vendor's application using its own credentials, not as a user. App-only sign-ins aren't subject to user MFA and are logged separately as service principal sign-ins.
We inventory every third-party app and permission in your tenant, remove what you don't need, and send service principal sign-ins to a SIEM that alerts when a vendor app behaves out of pattern.
Get in touch →