CryptoDrainEXE: Analyse eines Browser-Wallet-Drainers

Was wir geprüft haben

Untersucht wurde ein fixierter JavaScript-Snapshot des GitLab-Projekts cryptodrainexe/cryptowalletdrainer. Der Quellstand stammt vom 23. Februar 2025, das manuelle Audit vom 12. Oktober 2026. Für diese Darstellung wurden die vorhandenen Dateien am 13. Oktober rein statisch verglichen.

Die Frage lautet: Was zeigt diese konkrete Kopie über Wallet-Verhalten, Datenübermittlung und die Vollständigkeit des Systems? Es wurde keine Windows-EXE untersucht, kein Sample ausgeführt und kein Endpunkt kontaktiert.

Referenz: ARTIFACT-MANIFEST.md, Commit 233cd4e62536170ef67ac12e3ac8f218f1d10517; Verhaltensbewertung in AUDIT-DE.md. Die Hashliste unten unterscheidet Original und Ableitungen.

Dateiverbund und Analyseverlauf

Die erste Ansicht zeigt ausgewählte Referenzen des erhaltenen HTML-Pakets. Die zweite trennt Rohdatei, unser Werkzeug, vorhandene Ableitungen und Bericht. Linien bedeuten dokumentierte Dateibeziehungen, keine ausgeführte Wallet- oder C2-Kette.

Originaldatei: HTML-Metadaten

Der HTML-Snapshot trägt den Projektnamen im title-Element. Die Browserdatei bezeichnet sich damit selbst als Drainer; der Name allein ist trotzdem kein Verhaltensnachweis. Hier werden nur Metadaten gezeigt, nicht das ausführende Script-Setup.

1<html lang="en"><head></head><body>
2
3    <meta charset="UTF-8">
4    <meta name="viewport" content="width=device-width, initial-scale=1.0">
5    <title>CryptoDrainEXE Multi-chain Crypto Wallet Drainer</title>

Was bei der Deobfuskierung verändert wurde

Das damalige Manifest dokumentiert 3.295 Stringeinträge, 403 Tabellenrotationen, 107 Decoder-Aliase und 7.922 statisch ersetzte Aufrufe. Anschließend wurden 1.722 Stringkonkatenationen gefaltet und die normalisierte Fassung mit Terser 5.44.0 syntaktisch geprüft. Diese Arbeit wurde hier nicht erneut ausgeführt.

Original, Decoderersetzung und Normalisierung haben unterschiedliche Hashes. Teilweise kryptische Variablennamen bleiben erhalten. Die Fassung ist lesbar, aber kein ausgeführtes Programm und kein nachgewiesenes Deployment.

Originalbeleg: Seitentitel

Der kurze Originalauszug wird nur als Text angezeigt. Er wurde in der Rohdatei und der vorhandenen normalisierten Fassung exakt gefunden. Der Seitentitel wird als Name in den Wallet-Verbindungsmetadaten verwendet. Diese Stelle erklärt die Transformation, nicht die schädliche Funktion des gesamten Samples.

'name':document[_0x24d3e8(0x483)]

name: document.title,

Originalbeleg: DOM-Elementtyp

Die normalisierte Fassung zeigt die tatsächlich verwendeten DOM-Bezeichner: style, div, web3-overlay und web3-modal. Der obere Vergleich belegt eine einzelne Stringauflösung; der längere Originalauszug darunter zeigt ihren unmittelbaren UI-Kontext.

Es ist ein Ausschnitt aus der bestehenden Analysefassung, keine nachgebaute Modell-UI. SHA-256: 02818c11a03deb783b45f89bfbc44409ae39ad7db7bbdc16edb251e30d27f42e.

'FxZSQ':_0x844b4c(0x579)

FxZSQ: "style",

1672        FxZSQ: "style",
1673        OujMT: "web3-style",
1674        iviYd: "div",
1675        kKYbd: "web3-overlay",
1676        wqNjF: "none",
1677        XEQTG: ".web3-overlay",
1678        uoEut: "click",
1679        luxzn: "web3-modal"

Unser Werkzeug: Escape-Zeichen lesen

Dieser Ausschnitt stammt aus unserem Analysewerkzeug, nicht aus dem Drainer. Er prüft einzelne Escape-Sequenzen, gibt ein Zeichen zurück und verschiebt die Leseposition. Kein eval, kein Browser und kein Netzwerkaufruf.

Der Ausschnitt ist kein vollständiger JavaScript-Parser. Er belegt die Arbeitsweise eines Hilfsschritts, nicht eine Ausführung des Samples.

1function decodeEscape(text, index) {
2  const ch = text[index];
3  const simple = { n: "\n", r: "\r", t: "\t", b: "\b", f: "\f", v: "\v", "0": "\0" };
4  if (Object.hasOwn(simple, ch)) return [simple[ch], index + 1];
5  if (ch === "x") {
6    const hex = text.slice(index + 1, index + 3);
7    if (!/^[0-9a-f]{2}$/i.test(hex)) throw new Error(`invalid hex escape at ${index}`);
8    return [String.fromCharCode(Number.parseInt(hex, 16)), index + 3];
9  }
10  if (ch === "u") {
11    const hex = text.slice(index + 1, index + 5);
12    if (!/^[0-9a-f]{4}$/i.test(hex)) throw new Error(`invalid unicode escape at ${index}`);
13    return [String.fromCharCode(Number.parseInt(hex, 16)), index + 5];
14  }
15  if (ch === "\n") return ["", index + 1];
16  if (ch === "\r" && text[index + 1] === "\n") return ["", index + 2];
17  return [ch, index + 1];
18}

Analysewerkzeug: ein begrenztes Stringliteral lesen

Der echte Auszug aus unserem Werkzeug liest Zeichen zwischen bekannten Anführungszeichen. Escape-Sequenzen werden an den separaten Helfer übergeben. Die Funktion wertet kein JavaScript aus; Tabellenmarker und sample-spezifische Decoderzuordnungen sind nicht Teil dieses Auszugs.

44    const quote = text[i];
45    if (quote !== "\"" && quote !== "'") throw new Error(`unexpected token in string table at ${i}`);
46    i += 1;
47    let value = "";
48    while (i < text.length && text[i] !== quote) {
49      if (text[i] === "\\") {
50        const decoded = decodeEscape(text, i + 1);
51        value += decoded[0];
52        i = decoded[1];
53      } else {
54        value += text[i];
55        i += 1;
56      }
57    }
58    if (text[i] !== quote) throw new Error("unterminated string table item");

Analysewerkzeug: Stringliterale zusammenfalten

Dieser zweite Werkzeugauszug verbindet erkannte JSON-Stringliterale. Die Schleife stoppt, sobald keine Ersetzung mehr erfolgt. Das ist der echte lokale Verarbeitungsschritt, kein nachgebautes Drainer-Modell. Der historische Lauf und seine Zählwerte stehen im Manifest; er wurde für diese Ergänzung nicht erneut ausgeführt.

110const jsonString = '"(?:\\\\.|[^"\\\\])*"';
111const concatPattern = new RegExp(`(${jsonString})\\s*\\+\\s*(${jsonString})`, "g");
112let foldedConcats = 0;
113while (true) {
114  let round = 0;
115  output = output.replace(concatPattern, (_full, left, right) => {
116    round += 1;
117    foldedConcats += 1;
118    return JSON.stringify(JSON.parse(left) + JSON.parse(right));
119  });
120  if (round === 0) break;
121}

Wallet-Verhalten und Datenübermittlung

Die statische Analyse dokumentiert eine Wertsortierung über amount_usd (Zeile 4445) und Wallet-/Gerätetelemetrie mit IP-/Standortdaten und Assetinventar (1938–2258). Damit priorisiert der Code Assets nach Wert und übermittelt Informationen über Wallet und Umgebung.

Der manuelle Befund CR-01 beschreibt die schädliche Diskrepanz: Die Seite rahmt den Vorgang als Verifikation oder Claim, während der Code hohe Berechtigungen oder direkte Vermögensübertragungen verlangt. Die zugrunde liegenden Wallet-Zweige sind in 4678–5875 dokumentiert; erlaubnisbezogene Befunde liegen in 3525–3832 und 4529–4677. „Verification Error“ erscheint in Zeile 4816 als UI-Text. Die Bewertung stützt sich auf die Pfade und ihren Kontext, nicht allein auf dieses Wort.

Telegram ist dabei Telemetriesenke, nicht der Nachweis eines vollständig vorhandenen ausführenden C2-Servers.

Adressen und Dienste nach Rolle

Die zwei konfigurierten Zieladressen stehen unten getrennt von Protokolladressen und Diensten. Address und Receiver benennen denselben Wert; die Chains-Konfiguration führt zusätzlich ein Ausführungsvertragsziel. Der manuelle Audit verfolgt die Empfänger-/Spenderrolle statisch bis zu werttragenden Pfaden.

Weitere Wallet-Deep-Links, Chain-Explorer, Preis- und Metadatendienste sind im Sample referenziert. Sie sind keine eigenständigen Schadindikatoren. Die öffentliche IP-Abfrage referenziert api[.]ipify[.]org in der normalisierten Fassung, Zeile 1950; unten sind repräsentative Dienste statt einer vollständigen Domainliste aufgeführt.

Warum kein vollständiges C2 rekonstruiert ist

In dieser Kopie ist send_request ein lokaler Dispatcher (Zeilen 1795–1858), kein vollständiger HTTP-C2-Client. Die Weitergabe bestimmter Signaturdaten an einen ausführenden Server ist deshalb nicht vollständig vorhanden. Der ursprüngliche Servercode fehlt.

Telegram ist als Telemetriedienst dokumentiert; Bot-Token und Chat-/Nutzerkennungen bleiben redigiert. RPC-Endpunkte und die deklarierte Metadaten-Domain sind keine Ersatzbelege für ein vollständiges Betreiber-Backend.

Was an dieser Kopie auffällt

Stringtabellen und kryptische Namen sind gewöhnliche Obfuskation. Aussagekräftiger ist die Kombination aus Wallet-orientiertem Verhalten, Wertsortierung und Telemetrie bei gleichzeitig unvollständigen Abhängigkeiten und fehlendem Servercode.

Das erklärt, warum eine lesbare Codekopie und ein vollständig beobachtetes System nicht dasselbe sind. Es erlaubt keine Aussage zur Marktposition oder zu tatsächlichen Opferverlusten.

Grenzen der Prüfung

• Keine Windows-EXE-Analyse, Sample-Ausführung oder Wallet-Signatur.
• Keine On-Chain-Verifikation von Kontotyp, Eigentum oder Verlusten.
• Keine Credentials, Requestkörper oder funktionsfähigen Drainer-Sequenzen veröffentlicht.