Fake RVTools Repos on GitHub Deploy a Rogue Action1 RMM Backdoor

Virtualization administrators download standalone utilities onto management jump hosts as a matter of routine, and RVTools sits near the top of that list. Rob de Veij originally developed it, and Dell Technologies now stewards it. It talks to vCenter Server and ESXi hosts through the VMware VI SDK and pulls detailed inventory on virtual machines, datastores, cluster configurations, and zombie VMDKs, so it usually runs on heavily privileged administrative workstations. Anyone searching for an RVTools installer almost certainly holds credentials to the virtualization management plane, Active Directory, or both. Attackers know this.

A campaign uncovered in early November 2026 removes custom malware from the intrusion chain altogether. Two counterfeit GitHub repositories, github[.]com/rvsphex/RVTools and github[.]com/rvnexa/RVTools, pose as distribution mirrors for the utility. Instead of the .NET-based VMware auditing tool, they serve an unsigned Windows Installer package labeled “Dell Setup.” That MSI drops no custom C2 implant, injects no shellcode into svchost.exe, and runs no obfuscated PowerShell loader. It silently installs version 6.0.664.1 of the legitimate, digitally signed Action1 Remote Monitoring and Management (RMM) agent, preconfigured to enroll the machine in an attacker-controlled Action1 cloud tenant.

When the installer finishes, the adversary holds an interactive, persistent NT AUTHORITY\SYSTEM foothold on the endpoint. The binary on disk is genuinely signed by Action1 Corporation and talks over standard TLS to legitimate vendor infrastructure, so signature-based antivirus engines and poorly tuned Endpoint Detection and Response (EDR) sensors treat the intrusion as normal administrative activity.

How the counterfeit RVTools GitHub repositories work

Dell’s product documentation says RVTools is closed-source freeware distributed only through official Dell channels, Robware.net, and RVTools.com. Busy administrators still search on search engines or GitHub directly to grab the latest release binary without navigating vendor portals, and the threat actors built the campaign around that habit. They set up rvsphex/RVTools as the primary payload host and rvnexa/RVTools as a secondary repository that sends visitors to the same counterfeit release package. The cross-linking gives the pair an air of community validation and organic maintenance.

The release archive is a ZIP file with SHA-256 hash 67c3fa674534548ff240e6f59b6ccabf1495703958b7d22006feed511f9fa672. Inside sits an MSI installer with SHA-256 hash 619d24f463c873e41ca76111695e72da145826945dc4db2b185bc52fa968df3b. The MSI metadata and wrapper carry “Dell Setup” branding to borrow credibility from RVTools’ corporate owner.

The unsigned “Dell Setup” MSI wrapper

Unlike the payload it carries, the outer MSI is unsigned. In a hardened environment, an unsigned MSI downloaded from the internet zone (Zone.Identifier alternate data stream set to 3) and run through msiexec.exe should trip Microsoft Defender SmartScreen or Application Control policies. Installing system utilities like RVTools requires local administrative privileges, though, so administrators routinely click past UAC elevation prompts and SmartScreen warnings, assuming Dell or Robware simply skipped signing a minor point release.

During execution the wrapper writes a registry key under the current user’s hive: HKCU\SOFTWARE\Dell\RVToolsSetup. That key is a useful forensic differentiator. A legitimate Action1 enterprise deployment never touches a Dell\RVToolsSetup path, and a genuine RVTools installation puts its binaries in C:\Program Files (x86)\Robware\RVTools (or the Dell equivalent directory) without any RMM service. The outer MSI is purely a delivery sled. Its internal custom actions extract and silently run the embedded Action1 installer (action1_agent.exe, version 6.0.664.1) with hidden command-line arguments that bind the endpoint to the attacker’s cloud organization ID, without showing a single GUI window or progress bar.

How the rogue Action1 agent enrolls and persists

Rogue tenant enrollment

Action1 is a legitimate enterprise patch management and vulnerability remediation platform. One of its tiers is free for up to 200 endpoints, forever, with no feature restrictions. Registration requires a corporate email address to deter casual abuse, and threat actors routinely get around that with aged domains, compromised business email accounts, or niche temporary email providers that vendor blocklists haven’t caught up with.

Every Action1 cloud tenant has a unique Organization ID and is bound to a regional data center. A deployment package generated from the Action1 web console is pre-keyed with that tenant’s cryptographic enrollment token and Organization ID. Forensic analysis of the MSI in this campaign showed the agent hardcoded to enroll in the European regional cluster at server.eu.action1.com, which resolves to AWS EC2 Frankfurt addresses 52.29.164.59 and 3.69.247.61, under the attacker-controlled Organization ID 2ef34aba-cb3c-4e19-8b9b-0494bde90540.

Files, service, and registry footprint

When msiexec.exe launches the embedded Action1 setup, the installer puts its files in C:\Windows\Action1\. Placing binaries under C:\Windows\ instead of C:\Program Files\ is standard Action1 behavior, meant to keep the agent away from casual end-user tampering. The installation populates several signed executables and working directories:

• Binaries in C:\Windows\Action1\: the primary service binary action1_agent.exe (the endpoint agent), plus action1_connector.exe, action1_remote.exe (used for interactive remote desktop sessions), and action1_update.exe. Every one of these PE files carries a valid Authenticode signature issued to Action1 Corporation.
• Directories and logs: C:\Windows\Action1\scripts\ stages batch and PowerShell scripts pushed from the cloud console, and C:\Windows\Action1\rule_data\ stores local evaluation rules. Rotating logs named C:\Windows\Action1\action1_log_*.log record connection states, executed job IDs, and system notifications.
• Service persistence: the installer registers a Windows service named A1Agent through the Service Control Manager, which generates Event ID 7045 in System.evtx and Event ID 4697 in Security.evtx. The service is set to SERVICE_AUTO_START and runs as LocalSystem (NT AUTHORITY\SYSTEM).
• Registry configuration: besides the standard service entry at HKLM\SYSTEM\CurrentControlSet\Services\A1Agent, the agent writes its operational parameters and tenant binding (CustomerId / Org ID) to HKLM\Software\Action1\Agent and HKLM\SOFTWARE\WOW6432Node\Action1.

What the attacker gets once the agent is online

As soon as A1Agent starts, action1_agent.exe performs local reconnaissance to register the host profile with the cloud console. Windows Security auditing (Event ID 4688) routinely captures the agent spawning child processes with command lines such as C:\Windows\Action1\action1_agent.exe loggedonuser, which enumerates active interactive sessions. The agent then opens persistent outbound TLS 1.2/1.3 connections over TCP port 443 to server.eu.action1.com and retrieves software package payloads from backend storage buckets such as a1-backend-packages.s3.amazonaws.com.

From that point the attacker logs into the Action1 web dashboard and sees the victim workstation listed as an online, managed asset. Without writing any custom malware to disk, they can run arbitrary PowerShell or CMD scripts as SYSTEM, push secondary payloads through the software deployment module, read the full hardware and software inventory, or launch action1_remote.exe to watch and control the administrator’s desktop in real time.

Why LOLRMM abuse evades EDR and network monitoring

The security industry has spent a decade tuning behavioral detection for classic post-exploitation frameworks. Drop a Cobalt Strike Beacon, a Sliver implant, or a custom C# loader on a modern workstation and EDR kernel callbacks and user-mode API hooks scrutinize the process immediately. Sensors watch for VirtualAllocEx and WriteProcessMemory calls aimed at remote processes, unbacked executable memory regions, odd parent-child process trees such as winword.exe spawning powershell.exe, and named pipe patterns tied to known malleable C2 profiles.

Weaponizing a commercial RMM agent sidesteps nearly all of those tripwires. The security community catalogs the technique as LOLRMM (Living off the Land Remote Monitoring and Management), and it works for three reasons.

Trusted binary reputation

When action1_agent.exe loads into memory, the Windows kernel and the EDR driver validate its Authenticode signature against a trusted root certificate authority. Action1 Corporation is a legitimate software vendor used by thousands of enterprises and Managed Service Providers (MSPs), so security vendors cannot classify the binary hash or the signer certificate as malicious without breaking production IT operations for their own customers.

Expected process behavior

When a traditional trojan spawns powershell.exe -nop -w hidden -enc ..., an EDR flags it, because a PDF reader or an unknown unsigned binary has no business launching hidden PowerShell. An RMM agent exists to run administrative scripts, query WMI, modify registry keys, install MSI packages, and manage system services. When action1_agent.exe spawns powershell.exe or cmd.exe from C:\Windows\Action1\scripts\, many EDR rulesets give the event less scrutiny or a lower risk score, so SOC analysts aren’t flooded with false positives every time an IT department pushes a patch script across five thousand workstations.

Legitimate TLS infrastructure

Network intrusion detection systems (NIDS) and next-generation firewalls (NGFWs) that look for newly registered domains, self-signed TLS certificates, or high-entropy DNS tunneling see nothing out of the ordinary. The traffic runs over HTTPS to *.action1.com, backed by valid certificates and hosted on reputable AWS IP space (52.29.164.59, 3.69.247.61). Unless an organization combines TLS inspection with strict application-layer allowlisting, the C2 channel blends into background SaaS traffic.

Timeline: eighteen months of fake RVTools malware campaigns

The November 2026 GitHub campaign is the latest step in an eighteen-month assault on virtualization administrators searching for RVTools. Across that stretch, threat actors have moved away from noisy, complex custom malware chains and toward frictionless abuse of trusted infrastructure.

May 2025: SEO poisoning, typosquatting, and Bumblebee

In May 2025, adversaries ran a widespread SEO poisoning and typosquatting campaign built on lookalike domains, most notably swapping the legitimate .com top-level domain for .org, that ranked at the top of search results. Administrators who downloaded the installer from those decoy portals got a trojanized package that used classic DLL side-loading through a malicious version.dll to deploy the Bumblebee malware loader, an initial-access broker tool frequently used ahead of human-operated ransomware and Active Directory compromise. The wave was severe enough that Dell Technologies issued formal advisories while Robware.net and RVTools.com went through transitions, warning customers never to source the utility outside official distribution pages.

May 2026: a signed MSI and a WinPython RAT

By May 2026, attackers had refined their evasion to defeat initial SmartScreen warnings. K7 Security Labs documented a campaign distributing a counterfeit RVTools MSI (SHA-256: d0f5e98fb840fb5656d3f50613b6f1ec60e57392643159841bc1fa95396087a4) digitally signed with a valid Sectigo code-signing certificate issued to a shell company named Xiamen Lunwei Huage Network Co., Ltd. The MSI abused the Windows Installer Binary table to hold an obfuscated VBScript (Binary.MyScript.vbs) triggered by an MSI Custom Action. Once msiexec.exe invoked it, the VBScript decoded a decimal-to-character obfuscated PowerShell command that called Invoke-WebRequest to pull a 33 MB archive (winp.zip) from Dropbox into %APPDATA%.

The payload was an elaborate “Bring Your Own Interpreter” (BYOI) operation. winp.zip unpacked a full portable WinPython environment, complete with legitimate developer tools like VS Code, Spyder, and Jupyter Lab to fool casual file-system inspection, while a fake reboot prompt claimed to be “cleaning installation artifacts.” After staggered 5-second and 30-second delays, hidden Python processes launched with STARTF_USESHOWWINDOW (wShowWindow = 0) and ran two heavily obfuscated scripts, collector.py and Pmanager.py.

collector.py generated a persistent 8-character victim ID by hashing the machine’s MAC address and hostname. It then sized up the enterprise with an LDAP query through PowerShell’s [adsisearcher] (([adsisearcher]"(ObjectClass=computer)").FindAll().Count) that counted every computer object in Active Directory. Pmanager.py set up persistence through Registry Run keys, Scheduled Tasks, and Active Setup entries. It compressed the stolen recon data (configA.json) with zlib, encrypted the buffer with a custom RC4 implementation (a 256-byte state vector initialized by the Key Scheduling Algorithm, XORed with the Pseudo-Random Generation Algorithm keystream), and exfiltrated the result by HTTP POST every five minutes to five hardcoded C2 IP addresses.

The chain was technically impressive and had far too many moving parts. Certificates from shell companies get revoked, msiexec.exe spawning wscript.exe to launch hidden PowerShell downloaders trips modern behavioral EDR rules, and beaconing over raw HTTP POST to hardcoded IP literals stands out in proxy logs.

August 2026: Level RMM, SystemBC, and Cobalt Strike

The adversaries pivoted quickly. On August 27, 2026, an intrusion analyzed by Threat Hunting Labs and MalBear Labs began when an administrator clicked an SEO-poisoned Google result for RVTools and ran the downloaded MSI. Instead of a custom Python stack, that installer deployed Level (level-windows-amd64.exe under C:\Program Files\Level\), another commercial RMM tool running as LocalSystem. The threat actor used the legitimate Level console to run initial discovery commands as SYSTEM, then installed a secondary custom RMM service (LightRmmAgent), deployed a SystemBC proxy bot, and finally staged a Cobalt Strike Beacon for lateral movement.

November 2026: GitHub repositories and a signed Action1 agent

The rvsphex/RVTools and rvnexa/RVTools campaign follows that trend to its end. Moving the lure from expensive, easily burned search ads to persistent GitHub repositories, and swapping custom Python loaders for a signed Action1 agent (6.0.664.1), removed every fragile link in the execution chain.

Why vendor takedowns do not clean infected hosts

After public reporting of the campaign on November 3, 2026, community researchers flagged the abuse to Action1’s leadership, including co-founder Gene Moody, and supplied the rogue Organization ID 2ef34aba-cb3c-4e19-8b9b-0494bde90540 so the vendor could terminate the attacker’s cloud tenant. Relying on a vendor takedown is a reactive posture. Even after the tenant is suspended or GitHub removes the repositories, any endpoint that ran the installer remains compromised. It may hold secondary backdoors dropped while the attacker had active C2 control, and the orphaned SYSTEM service stays in place.

RVTools campaign indicators of compromise (IOCs)

Sweep your SIEM, EDR telemetry, and firewall logs for these artifacts:

• Counterfeit repositories: github[.]com/rvsphex/RVTools and github[.]com/rvnexa/RVTools
• Delivery archive (ZIP) SHA-256: 67c3fa674534548ff240e6f59b6ccabf1495703958b7d22006feed511f9fa672
• “Dell Setup” MSI wrapper SHA-256: 619d24f463c873e41ca76111695e72da145826945dc4db2b185bc52fa968df3b
• Rogue Action1 tenant / Org ID: 2ef34aba-cb3c-4e19-8b9b-0494bde90540 (configured via HKLM\Software\Action1\Agent)
• Dropped agent version: Action1 Agent 6.0.664.1
• Host wrapper registry key: HKCU\SOFTWARE\Dell\RVToolsSetup
• Service name and path: A1Agent executing from C:\Windows\Action1\action1_agent.exe
• C2 domains and IPs: server.eu.action1.com (52.29.164.59, 3.69.247.61), *.action1.com, and a1-backend-packages.s3.amazonaws.com

How to hunt for a rogue Action1 agent

Defending against rogue RMM enrollment means auditing who is authorized to manage an endpoint instead of hunting for malware. The agent itself is not a virus. The useful SOC question is whether your organization licenses Action1 and, if it does, whether this endpoint belongs to your tenant.

If your organization does not use Action1, any A1Agent service or C:\Windows\Action1\ directory is a high-severity finding. If you do use Action1 legitimately, still verify that no administrator ran the counterfeit RVTools wrapper, which could have overwritten or co-opted the tenant configuration.

PowerShell triage script

Responders can run the script below from an elevated prompt on administrative jump hosts and virtualization workstations. It checks for the service and the install directory, inspects the Action1 registry keys for the enrolled Organization ID, and sweeps the user hives under HKEY_USERS for the wrapper’s registry artifact.

# Run from an elevated PowerShell prompt
Write-Host "[*] Starting RVTools / Rogue Action1 Triage..." -ForegroundColor Cyan
# 1. Check for the A1Agent Windows Service
$service = Get-Service -Name "A1Agent" -ErrorAction SilentlyContinue
if ($service) {
    $wmiSvc = Get-CimInstance -ClassName Win32_Service -Filter "Name='A1Agent'"
    Write-Host "[!] ALERT: A1Agent service detected! Status: $($service.Status) | Path: $($wmiSvc.PathName)" -ForegroundColor Red
} else {
    Write-Host "[+] A1Agent service not found." -ForegroundColor Green
}
# 2. Check for File System Artifacts and Binary Version
$installDir = "C:\Windows\Action1"
if (Test-Path $installDir) {
    Write-Host "[!] ALERT: Directory $installDir exists!" -ForegroundColor Red
    $agentBin = Join-Path $installDir "action1_agent.exe"
    if (Test-Path $agentBin) {
        $ver = (Get-Item $agentBin).VersionInfo.FileVersion
        Write-Host "    -> action1_agent.exe Version: $ver (Campaign version is 6.0.664.1)" -ForegroundColor Yellow
    }
}
# 3. Inspect Action1 Registry Keys for the Rogue Organization ID
$regPaths = @(
    "HKLM:\Software\Action1\Agent",
    "HKLM:\SOFTWARE\WOW6432Node\Action1",
    "HKLM:\SOFTWARE\WOW6432Node\Action1\Agent"
)
foreach ($path in $regPaths) {
    if (Test-Path $path) {
        Write-Host "[!] Action1 Registry Key found: $path" -ForegroundColor Yellow
        $props = Get-ItemProperty -Path $path
        $props.PSObject.Properties | Where-Object { $_.Name -notmatch '^PS' } | ForEach-Object {
            Write-Host "    -> $($_.Name) : $($_.Value)"
            if ($_.Value -match "2ef34aba-cb3c-4e19-8b9b-0494bde90540") {
                Write-Host "[!!!] CRITICAL: Matched known malicious RVTools Campaign Org ID!" -ForegroundColor Red
            }
        }
    }
}
# 4. Sweep HKU for the Fake "Dell Setup" Wrapper Artifact (HKCU\SOFTWARE\Dell\RVToolsSetup)
New-PSDrive -PSProvider Registry -Name HKU -Root HKEY_USERS -ErrorAction SilentlyContinue | Out-Null
Get-ChildItem "HKU:\" -ErrorAction SilentlyContinue | ForEach-Object {
    $rvKey = Join-Path $_.PSPath "SOFTWARE\Dell\RVToolsSetup"
    if (Test-Path $rvKey) {
        Write-Host "[!!!] CRITICAL: Malicious MSI Wrapper key found at $rvKey" -ForegroundColor Red
    }
}

KQL hunting query for Defender and Sentinel

In Microsoft Defender for Endpoint or Sentinel, hunt for unsigned MSI executions alongside service creation in C:\Windows\Action1\ and outbound connections from action1_agent.exe. The query below matches the Action1 paths, the wrapper registry key, the campaign network indicators, and both file hashes.

// KQL: Detect Action1 RMM Service Installation or Execution from C:\Windows\Action1\
union DeviceProcessEvents, DeviceNetworkEvents, DeviceRegistryEvents
| where Timestamp > ago(30d)
| where (FolderPath startswith @"C:\Windows\Action1\" and FileName in~ ("action1_agent.exe", "action1_remote.exe", "action1_connector.exe"))
   or (RegistryKey has @"SOFTWARE\Dell\RVToolsSetup")
   or (RemoteUrl has "action1.com" or RemoteIP in ("52.29.164.59", "3.69.247.61"))
   or (SHA256 in ("67c3fa674534548ff240e6f59b6ccabf1495703958b7d22006feed511f9fa672", "619d24f463c873e41ca76111695e72da145826945dc4db2b185bc52fa968df3b"))
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, ProcessCommandLine, RegistryKey, RemoteUrl, RemoteIP, InitiatingProcessFileName, InitiatingProcessCommandLine

How to remediate an infected endpoint and harden against RMM abuse

Contain the host and rotate credentials

If an endpoint has the HKCU\SOFTWARE\Dell\RVToolsSetup key or the rogue 2ef34aba-cb3c-4e19-8b9b-0494bde90540 tenant ID, stopping the A1Agent service and deleting C:\Windows\Action1\ is not enough. The agent gave the attacker interactive SYSTEM control, so responders should read C:\Windows\Action1\action1_log_*.log and check C:\Windows\Action1\scripts\ for secondary scripts or interactive sessions pushed before the host was isolated. Rotate immediately any vCenter, ESXi, or Active Directory credentials cached in LSASS or stored in browser profiles on that machine.

Long-term hardening against LOLRMM

Long-term resilience against LOLRMM campaigns means treating remote management agents with the same zero-trust skepticism you apply to unsigned executables. Maintain an explicit DNS and firewall blocklist built from community repositories such as the LOLRMM project (lolrmm.io), covering *.action1.com, *.level.io, *.atera.com, *.screenconnect.com, and dozens of other RMM domains, unless IT has formally sanctioned a specific platform.

Enforce Windows Defender Application Control (WDAC) or AppLocker rules that stop standard administrative accounts from running unsigned MSI packages out of user-writable directories (%USERPROFILE%\Downloads, %TEMP%). That neutralizes the outer “Dell Setup” delivery wrapper before the signed RMM payload can touch the disk.