CyberWire Daily - Crafting malware with modern metals. [Research Saturday]

Episode Date: April 19, 2025

This week, we are joined by Nick Cerne, Security Consultant from Bishop Fox, to discuss "Rust for Malware Development." In pursuit of simulating real adversarial tactics, this blog explores the use of Rust for malware development, contrasting it with C in terms of binary complexity, detection evasion, and reverse engineering challenges. The author demonstrates how Rust's inherent anti-analysis traits and memory safety features can create more evasive malware tooling, including a simple dropper that injects shellcode using lesser-known Windows APIs. Through hands-on comparisons and decompiled output analysis, the post highlights Rust’s growing appeal in offensive security while noting key OPSEC considerations and tooling limitations. The research can be found here: Rust for Malware Development Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the CyberWire Network powered by N2K. Looking for a career where innovation meets impact? Vanguard's technology team is shaping the future of financial services by solving complex challenges with cutting-edge solutions. Whether you're passionate about AI, cybersecurity, or cloud computing, Vanguard offers a dynamic and collaborative environment where your ideas drive change. With career growth opportunities and a focus on work-life balance, you'll have the flexibility to thrive both professionally and personally. Explore open cybersecurity

and technology roles today at Vanguardjobs.com. Hello everyone and welcome to the CyberWires Research Saturday. I'm Dave Bittner and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems and protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. A lot of modern malware, or just malware in general, was traditionally written in the C languages. Yeah.

However, recently, there's been an emerging trend where threat actors have been using other languages like D, NIM, Dolan, and Rust. That's Nick Cerny, security consultant at Bishop Fox. The research we're discussing today is titled Rust for Malware Development. And so Rust kind of appealed to me because it was a low-level language like C, but it also had some kind of cool features like memory safety guarantees and other nuances that I

found interesting. So that's kind of why I picked Rust over a traditional language like C or other programming languages. I see. Well, in your research, you recreated several common malware techniques using Rust. What were some of the challenges or surprises that you encountered during that process? Yeah, so one of the challenges I found with developing a Rust malware as opposed to using a traditional language like C is when using the Windows Crate, which is provided by Microsoft, this is basically a library that provides bindings

to Windows APIs, which are developed in C. And this is a little bit more challenging than just using a traditional, or just using the traditional seed libraries because there are some differences in calling those APIs as opposed to using the Rust-like wrapper or binding to that API. One of the things you mentioned in the report is that Rust's safety features can make detection more difficult, somewhat ironically. Can you explain how that works and why that matters for defenders? So before we get into that, I just want to talk quickly about like status quo reverse

engineering tools. So Gidra and IDA Pro are probably the most popular or one of the most popular sets of tools used in reverse engineering malware and they were kind of developed to decompile C applications. So whenever you decompile a program it's going to decompile the program into pseudo C and this is where it gets kind of difficult, because there's a lot of intricate differences between Rust and C, especially, as you've mentioned, with how it manages memory and also how the compiler optimizes code during compilation.

So due to those intricate differences, when you decompile a Rust program in Gidra or Ida Pro, it's going to produce a lot of garbled or nonsensical information that makes it a little bit more difficult to read the pseudocode. And I guess I can also dive into, quickly, one of the main differences in how memory is managed between C and Rust.

Yeah. So, Rust has a unique concept called ownership, which is part of the reason why I liked Rust as opposed to C because I thought it was a really cool concept. So, in traditional C, when you want to, I guess, allocate memory, the end user has to explicitly call APIs to allocate and deallocate memory. And you can run into memory management issues if you forget to free up the memory that is no longer being used. So that affects C explicitly. There's also other languages like Golang where you have garbage collectors, which will go

through your running program, look for any memory that is no longer being used and reclaim that memory. Rust is different because it introduces this concept called ownership. And it doesn't use a garbage collector or require the user to explicitly free up memory. It basically does all of that automatically. I think it would help to give an example. So let's say you create a variable in Rust and you assign a value to that variable. There is something in

Rust called scope where I mean a scope is basically just curly brackets. So you define this variable in curly brackets. Once you exit that scope, that variable and that value, they get dropped automatically by that variable and that value, they get dropped automatically by Rust. So you don't have to worry about freeing up the memory or deallocating memory. Rust will do it automatically. So that's why it gets kind of difficult when you decompile a Rust program, because it's going to decompile the Pseudo-C and Pseudo-C doesn't have these kinds of memory management

concepts. I see. So you sort of have to do your own kind of translation layer as you're looking through that Pseudo-C, right? Yeah. And a lot of it really just doesn't make sense. You know, there's bits and pieces you can pick out like symbols. If you look at the decompiled Rust program,

you can still see calls to some Windows APIs and stuff. So you can get some sense of what the Rust program is doing if you're a reverse engineer. But also, this is something I developed with no code obfuscation or anything. So you could make it a lot more difficult to analyze that Rust program. Yeah, it's certainly more difficult to understand than the decompiled C program, which is also in the blog post. C program, which is also in the blog post.

We'll be right back. Bad actors don't break in, they log in. Attackers use stolen credentials in nearly nine out of 10 data breaches. Once inside, they're after one thing, your data. out of 10 data breaches, once inside, thereafter one thing, your data. Varonis's AI-powered data security platform secures your data at scale. Across LAS, SAS, and hybrid cloud environments, join thousands of organizations who trust Varonis to keep their data safe. Get a free data risk assessment at Vonis.com. Cyber threats are evolving every second and staying ahead is more than just a challenge,

it's a necessity. That's why we're thrilled to partner with ThreatLocker, a cybersecurity solution trusted by businesses worldwide. ThreatLocker is a full suite of solutions designed to give you total control, stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely. Visit ThreatLocker.com today to see how a default deny approach can keep your company safe and compliant.

Well, how might the use of Rust affect how security teams detect and respond to threats? I mean, are the tools that we're using currently, are they prepared for, let's say, a shift? That's a great question. I would say, you know, if you have a dedicated malware reverse engineer, they're always going to figure out what the malware is doing no matter what. You can, as a malware author, you can take steps to make it more difficult or make it more time consuming. But I believe if you're a dedicated malware reverse engineer, you're going to figure out what the program is doing no matter what language you choose.

Now, going to endpoint detection or response solutions or antivirus solutions, yeah, it certainly could be more difficult to pick up malware that's developed in these languages. But I would say it really depends on how established or sophisticated the anti-virus solution or EDR solution is is or how adaptive is that detecting you know malicious behavior of a process or detecting signatures kind of depends on that. So does this shift towards languages like Rust? I think

people look at these as being more modern languages. I have seen people you know kind of call them more legitimate languages than some of the older ones. Do you think this changes the profile or the skill level required for your average malware author? Assuming your average malware author has a pretty good understanding of C and how memory works, I wouldn't say it would be terribly difficult for malware

authors to pick up Rust as a new language. I think the most difficult part about learning Rust is understanding ownership. That concept we discussed earlier on managing how memories manage in Rust. Understanding ownership is one of the most significant differences in Rust that separates it from other programming languages. So I'd say like once malware authors gain a understanding of how that works, it really shouldn't be that difficult to pick up, especially if they are coming from a background where they understand modern invasion techniques and, you know, I guess the theory behind malware development. Yeah.

Well, I mean, let's flip the coin here. Are there ways that defenders can also benefit from Rust's capabilities in their own tools? I haven't really thought about it from a defender's perspective. Yeah. I would say when it comes to detecting malware, I would say it doesn't really matter so much what language you choose to develop, like an endpoint detection and response solution. Right. Maybe if you were going to write a more comprehensive Rust decompiler, that would be helpful.

But for something like an EDR, I think the techniques kind of remain the same. Like these EDR solutions are still going to hook the Windows native API and look for malicious arguments. They can search through the memory of a process and look for malicious payloads, check Windows events for any malicious activity. I don't think any of that will really be different across languages. But if you wanted something more comprehensive for decompiling Rust programs,

maybe, or reverse engineering Rust programs, I think maybe a better Rust decompiler could be something interesting. Gotcha. Well, what are your takeaways here from this research, from this exercise? What do you hope people take away from it, having read it? I think one thing, or one of my biggest takeaways is kind of how easy it was to develop malware that bypasses like Windows Defender, for instance, or endpoint detection or response solution. A lot of antivirus software, they're signature based. So they depend on malware that's already been signature to detect and stop that malware.

Obviously, EDRs are a little bit harder to bypass because they do heuristic analysis. If your malware is doing or calling weird Windows APIs, it's going to pick up on that. Developing malware is very advantageous for red teams because you're essentially developing tooling that hasn't been signetured yet by anti-virus endpoint detection and response solutions, as opposed to using something open source or closed source, which might be picked up better by those solutions. So I think that's another huge draw to malware development in general and how it can make your red team more effective.

So I think that was one of my biggest takeaways was, I guess, not having to rely so much on open source tooling or closed source tooling for that manner, as opposed to being able to develop my own custom tooling to more effectively emulate a real adversary. Our thanks to Nick Cerny from Bishop Fox for joining us. The research is titled Rust for Malware Development. We'll have a link in the show notes. And that's Research Saturday brought to you by N2K Cyberwire. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you like our show, please share a rating

and review in your favorite podcast app. Please also fill out the survey in the show notes or send an email to cyberwire at n2k.com. This episode was produced by Liz Stokes, we're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Iben, Peter Kilpey is our publisher, and I'm Dave Bittner. Thanks for listening. We'll see you back here next time. you