The apps you trust can walk past your MFA

Most of us spend a lot of effort on MFA for people. Last week was a reminder that the apps we connect to Microsoft 365 can walk straight past it.

What happened

On 17 October, BleepingComputer reported that attackers had used the credentials of ConnectWise Cloud Backup, the product that used to be called SkyKick Cloud Backup, to sign in to customers' Microsoft 365 tenants. The backup tool works through a service principal in Entra ID. That's an app identity that has been given permissions by an admin, often broad ones, so it can read and back up mailboxes and files.

The attackers didn't need anyone's password. They used the application's own secret and signed in with scripts. Because no person was logging in, MFA and most user-focused Conditional Access rules simply didn't apply.

What they did next depends on who you ask. Todyl looked at nine tenants and only saw sign-ins. Huntress said it found at least 162 compromised tenants among its own customers, and saw ConnectWise Cloud Management apps giving themselves directory roles, mostly Exchange Administrator. In one tenant the attacker granted Global Administrator. Microsoft called it an active supply-chain attack and said the attacker likely abused permissions the app already had, including Directory.ReadWrite.All.

ConnectWise disabled seven application identities, took some services offline, and said it had no signs so far that backup data was taken. It also said tokens already issued may keep working until they expire. That last point matters more than it sounds.

Why this one stings

We grant these permissions because the product needs them. A backup tool has to read every mailbox. A management tool has to change settings. So the app ends up with more power than most of your admins, and nobody is sitting at a keyboard to approve each sign-in.

When a vendor's secret leaks, every tenant that trusted that app is exposed at once. You can do everything right inside your own tenant and still be caught out.

What I'd check this week

Whether or not you use this particular product, these checks are worth an hour of your time.

List your third-party apps. In the Entra admin center, go to Entra ID > Enterprise apps > All applications. Look for anything you don't recognise or no longer use.
Look at what each one can do. Open an app and select Permissions. The Admin consent tab shows what it has across the whole organisation. Anything with ReadWrite.All in the name deserves a second look.
Check app sign-ins, not just user sign-ins. Under Monitoring & health > Sign-in logs, service principal sign-ins are a separate log type. Look for sign-ins from IP addresses that don't belong to the vendor.
Check for new roles and new secrets. In the audit logs, look for role assignments to apps and credentials added to apps that you didn't make. Huntress advised reviewing secrets and certificates on all apps for anything added since 13 October.
Know how to switch an app off. In an app's Properties, setting Enabled for users to sign-in? to No stops new tokens being issued in your tenant. Practise it on a test app so you're not learning it during an incident.
Remove what you don't use. Old trials and tools you replaced years ago often still have consent. Each one is a door you're not watching.

Disabling or removing an app's permissions can break backups or other services that depend on it. Tell the people who rely on it first, and note what you changed so you can put it back.

The bigger lesson

Identity security isn't only about people any more. Apps and, increasingly, AI agents sign in on their own, with permissions that would make you nervous if a person had them. Treat them like privileged accounts: give them the least access that works, review them regularly, and watch their sign-ins.

And when a vendor says "disable the app", remember that tokens already issued can outlive that change. Keep watching the logs for a while afterwards.

Sources

← All posts