ROMULUS: Analysis of a New Multi-Payload ClickFix Delivery Platform

We recently reported how cybercriminals use ClickFix to deliver malware loaders that are then leveraged to deploy final payloads such as RATs or ransomware on victim machines.

On September 28, Huntress reported a campaign that adds a new link to that common attack chain: threat actors abused ChatGPT’s Custom GPTs that were programmed to present to victims links to pages serving the ClickFix lures that are then used to deliver loaders.

The server hosting the ClickFix script in that campaign was 96.62.224[.]81 and the trojanized software used to sideload malware included a Canon application (ISOSimple.msi) and Stardock DeElevation (IconEdit2Turb.msi).

While investigating an independent incident, we noticed the exact same malware being delivered via another server, 86.109.75[.]7. Beyond that, the new server hosted a panel called ROMULUS. Investigating that panel, we identified a new multi-payload shared ClickFix delivery platform. Here, we detail how ROMULUS was used in two delivery chains:

• The same Stardock DeElevation sideloading package reported by Huntress was observed on another server running ROMULUS.
• A separate chain delivering the LegionLoader malware. This second route served a PowerShell script that reached out to orbitflownetwork[.]lol to download a nested encrypted 7z file with an artificially inflated executable. That executable was identified as LegionLoader, a malware loader that has been active since 2019 and is also known as CurlyGate, RobotDropper and Satacom.

The identity of the operator behind the platform and common ownership of the final malware families are unknown. ROMULUS may be a privately operated panel, a commercial cybercriminal delivery service, an affiliate framework, or software that has been copied between operators. Notably, we have no evidence that this panel is related to the RomulusLoader reported by Proofpoint as being used by the Silver Fox threat actor earlier this year.

ROMULUS Delivery Infrastructure

By pivoting on VirusTotal (entity:url title:"Romulus" path:"/login") and Shodan (http.title:"Romulus"), we identified six IP addresses exposing the same dark-themed authentication frontend with the ROMULUS name and shield icon shown below:

• 62.224[.]81 (originally reported by Huntress as part of the Custom GPT campaign)
• 109.75[.]7 (involved in the incident we analyzed independently)
• 240.151[.]223
• 94.145[.]224
• 152.224[.]118
• 27.248[.]127

All have a login page with a JavaScript that POSTs the supplied username and password to /api/login, stores a returned token, and redirects successful logins to /.

Additionally, 86.109.75[.]7 exposed a page /stats.htm with the same ROMULUS theme. That page showed statistics for “unique installs” and “all runs” including a live counter, a 14-day timeline, a history log, and a country breakdown. Those statistics could allow operators to compare campaign reach and execution over time.

Beyond these pages, ROMULUS exposes two relevant endpoints:

• /s/<token> downloads a PowerShell staging script that prepares the victim and decides what to fetch next
• /app/<same-token> downloads a trojanized MSI installer carrying a malware loader

The tokens are all 12-character hexadecimal and may be used to represent a victim, campaign, assignment, or delivery job. The table below lists the tokens we observed on 86.109.75[.]7.

We can group these tokens into three categories:

• 19481b28bd67 serves the Stardock DeElevation delivery chain that we detail below in the ‘Route A’ section. That chain is exactly the same as reported by Huntress on another server 62.224[.]81/s/50d6565cf39e.
• 6c67e0336a7b uses the same PowerShell staging mechanism but an entirely different payload route. That script does not request an MSI file from a matching /app/ Instead, it reaches out to orbitflownetwork[.]lol and downloads an encrypted archive chain that we detail below in the ‘Route B’ section.
• The other tokens point to other MSI files which we have not analyzed.

The variety of routes – including or not MSI files – shows that ROMULUS is a reusable delivery backend rather than a single hard-coded malware server. There are many other tokens and MSI files reported on VirusTotal, which reinforce this conclusion and show that ROMULUS is being actively used at scale.

The figure below depicts the different servers and routes we have observed.

Payload Routing and Malware Delivery

We recovered two PowerShell staging scripts from 86.109.75[.]7/s/6c67e0336a7b and 86.109.75[.]7/s/19481b28bd67. They are both heavily obfuscated and generated from the same template, which is evidenced by common scaffolding.

Each script saves its own path to $env:__ST using $MyInvocation.MyCommand.Path, reconstructs code from a large array of integers using a sample-specific key, and executes the reconstructed text with [scriptblock]::Create. The reconstructed text is an inner layer that uses the same obfuscation technique for selected strings. The numerical keys, variable names, and payload-specific code change per script, while the overall control flow is similar. Both scripts also delete themselves before exiting.

Here, we explore the two routes observed, including the differences in the staging scripts and remainder of the chain in each case.

Route A: Stardock DeElevation

The 19481b28bd67 staging script creates a .NET WebClient with a Chrome/131 user-agent and a TLSv1.2 connection to download the trojanized hxxp://1450003207/app/19481b28bd67/IconEdit2Turb.msi. In that URL, 1450003207 is decimal IPv4 notation for 86.109.75[.]7.

The script retries the download up to three times with short randomized delays, writes the downloaded installer to %TEMP% with a GUID-prefixed filename, runs Unblock-File, then starts msiexec.exe with /i, /qn, and /norestart before deleting itself.

The downloaded MSI has a creation timestamp of 25 September 2026, identifies itself as “Stardock Smart DeElevation Tool“, targets x64 systems and installs on %LOCALAPPDATA%\Programs\Stardock Smart DeElevation Tool\. The installer contains a WixShellExec custom action that launches DeElevate64.exe after installation.

DeElevate64.exe is the legitimate host file used to load further malware and is one of the seven components present in the MSI file, described in the table below.

Upon execution, DeElevate64.exe imports DeElevator64.dll from its application directory. The packaged DeElevator64.dll is patched to introduce a dependency on I++u.dll, which moves execution to the malicious loader that uses the remaining files in the MSI package. The remaining loader stages are exactly the same as described by Huntress.

Route B: LegionLoader

The 6c67e0336a7b staging script uses a different delivery mechanism, depicted in the image below.

The staging script hides the PowerShell console through dynamically defined GetConsoleWindow, ShowWindow, and MoveWindow calls, then downloads orbitflownetwork[.]lol/dl/J8QkZUVJgV.7z and the legitimate 7zr.exe utility from GitHub.

The script verifies the 7z signature on the downloaded archive, checks that the downloaded 7zr.exe begins with an MZ header and exceeds a minimum size, then uses 7zr.exe to extract the password-protected J8QkZUVJgV.7z file using password iQQaQ7Yo41rbZ – hardcoded in the script – without displaying a console window.

The use of the legitimate 7-Zip binary avoids embedding an archive library in the loader and makes the extraction step look like an administrative task unless the full process lineage is considered. Encrypting the 7z header hides the file names and contents from file scanners.

Once extracted, J8QkZUVJgV.7z reveals another encrypted 7z file (CarJqRHyOtBu3mI.7z) and a 20-byte text file containing a password for its extraction (RkfZvXZt6XtfuoZsHfSr). After extraction, CarJqRHyOtBu3mI.7z reveals five high-entropy .bin files and a random-name executable with 882,716,672 bytes, as summarized in the table below.

The five .bin files have a fixed-size high-entropy layout that suggests encrypted or chunked content. However, no known container structure emerged from RC4, AES, XOR, or BabaDeda-style storage tests, and the files were never referenced in the final PE. They may be decoys, padding, or ancillary resources used by a code path we did not trace, but that does not affect the full communication between LegionLoader and C2.

The large size of the single EXE file is artificial. That executable is a valid x64 PE, but approximately 881.7 MB belongs to the raw .reloc section. The PE relocation directory describes only 108 bytes of actual relocation data, while most of the oversized section is a repeating 16-byte value. This repetitive padding compresses extremely well, so the attacker can distribute an archive under 1 MB that expands to a file large enough to exceed upload limits, sandbox budgets, or static-analysis thresholds.

The meaningful code and encrypted payload data are near the beginning of the file. This 2 MB prefix retained the PE headers, code, configuration, cryptographic material, and two packed stages:

• Stage 1 uses the Windows CryptoAPI with a PROV_RSA_AES provider and a plaintext key blob for CALG_AES_256 to decrypt an embedded buffer, remove PKCS#7 padding, and reverse the entire plaintext buffer, which contains stage 2.
• Stage 2 is position-independent shellcode that contains a second decryptor and custom image loader. The shellcode repeats the AES-256-CBC and byte-reversal sequence, then manually maps the resulting 475,648-byte PE (which we call stage 3) by allocating memory, resolving imports, applying relocations, and invoking its entry point.

LegionLoader Analysis

The final PE (stage 3) exposes a LegionLoader configuration that is similar to what was  reported by other researchers:

• smashshape[.]com is the C2 server, with endpoints /nfront.php and /nback.php. The former is used for registration and command retrieval, while the latter is used to report results.
• Chrome Local State key handling is used to retrieve keys and collect sensitive information stored on the Chrome browser of victims.
• A distinctive RC4/Base64 message framing that we discuss below.

Messages are sent via WinHTTP with declared Content-Type: application/x-www-form-urlencoded. However, instead of key=value form fields, the request body contains one string generated as follows. The client serializes a compact binary object, encrypts it with a 31-byte RC4 key recovered from the stage 3 PE, and base64-encodes the result. Responses are decoded in the opposite direction. The same framing is used for registration, commands, and result traffic.

Each decoded message starts with a 32-bit little-endian field count. Every field then contains an identifier, a type, a length, and a raw value. All observed fields used type ‘4’ regardless of the type of underlying value (string, raw bytes, integers, Booleans).

The stage 3 PE contains a field identification table with 98 entries. We could assign specific roles to the nine entries shown in the table below.

We divided these messages into the following phases:

• Registration and host identity. Upon registration, the client reports to the server the first five values shown in the field ID table above. Most are self-explanatory, but the machine ID is relevant. That ID is derived from the system volume serial by applying CRC32 five times in succession and formatting the final value as uppercase hexadecimal. This identifier is stable across repeat executions on the same installation and gives the C2 backend a compact way to identify returning systems.
• Tasking and payload handling. Tasking is field-driven rather than a fixed command packet. The overloaded 0x6976C50E field can carry control text, such as sleep, a download directive, a URL, or result text, depending on context. A separate field (0xB7117366) carries PowerShell code to be executed. When the server instructs the client to retrieve an encrypted payload, field 0x19BD28E4 supplies a raw 16-byte runtime key. The downloaded data is then processed through a separate two-layer RC4 path, first with the runtime key and then with a fixed 16-byte key embedded in the client. This downstream decryption path is distinct from the 31-byte key used to protect the C2 messages themselves.

Results are reported to /nback.php using the same serializer and RC4/Base64 framing.

Detection and Indicators

The table below lists threat detection opportunities ordered from infrastructure to execution and C2. Web fingerprinting and token hunting are useful before a host is compromised. Script and process telemetry cover the ClickFix and staging phases. File and image-load telemetry catch the two payload routes after a download. Network detections for LegionLoader require HTTP visibility or TLS interception while the field IDs and RC4 framing are most useful during packet or sandbox analysis.

MITRE ATT&CK Summary

Indicators of Compromise