Identity, IAM Technologies, Cloud Security

Attackers compromise Microsoft 365 credential via ConnectWise Cloud Backup

(Adobe Stock)

A Microsoft 365 credential belonging to ConnectWise Cloud Backup was compromised, and researchers at Huntress confirmed it's being used to gain unauthorized access to multiple Microsoft 365 environments.

Following the news late last week, ConnectWise shut down access to its Cloud Backup Service over the weekend because the following MS 365 environments were affected:

  • Exchange Online
  • Microsoft Teams
  • SharePoint Online
  • Cloud Backup
  • MS Graph
  • Partner Center

Jon Semon, principal security operations analyst at Huntress, explained that the incident involved the compromise of a digital key ConnectWise's backup app uses to sign in to customers' Microsoft 365 accounts.

While ConnectWise said the key has since been revoked for teams that used one of the affected ConnectWise apps — Cloud Backup, formerly SkyKick, or the related Cloud Management apps — admins should ask the company’s IT provider to do four things, according to Semon:

First, disable the apps in the organization’s Microsoft 365 settings, without deleting them. Second, check whether any new keys or passwords were added to the company’s other business apps since Oct. 13, and remove any not recognized. Third, look for unexpected new administrator accounts or app permissions. And finally, check for unexpected email forwarding or inbox rules.

“Some activity isn't logged, so a clean check doesn't mean nothing happened,” said Semon. “Keep the apps disabled until ConnectWise confirms they're safe, and keep watching for unusual changes.”

The attacks happened in two waves

Roman Y. Sannikov, global research coordinator at iCounter, said there are two waves here and admins should read them separately. In the first, someone used the ConnectWise Cloud Backup app’s own credential to sign-in as the app itself: no user logged in, so MFA never applied.

Sannikov said starting early on Oct. 15, ConnectWise Cloud Management apps began making themselves Exchange Administrator in about 50 of the tenants Huntress monitors. In one tenant, the Teams app made itself Global Administrator and added secrets to other applications, including Huntress’s own, with expiry dates in 2028.

Later that same day, Sannikov said a second wave hit 16 tenants in policy, national security, trade, and critical minerals. It’s important to note that most of those organizations don’t use ConnectWise at all, and Huntress hasn’t tied the two phases to the same operator.

“Until someone shows that link, I wouldn’t treat this as one campaign,” said Sannikov.

What the two waves share is the target, said Sannikov. Both waves went after Entra and Microsoft 365 through application identities. App-only Graph reads leave no audit trail, and that’s why nobody can say yet what data was taken.

“The first wave was clearly automated and run at scale,” said Sannikov. “It used curl and Python user agents, came from a hosting-provider IP, and worked through tenants in sorted GUID order. Nearly 1,000 Microsoft tenants saw sign-ins from that one address, and more than 300 of them succeeded.”

Denis Calderone, chief technology officer at Suzu Labs, added that while it’s hard to say for certain if this is the same operator, the same infrastructure was used on the same day with the same stolen ConnectWise credential.

Calderone said the first wave was a scripted crawl through tenants that already had the SkyKick backup app approved. The second wave used that same key against a short list of high-value tenants in national security, trade, and critical minerals, most of which never used ConnectWise at all.

“The first wave looks like they were working a list of tenants that already had the app,” said Calderone. “Second wave was aimed at organizations they actually wanted, and as Huntress showed, most of those attempts failed because the app wasn't even there. The overlap is the stolen key and a rented box, but that doesn't tell us it’s one single threat actor.”

Shane Barney, chief information security officer at Keeper Security, added that defenders should start with an inventory of every application and service principal holding broad permissions. For each one, teams need to identify who can add credentials and review sign-in logs for origins that should never appear. Most of these failures trace back to unclear ownership and excessive scope, said Barney, so every non-human identity needs a named owner and a defined scope.

“Application credentials need the same lifecycle controls as privileged accounts,” said Barney. “Store them in a managed vault rather than in scripts or shared files. Administrators must rotate them on a schedule, log every time they are used, and revoke any credential the moment the application no longer needs it. An application should never hold a directory role longer than its job requires.”

Steve Zurier
Steve Zurier has been a freelance writer and editor for SC Media since 2012. Now, Zurier writes daily news stories and edits SC Media’s Perspectives columns. A long-time member of the tech press, Zurier lives in Columbia, MD. During off-hours, Steve moonlights as an upright bassist for jazz and klezmer bands around the Baltimore/DC area.

You can skip this ad in 5 seconds