Vect — Technical Analysis / V2

VECT 2.0 Ransomware — Full Analysis

1. Sample Identification

The binary is a self-contained encryptor written in C++ and statically linked against MinGW-w64's libstdc++. The malware logic is built on top of a cryptographic codebase derived from libsodium (ChaCha20, BLAKE2b, X25519, Poly1305 are all present). All string literals, configuration values, kill-list entries, registry paths, PowerShell payloads, and command lines are XOR-encrypted with per-string 64-bit keys (cycle-of-8 byte-wise XOR), lazily decrypted on first use into a global cache, and re-encrypted at process exit by registered destructors. Three TLS callbacks are present (two are MinGW runtime, the third installs a vectored exception handler used incidentally by pthread_setname_np). The binary advertises a version string VECT 2.0 (rendered on the desktop wallpaper) and an internal codename dvm3 leaked through an artefact filename.

The present analysis is scoped to this Windows sample only. No claim is made here about other VECT 2.0 builds or non-Windows variants.

Key finding — this build is partially destructive, not merely an encryptor. Two independent design defects in the file-encryption pipeline cause data loss that no key disclosure can repair: (i) a single 256-bit ChaCha20 key is hardcoded in .text and reused across every file and every host (making files ≤ 128 KiB trivially decryptable when the build is recovered), and (ii) for files > 128 KiB the four-chunk intermittent-encryption loop reuses a stack-local nonce buffer, so only the last of the four random nonces is preserved on disk and the other three are lost forever. The combined effect is that any file larger than 128 KiB processed by this build has roughly 75 % of its content rendered cryptographically irrecoverable — including with full cooperation from the operator. See Section 5 ("Lost-nonce flaw" and "Operational consequence") for the technical detail and Section 15 (T1485) for the impact mapping.

Imports (10 DLLs)

Notably absent: any bcrypt, crypt32, wininet, winhttp, urlmon, wlanapi, dhcpapi, ldap, or socket transport (socket, connect, send, recv, WSAStartup) imports. The binary performs no network I/O of its own — the only networking-adjacent activity is SMB share enumeration via the MPR/NETAPI32 cached-credential APIs used for read/write file access during local encryption, and UTF-8 hostname/IP string handling via WS2_32 address utilities.

2. Infrastructure

3. Ransom Note

Filename

<base>.txt (base name is XOR-encrypted in the binary's static configuration). The note is dropped by every scanner thread inside every directory it enters during the recursive walk, plus an additional copy in %USERPROFILE%\Desktop\<base>.txt. The note is written before the directory's files are encrypted, ensuring readability after encryption completes.

Content

!!! 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.

The only way to recover your files is to get the decryption tool.

To obtain the decryption tool:

1. Open Tor Browser and visit: <onion>/chat/<victim_id>
2. Follow the instructions on
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

Do not use third party software to restore files
If you violate these rules, your files will be permanently damaged

WARNING:
- Do not modify encrypted files
- Do not reinstall system

Files encrypted: <count>
Total size: <bytes> bytes

Unique ID: <victim_id>

Backup contact (Qtox): 1A51DCBB33FBF603B385D223F599C6D64545E631F7C870FFEA320D84CE5DAF076C1F94100B5B

The exfiltration claim ("we have also exfiltrated your sensitive data… and will be published on our website") is not supported by any code in this binary: there is no HTTP/HTTPS, no SMTP, no FTP, no DNS tunnelling, and no socket transport import. Either the data theft is performed by a separate operator-side tool not present in this sample, or the claim is a psychological pressure tactic.

4. Execution Flow

Entry sequence

1.  Standard MinGW-w64 _tmainCRTStartup -> user main(argc, argv)
2.  Parse argv flags (see Section 11)
3.  Try to open C:\ProgramData\.vect as binary std::ifstream;
    if open fails, immediately destroy the stream and return 0 (silent exit)
4.  Set global verbose flag from -v/--verbose
5.  Probe is_admin (via OpenProcessToken/GetTokenInformation) and is_remote_session
    (via GetSystemMetrics(SM_REMOTESESSION))
6.  If admin:
      a. GetModuleFileNameA(self) -> module_path
      b. install_persistence_3way(module_path)        # see Section 10
      c. disable_defender_realtime()                   # see Section 7
      d. dispatch_kills_and_persist()                  # services + processes + Run key alt
      e. vssadmin_delete_shadows()                     # see Section 7
      f. if --force-safemode and not RDP: trigger_safemode_reboot() (bcdedit ...)
      g. if --mount: mount_network_shares() + Sleep(2000)
7.  Build the per-drive scan paths vector (init_encryption_ctx populates the
    crypto context from the static C++ global config struct)
8.  If --gpo: spawn 3 std::thread workers iterating g_lateral_techniques_array
    (10 PowerShell-based RCE techniques, see Section 10)
9.  For each drive in the scan list:
      encrypt_drive_orchestrator(ctx, drive)
        -> spawns N=max(4,total/8) scanner threads + M=max(12,total-N) encryptor threads
        -> waits via _InterlockedSub counter + WaitForMultipleObjects
        -> CloseHandle on all worker handles
10. Post-encryption cleanup (unmount shares if applicable)
11. delete_powershell_history()                       # see Section 7
12. If --stealth: spawn detached
    "cmd /c ping 127.0.0.1 -n 3 >nul & del /f /q \"<self>\""
    via CreateProcessA(CREATE_NO_WINDOW=0x8000000) and exit

Thread architecture

For each drive, the encryption orchestrator computes:

• n_total = thread count derived from CPU count and physical RAM (capped to 256)
• n_scanners = max(4, n_total / 8)
• n_encryptors = max(12, n_total - n_scanners)

Each scanner thread pops directory paths from a path queue, performs FindFirstFileW/FindNextFileW enumeration, applies the directory and file skip lists (Section 6), and pushes file paths onto a file queue while writing the ransom note inside the directory currently being scanned. Each encryptor thread pops file paths from the file queue, calls the per-file encryption routine, and increments an _InterlockedAdd64 counter of total bytes encrypted. The orchestrator waits on scanner-completion via an interlocked counter, then on encryptors via WaitForMultipleObjects(INFINITE).

Execution gate (anti-orphan-payload guard)

The marker file C:\ProgramData\.vect must exist on the host for any malicious behaviour to occur. Its content is never read; only its presence is tested. This functions as a guard that allows the binary to be safely staged on hosts before being activated by a separate first-stage component dropping the marker.

5. Encryption System

Key Exchange

Symmetric Cipher

The Universal Hardcoded Key

The encryption routine receives a pointer to a 97-byte crypto_state buffer constructed at runtime as follows:

The "randomization" gesture (XOR-with-valEv over bytes 0..63) provides no cryptographic entropy because those 64 bytes are not used by the cipher. The actual encryption key used by every ChaCha20 call is the unmodified 32-byte block at offsets 64..95:

Universal ChaCha20 key (this build):
  6A 51 09 57 F1 BF 8E CE  D9 AA E3 AA 5E 86 12 15
  2D 0A BB F1 11 FC D2 A3  9F 02 FF E6 00 0F 6B E8

File Encryption Process

For each victim file (per encryptor thread):

1. Build new pathname = <original_path> + "." + ".vect"
2. MoveFileExW(original, new, MOVEFILE_REPLACE_EXISTING)   # in-place rename
3. CreateFileW(new, GENERIC_READ|WRITE, FILE_SHARE_READ,
               OPEN_EXISTING, FILE_FLAG_NO_BUFFERING)       # 0x10000000
4. GetFileSizeEx
5. Branch on file size (see Intermittent Encryption below)
6. For each chunk i in {0, 1, 2, 3} (or single chunk for small files):
     SetFilePointer(file, chunk_offset, FILE_BEGIN)
     ReadFile(buf, chunk_size)
     RtlGenRandom(footer_buf, 12)                            # 12B random nonce
     ChaCha20_xor(buf, key=crypto_state+64, nonce=footer_buf, counter=0)
     SetFilePointer(file, chunk_offset, FILE_BEGIN)
     WriteFile(buf, chunk_size)                              # rewrite ciphertext
7. SetFilePointer(file, 0, FILE_END)
8. WriteFile(footer_buf, 12)                                 # append last nonce
9. _InterlockedAdd64(ctx.total_bytes_encrypted, file_size)
10. CloseHandle(file)

Intermittent Encryption

Lost-nonce flaw (large files)

The 12-byte nonce buffer used in step 6 of the per-file routine is a single function-frame stack local. Across the four chunk iterations, the same memory address is reused, and the previous nonce is unconditionally overwritten by the next call to RtlGenRandom. After the loop, only the nonce of the fourth (last) chunk remains, and that single value is what step 8 writes as the EOF footer.

The nonces of chunks 0, 1, and 2 are therefore not stored anywhere. They are not derived deterministically from a counter or from the master key; the source of randomness is pure CSPRNG, no derivation function is applied. As a result, for any encrypted file larger than 128 KiB, the contents of the first three chunks (covering offsets 0..size/4, size/4..size/2, size/2..3*size/4, i.e. 75% of the file content for any file size that is a clean multiple of 4 × 32 KiB) are cryptographically irrecoverable regardless of any future key disclosure.

For files that fall in the size range (128 KiB, 4 × 32 KiB) the same effect applies but the lost ciphertext fraction is smaller. For files just above 128 KiB, the four 32 KiB chunks may overlap or cover the entire content — in that case the first three nonces being lost still costs three quarters of the encrypted ciphertext.

Operational consequence: partial wiper, not a recoverable encryption

The combination of the universal hardcoded key (Section 5 — "The Universal Hardcoded Key") and the lost-nonce flaw described above produces a two-tier outcome on any victim host of this build:

The upper-tier effect is independent of any cryptanalytic effort and independent of operator cooperation. Even an operator with full control of the build, the source code, and the per-victim chat session has no mechanism to reproduce the three discarded nonces — they were never persisted anywhere they can be retrieved from. For the affected file population this build behaves as a partial wiper rather than as a ransom-paying cryptolocker, irrespective of intent. This is a property of the binary, not of the threat-actor playbook.

Encrypted File Format

+-----------------------------------------------------------------+
| Encrypted body (in-place, original file size unchanged)          |
|   - if size <= 128 KiB: entire content ChaCha20-encrypted         |
|   - if size  > 128 KiB: four 32 KiB chunks at offsets             |
|       i * (size/4), for i in {0,1,2,3}, ChaCha20-encrypted;       |
|       the rest of the file is left in plaintext                   |
+-----------------------------------------------------------------+
| Footer: 12 bytes — ChaCha20 nonce of the LAST encrypted chunk     |
+-----------------------------------------------------------------+

File rename: <original>.<ext>  ->  <original>.<ext>.vect

There is no per-file header, no magic bytes, no per-file key wrap, no signature, no MAC, and no metadata other than the trailing 12-byte nonce.

Sample File Layout (small file, ≤ 128 KiB)

For a hypothetical 1024-byte plaintext encrypted by this build, the resulting <original>.<ext>.vect file is 1036 bytes long with the following structure:

Offset      Length      Content
----------  ----------  ----------------------------------------------------
0x00000000  1024 bytes  ChaCha20(master_key, footer_nonce, counter=0) over the
                        original 1024-byte plaintext
----------  ----------  ----------------------------------------------------
0x00000400  12 bytes    ChaCha20 nonce (12 random bytes generated by
                        RtlGenRandom, written to stack-local then to EOF)
                        Example footer hex (illustrative — actual values are
                        per-file random):
                          XX XX XX XX XX XX XX XX XX XX XX XX

Decryption (for a file ≤ 128 KiB) reduces to: 1. Read the file body (everything except the last 12 bytes). 2. Read the trailing 12-byte footer as the ChaCha20 nonce. 3. Run ChaCha20 keystream with the universal master key, the footer as nonce, and counter starting at 0. 4. XOR keystream into the body to recover the plaintext.

Sample File Layout (large file, > 128 KiB)

For a hypothetical 1 MiB (1,048,576-byte) plaintext, the resulting .vect file is 1,048,588 bytes long. Four 32 KiB regions are encrypted in place at offsets 0x00000, 0x40000, 0x80000, and 0xC0000. The remaining ~896 KiB of the file is left in plaintext. Only the final chunk's nonce survives in the EOF footer:

Offset             Length      Content
-----------------  ----------  -----------------------------------------------
0x00000000         32,768 B    Chunk #0: ChaCha20 ciphertext (nonce LOST)
0x00008000        ~229 KiB     Plaintext gap
0x00040000         32,768 B    Chunk #1: ChaCha20 ciphertext (nonce LOST)
0x00048000        ~229 KiB     Plaintext gap
0x00080000         32,768 B    Chunk #2: ChaCha20 ciphertext (nonce LOST)
0x00088000        ~229 KiB     Plaintext gap
0x000C0000         32,768 B    Chunk #3: ChaCha20 ciphertext (nonce IN FOOTER)
0x000C8000        ~225 KiB     Plaintext gap
0x000FFFFC         12 bytes    ChaCha20 nonce of chunk #3 only

For files in this range, only the chunk at offset 0xC0000 (~32 KiB) is decryptable; the three earlier chunks remain ciphertext for which no nonce exists.

6. File Targeting

Targeted Extensions

All files except those matching the exclusion lists below. There is no allow-list of extensions; the malware encrypts any file under any reachable directory.

Excluded Directories

A recursive directory traversal is performed by scanner threads. A directory is skipped (not entered) if its name matches case-insensitively any of the entries below, or if its name begins with a $ character (NTFS metadata).

Excluded Extensions

.exe, .dll, .sys — executables and drivers are never encrypted. Combined with the boot-loader skip list below, this guarantees the host remains bootable so the wallpaper and the ransom note are visible to the victim.

Excluded Files

Files whose name starts with $ are also skipped (NTFS metadata).

7. Recovery Inhibition

8. Targeted Services (28 entries)

Stopped via OpenSCManagerA(SC_MANAGER_ALL_ACCESS) followed by OpenServiceA(STOP|QUERY|ENUMERATE_DEPENDENTS), QueryServiceStatusEx, and ControlService(SERVICE_CONTROL_STOP) for each service whose state is not already STOPPED/STOP_PENDING. Service names are XOR-encrypted in the binary and decrypted into a std::vector<char*> at runtime.

The kill list is heavily weighted toward enterprise backup software (CommVault, Veeam, Yoo) and centrally-managed AV/EDR suites (Symantec product line), with database engines added to release file locks.

9. Targeted Processes (8 entries)

Terminated via CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS) + Process32FirstW/Process32NextW, then OpenProcess(PROCESS_TERMINATE) + TerminateProcess(handle, 9) for each process whose szExeFile matches case-insensitively (via wcsicmp) any of the entries below.

10. Persistence & Evasion

Three-way registry persistence

Three keys are written under HKEY_LOCAL_MACHINE in order to maximise the chance that the malware regains execution after any reboot, including a Safe Mode boot.

A second Run-key write (under a slightly different name) is performed by the kill-list dispatcher every time the binary executes with administrative privileges, providing redundant persistence.

String obfuscation

Every literal string used at runtime — registry paths, service names, process names, kill-list entries, PowerShell payloads, log messages, ransom-note fragments — is stored XOR-encrypted under a unique 64-bit key per string, decoded byte-wise as pt[i] = ct[i] ^ ((K >> (8 × (i mod 8))) & 0xFF). A guard byte at the end of each string indicates the encrypted/decrypted state; the first read decrypts and caches the value in a global slot, and a destructor registered with atexit re-encrypts the cache at process termination.

Lateral movement: 10 PowerShell-based RCE techniques

A std::function<void(ctx*)> array of 10 entries is allocated statically. Each entry generates a self-contained PowerShell payload for one specific remote-execution primitive, writes it to a temporary buffer, and runs it via powershell.exe with a 60-second timeout. All ten payloads share the same Active Directory discovery preamble:

$ErrorActionPreference='SilentlyContinue'
$pcs=@()
try{$pcs=@([adsisearcher]'objectCategory=computer').FindAll()|%{$_.Properties.dnshostname[0]}|?{$_ -and $_ -ne $env:COMPUTERNAME}}catch{}
if(-not $pcs){$pcs=1..254|%{"192.168.1.$_"}}

(LDAP/ADSI search for all domain computers, with a 192.168.1.0/24 scan fallback when no domain is reachable.) All techniques drop the binary at \\<host>\C$\ProgramData\<filename> before triggering execution.

The --gpo flag spawns three parallel std::thread workers iterating this 10-entry array; despite its name, this is not a SYSVOL-based Group Policy injection (the binary contains no GPO/SYSVOL strings).

Anti-Analysis Summary

11. Command-Line Arguments

12. Static Imports Summary

13. IDA Analysis — Renamed Functions

Entry point and main dispatcher

Cryptography

File encryption pipeline

Persistence and recovery sabotage

Wallpaper and visual indicators

Lateral movement

Anti-analysis

Helpers

Notable globals

14. Indicators of Compromise (IOCs)

Hashes

Network

Files

Registry

Behavioural

• Spawning of vssadmin delete shadows /all /quiet shortly after process start
• Spawning of a multi-flag Set-MpPreference PowerShell command disabling four Defender protections in a single invocation
• Spawning of bcdedit /set {default} safeboot minimal before encryption
• Mass MoveFileExW operations renaming files to <path>.vect
• Direct FILE_FLAG_NO_BUFFERING (0x10000000) reads/writes during encryption
• Detached cmd /c ping 127.0.0.1 -n 3 >nul & del /f /q "<self>" triggered by the parent ransomware process (self-delete)
• Drop of <filename> into \\<host>\C$\ProgramData\ on multiple network hosts within a 60-second window followed by remote scheduled-task creation, WMI Win32_Process invocations, MMC20.Application DCOM activation, or WinRM Invoke-Command (depending on which lateral technique fires)
• Creation and quick deletion of remote scheduled tasks named DM[A-Z]{4} (six-character names with the DM prefix and four random uppercase letters)
• Creation and quick deletion of remote services named DM[A-Z]{4}
• Deletion of %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt after the encryption phase
• Mass [adsisearcher]'objectCategory=computer' LDAP queries originating from PowerShell on the compromised host, followed by parallel SMB write activity to multiple \\<host>\C$\ProgramData\ paths

Wallpaper Visual

The post-encryption desktop wallpaper has the following layout (1920×1080, 24-bit BMP, plain black background, three text colour ranges):

                              VECT 2.0                                            
                       (Arial 120 bold, red #FF3232, centred at Y=80)             


        :::     ::: :::::::::: :::::::: :::::::::::                               
        :+:     :+: :+:       :+:    :+:    :+:           (Arial 48 white)        
        +:+     +:+ +:+       +:+           +:+           Y = 280..420            
        +#+ +#++:++#  +#+                                                         
        +#+   +#+  +#+       +#+                                                  
        #+#+#+#   #+#       #+#                                                   
           ###     ########## ########     ###                                    

        Your files have been encrypted (cyan #FFC800, Y=540)                     

        Read the README file for instructions  (gray #C8C8C8, Y=620..740)        
        Do not modify encrypted files                                             
        Tor browser required for negotiation                                      


                ID: 5cb9f0f9-e171-403f-bed9-a3cd6ce36d1f                          
                       (Arial 32 dark gray #646464, Y=860)                        

(The exact text content of the white/cyan/gray middle lines depends on the build but follows the structure above. The ASCII-art logo style is identical across all known samples of this family.)

Distinctive Strings

• "VECT 2.0" — wallpaper title (Arial 120 bold red, displayed at the top of the post-encryption desktop wallpaper)
• "dvm3_wall.bmp" — wallpaper artefact filename in %TEMP%, leaks the internal codename dvm3
• "!!! README !!!" — first non-blank line of the ransom note
• "Backup contact (Qtox): 1A51DCBB33FBF603B385D223F599C6D64545E631F7C870FFEA320D84CE5DAF076C1F94100B5B" — last line of the ransom note (literal Qtox identifier)
• "DM[A-Z]{4}" regex — pattern of remote scheduled-task and service names created by the lateral-movement techniques
• "expand 32-byte k" — ChaCha20 sigma constant present in .rdata (libsodium-derived implementation marker)

15. MITRE ATT&CK Mapping

16. Summary

VECT 2.0 is a Windows x64 ransomware authored by an operator with strong red-team / Active Directory expertise but limited cryptographic engineering discipline. The malware combines an extensive lateral-movement toolkit (ten distinct PowerShell-based remote-execution primitives covering SMB, WMI, DCOM, WinRM, native scheduled tasks, and Windows services), a Safe Mode persistence chain designed to bypass endpoint protection, and a kill list curated specifically for enterprise environments (CommVault, Veeam, Symantec, MSSQL/Oracle/MySQL, QuickBooks). Recovery sabotage is thorough — Volume Shadow Copies are deleted, Microsoft Defender is disabled through a multi-flag Set-MpPreference call, and the binary self-deletes after encryption — and the artefact chain is anti-forensic-aware (PowerShell command history wipe, detached self-delete via the ping/del trick).

The cryptographic implementation, however, is poor. The 256-bit ChaCha20 key used to encrypt every file on every host is hardcoded at compile time and is not derived from any per-host or per-victim secret. A token "randomization" gesture is performed at runtime — a single byte from std::random_device is XOR'd byte-wise over an unrelated 64-byte region of the crypto context — but the actual key bytes (offsets 64..95 of the 97-byte context) are never modified after the static initialisation. Equally, for files larger than 128 KiB the ransomware applies an intermittent encryption scheme over four 32 KiB chunks but stores only the last chunk's nonce in the EOF footer; the nonces of the first three chunks are written to a stack-local buffer that is overwritten on every iteration and then discarded, so the corresponding ciphertext regions cannot be recovered even with full operator cooperation.

Finally, the ransom note's data-exfiltration claim is not backed by any networking code in this binary: no HTTP/HTTPS, no SMTP, no DNS tunnelling, no socket transport. SMB share enumeration and WS2_32 address-string utilities are present but are used solely for in-network read/write file access during local encryption.

The combination of competent operational tradecraft and amateur cryptographic engineering produces a malware that is dangerous (encryption is fast, broad in scope, and aggressively spreads laterally) but technically fragile: the universal-key flaw and the lost-nonce flaw are independent of any cryptanalytic effort and are properties of how the binary was built.