VECT 2.0 looks like ransomware. Ransom note, negotiation portal, affiliate panel, leak site — the full package. What it doesn’t have is a working decryptor. A bug in how it handles encryption means that for any file above 128 KB — every database, VM disk image, and business document that actually matters — the data is gone. Not locked. Gone. Paying the ransom gets you a decryptor that cannot work.
Check Point Research confirmed this on 28 April 2026, which was cold comfort for the businesses that had already found out the hard way. VECT is part of the two-axis ransomware mutation that’s reshaping the threat landscape — more distribution, less capability, driven by AI tooling. This article covers what VECT is, how the bug turns it from ransomware into a wiper, why payment achieves nothing, what the code quality signals about AI-assisted malware development, how it got into enterprise environments, and what an accurate incident response actually looks like.
What Is VECT 2.0 and Why Did It Get So Much Attention?
VECT 2.0 is a Ransomware-as-a-Service (RaaS) operation that launched in December 2025, targeting Windows, Linux, and VMware ESXi using a shared C++ codebase. It attracted attention for two reasons: an open-affiliate distribution model on BreachForums, and a cryptographic bug that makes it permanently destroy rather than encrypt most enterprise files.
💡 RaaS (Ransomware-as-a-Service) works like SaaS: operators build the payload, panel, and leak site; affiliates carry out the attacks and share revenue. VECT broke from convention by skipping the vetting process entirely.
The affiliate model was the unusual bit. Standard RaaS operations — LockBit being the benchmark — vet affiliates. VECT handed every registered BreachForums member a personal affiliate builder key. No vetting. No track record. No fee.
VECT’s ransom note claimed ChaCha20-Poly1305 AEAD encryption. Check Point Research confirmed no such authentication tag exists in any VECT-encrypted file. That’s marketing, not implementation. For context, this was playing out during the 900-incident month that defined Q1 2026’s threat volume — VECT was a high-profile variant in a historically elevated period.
The Encryption Bug That Turned Ransomware Into a Wiper
VECT uses ChaCha20-IETF for all file encryption. The library it relies on — libsodium — works correctly. The problem is how VECT manages nonces across multiple encryption passes.
💡 A nonce is a one-time random value that, together with the encryption key, is required to reverse a ChaCha20 encryption pass. Lose the nonce and decryption is computationally impossible — even with the correct key.
For large files, VECT runs four encryption passes at 0%, 25%, 50%, and 75% — intermittent encryption, a standard speed optimisation. Each chunk needs its own 12-byte nonce. Here’s the flaw: VECT writes all four nonces to the same output buffer, so only the final one survives to disk. Three are generated, used, and silently discarded.
Here is what each file size range means for recovery:
- Below 32 KB: Single-pass encryption, one nonce — theoretically decryptable with a working key
- 32 KB to 128 KB: JUMPSEC discovered these files are renamed to
.vectand receive a 12-byte footer, but their contents are never encrypted; data remains plaintext and is recoverable by stripping the footer - Above 128 KB: Four-chunk scheme applies; 75% of content is permanently irrecoverable regardless of whether the attacker cooperates
That silent-skip zone is a significant IR detail that hasn’t been widely reported. Files in this range look encrypted but were never touched — assess them separately before assuming total loss.
Why Paying the Ransom Cannot Recover Your Files
For files over 128 KB, three of four nonces were never saved. As Check Point Research’s Eli Smadja put it: “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 files over 128 KB are the ones that matter most: databases, VM disk images (VMDK, QCOW2, VHD), business documents, email archives. VECT’s ESXi locker targets VMDK images — almost universally hundreds of gigabytes — every one above the threshold. For virtualised infrastructure, the damage is total. JUMPSEC also confirmed the negotiation endpoint returns a 404 — even attempting contact may not be possible.
File recovery versus data leak suppression
Paying cannot restore files over 128 KB. Data exfiltration is a separate extortion threat — VECT’s first victim listing claimed four million emails and 700 GB. Whether to pay to suppress publication is a separate risk-management call. Don’t conflate it with file recovery.
For what changes in incident response when ransomware is a wiper, the no-negotiation decision is made at the technical evidence stage, not after attempting payment.
What the Code Quality Tells Us About AI-Assisted Malware Development
VECT has multiple implementation errors consistent with AI-generated or legacy code. Check Point Research flags AI-assisted development as a likely hypothesis — not a confirmed finding.
CIS geofencing anomaly: VECT exits without encrypting if the system locale matches CIS countries — including Ukraine. Post-2022, professional groups removed Ukraine from that list. Either AI training data still classified Ukraine as CIS, or VECT used a legacy codebase. Either way: unreviewed code.
Double XOR self-cancellation: VECT XORs command-line strings for obfuscation, then XORs them again. XOR twice returns the original value. Strings sit in plaintext — the opposite of what was intended.
Thread over-provisioning: 42 encryptor threads on an 8-CPU machine. LockBit caps at 1–2× CPU count. VECT causes the OS to spend its time on scheduling rather than encrypting, reducing its own speed.
FunkSec (Halcyon, late 2024) is a parallel case: AI assistance, similarly inconsistent quality. The pattern — professional presentation on top of amateur implementation — is becoming a recognisable signature of AI-assisted malware. It is one axis of ransomware’s quantum-AI mutation currently reshaping the threat landscape. VECT’s reach came down to distribution, not sophistication. And that’s where TeamPCP comes in.
How VECT Reached Enterprise Environments Without Direct Intrusion
VECT achieved enterprise-scale reach through a partnership with TeamPCP, the threat group behind March 2026 supply chain attacks on Trivy, Checkmarx KICS, LiteLLM, and Telnyx — tools found in enterprise CI/CD and developer pipelines. Trivy is Aqua Security‘s container security scanner. KICS scans infrastructure-as-code in DevSecOps workflows. LiteLLM is an open-source LLM gateway widely adopted in AI-enabled engineering teams. Telnyx is a cloud communications platform. TeamPCP’s supply chain delivery mechanism is covered in the cluster’s dedicated supply chain article.
The poisoned Trivy artefacts were live for 3–12 hours. Stolen GitHub PATs force-pushed backdoored KICS commits across all 35 version tags. The LiteLLM poisoned versions dropped a .pth file that Python executes at startup — malware on every Python process on the host, regardless of whether LiteLLM was imported.
Once inside, VECT spreads via GPO, WMI, DCOM, SMB, and SSH. Before encryption, it deletes VSS backups via vssadmin delete shadows /all /quiet, then registers under HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\ to persist through reboots into Safe Mode, where most EDR products are inactive.
What VECT Means for How You Respond to a Ransomware Incident
When ransomware is confirmed as a wiper, negotiation comes off the table. The response shifts to backup restoration, forensic investigation, and extortion-threat assessment — a categorically different playbook.
The sequence:
- Confirm the strain: The ransom note (
!!!_READ_ME_!!!.txt),.vectextension, and IOCs from Check Point Research and Halcyon - Assess the file inventory: Above 128 KB is irrecoverable; 32 KB–128 KB may not have been encrypted at all
- Skip ransom negotiation for file recovery: Three independent firms confirm the mathematical impossibility
- Activate backup restoration: VSS backups have been deleted; offline or immutable backups only
- Assess the data leak separately: A separate calculation from file recovery
- Investigate supply chain exposure: Check whether Trivy, KICS, LiteLLM, or Telnyx ran in the pipeline during March 2026; treat all pipeline-accessible credentials from that window as compromised
JUMPSEC put it plainly: “Vect’s incompetence makes it more dangerous. A functional ransomware operation at least offers the possibility of recovery through payment. Vect removes that option entirely.”
Not paying for file recovery is not guidance — it is a technical conclusion. For post-quantum IR planning, the cluster’s IR guide has the full picture.
Frequently Asked Questions
What is a nonce and why does losing it make decryption impossible?
A nonce is a 12-byte one-time random value required alongside the encryption key to reverse a ChaCha20 pass. Without it, decryption is mathematically impossible — even for the attacker who holds the key. VECT overwrites the same nonce buffer four times, so only the last value survives. The other three are cryptographically unpredictable and never stored or transmitted. Permanently gone.
What is the difference between ransomware and a wiper?
Ransomware encrypts files reversibly — payment theoretically enables recovery. A wiper destroys data permanently, whether intentionally (NotPetya) or accidentally (VECT’s nonce flaw). VECT presents as ransomware but behaves as a wiper for files over 128 KB. That distinction matters: wiper incidents remove negotiation as a recovery option entirely.
Does paying the VECT ransom protect against the data leak threat?
Paying cannot restore files over 128 KB. But data exfiltration is a separate extortion threat. If attackers took data before deploying the ransomware — VECT’s first victim listing claimed four million emails and 700 GB — paying may influence whether they publish it. File recovery and data leak suppression are two distinct decisions. Don’t conflate them.
What is the 32 KB to 128 KB “silent skip” zone discovered by JUMPSEC?
JUMPSEC found that files in this range are renamed to .vect and receive a 12-byte footer, but their contents are never encrypted. The data is plaintext and recoverable by removing the footer. A separate bug from the nonce flaw — and one that paradoxically makes a subset of files more recoverable than VECT intended.
Is VECT 2.0 confirmed to be AI-generated code?
No — it is a likely hypothesis, not a confirmed finding. The indicators (double-XOR self-cancellation, thread over-provisioning, Ukraine in the CIS exclusion list, unreachable anti-analysis code) are consistent with AI-generated or unreviewed code, but none is definitive proof.
How do I know if my organisation was exposed via the TeamPCP supply chain attacks?
Check whether your CI/CD pipeline ran Trivy, KICS, LiteLLM, or Telnyx during March 2026. IOCs are in the Check Point Research and Halcyon analyses. Exposure does not mean VECT was deployed — forensic investigation is needed. Treat all pipeline-accessible credentials from that window as compromised regardless.
What files are safe from VECT’s wiper behaviour?
Below 32 KB: single-pass encryption, theoretically recoverable. Between 32 KB and 128 KB: likely never encrypted at all — contents are plaintext, only the extension and footer changed. Above 128 KB — virtually all databases, VM images, business documents, email archives — permanently unrecoverable regardless of payment.
How does VECT’s open-affiliate model on BreachForums differ from normal RaaS?
Standard RaaS operations vet affiliates. VECT gave builder keys to every BreachForums member — no vetting, no precedent. As JUMPSEC noted: “LockBit spent years working on their encryptor before opening the gate to affiliates, whereas Vect have gone straight to opening the gate to anyone.” VECT had no control over what affiliates did with it.
What is intermittent encryption and how did VECT use it?
Intermittent encryption processes portions of each file rather than all of it, reducing the time to render files unreadable. VECT processes four chunks at 0%, 25%, 50%, and 75% offsets. Each chunk needed its own nonce; three of four were discarded. The technique is standard — VECT’s flaw is in the nonce buffer management, not the technique.
Can VECT survive a reboot into Windows Safe Mode?
Yes. VECT registers under HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\ to execute in Safe Mode, where most EDR products are inactive. Rebooting to stop it mid-encryption will not prevent it from continuing when the system restarts.
What is the DEVMAN 3.0 string found in VECT’s binary?
JUMPSEC found “DEVMAN 3.0” in VECT’s console banner — associated with DragonForce ransomware, though JUMPSEC found no functional overlap. Likely code lineage noise or attribution misdirection; one of several signs VECT’s codebase is built from borrowed components.
How does VECT’s thread provisioning compare to professional ransomware?
LockBit caps thread pools at 1–2× CPU count. VECT spawns 42 encryptor threads on an 8-CPU machine. The OS spends its time on thread scheduling rather than encryption. Textbook implementation error — consistent with everything else in VECT’s codebase.
