In-Depth Technical Analysis Of VECT Ransomware

Overview

On January 19, 2026, the Vect ransomware operation publicly announced its affiliate program through a post on a Brechforums, marking a clear step toward scaling its ransomware-as-a-service (RaaS) model. The announcement was made by the actor behind the operation (“vect”), who used the platform to introduce the program and share access to a dedicated TOR-based panel.

In the post, Vect emphasizes that its ransomware has been developed entirely in C++ from scratch, explicitly stating that it does not rely on leaked or reused source code from existing ransomware families. This claim is positioned as a key differentiator, aiming to establish credibility and independence within a crowded threat landscape.

The advertisement outlines a range of technical capabilities designed to attract affiliates, including the use of ChaCha20-Poly1305 encryption, high-speed file encryption, and flexible configuration options. Additional features include execution in Windows Safe Mode, service and process termination to ensure encryption success, and asynchronous encryption across local and network drives. The malware is also described as supporting lateral movement through protocols such as SMB and WinRM, alongside cross-platform targeting capabilities spanning Windows, ESXi, and Linux environments.

The inclusion of a TOR (.onion) link within the post suggests the presence of a structured backend infrastructure, likely supporting affiliate onboarding, campaign management, and victim negotiations. Overall, the announcement reflects a standard but strategic approach to affiliate recruitment, aligning Vect with established RaaS operations that leverage underground forums to expand their reach and operational capacity.

In early January 2026, the Vect ransomware operation formally introduced its affiliate program, signaling a transition toward a structured ransomware-as-a-service (RaaS) ecosystem.

Infrastructure associated with the group indicates a typical but organized deployment model, consisting of three TOR-based components identified through leak site monitoring: an affiliate onboarding portal, a dedicated victim negotiation interface, and a public-facing data leak site used to pressure targets through exposure of exfiltrated data.

The affiliate offering is positioned to attract a broad range of operators, advertising a five-tier revenue-sharing scheme alongside operational support features such as dedicated negotiators, ticket-based assistance, and multilingual interfaces. Notably, the program applies a region-based entry model affiliates operating within Commonwealth of Independent States (CIS) countries are exempt from fees, while those outside the region are required to pay an entry cost of $250. This approach aligns with patterns commonly observed among Russian-speaking ransomware groups.

Collaboration with Breach Forums & teamPCP

On March 25, 2026, the Vect ransomware operation published a new post on an underground forum announcing what it describes as a “partnership” with BreachForums and TeamPCP, signaling a more aggressive phase of expansion and ecosystem integration.

In the announcement, the group positions this development as a major milestone, claiming alignment with one of the most prominent cybercriminal communities. Vect states that all BreachForums members will be granted personal affiliate access, effectively lowering the barrier to entry and enabling large-scale onboarding of new operators. This approach suggests an effort to rapidly scale affiliate numbers and increase operational reach.

It indicates that affiliates struggling with ransomware deployment will receive support from the Vect team, highlighting the group’s intent to provide hands-on assistance and streamline operations for less experienced actors. The mention of “+300k affiliates” appears exaggerated, but reflects an attempt to project scale and influence within the underground ecosystem.

Vect also claims a partnership with TeamPCP, identified as actors behind recent supply chain compromise activity (Trivy / LiteLLM). The group suggests that this collaboration will allow them to leverage initial access obtained through such compromises and convert them into ransomware deployment opportunities, effectively chaining supply chain intrusions into follow-on attacks.

On February 27, 2026, Vect posted on an Breachforums that they are hiring negotiators, offering a 5% commission for every paid ransom, and inviting interested individuals to contact them directly through the forum.

Release of Affiliate Keys on Breach Forums

On March 2026, a BreachForums administrator (“diencracked”) announced the distribution of VECT affiliate keys to all registered users on the forum, reflecting a deeper level of integration between the ransomware operation and the platform.

Alongside this, several backend and security improvements were introduced across the forum, including stronger input validation, enhanced protection against injection attacks, improved CSP and anti-XSS mechanisms, as well as the implementation of rate limiting and anomaly detection to reduce brute-force attempts and suspicious traffic.

In parallel, an escrow infrastructure is being prepared using Monero (XMR) with a multi-signature model, ensuring that no single party has full control over transaction funds, which adds a layer of trust to financial interactions within the forum.

On April 16, 2026, BreachForums users started receiving automated emails containing their VECT access keys, marking the beginning of the actual distribution phase.

Each message included a unique key along with auto-generated login credentials, showing that access was being assigned in bulk rather than manually. The process appears fully automated, with keys delivered through direct messages linked to forum accounts.

VECT Affiliate Panel

The panel shows the Vect 2.0 dashboard, representing the main interface provided to affiliates after onboarding.

The interface is organized with multiple sections on the left sidebar, including builder, earnings, teams, and communication features like chat and tickets, along with additional sections such as announcements, FAQ, and rules.

Builder

The builder panel, where affiliates are required to enter specific details before creating a new operation.

The panel prompts for key information about the target, including the victim name, sector, country, estimated revenue, and the ransom amount. These inputs are then used to generate and structure the operation, linking the target to a dedicated case with its own negotiation channel.

the builder acts as the initial step in setting up a campaign, where all essential victim details are defined before moving into execution and negotiation phases.

The builder capabilities include generating payloads for Windows, Linux, and ESXi, with additional configuration options such as defining excluded file extensions and paths, as well as handling GPO-related credentials. The panel also includes an option for an exfiltration tool, but it appears to be not yet released or still under development.

Affiliate Earnings

The earnings panel shows how affiliate revenue is tracked and managed within the platform.

It includes details such as the current level, commission rate (80%), total earned, available balance, pending amounts, and total payouts—all currently at zero, indicating no completed operations yet. A level progression bar is also present, showing the threshold required to move to the next tier, where higher commission rates can be unlocked.

The panel also provides wallet configuration options, allowing affiliates to set BTC and XMR addresses for receiving payments, along with a payout request section that defines a minimum withdrawal amount of $1,000.

The level system panel shows how affiliate commissions increase based on total earnings.

It outlines multiple tiers, starting from Level 1 with an 80% share, and gradually increasing up to 89% at higher levels. Each level requires reaching a specific revenue threshold, ranging from $0 at entry level to $75,000,000+ for the highest tier.

At the same time, the panel cut decreases as affiliates progress, dropping from 20% at Level 1 to 11% at the top tier. This structure incentivizes higher activity, rewarding affiliates with a larger share as they generate more revenue.

Vect-Linked Victim Listings

As of April 22, 2026, Vect has listed a total of 25 victims, with the most recent additions recorded on April 16, indicating a pause or slowdown in public disclosures since then.\

The victim distribution shows a concentration across multiple regions, with the United States leading at 5 victims, followed by Brazil with 4. South Africa, India, and Egypt each account for 2 victims, reflecting a geographically diverse targeting pattern rather than a focus on a single region.

Technical Analysis

Binary Characteristics & Initial Triage

The sample is a **PE32+ (x86-64) console application** with PE contains **10 sections**: `.text`, `.data`, `.rdata`, `.pdata`, `.xdata`, `.bss`, `.idata`, `.CRT`, `.tls`, and `.reloc`.

The `.rdata` section is particularly noteworthy it houses the malware’s encrypted configuration data (RVA `0x126000`-`0x128000`), plaintext PowerShell scripts (`0x1270D0`-`0x127BF3`), wallpaper text (`0x128D70`), and libsodium constants including multiple instances of the ChaCha20 sigma constant `”expand 32-byte k”`.

Worth mentioning here also is that, during the initial analysis, the Vect ransomware seemed to be a variant or modification of the DEVMAN ransomware.

The `main()` function begins by parsing command-line arguments in a loop spanning . It uses a `strcmp` to match each argument against the following supported flags:

  -h, --help              Show help
  -v, --verbose           Enable verbose output
  -p, --path <dir>        Target specific path
  -c, --creds <b64>       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

Configuration Encryption

Every sensitive stringfile paths, registry keys, command lines, service names, process names, and network indicatorsis encrypted at rest using an 8-byte XOR scheme with per-string keys.

Using this pattern, we decrypted over 80 configuration entries. Key findings include:

Anti-Analysis Techniques

The malware “appears” to employs two separate anti-debug checks through dedicated wrapper functions:

1. CheckRemoteDebuggerPresent : A compact function that calls GetCurrentProcess() to obtain the process handle, then passes it to CheckRemoteDebuggerPresent to detect user-mode debuggers attached from external processes. Returns a boolean indicating debugger presence.
2. IsDebuggerPresent: A direct wrapper around the Win32 IsDebuggerPresent API, returning its result as a boolean. This detects debuggers attached to the current process through the PEB’s BeingDebugged flag.

Both functions are called during the malware’s initialization phase. Additionally, a separate privilege escalation check uses OpenProcessToken + GetTokenInformation with TokenElevation to determine whether the process is running with administrative privilegesthis is not an anti-debug function, but rather gates access to operations requiring elevated permissions (service termination, shadow copy deletion, etc.).

There are also VM detection functions that employs a file-based fingerprinting and decodes registry-based VM detection Keys

• SOFTWARE\VMware, Inc.\VMware Tools Detects VMware virtual machines
• SOFTWARE\Oracle\VirtualBox Guest Additions Detects VirtualBox virtual machines

And there are also a separate function that scans running processes and checks each process name against an array of known analysis tool names

But actually, during dynamic analysis, none of these functions were called, so either they are just placeholders or they require a specific condition to be triggered.

Defense Evasion

Before beginning encryption, Vect takes aggressive steps to neutralize the host’s defenses and eliminate recovery options.

Safe Mode Boot

The function at 0x14005E260 handles the first half of the Safe Mode attack. It decrypts a 40-byte command string (XOR key 0x297B45A773FB0941) and executes it via CreateProcessA with CREATE_NO_WINDOW:

bcdedit /set {default} safeboot minimal

This configures Windows Boot Configuration Data (BCD) to boot into Safe Mode (minimal) on the next restart. Safe Mode loads only a bare minimum set of drivers and services, meaning most endpoint protection products, backup agents, and security monitoring tools will not start. This is a deliberate pre-encryption step to create a clean environment for maximum file access.

The complementary function at 0x14005E5A0 handles the revert. After encryption is complete, it decrypts a 40-byte command string (XOR key 0x2B3DCFB5B5D3957B) and executes the teardown command:

bcdedit /deletevalue {default} safeboot

This removes the Safe Mode boot flag so that the system returns to normal boot on the next restart, allowing the victim to see the encrypted state and the ransom note normally. The two-phase approach (set before, remove after) means the ransomware only needs one Safe Mode cycle to complete its work.

both of these functions are conditional and only happens if elevated, --force-safemode is set, and not in remote session.

Shadow Copy Deletion

The function at 0x14005EC60 first verifies admin privileges via sub_14006C320 (the TokenElevation check). If running elevated, it decrypts a 36-byte command string and executes:

vssadmin delete shadows /all /quiet

This removes all Volume Shadow Service snapshots, eliminating the primary built-in mechanism for file recovery on Windows systems. The /quiet flag suppresses confirmation prompts. The function waits up to 30 seconds (0x7530 ms) for completion.

Event Log Clearing

After encryption completes, the malware clears Windows Event Logs to hinder forensic analysis. It first checks for admin privileges, and if elevated, it XOR-decrypts four event log channel names using the key 0xBB55FF59DF597B8D: Application, Security, System, Windows PowerShell

Then executes 4 commands to clear logs after decrypting:

wevtutil cl Application
wevtutil cl Security
wevtutil cl System
wevtutil cl "Windows PowerShell"

Persistence Mechanisms

Vect establishes persistence through two complementary registry mechanisms, both of which survive a reboot including a Safe Mode reboot triggered by the malware itself.

Defense Evasion – Disabling Task Manager

The function at 0x14005EF50 writes to the Windows group policy registry path for suppressing the Task Manager. It XOR-decrypts the 58-byte registry key path (key: 0x95DB052FC5CB6335):

Software\Microsoft\Windows\CurrentVersion\Policies\System

It then decrypts a 15-byte value name (key: 0xB5E3FF6F79E787BF):

DisableTaskMgr

And writes a DWORD value of 1 via RegSetValueExA. This blocks Task Manager from launching for standard users, preventing victims from easily identifying and killing the ransomware process. The key is opened under HKEY_CURRENT_USER via RegCreateKeyExA.

SafeBoot Registry Persistence

The function at 0x140063BC0 implements a two-pronged SafeBoot persistence technique designed to survive the forced Safe Mode reboot that the malware triggers via bcdedit. It performs the following steps:

1. Parse own path: XOR-decrypts the string .exe (5 bytes, key 0xC9771B45F9913B87) and uses it to locate the .exe extension in the malware’s own executable path via a string search call. The segment before .exe is extracted as the service name.
2. Register under SafeBoot\Minimal: XOR-decrypts the 51-byte registry path (key 0x194DB9CD9B4DBD9F):

SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\ 

Appends the service name, calls RegCreateKeyExA(HKEY_LOCAL_MACHINE, ...) to create the key, then XOR-decrypts the 8-byte value name Service (key 0xDB63D3A5DF2FA55D) and writes it via RegSetValueExA.

3. Register under SafeBoot\Network: XOR-decrypts the second 51-byte registry path (key 0xFD4FF1BDA37D1FD3):

SYSTEM\CurrentControlSet\Control\SafeBoot\Network\

Performs the same key creation and value write for the network-enabled Safe Mode variant.

By registering under both SafeBoot variants, the malware ensures it loads whether the operator reboots into safeboot minimal (no network drivers) or safeboot network (network available). This is a well-known technique originally popularized by REvil/Sodinokibi and is mapped to MITRE ATT&CK T1112 (Modify Registry).

Service & Process Termination

To maximize the number of files available for encryption particularly database files, email stores, and documents that are typically held open by running applications. The malware aggressively terminates security products, backup solutions, and business applications before beginning its encryption routine.

After building the large list of services to be killed by decrypting strings using the function at 0x14006CE20, it starts iterating over them to stop them all

list of services to be killed:

same happens for a list of processes:

File Encryption Engine

The encryption subsystem is a multi-threaded scanner/encryptor pipeline centered on (0x14006AD00). A ChaCha20-IETF-style stream cipher, per-chunk 12-byte nonces, .vect renaming, and a partial-encryption strategy for files larger than 0x20000 bytes (128kb).

Cipher and Nonce Generation

• the nonce length used by the file-encryption path is 0x0C bytes
• the file key pointer supplied to the crypto backend is key_struct + 0x40

Nonce generation is backed by sub_140003A80, which resolves to the random backend table and ultimately reaches sub_140004A90, where SystemFunction036 is called (generates random number). The binary also contains five embedded expand 32-byte k constants. Together, these are the concrete references supporting a ChaCha-family stream-cipher backend in the file-encryption path.

Key Material

sub_140069990) loads a 96-byte embedded key structure, initializes the crypto runtime, and XOR-conditions only the first 64 bytes with a single runtime byte derived from the "default" std::random_device path. This conditioning does not affect the actual file-encryption key.

The file-encryption path always passes bytes +0x40..+0x5F of that structure as the cipher key. Those 32 bytes are static and were not observed to be transformed before use:

6a510957f1bf8eced9aae3aa5e8612152d0abbf111fcd2a39f02ffe6000f6be8

This means the file-encryption path uses a constant 32-byte key across all encrypted files produced by this sample. The randomized byte only affects the first two 32-byte regions of the 96-byte structure, not the file key passed into the backend.

Per-File Encryption Logic

later, the funciton performs the following sequence to encrypt each file:

1. Rename the original file by appending .vect with MoveFileExW.
2. Reopen the renamed file for read/write access with CreateFileW.
3. Read the size with GetFileSizeEx.
4. Choose one of two encryption modes:
   • files <= 0x20000 bytes: encrypt the entire file in one pass
   • files > 0x20000 bytes: encrypt four 0x8000-byte chunks at offsets floor(size/4) * i, i = 0..3
5. Append a 12-byte footer to the end of the file.

The footer handling is critical. The chunk routine writes each generated nonce into a single 12-byte local buffer, and appends that buffer only once after the loop. For files larger than 0x20000, four different nonces are generated, but only the last one is preserved in the file footer. As a result:

• small files are fully decryptable from the .vect file alone
• large files retain only the nonce for the fourth encrypted chunk
• the first three encrypted chunks are not recoverable from the file alone, even with the correct static key

This behavior was validated against original/encrypted file pairs: a small .vect sample fully decrypted to the original, while larger samples decrypted correctly only in the final encrypted chunk.

There is no per-file wrapped key, public-key envelope, or authentication tag stored with the file. The format is therefore a renamed ciphertext plus a 12-byte nonce footer.

Decrypt small files

Knowing the fact that we can decrypt files smaller than 128kb, I’ve created a minimal python script that decrypts any file under 128kb

#!/usr/bin/env python3
import sys
from pathlib import Path

from Crypto.Cipher import ChaCha20

KEY = bytes.fromhex(
    "6a510957f1bf8eced9aae3aa5e861215"
    "2d0abbf111fcd2a39f02ffe6000f6be8"
)
MAX_SMALL = 0x20000


def main() -> int:
    if len(sys.argv) != 2:
        print(f"usage: {Path(sys.argv[0]).name} <file.vect>", file=sys.stderr)
        return 1

    src = Path(sys.argv[1])
    data = src.read_bytes()
    if len(data) <= 12:
        raise SystemExit("file too small")

    body, nonce = data[:-12], data[-12:]
    if len(body) > MAX_SMALL:
        raise SystemExit("large file: this minimal script only supports <= 0x20000-byte originals")

    out = src.with_name(src.name[:-5] if src.name.endswith(".vect") else src.name + ".decrypted")
    out.write_bytes(ChaCha20.new(key=KEY, nonce=nonce).decrypt(body))
    print(out)
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Traversal and File Queuing

The scanner worker recursively enumerates directories with FindFirstFileW / FindNextFileW, applies directory and file filters, and queues eligible paths for encryption. It also drops ransom-note content in visited directories. Confirmed diagnostic strings include:

[Scanner] Scanned %d paths, queued %d files
[Scanner] Thread finished. Scanned %d paths, queued %d files

The broader execution flow can also mount otherwise unmounted volumes before scanning, expanding the set of reachable encryption targets.

Lateral Movement & Network Propagation

The binary contains multiple remote-spread modules, but they are not part of the default encryption path. The controlling flag is --gpo: the associated .data bytes are zero by default, and vect_main enters the confirmed spread branch only when the operator enables that flag.

When --gpo is enabled, vect_main builds and launches three task objects:

• sub_1400F3F40 → spread_wmi_process_create_alt (0x140055890)
• invoke_spread_dcom_cim_callback → spread_dcom_cim_process_create (0x14005C770)
• invoke_spread_gpo_cimsession_callback → spread_gpo_cimsession_schtasks (0x140062F90)

Without --gpo, none of these three functions are entered from the analyzed main flow. A separate --verbose thread is launched earlier in vect_main, but its vtable resolves to a status/progress loop and not to any spread function

Ransom Note

The ransom note drops in almost every folder on system and also the system wallpaper gets changed

!!! 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: http://vectordntlcrlmfkcm4alni734tbcrnd5lk44v6sp4lqal6noqrgnbyd.onion/chat/5cb9f0f9-e171-403f-bed9-a3cd6ce36d1f
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: 3
Total size: 890864 bytes
Unique ID: 5cb9f0f9-e171-403f-bed9-a3cd6ce36d1f

Backup contact (Qtox): 1A51DCBB33FBF603B385D223F599C6D64545E631F7C870FFEA320D84CE5DAF076C1F94100B5B

The malware also creates the file C:\ProgramData\.vect, which is used as a marker to determine whether encryption has already been performed. On subsequent execution, the malware checks for the presence of this file and, if it exists, skips the full execution path under the assumption that the system has already been encrypted. As a result, the presence of this file alone may prevent the system from being encrypted.

IOCs

Yara Rule

rule Windows_Ransomware_Vect
{
    meta:
        description = "Vect Ransomware family rule"
        author = "Dark Atlas; @ELJoOker"
        date = "2026-04-23"

    strings:
        $brand = "DEVMAN" ascii
        $note = "!!!_READ_ME_!!!.txt" ascii
        $wallpaper1 = "YOUR FILES HAVE BEEN ENCRYPTED" ascii
        $wallpaper2 = "Find !!!_READ_ME_!!!.txt on your desktop" ascii

        $cli1 = "--stealth" ascii
        $cli2 = "--gpo" ascii
        $cli3 = "--mount" ascii
        $cli4 = "--force-safemode" ascii

        $ps1 = "New-ScheduledTaskAction" ascii
        $ps2 = "MMC20.Application" ascii
        $ps3 = "ExecuteShellCommand" ascii
        $ps4 = "Invoke-WmiMethod" ascii

        $sigma = "expand 32-byte k" ascii
        $libsodium = "LibsodiumDRG" ascii

    condition:
        uint16(0) == 0x5A4D and
        filesize > 1MB and filesize < 3MB and
        (
            ($note and $wallpaper1 and $wallpaper2) or
            (3 of ($ps*) and 2 of ($cli*)) or
            ($brand and $note and ($sigma or $libsodium))
        ) and
        (1 of ($cli*) or 2 of ($ps*))
}

Conclusion

VECT (“Devman 3.0”) is a Windows ransomware sample built for high-impact encryption and host disruption. The confirmed execution flow shows multi-threaded file encryption, service and process termination, SafeBoot persistence, shadow copy deletion, Defender tampering, log clearing, and optional self-deletion.

Its encryption design is weaker than the ransom note claims and confirms that, in this sample, large files are not fully recoverable from the .vect file alone. The file-encryption path uses a static 32-byte key, small files are fully recoverable from the .vect file, and large files are only partially recoverable because the binary preserves only the last nonce footer. No per-file key exchange or complete recovery metadata is stored in the file format.

Lateral movement is conditional rather than default behavior. In the analyzed main flow, no spread path is reached unless –gpo is enabled; with that flag, three remote-execution modules are launched.