DotRunpeX injector commonly comes as a second stage of the original infection.
The typical first stages are very different variants of .NET loaders/downloaders.
The first-stage loaders are primarily being delivered via phishing emails as malicious attachments (usually as a part of “.iso”, “.img”, “.zip”, and “.7z”) or via websites masquerading as regular program utilities.
Apart from the most common infection vectors, the customers of dotRunpeX are not ashamed to abuse Google Ads or even target other potential attackers via trojanized malware builders.
All of the trojanized programs contain the main .NET application enlarged with an overlay to avoid scanning with sandboxes very likely.
The .NET applications with overlay are the typical first stages, behaving as dotnet loaders with simple obfuscation.
These different variants of loaders use reflection to load the dotRunpeX injector in the second stage.
Some of them are very simple, and some are more advanced.
Programmatic way of second-stage extraction (dotRunpeX stage) from these kinds of loaders could be simply implemented using AsmResolver and reflection as shown below.
It turned out that during the building process of the Redline, configured to your needs, one will also get another Redline sample, probably the one that you didn’t desire, as a gift embedded in the dotRunpeX.
The new version of dotRunpeX:
Protected by a customized version of the KoiVM virtualizer
Highly configurable (disabling Anti-Malware services, Anti-VM, Anti-Sandbox, persistence settings, key for payload decryption, UAC bypass methods)
More UAC Bypass techniques
Using simple XOR to decrypt the main payload to be injected (omitted in the latest developed versions)
Abusing procexp driver (Sysinternals) to kill protected processes (Anti-Malware services)
Signs of being Russian based – procexp driver name translated as “jesus.sys”