Two loaders with different jobs
ExaTrack’s 5 November analysis describes a SectopRAT delivery chain using VMLoader and GPULoader. The first masquerades as libcef.dll beside a legitimate Chromium Embedded Framework executable. It checks the graphics environment, decrypts bytecode for a proprietary virtual machine, and retrieves a subsequent download address through a Binance Smart Chain contract. The downloaded archive can then supply the second loader and an encrypted companion payload. ExaTrack
Here, the virtual machine is a custom bytecode interpreter inside the malware. It is distinct from the VMware or QEMU environments that the loader attempts to screen out. The distinction matters when interpreting both the article title and sandbox results: a loader can execute its own virtualised instructions while rejecting an analysis host that looks virtualised. ExaTrack
What the GPU actually does
GPULoader masquerades as tempdir.dll and is sideloaded by a legitimate executable. It uses Direct3D 11 compute-shader execution to decrypt its companion file. ExaTrack describes an AES-256-CTR-derived routine with a modified MixColumns matrix. This is GPU-assisted payload decryption, not evidence of firmware infection or malware permanently resident in the graphics card. ExaTrack
Both loader stages use graphics-environment checks. A sandbox that fails those checks may never expose the next stage. The analyst should therefore report the conditions of an unsuccessful run, rather than concluding that a sample is harmless because no final payload appeared.
EtherHiding separates discovery from the final connection
The research describes smart-contract reads used to recover download or control information. Contract access and a subsequent connection to a returned server are different events. A request to a public blockchain endpoint alone is not sufficient evidence of this infection: legitimate software can use the same infrastructure. A stronger investigation joins process ancestry, unexpected DLL loading, companion-file access and the later network sequence.
ExaTrack also discusses optional additional tooling and possible relationships to other reporting. Those assessments should not be flattened into proof that every observed loader delivers the same components or that shared techniques establish a single operator. ExaTrack
Defensive priorities
TIR recommends inspecting legitimate executables running from unexpected download or user-profile locations, especially when they load adjacent DLLs. Signatures on a host executable do not authenticate every library that it loads. Preserve the host binary, suspected library and companion files as a set; analysing one file alone can omit the payload needed to understand the chain.
Correlate persistence changes and suspicious network activity with that execution context. Treat graphics API activity as supporting context, not a standalone malware signature. Where a laboratory lacks suitable GPU support, use the report’s static analysis and the available endpoint evidence to define what remains unobserved; do not run suspicious files on production systems to obtain a more complete trace.
