When Static Analysis Fights Back: Reconstructing an Obfuscated .NET RAT

Author: Danyal Rana

SHA256: 255c08bad1b9fb0092be6870923e7918cdd11b07fde4657875df8363af9b8843

MD5: 25e1a98bf6b4ac5596ee8c805f80aea0

Executive Summary

This malware presented a deliberately hostile static-analysis surface. The .NET assembly contained randomized identifiers, flattened control flow, embedded resources, encrypted data, and extensive dispatcher logic. The primary analysis target included a method with a code size of 0x334f bytes (13,135 bytes), dominated by a large state-driven switch structure.

Static analysis initially focused on reconstructing the malware’s execution flow without executing it. This approach successfully identified several important components, including its control-flow flattening implementation, Rijndael-based cryptography, embedded data, native process-manipulation capabilities, and execution-context validation.

Dynamic analysis was subsequently performed in an isolated Windows environment using Procmon and System Informer. Runtime observation revealed file staging, execution of the .NET 2.0 CasPol.exe utility, creation of a child process, and termination of the original process.

A memory dump of the spawned process provided the most significant behavioral evidence. The recovered runtime state exposed RAT configuration, C2 infrastructure, a named mutex, staging logic, WMI reconnaissance, host information, and the identification of Microsoft Defender.

The combined static and dynamic analysis demonstrates how heavily obfuscated malware can significantly increase the cost of static reconstruction while still being forced to expose its operational state during execution.

1. Static Analysis

1.1 Control-Flow Flattening

The malware employs extensive control-flow flattening (CFF).

A large dispatcher is centered around an integer state variable which is passed to a switch containing hundreds of potential basic-block targets. Individual blocks perform small operations, update the state variable, and return to the dispatcher.

Conceptually, the execution flow is transformed into:

State variable
      │
      ▼
   Dispatcher
      │
 ┌────┼────┐
 ▼    ▼    ▼
Block A  Block B  Block C
 │       │       │
 └───────┴───────┘
          │
          ▼
     New state
          │
          └──► Dispatcher

This obscures the original control-flow structure and makes straightforward decompilation significantly more difficult.

The dispatcher is accompanied by numerous arithmetic operations whose results are subsequently used as byte values, indexes, or state identifiers. Much of this logic provides additional obfuscation rather than complex functionality.

1.2 Embedded Data and Resources

The assembly contains embedded resources and compiler-generated static data used during execution.

Private implementation structures contain static byte arrays, including 32-byte and 16-byte values that are consumed by the malware’s cryptographic routines.

These values are initialized at runtime using RuntimeHelpers.InitializeArray, making the underlying data less obvious during ordinary string extraction.

2. Cryptographic Protection

The malware contains a Rijndael-based cryptographic routine.

The decryption implementation:

1. creates a memory stream;
2. creates a Rijndael instance;
3. initializes a 32-byte key;
4. initializes a 16-byte IV;
5. creates a decryptor;
6. wraps the stream in a CryptoStream;
7. processes the encrypted data; and
8. returns the resulting plaintext.

The relevant IL directly shows initialization of the key and IV followed by CreateDecryptor().

A corresponding encryption routine is also present and uses CreateEncryptor() before converting the resulting ciphertext to Base64.

The presence of both routines indicates that the malware is capable of transforming data in both directions rather than relying solely on static encrypted configuration.

3. Native Process-Manipulation Capabilities

Static analysis identified a substantial set of native API imports associated with process creation and remote process manipulation, including:

CreateProcess
GetThreadContext
Wow64GetThreadContext
SetThreadContext
Wow64SetThreadContext
ReadProcessMemory
WriteProcessMemory
NtUnmapViewOfSection
VirtualAllocEx
ResumeThread

These APIs are commonly associated with suspended-process manipulation and process-hollowing techniques.

Additional imports include:

LoadLibrary
GetProcAddress
WriteProcessMemory
ReadProcessMemory
VirtualProtect
OpenProcess
CloseHandle

which provide further capabilities for manipulating process memory and resolving native functionality dynamically.

The static evidence therefore establishes that the malware contains the implementation primitives required for advanced remote-process manipulation.

The captured execution confirmed creation of a CasPol.exe child process; however, the available telemetry does not independently demonstrate that every process-hollowing API was invoked against that specific process. The distinction between capability and observed execution is therefore important.

4. Execution-Context Validation

The malware also performs an execution-path validation check.

It constructs an expected value using an environment variable and an additional decoded string, then obtains the current process’s main-module filename:

GetCurrentProcess()
    └── MainModule
         └── FileName

The resulting path is compared against the expected value using CompareString. When the validation condition is met, the malware terminates the current process using Process.Kill().

This is more accurately characterized as execution-context or image-path validation than as a conventional anti-VM mechanism.

A separate search for common virtualization indicators did not identify a convincing malware-specific set of VirtualBox, VMware, VBoxGuest, VMTools, QEMU, or similar vendor fingerprints.

5. Dynamic Analysis

5.1 Initial Execution

The malware was executed in an isolated Windows 10 environment under Procmon monitoring.

Procmon recorded the malware loading from the analysis environment and initializing the expected Windows and .NET runtime components.

The captured process-start activity did not show a sustained cmd.exe, PowerShell, wscript.exe, cscript.exe, mshta.exe, or similar interpreter process.

6. Temporary File Staging

One of the clearest runtime artifacts was:

%TEMP%\HawrHJfWfh.txt

Procmon recorded the file being created and a subsequent WriteFile operation with a length of exactly 39 bytes.

The file contents were the full path of the running malware.

Static analysis independently identified the corresponding logic: the malware retrieves the temporary directory, constructs the filename, obtains the executable path through Application.ExecutablePath, and writes the result to disk.

This provided a direct correlation between static code and observed runtime behavior.

7. CasPol.exe Execution

The malware accesses the legacy .NET 2.0 security-policy utility:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CasPol.exe

Procmon recorded the executable being opened and subsequently created as a child process.

The same path was recovered independently from the memory dump, where it appeared repeatedly alongside the .NET 2.0 runtime components.

The parent process terminated shortly after the child process was created.

The behavior is consistent with a staged execution design in which the original process performs preparation and transfers subsequent work to another process.

8. Runtime Configuration Recovery

The CasPol.exe memory dump produced some of the most valuable findings in the analysis.

The runtime state contained:

Revenge-RATL

127.0.0.1,192.168.0.20,hinou.ddns.net

333,333,333

R3Vlc3Q=

RV_MUTEX

\Client.vbs

WScript.Shell

These values were recovered from the same runtime environment as the CasPol.exe process and were not merely extracted from the original file.

The named mutex was also observable as a runtime object:

\Sessions\1\BaseNamedObjects\RV_MUTEX

providing additional evidence that the mutex string was operational rather than simply present as an unused static string.

9. Staging and Script-Execution Logic

The memory dump also exposed the following script-launching logic:

On Error Resume Next
CreateObject("WScript.Shell").CurrentDirectory = "%FP%"
CreateObject("WScript.Shell").Run "%FN%"

The surrounding runtime state references Client.vbs, WScript.Shell, registry locations, and the Client component.

This indicates that the malware contains a secondary scripting or staging component in addition to its primary executable logic.

10. Host Reconnaissance

The malware performs host reconnaissance through WMI.

The captured runtime state contains queries for:

Select * from AntiVirusProduct

SELECT * FROM FirewallProduct

select * from Win32_Processor

The memory dump also contains SecurityCenter2, AntiVirusProduct, and WMI references associated with Win32_Processor.

The recovered data demonstrates that the malware collects information about both the security environment and the underlying system.

11. Host Information and Beacon Data

The runtime memory contained a structured information record incorporating values derived from the analysis environment.

Recovered and decoded fields included:

Guest
_2A90377A
MADARA / Danny
Microsoft Windows 10 Pro 64
Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
Windows Defender
N/A
10.0.2.15

The corresponding Base64 values decoded as:

R3Vlc3Q=
    → Guest

XzJBOTAzNzdB
    → _2A90377A

TUFEQVJBIC8gRGFubnk=
    → MADARA / Danny

V2luZG93cyBEZWZlbmRlcg==
    → Windows Defender

TWljcm9zb2Z0IFdpbmRvd3MgMTAgUHJvIDY0
    → Microsoft Windows 10 Pro 64

SW50ZWwoUikgQ29yZShUTSkgaTUtNzMwMFUgQ1BVIEAgMi42MEdIeg==
    → Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz

Ti9B
    → N/A

These fields appeared within the recovered runtime information associated with the RAT configuration and indicate deliberate host profiling.

The runtime state also contained the hostname, network address, user information, processor information, operating-system information, and antivirus product.

12. Security-Product Enumeration

The malware specifically queried Windows Security Center information through AntiVirusProduct and SecurityCenter2.

The captured memory contains references to:

AntiVirusProduct
SecurityCenter2
Windows Defender
C:\Program Files (x86)\Windows Defender\MpOav.dll

The identified antivirus product was subsequently present within the host-information data assembled by the malware.

During the observed execution, Microsoft Defender real-time protection was enabled in the analysis environment and did not generate an immediate detection or prevention event.

This should not be interpreted as evidence that Defender was disabled or permanently bypassed. It demonstrates only that the malware was able to execute and enumerate the installed security product during the captured run.

13. Anti-VM and Anti-Analysis Assessment

The malware clearly performs environment profiling, but the available evidence does not establish a conventional vendor-specific anti-VM routine.

No convincing malware-specific collection of identifiers such as:

VBoxGuest
VBoxService
VMTools
vmtoolsd
VMwareTools
QEMU
Sandboxie

was identified during the targeted search.

Instead, the analysis identified:

• CPU enumeration
• operating-system profiling
• antivirus enumeration
• firewall enumeration
• host/user information
• network information
• execution-path validation
• process-oriented native APIs

The most defensible conclusion is therefore that the malware performs extensive environment fingerprinting, while dedicated VirtualBox/VMware detection was not established by the available evidence.

14. Static vs. Dynamic Findings

The strongest conclusions came from correlating both sources of evidence rather than relying exclusively on either.

15. Limitations and Confidence

Several findings require careful qualification.

Process hollowing

The malware contains the API set traditionally associated with process hollowing, including CreateProcess, NtUnmapViewOfSection, VirtualAllocEx, WriteProcessMemory, SetThreadContext, and ResumeThread.

This establishes capability.

The captured runtime evidence confirms creation of CasPol.exe, but it does not independently demonstrate the complete hollowing sequence against that specific process. A definitive conclusion would require API-level tracing, debugger observation, or direct comparison of the target process image and memory state.

Anti-VM behavior

The malware profiles its execution environment extensively, but the available evidence does not establish that it terminates specifically because it detected a virtual machine.

Defender

The malware identified Windows Defender and continued executing while real-time protection was enabled. This demonstrates successful execution during the captured run, not a universal Defender bypass.

16. Conclusion

This analysis illustrates an important property of heavily obfuscated malware: static concealment does not eliminate runtime requirements.

The malware can rename classes and methods.

It can flatten its control flow.

It can encrypt configuration.

It can distribute logic across a large dispatcher.

But eventually it must:

• decrypt data,
• create files,
• create or manipulate processes,
• query the host,
• construct configuration,
• and communicate.

Those actions create observable state.

In this case, static analysis uncovered the malware’s architecture and capabilities, while dynamic execution exposed the operational details that were difficult to reconstruct through the obfuscated control flow alone.

The most significant runtime discoveries included the temporary staging artifact, execution of CasPol.exe, the RV_MUTEX object, RAT configuration, C2 infrastructure, script-launching logic, WMI reconnaissance, host fingerprinting, and identification of Windows Defender.

For an analyst, the result is less about choosing static or dynamic analysis as a single preferred methodology and more about recognizing when each approach provides the strongest evidence.

Static analysis explains how the malware is designed to operate.
Dynamic analysis shows what that design actually produces at runtime.

And in this case, the runtime state provided the clearest view of what the malware was ultimately trying to accomplish.

Updated Notes: 

Process Hollowing Confirmed by Static Analysis

The malware contains a dedicated native process-injection routine that creates a target process with CREATE_SUSPENDED (0x4), retrieves and modifies its thread context, performs ReadProcessMemory/WriteProcessMemory operations, calls NtUnmapViewOfSection, allocates memory using VirtualAllocEx, writes payload data into the target process, and ultimately calls