Could Your Microsoft 365 Tenant Be Exposed by the ConnectWise Cloud Backup Breach?

‍

If you use ConnectWise Cloud Backup (formerly SkyKick) in Microsoft 365, treat this like a “trust-but-verify” moment. A supply-chain hit can skip user MFA because the attacker isn’t logging in as a person. They’re logging in as your backup app, using an app secret that already has permissions inside your tenant . That’s what makes this incident so uncomfortable: the access can look “legitimate” unless you know exactly what to hunt for.

What actually happened (and why MFA didn’t save you)

ConnectWise Cloud Backup (formerly SkyKick) isn’t just “a backup login.” In Microsoft 365, it operates as an Entra ID application inside your tenant. That application is represented by a service principal and it gets whatever Microsoft Graph permissions you (or your MSP) granted during setup. That design is normal for SaaS backups. It’s also why this incident matters.

Based on reporting from Microsoft and multiple security teams, attackers gained unauthorized access to application identities in the ConnectWise Cloud Backup environment, then used those stolen app credentials to authenticate straight into customer Microsoft 365 tenants as the backup application . No password guessing. No “user” to phish. Just app-to-app auth.

The simple attack path (plain English)

Here’s the flow most people miss:

1. Vendor gets hit (supply-chain compromise)

The attacker gets access to the backup service’s app identities/credentials in the vendor environment .

2. Attacker signs into your tenant as the app

In Entra ID, this shows up as a service principal sign-in, not an interactive user sign-in .

3. Microsoft Graph access happens under “legitimate” permissions

If the app already had broad consent, those tokens can allow reading or writing data across Exchange, OneDrive, SharePoint, Teams, and more—whatever was already granted .

This is the uncomfortable part: the access can look “allowed,” because technically it is allowed.

Why MFA didn’t save you

Most MFA policies protect user logins (interactive sign-ins). This attack didn’t need a user at all. It used application authentication (service principal + secret/cert). Security teams explicitly noted the activity was automated/scripted and did not involve a user login, making user MFA ineffective .

So if you’re thinking, “All admins have MFA, we’re fine,” that’s a half-truth. You might be protected from a phish. You’re not automatically protected from a trusted third-party app getting abused.

Timeline and scope (what we know)

Reports tie suspicious activity to mid-October. Microsoft confirmed it saw unauthorized authentication attempts from a single IP on October 15 . Huntress publicly stated it identified at least 162 compromised tenants . ConnectWise said it identified unauthorized access to app identities and shut down Cloud Backup application access for partners/clients as part of containment .

Also worth knowing: investigations didn’t all agree on “how far it went” inside every tenant. One team analyzing a smaller set of intrusions saw sign-in activity but didn’t find evidence of account creation or password changes through the backup app . Another set of observations described directory role assignments and persistence attempts involving related Cloud Management apps in some tenants . That gap is exactly why you should verify in your logs, not rely on headlines.

At this point, the key takeaway is simple: this was a ConnectWise Cloud Backup supply-chain attack that targeted Microsoft 365 tenants through service principal authentication, and it bypassed MFA because it didn’t need a person to log in .

The specific signs to check in your tenant (don’t overthink it)

You don’t need a fancy threat hunt to get signal fast. You need to look in the right place, for the right app, and match a few very specific indicators that have already been tied to this incident.

Start here: Entra ID sign-in logs (service principal sign-ins)

You’re looking for non-interactive app authentication tied to ConnectWise Cloud Backup.

What to filter on (high confidence):

• Application (Client) ID: 506e08f9-6e9a-4da4-942b-a099a03644ae (ConnectWise Cloud Backup)
• Source IP address: 144.172.64.128
• User agents associated with scripted activity:
• curl/7.88.1
• python-urllib/3.12
• python-requests/2.31
• python-requests/2.34.2

How to read what you find:

• A hit on the app ID alone isn’t automatically bad. It just means the backup tool (or something posing as it) authenticated.
• A hit where app ID + the IP/user-agent above line up is when you stop debating and start treating it as potential compromise.

Don’t get tripped up by naming (tenants are messy)

Even if you don’t use “ConnectWise Cloud Backup” anymore, older tenants can have leftover enterprise apps. Huntress called out that Cloud Management apps may appear under older SkyKick naming, like “SkyKick Cloud Manager” .

So, broaden your search beyond the one Cloud Backup app.

Expand the net: related ConnectWise / SkyKick app IDs to check

These have been shared as relevant application IDs worth hunting for in Entra ID :

• ConnectWise Cloud Management: 2399d300-6fca-4e6a-a686-399fefe75b83
• ConnectWise Cloud Management - MS Teams: 24205314-2b89-4e07-a2a4-579e898a5640
• ConnectWise Cloud Management - Exchange Online: b78f6a77-d4e5-46fb-87e5-d1648bd02519
• ConnectWise Cloud Management - MS Graph: 0de14c77-b9b0-4137-9360-34878a929827
• ConnectWise Cloud Management - Partner Center: 412dcf96-176d-4b3a-a1b0-4981ad66971e
• ConnectWise Cloud Management - SharePoint Online: b2b55f5b-7758-4719-8d8f-88ae172e6bdb

Treat these as “related surface area.” If an attacker got working app credentials once, they’ll try the other doors too.

Quick triage checklist (10 minutes, no overthinking)

Pull up sign-in logs and answer these in order:

1. Do we see service principal sign-ins for 506e08f9-...?
2. Any sign-ins from 144.172.64.128?
3. Any sign-ins with curl / python-requests / python-urllib user agents?
4. Do any of the Cloud Management app IDs show unusual sign-in patterns around the same window?

If you get a “yes” on #1 plus either #2 or #3, you’ve got enough reason to move into containment and credential review rather than staring at dashboards.

Response checklist: contain it fast, then clean it properly

If your tenant shows suspicious service principal activity tied to ConnectWise/SkyKick apps, your goal is simple: stop new access quickly, then work the cleanup methodically. Don’t mix those up.

Step 1: Contain (stop new tokens and new actions)

Do these in order:

1. Disable the implicated enterprise applications in Entra ID

• Huntress explicitly advised disabling the impacted ConnectWise applications and reviewing related Cloud Management integrations .
• Don’t disable just the “backup” app and call it done. Include the broader ConnectWise Cloud Management app set if it exists in your tenant .

2. Scope the blast radius before you touch anything else

• Export evidence now (sign-in logs, audit logs). If you start deleting credentials first, you can wipe out the trail you’ll need for your incident report.

3. Temporarily block access paths you can control

• If an MSP integration is involved, pause automation that depends on these apps until you’ve confirmed which service principals were touched.

Step 2: Clean (remove persistence and close the same door everywhere)

This is where most teams under-react.

Review and remove app credential changes (since Oct 13)

Microsoft recommended reviewing application credential changes and OAuth grants, plus related Graph activity .

Huntress added a key detail: admins should review secrets and certificates across all applications for unauthorized additions since October 13 and remove them .

What to do:

• In Entra ID, check Certificates & secrets (and any equivalent credential listings) on:
• The ConnectWise Cloud Backup service principal
• Any related ConnectWise/SkyKick Cloud Management service principals
• Any other high-privilege apps you rely on (attackers like to pivot)
• Look for:
• New secrets/certs added
• Unexpected credential names
• Credential lifetime changes (longer expiry than you normally allow)

Review OAuth grants / app consent

OAuth grants are “quiet permissions.” If consent was modified, the attacker may not need to add new users at all.

Focus on:

• Newly granted admin consent
• Apps suddenly holding broader Graph permissions than your backup tool should need

Step 3: Token reality check (the part that ruins “we disabled it” confidence)

Disabling an enterprise application is necessary, but it’s not magic.

Todyl’s warning is the one to take seriously: disabling an application stops new tokens from being issued, but existing tokens can remain valid until they expire, and revoking user sessions doesn’t end application-based access .

Practical impact:

• You may still see activity for a bit after shutdown, depending on token lifetimes.
• Your response plan should assume a window where previously issued app tokens could still work.

Minimal “done right” checklist (printable)

• Disable impacted ConnectWise/SkyKick enterprise apps
• Pull and save Entra sign-in logs + audit logs (before making changes)
• Review app credential additions since Oct 13 across all apps; remove anything suspicious
• Review OAuth grants and any unusual Graph activity

• Rotate secrets/certs broadly (don’t assume only one app is “the” app)
• Plan for token expiry; don’t assume “disabled” equals “no access”

MSP playbook: triage across many tenants without losing your mind

When you’re an MSP, the hard part isn’t “what to look for.” It’s doing the same check across 20, 50, or 200 Microsoft 365 tenants and still trusting your results.

Standardize your sweep (same query, every tenant)

Pick one workflow and don’t improvise mid-incident.

Baseline rule: run the exact same Entra ID sign-in log checks everywhere, then compare outputs.

Minimum export fields (so your spreadsheet isn’t useless):

• Time (UTC)
• Tenant name / Tenant ID
• Service principal / Enterprise app name
• Application (client) ID
• IP address
• User agent
• Result (success/failure)
• Correlation ID (when available)

This incident is noisy because it’s app-based. Having identical export fields is what lets you spot patterns fast, like repeated attempts from the same infrastructure.

Prioritize “role assignment” tenants first

Not every tenant is equal risk. Huntress reported a more aggressive pattern in some environments: ConnectWise Cloud Management apps assigning themselves directory roles, “mostly Exchange Administrator” . In at least one case, Huntress observed persistence activity within minutes, including a Cloud Management Teams app assigning Global Administrator and adding credentials to other applications .

Triage order that makes sense:

1. Tenants where any ConnectWise/SkyKick Cloud Management enterprise app exists
2. Tenants where you see directory role changes tied to a service principal
3. Tenants where you see new app credentials added (secrets/certs) after the suspicious window started
4. Everyone else

If you’re short on time, this is how you avoid spending an hour on low-signal tenants while a high-impact tenant sits untouched.

Build a clean “app inventory” view per tenant

Tenants accumulate junk over years. Huntress noted older tenants may list Cloud Management apps under “SkyKick Cloud Manager” .

So don’t rely on names alone.

What to track per tenant:

• All ConnectWise/SkyKick-related enterprise apps you find (including old SkyKick naming)
• Whether each app is:
• Enabled/disabled
• Assigned any directory roles
• Holding any recently added secrets/certs

Hardening for next time (reduce the blast radius)

Once the fire is out, you want fewer apps with broad access sitting around “just in case.”

Practical cleanup moves:

• Prune unused enterprise apps (if it’s not used, it shouldn’t exist)
• Tighten app permissions to what’s actually required (backups don’t need the keys to everything by default)
• Make app reviews routine: permissions + credentials + last sign-in

A note on vendor/portal sprawl (where Cloaked fits)

A lot of MSP exposure doesn’t come from Graph permissions. It comes from the sprawl of vendor portals, trials, and admin sign-ups that pile up over time.

Using Cloaked for separate identities—like masked emails and phone numbers—for vendor sign-ups and admin-facing workflows can shrink that day-to-day exposure when a vendor ecosystem becomes the weak link. It’s not a fix for service-principal abuse inside Entra, but it can help keep “who has your real admin contact info” under control when you’re managing dozens of SaaS relationships.

‍