Hacking Cat Deploys Gorilla RAT and Monkey Ransomware Against Russian Targets

Pro-Ukraine operations shift toward data destruction

Kaspersky researchers have linked two newly documented malware families to Hacking Cat, a pro-Ukraine hacktivist group targeting Russian organizations since approximately February 2024.

The group initially concentrated on website defacements and data theft. By summer 2025, however, its operations increasingly involved encrypting victim files or destroying data outright, according to the research findings.

The identified malware includes Gorilla RAT, a remote-access tool with network-tunneling capabilities, and Monkey Ransomware, a file encryptor that adds the .monkey extension to affected data. Multiple Monkey variants have appeared on systems compromised in operations attributed to Hacking Cat.

Researchers also observed the separate Nemo Wiper during a collaborative attack involving Hacking Cat and the Ukrainian Cyber Alliance. Its apparent purpose was disruption and permanent data loss rather than obtaining ransom payments.

The affected organizations are primarily Russian entities or organizations operating in territories occupied by Russia. The complete victim list, number of compromised systems and scale of resulting data loss have not been disclosed.

Gorilla RAT opens paths into internal networks

Gorilla RAT is a previously undocumented remote-access tool that can tunnel network traffic through an infected system. This gives an operator a potential route from an initially compromised host to other services or machines that are not directly reachable from the internet.

Such tunneling changes the role of the first infected device. Instead of functioning only as a surveillance point, it can become an intermediary for exploring internal network segments and reaching additional systems.

In some attributed incidents, the attackers first compromised Microsoft Exchange servers and then installed Gorilla RAT. The specific Exchange flaws used for initial access are not known. No CVE identifiers, affected Exchange editions or exact vulnerable versions have been disclosed.

That absence limits vulnerability-specific detection and remediation. Administrators cannot use the findings alone to determine whether attackers relied on a newly discovered flaw, an older unpatched vulnerability or a configuration weakness.

The general exposure remains clear. An internet-facing Exchange server can provide both an entry point and a durable position inside an organization if it is vulnerable or inadequately protected.

Kaspersky has not disclosed hashes, filenames, command-and-control infrastructure or protocol details for Gorilla RAT. Defenders therefore need to look for behavior rather than depend exclusively on fixed indicators. Relevant signals include unexplained outbound connections from Exchange systems, unusual proxy-like traffic and access from a mail server to internal resources it does not normally contact.

Monkey Ransomware evolved through several implementations

Monkey Ransomware first appeared in late summer or early fall 2025. During the following months, its operators repeatedly modified it and produced versions written in different programming languages.

The malware encrypts user data and marks affected files with the .monkey extension. Multiple variants were recovered from compromised environments, indicating continuing development rather than use of a single static build.

Kaspersky assessed that the speed and breadth of these changes could reflect generative AI assistance. A model could potentially help rewrite functions, translate code between languages or generate alternative implementations more quickly than a small team working manually.

That remains an assessment, not proof. Rapid iteration could also result from conventional experimentation, reuse of existing code or work by several developers. No direct evidence was disclosed showing that Hacking Cat entered prompts into an AI service or incorporated model-generated code.

The distinction matters for understanding development capacity, but not for incident response. Regardless of how the variants were created, frequent rewrites can reduce the effectiveness of signature-based detection and complicate comparisons between samples.

The available information does not specify Monkey’s encryption algorithm, key management, ransom-note format or whether file recovery is technically possible. It is also unclear whether its operators maintain a reliable decryption process for victims that pay.

Nemo Wiper points to objectives beyond extortion

Hacking Cat’s activity cannot be treated solely as financially motivated ransomware. Researchers observed Nemo Wiper in a joint operation with the Ukrainian Cyber Alliance, assessing that the malware was intended to destroy information and disrupt infrastructure.

In June, with the year not disclosed, the two groups conducted a destructive attack against Donbassteploenergo. The state-owned heating provider operates in Russian-occupied areas of Ukraine’s Donetsk region.

A wiper creates a different risk from conventional ransomware. Encryption used for extortion theoretically leaves open the possibility of decryption, although payment never guarantees recovery. Destructive malware may instead overwrite or corrupt information without preserving any practical restoration mechanism.

Hacking Cat also collaborated with the pro-Ukraine Cyber Anarchy Squad. In March, again without a disclosed year, the groups claimed responsibility for compromising a contractor supporting Rosatom, Russia’s state nuclear-energy corporation. Details about the initial access method, compromised systems and operational effects are not known.

These collaborations indicate that campaigns may combine access, tooling and public claims from several actors. A single intrusion can therefore involve more than one group and more than one objective.

Shared malware makes attribution uncertain

Kaspersky’s attribution is not uncontested. Hacking Cat acknowledged ownership of some tools in a Telegram statement but denied that the ransomware lockers belonged to the group. It accused the researchers of incorrectly combining unrelated actors’ malware and challenged aspects of their reverse-engineering work.

Researchers also found the same malware in operations associated with separate groups. In some cases, different actors apparently used identical multi-stage infection chains.

One possible explanation is centralized or semi-centralized development. A single programmer or small development team may create and maintain tools that are subsequently distributed among several pro-Ukraine hacktivist groups.

That model would blur the boundary between developers and operators. Finding a particular malware family on a victim system would not necessarily identify the group that selected the target, conducted the intrusion or controlled the infrastructure.

Tool sharing also increases the risk of circular attribution. Investigators may associate malware with one group based on an earlier incident, then use that association to attribute later attacks even after the tool has spread to other operators.

The findings therefore support an association between Hacking Cat, the observed campaigns and some of the custom tooling, but they do not establish exclusive ownership of every Monkey Ransomware variant.

Exchange operators should hunt for post-compromise behavior

No formal mitigation instructions or vendor-specific indicators have been published for these campaigns. Organizations running Microsoft Exchange should begin with supported security updates and confirm that externally accessible servers are not missing relevant vendor patches.

Because the exploited vulnerabilities and affected versions remain unknown, patching alone should not be treated as evidence that a system was never compromised. Administrators should review historical Exchange activity, authentication records, newly created accounts and processes launched by mail-server components.

Access to management interfaces should be restricted wherever operationally possible. Unexpected connections from Exchange hosts to internal systems deserve investigation, particularly when they resemble tunneling, proxying or lateral movement.

Defenders should also search endpoints and file servers for files ending in .monkey, unexplained bulk file modifications and simultaneous encryption activity across multiple directories. Backup systems must be checked separately to ensure that attackers did not erase or corrupt recovery copies.

Potential wiper behavior requires rapid isolation. Indicators include large-scale destructive writes, sudden file corruption, deletion of recovery material and coordinated disruption across several machines.

The strongest defensive approach is to connect these signals rather than inspect them independently. Suspicious Exchange activity followed by internal tunneling, deployment of unfamiliar remote-access software and widespread file changes may expose the full intrusion chain before encryption or destruction reaches the rest of the network.