On October 15, unauthorized authentication attempts hit ConnectWise's Cloud Backup service. Within hours, attackers had compromised at least 162 Microsoft 365 tenants. They didn't crack passwords or bypass MFA. They exploited application identities, service principals that your monitoring likely ignores.
What Happened
Attackers accessed ConnectWise's Cloud Backup infrastructure and used it to target customer Microsoft 365 environments. They exploited existing service principal permissions to assign themselves elevated directory roles, like Exchange Administrator. This wasn't a credential stuffing attack or a phishing campaign. The breach exploited the trust relationship between ConnectWise's backup service and its customers' Microsoft Entra ID tenants.
The attack succeeded because service principals, non-human identities that applications use to authenticate, operate outside the security controls you've built for user accounts. No MFA requirement. No impossible travel alerts. No behavioral analytics flagging unusual login patterns.
Timeline
October 15: Unauthorized authentication attempts detected from a specific IP address targeting ConnectWise infrastructure.
Same day: Attackers begin accessing compromised Microsoft 365 tenants through legitimate service principal credentials.
Hours after initial access: Service principals assign themselves Exchange Administrator and other directory roles across multiple tenants.
Following days: Reconnaissance activity observed as attackers enumerate mailboxes, explore tenant configurations, and establish persistence mechanisms.
The speed of lateral movement, from initial compromise to privilege escalation across 162 tenants, demonstrates how application identity attacks bypass your existing detection layers.
Which Controls Failed
Application identity monitoring: Most organizations monitor user sign-ins but don't track service principal authentication events. You're watching the front door while attackers walk through the service entrance.
Privilege escalation detection: When a service principal assigns itself a new directory role, that's an immediate red flag. Yet standard Microsoft 365 audit configurations don't alert on these events by default.
Third-party access review: How many service principals have permissions in your tenant right now? Which vendors do they belong to? When were those permissions last reviewed? For most teams, the answer is "we don't know."
Supply-chain validation: The ConnectWise service had legitimate permissions to access customer tenants. Organizations trusted those permissions without implementing compensating controls to detect misuse.
What Standards Require
ISO/IEC 27001:2022 Control 5.19 (Identity and access management) requires you to manage the full lifecycle of identities, including non-human identities. Service principals need the same governance as user accounts: regular access reviews, least-privilege principles, and monitoring.
NIST CSF v2.0 PR.AA-06 mandates that physical and logical access to assets be managed based on risk. A service principal with Exchange Administrator rights represents significant risk. Your access management framework must account for it.
NIST 800-53 Rev 5 AC-2 (Account Management) explicitly includes "system accounts" in its scope. That's your service principals. The control requires you to monitor account usage, review privileges regularly, and disable accounts when no longer needed.
PCI DSS v4.0.1 Requirement 8.2.2 states that all users must be authenticated before access is granted. Service principals are users in this context. You need to verify not just that authentication occurred, but that the authentication was legitimate and expected.
Lessons and Action Items
Inventory your service principals now. Run this PowerShell command in your Microsoft 365 tenant:
Get-AzureADServicePrincipal -All $true | Select-Object DisplayName, AppId, ObjectId
Document which applications own each principal, what permissions they hold, and why those permissions are necessary.
Enable service principal sign-in logging. In Microsoft Entra ID, navigate to Diagnostic Settings and ensure you're capturing ServicePrincipalSignInLogs. Route these to your SIEM. You can't detect anomalies in data you're not collecting.
Alert on role assignments to service principals. Create a detection rule that fires when a service principal is assigned a directory role. The event is captured in the AuditLogs table with OperationName "Add member to role" where the target is a service principal object type. This should trigger immediate investigation.
Implement conditional access for applications. Microsoft Entra ID supports conditional access policies for service principals. Restrict which IP ranges can authenticate as your service principals. The ConnectWise attack used a specific IP address; geography-based restrictions would have blocked it.
Review third-party permissions quarterly. Every vendor integration that touches your Microsoft 365 environment uses a service principal. Treat these reviews like you treat user access reviews: document business justification, verify least privilege, remove permissions that are no longer needed.
Separate backup service accounts from administrative roles. A backup service principal should have backup permissions, not Exchange Administrator rights. If ConnectWise needed broader access, that's a conversation about architecture, not a reason to grant excessive permissions.
Build a service principal baseline. For each service principal, document: normal authentication frequency, expected source IP ranges, typical API calls. Deviations from this baseline should trigger alerts. You're looking for the same behavioral anomalies you track for user accounts.
The ConnectWise breach succeeded because organizations treated application identities as infrastructure instead of as security-critical assets. Your service principals have keys to your environment. Start treating them like the privileged accounts they are.
