DEV Community

andreagomez
andreagomez

Posted on

78,207 ConnectWise Automate fingerprints cannot describe a Cloud Backup compromise

#zoomeye #connectwise #rmm #storm0940

78,207 ConnectWise Automate fingerprints cannot describe a Cloud Backup compromise

A ZoomEye search for app="ConnectWise Automate" returned 78,207 matching assets on 22 October 2026 at 05:36 UTC. The number is relevant to the ConnectWise story because it measures a real exposure surface. It is also unrelated to the incident that put ConnectWise in the news, and that difference is the point of this article.

What the incident involved

Microsoft attributed a supply-chain attack against ConnectWise customers' Microsoft 365 environments to a group it tracks as Storm-0940. The intrusion path ran through ConnectWise's Cloud Backup service, a hosted product. ConnectWise temporarily shut down services on the Saturday following the attacks and said it began restoring services in phases the following Wednesday, advising customers to keep connections disabled.
Microsoft reported that the group used an agentic AI penetration testing framework called ARTEX, and that in some victim environments the AI agents progressed beyond authentication into Microsoft Graph and directory operations, including reconnaissance, application credential modifications for persistence, and changes involving identities, groups and privileged roles.
None of that traffic reached an internet-facing ConnectWise appliance. The compromised component was a multi-tenant service, and the attacker's relationship with it was a customer relationship rather than a network one.

What the 78,207 measures

The fingerprint counts ConnectWise Automate instances visible to a public scanner. Automate is remote monitoring and management software, and an exposed instance is a management console that holds credentials for the endpoints it manages.
That is a serious exposure surface on its own terms and a different surface from the one in the incident. A count of internet-reachable RMM consoles says nothing about the security of a hosted backup service, and a compromise of that service says nothing about whether any individual Automate console is exposed.
| What you can measure externally | What the incident required |
| --- | --- |
| Presence of a fingerprint | Trust in a hosted service |
| Reachability of a console | OAuth consent granted to a third party |
| Product family | Application credentials in a tenant directory |
| Asset count | Directory role and group changes |
The columns do not intersect. Treating the left column as evidence about the right column is the error this comparison is meant to prevent.

Why the RMM surface still belongs in the same conversation

The two issues connect through privilege. Both a compromised RMM console and a compromised backup integration end at the same place: an identity with broad reach that authenticates without a human present.
The incident description makes that explicit. Microsoft noted that a compromised third-party application holding high privileges could provide access beyond its originally intended purpose, and that some environments showed application credential modifications used to establish persistence. An RMM agent is a comparable privilege holder in the endpoint direction.
The 78,207 figure therefore supports a question worth asking after this incident, although it cannot answer whether ConnectWise's own service was compromised. Which RMM consoles in your estate are reachable from the internet, and what credentials would an attacker holding one of them inherit.

Checks that follow from the reported activity

  1. Enumerate every application with directory-level permission and ask which genuinely need write access to identities, groups or roles.
  2. Review recent credential additions on existing applications, since the reported technique modifies application credentials for persistence and a new secret on an old application is easy to miss.
  3. Compare group and role membership against a known baseline so that privileged role changes surface as differences.
  4. Review internet-reachable RMM consoles separately, with their own authentication model and their own logging, because they hold a different class of credential. The third check is the most likely to find something, because the reported activity includes changes involving identities, groups and privileged roles rather than only sign-ins.

Recovery timing, described honestly

ConnectWise advised customers to keep connections disabled during the phased restoration, and stated that the process would take several days. Microsoft's executive vice president described the campaign as one of many in a wave of AI-driven cyberattacks since early October.
For an affected customer, re-enabling an integration is a decision with an order of operations. Rotate credentials reachable from the tenant while connections stay disabled, review directory changes made during the window, then re-enable one integration at a time with the permission scope re-checked.

What remains unmeasured

Reporting does not state how many tenants were compromised. Microsoft said that successful authentication does not necessarily indicate that the group accessed or stole data, which leaves authentication events and data access as separate questions.
The 78,207 fingerprint count has its own limits. It identifies product family rather than version, does not indicate which consoles are multi-tenant service-provider deployments, and cannot report whether an operator has enabled multi-factor authentication on the console. All three matter more than the total.

References

Top comments (0)