unclassified-dotnet-tripledes-resource-loader: e8744da8 — ConfuserEx-obfuscated variant, TripleDES resource decryption, reflective delegate execution

Executive Summary

A .NET Framework PE32 crypter/loader and the third confirmed sibling of the unclassified-dotnet-tripledes-resource-loader family. The outer binary uses ConfuserEx name mangling (#=q…== identifiers) and control-flow flattening, decrypts a large embedded .resources payload via TripleDESCryptoServiceProvider with a Base64-encoded key/IV pair, and reflectively executes the inner assembly via Assembly.Load → Type.GetType → Delegate.CreateDelegate → DynamicInvoke. Distributed as PO1029837346 Dec 1015.exe — a purchase-order social-engineering lure. Static-only analysis; no CAPE detonation data available.

What It Is

Family ascription: Confirmed third sibling of unclassified-dotnet-tripledes-resource-loader. Shared with prior siblings 5e1922a7 and 1051b5a4: TripleDES+Base64 resource decryption chain, Assembly.Load reflective loading, randomized CIL namespace/class names, Linker 8.0 anachronistic build, and purchase-order filename masquerade. ^[entities/unclassified-dotnet-tripledes-resource-loader.md]

Delta from siblings: This sample adds ConfuserEx obfuscation (prior siblings were unobfuscated) and carries a much larger encrypted payload (~1.3 MB vs ~232 bytes), suggesting the inner assembly may be a full-featured RAT or stealer rather than a minimal stub.

How It Works

Stage 1 — ConfuserEx De-obfuscation (Runtime)

The outer assembly is protected with ConfuserEx control-flow flattening and string encryption. At runtime, ConfuserEx's anti-tamper delegate decrypts strings and restores the original CIL before the CLR JIT compiles the entry point. ^[capa.txt] ^[strings.txt:792]

Stage 2 — TripleDES Payload Decryption

After de-obfuscation, the bootstrap reads an embedded .resources blob (observed via dnfile resource enumeration). The decryption chain is:

1. Convert.FromBase64String decodes the key and IV from hardcoded Base64 strings
2. TripleDESCryptoServiceProvider is instantiated
3. CreateDecryptor produces a ICryptoTransform
4. CryptoStream reads the resource stream through the transform

This matches the exact chain documented in siblings 5e1922a7 and 1051b5a4. ^[entities/unclassified-dotnet-tripledes-resource-loader.md] ^[/intel/analyses/5e1922a744bc4df2ef384022a4554908baab68c8ee6c14305130c1d4fef79a3f.html]

Stage 3 — Reflective Assembly Loading

The decrypted byte array is fed to Assembly.Load(byte[]) (inferred from Assembly.Load MemberRef in CIL metadata). The entry-point type is retrieved via Type.GetType or GetTypeFromHandle, and execution is dispatched through Delegate.CreateDelegate → DynamicInvoke. ^[pefile.txt] ^[strings.txt:406-448]

The absence of MethodBase.Invoke or EntryPoint strings in the outer layer suggests the inner assembly's entry point is invoked via delegate, not direct method call — a subtle variation from the InvokeMember pattern seen in sibling 5e1922a7.

Decompiled Behavior

No Ghidra decompilation was performed (sample is CIL/.NET; radare2's IL decompiler produces garbled output). Static inspection via dnfile reveals:

Namespaces and Types (ConfuserEx mangled)

• Primary namespace: Edodhixbr ^[dnfile: TypeDef rows]
• Key types: Edodhixbr.Spigbfcw (likely the resource wrapper / settings class), Edodhixbr.Gscpj (likely the decryption bootstrap)
• VS_VERSIONINFO CompanyName is empty; FileDescription masquerades as purchase-order document

MemberRef Import Surface

The CIL metadata imports the following critical APIs via MemberRef (statically visible after ConfuserEx layer is conceptually stripped):

^[dnfile: MemberRef table] ^[pefile.txt]

Resource Payload

The .resources embedded payload is large (~1.3 MB). Entropy analysis via binwalk and ssdeep shows high randomness consistent with encrypted data. No plaintext C2 URLs, IP addresses, or executable markers are visible in the encrypted blob. ^[binwalk.txt] ^[ssdeep.txt]

C2 Infrastructure

No hardcoded C2 in outer layer. The inner payload is decrypted and loaded reflectively; its network indicators are not recoverable from static analysis of the outer binary. The encrypted resource must be dumped at runtime (e.g., via dnSpy breakpoint on Assembly.Load or CAPE API hooking) to extract the inner assembly for further IOC extraction.

Interesting Tidbits

• Anachronistic linker: Linker version 8.0 (Visual Studio 2005) with a 2024 PE timestamp is identical to siblings 5e1922a7 and 1051b5a4. This strongly suggests a shared build pipeline — possibly ILASM rebuild or an old toolchain template reused across campaigns. ^[rabin2-info.txt] ^[exiftool.json]
• ConfuserEx variant emergence: Prior siblings were unobfuscated .NET assemblies with only randomized namespace names. This sample adds full ConfuserEx protection (control-flow flattening + string encryption + anti-tamper), indicating the actor or builder has evolved to defeat static string extraction.
• Filename pattern: "PO" + numeric tracking code + "Dec" + year fragment (PO1029837346 Dec 1015) mimics legitimate purchase-order document filenames. The space before "Dec" and the trailing "1015" (likely a fabricated document ID) are deliberately chosen to look like a scanned PDF converted to executable. ^[exiftool.json]
• Empty CompanyName: VS_VERSIONINFO CompanyName is blank — a common trait in ConfuserEx-packed binaries where the obfuscator strips or fails to populate version resource fields. ^[exiftool.json]
• No P/Invoke: Unlike the unclassified-dotnet-crypter-loader family, this sample has no LoadLibrary, GetProcAddress, VirtualProtect, or AMSI bypass APIs in the outer layer. The entire threat surface is managed .NET code, making EDR hook evasion harder but API monitoring easier. ^[pefile.txt] ^[strings.txt]
• FLOSS failure: FLOSS errored out during invocation (argument parsing failure), yielding no decoded strings. This is expected for ConfuserEx-protected .NET, where strings are encrypted in the PE and decrypted at runtime by the obfuscator's stub. ^[floss.txt]

How To Mess With It (Homelab Replication)

Reproducing the TripleDES+Base64 decryption chain

// Minimal C# reproducer matching the family's decryption pattern
using System;
using System.IO;
using System.Security.Cryptography;

class TripleDESLoader {
    static void Main(string[] args) {
        byte[] key = Convert.FromBase6464String("YOUR_BASE64_KEY_HERE");
        byte[] iv  = Convert.FromBase64String("YOUR_BASE64_IV_HERE");
        byte[] payload = File.ReadAllBytes("encrypted_payload.bin");

        using (var tdes = new TripleDESCryptoServiceProvider()) {
            tdes.Key = key;
            tdes.IV  = iv;
            using (var ms = new MemoryStream(payload))
            using (var cs = new CryptoStream(ms, tdes.CreateDecryptor(), CryptoStreamMode.Read)) {
                byte[] decrypted = new byte[payload.Length];
                cs.Read(decrypted, 0, decrypted.Length);
                File.WriteAllBytes("inner_payload.dll", decrypted);
            }
        }
    }
}

Compile with csc /target:exe TripleDESLoader.cs. Replace key/IV with values recovered from runtime analysis (dnSpy breakpoint on TripleDESCryptoServiceProvider.set_Key).

Verification step

Run capa reproducer.exe and compare to this sample's capa.txt — should hit T1140 (Deobfuscate/Decode Files or Information) and T1620 (Reflective Code Loading) if the reflection chain is present.

What you'll learn

How ConfuserEx-protected .NET crypters hide their inner payload using standard .NET crypto primitives, and why the outer layer is often "boring" (no C2, no P/Invoke) while all threat logic lives in the encrypted resource.

Deployable Signatures

YARA Rule

rule UnclassifiedDotNet_TripleDES_Resource_Loader {
    meta:
        description = "Detects .NET TripleDES+Base64 resource loader family"
        author = "PacketPursuit SOC"
        date = "2026-07-21"
        hash1 = "e8744da8113beed4a9f4f0c986e737b5f3711fb94a76a8daadc5b41c6745d863"
        hash2 = "5e1922a744bc4df2ef384022a4554908baab68c8ee6c14305130c1d4fef79a3f"
        hash3 = "1051b5a48a4db66f11b8a28762bc7fae03de6b0a425dbfea26f89b0d99506959"
        family = "unclassified-dotnet-tripledes-resource-loader"
    strings:
        $ TripleDESCryptoServiceProvider" fullword ascii wide
        $b = "FromBase64String" fullword ascii wide
        $c = "CreateDecryptor" fullword ascii wide
        $d = "CryptoStream" fullword ascii wide
        $e = "System.Reflection.Assembly" fullword ascii wide
        $f = "Delegate.CreateDelegate" fullword ascii wide
        $g = "DynamicInvoke" fullword ascii wide
        $h = "GetManifestResourceStream" fullword ascii wide
        // ConfuserEx indicator (may be absent in unobfuscated siblings)
        $confuser = "#=q" ascii
    condition:
        uint16(0) == 0x5A4D and
        uint32(uint32(0x3C)) == 0x00004550 and
        4 of ($a, $b, $c, $d, $e, $f, $g, $h) and
        filesize < 5MB and
        // .NET assembly marker
        pe.data_directories[14].virtual_address != 0
}

Sigma Rule

title: .NET TripleDES Resource Loader Execution
logsource:
    product: windows
    category: process_creation
detection:
    selection:
        CommandLine|contains:
            - 'PO1029837346'
            - 'PO'
    selection_dotnet:
        Image|endswith:
            - '\dotnet.exe'
            - '\MSBuild.exe'
        CommandLine|contains:
            - 'PO1029837346 Dec 1015.exe'
    selection_hashes:
        Hashes|contains:
            - 'e8744da8113beed4a9f4f0c986e737b5f3711fb94a76a8daadc5b41c6745d863'
    condition: 1 of selection*
falsepositives:
    - Legitimate purchase-order processing applications (unlikely given the .NET reflection + crypto surface)
level: high

IOC List

Behavioral Fingerprint

This binary is a .NET Framework PE32 that, on execution, allocates a TripleDESCryptoServiceProvider object, decodes a Base64 key/IV pair, opens an embedded .resources stream through a CryptoStream decryptor, and loads the resulting byte array via System.Reflection.Assembly.Load. It then resolves a type from the loaded assembly and invokes its entry point through Delegate.CreateDelegate followed by DynamicInvoke. No native API calls (P/Invoke) are present in the outer layer. The process shows minimal network activity until the inner payload decrypts and executes.

Detection Signatures

capa → MITRE ATT&CK Mapping

References

• Wiki entity page: unclassified-dotnet-tripledes-resource-loader
• Sibling analysis 1: /intel/analyses/5e1922a744bc4df2ef384022a4554908baab68c8ee6c14305130c1d4fef79a3f.html
• Sibling analysis 2: /intel/analyses/1051b5a48a4db66f11b8a28762bc7fae03de6b0a425dbfea26f89b0d99506959.html
• Technique page: confuserex-obfuscation
• Concept page: dotnet-manifest-resource-decryption

Provenance

• file.txt — file(1) output confirming PE32 .NET assembly
• exiftool.json — VS_VERSIONINFO metadata and PE timestamp
• pefile.txt — dnfile structural dump, TypeDef/MethodDef/MemberRef tables
• strings.txt — extracted strings including ConfuserEx indicators and crypto API names
• floss.txt — FLOSS invocation (errored, no decoded strings recovered)
• capa.txt — Mandiant capa static capability detection
• binwalk.txt — embedded artefact scan
• ssdeep.txt — fuzzy hash for similarity matching
• rabin2-info.txt — radare2 binary header summary
• triage.json — triage pipeline metadata
• dnfile Python library v0.15.1 — .NET metadata inspection
• radare2 v5.9.8 — binary header analysis (function listing only; CIL decompilation avoided due to known garbling)