In this month’s Threat Briefing, Nathanael Iversen looks at three incidents with a common thread. In each one, the attacker was already inside the trust boundary, through a stolen password, a trusted vendor, or a trusted software update. Nothing was in place to contain what came next.
On October 20, CISA, the FBI, and the U.S. Secret Service, joined by partners in Germany and the UK, issued a joint advisory on SafePay, one of the most active ransomware groups of 2026. The agencies say SafePay has hit at least 600 victims across multiple critical infrastructure sectors since August 2024. The group doesn’t rely on novel exploits. It gets in with compromised credentials, VPN access, phishing, and known vulnerabilities in unpatched firewalls and edge devices. Once inside, it runs a familiar playbook:
For operators running plants, pipelines, and water systems, that lateral path is the real danger, because it runs from the office network to the systems that control physical processes. Placing OT assets inside isolated Zero Trust virtual chambers breaks that path. A stolen password might still get an attacker onto the network, but it won’t get them into the chamber, so critical processes stay protected and online. [See how Zentera secures OT environments →]
On October 21, Microsoft attributed the compromise of ConnectWise’s Cloud Backup service, formerly SkyKick, to Storm-0940, a China state-aligned group. The group took over the identities of multiple ConnectWise cloud applications and used them to attempt access to more than 2,250 Microsoft 365 tenants. Targets spanned hundreds of organizations in aerospace and defense, energy, financial services, government, and semiconductors. The operation ran on ARTEX, an agentic AI penetration testing framework that automated reconnaissance, password spraying, and abuse of OAuth applications at machine speed. Most attempts failed. In several cases, though, Microsoft says the group went from first targeting to privileged cloud access in under three hours.
This is the trusted vendor problem at scale. Compromise one vendor’s integration and you inherit the approved access it already holds in every customer environment. ConnectWise shut down the affected services. Microsoft warns, however, that credential changes the attackers made inside customer tenants can remain active as a backdoor even after the original application is fixed. Tight internal segmentation contains what the perimeter misses. Applications running inside virtual chambers have ingress and egress policies governing every connection, so malicious activity stays contained and every unexpected communication attempt raises an alert. For providers hosting customer data or application instances, putting each one in its own chamber keeps an incident like this from becoming the next headline. [See how Virtual Chambers contain a breach →]
LiteLLM is an open-source gateway many companies use to reach OpenAI, Anthropic, and other model providers, which means it holds the API keys to all of them. On October 21, attackers used what appear to be stolen GitHub CLI tokens from three LiteLLM engineers to push a malicious version 1.107.0 through the project’s own release pipeline. One account triggered the release and another approved it. The poisoned package was available on PyPI and in official Docker images for about two hours. Hidden inside was a file that runs whenever Python starts, before LiteLLM is even imported. It collected cloud tokens, private keys, AI tool credentials, and environment variables, then sent them to an attacker-controlled server. A second payload installed a backdoor that checked a GitHub dead drop every hour and ran whatever code it found.
AI workloads need AI-native controls over what they can reach and where they can send data. With those controls in place, both the credential upload and the hourly callback would have headed to destinations that were never approved. Both would have been blocked and flagged before anything left the environment. [See how Zentera secures AI workloads →]
A stolen password, a trusted vendor, a trusted update. In each case, the attacker or the attacker’s AI agent was already inside the trust boundary, and nothing was left to contain it. Different entry points, same failure: too much trust and too little containment. The fix is consistent across all three:
Key Takeaways
If you need guardrails around your critical systems, vendor integrations, or AI workloads, reach out and we will connect you with one of our solutions engineers. We can show you how to contain the blast radius before the next headline.