RansomEXX

Management summary

RansomEXX is relevant because the group shows a recognizable ransomware or extortion chain: targeted ransomware against large organizations with Windows and Linux variants. For visitors this is not a name to remember, but a scenario to counter their own environment.

The most important question is where the organization is vulnerable before encryption becomes visible. At RansomEXX, the defensible phase lies mainly with initial access, lateral movement, data discovery, staging, exfiltration and misuse of management rights.

The profile is written as practically CTI- file: what does the group do, which artifacts are known, which victims or sectors come back and what measures reduce the likelihood of the same method being successful?

Grouping and development

RansomEXX must be managed as a living profile. Actors exchange tools, affiliates, leak sites and negotiators, but operational patterns are often recognizable.

RansomEXX was associated with targeted attacks on large organisations where critical data and servers are a lot of pressure.

When a group gets older or less active, the file remains useful as case profile as long as attack techniques come back to new groups. Therefore we only remove real noise profiles, not historically usable groups.

Attack pattern from public cases

Kaspersky analysed a Linuxbuild of RansomEXX and saw similarities in code, ransom notes and extortion approach with the well-known Windows family.

The Linux variant shows that ransomware not only hits Windows endpoints. Servers, Linux application hosts and virtualization layers should be in scope.

The damage usually occurs in phases. First access is made usable, then the environment is understood, then data is collected or management width is built up, and only after that will encryption, publication or further extortion.

Known IOCs and artifacts

Use hard IOC pistols especially for retro-hunting and confirmation. The structural detection value is in behavior: remote access, tool usage, datatasting, privilege changes, service stops and unusual file activity.

The Linux variant shows that ransomware not only hits Windows endpoints. Servers, Linux application hosts and virtualization layers should be in scope.

Record by incident which files, notes, extensions, command lines, external destinations and accounts have actually been observed, preventing old indicators from being treated as actual truth.

Practical detection logic

Link identity to endpoint behavior. A suspicious login becomes really relevant only when it subsequently follows discovery, remote execution, tool installation, file-share access or data staging.

Monitor sensitive data on massive access, archiving and outbound transfer. Double extortion often means this is more important than the first encryption notification.

Check management platforms, RDP, PowerShell, PsExec-like behaviour, RMM-tools and hypervisor or backup consoles for abnormal usage. Ransomware often uses common management paths.

Concrete Hardening Priorities

Secure Linux servers with EDR/logging wherever possible, limit SSH, sudo and service accounts, monitor massive file writes and test recovery of Linux and application servers.

Force MFA on external access, limit RDP and VPN, segment servers and protect backups outside the normal domain management layer.

Make logging central to identity, VPN, EDR, firewall, Windows Event Logs, cloud storage and backup platforms. Local logs alone are insufficient for ransomware.

Identity, naming and attribution

For RansomEXX, the operational starting point is an exact identity match. The local dossier records the following names or aliases: RansomEXX, Defray777. An alias is a search aid, not independent evidence of shared operators. Similar names, reused logos and the same extortion vocabulary cannot establish a relationship between groups. Analysts should retain the original spelling of a claim and distinguish the publisher, malware family and suspected intrusion operator. Those roles can belong to different people. This prevents an incident being assigned to the wrong group simply because a filename or public post resembles an earlier case. Any proposed relationship needs its own dated, attributable source.

Timeline and interpretation of dates

The source registry date available for RansomEXX is 2020-05-14; the metadata snapshot was collected on 2026-09-15. These timestamps describe the available record, not a proven beginning of criminal operations. Registration may follow earlier activity, and a claim can concern an older incident. A defensible timeline separates suspected intrusion, data access, discovery by the victim, publication by the claimant and discovery by the monitoring service. The profile review date is another independent timestamp. Analysts should not silently convert one date into another. When sources disagree, preserve both observations and their provenance, then explain the uncertainty rather than presenting a falsely precise attack chronology.

Victim claims and targeting assessment

The victim panel for RansomEXX shows up to five distinct organisations from the stored claim history. It is a moving observation window, not a complete incident census. Public listings can omit victims, repeat old material or exaggerate access. Consequently, a short run of organisations in one country or industry does not by itself prove deliberate targeting of that sector. The useful comparison is with the organisation's own dependencies: shared providers, remote access arrangements, exposed services and sensitive data flows. A supplier appearing in a claim justifies verification through established contacts, but does not establish that downstream customers were compromised. Separate confirmed statements from the claimant's assertions.

Indicators of compromise (IOCs)

Indicators are historical observations, not proof of a current infection. Validate source, age and context before hunting or blocking; legitimate administrative tools can produce false positives.

Sources

• Kaspersky Securelist: RansomEXX Trojan attacks Linux systems
• MITRE ATT&CK — Valid Accounts (defensive context)
• MITRE ATT&CK — External Remote Services (defensive context)
• MITRE ATT&CK — Exfiltration Over Web Service (defensive context)
• MITRE ATT&CK — Inhibit System Recovery (defensive context)
• Ransomware.live — RansomEXX

Evidence and limitations

Attribution describes the source assessment, not a verified identity. A leak-site listing alone does not prove encryption, data theft, a particular vulnerability or an affiliate relationship. Missing information is left explicit.