Bavacai — Technical Analysis / Windows

BAVACAI Ransomware — Full Analysis

1. Sample Identification

The binary is a single-stage ransomware encryptor built with verbose debug logging left in. Strings are not obfuscated — the only encrypted artefact is the embedded JSON configuration (PE resource id 101). The PDB path includes the developer's project tree, an internal slur as folder name, and the build subfolder — strong amateur-development signal. There is no anti-debug, no anti-VM, no anti-sandbox, no string obfuscation, no API hashing, no code injection, no packer; the whole pipeline is plainly visible to a casual reverser. The binary nonetheless ships with curated kill lists, multi-vector recovery inhibition, network-share enumeration, multi-threaded scanning, and a per-victim PKI hierarchy.

Imports (10 DLLs)

Notably absent: - No WinHTTP/WinINet/Ws2_32/socket APIs → no exfiltration in this binary, no C2 callback (the only outbound HTTP is api.ipify.org for victim IP fingerprinting) - No OpenSCManager/EnumServicesStatus → service stops are shell-spawned via net stop, not in-process - No CreateToolhelp32Snapshot → process kills are shell-spawned via taskkill, not in-process - No IsDebuggerPresent/NtQueryInformationProcess/CheckRemoteDebuggerPresent reachable from non-CRT code paths - No BCryptOpenAlgorithmProvider / CNG — relies entirely on legacy CryptoAPI (Microsoft Base Cryptographic Provider, MS_DEF_PROV) - No mutex API call (CreateMutexA/W/OpenMutexW) — no single-instance enforcement

2. Infrastructure

Infrastructure surface is thin and operator-grade: a single Tor file server (claimed to host victim data), a clearnet outlook.com address, and a Tox ID. No leak site URL is embedded; no chat-portal UUID; no per-build campaign identifier. The note text is entirely static — there is no per-victim cohort key or affiliate flag.

3. Ransom Note

Filename and deployment

WHATS_HAPPEND.txt (note the misspelling) — deployed by CreateNote after encryption finishes. Function CreateNote writes the note in:

• The root of every encrypted drive (per drive iterator Drive_EnumLogical at 0x140030A80 and Drive_EnumCipher at 0x140039F30)
• Every directory the scanner enters (per DirWalker at 0x14001AA20)
• Path-skip exclusions apply: directories matching any skipPathes substring receive no note

If openRequirementsOnFinish=true (default), the note is ShellExecute-opened on the operator's console at the end of the run.

Content (decrypted JSON field requirementsFileDataUTF8, 723 bytes)

DON'T PANIC!!! YOUR FILES ARE PERFECT AND SAFE!
We've found flaws in your security system and gained access to your internal corporate network. Your files were encrypted, and we can help you decrypt them and fix any existing security flaws.

We've also retrieved files from your servers, which will be published in 72 hours if you don't contact us.

Our contact information: qtox - 7C564920870C0D33535D2012ECDDE389FE25BAF7AF427DD584EE39C04AF8CF024F8BFA93D8DB
e-mail: nhuvgh@outlook.com
our tor fileserver with your files - http://t33zoj4qwv455fog7qnb2azi5xcdxkixughmmduzbw2rtdgryqfbh6id.onion

Your ID: [IDENTIFIER]

Please do not use file recovery services. They are either scammers or middlemen. In both cases, you will simply pay more.

The [IDENTIFIER] placeholder is replaced at runtime by Context__InitializePCInfo at 0x1400070E0:

1. Build a plaintext UTF-8 PCInfo blob via Util_GetPCInfo at 0x140033040. The exact line-by-line format is:

   IP: <api.ipify.org response> PC-Name: <GetComputerNameA> Domain: <GetComputerNameExA(ComputerNameDnsDomain)> CPU: <RegGetValueA HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ProcessorNameString> RAM: <GlobalMemoryStatusEx.ullTotalPhys / 1048576> MB Disks: \\.\PhysicalDrive0 \\.\PhysicalDrive1 ...

   Each section is omitted when the underlying API call fails. Disks are enumerated by opening \\.\PhysicalDrive<N> for increasing N until CreateFileA fails.

2. RSA-encrypt with master public key (multi-block PKCS#1 v1.5 → 5 × 256 = 1280 B output for the ~1 KB plaintext)

3. Base64-encode via CryptBinaryToStringA(CRYPT_STRING_BASE64 | CRYPT_STRING_NOCRLF)
4. Single string-replace of [IDENTIFIER] substring with the resulting base64 ID

Because the plaintext is a deterministic function of (hostname, DNS domain, CPU model, RAM, physical-disk count, external IP), two runs from the same machine produce different ciphertexts (RSA-PKCS#1 padding randomises) but the underlying plaintext digest is reproducible — useful for attacker-side de-duplication of victims contacting from different IPs over time.

The 72-hour exfil claim is not backed by code in this build — see §10 (Exfiltration). The ransom note hints at exfiltration the binary cannot perform.

4. Execution Flow

main at 0x14001F890

1.  setmode(stdout, _O_U16TEXT) — wide console output
2.  Argv parsing loop (i=1..argc):
      -help        → print usage, exit
      -network     → set flag: only network/UNC drives encrypted
      -skip_misc   → set flag: skip preRunCommands, recycle, wallpaper
      <unknown>    → "Unknown argument: <arg>" warning
3.  App_Run (0x1400081D0):
      a. SHGetFolderPathW for CSIDL 26 (APPDATA), 28 (LOCAL_APPDATA),
         46 (COMMON_APPDATA), 35 (WINDOWS), 36 (SYSTEM) — all appended
         to runtime skipPaths
      b. Context::LoadSettings → decrypt resource SETTINGS, parse JSON,
         hydrate global settings (extension, public key, etc.)
      c. Context::InitializeKeys → load HKLM\SOFTWARE\PAIDMEMES or
         generate fresh RSA-2048 victim keypair
      d. Crypto::RSA::ctor (master pubkey context)
      e. Context::InitializePCInfo → fetch external IP, build victim ID,
         substitute [IDENTIFIER] in note template
      f. Crypto::RSA::Cleanup
4.  hideConsole=true → ShowWindow(GetConsoleWindow(), SW_HIDE)
5.  Spawn Thread_HotkeyMonitor (0x14001EB90) — VK_INSERT/VK_HOME watcher
6.  Run preRunCommands (unless -skip_misc): 30 shell commands via
    Util_RunProcessElevated (no PPID spoof; sysnative WoW64 hop)
7.  FindFirstVolumeW / FindNextVolumeW iteration over all volumes
    including non-lettered \\?\Volume{GUID}\ entries; for each:
      - QueryDosDeviceW validates the NT mapping
      - Drive_EnumLogical (GetVolumePathNamesForVolumeNameW +
        SetVolumeMountPointW) mounts unmounted volumes at temp letters
8.  Drive_EnumCipher (GetLogicalDrives + GetDriveTypeW filter to
    REMOVABLE+FIXED+RAMDISK) — populates the local-drives vector
9.  Drive_EnumNetworkConnections (WNetGetConnectionW) — populates the
    mapped-network-drives vector
10. Privilege check: OpenProcessToken(TOKEN_QUERY) +
    GetTokenInformation(TokenElevation) → r15 = TokenIsElevated
11. Branch on elevation (master gate at 0x140020e8e):
      - elevated   → encrypt local drives only (the result of step 8)
                     + Util_RunProcess(<own_path> -network -skip_misc)
                       with PPID spoofed to explorer.exe to fork a
                       sibling process that handles the network drives
                       in parallel (see §10 PPID Spoofing)
      - not elev.  → encrypt mapped network drives only (step 9)
12. For each drive selected:
      a. CreateNote at root
      b. DirWalker recursion
         - StrStrIW skip-path check at every directory
         - For each file: extension skip check, then EncryptFile
         - threadPool=true → enqueue file path on thread pool
           (threadPoolMaxThreads=32, priority queue pulls
            threadPoolPriorityExtensions first)
13. Wait for all encryptor threads to drain
14. byte_1400B7B3C = 1 → signal Thread_HotkeyMonitor to exit
15. removeRecycle=true → SHEmptyRecycleBinW(NULL) per drive
16. backgroundImage=true → CreateAndSetBackgroundImage (renders the
    note text into a 1280×1024 BMP and sets it as wallpaper via
    SystemParametersInfoW(SPI_SETDESKWALLPAPER)) — disabled by this
    build's config (backgroundImage=false)
17. postRunCommands: 0 entries in this build — no-op
18. openRequirementsOnFinish=true → open the note in default handler

Privilege-asymmetric encryption strategy

Steps 8–11 implement a deliberate privilege-aware target split:

When admin, the binary additionally spawns a child copy of itself with the command line <own_path> -network -skip_misc, using the PPID-spoofing primitive described in §10 to make the child appear as a descendant of explorer.exe. The child then runs as the "non-elevated" branch and processes network drives in parallel with the admin parent's local-drive pass. The -skip_misc flag suppresses re-execution of preRunCommands, recycle-bin emptying, and wallpaper setting in the child — those side effects only run once, in the parent.

When not admin, the binary processes only what it has access to via existing user mappings, and does not attempt elevation, escalation, or new SMB authentication.

Volume coverage beyond drive letters

Step 7 (FindFirstVolumeW loop) is independent of drive letters. It runs before the elevation check and reaches every volume the OS exposes to the active user, including hidden recovery partitions, EFI System Partitions, and BitLocker-suspended volumes that have no letter assignment. For each such volume it calls SetVolumeMountPointW to mount it at a temporary letter, after which the standard drive-letter pipeline picks it up. The hard-coded skipPathes entries B:\Boot, A:\Boot, B:\EFI, A:\EFI, and :\Boot are expressly there to guard against re-encryption of these mount targets.

Thread architecture

When threadPool=true (default):

• A worker pool of up to threadPoolMaxThreads (default 32) consumes a producer-consumer queue fed by DirWalker
• The queue prioritises extensions in threadPoolPriorityExtensions = [".sql", ".bak", ".VHDX"] — ensures high-value VM/database files encrypt early so kills happen before volumes are unmounted by service stops
• One auxiliary thread (Thread_HotkeyMonitor) runs in parallel watching GetAsyncKeyState polled at ticks (no blocking hook)

If threadPool=false, EncryptFile is called inline from DirWalker for each file.

5. Encryption System

Key Hierarchy (3 layers)

                 [Master RSA-2048 keypair]
                  (private kept by operator,
                   public embedded in JSON config)
                            │
                            │ wraps
                            ▼
              [Victim RSA-2048 keypair]
              (generated/persisted in HKLM\SOFTWARE\PAIDMEMES;
               PRIVATEKEYBLOB stored under PRIVATE,
               wrapped with master pub via RSA-PKCS1)
                            │
                            │ wraps
                            ▼
        [Per-file ChaCha20 32-byte key + 8-byte nonce]
        (32+8=40 bytes random per file via CryptGenRandom,
         wrapped with victim pub key, footer-appended)

This is a textbook operator-master / victim / per-file three-tier key hierarchy. Recovery requires only the master private key — every encrypted file carries its own self-sufficient key envelope.

Asymmetric: RSA-2048 (legacy CryptoAPI)

Crypto::RSA::Encrypt at 0x14003D210 chunks input into ≤245-byte blocks (RSA-2048 PKCS#1 max plaintext) and concatenates the 256-byte ciphertexts. It is used for: - Per-file 40-byte key+nonce wrap (1 block × 256 B) - Victim PRIVATEKEYBLOB wrap during key generation (5 blocks × 256 B = 1280 B) - PCInfo wrap for victim ID generation (5 blocks × 256 B = 1280 B, base64-encoded)

Symmetric: ChaCha20 (DJB original variant, no MAC)

ChaCha20__InitState at 0x140002E90 performs the canonical state setup:

state[0..15]  = "expand 32-byte k"     // sigma
state[16..47] = key[0..31]              // 32-byte key
state[48..55] = 0                       // block counter (low+high = 0)
state[56..63] = nonce[0..7]             // 8-byte nonce
state[128]    = 64                      // keystream byte index, set in EncryptFile
                                        // ("flush" forces ChaCha block on first XOR)

The block function at sub_140003390 performs the standard 20-round ChaCha20 block (10 double-rounds: column + diagonal). Output is XORed against plaintext byte-by-byte from state[64..127] (the keystream block).

File Encryption Process — EncryptFile at 0x14001A2A0

1.  CreateFileW(GENERIC_RW, share=0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL)
2.  If failed with ERROR_SHARING_VIOLATION (32) or ERROR_LOCK_VIOLATION (33),
    AND path is not network → Util_RestartManagerUnlock:
       RmStartSession → RmRegisterResources → RmShutdown(RmForceShutdown)
       to force-close handles held by other processes (Office, SQL, …)
       → reopen
3.  Crypto::GenerateBytes(40) → buf[0..31]=key, buf[32..39]=nonce
4.  ChaCha20::InitState(state, key, nonce); state[128]=64; state[12..13]=0
5.  Crypto::RSA::Encrypt(victim_pubkey, buf40) → wrap = 256 B
6.  if (sizeof(wrap) != 256) throw "Bad password size: …"
7.  Crypto::CryptFile(hFile, state, ?, fileSize)  ── see §5 below
8.  Build footer (1544 B): victim_priv_blob_wrapped (1280) ‖ wrap (256) ‖
    qword(0x6) (8 bytes constant — sizeof(L".crypt") in chars)
9.  WriteFile(hFile, footer, 1544, offset=fileSize)
10. CloseHandle, MoveFileW(orig → orig + ".BAVACAI")

Intermittent Encryption — Crypto::CryptFile at 0x14003DDE0

Two parameters from the JSON config drive the pattern (bytesForEncrypt is loaded into global ::Size via LODWORD so its 32-bit value is what is consulted in the file-size comparison):

• bytesForEncrypt (BFE) = 630 057 793 bytes (≈ 601 MiB) — Range A maximum buffer size
• bytesCryptAndSkip (BCS) = 352 055 393 bytes (≈ 336 MiB) — chunk size of the inner encrypt-N / skip-N pattern

Algorithm:

size_A = min(fileSize, BFE)
read [0, size_A] into buffer of size_A bytes
v12 = 0
while v12 < size_A:
    encrypt min(BCS, size_A - v12) bytes at offset v12 (XOR ChaCha20 keystream)
    v12 += 2 * BCS                                        # skip BCS bytes
write buffer back at file offset 0

if fileSize > 2 * BFE:
    offset_B = fileSize - BFE
    read [offset_B, fileSize] into buffer of BFE bytes
    apply the same encrypt-BCS / skip-BCS inner loop on this buffer
    write buffer back at offset_B

Effective coverage (with the in-build constants BFE = 601 MiB, BCS = 336 MiB):

Two consequences of this exact wording of the inner loop:

1. Files larger than 1.2 GiB always have an unencrypted 265 MiB tail at the very end. Range B encrypts only the first 336 MiB of the last-601 MiB window, not the last 336 MiB of the file. The bytes in [fileSize − 265 MiB, fileSize] are never touched.
2. Range A coverage stops at offset 336 MiB even for files between 600 MiB and 1.2 GiB. The Range A buffer is 601 MiB but the inner loop encrypts only the first 336 MiB inside it, then the v12 += 2*BCS jump goes past the buffer end and the loop exits. The bytes [336 MiB, 601 MiB] of the Range A buffer are read into memory and immediately written back unmodified.

Because BCS itself is 336 MiB (larger than virtually any user document), the "skip" is never observed within a single encrypted span — the encrypt N, skip N pattern degenerates into "encrypt one contiguous chunk per Range, then exit". The intermittent-encryption knob is effectively dormant in this build; what acts is the per-Range cap. For typical files (≤ 336 MiB), the binary performs full file encryption.

The configured constants make the encryption strategy practically equivalent to: "encrypt up to 336 MiB at the start of every file, plus 336 MiB ~600 MiB before the end of files larger than 1.2 GiB". The strategy is tuned to corrupt VHDX/database/backup files large enough to make full-encryption time-prohibitive while still touching enough of the file structure to render it unusable.

Encrypted File Format

[ original file content, partially XORed with ChaCha20 keystream      ]
[ size: original size (unchanged) — encryption is in-place            ]

----- Footer: 1544 bytes appended at end -----
[ 0      ..  1279 ] : RSA(masterPubkey, victim_PRIVATEKEYBLOB)
                       — 5 × 256-byte PKCS#1 blocks
                       — recoverable only with master private key

[ 1280   ..  1535 ] : RSA(victim_pubkey, ChaCha20_key32 ‖ ChaCha20_nonce8)
                       — 1 × 256-byte PKCS#1 block
                       — recoverable with victim private key

[ 1536   ..  1543 ] : 0x06 0x00 0x00 0x00 0x00 0x00 0x00 0x00
                       — fixed 8-byte trailer = sizeof(L".crypt") = 6
                       — usable as YARA tail magic

Recovery flow (operator-side):

1. Operator has master private RSA-2048 key
2. Decrypt footer[0..1279] → victim PRIVATEKEYBLOB
3. Import victim private key into CryptoAPI
4. Decrypt footer[1280..1535] → 32 B key + 8 B nonce
5. Re-init ChaCha20 state, XOR over Range A (and Range B if applicable) → plaintext
6. Truncate file to (size – 1544), strip .BAVACAI extension

Recovery feasibility for the victim: zero. Without the master private RSA key, neither inline footer nor registry blob is reachable. Both bavacai_rsa_pubkey.pem (2048-bit n+e) and the registry-resident victim public key are public information; the corresponding private keys are not in the binary.

6. File Targeting

Targeted extensions

All files except those matched by skipExtensions — there is no allow-list. Extension matching uses PathFindExtensionW followed by case-insensitive comparison against the skip list.

Excluded directories — substring match via StrStrIW on each directory path

JSON config skipPathes (typo) — 13 entries:

Runtime additions (appended in App_Run):

The hard-coded path list also contains hard-coded JSON entry \AppData\ (substring), which means any directory path containing the substring "\AppData\" is skipped — a wider exclusion than just %AppData%. Likewise \Google\Chrome\ excludes Chrome user data.

Excluded extensions

The .readtext* glob is never used — comparison is exact-string, not glob. So in practice only .dll and .sys are skipped.

Excluded files

None hard-coded. The ransom note WHATS_HAPPEND.txt is not in any excluded list — it would be re-encrypted by a second pass if the binary were re-run, but the encrypted file would have extension .BAVACAI, breaking the substring check on note name. The 4 bytes of effort it would have taken to skip the note are absent.

Linux/NAS leftovers — startPathes (sic)

"/volume/", "/vmfs/", "/share/", "/volumeusb/",
"/volume0/", "/volume1", "/volume2", "/volumeUSB1",
"/volume3", "/volume4", "/volume5", "/volume6", "/shares"

These 13 entries are completely dead in this Windows binary. The string "startPathes" is absent from .rdata — neither IDA's strings analysis nor strings(1) over the raw image returns a match. The Windows binary therefore cannot read this JSON field; the entries are pure config bloat inherited from a Linux/ESXi/Synology variant (notable /vmfs/ for ESXi, /volumeusb/ and /volume[0-6]/ for Synology DSM, /shares for QNAP). The presence of these paths in the JSON template strongly suggests an existing or planned non-Windows counterpart in the same family.

7. Recovery Inhibition

All recovery-inhibition is shell-spawned via cmd.exe /c <cmd> (not in-process). The 7 commands embedded in preRunCommands (config-defined, not hard-coded in .text):

Two of the seven recovery-inhibition commands silently fail due to typos (SYSTEMSTABACKUP, recoverynabled); a third (wmic.exe SHADOWCOPY /nointeractive without delete) is essentially a no-op listing. Net effect: VSS deletion and bcdedit boot-status policy do take effect; system-state backup deletion and bcdedit recovery-enable do not.

8. Targeted Services (10 explicit net stop)

MSSQLServerADHelper100   MSSQL$ISARS         MSSQL$MSFW
SQLAgent$ISARS           SQLAgent$MSFW       SQLBrowser
REportServer$ISARS       SQLWriter

Plus taskkill -f -im of equivalent service binaries. Service stops cover the MSSQL Server product family (Forefront/ISA-Reporting "ISARS" and "MSFW" are the historical instance names of Microsoft Forefront Threat Management Gateway / ISA Server) — i.e. the malware targets very specific legacy MSSQL deployments.

There is no OpenSCManager/EnumServicesStatus/StopService in-process — all stops go via cmd.exe /c net stop <svc>. There is no service-name pattern matching; the list is fixed.

9. Targeted Processes (13 taskkill -f -im)

sqlbrowser.exe          sql writer.exe (typo - should be sqlwriter.exe)
sqlserv.exe             msmdsrv.exe
MsDtsSrvr.exe           sqlceip.exe
fdlauncher.exe          Ssms.exe
SQLAGENT.EXE            fdhost.exe
ReportingServicesService.exe
msftesql.exe            pg_ctl.exe
"taskkill -f -impostgres.exe"  (missing space — never executes)

Two entries are broken:

• sql writer.exe — process name with embedded space; without quotes taskkill parses this as two arguments, fails
• taskkill -f -impostgres.exe — -im joined with postgres.exe; taskkill rejects the malformed switch

So PostgreSQL (postgres.exe) and SQLWriter (sqlwriter.exe) effectively survive preRunCommands. The intent was clearly to cover both Microsoft SQL Server, SSIS/SSRS/SSMS, MS Search, and PostgreSQL — but the kill list is buggy in this build.

10. Persistence & Evasion

Operator-side persistence (registry — victim side)

Only these two values are written. There is no SETTINGS registry value — the wide string "SETTINGS" at 0x14009C6E0 is referenced exactly once, at 0x1400050CF, where it is passed as the lpType parameter to FindResourceW(101, "SETTINGS") to load the ChaCha20-encrypted JSON config from the PE resource directory. Runtime configuration comes exclusively from the PE resource; no registry-based override path exists.

Util_LoadKeyEntry_PUBLIC_PRIVATE (0x140004D30) reads PUBLIC and PRIVATE on every run; if both decode and RSA-import successfully, fresh keys are not generated. With regenerateKeysAlways=false (default), this means a single victim machine is encrypted with the same victim keypair across multiple runs of the binary.

The PAIDMEMES registry key name is a deliberate edgy/troll handle — not an MSSQL vendor or product key.

Parent PID Spoofing (T1134.004)

Util_RunProcess at 0x14003AD60 is the malware's only PPID-spoofing primitive. The sequence:

1. GetShellWindow() → handle to the desktop's shell window (typically owned by explorer.exe)
2. GetWindowThreadProcessId(shellWnd, &pid) → resolve the explorer PID
3. OpenProcess(PROCESS_CREATE_PROCESS = 0x80, FALSE, pid) → handle on explorer.exe (no read/query rights — only the right needed for UpdateProcThreadAttribute)
4. InitializeProcThreadAttributeList(NULL, 1, 0, &size) to size the attribute list, then a real-allocated init pass
5. UpdateProcThreadAttribute(attrList, 0, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS = 0x20000, &hExplorer, sizeof(HANDLE), NULL, NULL) — declares explorer.exe as the parent of the to-be-spawned process
6. CreateProcessW(NULL, lpCommandLine, ..., dwCreationFlags = 0x80010 (EXTENDED_STARTUPINFO_PRESENT | CREATE_DEFAULT_ERROR_MODE | CREATE_NO_WINDOW), ..., &startupInfoEx, &pi) with the extended STARTUPINFOEX.lpAttributeList

The single call site in main is at 0x140020D5D, and the command line built immediately before is <own_path> -network -skip_misc. The admin process therefore self-relaunches with explorer.exe recorded as parent so that the network-drive child is not visibly a descendant of the admin malware in EDR/Sysmon process trees.

WoW64 redirection hop in preRunCommands execution

Util_RunProcessElevated at 0x140030530 (which runs every entry of preRunCommands and postRunCommands and also the hotkey-thread's explorer restart) wraps each command line as:

<windir>\SysWOW64\cmd.exe /c %windir%\sysnative\cmd.exe /c <command>

This is a 64 → 32 → 64 process hop via the WoW64 redirection alias sysnative. The 32-bit cmd.exe (in SysWOW64\) starts as a WoW64 process; from a WoW64 process, the path %windir%\sysnative\ resolves to %windir%\System32\ (i.e. the 64-bit binaries) and re-spawns the native 64-bit cmd.exe to execute the actual command. Net effect for monitoring: the parent-child chain becomes bavacai.exe → SysWOW64\cmd.exe (WoW64) → System32\cmd.exe → <recovery_command>, breaking detection rules that match <malware> → cmd.exe → vssadmin/taskkill directly. This is not PPID spoofing — it adds extra real cmd parents into the chain rather than rewriting the recorded parent.

Console hide

hideConsole=true (default in this config) → after App_Run returns, ShowWindow(GetConsoleWindow(), SW_HIDE) removes the window from the user. This is not an analysis-evasion technique — Console-Mode hide does not prevent process or kernel-mode introspection — but it serves the operator UX (silent execution).

Hotkey monitor — Thread_HotkeyMonitor at 0x14001EB90

A background thread polls (no hook) every iteration:

• VK_INSERT (0x2D) pressed → toggle visibility of every window owned by the current PID via EnumWindows+ShowWindow(SW_HIDE/SW_SHOWNORMAL). Used by the operator to peek at the encryption progress on a hidden console.
• VK_HOME (0x24) pressed AND console window is foreground → spawn taskkill /f /im explorer.exe then start explorer.exe (via Util_RunProcessElevated, no PPID spoof). Forces a desktop refresh — used to make a wallpaper change visible immediately. Only triggers when the operator is sitting at the console.

These are operator UX features, not anti-analysis. They do not disable when a debugger is attached.

Anti-debug / anti-VM / anti-sandbox

None. The only IsDebuggerPresent calls are in MSVC CRT crash handlers (__scrt_fastfail, __acrt_call_reportfault) and serve the standard purpose of routing fatal-error reporting; they do not gate the encryption logic. There is no RDTSC timing check, no CPUID hypervisor-bit check, no NtQueryInformationProcess(ProcessDebugPort), no NtQuerySystemInformation(SystemKernelDebuggerInformation), no GetTickCount-delta check, no WMI Win32_BIOS / Win32_ComputerSystem VM-vendor lookup, no MAC-prefix VM check, no installed-program enumeration.

String obfuscation

None. All strings are stored either:

• In plaintext in .rdata (the implementation strings: error messages, JSON parse keys, registry value names, the markers TRUMPTRUMP… and PUTLERPUTLER themselves)
• In the ChaCha20-encrypted PE resource id 101 of type SETTINGS (the IOC-bearing strings: onion URL, email, Tox ID, ransom note text, master public key)

The encryption of the resource is functionally string obfuscation but trivially reversed — the ChaCha20 key (TRUMPTRUMP…) and nonce (PUTLERPUTLER) are themselves plaintext strings in .rdata, passed by reference to ChaCha20::Init at 0x14000511D.

API hashing / dynamic resolution

None. Imports are static; no LoadLibrary/GetProcAddress walks; no PEB.Ldr traversal; no FNV/CRC32/SDBM hash table.

Anti-Analysis Summary

There is no string obfuscation, no API hashing, no runtime anti-debug, no anti-VM, no sandbox evasion. The only proper obfuscation is the single ChaCha20 layer over the PE config resource, defeated by the plaintext key two .rdata entries away.

11. Command-Line Arguments

Anything else triggers Unknown argument: <arg> log line then a normal run.

12. Static Imports Summary

13. IDA Analysis — Renamed Functions

14. Indicators of Compromise (IOCs)

Hashes

Network

Files

Registry

Behavioural

• Spawns 30 child cmd.exe processes within seconds of launch (all from the static preRunCommands list)
• 13× taskkill -f -im of MSSQL/MSDTS/SSMS/PostgreSQL processes
• 7× net stop of MSSQL service variants (instances ISARS, MSFW)
• 1× vssadmin Delete Shadows /All /Quiet, 3× wbadmin delete, 1× wmic.exe SHADOWCOPY, 2× bcdedit.exe /set {default} — note 3 of these silently fail (typos)
• RegCreateKeyExW HKLM\SOFTWARE\PAIDMEMES, then RegSetValueExW of PUBLIC and PRIVATE blobs
• File handles released via RmStartSession for any locked target file
• SHEmptyRecycleBinW on every drive at end of run
• In-place encryption only — no shadow copy of original; MoveFileW rename to <orig>.BAVACAI
• 32 simultaneous encryption threads (threadPoolMaxThreads default)
• Outbound HTTPS to api.ipify.org exactly once per run

Distinctive Strings (.rdata, plaintext)

• "TRUMPTRUMPTRUMPTRUMPTRUMPTRUMPTRUMP" (35 chars — ChaCha20 key string)
• "PUTLERPUTLER" (12 chars — ChaCha20 nonce string)
• "SOFTWARE\\PAIDMEMES" (registry root)
• "[IDENTIFIER]" (note placeholder)
• "--------------------------------" (32 dashes — log separator)
• "J:\\edu\\niggerProject\\bin\\Publish\\locker_win_x64_encrypter.pdb" (PDB path)
• "Crypto::RSA::GenerateKeys", "Crypto::RSA::Encrypt", "Context::InitializeKeys", "EncryptFile", "CryptFile" (verbose log function names)
• "chiperDrives" (typo "cipher")
• "skipPathes" (typo "Paths")

Distinctive Strings (encrypted JSON config — requirementsFileDataUTF8)

• "DON'T PANIC!!! YOUR FILES ARE PERFECT AND SAFE!" (note opening line)
• "WHATS_HAPPEND.txt" (note filename)
• "qtox - 7C564920870C0D33535D2012ECDDE389FE25BAF7AF427DD584EE39C04AF8CF024F8BFA93D8DB" (full Tox ID)

15. MITRE ATT&CK Mapping

16. Summary

BAVACAI is a single-stage Windows x64 ransomware distributed as a self-contained PE32+ console executable (~735 KB). Encryption combines RSA-2048 (Microsoft legacy CryptoAPI, PKCS#1 v1.5, e=65537) for key wrapping and a custom ChaCha20 implementation (DJB original 8-byte nonce variant, no Poly1305) for bulk file content. The cipher key for every encrypted file is freshly generated from CryptGenRandom, wrapped with the victim's per-machine RSA-2048 public key, and appended along with the master-pub-wrapped victim PRIVATEKEYBLOB into a 1544-byte footer — yielding a self-contained recovery envelope per file that requires only the master private key.

The binary's operator surface is rich: 30 pre-run shell commands, 13 process kills + 7 service stops, multi-vector recovery inhibition (vssadmin / wbadmin / wmic / bcdedit), Restart Manager file-handle release, recycle-bin emptying, optional wallpaper change, optional console hide, mount-unmounted-volume support, mapped network drive enumeration, IPv4 external IP fingerprinting via api.ipify.org, and a 32-thread producer-consumer pool prioritising .sql / .bak / .VHDX. Configuration is read from a single ChaCha20-encrypted PE resource keyed by the plaintext strings "TRUMPTRUMPTRUMPTRUMPTRUMPTRUMPTRUMP" / "PUTLERPUTLER" — trivially decoded.

Cryptographic engineering is mostly correct but unauthenticated (no MAC over file content, vulnerable to bit-flip on the encrypted stream, but in practice unrecoverable for the victim because the per-file key is unrecoverable without the master). The engineering quality is otherwise amateur: the PDB path includes a slur as folder name, JSON keys contain typos (skipPathes, chiperDrives), the recovery-inhibition shell list contains 2 typos that silently fail, the kill list contains 2 malformed entries that never run, and the verbose error logs leak full class::method names (Crypto::RSA::Encrypt, Context::InitializeKeys, …) that map directly back to the source layout.

Operational sophistication is moderate: the kill-list is curated for MSSQL/MSDTS/SSMS environments specifically (instance names ISARS, MSFW are historical Forefront/ISA Server), the threadPoolPriorityExtensions includes .VHDX (Hyper-V) and .bak (SQL Server backups), and Restart Manager is correctly used to recover locked database files — these are deliberate choices targeting Windows Server / Hyper-V / SQL Server estates. Network-share encryption is opt-in via -network; lateral movement, AD enumeration, PowerShell invocation, RDP enumeration, scheduled-task creation, service install — none are present. There is no exfiltration component, despite the "72 hours if you don't contact us" leak claim in the note.

The infrastructure is single-handle (one Tor file server, one outlook.com mailbox, one Tox ID), the per-victim ID is reproducible-by-hostname (no random salt), and the binary contains no anti-debug, no anti-VM, no anti-sandbox, no string obfuscation, no API hashing, no packing — making this an inventory-friendly low-effort variant suitable for IR triage but with no in-place recovery option for the victim: every file's key is wrapped exclusively against the master key.

Appendix A — Master RSA-2048 Public Key (PEM)

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0dtZGZGXTx1FWagCvFRC
Hr616k+7WrBT9CYCbyUVGSvuJ2Oe1pgW/U2N4LTmWxdYlZVFXEdRdKChfBC9biu5
meLxps2zpdsvV/9IAKUYIfSvSE3UBVaw7EUaYAS1ykj6o+FLTwEp+jqro001P7vn
GoiMIADie/v1oibQk1AQjKByEMmaZqGjD7wfpVeV/wdcLhPt+r6TGz7IldayOG6o
3IM52DFtjihWBL3g0iJYHPZW0CHb23fTz+EEh8JHshuH1G4lEvmZBTfaQjpFpCHo
2Rm2meNODI968tHKJ6ZMzGx0SUaVvXmuKckbCUg7Ve3TjvdMT/3NEFEeDJ9WBbn4
yQIDAQAB
-----END PUBLIC KEY-----

Modulus (BE): d1db59 19 91 97 4f 1d 45 59 a8 02 bc 54 42 1e be b5 ea 4f bb 5a b0 53 f4 26 02 6f 25 15 19 2b ee 27 … (full 256 B in bavacai_rsa_pubkey.der).

Appendix B — Wallpaper rendering (build-disabled)

Although backgroundImage=false in this build, the code path at 0x140039C50 (Util_SetWallpaper) and 0x140039530 (rendering helper) is fully present and would activate on a build that flips the flag. The output is a fixed 1280×1024 BMP:

The output BMP path is a global initialised in App_Run (pvParam / xmmword_1400B0DE0).