Trojanized RVTools: Python Stager Linked to UNC2465

Key findings

• In October 2026, attackers used Google Ads to redirect users searching for RVTools, a popular VMware vSphere inventory utility, to a fake download site distributing a trojanized installer.
• The trojanized installer deploys a Python stager alongside a genuine, Dell-signed copy of RVTools used as a decoy.
• A scheduled task launches the Python stager five minutes after installation. The stager collects host information, registers with a Cloudflare Workers command-and-control (C2) server, and waits 72 hours by default before its next check-in. It also carries an encrypted .NET assembly designed to be decrypted and loaded in memory when the C2 supplies the required key.
• Analysis of two trojanized RVTools installer samples revealed that one contained both the Python stager and a SmokedHam-style dropper built from the same template. A developer comment further links their launchers, establishing a technical connection between the two.
• The shared tooling, combined with overlaps in the RVTools malvertising delivery chain, suggests an association with UNC2465 (Storm-0241), a threat actor previously linked to ransomware operations.
• Vega customers are protected: behavior-based detections cover the renamed Python interpreter, host discovery, scheduled-task persistence, Run-key changes, and Cloudflare Workers C2, and Schtasks From Suspicious Folders alerted during the investigated intrusion.

Vega Threat Research investigated an intrusion in which a user installed a trojanized RVTools MSI (rvtools4.8.1.msi) obtained through a sponsored search result (referred to below as Sample 1). The installer executed a batch dropper that deployed a Python stager named DeviceSync.py alongside a legitimate copy of RVTools as a decoy (Dell-signed).

To investigate the activity further, our team analyzed a second trojanized RVTools installer (rvtools4.7.1.msi, Sample 2) identified in a public ANY.RUN sandbox submission. This sample contains both DeviceSync and SmokedHam-style droppers built from the same template, with a developer comment further linking their launchers.

These findings, combined with overlaps in the RVTools malvertising delivery chain previously documented by Orange Cyberdefense CERT and FieldEffect, suggest an association with UNC2465 (Storm-0241).

Below, we trace the delivery and execution chain, examine DeviceSync's capabilities, and identify detection opportunities that remain useful when infrastructure and file hashes change.

Figure 1: Attack chain

Stage 1: A Sponsored Search Result

RVTools is a free utility for inventorying VMware vSphere environments. Because it is commonly used by vSphere administrators, a fake download can reach users with privileged access to critical virtualization infrastructure, including vCenter and ESXi environments.

In October 2026, attackers exploited this opportunity through a Google Ads campaign targeting searches for "rvtools". In the investigated intrusion, the victim clicked the top sponsored result and was redirected to a forged RVTools download site through Google's googleadservices.com/pagead/aclk redirect. The URL included tracking parameters such as gad_campaignid=24297418705 and utm_content=826049045241, which may help correlate activity associated with the same advertising campaign.

The ad led to rvtok[.]app, a Cloudflare-fronted site impersonating the RVTools download page. When the site was revisited outside the original ad flow, the download page was no longer displayed. This behavior is consistent with traffic filtering, although this observation alone does not establish which visitor attributes were evaluated. Orange Cyberdefense has previously described similar filtering based on geography, user agent, and ad-click parameters.

Figure 2: Malicious sponsored result

Stage 2: The Redirect Chain Delivering the Malicious Payload

While the download page is open, it runs a bot check and repeatedly polls a second lookalike domain, rvtooks[.]com. The Download button directs the victim to an Azure Front Door endpoint, part of Microsoft's cloud-based application delivery service, which acts as an intermediary in the download chain: web-app-server-gqdmgecbb2e6czg3.z03.azurefd[.]net/id-RVTools4.7.1?q=RVTools. The endpoint then redirects to Dropbox, where the malicious rvtools4.8.1.msi installer is hosted.

ReversingLabs first observed the lookalike domain, Azure Front Door endpoint, and Dropbox host on May 25, 2026. The Azure CDN-to-Dropbox delivery chain is consistent with previously reported UNC2465 campaigns.

Stage 3: A Trojanized RVTools Installer with a Legitimate Decoy

Vega Threat Research compared two trojanized RVTools MSI installers: Sample 1 from the investigated intrusion and Sample 2 from a public ANY.RUN submission. The table below summarizes their file properties, MSI metadata, installation paths, and digital signatures.

Both MSI installers are unsigned, and their metadata does not match the RVTools filenames. Sample 1's randomized suffixes and the different installation paths suggest the use of a configurable installer builder. Previously reported UNC2465 RVTools malvertising campaigns commonly used NSIS installers signed with EV certificates, making these unsigned MSI packages a notable change in packaging.

Despite this, the installer deploys a genuine, Dell-signed copy of RVTools as a decoy. The application installs and launches normally while deploy.bat runs in the background.

Stage 4: The deploy.bat Dropper

deploy.bat extracts python.zip using the built-in tar.exe into a directory disguised as a Windows component, such as C:\ProgramData\Microsoft\DiskCleanup\python\. The archive contains a complete CPython 3.12 runtime, pycryptodome, and pythonnet, which enables Python to interact with .NET assemblies. The windowless interpreter, pythonw.exe, is renamed to UsbService64.exe at build time.

In Sample 1, the dropper creates two scheduled tasks to execute DeviceSync.py under the SYSTEM account:

• LanguagePack (initial execution): A one-time task scheduled five minutes after installation
• SecurityHealth (persistence): A logon-triggered task that relaunches the stager

Both tasks execute a batch launcher through cmd.exe, which invokes the renamed Python interpreter (UsbService64.exe). Before creating the tasks, the dropper removes any existing tasks with the same names.

The dropper also creates an HKLM Run-key value named OfficeHelper, pointing to a shortcut that is never created. Although the original dropper template includes VBScript code to generate this shortcut, that step is missing from the DeviceSync version, leaving the Run-key persistence mechanism nonfunctional.

Sample 2 reveals two additional implementation details: First, its dropper exits if the stager is already present, preventing repeated installation.

Second, a Russian-language developer comment describes _agent.bat as launching DeviceSync “by analogy with _c.bat,” the launcher generated by the SmokedHam-style dropper in the same installer. This provides direct code-level evidence connecting the two droppers.

Figure 3: Process execution in Vega

Stage 5: DeviceSync.py, an Encrypted .NET Payload Stager

DeviceSync.py is a lightly obfuscated Python stager designed to fingerprint infected hosts, communicate with a C2 server, receive remote instructions, and decrypt and execute an embedded .NET assembly in memory. It uses XOR-encoded strings and randomized function names and differs from the SmokedHam ThunderShell-style protocol and Cacciatore payloads (both described by Orange Cyberdefense CERT) previously observed in this delivery chain.

Our code-level analysis is based on Sample 2. Similarities in the dropper structure, Python interpreter, launcher, and observed behavior suggest that both samples deploy the same or closely related stager.

Fingerprinting and Registration: Upon execution, the stager generates a random agent ID and collects host information, including the hostname, username, domain, OS version (cmd /c ver), administrative privileges, running processes (tasklist /fo csv /nh), and system information (systeminfo). The collected information is transmitted to the C2 server during the initial check-in.

Figure 4: DeviceSync host fingerprinting

Encrypted check-ins: Messages go over HTTPS POST to a Cloudflare Workers C2. Each is AES-CBC encrypted with an HMAC-SHA256 integrity tag, under a key derived per agent; the agent ID travels in a request header. TLS certificate checking is turned off. A w.conf file next to the script can override the C2 address, and the server can rotate it remotely.

A 72-hour default sleep: Static analysis of DeviceSync.py from Sample 2 shows that, after initial registration, the stager defaults to a 72-hour delay before its next check-in and then polls every 20 minutes. The C2 can change both intervals. This is separate from the dropper’s five-minute launch delay, which postpones the first run; the longer interval reduces subsequent network activity. In the investigated intrusion, the stager's only C2 traffic was a burst of six short connections within 45 seconds of its first run, consistent with registering and then going quiet.

Encrypted second stage: The stager handles host discovery, registration, and C2 communication. It also carries an encrypted .NET assembly whose decryption key is supplied only by a C2 run instruction. The script is designed to decrypt the assembly and load it into memory using pythonnet (Assembly.Load), without saving it to disk. Because that key was not available during analysis, the assembly's contents and functionality remain unknown. Although the shared dropper code and campaign overlap establish a technical connection to SmokedHam-style tooling, they do not confirm that the encrypted assembly contains a SmokedHam payload.

def _yztxjypg(exe):
    import clr
    clr.AddReference('System')
    clr.AddReference('System.Reflection')
    from System.Reflection import Assembly
    from System import Byte, Array
    e = Assembly.Load(Array[Byte](exe)).EntryPoint
    if e is None:
        raise RuntimeError(_ds('/R1TKWV8iYiwYZdqN1s='))
    e.Invoke(None, None)

Figure 5: DeviceSync’s .NET loading routine, designed to load a decrypted assembly from a byte array using pythonnet (Assembly.Load) and invoke its entry point (e.Invoke)

Control and kill switch: The server can stop the agent with a quit command. The stager reports its status (alive, active, sleeping, run_ok, run_failed), and it exits on its own when the C2 answers HTTP 403, 404, or 410, so taking down or retiring a C2 also silences its agents.

Self-modification: The script is designed to store its agent ID and any new C2 address by rewriting its own source. A coding error prevents the script from persisting these changes in the analyzed build. The routine therefore does not modify the source file, and the stager generates a new agent ID on restart.

Who Is Behind It?

Based on overlaps in the RVTools malvertising delivery chain and the shared DeviceSync/SmokedHam-style dropper code, Vega Threat Research assesses with moderate confidence that this activity is associated with UNC2465 (also tracked as Storm-0241).

UNC2465 is a financially motivated threat actor active since at least 2019, known for distributing malware through trojanized software installers and malvertising campaigns targeting IT administrators. Historically associated with DarkSide ransomware, the group has also been linked to LockBit, Hunters International, and Qilin operations. In a Qilin case documented by Orange Cyberdefense CERT, the operator targeted backup infrastructure before encrypting ESXi virtual machine disks.

The strongest evidence supporting this association comes from Sample 2. It contains two droppers built from the same template: one installs DeviceSync, the other sets up the SmokedHam MSDTC persistence. They share the install folder, the scheduling code, and the Run value, and a developer comment describes the DeviceSync launcher as modeled on the SmokedHam one. In Sample 2 the SmokedHam payloads are placeholders, which suggests a test or template build. The link is therefore in the tooling, not in a co-delivered SmokedHam infection. The build in the customer environment deployed DeviceSync only.

However, the investigated samples also differ from previously reported UNC2465 activity: the installer is unsigned, uses an MSI wrapper rather than NSIS, and deploys a plain .py script instead of renamed .pyc files. These changes may reflect tooling evolution, but reuse of a shared installer kit by another operator cannot be ruled out.

What Should Defenders Do?

• Look back, not just forward: By default, DeviceSync registers with its C2 and then sleeps for 72 hours before its next check-in. Search historical telemetry for the indicators below and related execution behaviors. Consider extending the investigation to late May 2026, when the associated infrastructure was first observed.
• Check MSI identity: Investigate installers impersonating known administrative tools, particularly when their filenames don't match their ProductName or Manufacturer metadata. Windows Installer events (including 1033 and 11707) can provide useful installation context.
• Prevent malicious software downloads: Encourage administrators to obtain software from trusted, approved sources and restrict access to suspicious or newly registered domains.
• Restrict unauthorized software execution: Use application control policies to prevent unapproved executables and scripts from running on administrative workstations, particularly from user-writable directories. Test policies before enforcement to avoid disrupting legitimate applications.
• Assess potential hypervisor exposure: If an administrative workstation is infected, review vCenter and ESXi access, assess whether credentials or vault secrets were exposed, and rotate potentially compromised credentials. Isolate and remediate the host before returning it to service.

How Vega Customers Are Protected

Vega provides behavior-based detections covering multiple stages of the attack, from interpreter masquerading and host discovery to persistence and command-and-control activity.

• Execution and discovery: Masqueraded Python Interpreter identifies renamed Python executables such as UsbService64.exe. Host Reconnaissance From a User-Writable Folder Process detects multiple distinct system discovery utilities launched by the same process from a user-writable directory, consistent with DeviceSync's fingerprinting behavior.
• Scheduled task execution and persistence: Vega's Schtasks From Suspicious Folders detection raised an alert during the customer intrusion, identifying suspicious scheduled-task activity involving files in unusual directories. Additional coverage includes Schtasks Creation Or Modification With SYSTEM Privileges, Suspicious Command Patterns In Scheduled Task Creation, and Scheduled Task Registering Binary from User-Writable Path, which detects schtasks.exe creating tasks that execute files from user-writable directories.
• Run-key modifications: Potential Persistence Attempt Via Run Keys Using Reg.EXE and Run Key Set by LOLBAS Process flag built-in Windows utilities and script hosts, including reg.exe, writing Run or RunOnce values.
• Command and control: Possible Cloudflare Workers Command and Control identifies potential C2 activity involving script interpreters or executables in user-writable directories connecting to workers.dev infrastructure, rather than flagging the domain alone.

The indicators below cover the observed techniques, and Vega's IOC scanning automatically checks customer data against them.

Indicators of Compromise (IOCs)