Inside BlueLoader: BoxedApp, DNGuard and a two-stage .NET bot

Key findings

The analysis does not produce one monolithic “unpacked sample”; it establishes an evidence-backed architecture across separately examined components.

01 · Panel container. Product-specific BoxedApp symbols and resource layout support the native packaging assessment; wrapper code was kept separate from BlueLoader application logic.

02 · Protected panel. An existing isolated minidump enabled offline reconstruction of the loaded BlueLoader.dll, two DNGuard runtime modules and strictly attributed native JIT bodies.

03 · Bot loader. The separate 460 KB .NET loader decrypts an embedded stage with TripleDES-CBC, removes a four-byte length field, decompresses GZip and loads the result exclusively from memory.

04 · Technical linkage. Bot and panel implement the same ten protobuf message types with matching tags, field numbers and normalised types. This protocol parity is the strongest technical relationship in the corpus.

05 · Impact. The bot combines scheduled-task persistence, encrypted C2, PowerShell, download-and-execute, process hollowing, cleanup and self-removal routines.

Analysis scope and evidence model

The evidence set has two separate entry points. The bot branch starts with a 460 KB .NET loader and leads through TripleDES and GZip to the inner assembly. The panel branch starts with a 98,218,496-byte native PE64 container whose BoxedApp wrapper was identified statically; the panel assembly running inside it is additionally protected by DNGuard.

The report therefore documents three evidence layers: container identification, bounded DNGuard reconstruction from an existing isolated memory image, and static bot deobfuscation. Only the subsequent protocol comparison technically links bot and panel. Original samples and secrets remain outside the website.

Relationship to public PureCrypter research

In 2022, Zscaler ThreatLabz described PureCrypter as a multi-stage .NET loader using obfuscation, compression, encryption, protobuf-based configuration, persistence and process injection. That publication provides a useful structural comparison for the loader portion of our corpus.

The evidence examined here takes a different direction and substantially broadens the view: in addition to the bot loader, it includes a standalone native BoxedApp container, a DNGuard-protected management panel, recovered panel metadata, native JIT evidence and a field-level bot-to-panel protocol comparison. This does not equate the sample with PureCrypter or imply shared developers. The comparison concerns architecture; family assessment rests solely on the local evidence set.

Technical analysis I — BoxedApp panel container

The 98 MB panel container is not a directly decompilable .NET program: the outer AMD64 PE has no CLR directory. Its attribution to BoxedApp instead rests on several independent features—numerous BoxedAppSDK symbols, PackerStubEntryPoint, embedded vendor build paths and the unusually large resource 10/15/0.

01 · Separate wrapper from payload. Wrapper APIs and helper files were not automatically attributed to BlueLoader code. Four valid PE helpers were byte-identical to known wrapper components; the .NET helper contained no application code.

02 · Test carving hypotheses. MZ/PE, BSJB, archive, GZip, zlib and short periodic XOR/addition searches produced no defensible embedded assembly. Those bounded heuristic failures were recorded as negative results, not as proof of a specific encryption algorithm.

03 · Match tools to evidence. A public unboxing tool expected a .bxpck section absent from the sample and would overwrite its input. It was therefore not run against the original. The BoxedApp finding reliably identifies the packaging, but does not claim a universal static unpacking success.

16Zahlreiche `BoxedAppSDK_*`-Symbole, insbesondere `BoxedAppSDK_PackerStubEntryPoint`, und eingebettete BoxedApp-Buildpfade belegen einen BoxedApp-bezogenen Wrapper. Die eingebetteten Buildpfade sind Hersteller-/Buildinformationen, keine beobachteten Dateien auf diesem Rechner.
17
18PE-Sektionen: `.text`, `.rdata`, `.data`, `.pdata`, `.Lmc`, `.rsrc`.
19
20Die Ressource `10/15/0` umfasst 91.035.348 Bytes. Ihr Inhalt wurde nicht entpackt oder ausgeführt. Weitere Ressourcen enthalten Icon-, Versions- und Manifestdaten. Der geprüfte Standard-Signaturwert eines .NET-Single-File-Bundles wurde nicht gefunden.

Technical analysis II — DNGuard-protected panel

The DNGuard layer was not removed with a single “deobfuscate” switch. The basis was an existing full minidump from an isolated Windows VM with no active network adapters. Every subsequent step only read that image; no extracted PE file or entry point was re-executed.

01 · Bind loaded modules. BlueLoader.dll, DNRuntime.dll and DNGuard.Runtime.dll were separately inventoried through memory addresses, CLR module attribution and SHA-256. The loaded main module had erased CLI and metadata headers; intact secondary copies in the same dump enabled repair of the metadata streams.

02 · Attribute JIT bodies strictly. A native body was accepted only when declaring module, ClrMD signature, valid MethodDef token, positive JIT hot region and uniqueness all matched. This excluded token collisions with framework and DevExpress methods.

03 · Separate reconstruction from projection. The final inventory counts 3,400 protected MethodDefs, 998 locally bounded native bodies and 742 integrated analysis bodies. Of those 742, 346 are runtime-derived and 396 are explicitly semantic projections—not a claim that the original CIL or C# was fully recovered.

04 · Quantify gaps. 498 bounded native bodies remain outside the analysis DLL. Only two are locally and transitively complete, both without a useful additional product finding. The other 496 require further target attribution or call-graph closure. That explicit boundary prevents partial reconstructions from being presented as a complete DNGuard unpack.

22`BlueLoader.dll` war als DNGuard-geschütztes, gemapptes Image bei
23`0x32370000` geladen. Der gemappte CLI-Header war gelöscht; eine intakte
24Zweitkopie lag bei `0x32370208`. Der ebenfalls gelöschte Metadatenkopf ließ
25sich aus der intakten CLR-Kopie bei `0x14c78f3c` wiederherstellen. Danach
26lesen `dnfile` und ILSpy alle fünf Metadatenstreams.

Technical analysis III — Bot loader and inner assembly

The decryption was not guessed and the loader was not executed. The starting point was the static call chain in Qhtid.cs: the step labelled “Decrypt” passes three byte arrays to ProcRunner.ExecuteConfigurableProc; its result flows directly into the step labelled “Decompress” and then into Assembly.Load(byte[]).

01 · Identify the primitive. ProcRunner.cs instantiates TripleDESCryptoServiceProvider. The numeric .NET enum values Mode = 1 and Padding = 2 resolve to CBC and PKCS#7. It also requires 24 bytes for the key and 8 bytes for the IV before decryption.

02 · Follow the data flow. The embedded byte buffer is written to a CryptoStream backed by CreateDecryptor(); FlushFinalBlock() materialises the decrypted buffer. The conclusion rests not on one string but on the connected input, key, IV and output along the same call graph.

03 · Confirm the container format. OperationalTracker.cs reads the first four bytes as a little-endian Int32, starts a MemoryStream at offset 4 and feeds the remainder to GZipStream. It checks the resulting length against the prefix. This functionally establishes the prefix instead of merely inferring it from magic bytes.

04 · Verify the destination stage. The decompressed buffer is passed directly to Assembly.Load(byte[]) without a file write. That sink confirms the output is intended as a managed .NET assembly.

05 · Preserve reproducibility. Every evidence file is SHA-256-bound in the manifest; line ranges and hand-offs were cross-checked separately. The result is a static reconstruction. It supports the implemented unpacking chain, not successful execution on a victim system.

64				using (MemoryStream memoryStream = new MemoryStream(task, mean_visitor, task.Length - mean_visitor))
65				{
66					GZipStream gzipStream = new GZipStream(memoryStream, 0);
67					try
68					{
69						using (MemoryStream memoryStream2 = new MemoryStream((num2 <= 0) ? 0 : num2))
70						{
71							gzipStream.CopyTo(memoryStream2);
72							byte[] array = memoryStream2.ToArray();
73							if (array.Length != num2)
74							{
75								throw new InvalidDataException();
76							}
77							return array;

Component flow and evidence chain

The investigation uses three evidence classes: immutable source artifacts, reproducible analysis tooling and explicitly labelled semantic projections. The map shows more than file relationships: it marks where a conclusion moves from observed bytes to analytical derivation. Runtime evidence, static findings and reconstruction therefore remain distinguishable.

Deobfuscation at scale: strings, proxies and schema

The inner bot assembly contains 1,923 types and 9,748 methods; 6,189 methods retain a readable IL body. The cleanup pass replaced 990 verified string-resolver calls and rewrote 9,514 delegate proxies to direct targets. A complete expression scan showed that four initially suspicious sites invoke a random-name generator—an important negative finding because they must not be reported as missing plaintext.

Protocol reconstruction was then performed independently from behavioural control flow. The analysis tool extracts ProtoInclude relationships from decompiled sources, normalises signatures and rejects the result unless the complete expected tag set from 1 through 10 is present.

33def read_sources(root: Path) -> list[tuple[Path, str]]:
34    return [(p, p.read_text(encoding="utf-8-sig", errors="replace")) for p in root.rglob("*.cs")]
35
36
37def class_region(sources: list[tuple[Path, str]], class_name: str) -> tuple[Path, str]:
38    pattern = re.compile(r"\bclass\s+" + re.escape(class_name) + r"\b")
39    for path, text in sources:
40        match = pattern.search(text)
41        if not match:
42            continue
43        start = match.start()
44        next_namespace = text.find("\nnamespace ", match.end())
45        end = len(text) if next_namespace < 0 else next_namespace
46        return path, text[start:end]
47    raise KeyError(f"class not found: {class_name}")
48
49
50def include_map(sources: list[tuple[Path, str]], base_class: str) -> tuple[Path, dict[int, str]]:
51    path, region = class_region(sources, base_class)
52    # Attributes are before the class declaration, so collect a bounded prefix.
53    text = path.read_text(encoding="utf-8-sig", errors="replace")
54    class_pos = re.search(r"\bclass\s+" + re.escape(base_class) + r"\b", text).start()
55    prefix = text[max(0, class_pos - 2500) : class_pos]
56    pairs = re.findall(r"\[ProtoInclude\((\d+),\s*typeof\(([^)]+)\)\)\]", prefix)
57    mapping = {int(tag): name.strip() for tag, name in pairs}
58    if set(mapping) != set(range(1, 11)):
59        raise ValueError(f"{base_class}: expected tags 1..10, found {sorted(mapping)}")
60    return path, mapping

C2 cryptography: original path and analytical projection

The obfuscation removes semantic meaning from identifiers, but not the observable cryptography. AES key size, CBC mode, PKCS#7 padding, random IV generation and HMAC computation remain directly visible in the decompiled transport path. The comparison reduces that path to verifiable protocol properties and explicitly labels reconstructed names as analyst terminology. The shared secret is neither displayed nor published in derivable form.

						using (AesCryptoServiceProvider aesCryptoServiceProvider = new AesCryptoServiceProvider())
						{
							aesCryptoServiceProvider.KeySize = 256;
							aesCryptoServiceProvider.BlockSize = 128;
							aesCryptoServiceProvider.Mode = CipherMode.CBC;
							aesCryptoServiceProvider.Padding = PaddingMode.PKCS7;
							aesCryptoServiceProvider.Key = this.U260suBvbl;
							aesCryptoServiceProvider.GenerateIV();
							for (;;)
							{
								using (CryptoStream cryptoStream = new CryptoStream(memoryStream, aesCryptoServiceProvider.CreateEncryptor(), CryptoStreamMode.Write))
								{
									memoryStream.Write(aesCryptoServiceProvider.IV, 0, aesCryptoServiceProvider.IV.Length);
									cryptoStream.Write(\u0020, 0, \u0020.Length);
									cryptoStream.FlushFinalBlock();
									using (HMACSHA256 hmacsha = new HMACSHA256(this.BDg0C5xXGU))
									{
										byte[] array = hmacsha.ComputeHash(memoryStream.ToArray(), 32, memoryStream.ToArray().Length - 32);
										memoryStream.Position = 0L;
										memoryStream.Write(array, 0, array.Length);

public static class TransportProfile
{
    public const string Framing = "4-byte little-endian encrypted-payload length";
    public const string Serialization = "protobuf-net base message with ProtoInclude tags 1..10";
    public const string Encryption = "AES-256-CBC with PKCS#7 padding and a random 16-byte IV";
    public const string Authentication = "HMAC-SHA256 over IV || ciphertext";
    public const string WireLayout = "32-byte HMAC || 16-byte IV || ciphertext";
    public const string KeyDerivation = "PBKDF2/Rfc2898DeriveBytes, 5,000 iterations";

Command-and-control protocol

Each message is serialised as a protobuf object and then encrypted with AES-256-CBC and PKCS#7 padding. A random 16-byte IV precedes the ciphertext; HMAC-SHA256 authenticates the IV and ciphertext together. The resulting packet starts with the 32-byte HMAC, followed by the IV and ciphertext. A four-byte little-endian length field frames transmission on the TCP stream.

This construction provides confidentiality and integrity inside the proprietary protocol. It does not conceal the destination or connection metadata and does not prevent host-based detection. The structure shown is a defensive protocol model, not an operational client.

8public static class TransportProfile
9{
10    public const string Framing = "4-byte little-endian encrypted-payload length";
11    public const string Serialization = "protobuf-net base message with ProtoInclude tags 1..10";
12    public const string Encryption = "AES-256-CBC with PKCS#7 padding and a random 16-byte IV";
13    public const string Authentication = "HMAC-SHA256 over IV || ciphertext";
14    public const string WireLayout = "32-byte HMAC || 16-byte IV || ciphertext";
15    public const string KeyDerivation = "PBKDF2/Rfc2898DeriveBytes, 5,000 iterations";

Execution chain: persistence, tasking and process hollowing

After registration, the second stage can install under Local Application Data and persist through a scheduled task. Its tasking model covers file transfer, execution from disk or memory, PowerShell, status acknowledgement, cleanup and complete uninstall.

The in-memory path implements separate 32-bit and 64-bit process-hollowing helpers: create a suspended target, prepare image regions, allocate and write remote memory, update thread context and resume the primary thread. On Windows builds from 26100 onward, an additional compatibility or bypass branch modifies functions inside the target process's ntdll.

For defenders, this sequence is more reliable than any single indicator: a new scheduled task, RegisteredHandlers/Current, PowerShell, remote-memory writes, context modification and ResumeThread on the same host.

12    public static IReadOnlyList<BehaviorFinding> Findings { get; } = new[]
13    {
14        new BehaviorFinding("BL-001", "Two-stage loader", "Outer decrypts and decompresses a managed inner assembly.", "Exact/static", "T1027,T1140"),
15        new BehaviorFinding("BL-002", "Custom TCP C2", "protobuf messages are protected with AES-CBC and HMAC-SHA256 and framed with a little-endian length.", "Static", "T1095"),
16        new BehaviorFinding("BL-003", "Scheduled task persistence", "The install path creates and removes a configured scheduled task.", "Static", "T1053.005"),
17        new BehaviorFinding("BL-004", "Download and execute", "Tag 4 selects disk, PowerShell or in-memory handling.", "Static", "T1105,T1059.001"),
18        new BehaviorFinding("BL-005", "Process hollowing", "Separate 32-bit and 64-bit helpers replace a suspended process image.", "Static", "T1055.012"),
19        new BehaviorFinding("BL-006", "Aggressive cleanup", "The cleanup path can terminate processes and delete startup material.", "Static", "T1070.004"),
20        new BehaviorFinding("BL-007", "Host inventory", "Registration includes HWID, OS, user, AV, privilege, bitness, process and GPU data.", "Static", "T1082,T1518.001"),
21        new BehaviorFinding("BL-008", "Windows 26100 compatibility patch", "The hollowing path patches functions inside target-process ntdll on newer builds.", "Static", "T1055.012")
22    };

Indicators of compromise and confidence

The filters separate file hashes, configured server values and local artifacts. A configured target is not evidence of successful contact or current control.

YARA: exact sample detection

The baseline rule relies exclusively on the three SHA-256 values confirmed in the evidence set. It is highly precise but will not detect rebuilt or modified variants. The size gate limits unnecessary hashing; the rule contains neither sample bytes nor reconstruction logic.

1import "hash"
2
3rule TW_BlueLoader_Exact_Samples_2026_10
4{
5    meta:
6        description = "Exact BlueLoader artifacts from static review"
7        author = "TW Research"
8        date = "2026-10-17"
9        confidence = "high / exact hash only"
10
11    condition:
12        filesize < 5MB and (
13            hash.sha256(0, filesize) == "672320eb064f6d971e98c7cbfc5bfdd48541a992ccedac9b5550030953587c39" or
14            hash.sha256(0, filesize) == "c706546279ba2781d349bdf8512651e0ec1e82e3172a1a700dd991d1d562b77f" or
15            hash.sha256(0, filesize) == "46e5ca3417006841884c4cca9d76a6fd03772ec54f4692079df9af8319a1505c"
16        )
17}

Sigma: local installation trace

The Sigma rule models a narrow filesystem trace: the combination of the reconstructed RegisteredHandlers directory component and the Current name component. It requires file-event telemetry and is intended for hunting. Environments should add known legitimate matches as filters first.

1title: BlueLoader-Like LocalAppData Installation Trace
2id: 4262753e-797b-46d0-96df-a84521dbf3f2
3status: experimental
4description: Detects the reviewed directory and filename components together
5author: TW Research
6date: 2026-10-17
7logsource:
8  category: file_event
9  product: windows
10detection:
11  selection_path:
12    TargetFilename|contains: '\\RegisteredHandlers\\'
13  selection_name:
14    TargetFilename|endswith:
15      - '\\Current'
16      - '\\Current.exe'
17  condition: selection_path and selection_name
18falsepositives:
19  - Legitimate software using the same generic components
20level: medium
21tags:
22  - attack.persistence
23  - attack.t1053.005

Suricata: configured infrastructure

This network rule is deliberately narrow and time-bound. It alerts only on outbound TCP connections to the address configured in the sample over either reviewed port. Before deployment, check reputation, current address ownership and local allowlists. A hit supports a connection attempt, not successful C2 communication.

1alert tcp $HOME_NET any -> 82.102.27.163 [45050,45080] (
2    msg:"TW BlueLoader configured destination / review 2026-10-17";
3    flow:to_server;
4    classtype:trojan-activity;
5    sid:99001701; rev:1;
6    metadata:created_at 2026_10_17, confidence High, deployment Perimeter;
7)

KQL: correlate network and host

The hunting query combines the stronger approach: connections to the configured target must coincide within 15 minutes with the local path trace on the same device. It is written for Microsoft Defender XDR and must be adapted to the tables and retention actually available.

1let NetworkSignal = DeviceNetworkEvents
2| where RemoteIP == "82.102.27.163"
3| where RemotePort in (45050, 45080)
4| project DeviceId, DeviceName, NetTime=Timestamp, RemoteIP, RemotePort;
5let HostSignal = DeviceFileEvents
6| where FolderPath contains @"\RegisteredHandlers\"
7| where FileName in~ ("Current", "Current.exe")
8| project DeviceId, HostTime=Timestamp, FolderPath, FileName;
9NetworkSignal
10| join kind=inner HostSignal on DeviceId
11| where abs(datetime_diff('minute', NetTime, HostTime)) <= 15
12| project NetTime, HostTime, DeviceName, RemoteIP, RemotePort, FolderPath, FileName
13| order by NetTime desc

Panel-to-bot correlation

The independent panel corpus contains structural counterparts for all ten protobuf message types implemented by the bot. Comparison did not rely on class names; it used ProtoInclude tags, field numbers, normalised field types and their call sites. The matched set covers configuration, registration, task delivery, acknowledgement, heartbeat, cleanup and uninstall.

This 10-of-10 parity is stronger than a shared string or similar user interface: it shows that both components implement the same message contract. The panel also adds licensing and update paths plus a local scanner for reverse-engineering tools. This supports a local anti-analysis path, but not an automatic server-side ban, operator identity or byte-identical build provenance.

Attribution assessment

We assess the bot as BlueLoader-compatible with high technical confidence. The basis is ten matching message contracts, corresponding control flows and the functional complement between client and panel. This assessment classifies software components—not people.

The evidence does not support conclusions about developers, customers, operators or infrastructure owners. The configuration value 12.09.2025 is likewise treated only as an embedded label; without an independent time source it is neither a build date nor a campaign start.

Conclusion

The reviewed evidence exposes a broader BlueLoader ecosystem than a loader-only analysis: a natively packaged management panel, a DNGuard-protected .NET application and a separate two-stage remote-control bot. BoxedApp obstructs direct access to the panel, DNGuard moves material logic into runtime-dependent native bodies, and the bot protects its proprietary protobuf protocol with AES-CBC and HMAC.

These layers still leave defensible detection opportunities. The strongest signal comes from correlated host and network behaviour: installation under Local Application Data, a scheduled task, recurring TCP connections to a configured destination, PowerShell and the characteristic process-hollowing sequence. The accompanying YARA, Sigma, Suricata and KQL examples operationalise those distinct evidence layers.

Review limits

• The analysis reconstructs behaviour from code; it does not prove successful execution on a victim device.
• Configured infrastructure proves neither current reachability nor ownership.
• Reconstructed names are analytical labels, not recovered original source code.