unclassified-dotnet-tripledes-resource-loader: 1051b5a4 — TripleDES + Base64 resource decryptor, "sc copy" masquerade

Executive Summary

A second confirmed sibling of the unclassified-dotnet-tripledes-resource-loader .NET Framework crypter/loader family. Decrypts an embedded .resources payload via TripleDESCryptoServiceProvider + Base64, then reflectively loads the inner assembly. Masquerades as "sc copy" (service-controller copy) with a 2012 copyright stamp. Same build artefacts as sibling 5e1922a7 (linker 8.0, 2024 timestamp, no commercial obfuscator, no P/Invoke), but with completely different randomized CIL identifiers and an additional capa discovery hit (get session user name → T1033).

What It Is

VS_VERSIONINFO brands the binary as sc copy / sc copy.exe, Copyright © 2012. ^[exiftool.json] The name mimics the legitimate Windows sc.exe (Service Controller) utility, adding a social-engineering veneer of system administration legitimacy.

How It Works

Same staging chain as sibling 5e1922a7 — see unclassified-dotnet-tripledes-resource-loader for the family-wide pattern. Per-sample deltas follow:

Randomized CIL Identifiers (family anti-clustering)

^[r2:symbol list] ^[/intel/analyses/5e1922a744bc4df2ef384022a4554908baab68c8ee6c14305130c1d4fef79a3f.html]

Payload Staging Chain

1. Resource Retrieval — Axdne.Properties.Qduewrj.get_Sfzmuyv() wraps ResourceManager.GetObject() to pull the encrypted .resources blob. ^[r2:method.Axdne.Properties.Qduewrj.get_Sfzmuyv]
2. Base64 Decode — Convert.FromBase64String() on the resource string. ^[strings.txt:2830]
3. TripleDES Decrypt — TripleDESCryptoServiceProvider.CreateDecryptor() invoked against the decoded bytes inside a CryptoStream. ^[strings.txt:2853] ^[strings.txt:2857]
4. Reflective Load — Decrypted bytes passed to Assembly.Load(byte[]) (inferred from InvokeMember reference and capa hits). ^[strings.txt:2830] ^[capa.txt]

The hardcoded key/IV pair is not recoverable statically from strings or metadata in this sample — the #US heap is compressed and the Base64 material does not surface in plain strings output. Dynamic detonation or dnSpy/ILSpy analysis would be required to extract the actual crypto material. This is a step forward in opsec from sibling 5e1922a7, whose key/IV were plaintext in the #US heap.

CIL Metadata Structure

• 10 methods, 4 type definitions, 2 assembly references (mscorlib only). ^[r2:function list]
• No ConfuserEx (#=q…== absent), no SmartAssembly, no Xenocode, no P/Invoke surface. ^[strings.txt]

Decompiled Behavior

radare2 CIL analysis (Ghidra not run; pyghidra MCP unavailable):

• entry0 at 0x004020b4 is the standard _CorExeMain stub. ^[r2:entry0]
• method.Axdne.Cptnzhewmk.Fdiwrh initializes the runtime context. ^[r2:method.Axdne.Cptnzhewmk.Fdiwrh]
• method.Axdne.Cptnzhewmk.Jdqvgogfqvj orchestrates the decrypt-and-invoke chain. ^[r2:method.Axdne.Cptnzhewmk.Jdqvgogfqvj]
• method.Axdne.Xnapyrru.Decrypt implements the TripleDES + Base64 pipeline. ^[r2:method.Axdne.Xnapyrru.Decrypt]

Control flow is linear: no environment checks, no obfuscated dispatch, no anti-debug. The outer layer is a thin crypter wrapper.

C2 Infrastructure

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

Interesting Tidbits

• Key/IV opsec improvement — Unlike sibling 5e1922a7, the hardcoded TripleDES key and IV are not visible in strings or #US heap dumps. This suggests the crypter builder may have been updated, or the strings are stored in a different encoding/compression. ^[strings.txt] ^[floss.txt]
• sc copy masquerade — The filename and VS_VERSIONINFO impersonate the Windows Service Controller (sc.exe), a common administrative tool. This is slightly more targeted than sibling 5e1922a7's generic "new request" masquerade. ^[exiftool.json]
• Linker anachronism persists — Linker version 8.0 (VS 2005) with a 2024 compile timestamp, identical to sibling 5e1922a7. Strong indicator of a reused crypter stub or ILASM rebuild pipeline. ^[pefile.txt]
• Capa discovery hit — get session user name / T1033 is present in this sample but was not reported in 5e1922a7. This may reflect a different inner payload, or capa detecting Environment.UserName / WindowsIdentity references in the CIL metadata that were absent in the first sibling. ^[capa.txt] ^[strings.txt:2804]
• floss failure — floss.txt contains only an argument-parsing error; no decoded strings recovered, as expected for a pure .NET binary where strings live in CIL metadata. ^[floss.txt]

How To Mess With It (Homelab Replication)

See the family-wide replication notes on the unclassified-dotnet-tripledes-resource-loader entity page. The build recipe is identical; substitute the randomized namespace/class names and embed your own payload as a .resources string encrypted with TripleDES-CBC + Base64.

Deployable Signatures

YARA Rule

rule dotnet_tripledes_resource_loader_family {
    meta:
        description = ".NET crypter/loader family using TripleDESCryptoServiceProvider + Base64 resource decryption"
        author = "PacketPursuit"
        date = "2026-07-17"
        sha256_1 = "5e1922a744bc4df2ef384022a4554908baab68c8ee6c14305130c1d4fef79a3f"
        sha256_2 = "1051b5a48a4db66f11b8a28762bc7fae03de6b0a425dbfea26f89b0d99506959"
    strings:
        $tripledes = "TripleDESCryptoServiceProvider" wide ascii
        $create_dec = "CreateDecryptor" wide ascii
        $fromb64 = "FromBase64String" wide ascii
        $crypto_stream = "CryptoStream" wide ascii
        $resource_reader = "System.Resources.ResourceReader" ascii
        $runtime_set = "System.Resources.RuntimeResourceSet" ascii
    condition:
        uint16(0) == 0x5a4d and
        ($tripledes and $create_dec and $fromb64) and
        ($crypto_stream or $resource_reader or $runtime_set) 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 a benign system utility ("sc copy", "new request", etc.), 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, and loads the resulting assembly reflectively via Assembly.Load(byte[]). No network APIs and no persistence mechanisms are present in the outer layer. The CIL namespace and class names are randomized 8–12 character gibberish strings that change per sample. Detection should focus on the TripleDES + Base64 + ResourceManager chain combined with the single-import IAT and oversized .text section.

IOC List

Detection Signatures (capa → ATT&CK)

References

• SHA-256: 1051b5a48a4db66f11b8a28762bc7fae03de6b0a425dbfea26f89b0d99506959
• Source: MalwareBazaar / OpenCTI ingestion
• Related family: unclassified-dotnet-tripledes-resource-loader — cluster entity page with first sibling (5e1922a7) and full build/replication notes

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 dnfile (Python)