Back to blog

ConnectWise incident: M365 recovery must include app identities

3 min read
ConnectWise incident: M365 recovery must include app identities

Sources checked: . FailSafe Research.

Resetting user passwords will not resolve every Microsoft 365 intrusion. An application identity can retain a separate route into the tenant, with permissions and credentials that have their own lifecycle.

What incident responders observed

Huntress’s investigation reports abuse of a ConnectWise Cloud Backup credential and unauthorized access to customer Microsoft 365 environments. Its updated findings include abuse of additional Cloud Management applications and the addition of credentials to other applications in a partner tenant. Huntress warns that disabling the initially abused application does not remove credentials already added elsewhere.

The firm advises disabling affected application identities rather than deleting them and reviewing credentials across tenant applications. Its follow-up analysis separates observed activity, scripting and operator involvement. Follow the current vendor and responder guidance for the specific tenant; a shared network indicator alone does not prove malicious activity.

Inventory the machine principals

For your own environment, list enterprise applications, service principals, consent grants, certificates, secrets and privileged role assignments. Include applications installed by suppliers and the people authorized to approve those integrations. Record which identities can add a credential to another identity.

That last relationship matters. A recovered integration can still leave behind a second access route if responders review only its original secret. Look for changes made during the investigation window and compare them with an approved baseline.

What to validate in a safe tenant

  • Can an integration request or assign permissions beyond the agreed service?
  • Can it add a credential to an unrelated application?
  • Do app-only sign-ins reach the monitoring team with enough context to investigate?
  • Does disabling the integration stop every action its documented credentials allowed?

Use a dedicated tenant or explicitly authorized scope. Preserve the identity chain and denied operations as well as the successful ones. Restore testing and backup retention also need named owners so containment does not accidentally erase recovery options.

How FailSafe can help

FailSafe SWARM can connect identity and application testing to the systems those identities can reach. An enterprise assessment should demonstrate the privilege transition, retain the evidence and retest it after remediation. This is more useful than a disconnected list of configuration warnings.

For another example of a supplier’s credential becoming downstream authority, see our TeamUpdraft analysis. The products and incidents differ; the common assessment question is what a trusted integration is actually allowed to do.

Explore the October incident collection for related cases and existing FailSafe coverage. Incident descriptions are attributed to the linked sources; assessment recommendations are FailSafe’s analysis. We have not conducted forensic investigations of these incidents.

Questions & answers

Questions about this topic

Direct answers to common questions about this page.

No. Review service principals, consent, application secrets, certificates and credentials added during the intrusion, following current responder guidance.

Not necessarily. Huntress reports that credentials added to other applications require separate review and containment.

Put this guidance to work

Discuss a scoped FailSafe SWARM assessment with reproduced findings, engineering handoff and remediation retesting. Containment and forensic investigation remain separate workstreams.

Test the boundary that matters