{
	"id": "46412c96-65a1-4179-8d39-226842fc2ad7",
	"created_at": "2026-04-10T03:20:18.848302Z",
	"updated_at": "2026-04-10T13:11:52.281237Z",
	"deleted_at": null,
	"sha1_hash": "0c7ac61bf354cafd2706d1719703d1b82886c4b2",
	"title": "Malware Against the C Monoculture",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 114806,
	"plain_text": "Malware Against the C Monoculture\r\nBy deugenio\r\nPublished: 2019-05-20 · Archived: 2026-04-10 02:21:21 UTC\r\nResearch by: Ben Herzog\r\nIt’s possible to write any program in any programming language; that’s what Turing completeness means.\r\nTherefore, it’s possible to write malware in any language, too. But in both cases, what’s possible isn’t always\r\nfeasible. Performance issues, compatibility issues, the availability of third-party libraries and useful primitives —\r\nall of these can spell the difference between a huge success and a huge headache.\r\nMalware authors face “product specifications” unlike any other developer. They need their product to run silently,\r\nreliably, and with minimum user interaction. As a result, they will go to great lengths to avoid an extra dependency\r\nthat requires separate installation, or an extra dialogue box that asks “are you sure?”. These things are usually just\r\n“nice-not-to-have”s, but for malware authors, they directly hurt the campaign’s bottom line.\r\nThis contributes to somewhat of a monoculture in the malware landscape. A great majority of notable malware is\r\nwritten in C language, or at best C++. These may not be the most developer-friendly languages in the world (C\r\nlanguage creator Dennis Ritchie sardonically noted in 2011 that C has “all the power of assembly language,\r\ncombined with all the convenience of assembly language”), but the amount of example code and reference\r\nmaterials available for these languages is very great. More importantly, a well-built C binary looks just like a\r\nlegitimate program to the untrained eye, and runs without a hitch or a dialogue box. If we started listing current or\r\nhistorical high-profile malware that’s written in C or C++, we wouldn’t stop.\r\nStill, is this choice set in stone? How much of it is well-founded decision, rather than just attachment to the status\r\nquo? In this article, we explore that question via a review of some malware where the authors chose otherwise.\r\nWe’ll separate the chosen languages into rough categories (dynamic, VM and static), and ask ourselves: Was this a\r\ngood choice? Is this language — even this kind of language — a good fit for writing malware with, and why?\r\nEasy, but There’s a Catch: Dynamic-Language Malware\r\nThere is no single well-defined quality that makes a programming language “dynamic” or “static”. These are more\r\nterms of art than rigid definitions. A programming language will tend to be called “dynamic” if it has enough of\r\nthe following characteristics:\r\n1. Dynamically typed: Types are only assigned to objects at run-time.\r\n2. Weakly typed: Type conversions can happen without the developer explicitly invoking a conversion\r\nfunction.\r\n3. Garbage Collected: Memory management happens automatically at run-time, and is invisible to the\r\ndeveloper.\r\n4. Interpreted: Language instructions are converted into machine instructions as a part of the execution\r\nprocess.\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 1 of 17\n\nSome well-known examples of languages generally considered “dynamic” are Lua, Javascript, PHP, Perl, and\r\nPython (which isn’t weakly typed). These stand in contrast to “static” languages, which have traditionally had\r\nthese characteristics:\r\n1. Statically typed: Types are assigned to variables at compile time.\r\n2. Strongly typed: Type conversions can only happen if the developer explicitly invokes a conversion\r\nfunction.\r\n3. Manual memory management: The developer is responsible for specifying correct allocation and de-allocation of memory at compile time.\r\n4. Compiled: Language instructions are all converted directly into machine instructions in a separate step,\r\nwhich must be completed before the program can be run.\r\nThis category includes C, C++, Pascal and Fortran.\r\nOn paper, dynamic languages should be very attractive to malware authors. When using them, the development\r\nprocess takes less time and is much less of a hassle — things “just work”, and quickly. There are no long\r\ncompilation times, barely any time spent satisfying the type system, no boilerplate code to manage memory, and\r\nrelatively little debugging before the code’s first successful run from beginning to end. It’s a much breezier\r\nexperience than using “static” languages in general, let alone C.\r\nThat’s not to say Dynamic languages are without drawbacks. Garbage collection has a performance cost; some\r\nrun-time errors will get into production that a rigid type system would’ve caught; and dynamic code is empirically\r\nknown to not “scale” as well when the project grows, due to the languages’ lax guarantees and fountain of implicit\r\nmagic. Still, malware authors don’t typically care about these issues. They don’t mind if the malware takes 3\r\nminutes to run instead of 10 seconds; they’d rather ship quickly than enjoy any fancy-pants guarantees on esoteric\r\nedge cases; and they certainly aren’t in it for the ‘scaling’ experience. From their point of view, you can live the\r\ndream of zero bugs, zero features, and zero technical debt – as long as you give zero priority to any of those\r\naspects of software.\r\nThe Joy of Dynamic Languages (Credit: Randall Munroe)\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 2 of 17\n\nSo why isn’t all malware just written in dynamic languages? Generally, it’s because:\r\n1. Some actors have the above attitude to maintaining projects, and then others don’t. They aim high, and\r\ntheir goal is to build a robust product and a lucrative brand identity, where they get to sit and watch as other\r\ncriminals fork over cash to participate in their affiliate program or to use their product in a separate\r\ncampaign. Feature logs, bug fixes, and technical debt are not mere hassles to these actors, but legitimate\r\nconcerns.\r\n2. Dynamic languages typically require an interpreter to function, which may not even be installed at the\r\nvictim machine. Socially engineering someone to double-click a file is one thing, but socially engineering\r\nthem to first install the Perl interpreter and then double-click the file is something else entirely.\r\n3. Victims are used to running compiled binaries. When you hand them a compiled binary and name it\r\nfrog_blender.exe, they’ll just double-click it and get infected. The same gambit with an interpreted file will\r\nnot work as easily. “Why does this file have a py extension instead of exe? Why is Windows asking\r\nwhether I want to run or edit the file? Why do I need to pick a program to run it with?”. A whole separate\r\neffort has to be made to socially engineer the victim into running the code at all.\r\n4. In any language, some functions that are a malware author’s bread and butter — such as reading and\r\nwriting to the registry, working with remote processes, and sending HTTP requests — will be absent from\r\nthe language’s standard library. The difference is that in a compiled language, these dependencies can be\r\nbaked into the malware at compile time, on the author’s end; but in the case of an interpreted language, the\r\nmalicious code looks for these dependencies at run time, on the victim machine, where they are almost\r\ncertainly missing.\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 3 of 17\n\nThe Sorrow of Dynamic Languages (Credit: Manu Cornet)\r\nDynamic code is typically much easier to analyze. Whole classes of anti-disassembly, anti-debugging, anti-VM,\r\nanti-Analyst’s-will-to-live tricks are just out of reach when writing in a dynamic language. This is the result of\r\nseveral factors, and mostly the semantic gap between the interpreted script and the machine code that these\r\ntechniques are typically written in. Also, interpreted malware doubles as its own source code, which is easier to\r\nunderstand and modify. Severely “obfuscated” scripts have been known to be de-obfuscated single-handedly by\r\nchanging a single eval statement into a print.\r\nPowershell Malware (MuddyWater, 2018; GhostMiner, 2018)\r\nPowershell is a “task automation and configuration management framework” which\r\nMicrosoft introduced in the year 2000. It is roughly analogous in function to Linux’s bash, which means that if\r\nyou want to do something, there’s probably a command for it. Powershell is built on top of Microsoft’s “.NET\r\nframework” — meaning that similarly to Java, it ultimately runs on a specific Virtual Machine, created for this\r\npurpose.\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 4 of 17\n\nFor a dynamic language, Powershell is unusually suited to writing malware, as it compensates for two of the\r\ndrawbacks noted above. First, every version of Windows since XP ships with the Powershell interpreter included\r\nout of the box; second, all of Powershell’s functionality is accessible immediately without the need to download\r\nthird-party code. This leaves merely the concerns of poor scalability, weaker obfuscation and the lack of built-in\r\nsocial engineering. Actors willing to tolerate these issues, or to do some work and compensate for them, actually\r\nhave the option to write their malware in a dynamic language, with all the resulting productivity gains.\r\nOne notable campaign that went the Powershell route is MuddyWater, a backdoor operation attributed to an\r\nIranian threat actor that’s been active since at least 2017. MuddyWater was mostly noted for an elaborate\r\ncampaign targeted at the Saudi Arabian government, but has also been known to pick targets in the US and\r\nEurope. A year after the campaign’s debut, in 2018, Turkish public companies in the finance and energy sectors\r\nwere hit with a malicious document campaign that, as its payload, basically had a Powershell rewrite of\r\npreviously-known MuddyWater tools. The payload itself was moderately obfuscated by BASE64 encoding, AES-encryption with a known key, and the hiding of some code fragments behind variables named after colorful\r\nEnglish swear words. Once you got past that, the backdoor itself was minimalistic in function, and mostly used\r\nPowershell’s facilities to easily perform tasks such as getting the victim’s system architecture and privileges.\r\nWhen using C, these trivial tasks can require correctly chaining several calls from the Win32 API, which is\r\nnotorious for functions such as the succinctly-named AccessCheckByTypeResultListAndAuditAlarmByHandleA\r\nthat takes a mind-boggling 17 parameters.\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 5 of 17\n\nMuddyWater decoy document, with the blurred logo of the Kurdistan regional government. (as initially outlined\r\nhere)\r\nAnother example of Powershell malware was GhostMiner, a fileless threat discovered by researchers at Minerva\r\nat 2018 that used its hapless victims’ CPU cycles to mine cryptocurrency. GhostMiner was a piece of technical art,\r\ncombining ready-made pieces to create an unusually evasive infection chain. For its propagation phase, it acted\r\nakin to the old-school Morris Worm, probing random IP addresses and targeting them with an exploit for a certain\r\n1-day vulnerability (in this case CVE-2017-10271, a vulnerability in Oracle’s WebLogic server). Post-exploitation, it used two separate evasion techniques, both released as open-source tools by legitimate penetration\r\ntesters, to reflectively load a malicious DLL from an obfuscated payload (Invoke-ReflectivePEInjection and Out-CompressedDll).\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 6 of 17\n\nGhostminer code that removes competing miners from the victim system. (Credit: Minerva Labs)\r\nOne can see how both those choices were made to compensate for Powershell’s weaknesses as a tool of the\r\nmalware craft. Exploiting a vulnerability — rather than the human element — meant that the attack could proceed\r\nwithout socially-engineering anyone to run a Powershell script. This insight has not escaped other actors, and as a\r\nresult, in recent years Powershell has seen wide use in “Fileless” malware built on the same principle. This\r\nextends to other contexts where code is already running on the victim machine, such as the tail of a malicious MS-Office macro attack (see for example here, as well as this quaint little backdoor which liaisons with its C\u0026C\r\nserver via DNS TXT entries). By using ready-made frameworks to handle evasion and obfuscation, the authors\r\nmade sure that analyst frustration when coming across this threat was at least moderate.\r\nThe only thing the attackers did not (and could not) compensate for was the language’s unsuitability for\r\ncommitment to large, maintenance-heavy projects. But maybe that’s for the best: analysts suspect that\r\nGhostMiner’s technical tour de force only managed to mine 1 XMR, equivalent to a grand total of about $200.\r\nPython Malware (Pbot, 2018)\r\nFirst released by Guido von Rossum in 1991, the Python programming\r\nlanguage pivoted off its simple syntax and large standard library to become a sort of lingua franca for developers.\r\nIt is one of the easiest programming language to learn, if not the easiest, and one of the most fully-featured, in that\r\nthere’s a library for nearly everything you might want to do. Python is the poster child for all the advantages of\r\ndynamic languages; if malware authors could just write all their malware in Python, all else being equal, they\r\nwould.\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 7 of 17\n\nUnfortunately for them, things are not that simple. With respect to writing malware, Python has all of Powershell’s\r\npitfalls, and then all the rest of the issues with dynamic languages on top of those. Python isn’t pre-installed by\r\ndefault on Windows, and so has to be installed separately; also, many pieces of functionality that are essential to\r\nmalware aren’t even included with the Python standard library, and so require third-party modules. For instance,\r\nnearly every malware will have to interact with the Windows registry and send HTTP requests, but if you want to\r\ndo that in idiomatic Python, you need to download a separate third-party module for each of those actions (such as\r\nwinreg and requests, respectively).\r\nAll of these concerns make Python malware rare — but, apparently, not unheard of. For some malicious actors,\r\nthe prospect of cutting down on 70% of their work with a few import statements is just too good to pass up, and\r\nthe result is strange creatures like Pbot.\r\nFragment of Pbot’s loader code. (Credit: MalwareBytes)\r\nPbot is a piece of python Adware, noticed by Malwarebytes researchers in early 2018. It spends a lot of energy\r\nclearing several of the hurdles outlined above. For instance, at the time it was being spread via the RIG exploit kit,\r\nrouting (again) around the requirement for social engineering. To deal with the fact that the victim may be missing\r\nthe Python interpreter and/or the required libraries, Pbot does not deliver a raw .py script file, and instead delivers\r\na large executable bundle which contains a complete Python environment and interpreter, including all the\r\nrequired dependencies. Bundles such as these can be created from Python packages using 3rd-party tools such as\r\nPyInstaller.\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 8 of 17\n\nPbot’s main functionality was a framework for injects and man-in-the-browser attacks. Without access to Pbot’s\r\nconfiguration, one could only speculate on the exact monetization model that authors had in mind; but given that\r\nmost malware with such functionality uses it to steal banking credentials, and given that the malware came with a\r\nbuilt-in whitelist of Russian banks to refrain from attacking, we can conclude that Pbot was probably a banking\r\nTrojan (the canonical example of such malware, ZeuS, was also known as Zbot).\r\nBy hitch-hiking on an exploit kit and using the executable bundle install, the authors of Pbot were able to skirt\r\nsome of the inherent problems of Python malware, but not all. The most glaring drawback is the particularly weak\r\nobfuscation, which the authors didn’t do much to offset (even leaving in some comments and debug strings). It\r\nmay also be worth mentioning that spam emails are still the most prolific attack vector, and that for\r\ncybercriminals, giving up on spam and relying solely on exploit kits is likely a bitter trade-off.\r\nSchema of how an application written in a VM language (in this case, Java) can be run on multiple platforms.\r\nSome of Column A, Some of Column B: VM Language Malware\r\nNot all languages can be stuffed neatly into the “static” or “dynamic” pigeon-hole. There’s a notable set of\r\nprogramming languages which, on the one hand, are statically and strongly typed, and have an explicit\r\ncompilation step; but on the other hand, are garbage-collected, and are compiled to bytecode that’s only translated\r\nto machine code at run time by a dedicated VM. You may rightly ask where’s the difference between this so-called\r\n“compilation” and the flow of a fully interpreted language like, for example, Python, which does after all have its\r\nown VM for exactly the same purpose. Mainly, the difference is that a VM language may easily lack a REPL\r\n(interactive prompt), whereas for a dynamic language, it’s a must-have feature; and that in a VM language, the\r\nbytecode translation must be invoked by the developer explicitly and both it and the VM itself generally have\r\nproper specifications, whereas in a dynamic language the conversion is invoked implicitly and is more of a mere\r\nimplementation detail. (If you’re interested in a deeper dive into this shadowy corner, we recommend this blog\r\npost by Ned Batchelder). Some prominent examples of VM languages are Java, Scala and Kotlin, all of which run\r\non Oracle’s JVM; as well as C# and VB.NET, all of which run on Microsoft’s CLR.\r\nVM languages’ mishmash of characteristics puts them somewhere in the twilight zone between “static” and\r\n“dynamic”, with a resulting mix of pros and cons for malware developers. These languages provide an immediate\r\nproductivity boost over C, and their bytecode can be run on any OS that has the appropriate VM installed; on the\r\nflip side, they introduce a glaring dependency in the form of the VM itself, as well as the challenge of getting the\r\nvictim to run a non-PE file (there’s also the performance overhead, but again, that’s less important in the context\r\nof malware).\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 9 of 17\n\nJava Malware (Jrat, 2012)\r\nJava spent several years reigning as the most popular programming language on\r\nearth, and has a long and complicated history, fraught with patent lawsuits and corporate acquisitions. It is well-known for being an essential layer in the development stack of Android Apps, as well as a popular choice for\r\nserver-side enterprise apps. Apart from its VM nature, Java is perhaps best-known for its strong adherence to\r\nObject Oriented Programming principles: In Java, everything is an object (as lampooned in Steve Yegge’s\r\nExecution in the Kingdom of Nouns).\r\nIs Java a good choice for cybercriminals trying to write malware? That depends on how much they like Java’s\r\nObject-orientation, how much their campaign stands to gain from Java’s cross-platform reach, how much they\r\ncare about obfuscation, and how much they are willing to let victim conversion rates suffer. The tagline goes “15\r\nBillion devices run Java”, but the victim’s machine might not be one of them.\r\nThis apparently was not enough of a concern for the authors of JRat, a Remote Administration Tool discovered by\r\nFortinet in 2016. JRat supports a variety of commands, among them deleting victim files, sending screenshots to\r\nits C\u0026C server, killing processes and visiting URLs (this last one may be used for DDOS attacks and click fraud).\r\nUnlike with PBot, which included all its bundled dependencies, JRat only targets machines which already have\r\nJava installed.\r\nJRat is obfuscated to a reasonable standard for a dynamic language; all the package and variable names are\r\nreplaced with random gibberish, all the strings are split into many shreds that are only assembled at run-time, and\r\nsome of the functionality is buried behind an AES-encrypted blob. While frustrating, these stumbling blocks still\r\ncan’t hold a candle to the obfuscations and evasions one often encounters on classic-flavor C malware.\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 10 of 17\n\nJrat source containing obfuscated string shreds. (Credit: Fortinet)\r\nHappily, judging by JRat itself, we are still far away from the specter of true cross-platform malware. The\r\nmalware was not actually written fully in Java, and contained OS-specific components which were executed\r\ndepending on the victim OS. Also, according to analysis by Trend Micro, the authors did not fully implement all\r\nof the malware’s functionality for all operating systems, and instead showed clear “preferential treatment” to\r\ncompatibility with Windows OS. This makes some sense, given that Windows OS is probably more familiar to the\r\nmalware authors and has a significantly larger market share — but if we put ourselves in the authors’ shoes, we\r\ncan’t help but see this choice as a missed opportunity.\r\nWe Fear It’s the Future: Ergonomic Static Language Malware\r\nAs mentioned above, ergonomics for static languages have been historically poor, especially so for C language.\r\nThis deficiency gave birth to dynamic and VM-based languages, but also produced efforts to create new static\r\nlanguages with improved ergonomics. The most well-known effort in this direction is old reliable C++, which\r\nintroduced exceptions, operator overloading, improved memory management and built-in support for Object\r\nOriented Programming; yet during the years, has also inspired a litany of criticisms leveled at its ad-hoc\r\npatchwork design, Turing-complete template system and, most importantly, its manual memory management. The\r\nlast 20 years therefore saw many efforts to address these issues by creating “a better C++”, many of which failed\r\nto catch on and faded into obscurity.\r\nFor malware authors, the modern static languages in serious use today generally share the advantages and\r\ndisadvantages of static languages, apart from some differences. First, the ergonomics tend to be much better, but\r\nstill can’t match the experience of writing in, say, Python. Second, these languages use stronger typing systems\r\nthan C, which place more restrictions on conversions between types. This improves scalability with respect to\r\nproject size, but means that some categories of clever tricks are right out, and the malware developer may have\r\ncome to rely on those in their coding style. Third, these languages are typically new, with a smaller niche than\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 11 of 17\n\nC++, and so studying them is a costly, avoidable investment. Fourth, and related to the third: there is no large\r\nrepository of leaked malicious code to pick and choose from, and the third-party libraries are sometimes not\r\nmature by the standard you’d come to expect from more established languages.\r\nGolang Malware (Mirai, 2016; Zebrocy, 2019)\r\nGolang, which was created at Google in 2007, puts a particular emphasis on\r\nreadability, simplicity, built-in concurrency primitives, and a minimal feature set. The authors reportedly wanted\r\nthe language specification to be “small enough to hold in a programmer’s head”, and opted to leave out many\r\ncomplex features (most notably generic programming facilities), which makes the learning curve for Golang a\r\ntreat. Golang is therefore an opportunity for malware authors if they are willing to put in the moderate learning\r\neffort, and as long as they are also willing to roll up their sleeves and make do when otherwise they would have\r\nused a third-party library or copy-pasted code from the leaked Gozi sources.\r\nSince 2012, the infosec world has been subjected to an intermittent drizzle of Golang malware. Among the notable\r\nexamples, one can find this tool that co-opts the victim machine to assist in brute-forcing the credentials to\r\nphpMyAdmin and WordPress websites; WellMess, a simple backdoor that allows remote execution of shell\r\ncommands on the victim machine; and we would be remiss not to mention the Mirai Botnet, a juggernaut made\r\nout of hundreds of thousands of IoT devices that were compromised via credential brute-force, and was\r\ninfamously used to launch a gigantic denial of service attack against the blogging platform of investigative\r\nreporter Brian Krebs. (If you happen to have a spare hour, the follow-up investigation report by Krebs is really\r\nsomething.)\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 12 of 17\n\nThis open-source Golang code to retrieve the list of logged-in users was used verbatim in Zebrocy. (Credit: Vitali\r\nKremez)\r\nPerhaps the most technically notable incident was in late 2018, when a new variant surfaced of the Zebrocy\r\nDownloader / Infostealer, a large piece of which was written in Golang. This piece of malware originated with the\r\nSofacy Group (APT28), thought connected to the Russian military intelligence agency GRU. According to\r\nresearchers at Kaspersky, this new variant was mainly used to attack central Asian governments, and rode on the\r\ntail of a complex infection chain that lured victims to run an executable file with an icon mimicking that of an\r\nMS-Word document. Post-infection, the malware displayed a decoy document to mitigate suspicion, which\r\ncertainly implies some degree of author dedication.\r\nRust Malware (Exaramel Backdoor, 2017)\r\nRust language was originally conceived at Mozilla Research, and its main feature is\r\na “borrow checker” that enforces thread and memory safety at compile time, removing the need for a run-time\r\ngarbage collector and making the language viable for real-time and embedded systems. Apart from that, Rust has a\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 13 of 17\n\ncomplex type system, mind-boggling iterator adapters and many other such features directly inspired by Haskell\r\nand its functional ilk.\r\nThis Rust code performs a generalized rotating byte-wise encryption.\r\nOn the face of it, Rust is not a reasonable choice for malware authors. While practitioners hold the language in\r\nhigh regard, it has a notoriously difficult learning curve, and solves problems that cybercriminals don’t much care\r\nfor. Maybe somewhere out there, there’s a malware author with a passion for shaving 5% off their malware’\r\nrunning time, running it on embedded devices and implementing all the logic via zygohistomorphic\r\nprepromorphisms, but we suspect this person is the exception, rather than the rule.\r\nImagine our surprise, then, when we first heard of Linux.Backdoor.IRC, originally discovered in 2016. It is a\r\nsimple Rust backdoor that responds to commands via IRC protocol (some would call this “old-school”), and\r\nsupports a total of 4 commands: collect \u0026 send OS information to the C\u0026C server; collect and send information\r\nabout running processes on the victim machine; connect to a specific chat channel; and self-destruct (delete self\r\nfrom file system). The analysts at Dr. Web, who discovered this curiosity, noted that the IRC channel was not\r\nactive and the malware appeared to lack any mechanism for self-propagation, and thus came to believe that it was\r\na prototype or a proof-of-concept. Whatever it was, when its authors were done, they apparently wiped a drop of\r\nsweat off their brow and said, “we’re not doing that again”.\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 14 of 17\n\nScreenshot of the IRC channel used to control Linux.Backdoor.IRC. (Credit: Dr. Web)\r\nWe would disregard Linux.Backdoor.IRC as a freak coincidence and/or urban legend, except that two years later it\r\nwas followed by another, and rather more serious, instance of Rust malware: the Exaramel backdoor, used by the\r\nTelebots group. This group is thought to have been behind the high-profile NotPetya outbreak, as well as several\r\nattacks against critical infrastructure in Ukraine (which were dressed up as ransomware attacks with a highly\r\nunreasonable ransom demand). The group is thought to have connections with the BlackEnergy group, which was\r\nknown for a similar modus operandi; the name “Telebots” is derived from its standard backdoor tool, which\r\ncommunicates with its C\u0026C server via the Telegram bot API.\r\nA part of the Exaramel backdoor disassembly. (Credit: ESET)\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 15 of 17\n\nThe Exaramel backdoor was originally written in Python but was later Rewritten in Rust. According to ESET, it\r\nwas distributed as a Trojan pretending to be an AV solution, and even communicated with domains that were\r\nforged to appear to be legitimate AV vendor domains. It supported a fairly sophisticated API, including the ability\r\nto create processes as a specific user, start and stop Windows services, and evaluate arbitrary VBS code. It was\r\nalso bundled with an embedded credential stealer, which harvested passwords from a long list of web browsers\r\nand FTP clients.\r\nWe finally note that versions of this backdoor were spotted in the wild that were compiled to run on Linux OS,\r\nwhich implies that the Telebots group makes a point of being a cross-platform threat. This at least may explain\r\nwhy they rewrote their backdoor in a “modern C++ replacement” language. Outside of Rust and Golang’s 3rd\r\nparty code ecosystems, to retarget your executable you’d either have to rely on a VM/interpreter at the victim end,\r\nor else go back and individually change OS API calls. As to why this group didn’t rewrite the backdoor in Golang\r\ninstead, it is a mystery for the ages. Maybe they just really like generics.\r\nOther Honorable mentions\r\nLinux.Grip (2005) reportedly used a snippet of the esoteric language Brainf*ck for generating encryption\r\nkeys.\r\nRetefe (2013), a banking Trojan, has a history of unorthodox clones meant for non-Windows operating\r\nsystems — including a clone written in Apple’s Objective-C, which was distributed circa April 2017 in a\r\ncampaign that targeted the key demographic of Swiss macOS users.\r\nGootkit (2014), also a banking Trojan, is written mostly in Javascript (Node.js), a language usually\r\nreserved for web development.\r\nLatentBot (2017), an all-purpose modular backdoor, as well as several packers that have been spotted in the\r\nwild, were written in Delphi — a dialect of Pascal, a language invented in 1970 for educational purposes.\r\nConclusion\r\nAs you’ve probably heard, the malware landscape is in constant evolution. Most actors just copy what’s known to\r\nwork, but some like to experiment — whether due to an actual need or sheer hipster spirit. The failures are then\r\ndiscarded as dead ends, while the successes are imitated. Some technologies are esoteric right now because they\r\ngenuinely aren’t a good fit for writing malware; others, because they haven’t picked up credibility, or because\r\nthreat actors shy away from their slightly different mix of pros and cons, and would rather deal with the devil they\r\nknow.\r\nIt’s difficult to say in advance which of these technologies, if any, will become the “next big thing” in the malware\r\nworld. Some technologies, such as Golang and Powershell, seem particularly well-poised to do so (Powershell is\r\nalready halfway there). Others, like Java and Rust, not so much. But for a technology to become fashionable in the\r\ncybercrime circles, all it takes is one ambitious author to produce one high-profile successful campaign that hinges\r\non it.\r\nWill we all still be looking at C malware all day long 10 years from now? 20? It’s difficult to know. But maybe we\r\nshould hope so. The current malware landscape, which is enough of a problem, came to be even as threat actors\r\nduly spent a bulk of their resources debugging segmentation faults, looking up function parameter order in the\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 16 of 17\n\nMSDN database and copy-pasting code from header to source files and back again. Maybe we don’t want to find\r\nout what happens when all of that time suddenly becomes free time.\r\nSource: https://research.checkpoint.com/malware-against-the-c-monoculture/\r\nhttps://research.checkpoint.com/malware-against-the-c-monoculture/\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://research.checkpoint.com/malware-against-the-c-monoculture/"
	],
	"report_names": [
		"malware-against-the-c-monoculture"
	],
	"threat_actors": [],
	"ts_created_at": 1775791218,
	"ts_updated_at": 1775826712,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0c7ac61bf354cafd2706d1719703d1b82886c4b2.pdf",
		"text": "https://archive.orkl.eu/0c7ac61bf354cafd2706d1719703d1b82886c4b2.txt",
		"img": "https://archive.orkl.eu/0c7ac61bf354cafd2706d1719703d1b82886c4b2.jpg"
	}
}