2CLoader: Tarnschicht, Payload-Kette und Erkennungspunkte

Quelle, Prüfauftrag und Beleggrenze

ThreatLabz veröffentlichte am 30. September 2026 eine technische Analyse von 2CLoader und ein Python-Werkzeug zur Payload-Extraktion. Diese Untersuchung liest beide Primärquellen gegeneinander: Welche Struktur ist im Werkzeug tatsächlich kodiert, welche Verhaltensaussagen stammen ausschließlich aus der Sample- und Telemetrieanalyse von ThreatLabz, und welche defensiven Konsequenzen lassen sich daraus ableiten?

Es lag uns kein 2CLoader-Sample vor. Der Begleitcode wurde nicht mit Malware ausgeführt. Aussagen über Laufzeitverhalten, ausgelieferte Familien und Infrastruktur bleiben deshalb ausdrücklich der Primärquelle zugeschrieben.

Was belegt ist — und was fehlt

Bericht und Begleitcode bilden zwei verschiedene Evidenzebenen. Der Bericht beschreibt beobachtete Samples, Ausführungsoptionen und Kampagnentelemetrie. Das Werkzeug implementiert die Resource-Suche, Footer-Struktur und Entschlüsselungsfolge. Ohne Originalsample lässt sich diese Implementierung hier nicht gegen einen konkreten Build wiederholen.

Der Footer ist die Schaltzentrale

Das öffentliche Werkzeug erwartet am Ende der PE-Resource exakt 0xDC Byte Konfiguration. Ein Magic-Wert markiert den Footer; Größenfelder trennen Hauptpayload, optionale Zusatzdatei und optionale Nachricht. Weitere Felder steuern Persistenz, Anti-Analyse, Zielprozess, Schlafzeit und den geplanten Task.

Das ist defensiv relevant: Der Footer verbindet statisch sichtbare Struktur mit späterem Verhalten. Ein einzelner Magic-Wert wäre als Erkennung zu fragil; zusammen mit PE-Resource-Lage, plausiblen Größenbeziehungen und den nachfolgenden Prozessaktionen wird er belastbarer.

80def parse_footer(footer_bytes: bytes) -> configfooter:
81
82    if struct.unpack_from("<I", footer_bytes, 0)[0] != FOOTER_MAGIC:
83        fail()
84
85    dwords = struct.unpack("<55I", footer_bytes)
86    return configfooter(
87        magic=dwords[0],
88        fl=dwords[1],
89        final_payload_size=dwords[2],
90        aes_gcm_nonce_size=dwords[3],
91        aes_gcm_tag_size=dwords[4],
92        aes_gcm_nonce=footer_bytes[0x14:0x20],
93        aes_gcm_tag=footer_bytes[0x20:0x30],
94        sha256_seed_xor2=footer_bytes[0x30:0x40],
95        sha256_seed_xor1=footer_bytes[0x40:0x50],
96        sum_of_bytes_checksum=dwords[20],
97        persistence=dwords[21],
98        opt_flag=dwords[22],
99        optional_payload_size=dwords[23],
100        optional_message_size=dwords[24],
101        xor_add_after_rolling_xor=footer_bytes[0x64],
102        xor_key_after_rolling_xor=footer_bytes[0x65],
103        rolling_xor_seed=footer_bytes[0x66],
104        unk_67=footer_bytes[0x67],
105        sleeptime=dwords[26],
106        beacon_id=footer_bytes[0x6C:0x7C],
107        target_executable_name_used_in_injection=footer_bytes[0x7C:0xBC],
108        bt=dwords[47],
109        pn=footer_bytes[0xC0:0xD0],
110        unk_D0=dwords[52],
111        scheduled_tasks_trigger_interval_hours=dwords[53],
112        decompressed_buffer_size=dwords[54],
113    )

Von der Resource zu drei Ausgaben

Die dokumentierte Verarbeitung ist eine feste Kette: Resource finden, Rolling XOR anwenden, zweite XOR-Stufe anwenden, Schlüssel aus Konfiguration und Code-Hash ableiten, AES-GCM authentifiziert entschlüsseln und optional Xpress Huffman dekomprimieren. Erst danach werden Hauptpayload, optionale Zusatzdatei und Nachrichtenblock getrennt.

AES-GCM ist hier kein Schutz für das Opfer, sondern schützt die eingebettete Payload vor einfacher statischer Extraktion. Gleichzeitig schafft der authentifizierte Tag einen harten Prüfschritt: falsche Schlüsselableitung oder veränderte Daten brechen die Kette.

316def extract_decode_and_write(pe_path: str | Path, out_dir: str | Path):
317    resource = find_footer_resource(pe_path)
318    footer = resource["footer"]
319    out_dir = Path(out_dir)
320    out_dir.mkdir(parents=True, exist_ok=True)
321
322    section_sha256_seed = compute_section_sha256_seed(pe_path)
323    stage1 = decode_resource_stage(resource["body"], footer.rolling_xor_seed)
324    stage2 = xor_decrypt_payload(bytearray(stage1), footer.xor_add_after_rolling_xor, footer.xor_key_after_rolling_xor)
325    aes_key = generate_aes_key(footer, section_sha256_seed)
326    aes_plaintext = aes_gcm_decrypt(stage2, footer, aes_key)
327    final_buffer = decompress_final_payload(aes_plaintext, footer)
328    main_payload, dropped_payload, message_block = split_body_parts(final_buffer, footer)

Anti-Analyse ist Teil der Schlüsselableitung

ThreatLabz beschreibt VM-, Debugger-, Timing- und Benutzeraktivitätsprüfungen. Besonders relevant ist die Kopplung an die Entschlüsselung: Eine Timingprüfung kann den SHA-256-Zwischenwert verändern und dadurch einen falschen AES-Schlüssel erzeugen. Das erzeugt keinen separaten sichtbaren Abbruch, sondern lässt die Payload-Kette kryptografisch scheitern.

Daneben soll 2CLoader über indirekte Systemaufrufe und Inline-Trampoline die Sicht von User-Mode-Sicherheitsprodukten und der nachgeladenen Payload beeinflussen. Die Wirkung dieser Mechanismen wurde hier nicht dynamisch nachgemessen.

Drei Ausführungswege, mehrere Persistenzpfade

Der Primärbericht beschreibt speicherbasierte .NET-Ausführung, manuelles LoadPE im eigenen Prozess und RunPE in einem angehaltenen Zielprozess. Konfigurationsflags können Fallbacks zwischen den nativen Wegen steuern. Optional kommen eine zweite abgelegte Datei und eine Täuschungsnachricht hinzu.

Persistenz kann über Run, RunOnce, Startup-Ordner, geplante Aufgaben, den Registry-Wert Load oder UserInitMprLogonScript erfolgen. Für die Verteidigung ist nicht die einzelne Methode entscheidend, sondern die zeitliche Kette aus neuer Autostart-Konfiguration, verdächtigem Prozessstart beziehungsweise Prozessmanipulation und anschließendem Beacon-Verkehr.

Erkennung: Struktur und Verhalten korrelieren

Ein belastbares Modell sollte drei Ebenen verbinden. Erstens statisch: PE-Resource mit passendem Footer-Magic, plausiblen Größenbeziehungen und Optionsfeldern. Zweitens Hostverhalten: neue Persistenz plus Prozessmanipulation oder speicherbasierte CLR-Ladung. Drittens Netzwerk: zeitnaher HTTP-POST eines neu gestarteten, nicht erwarteten Prozesses.

Das folgende Sigma-Beispiel ist ein defensives Korrelationsmodell für einen besonders aussagekräftigen Persistenzzweig. Es wurde hier nicht mit einer Sigma-Engine validiert und muss an Produktfelder, legitime Softwareverteilung und lokale Namenskonventionen angepasst werden.

1title: 2CLoader-style scheduled task persistence candidate
2status: experimental
3logsource:
4  product: windows
5  category: process_creation
6detection:
7  task_tool:
8    Image|endswith: '\\schtasks.exe'
9    CommandLine|contains|all:
10      - '/create'
11      - '/sc'
12      - 'onlogon'
13  suspicious_name:
14    CommandLine|contains: 'SecurityHealthService.exe'
15  condition: task_tool and suspicious_name
16falsepositives:
17  - Legitimate software using the same filename or task pattern
18level: medium

Payload-Nutzung ist keine Entwicklerzuordnung

ThreatLabz beobachtete 2CLoader vor allem in Verbindung mit Vidar und Remus sowie zusätzlich XWorm. Das beschreibt Auslieferungsbeziehungen in den untersuchten Kampagnen. Es beweist weder, dass dieselbe Partei Loader und Payloads entwickelt, noch dass jede künftige 2CLoader-Variante dieselben Familien verteilt.

Ebenso sind Dateiname, MessageBox-Text, Zielprozess oder einzelne C2-Indikatoren keine belastbare Betreiberidentität. Dieser Bericht übernimmt deshalb keine Akteurszuordnung.

Was diese Quellenanalyse trägt

Bericht und offizieller Decryptor stimmen in den strukturellen Kernaussagen überein: Footer-Größe und Magic, dreiteilige Resource, gestufte Entschlüsselung, codegebundene Schlüsselableitung und optionale Dekompression. Die Primärquelle ergänzt Anti-Analyse, Persistenz, Ausführungsoptionen und Kampagnenbeobachtungen.

Nicht belegt ist eine eigene Reproduktion an einem Sample. Deshalb bewertet diese Untersuchung die Architektur und ihre defensiven Konsequenzen, nicht die Funktionsfähigkeit eines konkreten Samples oder die Vollständigkeit aller Varianten.

Grenzen der Prüfung

• Der Bericht ist eine eigenständige technische Einordnung öffentlicher Primärquellen, keine eigene Malware-Sample-Reversierung.
• Der veröffentlichte Decryptor wurde gelesen und hashgebunden, aber ohne Malware-Eingabe weder ausgeführt noch funktional verifiziert.
• Von ThreatLabz beobachtete Payload-Familien und Infrastruktur belegen keine allgemeine Zuordnung jedes 2CLoader-Builds.