Search/GlassWorm attack installs fake browser extension for surveillance
● Story

GlassWorm attack installs fake browser extension for surveillance

Supply-chain attacks have been one of the most dangerous categories of cybersecurity incidents for years now. And if 2025 taught us anything, it’s that cybercriminals are doubling down on them. In this deep dive, we’re looking at supply-chain attacks from 2025 that, while not always the costliest, were certainly the most unusual and caught the industry’s attention. January 2025: a RAT found in the DogWifTools GitHub repository As a “warm-up” after the holiday break, cybercriminals systematically backdoored several versions of DogWifTools. This is a utility designed for launching and vigorously promoting Solana-based meme coins on Pump.fun. After compromising the private GitHub repository for DogWifTools, the attackers waited for the developers to upload a fresh build, injected a RAT into…

CVEs
0
Highest CVSS
—
In KEV
0
Sources
3
Connections
23 relationships
Most notable supply-chain attacks of 2025 | Kaspersky official blog
Supply-chain attacks have been one of the most dangerous categories of cybersecurity incidents for years now. And if 2025 taught us anything, it’s that cybercriminals are doubling down on them. In this deep dive, we’re looking at supply-chain attacks from 2025 that, while not always the costliest, were certainly the most unusual and caught the industry’s attention. January 2025: a RAT found in the DogWifTools GitHub repository As a “warm-up” after the holiday break, cybercriminals systematically backdoored several versions of DogWifTools. This is a utility designed for launching and vigorously promoting Solana-based meme coins on Pump.fun. After compromising the private GitHub repository for DogWifTools, the attackers waited for the developers to upload a fresh build, injected a RAT into it, and then swapped the legitimate program with their malicious version just a few hours later. According to the developers, the threat actors successfully trojanized versions 1.6.3 through 1.6.6 of DogWifTools for Windows. The endgame was triggered in late January. After using the RAT to harvest a massive amount of data from infected devices, the attackers drained their victims’ crypto wallets. While victims estimate the total haul at over US$10 million in cryptocurrency, the attackers themselves disputed that figure — though they stopped short of revealing exactly how much they’d actually made off with. February 2025: the US$1.5 billion Bybit heist If January was a warm-up, February was a total meltdown. The Bybit crypto exchange hack completely eclipsed previous incidents — becoming the largest crypto heist in history. The attackers managed to compromise the Safe{Wallet} software, the multisig cold storage solution the exchange relied on to manage its assets. Bybit employees thought they were signing a routine transaction; in reality they were authorizing a malicious smart contract. Once executed, it drained a primary cold wallet, dispersing the funds across several hundred attacker-controlled addresses. The final haul exceeded 400 000 ETH/stETH, with a staggering total value of approximately… US$1.5 billion! March 2025: Coinbase targeted in a GitHub Actions cascading compromise Spring 2025 kicked off with a sophisticated attack that used a compromise of multiple GitHub Actions — the workflow patterns used to automate standard DevOps tasks — as its primary delivery mechanism. It all started with the theft of a personal access token belonging to a maintainer of the SpotBugs analysis tool. Using this foothold, the attackers published a malicious process and managed to hijack a token from a maintainer of the reviewdog/action-setup workflow, who was also involved in the project. From there, they compromised a dependency, the tj-actions/changed-files workflow, modifying it to execute a malicious Python script. This script was designed to hunt for high-value secrets, such as AWS, Azure and Google Cloud keys, GitHub and NPM tokens, database credentials, and RSA private keys. Oddly, the script wrote everything it found directly to publicly accessible build logs. This meant the leaked data wasn’t just available to the attackers, but to anyone savvy enough to look. The original goal of this operation was a repository belonging to the Coinbase crypto exchange. Fortunately, the developers caught the threat in time and prevented the compromise. After apparently realizing they were about to lose control of the tj-actions/changed-files pipeline, the attackers pivoted to a spray-and-pray approach. This put 23 000 repositories at risk of a secrets leak. In the end, several hundred of those repositories actually saw their sensitive credentials exposed to the public. April 2025: a backdoor in 21 Magento extensions In April, an infection was discovered across a whole range of extensions for Magento, one of the most popular platforms for building online stores. The backdoor was embedded into 21 modules developed by three vendors: Tigren, Meetanshi, and MGS. These extensions were part of the infrastructure for several hundred e-commerce companies, including at least one multinational corporation. According to the researchers who discovered it, the backdoor was actually planted way back in 2019. In April 2025, the attackers finally triggered it to compromise websites and upload web shells. This was accomplished through a function embedded in the extensions that executed arbitrary code pulled from a license file. Ironically, the infected modules included MGS GDPR and Meetanshi CookieNotice. As the names suggest, these extensions were designed to help sites comply with user privacy and data processing regulations. In the end, instead of ensuring privacy, their use most probably led to the theft of user data and financial assets through web skimming. May 2025: ransomware distributed through a compromised MSP In May, ransomware actors from the DragonForce gang gained access to the infrastructure of an unnamed managed service provider (MSP) and used it to distribute their ransomware and steal data from the MSP’s client organizations. It appears the attackers exploited several vulnerabilities (including one critical flaw) in SimpleHelp, the remote monitoring and management tool used by the MSP. These vulnerabilities were discovered back in 2024 and were publicly disclosed and patched in January 2025. Unfortunately, the MSP evidently decided not to rush the update process — a delay the ransomware gang was more than happy to exploit. June 2025: a backdoor in over a dozen popular npm packages At the start of the summer, attackers hacked the account of one of the Gluestack library maintainers and used a stolen access token to inject backdoors into 17 npm packages. The most popular of these packages, @react-native-aria/interactions, boasted 125 000 weekly downloads, while all the compromised packages combined totaled over a million. What’s particularly interesting in this case are the steps the Gluestack developers took following the incident: first, they restricted GitHub repository access for secondary contributors; second, they enabled two-factor authentication (2FA) for publishing new versions; and third, they promised to implement secure development practices like pull-request-based workflow, systematic code reviews, audit logging, and so on. In other words, prior to the incident a project with hundreds of thousands of weekly downloads had no such measures in place. July 2025: popular npm packages infected through a phishing attack In July, npm packages were once again the stars of the show — including the widely used, succinctly named “is” package, which boasts 2.7 million weekly downloads. This JavaScript utility library provides a broad range of type-checking and value validation functions. To pull off a phishing strike against one of the project owners, attackers successfully utilized the oldest trick in the book: typosquatting (using the domain npnjs.com instead of npmjs.com) and a clone of the official npm website. They then used the compromised account to publish several of their own versions of the package with an embedded backdoor. The infection flew under the radar for six hours: plenty of time for a large number of developers to download the malicious npm packages. The same phishing tactic was deployed against other developers as well. The attackers leveraged several compromised developer accounts to distribute different variants of their malicious payload. There’s also a strong suspicion that they may have saved some of their haul for future attacks. August 2025: the s1ngularity attack and a leak of hundreds of developers’ secrets In late August, an incident dubbed “s1ngularity” continued the trend of targeting JavaScript developers. Attackers compromised Nx, a popular build system and CI/CD pipeline optimization tool. Malicious code injected into the packages searched through infected developer systems for a vast range of sensitive data, such as crypto wallet keys, npm and GitHub tokens, SSH keys, API keys, and more. Interestingly, the attackers used locally installed AI tools, such as Claude Code, Gemini CLI, and Amazon Q, to sniff out secrets on the victims’ machines. Everything they found was then posted to public GitHub repositories created in the victims’ names, using titles “s1ngularity-repository”, “s1ngularity-repository-0”, and “s1ngularity-repository-1”. As you might have guessed, that’s where the name of the attack comes from. Consequently, the private data of hundreds of developers ended up sitting in plain sight, where it could be accessed not just by the attackers, but by absolutely anyone with an internet connection. September 2025: a crypto stealer hits npm packages that have 2.6 billion weekly downloads The trend of npm package compromises rolled right into September. Following a fresh phishing campaign targeting JavaScript developers, attackers managed to inject malicious code into a few dozen high-profile projects. Some of these, specifically “chalk” and “debug”, boast hundreds of millions of weekly downloads; collectively, the infected packages were racking up over 2.6 billion downloads per week at the time of the breach — and they’ve only grown more popular since. The payload was a crypto stealer: malware designed to intercept cryptocurrency transactions and reroute them to the attackers’ wallets. Fortunately, despite successfully poisoning some of the world’s most popular projects, the attackers somehow managed to botch the final stage of their operation. In the end, they walked away with a measly US$925. Just a week later, another major incident struck: the first wave of the self-propagating Shai-Hulud malware, which infected around 150 npm packages, including projects from CrowdStrike. However, the second wave, which hit several months later, proved to be far more destructive. We’ll take a closer look at the Great Worm a bit further down. October 2025: GlassWorm infects the Visual Studio Code ecosystem Roughly a month after the Shai-Hulud attack, similar self-propagating malware dubbed GlassWorm began infecting Visual Studio Code extensions across both the Open VSX Registry and the Microsoft Extension Marketplace. The attackers were hunting for GitHub, Git, npm, and Open VSX accounts, as well as crypto wallet keys. The creators of GlassWorm took a highly creative approach to their command-and-control infrastructure: they used a crypto wallet on the Solana blockchain as their primary C2, with Google Calendar serving as a backup communication channel. Beyond simply draining victims’ crypto wallets and hijacking their accounts to spread the worm further, the attackers also dropped a RAT named Zombi onto infected devices, granting them total control over the compromised systems. November 2025: the IndonesianFoods campaign and 150 000 spam packages on npm In November, a new nuisance emerged within the npm registry. A coordinated malicious campaign dubbed IndonesianFoods saw attackers flood the registry with tens of thousands of useless packages. The primary goal here was gaming the system to inflate metrics and farm tokens on tea.xyz, a blockchain platform designed to reward open-source developers. To pull this off, the attackers built a massive web of interdependent projects with the names referencing Indonesian cuisine, such as zul-tapai9-kyuki or andi-rendang23-breki. The creators of this campaign didn’t bother hijacking accounts. Strictly speaking, the spam packages didn’t even contain a malicious payload — unless you count a script designed to automatically generate new packages every seven seconds. Nevertheless, the incident served as a stark reminder of how vulnerable the npm infrastructure is to large-scale spam campaigns. December 2025: Shai-Hulud 2.0 and the leak of 400 000 developer secrets The absolute headliner of the year — not just for supply-chain attacks, but likely for the entire cybersecurity field — was the self-propagating malware Shai-Hulud (also known as Sha1-Hulud) targeting developers. This malware was the logical evolution of the s1ngularity attack we mentioned earlier: it also scours systems for all kinds of secrets and publishes them in open GitHub repositories. However, Shai-Hulud added a self-propagation mechanism to this baseline: the worm infects projects controlled by already-compromised developers by using their stolen credentials. The first wave of Shai-Hulud hit in September, infecting several hundred npm packages. But toward the end of the year, a second wave arrived, dubbed Shai-Hulud 2.0. This time, the worm was upgraded with wiper functionality. If the malware failed to find valid npm or GitHub tokens on an infected system, it triggered a destructive payload that erased user files. Approximately 400 000 secrets were leaked in total as a result of the attack. It’s worth noting that, just like with s1ngularity, all this sensitive data ended up in public repositories where it could be downloaded not only by the attackers but by anyone else. And it’s highly likely that the fallout from this attack will be felt for a long time to come. One of the first, confirmed cases of an exploit using secrets leaked by Shai-Hulud was a cryptocurrency theft targeting several thousand Trust Wallet users. Attackers used these secrets on Christmas Eve to upload a malicious version of the Trust Wallet extension, complete with a built-in crypto drainer, to the Chrome Web Store. In the end, they managed to make off with US$8.5 million in cryptocurrency. How to protect against supply-chain attacks While putting together a similar retrospective for 2024, we found sticking to a “one month, one threat” structure fairly easy. For 2025, however, it was a much taller order. There were so many massive supply-chain attacks last year that we simply couldn’t fit them all into this one overview. The year 2026 is shaping up to be just as intense, so we recommend checking out our dedicated post on preventing supply-chain attacks. In the meantime, here are the essential takeaways: Thoroughly evaluate your vendors and carefully audit the code you integrate into your own projects. Implement strict security requirements directly into your service contracts. Develop a comprehensive incident response plan. Monitor your corporate infrastructure for suspicious activity using an XDR solution. If your internal security team is stretched thin, leverage an external service for proactive threat hunting and timely response. If you want to learn more about supply-chain attacks, have a read of our analytical report Supply chain reaction: securing the global digital ecosystem in an age of interdependence. It’s based on insights from technical experts, and reveals how often organizations face supply-chain and trusted-relationship risks, where protection gaps remain, and what strategies to employ to improve resilience against these kinds of threats.
kaspersky.comMar 27, 2026extracted
GlassWorm attack installs fake browser extension for surveillance
GlassWorm hides inside developer tools. Once it’s in, it steals data, installs remote access malware, and even a fake browser extension to monitor activity. While it starts with developers, the impact can quickly spread. With stolen credentials, access tokens, and compromised tools, attackers can launch wider supply chain attacks, putting companies and everyday users at risk. How the infection starts GlassWorm is usually distributed through developer channels. That means that programmers get their systems compromised by downloading malicious packages from code repositories like npm, GitHub, PyPI, and so on. These can be new malicious packages or altered packages from once-trusted, but now compromised, accounts. The developer installs or updates a trusted or popular npm/PyPI package or VS Code extension, but the maintainer’s account or supply chain has been compromised. What happens after installation Once the package is pulled, a preinstall script or invisible Unicode loader runs and fingerprints the machine. If it finds a Russian locale, execution stops. If not, the script waits a few hours and then quietly contacts the Solana blockchain to discover where to fetch stage two of the infection. Rather than hardcoding a link that could be taken down, the attacker stores this information in the memo field of a Solana transaction. Stage two: Data theft The stage two payload is an infostealer that targets browser extension profiles, standalone wallet apps, and .txt/image files likely holding seeds or keys, along with npm tokens, git credentials, VS Code secrets, and cloud provider credentials. After gathering this information, it sends it to a remote server via a POST request. Stage three: Full system compromise After that, it’s on to stage three. The malware fetches two main components: the Ledger/Trezor phishing binary aimed at users with a Ledger or Trezor device plugged in, and a Node.js Remote Access Trojan (RAT) with several modules, including browser credential stealers and a Chrome‑extension installer. It gains persistence by setting up scheduled tasks and Run registry keys so that the RAT comes back on every reboot. The RAT does not hardcode its main command and control (C2) address. Instead, it performs a distributed hash table (DHT) lookup for the pinned public key. DHT is a distributed system that provides a lookup service similar to a hash table. Key–value pairs are stored in a DHT and can be used to retrieve the value associated with a given key. If this method fails, the RAT goes back to the Solana blockchain to fetch a new IP address. Browser surveillance and tracking The RAT also force-installs a Chrome extension (in the example described by Aikido, it pretends to be “Google Docs Offline”), which acts as an onboard session surveillance. Besides stealing cookies, localStorage, the full Document Object Model (DOM) tree of the active tab, bookmarks, screenshots, keystrokes, clipboard content, up to 5,000 browser history entries, and the installed extensions list, it can also be used to take screenshots and act as a keylogger. What this looks like to the victim From the victim’s point of view, all this happens very stealthily. If they’re paying close attention, they may see a few suspicious outgoing connections, the startup entries, and the new browser extension. Who’s at risk, and how this could spread The current setup appears to focus on developers who may have cryptocurrency assets, but many of these components and the stolen information can be used to initiate supply chain attacks or target other groups of users. How to stay safe Because of the stealthy nature of this infection chain, there are two main strategies to stay safe: Prefer known‑good, pinned versions, and treat sudden ownership changes, new maintainers, or big code rewrites in minor releases as review triggers. Regularly audit browser extensions, remove anything you don’t recognize, and be suspicious of “Google Docs Offline”‑style clones or duplicates. Check your scheduled tasks and registry startup locations for unexpected entries. Use an up-to-date, real-time anti-malware solution to detect and block malicious connections and the downloaded malware. IOCs (Indicators of Compromise) IP addresses: 45.32.150[.]251 217.69.3[.]152 217.69.0[.]159 45.150.34[.]158 Registry keys: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\UpdateApp HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\UpdateLedger Scheduled Task: Name: UpdateApp which runs: AghzgY.ps1 Browser extension: Display name: Google Docs Offline (version 1.95.1) Windows extension directory name :jucku macOS extension directory name: myextension From reporting threats to removing them. Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
malwarebytes.comMar 26, 2026extracted
GlassWorm Malware Uses Solana Dead Drops to Deliver RAT and Steal Browser, Crypto Data
Cybersecurity researchers have flagged a new evolution of the GlassWorm campaign that delivers a multi-stage framework capable of comprehensive data theft and installing a remote access trojan (RAT), which deploys an information-stealing Google Chrome extension masquerading as an offline version of Google Docs. "It logs keystrokes, dumps cookies and session tokens, captures screenshots, and takes commands from a C2 server hidden in a Solana blockchain memo," Aikido security researcher Ilyas Makari said in a report published last week. GlassWorm is the moniker assigned to a persistent campaign that obtains an initial foothold through rogue packages published across npm, PyPI, GitHub, and the Open VSX marketplace. In addition, the operators are known to compromise the accounts of project maintainers to push poisoned updates. The attacks are careful enough to avoid infecting systems with a Russian locale and use Solana transactions as a dead drop resolver to fetch the command-and-control (C2) server ("45.32.150[.]251") and download operating system-specific payloads. The stage two payload is a data-theft framework with credential harvesting, cryptocurrency wallet exfiltration, and system profiling capabilities. The collected data is compressed into a ZIP archive and exfiltrated to an external server ("217.69.3[.]152/wall"). It also incorporates functionality to retrieve and launch the final payload. Once the data is transmitted, the attack chain involves fetching two additional components: a .NET binary that is designed to carry out hardware wallet phishing and a Websocket-based JavaScript RAT to siphon web browser data and run arbitrary code. The RAT payload is fetched from "45.32.150[.]251" by using a public Google Calendar event URL as a dead drop resolver. The .NET binary leverages the Windows Management Instrumentation (WMI) infrastructure to detect USB device connections and displays a phishing window when a Ledger or Trezor hardware wallet is plugged in. "The Ledger UI displays a fake configuration error and presents 24 numbered recovery phrase input fields," Makari noted. "The Trezor UI displays a fake "Firmware validation failed, initiating emergency reboot" message with the same 24-word input layout. Both windows include a 'RESTORE WALLET' button." The malware not only kills any real Ledger Live processes running on the Windows host, but also re-displays the phishing window if the victim closes it. The end goal of the attack is to capture the wallet recovery phrase and transmit it to the IP address "45.150.34[.]158." The RAT, on the other hand, uses a Distributed Hash Table (DHT) to retrieve the C2 details. In the event the mechanism returns no value, the malware switches to the Solana-based dead drop. The RAT then establishes communication with the server to run various commands on the compromised system - start_hvnc / stop_hvnc, to deploy a Hidden Virtual Network Computing (HVNC) module for remote desktop access. start_socks / stop_socks, to launch a WebRTC module and run it as a SOCKS proxy. reget_log, to steal data from web browsers, such as Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Vivaldi, and Mozilla Firefox. The component is equipped to bypass Chrome's app-bound encryption (ABE) protections. get_system_info, to send system information. command, to execute attacker-supplied JavaScript via eval(). The RAT also force-installs a Google Chrome extension named Google Docs Offline on Windows and macOS systems, which then connects to a C2 server and receives commands issued by the operator, allowing to gather cookies, localStorage, the full Document Object Model (DOM) tree of the active tab, bookmarks, screenshots, keystrokes, clipboard content, up to 5,000 browser history entries, and the installed extensions list. "The extension also performs targeted session surveillance. It pulls monitored site rules from /api/get-url-for-watch and ships with Bybit (.bybit.com) pre-configured as a target, watching for the secure-token and deviceid cookies," Aikido said. "On detection, it fires an auth-detected webhook to /api/webhook/auth-detected containing the cookie material and page metadata. The C2 can also supply redirect rules that force active tabs to attacker-controlled URLs." The discovery coincides with yet another shift in GlassWorm tactics, with the attackers publishing npm packages impersonating the WaterCrawl Model Context Protocol (MCP) server ("@iflow-mcp/watercrawl-watercrawl-mcp) to distribute malicious payloads. "This is GlassWorm's first confirmed move into the MCP ecosystem," Koi security researcher Lotan Sery said. "And given how fast AI-assisted development is growing – and how much trust MCP servers are given by design – this won't be the last." Developers are advised to exercise caution when it comes to installing Open VSX extensions, npm packages, and MCP servers. It's also recommended to verify publisher names, package histories, and avoid blindly trusting download counts. Polish cybersecurity company AFINE has published an open-source Python tool called glassworm-hunter to scan developer systems for payloads associated with the campaign. "Glassworm-hunter makes zero network requests during scanning," researchers Paweł Woyke and Sławomir Zakrzewski said. "No telemetry. No phone-home. No automatic update checks. It reads local files only. Glassworm-hunter update is the only command that touches the network. It fetches the latest IoC database from our GitHub and saves it locally."
thehackernews.comMar 25, 2026extracted
Related Stories
6
TeamPCP deploys Iran-targeted wiper in Kubernetes attacks
This is the second update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 001 covered developments through March 26. This update covers developments from March 26-27, 2026. CRITICAL: Telnyx Python SDK Compromised on PyPI -- New WAV Steganography TTP TeamPCP compromised the telnyx Python SDK (670,000+ monthly downloads) on PyPI, publishing malicious versions 4.87.1 and 4.87.2 at approximately 03:51 UTC on March 27, 2026. No corresponding GitHub releases or tags exist for these versions -- the attacker used stolen PyPI credentials rather than a repository compromise. The most significant technical finding is a new TTP: WAV audio file steganography. Payloads are embedded inside .wav files, which blend naturally with Telnyx's purpose as a voice and telecom API provider. Platform-specific payloads are delivered: Windows: A persistent binary dropped to the Startup folder as msbuild.exe Linux/macOS: A credential harvester following the same pattern as the LiteLLM compromise Forensic analysis by Aikido Security, JFrog, and SafeDep confirms the same RSA-4096 public key and tpcp.tar.gz exfiltration pattern seen in the LiteLLM compromise. Both malicious versions have been quarantined by PyPI. Recommended action: Check your Python environments and CI/CD pipelines for telnyx versions 4.87.1 or 4.87.2. If found, treat all credentials accessible to that environment as compromised and rotate immediately. The last known-safe version is 4.87.0. Also search for .wav files in unexpected locations, msbuild.exe in Windows Startup folders, and outbound connections to known TeamPCP exfiltration domains. This confirms the "expansion to additional PyPI packages" watch item from Update 001. TeamPCP's PyPI campaign is not limited to LiteLLM -- they are actively working through stolen credentials to compromise additional high-value packages. CRITICAL: TeamPCP Partners with Vect Ransomware and BreachForums for Mass Affiliate Program TeamPCP has formally partnered with the Vect ransomware-as-a-service operation and BreachForums. Per Cybernews and Infosecurity Magazine, the announcement states that all approximately 300,000 registered BreachForums users will receive personal Vect affiliate keys. The operational model: TeamPCP provides initial access via compromised supply chain packages and stolen credentials, Vect provides encryption and extortion tooling, and BreachForums provides the operator base. Analysts assess this represents a fundamental shift from supply chain credential theft to industrialized ransomware deployment. If even a small fraction of 300,000 users activate, this could become one of the largest coordinated ransomware affiliate mobilizations observed. The convergence of supply chain compromise, ransomware-as-a-service, and dark web forum mobilization at this scale is, to the best of our knowledge, unprecedented. Recommended action: Organizations that were exposed to any phase of the TeamPCP campaign (Trivy, Checkmarx, LiteLLM, Telnyx) should assume their stolen credentials may now be distributed to a large affiliate network. Credential rotation is no longer optional -- it is urgent. Monitor for Vect ransomware indicators. HIGH: LAPSUS$ Claims 3GB AstraZeneca Breach Using TeamPCP Credentials LAPSUS$ is publicly claiming a 3GB breach of AstraZeneca, as reported by SecurityWeek and CSO Online. The claimed data includes internal code repositories, cloud infrastructure configurations (AWS, Azure, Terraform), Spring Boot configs, GitHub Enterprise user information, and employee data. LAPSUS$ is selling access via Session encrypted messaging. This is the first named victim claim from the TeamPCP/LAPSUS$ partnership, confirming the "named victim breach disclosures" watch item from Update 001. AstraZeneca has not confirmed or denied the breach as of publication time. Recommended action: Organizations should not wait for public victim disclosures to take action. If you were exposed to any TeamPCP-compromised component, assume credential theft occurred and rotate proactively. The extortion timeline is accelerating. HIGH: LiteLLM CEO's Personal GitHub Account Was the Compromise Vector ReversingLabs has published new intelligence identifying the specific mechanism behind the LiteLLM PyPI compromise: TeamPCP compromised Krish Dholakia's personal GitHub account (LiteLLM co-founder and CEO) on March 23-24. This was not a generic CI/CD token sweep -- the attacker specifically identified and targeted a named executive's account from the stolen credential trove harvested during the Trivy/Checkmarx phase. This detail refines the attack chain narrative. TeamPCP appears to be triaging stolen credentials for maximum impact, targeting package maintainers with PyPI publishing privileges rather than indiscriminately using every credential they harvested. MEDIUM: CISA KEV Remediation Deadline Correction -- April 8, Not April 3 Update 001 reported the CISA KEV remediation deadline for CVE-2026-33634 as April 3, 2026. The official CISA KEV catalog entry shows the actual deadline is April 8, 2026. This update corrects the previously reported date. Additionally, Help Net Security reports that CISA simultaneously added CVE-2026-33017 (Langflow unauthenticated RCE, affecting versions prior to 1.8.2) alongside the Trivy CVE in the same KEV update. The pairing of two AI/ML infrastructure tool vulnerabilities in a single KEV addition signals that CISA is treating AI toolchain supply chain security as a systemic risk category. Federal agencies now face remediation deadlines of April 8 for CVE-2026-33634 (Trivy) and April 9 for CVE-2026-33017 (Langflow). INFO: LiteLLM's Compliance Certifications Performed by Embattled Auditor TechCrunch reported on March 26 that LiteLLM's SOC2 and ISO 27001 certifications were performed by Delve, a YC startup currently under scrutiny for allegations of "rubber-stamped" compliance audits. This intersection of two Silicon Valley scandals raises questions about the effectiveness of third-party compliance certifications in the AI/ML supply chain ecosystem. HIGH: First Responder Publishes Full Attack Transcript With New IOCs FutureSearch has published the full forensic transcript from Callum McMahon, the engineer who first discovered the compromised LiteLLM package and coordinated the PyPI quarantine on March 24. McMahon used Claude Code to perform real-time forensic analysis of the malicious litellm==1.82.8 package in an isolated Docker environment, producing what is likely the most detailed public record of this attack's execution. Key technical findings not previously documented in the campaign report: .pth file exploitation: The payload (litellm_init.pth , 34 KB) exploited Python's automatic.pth site-packages execution, triggering on every Python interpreter startup -- not just when LiteLLM was imported. This is a persistence mechanism that runs across all Python processes in the environment. C2 domain: models.litellm.cloud -- a typosquat of LiteLLM's legitimate infrastructure, used for HTTPS exfiltration with RSA encryption. Persistence path: ~/.config/sysmon/sysmon.py with systemd service registration. In McMahon's case, the write was interrupted at 0 bytes by a forced reboot. Kubernetes lateral movement: The payload attempted to create privileged alpine:latest pods and harvest service account tokens from/var/run/secrets/kubernetes.io/serviceaccount/token , usingnode-setup-* pod naming to blend with legitimate infrastructure. Multi-cloud credential sweep: A single payload targeted SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, .env files, database passwords, crypto wallets, and shell history simultaneously. Accidental fork bomb: The .pth auto-execution combined with subprocess spawning created exponential process multiplication -- each child Python process re-triggered the payload, causing resource exhaustion that inadvertently exposed the attack. The 72-minute timeline from detection to public PyPI quarantine demonstrates how AI-assisted forensic analysis dramatically accelerated incident response. This transcript is highly instructive for defenders studying the attack mechanics and should be reviewed by any team performing forensic analysis of TeamPCP-compromised environments. Recommended action: Search environments for the C2 domain models.litellm.cloud, the persistence path ~/.config/sysmon/sysmon.py, unexpected .pth files in site-packages directories, and node-setup-* pods in Kubernetes clusters. These IOCs supplement the indicators in the parent report. INFO: GitHub Announces Actions Security Roadmap in Response to Supply Chain Attacks GitHub has published a 2026 security roadmap for GitHub Actions that directly references the TeamPCP campaign. The blog post states: "incidents targeting projects like tj-actions/changed-file, Nx, and trivy-action show a clear pattern: attackers are targeting CI/CD automation itself." The roadmap introduces three categories of controls that, if implemented at the time of the Trivy compromise, would have materially altered the attack surface: Workflow dependency locking: A new dependencies: section in workflow YAML pins all direct and transitive action references to immutable commit SHAs. Hash mismatches stop execution before jobs run. This directly addresses the tag-rewriting TTP that TeamPCP used to redirect 76 trivy-action tags and all 91 ast-github-action tags to malicious commits. Public preview in 3-6 months. Policy-driven execution controls: Rulesets-based policies that restrict which actors can trigger workflows, which events are permitted, and which execution contexts can access secrets. Scoped secrets prevent a single compromised token from accessing all repository secrets. Public preview in 3-6 months. Egress firewall for hosted runners: Layer 7 network monitoring and enforcement for GitHub-hosted runners, restricting which external domains workflows can reach. This would have blocked the exfiltration to scan.aquasecurtiy[.]org andmodels.litellm.cloud . Public preview in 6-9 months. Analysts assess these controls represent the most substantive platform-level response to the GitHub Actions supply chain attack vector to date. However, the 3-9 month rollout timeline means organizations remain exposed to tag-rewriting and credential theft TTPs in the interim. Pinning actions to full commit SHAs remains the primary defensive measure until dependency locking reaches GA. Additional Intelligence Kaspersky publishes independent verification: Kaspersky published their own technical advisory characterizing this as a unified "trojanization" campaign, independently verifying the attack chain and broadening awareness to their enterprise customer base. GitGuardian draws "Shai Hulud" parallel: GitGuardian frames the campaign alongside the "Shai Hulud" attack pattern -- both targeting CI/CD pipelines to harvest secrets rather than attacking applications directly. Their analysis emphasizes that Aqua Security's non-atomic credential rotation was the root cause enabling the second compromise wave (Docker Hub images v0.69.5 and v0.69.6 on March 22). Corrections to Update 001 Aqua Security "additional findings" deadline: Update 001 stated "Aqua Security promised additional findings by end of day March 26" as a watch item. This was incorrect. On March 23, 2026, Aqua Security's blog stated they would "provide a further update, including additional findings, tomorrow end of day" -- meaning end of day March 24, not March 26. Aqua published their comprehensive incident report, "Trivy Supply Chain Attack: What Happened and What You Need to Know", on March 24 at 23:00 UTC, meeting their stated deadline. The report covers the full attack timeline, root cause (non-atomic credential rotation after the March 1 incident), and remediation details. This is no longer a watch item. CISA KEV remediation deadline: Also corrected in this update's MEDIUM finding above -- April 8, not April 3 as originally reported in Update 001. Watch Items Vect ransomware affiliate key distribution and first deployments linked to TeamPCP credentials Additional PyPI packages compromised via stolen credentials (telnyx confirms the pattern) AstraZeneca confirmation or denial of the LAPSUS$ breach claim Mandiant formal attribution report (BerriAI engagement announced, report pending) CISA standalone advisory or emergency directive (KEV entries issued, no dedicated advisory yet) Expansion to RubyGems, crates.io, or Maven Central (Endor Labs prediction, not yet confirmed) LiteLLM/BerriAI forensics completion and release resumption The full campaign report is available at sans.org/white-papers/when-security-scanner-became-weapon. A SANS Emergency Webcast replay is available at sans.org/webcasts/when-security-scanner-became-weapon. Updates to the report will be in the form of these ISC diaries.
11 shared
Mar 28, 2026
TeamPCP Moves From OSS to AWS Environments
This is the second update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 001 covered developments through March 26. This update covers developments from March 26-27, 2026. CRITICAL: Telnyx Python SDK Compromised on PyPI -- New WAV Steganography TTP TeamPCP compromised the telnyx Python SDK (670,000+ monthly downloads) on PyPI, publishing malicious versions 4.87.1 and 4.87.2 at approximately 03:51 UTC on March 27, 2026. No corresponding GitHub releases or tags exist for these versions -- the attacker used stolen PyPI credentials rather than a repository compromise. The most significant technical finding is a new TTP: WAV audio file steganography. Payloads are embedded inside .wav files, which blend naturally with Telnyx's purpose as a voice and telecom API provider. Platform-specific payloads are delivered: Windows: A persistent binary dropped to the Startup folder as msbuild.exe Linux/macOS: A credential harvester following the same pattern as the LiteLLM compromise Forensic analysis by Aikido Security, JFrog, and SafeDep confirms the same RSA-4096 public key and tpcp.tar.gz exfiltration pattern seen in the LiteLLM compromise. Both malicious versions have been quarantined by PyPI. Recommended action: Check your Python environments and CI/CD pipelines for telnyx versions 4.87.1 or 4.87.2. If found, treat all credentials accessible to that environment as compromised and rotate immediately. The last known-safe version is 4.87.0. Also search for .wav files in unexpected locations, msbuild.exe in Windows Startup folders, and outbound connections to known TeamPCP exfiltration domains. This confirms the "expansion to additional PyPI packages" watch item from Update 001. TeamPCP's PyPI campaign is not limited to LiteLLM -- they are actively working through stolen credentials to compromise additional high-value packages. CRITICAL: TeamPCP Partners with Vect Ransomware and BreachForums for Mass Affiliate Program TeamPCP has formally partnered with the Vect ransomware-as-a-service operation and BreachForums. Per Cybernews and Infosecurity Magazine, the announcement states that all approximately 300,000 registered BreachForums users will receive personal Vect affiliate keys. The operational model: TeamPCP provides initial access via compromised supply chain packages and stolen credentials, Vect provides encryption and extortion tooling, and BreachForums provides the operator base. Analysts assess this represents a fundamental shift from supply chain credential theft to industrialized ransomware deployment. If even a small fraction of 300,000 users activate, this could become one of the largest coordinated ransomware affiliate mobilizations observed. The convergence of supply chain compromise, ransomware-as-a-service, and dark web forum mobilization at this scale is, to the best of our knowledge, unprecedented. Recommended action: Organizations that were exposed to any phase of the TeamPCP campaign (Trivy, Checkmarx, LiteLLM, Telnyx) should assume their stolen credentials may now be distributed to a large affiliate network. Credential rotation is no longer optional -- it is urgent. Monitor for Vect ransomware indicators. HIGH: LAPSUS$ Claims 3GB AstraZeneca Breach Using TeamPCP Credentials LAPSUS$ is publicly claiming a 3GB breach of AstraZeneca, as reported by SecurityWeek and CSO Online. The claimed data includes internal code repositories, cloud infrastructure configurations (AWS, Azure, Terraform), Spring Boot configs, GitHub Enterprise user information, and employee data. LAPSUS$ is selling access via Session encrypted messaging. This is the first named victim claim from the TeamPCP/LAPSUS$ partnership, confirming the "named victim breach disclosures" watch item from Update 001. AstraZeneca has not confirmed or denied the breach as of publication time. Recommended action: Organizations should not wait for public victim disclosures to take action. If you were exposed to any TeamPCP-compromised component, assume credential theft occurred and rotate proactively. The extortion timeline is accelerating. HIGH: LiteLLM CEO's Personal GitHub Account Was the Compromise Vector ReversingLabs has published new intelligence identifying the specific mechanism behind the LiteLLM PyPI compromise: TeamPCP compromised Krish Dholakia's personal GitHub account (LiteLLM co-founder and CEO) on March 23-24. This was not a generic CI/CD token sweep -- the attacker specifically identified and targeted a named executive's account from the stolen credential trove harvested during the Trivy/Checkmarx phase. This detail refines the attack chain narrative. TeamPCP appears to be triaging stolen credentials for maximum impact, targeting package maintainers with PyPI publishing privileges rather than indiscriminately using every credential they harvested. MEDIUM: CISA KEV Remediation Deadline Correction -- April 8, Not April 3 Update 001 reported the CISA KEV remediation deadline for CVE-2026-33634 as April 3, 2026. The official CISA KEV catalog entry shows the actual deadline is April 8, 2026. This update corrects the previously reported date. Additionally, Help Net Security reports that CISA simultaneously added CVE-2026-33017 (Langflow unauthenticated RCE, affecting versions prior to 1.8.2) alongside the Trivy CVE in the same KEV update. The pairing of two AI/ML infrastructure tool vulnerabilities in a single KEV addition signals that CISA is treating AI toolchain supply chain security as a systemic risk category. Federal agencies now face remediation deadlines of April 8 for CVE-2026-33634 (Trivy) and April 9 for CVE-2026-33017 (Langflow). INFO: LiteLLM's Compliance Certifications Performed by Embattled Auditor TechCrunch reported on March 26 that LiteLLM's SOC2 and ISO 27001 certifications were performed by Delve, a YC startup currently under scrutiny for allegations of "rubber-stamped" compliance audits. This intersection of two Silicon Valley scandals raises questions about the effectiveness of third-party compliance certifications in the AI/ML supply chain ecosystem. HIGH: First Responder Publishes Full Attack Transcript With New IOCs FutureSearch has published the full forensic transcript from Callum McMahon, the engineer who first discovered the compromised LiteLLM package and coordinated the PyPI quarantine on March 24. McMahon used Claude Code to perform real-time forensic analysis of the malicious litellm==1.82.8 package in an isolated Docker environment, producing what is likely the most detailed public record of this attack's execution. Key technical findings not previously documented in the campaign report: .pth file exploitation: The payload (litellm_init.pth , 34 KB) exploited Python's automatic.pth site-packages execution, triggering on every Python interpreter startup -- not just when LiteLLM was imported. This is a persistence mechanism that runs across all Python processes in the environment. C2 domain: models.litellm.cloud -- a typosquat of LiteLLM's legitimate infrastructure, used for HTTPS exfiltration with RSA encryption. Persistence path: ~/.config/sysmon/sysmon.py with systemd service registration. In McMahon's case, the write was interrupted at 0 bytes by a forced reboot. Kubernetes lateral movement: The payload attempted to create privileged alpine:latest pods and harvest service account tokens from/var/run/secrets/kubernetes.io/serviceaccount/token , usingnode-setup-* pod naming to blend with legitimate infrastructure. Multi-cloud credential sweep: A single payload targeted SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, .env files, database passwords, crypto wallets, and shell history simultaneously. Accidental fork bomb: The .pth auto-execution combined with subprocess spawning created exponential process multiplication -- each child Python process re-triggered the payload, causing resource exhaustion that inadvertently exposed the attack. The 72-minute timeline from detection to public PyPI quarantine demonstrates how AI-assisted forensic analysis dramatically accelerated incident response. This transcript is highly instructive for defenders studying the attack mechanics and should be reviewed by any team performing forensic analysis of TeamPCP-compromised environments. Recommended action: Search environments for the C2 domain models.litellm.cloud, the persistence path ~/.config/sysmon/sysmon.py, unexpected .pth files in site-packages directories, and node-setup-* pods in Kubernetes clusters. These IOCs supplement the indicators in the parent report. INFO: GitHub Announces Actions Security Roadmap in Response to Supply Chain Attacks GitHub has published a 2026 security roadmap for GitHub Actions that directly references the TeamPCP campaign. The blog post states: "incidents targeting projects like tj-actions/changed-file, Nx, and trivy-action show a clear pattern: attackers are targeting CI/CD automation itself." The roadmap introduces three categories of controls that, if implemented at the time of the Trivy compromise, would have materially altered the attack surface: Workflow dependency locking: A new dependencies: section in workflow YAML pins all direct and transitive action references to immutable commit SHAs. Hash mismatches stop execution before jobs run. This directly addresses the tag-rewriting TTP that TeamPCP used to redirect 76 trivy-action tags and all 91 ast-github-action tags to malicious commits. Public preview in 3-6 months. Policy-driven execution controls: Rulesets-based policies that restrict which actors can trigger workflows, which events are permitted, and which execution contexts can access secrets. Scoped secrets prevent a single compromised token from accessing all repository secrets. Public preview in 3-6 months. Egress firewall for hosted runners: Layer 7 network monitoring and enforcement for GitHub-hosted runners, restricting which external domains workflows can reach. This would have blocked the exfiltration to scan.aquasecurtiy[.]org andmodels.litellm.cloud . Public preview in 6-9 months. Analysts assess these controls represent the most substantive platform-level response to the GitHub Actions supply chain attack vector to date. However, the 3-9 month rollout timeline means organizations remain exposed to tag-rewriting and credential theft TTPs in the interim. Pinning actions to full commit SHAs remains the primary defensive measure until dependency locking reaches GA. Additional Intelligence Kaspersky publishes independent verification: Kaspersky published their own technical advisory characterizing this as a unified "trojanization" campaign, independently verifying the attack chain and broadening awareness to their enterprise customer base. GitGuardian draws "Shai Hulud" parallel: GitGuardian frames the campaign alongside the "Shai Hulud" attack pattern -- both targeting CI/CD pipelines to harvest secrets rather than attacking applications directly. Their analysis emphasizes that Aqua Security's non-atomic credential rotation was the root cause enabling the second compromise wave (Docker Hub images v0.69.5 and v0.69.6 on March 22). Corrections to Update 001 Aqua Security "additional findings" deadline: Update 001 stated "Aqua Security promised additional findings by end of day March 26" as a watch item. This was incorrect. On March 23, 2026, Aqua Security's blog stated they would "provide a further update, including additional findings, tomorrow end of day" -- meaning end of day March 24, not March 26. Aqua published their comprehensive incident report, "Trivy Supply Chain Attack: What Happened and What You Need to Know", on March 24 at 23:00 UTC, meeting their stated deadline. The report covers the full attack timeline, root cause (non-atomic credential rotation after the March 1 incident), and remediation details. This is no longer a watch item. CISA KEV remediation deadline: Also corrected in this update's MEDIUM finding above -- April 8, not April 3 as originally reported in Update 001. Watch Items Vect ransomware affiliate key distribution and first deployments linked to TeamPCP credentials Additional PyPI packages compromised via stolen credentials (telnyx confirms the pattern) AstraZeneca confirmation or denial of the LAPSUS$ breach claim Mandiant formal attribution report (BerriAI engagement announced, report pending) CISA standalone advisory or emergency directive (KEV entries issued, no dedicated advisory yet) Expansion to RubyGems, crates.io, or Maven Central (Endor Labs prediction, not yet confirmed) LiteLLM/BerriAI forensics completion and release resumption The full campaign report is available at sans.org/white-papers/when-security-scanner-became-weapon. A SANS Emergency Webcast replay is available at sans.org/webcasts/when-security-scanner-became-weapon. Updates to the report will be in the form of these ISC diaries.
10 shared
Mar 31, 2026
TeamPCP deploys Iran-targeted wiper in Kubernetes attacks
The TeamPCP hacking group has expanded its open source software campaign from the Trivy supply chain attack to NPM, Docker Hub, VS Code, and PyPI, and likely partnered with the Lapsus$ gang for monetization purposes. The attack on Aqua Security’s widely used Trivy vulnerability scanner started with the compromise of an access token in late February. Because the maintainers did not rotate all credentials and secrets simultaneously, the hackers were able to maintain access to the compromised environment. OpenSourceMalware reports with high confidence that the attackers compromised the Argon-DevOps-Mgt service account token, which provided them with write/admin access to both Aqua Security’s internal and public-facing repositories. The attack has been attributed to TeamPCP (also known as DeadCatx3, PCPcat, and ShellForce), which was behind a December worm-driven campaign that targeted Docker, Kubernetes, Ray, and Redis, and which also exploited the React2Shell vulnerability, according to Flare. In the Trivy supply chain attack, now tracked as CVE-2026-33634 (CVSS score of 9.4), the hackers released malicious package versions and modified GitHub Actions tags to push information-stealing malware that would harvest credentials, keys, tokens, and other sensitive data. In early March, a similar attack hit Xygeni: compromised credentials linked to repository automation were used to introduce malicious code. Initially, the attackers relied on pull requests, but when that failed, they modified a mutable tag to reference a malicious commit, leading to downstream infections. “While the attack leveraged a known GitHub Actions vulnerability involving mutable tags, the incident also highlights the importance of comprehensive repository protection, strict credential management, and defense-in-depth across CI/CD systems,” Xygeni notes in its incident report. The Trivy attack and blast radius TeamPCP started pushing malware to the Trivy repositories on March 19, but the multi-stage supply chain attack has been contained and is now in the remediation and documentation phase, Aqua said on Wednesday. However, it took five days to fully evict the attackers. Three days after the containment and remediation efforts started, the attackers published malicious Trivy Docker Hub images (v0.69.5 and v0.69.6), confirming that their access had not been blocked, Trivy’s maintainers revealed. “Working closely with Sygnia, we are developing formal documentation that includes the confirmed timeline, actions taken to remediate the incident, and supporting materials for customer assurance and attestation. This effort is informed by a comprehensive review of credentials, access controls, and affected systems,” Aqua says. What made the attack stand out was the use of modified GitHub Action tags to reference malware without any visible changes to the tag name, published dates, or the release page, allowing the attackers to operate under the radar. According to a SANS Institute report seen by SecurityWeek, more than 10,000 CI/CD workflows were affected by the Trivy incident. Every CI/CD pipeline referencing the modified GitHub Actions automatically executed the malicious code, dropping TeamPCP’s information stealer and exposing secrets, credentials, and infrastructure. To evade detection on the infected systems, malicious code contains instructions to remove all its temporary files after performing its multi-stage credential theft and exfiltration operation, CrowdStrike explains. “The remainder of the script is a functional copy of the real trivy-action entry point. It downloads and runs Trivy normally, producing expected scanner output. To an operator reviewing workflow logs, the step appears to have completed successfully,” the cybersecurity company notes. The Checkmarx attack On March 23, TeamPCP hit Checkmarx’s KICS open-source project, publishing malicious versions of the checkmarx.cx-dev-assist and checkmarx.ast-results VS Code plugins to the OpenVSX marketplace. Like the Trivy attack, the hackers injected malicious payloads into the plugins by force-pushing tags that were pointing to malicious commits. A total of 35 GitHub Action version tags were hijacked, SANS Institute says. Checkmarx has since updated GitHub Actions to ast-github-action v2.3.33 and kics-github-action v2.1.20 and permanently removed all previous versions from its repositories. The malicious plugin iterations, namely ast-results 2.53.0 and cx-dev-assist 1.7.0, should be immediately removed. “Upon discovery, we removed the malicious artifacts, pinned our workflows to safe verified commit SHAs, revoked and rotated all exposed credentials, blocked outbound access to the attacker-controlled domain, and reviewed our environments for any signs of further compromise,” Checkmarx says. The cybersecurity firm warns all organizations that downloaded or ran a compromised version of the two plugins from Open VSX to rotate all secrets and environment variables. GitHub credentials, Personal Access Tokens (PATs), repository and organization secrets, SSH keys, Docker registry credentials, Kubernetes service account tokens, and GitHub, Microsoft Azure, Google Cloud (GCP), and AWS access tokens should be considered compromised and immediately rotated. As ReversingLabs points out, the two VS Code extensions have a combined download count of over 36,000 and are designed for use within VS Code and compatible integrated development environments (IDEs), such as Cursor, Kiro, and Windsurf, making the attack’s blast radius large. CanisterWorm and the NPM attacks Last week, TeamPCP’s campaign also targeted the NPM ecosystem, using read/write access tokens to push malware downstream and using the same infostealer from the Trivy attack. The NPM supply chain attack hit at least 64 unique packages and affected more than 140 package artifacts, injecting install-time malware that relies on an Internet Computer Protocol (ICP) canister dead drop to deliver follow-on binaries. Dubbed CanisterWorm, the final payload contains a component that uses compromised NPM publishing credentials to inject the payload into additional packages. To evade detection, it preserves the legitimate README files, Socket explains. As the attack unfolded, the hackers were seen updating their code, moving from using a postinstall hook to write a Python payload, install it as a systemd –user service, and execute it, to using a hardcoded Python dropper and using the service name pgmon for persistence. According to Aikido, the malware was initially similar to the one used in the Trivy attack, but was later updated with the worm component that allowed it to use harvested NPM tokens and environment variables and spawn a persistent background process using them, to infect additional packages. “Every developer or CI pipeline that installs this package and has an NPM token accessible becomes an unwitting propagation vector. Their packages get infected, their downstream users install those, and if any of them have tokens, the cycle repeats,” Aikido notes. The Kubernetes wiper targeting Iran The same ICP canister used in the CanisterWorm attack on NPM was also used in a campaign targeting Kubernetes. The main difference was that the code included a wiper aimed at Iran-based clusters. The payload contains standard Kubernetes pod detection, deploys privileged DaemonSets across every node, and drops the CanisterWorm backdoor on them as a systemd service, achieving persistence as PostgreSQL tooling. In more recent iterations of the attack, the malware added network-based lateral movement, using SSH via compromised keys and auth log parsing, and exploiting exposed Docker APIs, Aikido reports. The code also checks the system timezone and locale and, if it detects machines configured for Iran, drops a DaemonSet to wipe the entire cluster. Dubbed “kamikaze”, the wiper mounts the host’s root filesystem, erases the top-level content, and then forces a reboot. The operation is performed on all nodes, including the control plane, destroying the entire cluster. “The Kubernetes-native lateral movement via DaemonSets is consistent with TeamPCP’s known playbook, but this variant adds something we haven’t seen from them before: a geopolitically targeted destructive payload aimed specifically at Iranian systems,” Aikido notes. On non-Kubernetes systems configured for Iran, if root access is available, the malware wipes everything. If it does not have root access, it “tries passwordless sudo, then tries anyway. Even without root, it’ll destroy everything the user owns,” Aikido notes. The PyPI attack and LiteLLM compromise In its most recent phase, TeamPCP’s campaign moved to the PyPI ecosystem, compromising LiteLLM, an open source Python library and proxy server that has more than 95 million monthly downloads. LiteLLM versions 1.82.7 and 1.82.8 were injected with the same information-stealing and dropper malware observed in the other TeamPCP attacks, with the same goal: the compromise of valuable credentials for broad access. The malicious code in LiteLLM 1.82.8 “fires on every Python invocation in the environment” and “runs silently in the background without delaying Python startup,” EndorLabs explains. Used as a unified interface between applications and AI service providers such as Anthropic, Google, and OpenAI, LiteLLM supports over 100 LLM APIs and typically has access to sensitive information such as API keys and environment variables. “Additionally, the breadth of data targeted by the malware underscores how modern development environments — spanning local machines, CI/CD pipelines, and cloud infrastructure — are deeply interconnected. A single compromised dependency can expose credentials across multiple systems, dramatically increasing the potential blast radius,” Sonatype notes. LiteLLM compromise has provided the attackers with access to all the secrets the library touches, and the impact from the attack is broad: approximately 300GB of data was exfiltrated from around 500,000 infected machines, threat intelligence and research project Vx-Underground says. ReversingLabs says that the hackers likely compromised the GitHub account of LiteLLM co-founder and CEO Krish Dholakia on March 23 and then defaced the LiteLLM GitHub repositories in an automated manner the next day. Organizations that installed or executed the malicious LiteLLM versions should immediately remove the packages, rotate all credentials, and investigate the affected systems for suspicious connections, persistence mechanisms, and potentially affected packages. According to cybersecurity outfit Wiz, LiteLLM is present in 36% of all cloud environments, providing hackers with a foothold in highly sensitive parts of the development lifecycle. “In many cases, rebuilding affected systems from a known clean state may be the safest course of action,” Sonatype notes. The Lapsus$ connection In addition to expanding across multiple OSS communities, TeamPCP’s campaign has escalated to a monetization phase. The group is openly taking credit for the attacks and appears to have partnered with the Lapsus$ extortion group for financial gain. TeamPCP has boasted on its Telegram account about the Trivy compromise, the GitHub Actions attacks, the OpenVSX extensions incident, and the PyPI hack, stating a clear focus on security tools and high-leverage points within the OSS ecosystem. The group also claims its operation is still unfolding, saying that it will be “stealing terabytes of trade secrets with our new partners”, Socket reports. While the ‘partners’ were not named, it appears that the hacking group was hinting at Lapsus$, which boasted on its Telegram account about an upcoming supply chain attack from TeamPCP. According to Wiz, this explicit collaboration between the two threat actors is an ecosystem-wide ‘cascade’ aimed at the modern cloud-native and AI ecosystems. “We are seeing a dangerous convergence between supply chain attackers and high-profile extortion groups like Lapsus$,” Wiz lead researcher Ben Read told SecurityWeek. “By moving horizontally across the ecosystem – hitting tools like LiteLLM that are present in over a third of cloud environments – they are creating a ‘snowball effect.’ This isn’t an isolated incident; it’s a systemic campaign that requires security teams to take action and will likely continue to expand,” Read added. The partnership between the two groups also appears to explain why some security researchers linked the AstraZeneca data breach to TeamPCP’s campaign, while Lapsus$ has claimed responsibility for it. Related: Polyfill Supply Chain Attack Impacting 100k Sites Linked to North Korea Related: New ‘Sandworm_Mode’ Supply Chain Attack Hits NPM Related: Autonomous AI Agents Provide New Class of Supply Chain Attack Related: ‘PackageGate’ Flaws Open JavaScript Ecosystem to Supply Chain Attacks
9 shared
Mar 25, 2026
Analyzing Sharepoint Exploits (CVE-2025-53770, CVE-2025-53771), (Wed, Jul 23rd)
On July 19–20, 2025, various security companies and national CERTs published alerts about active exploitation of on-premise SharePoint servers. According to the reports, observed attacks did not require authentication, allowed attackers to gain full control over the infected servers, and were performed using an exploit chain of two vulnerabilities: CVE-2025-49704 and CVE-2025-49706, publicly named “ToolShell”. Additionally, on the same dates, Microsoft released out-of-band security patches for the vulnerabilities CVE-2025-53770 and CVE-2025-53771, aimed at addressing the security bypasses of previously issued fixes for CVE-2025-49704 and CVE-2025-49706. The release of the new, “proper” updates has caused confusion about exactly which vulnerabilities attackers are exploiting and whether they are using zero-day exploits. Kaspersky products proactively detected and blocked malicious activity linked to these attacks, which allowed us to gather statistics about the timeframe and spread of this campaign. Our statistics show that widespread exploitation started on July 18, 2025, and attackers targeted servers across the world in Egypt, Jordan, Russia, Vietnam, and Zambia. Entities across multiple sectors were affected: government, finance, manufacturing, forestry, and agriculture. While analyzing all artifacts related to these attacks, which were detected by our products and public information provided by external researchers, we found a dump of a POST request that was claimed to contain the malicious payload used in these attacks. After performing our own analysis, we were able to confirm that this dump indeed contained the malicious payload detected by our technologies, and that sending this single request to an affected SharePoint installation was enough to execute the malicious payload there. Our analysis of the exploit showed that it did rely on vulnerabilities fixed under CVE-2025-49704 and CVE-2025-49706, but by changing just one byte in the request, we were able to bypass those fixes. In this post, we provide detailed information about CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771, and one related vulnerability. Since the exploit code is already published online, is very easy to use, and poses a significant risk, we encourage all organizations to install the necessary updates. The exploit Our research started with an analysis of a POST request dump associated with this wave of attacks on SharePoint servers. We can see that this POST request targets the “/_layouts/15/ToolPane.aspx” endpoint and embeds two parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. Looking at the code of ToolPane.aspx, we can see that this file itself does not contain much functionality and most of its code is located in the ToolPane class of the Microsoft.SharePoint.WebPartPages namespace in Microsoft.SharePoint.dll. Looking at this class reveals the code that works with the two parameters present in the exploit. However, accessing this endpoint under normal conditions is not possible without bypassing authentication on the attacked SharePoint server. This is where the first Microsoft SharePoint Server Spoofing Vulnerability CVE-2025-49706 comes into play. CVE-2025-49706 This vulnerability is present in the method PostAuthenticateRequestHandler, in Microsoft.SharePoint.dll. SharePoint requires Internet Information Services (IIS) to be configured in integrated mode. In this mode, the IIS and ASP.NET authentication stages are unified. As a result, the outcome of IIS authentication is not determined until the PostAuthenticateRequest stage, at which point both the ASP.NET and IIS authentication methods have been completed. Therefore, the PostAuthenticateRequestHandler method utilizes a series of flags to track potential authentication violations. A logic bug in this method enables an authentication bypass if the “Referrer” header of the HTTP request is equal to “/_layouts/SignOut.aspx”, “/_layouts/14/SignOut.aspx”, or “/_layouts/15/SignOut.aspx” using case insensitive comparison. The code displayed in the image above handles the sign-out request and is also triggered when the sign-out page is specified as the referrer. When flag6 is set to false and flag7 is set to true, both conditional branches that could potentially throw an “Unauthorized Access” exception are bypassed. On July 8, 2025, Microsoft released an update that addressed this vulnerability by introducing additional checks to detect the usage of the “ToolPane.aspx” endpoint with the sign-out page specified as the referrer. The added check uses case insensitive comparison to verify if the requested path ends with “ToolPane.aspx”. Is it possible to bypass this check, say, by using a different endpoint? Our testing has shown that this check can be easily bypassed. CVE-2025-53771 We were able to successfully bypass the patch for vulnerability CVE-2025-49706 by adding just one byte to the exploit POST request. All that was required to bypass this patch was to add a “/” (slash) to the end of the requested “ToolPane.aspx” path. On July 20, 2025, Microsoft released an update that fixed this bypass as CVE-2025-53771. This fix replaces the “ToolPane.aspx” check to instead check whether the requested path is in the list of paths allowed for use with the sign-out page specified as the referrer. This allowlist includes the following paths: “/_layouts/15/SignOut.aspx”, “/_layouts/15/1033/initstrings.js”, “/_layouts/15/init.js”, “/_layouts/15/theming.js”, “/ScriptResource.axd”, “/_layouts/15/blank.js”, “/ScriptResource.axd”, “/WebResource.axd”, “/_layouts/15/1033/styles/corev15.css”, “/_layouts/15/1033/styles/error.css”, “/_layouts/15/images/favicon.ico”, “/_layouts/15/1033/strings.js”, “/_layouts/15/core.js”, and it can contain additional paths added by the administrator. While testing the CVE-2025-49706 bypass with the July 8, 2025 updates installed on our SharePoint debugging stand, we noticed some strange behavior. Not only did the bypass of CVE-2025-49706 work, but the entire exploit chain did! But wait! Didn’t the attackers use an additional Microsoft SharePoint Remote Code Execution Vulnerability CVE-2025-49704, which was supposed to be fixed in the same update? To understand why the entire exploit chain worked in our case, let’s take a look at the vulnerability CVE-2025-49704 and how it was fixed. CVE-2025-49704 CVE-2025-49704 is an untrusted data deserialization vulnerability that exists due to improper validation of XML content. Looking at the exploit POST request, we can see that it contains two URL encoded parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. We can see how they are handled by examining the code of the method GetPartPreviewAndPropertiesFromMarkup in Microsoft.SharePoint.dll. A quick analysis reveals that “MSOtlPn_Uri” is a page URL that might be pointing to an any file in the CONTROLTEMPLATES folder and the parameter “MSOtlPn_DWP” contains something known as WebPart markup. This markup contains special directives that can be used to execute safe controls on a server and has a format very similar to XML. While this “XML” included in the “MSOtlPn_DWP” parameter does not itself contain a vulnerability, it allows attackers to instantiate the ExcelDataSet control from Microsoft.PerformancePoint.Scorecards.Client.dll with CompressedDataTable property set to malicious payload and trigger its processing using DataTable property getter. Looking at the code of the ExcelDataSet’s DataTable property getter in Microsoft.PerformancePoint.Scorecards.Client.dll, we find the method GetObjectFromCompressedBase64String, responsible for deserialization of CompressedDataTable property contents. The data provided as Base64 string is decoded, unzipped, and passed to the BinarySerialization.Deserialize method from Microsoft.SharePoint.dll. Attackers use this method to provide a malicious DataSet whose deserialized content is shown in the image above. It contains an XML with an element of dangerous type "System.Collections.Generic.List1[[System.Data.Services.Internal.ExpandedWrapper2[...], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]", which allows attackers to execute arbitrary methods with the help of the well-known ExpandedWrapper technique aimed at exploitation of unsafe XML deserialization in applications based on the .NET framework. In fact, this shouldn’t be possible, since BinarySerialization.Deserialize in Microsoft.SharePoint.dll uses a special XmlValidator designed to protect against this technique by checking the types of all elements present in the provided XML and ensuring that they are on the list of allowed types. However, the exploit bypasses this check by placing the ExpandedWrapper object into the list. Now, to find out why the exploit worked on our SharePoint debugging stand with the July 8, 2025 updates installed, let’s take a look at how this vulnerability was fixed. In this patch, Microsoft did not really fix the vulnerability but only mitigated it by adding the new AddExcelDataSetToSafeControls class to the Microsoft.SharePoint.Upgrade namespace. This class contains new code that modifies the web.config file and marks the Microsoft.PerformancePoint.Scorecards.ExcelDataSet control as unsafe. Because SharePoint does not execute this code on its own after installing updates, the only way to achieve the security effect was to manually run a configuration upgrade using the SharePoint Products Configuration Wizard tool. Notably, the security guidance for CVE-2025-49704 does not mention the need for this step, which means at least some SharePoint administrators may skip it. Meanwhile, anyone who installed this update but did not manually perform a configuration upgrade remained vulnerable. CVE-2025-53770 On July 20, 2025, Microsoft released an update with a proper fix for the CVE-2025-49704 vulnerability. This patch introduces an updated XmlValidator that now properly validates element types in XML, preventing exploitation of this vulnerability without requiring a configuration upgrade and, more importantly, addressing the root cause and preventing exploitation of the same vulnerability through controls other than Microsoft.PerformancePoint.Scorecards.ExcelDataSet. CVE-2020-1147 Readers familiar with previous SharePoint exploits might feel that the vulnerability CVE-2025-49704/CVE-2025-53770 and the exploit used by the attackers looks very familiar and very similar to the older .NET Framework, SharePoint Server, and Visual Studio Remote Code Execution Vulnerability CVE-2020-1147. In fact, if we compare the exploit for CVE-2020-1147 and an exploit for CVE-2025-49704/CVE-2025-53770, we can see that they are almost identical. The only difference is that in the exploit for CVE-2025-49704/CVE-2025-53770, the dangerous ExpandedWrapper object is placed in the list. This makes CVE-2025-53770 an updated fix for CVE-2020-1147. Conclusions Despite the fact that patches for the ToolShell vulnerabilities are now available for deployment, we assess that this chain of exploits will continue being used by attackers for a long time. We have been observing the same situation with other notorious vulnerabilities, such as ProxyLogon, PrintNightmare, or EternalBlue. While they have been known for years, many threat actors still continue leveraging them in their attacks to compromise unpatched systems. We expect the ToolShell vulnerabilities to follow the same fate, as they can be exploited with extremely low effort and allow full control over the vulnerable server. To stay better protected against threats like ToolShell, we as a community should learn lessons from previous events in the industry related to critical vulnerabilities. Specifically, the speed of applying security patches nowadays is the most important factor when it comes to fighting such vulnerabilities. Since public exploits for these dangerous vulnerabilities appear very soon after vulnerability announcements, it is paramount to install patches as soon as possible, as a gap of even a few hours can make a critical difference. At the same time, it is important to protect enterprise networks against zero-day exploits, which can be leveraged when there is no available public patch for vulnerabilities. In this regard, it is critical to equip machines with reliable cybersecurity solutions that have proven effective in combatting ToolShell attacks before they were publicly disclosed. Kaspersky Next with its Behaviour detection component proactively protects against exploitation of these vulnerabilities. Additionally, it is able to detect exploitation and the subsequent malicious activity. Kaspersky products detect the exploits and malware used in these attacks with the following verdicts: UDS:DangerousObject.Multi.Generic PDM:Exploit.Win32.Generic PDM:Trojan.Win32.Generic HEUR:Trojan.MSIL.Agent.gen ASP.Agent.* PowerShell.Agent.*
7 shared
Jul 28, 2025
Microsoft releases emergency .NET patches for critical Brotli flaw
A vulnerability in Google’s Brotli data compression library, tracked as CVE-2026-111497 and dubbed Node2Shell, has led to security updates from Microsoft, the Node.js project and the maintainers of two Python packages. Node.js and the Python packages were patched last week, and Microsoft followed on October 25 with fixes for .NET, Visual Studio and PowerShell. Bun, Envoy and Istio have also been updated. Brotli is a popular choice for compressing data sent over the web, and its decoder is embedded in a long list of applications and libraries. Described as an out-of-bounds write, the bug impacts Brotli 1.0.3 through 1.2.0. Google gave it a CVSS v4 score of 9.2, which puts it in the critical category. Brotli versions 1.0.10, 1.1.1 and 1.2.1 contain the fix. The Node.js project said specially crafted input can push data beyond the limits of a buffer used by the decoder. The resulting memory corruption could cause the process to crash or leak memory contents, and could also allow an unauthenticated attacker to run arbitrary code. Node.js credited the discovery to members of OpenAI Codex Security. According to OpenAI, the issue was uncovered during red-teaming work, after which the company notified the Brotli developers and the projects that rely on the library. OpenAI noted that the fix predates the disclosure. “This root cause issue was actually fixed in the Brotli source code in February, but it wasn’t known at the time that it gave rise to a security vulnerability and there was no more recent release of Brotli,” the AI company said. Code execution demonstrated on official Node.js image Imperva has shown that it can be exploited for code execution on the official Node.js 24.22.0 image for Linux arm64. Its researchers sent the malicious data both in a server response retrieved by the targeted application and in a request body processed by Express 5 or body-parser 2. “The proof did not succeed on every attempt. Our results establish code execution for the tested Linux arm64 build and application setups, and show how the fixed build handled the same inputs,” Imperva said. The security firm has not made its exploit public. Attacks only work if malicious Brotli data reaches the decoder, for instance through a library that unpacks compressed content on the application’s behalf. “Any application that passes attacker-controlled data to an affected Google Brotli decoder may be exposed. This includes compressed HTTP request bodies, responses fetched from untrusted servers, and compressed files,” OpenAI’s Patch the Planet initiative said in its advisory. No exploitation in the wild has been reported so far. A proof-of-concept exploit published on GitHub reportedly achieves code execution only against an intentionally weakened build, and some researchers argued the bug can only be used for denial-of-service (DoS) attacks. Microsoft products and Python packages affected Microsoft’s October 25 updates include .NET runtime versions 8.0.33, 9.0.22 and 10.0.14, along with .NET 11 Release Candidate 3. Visual Studio 2019, 2022 and 2026, as well as PowerShell 7.4, 7.5 and 7.6, have also been updated. Microsoft has categorized CVE-2026-111497 as an elevation of privilege issue with a CVSS v3.1 base score of 8.1. It rates the flaw critical for .NET and Visual Studio and important for PowerShell, and its exploitability assessment is “Exploitation More Likely.” In Python’s case, the vulnerable decoder is built into two PyPI packages, Brotli and brotlicffi. They have been patched with the release of versions 1.2.1 and 1.2.1.0, respectively. As more affected software emerged, researchers began referring to the flaw as HTTP2Shell and Broccoli2Shell. A public tracker of software that bundles its own copy of the Brotli decoder lists several projects that are still unpatched, including DuckDB, Apache Arrow, 7-Zip-zstd, p7zip and EDK II. Its maintainers say the list is incomplete, and that not every configuration of these projects necessarily exposes the vulnerable code. Applying the updates also requires restarting affected services and rebuilding container images on top of a patched base, since processes that are already running keep using the vulnerable code. Related: Mirai Botnet Operators Join PHP2Shell Attacks as ASLR Bypass Exploits Emerge Related: Attackers Exploit Third Arista VCO Zero-Day in Four Months Related: LiteLLM Compromised in Fresh Supply Chain Attack
7 shared
Oct 29, 2026
Hackers Infect 953 Online Stores With Scanner-Evading Code
Attackers have infected 953 online stores, mostly running Magento, with a JavaScript loader that has evolved to tell security scanners apart from real shoppers. The campaign has been active since July 2025 and has cycled through five loader domains, according to research from Dutch e-commerce security firm Sansec. Its latest domain, registered October 6, was found in the content management system (CMS) blocks of 83 stores, 60 of which had carried an earlier version of the loader. The loader is stored in Magento's cms_block database table and has visitors' browsers fetch instructions from the attackers. Sansec said the server first works out whether a request comes from a genuine customer or a security scanner, and gives scanners nothing. Latest Loader Filters Security Scanners Before October, the operator relied on the Keitaro traffic distribution system to choose, for each visitor, between delivering a payload, redirecting the browser and returning nothing. The loader Sansec first found on October 7 instead called the new domain directly and replayed code saved in the browser, so anyone served the payload would rerun it on later page loads, even with the domain down or blocked. An October 23 rewrite added browser fingerprinting, checking for signs of browser automation and collecting hardware details, screen size, time zone and language before the server chose its response. When scanning service urlscan.io loaded an infected store in an automated browser, Sansec found no injected content. The company has yet to obtain the final payload, so the campaign's ultimate purpose remains unclear. Patches Did Not Always Stop Reinfection Sansec said a March wave planted the loader on 471 stores within an hour, using webshells placed through PolyShell (CVE-2026-48356). Among 169 infected Magento 2 installations lacking at least one core patch, 102 showed evidence of file uploads via PolyShell or SessionReaper (CVE-2025-54236). Patching alone did not prevent reinfection. A fully patched store running Magento 2.4.7-p10 picked up the newest loader on October 23, an hour after passing a clean scan. Sansec had spotted a rogue admin account and a GSocket backdoor on the store in September. Sansec advised merchants to look for the loader in CMS content, review admin accounts and hunt for backdoors, rotate database, admin and integration credentials once the store is clean and apply the latest Magento and Adobe Commerce security updates. It warned that removing the script leaves an attacker's write access to the database intact, so a compromised store can be reinfected while the original way in remains.
7 shared
Oct 30, 2026