unclassified-dotnet-tripledes-resource-loader: 5e1922a7 — TripleDES + Base64 resource decryptor, "new request" masquerade

Executive Summary

A .NET Framework PE32 crypter/loader that decrypts an embedded .resources payload using TripleDESCryptoServiceProvider with a hardcoded Base64 key/IV pair, then reflectively loads the inner assembly. The outer binary masquerades as a benign "new request" application with minimal version-info metadata. No ConfuserEx or commercial obfuscator is present; the threat logic lives entirely in the encrypted resource and is not recoverable without detonation. Static-only analysis (CAPE skipped — no Windows guest).

What It Is

The VS_VERSIONINFO resource brands the binary as new request with FileDescription: new request, InternalName: new request.exe, and Copyright © 2018. ^[exiftool.json] This is a generic masquerade with no attempt at legitimacy through a known software vendor name.

How It Works

Payload Staging Chain

1. Resource Retrieval — On startup, the binary calls Nmvffwquw.Properties.Zyscaotxd.get_Cmoqoxce(), which wraps ResourceManager.GetObject("dkle") to retrieve an embedded .resources blob named Cmoqoxce. ^[r2:method.Zyscaotxd.get_Cmoqoxce]
2. Base64 Decode — The resource string is passed through Convert.FromBase64String(). ^[r2:method.Diqzw.Decrypt]
3. TripleDES Decrypt — A TripleDESCryptoServiceProvider instance is created with a hardcoded key and IV, then CreateDecryptor() is invoked. The decrypted stream is read into a MemoryStream via CryptoStream. ^[r2:method.Diqzw.Decrypt] ^[capa.txt]
4. Reflective Load — The decrypted bytes are loaded via Assembly.Load(byte[]) (inferred from the InvokeMember reference in CIL metadata and capa's load .NET assembly / invoke .NET assembly method hits). ^[capa.txt] ^[strings.txt:4]

Hardcoded Cryptographic Material

These values are stored as #US (Unicode string) entries in the CIL metadata heap. ^[strings.txt:4]

CIL Metadata Structure

The assembly contains only 10 methods, 5 type definitions, and 2 assembly references (mscorlib only). The namespace and class names are randomized 10–12 character gibberish strings, a lightweight anti-clustering technique:

• Nmvffwquw — root namespace
• Cxgajcbno — outer loader class (constructor)
• Kyyfnntjcyp — secondary class
• Diqzw — decryptor class (contains Decrypt() method)
• Properties.Zyscaotxd — strongly-typed resource accessor

^[r2:function list] ^[pefile.txt]

There is no ConfuserEx name mangling (#=q…== pattern absent), no SmartAssembly anti-tamper, and no P/Invoke surface (no LoadLibrary, GetProcAddress, VirtualProtect, or NtWriteVirtualMemory strings in metadata). ^[strings.txt]

Anti-Analysis

None observed. No debugger checks, no VM detection, no time-bombs, no sandbox gates. The binary runs straight through its decrypt-and-load chain. The only anti-static measure is the encrypted resource payload and the randomized type names.

Decompiled Behavior

Ghidra was not run (pyghidra MCP unavailable); radare2 CIL analysis provides the following entry-point summary:

• entry0 at 0x004020b4 is the standard _CorExeMain jump stub. ^[r2:entry0]
• method.Nmvffwquw.Kyyfnntjcyp.Uvngzbfbbiu is called from entry, performs basic initialization. ^[r2:method.Kyyfnntjcyp.Uvngzbfbbiu]
• method.Nmvffwquw.Cxgajcbno.Mpiqbkpvxcv orchestrates the decrypt-and-invoke chain, calling get_Cmoqoxce() → Decrypt(). ^[r2:method.Cxgajcbno.Mpiqbkpvxcv]
• method.Nmvffwquw.Diqzw.Decrypt implements the TripleDES + Base64 pipeline. ^[r2:method.Diqzw.Decrypt]

Control flow is linear: no branching on environment checks, no obfuscated dispatch. The decryptor is a thin wrapper around .NET crypto APIs.

C2 Infrastructure

No C2 indicators recovered statically. No URLs, IPs, domains, mutex names, named pipes, or registry keys observed. The inner payload is encrypted and not recoverable without detonation. ^[strings.txt] ^[dynamic-analysis.md]

Interesting Tidbits

• Minimal metadata footprint — Only 3,468 bytes of CLR metadata for a 1.6 MB binary. The remaining ~1.6 MB is almost entirely the encrypted .text section (entropy 7.999), suggesting the inner payload is large (likely a full second-stage .NET assembly). ^[pefile.txt]
• No P/Invoke bridge — Unlike the unclassified-dotnet-crypter-loader cluster, this sample does not import LoadLibrary or GetProcAddress, and shows no nativeEntry / nativeSizeOfCode fields. The entire threat surface is managed-code reflection.
• Linker anachronism — Linker version 8.0 (VS 2005) with a 2024 compile timestamp is unusual for a .NET Framework 4.0 binary. This may indicate a custom ILASM build pipeline, a crypter stub compiled long ago and reused, or an obfuscator that rewrites the PE header.
• Resource naming — The Cmoqoxce resource name and dkle lookup key are both 8-character gibberish, consistent with auto-generated crypter output.
• Floss failure — floss.txt contains only an argument-parsing error; no decoded strings were recovered. This is expected for a pure .NET binary where strings live in CIL metadata rather than the native .text section. ^[floss.txt]

How To Mess With It (Homelab Replication)

Toolchain

• Visual Studio 2005 or csc.exe targeting .NET Framework 2.0/3.5
• Alternatively, ILASM + a simple C# stub

Build recipe

1. Create a C# WinForms project with a Resources.resx file.
2. Embed your payload (a second .NET assembly) as a string resource, encrypted with TripleDES-CBC and Base64-encoded.
3. In Program.cs or a loader class, implement:

   var tdes = new TripleDESCryptoServiceProvider();
   tdes.Key = Convert.FromBase64String("nXTpESMRpQjY3K3fH3SDjg==");
   tdes.IV  = Convert.FromBase64String("m1U/vylewns=");
   var cipher = Convert.FromBase64String(Properties.Resources.Cmoqoxce);
   var decryptor = tdes.CreateDecryptor();
   var ms = new MemoryStream();
   using (var cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Write))
      cs.Write(cipher, 0, cipher.Length);
   var asm = Assembly.Load(ms.ToArray());
   asm.EntryPoint.Invoke(null, null);
   

4. Compile with csc /target:winexe /platform:x86.

Verification

Run capa against the reproducer. You should see the same five capabilities:

• decode data using Base64 in .NET
• access .NET resource
• invoke .NET assembly method
• load .NET assembly
• compiled to the .NET platform

Compare to capa.txt in this analysis directory.

Deployable Signatures

YARA Rule

rule dotnet_tripledes_resource_loader {
    meta:
        description = ".NET crypter/loader using TripleDESCryptoServiceProvider + Base64 resource decryption"
        author = "PacketPursuit"
        date = "2026-07-10"
        sha256 = "5e1922a744bc4df2ef384022a4554908baab68c8ee6c14305130c1d4fef79a3f"
    strings:
        $tripledes = "TripleDESCryptoServiceProvider" wide ascii
        $create_dec = "CreateDecryptor" wide ascii
        $fromb64 = "FromBase64String" wide ascii
        $resource1 = "Cmoqoxce" wide ascii
        $resource2 = "get_Cmoqoxce" ascii
        $key_b64 = "nXTpESMRpQjY3K3fH3SDjg==" wide ascii
        $iv_b64 = "m1U/vylewns=" wide ascii
        $crypto_stream = "CryptoStream" wide ascii
    condition:
        uint16(0) == 0x5a4d and
        ($tripledes and $create_dec and $fromb64) and
        (any of ($resource*)) and
        (any of ($key_b64, $iv_b64)) and
        filesize < 2MB
}

Behavioral Fingerprint Statement

This binary is a .NET Framework PE32 with a minimal IAT (only mscoree.dll._CorExeMain), a VS_VERSIONINFO masquerading as "new request", and an unusually large .text section (~1.6 MB) with near-maximum entropy. At runtime, it retrieves an embedded resource via ResourceManager.GetObject, Base64-decodes it, decrypts it with TripleDESCryptoServiceProvider.CreateDecryptor using a hardcoded 16-byte key and 8-byte IV, and loads the resulting assembly reflectively. No network APIs, no P/Invoke, and no persistence mechanisms are present in the outer layer. Detection should focus on the TripleDES + Base64 + ResourceManager chain.

IOC List

Detection Signatures (capa → ATT&CK)

References

• SHA-256: 5e1922a744bc4df2ef384022a4554908baab68c8ee6c14305130c1d4fef79a3f
• Source: MalwareBazaar / OpenCTI ingestion
• Related family: unclassified-dotnet-crypter-loader — similar .NET crypter/loader pattern but uses AES+GZip+Base64 instead of TripleDES; no shared method names or namespaces

Provenance

• file.txt — file(1) v5.45
• exiftool.json — ExifTool 12.76
• pefile.txt — pefile (Python)
• strings.txt — strings (GNU binutils)
• capa.txt — Mandiant capa v8.0.1 (static)
• rabin2-info.txt — radare2 5.9.8
• dynamic-analysis.md — CAPE sandbox (skipped — no Windows guest)
• CIL metadata parsed via custom Python script using ECMA-335 tables