vect

The emerging ransomware has been deployed against victims of the TeamPCP supply chain attacks, but organizations should think twice before paying for a decryptor.

Vect 2.0 ransomware has been found to wipes large, compromised files instead of merely encrypting them, making recovery impossible – even for the attackers. This is due to a critical flaw in the encryption implementation. The bug, likely an unintended coding error, was discovered by Check Point Research when investigating the latest version of the Vect ransomware. Vect is a ransomware-as-a-service (RaaS) program that first appeared in December 2025 on a Russian-language cybercrime forum and was discovered by security researchers in early January 2026. The group quickly grabbed headlines after it announced on BreachForums that it was partnering with TeamPCP, the threat group behind several supply-chain attacks, such as Trivy, Checkmarx’ KICS, LiteLLM and Telnyx, in March and April 2026. Additionally, Check Point reported that Vect also announced a partnership with BreachForums itself, promising that every registered forum user will become an affiliate and be granted use of the Vect ransomware, negotiation platform and leak site for operations. “As of April 2026, this partnership is in full effect,” the Check Point researchers noted in a new report published on April 28. Vect 2.0: RaaS Ambitions Crumble Under Poor Implementation Allegedly built from scratch, Vect launched version 2.0 of its ransomware lockers in February 2026 after its rise to fame. Written in C++, the lockers support Windows and Linux hosts as well as VMware ESXi hypervisors. The group claims to have built all three lockers from scratch. “Additionally, a forum post mentions that dedicated ‘cloud Lockers,’ likely targeting various cloud storage services, will be made available for affiliates that will prove their skills through a quiz or puzzle challenge in the near future,” the Check Point researchers indicated. After obtaining the Vect ransomware builder via BreachForums, the research team analyzed the three payloads, for Windows, Linux and ESXi. They found that all files above 131,072 bytes (128 KB) were permanently destroyed rather than being encrypted. This is due to a critical flaw in the encryption implementation of the ransomware that discards three of four decryption nonces – one-time secret numbers used in an authentication protocol to ensure that each cryptographic communication session is unique. Specifically, the researchers said that the cipher used in the ransomware encryption system is raw ChaCha20-IETF (RFC 8439) with no authentication, not ChaCha20-Poly1305 AEAD as claimed in the group’s initial advertisements of its product and mentioned in some threat intelligence reports. “There is no Poly1305 MAC and no integrity protection. This effectively makes Vect a wiper for virtually any file containing meaningful data, enterprise assets such as virtual machine (VM) disks, databases, documents and backups included,” said the Check Point researchers. The researcher also confirmed this flaw is present across all publicly available Vect versions and across the three targeted platforms, Windows, Linux and ESXi. All variants share an identical encryption design built on libsodium, with the same file-size thresholds, the same four-chunk logic and the same nonce-handling flaw throughout, “confirming a single codebase ported across platforms,” the report noted. Additionally, the Check Point researchers identified multiple additional bugs and design failures across all variants of the Vect ransomware, from self-cancelling string obfuscation and permanently unreachable anti-analysis code to a thread scheduler that actively degrades the encryption performance it meant to improve. “Vect 2.0 presents an ambitious threat profile with multi-platform coverage, an active affiliate program, supply-chain distribution via the TeamPCP partnership, and a polished operator panel. In practice, the technical implementation falls significantly short of its presentation,” the Check Point report concluded.

Researchers are warning that the VECT 2.0 ransomware has a problem in the way it handles encryption nonces that leads to permanently destroying larger files rather than encrypt them. VECT has been advertised on one of the latest BreachForums iterations, inviting registered users to become affiliates, and distributing access keys via private messages to those who showed interest. At some point, VECT operators announced a partnership with TeamPCP, the threat group responsible for the recent supply-chain attacks impacting Trivy, LiteLLM, and Telnyx, as well as an attack against the European Commission. In the announcement, VECT operators stated that their goal was to exploit victims of those supply-chain compromises, deploying ransomware payloads in their environments, as well as to conduct larger supply-chain attacks against other organizations. Faulty ransomware While this is meant to increase encryption speed for larger files, because all chunk encryptions use the same memory buffer for the nonce output, each new nonce overwrites the previous one. Once all chunks are processed, only the last nonce generated remains in memory, and only that one is written to disk. As a result, the only portion of the file that is recoverable is the last 25%, with the previous three parts being impossible to decrypt, as the nonces have been lost. Those lost nonces aren’t transmitted to the attacker either, so even if VECT operators wanted to decrypt the files for victims paying the ransom, they wouldn’t be able to. While this is meant to increase encryption speed for larger files, because all chunk encryptions use the same memory buffer for the nonce output, each new nonce overwrites the previous one. Once all chunks are processed, only the last nonce generated remains in memory, and only that one is written to disk. As a result, the only portion of the file that is recoverable is the last 25%, with the previous three parts being impossible to decrypt, as the nonces have been lost. Those lost nonces aren’t transmitted to the attacker either, so even if VECT operators wanted to decrypt the files for victims paying the ransom, they wouldn’t be able to. Check Point notes that, since most valuable enterprise files, including VM disks, database files, and backups, are above 128kb, VECT’s impact as a data wiper can be catastrophic in most environments. “At a threshold of only 128 KB, smaller than a typical email attachment or office document, what the code classifies as a large file encompasses not just VM disks, databases, and backups, but routine documents, spreadsheets, and mailboxes. In practice, almost nothing a victim would care to recover falls below this boundary,” Check Point says. The researchers found that the same nonce-handling flaw is present across all variants of the VECT 2.0 ransomware, including Windows, Linux, and ESXi, so the same data-wiping behavior applies across all cases. 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

SAAS Salesforce partners not seeing meaningful revenue from Agentforce AI platform, report saysShow us the money ai and ml AI companies are burning books, advocates complain to FTCFahrenheit 203, the temperature GPUs stop gorging on literature DEVOPS Go updates may delight diehard gophers but displease AI overlordsv 1.27 expands generics to support methods EDGE AND IOT Waymo has designed a robocar chip to stay ahead of Tesla5 nm ML accelerators promise 1,000+ TOPS, ultra-low latency SYSTEMS AMD inches closer to its goal of making AI suck less ... energyHouse of Zen claims latest systems already 4x more efficient than two years ago Security Russians are posing as Signal support to launch phishing attacksPLUS: US takes down Iranian propaganda sites; Marketing company asks 'Why Do We Have Your Information?' And more! Security Microsoft patches failed to fix on-prem SharePoint, which is now under zero-day attackPLUS: China upgrades smartphone surveillance tools; Ring eases anti-snooping stance; and more Black Hat and DEF CON DEF CON Franklin project enlists hackers to harden critical infrastructureVoting village reports have been so successful, says Jeff Moss, that the whole of DEF CON will now be included Security EQT buys majority share in Swiss cybersecurity biz AcronisWent at equivalent of $3.5B+ valuation for entire firm, though portion sold not specified Malware Month Ten years since the first corp ransomware, Mikko Hyppönen sees no end in sightOn the plus side, infosec's a good bet for a long, stable career FOSS smashed one Microsoft monopoly. After 20 years of failure, it's time to smash anotherWord up GNOME can look like Windows – and Flashback can do it without extensionsNew 'Simple-taskbar' is an option, but there's a simpler, stabler way A moment of silence, please, for the final release of Debian on x86-32New Debian versions hit FOSSland in the form of 13.6 and 12.15 Baddies caught exploiting extensions bugs with perfect 10 scores on vulnerable Joomla websitesFlaws in iCagenda, Balbooa Forms extensions can impact open source CMS that powers a million sites worldwide Frame: A new X11 server – implemented directly in assemblyJoins yserver, Phoenix, and of course XLibre – and outlier Arcan Cinnamon 6.8 will support Wayland – if you want itNext version of Linux Mint’s desktop has both kinds of display server

Threat hunters are warning that the cybercriminal operation known as VECT 2.0 acts more like a wiper than a ransomware due to a critical flaw in its encryption implementation across Windows, Linux, and ESXi variants that renders recovery impossible even for the threat actors. The fact that VECT's locker permanently destroys large files rather than encrypting them means even victims who opt to pay the ransom cannot get their data back, as the decryption keys are discarded by the malware during the time encryption occurs. "VECT is being marketed as ransomware, but for any file over 131KB – which is most of what enterprises actually care about – it functions as a data destruction tool," Eli Smadja, group manager at Check Point Research, said in a statement shared with The Hacker News. "CISOs need to understand that in a VECT incident, paying is not a recovery strategy. There is no decrypter that can be handed over, not because the attackers are unwilling, but because the information required to build one was destroyed the moment their software ran. The focus has to be on resilience: offline backups, tested recovery procedures, and rapid containment – not negotiation." VECT (now rebranded as VECT 2.0) is a ransomware-as-a-service (RaaS) scheme that first launched its affiliate program in December 2025. On its dark website, the group displays the message "Exfiltration / Encryption / Extortion," highlighting its triple-threat business model. According to an analysis published by the Data Security Council of India (DSCI) last month, a $250 entry fee, payable in Monero (XMR), is required for new affiliates. The fee is waived for applicants from the Commonwealth of Independent States (CIS) countries, indicating an attempt to recruit individuals from the region. In recent weeks, the group has established a formal partnership with the BreachForums cybercrime marketplace and the TeamPCP hacking group, in a move aimed at further lowering the barrier to entry for ransomware operators and incentivizing affiliates to launch attacks by weaponizing previously stolen data. "The convergence of large-scale supply chain credential theft, a maturing RaaS operation, and mass dark web forum mobilization represents an unprecedented model of industrialized ransomware deployment," Dataminr noted earlier this month. While the collaboration may be a sign of what's to come, its data leak site currently lists only two victims, both of which are said to have been compromised via the TeamPCP supply chain attacks. What's more, contrary to the group's initial claims of using ChaCha20-Poly1305 AEAD for encryption, Check Point's analysis has found that it uses a weaker, unauthenticated cipher with no integrity protection. But it doesn't end there, for the C++-based lockers for all three platforms suffer from a fundamental design flaw that causes any file larger than 131,072 bytes to be permanently and irrecoverably destroyed, as opposed to being encrypted. "The malware encrypts four independent chunks of each 'large file' using four freshly generated random 12-byte nonces, but appends only the final nonce to the specific encrypted file on disk," Check Point explained. "The first three nonces, each required to decrypt its respective chunk, are generated, used, and silently discarded. They are never stored on disk, in the registry, or transmitted to the operator." "Because ChaCha20-IETF requires both the 32-byte key and the exact matching 12-byte nonce to reverse each chunk, the first three quarters of every large file are unrecoverable by anyone, including the ransomware operator, who cannot provide a working decryption tool even after ransom payment. Since the vast majority of operationally critical files exceed this 'large-size' threshold, VECT 2.0 functions in practice as a data wiper with a ransomware facade." The Windows version of the ransomware, besides encrypting files across local, removable, and network-accessible storage, features a comprehensive anti-analysis suite targeting 44 specific security and debugging tools, alongside a safe-mode persistence mechanism and multiple remote-execution script templates for lateral spread. When "--force-safemode" is active, the locker configures the next boot into Windows Safe Mode and writes its own executable path into the Windows Registry so that it's automatically run on the subsequent Safe Mode boot, where the operating system is launched in a basic state using a limited set of files and drivers. On top of that, although the Windows variant implements environment detection mechanisms to fly under the radar, they are never invoked, allowing security teams running the artifacts to avoid triggering any evasive response. The ESXi variant, on the other hand, enforces geofencing and anti-debugging checks prior to commencing the encryption step. It also attempts to move laterally using SSH. The Linux version uses the same codebase as the ESXi flavor and implements a subset of its functionality. The geofencing step verifies if it's running in a CIS country, and if so, exits without encrypting the files. This behavior, per Check Point, is rather unusual as most RaaS programs removed Ukraine from the CIS countries list following Russia's military invasion of the country in early 2022. "During recent years these checks have been largely removed from ransomware," it added. "VECT including such checks and even adding Ukraine to the list of exclusions is rather uncommon. Check Point Research has two theories regarding this observation: either this code was AI generated, where LLMs were trained with Ukraine being part of CIS or VECT used an old code base for their ransomware." It's assessed that the operators of VECT are novice actors rather than experienced threat actors, not to mention the possibility that some chunks of code could have been generated with help from an artificial intelligence (AI) tool. "VECT 2.0 presents an ambitious threat profile with multi-platform coverage, an active affiliate program, supply-chain distribution via the TeamPCP partnership, and a polished operator panel," Check Point concluded. "In practice, the technical implementation falls significantly short of its presentation."

Check Point Research discovers that the VECT 2.0 ransomware permanently destroys “large files” rather than encrypting them. A critical flaw in the encryption implementation, identical across all three platform variants (Windows, Linux, ESXi), discards three of four decryption nonces for every file above 131,072 bytes (128 KB). Full recovery is impossible for anyone, including the attacker. At a threshold of only 128 KB, this effectively makes VECT a wiper for virtually any file containing meaningful data, enterprise assets such as VM disks, databases, documents and backups included. CPR confirmed this flaw is present across all publicly available VECT versions. The cipher is misidentified in public reporting. VECT uses raw ChaCha20-IETF (RFC 8439) with no authentication, not ChaCha20-Poly1305 AEAD as claimed in several widely cited threat intelligence reports (and VECT’s initial advertisement). There is no Poly1305 MAC and no integrity protection. Advertised encryption speed modes are not implemented. The --fast, --medium, and --secure flags present across Linux and ESXi variants are parsed and then silently ignored. Every execution applies identical hardcoded thresholds regardless of operator selection. Three platforms, one flawed engine: Windows, Linux, and ESXi variants share an identical encryption design built on libsodium, with the same file-size thresholds, the same four-chunk logic, and the same nonce-handling flaw throughout, confirming a single codebase ported across platforms. Professional facade, amateur execution: beyond the nonce flaw, CPR identified multiple additional bugs and design failures across all variants, from self-cancelling string obfuscation and permanently unreachable anti-analysis code, to a thread scheduler that actively degrades the encryption performance it meant to improve. Background VECT Ransomware is a Ransomware-as-a-Service (RaaS) program that made its first appearance in December 2025 on a Russian-language cybercrime forum. After claiming their first two victims in January 2026, the group got back into the public eye due to an announcement of a partnership with TeamPCP, the actor behind several supply-chain attacks in March 2026. These attacks injected malware into popular software packages such as Trivy, Checkmarx’ KICS, LiteLLM and Telnyx, affecting a large base of downstream consumers. Shortly after these attacks made headlines, VECT made a post on BreachForums, announcing their partnership with TeamPCP, with the goal to exploit the companies affected by those supply chain attacks. In addition, VECT announced a partnership with BreachForums itself, promising that every registered forum user will become an affiliate and thus be able to use the VECT ransomware, negotiation platform and leak site for operations. Traditionally, most ransomware groups allow affiliates to join either based on reputation or through paying a fee. As of April 2026, this partnership is in full effect: While these actions show an ambitious project, the group’s current leak site only lists two victims, both originating from the TeamPCP supply chain attacks: The VECT Ransomware is written in C++ and, with version 2.0 released in February 2026, VECT supports Windows and Linux hosts as well as ESXi hypervisors. The group claims to have built all three lockers from scratch. Additionally, a forum post mentions that dedicated “Cloud Lockers”, likely targeting various cloud storage services, will be made available for affiliates that will prove their skills through a quiz or puzzle challenge in the near future. Introduction: Ransomware Analysis Overview Through an account on BreachForums, Check Point Research got access to the panel and ransomware builder. Here, an affiliate has the option to build three different payloads: Windows, Linux and ESXi (as well as a dedicated tool for data exfiltration, which is not yet available at the time of writing): Check Point Research analyzed all three payloads, uncovering various flaws and oversights – revealing that, behind the professional facade, VECT ransomware is not a technically sophisticated service. Ransomware Cross-Platform Overview As detailed in the following sections, VECT 2.0 targets Windows, Linux, and VMware ESXi through three distinct variants built on a shared codebase. While platform-specific disruption logic differs, the core encryption engine is identical across all three, a design decision that ensures the flaw described in the next section affects every supported platform equally. All three variants are statically compiled C++ executables embedding the libsodium cryptographic library, accept operator-supplied command-line flags, support lateral movement, and produce an identical on-disk encrypted file format. The table below summarizes the key properties across all three variants. Nonce Flaw – “Large File” Destruction Correct Cryptographic Identification Before describing the flaw, a correction to existing public reporting is warranted. Several published analyses describe VECT’s encryption as ChaCha20-Poly1305 AEAD. This is incorrect as we confirmed that all three versions (Windows, Linux, ESXi) use the raw, unauthenticated ChaCha20 stream cipher in its IETF variant (RFC 8439) via libsodium’s crypto_stream_chacha20_ietf_xor. The _ietf designation refers specifically to the standardized 96-bit (12-byte) nonce and 32-bit counter parameterization distinct from Bernstein’s original 64-bit nonce form. The ChaCha20-Poly1305 AEAD construction appends a 16-byte Poly1305 authentication tag to each ciphertext. No such tag exists in any VECT-encrypted file. The on-disk format contains only raw ciphertext followed by a 12-byte nonce – no MAC, no integrity protection, no authenticated encryption of any kind. This misattribution likely stems from researchers trusting the threat actors’ own initial forum advertisement where VECT themselves incorrectly named the encryption scheme they use. Overview All three VECT 2.0 variants share a critical implementation flaw that causes any file larger than 131,072 bytes (128 KB, smaller even than a simple document) to be permanently and irrecoverably destroyed rather than encrypted for later decryption. The malware encrypts four independent chunks of each ”large file” using four freshly generated random 12-byte nonces, but appends only the final nonce to the specific encrypted file on disk. The first three nonces, each required to decrypt its respective chunk, are generated, used, and silently discarded. They are never stored on disk, in the registry, or transmitted to the operator. Because ChaCha20-IETF requires both the 32-byte key and the exact matching 12-byte nonce to reverse each chunk, the first three quarters of every large file are unrecoverable by anyone including the ransomware operator who cannot provide a working decryption tool even after ransom payment. Since the vast majority of operationally critical files exceed this “large-size” threshold, VECT 2.0 functions in practice as a data wiper with a ransomware facade. Small File Processing For files not exceeding131,072 bytes (128 KB), the entire content is encrypted in a single pass. One 12-byte nonce is generated, used to encrypt the full file in-place, and appended to the end of the file. The resulting on-disk layout is: For this size class, the format is internally consistent and the appended nonce is sufficient to reverse the single encryption pass. These files are fully decryptable. Large File Processing – The Flaw For files exceeding 131,072 bytes (128 KB), VECT divides the file into four chunks at quarter-file offsets derived from the file size: Quarter size: file size divided by 4 Chunk start offsets:0, ¼, ½, ¾ of the file Chunk size per offset: up to 32,768 bytes (32 KB), or the remaining file length if shorter The encryption loop processes each chunk in sequence. The per-chunk encryption helper is called once per iteration and on every call it generates a fresh cryptographically random 12-byte nonce via libsodium’s randombytes(), writing it into a single shared output buffer passed by the caller. Because all four calls receive the same buffer address, each new nonce overwrites the previous one. After the loop completes, only the nonce from the fourth/final chunk remains in the buffer and this is the only nonce appended to the file. The three discarded nonces are outputs of randombytes() (which on Windows internally resolves to SystemFunction036 / RtlGenRandom in advapi32.dll, forwarding to ProcessPrng in bcryptprimitives.dll; on Linux and ESXi it reads from the kernel CSPRNG via getrandom() or /dev/urandom through libsodium’s safe_read()), cryptographically unpredictable values that are never stored anywhere after the buffer is overwritten. There is no sidecar file, no registry entry, and no network exfiltration of nonce material in any of the three variants. Cross-Platform Confirmation The flaw is structurally identical across all three platform variants. In each case, the per-chunk encryption helper generates a fresh random nonce on every call and writes it into the same caller-supplied 12-byte buffer; all four iterations of the loop share this buffer; and a single 12-byte write to the end of the file follows the loop. The ESXi variant also performs a zero-block check before each encryption call, where chunks consisting entirely of zero bytes are skipped (an optimization for sparse VMDK files). This does not affect the nonce flaw; the shared buffer is still overwritten on each non-skipped call and only the final surviving nonce reaches disk. The flaw predates VECT 2.0. CPR’s analysis of an older ESXi variant identified in the wild prior to the 2.0 release confirms the identical four-chunk loop, quarter-offset calculation, shared nonce buffer, and single EOF nonce write – unchanged from the operator’s first publicly observed deployment through every known release. Impact Files commonly exceeding 128 KB span virtually everything from typical office documents, spreadsheets, and images to virtual machine disk images, database files, archives, and backups – precisely those most critical to business continuity and most targeted by ransomware operators. For this dominant file class, VECT 2.0 cannot function as recoverable ransomware; it is operationally a data wiper. Victims who pay the ransom cannot receive a functional decryptor for their most critical files – not because the operator is uncooperative, but because the nonces required for decryption no longer exist. Windows Locker The Windows variant targets local, removable, and network-accessible storage, renames encrypted files with the .vect extension, drops a ransom note and a branded desktop wallpaper, and executes defense-evasion, persistence, and lateral-movement routines. Of particular note is a comprehensive anti-analysis suite targeting 44 specific security and debugging tools, alongside a safe-mode persistence mechanism and multiple remote-execution methods for lateral spread. Command-Line Interface and Default Behavior The locker exposes the following operator options: -h, --help Help -v, --verbose Verbose output -p, --path Target specific path -c, --creds Override credentials --gpo Enable GPO spread (default: on) --no-gpo Disable GPO spread --mount Enable network mount (default: on) --no-mount Disable network mount --stealth Enable self-delete (default: on) --no-stealth Disable self-delete --force-safemode Force safemode boot GPO spread, network mounting, and self-deletion are all on by default. An operator deploying without flags, for example via Group Policy or a remote execution primitive, activates the full impact chain automatically, including spread, hidden volume access, and post-execution cleanup. File Encryption and Renaming Each target file is renamed to append .vect before encryption. The file is then opened in-place and encrypted using the ChaCha20-IETF scheme described in the preceding section. The nonce flaw applies identically: files larger than 131,072 bytes (128 KB) lose the first three chunk nonces permanently, thus resulting in large file destruction rather than encryption. The encryption engine spawns worker threads in a fixed 1:7 scanner-to-encryptor ratio derived from a CPU-count-tiered multiplier: ×8 for machines with up to 4 CPUs, ×6 for 5-8 CPUs, and ×4 beyond that, hard-capped at 256 total. On a typical 8-CPU target, this produces 6 scanner and 42 encryptor threads simultaneously competing for the same disk I/O channels – overkill by any measure, and a thread count that would make any seasoned ransomware developer laugh. Families like LockBit cap their pools at 1-2× CPU count for good reason; spawning six times as many threads as there are CPUs does not encrypt files faster; it simply means the operating system spends more time switching between threads than doing useful work. This is a textbook mistake made by developers who read about parallelism but skipped the part about profiling. The fact that it is shipped in a supposedly operational ransomware tool speaks volumes about the maturity of whoever is behind this project. Ransom Note and Wallpaper After encrypting each drive target, the locker drops !!!READ_ME!!!.txt, assembled from multiple decoded string fragments (see the ransom note in the Appendix). Then, it generates a replacement desktop wallpaper (dvm3_wall.bmp) that carries the VECT 2.0 brand banner, as shown in the image below. Target Selection and Exclusions Drive enumeration covers logical drives and network-mapped resources. The file selection logic skips the following to leave the operating system functional enough for the victim to access the payment portal: Excluded directories:Windows, Windows.old, Boot, $Recycle.Bin, System Volume Information, Program Files, Program Files (x86), ProgramData These represent the builder defaults; affiliates may configure additional exclusions at sample generation time. Process and Service Disruption When running with elevated privileges, the locker stops services via the Windows Service Control Manager and terminates the following processes to release file handles before encryption begins: sql.exe, oracle.exe, mysqld.exe, excel.exe, winword.exe, outlook.exe, firefox.exe, thunderbird.exe. Unlike typical RaaS offerings where affiliates can customize kill lists, this list is hardcoded by the builder and cannot be modified at sample generation time. Persistence and Safe-Mode Preparation When --force-safemode is active, the locker executes bcdedit /set {default} safeboot minimal to configure the next boot into minimal safe mode, then writes its own executable path into the Windows registry under the safe-boot service load path with value "Service". This ensures the locker runs on the subsequent safe-mode boot, where the majority of security products are disabled. After completing execution, the boot configuration entry is removed to avoid persistent boot loops. Task Manager is also disabled via the registry for the duration of execution. Lateral Movement The locker contains multiple encoded remote-execution script templates enabling propagation to additional Windows hosts using operator-supplied credentials (--creds). Methods include: admin share file copy, Windows Credential Manager storage via cmdkey, WMI execution, DCOM/MMC application instantiation, remote scheduled task creation, remote service installation via sc.exe, and PowerShell remoting. Host discovery combines Windows domain enumeration with a local subnet sweep using network adapter information. Anti-Analysis The Windows variant implements three layered analyst-environment detection mechanisms. All three detection mechanisms are present in compiled form but are never invoked. The cross-reference analysis confirms zero call sites reach any of the three functionalities in this build. This is consistent with a conditional compilation flag that was left disabled at build time, and represents a meaningful gap: an analyst running this sample under any of the targeted tools will not trigger any evasive response. No code obfuscation is applied, although the most operator-facing strings are concealed using a rotating 64-bit XOR scheme: each byte is XORed against the corresponding byte of a fixed 64-bit key, cycling through all eight key bytes. Running-process scan A full process snapshot is taken and each process name is compared against a hardcoded list of 44 analysis tools (originally 47, but we removed the duplicates), covering debuggers, import reconstructors, PE utilities, process monitors, network sniffers, and sandbox controllers (the full list of detected tools can be found in the Appendix section). Parent process check The parent process image path is retrieved and matched against a list of debugging environments: devenv, windbg, x64dbg, x32dbg, ollydbg, ida. A process launched from any of these is treated as running under analysis. Kernel debug-object query The Windows native API NtQueryInformationProcess is resolved dynamically from ntdll.dll at runtime avoiding static import detection and queried for the ProcessDebugObjectHandle information class. A non-null return indicates an attached debugger. Defense Evasion and Cleanup ESXi Locker – The Hypervisor Ransomware The ESXi variant of the VECT ransomware targets VMware ESXi hypervisors and employs geofencing and anti-debugging before disrupting various system services, wiping logs, and encrypting victim files, defaulting to the VMware File System mount point at /vmfs/volumes. The malware also supports SSH-based lateral movement, where the ransomware tries to use available credentials to connect to known SSH hosts. Anti-Analysis and Geofencing Before executing any malicious code, the ransomware employs two simple anti-analysis checks: First, it checks if it is running in a CIS state, and if so, exits without encryption. The malware runs timedatectl and compares the time zones against a blacklist and checks the LANG and LC_ALL environment variables, validating that the country code does not match one of the excluded countries. Before 2022 CIS checks were very common in RaaS malware. During the start of the Russo-Ukrainian war, most RaaS programs removed Ukraine from the CIS countries list. During recent years these checks have been largely removed from ransomware. VECT including such checks and even adding Ukraine to the list of exclusions is rather uncommon. Check Point Research has two theories regarding this observation: either this code was AI generated, where LLMs were trained with Ukraine being part of CIS or VECT used an old code base for their ransomware. Additionally to these checks, the malware probes for the presence of a debugger by checking the value of TracerPid in /proc/self/status, exiting if any tracing process is found. To obfuscate from basic static analysis, the authors decided to implement strings as stack strings. Some strings, most notably the different command line options, are additionally XORed with a single byte key: Command-Line Interface and SSH lateral movement The following command line options are available: --path Target directory (default: /vmfs/volumes) --spread Enable SSH lateral movement --fast Fast mode: encrypt only 1MB --medium Medium mode: encrypt 4 parts (64MB each) --secure Secure mode: encrypt 100% (default) --no-kill-vms Don't kill running VMs (encrypt only) --verbose Enable verbose output --help Show this help message Operators can seemingly decide between three different encryption methods, --fast, --medium, and --secure, to find a tradeoff between speed and thoroughness of the encryption – however, the ransomware does not actually implement these different modes – the code parses them into variables, but they are never read back. Every execution, regardless of operator-selected flag, applies the same hardcoded thresholds: 131,072-byte large-file boundary and 32,768-byte maximum chunk size. The same goes for the Linux variant we describe further below. If the --spread option is supplied, the malware tries to spread laterally like an SSH based worm: All readable keys from the home and /root directories are extracted /etc/ssh/ssh_config and ~/.ssh/config are read and parsed for any hostnames and corresponding usernames All known_hosts files are zeroed out to avoid any host-key warnings For each host, the locker tries to connect with each of the collected usernames as well as a hardcoded list of common usernames If a connection succeeds, the malware copies itself over via scp and executes itself via ssh Service Disruption, Log Wiping and Encryption Before running any encryption, the malware makes sure to shut down any services that could hold any file locks or could otherwise interfere with the process. It starts by disabling the ESXi firewall via the esxcli utility, as well as specific firewall rulesets and shutting down various ESXi health monitoring processes: Afterwards, it proceeds with shutting down other services and processes, like databases, backup tools, Hypervisor related services and security products. Shutdown is either attempted gracefully, via systemctl stop and service stop, or aggressively via pkill -9 and systemctl disable --now . A full list of targeted services can be found in the Appendix. To remove any locks from virtual machine disk files, the VECT locker invokes various legitimate administration utilities to shut down any running virtual machines. However, contrary to its name, the locker not only targets ESXi but also other common Hypervisors: Next, various shell history files and logs in /var/log are removed or zeroed-out. This includes logs from hypervisors, container services, databases, web servers, audit logs or other system logs and journals (see the Appendix for a complete list). After this prelude, the actual encryption process is kicked off: If no path is supplied, the default path of /vmfs/volumes is used, which is the default VMware File System (VMFS) mount point for all datastores. In a multi-threaded process, each datastore is searched for files to encrypt. The ransomware maintains a sensible blacklist, which excludes several directories hosting mainly executables, system files or config files: Again, the thread count is chosen rather excessively, by multiplying the amount of CPU cores by 4, clamping the value between a minimum of 32 and a maximum of 256. By sharing a codebase with the other versions, see encryption process is the same and contains the same flaw in its implementation: it only includes the latest nonce when chunk-processing a big file: Finally, if the malware was configured to do so, the ransom note is dropped to /home, /root and /tmp, as well as in various system paths: Linux Locker The Linux version is built on the same codebase as the ESXi and implements a subset of its functionality. This becomes apparent when comparing the execution flow of the main functions side-by-side: Just like the ESXi version, the malware first kills any services and processes that could interfere with the encryption, shuts down any VMs (interestingly also including ESXi VMs) and wipes system logs and shell history files. Then, encryption is started, with the system root / as the default path and ransom notes are written to disk. The Linux locker, just like its ESXi counterpart, supports the --spread SSH lateral movement functionality. Due to the shared codebase, the locker also fails to save the first three nonces when encrypting large files, making fill recovery of big files impossible. The Linux version also has another oversight in the implementation of the encryption. Just like in the ESXi locker, the command line flags are supposed to be encrypted, but the authors accidentally designed a double XOR encryption scheme, which cancels out the encryption and leads to plain text strings being present in the binary: On a side note, even the ASCII art is broken because the developers forgot to escape the backslash characters: Conclusion VECT 2.0 presents an ambitious threat profile with multi-platform coverage, an active affiliate program, supply-chain distribution via the TeamPCP partnership, and a polished operator panel. In practice, the technical implementation falls significantly short of its presentation. Check Point Research’s analysis reveals that the ransomware’s encryption flaw is not a minor edge case but a fundamental design error affecting virtually every file of consequence. At a threshold of only 128 KB, smaller than a typical email attachment or office document, what the code classifies as a large file encompasses not just VM disks, databases, and backups, but routine documents, spreadsheets, and mailboxes. In practice, almost nothing a victim would care to recover falls below this boundary. The nonce-handling bug is identical across all three platform variants and as confirmed through analysis of an earlier variant identified in the wild prior to the VECT 2.0 release, has been present since the operator’s first publicly observed deployment. It has never been corrected. Victims who pay the ransom cannot receive a working decryptor for their largest files, not through operator deception, but because the information required for decryption was irrecoverably destroyed at the moment of encryption. An overly aggressive thread scheduler that actively harms encryption throughput, and three fully compiled but permanently unreachable anti-analysis routines, further reinforce this assessment: the authors know what features a professional ransomware tool should have, but demonstrably struggled to implement them correctly or at all. Beyond the nonce flaw, CPR identified a pattern of incomplete implementation: advertised encryption modes that are parsed but never applied, string obfuscation routines that accidentally cancel themselves out, and a cipher incorrectly described in public reporting. Together these findings paint a picture of a group with operational ambition, reflected in the BreachForums open-affiliate model and the TeamPCP supply-chain campaign, but with cryptographic and software engineering maturity that does not match the scale of the operation they are attempting to run. The announcement of forthcoming “Cloud Lockers” and the low technical barrier introduced by the open-affiliate model both warrant continued monitoring. As CPR has demonstrated, the current implementation has severe limitations but those can be corrected in a future version, and the distribution infrastructure to deploy such a version at scale already exists. Protections Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems and protect against the attacks and threats described in this report. !!! README !!! =============== ::: ::: :::::::::: :::::::: ::::::::::: :+: :+: :+: :+: :+: :+: +:+ +:+ +:+ +:+ +:+ +#+ +:+ +#++:++# +#+ +#+ +#+ +#+ +#+ +#+ +#+ #+#+#+# #+# #+# #+# #+# ########## ######## ### =============== Dear Management, all of your files have been encrypted with ChaCha20 which is an unbreakable encryption algorithm. Sadly, this is not the only bad news for you. We have also exfiltrated your sensitive data, consisting mostly of databases, backups and other personal information from your company and will be published on our website if you do not cooperate with us. The only way to recover your files is to get the decryption tool from us. To obtain the decryption tool, you need to: 1. Open Tor Browser and visit: 2. Follow the instructions on the chat page 3. Receive a sample decryption of up to 4 small files 4. We will provide payment instructions 5. After payment, you will receive decryption tool WARNING: Do not modify encrypted files Do not use third party software to restore files Do not reinstall system If you violate these rules, your files will be permanently damaged. Files encrypted: [N] Total size: [size] bytes Unique ID: REDACTED Backup contact (Qtox): 1A51DCBB33FBF603B385D223F599C6D64545E631F7C870FFEA320D84CE5DAF076C1F94100B5B “The Turkish Rat” Evolved Adwind in a Massive Ongoing Phishing Campaign Check Point Research Publications August 11, 2017 “The Next WannaCry” Vulnerability is Here Check Point Research Publications March 12, 2026 “Handala Hack” – Unveiling Group’s Modus Operandi SUBSCRIBE TO CYBER INTELLIGENCE REPORTS We value your privacy! BFSI uses cookies on this site. We use cookies to enable faster and easier experience for you. By continuing to visit this website you agree to our use of cookies.

The threat actor behind the widespread March campaign targeting the open source software community has been using compromised credentials to access AWS environments and exfiltrate more data, cybersecurity firm Wiz reports. The hacking group, known as TeamPCP, DeadCatx3, PCPcat, and ShellForce, has been active since 2024. Initially focused on cloud environments, the group shifted to supply chain attacks in mid-2025, targeting the theft of CI/CD credentials at scale. TeamPCP made headlines over the past two weeks, after hacking Aqua Security’s Trivy vulnerability scanner as part of a campaign that has since expanded to NPM, PyPI, and OpenVSX. According to OpenSourceMalware, the various incidents attributed to the group over the past weeks are chained together, as they were all triggered by the Trivy hack, which was the result of improperly rotated credentials following a February compromise. The malware injected in Trivy packages and GitHub Actions was executed when Trivy ran in downstream pipelines, allowing TeamPCP to compromise publish tokens of NPM developers, as well as a PyPI token belonging to LiteLLM co-founder and CEO Krrish Dholakia. LiteLLM has over 90 million monthly downloads, and its compromise had a massive blast radius. Among others, it exposed a Telnyx PyPI token that led to Telnyx’s PyPI packages being injected with malware. Security researchers estimate that tens of thousands of repositories were likely impacted by the campaign, as TeamPCP’s malware was designed to harvest credentials, API tokens, SSH tokens, and other secrets from the infected developer systems. According to a fresh Wiz report, the hacking group did not waste time validating the exfiltrated credentials. They used the open source tool TruffleHog to confirm that stolen AWS access keys, Azure application secrets, and various SaaS tokens were still valid and in use. Within 24 hours of validating the stolen secrets, the group moved to discovery operations in the compromised AWS environments, enumerating various services, with a focus on containers, where it mapped clusters and task definitions. It also targeted the victims’ AWS Secrets Managers. “Once access had been validated and the layout identified, the actors used a variety of techniques to further their scheme by executing additional code and gaining access to other parts of the victim environments,” Wiz notes. The hackers relied on GitHub workflows to execute code within victim environments, and used the ECS Exec feature to execute Bash commands and Python scripts directly on containers running in AWS environments. “This access enabled the attackers to explore the environment and exfiltrate sensitive data,” Wiz explains. While it stole source code, configuration files, and embedded secrets from GitHub repositories, TeamPCP accessed S3 buckets, Secrets Manager, and databases for bulk data exfiltration from AWS environments, the cybersecurity firm says. “TeamPCP’s post-compromise activities focused on compromising additional secrets and exfiltrating massive amounts of data from code repositories and cloud resources. The exfiltrated data and compromised secrets are potentially being shared with other groups to enable a range of operations,” Wiz notes. In terms of other threat actors that TeamPCP might be working with to monetize its access to compromised environments, the main suspects are the infamous extortion group Lapsus$ and the Vect Ransomware Group. Lapsus$ was seen boasting about future TeamPCP operations, as if it had insider knowledge, and Vect claimed on a known hacking forum that it had a partnership with TeamPCP, Socket reports. “As always, we recommend all customers to follow security, identity, and compliance best practices—including relying on temporary credentials, such as IAM roles, instead of creating long-term credentials, such as access keys. Customers can contact AWS Support with any questions or concerns about the security of their account,” an AWS spokesperson told SecurityWeek. *Updated with statement from AWS. Related: Silent Drift: How LLMs Are Quietly Breaking Organizational Access Control Related: Chinese Hackers Caught Deep Within Telecom Backbone Infrastructure Related: AI Speeds Attacks, But Identity Remains Cybersecurity’s Weakest Link

Researchers have observed a “dangerous convergence” between supply chain attackers and extortion gangs like Lapsus$ as TeamPCP looks to exploit stolen credentials. In a new report published on March 30, security researchers at Wiz, now part of Google Cloud, said they found evidence that TeamPCP was exploring ways to monetize the secrets harvested during these campaigns, such as cloud credentials, SSH keys, Kubernetes configuration files and other coding process secrets. The threat group had been observed validating, encrypting and exfiltrating theses secrets to attacker-controlled domains. “While the speed at which they were used suggests that it was the work of the same threat actors responsible for the supply chain operations, we are not able to rule out the secrets being shared with other groups and used by them,” the Wiz researchers wrote. TeamPCP: Alleged Ties to Ransomware Groups In a message shared with Infosecurity, Wiz confirmed that TeamPCP was “explicitly collaborating with the notorious extortion group Lapsus$ to perpetuate the chaos." Lapsus$ is an extortion-focused hacking group known for high-profile breaches via social engineering and credential theft, with suspected tactical overlaps – but no confirmed organizational ties – to Scattered Spider and ShinyHunters. Ben Read, a lead researcher at Wiz, told Infosecurity: "We are seeing a dangerous convergence between supply chain attackers and high-profile extortion groups like Lapsus$. By moving horizontally across the ecosystem – hitting tools like liteLLM that are present in over a third of cloud environments – they are creating a 'snowball effect.' This isn't an isolated incident; it’s a systemic campaign that requires security teams to take action and will likely continue to expand." Meanwhile, Socket, one of the earliest firms to report the TeamPCP software supply chain attacks, shared posts attributed to the Vect ransomware group on BreachForums announcing a partnership with TeamPCP as part of its research into the group. “Vect Ransomware Group is now partnering with TeamPCP, the operators behind the latest Trivy / LiteLLM supply chain compromises. Together, we are ready to deploy ransomware across all affected companies that got hit by these attacks, and we won't stop there. We will pull off even bigger supply chain operations. We will chain these compromises into devastating follow-on ransomware campaigns,” the message read. Vect is an emerging Russian-speaking ransomware-as-a-service (RaaS) group, operating as a structured affiliate model where core developers build the ransomware and affiliates carry out attacks, earning up to 80–88% of the profits. TeamPCP Behind Wave of Malicious PyPI Packages The cyber threat group known as TeamPCP recently rose to notoriety by uploading malicious packages to Python Package Index (PyPI), the official online repository where developers share and download Python software packages. The group typically uses typosquatting to trick developers into downloading them. In one campaign, the group targeted Trivy, a widely used open-source vulnerability scanner owned by Aqua Security, by injecting credential-stealing malware into official releases and GitHub Actions. TeamPCP subsequently injected the same malware into Checkmarx's KICS scanner through GitHub Actions and OpenVSX extensions. Later, researchers discovered TeamPCP targeted LiteLLM AI Gateway, a popular Python library for AI model integration. A fourth TeamPCP campaign affected the Telnyx Python package on PyPI and led, once again, to the delivery of credential-stealing malware.

TeamPCP’s attack spree slows, but threat escalates with ransomware pivot TeamPCP’s destructive run of supply chain breaches has stopped, for now: it has been three days since the group published malicious versions of Telnyx’s SDK on PyPI, and there haven’t been reports of new open-source project compromises. Partnership with emerging RaaS operation “The prior operational cadence was aggressive – a new target every 1-3 days (Trivy [on] March 19, CanisterWorm [on] March 20-22, Checkmarx [on] March 23, LiteLLM [on] March 24, Telnyx [on] March 27),” SANS instructor Kenneth Hartman noted. “The current pause, combined with the Vect ransomware affiliate announcement, suggests TeamPCP has shifted primary operational focus from supply chain expansion to monetization of existing credential harvests.” The announcement in question has been made by Vect, a new ransomware-as-a-service (RaaS) operation, on BreachForum, which is a known “hangout” for cybercriminals. They revealed their plan to make all BreachForum members their affiliates (by providing a “Vect Affiliation Key”), and their partnership with TeamPCP. “Together, we are ready to deploy ransomware across all affected companies that got hit by these attacks, and we won’t stop there. We will pull off even bigger supply chain operations. We will chain these compromises into devastating follow-on ransomware campaigns,” they boasted. The threat is real. According to Hartman, there has already been a first confirmed Vect ransomware deployment using TeamPCP-sourced credentials. TeamPCP’s rapid evolution TeamPCP emerged in 2024 and focused on targeting and compromising misconfigured Docker APIs, Kubernetes clusters, Ray dashboards, and Redis servers to steal credentials and deploy cryptominers. In 2025, they started building their capacity for automated supply chain attacks. “In late 2025 they deployed CanisterWorm, a self-propagating worm that used ICP Canister nodes as decentralized, censorship-resistant C2 infrastructure — the first observed use of this technique in the wild. In early 2026, destructive payloads with geotargeting logic appeared, combining credential theft with region-specific destruction,” says the OpenSourceMalware team. “The March 2026 campaign represents the culmination: a cascading chain through five vendor ecosystems seeded by a single retained credential [from a previous Trivy compromise].” They demonstrated their adaptibility even during these latest supply chain attacks. “In just eight days, the actor has pivoted across security scanners, AI infrastructure, and now telecommunications tooling evolving their delivery from inline Base64 to .pth auto-execution, and ultimately to split-file WAV steganography, while also expanding from Linux-only to dual-platform targeting with Windows persistence,” Trend Micro researchers noted in the wake of the Telnyx compromise. Hartman also documented another of the group’s innovative techniques: the use of the GitHub Releases API as a fallback data exfiltration channel during a supply chain compromise. TeamPCP’s attacks ripple through dependencies Hartman pointed out that TeamPCP’s pause in supply chain compromises should not be interpreted as the end of the group’s supply chain operations. “TeamPCP explicitly stated they intend to be ‘around for a long time,’ and stolen credentials from the estimated 300 GB trove could enable future package compromises at any time. The absence of new compromises may also reflect improved vigilance by package registries – PyPI has quarantined two TeamPCP campaigns in rapid succession, which may be raising the attacker’s cost of operations on that platform.” Open-source maintainers must realize that TeamPCP is an eminently capable attack group and should take steps to secure their projects. “This incident also exposes the absolute stupidity of blindly updating to the latest package versions. The obsession with using the newest patch the second it drops is a massive vulnerability,” Trend Micro researchers also opined. “If your CI/CD pipeline automatically pulls the newest release without a quarantine period, you are automating your own breach. Pin your dependencies to cryptographic hashes. Let someone else’s infrastructure test the newest release for supply chain malware first.” GitGuardian reseachers have analyzed how TeamPHP’s supply chain attacks spread through dependencies and automation pipelines, and found that: 474 public repositories executed malicious code from the compromised trivy-action (CI/CD component) 1,750 Python (PyPI) packages were set up in a way that would automatically pull the poisoned LiteLLM versions Those numbers are not definitive – i.e., they are likely bigger – because they did not (could not) analyze private GitHub repositories, and they limited their search to Python packages with direct dependency of LiteLLM. “The package could have been included through a longer dependency chain. Looking for the exact digest of the malicious packages is the only way to determine if the dependency was downloaded on a given machine,” they pointed out, and shared the malicious packages’ SHA256 digests for organizations to use when investigating. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

This is the fourth update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 003 covered developments through March 28, including the first 48-hour pause in new compromises and the campaign's shift to monetization. This update consolidates intelligence from March 28-30, 2026 -- two days since our last update. HIGH: Databricks Investigating Alleged Compromise Linked to TeamPCP Credential Harvest CybersecurityNews reports that Databricks, the cloud data analytics platform, is investigating an alleged security compromise linked to the TeamPCP credential harvest. International Cyber Digest stated on X that they "notified them last week" and Databricks "scaled up to investigate." A separate analyst corroborated that screenshots showing AWS artifacts, CloudFormation dumps, and STS tokens "match TeamPCP's exact playbook." Databricks has not issued an official statement. If confirmed, this would be the first major cloud platform identified as a downstream victim of TeamPCP's credential trove -- distinct from the security tool vendors (Aqua, Checkmarx, BerriAI, Telnyx) directly compromised in the supply chain phase. The distinction matters: tool vendor compromises expanded TeamPCP's credential pool, while a Databricks compromise would represent the monetization of that pool against an enterprise target processing sensitive data across AWS, GCP, and Azure. Update (2026-03-30): Databricks' Head of Global Communications and their external PR agency FGS Global have confirmed the authenticity of the new @DatabricksSec X account. In their https://x.com/DatabricksSec/status/2038649955401794042, Databricks says they "thoroughly investigated this information in our internal systems and found nothing" and have "asked for more information beyond this screenshot." They state they will "transparently continue to share any new updates on all security matters." Recommended action: Organizations using Databricks should monitor for an official statement. If your CI/CD pipelines were exposed to any TeamPCP-compromised component AND those pipelines had access to Databricks credentials, treat those credentials as potentially compromised regardless of whether Databricks confirms the breach. HIGH: TeamPCP Operates Dual Ransomware Tracks - CipherForce Is Their Own Operation Update 002 documented TeamPCP's partnership with the Vect ransomware-as-a-service operation and BreachForums mass affiliate key distribution. New intelligence reveals that Vect is not TeamPCP's only ransomware channel. According to Flare and corroborated by Rami McCarthy's IOC tracker, TeamPCP operates under five confirmed aliases: PCPcat, ShellForce, DeadCatx3, CipherForce, and Persy_PCP. TeamPCP's own Telegram channel states: "you may already know us as TeamPCP or Shellforce... CipherForce is a newer project we are starting to find affiliates." CipherForce is TeamPCP's own ransomware operation, separate from the Vect partnership. This means TeamPCP is running two parallel ransomware tracks simultaneously: their proprietary CipherForce program for direct operations, and the mass Vect affiliate program via BreachForums for distributed operations. The SANS ISC Stormcast for March 30 also notes "more and more links between the TeamPCP crew and various ransomware actors" -- plural -- consistent with this dual-track model. Analysts assess this dual-track approach allows TeamPCP to maintain direct control over high-value targets (via CipherForce) while simultaneously flooding the ecosystem with mass affiliate operations (via Vect). The 300 GB stolen credential trove can feed both tracks simultaneously. Recommended action: Detection teams monitoring for Vect ransomware indicators should also add CipherForce to their watchlist. The strongest attribution link across all TeamPCP operations is a shared RSA-4096 public key embedded in payloads -- search for this key in forensic artifacts from any suspected TeamPCP exposure. HIGH: LAPSUS$ Releases AstraZeneca Data Free After Failed Sale Attempt The LAPSUS$/AstraZeneca breach claim documented in Updates 002-003 has escalated. Cybernews and Cybersecurity Insiders report two developments: LAPSUS$ released the claimed 3 GB archive for free after failing to find buyers via Session encrypted messaging. This shifts the incident from an extortion attempt to a full data exposure event. Cybernews research team has partially verified the dump's contents -- GitHub user information for internal AstraZeneca software developers, employee data spanning clinical research subsidiaries, and internal source code tree structures were assessed as consistent with legitimate AstraZeneca infrastructure. AstraZeneca has still not issued any public statement confirming or denying the breach at approximately 96 hours since the initial claim. Analysts assess that AstraZeneca's continued silence, combined with GDPR obligations if EU employee data is in the dump, creates increasing regulatory exposure with each passing day. Recommended action: Organizations should treat this as a probable confirmed breach for defensive planning purposes. If your organization shares integrations, data, or credentials with AstraZeneca, assess whether the exposed repository structures and configurations could affect your security posture. Given AstraZeneca's clinical research operations, the dump may contain protected health information (PHI) subject to HIPAA in the US and GDPR in the EU. Organizations with data-sharing agreements with AstraZeneca should evaluate whether their data may be in the exposed archive and prepare breach notification workflows accordingly. MEDIUM: ownCloud Discloses Build Infrastructure Impact From CVE-2026-33634 ownCloud published a security notice confirming their build infrastructure -- the systems producing container images and client binaries -- was affected by CVE-2026-33634 (the Trivy compromise). ownCloud confirms: no customer data compromised, no source code altered, impact limited to build systems only. This is one of the first named downstream organizations to publicly disclose that they were in the blast radius of the Trivy supply chain compromise. The disclosure is notable for its transparency -- most affected organizations have remained silent despite the CISA KEV entry and federal remediation deadline of April 8. Recommended action: Organizations using ownCloud should review the security notice and verify their deployments are using images produced after the remediation. More broadly, ownCloud's disclosure should prompt other organizations that used Trivy in their build pipelines between March 19-22 to conduct their own impact assessments and consider similar disclosure. MEDIUM: Supply Chain Pause Extends Past 96 Hours No new package compromises across any ecosystem have been publicly reported since the Telnyx PyPI disclosure on March 27, extending the supply chain pause documented in Update 003 past 96 hours. This is the longest quiet period since TeamPCP began active supply chain operations on March 19. Expanded ecosystem search results (March 30): An independent search of RubyGems, crates.io, and Maven Central -- the three ecosystems identified as plausible expansion targets in Update 003 -- found zero TeamPCP-related IOCs in any of them. The RubyGems, crates.io, and Maven Central watch items remain "Not observed." While the CanisterWorm's propagation technique is registry-agnostic (any stolen publish token would work), there is no evidence TeamPCP has moved beyond the five confirmed ecosystems (GitHub Actions, PyPI, npm, Docker Hub/GHCR, OpenVSX). Note on sourcing: CybersecurityNews listed "NPM and OpenVSX" alongside the other compromised ecosystems in their Databricks article. These are accurate in the sense that both ecosystems were hit, but they refer to the known CanisterWorm npm worm (March 20, 66+ packages) and the Checkmarx OpenVSX extensions (March 23, ast-results and cx-dev-assist) -- not new compromises. No new npm or OpenVSX activity has been documented since the original incidents. Recommended action: Use this supply chain pause as a remediation window. The CISA KEV deadline for CVE-2026-33634 is now 9 days away (April 8, 2026). Complete credential rotations and IOC sweeps before the deadline. HIGH: Campaign Transitions to Three Parallel Monetization Tracks While supply chain poisoning has paused, TeamPCP is not dormant. Analysts assess the group has completed its supply chain expansion phase and transitioned fully to credential exploitation and monetization. Three distinct operational tracks are now running simultaneously: Direct credential exploitation against high-value targets -- the Databricks investigation (see above) represents the first alleged downstream victim of the ~300 GB stolen credential trove, distinct from the tool vendors directly compromised in the supply chain phase. Proprietary ransomware via CipherForce -- TeamPCP's own ransomware operation, with recruitment via their Telegram channel. No confirmed deployments yet, but the infrastructure and affiliate recruitment are active. Mass affiliate ransomware via Vect/BreachForums -- Distributed operations leveraging the BreachForums mass affiliate key distribution documented in Update 002. The distribution window is now ~96 hours with no confirmed deployments. The distinction between these tracks matters for defenders: detection teams monitoring for Vect ransomware indicators should also add CipherForce to their watchlist. The shared RSA-4096 public key embedded in payloads is the strongest attribution link across all TeamPCP operations. INFO: Cloud Security Alliance Publishes Second Research Note on AI/ML Supply Chain Risk The Cloud Security Alliance AI Safety Initiative published a research note on March 29 framing the TeamPCP campaign as a structural shift in adversary methodology -- from opportunistic typosquatting to deliberate pipeline compromise of trusted AI/ML packages. The note assesses that "the economics of targeting high-value AI credential stores are accelerating adversary investment." This is the second CSA publication covering TeamPCP (the first was the Kubernetes wiper lab analysis documented in Update 003) and focuses specifically on the AI/ML ecosystem implications rather than technical TTPs. Watch Item Status 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.

This is the third update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 002 covered developments through March 27, including the Telnyx PyPI compromise and Vect ransomware partnership. This update covers developments from March 27-28, 2026. HIGH: First 48-Hour Window Without a New Supply Chain Compromise The most operationally significant development in the last 24 hours is what did not happen: no new package compromises have been confirmed since the Telnyx disclosure on March 27. This is the first 48-hour window without a new ecosystem compromise since TeamPCP began active operations on March 19. The prior operational cadence was aggressive -- a new target every 1-3 days (Trivy March 19, CanisterWorm March 20-22, Checkmarx March 23, LiteLLM March 24, Telnyx March 27). The current pause, combined with the Vect ransomware affiliate announcement, suggests TeamPCP has shifted primary operational focus from supply chain expansion to monetization of existing credential harvests. Analysts assess this pause should not be interpreted as the end of supply chain operations. TeamPCP explicitly stated they intend to be "around for a long time," and stolen credentials from the estimated 300 GB trove could enable future package compromises at any time. The absence of new compromises may also reflect improved vigilance by package registries -- PyPI has quarantined two TeamPCP campaigns in rapid succession, which may be raising the attacker's cost of operations on that platform. Recommended action: Maintain heightened monitoring posture. Use this operational window to complete credential rotations and IOC sweeps if not already done. The CISA KEV remediation deadline for CVE-2026-33634 is now 11 days away (April 8, 2026). HIGH: Palo Alto Networks Publishes Behavioral Detection Rules for CI/CD Pipeline Attacks Palo Alto Networks has published detection rules specifically designed to identify TeamPCP-style CI/CD pipeline attacks at the behavioral level rather than relying solely on IOC matching. This is significant because TeamPCP has demonstrated the ability to rotate infrastructure across each new compromise wave -- each phase used different C2 domains, different exfiltration endpoints, and different packaging techniques (raw scripts, npm worm, .pth exploitation, WAV steganography). Behavioral detection approaches focus on anomalous CI/CD runner behavior: unexpected credential directory enumeration, bulk secret reads from /proc/ /mem, large encrypted archive creation, and outbound data transfers to newly registered domains during workflow execution. These patterns have been consistent across all five TeamPCP compromise phases even as specific IOCs changed. Recommended action: Organizations with Palo Alto Networks security products should review and deploy the published detection rules. All organizations should evaluate whether their CI/CD monitoring can detect the behavioral patterns described -- process memory reads of Runner.Worker, creation of tpcp.tar.gz or similarly named archives, and outbound HTTPS to domains registered within the past 30 days. MEDIUM: Cloud Security Alliance Publishes Kubernetes Wiper Lab Analysis The Cloud Security Alliance has published a detailed lab analysis of TeamPCP's Kubernetes wiper component -- the Iran-targeted DaemonSet that deletes all host filesystem contents when Farsi language settings are detected. The analysis reconstructs the wiper's deployment mechanism and provides detection queries for Kubernetes audit logs. This component was mentioned in the parent report but has received less attention than the credential-stealing payloads. The CSA analysis provides the first detailed defensive playbook specifically for the wiper TTP, including Kubernetes admission controller policies that would block the privileged DaemonSet deployment pattern. Recommended action: Kubernetes operators should review the CSA analysis and implement admission controller policies that prevent privileged DaemonSets from mounting hostPath / with write access. This is good hygiene regardless of TeamPCP exposure. MEDIUM: GitGuardian Quantitative Analysis Maps Credential Exposure Blast Radius GitGuardian has published a quantitative "snowball effect" analysis tracing how a single compromised token cascaded across ecosystems. The analysis maps the amplification factor at each stage: one stolen PAT led to 76+ poisoned GitHub Action tags, which harvested credentials from hundreds of CI/CD pipelines, which enabled compromise of packages with a combined 100+ million monthly downloads. The analysis introduces a metric they call "credential fan-out" -- the ratio of credentials stolen to credentials used for initial access. For TeamPCP, this ratio is estimated at greater than 10,000:1, meaning each compromised credential potentially exposed thousands of downstream secrets. This quantitative framing is useful for communicating risk to executive stakeholders who need to understand why a single supply chain compromise requires organization-wide credential rotation. INFO: Deep Analysis of GitHub Repository-Based Exfiltration Technique Published I have published a detailed analysis of TeamPCP's novel GitHub repository-based data exfiltration technique. The post examines how the campaign used the GitHub Releases API as a fallback exfiltration channel -- programmatically creating repositories on the victim's own account and uploading stolen data as release assets. This technique is significant because corporate firewalls and DLP solutions that whitelist api.github.com traffic cannot distinguish this exfiltration from legitimate GitHub API usage. The analysis includes organizational controls, alternative attack permutations, and threat hunting queries. INFO: AstraZeneca Breach Claim Remains Unconfirmed at 48 Hours LAPSUS$'s claimed 3GB AstraZeneca breach (reported in Update 002) remains unconfirmed. Security Affairs characterized the claim as "potentially one of the most serious healthcare cyber incidents this year" if verified. AstraZeneca has not issued a public statement confirming or denying the breach as of March 28, 2026. No additional named victim claims have been disclosed in the past 24 hours, though the Vect affiliate program distribution may shift the extortion model from centralized TeamPCP/LAPSUS$ operations to distributed affiliate-driven campaigns that are harder to track. Watch Item Status Updated Watch Items First confirmed Vect ransomware deployment using TeamPCP-sourced credentials -- this is the highest-priority indicator of the campaign's next phase Additional named victim disclosures beyond AstraZeneca -- distributed affiliate model may produce claims from multiple actors simultaneously Law enforcement action -- 10 days into an active campaign affecting federal systems with no public enforcement response PyPI and npm registry-level proactive scanning -- both registries have only responded reactively (quarantining packages after disclosure); an announcement of proactive malicious package scanning or signing requirements would signal a meaningful shift in supply chain defense posture CISA KEV deadline compliance (April 8, 2026) -- 11 days remaining 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.

TeamPCP, the threat actor behind the supply chain attack targeting Trivy, KICS, and litellm, has now compromised the telnyx Python package by pushing two malicious versions to steal sensitive data. The two versions, 4.87.1 and 4.87.2, published to the Python Package Index (PyPI) repository on March 27, 2026, concealed their credential harvesting capabilities within a .WAV file. Users are recommended to downgrade to version 4.87.0 immediately. The PyPI project is currently quarantined. Various reports from Aikido, Endor Labs, JFrog, Ossprey Security, SafeDep, Socket, and StepSecurity indicate the malicious code is injected into "telnyx/_client.py," causing it to be invoked when the package is imported into a Python application. The malware is designed to target Windows, Linux, and macOS systems. "Our analysis reveals a three-stage runtime attack chain on Linux/macOS consisting of delivery via audio steganography, in-memory execution of a data harvester, and encrypted exfiltration," Socket said. "The entire chain is designed to operate within a self-destructing temporary directory and leave near-zero forensic artifacts on the host." On Windows, the malware downloads a file named "hangup.wav" from a command-and-control (C2) server and extracts from the audio data an executable that's then dropped into the Startup folder as "msbuild.exe." This allows it to persist across system reboots and automatically run every time a user logs in to the system. In case the compromised host runs on Linux or macOS, it fetches a different .WAV file ("ringtone.wav") from the same server to extract a third-stage collector script and run. The credential harvester is designed to capture a wide range of sensitive data and exfiltrate the data in the form of "tpcp.tar.gz" via an HTTP POST request to "83.142.209[.]203:8080." "The standout technique in this sample - and the reason for the post title - is the use of audio steganography to deliver the final payload," Ossprey Security said. "Rather than hosting a raw executable or a base64 blob on the C2 (both of which are trivially flagged by network inspection and EDR), the attacker wraps the payload inside a .WAV file." "This is almost identical to the sample observed in the LiteLLM malware, with one key difference: instead of embedding the malicious code as Base64, they now download it from a remote server," OX Security's Moshe Siman Tov Bustan said. "The malware downloads an XOR-obfuscated WAV file from a remote C2 server, decodes it, and then executes it on the target machine." It's worth noting that the .WAV trick isn't new to TeamPCP. The same methodology was previously used to conceal the malicious payload in the "kamikaze" wiper malware distributed via CanisterWorm and exposed Docker instances. In addition, the malware features a Kubernetes lateral movement component that abuses Kubernetes service account tokens to deploy a privileged pod to every node and deploy a persistence mechanism. It's currently not known how the package's PYPI_TOKEN was obtained by TeamPCP, but it's likely that it was through a prior credential harvesting operation. "We believe the most likely vector is the litellm compromise itself," Endor Labs researchers Kiran Raj and Rachana Misal said. "TeamPCP's harvester swept environment variables, .env files, and shell histories from every system that imported litellm. If any developer or CI pipeline had both litellm installed and access to the telnyx PyPI token, that token was already in TeamPCP's hands." In a security notice shared on its website, the maintainers of the Python package said both unauthorized versions have been removed from PyPI and that users are likely to be affected if they installed or upgraded the library between 03:51 UTC and 10:13 UTC on March 27, 2026. Telnyx said it's also investigating how the publishing credentials were obtained by the threat actors. What's notable about the attack is the absence of a persistence mechanism in Linux and macOS and the use of a temporary directory to conduct the malicious actions and recursively delete all its contents once everything is complete. "The strategic split is clear. Windows gets persistence: a binary in the Startup folder that survives reboots, providing the threat actor with long-term, repeatable access," Socket explained. "Linux/macOS gets smash-and-grab: a single, high-speed data harvesting operation that collects everything of value and exfiltrates it immediately, then vanishes." The development comes a few days after the threat actor distributed trojanized versions of the popular litellm Python package to exfiltrate cloud credentials, CI/CD secrets, and keys to a domain under its control. The supply chain incident also reflects a new-found maturation, where the threat actor has consistently infected legitimate, trusted packages with massive user bases to distribute malware to downstream users and widen blast radius, rather than directly publishing malicious typosquats to open-source package repositories. "The target selection across this campaign focuses on tools with elevated access to automated pipelines: a container scanner (Trivy), an infrastructure scanning tool (KICS), and an AI model routing library (litellm)," Snyk said. "Each of these tools requires broad read access to the systems it operates on (credentials, configs, environment variables) by design." To mitigate the threat, developers are advised to perform the following actions - Audit Python environments and requirements.txt files for telnyx==4.87.1 or telnyx==4.87.2. If found, replace them with a clean version. Assume compromise and rotate all secrets. Look for a file named "msbuild.exe" in the Windows Startup folder. Block the C2 and exfiltration domain ("83.142.209[.]203"). The compromise is part of a broader, ongoing campaign undertaken by TeamPCP spanning multiple ecosystems, with the threat actor announcing collaborations with other cybercriminal groups like LAPSUS$ and an emerging ransomware group called Vect to conduct extortion and ransomware operations. "Supposedly, the group harvested a ton of credentials over the course of the last few attacks, and teaming up allows scaling/accelerating their (ab)use before all the victims completed remediation," Henrik Plate, head of security research at Endor Labs, told The Hacker news. "Depending on the credentials, 'downstream threat actors' will continue according to their focus, e.g., ransomware attacks." This also signals a shift where ransomware gangs, which have historically focused on initial access methods like phishing and exploitation of security flaws, are now weaponizing supply chain attacks targeting the open source infrastructure as an entry point for follow-on attacks. "This puts a spotlight on anything in CI/CD environments that isn’t locked down," Socket said. "Security scanners, IDE extensions, build tooling, and execution environments are granted broad access because they’re expected to need it. When attackers are targeting the tools themselves, anything running in the pipeline has to be treated as a potential entry point."

TeamPCP has again expanded its supply chain attacks on open-source repositories by targeting Telnyx, according to security researchers. The cyber threat group recently rose to notoriety by uploading malicious packages to Python Package Index (PyPI), the official online repository where developers share and download Python software packages. The group typically uses typosquatting to trick developers into downloading them. In one campaign, the group targeted Trivy, a widely used open-source vulnerability scanner owned by Aqua Security, by injecting credential-stealing malware into official releases and GitHub Actions. A few days later, researchers discovered TeamPCP targeted LiteLLM AI Gateway, a popular Python library for AI model integration. Now, a third TeamPCP campaign has been identified which affects the Telnyx Python package on PyPI and leads to the delivery of credential-stealing malware. Telnyx is a cloud communications platform that provides application programming interfaces (APIs) for phone calls, SMS, MMS and other telecom services. TeamPCP’s Telnyx Compromise Campaign Explained On March 27, researchers from both Socket and Endor Labs published findings revealing that the official Telnyx Python software development kit (SDK) had been compromised in a software supply chain attack. Socket researchers identified that the telnyx package, a legitimate and widely used Python SDK for the Telnyx communications platform, had been tampered with. The malicious versions published to PyPI – versions 4.87.1 and 4.87.2 – contained code designed to exfiltrate sensitive information from victim environments. “They should not be used,” warned the Socket Research Team, whose members confirmed that researchers at Aikido Security and Wiz, now part of Google Cloud, independently came to the same conclusions. Socket found that the attacker had injected functionality to steal SSH private keys and bash history files from compromised systems, sending that data to an attacker-controlled remote server. The malicious payload was designed to execute at install time, meaning a developer or automated pipeline simply installing or updating the package would trigger the attack without needing to import or run any of the package's actual functionality. Endor Labs researchers confirmed Socket’s findings and further explained that the threat actor gained the ability to publish malicious versions of the telnyx package by compromising the credentials of a maintainer account. This is a particularly dangerous attack vector because it does not require vulnerabilities in PyPI's infrastructure itself to be exploited. Instead, the attacker leveraged legitimate publishing access to push trojanized versions that would appear authentic to any automated or manual dependency resolution process. Because the package retained its legitimate name and continued to function as expected for its intended purpose, detection through casual inspection or functional testing would be extremely difficult. Socket researchers noted that the injected payload specifically targeted files that would be of high value in a lateral movement or credential harvesting context. SSH private keys would allow an attacker to pivot to other systems the victim has access to, while bash history files could expose commands containing credentials, server addresses, internal tooling or other sensitive operational information. The data exfiltration was performed over HTTP to an external endpoint controlled by the attacker. Telnyx Campaign Reflects TeamPCP's Growing Sophistication Endor Labs researchers emphasized that the pattern exhibited by TeamPCP reflects a maturation in supply chain attack methodology. Rather than relying solely on typosquatting, which depends on a developer making a naming mistake, this actor has demonstrated the capability and willingness to directly compromise legitimate, trusted packages with real user bases. Endor Labs researchers argued that this significantly raises the risk profile because developers and security teams who explicitly trust a known package and pin to it by name are not protected against this class of attack. Additionally, the three-day interval between the LiteLLM and Telnyx compromises further suggested that the actor was actively iterating and moving quickly across targets rather than executing a single opportunistic event. According to Socket, TeamPCP has recently started partnering with the Vect ransomware group to turn supply chain compromises into large-scale ransomware operations. Socket and Endor Labs researchers recommended that organizations audit their environments for the presence of the malicious versions and rotate any credentials or keys that may have been exposed on systems where the compromised package was installed.

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.

Betti RHC, la prima graphic novel al mondo dedicata alla cybersecurity awareness, ha finalmente il suo sito ufficiale. Uno spazio tutto suo dove scoprire il progetto, sfogliare le copertine degli episodi e immergersi nel mondo di Betti: la giovane laureanda in informatica che, dopo la morte misteriosa del padre, si trasforma nell'hacker più potente del mondo. Una storia avvincente che, episodio dopo episodio, affronta una minaccia digitale diversa — dal phishing al ransomware, fino al cyberbullismo — e insegna a riconoscerla e a difendersi, senza che sembri mai una lezione. Sul sito trovate tutto ciò che rende Betti un progetto diverso dal solito: la sua filosofia, le anteprime delle tavole e il racconto di come nasce ogni volume. Perché dietro Betti RHC c'è solo lavoro umano: ogni tavola è disegnata interamente a mano dagli artisti del Gruppo Arte di Red Hot Cyber, senza alcun uso di intelligenza artificiale. E a garantire che ogni storia sia realistica e tecnicamente corretta c'è la supervisione degli hacker etici del gruppo HackerHood, che mantengono il racconto fedele al mondo reale della sicurezza informatica. C'è spazio anche per le aziende, che possono usare Betti come strumento di awareness diverso dai soliti corsi: acquistare i volumi, personalizzarli con il proprio brand o sponsorizzare nuovi episodi. E come primo regalo, l'episodio "Byte the Silence", dedicato al cyberbullismo, è scaricabile gratuitamente per uso personale. Perché la miglior difesa, in fondo, è una bella storia. 👉 Scopri tutto su https://betti.redhotcyber.com/

Security researchers have discovered a new ransomware-as-a-service (RaaS) group which has already victimized organizations in Brazil and South Africa. Dubbed “Vect,” the group is currently onboarding affiliates after launching a recruitment program in December 2025, according to ransomware specialist Halcyon. The group has claimed that its malware was built using C++ rather than repurposing leaked source code from the likes of Lockbit 3.0 or Conti, as is more common. It uses the ChaCha20-Poly1305 AEAD encryption algorithm, which is said to be two-and-a-half-times faster than AES-256-GCM on systems without hardware acceleration. It is deployed using intermittent encryption techniques, whereby only blocks of data are scrambled for speed. “Despite its short lifespan, the group shows unusual maturity, advertising cross-platform ransomware targeting Windows, Linux and VMware ESXi, Safe Mode execution to suppress security tools, and fast intermittent encryption designed for speed and disruption,” Halcyon claimed. “Vect appears to be in an early validation phase, with two claimed victims in Brazil and South Africa, and is likely testing capabilities ahead of broader expansion.” The affiliate revenue-sharing model is apparently a “generous” one, with a $250 entry fee waived for applicants inside the Commonwealth of Independent States (CIS) – hinting at the group’s location. The maturity of the operation signals that it’s being run by some experienced RaaS players, claimed a separate analysis by Red Piranha. “The group's operational security is notable, utilising Monero for payments to maintain financial anonymity, TOX protocol for encrypted peer-to-peer affiliate communications, and exclusively TOR hidden services for infrastructure with no clearnet presence,” Red Piranha explained in a research note. “This combination of custom-built malware, modern encryption, multi-platform capabilities, and strong OPSEC measures suggests Vect is operated by experienced threat actors who may represent a rebrand or new venture by established ransomware affiliates.” The vendor added that initial access is likely achieved via exposed RDP/VPN, stolen credentials, phishing or vulnerability exploitation. Vect operates a classic double extortion model, with both of its victims to date apparently being listed on its public-facing leak site. Mitigations to Consider Halcyon recommended network defenders observe the following to reduce the risk posed by Vect: Harden edge appliances against initial access: This should include Fortinet accounts and management interfaces, as Vect has been requesting compromised Fortinet accounts on a Russian-speaking forum. Apply updates promptly, restrict admin exposure, and enforce strong authentication for all remote and privileged access Contain the threat across Windows, Linux and VMware ESXi: Segment management networks, restrict access to hypervisor management planes, and limit lateral movement paths through administrative protocols and file shares Focus detection on Safe Mode and intermittent encryption: Increase monitoring for suspicious Safe Mode boots, and rapid, selective file encryption patterns indicating intermittent encryption. Centralize and review relevant logs and telemetry for speedy scoping and containment Deploy anti-ransomware controls: Use a solution that blocks execution of malicious binaries before they run, detects and prevents ransomware runtime behavior and data exfiltration attempts, and blocks tampering and network intrusion