Cybersecurity

Cloud Backup Attack: Why Microsoft 365 App Access Matters

An October 26 investigation update examines automation in the ConnectWise cloud-backup incident. For businesses, the lasting lesson is to monitor application identities—not only user logins.

A fresh investigation update exposes an old trust problem

On October 26, 2026, Huntress published new analysis of the ConnectWise cloud-backup attack. The update examines how scripted tooling, possible AI assistance, and human intervention appeared in the observed activity. It follows Huntress’s October 16 disclosure that a vendor-held application credential was abused to obtain unauthorized access to customer Microsoft 365 environments.

The original incident occurred before the past week; the October 26 investigation update is the new development covered here. That distinction matters. This is not a newly discovered breach dated October 26, and it is not evidence that every business using Microsoft 365—or every managed IT provider—was affected.

Key takeaways: protect application identities as well as people, check for persistence beyond the originally abused integration, and confirm that business recovery remains possible if a backup service is interrupted. The enduring issue is what a trusted application can do inside your environment.

What researchers know—and what remains uncertain

In its initial investigation, Huntress identified abuse of a ConnectWise Cloud Backup credential, formerly associated with SkyKick, and described downstream Microsoft 365 access. Researchers also reported activity involving other ConnectWise cloud-management applications and, in one partner tenant, an application adding credentials to other applications. These are observed findings in identified environments, not a claim that the same actions occurred everywhere.

The October 26 update says Microsoft attributed the activity to Storm-0940 using ARTEX, an AI agent framework. Huntress says its telemetry is consistent with that account but that it cannot independently verify it. Its confidence in AI involvement differs depending on whether Microsoft’s attribution is considered. The responsible reading is “investigators describe possible AI-assisted operations,” not “AI conclusively caused every intrusion.”

The business lesson does not depend on the attacker’s keyboard. Whether automation, a person, or both used the credential, the defensive priority is detecting unauthorized actions and limiting their reach. Avoid assuming that backup data was stolen simply because access to a vendor application was abused; that requires separate evidence.

Why user MFA is not the whole answer

Multi-factor authentication remains important for users. However, applications can authenticate using their own identities and credentials. Sophos’s technical analysis describes app-only Microsoft Graph token requests that did not require a user password or user MFA. In that model, a consenting customer tenant trusts the vendor application’s identity and permissions.

This is why “everyone has MFA” is not a complete cloud-security assessment. Your tenant may contain backup integrations, reporting tools, migration utilities, and automation that can read or modify data independently of an employee signing in. Each needs an owner, a business purpose, a permission review, and a lifecycle plan.

For businesses across DFW and Greater Houston, outsourced software does not remove the need for oversight. Ask which third-party applications have access to email, files, and administrative functions, and which provider monitors their service-principal sign-ins. Microsoft 365 management should include that layer, not only account setup and license purchasing.

Review persistence, not just the first compromised connection

For affected environments, Huntress’s published guidance recommends disabling identified abused applications and reviewing credentials on all Microsoft 365 applications. Its warning is important: disabling an original integration does not remove credentials an attacker may already have added elsewhere. Follow the latest vendor and incident-response instructions for your environment, and coordinate changes with continuity requirements.

A useful review includes enterprise applications, service principals, application credentials, role assignments, consent changes, and audit and sign-in logs. Investigate unexpected additions and validate legitimate ones with their owners. Preserve evidence before cleanup. Do not blindly remove every integration; a poorly planned response can disable business workflows while leaving the actual persistence mechanism untouched.

If compromise is suspected, engage qualified incident responders to determine scope, containment, credential rotation, and recovery. An access review is not a substitute for that investigation. Equally, a familiar vendor name is not a reason to skip it.

Can the business recover if the backup service is unavailable?

Cloud backup is valuable, but it is also a service with identities, dependencies, and possible interruptions. October 20 reporting by CyberScoop described service suspensions during the response. That makes continuity a practical question, even where a customer has no evidence of data theft.

Ask when the last successful backup occurred, whether restore operations are available, what permissions are needed to recover, and whether the recovery procedure depends on the same identities under investigation. Test representative email and file restores. Document acceptable data loss and recovery time for the processes that keep staff working.

Separate backup success from high availability. A working backup does not automatically keep a service online; high availability does not automatically preserve a clean historical copy. Both need a defined purpose. Review backup and disaster recovery together with identity controls so the recovery path is not an afterthought.

Hold your provider accountable without a long-term lock-in

Spryder uses a Kaseya-based managed IT stack; discussing this ConnectWise incident does not imply that Spryder uses the affected product or that our clients were involved. It also does not mean a different vendor is immune. Every technology relationship deserves scrutiny, including ours.

The right questions are blunt: who owns each integration, how are unusual application actions detected, and when was recovery last tested? Tools help, but ownership and verified follow-through matter. No long-term contracts. We earn your business every day. Accountability should not depend on waiting for a renewal date.

Start a conversation with Spryder about Microsoft 365 access, a free vulnerability scan, and recovery planning for your business. We will scope the work transparently. A vulnerability scan alone cannot establish whether application credentials were abused; that requires the appropriate cloud-access and incident review.

Sources reflect reporting available by October 27, 2026. Follow current vendor advisories as the investigation develops.