Recently, the SonicWall Capture Labs Threat Research Team discovered a sophisticated multi-stage .NET malware campaign that delivers the LokiBot information stealer via a heavily obfuscated infection chain. The malware uses multiple .NET loader stages, layered decryption, and process hollowing to evade detection before executing the final native LokiBot payload.
Figure 1. Multi-stage LokiBot infection chain.
Stage 1 Loader (CallerFilePathAttribu.exe)
The analysis begins with a managed .NET executable, CallerFilePathAttribu.exe, which serves as the entry point of the malware chain. The loader then accesses the embedded bitmap resource, IApplicationTrustManag, which contains the encrypted second-stage payload, as shown in Figure 2.
Figure 2. Embedded bitmap resource containing the encrypted second-stage payload.
The loader first extracts the embedded payload from the bitmap and performs a custom XOR decryption, which recovers both the encrypted payload and its associated decryption key. The recovered payload is then Base64-decoded before being passed to a TripleDES decryption routine, as shown in Figure 3. This routine computes the MD5 hash of the supplied key string to generate the TripleDES decryption key, which then decrypts the Base64-decoded ciphertext in ECB mode.
Figure 3. TripleDES decryption and Base64 decoding of the second-stage payload.
The decrypted output is not the final payload itself, but another Base64-encoded string, which is then Base64-decoded to obtain the second-stage .NET loader.
Once the second-stage payload is recovered, the loader loads it directly into memory using Assembly.Load(). As shown in Figure 4, it retrieves the target type with Assembly.GetType() and prepares an object[] containing three runtime parameters:
"494170706C69636174696F6E54727573744D616E6167" – Resource name (IApplicationTrustManag).
"63544144537664516C" – XOR key used to decrypt the second-stage loader.
ServiceManager – Namespace used to locate the embedded resource.
The loader then passes these parameters to the second-stage assembly via Type.InvokeMember(), transferring execution to the next stage using .NET Reflection.
Figure 4. Reflective loading and execution of the second-stage .NET Loader.
Stage 2 Loader (EnvoySinks.dll)
The second-stage loader does not include its own resources. It transfers execution directly to the ServerIdentityObject. As shown in Figure 5, the constructor receives the same three parameters passed by the first stage and immediately calls the abc() method. The loader then waits for 33–45 seconds before continuing. This delay can slow automated analysis and may cause the malicious activity to be missed.
Figure 5. Second-stage constructor with first-stage parameters.
After the delay, the second-stage loader calls the xyz() method with the hex resource name (IApplicationTrustManag) and the project name (ServiceManager). The xyz() method calls Assembly.GetEntryAssembly() to retrieve the first-stage executable and extracts its bitmap resource, which contains the encrypted third-stage loader. The bitmap is then passed to the cba() method, which extracts data from each pixel using GetPixel().ToArgb(). The first four bytes store the payload size, while the remaining bytes contain the encrypted third-stage loader. The inherited key (cTADSvdQl) is then used by a custom XOR routine to decrypt the third-stage .NET assembly, as shown in Figure 6.
Figure 6. Custom XOR routine recovering the third-stage .NET assembly.
After decrypting the third-stage loader, the second-stage loader loads it into memory using AppDomain.CurrentDomain.Load(). It then retrieves the required class and method using GetTypes() and GetMethods() respectively and invokes the Fedree() method via Interaction.CallByName(). As shown in Figure 7, calling the Reuniao class triggers its static constructor, which initialises the third-stage loader before Fedree() continues execution.
Figure 7. Reflective loading and invocation of the third-stage .NET assembly.
Stage 3 Loader (CF_Secretaria.dll)
The third-stage loader is another obfuscated .NET assembly that recovers and executes the native LokiBot payload. Due to extensive identifier obfuscation, de4dot was used to improve code readability. Execution begins in the static constructor (Reuniao()), which resolves the required Windows APIs and initiates payload recovery. It then retrieves the E7xj2GK.resources resource, which contains an encrypted byte array. The loader applies a custom XOR routine to this data, producing another encrypted blob, as shown in Figure 8, which is then passed to the next decryption stage.
Figure 8. First-stage decryption of the encrypted resource blob.
The intermediate encrypted blob is then passed to the second decryption routine, as shown in Figure 9. The loader uses the first 16 bytes as the decryption key, while the remaining bytes contain the encrypted native LokiBot payload. It then uses this key to decrypt the payload and recover the native LokiBot PE.
Figure 9. Recovery of the native LokiBot PE.
Before process hollowing, the third-stage loader resolves the required Windows APIs at runtime rather than using the Import Address Table (IAT). As shown in Figure 10, it loads the required DLL with LoadLibraryA(), retrieves the API address with GetProcAddress(), and converts it to a .NET delegate using Marshal.GetDelegateForFunctionPointer(). It uses the same method to resolve APIs for process creation, memory operations, thread context changes, and ResumeThread().
Figure 10. Dynamic resolution of native Windows APIs
After resolving the required APIs, the loader invokes the CreateProcessA() delegate to create a suspended instance of itself. It then manually parses the decrypted LokiBot payload and uses WriteProcessMemory() to write its headers and sections to the specified addresses in the suspended process. Once the payload is fully written, the loader calls ResumeThread() to resume the process and execute LokiBot.
Stage 4 Lokibot Stealer:
Once the process hollowing is complete, execution reaches the decrypted LokiBot payload. LokiBot is an information-stealing malware known for targeting credentials and other sensitive data from web browsers, cryptocurrency wallets, email clients, FTP software, and other applications. The stolen data is then sent to attacker-controlled C2 servers.
Figure 11. PE header of the decrypted LokiBot.
Figure 11 shows the PE header of the recovered native LokiBot payload. Although the LokiBot binary has a PE timestamp of Thu Jun 23 09:04:21 2016, it is delivered via a newer multi-stage .NET loader that uses steganography, layered decryption, and process hollowing. This indicates that threat actors continue to reuse older LokiBot payloads while adopting newer delivery methods. For a detailed analysis of the native LokiBot stealer, see our LokiBot
Yogesh is a threat researcher specializing in malware reverse engineering, infection chain analysis, and investigation of advanced attack techniques. He also works on developing detection and protection solutions against evolving malware threats.
Related Articles
No File, No Trace: How a Fake Invoice Hides a Formbook Loader in Plain Sight
