Securing Vendor Credentials After ConnectWise

When ConnectWise suspended its Cloud Backup service due to a credential compromise, it exposed a significant weakness in how organizations manage vendor access to cloud environments. Huntress identified unauthorized sign-ins in 162 tenants. Microsoft confirmed attackers exploited permissions like Directory.ReadWrite.All, turning the credential into a skeleton key.

This isn't theoretical. Your backup vendor needs read access to mail, files, Teams, and directory data. If compromised, an attacker can assign themselves Global Administrator rights, create new applications, reset authentication methods, and modify Conditional Access policies. Each step creates another entry point that survives credential rotation.

Essential Preparations

To manage vendor credentials effectively, your team needs:

Inventory of service principals and enterprise applications. You can't secure what you can't see. Export your Azure AD application registrations and service principals with assigned permissions.

Permission baselines for each vendor category. Backup tools need different access than help desk software. Document what each vendor type legitimately requires.

Monitoring infrastructure. Enable audit logs in Azure AD and Microsoft 365, and forward them to a SIEM or log aggregation platform. The free tier of Azure AD doesn't retain audit logs long enough for forensic analysis.

Step-by-Step Implementation

Phase 1: Audit Current Vendor Access

Start in Azure AD. Navigate to Enterprise Applications and export the full list. For each application with directory-level permissions:

Get-AzureADServicePrincipal -All $true | 
Where-Object {$_.AppRoles -ne $null} | 
Select-Object DisplayName, AppId, AppRoles | 
Export-Csv -Path "vendor-permissions-audit.csv"

Flag any application with Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, or Application.ReadWrite.All. These permissions let an application modify its own access or create new credentials.

Cross-reference this list against your vendor register. You'll find forgotten applications, test integrations that were never decommissioned, and vendors whose contracts expired months ago.

Phase 2: Implement Least Privilege for Backup Tools

Backup applications don't need write access to your directory. They need read access to content and the ability to restore it to a specific location.

For Microsoft 365 backup vendors, the minimum viable permission set is:

• Mail.Read (not Mail.ReadWrite)
• Files.Read.All (not Files.ReadWrite.All)
• Sites.Read.All (not Sites.FullControl.All)
• User.Read.All (not Directory.ReadWrite.All)

If your vendor requires broader permissions, document the business justification in writing. Ask them to specify which restore scenarios require write access and whether those scenarios can be handled through admin-initiated workflows instead.

Phase 3: Deploy Conditional Access for Service Principals

Microsoft added Conditional Access support for workload identities in 2023. Create a policy that applies to all service principals:

1. Navigate to Azure AD > Security > Conditional Access
2. Create a new policy targeting "Workload identities"
3. Set conditions: Include all workload identities, exclude known-good applications
4. Grant controls: Require compliant device (for user-interactive flows) or restrict to specific IP ranges

For backup vendors, restrict authentication to their documented datacenter IP ranges. If they can't provide a static IP list, that's a vendor due diligence finding.

Phase 4: Enable Application-Specific Audit Alerts

Configure alerts for privilege escalation by service principals:

New-AzActivityLogAlert -Name "ServicePrincipalRoleAssignment" `
  -ResourceGroupName "security-monitoring" `
  -Condition @{
    field = "operationName"
    equals = "Add member to role"
  } `
  -Condition @{
    field = "properties.initiatedBy.app"
    exists = "true"
  }

This triggers when any application assigns a directory role. Normally, this should be rare. During an incident like ConnectWise, it's the first indicator.

Phase 5: Implement Credential Rotation Procedures

Create a quarterly credential rotation schedule for high-risk vendor integrations. For OAuth applications, this means:

1. Generate new client secret in Azure AD
2. Provide new secret to vendor through secure channel
3. Verify vendor has updated their configuration
4. Revoke old secret
5. Monitor for authentication failures

Don't rotate all vendors simultaneously. Stagger rotations across the quarter to isolate any access issues.

Validation

Test your controls with a simulated credential compromise:

1. Create a test service principal with backup-level permissions
2. Attempt to assign it a directory role using its own credentials
3. Verify your Conditional Access policy blocks the assignment
4. Confirm your audit alert fires within 5 minutes
5. Validate you can identify the source application in your SIEM

If any step fails, your controls have gaps.

For managed service providers, test cross-tenant access controls. Create a test customer tenant and verify a compromised credential in one tenant can't pivot to others.

Maintenance

Weekly: Review new service principal creations. Any application created outside your vendor intake process is suspicious.

Monthly: Audit permission changes. Export AppRoleAssignments and compare against your baseline. Investigate any additions of Directory.ReadWrite.All or RoleManagement permissions.

Quarterly: Rotate credentials for vendors with directory-level access. Document the rotation in your vendor management system.

After any vendor security incident: Review that vendor's permission scope. Even if you weren't directly affected, use the incident as a trigger to validate least privilege.

The ConnectWise incident showed that vendor credential compromise isn't just about data exfiltration. It's about privilege escalation, persistence, and lateral movement. Your backup vendor's credentials can become an attacker's administrative access. Treat them accordingly.