During a ransomware incident response, I noticed a file with a strange name that was retrieved by the team. Upon inspection, it turned out to be a driver. This raised the question “what does a driver have to do with a ransomware incident response?” To understand this, I started gathering information about the binary.

Every driver contains information about itself

by inspecting it, we can see that the driver’s original name is gmer64.sys and it belongs to a company called GMER, If we visit the website mentioned in the driver description, we can see that GMER is an application used for rootkit detection and removal

Every driver should be signed with a valid certificate in order to be loaded. This driver is signed under GMEREK Systemy Komputerowe Przemysław Gmerek, which is a company located in Poland

then i remembered reading about it in the Conti ransomware group leak, which was leaked in 2022. The group used the program’s client GUI to terminate the EDRs, which is a bit messy and easy to detect. There was no proof of concept (PoC) about the driver, so I had to dig my way to it.

Technical Analysis

The driver retrieves its name at runtime from the DriverObject, allowing us to control the symbolic name. Next, the driver creates a device object using IoCreateDevice ,if all goes well, it returns a device object and to make this device object accessible to user-mode it creates a symbolic link by calling IoCreateSymbolicLink.

and since the driver name on disk is Blackout, we can see that the symbolic link is created under the same name Blackout

Now we need to open a handle to our device. The file name for CreateFile should be the symbolic link prefixed with \\.\\ , so it will be \\.\\Blackout ,

All device objects are DEVICE_OBJECT structures created by different drivers, each responsible for its own layer. These objects are essential because they enable communication. Every driver needs to create at least one device object and assign it a name so clients can communicate with it .

and since the SDDL is not configured on the device a non-admin users can interact with it

To mitigate this issue we can use IoCreateDeviceSecure with a Security Descriptor that restrict non-admin users from opening a handle to the device , for more info check Controlling-device-access

using C code

All drivers must have dispatch routines, especially IRP_MJ_CREATE without it, no device handles could be opened. In the case of the gmer64 driver all dispatch routines point to a single function ,in this function major operations are processed including:

• IRP_MJ_CREATE: Create operation, typically invoked for CreateFile or ZwCreateFile calls.
• IRP_MJ_SHUTDOWN : Called when the system shuts down.
• IRP_MJ_CLOSE: Close operation, normally invoked for CloseHandle or ZwClose calls.
• IRP_MJ_DEVICE_CONTROL: Generic call to a driver, invoked by DeviceIoControl or ZwDeviceIoControlFile calls, which is the most important one in this article.

The function accepts two arguments __int64 a1 and IRP *a2, we will focus in a2 since it contains all data passed from user-mode client this data structure used to communicate with drivers and pass information about I/O requests essentially an IRP tells the driver what action to perform and provides the necessary details to complete that action.

Here are some other important fields of the IRP structure:

• IoStatus: Contains the status (NT_STATUS) of the IRP and an information field. The information field is a polymorphic one, typed as ULONG_PTR (32 or 64-bit integer), but its meaning depends on the type of IRP. For example, for Read and Write IRPs, it indicates the number of bytes transferred in the operation.
• UserBuffer: Contains the raw buffer pointer to the user’s buffer for relevant IRPs. For example, Read and Write IRPs store the user’s buffer pointer in this field. In DeviceIoControl IRPs, this points to the output buffer provided in the request.
• UserEvent: This is a pointer to an event object (KEVENT) provided by a client if the call is asynchronous and such an event was supplied. From user mode, this event can be provided (with a HANDLE) in the OVERLAPPED structure that is mandatory for invoking I/O operations asynchronously.
• AssociatedIrp: This union holds three members, but only one (at most) is valid at a time:*
• SystemBuffer: The most often used member. This points to a system-allocated non-paged pool buffer used for buffered I/O operations.

In the Major function  we can see that it checks conditions for IRP_MJ_CLOSE and IRP_MJ_DEVICE_CONTROL. However, we are more interested in IRP_MJ_DEVICE_CONTROL, as it contains the core functionalities of the driver. IRP_MJ_CLOSE likely contains cleanup code. If other IRPs such as IRP_MJ_SHUTDOWN or IRP_MJ_CREATE are called, the operation will be completed successfully

The Dispatch function takes the following eight arguments:

1. 1. FileObject: Pointer to the file object for the I/O request.
   2. MasterIrp: The master I/O request packet.
   3. Options: Options for the create operation.
   4. UserBuffer: Pointer to the user buffer with data.
   5. Length: Length of the data to be read or written.
   6. LowPart: A variable used for specific conditions or flags.
   7. p_IoStatus: Pointer to the status of the I/O operation.
   8. a1: An additional parameter for the function’s context or control.

In the dispatch function, it starts by checking if the received i/o control code is 0x9876C004. If yes, it initializes a variable with the value of 1; otherwise, it returns an access denied error. Therefore, we must first send this i/o control code to enable the driver to receive further i/o control codes, additionally the buffer size should be more than 4 bytes otherwise, you will get an access denied the content of the buffer does not matter as long as the passed buffer is not null after that, it will initialize the buffer to 1 then return success and complete the IRP with the given status and buffer

Now that we have obtained a handle to the device, all we need to do is send the I/O control code with the 4-byte buffer to the driver using DeviceIoControl API to enable it. From there, we will have full access to all other I/O control codes

After sending the I/O control code, we can see that the driver has returned 1 to us, which means the driver is now enabled

We can see that this function takes an unsigned integer which is the process id as a parameter  then it attaches to it and opens a handle to it and terminates it using ZwTerminateProcess

Now, putting it all together, we pass the process ID as an argument and convert it to an integer. After that, we call DeviceIoControl to terminate the process. The I/O control code is 0x9876C094, and we pass the process ID as the buffer

After executing the program, we can successfully terminate the anti-malware protected process or any other sort of  PPL processes

At the time of creating the PoC it was undetected on a fully-patched Windows 11 22H2 system, even though it was covered by the Microsoft driver block list because it only get updated 1-2 times per year.

you can find the source code from here !

There are numerous interesting IOCTLs that can be abused. Here is another researchconducted by Jonny Johnson from Binary Defense. Instead of terminating processes, this research focuses on suspending the process threads.

Wrapping Up

Even though this technique is effective for ransomware groups to shut down EDR/AV agents before starting the encryption stage, it requires local admin privileges. However, if the driver or another driver that exposes its functionality such as terminating or suspending threads is already loaded and allows non-admin users to get a handle to its device then admin privileges are not required.

The file is a 32-bit Windows executable that contains BlackCat Ransomware, BlackCat, also known as Noberus or ALPHV, is a sophisticated ransomware family programmed in Rust and deployed as part of Ransomware as a Service (RaaS) operations on Windows, The ransomware can be configured to encrypt files using either AES or ChaCha20 algorithms, In addition, it can delete volume shadow copies, terminate processes and services, and halt virtual machines on ESXi servers, ALPHV also possesses self-propagation capabilities, enabling it to remotely execute itself on other hosts within the local network using PsExec, to execute, the ransomware requires an access token to decrypt its config, This indicates that the ransomware was deployed and activated using another file, However, since the access token wasn’t retrieved, dynamic analysis of the malware was not possible.

Analyzing ALPHV

The ransomware has never been submitted to VirusTotal, This could suggest that it is part of a targeted campaign

The ransomware TEXT and RDATA and RELOC sections are packed

The ransomware uses three local thread storages to hide its main functions and evade detection, complicating its code for analysis or debugging

when ransomware is executed the output indicates its support command line arguments, which is a feature added by ALPHVto simplify its use in the Ransomware as a Service (RaaS) model.

The string located in its binary reaffirms the aforementioned information.

Utilizing the command line with the binary provides an output containing all available options for the ransomware’s deployment

The image below outlines all supported options of the ransomware. Each option necessitates an access token for usage, without it, the program remains inoperable

The ransomware modifies the registry to increase allowed requests, enhancing its lateral movement capabilities across more devices, this is achieved by adjusting the ‘MaxMpxCt‘ setting located at:

‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters‘, set to 65535, using the force (/f) flag.

 

After increasing the number of permitted requests, the ransomware propagates across the network using the PsExec tool

also it uses ‘NetServerEnum‘ api with ‘servertype‘ set to ‘0xFFFFFFFF‘, indicating an intent to retrieve all servers , then it try to connect to network shares on order to spread itself

The ransomware abuse the ‘wevtutil.exe‘ executable to erase all event logs, complicating the task of incident response team

The ransomware note contains random characters, which are decrypted at runtime once the access token is provided, and written into a file called RECOVER-${EXTENSION}-FILES.txt ,This suggests that the extension name is generated for each target

The ransomware note, after being decrypted at runtime, contains the file extension of the encrypted files, details about the stolen data, and instructions to contact the threat actor

in the encryption phase the ransomware loop thourgh all volums then thourg all files with specific extension then start encrypting them , the encryption algorithm the ransomware support chacha and AES algorithms

According to their own RaaSÂadvertisements, BlackCat ransomware can be configured to use several

different encryption modes:

• Full file encryption – the strongest but slowest encryption method.

• Fast encryption – the opposite of full – sacrifices strength for speed as it only encrypts the first N

  megabytes.

• DotPattern encryption – favors speed but is still somewhat strong encryption by encrypting N

  megabytes through M step.

• SmartPattern encryption – the most optimal mode in terms of speed/strength ratio; encrypts N

  megabytes in percentage steps (default: 10 megabytes every 10% of the file starting from the

  header).

• Auto– The encryption speed/strength can change depending on the type and size of the file,the choice will be optimized for both speed and security.

Targeted file extensions :

The threat actor offer a decryption program priced at $625,000. This application is allegedly capable of restoring the encrypted file, Payment instructions are provided with the option to use live-chat for queries. The current status shows the ransom amount awaiting payment in either Bitcoin or Monero cryptocurrencies , The equivalent of the ransom in Bitcoin is 25.794933 BTC, and in Monero, it is 4082.032526 XMR.

Ransomwre IOCs

• C:\\Users\\Public\\All Usersdeploy_note_and_image_for_all_users=

• –no-prop-servers–propagatedpropagate::server=

• drag-and-drop-target.bat

• Important files on your system was ENCRYPTED

MITRE ATT&CK Techniques

The first file is a 32-bit Windows executable that contains a Cobalt Strike Beacon, This executable file uses two local thread storages to conceal its main functionality, evade detection, and make its code more complex and difficult to analyze, also the file contains a malicious implant known as a Cobalt Strike Beacon, which is designed to persist on a compromised system and establish communication with a command-and-control (C2) server, The Beacon periodically checks for additional commands from the C2 server that it can execute on the compromised system,The second file is a 32-bit Windows executable that belongs to the ransomware family, This executable employs some advanced techniques to make it difficult to analyze dynamically and statically, Once the malware is executed, it will initiate a series of file encryption operations using symmetric keys, To make it challenging to recover the files, the malware encrypts each directory with a different key.

URLs ( 2 )

• http://mbrlkbtq5jonaqkurjwmxftytyn2ethqvbxfu4rgjbkkknndqwae6byd.onion

• http://k7kg3jqxang3wh7hnmaiokchk7qoebupfgoik6rha6mjpzwupwtj25yd.onion

Analyzing sihost.exe

the Cobalt Strike beacon was identified employing the deceptive name “sihost.exe” to obfuscate its presence and appear legitimate. It’s essential to note that “sihost.exe” is a genuine Windows process responsible for managing graphical elements in the Windows interface.

The malware has never been submitted to VirusTotal, This could suggest that it is part of a targeted campaign

The malware data section is packed

The malware utilizes two local thread storages to conceal its primary functions, evade detection, and complicate its code, making it more challenging to analyze or debug, as the malware will execute before the main thread

The local storage threads in this malware load mingwm10.dll for TLS management, followed by obtaining two functions __mingwthr_remove_key_dtor and __mingwthr_key_dtor using GetProcAddress(), Both functions are responsible for managing the thread-local storage.

After the malware reaches the main function, it generates a random number using the GetTickCountfunction. This number is then used to create a named pipe by formatting a string using the sprintffunction, followed by creating a thread to create the pipe.

then the malware will decode the C2 function address and execute it

a diagram illustrating the flow of the Cobalt Strike Beacon

Analyzing PLAY.exe

Also for this file using the file hash to search in VirusTotal, we could not find anything, which means that the malware has not been uploaded

The malware reloc section is packed

The ransomware uses a lot of anti-analysis techniques to prevent dynamic or static analysis

Once the malware executes it starts enumerating all files on the hard drive, Then, the ransomware iterates through all directories in those drives using the FindNextFileWAPI.

and for each directory, it will spawn a thread to encrypt all files in it, to speed up the encryption process

a list of large handles that ransomware opens to files and threads during its encryption process

after enumerating all files and opening a handle to them,the ransomware calls BCryptGenerateSymmetricKeyfunction that creates a key object for use with a symmetric key encryption algorithm.

Then, it uses that symmetric key to encrypt the buffer retrieved from the files

after encrypting the buffer, the ransomware writes it back to the file, causing the original buffer to be overwritten

then the ransomware destroys the key from memory using the BCryptDestroyKeyAPI, making it extremely difficult, if not impossible, to recover the key data, This API securely deallocates the key object and any associated memory, which typically involves overwriting the memory with zeros or random data to prevent any residual information from remaining

The ransomware repeats these steps with all the other directories, it generates a key, encrypts all files in that directory, destroys the key, and then moves to the next directory, every directory is encrypted with a different key, and it seems that the purpose of this malware is only data destruction

Ransom Note :

the ransom note placed in the hard drive location the being encrypted

ransom note

the content of the ransomware note

The onion site of the threat actor shows multiple affected companies being demanded a ransom, otherwise, the data will be published

a diagram illustrating the ransomware encryption flow