Inside BlueLoader: BoxedApp, DNGuard und ein zweistufiger .NET-Bot

Key Findings

Die Analyse ergibt kein einzelnes „entpacktes Sample“, sondern eine belastbare Architektur aus getrennt untersuchten Komponenten.

01 · Panelcontainer. Produktspezifische BoxedApp-Symbole und die Ressourcenstruktur belegen die native Verpackung; Wrappercode und BlueLoader-Anwendungslogik wurden konsequent getrennt.

02 · Geschütztes Panel. Ein vorhandener isolierter Minidump ermöglichte die Offline-Rekonstruktion der geladenen BlueLoader.dll, zweier DNGuard-Laufzeitmodule und streng zugeordneter nativer JIT-Körper.

03 · Bot-Loader. Der separate 460-KB-.NET-Loader entschlüsselt eine eingebettete Stufe mit TripleDES-CBC, entfernt ein vier Byte breites Längenfeld, dekomprimiert GZip und lädt das Ergebnis ausschließlich aus dem Speicher.

04 · Technische Verbindung. Bot und Panel implementieren dieselben zehn protobuf-Nachrichtentypen mit übereinstimmenden Tags, Feldnummern und normalisierten Typen. Diese Protokollparität ist der stärkste technische Zusammenhang im Korpus.

05 · Wirkung. Der Bot kombiniert Scheduled-Task-Persistenz, verschlüsselte C2-Kommunikation, PowerShell, Download-and-Execute, Process Hollowing sowie Bereinigungs- und Selbstentfernungsroutinen.

Analysis Scope und Evidence Model

Der Prüfbestand hat zwei getrennte Einstiege. Der Bot-Zweig beginnt mit einem 460 Kilobyte großen .NET-Loader und führt über TripleDES und GZip zur inneren Assembly. Der Panel-Zweig beginnt mit einem 98.218.496 Byte großen nativen PE64-Container, dessen BoxedApp-Wrapper statisch identifiziert wurde; die darin laufende Panelassembly ist zusätzlich mit DNGuard geschützt.

Der Bericht dokumentiert deshalb drei Beweisschichten: Containeridentifikation, begrenzte DNGuard-Rekonstruktion aus einem vorhandenen isolierten Speicherabbild und statische Bot-Deobfuskation. Erst der danach durchgeführte Protokollvergleich verbindet Bot und Panel technisch. Originalsamples und Geheimnisse bleiben außerhalb der Website.

Einordnung gegenüber der PureCrypter-Forschung

Zscaler ThreatLabz beschrieb 2022 PureCrypter als mehrstufigen .NET-Loader mit Obfuskation, Kompression, Verschlüsselung, protobuf-basierter Konfiguration, Persistenz und Prozessinjektion. Diese Veröffentlichung liefert einen sinnvollen strukturellen Vergleich für den Loader-Teil unseres Korpus.

Der hier untersuchte Bestand geht jedoch in eine andere Richtung und erweitert den Blick erheblich: Zusätzlich zum Bot-Loader liegen ein eigenständiger nativer BoxedApp-Container, ein DNGuard-geschütztes Management-Panel, wiedergewonnene Panel-Metadaten, native JIT-Evidenz und ein feldgenauer Bot-/Panel-Protokollvergleich vor. Daraus folgt keine Gleichsetzung mit PureCrypter und keine Aussage über gemeinsame Entwickler. Der Vergleich betrifft Architekturmerkmale; die Familienzuordnung beruht ausschließlich auf dem eigenen Belegbestand.

Technical Analysis I — BoxedApp-Panelcontainer

Der 98-MB-Panelcontainer ist kein direkt dekompilierbares .NET-Programm: Das äußere AMD64-PE besitzt kein CLR-Verzeichnis. Die Zuordnung zu BoxedApp stützt sich stattdessen auf mehrere voneinander unabhängige Merkmale – zahlreiche BoxedAppSDK-Symbole, den PackerStubEntryPoint, eingebettete Hersteller-Buildpfade und die ungewöhnlich große Ressource 10/15/0.

01 · Wrapper von Nutzlast trennen. Wrapper-APIs und Hilfsdateien wurden nicht automatisch dem BlueLoader-Code zugerechnet. Vier gültige PE-Hilfsdateien erwiesen sich als bytegleich mit bekannten Wrapperkomponenten; die .NET-Hilfsdatei enthielt keinen Anwendungscode.

02 · Carving-Hypothesen testen. MZ/PE-, BSJB-, Archiv-, GZip-, zlib- und kurze periodische XOR-/Additionssuchen lieferten keine belastbare eingebettete Assembly. Das Fehlschlagen dieser begrenzten Heuristiken wurde als Negativbefund dokumentiert, nicht als Beweis für einen bestimmten Verschlüsselungsalgorithmus.

03 · Werkzeug passend auswählen. Ein öffentliches Unboxing-Werkzeug erwartete eine .bxpck-Sektion, die im Sample fehlt, und hätte die Eingabe überschrieben. Es wurde deshalb nicht auf das Original angewandt. Der BoxedApp-Befund identifiziert somit zuverlässig die Verpackung, behauptet aber keinen universellen statischen Unpackerfolg.

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-geschütztes Panel

Die DNGuard-Schicht wurde nicht durch einen einzigen „Deobfuscate“-Schalter entfernt. Grundlage war ein bereits vorhandener vollständiger Minidump aus einer isolierten Windows-VM ohne aktive Netzwerkadapter. Alle folgenden Schritte lasen ausschließlich dieses Abbild; keine extrahierte PE-Datei und kein Einstiegspunkt wurde erneut ausgeführt.

01 · Geladene Module binden. BlueLoader.dll, DNRuntime.dll und DNGuard.Runtime.dll wurden über Speicheradressen, CLR-Modulzuordnung und SHA-256 getrennt inventarisiert. Beim geladenen Hauptmodul waren CLI- und Metadatenköpfe gelöscht; intakte Zweitkopien im selben Dump ermöglichten die Reparatur der Metadatenstreams.

02 · JIT-Körper streng zuordnen. Ein nativer Körper wurde nur übernommen, wenn Declaring Module, ClrMD-Signatur, gültiger MethodDef-Token, positiver JIT-Hot-Bereich und Eindeutigkeit zusammenpassten. So wurden Token-Kollisionen mit Framework- und DevExpress-Methoden ausgeschlossen.

03 · Rekonstruktion von Projektion trennen. Die Endinventur zählt 3.400 geschützte MethodDefs, 998 lokal abgegrenzte native Körper und 742 integrierte Analysekörper. Von diesen 742 sind 346 laufzeitabgeleitet und 396 ausdrücklich semantische Projektionen – keine Behauptung, das ursprüngliche CIL oder C# vollständig zurückgewonnen zu haben.

04 · Lücken quantifizieren. 498 abgegrenzte native Körper liegen außerhalb der Analyse-DLL. Nur zwei sind lokal und transitiv vollständig, beide ohne nutzbaren zusätzlichen Produktbefund. Die übrigen 496 benötigen weitere Zielattribution oder Callgraph-Abdeckung. Genau diese Grenze verhindert, Teilrekonstruktionen als vollständigen DNGuard-Unpack auszugeben.

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 und innere Assembly

Die Entschlüsselung wurde nicht erraten und der Loader nicht ausgeführt. Ausgangspunkt war die statische Aufrufkette in Qhtid.cs: Der mit „Decrypt“ markierte Schritt übergibt drei Bytefelder an ProcRunner.ExecuteConfigurableProc; dessen Ergebnis fließt unmittelbar in den mit „Decompress“ markierten Schritt und anschließend in Assembly.Load(byte[]).

01 · Primitive bestimmen. ProcRunner.cs instanziiert TripleDESCryptoServiceProvider. Die numerischen .NET-Enumwerte Mode = 1 und Padding = 2 entsprechen CBC und PKCS#7. Vor der Entschlüsselung werden außerdem 24 Byte für den Schlüssel und 8 Byte für den IV verlangt.

02 · Datenfluss verfolgen. Der eingebettete Bytepuffer wird in einen CryptoStream mit CreateDecryptor() geschrieben; erst FlushFinalBlock() materialisiert den entschlüsselten Puffer. Entscheidend war nicht ein einzelner String, sondern dass Eingabe, Schlüssel, IV und Ergebnis über denselben Callgraph verbunden sind.

03 · Containerformat bestätigen. OperationalTracker.cs liest die ersten vier Byte als Little-Endian-Int32, beginnt den MemoryStream bei Offset 4 und führt den Rest einem GZipStream zu. Die erwartete Ausgabelänge wird gegen das Präfix geprüft. Damit ist das vermeintliche Präfix funktional belegt, nicht nur anhand einer Magic-Byte-Suche vermutet.

04 · Zielstufe verifizieren. Der dekomprimierte Puffer wird ohne Dateischreibvorgang an Assembly.Load(byte[]) übergeben. Diese Senke bestätigt, dass die Ausgabe als verwaltete .NET-Assembly gedacht ist.

05 · Reproduzierbarkeit sichern. Jede Belegdatei ist im Manifest mit SHA-256 gebunden; Zeilenbereiche und Übergaben wurden getrennt gegengeprüft. Das Ergebnis ist eine statische Rekonstruktion. Es belegt die implementierte Entpackkette, aber keine erfolgreiche Ausführung auf einem Opfergerät.

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 und Beweiskette

Die Analyse arbeitet mit drei Evidenzklassen: unveränderten Quellartefakten, reproduzierbaren Analysewerkzeugen und explizit gekennzeichneten semantischen Projektionen. Die Karte bildet nicht nur Dateibeziehungen ab, sondern zeigt, an welcher Stelle eine Aussage von beobachteten Bytes zu einer analytischen Ableitung wechselt. Laufzeitbeleg, statischer Befund und Rekonstruktion bleiben dadurch voneinander unterscheidbar.

Deobfuscation at Scale: Strings, Proxys und Schema

Die innere Bot-Assembly umfasst 1.923 Typen und 9.748 Methoden; 6.189 Methoden besitzen einen lesbaren IL-Körper. Der Bereinigungslauf ersetzte 990 verifizierte Stringresolver-Aufrufe und führte 9.514 Delegate-Proxys auf direkte Ziele zurück. Vier zunächst verdächtige Ausdrücke erwiesen sich nach vollständigem Expression-Scan als Aufrufe eines Zufallsnamengenerators – ein wichtiger Negativbefund, weil dort keine fehlenden Klartexte behauptet werden dürfen.

Die Protokollrekonstruktion wurde anschließend unabhängig vom Kontrollfluss durchgeführt. Das Analysewerkzeug extrahiert ProtoInclude-Beziehungen aus den dekompilierten Quellen, normalisiert die Signaturen und verwirft das Ergebnis, wenn die erwartete Tag-Menge 1 bis 10 nicht vollständig vorliegt.

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-Kryptografie: Originalpfad und analytische Projektion

Die Obfuskation zerstört Semantik in Bezeichnern, nicht jedoch die beobachtbare Kryptografie. Im dekompilierten Transportpfad bleiben AES-Schlüsselgröße, CBC-Modus, PKCS#7-Padding, zufälliger IV und HMAC-Berechnung direkt sichtbar. Die Gegenüberstellung reduziert diesen Pfad auf prüfbare Protokolleigenschaften und kennzeichnet rekonstruierte Namen ausdrücklich als Analystenlabels. Das gemeinsame Geheimnis wird weder angezeigt noch in ableitbarer Form veröffentlicht.

						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-Protokoll

Jede Nachricht wird als protobuf-Objekt serialisiert und anschließend mit AES-256-CBC sowie PKCS#7-Padding verschlüsselt. Ein zufälliger 16-Byte-IV steht vor dem Ciphertext; HMAC-SHA256 authentisiert IV und Ciphertext gemeinsam. Das resultierende Paket beginnt mit dem 32-Byte-HMAC, gefolgt von IV und Ciphertext. Ein vier Byte breites Little-Endian-Längenfeld rahmt die Übertragung auf dem TCP-Stream.

Diese Kombination liefert Vertraulichkeit und Integrität innerhalb des proprietären Protokolls. Sie verschleiert jedoch weder Zieladresse noch Verbindungsmetadaten und verhindert keine hostbasierte Erkennung. Die dargestellte Struktur ist ein defensives Protokollmodell, kein einsatzfähiger 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: Persistenz, Tasking und Process Hollowing

Nach der Registrierung kann die zweite Stufe eine Installation unter Local Application Data anlegen und über einen geplanten Task persistieren. Das Tasking-Modell deckt Dateiübertragung, Ausführung von Datenträger oder Speicher, PowerShell, Statusbestätigung, Bereinigung und vollständige Deinstallation ab.

Der In-Memory-Pfad implementiert getrennte 32- und 64-Bit-Helfer für Process Hollowing: Zielprozess angehalten erzeugen, Abbildbereiche vorbereiten, Remote-Speicher reservieren und beschreiben, Thread-Kontext anpassen und den Hauptthread fortsetzen. Auf Windows-Builds ab 26100 kommt ein zusätzlicher Kompatibilitäts- oder Bypasszweig hinzu, der Funktionen innerhalb der ntdll des Zielprozesses verändert.

Für Verteidiger ist diese Sequenz belastbarer als jeder Einzelindikator: neuer Scheduled Task, RegisteredHandlers/Current, PowerShell, Remote-Memory-Write, Context-Set und ResumeThread auf demselben 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 und Confidence

Die Filter trennen Dateihashes, konfigurierte Serverwerte und lokale Artefakte. Ein konfiguriertes Ziel ist kein Beleg für erfolgreichen Kontakt oder aktuelle Kontrolle.

YARA: exakte Sample-Erkennung

Die robuste Basisregel arbeitet ausschließlich mit den drei im Prüfbestand bestätigten SHA-256-Werten. Sie ist hochpräzise, erkennt aber keine neu kompilierten oder veränderten Varianten. Der Größenfilter begrenzt unnötige Hashberechnung; die Regel enthält weder Samplebytes noch Rekonstruktionslogik.

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: lokale Installationsspur

Die Sigma-Regel modelliert eine enge Dateisystemspur: die Kombination aus dem rekonstruierten Verzeichnisbestandteil RegisteredHandlers und dem Namensbestandteil Current. Sie setzt File-Event-Telemetrie voraus und ist als Hunting-Regel gedacht. Umgebungen sollten bekannte legitime Treffer zuerst als Filter ergänzen.

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: konfigurierte Infrastruktur

Diese Netzwerkregel ist bewusst schmal und zeitgebunden. Sie alarmiert nur auf ausgehende TCP-Verbindungen zur im Sample konfigurierten Adresse über einen der beiden Ports. Vor Einsatz müssen Reputation, aktueller Besitz der Adresse und lokale Allowlist geprüft werden. Ein Treffer belegt Kontaktversuch, nicht erfolgreiche C2-Kommunikation.

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: Netzwerk und Host korrelieren

Die Hunting-Abfrage kombiniert den stärkeren Ansatz: Verbindungen zum konfigurierten Ziel müssen innerhalb von 15 Minuten mit der lokalen Pfadspur auf demselben Gerät zusammenfallen. Sie ist für Microsoft Defender XDR formuliert und muss an die tatsächlich verfügbaren Tabellen sowie Datenaufbewahrung angepasst werden.

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

Der unabhängige Panel-Bestand enthält strukturelle Gegenstücke zu sämtlichen zehn protobuf-Nachrichtentypen des Bots. Der Vergleich erfolgte nicht anhand von Klassennamen, sondern über ProtoInclude-Tags, Feldnummern, normalisierte Feldtypen und die jeweiligen Verwendungsstellen. Abgedeckt sind Konfiguration, Registrierung, Taskzustellung, Bestätigung, Heartbeat, Bereinigung und Deinstallation.

Diese 10-von-10-Parität ist stärker als eine gemeinsame Zeichenkette oder ein ähnliches UI: Sie zeigt, dass beide Komponenten denselben Nachrichtenvertrag implementieren. Das Panel ergänzt außerdem Lizenz- und Updatepfade sowie einen lokalen Scanner für Reverse-Engineering-Werkzeuge. Belegt ist damit ein lokaler Anti-Analyse-Pfad; nicht belegt sind eine automatische serverseitige Sperre, Betreiberidentität oder bytegleiche Build-Provenienz.

Attribution Assessment

Wir bewerten den Bot als BlueLoader-kompatibel mit hoher technischer Konfidenz. Grundlage sind zehn übereinstimmende Nachrichtenverträge, korrespondierende Kontrollflüsse und die funktionale Ergänzung zwischen Client und Panel. Diese Aussage ordnet Softwarekomponenten ein – keine Personen.

Nicht belastbar sind Rückschlüsse auf Entwickler, Käufer, Betreiber oder Infrastrukturinhaber. Ebenso wird der Konfigurationswert 12.09.2025 nur als eingebettetes Label behandelt; ohne unabhängige Zeitquelle ist er weder Build-Datum noch Kampagnenbeginn.

Conclusion

Der untersuchte Bestand zeigt ein vollständigeres BlueLoader-Ökosystem als eine reine Loaderanalyse: ein nativ verpacktes Management-Panel, eine DNGuard-geschützte .NET-Anwendung und einen getrennten zweistufigen Remote-Control-Bot. BoxedApp erschwert den direkten Zugriff auf das Panel, DNGuard verschiebt wesentliche Logik in laufzeitabhängige native Körper, und der Bot schützt sein proprietäres protobuf-Protokoll mit AES-CBC und HMAC.

Trotz dieser Schichten bleiben belastbare Erkennungspunkte bestehen. Die höchste Signalqualität entsteht aus korreliertem Host- und Netzwerkverhalten: Installation unter Local Application Data, geplanter Task, wiederkehrende TCP-Verbindungen zu einem konfigurierten Ziel, PowerShell sowie die charakteristische Process-Hollowing-Abfolge. Die beigefügten YARA-, Sigma-, Suricata- und KQL-Beispiele operationalisieren genau diese unterschiedlichen Evidenzebenen.

Grenzen der Prüfung

• Die Analyse rekonstruiert Verhalten aus Code; sie belegt keine erfolgreiche Ausführung auf einem Opfergerät.
• Konfigurierte Infrastruktur belegt weder aktuelle Erreichbarkeit noch Eigentümerschaft.
• Rekonstruierte Namen sind Analysebezeichnungen und kein wiederhergestellter Originalquellcode.