Unveiling KamiKakaBot – Malware Analysis

by Mar 22, 2024

Back in January 2023 Group-IB first reported and documented the TTPs of DarkPink, an APT group that targets the Asia-Pacific regions.

We’ve been monitoring KamiKakaBot samples since September of last year. And at the start of this year in January we’ve noticed 2 new samples being uploaded to Virustotal.

These 2 new samples have had a very low detection rate. Which led us to investigate them a bit closer.

 The following is a full writeup on the newer variants KamiKakaBot samples from the initial lure to full persistence on disk and credential stealer component.

Johann Aydinbas was the first to spot this and mention it on twitter. Kudos to him.

Start Of The Infection

As discussed in the original Group-IB research blog, DarkPink APT uses ISO files as a phishing mechanism. And this case is not much different in terms of structure.The ISO in question is named “Proposed Concept Note on the AOIP-based Comprehensive Regional Architecture.iso” and contains the following.

Name

Description

ID SOM LETTER ON CONCEPT NOTE ON THE AOIP-BASED COMPREHENSIVE REGIONAL ARCHITECTURE.PDF

Lure document that is never used by the malware

CN AOIP-BASED COMPREHENSIVE REGIONAL ARCHITECTURE (1).DOCX.EXE

Legitimate WinWord.EXE binary masqueraded as a double extension file to incentivise the victim to click it

~CN AOIP-BASED COMPREHENSIVE REGIONAL ARCHITECTURE (1).DOC

Lure document that also contains the .NET XML task that will load the KamiKakaBot main component as well as the credential stealer component

WWLIB.DLL

Loader

These newer KamiKakaBot samples use “WWLIB.dll” DLL in order to side-load the malicious payload, in contrast to “MSVCR100.dll” DLL that was used in older variants.

Something to note is that winword.exe (which is the binary being used to sideload the WWLIB DLL) as well as many Microsoft Office utilities such as Excel, PowerPoint, etc are vulnerable to many other side loading vulnerabilities. As it’s illustrated in the screenshot below that’s taken from hijacklibs.net.

WWLIB Sideloading

The infection starts when the victim launches the binary “CN AOIP-BASED COMPREHENSIVE REGIONAL ARCHITECTURE (1).DOCX.EXE” which is the legitimate “WinWord.exe” binary masqueraded as a word document using the double extension technique. It tries to side load the “WWLIB.dll” from the current directory.

Once loaded, it starts by searching the current directory for a file that has the following characteristics:

  • Hidden
  • Read Only
  • Filename contains both “~” and “.doc”

The file that fits these characteristics was shipped inside of the ISO and in our case it has the name “~CN AOIP-BASED COMPREHENSIVE REGIONAL ARCHITECTURE (1).DOC”

Next, it’ll start reading the aforementioned DOC file starting from the end and going up until a null byte is reached. That blob is then decrypted with a hardcoded XOR key. The content is an XML file that we will discuss later in this article.

The next step is to decrypt the file name of the XML file that will be created next. This will result in “wctA91F.tmp”.

The XML file is then created under “C:\Users\<username>\AppData\Local\Temp\”

We’re providing a Python script that emulates the decryption routine mentioned above. It takes the “DOC” and a “XOR” key and outputs the XML in question.

After the decryption routine, the DLL will try to execute the lure document by locating the legitimate Word binary installed on the system. It does this by assuming that a “Start Menu” entry exists for Word.

When an application is installed in Windows it can be added to the list of applications in the Start Menu. This is achieved by adding a shortcut “.lnk” file pointing to it. A default Microsoft Office Word installation creates a shortcut called “Word.lnk” in that location.

The DLL chooses this method of execution to avoid hard coding different paths for the “WinWord.exe” binary. As the exact location will depend on which version is installed.

Once the Word.lnk shortcut is found it proceeds to execute the lure “~CN AOIP-BASED COMPREHENSIVE REGIONAL ARCHITECTURE (1).DOC” via CreateProcessW

Below is the command line after execution.

cmd /c C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Word 2016.lnk ~CN AOIP-based Comprehensive Regional Architecture.doc

Persistence & Execution

Once the lure has been executed, the DLL sets up the following persistence mechanism in order to initiate the execution of the 2nd stage (XML payload) and to ensure execution across reboots.

It starts by setting 3 environment variables that point to the following values.

Name Value Description
Msbd %WINDIR%\Microsoft.NET\Framework64\<version>\MSBuild.exe Legitimate path to MSBuild instance on the system
Pyps powershell PowerShell
Tepmrd %TEMP%\wctA91F.tmp Path to the decrypted XML

Once these variables are set. It overrides the Winlogon Shell registry entry in order to set up persistence.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell = explorer.exe, explorer.exe /e,/root,%Pyps% -nop -w h "Start-Process -N -F $env:Msbd -A $env:Temprd"

This will make sure that every time the current infected user logs onto the system, the above command is executed.

The command leverages the fact that anything passed to the “explorer.exe” binary is executed. If we replace the environment variables, we get the following PowerShell command:

powershell -nop -w h "Start-Process -N -F %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe -A %TEMP%\wctA91F.tmp"

Finally, it makes sure that the machine will shut down by setting a scheduled task called “OneDriver Reporting Task” that runs on a weekly basis, every Tuesday and Friday at 12:35PM executing the “shutdown” command:

SCHTASKS /CREATE /f /TN "OneDriver Reporting Task" /TR "shutdown /l /f" /SC WEEKLY /d TUE,FRI /ST 12:35 

After a reboot the Msbuild process will compile and run the KamiKakaBot, which we will look at next.

KamiKakaBot Says Compile Me Please

In the previous section we’ve seen that the side-loaded WWLIB.dll decrypted and dropped an XML in the temp directory that was going to be executed by MsBuild.

The XML file uses an MsBuild inline task to embed everything in one file, and it contains two components:

  • KamiKakaBot Main Payload.
  • KamiKakaBot Credential Stealer.

The main payload is stored as an XOR encrypted base64 blob, whereas the credential stealer is simply XOR encrypted.

The decryption key is hardcoded in the task itself.

The tasks start by generating a random name for the credential stealer, decrypting and storing it in the temp directory and setting its attributes to “Hidden”.

It then decodes and decrypts the main KamiKakaBot payload, which results in a ZIP file. This ZIP file is opened, and its entry is the DLL that will be directly loaded into memory and executed via the “InvokeMember” function.

The main KamiKakaBot payload is invoked with three arguments which are the following:

  • Encrypted Telegram Token.
  • Telegram Chat ID.
  • Credential Stealer DLL path.

KamiKakaBot Main Payload

KamiKakaBot starts by decrypting the passed “Telegram Token” and calling the “Execute” function to start the execution.

Execute Function

The “Execute” function starts by initialising some variables.

  • It sets the variable “Ap1kkk3y” which will contain the “bot” prefix and the telegram token for communication with the API.
  • It sets the variable “CHATID” with the passed on chat ID from the previous step.
  • It sets the variable “IdentifyName” by calling the “getIndentifyName” function. Which is a function that uses the “WindowsIdentity” class from .NET in order to obtain the current user information. The results will be in the form “Domain+=…=+Username”
  • It sets the “linktel” variable to the telegram API domain “https://api.telegram.org/
  • It sets the “xmlName” variable to the value of “System.IO.Compression”
  • It then checks if the credential stealer file that was passed as an argument from the previous step and that resides on disk. If it does, then it converts its content into base64 for later use, stores it in the “Dat10dje1” variable and then deletes the file from disk.

After this initialization it starts the main function “Run”.

Run Function

The “Run” function is the “real” main function of KamiKakaBot. It starts by calling a function called “k01mdhaj3yf”.

This function ensures the creation of a file in the temp directory with the name “%TEMP%\\3f88dd57-6ce606be-54c358fb-c566587a.tmp”. This text file will contain a string that’s a combination of a substring from the Telegram Token and the string “:0”.

For example if the token string was this “bot6860256103:ABFrlFzcLuyXU4HxKisFUhvhwKucyL4rDS0” then the content of the text file would be “ABFrlFzcLuyXU4H:0”. This string is parsed and depending on the value after the colon either a “0” or a positive integer value is returned.

The result is used to determine the path of the following “if” clause.

The function “s39fjMkdm” will simply take the results from the previously set “IdentifyName” variable and send it to the attacker by using Telegram’s “sendMessage” API.

Based on older samples the appended values “12” and “21” signify either a “new connection” established or “reconnection” respectively.

Next, the function “ok0djfnakf” is called which is responsible for launching the credential stealer component.

This function simply takes the contents of the previously initialised variable “Dat10dje1”, decodes it from its base64 form and loads it into memory.

It then invokes the member function from the stealer with the name “JegrywbXVS” and passes to it a randomly generated name in the form

xxxx-xxxx-xxxx-xxxx-xxxx.tmp

After invoking the stealer, the function “kowfnF1lwd3” is called. Its aim is to send the data collected by the stealer as a ZIP file to the threat actor via the sendDocument API.

Note: We’ll discuss the functionality of the stealer in a separate section.

After this we reach the main C2 loop which is straightforward. It loops indefinitely waiting for commands from the threat actor. These commands are collected via the getUpdates API.

The functions perform some checks related to the ChatID and MessageID to ensure that the commands are coming from the expected chat and commands aren’t repeated.

For a command to be passed a couple of conditions need to be satisfied.

  • The ChatID from the API response needs to be equal the ChatID of the sample
  • The From ID from the API response needs to be equal the ChatID of the sample
  • The Message ID from the API response needs to be bigger than the current stored value.

While the 2 first conditions are straightforward. In order to obtain the current MessageID value, the function reads the contents of the file “3f88dd57-6ce606be-54c358fb-c566587a.tmp” from earlier and extracts the value stored after the colon.

In our example “abfrlfzcluyxu4h:0” the extracted value will be “0”. The MessageID sent by the threat actor needs to be bigger than “0”. This is to keep track of the last executed command.

The 2nd part of the condition that needs to be valid is that the command either starts with the string all+=…=+” or with Domain+=…=+Username” where “Domain” and “Username” are from the infected user machine.

Either way the result is passed on to the rest of the loop in order to execute the appropriate functions. The C2 accepts the special values to execute specific functions:

  • 1* – Send current user Identity.
  • 34 – Load the credential stealer module and collect the data.
  • 91 – Update the Telegram Token and Chat ID.
  • 45 – Update the build XML file in order to provide a newer version or newer payload.

If none of the above is sent then the command is passed on to the “s39fjMkdm” function, which will execute it via “Cmd.EXE”.

cmd.exe /c <command>

KamiKakaBot Credential Stealer

The credential stealer component is straight forward. It starts by creating a new directory in the temp folder with the OS version as a name by calling the “Environment.OSVersion.Version.ToString()” function.

The folder name will be in the form of

C:\Users\<username>\AppData\Local\Temp\<OSversion>

For example:

C:\Users\<username>\AppData\Local\Temp\6.2.9200.0

Its main goal is to steal credentials and login information from the user’s browser. It focuses on Mozilla Firefox, Microsoft Edge and Google Chrome.

It grabs the following file from the Firefox profile folder:

  • autofill-profiles.json
  • cookies.sqlite
  • key3.db
  • key4.db
  • logins.json

It extracts the decryption key from the Chromium based browsers Chrome and Edge and saves it into a text file. It then copies the following files from their respective profile folders:

  • Cookies
  • Login Data
  • Login Data For Account

All of the above is copied into the aforementioned temporary directory, compressed and put into a ZIP file, to be used by the KamiKakaBot function “ok0djfnakf” described above.

KamiKakaBot Variants – New Vs Old

While there are some slight differences between the old and new variants of KamiKakaBot. Including different text file anchors, code obfuscation, and different special C2 commands. The major difference is mainly the decoupling of the stealer component to a standalone DLL from the main payload.

Detection Opportunities

KamiKakaBot TTPs offer many detection opportunities that are easily detectable using public Sigma rules. For example, using our endpoint agent Aurora we can see many alerts triggering just for the first stage.

Indicators Of Compromise

You can find all IOCs and links to the latest version of the detection rules here.

MITRE ATT&CK

Tactics Technique/Sub-Technique ID
Collection Archive Collected Data: Archive via Library T1560.002
Command and Control Application Layer Protocol: Web Protocols T1071.001
Defense Evasion Deobfuscate/Decode Files or Information T1140
Defense Evasion Reflective Code Loading T1620
Defense Evasion Hijack Execution Flow: DLL Side-Loading T1574.002
Execution Command and Scripting Interpreter: Windows Command Shell T1059.003
Execution Command and Scripting interpreter: PowerShell T1059.001
Exfiltration Exfiltration Over C2 Channel T1041
Persistence Boot or Logon Autostart Execution: Winlogon Helper DLL T1547.004
Persistence Scheduled Task/Job: Scheduled Task T1053.005

Nextron’s Solutions for Enhanced Cybersecurity

Nextron steps in where traditional security measures might miss threats. Our digital forensics tools conduct thorough analyses of systems that show signs of unusual behavior. They effectively identify risky software and expose a range of threats that could go unnoticed by standard methods.

Our signature collection is tailored to detect a variety of security concerns. This includes hacker tools, their remnants, unusual user activities, hidden configuration settings, and legitimate software that might be misused for attacks. Our approach is especially useful in detecting the tactics used in supply chain attacks and identifying tools that evade Antivirus and EDR systems.

About the author:

Nextron Threat Research Team

Newsletter

New blog posts
(~1 email/month)

GDPR Cookie Consent with Real Cookie Banner