A signed “Marvell RAID utility” that builds its malware with Microsoft’s own compiler

About this post: Thank you to MalwareHunterTeam for identifying and sharing the file. This analysis and write-up were produced by Claude (Opus 5.5), working as an agent in Claude Code on a REMnux analysis VM. Tools used: msitools, Malcat, ILSpy, capa, Python, ANY.RUN and Deception Pro.

TL;DR

_RJP9CMD.msi presents itself as a "RAID Configuration Utility" from Marvell, a real storage-chip vendor. It is signed, but by a certificate in the name of an individual, Melvin Jackson, issued three days before the file was signed. It never installs a RAID tool. Instead it starts a genuine, Microsoft-signed copy of MSBuild (the program Visual Studio uses to compile code) under a random name, which loads a tampered Microsoft library that decrypts a hidden program and runs it in memory. About five minutes later the installer uninstalls itself, while the hidden program keeps running.

That program contacts a server we have seen before as the command server of the CNCMachineRMS remote-access trojan (RAT), and downloads five more malware kits, each hiding behind a different signed, legitimate program. We unpacked all five. Each is built with HijackLoader (also called IDAT Loader), and all five deliver the same build of SectopRAT (also called ArechClient2), a RAT and information stealer, which runs inside a renamed but genuine signed program. When its server stops responding, SectopRAT reads a backup copy of the server’s address from a smart contract on the BNB Smart Chain blockchain.

• Signed: SSL.com certificate "Melvin Jackson", serial 6dbb6dd7243b97569d7ec15dab2d1a10, signed 30 October 2026.
• Living off the land (abusing tools that Windows or developers already trust): the first stage runs inside Microsoft’s MSBuild.exe, renamed analytics_eb93.exe. SectopRAT runs inside signed programs such as Microsoft’s Visual Studio CodeCoverage.exe, renamed VHandler.exe.
• Hidden in memory: a 16.6 MB encrypted .NET program inside a tampered Microsoft.Data.Edm.dll, never written to disk. It loads a doctored copy of the Windows DLL wmp.dll, most likely to hide its code inside it.
• Covering tracks: a self-uninstall after about five minutes, with a backup registry entry that runs it at next logon.
• Command and control (C2): kenpousland[.]cfd and crepiehumru[.]lol behind Cloudflare, looked up through Google’s encrypted DNS; then 96.62.218[.]59, the server from our signed fake Microsoft Teams installer case two weeks ago. We have not confirmed at code level that the program talking to it is CNCMachineRMS; see "What we still don’t know".
• Five kits: signed programs from MAGIX, ACD Systems, ASUS, NetEase and VNG, each paired with a tampered DLL ("DLL sideloading") and a HijackLoader payload.
• Final payload (all five kits): one SectopRAT build, talking to 93.152.220[.]219, with BNB Smart Chain contract 0xb11613acf39ad3b4dde427c27068d278fafa8998 as its backup address book.

But it’s signed!

Code signing is like a tamper seal with a name on it, vouched for by a certificate authority (CA) such as SSL.com: it tells you who sealed the package and that nobody changed it afterwards. It does not tell you the contents are safe. Here the seal says "Melvin Jackson, Orlando, Florida", while every visible label in the installer says "Marvell Technology Group". A brand-new certificate that is immediately used to sign someone else’s product is a pattern we see again and again with signed malware. The certificate was valid from 27 October 2026, and the file was signed on 30 October.

The certificate has been reported to the CA and added to the CertGraveyard.

Step one: an installer that installs nothing useful

MSI files are Windows installer databases: tables that say which files go where and which "custom actions" run. This one copies five files into %LOCALAPPDATA%\Marvell\RAID Configuration Utility\:

Then it runs two custom actions: MSBuild on the project file, and the cleanup script.

Step two: borrowing Microsoft’s compiler

MSBuild lets a project define custom "tasks", small pieces of code that run during a build. Attackers like this because MSBuild is signed by Microsoft and often allowed by application-control rules. The project file here contains nothing except one instruction: load the task Microsoft.Data.Edm.CachedResolver4 from Microsoft.Data.Edm.dll and run it.

That DLL is mostly a real copy of Microsoft’s Entity Data Model library, with one class and a handful of encrypted data blobs added. Think of it as a library book with an extra chapter glued in, plus a sealed envelope tucked in the back. The added class:

• looks up Windows functions by hash instead of by name (it compares a scrambled fingerprint of each function name), so the names don’t appear in the file;
• checks for a debugger in three different ways and stops if it finds one;
• stops unless a .csproj with the same name sits next to the running program, so it only works inside its own install;
• detaches from its console window so nothing pops up;
• waits about 35 to 43 seconds before doing anything else, which helps it outlast short automated sandboxes;
• runs a tiny custom "virtual machine" (its own mini instruction set) to unpack encrypted strings and the payload;
• appears to loosen the program’s internet settings, accepting any HTTPS certificate and enabling every version of TLS (the encryption behind HTTPS), which fits what we later saw: the payload talks to its servers over HTTPS;
• loads the decrypted 16.6 MB .NET program straight into memory and calls System.Net.Security.MutexChannel.LockPipe(), a name chosen to look like part of .NET;
• after the payload returns, erases the payload’s headers (the part of a program that says what it is and how it’s laid out) from memory. That makes a memory snapshot taken by investigators much harder to use.

The cleanup crew

The second custom action runs indexer_0ae9.cmd, which starts a hidden PowerShell window. That window starts a hidden command prompt that pings the computer’s own address 301 times (a cheap way to wait about five minutes) and then silently uninstalls the MSI, deleting the dropped files. The installer also writes a RunOnce registry value, !Upd531d1ed0 (RunOnce entries run once at the next logon and then disappear), as a backup: if the uninstall hasn’t happened yet, it runs at the next logon. The installer even marks the cleanup command as "hidden" so it doesn’t show up in installer logs. Whoever investigates later may find the payload already running in memory with nothing left on disk.

Step three: the payload wakes up

The public ANY.RUN sandbox run never got this far. About six seconds after MSBuild started, an uninstall ran in that sandbox. It was most likely started by the sandbox’s own automation, not the five-minute cleanup script. It removed the files while the loader was still in its 40-second wait, so the loader most likely found its own DLL gone when it went to re-read it for the decryption key, and quietly exited.

In a DeceptionPro run, the payload loaded as designed:

• About a minute after the install, the machine opens an encrypted session to Google’s DNS-over-HTTPS service at 8.8.8.8, one second before MSBuild’s first connection to the attacker’s servers. No ordinary DNS lookups for those servers were seen, and no new process is started. Looking up servers through encrypted DNS hides the lookups from network monitoring that only watches ordinary DNS.
• The MSBuild process then opens encrypted (TLS 1.3) connections to kenpousland[.]cfd and crepiehumru[.]lol. Both sit behind Cloudflare, so the IP addresses belong to Cloudflare rather than the attacker.
• When the five-minute cleanup ran and the files disappeared, the connections carried on. That confirms the point of the design: the payload lives in memory, and nothing is left on disk to find.

A copy of wmp.dll (Windows Media Player’s library) also appears in a folder under %TEMP% named after the MSBuild program and its process number (in hexadecimal), and the MSBuild process loads it. We compared it with the genuine file from Microsoft. Same version, same size, and only 57 bytes differ. Those bytes switch off Control Flow Guard (CFG) and related exploit-protection data. CFG is a Windows protection that stops a program from jumping into code it shouldn’t. The likely reason is a trick called module stomping: the malware loads a real-looking Microsoft DLL, then overwrites that DLL’s code in memory with its own. To a casual look at the process, the code appears to belong to Windows Media Player. With CFG still on, Windows could block the jump into the replaced code, so the payload strips it first.

Step four: the server hands out five kits

About 20 minutes after the install, the MSBuild process connects to 96.62.218[.]59 on port 443. This isn’t HTTPS. It is a custom binary protocol on the HTTPS port, so it can blend in with ordinary web traffic. We know this server: it was the command server of the CNCMachineRMS RAT in a signed fake Microsoft Teams installer we wrote about two weeks ago.

The server sent about 56 MB. That traffic is only lightly scrambled (each field XORed with a single byte, with files compressed), so we could unpack it. It is a list of five tasks, each naming a folder under %LOCALAPPDATA%, a program to start, and the files to write. Every file the sandbox collected from the three kit folders matches a file in that download byte for byte. After the download, the payload keeps checking in with the server every couple of minutes.

Each task is a DLL sideloading kit. Windows programs look for the DLLs they need in their own folder first. So if you put a genuine, signed program next to a tampered DLL with the right name, the trusted program loads the attacker’s code:

All six tampered DLLs are unsigned copies of real libraries with extra code patched in. Each kit also carries two data files with innocent-looking names such as graphlog15.bak and particle_policy.dat. Once running, each signed program copies its kit into its own folder under C:\ProgramData (for example AMDKernel and SysProc_core) and starts further signed programs, which we come to next.

Step five: inside the kits, HijackLoader and SectopRAT

We decoded all five kits’ data files without running them, starting with the ASUS kit’s proxy256.lock and watcherparam.bak. The tampered AsusTPApi.dll reads the small file, a block of shellcode disguised as jumbled English letters, writes it over the code of a Windows DLL (tapisrv.dll) and runs it there. That shellcode digs the real cargo out of the large file, where it is hidden in chunks formatted like the "IDAT" data blocks of a PNG image, then decrypts and decompresses it. The hidden chunks, their marker bytes (C6 A5 79 EA), the XOR decryption (with a different key in each kit), the LZNT1 compression and module names such as modUAC and modCreateProcess all match what Zscaler describes for HijackLoader, a modular loader that has been used to deliver many different stealers and RATs.

The cargo is a bundle of HijackLoader modules plus a signed program to hide in. In the ASUS kit it sets up a folder called %APPDATA%\AMDKernel and drops three more signed programs: a Qihoo 360 utility (360XPFix.exe), a VMware-signed copy of the Info-ZIP zip.exe, and Microsoft’s own Visual Studio CodeCoverage.exe, copied to %TEMP% as VHandler.exe. That last file is the real thing, untouched and validly signed by Microsoft. It is only a shell: the malware starts it and runs its own code inside it. That loader code:

• contains a known trick for skipping the Windows UAC (User Account Control) prompt, and PowerShell commands to add Microsoft Defender exclusions (we saw no sign in the sandbox that either ran);
• contains code to switch off AMSI, the Windows interface that lets antivirus scan scripts and .NET code in memory;
• decrypts and starts a .NET program inside VHandler.exe.

The other four kits are built the same way, with a different signed program as the shell each time:

The MAGIX kit swaps the Qihoo 360 utility for a signed Amazon Chime executable and leaves out the Defender commands. The ASUS, ACD and MAGIX kits carry byte-for-byte identical loader modules. The NetEase and VNG kits carry a newer, much larger Defender module (about 100 KB instead of 8 KB) and slightly changed task and UAC modules. The hidden .NET program is identical in all five. The operators set up five separate routes to one payload, most likely so that if security software blocks one signed program, another can still get through. In the sandbox, the ASUS kit’s copy was the only one we saw reach its server.

That .NET program is SectopRAT, also known as ArechClient2. Malcat’s code-similarity service matches it to SectopRAT (75% similarity; its next-best match, RedLine, scores 27%), and its features match public descriptions of that family. It is a remote-access trojan with a built-in stealer. Whenever its server tells it to steal, it always takes saved browser passwords, cookies, autofill data and cards, and data from 24 crypto-wallet browser extensions (including MetaMask, Coinbase Wallet, Binance Chain Wallet, TronLink and Ronin). Telegram sessions, Steam login files, Discord data, FTP logins, VPN files and files matching patterns the operator chooses are taken only if the server’s settings switch them on.

In the sandbox, VHandler.exe talked to 93.152.220[.]219 on port 443, again with a custom, non-HTTPS protocol, and uploaded about 2 MB over the run. Hours later it also exchanged a few UDP packets on port 81 with two more servers, 94.26.41[.]43 and 93.152.224[.]17.

A backup address book on the blockchain

SectopRAT also carries a fallback: a list of 12 public BNB Smart Chain servers (bsc-dataseed1-4.binance.org, .defibit.io and .ninicoin.io) and the address of a smart contract, stored encrypted in its configuration. Fortinet reported the same 12 backup servers in a SectopRAT variant in September. Here is the contract this build reads:

0xb11613acf39ad3b4dde427c27068d278fafa8998

If its server stops answering, the program asks those public servers to read that contract. The contract returns an encrypted string, which the program decrypts into a new server address. Because the blockchain is public and the contract can’t be deleted or seized the way a domain can, the operators can move their server at any time by writing a new value. The sandbox fits this: twice, while 93.152.220[.]219 was not responding, VHandler.exe contacted the blockchain servers one after another, and it stopped once its server answered again. That traffic was encrypted, so we could not see the requests themselves.

We read the contract ourselves. Today it decrypts to 93.152.220[.]219, the same server, which would explain why the program went back to it after each lookup.

What we still don’t know

• Is the code talking to 96.62.218[.]59 CNCMachineRMS? Probably. It uses the exact server from the Teams case, looks up servers through Google’s encrypted DNS like that build, goes quiet for about 15 minutes before calling (that build was set to wait 900 seconds), and receives "directory" tasks that drop a folder of files and start one of them, a task type that build supports. Two things don’t match: it checks in about every two minutes rather than every ten, and it unpacks files with a compression method we didn’t see in that build. Both could be build settings. The 16.6 MB .NET program is more likely the loader than the RAT itself. Just before the quiet period, the two Cloudflare-fronted domains delivered about 2.8 MB; that may be the RAT, loaded into the doctored wmp.dll, but we couldn’t see inside that traffic. We never got the RAT’s code, so this is a strong link, not a code-level match. Whatever it is, its job here was to deliver the kits, and SectopRAT is the payload we could confirm.
• Why only one SectopRAT copy reached its server in the sandbox. All five kits carry the same payload. The ACD kit’s SVault.exe started, but we saw no sign that it got as far as running .NET code. The other three shells were written to disk, but we have no record of them running or connecting. Whether that comes down to timing, a failed step or a deliberate check, we can’t tell from the data we have.
• How the code gets into the shell programs. We saw the result (SectopRAT running inside VHandler.exe), but not the exact injection technique.
• No visible loader code reads the 84-byte data_6efcd92.log, so it is most likely configuration for the payload.

Advice

For regular users: get drivers and storage tools from the vendor’s own website or your PC maker’s support page. If a "driver utility" asks you to install an MSI from a link or a download site, and its signature names a person rather than the company, don’t run it.

For defenders:

• Alert on MSBuild.exe (check the OriginalFileName, since it is often renamed) running from user-writable folders such as %LOCALAPPDATA%, or launched by msiexec.exe.
• Hunt for the environment variables CFG_SYSTEM_TASK_add8 and CFG_CONTEXT_PATH_0fa5 in process telemetry.
• Look for RunOnce values that run msiexec /x … /qn shortly after an install.
• Block the certificate serial, the two domains and the IP addresses below.
• Watch for MSBuild, even under another file name (check the file’s original name, MSBuild.exe), making HTTPS connections to 8.8.8.8 or other public DNS-over-HTTPS resolvers.
• Look for a copy of wmp.dll (or another system DLL) loaded from %TEMP%. A system DLL loaded from a user folder with Control Flow Guard switched off is a strong sign of module stomping. The patched copy here also fails its own PE header checksum, a cheap static tell.
• Hunt for signed programs from MAGIX, ACD Systems, ASUS, NetEase or VNG running from %LOCALAPPDATA%\appdata, appspace or appspace1, and for folders named API_v1_0_prod, SysProc_core, AMDKernel, debug_tool and scheduler_node_v5 under C:\ProgramData or %APPDATA%.
• Flag non-TLS traffic on port 443. Both 96.62.218[.]59 and 93.152.220[.]219 speak a custom protocol on that port.
• Alert on non-browser processes, especially ones in %TEMP%, connecting to public blockchain RPC endpoints such as bsc-dataseed*.binance.org.
• Treat Microsoft’s CodeCoverage.exe running outside a Visual Studio install, under another name or from %TEMP% or the user profile, as suspicious, and especially so if it loads the .NET runtime or makes network connections. The same goes for DBeaver CLI, Bvckup 2 or CHENGDU YIWO (EaseUS)-signed programs running from %TEMP%, %LOCALAPPDATA% or the root of the user profile. These are genuine files, so hunt by path and original file name, not by hash. The kits also reference the user’s Startup folder and include a scheduled-task module, so check both for these programs.
• If SectopRAT ran on a machine, assume its browser passwords, cookies and wallet extensions are compromised, along with Telegram, Steam and Discord sessions: change passwords from a clean device, revoke sessions and move any crypto funds.

IOCs

The public sandbox run is at app.any.run/tasks/42df84dd-c5e1-414e-b30b-8c63f29259ba.

Thanks for reading. If you have seen this SectopRAT build or contract elsewhere, or another file signed with this certificate, we would love to hear about it.