Was wir zunehmend brauchten — besonders als mehr unserer Ziele zu KI- Anwendungsökosystemen wurden, in denen nicht vertrauenswürdiger Text durch Agenten, Tool-Ausgaben, Admin-Review-Warteschlangen und Support-Konsolen fließt und JavaScript an Orten auslöst, die niemand beobachtet — war ein einziges Framework, das beides konnte: die interaktive, persistente Post-Exploitation-Kontrolle eines BeEF-Hooks und die Fire-and-Forget-Blind-XSS-Callback-Beute, in einer Payload, die in aktuellen Browsern zuverlässig ist und wie heutige echte Login-Bildschirme aussieht.

Also haben wir WRAITH gebaut.

Hinweis: Dies ist eine laufende Arbeit

Wir veröffentlichen WRAITH früh und mit Absicht. Wir geben es lieber in die Hände der Leute, die es tatsächlich nutzen werden — und hören, was kaputt geht — als darauf zu sitzen, bis es „fertig" ist.

Das bedeutet: Erwarten Sie raue Kanten und Fehler. Einige Module sind stärker kampferprobt als andere, das Browser-Verhalten verschiebt sich ständig unter uns (siehe die Hinweise zum Netzwerk-Scan unten), und APIs können sich zwischen Versionen ändern. Wenn Sie auf etwas stoßen, eröffnen Sie bitte ein Issue — Reproduktionsschritte, Browser + Version und was Sie erwartet haben, sind Gold wert. Pull Requests sind unter den Beitragsbedingungen des Projekts willkommen.

Schnellstart (Docker)

Der schnellste Weg. Sie benötigen Docker + Docker Compose.

setup.sh führt Sie durch alles:

1. Erkennt Ihre öffentliche IP (oder lässt Sie eine Domain / einen benutzerdefinierten Host eingeben), sodass jede Hook- und Payload-URL mit Ihrer Adresse erstellt wird.
2. Lässt Sie einen Operator-Benutzernamen + ein Passwort für die Konsolen-Anmeldung festlegen.
3. Generiert das Sitzungssignierungs-Geheimnis, schreibt eine gitignorierte .env (chmod 600) und baut + startet den Container.
4. Gibt am Ende Ihre Live-URLs und eine Drop-in-XSS-Payload aus:

Verwalten Sie es mit Standard-Compose-Befehlen:

Erfasste Sitzungen bleiben in ./data/ auf dem Host erhalten — niemals in das Image eingebacken, niemals committet (.env und data/ sind gitignored).

Die Operator-Konsole ist login-geschützt, wann immer ein Operator-Passwort gesetzt ist, mit einer Benutzername- + Passwort-Anmeldung:

Lokal ohne Docker ausführen (Dev)

Öffnen Sie dann die Operator-Konsole unter http://127.0.0.1:3000/operator/ und die Demo-Opfer-Seite unter http://127.0.0.1:3000/demo/ (in einem zweiten Browser/Profil). Auf localhost ist die Anmeldung standardmäßig aus Bequemlichkeit deaktiviert — der Server weigert sich, ohne ein Operator-Passwort an eine öffentliche Schnittstelle zu binden, sodass Sie nicht versehentlich ein offenes Panel exponieren können.

Funktionen

Hook + Operator-Konsole

/hook.js ist eine kleine Payload. Platzieren Sie sie auf jeder Seite, die Sie kontrollieren (<script src="/hook.js"></script>), oder liefern Sie sie über eine XSS in Ihrem Ziel aus. Der Browser, der sie lädt, öffnet einen WebSocket zurück zum Operator, identifiziert sich selbst (Browser, OS, IP, Seite, UA), verbindet sich automatisch neu und übersteht Navigationen. Jeder gehookte Browser erscheint live in der Konsole, wo Sie einen auswählen und steuern — das vollständige Dashboard ist der Hero-Shot oben in dieser README: Gehookte-Browser-Liste, Zieldetails, Bereitstellungssteuerung, Live-Aktivitätsfeed und erfasste Anmeldedaten.

Social-Engineering-Overlays

Modernisierte Fake-Login-Overlays, gerendert in einem isolierten Shadow DOM, damit sie auf jeder Host-Seite pixelgenau aussehen und die Seite dahinter wie ein echtes Re-Auth-Modal frost-verwischen. Wird mit LinkedIn, Facebook und Microsoft / Office 365 ausgeliefert (authentische Zwei-Schritt-E-Mail → Passwort).

Live-Tastatureingaben + erfasste Anmeldedaten

Jedes Zeichen, das das Ziel in ein Overlay tippt, wird in Echtzeit an die Konsole gestreamt, und die übermittelten Anmeldedaten landen in Erfasste Anmeldedaten — alles wird persistiert, sodass bei Aktualisierung oder Neustart nichts verloren geht.

Page Capture — die Blind-XSS-Beute

In dem Moment, in dem ein Browser hookt, löst WRAITH automatisch Page Capture aus: genau das, was ein Blind-XSS-Framework greift, wenn Ihre Payload irgendwo feuert, wo Sie sie nicht sehen können — wo sie gefeuert hat (Origin + URL + Referrer), die Cookies des Opfers (nicht-HttpOnly), das vollständige DOM und einen Screenshot. Fehler werden ehrlich gemeldet, weil sie die Lektion sind: HttpOnly-Cookies erscheinen nie, und CSP oder Cross-Origin-Canvas-Tainting können den Screenshot blockieren.

Page Mirror — gehen Sie über den Screenshot hinaus 🆕

Hier geht WRAITH weiter als die Tools, die es ersetzt. Wenn Sie eine Blind-XSS oder einen Hook in einer Seite landen, bleiben die meisten Frameworks bei einem Screenshot und einem Dump des rohen HTMLs stehen — Sie können sehen, wo Ihre Payload gefeuert hat, aber Sie können nicht wirklich etwas damit anfangen.

WRAITHs Page Mirror verwandelt diese Sackgassen-Beute in eine live, navigierbare Ansicht der Anwendung. Öffnen Sie die gehookte Seite als echte, gerenderte Browser-Ansicht innerhalb der Operator-Konsole — klicken Sie dann auf Links und bewegen Sie sich visuell durch die App, genau wie das Opfer es tun würde.

Der Schlüssel: jede Navigation wird durch den gehookten Browser abgerufen, sodass sie die Sitzung und das Same-Origin-Vertrauen des Opfers nutzt. Jede Seite, jeder Endpunkt, jedes Feature, das die Sitzung des Opfers erreichen kann, können auch Sie erreichen — einschließlich Seiten, die hinter einem authentifizierten Sitzungs-Cookie liegen, das Sie nie sehen (und das, da es HttpOnly ist, nie direkt stehlen könnten).

Im Beispiel unten starten wir in der Ticket-Warteschlange eines Support-Agenten und klicken direkt zu einem internen Credential Vault durch — einer Seite, die nur innerhalb einer authentifizierten Agenten-Sitzung aufgelöst wird. Keine Anmeldedaten gephisht, kein Cookie gestohlen: Wir sind einfach auf der Sitzung des Opfers dorthin geritten.

Cross-Origin-Lesezugriffe schlagen weiterhin absichtlich fehl (die Same-Origin-Policy gilt) — die Reichweite des Mirrors ist exakt die Reichweite des Opfers, nicht mehr, nicht weniger. Diese Grenze ist selbst Teil der Lektion.

Blind-XSS-Payload-Katalog

Ein XSS-Hunter-artiger Katalog von einsatzbereiten Injektions-Strings für jeden Kontext (HTML, Attribut-Breakout, Tag-Close, Event-Handler, JS-Kontext, javascript:-URIs, jQuery), jeweils automatisch mit Ihrer Hook-URL gefüllt und mit einem Klick kopierbar.

Lokaler / Localhost-Netzwerk-Scan

Nutzt den gehookten Browser als Proxy, um die lokalen Dienste des Opfers zu fingerprinten. Es ist ein Timing-Seitenkanal, neu gebaut für aktuelle Browser — der zuverlässige Standard ist ein kalibrierter 127.0.0.1-Scan mit zwei unabhängigen Primitive (Fetch- und WebSocket-Timing, die wörtliche eBay- check.js-Methode). LAN-Modi sind enthalten, aber ehrlich gekennzeichnet, da Chrome 142+ Local Network Access sie jetzt einschränkt (siehe unten).

Integriertes Übungslabor

Ein absichtlich verwundbarer „Support-Desk" unter /lab mit einem Stored-XSS-Sink, sodass Sie die gesamte Kette Ende-zu-Ende, Same-Origin, demonstrieren können: ein bösartiges Ticket einreichen → ein „Agent" prüft die Warteschlange und die Payload feuert (der Blind-XSS-Moment) → Page Mirror auf den gehookten Agenten und den sitzungsgeschützten Vault ziehen. Absichtlich unsicher by design, mit gepflanzten Flags.

Blind XSS auf dieser Plattform lehren

Der Hook feuert in dem Moment, in dem er lädt, genau wie eine Blind-XSS-Payload, die in ein gespeichertes Feld eingefügt wird und später in einem Admin-/Support-/ Log-/Agenten-Kontext gerendert wird, den Sie nicht sehen können. Lektionen, die direkt in den Daten sichtbar werden:

• Cookies sind nur JS-lesbar. HttpOnly-Cookies erscheinen nie, was der ganze Sinn von HttpOnly ist — und genau der Grund, warum Page Mirrors Auf-der- Sitzung-reiten-Ansatz wichtiger ist als das Cookie stehlen.
• Screenshots sind Best-Effort. html2canvas kann durch CSP blockiert werden, und Cross-Origin-Bilder taintieren die Canvas, sodass sie nicht exportiert werden kann. Diese Fehler werden ehrlich gemeldet statt versteckt.
• Origin + Referrer sagen Ihnen, wo Sie gelandet sind, was bei Blind XSS die gesamte Frage ist („Wo hat meine Payload ausgeführt?").

Für ein Offline-Labor hosten Sie html2canvas selbst — siehe public/vendor/README.md.

Über den Netzwerk-Scan (lesen Sie vor der Demo)

JavaScript kann keine Cross-Origin-Antworten lesen, aber es kann eine Anfrage starten und beobachten, wie sie fehlschlägt und wie schnell, was den Port-Status verrät. Das Modul wurde neu um das herum gebaut, was in aktuellen Browsern (2025–2026) funktioniert, weil der alte LAN-Sweep aus der BeEF-Ära jetzt tot ist.

Die moderne Realität: Chrome 142+ (Okt 2025) hat Local Network Access (LNA) ausgeliefert, das Anfragen an private Bereiche (10.x / 172.16.x / 192.168.x) hinter einer Berechtigungsabfrage einschränkt. Ein blinder LAN-Sweep erreicht das Kabel nicht mehr. Aber Loopback (127.0.0.1) ist weiterhin erreichbar, und das Scannen davon ist der reale Angriff — eBay, Best Buy und andere wurden dabei erwischt, wie sie den Localhost von Besuchern port-scannten, um lokale Dienste und Remote-Access-Tools zu fingerprinten.

Das Modul hat also drei Modi:

• Dieser Rechner (localhost) — der zuverlässige Standard. Ein kalibrierter 127.0.0.1-Scan, der jeden Port mit Fetch-Timing und WebSocket-Timing testet, zuerst die RST-Baseline dieses Rechners lernt und dann alles, was sich auflöst, hängt oder langsamer läuft, als OPEN markiert, den wahrscheinlichen Dienst beschriftet und zeigt, ob fetch, ws oder beide übereinstimmten. Funktioniert heute in Chrome und Firefox.
• LAN-Host — eine private IP scannen. Funktioniert nur, wenn der Browser es durchlässt; Chrome 142+ wird es normalerweise blockieren (das Modul erkennt dies und sagt es).
• LAN-Hosts entdecken — Subnetz-Sweep. Meistens jetzt LNA-blockiert; behalten, um den Block als Lektion zu zeigen.

Wie es sich auf BeEF abbildet (für den Vortrag)

„Wie unterscheidet sich das von Blind XSS, Evilginx oder EvilGoPhish?"

Diese Tools leben in verschiedenen Phasen des Angriffs und missbrauchen verschiedene Vertrauenskontexte. Sie sind komplementär und verketten sich miteinander.

Die ehrliche Unterscheidung, die man lehren sollte: Unser Overlay-Phishing erntet, was der Benutzer tippt — es erfasst keine echte Sitzung und schlägt kein MFA. Genau deshalb ist es ein großartiger Kontrast und genau der Grund, warum die Branche zu phishing-resistenter, origin-gebundener Authentifizierung (FIDO2 / WebAuthn / Passkeys) übergegangen ist. Eine realistische Kill-Chain nutzt alle drei: Blind XSS findet und liefert Code-Ausführung, ein WRAITH-Hook gibt interaktive In-Session-Kontrolle (und erreicht über Page Mirror direkt App-Funktionalität), und eine Weiterleitung kann das Opfer in einen Evilginx-Flow für eine echte MFA-bestandene Sitzung führen.

Konfiguration

Alles ist env-getrieben; derselbe Build läuft überall, weil hook.js seine Call-Back-URL von dem Ort ableitet, an dem es ausgeliefert wurde. setup.sh schreibt diese in .env.

Ein signiertes HttpOnly-Sitzungs-Cookie deckt sowohl das Panel als auch den Live-WebSocket ab. Die Hook-Payload, die Demo-Seite und der /ws/hook-Kanal bleiben öffentlich, damit Opfer sie erreichen können. Als Fail-Safe weigert sich der Server, an eine öffentliche Schnittstelle zu binden, es sei denn, ein Passwort ist gesetzt.

Für eine Bare-Metal-/systemd-Bereitstellung statt Docker siehe deploy/DEPLOY.md.

Dateien

Lizenz & Attribution

WRAITH ist © 2026 Arcanum Information Security, veröffentlicht unter der Apache License 2.0.

Sie können es frei verwenden, modifizieren und weiterverbreiten — auch in Ihrer eigenen Schulung — aber Sie müssen die Attribution beibehalten: Behalten Sie die LICENSE- und NOTICE-Dateien und den Arcanum-Urheberrechtshinweis in allem, was Sie verbreiten oder forken, und geben Sie alle von Ihnen vorgenommenen Änderungen an (Apache-2.0 §4). Siehe NOTICE. Die Lizenz gewährt keine Nutzung des Arcanum-Namens oder der Marken über die Beschreibung der Herkunft des Codes hinaus.

Mit ❤️ gebaut von Arcanum — https://arcanum-sec.com