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.

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.

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.

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.

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.

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.

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.

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.

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.

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

• https://www.sentinelone.com/anthology/inc-ransom/
• https://www.cybereason.com/blog/threat-alert-inc-ransomware
• https://www.huntress.com/blog/lolbin-to-inc-ransomware
• https://blog.sonicwall.com/en-us/2024/06/inc-ransomware-the-latest-linux-threat/
• https://blog.polyswarm.io/inc-ransomware
• https://github.com/rivitna/Malware/blob/main/Inc/Inc_samples.txt