unclassified-dotnet-crypter-loader: 07835853 — .NET Framework 4.0 reflective loader with AES-GZip-Base64 manifest-resource decryption and native API P/Invoke

Executive Summary

A 579 KB .NET Framework 4.0 PE32 binary (fortnite hack vip.exe) that acts as a reflective crypter/loader. It decrypts a multi-layered payload (AES → GZip → Base64) from an embedded manifest resource, then uses System.Reflection.Emit and P/Invoke to load and execute native code in memory. Heavy obfuscation (likely ConfuserEx) strips all meaningful identifiers. No CAPE detonation available; all behavior inferred from static. This is a commodity .NET crypter pattern frequently seen in malware-as-a-service loaders.

What It Is

The binary is a C# assembly (not VB.NET), evidenced by Microsoft.CodeAnalysis.EmbeddedAttribute and RefSafetyRulesAttribute in the metadata ^[strings.txt:45-48]. The namespace Newmcentu.Properties suggests the original project name was altered to random syllables.

How It Works

Obfuscation

Every type, method, field, and property has been renamed to 20-character random alphanumeric strings (e.g., oyNaDVBdne6EfJWPON, ofMjJJ0YjS4IWVujYc, y8dmROepc0Qhsflcxj) ^[strings.txt:49-165]. This matches the ConfuserEx name-mangling fingerprint ^[capa.txt]. Combined with System.Reflection.Emit usage and the absence of debug symbols, this is consistent with ConfuserEx or a derivative commercial obfuscator.

Payload Retrieval

The binary calls Assembly.GetManifestResourceStream and GetManifestResourceNames ^[strings.txt:350,530] to locate an embedded resource. The resource is decrypted through a multi-stage pipeline:

1. Base64 decode — Convert.FromBase64String ^[strings.txt:406]
2. AES decryption — AesCryptoServiceProvider or RijndaelManaged with CreateDecryptor, set_Key, set_IV ^[strings.txt:320-324, 446-448]
3. GZip / Deflate decompression — GZipStream or DeflateStream in CompressionMode.Decompress ^[strings.txt:197-199, 528]

This exact pipeline is documented at dotnet-manifest-resource-decryption.

Native Code Execution

After decryption, the payload is not a managed assembly. The binary prepares native execution via:

• kernel32!LoadLibrary and kernel32!GetProcAddress resolved through P/Invoke ^[strings.txt:422-425]
• Marshal.GetDelegateForFunctionPointer to cast native function pointers to managed delegates ^[strings.txt:428]
• DynamicMethod + ILGenerator to emit runtime call thunks ^[strings.txt:346-348, 375]
• nativeEntry and nativeSizeOfCode fields ^[strings.txt:493-494] strongly imply a fixed entry point and size for shellcode or an unmanaged DLL loaded into the current process.

The presence of BeginInvoke/EndInvoke with IAsyncResult and AsyncCallback ^[strings.txt:244-250] suggests the loader may spawn the payload asynchronously.

Anti-Analysis

• Minimal IAT: Only _CorExeMain is imported; everything else resolved at runtime via reflection or P/Invoke ^[pefile.txt:255]
• Process detection: capa flags "reference analysis tools strings" and "process detection" ^[capa.txt]
• Future timestamp: 2098 compilation date is a common anti-forensic triviality ^[exiftool.json:15]
• High-entropy .text: 7.86 entropy in the .text section ^[pefile.txt:92] — consistent with encrypted IL or embedded payload

Decompiled Behavior

Ghidra decompilation was unavailable on this analysis host (no pyghidra MCP server running). Radare2 CIL support produced only raw IL bytecode for entry0 (0x00402190) with switch-based dispatch, which is unreadable against ConfuserEx-flattened control flow. The behavioral narrative above is therefore reconstructed from:

• strings.txt namespace and API references
• capa.txt capability mapping
• pefile.txt structural metadata
• Known .NET crypter/loader patterns

C2 Infrastructure

No hardcoded C2 strings recovered statically. The loader's network capability, if any, lives inside the encrypted manifest resource and would only be observable at runtime. Static indicators are limited to:

• Payload delivery mechanism: embedded resource (self-contained)
• No HTTP/HTTPS/TCP/DNS strings in outer binary
• No cryptocurrency wallet addresses or Telegram bot tokens

Interesting Tidbits

• The binary carries two internal names (Newmcentu.exe and Aflxpd.exe), suggesting the obfuscator may have merged or renamed modules post-build ^[exiftool.json:40,43]
• capa maps 14 distinct capabilities including AES, MD5, GZip, Base64, runtime linking, and reflection-based method generation ^[capa.txt]
• System.Core is referenced for AesCryptoServiceProvider, confirming .NET Framework 4.0+ target ^[strings.txt:322]
• A large block of GUID-like field names (m_30d70bc518e247ef8f42305b16bd6c40 etc.) ^[strings.txt:581-693] are likely auto-generated backing fields for obfuscated properties — another ConfuserEx hallmark

How To Mess With It (Homelab Replication)

Goal: Build a minimal .NET crypter that replicates the AES→GZip→Base64 manifest-resource loading pattern.

Toolchain: Visual Studio 2022 Community, .NET Framework 4.0 Console App

Compiler flags: None special; the obfuscation layer is applied post-build.

Working source snippet (C#):

using System;
using System.IO;
using System.IO.Compression;
using System.Security.Cryptography;
using System.Reflection;

class Program {
    static void Main() {
        var asm = Assembly.GetExecutingAssembly();
        using (var stream = asm.GetManifestResourceStream("payload.bin"))
        using (var ms = new MemoryStream()) {
            stream.CopyTo(ms);
            byte[] b64 = ms.ToArray();
            byte[] aes = Convert.FromBase64String(System.Text.Encoding.UTF8.GetString(b64));
            // AES decrypt here ...
            using (var gz = new GZipStream(new MemoryStream(aes), CompressionMode.Decompress))
            using (var outMs = new MemoryStream()) {
                gz.CopyTo(outMs);
                byte[] shellcode = outMs.ToArray();
                // Load via VirtualAlloc + delegate
            }
        }
    }
}

Verification: Run capa reproducer.exe — expect hits on encrypt data using AES via .NET, compress data using GZip in .NET, decode data using Base64 in .NET, access .NET resource.

What you'll learn: How commodity .NET crypters stage payloads, and why static string extraction fails against even trivial obfuscation.

Deployable Signatures

YARA Rule

rule unclassified_dotnet_crypter_loader_07835853 {
    meta:
        description = ".NET reflective loader with AES+GZip+Base64 manifest resource decryption"
        author = "Titus"
        sha256 = "0783585328aa96695c4412282b96cb03dffe79a1c5e68625bbad983ad9ef24f9"
        date = "2026-06-10"
    strings:
        $a1 = "GetManifestResourceStream" ascii wide
        $a2 = "CreateDecryptor" ascii wide
        $a3 = "GZipStream" ascii wide
        $a4 = "FromBase64String" ascii wide
        $a5 = "LoadLibrary" ascii wide
        $a6 = "GetProcAddress" ascii wide
        $a7 = "GetDelegateForFunctionPointer" ascii wide
        $a8 = "DynamicMethod" ascii wide
        $a9 = "nativeEntry" ascii wide
        $a10 = "nativeSizeOfCode" ascii wide
        $dotnet = "mscoree.dll" ascii wide
        $cor = "_CorExeMain" ascii wide
    condition:
        uint16(0) == 0x5A4D and
        $dotnet and $cor and
        6 of ($a*)
}

Sigma Rule

title: .NET Reflective Loader with Native API P/Invoke
id: titus-dotnet-reflective-loader-1
status: experimental
description: Detects .NET processes loading native APIs via P/Invoke after manifest resource access
logsource:
    category: process_creation
    product: windows
detection:
    selection_dotnet:
        Image|endswith:
            - '\\mscorlib.dll'
        ParentImage|endswith:
            - '.exe'
    selection_api:
        CommandLine|contains:
            - 'LoadLibrary'
            - 'GetProcAddress'
            - 'GetDelegateForFunctionPointer'
    condition: selection_dotnet and selection_api
falsepositives:
    - Legitimate .NET applications using P/Invoke
level: medium

IOC List

Behavioral Fingerprint Statement

This binary is a .NET Framework 4.0 GUI executable with a single native import (mscoree.dll!_CorExeMain). At startup it accesses an embedded manifest resource, decrypts the blob via AES, decompresses with GZip, Base64-decodes the result, and uses System.Reflection.Emit together with Marshal.GetDelegateForFunctionPointer to bridge into native code loaded via kernel32!LoadLibrary. The absence of meaningful type names and the presence of 20-character random alphanumeric identifiers across all namespaces indicate ConfuserEx-grade obfuscation. No network strings are present in the outer binary; any C2 capability is encapsulated in the encrypted payload.

Detection Signatures (capa → ATT&CK)

References

• Artifact ID: 94efb18d-7a51-4d5f-9f66-87a9cf465595 (OpenCTI)
• Source: MalwareBazaar / abuse.ch
• Related wiki pages: confuserex-obfuscation, dotnet-manifest-resource-decryption

Provenance

Analysis derived from static artifacts in raw/analyses/0783585328aa96695c4412282b96cb03dffe79a1c5e68625bbad983ad9ef24f9/:

• file.txt — file(1) output
• exiftool.json — EXIF/PE metadata
• pefile.txt — pefile structural dump
• strings.txt — ASCII/Unicode string extraction
• capa.txt — Mandiant capa v7 static analysis
• rabin2-info.txt — radare2 binary header summary
• binwalk.txt — embedded artifact scan
• triage.json — pipeline metadata
• metadata.json — OpenCTI labels

Ghidra decompilation unavailable; radare2 CIL support insufficient for ConfuserEx-flattened IL. All behavioral claims are static-inference with confidence noted.