This research from Bitdefender Labs details a cluster of malicious activity we've been tracking since mid-2024. It uncovers a new threat actor group we’ve named Curly COMrades, operating to support Russian interests, that's been targeting critical organizations in countries facing significant geopolitical shifts. We observed them launching focused attacks against judicial and government bodies in Georgia, as well as an energy distribution company in Moldova. 

The group's primary objective is to maintain long-term access to target networks and steal valid credentials. This allows them to move around the network, collect data, and send it out. They repeatedly attempted to extract the NTDS database from domain controllers, the primary repository for user password hashes and authentication data in a Windows network. Additionally, they attempted to dump LSASS memory from specific systems to recover active user credentials, potentially plain-text passwords, from machines where users were logged on. 

"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 <redacted>[.]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. 

This 128-character string is then divided into four 32-character segments. From these segments, two distinct 64-character strings are constructed through concatenation: 

• The substitution alphabet is created by joining characters 0-31 and characters 64-95 

• Result: H2IWw5/AOhBJ6zQmxreqlVFYgfckCEnbKDPL8t0N9T3UMRo1XajZ7Gp+ydvSisu4 

• The standard Base64 alphabet is created by joining characters 32-63 and characters 96-127 

• Result: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ 

These two 64-character strings are then used to establish a one-to-one character mapping. This means each character from the Standard Base64 Alphabet (the second string) is replaced by the character found at the exact corresponding position in the Substitution Alphabet (the first string). For example, if the tool needs to encode a character that would normally be 'A' in standard Base64 (the first character of the standard alphabet), it would instead use 'H' (the first character of the custom substitution alphabet). This effectively scrambles or "encodes" the data using a custom alphabet, making it harder for generic decoders to interpret. 

The tool retrieves content from standard input using PeekNamedPipe() and ReadFile(), then encodes it. The encoded data is sent via an HTTPS request, and the server's response is decoded using the same logic before being written to standard output via the WriteFile() API. 

Another sample discovered at the same location (C:\Program Files (x86)\Google\GoogleUpdate.exe) communicated with the domain <redacted>[.]md as its C2 server. Its structure and behavior closely resembled the previously mentioned site, suggesting it was also configured to operate as an intermediary—likely a compromised web server functioning as a proxy between the victim machine and attacker-controlled infrastructure. 

RuRat 

Although the attackers had already achieved persistence through valid credentials and sustained network access via proxy relays, they implemented an additional method for continued access: deploying the legitimate Remote Monitoring and Management (RMM) tool, Remote Utilities (RuRat). This was initiated by %COMMON_APDATA%\run.bat, which created RuRat's default installation directory and extracted the tool's contents into it. 

MucorAgent  

A complex and previously unknown malware—designated MucorAgent—was identified on multiple systems within one of the targeted organizations. 

 It was engineered as a .NET stealthy tool capable of executing an AES-encrypted PowerShell script and uploading the resulting output to a designated server. Although no PowerShell payloads were recovered, the design of the malware suggests that its execution was intended to occur periodically—most likely for the purpose of data collection and exfiltration. 

The malware consists of three distinct components. The first is a .NET assembly that hijacks a legitimate COM handler associated with the CLSID {de434264-8fe9-4c0b-a83b-89ebeebff78e}. This initial component is responsible for loading a second .NET stage dynamically. The second stage proceeds to decrypt and execute the third stage alongside another assembly responsible for AMSI patching in order to avoid the PowerShell script payload being detected. 

The final payload searches for specific files (index.png or icon.png) within a designated folder, decrypts an embedded PowerShell script, and executes it using System.Management.Automation namespace without invoking the PowerShell.exe process—thereby reducing visibility. The script’s output is then AES-encrypted and wrapped with a PNG header and footer to masquerade as a legitimate image file. This disguised output is subsequently exfiltrated to an attacker-controlled server using curl.exe. 

Deployment 

The typical method used to deploy MucorAgent and establish persistence involves the execution of reg.exe commands to hijack the CLSID. This was done either manually or by placing all the necessary commands into a single batch file, commonly named C:\ProgramData\r.bat: 

The COM handler {de434264-8fe9-4c0b-a83b-89ebeebff78e} is linked to the scheduled task named “.NET Framework NGEN v4.0.30319 Critical.” While this task is typically disabled by default, it is periodically enabled. 

To explain, NGEN (Native Image Generator) is a Microsoft .NET tool designed to boost the performance of .NET applications. It works by pre-compiling an application's intermediate code into native machine code, storing it for faster loading later and reducing startup times and memory usage. NGEN tasks are usually executed in the background during system idle times or triggered after specific events like the deployment of new .NET applications, updates to the .NET Framework, or the installation/updates of .NET-reliant applications. This periodic enablement ensures that .NET applications remain optimized over time. 

By hijacking this CLSID, threat actors gain a unique persistence mechanism, allowing them to restore their MucorAgent backdoor during one of these periodic NGEN optimization scans. A critical advantage of this method is stealth and execution under the highly privileged SYSTEM account. This particular technique, leveraging CLSID hijacking in conjunction with NGEN, is unprecedented in our observations. 

However, a notable drawback of this approach is the inherent unpredictability of NGEN task execution times. For this reason, we believe the attackers likely employed another, more reliable task or trigger in parallel, either to directly execute MucorAgent or to trigger the NGEN optimization process on-demand. This hypothesis is further supported by another task creation command immediately following the reg add commands: 

One step in the setup process involved delivering the payload intended for execution by MucorAgent. This payload was an encrypted data blob, disguised as a .png file (though lacking actual image headers). In one observed instance, the attackers used curl.exe to download this file directly from a compromised website. The file was then placed in the specific location where MucorAgent was configured to find and execute it. 

Another COM handler hijacking was also identified, targeting the CLSID {613fba38-a3df-4ab8-9674-5604984a299a}, which corresponds to NGenTaskLauncher.CriticalTaskHandler64. 

Internals 

The first stage of MucorAgent exposes a class named TaskLauncher, which inherits from TaskHandlerBase, enabling it to be loaded by taskhostw.exe. The core functionality is implemented within the Start() method, which receives a data parameter, verifies the presence of the encrypted payload, and proceeds to invoke the second stage if the payload is found. 

If the primary payload is not found, the Launch() function is invoked instead. This function initiates the curl.exe process, providing it with the -K image parameter. This parameter instructs curl to use the file “image” (located in the %APPDATA%\Microsoft\Windows\Templates\Curl folder) as its configuration file. This action is likely intended to upload the results produced by the previous PowerShell script and to retrieve the next PowerShell script for execution. 

If a file with the payload is present, the next step involves loading the second stage. This is accomplished by configuring an AppDomainSetup and creating an instance of a .NET assembly using CreateInstanceFrom(), specifying the assembly name TaskLauncher.TaskHandler and the type "TaskLauncher, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null". This operation results in the loading of TaskLauncher.dll from %COMMON_APPDATA%\SOShared\Logs\User\FE8C4219-A639-46F6-AC97-8035FF5A4A85\Packages\, and the invocation of the TaskHandler constructor, where the logic for the second stage is implemented. 

It’s important to note that the Properties Date, Form, Path, and Count are set for the second stage and have the following meaning:

In other samples analyzed, the Date property is absent, and the third-stage payload is read directly from a file specified by a hardcoded path within the second stage. The AES key and Count value are extracted and used within the Decode() method to decrypt the third stage, employing the AesManaged algorithm with both the key and initialization vector (IV) set to the same value obtained from the Form property. The decryption process results in a GZip archive containing the AMSI patch assembly concatenated with the third and final stage.

Each invocation of the Show() method results in the loading and execution of a type from the assembly provided as input. 

The initial invocation of the Show method is intended to execute the AMSI patch assembly. As with other payloads, the core logic is implemented within the TaskLauncher.TaskHandler class, where the class constructor calls a static Main() function responsible for applying the AMSI bypass. The bypass technique employed is similar to the method described in this analysis and involves overwriting the address of the AmsiScanBuffer function within a .NET utility library with a dummy function. This modification allows the payload to evade inspection by the Antimalware Scan Interface (AMSI), thereby bypassing detection mechanisms. 

The third and final stage utilizes the Form and Path properties to retrieve the AES key and the directory containing the encrypted PowerShell script. As illustrated in the image below, the Show() function is invoked with parameters that include this information, along with the index.png file—expected to contain the encrypted script—and the string "error.jpg", which designates the output file where the execution results will be written. 

The Show() method reads the encrypted script, decrypts it using the AesManaged algorithm (AES in CBC mode) with both the key and initialization vector (IV) set to the same value, and subsequently decompresses the result using GZIP. The resulting buffer is supplied as input to a PowerShell object instance from the System.Management.Automation namespace. The script is executed, and the output is serialized into a byte array, which is then passed to an encoding routine that performs GZIP compression followed by AES encryption.  

The SetData() method then processes the encrypted output by appending a PNG header and footer, after which the resulting data is written to the designated output file, error.jpg. 

Although neither the encrypted PowerShell script nor the corresponding output file could be recovered, the design of the MucorAgent suggests that it was likely intended to function as a backdoor capable of executing payloads on a periodic basis. Each encrypted payload is deleted after being loaded into memory, and no additional mechanism for regularly delivering new payloads was identified. Additional payloads may have been retrieved by the same curl.exe instance believed to be responsible for uploading the execution results. 

Two potential C2 servers associated with the MucorAgent were identified: <redacted>[.]org and 45.43.91[.]10. The first, a domain, was observed in a curl command and is assessed to correspond to the manual retrieval of an encrypted PowerShell payload. The second, an IP address, appeared in a manually executed curl command likely intended to verify connectivity. This activity was observed immediately following the execution of the scheduled task believed to initiate the first stage of the MucorAgent. 

The locations where the first, second and third stages were deployed during the attacks are provided in the table below: 

In several analyzed samples, the folder designated for locating the encrypted PowerShell payload was configured as C:\ProgramData\canon\OIPPESP, with the payload file named icon.png in certain instances. 

Discovery 

Analysis of all artefacts revealed the methods by which the attackers gathered general information about the compromised network and systems. On specific hosts, depending on operational requirements, living-off-the-land binaries (LOLBins) were employed. A subset of the observed commands is presented below: 

Additional commands falling under the discovery category were also observed. The command curl ipinfo.io was used to verify internet connectivity, while netstat -ano -p tcp was executed to identify active proxy tunnels. For network-level discovery of domain controller information, PowerShell cmdlets from the ActiveDirectory module were utilized.