tl;dr:

I analysed a malware.zip containing a Windows installer, deps.html, and an embedded Python runtime. Unpacking it exposed two malicious chains: an MSI leading to a backdoor strongly matching LegionLoader/Satacom, and a Python chain leading to remote-control malware with hidden-desktop functionality.

The interesting part was getting past the packaging. The installer hid its payload outside the normal installed files, while the .html file was actually executable Python. Here’s how both chains work.

parent post: https://www.reddit.com/r/OperSec/s/L5R6BgfB4F

1. The installer hides its scripts in the MSI database

S483.msi presents itself as SynerIntegration 4.1.6, published by “Sare Level Corp.” Its ordinary cabinet payload contains a tiny package-notes.txt. The malicious content sits in the MSI Binary table: an obfuscated VBScript, PowerShell, and an encrypted native payload.

During initial installation, a custom action runs the VBScript. Decoding its Chr(...) expressions reveals the sequence: locate the original MSI, extract the PowerShell stream, write it to a random .ps1 under %TEMP%, and launch it with a hidden window. It then attempts to delete the temporary script.

The PowerShell decodes another script and compiles C# helpers to read the MSI stream and manually map a Windows executable into memory. Following the payload through three AES layers, including byte reversal in the later stages, recovered the final backdoor.

2. Decrypting the configuration exposed the first C2

The final MSI-derived PE still hides its configuration behind RC4. I traced the record table at RVA 0x6FBF0 and reproduced the decoding separately. That recovered yugernaut[.]com, nfront.php, nback.php, and the HTTPS URL templates used to assemble its requests.

The AES/reversal stages, thread-pool execution, environment screening and these request paths closely match published LegionLoader research. The code also prepares host information for transmission and supports handling additional payloads.

A separately encrypted helper goes after Chrome’s app-bound key. It reads Local State, extracts and Base64-decodes app_bound_encrypted_key, removes the APPB prefix, and calls Chrome’s COM elevation service. It tries a newer interface first, then falls back to the legacy one. On success, it returns 32 bytes of key material through a named pipe. That is concrete key-theft logic; whether it succeeds depends on the execution context and browser configuration.

3. The HTML file is Python carrying native shellcode

deps.html contains a large amount of page-like junk inside Python strings. Its executable portion reverses an encoded byte string, Base64-decodes it, decompresses it with zlib, and executes the resulting Python source.

The decoded source waits ten seconds, places roughly 3.5 MB of native shellcode into a ctypes buffer, marks the memory executable with VirtualProtect, and calls it. The supplied Python runtime files matched the official Python 3.11.9 embedded distribution byte for byte.

The native loader conceals encrypted bytes in x64 instruction operands. Extracting those fields and reproducing its modified ChaCha routine recovered another PE containing the remote-control program.

One detail initially broke the decoding: a timing check controls a decryption-key byte. The loader requests a 35-second wait. Controlled emulation showed a 17.5-second acceptance boundary under the tested conditions; passing the check changes that byte from 14 to dd. Reproducing that path explained the earlier failed decryption.

4. The recovered program has browser, shell and hidden-desktop handlers

The embedded program’s decoded strings and surrounding code include hvnc/hvnc_original, browser DevTools commands, screenshot requests, PowerShell execution, file uploads/downloads, and several persistence mechanisms. It also handles browser profiles, cookies and login databases.

Its configuration decoder produced two WebSocket C2 hostnames. These are the endpoints recovered across both branches:

I also reproduced its registration-message construction: register,<host-id>,<channel>,<nonce>,<tag>. The tag uses FNV-1a with a fixed prefix, DGnk_24598AWE*&; independent calculations matched three native-generated test messages. Another handler parses modules beginning with HEIZ and contains image-mapping and thread/APC execution paths.

Infrastructure checks on 16 October: the two WebSocket domains were registered four seconds apart through the same registrar and used the same Cloudflare nameservers. Their returned addresses were Cloudflare infrastructure, not exposed origin servers. No verified operator identity emerged.

Someone who reviewed the files suggested RomulusLoader. I’m keeping that as an attribution lead pending a matching sample or code comparison. The recovered payloads and endpoints are stronger evidence than the proposed family name.

Both malicious branches were present in the archive, but I haven’t established that one launches the other. Analysis used static extraction and isolated native-code emulation, without connecting to the C2s. The code supports remote access and browser-data theft; no successful theft from a real victim was demonstrated.

Original archive SHA-256: add895704d082c6f0be53394905e569ab9683da041e4410489e1af19667e844a