KBOT: sometimes they come back

Although by force of habit many still refer to any malware as a virus, this once extremely common class of threats is gradually becoming a thing of the past. However, there are some interesting exceptions to this trend: we recently discovered malware that spread through injecting malicious code into Windows executable files; in other words, a virus. It is the first “living” virus in recent years that we have spotted in the wild.

We named it KBOT, and Kaspersky solutions detect the malware and its components as Virus.Win32.Kpot.a, Virus.Win64.Kpot.a, Virus.Win32.Kpot.b, Virus.Win64.Kpot.b, and Trojan-PSW.Win32.Coins.nav.

What does KBOT do

KBOT penetrates users’ computers via the Internet or a local network, or from infected external media. After the infected file is launched, the malware gains a foothold in the system, writing itself to Startup and the Task Scheduler, and then deploys web injects to try to steal the victim’s bank and personal data. For the same purpose, KBOT can download additional stealer modules that harvest and send to the C&C server almost full information about the user: passwords/logins, cryptowallet data, lists of files and installed applications, and so on. The malware stores all its files and collected data in a virtual file system encrypted using the RC6 algorithm, making it hard to detect.

Number of Virus.Win32.Kpot detections, March — December 2019

Infection methods

KBOT infects all EXE files on connected logical drives (HDD partitions, external media, network drives) and in shared network folders by adding polymorphic malicious code to the file body. To do so, the malware listens to the connection events of local and network logical drives using the IID_IwbemObjectSink interface and a query of type SELECT * FROM __InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA ‘Win32_LogicalDisk, and overrides the Indicate function of the IWbemObjectSink interface, where for each drive it performs recursive scanning of directories and infects EXE files.

The malware retrieves paths to shared network resources using the API functions NetServerEnum and NetShareEnum, before scanning directories and infecting executable EXE files:

Like many other viruses, KBOT patches the entry point code, where the switch to the polymorphic code added to the start of the code section is implemented. As a result, the original code of the entry point and the start of the code section are not saved. Consequently, the original functionality of the infected file is not retained.

Virus code at the entry point

The jmp command makes the switch to the polymorphic code:

The virus also adds encrypted data to the end of one of the following sections: .rsrc, .data, .rdata. Data located after the selected section is shifted. At the same time, the parameters of the relocation table directory, resources directory, imports directory, parameters of sections, and other PE file parameters are modified accordingly. The encrypted data contains the body of the main malware module (DLL library), as well as code for decrypting, loading into memory, and running this library. The data is encrypted using the XOR method, plus the library is additionally encrypted with the RC4 algorithm and compressed using Aplib.

Example of an infected file

At the end of the polymorphic code is a classic piece of code for obtaining the kernel32.dll base:

Next, the API address of the VirtualProtect function is retrieved and used to set permissions to write and execute encrypted virus data located at the end of the above-mentioned .rsrc, .data, and .rdata sections. The data is decrypted, and the switch to the relevant code is made:

The code decrypts the DLL library with basic bot functionality (encrypted using RC4 and compressed using Aplib), maps the library headers and sections into memory, resolves the imports from the import directory, does manual relocations using information from the relocation table directory, and executes the code at the library entry point.

KBOT functions

Injects

To conceal malicious activity in the system and its ability to operate in the context of system applications, KBOT attempts to inject code into running system processes.

Using the API functions OpenProcess/OpenProcessToken and GetTokenInformation, it retrieves the SID of the process into whose address space the main malware module is loaded. If the SID of the process matches WinLocalSystemSid, KBOT uses the CreateProcess API with the CREATE_SUSPENDED flag to create the new process svchost.exe, and then performs a classic inject: using the API functions NtCreateSection/NtMapViewOfSection, it allocates memory in the address space of the svchost.exe process, where it copies the header and sections of the main module, after which it resolves the imports from the import directory and does manual relocations using information from the relocation table directory. Next, KBOT calls the CreateRemoteThread/RtlCreateUserThread API with the address of the entry point. If the SID of the process does not match WinLocalSystemSid, the malware sets SeDebugPrivilege debug privileges and tries to perform a similar inject in the running processes services.exe and svchost.exe, whose SIDs match WinLocalSystemSid, as well as in the explorer.exe process.

KBOT also injects the DLLs specified in the injects.ini file (located in the virtual file storage) into the processes listed in the same INI file. Configuration files, including injects.ini, are encrypted in one of the last sections of the main module of the bot, from where they are read, decrypted, and moved to the virtual file storage. The sample first searches for the current version of the required file in its storage (it might be that the current version was previously retrieved from the C&C); in case of failure, it reads the file data from the original version, which is located in the body of the bot itself in encrypted form. A special bot module — JF (joined files) — handles the processing of such files. At the start of the encrypted data of every such file, there is a structure with a data description containing a JF signature.

Description of the data processing procedure of the configuration file

The structure with the description of the encrypted file data corresponds to each encrypted file attached:

Example of injects.ini:

The above-mentioned JUPITER.32 and JUPITER.64 are DLLs that perform web injects that help the malware steal users’ personal data entered in browsers: passwords, credit card/wallet numbers, etc.; such injects are carried out through spoofing web page content as a result of injecting malicious code into the HTTP traffic. For this, it is necessary to modify the code of the browser and system functions responsible for the transmission and processing of traffic. To do so, after performing an inject in the system and browser processes, the web-injects library patches the code of functions in popular browsers (Chrome, Firefox, Opera, Yandex.Browser) and the code of system functions for transmitting traffic:

The list of injects from the configuration file is stored by the malware in a global array of inject descriptors — a functionality analogous in many ways to the Rovnix bootkit.

Below we give an example of the configuration file kbot.ini, where Hosts is the C&C list and ServerPub is the public key for data encryption:

DLL hijacking

So as to operate in the address space of a legitimate system application when the system boots, the malware performs a DLL hijacking attack by infecting the system libraries specified in the import directory of the system executable file and placing them next to the system file, which is then written to Startup.

In the system folder C:Windows\System32, the malware searches for executable EXE files suitable for attack, excluding from consideration the following files:

1. Containing the strings level=”requireAdministrator” and >true in the manifest. That is, executable files that need administrator rights to run. Calling such applications invokes a UAC dialog box.
2. Containing in the import table library names starting with API-MS-WIN- and EXT-MS-WIN-. That is, files that contain virtual library names in imports and use the API Set redirection table in ApiSetSchema.dll. For such files, DLL hijacking is impossible to implement, because virtual names are translated into system library names with full paths.
3. The names of which are contained in the stop list:
   

Having found an executable file that meets all the criteria, KBOT creates a folder with an arbitrary name in the system directory, and copies the detected EXE file to it, as well as the system DLLs located in the import directory of the executable file. To perform these operations with administrator privileges, the malware generates a shellcode (based on this code) using EIFOMoniker Elevation:Administrator!new:{3ad05575-8857-4850-9277-11b85bdb8e09}”.

The above shellcode functionality

This shellcode, along with the necessary parameters, is injected into the explorer.exe process using the CreateRemoteThread API function.

After copying, the virus creates an arbitrarily named file in the same folder, which is an encrypted file storage; VFAT is used as the file system. Located in the storage is the current version of the main bot module, configuration files received from the C&C, system information, and other service data.

As a result, the directory containing the system application, DLLs from the import directory, and the KBOT service data storage looks as follows (the file name of the malware’s encrypted virtual storage is highlighted red):

Next, KBOT infects the copied system libraries. The code of the DLLEntryPoint entry point is overwritten with the following code:

As when infecting the executable file, the virus adds polymorphic code to the code section and encrypted code at the end of one of the .rsrc, .data, or .rdata sections. Unlike the code added to the EXE file, this code does not contain the encrypted main module of the bot, rather it reads and decrypts it from the file storage. Functions imported by the system EXE file from the created folder have their start overwritten with the code for performing the switch to the polymorphic code:

The further operating algorithm of the malicious code is analogous to that of the malicious code in the infected EXE files, except that the main bot module is read from the encrypted storage. The original data of the infected DLLs is not saved.
Encrypted code at the end of the last section of the DLL:

In this way, after the system EXE file is started, the imported DLLs located next to it are loaded into the address space of the process. After calling the imported functions, the malicious code is executed.

Startup

To run at system startup, the malware uses the following methods:

1. It writes itself to Software\Microsoft\Windows\CurrentVersion\Run.
   To prevent a UAC window from appearing, it sets the value of the __compat_layer environment variable to RunAsInvoker. Using the CreateDesktop API, it creates a new desktop. Within the framework of this desktop, it uses the CreateProcess API to launch the regedit.exe process. It injects into this process the shellcode, which uses API functions for working with the registry to write the full path of the system EXE to the specified registry key.
2. Using WMI tools, a task is created to run the system EXE file in Task Scheduler, next to which are the infected malicious DLLs (see DLL hijacking above).

KBOT performs a preliminary check of the current tasks in Task Scheduler, reads the contents of DLLs imported from the tasks by the EXE files, and searches for the infection signature data:

If there are no tasks with infected files, it creates a new task on behalf of the local system account (S-1-5-18) without a user name:

Task parameters:

Example of XML with the created task:

Remote management

To remotely manage the victim’s computer, KBOT establishes reverse connections with the servers listed in the BC.ini file.

To create several simultaneous sessions using the RDP protocol, the malware configures the Remote Desktop Server settings:

1. It finds processes that have the termserv.dll library loaded in their memory.
   
2. It patches the memory section of the found process where termserv.dll is loaded. Different patching code is applied for different system versions.
   
3. During the patching process, it searches the memory of the module for specific sets of bytes, and replaces them with those specified.
   

Next, KBOT duly edits the values of the registry keys responsible for TermService settings (not all editable values are listed):

• HKLMSYSTEMControlSetControlTerminalServerLicensingCore EnableConcurrentSessions
• HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionWinlogonEnableConcurrentSessions
• HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionWinlogon AllowMultipleTSSessions
• HKLMSOFTWAREPoliciesMicrosoftWindowsNTTerminalServicesMaxInstanceCount

It then restarts TermService and creates a user in the system for remote connections with the SID WinBuiltinRemoteDesktopUsersSid.

C&C communication

The malware, according to a timer and in a separate thread, starts a process for receiving and processing commands from the server. The list of commands is sent in the form of a buffer. To receive commands, the wininet.dll APIs for network connections are used. The domains for receiving commands are located in the hosts.ini file, which the malware periodically updates. All configuration files with C&C data and connection parameters are stored in encrypted form in one of the last sections of the main bot module; newer versions are stored in an encrypted VFAT storage, as previously mentioned. Files received from C&C are placed in an encrypted storage.

Example of hosts.ini configuration file

Bot IDs and detailed information about the infected system (computer name, domain, system language and version, list of local users, list of installed security software, etc.) are sent to C&C in advance. Traffic is encrypted using the AES algorithm:

The malware can receive the following commands from the C&C server:

• DeleteFile — delete the specified file from the file storage.
• UpdateFile — update the specified file in the file storage.
• UpdateInjects — update injects.ini.
• UpdateHosts — update hosts.ini.
• UpdateCore — update the main bot module and the configuration file kbot.ini.
• Uninstall — uninstall the malware.
• UpdateWormConfig — update worm.ini containing information about the location of EXE files to be infected.
  

  Example of worm.ini

• UpdateBackconnectConfig — update the configuration file with the list of servers for reverse connections.
  

  Example of bc.ini

• Load — load the file into the storage; it loads spyware programs for collecting user data, as well as DLLs for web injects (saved under the names JUPITER.32 and JUPITER.64), their configuration files, etc.
  

  Example of part of the configuration file for a web inject

Obfuscation

To complicate the analysis of its malicious activity, KBOT uses a set of obfuscation tools. When it loads, the main bot module checks whether the imported functions are patched for breakpoints; if so, it reloads the imported DLLs into memory, zeroes the names of the imported functions, and uses string obfuscation. The encrypted strings are stored in a special array of structures; to access them, the decryption function is called with the number of the string structure in the array. The strings are encrypted using the RC4 algorithm, and the decryption key is stored in the structure.

Example of an array of structures with a description of the strings

Access to the string:

Decryption function:

Obfuscation of the DLL that performs the web injects

The malware suspends IBM Trusteer Rapport threads (like the Carberp Trojan), and in the context of its process finds threads whose code was run from DLLs located at the path mask *\Trusteer\Rapport\*.dll

Next, the malware scans the contents of the DLL for signatures of interest to it. If any are present, it suspends execution of the thread, patches the context so that it performs the Sleep function, and resumes the thread:

KBOT then scans the code of the imported functions for patches. If the code is patched (for example, a 0xcc breakpoint has been added), it reloads the imported libraries into memory and resolves imports.

Conclusion

The KBOT virus poses a serious threat, because it is able to spread quickly in the system and on the local network by infecting executable files with no possibility of recovery. It significantly slows down the system through injects into system processes, enables its handlers to control the compromised system through remote desktop sessions, steals personal data, and performs web injects for the purpose of stealing users’ bank data.

IOC

Executable files:
Infected EXEs:
x86 — 2e3a7d4cf86025f5873ebddf3dcacf72
x64 — 46b3c12b44f587ae25d6f38d2a8c4e0f
Infected DLLs:
x86 – 5f00df73bb6e84c49b9bf33ff1d552c3
x64 – 1c15c98bc57c48140558d0e8d71b4ecd
Stealer:
c37058752b2c055ff3a3b3eac50f1350

C&C
213.252.245.229
my-backup-club-911[.]xyz
213.252.245.146/au.exe
sync-time[.]info/au.exe
sync-time[.]icu/au.exe
sync-time[.]club/au.exe