ConnectWise Cloud Backup Suspended After M365 Tenant Compromise — Hunting Malicious OAuth App Identities in Your Tenant

ConnectWise disclosed on Saturday that unknown threat actors gained unauthorized access to application identities associated with its products and used that access to compromise Microsoft 365 tenants. The company has disabled seven ConnectWise application identities while its investigation continues — including ConnectWise Cloud Backup (506e08f9-6e9a-4da4-942b-a099a03644ae), which has been suspended outright.

This is a SaaS supply-chain incident with direct blast radius into customer tenants. If your organization — or your MSP — uses ConnectWise Cloud Backup or any other ConnectWise integration with Microsoft 365, a third-party service principal in your Entra ID tenant may have been operating under attacker control. The identities are disabled by the vendor, but anything the attacker did while holding that access (mailbox reads, data exfiltration, persistence planted in your tenant, modified backup configurations) remains your problem to find and remediate.

The defensive window is now. Every organization with ConnectWise integrations should be auditing service principal sign-in activity, reviewing permissions granted to those applications, and hunting for secondary persistence the attacker may have established while operating with legitimate OAuth tokens.

Technical Analysis

What Was Compromised

The compromised assets are application identities — Entra ID (Azure AD) app registrations and their associated service principals — that ConnectWise products use to integrate with customer Microsoft 365 tenants via OAuth. The confirmed disabled identity is:

• ConnectWise Cloud Backup — App ID 506e08f9-6e9a-4da4-942b-a099a03644ae

Six additional ConnectWise application identities were also disabled (the vendor has indicated seven total). ConnectWise Cloud Backup service has been suspended as a precaution.

How This Attack Works — Defender's View

This is not a vulnerability in the traditional CVE sense — it is identity compromise of a trusted third-party OAuth application, and it maps to a well-documented attack pattern (MITRE ATT&CK T1550.001 – Use Alternate Authentication Material: Application Access Token, and T1098.003 – Account Manipulation: Additional Cloud/App Roles). The attack chain from a defender's perspective:

1. Identity theft at the vendor. The threat actor obtained credentials or tokens for ConnectWise-controlled application identities — most plausibly client secrets, certificates, or refresh tokens stolen from the vendor's environment.
2. Token issuance against customer tenants. Because these app registrations were previously consented in customer tenants (as multi-tenant enterprise applications), the attacker could request valid access tokens for those tenants as the ConnectWise app — no password spray, no phishing, no MFA prompt. The service principal authenticates silently.
3. Tenant access within granted scope. The attacker operated with whatever Microsoft Graph permissions the app held — backup applications typically require broad read access to mailboxes, OneDrive, SharePoint, and Teams data to function. That means potential bulk data access/exfiltration and, critically, insight into backup configurations that could be leveraged to destroy recovery capability ahead of a follow-on attack (e.g., ransomware).
4. Low-and-slow tradecraft. Service principal sign-ins from a known vendor app are notoriously easy to overlook — they blend into expected machine-to-machine traffic and rarely trigger user-centric detections like impossible travel.

This technique mirrors prior high-impact SaaS supply-chain compromises where stolen app credentials or signing keys were used to mint trusted tokens against downstream tenants. The lesson is consistent: consent is a standing trust decision, and vendor compromise converts it into standing attacker access.

Exploitation Status

• Confirmed active exploitation in the wild — ConnectWise states Microsoft 365 tenants were compromised. This is not theoretical.
• No CVE has been assigned — this is an identity/credential compromise, not a software flaw.
• Vendor response in progress — seven app identities disabled, Cloud Backup suspended, investigation ongoing. Treat ConnectWise's guidance as authoritative and monitor their status page for updates.

Who Is Affected

• Organizations (or MSP clients) using ConnectWise Cloud Backup for Microsoft 365.
• Any tenant that consented to any ConnectWise multi-tenant enterprise application — until the full list of seven identities is published, assume all ConnectWise app registrations in your tenant are in scope for audit.

Detection & Response

The highest-fidelity detection surface is your Entra ID sign-in and audit logs. Focus on: (1) service principal sign-ins for the known malicious app ID, (2) anomalous Graph API activity patterns from ConnectWise apps (volume spikes, unusual resource types, after-hours activity), and (3) persistence mechanisms an attacker with app-level access commonly plants — new credentials on existing service principals, new consent grants, mailbox forwarding rules, or inbox rules for exfiltration staging.

Sigma Rules

---
title: Sign-In From Compromised ConnectWise Cloud Backup Application Identity
description: Detects service principal sign-in activity associated with the ConnectWise Cloud Backup application identity (506e08f9-6e9a-4da4-942b-a099a03644ae) that ConnectWise disabled after attackers compromised it and accessed Microsoft 365 tenants.
references:
  - https://thehackernews.com/2026/10/connectwise-suspends-cloud-backup-after.html
  - https://attack.mitre.org/techniques/T1550/001/
author: Security Arsenal
date: 2026/10/19
status: experimental
logsource:
  product: azure
  category: serviceprincipal_signin
detection:
  selection:
    AppId: '506e08f9-6e9a-4da4-942b-a099a03644ae'
  condition: selection
falsepositives:
  - Historical legitimate ConnectWise Cloud Backup activity prior to suspension (review, do not alert-blind)
level: critical
---
title: New Credentials Added to Service Principal or Application
description: Detects addition of client secrets or certificates to app registrations/service principals - a common persistence technique after OAuth app compromise, enabling continued access even after original credentials are revoked.
references:
  - https://thehackernews.com/2026/10/connectwise-suspends-cloud-backup-after.html
  - https://attack.mitre.org/techniques/T1098/001/
author: Security Arsenal
date: 2026/10/19
status: experimental
logsource:
  product: azure
  category: auditlogs
detection:
  selection_operation:
    OperationName|contains:
      - 'Add service principal credentials'
      - 'Update application - Certificates and secrets management'
      - 'Add service principal certificate'
  condition: selection_operation
falsepositives:
  - Legitimate application lifecycle management by admins (correlate with change tickets)
level: high
---
title: Suspicious Application Consent Grant With Broad Graph Permissions
description: Detects admin consent grants to applications requesting high-value Microsoft Graph scopes (Mail.Read, Files.ReadWrite.All, Sites.FullControl.All, full_access_as_app) - a hallmark of malicious OAuth app establishment following identity compromise.
references:
  - https://thehackernews.com/2026/10/connectwise-suspends-cloud-backup-after.html
  - https://attack.mitre.org/techniques/T1528/
author: Security Arsenal
date: 2026/10/19
status: experimental
logsource:
  product: azure
  category: auditlogs
detection:
  selection_operation:
    OperationName: 'Consent to application'
  selection_scope:
    TargetResources|contains:
      - 'Mail.Read'
      - 'Mail.ReadWrite'
      - 'Files.ReadWrite.All'
      - 'Sites.FullControl.All'
      - 'full_access_as_app'
      - 'Directory.ReadWrite.All'
  condition: selection_operation and selection_scope
falsepositives:
  - Legitimate enterprise app onboarding (validate app publisher and business justification)
level: high

KQL — Microsoft Sentinel / Defender Hunting

Run these against your Sentinel workspace. The first two queries are point-in-time forensics over the last 90 days (the maximum retention for Entra sign-in logs in many tenants — export results before they age out).

// Query 1: All service principal sign-in activity for the compromised ConnectWise Cloud Backup app ID
AADServicePrincipalSignInLogs
| where AppId == "506e08f9-6e9a-4da4-942b-a099a03644ae"
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), SignInCount=count(),
            IPs=make_set(IPAddress), Resources=make_set(ResourceDisplayName), Locations=make_set(LocationDetails)
  by AppDisplayName, ServicePrincipalId
| project FirstSeen, LastSeen, SignInCount, IPs, Resources, Locations, AppDisplayName, ServicePrincipalId
;
// Query 2: Hunt ALL ConnectWise enterprise apps in the tenant for anomalous sign-in source IPs
// (flag any sign-in from an IP seen fewer than 5 times historically - possible attacker infrastructure)
AADServicePrincipalSignInLogs
| where AppDisplayName has "ConnectWise" or ServicePrincipalDisplayName has "ConnectWise"
| summarize SignInCount=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
  by AppId, AppDisplayName, IPAddress
| where SignInCount < 5
| sort by LastSeen desc
;
// Query 3: Credentials added to any app/SP during the exposure window (persistence hunt)
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName has_any ("Add service principal credentials", "Update application – Certificates and secrets", "Add service principal certificate")
| mv-expand TargetResources
| extend AppId = tostring(TargetResources.id)
| extend ModifiedProps = TargetResources.modifiedProperties
| project TimeGenerated, OperationName, AppId, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
          IPAddress = tostring(InitiatedBy.user.ipAddress), ModifiedProps
| sort by TimeGenerated desc
;
// Query 4: Mailbox inbox rules created during exposure window (exfiltration staging hunt via OfficeActivity)
OfficeActivity
| where TimeGenerated > ago(90d)
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| extend RuleName = tostring(parse_json(Parameters)[1].Value)
| where RuleName has_any ("forward", "redirect", "delete") or Parameters has_any ("ForwardTo", "RedirectTo", "DeleteMessage")
| project TimeGenerated, UserId, Operation, Parameters, ClientIP
| sort by TimeGenerated desc

Velociraptor VQL — Endpoint Hunt

While the compromise is cloud-side, attackers who achieved tenant access frequently pivot to endpoints using harvested credentials or deploy tooling via the backup/management agent they already control. This hunt looks for interactive use of Entra ID / Graph tooling from endpoints (unusual for end users) and for processes accessing cached Microsoft 365 tokens — both common in the follow-on phase of these intrusions.

-- Hunt endpoints for cloud administration tooling usage and token cache access
-- consistent with post-compromise M365 tenant abuse
LET procs = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
  FROM pslist()
  WHERE CommandLine =~ '(?i)(Connect-MgGraph|Connect-AzureAD|Connect-MgServicePrincipal|Add-MgServicePrincipalKey|New-MgServicePrincipal|MSOnline|Az\.Accounts|New-ApplicationAccessPolicy)'
     OR CommandLine =~ '(?i)identityservice.*(token|cache)'
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM procs

Remediation / Verification Script

The following PowerShell script (requires the Microsoft.Graph module and Application.Read.All, Directory.Read.All permissions) inventories ConnectWise service principals in your tenant, checks for the known compromised app ID, enumerates their granted permissions and credential expiry/creation dates, and flags recently added secrets or certificates.

# ConnectWise OAuth App Identity Audit - run with a Global Admin / Cloud App Admin account
# Requires: Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","AuditLog.Read.All"

$knownBadAppId = "506e08f9-6e9a-4da4-942b-a099a03644ae"

# 1) Enumerate all ConnectWise service principals in the tenant
$cwApps = Get-MgServicePrincipal -All | Where-Object { $_.DisplayName -match "ConnectWise" }
$cwApps | Select-Object DisplayName, AppId, Id, AccountEnabled,
    @{N='CreatedDateTime';E={$_.AdditionalProperties.createdDateTime}} |
    Format-Table -AutoSize

# 2) Check for the known compromised app ID
if ($cwApps.AppId -contains $knownBadAppId) {
    Write-Host "[CRITICAL] Compromised ConnectWise Cloud Backup app identity present in tenant!" -ForegroundColor Red
    Write-Host "    AppId: $knownBadAppId - verify it is disabled and review its full sign-in history." -ForegroundColor Red
}

# 3) Review delegated permission grants (OAuth2 consent) for each ConnectWise SP
foreach ($sp in $cwApps) {
    Write-Host "`n=== Grants for: $($sp.DisplayName) ($($sp.AppId)) ===" -ForegroundColor Cyan
    Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $sp.Id -All |
        Select-Object ClientId, ConsentType, Scope, ResourceId | Format-Table -AutoSize
}

# 4) Review app role assignments (application permissions) granted to ConnectWise SPs
foreach ($sp in $cwApps) {
    Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All |
        Select-Object PrincipalDisplayName, ResourceDisplayName, AppRoleId, CreatedDateTime |
        Format-Table -AutoSize
}

# 5) Flag credentials (secrets/certs) added in the last 90 days on ANY app registration - persistence check
$cutoff = (Get-Date).AddDays(-90)
Get-MgApplication -All | ForEach-Object {
    $app = $_
    $recentSecrets = $app.PasswordCredentials | Where-Object { $_.StartDateTime -gt $cutoff }
    $recentCerts   = $app.KeyCredentials      | Where-Object { $_.StartDateTime -gt $cutoff }
    if ($recentSecrets -or $recentCerts) {
        [PSCustomObject]@{
            DisplayName = $app.DisplayName
            AppId       = $app.AppId
            NewSecrets  = ($recentSecrets | ForEach-Object { $_.StartDateTime }) -join '; '
            NewCerts    = ($recentCerts   | ForEach-Object { $_.StartDateTime }) -join '; '
        }
    }
} | Format-Table -AutoSize

Write-Host "`nNext steps: cross-reference findings with Entra sign-in logs (90-day lookback) and ConnectWise advisories before removing or re-onboarding any integration." -ForegroundColor Yellow

Remediation

Immediate Actions (Today)

1. Confirm whether the compromised app exists in your tenant. Search Entra ID → Enterprise Applications for 506e08f9-6e9a-4da4-942b-a099a03644ae and any ConnectWise publisher apps. If present, verify the service principal is disabled (ConnectWise disabled the app identities vendor-side, but confirm accountEnabled status in your tenant).
2. Pull and preserve sign-in logs before retention expires. Export AADServicePrincipalSignInLogs, AADNonInteractiveUserSignInLogs, and AuditLogs covering the last 90 days for all ConnectWise app IDs. Look for: sign-ins from IP addresses or ASNs that are not ConnectWise infrastructure, sign-ins at unusual volumes/hours, and access to resources (mailboxes, SharePoint sites, Teams) beyond expected backup scopes.
3. Audit what data was touched. Use Microsoft Purview audit search (if licensed) or Unified Audit Log to identify mailbox, SharePoint, and OneDrive access attributed to the ConnectWise app identity during the exposure window. Treat bulk read patterns as confirmed exfiltration and invoke your IR process.
4. Hunt for planted persistence. Review all app registrations and service principals for credentials (secrets/certificates) added during the exposure window — an attacker with app-level access commonly adds credentials to other benign-looking apps to survive the vendor's revocation. Also review inbox forwarding/redirect rules and OAuth consent grants tenant-wide.

Short-Term Actions (This Week)

5. Do not re-enable ConnectWise Cloud Backup until ConnectWise publishes the re-issued application identity and confirms the compromised credentials are fully invalidated. When re-onboarding, verify the new App ID against the vendor's official advisory — never trust a consent prompt that arrives via email or ticket.
6. Review and right-size permissions. If the ConnectWise app held Sites.FullControl.All, Mail.Read, or similarly broad scopes, evaluate whether narrower scopes suffice when service resumes. Apply least privilege at re-consent time.
7. Rotate credentials that may have been exposed. If forensic review shows the attacker accessed mailboxes or files containing stored credentials, API keys, or configuration secrets, rotate them — assume anything readable was read.
8. Validate backup integrity. Given this incident touches a backup product, verify the integrity and availability of your Microsoft 365 backups from alternate copies. An attacker inside your backup pipeline ahead of a ransomware event is the worst-case sequencing — close that gap now.

Structural Defenses

9. Deploy Entra ID Conditional Access for workload identities — restrict where service principals can authenticate from (named locations / trusted IP ranges). This would have blocked token use from attacker-controlled infrastructure even with valid credentials.
10. Enable alerting on service principal credential changes and anomalous SP sign-ins in Sentinel/Defender. Service principal anomalies are among the most under-monitored signals in most SOCs — this incident is the case study for fixing that.
11. Maintain an inventory of all consented third-party enterprise applications with their granted scopes, owners, and business justification. When the next vendor identity compromise lands — and it will — triage speed depends entirely on knowing what's in your tenant.
12. MSP/MSSP customers: require your provider to disclose which ConnectWise integrations are present in your tenant and confirm they've performed the audits above. Supply-chain risk flows downhill; your contract should specify notification and audit obligations.

References

• ConnectWise advisories and status page (monitor for the full list of seven disabled application identities and re-issuance guidance)
• The Hacker News coverage: https://thehackernews.com/2026/10/connectwise-suspends-cloud-backup-after.html
• MITRE ATT&CK: T1550.001 (Application Access Token), T1098.001 (Additional Cloud Credentials), T1528 (Steal Application Access Token)
• Microsoft guidance: Securing workload identities and service principals and investigating compromised service principals

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub