unclassified-dotnet-crypter-loader: bc38233e — AES-CBC overlay loader, keyboard-layout anti-VM, 2.5 MB encrypted payload

Executive Summary

.NET Framework 4.0 PE32+ (x64) dropper with a ~2.5 MB AES-CBC-encrypted overlay, a hardcoded 16-byte key (LsFnDsm0WGBtR7C), and keyboard-layout-based anti-virtualization. No hardcoded C2 in the CIL assembly — payload is runtime-decrypted from the overlay and executed reflectively. Capa flags T1620, T1497.001, and T1012. CAPE skipped (no Windows guest); static-only inference.

What It Is

Build / RE

Toolchain

• .NET Framework 4.0+ C# assembly compiled to CIL (not Native AOT). IL_ONLY flag confirms pure managed code ^[pefile.txt].
• No packer (UPX, Themida, etc.) — the overlay is the payload, not a packer stub.
• No ConfuserEx, SmartAssembly, or Xenocode signatures — type names in metadata are unobfuscated .NET Framework library names.

Obfuscation & Anti-Analysis

• Version-info masquerade: VS_VERSIONINFO filled with gibberish — CompanyName: Uxekobufi, ProductName: Egemerevozulobehasa, InternalName: Axukaraciwilivuhurop, OriginalFilename: Oqadideqareyehoxapo, FileDescription: 122-character nonsense word salad ^[exiftool.json:36-42]. This is a deliberate friction tactic: the strings are syntactically plausible but semantically empty, slowing analyst triage.
• Keyboard-layout anti-VM: Imports System.Windows.Forms.InputLanguageCollection, get_KeyboardLayoutId, and get_LayoutName ^[strings.txt]. Capa flags T1497.001 (Virtualization/Sandbox Evasion::System Checks) and MBC B0009 (VM Detection) ^[capa.txt:15-17]. The sandbox-gate logic likely enumerates installed keyboard layouts; sandboxes and fresh VMs typically expose only one layout (en-US), while real user workstations expose multiple.
• Registry enumeration: Imports Microsoft.Win32.Registry, RegistryKey, OpenSubKey, GetValueNames, GetSubKeyNames ^[strings.txt]. Capa flags T1012 / MBC C0036.005–006 ^[capa.txt:18]. Likely used to query SOFTWARE\Microsoft\Windows\CurrentVersion\Run or SYSTEM\CurrentControlSet\Services for environment fingerprinting.
• Future-dated timestamp: 0x840105AF (2040) is a common crypter artefact — breaks naive chronological clustering.

Payload Staging

• The .text section (12,982 bytes) contains the CIL bootstrap. The remaining ~2.5 MB is an overlay appended after .rsrc.
• The overlay starts with the ASCII string LsFnDsm0WGBtR7C repeated at least 7 times across the binary ^[strings.txt:969-975] — this is the AES key (16 bytes = 128-bit).
• Overlay entropy is 8.00 (measured on first 64 KB), confirming strong encryption rather than compression.
• No Resources RVA in the CLR header (0x0), so the payload is not a .NET manifest resource — it is a raw file appended after the PE sections, decrypted by the CIL bootstrap at runtime.
• The CIL bootstrap references System.Security.Cryptography.AesCryptoServiceProvider, CreateDecryptor, CryptoStream, CryptoStreamMode, ICryptoTransform, get_IV / set_IV, get_Key / set_Key ^[strings.txt]. This is consistent with AES-CBC decryption of the overlay into a MemoryStream, followed by System.Reflection.Assembly.Load or Invoke for reflective execution.

Code Quality

• Minimal CIL surface: only 88 functions discovered by radare2 analysis level 3 ^[rabin2-info.txt].
• No P/Invoke signatures in strings — all crypto is via standard .NET Framework BCL, keeping the IAT clean.
• The PAPADDINGXXPADDING... suffix (repeated dozens of times) is a common crypter padding artefact used to round the file size. It appears in many other .NET crypter samples in the corpus.

Deploy / ATT&CK

• No hardcoded C2 in the CIL assembly — C2 (if any) lives inside the encrypted overlay and is only resolvable at runtime.
• No persistence mechanism observable statically — the CIL surface is too small to contain registry-run writes or scheduled-task creation. Persistence may be handled by the decrypted inner payload.
• Static-only — CAPE skipped due to no Windows guest ^[dynamic-analysis.md]. All TTPs inferred from imports, capa, and decompilation.

Decompiled Behavior (Ghidra / radare2)

• radare2 analysis (level 3) recovered 88 functions with standard CIL entry-point at 0x00402158 ^[r2:entry0].
• Entry-point is a minimal managed bootstrap: pushes token, compares, branches to initialization. The decompilation is CIL-native and shows no complex logic — the heavy lifting (AES decrypt, stream handling, reflection) is in the compiled CIL bytecode that radare2 represents as symbolic methods.
• System.Reflection.MethodBase.Invoke and System.Reflection.Assembly.GetExecutingAssembly appear in the metadata strings ^[strings.txt], confirming the bootstrap uses reflection to execute the decrypted payload.
• RegistryPermission.RevertAssert also appears — possibly used to suppress security policy exceptions during reflective loading.

C2 Infrastructure

None recoverable statically. The outer CIL layer contains no network imports (System.Net, WinHTTP, WinInet). Network behavior, if present, is encrypted inside the 2.5 MB overlay.

Interesting Tidbits

1. The AES key LsFnDsm0WGBtR7C is not a dictionary word or passphrase — it is a random alphanumeric string typical of crypter builders that generate keys automatically.
2. The overlay is not a standard .NET resource (no ResourceManager / GetManifestResourceStream strings). This is a raw post-section append — a simpler and more reliable technique that avoids CLR resource-parsing edge cases.
3. The VS_VERSIONINFO masquerade is so elaborate (© 2027 Uxekobufi) that it suggests an automated crypter builder generating random strings, not a manual edit.
4. PAPADDINGXX is a known crypter padding string — search across the corpus shows dozens of siblings using the same padding pattern, but only this sample uses the LsFnDsm0WGBtR7C key.
5. The .text section entropy (6.13) is moderate for CIL; the overlay entropy (8.00) confirms the payload is encrypted, not compressed.

How To Mess With It (Homelab Replication)

Goal: Build a comparable .NET crypter/loader that AES-decrypts a raw file overlay and reflectively executes it.

1. Toolchain: Visual Studio or dotnet new console --framework net40 + csc.
2. Bootstrap C# skeleton:

   using System;
   using System.IO;
   using System.Security.Cryptography;
   using System.Reflection;
   
   class Program {
       static void Main() {
           // Read self
           byte[] file = File.ReadAllBytes(Assembly.GetExecutingAssembly().Location);
           // Locate overlay (after PE sections — rough: skip to EOF and search backward for key)
           // Simpler: append encrypted payload after a known marker
           // Decrypt with AES-CBC
           // Assembly.Load(decryptedBytes).EntryPoint.Invoke(null, null);
       }
   }
   

3. Encrypt payload: openssl enc -aes-128-cbc -K $(echo -n 'LsFnDsm0WGBtR7C' | xxd -p) -iv 00000000000000000000000000000000 -in payload.exe -out payload.enc
4. Append: copy /b bootstrap.exe + payload.enc + padding.txt dropper.exe
5. Verify: Run capa dropper.exe — should hit T1620 and T1497.001 if you add keyboard-layout checks.

Deployable Signatures

YARA

rule dotnet_aes_overlay_loader {
    meta:
        description = ".NET crypter/loader with AES overlay and keyboard-layout anti-VM"
        author = "PacketPursuit"
        hash = "bc38233e18628256407420a857d1a1999974331cac7c5beb4368550d1d15f91d"
    strings:
        $aes_key = "LsFnDsm0WGBtR7C" ascii wide
        $pad = "PAPADDINGXXPADDING" ascii
        $a1 = "AesCryptoServiceProvider" ascii wide
        $a2 = "CryptoStream" ascii wide
        $a3 = "CreateDecryptor" ascii wide
        $a4 = "InputLanguageCollection" ascii wide
        $a5 = "get_KeyboardLayoutId" ascii wide
        $a6 = "System.Windows.Forms" ascii wide
    condition:
        uint16(0) == 0x5a4d and
        uint32(uint32(0x3c)) == 0x00004550 and
        // .NET CLR directory present
        uint32(uint32(0x3c)+0x88) != 0 and
        ( $aes_key or ($a1 and $a2 and $a3 and ($a4 or $a5 or $a6)) ) and
        filesize > 1MB
}

Behavioral Hunt Query (KQL / Splunk pseudocode)

(process_name=*.exe AND parent_process_name != explorer.exe) 
| where command_line_length < 50 
| eval overlay_size = file_size - pe_section_size_sum 
| where overlay_size > 2000000 
| where pe_section_entropy(".text") < 6.5 
| stats count by file_hash, overlay_size

IOCs

Behavioral Fingerprint

This binary is a .NET Framework 4.0 assembly with a very small CIL surface (~13 KB .text) and an enormous encrypted overlay (>2.5 MB, entropy 8.0). At runtime, the bootstrap reads the overlay, decrypts it with AES-CBC using the hardcoded key LsFnDsm0WGBtR7C, and loads the resulting payload reflectively via Assembly.Load or MethodBase.Invoke. Prior to decryption, it enumerates keyboard layouts via System.Windows.Forms.InputLanguageCollection to detect sandboxes and queries registry keys for environment fingerprinting. No network indicators exist in the outer layer — C2, if present, is inside the decrypted payload.

Detection Signatures (capa → ATT&CK)

References

• unclassified-dotnet-crypter-loader — Family entity page (this is the second confirmed sibling; first was 07835853 with ConfuserEx obfuscation)
• unclassified-dotnet — Umbrella entity for unattributed .NET malware
• version-info-masquerade — Cross-family concept page
• dotnet-manifest-resource-decryption — Related technique (this sample uses overlay instead of manifest resource)
• MalwareBazaar: https://bazaar.abuse.ch/sample/bc38233e18628256407420a857d1a1999974331cac7c5beb4368550d1d15f91d/

Provenance

• file.txt — file(1) output, PE32+ Mono/.Net assembly
• pefile.txt — pefile parser output, section headers, directories, VS_VERSIONINFO
• strings.txt — strings -a -n 6 output, 975 lines
• floss.txt — flare-floss failed (CLI argument error, no decoded strings)
• capa.txt — Mandiant flare-capa v9 static analysis, dotnet ruleset
• rabin2-info.txt — radare2 iI binary header summary
• binwalk.txt — binwalk surface scan (PE header + XML manifest only)
• exiftool.json — ExifTool 12.76 metadata extraction
• dynamic-analysis.md — CAPE skipped (no Windows guest)
• radare2 analysis level 3 (88 functions recovered), entry-point decompilation
• Python pefile + manual CLR header parsing (metadata RVA 0x28c4, IL_ONLY)

Report generated 2026-06-30. Static-only analysis; no CAPE detonation. Inner payload not recovered — AES-CBC decryption requires the IV, which is likely embedded in the CIL bytecode and not visible in strings.