“Curly COMrades” heavily rely on establishing strong access points. They use proxy tools like Resocks, SSH, and Stunnel to establish multiple entry points into internal networks. Through these established proxy relays, they frequently executed remote commands, often through tools like Atexec. 

For persistent access, attackers deployed a new backdoor we’ve named MucorAgent, using a very smart technique: hijacking CLSIDs to target NGEN (Native Image Generator) for persistence. NGEN, a default Windows .NET Framework component that pre-compiles assemblies, provides a mechanism for persistence via a disabled scheduled task.

This task appears inactive, yet the operating system occasionally enables and executes it at unpredictable intervals (such as during system idle times or new application deployments), making it a great mechanism for restoring access covertly. Given this unpredictability, it is probable that a secondary, more predictable mechanism for executing this specific task also existed. 

They also strategically use compromised, but legitimate websites as traffic relays. This tactic complicates detection and attribution by blending malicious traffic with legitimate network activity. By routing command-and-control (C2) and data exfiltration through seemingly harmless sites, they bypass defenses that trust known domains and hide their true infrastructure. It’s very likely that what we’ve observed is just a small part of a much larger network of compromised web infrastructure they control.

Threat Actor Naming 

In our extensive analysis, we looked for strong overlaps with known threat actor groups. While we noted minor similarities, like the incidental use of rar.exe for archiving or the System.Management.Automation namespace for PowerShell code execution, these are common tactics shared by many actors. Ultimately, we found insufficient evidence to confidently attribute this campaign to any existing group. To avoid misleading the community with low-confidence attribution, we chose to designate them as a new, distinct threat actor: ‘Curly COMrades’. 

Our decision to name this threat actor “Curly COMrades” is rooted in two primary factors: their operational methodologies and a broader industry concern. 

Their technical indicators heavily feature the use of curl.exe for C2 communications and data exfiltration, and a significant aspect of their tooling involves the hijacking of Component Object Model (COM) objects. Beyond these technical aspects, the group’s operations align with the geopolitical goals of the Russian Federation. 

The second, and perhaps more contentious, aspect of ‘Curly COMrades’ is its deliberately derogatory nature. We recognize that the cybersecurity industry has a long-standing trend of assigning cool, fancy, or even mythological names to threat actors. While memorable, we—and many others in the cybersecurity community—believe this inadvertently glorifies and, at times, even markets malicious actors. 

By choosing a name like ‘Curly COMrades,’ we aim to de-glamorize cybercrime, stripping away any perception of sophistication or mystique. They are not ‘fancy bears’ or ‘wizard spiders’; they are simply malicious actors engaged in disruptive and harmful behavior. 

We hope this choice sparks a wider conversation within the cybersecurity community about naming conventions, encouraging a shift towards more practical and less sensational designations. 

Technical Analysis 

Suspicious activity was first detected in late 2024 with an attempt to deploy a resocks client. This triggered an investigation, which ultimately uncovered a wider espionage campaign. Forensic analysis of the affected systems revealed additional compromised machines and credentials, highlighting the attackers’ extensive efforts to maintain persistent access. 

The attackers installed reverse proxy agents across multiple systems and leveraged stolen credentials to access, collect, archive, and exfiltrate internal data. They repeatedly attempted to extract the NTDS database from domain controllers and dump LSASS memory on select systems to maintain their access.  

After several resocks tunnels were taken down, the attackers tried to reestablish access by deploying a SOCKS5 server on an internet-facing host as an alternative entry point. They then attempted to set up new tunnels between the victim network and their infrastructure using tools like ssh.exe and stunnel. Their persistent efforts to regain access underscore a common tactic of advanced threat actors: establishing multiple routes for persistence. 

Remote commands were executed through reverse proxy relays using the stolen credentials—likely via atexec from the Impacket toolkit or a similar tool. The attackers’ focus was on harvesting credentials and browser data. During this period, a previously unseen three-stage malware component—MucorAgent—was identified within their toolkit. This malware was designed to maintain persistence, execute PowerShell scripts, and exfiltrate output via curl.exe. 

Another important tactic observed in this campaign is strategic use of compromised, legitimate websites as traffic relays, a tactic that significantly complicates detection and attribution. This approach allows them to blend malicious traffic with normal network activity, making it harder for security tools to flag their communications. By routing C2 and data exfiltration through seemingly benign sites, they evade defenses that trust known domains and obscure their true infrastructure. 

The sections below outline the observed threat actor activity as identified through forensic analysis and investigation. 

Proxy Relays 

Proxy tools were a core component of these intrusions. When combined with valid privileged credentials, they gave the attackers unrestricted access and control over the affected networks. 

Resocks 

The most frequently observed proxy was resocks, a readily accessible proxy tool from GitHub. Resocks essentially turns a compromised computer into a secure relay point, allowing attackers to route their traffic through that internal system as if they were directly on the network. The code samples recovered from the compromised systems had been built using garble, an obfuscation utility designed for Go binaries. Garble works by scrambling and encrypting parts of the program’s code, making it harder for security analysts to reverse-engineer it and understand how the tool functions.

Resocks acts as a relay point into a compromised network. In this case, Network A represents an attacker, and Network B represents a victim. Source: resocks GitHub readme. 

Here’s an example of a resocks deployment: the attackers first manually retrieved the client binary using curl. They then initiated the resocks tunnel to establish their C2 connection, and finally created a scheduled task to maintain this access persistently.

As usual, the choice of paths, scheduled task names, and service names clearly indicates an attempt to blend in with legitimate system files and processes. For persistence, the attackers consistently created scheduled tasks and Windows services.

Analysis of commands found within the scheduled tasks and service definitions revealed that, in most cases, the resocks clients were configured to communicate over port 443. One instance involving port 8443 was also identified.

Available evidence indicates that a significant portion of the remote command execution was channeled through their established SOCKS tunnels. Alongside general remote commands, we also observed attempts to execute DCSync. This attack technique exploits legitimate Active Directory replication functions to trick a Domain Controller into replicating sensitive information (including user password hashes) to the attacker’s machine , demonstrating the Curly COMrades’ appetite for credentials and further lateral movement.

In one instance, the resocks client located in Moldova initiated an HTTP request to a Redmine server over port 3000 in Ukraine. Redmine is a legitimate, open-source web-based project management application, widely used by businesses, that use port 3000 by default. This behavior strongly indicates that the Redmine server in Ukraine was likely compromised by the attackers and then repurposed, potentially allowing the attackers to circumvent geolocation-based access restrictions.

SOCKS5 Binary

Another proxy tool, believed to have been deployed alongside the resocks tunnels as an alternative access point on an internet-exposed system, was identified as a SOCKS5 server binary, adapted from an open-source project hosted on GitHub. This tool binds to 0.0.0.0:55333 (with a later identified sample binding to port 55334; MD5: 44a57a7c388af4d96771ab23e85b7f1e), enabling immediate proxying of network traffic after execution. Before the server starts, the application console window is hidden through calls to the AllocConsole(), FindWindowA(), and ShowWindow() APIs using the SW_HIDE parameter.

In total, two distinct samples of this SOCKS server variant were identified across separate compromised hosts.

Persistence for one instance of this SOCKS5 server was achieved through the scheduled task names \Microsoft\Windows\DeviceDirectoryClient\RegisterDevicesUSB.

SSH + Stunnel

The most recently investigated activity revealed a shift in the technique to establish SOCKS proxy capabilities. Instead of relying on custom proxy binaries, ssh.exe was used for remote port forwarding, while tstunnel.exe—a component of the Stunnel suite — was used to encrypt the TCP traffic. This approach was likely intended to obfuscate the SSH communication and evade network-based detection mechanisms.

First, the tstunnel.exe (MD5: 063770f7e7eb52d83c97aa63c0a6f8a6) was executed with a configuration directing it to bind to the localhost interface on a high-numbered port, such as 52437. The configuration instructed the tool to encapsulate the local TCP traffic and send it to the remote compromised server, creating an encrypted communication channel.

Next, ssh.exe was copied to an unusual location, like C:\ProgramData\Microsoft\UEV\Templates\Template.exe. A special configuration file was also put in place. This file was set up to enable remote port forwarding, allowing ssh.exe to communicate with the SSH server through a local port opened by tstunnel.exe. File permissions were then adjusted to make sure ssh.exe could run successfully. implemented

The binary was then launched with the -F option to load the custom configuration, followed by parameters that activated the remote forwarding functionality.

In a separate attempt to configure SSH traffic forwarding, the use of a custom configuration file was avoided. Instead, a default configuration file was placed for the SYSTEM user. File permissions required for this setup were adjusted through the execution of a batch script located at C:\ProgramData\ch_prm.bat:

Next, the ssh.exe binary was copied to C:\Program Files (x86)\Google\chrome.exe and executed using a configuration profile “Update” that was likely predefined in the default config. The selection of the destination path, executable name, and profile designation appears to have been deliberately made to blend seamlessly with legitimate system behavior.

CurlCat

An interesting artifact associated with this execution—presumably intended to support traffic forwarding—was the spawning of a secondary process, C:\Program Files (x86)\Google\GoogleUpdate.exe (MD5: dd253f7403644cfa09d8e42a7120180d), by the ssh.exe binary. Analysis of GoogleUpdate.exe revealed that it obtained handles to the standard input and output streams and facilitated bidirectional data transfer between these streams and C2 server over HTTPS. The binary effectively behaves in a manner similar to netcat and is likely used in conjunction with the SSH ProxyCommand option to relay traffic through the specified intermediary.

The tool is assessed to be a custom implementation, with several relevant details identified through static analysis. It is statically linked with the libcurl library, which is used to establish communication with a hardcoded compromised site [.]ge — likely hosted on a PHP and WordPress stack. HTTP requests issued by the tool contain hardcoded headers, indicating a predefined communication pattern with the C2 infrastructure:

An important part of the tool’s setup involves creating a custom character substitution map. This map is derived from the following string.