There Is No C2 Server To Block: EtherRAT, TukTuk, and Command and Control Built Entirely on SaaS

Block the command and control server and the intrusion stops. That has been the shape of the advice for twenty years, and it is the reason threat reports lead with IP addresses.

In an intrusion The DFIR Report documented in April 2026, ending in domain-wide deployment of The Gentlemen ransomware, there was no server to block. The configuration came off the Ethereum blockchain. The primary C2 ran through ClickHouse and Supabase. The fallbacks were Ably, Dropbox, plain HTTP and GitHub Issues, with an Arweave dead drop underneath.

Every one of those is a product a company might be paying for. Blocking the C2 means blocking your own vendors.

//A Sysinternals Tool That Was Not

Initial access was an MSI masquerading as Sysinternals RAMMap.

That choice deserves the same attention as the ManageEngine lure in the Akira intrusion. RAMMap is a memory analysis utility from Microsoft's own Sysinternals suite. Nobody downloads RAMMap casually. You go looking for it when you are investigating a memory problem on a server, which means the person running it is technical, is probably an administrator, and is running it deliberately on a machine that matters.

The installer deployed a portable Node.js runtime and used it to execute obfuscated JavaScript, with persistence through registry Run keys. Portable Node is the same idea as ChainDrop reaching for Bun: ship an interpreter nobody has written rules for, and the payload is just text it happens to be reading.

EtherHiding

EtherRAT does not carry its configuration. It contacts 1rpc[.]io - a public Ethereum RPC endpoint - and reads configuration data stored on-chain, from contracts 0xdf0b529043ef7a2bb9111bad26de624a326bacf9 and 0x5953f27F044779a3AFCd2BF56a4B712583Dd2E4e.

The technique has a name now, EtherHiding, and its properties are worth being precise about. The data is public, permanent and unremovable. There is no host to serve an abuse complaint to. Updating the configuration costs a transaction fee. And the read looks like an HTTPS request to a JSON-RPC endpoint, which on a developer's workstation is entirely ordinary traffic.

The trade is that everything the operator stores is world-readable forever, which is why the chain holds pointers rather than payloads.

//TukTuk: C2 As A SaaS Integration Problem

After reconnaissance, the operators deployed a framework The DFIR Report had not seen before, called TukTuk.

OASIS Security later obtained and analysed it. It has four components: a Windows agent written in C#, an independently implemented Linux agent, a backend, and a management panel built in Node.js and Electron. The panel does what you would expect - agent management, remote commands, file operations, screen capture, process control - plus credential harvesting through spoofed Windows Security dialogs, which is the cheapest reliable way to get a password out of a user who has already decided the machine is trustworthy.

The channel list is the point

Primary C2 ran over ClickHouse and Supabase. Secondary channels could use Ably, Dropbox, direct HTTP or GitHub Issues. There was also Arweave dead-drop resolution using Drive-Id a6278417-39f4-407e-90bf-599f74726e66. The malicious log4net.dll OASIS analysed carried references to Slack, GitHub and Dropbox settings alongside the domain borjumaniya[.]store.

Consider what each of those actually is on your network. ClickHouse is an analytics database - a data engineering team may well be pushing to ClickHouse Cloud all day. Supabase is a backend platform your developers might be building on. Ably is realtime messaging infrastructure, used by exactly the sort of application that needs a persistent bidirectional channel. Dropbox is Dropbox. GitHub Issues is GitHub.

None of these are compromised. None of them are abused in a way the vendor could reasonably detect from their side. The operators simply signed up.

And the traffic is not merely allowed, it is correct. Beaconing over Ably looks like an application using Ably, because it is an application using Ably. TLS inspection shows you a real Ably endpoint with a real Ably certificate carrying real Ably protocol messages. The malicious part is the content, and the content is what you cannot see.

What this does to your detection strategy

Domain blocking is finished as a primary control here. So is destination reputation - every destination has a perfect reputation.

What is left is the shape of the traffic and the identity of the process making it. A finance workstation talking to Supabase is odd not because Supabase is bad but because that host has no reason to. A node.exein a user profile directory holding a persistent connection to Ably is odd regardless of where Ably sits on your allowlist. The question stops being "is this destination malicious" and becomes "does this host have any business reaching it", which is a much harder question to answer at scale and the only one that still works.

//Three Days of Ordinary Administration

The middle of the intrusion is unremarkable, which is the point. Kerberoasting. Credential discovery aimed at administrative accounts. GoTo Resolve - commercial remote management software - deployed laterally across multiple systems, exactly as an MSP would deploy it. RDP, SMB and WinRM for movement. NetExec, Mimikatz, LSASS and NTDS dumping for credentials. Rclone to push bulk data to Wasabi.

Wasabi is S3-compatible object storage sold on price. Rclone is a well-regarded open-source tool that thousands of administrators use for backups. An Rclone process uploading to Wasabi at high concurrency is the single loudest thing in the whole intrusion and it is also exactly what a legitimate backup job looks like.

The distinguishing features are volume, direction, timing and whether that host has ever done it before. This is the same lesson as the nine-hour SFTP session in the Akira intrusion: bulk egress is where ransomware operators are most visible and least often watched.

Then the destruction

Three days in, the operators disabled Microsoft Defender protections, added antivirus exclusions, stopped virtual machines, deleted shadow copies, cleared event logs and removed forensic artifacts. Then they pushed a malicious Group Policy Object that executed staged ransomware binaries out of SYSVOL and NETLOGON via scheduled tasks.

GPO deployment is the most efficient ransomware delivery mechanism available on a Windows domain, and it is a good demonstration of what domain admin actually means. The attacker does not need to touch each machine. They change one policy object and the domain does the work, using the mechanism built to make administration easy.

Stopping virtual machines before encrypting is a detail worth noting. A running VM holds its disk files open and they encrypt badly or not at all. Shutting them down first is an operator who has done this before.

//The EDR Research Programme

The most unusual thing OASIS found was not malware. It was coursework.

Alongside the framework sat BYOVD material: eb.sys, which matches a GentleKiller variant, and wsftprm.sys, plus testing artefacts aimed at K7 antivirus, TFSysmon and Safetica. And a four-lesson progressive training structure covering existing EDR killers, methodology for hunting vulnerable drivers, kernel-level research, and zero-day driver vulnerability research.

That is a syllabus. It teaches a member to go from using someone else's EDR killer to finding their own kernel bugs, in four steps.

The operational implication is straightforward and unwelcome: a group with an internal curriculum for driver vulnerability research is not going to be stopped by revoking the drivers currently on the Microsoft vulnerable driver blocklist. Blocklists handle the known set. The curriculum exists to produce things that are not in it yet. Driver blocklisting remains worth doing, and it should be understood as raising cost rather than closing the door.

//The AI Claim, Stated Precisely

Both reports describe TukTuk as AI-generated, and this has been repeated widely. It is worth being exact about what the evidence is.

The DFIR Report describes the framework as "AI-generated". The OASIS report's support for this is a single figure with the caption "Screenshot indicating TukTuk C2 development was carried out using artificial intelligence". That caption is the sole explicit claim in the report, and the screenshot's contents are not detailed beyond it.

So: researchers who had access to the operators' own material concluded AI was used in development, and they appear to have based that on something they saw in that material rather than on code analysis. That is meaningful evidence. It is not the same as a demonstrated finding, and this article does not treat it as one.

It also would not change much if confirmed. A four-component C2 framework with a Node and Electron panel is a weekend of work for a competent developer. The interesting capability in this intrusion is the channel design and the driver research programme, and neither of those is the sort of thing a model hands you.

//Detection Opportunities, Ranked

Bulk outbound to object storage from a host that has never done it. Rclone to Wasabi, at concurrency, for hours, before encryption. The loudest event in the intrusion.

Persistent SaaS connections from hosts with no business reason. Not the destination, the pairing. Build the allowlist per host group rather than per domain, and accept that this is work.

Portable runtimes in user-writable directories. A Node.js binary under a user profile with a registry Run key pointing at it, executing obfuscated JavaScript. Neither half is rare; together they are the initial access.

GPO modification and scheduled task creation in SYSVOL or NETLOGON. Extremely low volume, extremely high value. Directory service change auditing catches this and almost nobody reads it.

RMM installation where the organisation does not use that product. GoTo Resolve here, RustDesk in the Akira intrusion. Same problem, same answer: allowlist, not blocklist.

Defender tampering and AV exclusion changes. Late in the chain, but it immediately precedes encryption and it is one of the few signals with almost no legitimate volume.

//Sourcing and Uncertainty

All intrusion detail - the RAMMap MSI, EtherHiding, the channel list, Kerberoasting, GoTo Resolve, Rclone to Wasabi, the GPO deployment and the three-day timeline - is from The DFIR Report's 11 May 2026 flash alert. All framework detail - the four components, the panel capabilities, the spoofed credential dialogs, the BYOVD drivers and the training structure - is from OASIS Security's 31 August 2026 analysis.

One indicator does not reconcile, and you should know before you hunt on it. The two reports give different SHA256 values for log4net.dll: 19021e53... from The DFIR Report and 096ec378... from OASIS. The most likely explanation is two builds of the same component, since OASIS analysed the framework itself while The DFIR Report analysed one deployment of it, and TukTuk is versioned - their archive is named tuktuk-v2.0_10.zip. But that is inference. Hunt for both, and do not treat either as the canonical hash.

The interpretation is mine: the argument that SaaS C2 breaks destination-based blocking as a category rather than as an instance, the reading of the RAMMap lure as administrator-selecting in the same way the ManageEngine lure was, the point about shutting down VMs before encryption, and the assessment that the driver research curriculum matters more than the framework does. The AI-generation claim is reported above exactly as strongly as its sources support it and no more.