Rust Ransomware: Why Threat Actors Rewrote Their Payloads and What Defenders Must Do Differently

Rust was introduced in 2015 as a systems programming language offering C-level performance without C's memory safety hazards. It rapidly gained developer adoption — holding the title of most-loved programming language in Stack Overflow's annual developer survey for seven consecutive years from its release — and began appearing in high-profile projects from Microsoft, Google, the Linux kernel, and the Android operating system. Cybercriminals noticed. The same properties that made Rust attractive for systems software made it attractive for malware, and starting with the first major in-the-wild Rust ransomware in late 2021, the language has become an established and growing part of the threat landscape.

Why Threat Actors Chose Rust

The shift to Rust is driven by a cluster of advantages that collectively improve a ransomware operator's operational position. None of these advantages is exclusive to Rust — many are shared to varying degrees with Go, another language that saw significant malware adoption in the same period — but Rust offers a combination that has made it distinctively attractive to technically capable groups.

Signature evasion through language novelty

Security products accumulate detection signatures over time. The antivirus and EDR signatures tuned over years of analyzing malware written in C, C++, Delphi, and later Go are largely ineffective against Rust binaries because the compiled output looks structurally different. Trend Micro's researchers stated the assessment directly: attackers are shifting to Rust because modern versions lack the detection features found in ransomware written in Go. The same observation applies to C++ and Delphi-based detections — the entire signature ecosystem built for those languages provides minimal coverage for Rust. This evasion window narrows as vendors build Rust-specific signatures over time, but it gives early-adopter groups a meaningful lead period during which their payload encounters fewer detection events.

Compilation complexity as analysis friction

Rust's compilation model produces binaries that are dramatically more complex than equivalent programs written in other languages. Microsoft's Threat Intelligence Center demonstrated this with a controlled experiment: a simple downloader program written in both C++ and Rust. The C++ binary compiled to under 20 KB and contained fewer than 100 functions. The identical Rust binary compiled to over 3 MB and contained nearly 10,000 functions. The reason is static linking — Rust programs by default embed all their library dependencies directly into the executable, producing a single large binary rather than a smaller executable that calls shared system libraries at runtime. For a malware analyst, this means that most of what they see when they load a Rust binary in a disassembler is library code, not attacker-written logic. Separating the signal from the noise — finding the actual malicious code among thousands of standard library functions — is a time-consuming and technically demanding process that slows incident response and threat intelligence production.

Cross-platform execution from a single codebase

Rust's cross-compilation support allows a developer to write code once and compile it for Windows, Linux, and VMware ESXi with minimal modification. For ransomware operators, this is operationally significant. A threat group that previously needed separate development and maintenance efforts for Windows and Linux variants can now maintain a single codebase that targets all three platforms. As enterprise environments have shifted toward virtualization — where hundreds of Windows workloads may run as guests on a relatively small number of ESXi hypervisors — the ability to encrypt ESXi hosts directly has become a priority for ransomware groups seeking maximum impact per intrusion. Rust makes this cross-platform capability easier to achieve and maintain.

Memory safety prevents operational crashes

Ransomware must continue running successfully to generate ransom demands. A crash mid-encryption leaves files in a partially encrypted state, may not complete the ransom note deployment, and produces no revenue for the operator while still generating an incident for the victim. Rust's memory safety guarantees — its ownership model prevents use-after-free errors, buffer overflows, and the other memory corruption bugs that plague C and C++ programs — mean that Rust ransomware is significantly less likely to crash or exhibit anomalous behavior mid-execution. The Android development team, after transitioning to Rust, reported that memory safety vulnerabilities dropped from 76% of all vulnerabilities in 2019 to 24% by 2024. That same crash-resistance benefits malware: a Rust ransomware that completes its encryption run without crashing is more operationally reliable than a comparable C++ payload.

The Major Rust Ransomware Families

BlackCat / ALPHV (November 2021)

BlackCat — marketed on underground forums as ALPHV — was the first professional ransomware operation to deploy Rust in real-world attacks at scale. It emerged in November 2021 with Windows and Linux variants available from launch, ESXi support built in from early iterations, and a RaaS affiliate model offering 80–90% revenue splits. The operational sophistication of the code — use of the Zeroize crate to securely clear encryption secrets from memory, preventing key recovery from RAM captures; a JSON-encrypted configuration containing target credential lists and exclusion parameters; required access token authentication as an anti-sandbox measure — indicated a technically capable group, assessed by Recorded Future analysts as likely including former REvil operators.

BlackCat encrypted files using AES or ChaCha20 (operator-configurable), with the AES key itself encrypted by an RSA public key embedded in the configuration. On ESXi it shut down virtual machines via virsh before encrypting VM volumes. On Windows it deleted Volume Shadow Copies via vssadmin and wmic, disabled recovery in boot configuration, cleared Windows event logs, and used PsExec to propagate to additional hosts on the local network — all before the encryption pass. The group's triple extortion model — encrypt, threaten to leak, and launch DDoS attacks — was unusually aggressive, and the RaaS offered API documentation and a Python crawler, features no other group had provided at the time.

BlackCat breached over 200 organizations in 2022 alone. The FBI and DOJ disrupted the operation in December 2023, seizing its leak site and providing decryption keys to over 500 victims — saving approximately $68 million in ransom demands. BlackCat "unseized" its site the same day through what appeared to be a domain they had retained. By March 2024, the group had effectively shut down operations in what researchers characterized as either an exit scam or a response to ongoing law enforcement pressure, two months after the initial FBI disruption and weeks after the LockBit takedown.

Hive (June 2022)

Hive ransomware had operated since 2021 written in Go when, in June 2022, Microsoft documented a near-complete rewrite of the payload in Rust. The rewrite was not cosmetic — Hive added anti-analysis features, encoded its command-and-control communications differently, and gained the same cross-platform advantages as BlackCat. Hive became the second ransomware operation to make the Rust transition, following BlackCat's lead by approximately six months. The Rust rewrite made Hive significantly harder to detect and analyze than its Go predecessor, extending the operational window before AV vendors caught up with signatures for the new variant.

RansomExx2 (October 2022)

The RansomExx operation — active since 2018 and operated by the DefrayX threat group (also known as Hive0091) — released RansomExx2, a complete rewrite of the payload from C++ to Rust, in late 2022. The stated primary motivation was lower AV detection rates. RansomExx2's Linux variant replicated the functionality of its C++ predecessor — AES-256 file encryption with RSA key protection, command-line-specified target directory list — while gaining Rust's evasion and crash-resistance advantages. RansomExx has targeted government agencies, major manufacturers, and high-profile brands; its previous victims include GIGABYTE and Italian luxury brand Zegna.

Luna (July 2022)

Kaspersky documented Luna ransomware in July 2022 as a Rust-native payload targeting Windows, Linux, and ESXi simultaneously from a single codebase — a direct demonstration of Rust's cross-platform compilation advantage. Luna was relatively straightforward in its implementation compared to BlackCat, but its ability to target three operating system environments from one payload illustrated why groups were willing to invest the development effort of a Rust rewrite or fresh implementation.

Agenda / Qilin (December 2022)

The Agenda ransomware group — also tracked as Qilin — originally operated a Go-based payload targeting healthcare and education organizations. Trend Micro documented a Rust-variant release in December 2022, which expanded targeting to manufacturing and IT sectors. The Rust version introduced intermittent encryption as a detection evasion technique: rather than encrypting files completely, the payload encrypts only portions of each file. This produces the same denial-of-access effect for the victim while reducing the I/O activity and time signatures that full-file encryption generates — patterns that some behavioral detection tools use to identify ransomware in progress. Agenda's Rust variant could also disable Windows User Account Control (UAC), preventing other applications from executing with administrative privileges and narrowing the windows through which security tools could intervene.

The Analysis Problem: What a Rust Binary Looks Like to a Defender

Understanding why Rust ransomware is hard to analyze requires understanding what Rust compilation produces and what a malware analyst actually faces when they open a Rust binary in IDA Pro or Ghidra.

Traditional malware analysis relies on pattern recognition. An analyst loading a C++ binary sees a relatively small number of functions — perhaps a few hundred in a typical sample — and can quickly identify which ones relate to the malicious payload versus which ones are standard library calls. The signal-to-noise ratio is manageable. With a Rust binary, the analyst is confronted with thousands of functions — typically ten thousand or more in even a moderately complex sample — because every library dependency has been statically compiled in. The challenge is not reading any individual function: it is knowing which of the ten thousand functions to read. Spending time analyzing standard Rust library code rather than attacker-authored logic is not just inefficient; it actively delays incident response and threat intelligence production.

A second problem is symbol naming. Even in a debug build of a Rust binary, the function naming conventions differ enough from C/C++ patterns that automated signature matching tools tuned for traditional malware produce significantly fewer hits. In release-optimized builds — which is what deployed ransomware uses — many symbols are stripped entirely, leaving analysts with large volumes of anonymous functions to work through.

A third problem is the abstraction layers Rust introduces through its ownership, borrowing, and concurrency models. Functionality that a C developer would express in a few direct function calls may be expressed in Rust through a chain of trait implementations and generic specializations that compiles to the same machine code but presents much more complex decompiled output. Analysts trained on C/C++ reverse engineering need additional Rust-specific expertise to read the output fluently.

Microsoft's RIFT: A Tool Built to Address the Analysis Gap

In June 2025, Microsoft's Threat Intelligence Center released RIFT (Rust Identification and Function Tagging) as an open-source tool designed specifically to address the Rust binary analysis problem. RIFT is an IDA Pro plugin suite — supporting IDA Pro versions 9.0 and above — that automates the process of identifying library code in Rust binaries, allowing analysts to filter out the thousands of standard library functions and focus their attention on the code that was actually written by the malware author.

RIFT consists of three components working together in sequence. The RIFT Static Analyzer is an IDA Pro plugin that reads a Rust binary and extracts its embedded metadata: the exact Rust compiler version used, the Git commit hash of the compiler, the library dependencies statically compiled in, the target architecture, and the target operating system. This information — output as a JSON file — tells an analyst exactly what version of the Rust toolchain produced the binary, which is essential for the next step. The RIFT Generator is a Python script that takes this metadata, downloads the matching Rust compiler and library versions from the Rust toolchain infrastructure, and generates FLIRT signatures — Fast Library Identification and Recognition Technology, IDA Pro's native format for library function matching. It also runs binary diffing using Diaphora, a third-party tool, to catch functions that FLIRT signatures miss because the code was slightly modified from the original library version. The RIFT Diff Applier is a second IDA Pro plugin that applies the generated signatures and diffing results back into the IDA workspace, annotating functions as library code so analysts can immediately see which functions to skip and which to investigate.

RIFT's two-pass approach handles the practical limitations of each technique. FLIRT signatures are fast and produce very few false positives, but they only match functions that are essentially identical to the original library code — if a developer made even small changes to a library function, the signature will not match. Binary diffing fills this gap by comparing against the compiled library at a structural level rather than an exact byte-match level, but it is computationally expensive and can take hours on a large binary. Using FLIRT first and diffing second produces the best balance of speed and coverage for the analyst.

What Defenders Must Do Differently

The Rust shift demands specific adjustments across detection, response, and analysis functions. Security teams that have not audited their defenses against Rust-compiled malware should treat that as an open gap.

1. Shift detection from signatures to behavior. Static signature-based detection has an inherent lag against any new language or rewritten payload, and that lag is longer for Rust because the compiled output is structurally distinct from C/C++ and Go. Detection strategies that depend primarily on file hash matching or static signatures for known ransomware families will miss Rust variants, particularly new families or freshly compiled versions of known groups. Behavioral detection — identifying ransomware by what it does rather than what it looks like — is the correct architectural response. Monitoring for high-volume file modification events, shadow copy deletion via vssadmin or wmic, boot configuration changes via bcdedit, event log clearing, and UAC bypass attempts provides coverage that is language-agnostic. A Rust binary that deletes Volume Shadow Copies triggers the same behavioral alert as a C++ binary doing the same thing.
2. Instrument EDR telemetry to catch cross-platform targeting attempts. Rust ransomware frequently targets Linux and ESXi hosts simultaneously with Windows endpoints. Many EDR deployments prioritize Windows coverage and have incomplete visibility into Linux servers and ESXi hypervisors. Gaps in Linux EDR coverage are gaps that Rust ransomware families specifically exploit — Luna, BlackCat, and Agenda all targeted Linux hosts, and BlackCat and Luna targeted ESXi directly. Inventory which hosts in the environment have EDR coverage, and prioritize filling gaps on Linux systems and hypervisors that host critical workloads.
3. Build Rust analysis capability in the security operations team. The skills and tooling required to reverse-engineer Rust malware are meaningfully different from those for C++ or Go malware. Teams that currently have no Rust-trained analysts, no FLIRT signatures for Rust libraries, and no integration of tools like RIFT into their analysis workflow will be significantly slower to triage and respond to Rust-based incidents. This is not an abstract future risk — Rust ransomware has been actively deployed in attacks since 2021 and is documented in incident response cases. Building this capability proactively, rather than first encountering it during an active incident, provides a meaningful response time advantage.
4. Treat large, statically-linked binaries as warranting deeper inspection. One artifact of Rust's static linking is that Rust binaries are substantially larger than equivalent C++ binaries — often 2–5 MB for what would be a 20–50 KB C++ file. This size differential is a passive indicator: an executable of unusual size relative to its claimed function should receive elevated scrutiny, particularly in initial access and lateral movement contexts. This heuristic is imperfect — many legitimate applications are large — but combined with other indicators it can prioritize analyst attention toward samples that warrant the additional effort Rust analysis requires.
5. Audit backup integrity and ESXi snapshot protection. Rust ransomware families with ESXi support shut down virtual machines via virsh or hypervisor management interfaces before encrypting VM volumes. Backups of VMs stored on the same datastore as the live VMs are encrypted in the same pass. Resilient recovery from a Rust ransomware incident targeting virtualized infrastructure requires backups that are genuinely isolated from the hypervisor — immutable object storage with object-lock enabled, or air-gapped tape, or off-site backup systems that the ransomware operator cannot reach from a compromised hypervisor management interface. The standard advice about maintaining backups does not protect against ESXi-targeting ransomware unless those backups are architecturally separated from the environment the ransomware can reach.
6. Apply FLIRT signatures for Rust library code to your malware analysis workflow. For teams with malware analysis functions, integrating RIFT or equivalent Rust library signature generation into the standard analysis process removes a significant friction point. Analysts who encounter a Rust binary without pre-generated FLIRT signatures for the relevant compiler and library versions face hours of additional work separating library code from payload logic. Having a documented process for generating and applying these signatures — and incorporating RIFT into the standard toolkit — reduces triage time for Rust samples from hours to minutes for the library-identification phase.

The Trajectory: Where Rust Malware Is Heading

The trend line is clear and accelerating. What began with BlackCat in late 2021 as a single technically sophisticated group's design choice has become a pattern adopted by multiple major ransomware operations and, as Microsoft explicitly confirmed, nation-state actors as well. As the broader developer ecosystem continues migrating toward Rust — encouraged by both CISA's memory-safe language guidance and the growth of the Rust standard library and crate ecosystem — the pool of developers with Rust skills expands, which in turn expands the pool of threat actors who can use it.

The evasion advantage of Rust against static signatures narrows over time as security vendors build out Rust-specific detection capabilities. This is the same dynamic that played out with Go malware, which initially evaded many detections and over several years acquired reasonably broad coverage. The current state of Rust detection is somewhere early on that maturation curve — better than it was in 2022 but not yet as mature as Go or C++ coverage. Groups that have already adopted Rust have front-loaded the evasion benefit; groups considering adoption have a smaller window of advantage than BlackCat enjoyed in 2021.

What does not narrow over time is the cross-platform capability advantage. Rust's cross-compilation support is a permanent structural feature of the language, not a temporary gap in security tooling. Ransomware groups that can target Windows, Linux, and ESXi from a single codebase will continue to have an operational efficiency advantage over groups maintaining separate platform-specific payloads. And the analysis complexity advantage — the sheer volume of library code embedded in Rust binaries — will remain a genuine friction point for analysts even as tooling like RIFT reduces it. The language's design creates inherent complexity in its binaries that is not going away.

Key Takeaways

1. The Rust shift began in 2021 and is now established across multiple major ransomware families and nation-state actors. BlackCat, Hive, RansomExx, Luna, and Agenda/Qilin have all deployed Rust variants. This is not a future trend — it is an active reality that security teams need to have accounted for in their detection and response capabilities.
2. Four core advantages drive Rust adoption: signature evasion, analysis complexity, cross-platform targeting, and operational stability. Each of these advantages individually would be a meaningful driver. Together they create a compelling case for technically capable ransomware groups to invest in Rust development or rewriting, and that investment is being made.
3. Static signature detection has a structural lag problem against Rust payloads. Behavioral detection is the correct architectural response — monitoring for what ransomware does (VSS deletion, file mass-modification, UAC bypass, boot configuration changes) rather than what it looks like produces language-agnostic coverage that works against Rust variants of known families and against new Rust families simultaneously.
4. Microsoft's RIFT tool, released June 2025, directly addresses the Rust binary analysis problem. By automating FLIRT signature generation from the compiler and library versions embedded in a Rust binary, RIFT allows analysts to label over 90% of library functions in a single pass and focus on attacker-authored code. Security teams with malware analysis functions should evaluate integrating RIFT into their standard workflow.
5. ESXi and Linux coverage gaps are specifically exploited by Rust ransomware families. The cross-platform capability that Rust enables is not theoretical — BlackCat, Luna, and Agenda all actively targeted Linux and ESXi. Organizations that have strong Windows EDR coverage but incomplete Linux and hypervisor visibility have gaps that Rust ransomware operators have demonstrated they will use.

The programming language a threat actor uses does not change the fundamental nature of the threat — ransomware still needs to gain access, move laterally, and encrypt or exfiltrate data before it becomes a ransom demand. What it changes is the specific tooling and skills required to detect it during execution, analyze it after the fact, and build effective signatures against it. Rust demands adjustment in all three of those areas, and the groups that adopted it earliest have consistently demonstrated they understood that advantage before the security community caught up to it.