This Week in Cybersecurity: ConnectWise Containment Still Needs Customer Verification
October 15–22, 2026 | Trust Player Zero
On October 17, ConnectWise disabled seven application identities following unauthorized access to credentials associated with Cloud Backup. Its incident advisory said disabling the connections prevented new authentication through them, but did not undo changes already made inside customer tenants.
Huntress’s October 19 update showed why that mattered. In two tenants it investigated, an application granted itself Global Administrator privileges and planted new secrets on other applications. The original application could be shut off and those additional credentials would still remain.
Other reports this week described compromised identities overriding release protections and changing cloud billing access. The common thread is that a trusted identity can change other access or even the controls that govern it. Containment has to follow those changes beyond the credential used to get in.
ConnectWise: the customer’s work continues
The attacker didn’t need an employee to sign in. Todyl’s investigation found authentication through the Cloud Backup application itself, using permissions customers had already granted for a legitimate backup service.
The customer still had to inspect its own environment. ConnectWise told partners to verify each local enterprise-application setting and review credentials, permissions, roles, consent grants, and recent policy changes. Its guidance treats successful authentication and data access as separate findings; a successful sign-in alone doesn’t establish that data was copied.
Access needs an owner for as long as it exists. That includes someone on the customer’s side who knows what the vendor has secured and what remains to be checked locally.
LiteLLM: the approving identity was compromised
On October 21, LiteLLM’s release pipeline distributed malicious version 1.107.0 through public package and container registries. Its incident report describes credentials associated with three developer accounts being used: one overrode release protections, another satisfied the production approval gate, and a third deleted workflow records.
The system recorded an approval, but the credential used to provide it was compromised.
An extra approval step would still depend on the security of the account providing it. When reviewing a release process, examine the privileges that can override its protections. Evidence stored outside the reach of those same credentials can also help an investigator reconstruct what happened.
Cloud billing: administrative access became spending authority
Attackers added their own Gmail accounts to victims’ billing accounts and granted billing-administrator privileges. They then linked attacker-controlled projects to those accounts, making the victims pay for unauthorized AI workloads. Wiz reported charges reaching tens to hundreds of thousands of dollars within 24 to 48 hours. It did not disclose exact intrusion dates.
The compromised identity removed a restriction on access before granting more access. A review limited to newly added users would miss the policy change that allowed them in.
Put the business decision beside the technical permissions
Imagine a vendor emailing at 5 p.m. on a Friday to say its application credentials were compromised. At a lender or fintech with a small IT team, the administrator receiving that notice may also be responsible for keeping Monday’s work running.
Start with one integration that can reach customer records or change a production system. Microsoft’s compromised-application playbook recommends setting an owner for each enterprise application. Record that person next to the administrator who manages the integration.
Agree on who can suspend the integration under emergency authority and what would stop working. Decide who will review the environment afterward and who can approve reconnection. Keep missing evidence or unresolved access visible so the next person can pick up the work. Use the vendor’s current response guidance; documentation shouldn’t slow urgent containment.
What TPZ is testing
TPZ’s hypothesis starts with information that often sits in different places. The business reason for an integration may be in a ticket. Its permissions live in an administrative console. We want to test whether putting those together at the point of action helps a reviewer catch a mismatch before approving a change.
Our Microsoft Entra integration is read-only today. In the Design Partner Beta, we intend to test disabling a user with explicit customer authorization, then reading Entra again to verify the result. The target also includes retaining the evidence and verifying a customer-authorized re-enable. It doesn’t cover the application-credential cleanup, release security, or Google Cloud billing response described here.
Whatever tools a team uses, closing the ticket should require evidence of what the team actually confirmed. A closed ticket with an attacker’s secret still in place leaves the attacker a way back in.
Explore the TPZ Design Partner Beta
Microsoft-first organizations with lean IT and security teams can review the program and reach out to discuss an identity or access workflow worth testing.
Editorial note: The ownership recommendations and Friday scenario are TPZ’s analysis and illustration, not reported facts about the affected organizations. Wiz’s campaign details are attributed to its incident-response research.
