"This observation does not establish whether individual partner or customer Microsoft 365 tenants have been affected," ConnectWise said.
ConnectWise actions: suspension, resets, and elevated protections
On Monday ConnectWise disclosed a series of remediation steps taken in response to a security incident that led to unauthorized access to application identities associated with its Cloud Backup product. The company said it has disabled affected application connections and suspended Cloud Backup, and — as a precaution because of integration — suspended SaaS Security and Cloud Management.
Since it began rolling out mitigations on October 17 at 5:00 a.m. UTC, three days after the incident was first identified, ConnectWise reported it has: enlisted independent third-party specialists for incident response and remediation; enhanced administrative-access protections; reset accounts and replaced application credentials; and published technical guidance to help partners investigate and remediate potential unauthorized activity in their environments and those of their customers.
Containment status and guidance to partners
ConnectWise said it is validating the effectiveness of containment measures and emphasized that it has not seen any successful threat activity in the environments it monitors. The company further stated there is no evidence that any ConnectWise products and services — aside from Cloud Backup and the precautionary suspensions of SaaS Security and Cloud Management — are impacted.
ConnectWise warned that its observation does not establish the status of individual Microsoft 365 tenants and urged partners to review each potentially affected tenant. Its technical guidance advises partners to preserve relevant evidence, validate findings, and assess potential operational impacts before making changes. The company cautioned that completing those steps "does not guarantee that a tenant is unaffected or that all unauthorized access has been eliminated" and told partners not to reconnect affected applications until ConnectWise issues formal restoration instructions.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildHuntress findings: IPs, sign-ins, and post-compromise behavior
The cybersecurity firm Huntress shared specific IP addresses it observed in connection with the activity and distinguished between application sign-in activity and unrelated password-spray attempts. Huntress identified 144.172.64[.]128 as the address producing application sign-ins with a vendor credential and labelled it the primary vector.
- 144.172.64[.]128 — Application sign-ins with a vendor credential (primary vector)
- 144.172.64[.]99 — Failed user password spray, concentrated (October 10 to 14, 2026)
- 144.172.64[.]60 — A few failed user logins (October 18, 2026)
- 144.172.94[.]243 — Broad failed login spray, ongoing against many organizations
In a review of application sign-ins across more than 10,000 tenants where Huntress could see logs, the company said 144.172.64[.]128 and Microsoft-internal ranges were the only addresses that produced application sign-in activity. Huntress added that it did not see application sign-in activity from the other addresses in the same provider range (AS14956, RouterHosting), although it did observe password-spray and failed login attempts from some of them.
Huntress also reported post-compromise actions on a second tenant mirroring the earlier pattern: the application granted itself Global Administrator and then added a new secret on a small number of other applications in the tenant to maintain persistence.
Observed attacker behavior: reads, persistence, and randomness
According to Huntress, the access may have been used for Microsoft Graph directory reads, and the researchers reported no signs that attackers weaponized the access for mailbox or file manipulation, or to make user or policy changes. Across the two compromised tenants Huntress reviewed, the "choice of which applications to backdoor appeared to be random."
Huntress noted the only consistent structural criterion was that credentials were planted in applications that are registered inside the affected tenant, without regard to what those applications can actually do. That pattern — application credentials used to grant elevated roles and to seed secrets on other registered apps — formed the core of the observed modus operandi.
What this means for technologists, partners, and customers
- Technologists and security teams — Examine tenant application registrations and logs for evidence of unexpected application sign-ins, preserve forensic artifacts before making changes, and follow ConnectWise's published technical guidance; do not reconnect affected applications until formal restoration instructions are issued.
- Affected partners and managed service providers — Prioritize reviewing each potentially affected Microsoft 365 tenant, validate containment measures recommended by ConnectWise, and coordinate with any third-party incident responders engaged by ConnectWise.
- End users and customer organizations — Be aware that Cloud Backup, SaaS Security, and Cloud Management were suspended as precautionary measures; there is no evidence presented that mailboxes or files were altered in the reviewed tenants, but a tenant-level review remains essential.
ConnectWise has reset credentials and replaced application secrets and is continuing validation of containment; Huntress has pointed to a specific IP, 144.172.64[.]128, as the primary address tied to application sign-ins. The immediate next milestone named in ConnectWise's public statements is the issuance of formal restoration instructions — a step partners and customers will be watching closely as they complete tenant-level reviews and preserve evidence for any necessary follow-up.
