# A Programmer's View On Conti-Locker ## Introduction *** * I am writing this because a majority of articles summarize how this ransomware works but don't go into much detail on how the code works. I will be looking at the leaked source code of Conti-Locker ransomware and explaining in detail how it's code works using flowcharts and my knowledge on system programming. I hope this also helps future malware writers/ red-teamers make similar prototypes for adversary simulations. * Conti-Locker is a ransomware developed by the Conti Ransomware Gang, a Russian-speaking criminal collective with suspected links with Russian security agencies. Conti Ransomware Gang operated with a Ransomware-as-a-service (Raas) model. A summary on the gang can be found at the [forescout website](https://www.forescout.com/resources/analysis-of-conti-leaks/). * In the Raas model, a ransomware developer/group designs and creates a ransomware and lends it to affiliates or "Operators" who use it on organizations in return for a percentage of the profit. This model has become infamous in the recent times due to it's popularity and ease of use. The technical intricacies of developing a ransomware rests on the group whereas the operators just utilize it to ransom organizations. This with addition with social-engineering means the ceiling for conducting cybercriminal activities has dropped down to such a level that even people with bare-minimum technical skills can conduct ransomware activities. * The source code was leaked by an disgruntled affiliate in revenge for the cybercriminals siding with Russia on the invasion of Ukraine on January 25th, 2021. ## Encryptor *** #### Setup * The ransomware first sets up a custom structure named "string\_" which contains a character array of length 16384 bytes and a doubly linked tail queue which holds "**Entries**". This structure is then used in another doubly linked tail queue named "string\_list\_" which takes a "**STRING\_LIST**".

* After these structures are created, there is a function named "my\_stoi" which is a custom implementation of extracting integers from a string (probably to avoid winAPIs in the IAT). While the implementation is not that computationally efficient (because it multiplies digits by powers of 10 and adds them up), it does the work.

* Below that is a "**ParseFile**" function which supposedly takes in a FilePath and a list of filenames and parses their contents. The function expects the input file to be encoded in an OEM/DOS-style character set and converts each line to a Unicode (wide character) string before adding it to the list. While being a bit rudimentary, it's implementation is actually very clever. Instead of directly giving string literals, it is dynamically hashing the APIs and it's usage of TAILQ ensures that the parsing process is extremely efficient.

* The command-line arguments are parsed by the "**GetCommandLineArg**" function which performs a non-case sensitive comparison of the CLI arguments against a list using **plstrcmpiW** WinAPI. But the actual handling of the arguments is done by "**HandleCommandLine**" function. Following are the CLI options of Conti-Locker - 1. "-h" -> Specifies the HostsPath 2. "-p" -> Specifies the pathlist 3. "-m" -> Specifies the encryption mode 4. "-log" -> Enables Logging * Conti-Locker has 4 types of encryption modes available. We will look into thes soon. * ALL\_ENCRYPT (Enabled by default) * LOCAL\_ENCRYPT * NETWORK\_ENCRYPT * BACKUPS\_ENCRYPT * More configuration options are available in the "global\_parameters.cpp" file including extensions, mutex names, etc.

#### Main Function * Below is a simplified flowchart of what the ransomware does in general. We will delve deeper into what it does in detail soon.

* As seen in the flowchart, the first thing that the ransomware does is create a system-wide mutex to ensure only one instance of the ransomware runs at a time. The mutex name, `"kjsidugidf99439"`, is obfuscated using the `OBFA` macro to prevent detection based on a known string. Also "**pWaitForSingleObject**" WinAPI is used to check if a mutex already exists. If it does, it immediately exits. * Then it performs dynamic API resolution, which loads WinAPIs during runtime using **LoadLibrary** and **GetProcAddress**. This is defined in then namespace of **api::InitializeApiModule().** * After that it finds and disables function hooks placed by antivirus (AV), Endpoint Detection and Response (EDR), or analysis tools on critical Windows API functions. By unhooking these functions, the ransomware can execute its operations (like file I/O or process manipulation) without being monitored or blocked. * The code then initializes five separate linked lists using the `TAILQ` (tail queue) macro. These lists will be used to manage the malware's state and targets: * `g_WhitelistPids`: A list of Process IDs (PIDs) that should **not** be terminated by the `prockiller` module. * `DriveList`: A list of local drives (e.g., C:, D:) to be scanned for files. * `ShareList`: A list of network shares (e.g., `\\SERVER\share`) discovered during the network scan. * `g_PathList`: A list of specific file paths provided via the command line to be encrypted. * `g_HostList`: A list of specific network hosts provided via the command line to be targeted.

* It then parses CLI arguments and setups various ThreadPools for multi-threading. * Before the encryption process though, it does pre-encryption steps to ensure no are the attack is successful - * `locker::DeleteShadowCopies()` - It executes a command (likely using `vssadmin.exe delete shadows /all /quiet`) to delete all Volume Shadow Copies. This prevents the victim from using the "Previous Versions" feature in Windows to easily restore their encrypted files. * `process_killer::GetWhiteListProcess(&g_WhitelistPids)`- Populates the `g_WhitelistPids` list with processes that are critical for system stability or for the ransomware's own operation, ensuring they are not terminated. * `locker::SetWhiteListProcess(&g_WhitelistPids)`- This passes the whitelist to the encryption module so it can avoid encrypting files that are currently in use by these whitelisted processes, preventing system crashes.

* Finally, the encryption process is started. As per the provided encryption scope, the ransomware recursively enumerates local, network and backup drives and encrypts them. Multiple thread pools are started at once to encrypt files as soon as possible. * Now that we know what the ransomware does in general, we can delve deeper. #### Logging Capabilities

* This module is designed to record the malware's operational progress and any errors it encounters for debugging or tracking purposes by the malware authors. The ransomware utilizes a **CRITICAL\_SECTION** to synchronize threads writing to the log file. A logfile named - "**CONTI\_LOG.txt**" is created in the C drive and logs are written there. * The malware's logging namespace has two functions, namely - "Init" and "Write". Init function initializes the critical section, creates the log file with appropriate permissions and makes it "**FILE\_FLAG\_WRITE\_THROUGH**" i.e it forces the operating system to write data directly to the disk, bypassing the system's write cache. This ensures that log entries are not lost if the system crashes or is abruptly powered off.

* The Write function enables the thread pools to write their debug logs to the logfile. It first checks the availability of the log file, locks the critical section (If another thread is already inside this block, this thread will pause and wait until the other thread calls `pLeaveCriticalSection`) and writhes the log to the file. * The log is written in the format of -> Timestamp: Log contents.

#### Obfuscation * Before moving on to other parts, we need to quickly see how Conti-Locker obfuscates the strings to prevent static detection. This will make it easier to know how the anti-security measures are used. The "OBFW" macro that we have been seeing in the code up until now is a part of this obfuscation suite.

* The engine first generates a random number during compilation. The numbers are not generated when the program runs, but when the compiler is building it. This is achieved through C++ template metaprogramming (TMP). It first creates a starting `seed` value by parsing the `__TIME__` preprocessor macro, which ensures the seed changes every second the code is compiled. It then uses this seed in a compile-time implementation of a `LinearCongruentialEngine`, a classic pseudo-random number algorithm, which recursively calculates a final random integer. * The core idea of the obfuscation engine is to obfuscate each byte of a string literal at compile time using random keys, then decrypt it at runtime only when the string value is needed, so that the decrypted string never exists persistently in the program’s binary data. It's flowchart is given below.

* It utilizes Extended Euclidean Algorithm at compile time to find the modular multiplicative inverse of an integer modulo for the affine encryption scheme used in this system. In this context, for any encryption parameter `A`, its modular inverse modulo 127 is needed during decryption to reverse the affine transformation applied at encryption. * The main work is performed by the `MetaBuffer` template class, which is parameterized by two encryption keys, `A` and `B`, and a compile-time sequence of indexes indicating string positions. When a `MetaBuffer` is instantiated with a string and a sequence of indexes corresponding to its length, its constructor encrypts each character of the string at compile time using an affine cipher: `E(x) = (A * x + B) % 127`. The encrypted form is stored in a buffer. At runtime, calling the `decrypt()` method on the buffer will, if not already done, iterate through the buffer and apply the inverse affine decryption formula (`D(y) = A_inv * (y - B) % 127`, where `A_inv` is the modular inverse of `A`) to recover the original bytes, marking the buffer as decrypted. * The `OBFA` and `OBFW` macros provide a convenient way for obfuscation directly on ANSI and Unicode string literals, respectively. Macros such as `_TSTR`, `_STR`, and `_WCS` allow for portability between character set types and conditionally switch the method of string handling based on build configuration. * Using these macros essentially means that strings are encrypted at compile-time and decrypted at runtime. I found this extremely clever and I admire the creativity that went into this obfuscation engine. #### Process Killer * This is one of the modules that is present in the ransomware but isn't used that much. The Process killer namespace has 2 classes - GetWhiteListProcess and KillAll. The latter has been commented out and is out of scope, so we will be mainly talking about the first.

* Before the function logic begins, the code defines the necessary data structures for managing the whitelist. The `PID` struct represents a single node in this list, containing a `DWORD` to hold the numeric `dwProcessId` and a `TAILQ_ENTRY` macro that embeds the necessary forward and backward pointers for list traversal. The `PID_LIST` type defines the head of this list, which acts as the main handle for the entire collection. The function `GetWhiteListProcess` accepts a pointer to one of these lists (`PPID_LIST`) as an `__out` parameter, indicating that the function's primary job is to populate this list, which was created and initialized elsewhere in the program.

* The **GetWhiteListProcess** function identifies the process ID (PID) of the Windows Explorer shell (`explorer.exe`) and add it to a dynamically constructed list. This function's purpose is terminate the `explorer.exe` service to ensure it doesn't hold files open (like databases, office applications, or backup agents) to ensure they can be encrypted.

* The function's core operation begins by leveraging the Windows Tool Help Library to enumerate all processes currently running on the system. This is initiated with the `CreateToolhelp32Snapshot` API call, using the `TH32CS_SNAPPROCESS` flag to specify that it needs a point-in-time snapshot of all active processes. * It then prepares a `PROCESSENTRY32W` structure, which will serve as a container for the information of each process retrieved from the snapshot. Finally with the setup complete, `Process32FirstW` is called to retrieve the first process from the snapshot, priming the main loop.

* This loop iterates over all the snapshotted process until it stumbles upon `"explorer.exe"`. Most importantly, the target string `"explorer.exe"` is not present as a plaintext literal. Instead, it is wrapped in the `OBFW` macro, which invokes the advanced compile-time string obfuscation engine. * When the loop identifies the `explorer.exe` process, it proceeds to add its PID to the whitelist. It first allocates memory for a new `PID` list node using `m_malloc`. The process ID is copied from the `pe32.th32ProcessID` field into the `dwProcessId` member of the newly allocated node. Finally, the `TAILQ_INSERT_TAIL` macro is called. This function takes the list head (`PidList`), the new node (`Pid`), and the name of the entry member (`Entries`) and safely and efficiently appends the new node to the very end of the whitelist. This process is repeated for every instance of `explorer.exe` found, although typically there is only one. #### FileSystem Scanner * Conti-Locker utilizes it's `FileSystem` namespace to scan the local disks for data and files to encrypt. Similarly to before modules, it creates a `drive_info` structure for this namespace. This structure contains a wstring value - **RootPath** , which supposedly stores the file path of each scanned file and a TAILQ\_ENTRY macro.

* The `EnumirateDrives` function identifies all logical drives present on the system (e.g., `C:\`, `D:\`, removable drives) and compiles them into a linked list for later processing. This serves as the starting point for the local encryption phase of the ransomware. * It initializes a `TAILQ` (a type of linked list) named `DriveList`, which will store the root paths of the discovered drives and makes an initial call to the Windows API function `pGetLogicalDriveStringsW` with a `NULL` buffer. This is a standard technique to query the API for the required buffer size to hold all the drive strings. * Then it allocates a memory buffer and calls `pGetLogicalDriveStringsW` a second time, now with the allocated buffer, which the API fills with a sequence of null-terminated strings (e.g., `"C:\"`, `"D:\"`, `"E:\"`), followed by a final extra null terminator to mark the end of the entire list. * After that, it enters a **while** loop to parse the string buffer. The loop iterates through each null-terminated string in the buffer and for each drive string found (e.g., `"C:\"`), it creates a `DRIVE_INFO` structure, stores the drive's root path in the structure and finally uses `TAILQ_INSERT_TAIL` to add this `DRIVE_INFO` node to the end of the `DriveList.`

* Optionally if the logging function is enabled, it writes a summary message stating the total number of drives found (e.g., "Found 3 drives:") and the path of each individual drive found.

* Before going to the next major function, we need to go over some minor utilities first. The utility **`MakeSearchMask`** takes a directory path and creates a search mask suitable for `FindFirstFileW`. It correctly appends `\*` to the path, ensuring it handles paths that do or do not end with a backslash.

* The **`MakePath`** utility safely combines a directory path and a filename into a full path, adding a backslash only if needed.

* Next, the `CheckDirectory` utility checks if a given directory name contains any substrings from a hardcoded blacklist and the `CheckFilename` utility performs blacklisting for files. The hardcoded blacklist is given in the picture below.

* The **`DropInstruction`** function is responsible for creating the ransom note file (`R3ADM3.txt`) in a given directory. It calls `global::GetDecryptNote` to get the content of the note and writes it to the file using `pCreateFileW` and `pWriteFile`. * The main `SearchFiles` function aggregates everything to execute a comprehensive, non-recursive file search using a breadth-first search (BFS) algorithm. It initializes a `TAILQ` to act as a queue for directories to visit, starting with the provided `StartDirectory`. The main `while` loop continues as long as this queue is not empty, dequeuing one directory at a time for processing. * For each directory, it immediately calls `DropInstruction` to plant the ransom note. It then uses `pFindFirstFileW` and `pFindNextFileW` to enumerate every file and subdirectory within it. If the item is a directory and not on the `CheckDirectory` blacklist, it is added to the end of the queue for future processing. If the item is a file and it passes the `CheckFilename` blacklist checks, it is deemed a target. * Instead of encrypting the file directly, this function acts as a "producer" in a producer-consumer pattern; it submits the full file path as a task to a designated thread pool via `threadpool::PutTask`. This architecture allows the file discovery process to run in parallel with the CPU-intensive encryption process, maximizing throughput. The function even includes a back-pressure mechanism, temporarily suspending itself if the task queue grows too large, which prevents excessive memory consumption. * Finally the `StartLocalSearch` function serves as the high-level entry point that initiates the entire local filesystem attack. It is designed to be executed in its own thread, created by a function like `CreateThread.` * The function receives a single argument: a pointer to the `DRIVE_LIST` that was populated by the `EnumirateDrives` function. It then iterates through this list using a `TAILQ_FOREACH` loop. For each drive it finds in the list, it logs the action for debugging purposes and then calls the main `SearchFiles` function, passing the drive's root path as the starting point and specifying the `LOCAL_THREADPOOL` as the target for all encryption tasks generated. #### Network Scanner * After scanning the local filesystem, Conti-Locker moves on to the network if given the option. In a nutshell, this module enumerates SMB shares, asynchronously connects to them and adds them to a `HostList`.

* The module begins by defining the core data structures and global variables that manage the state of the entire scanning operation. These structures are built around `TAILQ` queues. The structures are - * **`SUBNET_INFO` and `SUBNET_LIST`**: This list is used to store the base addresses of all local subnets that need to be scanned (e.g., 192.168.1.0, 10.0.0.0). The scanner will generate all possible host IPs within these subnets. * **`HOST_INFO` and `HOST_LIST`**: This is a thread-safe work queue. Once the scanner confirms that a specific IP address is alive and has the SMB port (445) open, a `HOST_INFO` structure containing that IP is added to this list. A separate worker thread will consume hosts from this list to perform the next stage of the attack. * **`CONNECT_CONTEXT` and `CONNECTION_LIST`**: This is the most complex structure, designed specifically for the asynchronous IOCP model. Each `CONNECT_CONTEXT` holds all the state for a single connection attempt to a single IP address. This includes the `OVERLAPPED` structure required by IOCP, the `SOCKET` for the connection, the target IP address (`dwAddres`), and a `State` flag (`CONNECTED`, `CONNECTING`, `NOT_CONNECTED`). The `CONNECTION_LIST` holds all the connection contexts for a single batch of IP addresses being scanned simultaneously.

* Before the scanning can begin, Conti-Locker gathers information about its environment and loads necessary functions. The functions are - * **`GetConnectEX`**: This function dynamically loads the `ConnectEx` function pointer. `ConnectEx` is a powerful Microsoft-specific Winsock extension that can initiate a connection and wait for its completion asynchronously. To get a pointer to it, the code must create a dummy socket and use the `WSAIoctl` function with the `SIO_GET_EXTENSION_FUNCTION_POINTER` command. * **`GetSubnets`**: It queries the system's ARP table (the mapping of IP addresses to physical MAC addresses on the local network) by calling `GetIpNetTable`. It then iterates through every entry in this table, intelligently filtering for IPs that belong to private network ranges. For each valid private IP it finds, it extracts the subnet (by taking the first three bytes of the IP address, e.g., 192.168.1) and adds it to the `SubnetList`, ensuring that each unique subnet is only added once. This effectively tells the malware which network segments to target for its port scan. * **`EnumShares`**: Once a live host has been identified, this function is called to enumerate its available file shares. It uses the `NetShareEnum` Windows API function to query the remote machine for a list of its shares. It specifically filters for disk shares (`STYPE_DISKTREE`) and special or temporary shares, while explicitly blacklisting the administrative `ADMIN$` share to avoid unnecessary noise or permission errors. For each valid, accessible share found, it constructs the full UNC path (e.g., `\\192.168.1.10\Public`), logs the discovery, and adds the path to a `ShareList` for subsequent processing by the file encryption engine.

* The actual scanning happens in the `PortScanHandler` and it's helper functions. This is a dedicated worker thread that runs an event loop centered on `GetQueuedCompletionStatus` and blocks until an asynchronous I/O operation completes and is posted to the `g_IocpHandle.` * This function handles three types of events - 1. **`START_COMPLETION_KEY`**: This message kicks off a new batch scan. It calls `CreateHostTable` to prepare connection contexts for an entire subnet. 2. **`CONNECT_COMPLETION_KEY`**: This signals that a `ConnectEx` attempt has finished. If the connection was successful, it calls `AddHost` to place the live IP onto the shared `g_HostList`. It also decrements the `g_ActiveOperations` counter. 3. **`TIMER_COMPLETION_KEY`**: This is a timeout mechanism. After a batch scan is initiated, a 30-second timer is set. If the timer fires and there are still active operations (`g_ActiveOperations > 0`), it means some connections are stuck. The code then cancels these hung operations using `CancelIo` to ensure the scanner never gets permanently stuck. * The helper functions of `PortScanHandler` are -> **`CreateHostTable (`**This function prepares a batch of hosts for scanning by generating all possible IP addresses), **`ScanHosts(`**Once the host table is created, this function iterates through every connection context and fires off an asynchronous `g_ConnectEx` call targeting port 445 on each IP) and **`AddHost(`**a thread-safe function that adds a confirmed live host to the `g_HostList`, uses the `g_CriticalSection` to prevent race conditions and checks against the local machine's own IP addresses to avoid the malware attacking itself). * The Host and Share Handler function (`HostHandler`) runs in a separate worker thread and acts as the "consumer" to the port scanner's "producer." Its job is to take the live hosts discovered by the scanner and perform the actual attack.

* The `HostHandler` runs in an infinite loop, continuously checking the `g_HostList`. If the list is empty, it sleeps for a second and checks again. When a host appears in the list, the thread wakes up, locks the critical section, removes the `HOST_INFO` from the queue, and unlocks the critical section. * It then calls `network_scanner::EnumShares` to get a list of all shared folders on that host. After finding the shares, it iterates through each one and immediately hands off the UNC path to `filesystem::SearchFiles`, specifying `NETWORK_THREADPOOL` as the destination for encryption tasks. Lastly if it dequeues a host with the special `STOP_MARKER` address, it knows the scan is complete, and it exits its loop. * The main entry point of this module is the `StartScan` function. It initializes and coordinates the entire network scanning operation. #### Anti-Hooking * Now that everything been enumerated and the malware knows what to do, it can start it's encryption process. But just before the encryption process, it invokes to anti-hooking module to remove function hooks from critical dlls. The `removeHooks` function contains the core logic and orchestrates the entire process of finding and removing API hooks from a specified loaded module (e.g., `ntdll.dll` or `kernel32.dll`). * The core strategy is to get a clean, unmodified copy of the target DLL to use as a reference. The execution flow is as follows -> It calls `GetModuleFileName` to retrieve the full file path of the target module handle (`hmodule`) on the disk and uses the dynamically resolved `CreateFile` to open this file with read-only access. It then uses `CreateFileMapping` to create a file-mapping object from the file handle. Finally, it calls `MapViewOfFile`. This maps the entire contents of the DLL file into the current process's memory as a read-only block (`originDll`). * With the clean DLL mapped into memory, the code now needs to find the location of every function it exports. It does this by manually parsing the PE file structure of the `originDll` buffer. * After all this, it iterates over function, performing a quick check on the first byte of the in-memory function (`funcHooked`) to look for the `JMP` instruction. Next, it performs a more definitive check by comparing the first few bytes of the pristine function code (`funcAddr`) with the first few bytes of the in-memory code (`funcHooked`). If they do not match, the `funcIsHooked` flag is set to true. * If a hook is detected, the code proceeds to remove it. It does that in the following way - * It calls `VirtualProtect` on the memory region of the hooked function (`funcHooked`) to change its memory permissions from the typical read-execute to **read-write-execute**. This is a necessary step, as executable code sections are normally not writable. * It then uses `CopyMemory` to copy the first 10 bytes from the unhooked function (`funcAddr`) over the top of the hooked function (`funcHooked`). This overwrites the `JMP` instruction and any other patched bytes, effectively restoring the function to its original, untampered state. * Finally, it calls `VirtualProtect` a second time to revert the memory permissions back to their original state. #### Encryption Algorithm * Finally we come to the encryption process. Conti-Locker utilizes ChaCha20 for it's encryption process. The encryption module is two-fold. One is the actual encryption using ChaCha20 and the other is creation of thread pools to do the encryption parallelly. Let's talk about the thread pools first. It's flowchart is given below.

* The system is designed to manage three distinct pools, identified by the `THREADPOOLS` enum: `LOCAL_THREADPOOL`, `NETWORK_THREADPOOL`, and `BACKUPS_THREADPOOL`. This separation allows the malware to allocate different numbers of threads and potentially different priorities for encrypting local files versus files on network shares or backups. * The central `THREADPOOL_INFO` structure holds all the state for a single pool, including an array of thread handles (`hThreads`), counters for threads and tasks, a `CRITICAL_SECTION` for thread-safe queue access, the task list itself (`TaskList`, a `TAILQ`), and components for managing workflow, such as an event handle (`hQueueEvent`) and a flag for back-pressure (`IsWaiting`). * The `Create` function allocates the necessary resources for a specific pool, including the array for thread handles and the synchronization objects. The `Start` function is then called to launch the worker threads; it iterates the specified number of times and calls `CreateThread`, passing the `ThreadHandler` function as the entry point for each new thread.

* The `PutTask` function serves as the interface for producer threads to add work to the queue. It is a thread-safe operation that locks the critical section, creates a `TASK_INFO` struct containing the filename, and adds it to the tail of the list. The `SuspendThread` function, called by the producer, waits on an event object, effectively blocking the producer until the queue has been drained to a manageable level by the consumer threads. Finally, the `Wait` function provides a graceful shutdown mechanism. It sends a special `STOP_MARKER` task to each worker thread and then calls `WaitForMultipleObjects`, blocking until all threads in the pool have finished their current work.

* The main showrunner of the thread pool part is the `ThreadHandler` function. Each thread created by the `threadpool::Start` function begins execution here and remains in this function for its entire lifetime. At the outset, each thread performs a one-time initialization to prepare for its encryption duties. It allocates a large, 5MB memory buffer (`BufferSize`) for efficient file I/O operations. It also establishes a persistent cryptographic context by calling `GetCryptoProvider` to acquire a handle to the Microsoft CryptoAPI provider and then uses `pCryptImportKey` to import the global, hardcoded attacker's RSA public key (`g_PublicKey`). This setup is done once per thread.

* After initialization, the thread enters its main `while (TRUE)` loop, where it continuously attempts to dequeue and process tasks. It first locks the pool's critical section, then checks the head of the `TaskList`. If a task is available, it is removed from the queue, and the task counter is decremented. If the producer thread was suspended (`IsWaiting` is true) and the task count has now dropped to half of the maximum, the worker thread calls `SetEvent` on `hQueueEvent` to signal the waiting producer thread that it can resume adding new tasks. * After unlocking the critical section, the worker processes the task. It checks if the filename is the special `STOP_MARKER`, and if so, it exits the loop to terminate. Otherwise, it prepares a `locker::FILE_INFO` structure and passes it, along with the pre-initialized crypto provider, RSA key handle, and I/O buffer, to the main `locker::Encrypt` function. * Upon successful encryption, the worker calls `locker::ChangeFileName` to append the ransomware's extension to the file, finalizing the attack on that specific file. After processing is complete, it securely cleans up any handles or keys associated with the file and deletes the `TASK_INFO` object before looping back to get the next task. Now onto the encryptor.

* Before encryption, Crypto-Locker executes the `locker::DeleteShadowCopies` function. This function uses the Windows Management Instrumentation (WMI) framework via COM interfaces to systematically eradicate all Volume Shadow Copies (VSS), which are Windows' built-in file versioning and system restore points. By doing so, it eliminates the victim's easiest and most immediate path to recovery. * The function then initializes the COM library for multi-threaded operation, sets appropriate security levels, and connects to the `ROOT\CIMV2` WMI namespace. It also sets the `__ProviderArchitecture` context to ensure it interacts with the native 64-bit WMI provider. It then executes a WQL query (`SELECT * FROM Win32_ShadowCopy`) to enumerate all existing shadow copies. For each one found, it extracts its unique ID and programmatically constructs a command line to delete it using the `WMIC.exe` utility, a method that is both powerful and reliable.

* Along with the deletion of shadow copies, Conti-locker runs the `KillFileOwner` function in parallel. This function uses the Windows Restart Manager API to restart the applications holding a lock on system files. It starts a Restart Manager session, registers the locked file path, and retrieves a list of all processes using it. If the process is whitelisted, the function aborts to avoid system instability or self-termination. If the locking processes are not on the whitelist, it calls `RmShutdown` with the `RmForceShutdown` flag, forcibly terminating them. * Two helper functions, `CheckForDataBases` and `CheckForVirtualMachines`, are used for for the hybrid encryption scheme. Each contains an extensive, hardcoded list of file extensions commonly associated with databases (`.sql`, `.mdb`, `.mdf`, `.dbf`, etc.) and virtual machine disks (`.vmdk`, `.vhd`, `.vdi`, `.qcow2`, etc.). These functions perform a quick, case-insensitive check on a file's name to determine if it belongs to one of these.

* Conti-Locker utilizes ChaCha20 along with RSA for the encryption process. This is implemented in the `GenKey` function. For every single file to be encrypted, a unique 32-byte symmetric key and an 8-byte nonce (IV) are generated using the `CryptGenRandom` function. This key/IV pair is used to initialize a ChaCha20 cipher context (`ECRYPT_ctx`), which will perform the fast, bulk encryption of the file's content. This unique ChaCha20 key and IV are then immediately encrypted using a hardcoded, master RSA public key that was imported once per worker thread. The result of this RSA operation is a 512-byte encrypted key blob.

* After successfully generating the cryptographic keys and opening the target file (using `KillFileOwner` if necessary), it enters a decision tree to select one of three encryption modes based on the file's type and size. * Files identified as high-value databases are subjected to `EncryptFull`, which overwrites every single byte of the file with encrypted data. * Virtual machine disks are targeted with a specific `EncryptPartly` mode that encrypts three 7% chunks of the file. * For general files, the strategy is size-dependent: small files (under 1MB) are fully encrypted; medium files (1MB to 5MB) are subjected to `EncryptHeader`, which only encrypts the first megabyte which makes them unreadable to most programs; and large files (over 5MB) are encrypted with an intermittent `EncryptPartly` mode that encrypts five 10% chunks. * Once the file content has been encrypted, the `WriteEncryptInfo` function is called. This function appends a metadata footer to the end of the now-encrypted file. This footer contains the 512-byte RSA-encrypted ChaCha20 key blob, the original 64-bit file size, and a byte indicating which encryption mode was used. This information is essential for the decryption tool to properly reverse the process. * With the footer successfully written, the `ChangeFileName` function renames the file by appending the ransomware's custom extension. Finally, the `CloseFile` function performs a secure cleanup. ## Decryptor *** * Majority of the modules of the decryptor are the same as the encryptor, so I will be skipping them. I will however be analyzing the main core decryption module of the decryptor. The flowchart of the decryption module is given below.

* The decryptor mirrors the locker's logic with precision, reading the metadata footer from each encrypted file, decrypting the per-file symmetric key using the attacker's master private key, and then applying the correct decryption algorithm based on the mode used during encryption. * The central data structure is `decryptor::FILE_INFO`, which is designed to hold all the state required to decrypt a single file. It contains fields for the filename, a handle to the file, the original and encrypted file sizes, the ChaCha20 key and IV, and the `EncryptMode` and `DataPercent` values that will be read from the encrypted file's metadata.

* The core function `decryptor::Decrypt` first calls `OpenFileDecrypt`. This helper function opens the target file and then immediately calls `ReadEncryptInfo`. `ReadEncryptInfo` seeks to a position 534 bytes from the end of the file, which is where the locker engine wrote the metadata footer. * It reads this 534-byte block, which contains the 512-byte RSA-encrypted ChaCha20 key/IV, the 1-byte encryption mode, the 1-byte data percentage, and the 8-byte original file size. This information is parsed and stored in the `FileInfo` struct. * The function then calls `CryptDecrypt`, providing it with the attacker's master private key (`PrivateKey`). It uses this private key to decrypt the 512-byte `EncryptedKey` blob that was just read from the file's footer. This recovers the original, unique 32-byte ChaCha20 key and 8-byte IV that were used to encrypt this specific file. * With the plaintext ChaCha20 key and IV now available, the function calls `ECRYPT_keysetup` and `ECRYPT_ivsetup` to initialize the ChaCha20 stream cipher context (`FileInfo->CryptCtx`).

* Now according to the decryption mode, it calls one of the below three functions - * **`DecryptFull`**: This function reads the entire file from beginning to end in large chunks (up to 5MB at a time). For each chunk, it calls `ECRYPT_decrypt_bytes` to decrypt the data in-place in the buffer. It then seeks the file pointer back to the beginning of the chunk it just read and overwrites the encrypted data with the newly decrypted plaintext using the `WriteDecryptedData` helper function. This process continues until the entire file has been read, decrypted, and rewritten. * **`DecryptHeader`**: This function mirrors the `EncryptHeader` logic. It decrypts only the first 1,048,576 bytes (1MB) of the file, leaving the rest untouched. It reads, decrypts, and rewrites the data in the same manner as `DecryptFull` but stops after reaching the 1MB limit. * **`DecryptPartly`**: It uses a `switch` statement based on the `DataPercent` value (either 20 or 50) read from the file's metadata to calculate the exact size of the encrypted chunks (`PartSize`) and the size of the unencrypted gaps (`StepSize`). It then enters a loop, performing a series of seeks and partial decryptions. For example, for the 50% mode, it will decrypt a 10% chunk, seek forward over the next 10% unencrypted gap, decrypt the next 10% chunk, and so on, until all five encrypted parts have been restored.

* After the content has been decrypted, the function seeks back to the position 534 bytes from the end of the file and calls `SetEndOfFile`. This truncates the file, removing the metadata footer and restoring the file to its exact original size. The file is renamed back to it's original filename using `decryptor::ChangeFileName` . * In the end of the source code, there is a commented out function that handles the decryption process asynchronously. This means that the malware authors likely had plans to integrate the IOCP model (discussed in the network scanner module) into the decryptor. ## Conclusion *** * The ransomware's design is a case study in modern malware development. The use of multiple thread pools in a producer-consumer model for both filesystem scanning and encryption helps cripple a system as rapidly as possible. This is complemented by a pretty good encryption strategy that uses a hybrid ChaCha20 and RSA scheme, intelligently adapting its method to fully, partially, or header-only based on file type and size to maximize damage. Furthermore, the deletion of Volume Shadow Copies ensures that once infected, the victim **HAS** to pay the ransomware gang. * As stated in the introduction, understanding these intricate mechanisms is invaluable. For security researchers and blue teams, this code provides a clear blueprint of the advanced threats that modern defenses must counter. For red-teamers and those involved in adversary simulation, it serves as an inspiration in building effective and evasive tools.