Copy, Paste Persist: Inside the .NET Malware Gene Pool
Jonathan Peters (Malware Analyst and Threat Researcher · Nextron Systems)
Area41 2026 · Day 2 · Main Stage
Overview
In the rapidly evolving landscape of cybersecurity, understanding the origins and relationships between malware families is paramount for effective defense. Jonathan Peters, a Malware Analyst and Threat Researcher at Nextron Systems, delivered a compelling talk at Area41 titled "Copy, Paste Persist: Inside the .NET Malware Gene Pool," which meticulously dissects the pervasive trend of code reuse within the .NET malware ecosystem. The presentation highlights how many seemingly distinct and "new" threats are, in fact, derivatives of older, often open-source, projects, illustrating a significant lack of originality among many cybercriminals.

Key moments
- 0:00 Introduction: .NET malware's copy-paste problem
- 4:00 Quasar RAT: The open-source ancestor of many malwares
- 6:00 Pulsar RAT: Quasar's commercial, more malicious continuation
- 9:00 AsyncRAT's origins and its heavy borrowing from Quasar
- 13:00 Leveraging code reuse for effective malware detection
- 16:00 Examples of rules targeting specific malicious implementations
- 22:00 Detection results: High volume of unique samples matched
- 27:00 Q&A: Surprising false positives from unusual software
Copy, Paste Persist: Inside the .NET Malware Gene Pool
Speakers: Jonathan Peters, Malware Analyst and Threat Researcher, Nextron Systems
Conference: Area41
YouTube: https://www.youtube.com/watch?v=FUN227pF-gg
Overview
In the rapidly evolving landscape of cybersecurity, understanding the origins and relationships between malware families is paramount for effective defense. Jonathan Peters, a Malware Analyst and Threat Researcher at Nextron Systems, delivered a compelling talk at Area41 titled "Copy, Paste Persist: Inside the .NET Malware Gene Pool," which meticulously dissects the pervasive trend of code reuse within the .NET malware ecosystem. The presentation highlights how many seemingly distinct and "new" threats are, in fact, derivatives of older, often open-source, projects, illustrating a significant lack of originality among many cybercriminals.
Peters' research, leveraging extensive data from VirusTotal, reveals a deep interconnectedness, exposing that a vast number of commodity crimeware families—ranging from info stealers and Remote Access Trojans (RATs) to keyloggers and loaders—share common genetic material. This talk is crucial for defenders as it shifts the paradigm from reactive, highly specific detections to proactive, broad-based strategies. By understanding these underlying lineages, security professionals can develop more robust and efficient detection mechanisms that target core functionalities rather than superficial variations.
The implications of this widespread code reuse are profound. It not only streamlines the development process for malicious actors, allowing them to rapidly deploy new variants, but it also presents a unique opportunity for defenders. Peters argues that by recognizing the shared ancestry of these threats, the security community can develop more generalizable detection rules, saving significant time and resources. This analytical approach challenges the conventional wisdom of treating each new variant as a novel threat, instead advocating for a deeper understanding of the foundational components that persist across the malware "gene pool."
Background
▶ Watch: Introduction: .NET malware's copy-paste problem (0:00)
The .NET ecosystem has become a fertile ground for commodity crimeware, largely due to its ease of development and deployment. Malware authors, often lacking sophisticated programming skills, find .NET an attractive platform because it simplifies complex tasks like dependency management through services like NuGet. This accessibility has led to a proliferation of readily available tools, both legitimate and malicious, that can be compiled and deployed with minimal effort. The landscape is dominated by familiar names such as Async RAT, Quasar RAT, and RedLine Stealer, which frequently appear in threat reports.
Jonathan Peters' journey into this topic began while developing detection rules for Nextron Systems' Thor Scanner and Sigma standard. Tasked with creating specific rules for various .NET malware families, he observed an unexpected and significant overlap in codebases between ostensibly unrelated threats. This anomaly prompted a deeper investigation into the underlying connections, revealing that many "different" malware families shared identical or near-identical code segments. This insight formed the basis of his research, aiming to uncover the true lineages of these prevalent threats.
The data for this extensive analysis was sourced through Nextron Systems' partnership with VirusTotal, a leading aggregator of malware samples. By leveraging access to VirusTotal's vast repository of matches and samples, Peters and his team could systematically scan and analyze a multitude of binaries against their rule sets. This process allowed them to identify patterns, evaluate rule quality, and, crucially, discover generic detections that could flag new or previously unseen malware. The initial observation of code overlap, initially a quality assurance challenge, transformed into a foundational discovery about the structure of the .NET malware scene.
Key Findings
▶ Watch: Pulsar RAT: Quasar's commercial, more malicious continuation (6:00)
The central finding of Peters' research is the pervasive influence of Quasar RAT, an open-source Remote Access Trojan, which he aptly terms the "ancestor" of much of the modern .NET crimeware. Published approximately nine years ago and last updated seven years prior to the talk, Quasar RAT has garnered over 5,000 stars on GitHub, making it a go-to project for aspiring malware developers due to its ease of compilation—often requiring little more than a "click compile" action in Visual Studio. Its widespread adoption spans from script kiddies to, in some instances, even nation-state actors seeking to obscure their tracks or avoid burning more sophisticated implants.
From Quasar RAT, a clear lineage emerges, exemplified by Pulsar. Initially conceived as "Quasar V2" or a direct continuation, Pulsar's developers soon realized the financial benefits of commercializing their creation. They directly copied the entire project structure and most of the code from Quasar, then enhanced it with overtly malicious features that Quasar's original maintainer deliberately avoided. These additions include AMSI bypass, advanced stealth features, Windows Defender bypassing capabilities, robust obfuscation, modern browser exploits (such as Chrome app bound decryption), and even modules for ransomware and blue screen of death (BSOD) attacks. The laziness of this copying was even demonstrated by the persistence of the original Quasar GUID in some Pulsar binaries, a unique project identifier embedded by Visual Studio, which the Pulsar authors failed to strip out.
The genetic trail extends further to AsyncRAT, another highly prevalent .NET RAT. Despite claims by its author of being a completely custom, new malware, AsyncRAT heavily "borrows" from Quasar. Peters presented a side-by-side comparison of their cryptographic implementations within the network stack, revealing a one-to-one identical initialization vector (IV), referred to as "salt" in the code. This indicates direct copy-pasting of complex components like the IO and networking stacks, including cryptography and helper functions for packet parsing, compression, and video streaming for remote desktop features. AsyncRAT's distinguishing feature is its plugin system, allowing modules to be streamed to infected clients on demand, though even within these plugins and the main stub, Quasar's code is deeply embedded.
Peters' analysis using the Thor Scanner on the Ultimate RAT collection (a GitHub repository containing approximately 650 different RAT families) solidified these findings. Rules targeting Quasar detected not only Quasar itself but also Pulsar, Hive RAT, Silver RAT, and Zeno RAT, among others. Similarly, rules for AsyncRAT revealed its presence in Pulsar (which later copied AsyncRAT's plugin system), DC RAT, Xworm, and various other less prevalent crimeware. This demonstrates a "holy trinity" of copy-paste malware: Quasar (the original), Pulsar (the modernized, commercial evolution), and AsyncRAT (a different framework, but fundamentally Quasar under the hood). Interestingly, the research also noted a trend of Brazilian malware authors frequently copying AsyncRAT and integrating specific banking scams targeting their local population.
Technical Deep Dive
▶ Watch: Leveraging code reuse for effective malware detection (13:00)
The technical core of Peters' presentation lies in the concrete examples of code reuse and the subsequent strategies for detection. The most striking evidence of direct copying between Quasar and Pulsar was the project GUID. When a new project is created in Visual Studio, it's assigned a unique GUID. This GUID is embedded in the compiled binary unless specifically stripped. The fact that Blue one and Pulsar binaries matched on the original Quasar GUID indicated a direct, lazy copy of the project files themselves.
For AsyncRAT, the evidence was even more granular. Peters showed a snippet of code comparing the cryptographic implementations of Quasar and AsyncRAT's network stacks. The initialization vector (IV), named salt in the code, was identical across both. This wasn't merely inspiration; it was a direct copy-paste of a critical security component. This extended to entire sections of the IO and networking stack, including cryptographic functions, helper functions for package parsing, and compression algorithms used for features like video streaming for remote desktop control. These are complex components that many less-skilled actors would struggle to implement from scratch, making them prime candidates for reuse.
Leveraging this insight, Peters advocated for a broad, feature-based detection approach rather than narrow, sample-specific YARA rules. The strategy focuses on identifying core functionalities and code blocks highly likely to be reused. Examples include:
- Cryptographic implementations and networking stacks: As shown with Quasar and AsyncRAT, these are foundational and frequently copied.
- C2 communication package parsing: The logic for encoding and decoding commands and data is often intricate and thus reused.
- Embedded third-party libraries: Malware often bundles legitimate or slightly modified libraries. These can contain unique PDB paths (Program Database paths) or other indicators that persist even after debug information is stripped. Peters cited an example where a specific PDB path pattern was instrumental in detecting multiple loader stages.
- Forensic artifacts: Many stealers generate temporary log files or use specific browser decryption logic that leaves behind predictable file creation events, which can be targeted by Sigma rules or EDR queries.
Peters also highlighted technique-specific indicators that are highly anomalous in a .NET context. For instance, manual export parsing of native DLLs to find function addresses is entirely unnecessary in a managed language like .NET, which has its own mechanisms for interop. Similarly, direct calls to native memory allocation functions like VirtualProtect or VirtualAlloc, or initiating threads in a native context, are red flags. While some commercial obfuscators might use these, their combination often points to malicious intent. For keyloggers, authors often adapt existing game libraries for low-level keyboard hooking. The specific modifications made to support international keyboard layouts (e.g., Cyrillic, Chinese, European special characters) become unique, detectable patterns.
Addressing obfuscation, a common evasion technique, Peters provided several workarounds:
- Renaming patterns: While method names are scrambled, specific obfuscators often use unique renaming patterns (e.g., Portuguese swear words in class names by some Brazilian malware).
- Native pointers and pointer chains: Many obfuscators struggle to properly obfuscate pointer arithmetic and memory offsets, leaving these critical sections relatively untouched and thus detectable.
- Custom cryptography: If malware authors "roll their own crypto" (e.g., modifying RC4 with a simple XOR loop), the specific implementation itself becomes a unique signature. If hardcoded keys are used, the encrypted output is predictable.
- Metadata: Beyond PDB paths, unique icons, fake branding, or specific combinations of outdated dependencies can serve as indicators.
- Dynamic payload construction/code splitting: While challenging, the logic responsible for dynamically constructing or splitting payloads (e.g., AsyncRAT's plugin system) can often be detected.
Demo / Proof of Concept
▶ Watch: Examples of rules targeting specific malicious implementations (16:00)
To validate the effectiveness of their broad, feature-based detection strategy, Jonathan Peters presented results from live hunts on VirusTotal. For one month, all public samples uploaded to VirusTotal were subjected to a set of carefully crafted detection rules. The results unequivocally demonstrated the power of this approach.
One set of rules targeted the AsyncRAT core logic. These rules focused on fundamental components such as its unique plugin system, common persistence mechanisms, and specific IO functions used for tasks like overriding registry keys or performing AMSI bypassing. In just one month, these rules successfully matched approximately 50,000 unique samples. Crucially, these detections were not limited to AsyncRAT itself but encompassed a wide array of related families, including Xworm, DC Rat, and numerous other RATs. This showcased how a few well-designed rules could effectively detect an entire category of malware derived from a common codebase.
Another set of rules specifically targeted the Quasar protocol. These rules focused on the distinctive elements of Quasar's network stack, including its C2 packet parsing logic and a unique function responsible for display image compression used during remote desktop streaming. Additionally, other Quasar-specific functions were included. Over the same one-month period, these rules yielded around 40,000 unique matches. This again demonstrated broad coverage, detecting not only Quasar but also its direct descendant Pulsar, along with other modifications like High threat, which are widely distributed and sold across various underground forums and Telegram channels.
Peters emphasized that these results highlight the economic efficiency of their detection strategy. Instead of developing highly specific detections for each new variant, which is resource-intensive and prone to rapid obsolescence, focusing on these reused code blocks provides a much higher "economic detection value." This approach allows defenders to achieve significant coverage with fewer, more robust rules, directly leveraging the attackers' reliance on copy-pasting.
Defensive Implications
▶ Watch: Q&A: Surprising false positives from unusual software (27:00)
The insights gleaned from Peters' research carry significant implications for defensive strategies. The most critical takeaway for defenders is the need to shift away from narrow, sample-specific detections towards a more broad and feature-based approach. Instead of writing YARA rules for every new malware variant, security teams should focus on identifying and targeting the core functionalities and shared code blocks that underpin entire families of .NET crimeware. This includes common cryptographic implementations, networking stacks, C2 communication protocols, and persistence mechanisms.
Defenders should actively look for anomalous native interactions within .NET applications. The presence of functions like manual export parsing of native DLLs or direct calls to VirtualAlloc or VirtualProtect in a managed .NET context is highly suspicious and rarely legitimate. Implementing EDR queries or Sigma rules to detect these specific API calls and their combinations can provide powerful generic detections. Furthermore, leveraging forensic artifacts such as unique PDB paths embedded in binaries, specific log files generated during browser credential decryption, or unique embedded resources (like icons or branding) can offer robust indicators that often survive obfuscation attempts.
Understanding the "gene pool" also means recognizing that vulnerabilities in a base malware's code will persist across all its derivatives. Defenders should stay informed about known vulnerabilities in foundational projects like Quasar RAT, as these weaknesses are likely to be present in many "new" families. This proactive knowledge allows for anticipating potential attack vectors and developing preventative measures.
Finally, while obfuscation is a challenge, it's not insurmountable. Defenders should focus on techniques that obfuscators struggle with, such as pointer chains and native memory operations. Baseling known good software in their environment is also crucial to minimize false positives, especially when using broader, technique-based rules that might occasionally trigger on unusual, but legitimate, software. The goal is to maximize detection efficacy while minimizing operational overhead, turning the attackers' laziness into a defensive advantage.
Key Takeaways
- Pervasive Code Reuse: The vast majority of commodity .NET malware, especially those targeting individuals and small businesses, heavily reuses code from established open-source or leaked projects, primarily Quasar RAT and AsyncRAT.
- Illusion of Novelty: Many "new" malware families reported in the wild are simply rebranded or slightly modified versions of older, existing threats, often sharing identical core functionalities and vulnerabilities.
- Defender's Advantage: This widespread code reuse by attackers directly enables defenders to reuse and generalize their detection strategies, leading to more efficient and cost-effective security operations.
- Feature-Based Detection: Shifting from narrow, sample-specific detections to broader, feature-based rules that target core functionalities (e.g., networking stacks, cryptographic implementations, anomalous native API calls) yields significantly higher detection value.
- Obfuscation Bypasses: Advanced obfuscation can often be circumvented by focusing on specific implementation patterns, metadata (like PDB paths), custom crypto flaws, and native interactions that obfuscators struggle to obscure.
- Anticipating Threats: Understanding the malware "gene pool" allows defenders to anticipate the capabilities and potential vulnerabilities of new variants, enabling more proactive and robust defense mechanisms.
About the Speaker(s)
Jonathan Peters, known by his alias "Code Name," is a distinguished Malware Analyst and Threat Researcher at Nextron Systems. In this role, he plays a crucial part in the development of the Thor Scanner and the Sigma standard, both instrumental tools in the cybersecurity community for threat detection and research. His expertise lies in deep-dive malware analysis and comprehensive threat research, involving the meticulous tracking of malware families and threat actors across the internet. Prior to his significant contributions to cybersecurity, Jonathan Peters was a software developer specializing in .NET, a background that provides him with unique insights into the nuances of .NET malware. He also briefly worked as a payroll consultant, which he humorously refers to as a "very dark chapter" of his past.
Reviews
Dr. Zero (Offensive Security Researcher) — SOLID
Solid applied research that turns a practical observation—commodity .NET malware is lazy copy-paste of Quasar/AsyncRAT—into actionable detection strategy. Not groundbreaking exploitation research, but genuinely useful for defenders drowning in vendor-specific IOC churn.
Heather Calloway (CISO) — STRONG ACCEPT
This is exactly the kind of research that makes detection engineering more efficient. Peters demonstrates that most .NET commodity malware shares a common codebase, which means your team can write fewer, broader rules and catch more. Worth your SOC lead's time.