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”.
Access key verification
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.
|
1 |
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.
Contents of the SFX archive
The install.bat script contents
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.
The backupagnt.exe loader code
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.
Example agent configuration
Example of agent requests pinging the C2 address, as flagged by Kaspersky solutions and displayed in Kaspersky Threat Lookup
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.
SFX archive contents (09d0517a1f69feff8186655ae3b567e0)
The install.bat script contents
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.
Main backdoor loop
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:
- In user mode, the program finds the PID of the target process.
- It opens a handle to \\.\Warsaw_PM.
- It constructs a buffer containing the target process’s PID.
- It calls DeviceIoControl.
- 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.
Example of the process list storage inside the EDR killer
Both kil.exe and Killer.exe share the exact same list of processes targeted for termination:
|
1 |
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.
Example of output from the GhostDriver utility
The tool operates through the following stages:
- 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. - Enumerate system processes
To locate PIDs, the tool relies on standard Windows APIs:- CreateToolhelp32Snapshot
- Process32First
- Process32Next
- Generate a list of processes to kill.
- 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.
Original function names preserved within the Trojan’s body
When executed, ClearWater logs its progress in a separate console window.
The console window displayed upon launching the Trojan
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.
|
1 2 3 4 5 6 |
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.
Ransom note:
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).
Two variants of the desktop and lock screen image
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:
|
1 |
Get-Process|Where-Object{$w -notcontains $_.Name.ToLower()}|Stop-Process -Force |
The exclusion list contains various essential system processes and breaks down as follows:
|
1 |
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.
ClearWater execution graph in Kaspersky Cloud Sandbox
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.
Visualization via Research Graph on Kaspersky Threat Intelligence Portal
Kaspersky Threat Lookup demonstrating the connection between malicious files and the attackers’ IP address
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
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
Authors
From cause to cash: a cross-border look at hacktivist activity