Crafting malware with modern metals. [Research Saturday]

Summary

Podcast Summary: CyberWire Daily – "Crafting Malware with Modern Metals" [Research Saturday]

Title: Crafting Malware with Modern Metals
Host: Dave Bittner
Guest: Nick Cerny, Security Consultant at Bishop Fox
Release Date: April 19, 2025

---

Introduction

In the April 19, 2025 episode of CyberWire Daily titled "Crafting Malware with Modern Metals," host Dave Bittner engages in an illuminating conversation with Nick Cerny, a security consultant at Bishop Fox. This episode delves into the evolving landscape of malware development, specifically focusing on the adoption of modern programming languages like Rust and their implications for cybersecurity.

---

Rust: The New Frontier in Malware Development

Nick Cerny introduces the primary subject by highlighting the shift from traditional C-based languages to modern alternatives such as Rust for malware creation.

[01:23] Nick Cerny: "A lot of modern malware, or just malware in general, was traditionally written in the C languages. However, recently there's been an emerging trend where threat actors have been using other languages like D, Nim, Dolang, and Rust."

Cerny explains his personal inclination towards Rust due to its combination of low-level capabilities and advanced features like memory safety guarantees.

[02:00] Nick Cerny: "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."

---

Recreating Malware Techniques in Rust: Challenges and Surprises

The discussion progresses to Cerny's research, where he recreated common malware techniques using Rust. He outlines the challenges encountered, particularly when interfacing Rust with Windows APIs through Microsoft's Windows Crate.

[02:36] Nick Cerny: "One of the challenges I found with developing Rust malware as opposed to using a traditional language like C, is when using the Windows Crate... it's a little bit more challenging than just using a traditional or just using the traditional C libraries because there are some differences in calling those APIs as opposed to using the Rust like wrapper or binding to that API."

---

Rust's Safety Features and Their Impact on Malware Detection

A significant portion of the conversation centers on how Rust's inherent safety features can paradoxically complicate malware detection efforts. Cerny contrasts Rust's memory management with that of C, emphasizing Rust's ownership model that eliminates the need for manual memory deallocation.

[03:30] Nick Cerny: "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... 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."

He further explains how traditional reverse engineering tools like Ghidra and IDA Pro, designed for C, struggle with Rust binaries, resulting in "garbled or nonsensical information" that hampers analysis.

[06:46] Dave Bittner: "I see. So you sort of have to do your own kind of translation layer as you're looking through that Pseudo C, right?"
[06:57] Nick Cerny: "Yeah. And a lot of it really just doesn't make sense... it's going to produce a lot of garbled or nonsensical information that makes it a little bit more difficult to read the pseudocode."

---

Implications for Security Teams: Detection and Response

Bittner probes into how the shift to Rust might affect security teams' capabilities to detect and respond to threats. Cerny posits that while dedicated reverse engineers will eventually decode Rust-based malware, the initial hurdles imposed by Rust's structure can delay detection.

[09:44] Nick Cerny: "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."

Regarding endpoint detection and response (EDR) solutions, Cerny suggests that while Rust could pose challenges, the effectiveness largely depends on the sophistication of these security tools.

[10:50] Nick Cerny: "It really depends on how established or sophisticated the antivirus solution or EDR solution is or how adept it is at detecting malicious behavior of a process or detecting signatures."

---

Skill Level and Adaptability of Malware Authors

The conversation shifts to the expertise required for malware authors to adopt Rust. Cerny asserts that malware developers with a strong background in C can transition to Rust without significant difficulty, given their understanding of memory management and modern evasion techniques.

[11:10] Nick Cerny: "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."

He identifies Rust's ownership concept as the primary learning curve but acknowledges that once mastered, Rust becomes a powerful tool for developing sophisticated malware.

---

Potential Benefits of Rust for Defensive Tools

Bittner inquires whether Rust's features could be advantageous for defensive cybersecurity tools. Cerny reflects that while Rust could be beneficial in developing more robust decompilers, the core techniques for EDR solutions remain consistent irrespective of the programming language used.

[12:16] Nick Cerny: "Maybe if you were going to write like a more comprehensive Rust decompiler, that would be helpful."

He emphasizes that EDR capabilities like hooking Windows APIs and monitoring malicious payloads are language-agnostic.

---

Key Takeaways and Conclusions

Cerny shares his primary insights from the research, emphasizing the ease with which Rust-based malware can evade traditional signature-based antivirus solutions. He highlights the advantage this presents for red teams in developing custom tooling that mimics real-world adversaries more effectively.

[13:45] Nick Cerny: "Developing malware is very advantageous for red teams because you're essentially developing tooling that hasn't been signatured yet by antivirus endpoint detection response solutions... make my red team more effective."

---

Conclusion

The episode concludes with Cerny's reflections on the evolving malware landscape and the increasing adoption of modern programming languages like Rust. The discussion underscores the ongoing arms race between malware developers and defenders, highlighting the need for adaptive and sophisticated security measures to keep pace with emerging threats.

---

Additional Information

For listeners interested in exploring the research further, links are provided in the show notes. Feedback on the podcast is encouraged to ensure the delivery of pertinent cybersecurity insights.

---

Notable Quotes:

• Nick Cerny [02:00]: "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."
• Nick Cerny [03:30]: "Rust has a unique concept called ownership, which is part of the reason why I liked Rust as opposed to C..."
• Nick Cerny [09:44]: "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."
• Nick Cerny [13:45]: "Developing malware is very advantageous for red teams because you're essentially developing tooling that hasn't been signatured yet by antivirus endpoint detection response solutions..."

---

This comprehensive summary encapsulates the critical discussions and insights shared in the "Crafting Malware with Modern Metals" episode, providing valuable perspectives for cybersecurity professionals and enthusiasts alike.

Transcript

[Nick Cerny]

You're listening to the Cyberwire Network, powered by N2K.

[Dave Bittner]

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@vanguard jobs.com hello everyone and welcome to the Cyberwires Research Saturday. I'm Dave Bittin 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 our rapidly evolving cyberspace. Thanks for joining us.

[Nick Cerny]

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, Dolang, and Rust.

[Dave Bittner]

That's Nick Cerny, security consultant at Bishop Fox. The research we're discussing today is titled Rust for Malware Development.

[Nick Cerny]

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.

[Dave Bittner]

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?

[Nick Cerny]

Yeah, so one of the challenges I found with developing Rust malware as opposed to using a traditional language like C, is when using the Windows Crate, which is provided by Microsoft. These are this is basically a library that binds or 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 C libraries because there are some differences in calling those APIs as opposed to using the Rust like wrapper or binding to that API?

[Dave Bittner]

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?

[Nick Cerny]

So before we get into that, I just want to talk quickly about like status quo reverse engineering tools. Okay, so Ghidra 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 deprogram into sudo 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 Ghidra 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. 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 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. 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 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 Rust. So you don't have to worry about freeing up memory or deallocating memory. Rust will do it automatically. That's why it gets difficult when you decompile a Rust program, because it's going to decompile the sudo C and pseudo C doesn't have these kinds of memory management concepts.

[Dave Bittner]

I see. So you sort of have to do your own kind of translation layer as you're looking through that Pseudo C, right?

[Nick Cerny]

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. So if you look at the decompiled Rust program, you can still see calls to some Windows APIs and stuff. So you can Kind of get some sort of sense of what the Rust program is doing if you're a reverse engineer. But also, I mean, this is something I developed with no like 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.

[Dave Bittner]

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. Varonis AI powered data security platform secures your data at scale across las SaaS and hybrid cloud environments. Join thousands of organizations who trust Varonis to keep their data safe. Get a free data risk [e-mail] what's the common denominator in security incidents? Escalations and lateral movement. When a privileged account is compromised, attackers can seize control of critical assets with bad directory hygiene and years of technical debt. Identity attack paths are easy targets for threat actors to exploit, but hard for defenders to detect. This poses risk in active directory, entra ID and hybrid configurations. Identity leaders are reducing such risks with attack paths path management. You can learn how attack path management is connecting identity and security teams while reducing risk with Bloodhound Enterprise powered by SpectreOps. Head to SpectreOps IO today to learn more. SpectreOps see your attack paths the way adversaries do. 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?

[Nick Cerny]

That's a great question. I would say if you have a dedicated malware reverse engineer, they're always going to figure out what the malware is doing, no matter what. As a malware author, you can take steps to make it more difficult.

[Dave Bittner]

Or.

[Nick Cerny]

Make it more time consuming. But I believe, like if you're a dedicated and 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 like 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 antivirus solution or EDR solution is or how adept it is at detecting malicious behavior of a process or detecting signatures. Kind of depends on that.

[Dave Bittner]

So does this shift towards languages like Rust? I think people look at these as being more Modern languages, I've 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?

[Nick Cerny]

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 like memory is managed in Rust. Understanding ownership is the 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 take up, especially if they are coming from a background where they understand modern evasion techniques and, you know, I guess the theory behind malware development.

[Dave Bittner]

Yeah, well, I mean, let's flip the coin here. I mean, are there ways that defenders can also benefit from Rust's capabilities in their own tools?

[Nick Cerny]

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.

[Dave Bittner]

Right.

[Nick Cerny]

Maybe if you were going to write like a more comprehensive Rust decompiler, that would be helpful. But for something like an edr, I think the techniques kind of remain the same. 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 rusty compiler could be something interesting.

[Dave Bittner]

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?

[Nick Cerny]

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 an endpoint detection response solution. A lot of antivirus software, they're signature based, so, you know, they kind of depend on malware that's already been signatured to kind of detect and stop that malware. Obviously, EDRs are a little bit harder to bypass because they do heuristic analysis. You know, if your malware is doing recalling 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 signatured yet by antivirus endpoint detection response solutions, as opposed to using something open source or closed source, which might be picked up better in buy 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.

[Dave Bittner]

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 cyberwire2k.com this episode was produced by Liz Stokes, were mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Ibin, Peter Kilpe is our publisher and I'm Dave Bittner. Thanks for listening. We'll see you back here next time.