ConnectWise disclosed a security incident involving unauthorized access to application identities associated with its Cloud Backup service. The company has taken the service offline while it executes remediation — including strengthening administrative-access protections, resetting accounts, and replacing application credentials. For MSPs and the thousands of downstream SMB clients they protect, this is not a background event: backup platforms are the last line of defense in a ransomware scenario, and a compromise of backup application identities is a direct threat to recoverability. Defenders should treat this as an active identity-compromise incident in their own tenant until proven otherwise.
Why This Matters to Your Organization
ConnectWise sits at the center of the MSP toolchain. Cloud Backup application identities — typically OAuth application registrations and service principals granted access to customer Microsoft 365 / SaaS workloads — hold exactly the permissions an attacker wants: broad, quiet, read/write access to mailboxes, OneDrive, SharePoint, and backup stores. An adversary holding these credentials can:
- Exfiltrate tenant data through legitimate backup APIs, bypassing most DLP and CASB controls because the traffic looks like sanctioned backup activity.
- Delete or corrupt backups ahead of a ransomware detonation, destroying recovery capability before the encryption event.
- Persist in customer tenants by adding new credentials or secrets to the existing, trusted application registration — surviving password resets of user accounts entirely.
When a vendor resets application credentials en masse, the correct defensive assumption is that the old secrets may be in adversary hands. That drives a specific, time-boxed set of actions in every tenant the service touched.
Technical Analysis
What We Know
Per ConnectWise's disclosure, the incident resulted in unauthorized access to application identities associated with Cloud Backup. The company's stated remediation actions include:
- Strengthening protections around administrative access to the platform.
- Resetting accounts and replacing application credentials used by the Cloud Backup service.
- Keeping the Cloud Backup service offline while response activities continue.
No CVE has been published for this incident — this is a vendor-side security event, not a patchable software flaw in on-premises code. The exposure vector is identity: application credentials (client secrets, certificates, or tokens) used by the backup service to authenticate into customer workloads.
The Attack Pattern: Application Identity Abuse
SaaS backup platforms integrate with Microsoft 365 via Entra ID app registrations granted either delegated permissions or application permissions such as Sites.FullControl.All, Mail.Read, Directory.Read.All, and similar. Compromise of the app identity's secret gives an attacker the ability to mint tokens as the application — with no user sign-in, no MFA prompt, and often no Conditional Access evaluation, because application (client_credentials) flows are frequently excluded from CA policies.
The defender-relevant attack chain:
- Adversary obtains application identity credentials (vendor-side compromise, per this disclosure).
- Adversary requests tokens from Entra ID using the stolen client_id/secret pair, typically from infrastructure outside the vendor's normal egress ranges.
- Using granted backup permissions, adversary reads mailbox/SharePoint/OneDrive content at scale, or deletes backup sets.
- Optional persistence: if the adversary gained any administrative control, they may add additional credentials to the app registration — meaning the vendor's reset removes the original secret but leaves attacker-added ones intact. This is the single most important thing to hunt in your own tenant.
Exploitation Status
ConnectWise has confirmed unauthorized access occurred — this is not theoretical. Whether stolen credentials have been used against downstream customer tenants is the open question each MSP must answer with their own telemetry. Until that question is answered, assume compromise and hunt.
Detection & Response
The detections below target the observable behaviors of application-identity abuse: anomalous credential additions to app registrations, client-credential token use from unexpected locations, and pre-ransomware backup destruction on endpoints. Validate them against your environment before production deployment — backup and admin tooling varies, and legitimate MSP automation can resemble some of this activity. Baseline first, then alert on deviation.
Sigma Rules
---
title: Credential Added to Application Registration or Service Principal
id: 3f7a2c91-4b6e-4d58-a9c1-2e8f5b7d0a44
status: experimental
description: Detects addition of new secrets or certificates to app registrations/service principals. Post-compromise persistence technique when backup application identities are exposed, as in the ConnectWise Cloud Backup incident. Vendor resets remove original secrets but not attacker-added ones.
references:
- https://thehackernews.com/2026/10/connectwise-resets-credentials-as-cloud.html
- https://attack.mitre.org/techniques/T1098/001/
author: Security Arsenal
date: 2026/10/19
tags:
- attack.persistence
- attack.t1098.001
logsource:
product: azure
service: auditlogs
detection:
selection:
operationName:
- 'Add service principal credentials'
- 'Add service principal certificate'
- 'Update application - Certificates and secrets management'
- 'Add app role assignment to service principal'
condition: selection
falsepositives:
- Legitimate credential rotation by administrators (expected during incident response — alert anyway and verify against change tickets)
- Vendor-driven re-credentialing of the backup application
level: high
---
title: Unusual Admin Consent Grant to Application
id: 8b4e6d12-9f3a-4c71-b5d8-6a2f1e9c0d33
status: experimental
description: Detects admin consent grants to applications, which adversaries use to establish a second, attacker-controlled backup or data-access app after compromising an MSP or backup vendor tenant.
references:
- https://thehackernews.com/2026/10/connectwise-resets-credentials-as-cloud.html
- https://attack.mitre.org/techniques/T1528/
author: Security Arsenal
date: 2026/10/19
tags:
- attack.persistence
- attack.collection
logsource:
product: azure
service: auditlogs
detection:
selection:
operationName: 'Consent to application'
filter_known_backup_apps:
displayName|contains:
- 'ConnectWise'
condition: selection and not filter_known_backup_apps
falsepositives:
- New SaaS integrations onboarded by IT
- DevOps pipeline registrations
level: medium
---
title: Backup or Shadow Copy Deletion on Endpoint
id: 1c9d5e47-7a2b-4f83-9e6c-4d1a8b3f5e21
status: experimental
description: Detects deletion of volume shadow copies or backup catalogs via built-in Windows tooling. Standard pre-encryption ransomware behavior, especially when backup platform credentials are simultaneously compromised and recovery paths are being destroyed.
references:
- https://thehackernews.com/2026/10/connectwise-resets-credentials-as-cloud.html
- https://attack.mitre.org/techniques/T1490/
author: Security Arsenal
date: 2026/10/19
tags:
- attack.impact
- attack.t1490
logsource:
category: process_creation
product: windows
detection:
selection_vssadmin:
Image|endswith: '\vssadmin.exe'
CommandLine|contains:
- 'delete shadows'
- 'Delete Shadows'
selection_wbadmin:
Image|endswith: '\wbadmin.exe'
CommandLine|contains:
- 'delete catalog'
- 'delete systemstatebackup'
- 'delete backup'
selection_bcdedit:
Image|endswith: '\bcdedit.exe'
CommandLine|contains:
- 'recoveryenabled no'
- 'bootstatuspolicy ignoreallfailures'
condition: 1 of selection_*
falsepositives:
- Rare legitimate storage maintenance by administrators
level: high
KQL — Microsoft Sentinel / Defender
Hunt for credential modifications on app registrations and anomalous token issuance. The most valuable query right now joins AuditLogs credential-add events against SigninLogs/AADServicePrincipalSignInLogs to surface service principals that gained new credentials and then authenticated from unfamiliar locations. This query hunts for recently added app credentials followed by service principal sign-ins from IP addresses not seen in the prior 14 days:
// Hunt: New credentials on service principals + first-seen sign-in locations
let lookback = 14d;
let window = 7d;
let KnownIPs = AADServicePrincipalSignInLogs
| where TimeGenerated between (ago(lookback) .. ago(window))
| summarize by IPAddress;
AuditLogs
| where TimeGenerated > ago(window)
| where OperationName in~ ("Add service principal credentials", "Add service principal certificate", "Update application - Certificates and secrets management", "Add app role assignment to service principal")
| extend AppId = tostring(TargetResources[0].id), AppName = tostring(TargetResources[0].displayName)
| extend InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)
| project CredAddTime=TimeGenerated, AppName, AppId, InitiatedBy, OperationName
| join kind=leftouter (
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(window)
| where IPAddress !in (KnownIPs)
| summarize SignInCount=count(), Locations=make_set(Location), IPs=make_set(IPAddress) by ServicePrincipalId
) on $left.AppId == $right.ServicePrincipalId
| project CredAddTime, AppName, InitiatedBy, OperationName, SignInCount, IPs, Locations
| sort by CredAddTime desc;
For endpoint-side coverage in Defender, hunt for backup destruction tooling:
// Hunt: Shadow copy / backup deletion processes across fleet
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where (FileName =~ "vssadmin.exe" and ProcessCommandLine has_any ("delete shadows", "resize shadowstorage"))
or (FileName =~ "wbadmin.exe" and ProcessCommandLine has "delete")
or (FileName =~ "bcdedit.exe" and ProcessCommandLine has_any ("recoveryenabled", "bootstatuspolicy"))
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by TimeGenerated desc;
Velociraptor VQL
Use this hunt across Windows endpoints to surface backup-destruction processes and confirm whether shadow copies still exist on hosts — a quick integrity check during incident response when backup platform compromise is in play:
-- Hunt for backup/shadow-copy tampering processes and verify shadow copy presence
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(vssadmin.*(delete|resize)|wbadmin.*delete|bcdedit.*recoveryenabled|bcdedit.*bootstatuspolicy)'
-- Verify shadow copies still exist on each hunted host (run as a separate artifact using PowerShell via execve if needed)
SELECT Pid, Name, CommandLine, Username
FROM pslist()
WHERE Name =~ '(?i)(vssadmin|wbadmin|diskshadow)'
Remediation Script
Run this in each customer tenant to inventory application credentials modified recently — this catches the persistence scenario where an attacker added a secret to an existing trusted app (including the backup app itself) that survives a vendor-side reset. Requires the Microsoft.Graph PowerShell module and Application.Read.All / AuditLog.Read.All consent:
# Requires: Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","AuditLog.Read.All"
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","AuditLog.Read.All" -NoWelcome
$cutoff = (Get-Date).AddDays(-30)
$report = @()
# Enumerate all app registrations and flag credentials created or expiring recently
$apps = Get-MgApplication -All -Property Id,DisplayName,AppId,PasswordCredentials,KeyCredentials
foreach ($app in $apps) {
foreach ($cred in $app.PasswordCredentials) {
if ($cred.StartDateTime -gt $cutoff) {
$report += [pscustomobject]@{
AppName = $app.DisplayName
AppId = $app.AppId
CredType = "ClientSecret"
StartDate = $cred.StartDateTime
EndDate = $cred.EndDateTime
KeyId = $cred.KeyId
Recommendation = "VERIFY - secret added in last 30 days; confirm with change records, then remove if unauthorized"
}
}
}
foreach ($key in $app.KeyCredentials) {
if ($key.StartDateTime -gt $cutoff) {
$report += [pscustomobject]@{
AppName = $app.DisplayName
AppId = $app.AppId
CredType = "Certificate"
StartDate = $key.StartDateTime
EndDate = $key.EndDateTime
KeyId = $key.KeyId
Recommendation = "VERIFY - certificate added in last 30 days; confirm with change records, then remove if unauthorized"
}
}
}
}
# Pull directory audit events for credential/consent operations in the window
$audits = Get-MgAuditLogDirectoryAudit -All -Filter "activityDateTime ge $($cutoff.ToString('yyyy-MM-ddTHH:mm:ssZ'))" |
Where-Object { $_.ActivityDisplayName -match "service principal credential|Consent to application|Certificates and secrets" } |
Select-Object ActivityDateTime, ActivityDisplayName,
@{n='InitiatedBy';e={$_.InitiatedBy.user.userPrincipalName}},
@{n='Target';e={($_.TargetResources | Select-Object -First 1).displayName}}
$report | Sort-Object StartDate -Descending | Format-Table -AutoSize
$audits | Sort-Object ActivityDateTime -Descending | Format-Table -AutoSize
# Export for IR documentation
$report | Export-Csv -Path ".\AppCredAudit_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
$audits | Export-Csv -Path ".\DirectoryCredAudit_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
Write-Host "Review both exports. Any credential on a backup-related app NOT attributable to the vendor reset must be treated as attacker persistence and removed immediately."
Remediation
- Rotate every secret the vendor reset — and verify it took. Do not assume the vendor-side rotation propagated. In each tenant, locate the ConnectWise Cloud Backup service principal and confirm credential
StartDateTimevalues postdate the incident window. If old secrets persist, remove them manually. - Hunt for attacker-added credentials on existing app registrations. This is the highest-risk persistence path. Use the script above. Any secret or certificate added to a trusted app that is not in your change records is treated as hostile: remove it, then review that app's sign-in and data-access activity for the full period the rogue credential existed.
- Review consent grants tenant-wide. Enumerate all app registrations with application permissions (
Mail.Read,Sites.FullControl.All,Directory.Read.All,full_access_as_app). Anything you cannot attribute to a known business function gets revoked. - Audit token usage geography. Service principal sign-ins from IP ranges outside the vendor's documented egress infrastructure are presumptively malicious. Use the KQL above and cross-reference IPs against vendor-published ranges and threat intel.
- Verify backup integrity and test restoration now. With the service offline, confirm your most recent restorable recovery point predates the incident window, and perform an actual test restore of a sample workload. If Cloud Backup is your only recovery path, stand up an interim backup solution immediately — running with zero recovery capability during an active vendor incident is unacceptable risk.
- Enforce phishing-resistant MFA on all MSP administrative access, and review Conditional Access policies: ensure workload identities and service principal activity are monitored, and that legacy authentication is blocked tenant-wide.
- Monitor ConnectWise's official advisories for service restoration timelines and any expansion of scope. Treat downstream notifications to your clients as a contractual and regulatory obligation — several frameworks (and state breach laws) may apply depending on what data the backup identities could access.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.