Summary
Rust has quickly emerged as a popular language for malware development. Threat actors are adopting Rust to create cross-platform, highly optimized malware that can evade traditional detection and complicate analysis.
There are several notable Rust-based malware families such as BlackCat, RustyBuer, Ficker/Fickle, Hive ransomware, and P2PInfect (worm) that I have researched in order to gain a better understanding of what can be done to tackle malware compiled via Rust.
An aside:
An increased usage of Rust is being seen due to the aforementioned reasons but I’m also hearing a lot more discussion of Rust due to recent initiatives to move away from “memory unsafe” languages. There are rumors that there is mandate to stop using C++ and to use Rust instead.
However, I have not found this to be a confirmed statement and instead there appears to be strong suggestions to move away from C++ for writing critical infrastructure software. The Cybersecurity and Infrastructure Security Agency (CISA) has emphasized the importance of memory safety in software development.
In late 2024, CISA urged software manufacturers to publish a memory safety roadmap by January 1, 2026, detailing plans to eliminate memory safety vulnerabilities. This initiative encourages the adoption of memory-safe programming languages, such as Rust, Java, C#, Go, Python, and Swift, but does not specifically mandate the use of Rust or set a deadline for its adoption.
Reference: https://runsafesecurity.com/blog/cisa-memory-safety-ot-leaders/
Rise of Rust malware
The rise of Rust malware is in part due to a lack of signatures and heuristics for detecting them.
There has been a draw to Rust for a number of reasons:
- Fewer detections in sandboxes due to fewer signatures for Rust binaries.
- Cross-platform capabilities allowing for easier compilation of binaries for Windows, Linux, and macOS with minimal changes.
- Performance and modern features for memory safety and an abundance of crates to allow malware authors to write complex functionality more quickly.
For these reasons, there are cases where existing malware is simply re-written in Rust to achieve the desired results of bypassing sandboxes and EDRs. One such example is the Buer loader which was ported to Rust and allowed for bypassing the existing Yara rules and other signatures that detected the C version. It feels like we are still in the earlier phase of Rust for malware as reliance on having a lack of signatures as the evasion technique will only last so long.
Notable malware families
The following list of malware families are ones that have been written or re-written/ported to Rust (not a complete list). I have collected some key findings on each one and will pull each one into IDA Pro (in subsequent posts) to analyze further.
BlackCat (ALPHV) Ransomware
- This is one of the earliest ransomware families written fully in Rust.
- The malware is compiled to multiple architectures allowing the infection of Windows and Unix-based OS’s.
- The Rust-based implementation includes advanced features like different encryption modes and an “access token” mechanism for authentication of the ransomware binary.
- Challenges
- Binary is statically linked with Rust standard library code.
- File system and threading logic are performed through libraries via crates and are very different from how we are used to seeing it in C++.
- Whether or not some Rust symbols are left in the binary can determine how difficult it may be to understand.
- NOTE: You may find strings that indicate the Rust version number used to build the binary. This is useful if you plan to build FLIRT signatures for that specific version of Rust.
RustyBuer (malware loader)
- RustyBuer is a variant of the Buer malware loader completely rewritten in Rust (original Buer was in C).
- This marked one of the first instances of a mainstream malware family switching languages purely for evasion.
- By using Rust, the malware authors broke many signatures that endpoint solutions had for Buer.
Ficker (Information stealer)
- Its creator (@ficker) explicitly chose Rust to make analysis harder and to differentiate from other stealers like Raccoon or AgentTesla.
- The Rust implementation means these stealers come as optimized native binaries that don’t resemble the more common C# or C++ stealers.
- The core logic (parsing browser SQLite databases, reading files, etc.) is embedded in layers of Rust std library calls.
- NOTE:
- When reversing Rust stealers, one effective technique is to search the binary strings for signs of Rust crates or error messages.
- In Ficker’s case, you can identify strings associated with its keylogging and crypto wallet theft routines, then cross-reference those in IDA to locate the relevant functions.
Hive, Luna, and Agenda
- Following BlackCat, other ransomware groups jumped on Rust for its cross-platform potential. Hive ransomware was originally written in Golang and then introduced a Rust variant in 2022 to create “Hive 2.0”.
- Around the same time, a new group called Luna appeared, exclusively using a Rust-based ransomware that runs on Windows, Linux, and ESXi hosts.
- Agenda (renamed “Qilin”) also reportedly refactored in Rust for certain campaigns.
P2PInfect (worm)
- P2PInfect is a peer-to-peer self-propagating worm discovered in 2023, written in Rust.
- It targets Redis database servers on both Linux and Windows, exploiting a Lua sandbox escape vulnerability (CVE-2022-0543) to infect the system.
- Known to later deploy payloads like crypto miners and ransomware.
- P2PInfect’s complexity comes from its network capabilities and use of Rust’s concurrency (this means reverse engineers may encounter async state machine functions and polling loops rather than straightforward sequential code).
- P2PInfect has both exploit code (targeting Redis) and P2P protocol code intertwined, which can be a lot to analyze.
Conclusion
Rust-based malware is no longer a rarity and spans ransomware, stealers, loaders, and worms. These threats leverage Rust’s strengths (performance, cross-platform support, modern libraries) to enhance their payloads and evade defenses. For reverse engineers, this means encountering binaries that are technically challenging: they tend to be bloated with library code, aggressively optimized, and different in structure from equivalent C/C++ malware.
However, by studying documented cases and applying tailored reversing techniques, you can demystify Rust binaries. Key strategies include recognizing Rust-specific patterns (monomorphized generics, inlined functions, async state machines), using tools like IDA Pro’s Rust support to our advantage, and isolating the malware’s unique logic from the noise.
I will be spending more time with each of the above malware families and update the bottom of this post to links to the deeper dive into each one and what I found as my key takeaways.