REvil / Sodinokibi

Management summary

REvil, also known as Sodinokibi, was one of the most famous ransomware-as-a-service operations. The group was linked to double extortion, high ransom demands and attacks that could leverage managed service providers or management platforms. For visitors, the Kaseya VSA-case is especially important: when management platforms are abused, one access path can hit many organizations at once.

REvil is historic, but its defense value is high. The profile shows why RMM, MSP- access, software distribution and privileged management require separate security layers. An organisation can be technically good at endpoints but still vulnerable through the platform that manages those endpoints.

The main lesson is that supply-chain ransomware is not only a supplier problem. Customers need to know which management tools are active in their environment, what rights they have, how updates are validated and how quickly abuse can be stopped.

Grouping and development

REvil became a dominant RaaS operation with affiliates and a public leak site. Sodinokibi was often used as a technical name for the ransomware variant. The group gained extra fame from large victims and the Kaseya VSA- campaign in July 2021.

CISA and FBI published guidance around the Kaseya VSA supply-chain ransomware attack. That guide highlighted among other things the disabling or securing of VSA- servers, indicators, recovery steps and monitoring.

Although REvil was disrupted as a brand, the ecosystem example remains current: management platforms remain attractive to attackers because they offer trusted distribution, rights and network coverage.

Attack pattern from public cases

The Kaseya case was about misuse of a management platform used by MSP pictorialists, which is different from a loose phishing attack: the actor uses the management chain to distribute payloads himself. For defense, this means that management servers should be treated as crown jewelry.

REvil used double extortion. Data and availability were both printing agents, so not only search for encryption, but also for staging, compression, exfiltration and leak-site claims.

In the case of supply-chain-like incidents, the scope should be determined differently. Ask not only which endpoint was hit, but which customers, tenants, agents, scripts, update channels and credentials were accessible via the management platform.

Known IOCs and artifacts

Sodinokibi/Revil artefacts may include ransomware payloads, ransom notes, modified extensions and leak site claims. In the Kaseya context VSA- server and agent artefacts are especially relevant.

CISA /FBI published Kaseya-related guidance andIOC Use these historically for retro-hunting atVSA- environments andMSP- customers.

RMM and software distribution activities outside normal channel operators are important behavioural indicators, especially when many endpoints receive assignments simultaneously.

Practical detection logic

Monitor management platforms on mass deployment, unknown scripts, new packages, modified agent configuration and output from management servers outside of channelers.

Link MSP-actions to customer environments. A REvil-like incident can affect multiple customers; logging must keep tenant and customer boundaries visible.

Look for data-astaging before encryption. Double extortion means that system recovery is not enough when data has already been brought out of the environment.

Concrete Hardening Priorities

Centralize identity and remote access. Most historical ransomware chains did not start with a magic payload, but with valid access, phishing, vulnerable external services or reused credentials. MFA, device binding, account hygiene and logging are the first defense layer.

Protect data before encryption starts. Monitor massive file access, compression, staging, cloud transfer, Rclone-like behavior and unusual outbound volumes. Double extortion makes data steal just as important as encryption.

Separate backup, hypervisor and management accounts of regular domain routes. Historical groups sometimes disappeared, but their lesson remains: repairability fails when the same compromised identity can manage production and recovery.

Treat RMM and MSP- platforms as tier-0 systems. Use separate accounts, MFA, network restrictions, change control and logging that cannot be erased by the same platform.

Set up an emergency procedure to securely pause management agents or update channels when abuse is suspected.

Identity, naming and attribution

For REvil / Sodinokibi, the operational starting point is an exact identity match. The local dossier records the following names or aliases: REvil, Sodinokibi, Sodin. 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 REvil / Sodinokibi is 2019-08-26; 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.

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

• CISA/FBI Guidance for MSPs and Customers Affected by Kaseya VSA Supply-Chain Ransomware Attack
• 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 — REvil / Sodinokibi

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.