ConnectWise Supply-Chain Attack: How to Audit and Secure Microsoft 365 Application Identities

According to early reports from BleepingComputer and The Hacker News, ConnectWise has shut down customer access to its Cloud Backup service (formerly SkyKick Cloud Backup) after hackers accessed application identities and compromised Microsoft 365 tenants. This isn’t just another vendor breach—this is a textbook example of how overly permissive application identities can turn a single supply-chain compromise into mass tenant exposure.

The real danger here isn’t just what happened at ConnectWise. It’s what’s sitting in your Microsoft 365 tenant right now: third-party applications with enterprise administrator consent, service principals you’ve forgotten about, and OAuth tokens with permissions that would make an attacker weep with joy. Let’s use this incident as a wake-up call to master a critical defensive skill—auditing and hardening Microsoft 365 application identities and service principals.

Table of Contents

• What Happened in the ConnectWise Breach
• Understanding the Threat Surface: Application Identities in M365
• Auditing Service Principals and App Registrations
• Scoping Permissions and Applying Least Privilege
• Building Detection for Suspicious Application Activity
• Defense in Depth for Supply-Chain Risk

What Happened in the ConnectWise Breach

ConnectWise Cloud Backup is a managed service provider (MSP) tool used to back up customer data in Microsoft 365 environments. According to early reports, attackers gained access to the application identities used by ConnectWise to connect to customer tenants. Once compromised, those application credentials allowed the attackers to authenticate directly into customer Microsoft 365 environments—no phishing, no password spray, just legitimate API access with enterprise-level permissions.

This is supply-chain attack tradecraft at its finest. The attackers didn’t need to breach hundreds of individual organizations; they breached one trusted vendor and rode the existing trust relationships straight into victim tenants. ConnectWise had to shut down the service to contain the damage, but the lesson is universal: every third-party app you authorize in Microsoft 365 is a potential pivot point.

Understanding the Threat Surface: Application Identities in M365

Microsoft 365 uses two core constructs to enable third-party applications and automated workflows: App Registrations and Service Principals. When you grant a SaaS vendor like ConnectWise access to your tenant, you’re typically creating or approving a service principal with delegated or application permissions. These identities authenticate via OAuth 2.0 and can operate 24/7 without user interaction.

Here’s the problem: most organizations grant admin consent during initial onboarding and never look back. Years later, you’ve got dozens of zombie apps with Mail.Read, Files.ReadWrite.All, or even RoleManagement.ReadWrite.All permissions. If any of those vendors gets compromised—or goes rogue—they have the keys to your kingdom.

For security professionals looking to deepen their understanding of cloud identity architectures and OAuth flows, platforms like Coursera offer courses on identity and access management that cover these concepts in detail, often tied to real-world case studies like this one.

Auditing Service Principals and App Registrations

The first step in hardening your Microsoft 365 tenant against supply-chain attacks is knowing exactly what applications have access. Let’s audit service principals using Microsoft Graph PowerShell, a tool every M365 admin should have in their kit.

Install and Connect to Microsoft Graph PowerShell

# Install the Microsoft Graph PowerShell SDK if not already installed
Install-Module Microsoft.Graph -Scope CurrentUser

# Connect to Microsoft Graph with appropriate scopes
Connect-MgGraph -Scopes "Application.Read.All", "Directory.Read.All"

List All Service Principals with Permissions

# Retrieve all service principals and display key attributes including app permissions
Get-MgServicePrincipal -All | Select-Object DisplayName, AppId, ServicePrincipalType, @{Name="AppRoles";Expression={$_.AppRoles.Value -join ", "}} | Format-Table -AutoSize

# Export to CSV for deeper analysis
Get-MgServicePrincipal -All | Select-Object DisplayName, AppId, ServicePrincipalType, AccountEnabled, CreatedDateTime | Export-Csv -Path "ServicePrincipals_Audit.csv" -NoTypeInformation

This gives you a snapshot of every application identity in your tenant. Look for apps you don’t recognize, apps created years ago that haven’t been used recently, and especially apps with “Application” (not “Delegated”) permissions—those run without user context and are prime targets for abuse.

Enumerate OAuth Permissions Granted to Each App

# Get OAuth2 permission grants (delegated permissions) across the tenant
Get-MgOauth2PermissionGrant -All | Select-Object ClientId, ResourceId, Scope, ConsentType | Export-Csv -Path "OAuth_Permissions_Audit.csv" -NoTypeInformation

This command reveals which apps have been granted delegated permissions and the scope of those permissions (e.g., Mail.Read, Files.ReadWrite.All). Cross-reference the ClientId with your service principals list to identify high-risk combinations.

Scoping Permissions and Applying Least Privilege

Once you’ve identified your application identities, it’s time to apply the principle of least privilege. A backup tool like ConnectWise Cloud Backup might legitimately need Mail.Read or Files.Read.All, but does it really need User.ReadWrite.All or RoleManagement.ReadWrite.All? Probably not.

Review each application’s permission set and ask:

• Does this app still serve a business function?
• Are the permissions necessary for that function?
• Can we restrict the scope to specific users or groups instead of tenant-wide?
• Is there a more restrictive permission that accomplishes the same goal?

For example, instead of granting Files.ReadWrite.All (which allows access to all SharePoint and OneDrive files), consider scoping access to a specific SharePoint site using application-specific permissions or Conditional Access policies.

If you’re looking to build deeper skills in cloud security and policy enforcement, DataCamp offers hands-on exercises in cloud platform security and identity governance that complement real-world defense work.

Building Detection for Suspicious Application Activity

Auditing is essential, but detection is what catches active compromise. Microsoft 365 logs extensive telemetry on service principal activity, and you should be monitoring it.

Key Indicators of Compromise for Application Identities

• Unusual sign-in locations: Service principals authenticating from regions where you don’t have infrastructure.
• Spikes in API calls: Sudden increases in Mail.Read or Files.Read operations could signal data exfiltration.
• Permission escalation: An app requesting or being granted new, more privileged permissions.
• Sign-ins outside business hours: Backup apps might run on a schedule; deviations are suspicious.

Query Azure AD Sign-In Logs for Service Principal Activity

# Use Microsoft Graph to retrieve sign-in logs for service principals (app sign-ins)
Get-MgAuditLogSignIn -Filter "signInEventTypes/any(t: t eq 'servicePrincipal')" -Top 100 | Select-Object CreatedDateTime, AppDisplayName, IpAddress, Location, Status | Format-Table -AutoSize

Automate this query to run daily and alert on anomalies—new IPs, failed authentication attempts, or sign-ins from flagged countries. Integrate with your SIEM (Azure Sentinel, Splunk, Elastic) for correlation with other threat intelligence.

Defense in Depth for Supply-Chain Risk

The ConnectWise breach underscores a hard truth: you can’t fully trust third-party vendors, no matter how reputable. Your defense must account for the possibility that any vendor—SaaS, MSP, or cloud service—could be compromised or act maliciously.

Practical Mitigations

1. Require admin approval for all app consent requests. Disable user consent for OAuth apps in your Azure AD tenant settings. Force every app registration through a security review process.

2. Use Privileged Identity Management (PIM) for app permissions. Where possible, avoid permanent high-privilege application permissions. Azure AD PIM can enforce time-bound access even for service accounts.

3. Segment sensitive data. Don’t store crown jewel data in locations accessible to broad application permissions. Use sensitivity labels and information barriers to restrict access.

4. Rotate app secrets and certificates. Many breaches exploit stale, leaked credentials. Enforce 90-day rotation policies and use Azure Key Vault for secret management.

5. Monitor third-party risk continuously. Track vendor security posture, review their compliance reports, and maintain an inventory of all third-party integrations. When a breach is disclosed, you need to know within minutes whether you’re affected.

Supply-chain attacks like the ConnectWise breach are not anomalies—they’re a feature of the modern threat landscape. The organizations that survive aren’t the ones with perfect vendors; they’re the ones who assume compromise, limit blast radius, and detect abuse fast. Start your audit today. Export those service principals. Question every permission. Your Microsoft 365 tenant—and your career—will be better for it.