Why EtherRAT Is the Last Argument You'll Ever Need to Leave Windows
You are a senior systems engineer, and you need Kusto Explorer. This is not a casual need. Kusto Explorer is the desktop client for Azure Data Explorer, the query environment where your team runs KQL against telemetry logs, monitors infrastructure health, and traces incidents back to their origin events. It is a tool you use the way a surgeon uses a scalpel — precisely, repeatedly, without thinking much about where it came from. Today, for whatever reason, you need a fresh install. Maybe it's a new machine. Maybe the last version started behaving strangely. The reason doesn't matter. You do what you always do. You open a browser and search.
The first result looks exactly right. It's a GitHub repository — clean, documented, professional, the kind of page that signals someone has put real effort in. The README is thorough. The version numbers line up. There's no reason to hesitate, and you don't. You click the download link in the README. A second repository opens. You download the MSI. You run it.
This is the moment. Everything that follows — the silent Node.js installation, the in-memory payload chain, the AES-256 decryption stages, the process that settles under conhost.exe and begins beaconing to an address stored not on any server but on the Ethereum blockchain — all of it flows from this moment, and none of it is visible to you. The installer finishes. Kusto Explorer may or may not be there. It doesn't matter to the people who built that GitHub page. What matters to them is that you are exactly the kind of person they were looking for, and they have found you.
The campaign security researchers at the Atos Threat Research Center identified in March 2026 and named EtherRAT is not a wide-net attack. It is not phishing for credentials from ten million email addresses hoping that a fraction of one percent will click. It is a precision instrument, engineered with considerable patience and sophistication, designed to compromise a very specific kind of target: the administrator, the DevOps engineer, the security analyst — the person with elevated privileges and the keys to critical infrastructure. The selection mechanism is elegant in its simplicity. The attacker doesn't need to know who you are. They only need to know what you search for. And only a certain kind of person, doing a certain kind of job, searches for Kusto Explorer.
Before we get to what the malware does once it's inside — and what it does is genuinely novel, worth understanding in full — it's worth pausing on the architecture of the trap itself, because the trap is the story. EtherRAT is being covered by most of the security press as a warning: watch out, these attackers are sophisticated, these targets are high-value, these techniques are advanced. That framing is accurate and almost entirely useless. The more important story is structural. Every component of this attack — the SEO poisoning, the two-repository GitHub architecture, the fileless payload chain, the blockchain command-and-control infrastructure — is built on a foundation that a particular ecosystem makes possible, and that ecosystem is not a mystery. It has a name, and it runs on your workstation right now.
The Anatomy
The attack begins not with malware but with mathematics — the mathematics of search engine rankings. Across Bing, Yahoo, DuckDuckGo, and Yandex, the operators behind EtherRAT spent months manipulating search results for a carefully curated list of queries: "Kusto Explorer download," "Sysmon tool," "PsExec utility," "AzCopy latest version," "LAPS download," "WinDbg installer," "BgInfo tool," "ProcDump." If you recognize every item on that list, you are the target. These are not consumer tools. They are not the kind of thing a casual Windows user ever searches for. Kusto Explorer is the desktop client for Azure Data Explorer — a specialist instrument for engineers running KQL queries against telemetry at scale. Sysmon is a Windows system monitoring utility from Microsoft's own Sysinternals suite, deployed almost exclusively by security teams building detection pipelines. LAPS — Local Administrator Password Solution — is an Active Directory tool for managing local admin credentials across enterprise fleets. Every query on the list is a professional shibboleth. You have to already know what these tools are to search for them. The search terms themselves are the skills test. The attackers aren't casting a wide net and hoping. They're running a very precise filter, and the filter is your own job title.
Notably absent from the poisoned search engines is Google. Whether this reflects a deliberate operational decision — perhaps Google's search quality algorithms proved more resistant to the manipulation techniques being deployed — or simply that the target demographic was sufficiently capturable through the other four, researchers have not determined. But the omission is worth registering, not least because it tells you something about the attackers' methodical approach. This was not a rushed operation. Between December 2025 and April 2026, Atos researchers identified forty-four separate malicious GitHub facade repositories, impersonating seventeen distinct administrative tools. That is a sustained, patient, industrial campaign — the product of months of work by operators who were in no hurry, because their infrastructure was built to last.
The GitHub architecture is the first genuinely elegant engineering decision in the attack chain, and understanding it is essential to understanding why the conventional defender response — flagging and taking down malicious repositories — barely registers as an inconvenience. The campaign operates through a two-repository structure. The first repository, the one that ranks in search results, is completely clean. It contains convincing documentation, plausible version histories, and professional presentation. There is no malware in it anywhere. When a researcher flags it, when GitHub receives a takedown request, when automated scanners sweep it for malicious content, they find nothing, because there is nothing to find. What this repository contains instead is a README with a download link pointing to a second repository — a separate account, a separate namespace, entirely decoupled from the storefront. The payload lives there. If that second repository gets taken down, the attackers replace it with another one, update the README link, and the operation continues without interruption. The search rankings are preserved. The SEO investment — which represents the real labor-intensive work of this campaign — is protected entirely. The storefront never dies. The warehouse is disposable.
When a victim follows the link and downloads the file, what they receive is an MSI installer — a Windows package format so ubiquitous in enterprise environments that its presence barely registers as a decision. Running an MSI is what Windows administrators do. It is the expected, normal, trained behavior. The installer deploys four files and immediately launches an obfuscated CMD batch script via a Custom Action executed at SYSTEM privilege — a standard MSI installation mechanism that Windows provides precisely because legitimate software frequently needs elevated access during installation. The malware isn't exploiting a vulnerability here. It's using the platform's intended functionality. The batch script's first task is to silently install Node.js, the JavaScript runtime environment, if it isn't already present. On a properly administered Linux system with enforced package management and software installation policies, the appearance of an unauthorized runtime being installed mid-process would be an immediate and unambiguous alarm. On Windows, silently bundling and installing a runtime dependency during an MSI execution is so normal, so routine, so thoroughly baked into the culture of Windows software distribution, that monitoring systems frequently don't flag it. The attackers know this. They built the delivery chain around it.
What executes inside Node.js is a multi-stage JavaScript payload that never writes its active components to disk in any form that conventional signature-based detection can identify. Each stage decrypts the next using AES-256 encryption, entirely in memory, passing execution forward through a chain that leaves no recoverable artifacts on the filesystem. The final stage — the Remote Access Trojan itself, capable of receiving commands, executing arbitrary JavaScript, accessing the filesystem, running OS commands, and exfiltrating data — shelters its process activity under conhost.exe. To understand why this works, you have to understand what conhost.exe is and why it exists. The Console Window Host is a legitimate Windows system process, present on every Windows installation, that exists to broker communication between the legacy Win32 console subsystem and the modern Windows Desktop Window Manager. It has to run. It has to carry elevated trust. And because Windows's architecture is built on thirty years of backward compatibility obligations — layers of legacy subsystems that cannot be retired without breaking the vast installed base of software that depends on them — the operating system requires an entire category of opaque, privileged system processes doing work that is structurally difficult to audit from the outside. The svchost.exe instances multiplexing dozens of services under a single PID. The lsass.exe handling authentication. The dllhost.exe running COM objects. The conhost.exe managing console sessions. For a defender trying to distinguish legitimate system behavior from an attacker wearing a system process as a costume, this is the fundamental problem: the wardrobe is enormous, the costumes are high quality, and the platform itself insists they must be there. EtherRAT's authors did not create this problem. They simply dressed for the occasion.
The RAT beacons to its operators at approximately five-hundred-millisecond intervals, using randomized URL paths and file extensions designed to blend into ordinary background web traffic. Every five minutes, it performs a separate and more consequential lookup — one that sets EtherRAT apart from every piece of commodity malware in the current threat landscape, and one that renders the standard incident responder's toolkit nearly useless. Rather than contacting a hardcoded command-and-control server, or even a domain that could be seized through legal process, EtherRAT queries an Ethereum smart contract deployed on the public blockchain via openly accessible RPC endpoints. The smart contract stores a single piece of data: the current address of the actual C2 server. When the attacker needs to rotate infrastructure — because a server gets burned, because a hosting provider cooperates with law enforcement, because operational security demands a change — they execute a single blockchain transaction updating that stored address, paying a few dollars in gas fees, and every compromised host on the planet silently picks up the new location on its next polling cycle. There is no domain to seize. There is no registrar to serve with legal process. There is no hosting provider to contact. The Ethereum blockchain is globally distributed, cryptographically immutable, and publicly accessible — properties that exist because they are useful for legitimate financial applications, and that serve equally well as infrastructure for a command-and-control system that cannot be dismantled by any conventional means available to defenders or law enforcement.
This is not an isolated innovation. It is the leading edge of a technique propagating rapidly through the threat actor ecosystem. Researchers documented a separate campaign — GlassWorm — that embedded malicious code in invisible Unicode characters across more than one hundred and fifty GitHub repositories and used Solana smart contracts for the same C2 resolution purpose. A third campaign employed the Polygon blockchain. The pattern is clear enough to constitute doctrine: decentralized blockchain infrastructure is becoming the command-and-control substrate of choice for sophisticated threat actors, precisely because it inherits all of the properties that make public blockchains resistant to censorship and takedown. The same architectural decisions that make Ethereum attractive to financial privacy advocates make it attractive to state-level malware operators. The defenders have no equivalent asymmetry to exploit in return.
As for who built this, attribution remains formally unconfirmed, but the behavioral signatures are specific enough to be meaningful. Atos researchers noted structural and tactical similarities to tooling associated with Lazarus Group — the North Korean state-sponsored operation responsible for some of the most sophisticated and financially motivated intrusions of the past decade — and with MuddyWater, the Iranian threat cluster with a documented focus on government, defense, and telecommunications targets. The tools being impersonated — AzCopy, Kusto Explorer, LAPS — point unambiguously toward Azure-heavy enterprise environments. The intelligence value of owning the credentials of an administrator with full access to an organization's Azure Data Explorer telemetry, its Active Directory password management system, its system monitoring pipeline, is not abstract. That access is, in the language of the trade, the keys to the kingdom. And whoever built this infrastructure has been quietly collecting those keys, at industrial scale, since at least December of last year.
The Diagnosis
There is a reflex in security journalism, deeply ingrained and almost always wrong, that treats every successful attack as primarily a story about attacker sophistication. The write-ups appear within days. The threat actor is described as advanced, patient, well-resourced. The techniques are called novel. The victims are described as unlucky, or insufficiently defended, or operating in a threat environment that outpaced their defenses. The implicit conclusion — rarely stated but always present — is that the attack was essentially unpreventable, that determined adversaries at this level will find a way through, and that the appropriate response is better tooling, more vigilant monitoring, faster patching. This framing is not false. It is simply incomplete in a way that serves no one except the vendors selling the better tooling.
EtherRAT is sophisticated. Its operators are patient and well-resourced. The techniques are genuinely novel in their combination. All of that is true. What is also true, and what the standard write-up carefully avoids, is that almost every structural advantage the attackers enjoy in this campaign was provided to them, free of charge, by the platform their victims are running. The sophistication is real. But it is sophisticated exploitation of a pre-existing condition. And that condition has a name.
Consider conhost.exe again, because it is worth sitting with. The Console Window Host process is not a vulnerability. Microsoft did not make a mistake when they created it. It exists because Windows made a promise — decades ago, to millions of software developers and enterprise customers — that legacy applications would continue to run. That promise required a compatibility layer. The compatibility layer required a broker process. The broker process required elevated trust. And elevated trust, running under a system-level process that the operating system itself insists must be present, is the costume the attacker wore into your environment. The wardrobe that EtherRAT's payload dresses from — conhost.exe, svchost.exe, dllhost.exe, lsass.exe — is not a collection of security failures. It is the accumulated weight of thirty years of backward compatibility obligations, each one individually reasonable, collectively constituting an attack surface that no amount of endpoint detection engineering can fully collapse. Every generation of Windows security tooling is partly in the business of teaching machines to ask: is this legitimate system behavior, or is it an attacker inside a legitimate system process? That question is hard, expensive, and structurally permanent, because the platform will always require the processes that make it hard to answer.
The Node.js installation deserves the same analysis. The malware installs a complete JavaScript runtime as part of its delivery chain, silently, during an MSI execution, at SYSTEM privilege. On a properly administered Linux system — one running a distribution with enforced package management, a software allowlist, and standard privilege controls — this fails, or it screams. The package manager knows what is installed. Additions are logged. Privilege escalation during an installation process is visible and auditable in ways that make silent dropper chains structurally more difficult to execute. On Windows, silently bundling and installing a runtime dependency during an MSI execution is not suspicious. It is normal. It is what legitimate software does. Countless enterprise applications ship their own runtimes, their own copies of the .NET framework, their own Node.js environments, their own Java runtimes, because Windows has no enforced package management culture at the system level. The ecosystem developed around this reality. Administrators were trained inside it. The attackers simply followed the norms that the platform established, and those norms opened the door.
Then there is the ecosystem problem, which is the most uncomfortable part of the diagnosis because it implicates not just Windows but Microsoft's broader strategy. Every tool that EtherRAT impersonates — Kusto Explorer, AzCopy, LAPS, Sysmon, WinDbg, ProcDump — is either a Microsoft product or a tool that exists primarily to administer Microsoft infrastructure. The attack surface and the vendor ecosystem are the same object. When your administrative toolchain is substantially owned by a single vendor, and that vendor also controls the operating system, the identity management layer, the cloud platform, and the development environment, the attacker only needs to master one ecosystem to operate across your entire surface. Microsoft's genius — and this is genuine genius, not sarcasm — has always been integration. Everything works together. The seams are smooth. The experience is coherent. That coherence is also why a compromised Azure administrator credential in this ecosystem is not a partial breach. It is a systemic one. The integration that makes the platform attractive is the same property that makes the blast radius of a successful compromise so large.
Who, then, is actually vulnerable? The honest answer is: most Windows-based systems administrators, DevOps engineers, and security analysts working in Azure-heavy enterprise environments who source tools from web searches rather than from verified internal software repositories. Which is most of them. This is not an indictment of individuals. The practice of searching for tools and downloading them from the web is not reckless behavior on Windows — it is the trained, normal, culturally transmitted behavior of Windows administration. It is how the ecosystem works. Compare this to the administrative culture that developed around Linux, where the package manager is the canonical and expected source for software, where repositories are signed and verified, where the idea of downloading an executable from a website and running it sits outside the normal workflow in a way that creates natural friction against exactly this class of attack. The difference is not intelligence or diligence. It is culture, and culture is downstream of platform design. Windows created an ecosystem in which running downloaded executables is normal. Linux created one in which it isn't. EtherRAT's victim selection mechanism exploits the first of those cultures with precision. It would have to be entirely redesigned to threaten the second, and even then it would be working against the grain rather than with it.
The attackers are sophisticated. They are also, in a precise and important sense, opportunists — exploiting not a flaw in a system but the system's own design philosophy, turned against its users. That is a harder problem than a CVE. You cannot patch a design philosophy. You cannot issue a hotfix for thirty years of backward compatibility decisions. You cannot add an enterprise feature that retroactively installs a package manager culture in an ecosystem that was never built around one. What you can do — what the evidence of this campaign argues for with uncomfortable clarity — is make a different choice about the platform your administrators are running. Not as a punishment for the platform's history. As a rational response to what that history has produced.
The Solution
Let's be precise about what we are not saying. We are not saying that migrating your administrative workstations to Linux will make you invulnerable. We are not saying that Linux has no attack surface, produces no malware, and attracts no sophisticated threat actors. We are not making a religious argument about open source software or the moral failings of proprietary ecosystems. We are making a narrower and more defensible claim: that the specific structural conditions which made EtherRAT possible — the process masquerade problem, the silent runtime installation norm, the downloaded-executable culture, the monoculture blast radius — are properties of the Windows ecosystem, not of computing in general, and that administrators working from Linux-based workstations would have presented this particular campaign with a target that its entire architecture was not designed to compromise. That is not everything. It is enough to be worth taking seriously.
Start with the immediate mitigations, because they are real and some organizations are not ready to move. Internal software centers — curated, authenticated, internally hosted repositories of approved administrative tools — eliminate the attack's entry point entirely. If your engineers source every tool from a verified internal portal rather than a web search, the SEO poisoning becomes irrelevant. The facade repositories become invisible. Behavioral monitoring configured to alert on outbound connections to Ethereum RPC endpoints — specifically the public node services that EtherRAT uses to resolve its C2 address — will catch active infections before significant damage is done. Network-level blocking of Ethereum JSON-RPC traffic, while blunt, is effective against this specific technique. Privilege restriction, enforced software installation policies, and application allowlisting all raise the cost of the delivery chain substantially. These measures are worth implementing. They are also, stated plainly, patches on a structural problem. They treat the symptoms competently while leaving the underlying condition intact. The next campaign will find different symptoms to produce.
The structural solution is to migrate the administrative workstation. Not the servers — the workstation. This distinction matters because it is where the resistance always collapses into impracticality objections, and those objections are, in 2026, largely out of date. The Windows servers stay. The Active Directory domain stays. The Azure infrastructure stays. What changes is the machine the administrator is sitting in front of, and that change eliminates the attack surface that EtherRAT — and the entire class of campaigns it represents — depends on.
Every tool that EtherRAT impersonated has a Linux-native equivalent or a Linux-compatible administration path, and working through them is not a theoretical exercise. AzCopy, the Azure file transfer utility that featured prominently in the campaign's impersonation list, runs natively on Linux — Microsoft ships and maintains the Linux binary directly, and has for years. The Azure CLI, cross-platform and fully supported, covers the administrative surface that Kusto Explorer addresses for most operational workflows; for teams that specifically require the KQL desktop experience, Azure Data Studio runs natively on Linux and provides a full query environment against Azure Data Explorer. LAPS — the Local Administrator Password Solution — integrates with Linux workstations through SSSD and adcli for organizations still running it; for organizations willing to take the larger step, replacing LAPS with a proper secrets manager removes the Windows dependency entirely while improving the security posture the tool was designed to address. Sysmon, the Windows system monitoring utility, has no direct Linux port because it doesn't need one: auditd, the Linux auditing subsystem, provides equivalent and in many respects superior telemetry at the kernel level, and eBPF-based monitoring tools like Falco offer real-time behavioral detection that is architecturally cleaner than anything available in the Windows ecosystem. PsExec — remote execution across Windows hosts — is replaced by SSH with proper key management, which is more auditable, more scriptable, and more secure than the NTLM-authenticated remote execution model PsExec relies on. WinDbg for kernel debugging presents the most legitimate remaining challenge, though remote kernel debugging of Windows targets via KDNET functions from a Linux host, and the honest answer for most organizations is that kernel-level Windows debugging is a specialist workflow that represents a small fraction of the administrative surface being protected.
Administering Windows infrastructure from a Linux workstation is not an exotic configuration requiring heroic engineering. It is winrm over HTTPS for PowerShell remoting. It is any of several mature RDP clients — Remmina, FreeRDP — for graphical access to Windows servers. It is the Windows Admin Center, which is browser-based and platform-agnostic. The Windows servers do not know or care what operating system their administrator is running. They care about credentials and protocols, and Linux handles both. What changes on the administrator's workstation is everything that EtherRAT depended on: the MSI execution environment disappears. The Windows process namespace — with its wardrobe of system process costumes — disappears. The silent runtime installation norm disappears. The downloaded-executable culture, to the extent that Linux's package management infrastructure and administrative norms provide friction against it, becomes structurally harder to exploit. The attack does not port. It was not designed to port. Its entire architecture assumes a Windows target, because its authors built it for the ecosystem they found their victims in.
The timing of this argument is not accidental. Windows 10 reached end of life in October 2025. The enterprise hardware refresh cycle that end-of-life triggers is happening right now, in IT procurement departments across every sector. Organizations are evaluating which machines meet Windows 11's TPM 2.0 requirements and which do not, and they are making decisions about what to do with the hardware that doesn't qualify. Linux runs well on that hardware. The tooling gap that once made Linux administrative workstations a genuinely difficult proposition has largely closed. Visual Studio Code is native on Linux and is the dominant editor across the industry regardless of platform. The entire JetBrains suite runs on Linux. The complete cloud administration stack — Azure CLI, AWS CLI, Google Cloud SDK, kubectl, Terraform, Ansible — is Linux-native and in many cases Linux-first. The container and Kubernetes ecosystem that now underlies most enterprise infrastructure was built on Linux and runs most naturally there. The argument that Linux cannot support serious enterprise administrative work was never entirely true and is now comprehensively false.
The Linux desktop share numbers reflect this. Steam Deck normalized Linux as a serious computing platform for a generation of younger engineers who grew up understanding that the operating system is a choice rather than a given. The European enterprise market, already moving toward Linux desktop deployments for sovereignty reasons that the Dutch central bank's Lidl decision illustrates with crystalline clarity, is generating organizational experience and institutional knowledge that is lowering the migration cost for everyone who follows. The German state of Schleswig-Holstein is migrating thirty thousand workstations. The French gendarmerie has been running Ubuntu desktops for over a decade. These are not hobbyist experiments. They are operational deployments at scale, generating the documentation, the tooling, and the organizational templates that make the next migration easier than the last one.
The question for an enterprise IT director conducting a hardware refresh right now is not whether Linux can support their administrative workflows. The question is what they are concretely getting in return for the Windows license cost, the endpoint security stack cost, the EDR vendor cost, and the permanent operational overhead of managing a platform whose own design keeps handing sophisticated attackers a wardrobe of system-process costumes and a culture of MSI-installer trust to exploit. EtherRAT did not create that cost. It revealed it. The cost was always there. It will remain there, attached to every future campaign that follows the same architectural logic, until the platform underneath it changes.
The mitigations are real. Implement them if you are not ready to move. But know what they are: they are the security equivalent of weatherproofing a building that was designed without a roof. Competent, necessary, and not the same thing as building a roof.
The Verdict
The administrators who fell for EtherRAT were not careless. This point cannot be made too clearly, because the instinct when reading about a successful attack is to locate the human failure — the click that shouldn't have been clicked, the verification step that was skipped, the policy that wasn't followed. That instinct is comfortable because it implies that the problem is behavioral and therefore correctable through training, awareness programs, and more strongly worded acceptable use policies. It is also, in this case, wrong. The engineers who downloaded a malicious MSI from a convincing GitHub repository that ranked at the top of a Bing search result for a tool they use professionally were doing exactly what their platform, their ecosystem, and their professional culture trained them to do. They searched for a tool. They found what looked like the right repository. They downloaded the installer. They ran it. Every step in that sequence is normal Windows administrative behavior, and the attack was engineered with full knowledge of that normality, by people who understood the culture of the ecosystem they were targeting well enough to build a perfect trap inside it.
That is not an excuse. It is a diagnosis. And the diagnosis points not at the people but at the conditions that made their normal behavior dangerous. The platform that requires opaque privileged system processes as a structural feature. The ecosystem that normalized downloaded executables and silently bundled runtimes as standard installation practice. The monoculture that made every compromised Azure admin credential a master key rather than a partial one. The search engine visibility that the attackers manipulated because searching for tools from the open web is what Windows administrators do. None of these conditions were created by the victims. They were inherited from the platform, and they will be inherited by every administrator who stays on it.
The security industry's preferred response to campaigns like EtherRAT is to recommend more layers. Better EDR. More aggressive behavioral monitoring. Stricter application allowlisting. Zero trust network architecture. Threat intelligence feeds. All of it calibrated to make the existing platform survivable rather than to question whether the platform is the right foundation for the work being done on it. This is understandable — the industry is largely in the business of selling those layers, and the installed base is large enough that questioning the platform feels impractical rather than analytical. But impractical is doing a lot of work in that sentence, and in 2026 it is doing more work than the facts support. The migration path exists. The tooling exists. The organizational precedents exist. What remains, in most enterprises, is inertia and the reasonable fear of transition cost. Those are real considerations. They are not permanent ones.
What the verdict comes down to is this: EtherRAT worked because the platform made it easy to work. Not easy for amateurs — the blockchain C2, the dual-repository architecture, the fileless payload chain represent genuine engineering investment. But easy in the sense that the platform provided, without any effort on the attacker's part, the process masquerade capability, the runtime installation norms, the executable trust culture, and the monoculture blast radius that the attack depended on. The attackers brought the sophistication. Windows provided the conditions. And the conditions are not going to change, because they are not bugs. They are the product.
The Ironic Twist
There is one thread the Atos report does not pull, and that none of the coverage has pulled, and it is the one that reframes everything that came before it. It requires a small inference, but the inference is grounded in operational security research, documented threat actor behavior, and the kind of logic that holds up under scrutiny. It is this: the people who built EtherRAT are almost certainly not running Windows.
Start with attribution. Lazarus Group — the North Korean state-sponsored operation whose behavioral fingerprints appear in EtherRAT's tooling — operates out of an infrastructure that has been extensively documented by researchers at Kaspersky, Mandiant, and CISA over the past decade. North Korea's own computing environment runs on Red Star OS, a domestically developed Linux distribution modeled loosely on macOS. Lazarus operatives working abroad, typically stationed in China, Southeast Asia, and increasingly Eastern Europe under commercial cover, have been documented in multiple incident response reports and indictments using Ubuntu and Debian-based development environments, with macOS appearing in several cases where the operational profile suggests a preference for Unix-like tooling. MuddyWater, the Iranian cluster, has a similarly well-documented preference for Linux-based development infrastructure, consistent with Iranian state computing culture which has leaned heavily on open-source and Linux-based systems as a matter of both policy and practical sovereignty. Neither group has been documented operating primary development infrastructure on Windows. The platform they spend their professional lives attacking is not the platform they work from.
This is not coincidence, and it is not ideological. It is operational security at its most rational. You do not run the platform you are actively weaponizing. The reasons are practical and layered. A Windows development environment introduces the same attack surface against the developer that the developer is exploiting against targets — and sophisticated state-level operators are themselves targets of counterintelligence operations by adversary services who would love nothing more than to compromise a Lazarus developer's workstation. Beyond that, Windows telemetry, Windows Update infrastructure, and Windows licensing systems all create outbound network traffic and identifier exposure that a careful operator wants to minimize. A Linux workstation with a hardened network profile, a VPN, and no mandatory phone-home infrastructure is a substantially cleaner operational environment for someone whose continued freedom and effectiveness depends on not being found.
The testing problem — the obvious objection — is real but solved, and solved in a way that itself tells you something. EtherRAT's payload was clearly tested against Windows Defender, against common EDR products, against the specific process environment of Windows 10 and 11, against the MSI installation pipeline with its Custom Action execution model. That testing happened on Windows. But it happened on Windows running in virtual machines — isolated, snapshotted, restorable, and critically, air-gapped from any network infrastructure that could expose the developer's actual location or identity. This is standard practice across sophisticated threat actor groups and is documented explicitly in the operational security guidance recovered from several dismantled APT operations. The VM is the laboratory. It is brought up, tested against, snapshotted for rollback, and kept entirely separate from the host environment the developer actually works in. The host is Linux. The VMs are Windows. The malware is built and the C2 infrastructure is managed from the host. The payload behavior is validated inside the VM. When the test is done, the VM is suspended or destroyed. Nothing that happens inside it touches the developer's real network stack.
This workflow is not exotic. It is the standard approach of any competent developer doing security-sensitive work, and it is substantially easier to execute cleanly on Linux than on Windows precisely because Linux's hypervisor ecosystem — KVM, QEMU, libvirt — integrates naturally with the host environment in ways that make VM network isolation straightforward and auditable. The irony deepens: the tools that make it easy to safely develop Windows malware on a Linux host are the same open-source virtualization tools that Linux administrators use for entirely legitimate infrastructure work.
So here is the complete picture. A development team, almost certainly state-sponsored, builds a campaign of considerable sophistication targeting Windows administrators. They spend months poisoning search results, constructing forty-four GitHub facade repositories, engineering a fileless JavaScript RAT with Ethereum-based command-and-control, and validating that every stage of the payload chain survives Windows Defender and hides cleanly under conhost.exe. They do all of this from Linux workstations, using Windows virtual machines as a testing laboratory, keeping their actual operational environment clean, auditable, and free of the attack surface they are exploiting in their targets. They then deploy the campaign and watch the beacons arrive — connections from compromised Windows machines, reporting back through an Ethereum smart contract that no law enforcement agency can seize — from a terminal that is not running Windows.
They know what Windows costs the people running it. They have priced it with more precision than any security vendor's threat report. They mapped the process masquerade problem, the MSI trust culture, the silent runtime installation norm, the monoculture blast radius — mapped all of it carefully enough to build an industrial-scale operation around exploiting it. And then they exercised the choice that the administrators they are targeting have not yet made.
That choice is available to you. The attackers already know it is the right one. The only remaining question is how long it takes the defenders to reach the same conclusion.
Jonathan Brown (A.A.Sc., B.Sc) writes about cybersecurity infrastructure, privacy systems, the politics of AI development and many other topics at bordercybergroup.com and aetheriumarcana.org. Border Cyber Group maintains a cybersecurity resource portal at borderelliptic.com . He works from a custom-built Linux platform (SableLinux™) which is currently under development and fully documented at https://github.com/black-vajra/sablelinux.
If you would like to support our work, providing useful, well researched and detailed evaluations of current cybersecurity topics at no cost, feel free to buy us a coffee! https://bordercybergroup.com/#/portal/support
Member discussion: