VECT ransomware: small files decrypt, large files lose their nonces

VECT looks like ransomware. This Windows build also looks like a file-format accident.

For this vect.exe sample, small files are recoverable. The binary contains a static ChaCha20 file key, and each small encrypted .vect file keeps the 12-byte nonce needed to replay the cipher stream. Pair the recovered key with the appended trailer and the encrypted bytes decrypt back to the original content. The validation result is match=true.

Large files do not get the same mercy. The routine encrypts four 32 KiB chunks with four fresh nonces, then appends only the final 12-byte nonce to the file. The first three nonces are overwritten before they ever reach disk.

Check Point Research published the broader VECT 2.0 analysis (opens in new tab) on April 28, 2026. Their report says the Windows, Linux, and ESXi lockers use raw ChaCha20-IETF, process files above 131,072 bytes as four chunks, and save only the last 12-byte nonce. This Windows sample reaches the same boundary through observed file writes and a small-file decrypt check.

For ChaCha20, the key is only half the map. The nonce tells the cipher which stream to replay. Lose the nonce and the encrypted bytes are still there, but the route back to the original content is gone.

That is not a negotiation problem. It is a missing-metadata problem.

Public context

Halcyon described Vect (opens in new tab) as an emerging ransomware-as-a-service operation that began affiliate recruitment in late December 2025 and showed early public victim claims in January 2026. The actor advertised Windows, Linux, and VMware ESXi support, Tor-based affiliate and victim infrastructure, revenue sharing, Safe Mode execution, network discovery, lateral movement, and GPO propagation.

ThreatLocker later obtained panel access (opens in new tab) and documented a working affiliate dashboard with victim profiles, chat, support, payout tracking, and builders for Windows, Linux, and ESXi. The same writeup says the panel listed an exfiltration-only binary as "coming soon" at the time of writing.

Ransomware.live listed 25 VECT victim claims (opens in new tab) when checked on May 2, 2026, with the first discovered claim on January 6 and the latest on April 15. Treat those as leak-site and tracker claims. They help with timing and public footprint; intrusion details need separate confirmation.

The TeamPCP context is the access side of the story. Wiz reported (opens in new tab) TeamPCP activity after supply-chain compromises involving Trivy, KICS, LiteLLM, and Telnyx, with stolen cloud, SSH, Kubernetes, and CI/CD secrets validated and used in victim environments. Unit 42 also described (opens in new tab) the TeamPCP supply-chain campaign against security and developer infrastructure.

That does not make every TeamPCP data claim a VECT locker deployment. It means the access pipeline around VECT is more worrying than the locker code deserves.

Halcyon's later recovery warning (opens in new tab) points at the practical response implication: do not assume payment can restore affected files. The Windows sample below shows why, byte by byte.

Sample overview

The binary's strings expose an operator interface:

The --help path also exposed embedded default credential material:

Windows behavior

Two controlled executions completed cleanly: one targeted folder and one default run.

Observed impact behavior includes:

The embedded PowerShell is built for lateral movement and remote execution. It references admin-share copy to \\$pc\C$\ProgramData\$name, scheduled tasks, CIM/WMI process creation, PowerShell remoting, and remote service creation through sc.exe.

The controlled environment showed the hidden PowerShell GPO/lateral command launch path. Real propagation would need reachable domain peers, shares, or hosts.

Ransom note and contact

The recovered ransom note is 1,656 bytes before impact counters are updated.

File impact

The relevant file routine starts at 0x14006a4b0. It renames the target to a .vect path, opens the file, reads chunks into a shared buffer, encrypts those chunks through 0x140068db0, writes the encrypted bytes back, and then appends one 12-byte trailer.

Representative examples from the default execution:

The same execution also produced malformed edge-case names such as customer-list.csvvect and customer-list.csvvvect. Those are useful as observed file artifacts, but .vect is the primary extension behavior.

The byte-level evidence comes from watching what the malware wrote to encrypted files. One example:

For large-archive.zip.vect, the routine wrote four encrypted 32 KiB chunks at offsets 0, 0x80000, 0x100000, and 0x180000, then wrote one 12-byte trailer at offset 0x200000.

Why small files decrypt

The sample's ransom note says ChaCha20. The code path and file writes agree.

The encrypt/decrypt routine at 0x140068db0 passes the file key into a ChaCha implementation. The ChaCha state uses:

The file key is static in the binary. The encrypted-file format is simple: encrypted bytes plus a per-chunk nonce. Recovery depends on the static key and the correct nonce for the chunk being decrypted.

The decrypt check proves the small-file path. Using the captured quarterly-planning.docx.vect encrypted chunk and its 12-byte trailer, it decrypts the chunk back to the matching original bytes:

That is the clean half of the story. For a file that fits in one encrypted chunk, the appended nonce is enough.

The large-file break

Large files are different.

For large-archive.zip.vect, the final file is exactly original size plus 12 bytes:

The decrypt check tested that persisted trailer against each encrypted large-file chunk:

The final trailer belongs to the final encrypted chunk only.

The code explains why. In large-file mode, the routine computes a stride from file_size >> 2, runs four read/encrypt/write iterations, and calls 0x140068db0 each time. Each call generates a fresh 12-byte nonce into the same trailer buffer. The first three nonces are overwritten before any trailer is written. After the loop, the code seeks to the end of the file and writes exactly 0x0c bytes from the current trailer buffer.

The observed file format has no place for the missing three nonces.

Where the missing nonces would have to be

A disk-only recovery path for large files would need the first three nonces to be stored somewhere else. I checked the places they would realistically appear:

That gives the practical boundary:

Full large-file restoration would require capturing the transient per-chunk nonces while the malware is running, for example around 0x140068db0.

About the public possible decryptor

A public post from DarkWebInformer raised the obvious question: is there already a VECT ransomware decryptor?

That question is what sent me into the sample. The analysis above was done from the Windows VECT binary and its encrypted-file behavior first. Only after that did I compare the public repository against the recovered file format.

The caution in the repository README is still important. It says the tool was found on Telegram, describes it as possibly a VECT decryptor, says the author did not have an encrypted file to test, and recommends running it only in an isolated environment.

The Go source targets a different file format than the Windows VECT sample analyzed here.

The mismatch is structural, not cosmetic.

That last point matters. The repo's key-search approach depends on ChaCha20-Poly1305 authentication succeeding for a candidate key. This sample's format is raw encrypted bytes plus a trailing nonce, and the nonce sits at the opposite end of the file from where the tool expects it.

For small files in this sample, recovery is possible because the format is internally consistent: encrypted body plus the final 12-byte nonce. For large files, the problem remains the same: the sample generates four per-chunk nonces and only preserves the final one. A third-party decryptor cannot recover nonce material that was never written to disk.

The practical read: this GitHub project may relate to a different .vect1 artifact, an early proof of concept, a confused Telegram tool, or something else entirely. It targets a different file format than the VECT 2.0 Windows sample analyzed here.

Use the file-format details in this post before trusting any public decryptor claim. If you are working a VECT case and need help validating whether your files match this format, reach out to [email protected].

Responder takeaway

For this build, small-file recovery is technically plausible when the static key and the appended 12-byte nonce are available. Large-file recovery from disk alone stops at the final encrypted chunk, because that is the only chunk that keeps its nonce.

Preserve affected files, preserve memory if the process is still live, and plan recovery around backups. A paid decryptor cannot reconstruct nonce material that the locker never wrote down.

What this sample shows

The clean read is simple: this Windows sample is a VECT-branded ransomware locker with local and lateral impact features. Its file encryption is ChaCha20-compatible, and its small-file format is recoverable. The large-file format loses the data needed to finish the job.

In this case, the interesting part is the locker: the file format, the saved nonce, and the missing nonce material.

Appendix: cryptographic artifacts

The decrypt check uses these little-endian file-key qwords from 0x140069140:

The resulting file-key SHA256 is:

dd2105e5d97add32151d3340022e7bcb2ddefb2c635725a5fea2327c38a2d4bd

Detection artifacts

Research note

This kind of work gets better with more telemetry. If you operate a threat intelligence platform with API access and can provide a researcher account, please reach out to [email protected].

VECT does not need a dramatic ending. The operator-facing story says ransomware. The file format says something harsher: for large files, the sample throws away three of the four nonces it needs, then asks the victim to trust a decryptor that cannot have the missing pieces.