.NET Obfuscation & De-obfuscation

.NET Obfuscation & De-obfuscation

The Obfuscation Arms Race

Because .NET decompilation produces near-source-code quality output, malware authors must obfuscate their code to hinder analysis. Without obfuscation, an analyst can open a .NET RAT in dnSpyEx and read C2 addresses, encryption keys, and the full program logic within minutes. Obfuscation raises the cost of analysis -- but it does not make analysis impossible.

Understanding the common obfuscation techniques and how to defeat them is a core skill for .NET malware analysts. The general approach is: try automated de-obfuscation first (de4dot), fall back to dynamic analysis (debugging) when automation fails.

Categories of .NET Obfuscation

.NET obfuscation operates at multiple levels. Most commercial obfuscators combine several of these techniques:

1. Symbol Renaming

The simplest and most common technique. Classes, methods, fields, and variables are renamed to meaningless identifiers:

Before obfuscation:
  class NetworkClient { void ConnectToC2(string host, int port) }

After basic renaming:
  class a { void b(string c, int d) }

After Unicode renaming (Eazfuscator style):
  class \u0001 { void \u0002(string \u0003, int \u0004) }

The Unicode renaming variant uses unprintable characters that appear as blank boxes in most decompilers, making the code extremely difficult to read visually.

Real-World Example: The chatroom.exe sample analyzed in SANS FOR610 uses Eazfuscator with Unicode character renaming. Class names appear as invisible/unprintable characters in dnSpyEx, forcing analysts to rely on behavioral analysis rather than name-based navigation.

2. String Encryption

All string literals (C2 URLs, registry keys, file paths, API names) are encrypted at compile time. At runtime, a decryption method is called before each string use:

Before:
  string c2 = "http://evil.com:8080/gate.php";

After:
  string c2 = StringDecryptor.Decrypt("a3F2X09iZnVzY2F0ZWQ=");

The decryption method is often called hundreds of times throughout the code, always with different encrypted inputs.

3. Control Flow Obfuscation

The logical flow of methods is restructured using switch statements, state machines, and opaque predicates:

Before:
  DoStep1();
  DoStep2();
  DoStep3();

After (switch-based flattening):
  int state = 0;
  while (true)
  {
      switch (state)
      {
          case 3: DoStep1(); state = 7; break;
          case 7: DoStep2(); state = 1; break;
          case 1: DoStep3(); return;
          default: state = 3; break;
      }
  }

4. Anti-Tamper and Anti-Debug

Protections that detect analysis environments and terminate if detected:

• Anti-tamper: Verifies assembly integrity at runtime (checksums, strong name verification)
• Anti-debug: Checks for debuggers using Debugger.IsAttached, timing checks, or NtQueryInformationProcess
• Anti-VM: Detects virtual machines via WMI queries, registry checks, or known VM artifacts

5. Proxy Method Delegates

Direct method calls are replaced with delegate invocations, breaking the decompiler's ability to resolve call targets:

Before:
  File.WriteAllBytes(path, data);

After:
  delegateField_42(path, data);  // Delegate resolved at runtime

6. Resource Encryption

Embedded resources (which often contain second-stage payloads) are encrypted. The assembly decrypts them at runtime using a key derived from the assembly metadata or hardcoded values.

Common .NET Obfuscators -- Identification and Response

Using Detect It Easy (DiE) for Obfuscator Identification

DiE output for Eazfuscator-protected sample:
  Protector: Eazfuscator.NET(v2023.x)
  Compiler:  Microsoft Visual C# v10.0 (.NET CLR v4.0)

DiE output for ConfuserEx-protected sample:
  Protector: ConfuserEx(v1.x)
  Compiler:  Microsoft Visual C# (.NET CLR v4.0)

de4dot -- The Universal .NET De-obfuscator

de4dot is the standard automated de-obfuscation tool. It detects the obfuscator type and applies appropriate cleaning passes. Always try de4dot first before spending time on manual de-obfuscation.

Basic Usage

# Auto-detect obfuscator and clean (produces suspect-cleaned.exe)
de4dot suspect.exe

# Example output:
# Detected Eazfuscator.NET 2020.1+
# Cleaning...
# Renaming symbols with short names
# Decrypting strings
# Removing proxy delegates
# Saved cleaned assembly to suspect-cleaned.exe

# Specify output file explicitly
de4dot suspect.exe -o cleaned.exe

# Force a specific obfuscator detection (if auto-detect fails)
de4dot suspect.exe --strtyp delegate --strtok 06000042

What de4dot Cleans

Verifying de4dot Results

After running de4dot, always verify the output:

1. Open cleaned assembly in dnSpyEx
2. Check: Are string literals now visible? (C2 URLs, paths, keys)
3. Check: Are class/method names more readable?
4. Check: Can you follow the execution flow from Main()?
5. Check: Are resources now accessible?

Important: de4dot produces cleaned symbols, not original symbols. method_0 is more readable than Unicode garbage, but it is not the original name the developer used. You still need to analyze behavior to understand each method's purpose.

When de4dot Fails: Manual De-obfuscation

de4dot handles the majority of cases, but it can fail on:

• Custom obfuscators not in its database
• Heavily modified versions of known obfuscators
• Multi-layer obfuscation (e.g., ConfuserEx + custom packing)
• Assemblies with native code stubs that must run first

Manual String Decryption via Debugging

This is the most common manual technique. The idea: let the malware decrypt its own strings, then collect the results.

Step 1: Open the obfuscated assembly in dnSpyEx
Step 2: Locate the string decryption method
        - It is typically called from many places
        - It takes an encrypted string/int and returns a decrypted string
        - Use Analyze > "Used By" to confirm it is called frequently
Step 3: Set a breakpoint on the RETURN statement of the decryption method
Step 4: Debug > Start Debugging (F5)
Step 5: Each time the breakpoint hits, note the return value (decrypted string)
Step 6: Press F5 to continue to the next call
Step 7: Collect all decrypted strings in a spreadsheet or text file

Manual String Decryption via Scripting

If you can identify the decryption algorithm, write a standalone script to decrypt all strings at once:

import base64
from Crypto.Cipher import AES

# Example: Common XOR + Base64 string decryption pattern
def decrypt_string(encrypted, key=0x42):
    decoded = base64.b64decode(encrypted)
    return bytes([b ^ key for b in decoded]).decode('utf-8')

# Encrypted strings extracted from the obfuscated assembly
encrypted_strings = [
    "KissKT0kPCQ8JA==",
    "NzI3NjMy",
    "JCksKSYpJg==",
]

for s in encrypted_strings:
    print(f"{s} -> {decrypt_string(s)}")

DotDumper -- Automated Runtime Extraction

DotDumper is a specialized tool that monitors .NET assembly execution and automatically extracts:

• Decrypted strings
• Loaded assemblies (Assembly.Load payloads)
• Written files
• Network connections
• Registry modifications

# Run DotDumper against the obfuscated sample
DotDumper.exe -file suspect.exe -log output.json

# DotDumper hooks Assembly.Load, File.Write, WebClient, etc.
# and captures all dynamic content including decrypted payloads

This is particularly effective for multi-stage .NET malware that uses Assembly.Load to chain stages -- DotDumper captures each loaded assembly as a separate file.

Real-World De-obfuscation Walkthrough

Consider the chatroom.exe sample from SANS FOR610, protected by Eazfuscator:

1. DiE identifies: "Eazfuscator.NET"
2. Open in dnSpyEx -> class names are unprintable Unicode characters
3. Run de4dot:
     de4dot chatroom.exe
     Output: "Detected Eazfuscator.NET" -> chatroom-cleaned.exe
4. Open chatroom-cleaned.exe in dnSpyEx:
     - Class names now readable: Class0, Class1, Class2...
     - Strings now visible in decompiled code
     - Can identify Assembly.Load pattern loading second stage
5. Trace execution: Main() -> decrypts resource -> Assembly.Load()
     -> Second stage ("Windows Mddules.dll") loads
     -> Second stage decrypts and loads final payload (ReZer0V4.exe)

Obfuscation Identification Quick Reference

MITRE ATT&CK Mapping