Did the ConnectWise Breach Reach Your Tenant? Run These 7 Entra Checks Today

When a vendor tells you the breach is "contained", they mean their side of it. That's a very different thing from your tenant being clean.

The ConnectWise incident is a good example. Once the affected application connection was disabled, no new sign-ins could happen through it. Reassuring, right? Except disabling an app only stops the door from opening again. It does nothing about who already walked through it, what they picked up, and what they left behind. If an attacker added a second credential to a service principal, consented to a fresh OAuth app, or quietly bumped a role assignment while they had access, pulling the original connection changes none of that. Those footholds persist. Some of them survive password resets, MFA rollouts, and even the vendor's own remediation.

So "ConnectWise fixed it" is not the all-clear. It's the starting gun for your own audit. Below is the sequence we run for clients at Cloudworks, written so you can follow it in your own tenant today. You'll need Global Reader at minimum, though some steps want Security Administrator or Privileged Role Administrator to act on what you find. Microsoft Entra admin centre and a PowerShell session with the Microsoft Graph module will cover everything here.

1. Review service principal sign-ins

Start where the breach actually lands: the service principal. This is the identity the ConnectWise or SkyKick app uses to act inside your tenant, and its sign-in history is the clearest record of whether that identity did anything unexpected.

In Entra, go to Sign-in logs and switch to the Service principal sign-ins tab. Filter to the application in question. Look for sign-ins from IP ranges or countries that don't match the vendor's normal infrastructure, bursts of activity at odd hours, or a sudden spike in volume. One client of ours spotted a cluster of service principal sign-ins over a weekend when no technician was rostered — that was the thread that unravelled the whole thing.

Note the dates. You'll use that window to scope every other check. If the suspicious activity ran from, say, the 12th to the 15th, those are the days you scrutinise hardest across OAuth grants, credentials and role changes.

2. Audit OAuth consent grants

This is the one people miss, and it's often where the real damage sits. An attacker with a foothold can consent to new applications on behalf of your tenant. Those apps then hold their own permissions — to read mail, access files, send on behalf of users — completely independent of the app you just disabled.

In Entra, open Enterprise applications, then Consent and permissions, and review recently added applications. Better still, run a Graph query to list OAuth2 permission grants and sort by creation date:

Get-MgOauth2PermissionGrant -All | Sort-Object CreatedDateTime -Descending

Pay close attention to any grant that appeared during your suspicious window. Watch for high-privilege scopes like Mail.ReadWrite, Files.ReadWrite.All, Directory.ReadWrite.All, or anything granting application-level (not delegated) access. Application permissions don't need a user to sign in, which makes them a favourite for persistence. If you find a consent grant you can't explain, revoke it — but log the details first, because it tells you what the attacker was after.

3. Check for added credentials on service principals and app registrations

Here's the persistence trick that outlives everything else. An attacker adds a new client secret or certificate to an existing app registration or service principal. From then on they can authenticate as that application whenever they like, with no need to touch the original compromised connection. Reset every password in the tenant and this still works.

Inspect the credentials on the affected app and any related ones:

Get-MgServicePrincipal -ServicePrincipalId <id> | Select-Object -ExpandProperty KeyCredentials
Get-MgServicePrincipal -ServicePrincipalId <id> | Select-Object -ExpandProperty PasswordCredentials

Look at the StartDateTime on each credential. Any secret or certificate created during or just after the incident window, that you didn't create yourself, is suspect. Remove it. Then widen the net: run the same check across other privileged applications in the tenant, because an attacker who gets in through one app often sprays credentials across several to guarantee a way back.

4. Examine directory role assignments

With enough access, an attacker will try to escalate. The quiet way is to add a role assignment rather than a new account — it draws less attention and survives user clean-ups. Check who holds privileged roles now, and when they got them.

In Entra, go to Roles and administrators and review the membership of Global Administrator, Privileged Role Administrator, Application Administrator, Cloud Application Administrator and Security Administrator. Cross-reference against your known admin list. The Application Administrator and Cloud Application Administrator roles deserve extra suspicion here, because they let the holder add credentials to apps — exactly the step in point three.

If you use Privileged Identity Management, check both active and eligible assignments. An eligible assignment is a time bomb: it looks dormant until someone activates it.

5. Hunt for new or modified app registrations

Beyond adding credentials to existing apps, attackers sometimes register their own. A fresh app registration with broad permissions, created during the incident, is a clear backdoor. Sort your app registrations by creation date and investigate anything new and unfamiliar. Check the reply URLs too — a legitimate-looking app pointed at an attacker-controlled domain is a classic token-theft setup.

6. Review mailbox and inbox rules for affected users

If the attacker reached user mailboxes through delegated permissions, they may have set forwarding or inbox rules to siphon mail quietly. Run a check across the tenant for forwarding rules, external forwarding settings and suspicious inbox rules (ones that move or delete messages containing words like "invoice", "password" or "payment"). These rules survive a password reset and keep leaking data long after you think you're clean.

7. Correlate with the unified audit log

Finally, pull it together. The unified audit log in Microsoft Purview is your single timeline. Search it for the incident window and filter on activities like Add service principal credentials, Consent to application, Add member to role, and Update application. This is where you confirm what happened in sequence, who or what triggered it, and whether the actions you found in steps one to six are connected. It's also what you'll hand to your insurer or an incident responder if things escalate.

Don't stop at step seven

If you find nothing, document that you looked — the dates you checked, the queries you ran, the window you covered. That record matters if questions come later. If you find something, treat it as a live incident: isolate, revoke, rotate, and get experienced eyes on it before you assume you've caught everything.

The uncomfortable truth is that vendor remediation and tenant remediation are two separate jobs. One is done for you. The other is yours. If you'd rather not run these checks alone — or you want a second pair of eyes on what you find — that's exactly the kind of work we do at Cloudworks. Give us a call before you decide the matter's closed.