Compliance

ConnectWise Breach: Audit M365 App Permissions Now

ConnectWise Breach: Audit M365 App Permissions Now

Know what attackers see before they do. See a live Radar report →

If you manage Microsoft 365 for a small business, you've probably clicked Accept on a vendor's permission request without reading past the first line. Most of the time that's fine. But the recent ConnectWise/SkyKick incident is a reminder that one of those fine clicks can hand an attacker a direct line into your tenant — no phishing email, no malware, just a trusted vendor's credentials being used exactly as designed.

What Actually Happened

According to Security News, ConnectWise disabled cloud backups amid concerns for downstream MSPs after attackers were confirmed to have authenticated directly into customer Microsoft 365 tenants using ConnectWise credentials. The attackers didn't need to break Microsoft's security — they walked in through an enterprise application connection that customers had already approved, then self-granted Global Administrator privileges once inside. That's the part small business owners miss: a compromised vendor credential doesn't just expose the vendor's systems, it can expose every tenant that vendor has a standing connection to.

This isn't an isolated pattern. The same week, according to The Hacker News, attackers abused UpdraftCentral keys to plant backdoors on WordPress sites by hijacking the trusted connection keys that customers had already granted to that backup vendor. Different platform, same playbook: breach the vendor, weaponize the access customers already handed over.

Why Standard M365 Hygiene Doesn't Catch This

MFA, conditional access, and strong password policies protect against someone guessing or phishing a user's credentials. They do almost nothing against an enterprise application that already has delegated or application-level permissions in your tenant. Once an app is consented to — especially with admin consent — it can operate independently of normal sign-in protections. If the vendor behind that app is compromised, the attacker inherits whatever scope your organization granted, which in incidents like this one can include directory read/write access, mail access, or in the worst case, the ability to elevate to Global Admin.

This is exactly the blast radius we walk through in our guide to auditing and revoking M365 OAuth app permissions — most tenants are running far more enterprise app connections than anyone remembers approving.

Audit Steps You Can Take Today

  1. Open the Enterprise Applications blade in Entra ID (Azure AD) and sort by permissions granted, not by name. Look specifically for anything with Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, or Mail.ReadWrite.
  2. Identify every app tied to an MSP tool, backup vendor, or billing/PSA platform — these are the highest-value targets because they're built to have broad access by default.
  3. Check consent dates and last sign-in activity. An app that hasn't authenticated in six months but still holds admin-level scope is a liability sitting dormant.
  4. Revoke anything you can't immediately justify. If you can't name the business reason for an app's access within 30 seconds, it shouldn't still have it.
  5. Re-grant permissions at the narrowest scope possible when re-adding a legitimate integration, and document who approved it and why.

If your organization uses ConnectWise, SkyKick, or any similar PSA/backup integration, treat this as urgent, not routine. Rotate any shared credentials, review sign-in logs for anomalous admin activity, and confirm with the vendor directly what remediation steps they've taken.

The Bigger Lesson: Vendor Trust Isn't Static

Granting an app permission isn't a one-time decision — it's an ongoing liability that needs periodic review, the same way you'd review who owns admin credentials in your organization or run through an offboarding checklist when an employee leaves. A vendor relationship can end quietly, but the app connection it left behind doesn't expire on its own. The ConnectWise incident is proof that the question isn't if a vendor you trust will eventually have a bad day — it's whether your tenant is structured so that their bad day doesn't automatically become yours.

Take Action

Proactive scanning catches over-privileged app connections and misconfigurations before an attacker finds them for you. Oscar Six Security's Radar scan is an affordable, no-commitment way to get a clear picture of your Microsoft 365 exposure — including risky enterprise app permissions — for just $99. Check out our Radar solutions and find out what's quietly connected to your tenant before it becomes a headline.

Focus Forward. We've Got Your Six.

Frequently Asked Questions

What happened in the ConnectWise/SkyKick breach?

Attackers compromised ConnectWise credentials and used them to authenticate directly into customer Microsoft 365 tenants, then self-granted Global Administrator privileges through an enterprise application connection. ConnectWise disabled cloud backups for downstream MSPs in response to contain the impact.

How do I check which third-party apps have access to my Microsoft 365 tenant?

Go to Entra ID (Azure AD) > Enterprise Applications and review each app's granted permissions, sorting by scope rather than name. Focus on apps with directory read/write or role management permissions, which indicate admin-level access.

Can a compromised vendor really get Global Admin access to my M365 tenant?

Yes, if an enterprise application tied to that vendor was previously granted broad permissions, a compromised vendor credential can be used to escalate privileges within your tenant, as seen in the ConnectWise/SkyKick incident. This is why reviewing and limiting app consent scope is critical, not optional.

What is the best way to audit M365 enterprise app permissions for a small business?

Small businesses can manually review the Enterprise Applications blade in Entra ID, or use an affordable third-party scan like Oscar Six Radar ($99) to surface over-privileged apps, stale connections, and misconfigurations automatically. Regular audits, ideally quarterly, catch dormant high-risk apps before they're exploited.

Does MFA protect against OAuth app permission abuse?

No, MFA protects user sign-ins but does nothing to limit what an already-consented enterprise application can do within your tenant. Once an app has been granted permissions, it can operate independently of MFA and conditional access policies until those permissions are revoked.

Step-by-Step Guide

  1. Open Enterprise Applications

    In Entra ID (Azure AD), navigate to the Enterprise Applications blade and sort by granted permissions rather than app name.

  2. Flag high-risk permission scopes

    Identify apps with Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, or Mail.ReadWrite access, which carry the highest blast radius if compromised.

  3. Check activity and consent dates

    Review last sign-in activity for each app; dormant apps with admin-level scope are a liability even if unused.

  4. Revoke unjustified access

    Remove permissions for any app you can't immediately explain the business need for.

  5. Re-grant at minimum scope

    When reconnecting legitimate integrations, grant the narrowest permission scope possible and document the approval.

Find out what's exposed. Radar scans your external attack surface and shows you exactly what needs fixing. See a sample report →