Search/US Government Warns of Wide-Ranging Interlock Attacks
● Story

US Government Warns of Wide-Ranging Interlock Attacks

The US government has warned businesses and critical infrastructure organizations to stay vigilant against wide-ranging attacks from the Interlock ransomware gang. The joint advisory from four government agencies including the FBI and the Department of Health and Human Services (HHS), highlighted the novel initial access techniques used by the cybercrime group. This includes “drive-by-download” and ClickFix social engineering techniques. The group, first identified in late September 2024, has been observed targeting various business, critical infrastructure and other organizations in North America and Europe. High-profile incidents attributed to Interlock in 2025 include Kettering Health, a major healthcare provider in western Ohio, US, and Scottish local authority West Lothian council.…

View graph Export
CVEs
0
Highest CVSS
—
In KEV
0
Sources
5
Connections
22 relationships
Hijacking Discord invite links to install malware | Kaspersky official blog
Attackers are using expired and deleted Discord invite links to distribute two strains of malware: AsyncRAT for taking remote control of infected computers, and Skuld Stealer for stealing crypto wallet data. They do this by exploiting a vulnerability in Discord’s invite link system to stealthily redirect users from trusted sources to malicious servers. The attack leverages the ClickFix technique, multi-stage loaders and deferred execution to bypass defenses and deliver malware undetected. This post examines in detail how attackers exploit the invite link system, what is ClickFix and why they use it, and, most importantly, how not to fall victim to this scheme. How Discord invite links work First, let’s look at how Discord invite links work and how they differ from each other. By doing so, we’ll gain an insight into how the attackers learned to exploit the link creation system in Discord. Discord invite links are special URLs that users can use to join servers. They are created by administrators to simplify access to communities without having to add members manually. Invite links in Discord can take two alternative formats: https://discord.gg/{invite_code} https://discord.com/invite/{invite_code} Having more than one format, with one that uses a “meme” domain, is not the best solution from a security viewpoint, as it sows confusion in the users’ minds. But that’s not all. Discord invite links also have three main types, which differ significantly from each other in terms of properties: Temporary invite links Permanent invite links Custom invite links (vanity URLs) Links of the first type are what Discord creates by default. Moreover, in the Discord app, the server administrator has a choice of fixed invite expiration times: 30 minutes, 1 hour, 6 hours, 12 hours, 1 day or 7 days (the default option). For links created through the Discord API, a custom expiration time can be set — any value up to 7 days. Codes for temporary invite links are randomly generated and usually contain 7 or 8 characters, including uppercase and lowercase letters, as well as numbers. Examples of a temporary link: https://discord.gg/a7X9pLd https://discord.gg/Fq5zW2cn To create a permanent invite link, the server administrator must manually select Never in the Expire After field. Permanent invite codes consist of 10 random characters — uppercase and lowercase letters, and numbers, as before. Example of a permanent link: https://discord.gg/hT9aR2kLmB Lastly, custom invite links (vanity links) are available only to Discord Level 3 servers. To reach this level, a server must get 14 boosts, which are paid upgrades that community members can buy to unlock special perks. That’s why popular communities with an active audience — servers of bloggers, streamers, gaming clans or public projects — usually attain Level 3. Custom invite links allow administrators to set their own invite code, which must be unique among all servers. The code can contain lowercase letters, numbers and hyphens, and can be almost arbitrary in length — from 2 to 32 characters. A server can have only one custom link at any given time. Such links are always permanent — they do not expire as long as the server maintains Level 3 perks. If the server loses this level, its vanity link becomes available for reuse by another server with the required level. Examples of a custom invite link: https://discord.gg/alanna-titterington https://discord.gg/best-discord-server-ever https://discord.gg/fq5zw2cn From this last example, attentive readers may guess where we’re heading. How scammers exploit the invite system Now that we’ve looked at the different types of Discord invite links, let’s see how malicious actors weaponize the mechanism. Note that when a regular, non-custom invite link expires or is deleted, the administrator of a legitimate server cannot get the same code again, since all codes are generated randomly. But when creating a custom invite link, the server owner can manually enter any available code, including one that matches the code of a previously expired or deleted link. It is this quirk of the invite system that attackers exploit: they track legitimate expiring codes, then register them as custom links on their servers with Level 3 perks. As a result, scammers can use: Any expired temporary invite links (even if the expired link has capital letters and the scammers’ custom URL replaces them with lowercase, the system automatically redirects the user to this vanity URL) Permanent invite links deleted from servers, if the code consisted solely of lowercase letters and numbers (no redirection here) Custom invite links, if the original server has lost Level 3 perks and its link is available for re-registration What does this substitution lead to? Attackers get the ability to direct users who follow links previously posted on wholly legitimate resources (social networks, websites, blogs and forums of various communities) to their own malicious servers on Discord. What’s more, the legal owners of these resources may not even realize that the old invite links now point to fake Discord servers set up to distribute malware. This means they can’t even warn users that a link is dangerous, or delete messages in which it appears. How ClickFix works in Discord-based attacks Now let’s talk about what happens to users who follow hijacked invite links received from trusted sources. After joining the attackers’ Discord server, the user sees that all channels are unavailable to them except one, called verify. This channel features a bot named Safeguard that offers full access to the server. To get this, the user must click the Verify button, which is followed by a prompt to authorize the bot. After authorization, the bot gains access to profile information (username, avatar, banner), and the user is redirected to an external site: https://captchaguard[.]me. Next, the user goes through a chain of redirects and ends up on a well-designed web page that mimics the Discord interface, with a Verify button in the center. Clicking the Verify button activates JavaScript code that copies a malicious PowerShell command to the clipboard. The user is then given precise instructions on how to “pass the check”: open the Run window (Win + R), paste the clipboarded text (Ctrl + V), and click Enter. The site does not ask the user to download or run any files manually, thereby removing the typical warning signs. Instead, users essentially infect themselves by running a malicious PowerShell command that the site slips onto the clipboard. All these steps are part of an infection tactic called ClickFix, which we’ve already covered in depth on our blog. AsyncRAT and Skuld Stealer malware The user-activated PowerShell script is the first step in the multi-stage delivery of the malicious payload. The attackers’ next goal is to install two malicious programs on the victim’s device — let’s take a closer look at each of them. First, the attackers download a modified version of AsyncRAT to gain remote control over the infected system. This tool provides a wide range of capabilities: executing commands and scripts, intercepting keystrokes, viewing the screen, managing files, and accessing the remote desktop and camera. Next, the cybercriminals install Skuld Stealer on the victim’s device. This crypto stealer harvests system information, siphons off Discord login credentials and authentication tokens saved in the browser, and, crucially, steals seed phrases and passwords for Exodus and Atomic crypto wallets by injecting malicious code directly into their interface. Skuld sends all collected data via a Discord webhook — a one-way HTTP channel that allows applications to automatically send messages to Discord channels. This provides a secure way for stealing information directly in Discord without the need for a sophisticated management infrastructure. As a result, all data — from passwords and authentication tokens to crypto wallet seed phrases — is automatically published in a private channel set up in advance on the attackers’ Discord server. Armed with the seed phrases, the attackers can recover all the private keys of the hijacked wallets and gain full control over all cryptocurrency assets of their victims. How to avoid falling victim? Unfortunately, Discord’s invite system lacks transparency and clarity. And this makes it extremely difficult, especially for newbies, to spot the trick before clicking a hijacked link and during the redirection process. Nevertheless, there are some security measures that, if done properly, should fend off the worst outcome — a malware-infected computer and financial losses: Never paste code into the Run window if you don’t know exactly what it does. Doing this is extremely dangerous, and normal sites will never give such an instruction. Configure Discord privacy and security by following our detailed guide. This will not guard against hijacked invite links, but will minimize other risks associated with Discord. Use a reliable security solution that gives advance warning of danger and prevents the download of malware. It’s best to install it on all devices, but especially on ones where you use crypto wallets and other financial software. Malicious actors often target Discord to steal cryptocurrency, game accounts and assets, and generally cause misery for users. Check out our posts for more examples of Discord scams:
kaspersky.comJul 25, 2025extracted
CastleLoader Malware Infects 469 Devices Using Fake GitHub Repos and ClickFix Phishing
Cybersecurity researchers have shed light on a new versatile malware loader called CastleLoader that has been put to use in campaigns distributing various information stealers and remote access trojans (RATs). The activity employs Cloudflare-themed ClickFix phishing attacks and fake GitHub repositories opened under the names of legitimate applications, Swiss cybersecurity company PRODAFT said in a report shared with The Hacker News. The malware loader, first observed in the wild earlier this year, has been used to distribute DeerStealer, RedLine, StealC, NetSupport RAT, SectopRAT, and even other loaders like Hijack Loader. "It employs dead code injection and packing techniques to hinder analysis," the company said. "After unpacking itself at runtime, it connects to a C2 (command-and-control) server, downloads target modules, and executes them." CastleLoader’s modular structure allows it to act as both a delivery mechanism and a staging utility, enabling threat actors to separate initial infection from payload deployment. This separation complicates attribution and response because it decouples the infection vector from the eventual malware behavior, giving attackers more flexibility in adapting campaigns over time. CastleLoader payloads are distributed as portable executables containing an embedded shellcode, which then invokes the main module of the loader that, in turn, connects to the C2 server in order to fetch and execute the next-stage malware. Attacks distributing the malware have relied on the prevalent ClickFix technique on domains posing as software development libraries, videoconferencing platforms, browser update notifications, or document verification systems, ultimately tricking users into copying and executing PowerShell commands that activate the infection chain. Victims are directed to the bogus domains through Google searches, at which point they are served pages containing fake error messages and CAPTCHA verification boxes developed by the threat actors, asking them to carry out a series of instructions to supposedly address the issue. Alternatively, CastleLoader leverages fake GitHub repositories mimicking legitimate tools as a distribution vector, causing users who unknowingly download them to compromise their machines with malware instead. "This technique exploits developers' trust in GitHub and their tendency to run installation commands from repositories that appear reputable," PRODAFT said. This strategic abuse of social engineering mirrors techniques used in initial access brokers (IABs), underscoring its role within a broader cybercrime supply chain. PRODAFT said it has observed Hijack Loader being delivered via DeerStealer as well as CastleLoader, with the latter also propagating DeerStealer variants. This suggests the overlapping nature of these campaigns, despite them being orchestrated by different threat actors. Since May 2025, CastleLoader campaigns have leveraged seven distinct C2 servers, with over 1,634 infection attempts recorded during the time period. Analysis of its C2 infrastructure and its web-based panel—which is used to oversee and manage the infections – shows that as many as 469 devices were compromised, resulting in an infection rate of 28.7%. Researchers also observed elements of anti-sandboxing and obfuscation—features typical in advanced loaders like SmokeLoader or IceID. Combined with PowerShell abuse, GitHub impersonation, and dynamic unpacking, CastleLoader reflects a growing trend in stealth-first malware loaders that operate as stagers in malware-as-a-service (MaaS) ecosystems. "CastleLoader is a new and active threat, rapidly adopted by various malicious campaigns to deploy an array of other loaders and stealers," PRODAFT said. "Its sophisticated anti-analysis techniques and multi-stage infection process highlight its effectiveness as a primary distribution mechanism in the current threat landscape." "The C2 panel demonstrates operational capabilities typically associated with malware-as-a-service (MaaS) offerings, suggesting the operators have experience in cybercriminal infrastructure development." Update In a new analysis, IBM X-Force said it observed campaigns leveraging CastleLoader (aka CastleBot) to also deliver MonsterV2 (aka Aurotun Stealer) and WARMCOOKIE (aka BadSpace) via (Fixed spelling) SEO poisoning and GitHub repositories impersonating legitimate software. This underscores the versatility of the MaaS framework to enable the deployment of a diverse array of high-impact payloads. "What makes CastleBot particularly concerning is how it's being distributed: Most often through trojanized software installers downloaded from fake websites, luring unsuspecting users into launching the infection themselves," security researcher Golo Mühr said. "Once inside, CastleBot runs through a three-stage process: a stager/downloader, a loader and a core backdoor, which requests a set of tasks from its command and control (C2) server. Information gathered from the infected machine allows operators to easily filter victims, manage ongoing infections and deploy malware to high-value targets with precision." (The story was updated after publication on August 9, 2025, to include insights from IBM X-Force)
thehackernews.comJul 24, 2025extracted
US Government Warns of Wide-Ranging Interlock Attacks
The US government has warned businesses and critical infrastructure organizations to stay vigilant against wide-ranging attacks from the Interlock ransomware gang. The joint advisory from four government agencies including the FBI and the Department of Health and Human Services (HHS), highlighted the novel initial access techniques used by the cybercrime group. This includes “drive-by-download” and ClickFix social engineering techniques. The group, first identified in late September 2024, has been observed targeting various business, critical infrastructure and other organizations in North America and Europe. High-profile incidents attributed to Interlock in 2025 include Kettering Health, a major healthcare provider in western Ohio, US, and Scottish local authority West Lothian council. Its favored tactic is double extortion, in which threat actors exfiltrate data as well as encrypt it, increasing the pressure on victims to pay a ransom demand. The ransomware encryptors deployed are designed for both Windows and Linux operating systems. “These actors are opportunistic and financially motivated in nature and employ tactics to infiltrate and disrupt the victim’s ability to provide their essential services,” the advisory, published on July 22, warned. “Uncommon” Method for Initial Access The FBI has observed Interlock using a technique called drive-by-download to obtain initial access, which was described as an “uncommon method among ransomware groups.” This technique involves the compromise of legitimate websites, which automatically installs malware onto the victim’s device upon being visited. Interlock actors have also used the ClickFix social engineering technique to gain initial access. This tactic involves the use of a fake error or verification message to manipulate victims into copying and pasting a malicious script and then running it. Post-compromise, affiliates deploy various methods for discovery, credential access and lateral movement. A PowerShell script executes a series of commands designed to gather information on victim machines. Once command and control (C2) is established, a series of PowerShell commands are used to download a credential stealer and keylogger binary. These tools collect various information to help facilitate access between systems, including login information and users’ keystrokes. Remote desktop protocol (RDP) is also leveraged to facilitate lateral movement. Data is then exfiltrated via AzCopy, a legitimate tool used to copy files, and various file transfer tools, including WinSCP. Following exfiltration, Interlock launches ransomware encryptors. Encrypted files are appended with a ransom note titled !README!.txt. Interlock affiliates do not leave an initial ransom demand or payment instructions in this note, instead each victim is provided with a unique code and instructions to contact the ransomware actors via a .onion URL. When contact is made, victims are instructed to make ransom payments in Bitcoin to cryptocurrency wallet addresses provided by the actors. The actors also threaten to publish the victim’s exfiltrated data to their leak site on the Tor network unless the victim pays the ransom demand. “The actors have previously followed through on this threat,” the agencies noted. How to Defend Against Interlock Attacks The advisory set out a range of recommendations for organizations to protect against the techniques used by Interlock. These include: Reduce the risk of drive-by-download by implementing domain name system (DNS) to block users from accessing malicious sites Implement web access firewalls to mitigate and prevent unknown commands or process injection from malicious domains or websites Implement additional email security measures, including disabling hyperlinks in received emails Require all accounts with passwords to comply with National Institute of Standards and Technology (NIST) password guidance and implement multi-factor authentication (MFA) for all services Filter network traffic by preventing unknown or untrusted origins from accessing remote services on internal systems Maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented and secure location Segment networks to prevent the spread of ransomware
infosecurity-magazine.comJul 23, 2025extracted
FBI urges vigilance against Interlock ransomware group behind recent healthcare attacks
FBI urges vigilance against Interlock ransomware group behind recent healthcare attacks The Interlock ransomware is being used to target critical infrastructure and businesses across North America and Europe, the FBI and other federal agencies warned Tuesday. Federal officials said the group emerged in late September 2024 and has used uncommon methods of obtaining initial access to devices such as so-called drive-by downloads — when hackers use a compromised website or malicious link to make malware automatically download onto a victim’s computer without them knowing. In some cases, Interlock ransomware actors have disguised malicious payloads as fake Google Chrome or Microsoft Edge browser updates. The hackers have also been seen using "ClickFix" social engineering techniques for initial access — a popular trick where attackers convince victims to install something under the guise of fixing an issue. The group caused alarm this year with dangerous attacks that shut down the dialysis treatment company DaVita and one of the largest healthcare systems in Ohio. The Department of Health and Human Services assisted the FBI with the advisory alongside the Cybersecurity and Infrastructure Security Agency (CISA) and industry group MS-ISAC. Despite its high-profile healthcare attacks, the FBI said the group targets victims simply based on opportunity. Interlock actors have developed encryptors for both Windows and Linux operating systems. Ransom notes from the group do not include ransom demands or payment instructions, and only offer explanations for how to contact the threat actors. Ransom payments are demanded in Bitcoin. The advisory notes that analysts have identified potential links between Interlock and Rhysida — another ransomware operation known for its attacks on governments around the world. Federal investigators said cybersecurity firms have seen Interlock using information stealers like Lumma Stealer and Berserk Stealer to harvest credentials — allowing them to move throughout an organization and escalate their access. The FBI is increasingly releasing advisories on specific ransomware strains in an effort to help victims contend with threat actors currently launching attacks. Federal law enforcement agencies have been able to use incident response engagement to file legal action and even develop decryptors. On Friday, the FBI touted an announcement from Japanese officials about a decryptor for the Phobos ransomware. Jonathan Greig is a Breaking News Reporter at Recorded Future News. Jonathan has worked across the globe as a journalist since 2014. Before moving back to New York City, he worked for news outlets in South Africa, Jordan and Cambodia. He previously covered cybersecurity at ZDNet and TechRepublic.
therecord.mediaJul 22, 2025extracted
CISA and FBI warn of escalating Interlock ransomware attacks
CISA and the FBI warned on Tuesday of increased Interlock ransomware activity targeting businesses and critical infrastructure organizations in double extortion attacks. Today's advisory was jointly authored with the Department of Health and Human Services (HHS) and the Multi-State Information Sharing and Analysis Center (MS-ISAC) and it provides network defenders with indicators of compromise (IOCs) collected during investigations of incidents as recent as June 2025, along with mitigation measures to protect their networks against this ransomware gang's attacks. Interlock is a relatively new ransomware operation that emerged in September 2024 and has since targeted victims worldwide across various industry sectors, with a particular focus on the healthcare sector. The threat actors were also previously linked to ClickFix attacks, where they impersonate IT tools for initial network access, as well as malware attacks in which they deployed a remote access trojan called NodeSnake on the networks of U.K. universities. Recently, the cybercrime group claimed responsibility for breaching DaVita, a Fortune 500 company specializing in kidney care, resulting in the theft and leak of 1.5 terabytes of data from their systems, as well as for hacking Kettering Health, a healthcare giant that operates over 120 outpatient facilities and employs more than 15,000 people. While investigating their attacks, the FBI has observed the Interlock gang using some unusual tactics and pressuring their victims in double extortion attacks. "FBI observed actors obtaining initial access via drive-by download from compromised legitimate websites, which is an uncommon method among ransomware groups," the advisory reads. "Interlock actors employ a double extortion model in which actors encrypt systems after exfiltrating data, which increases pressure on victims to pay the ransom to both get their data decrypted and prevent it from being leaked." Earlier this month, the ransomware group was also observed adopting the new FileFix technique to drop remote access trojan (RAT) malware. FileFix is a social engineering attack in which the attackers weaponize trusted Windows UI elements, including the Windows File Explorer and HTML Applications (.HTA), to trick their targets into executing malicious PowerShell or JavaScript code without displaying any security warnings. To defend their networks against Interlock ransomware attacks, security teams are advised to implement Domain Name System (DNS) filtering, web access firewalls, and train users to recognize social engineering attempts. Defenders are also urged to keep systems, software, and firmware up to date and segment networks to limit access from compromised devices. Additionally, organizations need to establish identity, credential, and access management (ICAM) policies and require multifactor authentication (MFA) for all services when possible. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comJul 22, 2025extracted
Related Stories
6
Interlock Ransomware Exploits Cisco FMC Zero-Day CVE-2026-20131 for Root Access
Amazon threat intelligence teams identify Interlock ransomware campaign targeting enterprise firewalls Amazon threat intelligence has identified an active Interlock ransomware campaign exploiting CVE-2026-20131, a critical vulnerability in Cisco Secure Firewall Management Center (FMC) Software that could allow an unauthenticated, remote attacker to execute arbitrary Java code as root on an affected device, which was disclosed by Cisco on March 4, 2026. After Cisco’s disclosure, Amazon threat intelligence began research into this vulnerability using Amazon MadPot’s global sensor network—a system of honeypot servers that attract and monitor cybercriminal activity. While looking for any current or past exploits of this vulnerability, our research found that Interlock was exploiting this vulnerability 36 days before its public disclosure, beginning January 26, 2026. This wasn’t just another vulnerability exploit, Interlock had a zero-day in their hands, giving them a week’s head start to compromise organizations before defenders even knew to look. Upon making this discovery, we shared our findings with Cisco to help support their investigation and protect customers. A misconfigured infrastructure server—essentially, a poorly secured staging area used by the attackers—exposed Interlock’s complete operational toolkit. This rare mistake provided Amazon’s security teams with visibility into the ransomware group’s multi-stage attack chain, custom remote access trojans (backdoor programs that give attackers control of compromised systems), reconnaissance scripts (automated tools for mapping victim networks), and evasion techniques. AWS infrastructure and customer workloads on AWS were not observed to be involved in this campaign. This advisory shares comprehensive technical analysis and indicators of compromise to help organizations identify potential compromise and defend against Interlock’s operations. Organizations running Cisco Secure Firewall Management Center should immediately apply Cisco’s security patches and review the indicators provided below. Discovery and investigation timeline Amazon threat intelligence identified threat activity potentially related to CVE-2026-20131 beginning January 26, 2026, predating the public disclosure. Observed activity involved HTTP requests to a specific path in the affected software. Request bodies contained Java code execution attempts and two embedded URLs: one used to deliver configuration data supporting the exploit, and another designed to confirm successful exploitation by causing a vulnerable target to perform an HTTP PUT request and upload a generated file. Multiple variations of these URLs were observed across different exploit attempts. To advance the investigation and obtain additional threat intelligence, we performed the expected HTTP PUT request with the anticipated file content—essentially, we pretended to be a successfully compromised system. This successfully prompted Interlock to proceed to the next stage, issuing commands to fetch and execute a malicious ELF binary (a Linux executable file) from a remote server. When analysts retrieved the binary, they discovered the same host (attacker-controlled server) is used for distributing Interlock’s entire operational toolkit. The exposed infrastructure organized artifacts into separate paths corresponding to individual targets, with the same paths used for both downloading tools to compromised hosts and uploading operational artifacts back to the staging server. Attribution to Interlock ransomware The ELF binary and associated artifacts are attributable to the Interlock ransomware family based on convergent technical and operational indicators. The embedded ransom note and TOR negotiation portal are consistent with Interlock’s established branding and infrastructure. The ransom note’s invocation of multiple data protection regulations reflects Interlock’s documented practice of citing regulatory exposure to pressure victims, essentially threatening organizations not just with data encryption, but with regulatory fines and compliance violations. The campaign-specific organization identifier embedded in the note aligns with Interlock’s per-victim tracking model. Interlock has historically targeted specific sectors where operational disruption creates maximum pressure for payment. Education represents the largest share of their activity, followed by engineering, architecture, and construction firms, manufacturing and industrial organizations, healthcare providers, and government and public sector entities. Temporal analysis performed on timestamps from observed threat activities, artifacts stored on the misconfigured infrastructure server, and metadata embedded within recovered threat artifacts indicates the actor most likely operates in UTC+3 with 75–80% confidence. Systematic analysis across all UTC offsets showed UTC+3 produced the best fit: first activity around 08:30, peak activity between 12:00 and 18:00, and a probable sleep window of 00:30–08:30. Technical analysis: Interlock’s operational toolkit Post-compromise reconnaissance script Once Interlock gains initial access, they use a variety of priority tools to complete their attack. Amazon threat intelligence teams recovered a PowerShell script designed for systematic Windows environment enumeration (automated information gathering about the victim’s network). The script collects operating system and hardware details, running services, installed software, storage configuration, Hyper-V virtual machine inventory, user file listings across Desktop, Documents, and Downloads directories, browser artifacts from Chrome, Edge, Firefox, Internet Explorer, and 360 browser (including history, bookmarks, stored credentials, and extensions), active network connections correlated with responsible processes, ARP tables, iSCSI session data, and RDP authentication events from Windows event logs. The script stages results to a centralized network share (\JK-DC2\Temp) using each system’s fully qualified hostname to create dedicated directories—essentially creating a folder for each compromised computer. Following collection, it compresses data into ZIP archives named after each hostname and removes original raw data. This structured per-host output format indicates the script operates across multiple machines within a network—a hallmark of ransomware intrusion chains that prepare for organization-wide encryption. Custom remote access trojans Remote access trojans (RATs) are malicious programs that give attackers persistent control over compromised systems, functioning like unauthorized remote desktop software. JavaScript implant: Amazon threat intelligence recovered an obfuscated JavaScript remote access trojan that suppresses debugging output by overriding browser console methods (hiding its activity from basic detection tools). On execution, it profiles the infected host using PowerShell and Windows Management Instrumentation (WMI), collecting system identity, domain membership, username, OS version, and privilege context before transmitting this data during an encrypted initialization handshake. Command-and-control communication occurs over persistent WebSocket connections with RC4-encrypted messages using per-message 16-byte random keys embedded in packet headers—essentially, each message uses a different encryption key, making interception more difficult. The implant cycles through multiple operator-controlled hostnames and IP addresses in randomized order with exponential backoff between reconnection attempts. The implant provides interactive shell access, arbitrary command execution, bidirectional file transfer, and SOCKS5 proxy capability for tunneling TCP traffic (routing malicious traffic through other systems to hide its origin). Self-update and self-delete capabilities allow operators to replace or remove the implant without reinfection, supporting operational cleanup to hinder forensic investigation. Java implant: A functionally equivalent client implemented in Java provides identical command-and-control capabilities. Built on GlassFish ecosystem libraries, it uses Grizzly for non-blocking I/O transport and Tyrus for WebSocket protocol communication. In simpler terms, Interlock built the same backdoor in two different programming languages, ensuring they maintain access even if defenders detect one version. Infrastructure laundering script Sophisticated threat actors don’t attack from their own infrastructure, they build disposable relay networks to hide their tracks. Amazon threat intelligence teams identified a Bash script that configures Linux servers as HTTP reverse proxies (intermediary servers that forward traffic to hide the attacker’s true location). The script performs system updates, installs fail2ban with SSH brute-force protection, and compiles HAProxy 3.1.2 from source. The HAProxy instance listens on port 80 and forwards all inbound HTTP traffic to a hardcoded target IP, with systemd ensuring persistence across reboots. A notable component is a log erasure routine running as a cron job every five minutes. The routine truncates all *.log files under /var/log and suppresses shell history by unsetting the HISTFILE variable. This aggressive evidence destruction, wiping logs every five minutes, combined with the purpose-built HTTP forwarding proxy, indicates the script establishes disposable traffic-laundering relay nodes. These nodes obscure exploit traffic origin, relay command-and-control communications, or proxy data exfiltration, making it nearly impossible to trace attacks back to their source. Memory-resident webshell Amazon threat intelligence teams observed a Java class file delivered as an alternative to the ELF binary drop. When loaded by the Java Virtual Machine (JVM), its static initializer registers a ServletRequestListener with the server’s StandardContext, essentially installing a persistent memory-resident backdoor that intercepts HTTP requests without writing files to disk. This “fileless” approach evades traditional antivirus scanning that looks for malicious files. The listener inspects incoming requests for specially crafted parameters containing encrypted command payloads. Payloads are decrypted using AES-128 with a key derived from the MD5 hash of the hardcoded seed “geckoformboundary99fec155ea301140cbe26faf55ed2f40″ (using the first 16 characters: 09b1a8422e8faed0). Decrypted payloads are treated as compiled Java bytecode, dynamically loaded into the JVM, and executed—a technique designed to evade file-based detection by running malicious code entirely in memory. Connectivity verification tool Amazon threat intelligence teams recovered Java class files implementing a basic TCP server listening on port 45588 (encoded as Unicode character 넔 to obscure the port number from static analysis). The server accepts connections, logs connecting IP addresses, sends a greeting message, and immediately closes connections. This operational profile is consistent with a lightweight network beacon—essentially a “phone home” tool used to verify successful code execution or confirm network port reachability following initial exploitation. Legitimate tool abuse Interlock deployed ConnectWise ScreenConnect, a legitimate commercial remote desktop tool, alongside custom implants. When ransomware operators deploy legitimate remote access tools alongside their custom malware, they’re buying insurance—if defenders find and remove one backdoor, they still have another way in. This indicates multiple redundant remote access mechanisms—a pattern consistent with ransomware operators seeking to maintain access even if individual footholds are removed. The tool’s legitimate network footprint helps blend with authorized remote administration traffic, making detection more challenging. Amazon threat intelligence teams also recovered Volatility, an open-source memory forensics framework typically used by incident responders (the same tool defenders use to investigate attacks). While no artifacts indicated automated use, its presence alongside custom implants and reconnaissance scripts is consistent with advanced threat operations. Both ransomware groups and nation-state actors have been observed deploying Volatility during intrusions. The tool’s focus on parsing memory dumps provides access to sensitive data such as credentials stored in RAM, which can enable lateral movement (spreading through the network) and deeper environment compromise in support of ransom operations or espionage objectives. Interlock also used Certify, an open source offensive security tool designed to exploit misconfigurations in Active Directory Certificate Services (AD CS). For ransomware operators, Certify provides a pathway to identify vulnerable certificate templates and enrollment permissions that allow requesting authentication-capable certificates. These certificates can be used to impersonate users, escalate privileges, or maintain persistent access. These capabilities directly support both initial compromise and long-term persistence objectives in ransomware operations. Indicators of compromise (IoCs) The following indicators support defensive measures by organizations that may be affected. Due to Interlock’s use of content variation techniques, most file hashes are not included as reliable indicators. The threat actor modified most artifacts like scripts and binaries downloaded to different targets. This resulted in different file hashes for functionally identical tools. The customization allowed each attack to evade signature-based detection that looks for exact file matches. Defensive recommendations Organizations should take the following actions to protect against Interlock ransomware operations. Immediate actions: Apply Cisco’s security patches for Cisco Secure Firewall Management Center Review logs for the indicators of compromise listed above Conduct security assessments to identify potential compromise Review ScreenConnect deployments for unauthorized installations Detection opportunities: Monitor for PowerShell scripts staging data to network shares with hostname-based directory structures Detect Java ServletRequestListener registrations in web application contexts (unusual modifications to Java web applications) Identify HAProxy installations with aggressive log deletion cron jobs (proxy servers that erase their own logs every five minutes) Watch for TCP connections to unusual high-numbered ports (e.g., 45588) Long-term measures: Implement defense-in-depth strategies with multiple layers of security controls Maintain continuous threat monitoring and hunting capabilities Ensure comprehensive logging with secure, centralized log storage (stored separately from systems that could be compromised) Regularly test incident response procedures for ransomware scenarios Educate security teams on Interlock’s tactics, techniques, and procedures The real story here isn’t just about one vulnerability or one ransomware group—it’s about the fundamental challenge zero-day exploits pose to every security model. When attackers exploit vulnerabilities before patches exist, even the most diligent patching programs can’t protect you in that critical window. This is precisely why defense in depth is essential—layered security controls provide protection when any single control fails or hasn’t yet been deployed. Rapid patching remains foundational in vulnerability management, but defense in depth helps organizations not to be defenseless during the window between exploit and patch. Amazon Threat Intelligence teams continue to monitor Interlock ransomware operations and will provide updates as additional information becomes available. The intelligence gathered from this campaign is being integrated into AWS security services to protect customers proactively. If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
7 shared
Mar 23, 2026
US Tops Hit List as 396 SharePoint Systems Compromised Globally
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 31, 2025
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
USN-8900-1: Go Networking vulnerabilities
Welcome back to PWNED, the weekly column where we highlight some of the lowlights in corporate security. This week, we’ll talk about two scenarios, one that ended in tragedy and another that shows the power of a good defense over dedicated phishing attacks. Have a story about someone leaving a gaping hole in their network? Share it with us at [email protected]. Anonymity is available upon request. Both stories come courtesy of Dave Hatter, a cybersecurity and compliance consultant with Intrust IT. In his many years of experience with the company, Hatter has had to work for a variety of small companies that needed help with their security, whether they knew it or not. One time several years ago, the new CFO at a small construction company phoned Intrust and expressed interest in hiring them. However, the proposal was vetoed by the owner of the company, an older gentleman who thought his business was too small to interest hackers and that his existing, one-person IT staff was all he could afford. “We got a guy, my brother’s uncle’s cousin does my IT, don’t need you guys,” Hatter quotes the owner as saying. “We hear this all the time. Thanks for shopping. You’re too expensive.” Three weeks later, Hatter got a call from a local accountant friend who begged him to help a client who'd been hit with a ransomware attack. Hatter said he couldn’t really give more than general guidance, but would talk to the victim anyway. As soon as he called the number, Hatter realized that the ransomware victim was actually the same construction company that had turned down his services a few weeks earlier. The business had an old unpatched Windows server that contained all its most important data. There was a backup drive, but it was connected to the same server, so both devices were encrypted by the ransomware. “Their entire backup is this external drive, which, of course, is now encrypted,” Hatter said. “So, literally, they can't pay their employees. They don't know who owes them money.” Hatter could not help the company, and he never found out whether it paid the ransom. However, the org, which had been around for years, went out of business within months. This sad story shows the importance of having real backups that are off-site or in the cloud and patching whatever servers you have. You can never assume that your company is too small to be attacked because ransomware gangs want your money and they are just as happy to take on small businesses as large ones, which are likely to be harder targets. The other incident involved two companies in the landscaping and construction business. Somebody broke into an executive’s email account at company one and started sending phishing emails to company number two. The miscreants had also set up email filtering rules in the first company’s account so that the messages from the phishing campaign were routed to buried folders where the real-life account holder would never see them. The phishing mails took the form of RFPs (requests for proposal) – a perfect lure, because who wouldn't want new business? They were perfectly crafted, with no grammar errors or obvious tells, and the return address matched company one's. However, instead of attaching the RFP as a PDF or PowerPoint file, it had a button for the user to click to download it. “If I can get in your email and send out emails as you, the recipients, especially if they've interacted with me before, aren't going to have any guard up,” Hatter said. “Especially if there's no crazy language or crazy requests in there because they've got an email from me before.” Upon clicking the download button, the user was transported to a Microsoft 365 login screen that looked identical to the real one but was not on the microsoft.com domain. The user was then invited to put in their email address and password to gain access to the desired file. Because the user had 2FA, this fake page also asked them for their limited-time 2FA code. Behind the scenes, the threat actors were transmitting the login to Microsoft so that Microsoft itself would send an SMS message to the victim at company number two. Then the victim would pass along the one-time passcode via the fake login site. A classic man-in-the-middle attack. It worked, and the threat actors now had access to the Microsoft 365 account and email for the victim at company number two. This could've allowed them to do almost anything using that person’s email. If the victim had access to bank accounts or customer data, the attackers could have initiated password resets from the account, then conducted fraudulent money transfers, or stolen personal information. At the very least, they could've used the victim's account to phish other contacts. Fortunately, Hatter's client had installed a piece of software his company made called TarBot, which runs in the Microsoft 365 environment and uses Entra ID P2 to help customers identify suspicious logins. “It throws off a bunch of telemetry, statistics, metrics, whatever you want to call it, that allows our software to say, this is an anomalous login, revoke the token, and make the user log in again,” Hatter said. He said his company is not the only one to make apps like TarBot that detect suspicious logins. So the bad guys were kicked out after just a few minutes. But Hatter says the better way to stop these attacks is to use phishing-resistant MFA, such as hardware keys (like the YubiKey line) or passkeys. With today’s AI-assisted phishing, telltale signs such as bad grammar or obviously fake login pages are becoming few and far between. ®
6 shared
Oct 8, 2026
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.
6 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.
6 shared
Mar 31, 2026