Skip to content

VECT Ransomware by design, Wiper by accident#2179

Open
carlospolop wants to merge 1 commit intomasterfrom
update_VECT__Ransomware_by_design__Wiper_by_accident_20260428_193227
Open

VECT Ransomware by design, Wiper by accident#2179
carlospolop wants to merge 1 commit intomasterfrom
update_VECT__Ransomware_by_design__Wiper_by_accident_20260428_193227

Conversation

@carlospolop
Copy link
Copy Markdown
Collaborator

🤖 Automated Content Update

This PR was automatically generated by the HackTricks News Bot based on a technical blog post.

📝 Source Information

  • Blog URL: https://research.checkpoint.com/2026/vect-ransomware-by-design-wiper-by-accident/
  • Blog Title: VECT: Ransomware by design, Wiper by accident
  • Suggested Section: Basic Forensic Methodology -> Malware Analysis (or Crypto -> Symmetric Crypto / Stream ciphers pitfalls) : add a page/section on ransomware partial-encryption stream-cipher nonce persistence bugs (ChaCha20-IETF without AEAD) and how to spot it via file format/reversing

🎯 Content Summary

What the post is about
Check Point Research (CPR) analyzes the VECT Ransomware-as-a-Service (RaaS) ecosystem and its cross-platform “locker” payloads, and identifies a fundamental cryptographic implementation flaw that makes VECT behave like a data wiper for most real-world files. VECT first appeared on Russian-language forums in December 2025, claimed victims in January 2026, and released VECT 2.0 in February 2026. The operation also announced partn...

🔧 Technical Details

When implementing partial file encryption with a stream cipher (e.g., ChaCha20-IETF), each independently encrypted region must have its own persisted nonce. If the code generates a fresh random nonce per chunk but stores it in a shared buffer that is overwritten in a loop—and then writes only the final buffer value (e.g., appends a single nonce at EOF)—earlier encrypted chunks become irreversibly undecryptable, effectively turning “ransomware” into a wiper for files above the chunking threshold. To validate what a sample actually implements, confirm the cipher/mode by inspecting the file format (e.g., absence of a Poly1305 16-byte tag indicates no AEAD) and verify that operator “mode” flags influence real code paths (flags that are parsed but never read are cosmetic and do not change encryption behavior). Finally, SSH-based worm propagation can be built by harvesting readable private keys, parsing /etc/ssh/ssh_config and ~/.ssh/config for ...

🤖 Agent Actions

I’m mapping the repo first and then I’ll read the most relevant existing pages before choosing a single file to update. After that I’ll verify whether the nonce-loss pitfall is already covered anywhere so I don’t duplicate content.
The repo has a strong fit under forensics, but I’m still checking whether crypto-focused or file-format triage pages already cover this exact stream-cipher failure pattern. Next I’m reading several candidate pages and looking for existing ransomware-specific triage guidance.
I’ve confirmed there isn’t an obvious existing page for this exact nonce-persistence bug, so I’m checking the crypto section before deciding whether the better fit is “how to reverse/spot it” or “how the cipher misuse works.” The likely constraint is the single-file rule, so placement matters more than breadth.
I’ve settled on malware-analysis.md. The new content will stay narrowly focused on a reusable DFIR/reversing pattern: how to recognize partial-encryption ransomware that uses a stream cipher correctly per chunk in memory but fails to persist all chunk nonces on disk, making recovery impossible.
The edit is in place. I’m re-reading the modified section and the tail of the file now to make sure the placement is clean, the references stay at the end, and the content doesn’t duplicate an adjacent section.
Updated malware-analysis.md with a new DFIR/reversing section on partial-encryption ransomware that loses per-chunk stream-cipher nonces. I placed it there instead of the crypto section because the useful abstraction from the VECT post is analyst triage: identify raw crypto_stream_chacha20_ietf_xor, distinguish it from AEAD by the missing Poly1305 tag, verify whether parsed mode flags affect real code paths, and determine which file regions are permanently unrecoverable.

I kept the change to a single file, added the Check Point post plus libsodium and RFC 8439 as references, and verified the final file layout and diff. No test run was needed for this markdown-only update.


This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.

@carlospolop
Copy link
Copy Markdown
Collaborator Author

🔗 Additional Context

Original Blog Post: https://research.checkpoint.com/2026/vect-ransomware-by-design-wiper-by-accident/

Content Categories: Based on the analysis, this content was categorized under "Basic Forensic Methodology -> Malware Analysis (or Crypto -> Symmetric Crypto / Stream ciphers pitfalls) : add a page/section on ransomware partial-encryption stream-cipher nonce persistence bugs (ChaCha20-IETF without AEAD) and how to spot it via file format/reversing".

Repository Maintenance:

  • MD Files Formatting: 972 files processed

Review Notes:

  • This content was automatically processed and may require human review for accuracy
  • Check that the placement within the repository structure is appropriate
  • Verify that all technical details are correct and up-to-date
  • All .md files have been checked for proper formatting (headers, includes, etc.)

Bot Version: HackTricks News Bot v1.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant