INC Ransomware v2

Summary

INC ransomware has been around since the summer 2023. Cybereason created a very detailed write-up for INC ransomware version 1 (V1) earlier this year. You can read it here. Later, INC ransomware version 2 (V2) appeared, and it looks like they added several new command line options as well as updated their encryption method - so we will take a quick look at this sample in this post.

Environment

The tools used for this analysis are: Win 10 22H2 VM, PEiD, DIE v3.08, HxD, PE-Bear, Procmon, System Informer, IDA Community, x64dbg.

Sample

I will be skipping basic static and dynamic analysis since there wasn't much interesting content there. You can run this sample in a "safe" way by using the provided --file or --dir arguments.

FILE win.exe
SHA256 e17c601551dfded76ab99a233957c5c4acf0229b46cd7fc2175ead7fe1e3d261
Size 161.5 KB
Creation Time 2024-04-09 08:25:18 UTC
VT First Submission 2024-06-23 16:14:19 UTC
File Type PE32 Console
Packed No
Obfuscation Stores Base64 encoded strings
Encryption AES-256 CTR and Curve25519
Personal ID 667681103547f22b7c64f692

Analysis

The sample is not packed or heavily obfuscated. It uses LoadLibraryA and GetProcAddress to dynamically load the needed DLLs. The set of command line arguments available is listed below. However, it does not require any arguments to run.

Argument Comment
--file path to a file you want to encrypt
--dir path to a directory you want to encrypt
--sup need admin rights, kills any processes that uses the resource sample needs to encrypt
--lhd encrypt hidden drives
--ens encrypt network shares
--hide (new) hide console window
--safe-mode (new) forces the host in safemode and encrypts data in safemode
--kill (new) kills the process, this version targets sql process specifically
--mode (new) fast (default), medium, slow (full encryption)
--debug
--help

Default execution

Without any command line arguments, the sample first empties the recycle bin through the call to SHEmptyRecycleBinA. After that, it sets up the multi-threaded execution by calling GetSystemInfo to retrieve the number of logical processors on the host. Then it calls CreateIoCompletionPort with the NumberOfConcurrentThreads set to 0x0. Note that 0x0 means that the system will allow as many concurrently running threads as there are processors. Once the I/O Completion port is ready, it calls CreateThread  to create N number of "worker" threads to process multiple asynchronous I/O requests, where N is equal to the number of logical processors times four.

The "worker" threads use GetQueuedCompletionStatus to wait for a completion packet to be queued to the I/O completion port. I found it helpful to set a breakpoint right after the GetQueuedCompletionStatus function call to trace the "worker" thread execution.

To trace the moment when the execution is passed to the "worker" thread, you can set breakpoinst on InterlockedIncrement and PostQueuedCompletionPort.

The mechanism of using I/O completion port for multi-threaded execution is not new. It is very well documented by Microsoft, and you can find multiple references to ransomware using it for encryption.

Fig 1 x64dbg: Multi-threaded execution setup

The ransom note content is stored in Base64 format inside the sample. The CryptStringToBinaryA function is used to decrypt it. Just like in V1, this sample drops both .txt and .html versions of the ransomware note.

Fig 2 x64dbg: Ransom note content decryption

After that, the sample calls Sleep multiple times, followed by a GetDriveTypeW function call. If the returned drive type is in the DRIVE_REMOVABLE, DRIVE_FIXED, or DRIVE_REMOTE range, it deletes its volume shadow copies and starts the encryption thread.


To delete volume shadow copies, the sample opens a handle to the device driver through CreateFileW and calls DeviceIoControl with IoControlCode set to 0x53C028. This will send the IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE control code to the device driver, forcing it to resize the allocated space for shadow copies. This is also an old techniques used in V1 of INC ransomware.

Fig 3 x64dbg: DeviceIoControl call to remove shadow copies

The sample traverses the drive by calling the usual FindFirstFileW and FindNextFileW APIs. The directory name, file extension and file name are checked against whitelisted values that has not changed since V1. If the filename passes the check, a separate thread is created to encrypt its content.

Whitelist Name Whitelist Values
Directories windows, program files, program files (0x86), $RECYCLE.BIN, appdata
Extensions .exe, .dll, .inc, .msi
File name anything that contains INC in its file name is not encrypted


The encryption thread calls CreateFileW and GetFileSizeEx to open a handle to the file and to retrieve its size. The CryptStringToBinaryA is called again to Base64 decode the 256-bit public key value. On top of that CryptGenRandom is called to generate a random 256-bit key per each file.

Once the sample generates the symmetric key for encryption and prepares the buffer containing the encrypted symmetric key value, it calls CreateIoCompletionPort, ReadFile, and InterlockedIncrement APIs to pass execution to the waiting "worker" threads.

Fig 4 x64dbg: Buffer (80 bytes) to append to encrypted data 

The worker threads pick up the execution, encrypt the data read from the file, write it back into a file, write the buffer containing the encrypted symmetric key into a file, and update the file extension to .INC through MoveFileExW.

You can use capa to identify the type of encryption used by the sample. It indicated AES-256 and Curve25519. You can also monitor the encryption process through Sysinternals Procmon and its WriteFile operation. In many cases you can guess the type of cipher just by looking at the size of data written back into a file.

To confirm the encryption, you can trace the function that encrypts the file data. In this specific case, you will notice that the key stream is generated in 16 byte chunks before it is XORed with the plaintext data, confirming the AES-256 CTR mode. Procmon was not super helpful in identifying AES-256 CTR mode, since the size of encrypted data written back into a file was the same as the size of the plaintext.

Fig 4 x64dbg: Tracing file data encryption

This sample also has the ability to change the wallpaper after encryption, as well as to physically print the ransom note. Both functionalities are well documented by Cybereason.

New Command Line Arguments

The INC ransomware V2 contains four new command line arguments: --kill, --hide, --safe-mode, and --mode. Please read the Cybereason INC ransomware analysis to understand how the V1 command line arguments work. I will only cover the new additions:

--hide

This command simply calls GetConsoleWindow to retrieve a window handle used by the console associated with the ransomware process, and then it calls ShowWindow to set the window's show state to SW_HIDE (1).

--kill

This command iterates through the running processes by calling standard CreateToolhelp32Snapshot, Process32FirstW, and Process32NextW APIs. It searches for the processes whose names contains the substring sql and kills them using OpenProcess and TerminateProcess.

--mode <MODE>

This command allows setting the encryption mode. The mode value can be set to fast, medium, or slow. By default, the mode is set to fast. Depending on the file size, only 1,000,000 byte file chunks are getting encrypted. The slow mode encrypts all data in the file.

--safe-mode

This command creates a new service named dmksvc through calls to OpenSCManagerW, CreateServiceW. After creating the service, it calls RegCreateKeyExW and RegSetValueExW to ensure that the service will be auto-started when the host is restarted in safe mode.

Fig 6 x64dbg: New service creation
Fig 7 RegEdit: Safeboot Network key for new service

Then it executes bcedit.exe /set {default} safeboot network and shutdown.exe /r through CreateProcessW to force the host into safe mode before the encryption process. Note that it calls Wow64DisableWow64FsRedirection before running bcdedit.exe and shutdown.exe since the binary is 32-bit and it needs to access a 64-bit application.

The end... =)

IOCs

  • child process bcedit.exe
  • child process shutdown.exe
  • new service created dmksvc
  • ransomware notes dropped INC-README.html and INC-README.txt in each encrypted directory
  • registry key created HKLM\SYSTEM\ControlSet001\Control\Safeboot\Network\dmksvc
  • registry key set HKLM\SYSTEM\ControlSet001\Control\Safeboot\Network\dmksvc\(Default) to Service
  • registry key created HKLM\SYSTEM\ControlSet001\Control\Safeboot\Minimal\dmksvc
  • registry key set HKLM\SYSTEM\ControlSet001\Control\Safeboot\Minimal\dmksvc\(Default) to Service
  • IOCTL 0x53C028 issued to device driver through DeviceIoControl to resize volume shadow copies
  • Recycle bin is emptied through the call to SHEmptyRecycleBinA

References