ConnectWise disabled seven OAuth apps. Persistence is still in the tenant.

Huntress now counts almost 1,000 Entra tenants with sign-ins from 144.172.64.128 and more than 300 successes. ConnectWise’s 18 October update says it killed seven application identities at 07:00 UTC on 17 October and took SaaS Security and Cloud Management offline. Disabling those apps does not remove client secrets already planted.

RWP Ventures · 2026-10-18 · event 2026-10-15 · 17 min read · priority 9.4

Do not collapse five facts.

1. A vendor kill-switch is not a tenant clean. ConnectWise’s own sentence: disabling those connections prevents new authentication; it does not reverse changes previously made inside a tenant. Previously issued access tokens may remain usable until they expire. Unauthorized credentials, permissions, or other access established through separate identities still have to be found and removed in your directory.
2. Huntress’s 300 is still a telemetry floor, not a census. It is a different metric from yesterday’s 162. The 162 was confirmed unauthorized Cloud Backup sign-ins in Huntress’s view as of 16 October 19:00 UTC. The ~1,000 / 300+ count is Entra tenants Huntress later identified with any sign-in activity from that IP, of which more than 300 succeeded. Where the ConnectWise service principal was not present, Huntress says the actor did not get in. Microsoft has not published a matching count.
3. The second wave failed. Treat that as targeting, not as a breach. Huntress says a narrower set of 16 Huntress-protected tenants in the policy, national security, trade, and critical mineral sectors was hit on 15 October from the same IP. Most of those tenants do not use ConnectWise products. The attempts failed because the application was not there. Failed targeting is not a victim count and is not attribution.
4. The persistence Huntress already documented did not come from the VPS IP. In the one partner tenant where ConnectWise Cloud Management - MS Teams (24205314-2b89-4e07-a2a4-579e898a5640) self-assigned Global Administrator and added 2028-expiring client secrets, Huntress now says the access that planted a secret on Huntress’s own application came from private Azure IPv6 space, not 144.172.64[.]128. That secret was used seven times in quick succession. Huntress removed it on 16 October. Microsoft does not log every Graph read, so Huntress cannot rule out data access through that app.
5. This is still not a CVE, not ScreenConnect, and not OT process impact. ConnectWise says it is still analyzing how the identities were exposed and whether a product vulnerability contributed. An industrial or government tenant whose MSP installed SkyKick is an IT compromise of Microsoft 365 at that organization. Sector labels on failed Graph token requests do not become a process event.

The operator sentence: verify all seven Application IDs are disabled in every tenant you manage, including dormant SkyKick connections, then hunt client secrets, certificates, federation trusts, and directory roles added since 13 October — especially on MSP and security-platform apps. Searching only 144.172.64[.]128 will miss the Azure IPv6 path.

Yesterday’s assessment is [the 17 October Daily Top](/posts/2026-10-17-connectwise-skykick-m365-oauth/). This article is the increment.

What happened

The abuse window is still 15 October. What changed overnight is the scope of the vendor response and the size of Huntress’s floor.

ConnectWise’s 18 October 01:00 UTC update lists the seven identities it says it disabled at 07:00 UTC on 17 October:

Match on Application ID. Older tenants may still show SkyKick Cloud Manager display names. ConnectWise’s table is a publisher action. It is not a local Enabled for users to sign-in = No in every customer tenant. Partners still have to open Entra and confirm.

Huntress’s 10:30 ET on 17 October update had high confidence the actor also abused the Exchange Online, Teams, and SharePoint Cloud Management apps, and said at that hour those apps did not appear disabled by ConnectWise. Huntress’s 17:15 ET update records ConnectWise communicating that the relevant apps are disabled. Treat the 10:30 note as a timestamped observation, not as the current vendor state. The Hacker News 18 October piece still quotes Huntress from before that 17:15 confirmation on the Cloud Management apps; use Huntress’s later update and ConnectWise’s 01:00 UTC table for current status.

Huntress’s expanded timeline on the same 15 October day:

ConnectWise, separately, says it identified the issue on 14 October through its own monitoring, engaged a third-party forensics firm, and that since implementing mitigations it has not observed successful threat activity in the environments it monitors. That last clause is a statement about ConnectWise-held environments. ConnectWise also says Cloud Backup does not give it downstream visibility into whether a particular partner or customer tenant had unauthorized activity. The tenant review is therefore still on the MSP and the customer.

Cloud Backup remains suspended. Scheduled backups are not running. Restores are unavailable. ConnectWise repeats it has no evidence the encrypted archives were accessed. SaaS Security monitoring and alerting and Cloud Management user and license management are unavailable until ConnectWise finishes its review. Those pauses are vendor precautions. They do not, by themselves, establish that those products were compromised.

Why it matters

Yesterday the defender action was: disable 506e08f9, then hunt secrets. Overnight the vendor widened the disable list to the entire Cloud Management family, and Huntress widened the floor. The action did not get smaller. It got more specific.

Three reasons this is still the daily.

First, the blast radius was always the consent model, and the 300+ figure is the first public floor that looks like a crawl, not a handful of Huntress customers. Almost 1,000 Entra tenants with sign-in activity from one VPS, more than 300 successes, and failures explained by a missing service principal, is a script walking a list. Huntress already described the 06:13–08:34 UTC Cloud Backup pass as tenants in sorted GUID order, seconds apart. The afternoon sector pass is the same IP, slower, against tenants that mostly did not have the app. That is a targeting choice. It is not a confirmed espionage attribution and it is not confirmed data theft in those 16.

Second, persistence that outlives the seven-app kill-switch is now documented on a security vendor’s own application, not only on an unnamed MSP tool. Huntress: a credential added to Huntress Security Platform in one tenant, used seven times, removed 16 October; Graph reads may not log; Huntress cannot rule out access to data that application can read. Huntress has enabled App Instance Property Lock across its applications. That is Huntress hardening its own estate. It does not clean yours.

Third, the hunt that only greps 144.172.64[.]128 is now known-incomplete. Huntress: the Global Admin / secret-add window had no source IP in the audit log, and the follow-on use of the planted Huntress credential came from Azure private IPv6. Huntress publishes a ULA (fde4:8dba:2600:37ce:6d26:200:a76:*) and immediately warns that legitimate ConnectWise traffic and unrelated customer traffic also appear from the same range, so the address alone does not identify the operator. Hunt from Application ID, role add, credential add, and user-agent, not from a single IPv4.

Who / what is affected

Technical context

RWP is not reproducing the client-credentials flow. The overnight increment is which objects to hunt and which logs will lie.

Huntress maps the observed activity to T1078.004 (valid cloud accounts — the publisher credential), T1098.003 (additional cloud roles — self-assigned directory roles), and T1098.001 (additional cloud credentials — secrets planted on other apps). Microsoft Threat Intelligence’s 17 October post remains the independent classification: an active supply-chain attack on a trusted multi-tenant OAuth app, including Directory.ReadWrite.All and attempts to add additional credentials.

ConnectWise’s recommended review window is 13 October through now, with a scoping extension back to 1 October where logs still exist. Entra Free keeps sign-ins seven days. 18 October is already at the edge of that window for the 13 October spray. Export first.

Threat / exploitation status

Confidence on the seven-app disable, the 15 October service-principal authentications, the ~1,000 / 300+ Huntress floor, and the failed 16-tenant wave: high as statements of those sources. Confidence that 300 is the global victim count: low. Confidence that the VPS crawl and the Azure-IPv6 persistence window are the same operator: moderate on campaign association, low on a single-operator proof. Confidence on actor identity: none. Confidence on confirmed data theft versus logging gap: low as confirmed theft, moderate as potential exposure given the grant.

What defenders should do

1. Verify all seven Application IDs in every tenant you manage — MSP tenant and every customer, including dormant SkyKick connections. Entra → Enterprise applications → All applications → search by ID. If an affected app is still enabled, set Enabled for users to sign-in = No. Do not delete as the first response. Record Object ID, who changed it, and UTC time. ConnectWise’s publisher disable is not this step.
2. Hunt credentials on every other enterprise application and app registration, especially MSP, backup, RMM, and security tools, for secrets, certificates, or federated credentials added since 13 October that you did not create. Include Huntress Security Platform if you use Huntress. Remove unexpected entries. Huntress: disabling ConnectWise apps does not remove those. ConnectWise: it does not have access to make those changes inside your tenant.
3. Review directory roles held by applications. Prioritize Global Administrator, Privileged Role Administrator, Privileged Authentication Administrator, Application Administrator, Cloud Application Administrator, Exchange Administrator, SharePoint Administrator. Remove roles you did not grant after the app is disabled. Huntress saw Cloud Management apps assign themselves directory roles, mostly Exchange Administrator, in ~50 tenants around 01:58 UTC on 15 October with User-Agent kiota-dotnet — Huntress has not confirmed that window as vendor automation versus the actor.
4. Read the right logs, and do not stop at the VPS IP. Service-principal sign-ins for each of the seven IDs, 13 October through now. Filter 144.172.64[.]128, then inspect non-Azure addresses, then inspect Azure private IPv6 in the same window rather than clearing it as “vendor.” Directory audit for role adds and application updates by those apps and to other apps. Unified audit for forwarding, transport rules, delegated access. Export now; Free-tier retention is seven days.
5. Do not re-enable any of the seven until ConnectWise publishes reconnection instructions that include credential rotation. A status-page “contained” that does not say the publisher secret was rotated is not an all-clear. Tokens already issued may survive the disable until they expire.
6. Tell customers backups and, where they used them, SaaS Security alerting and Cloud Management license changes are paused. Mail, Teams, and user sign-in keep working. Decide whether a recovery-point gap matters before anyone re-enables. Use Partner Care for changes that used to go through Cloud Management.
7. Keep the other clocks. CVE-2026-21589 (Atlassian Data Center file access) is due today, 18 October, forensicTriage: Yes — that is a catalog clock on the [6 October Daily Top](/posts/2026-10-06-atlassian-cve-2026-21589-file-access/), not this story. CVE-2026-102764 (BeyondTrust Remote Support) and CVE-2025-61624 (Fortinet CLI path traversal) are due 19 October. CVE-2026-76519, CVE-2026-0322, and CVE-2026-105133 / 105134 were due 17 October. Catalog freeze is still 2026.10.16 / 1748. Do not steal the Entra owner for a Jira ticket.

RWP assessment

Score 9.4.

This is a material development on [yesterday’s SkyKick Daily Top](/posts/2026-10-17-connectwise-skykick-m365-oauth/), not a rewrite of it. Overnight ConnectWise moved from shutting off Cloud Backup to disabling seven identities and pausing two more product lines; Huntress moved from 162 confirmed Cloud Backup sign-ins to a ~1,000 / 300+ IP-activity floor plus a failed sector-targeted second wave; and the persistence Huntress already had in one tenant is now documented as having used a planted secret on Huntress’s own app, from Azure IPv6 rather than the VPS. Evidence quality is high on those three increments. Evidence quality is intentionally split on victim census, on confirmed data theft versus logging gap, on whether the persistence window and the VPS crawl are the same operator, and on actor identity.

It outranks Atlassian CVE-2026-21589 due today because that CVE was Daily Top 6 October, landed on KEV 15 October, and has no overnight technical increment — the due date is a federal clock, not a new story. It outranks BeyondTrust CVE-2026-102764 and Fortinet CVE-2025-61624 (both due 19 October) for the same reason: already on the site, catalog freeze unchanged at 2026.10.16 / 1748. It outranks Drupal CVE-2026-108097 (SA-CORE-2026-014, patched 14 October, BleepingComputer 17 October “exploits may emerge soon”) because there is no confirmed in-the-wild use in this retrieval. It outranks the MALFEX imgdecode npm loader (THN 17–18 October, 979 downloads) as a real supply-chain finding with a smaller, endpoint-scoped blast radius.

What we are not saying: that 300 tenants had mail stolen; that the 16 sector tenants were breached; that the actor is a named state; that ConnectWise backup archives are independently verified clean; that SaaS Security or Cloud Management were confirmed compromised; that ScreenConnect is in this incident; that this is a CVE; that this is OT process impact; that ransomware is Known.

What we are watching

• ConnectWise reconnection instructions that include publisher-credential rotation, not only “service restored.”
• Whether Huntress or Microsoft publishes a census above 300, and whether tenants with no active subscription were read.
• How many tenants besides Huntress’s one show T1098.001 on MSP or security-platform apps.
• Whether the 01:58 UTC kiota-dotnet role assignments were vendor automation or the actor.
• Any new sign-ins after 15 October from a different IP or from Azure IPv6 that can be tied to planted secrets.
• Attribution. None on the public record this morning. Sector targeting stays targeting.
• Parallel clocks: Atlassian 21589 due today; BeyondTrust 102764 and Fortinet 61624 due 19 October. Catalog freeze 2026.10.16 / 1748.

Sources

• Huntress — ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks
• ConnectWise — Trust Center advisories, updated 18 October 2026 01:00 UTC
• ConnectWise — Cloud Backup status incident
• The Hacker News — ConnectWise Suspends Cloud Backup, 18 October 2026
• Todyl — Unauthorized Access Through the ConnectWise Cloud Backup Microsoft 365 App
• Microsoft Threat Intelligence — OAuth app supply-chain tracking, 17 October 2026
• Huntress Support — 2026 October SkyKick
• SpecterOps — ConnectWise SkyKick Breach: How to Check Your Microsoft 365 Tenant, 17 October 2026
• CISA KEV JSON catalog 2026.10.16
• CISA — Adds One Known Exploited Vulnerability, 15 October 2026
• CISA — Adds Two Known Exploited Vulnerabilities, 16 October 2026
• Atlassian — CVE-2026-21589 advisory
• [RWP — ConnectWise SkyKick, 17 October 2026](/posts/2026-10-17-connectwise-skykick-m365-oauth/)
• [RWP — BeyondTrust CVE-2026-102764, 16 October 2026](/posts/2026-10-16-beyondtrust-cve-2026-102764-armory-castle/)
• [RWP — Atlassian CVE-2026-21589, 6 October 2026](/posts/2026-10-06-atlassian-cve-2026-21589-file-access/)
• [RWP — ScreenConnect CVE-2026-84869, 14 September 2026](/posts/2026-09-14-screenconnect-cve-2026-84869-kev/)