More than 2,500 companies and approximately 434,000 CI/CD pipelines worldwide were potentially exposed in what is believed to be the largest supply-chain attack targeting AI infrastructure in 2026.
In March 2026, threat actor group Team PCP compromised LiteLLM, a widely used open-source AI gateway. CloudSEK Threat Intelligence subsequently reconstructed the victim exposure and is now sharing details of impacted organisations to help security teams identify potential exposure and take remedial action.
The affected LiteLLM packages were reportedly available through PyPI for only around 40 minutes. However, automated CI/CD environments can download and execute dependencies rapidly, allowing even a short-lived compromise to create prolonged security risk.
Among the information potentially accessible from affected environments were AWS, Google Cloud and Microsoft Azure credentials, SSH keys, Kubernetes tokens, CI/CD secrets, repository credentials, environment variables and LLM/API keys.
CloudSEK’s exposure dataset includes high-confidence matches associated with major global organisations including NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales and London Stock Exchange Group, among others.
CloudSEK stresses that an exposure match does not automatically confirm successful compromise, data theft or malicious use of credentials. Organisations identified in the dataset should validate their exposure and investigate relevant systems.
The Threat May Outlive the Original Attack
The significance of the incident extends beyond the malicious package itself.
Once credentials are copied from an affected environment, removing the compromised software does not invalidate those credentials. According to CloudSEK’s analysis, stolen access can potentially be reused, sold or weaponized even after the malicious package has been removed, creating the possibility of downstream attacks weeks or months later.
The FBI also issued FLASH-20260702-01 on July 2, 2026, covering cybercriminal group TeamPCP, further highlighting the continuing security concern surrounding the campaign.
CloudSEK is sharing the exposure research openly so affected organisations can identify possible exposure, rotate credentials, investigate suspicious activity and harden their environments before compromised access is reused.
AI Infrastructure Is Becoming a High-Value Target
The LiteLLM incident also reflects a broader shift in cyberattacks.
AI gateways, MCP servers, agentic systems, vector databases and other AI infrastructure increasingly sit between sensitive corporate data, identities, cloud services and systems capable of taking action.
This makes AI infrastructure an attractive target for attackers seeking access beyond a single application. CloudSEK assesses that future attacks are increasingly likely to target the AI layer precisely because of how deeply it is connected to enterprise environments.
CloudSEK AIVigil: Continuous AI Attack Surface Monitoring
The growing attack surface around enterprise AI is the security problem CloudSEK AIVigil is designed to address.
AIVigil continuously discovers and monitors exposed AI infrastructure, MCP servers, leaked AI credentials, vector databases, agentic workflows and shadow AI. It combines CloudSEK’s cyber threat intelligence with AI exposure monitoring to help security teams identify exposed assets, credentials and attack paths before they develop into wider enterprise incidents.
Check Your Exposure
Organisations can use CloudSEK’s free exposure-checking tool to determine whether credentials associated with their environment appear in the identified dataset:
Free Exposure Checker: https://exposure.cloudsek.com/ai-supply-chain-incident
Full Research Report: https://www.cloudsek.com/blog/ai-supply-chain-breach-2500-companies-434000-cicd-pipelines
Full List Of Exposed Companies: TeamPCP CI/CD Secret Exposure — Check if your organisation is affected | CloudSEK
UPDATE: Rohit Valia, CEO of cybersecurity company Tumeryk, provided the following comments:
“Incidents like the recent LiteLLM supply chain compromise show that a single unrevoked token in an open source build chain can result in an ecosystem-wide exposure. Open source innovation is essential to the pace of AI development, but enterprises need more than the raw project — they need it hardened, tested, and accountable. It also needs to be put through rigorous security validation before it reaches production. Sanctioned shouldn’t just mean ‘permitted’ — it should mean proven.”
UPDATE #2: Seemant Sehgal, Founder & CEO, BreachLock adds this:
“The malicious packages were live for 40 minutes, but the window mattered to defenders long after it mattered to the attacker. Any system that pulled 1.82.7 or 1.82.8 during those 40 minutes ran malware on every subsequent Python startup, meaning credentials harvested from those environments have been sitting in attacker hands since before most teams knew there was an incident.
“Cloud keys, SSH keys, AI provider tokens, and package-publishing credentials from 434,000 CI/CD pipelines enable access, and access can be used quietly for a long time before anyone sees the effect. The initial scanner compromise fed LiteLLM’s CI pipeline, which pushed malware to PyPI. The affected organizations were two steps removed from the original breach, with every link in the chain working exactly as designed.”
John Strand, Owner, Black Hills Information Security, Inc.:
“One of the biggest takeaways from this latest LLM attack, especially when viewed alongside the recent wave of malicious NPM packages, is that sophisticated attackers are increasingly focused on the software supply chain. They’re looking for opportunities to compromise the tools and components that everyone trusts because that gives them an enormous amount of reach.
“What concerns me most about this attack isn’t just its scope, although the scope is certainly significant. It’s how difficult it would be for many organizations to detect. These attacks often operate outside the visibility of traditional security controls.
“In many ways, this reminds me of the early days of internet worms like Conficker, SQL Slammer, Blaster, and Nachi. Those threats spread incredibly fast, and because they were so loud, the entire security industry mobilized to detect them, contain them, and ultimately build better defenses.
“I think we’re seeing something similar with supply chain attacks today. Right now, attackers are going big. They’re compromising widely used packages and trying to maximize their impact. My concern is what happens after this phase. History tells us that attackers eventually become more disciplined. Instead of going after everything, they’ll become more selective, targeting the specific packages, libraries, and dependencies that give them access to the organizations they actually want to compromise.
“That’s why I see these attacks as a harbinger of what’s coming next. They’re already difficult to detect because they exist outside the normal visibility of EDR platforms, firewalls, and traditional intrusion detection and prevention systems. As attackers become more targeted and more subtle, that detection problem is only going to get harder for defenders.”
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“Forty minutes was the theft. Five months later, the FBI is still warning that the stolen credentials will be weaponized.
“I’ve been tracking TeamPCP’s campaign since they hit Aqua Security’s Trivy scanner in March. LiteLLM’s CI pipeline pulled Trivy from apt without pinning a version. One poisoned build later, the attackers had LiteLLM’s PyPI publishing credentials and pushed two malicious versions that ran code at Python startup, no import needed, bypassing the install-script protections most teams count on.
“2,500 organizations and 434,000 pipelines from that window. Automated build systems explain the math. They pull dependencies in seconds, cached layers spread them further, and a poisoned package rides the distribution network into every downstream consumer before anyone notices.
“TeamPCP has used this playbook all year. Trivy, LiteLLM, Microsoft’s durabletask-python twice, always re-entering through credentials that survived the previous cleanup. SANDCLOCK grabbed cloud keys, Kubernetes tokens, SSH keys, AI provider credentials, everything the runner could reach. Those stolen credentials often valid until someone actively revokes them.
“Organizations with a Software Bill of Materials (SBOM) knew within hours whether LiteLLM 1.82.7 or 1.82.8 was anywhere in their stack. A mandated delay on dependency updates, even an hour, would have cleared the entire 40-minute window before either version installed. Pin CI dependencies to verified hashes, scope runner credentials to the minimum each job needs, and if you ran either version, rotate every secret that runner could reach.”
Guest Post: Exposed Server Reveals Aurora Ransomware Affiliate’s Attacks on 20+ Organisations, AI-Assisted Planning and Crypto Trail
Posted in Commentary with tags CloudSEK on August 27, 2026 by itnerdAn exposed server belonging to an Aurora ransomware affiliate has revealed months of attack activity against more than 20 organisations across nine countries, giving researchers an unusually detailed view of how a ransomware operator moves from network compromise to data theft, encryption, extortion and payment laundering.
The exposed directory contained the operator’s Linux home directory, shell history, credential material, attack tooling, victim data, AI-assisted planning sessions and the Aurora ransomware encryptor itself, a CloudSEK investigation has revealed.
Working with TRM Labs, CloudSEK also traced a ransom payment on-chain. TRM Labs’ wider analysis identified two confirmed victim payments and two additional payments consistent with separate victims, with the funds ultimately converging through shared laundering infrastructure.
The findings provide a rare attacker-side view of a ransomware operation, showing not only the tools and techniques used to compromise organisations but also how the attacker planned intrusions, deployed ransomware and handled the financial proceeds.
20+ organisations compromised, 17 reached at domain or interactive level
The operator was active across the exposed dataset between April and July 2026 and compromised more than 20 organisations in nine countries.
CloudSEK found that the attacker achieved domain-level or interactive access at 17 organisations. Four of the organisations recorded in the attacker’s files were subsequently listed on Aurora’s public leak site, connecting the activity observed inside the operator’s infrastructure with later public extortion.
The victim set covered multiple industries, including manufacturing and industrial organisations, food and agriculture, professional and financial services, transport and logistics, consumer goods, environmental services, and IT and backup infrastructure. The United States accounted for the largest share of confirmed victims.
In several cases, the attacker obtained highly privileged access or sensitive material, including domain administrator credentials, Kerberos tickets, VPN credentials, Group Policy information, backup-system credentials and other authentication data.
Most of the affected organisations identified in the dataset have not appeared on public ransomware leak sites. CloudSEK initiated coordinated notification with relevant national CERTs and/or affected organisations before publication for victims that had not already been publicly identified.
AI coding assistant used to plan real-world attacks
One of the most significant findings was the operator’s use of Cursor, an AI-powered coding assistant, during attack planning.
Recovered sessions showed the attacker using Cursor in Russian to reason through attack sequences, including detailed planning around Active Directory Certificate Services exploitation. The chat history showed sustained back-and-forth use of the AI tool during victim engagements.
The finding offers direct visibility into how readily available AI tools are being incorporated into cybercriminal workflows, not merely for generating code, but for planning and working through attack paths against enterprise environments.
A repeatable playbook for compromising enterprise networks
The exposed directory allowed CloudSEK researchers to reconstruct a repeatable attack methodology used across multiple targets.
The operator repeatedly performed Active Directory and SMB discovery, retrieved password policies and carried out Kerberoasting and AS-REP Roasting. For privilege escalation, the attacker relied on several techniques depending on the environment, including a custom noPac chain, Active Directory Certificate Services abuse across ESC1, ESC6 and ESC8, and NTLM relay attacks using PetitPotam, PrinterBug and DFSCoerce.
Exploit code for at least a dozen vulnerabilities was also stored in the exposed environment. Much of it consisted of public proof-of-concept code, while some tooling had been modified and a FortiOS toolkit had been rebuilt as an independent framework.
The operator maintained custom NetExec modules, including tools designed to collect browser credentials across multiple browsers and identify ESXi infrastructure.
CloudSEK assesses with high confidence that the individual was operating directly as an Aurora ransomware affiliate rather than functioning solely as an initial-access broker. The activity continued beyond obtaining access into credential theft, domain compromise, exfiltration, ransomware staging and extortion.
Aurora ransomware built in Zig targets Windows, Linux and ESXi
The exposed environment also contained multiple versions of the Aurora encryptor for Windows and Linux/ESXi systems.
Both versions were written in Zig, a relatively uncommon programming language in ransomware development. The Windows and Linux variants appear to have been built from the same Zig codebase and compiled for different operating systems.
The encryptor supports several options designed to speed up or customise encryption, including partial-file encryption, multithreading and file-size restrictions.
The Linux/ESXi version contains functionality specifically designed for virtual infrastructure. Before encryption begins, the ransomware enumerates running virtual machines and force-terminates them. It also handles ransom-note delivery differently: instead of simply dropping a note as a file, it can modify the ESXi host’s SSH login banner so that the ransom message appears when administrators connect to the server.
The report includes indicators of compromise and a detection rule designed to identify this behaviour.
Following the ransom payment trail
The exposed files also provided researchers with visibility into the financial side of the operation. The wallet address the operator provided for payment was found to hold 7 BTC at the time of analysis, a balance more consistent with accumulated proceeds from several victims than a single payment, and itself a strong indicator that this operator’s activity generates significant revenue.
A key recovered from the Aurora encryptor allowed CloudSEK to access records from a completed ransom negotiation. The victim involved is not being named.
Working with TRM Labs, CloudSEK traced the resulting payment on-chain and examined how the funds moved after payment.
The wider analysis identified two confirmed victim payments and two additional payments consistent with separate victims. While each payment began on a separate path, several later converged at shared consolidation points before moving towards cash-out infrastructure.
Researchers also observed differing splits across the payments analysed, including 35/65, 21/79, 46/54 and 40/60, with no single ratio consistently repeated. The finding suggests that, across the transactions examined, the division of proceeds between participants was not based on a single fixed percentage.
Most of the traced funds passed through two dominant consolidation clusters before reaching cash-out addresses. One payment followed a different route through a peeling chain, where funds were gradually moved across a sequence of transactions rather than through the main consolidation hubs.
The financial activity observed in the investigation suggests that Aurora-linked ransomware activity may extend beyond the victims visible on public leak sites.
Russian-speaking operator, CIS targets absent from observed dataset
CloudSEK assesses with high confidence that the operator is Russian-speaking.
The assessment is based on material created directly by the attacker, including Cursor conversations, module documentation and session notes written in Russian.
Researchers also found that no CIS-allocated IP ranges or CIS-country domains appeared in three months of the operator’s target lists, scans or success logs.
CloudSEK’s assessment relates to the operator’s language and the targeting behaviour visible in the recovered dataset and does not establish the individual’s nationality or physical location.
Why the investigation matters
Ransomware investigations typically begin after an organisation has already been compromised, forcing defenders and researchers to reconstruct an attack from the victim’s environment.
In this case, the exposed directory provided visibility from the other side.
Researchers were able to examine the attacker’s working environment, understand how organisations were enumerated, follow privilege-escalation attempts, review stolen credentials and attack tools, observe the use of AI during operational planning, analyse the ransomware itself and follow a victim payment into cryptocurrency laundering infrastructure.
Taken together, the findings provide an unusually detailed picture of the operational lifecycle of a modern ransomware affiliate, from enterprise intrusion and data theft to encryption, extortion and the movement of ransom proceeds.
The full report also includes technical indicators of compromise, attacker infrastructure, malware hashes, detection rules and detailed mitigation recommendations to help organisations identify and defend against similar activity.
For more information, read the full report.
Leave a comment »