Quello di cui avevamo sempre più bisogno — specialmente man mano che più target diventavano ecosistemi di applicazioni AI, dove testo non fidato scorre attraverso agenti, output di strumenti, code di revisione admin e console di supporto, e fa scattare JavaScript in luoghi dove nessuno guarda — era un unico framework che facesse entrambe le cose: il controllo interattivo e persistente post-exploitation di un hook BeEF, e il bottino fire-and-forget da callback blind-XSS, in un unico payload affidabile nei browser attuali e che somigli ai veri schermi di login di oggi.

Così abbiamo costruito WRAITH.

Attenzione: è un lavoro in corso

Rilasciamo WRAITH in anticipo, e di proposito. Preferiamo metterlo nelle mani delle persone che lo useranno davvero — e sentire cosa si rompe — piuttosto che tenerlo finché non è "finito".

Questo significa: aspettatevi spigoli e bug. Alcuni moduli sono più testati sul campo di altri, il comportamento dei browser cambia continuamente sotto di noi (vedi le note sullo scan di rete qui sotto), e le API possono cambiare tra versioni. Se incontri qualcosa, apri una issue — passi per la riproduzione, browser + versione, e cosa ti aspettavi sono oro. Le PR sono benvenute secondo i termini di contribuzione del progetto.

Avvio rapido (Docker)

Il percorso più veloce. Ti servono Docker + Docker Compose.

setup.sh ti guida attraverso tutto:

1. Rileva il tuo IP pubblico (o ti permette di inserire un dominio / host personalizzato) così ogni hook e URL di payload viene creato con il tuo indirizzo.
2. Ti fa impostare un nome utente + password operatore per il login alla console.
3. Genera il segreto per la firma delle sessioni, scrive un .env gitignorato (chmod 600), e compila + avvia il container.
4. Alla fine stampa i tuoi URL live e un payload XSS pronto all'uso:

Gestiscilo con i comandi compose standard:

Le sessioni catturate persistono in ./data/ sull'host — mai incluse nell' immagine, mai committate (.env e data/ sono gitignorati).

La console operatore è protetta da login ogni volta che è impostata una password operatore, con accesso tramite nome utente + password:

Eseguilo localmente senza Docker (dev)

Poi apri la console operatore su http://127.0.0.1:3000/operator/ e la pagina vittima demo su http://127.0.0.1:3000/demo/ (in un secondo browser/profilo). Su localhost, il login è disabilitato di default per comodità — il server rifiuta di legarsi a un'interfaccia pubblica senza una password operatore, così non puoi esporre accidentalmente un pannello aperto.

Funzionalità

Hook + console operatore

/hook.js è un payload piccolo. Inseriscilo in qualsiasi pagina che controlli (<script src="/hook.js"></script>) o consegnalo tramite un XSS nel tuo target. Il browser che lo carica apre un WebSocket verso l'operatore, si identifica (browser, OS, IP, pagina, UA), si riconnette automaticamente e sopravvive alla navigazione. Ogni browser hookato appare live nella console, dove ne scegli uno e lo piloti — la dashboard completa è l'immagine principale in cima a questo README: elenco dei browser hookati, dettaglio del target, controlli di deploy, feed attività live e credenziali catturate.

Overlay di social engineering

Overlay modernizzate di finto login, renderizzate in un shadow DOM isolato così che appaiano pixel-perfect su qualsiasi pagina host e sfumino la pagina dietro di loro come un vero modale di ri-autenticazione. Include LinkedIn, Facebook e Microsoft / Office 365 (autentico flusso a due passaggi email → password).

Keystroke live + credenziali catturate

Ogni carattere che il target digita in un'overlay viene trasmesso alla console in tempo reale, e le credenziali inviate finiscono in Credenziali Catturate — tutto persistito così che nulla vada perso al refresh o al riavvio.

Page Capture — il bottino blind-XSS

Nell'istante in cui un browser si hooka, WRAITH attiva automaticamente Page Capture: esattamente ciò che un framework blind-XSS cattura quando il tuo payload si attiva da qualche parte che non puoi vedere — dove si è attivato (origine + URL + referrer), i cookie della vittima (non-HttpOnly), il DOM completo e uno screenshot. I fallimenti vengono riportati onestamente, perché sono la lezione: i cookie HttpOnly non compaiono mai, e CSP o il tainting del canvas cross-origin possono bloccare lo screenshot.

Page Mirror — vai oltre lo screenshot 🆕

È qui che WRAITH va oltre gli strumenti che sostituisce. Quando piazzi un blind XSS o un hook in una pagina, la maggior parte dei framework si ferma a uno screenshot e un dump di HTML grezzo — puoi vedere dove si è attivato il tuo payload, ma non puoi davvero fare nulla con esso.

Il Page Mirror di WRAITH trasforma quel bottino senza uscita in una vista live e navigabile dell'applicazione. Apri la pagina hookata come una vera vista browser renderizzata dentro la console operatore — poi clicca sui link e muoviti nell'app visivamente, proprio come farebbe la vittima.

Il punto chiave: ogni navigazione viene recuperata attraverso il browser hookato, quindi viaggia sulla sessione della vittima e sulla fiducia same-origin. Qualsiasi pagina, endpoint o funzionalità che la sessione della vittima può raggiungere, puoi raggiungerla anche tu — incluse pagine protette da un cookie di sessione autenticato che non vedi mai (e che, essendo HttpOnly, non potresti mai rubare direttamente).

Nell'esempio qui sotto, partiamo dalla coda ticket di un agente di supporto e clicchiamo direttamente fino a un Credential Vault interno — una pagina che si risolve solo dentro una sessione agente autenticata. Nessuna credenziale phishata, nessun cookie rubato: abbiamo semplicemente cavalcato la sessione della vittima fino a lì.

Le letture cross-origin falliscono ancora di proposito (la Same-Origin Policy regge) — la portata del mirror è esattamente quella della vittima, né più né meno. Quel confine è esso stesso parte della lezione.

Catalogo payload blind-XSS

Un catalogo in stile XSS-Hunter di stringhe di iniezione pronte all'uso per ogni contesto (HTML, attribute breakout, chiusura tag, event handler, contesto JS, URI javascript:, jQuery), ognuna precompilata con il tuo URL di hook e copiabile con un clic.

Scan di rete locale / localhost

Usa il browser hookato come proxy per identificare i servizi locali della vittima. È un canale laterale di timing, ricostruito per i browser attuali — il default affidabile è uno scan 127.0.0.1 calibrato che usa due primitive indipendenti (timing fetch- e WebSocket, il metodo letterale check.js di eBay). Le modalità LAN sono incluse ma etichettate onestamente, perché Chrome 142+ Local Network Access ora le blocca (vedi qui sotto).

Laboratorio di pratica integrato

Una "help desk" deliberatamente vulnerabile su /lab con un sink XSS memorizzato, così puoi dimostrare l'intera catena end-to-end, same-origin: invia un ticket malevolo → un "agente" rivede la coda e il payload si attiva (il momento blind-XSS) → fai Page Mirror dell'agente hookato e tira fuori il vault protetto da sessione. Intenzionalmente insicuro di progetto, con flag piantati.

Insegnare il blind XSS su questa piattaforma

L'hook si attiva nell'istante in cui viene caricato, esattamente come un payload blind-XSS inserito in un campo memorizzato che poi viene renderizzato in qualche contesto admin/supporto/log/agente che non puoi vedere. Lezioni che emergono direttamente dai dati:

• I cookie sono leggibili solo via JS. I cookie HttpOnly non compaiono mai, che è il punto stesso di HttpOnly — ed è esattamente il motivo per cui l'approccio cavalca la sessione di Page Mirror conta più di rubare il cookie.
• Gli screenshot sono best-effort. html2canvas può essere bloccato da CSP, e le immagini cross-origin inquinano il canvas così che non può essere esportato. Quei fallimenti vengono riportati onestamente invece di essere nascosti.
• Origine + referrer ti dicono dove sei atterrato, che per il blind XSS è l'intera domanda ("dove si è eseguito il mio payload?").

Per un laboratorio offline, self-hosta html2canvas — vedi public/vendor/README.md.

Sullo scan di rete (leggilo prima di dimostrarlo)

JavaScript non può leggere risposte cross-origin, ma può avviare una richiesta e osservare come fallisce e quanto velocemente, il che rivela lo stato della porta. Il modulo è stato ricostruito attorno a ciò che funziona nei browser attuali (2025–2026), perché il vecchio sweep LAN dell'era BeEF è ora morto.

La realtà moderna: Chrome 142+ (ott 2025) ha introdotto Local Network Access (LNA), che blocca le richieste verso range privati (10.x / 172.16.x / 192.168.x) dietro un prompt di permesso. Uno sweep LAN cieco non raggiunge più il cavo. Ma loopback (127.0.0.1) è ancora raggiungibile, e scansionarlo è l'attacco nel mondo reale — eBay, Best Buy e altri sono stati scoperti a fare port-scan del localhost dei visitatori per identificare servizi locali e strumenti di accesso remoto.

Quindi il modulo ha tre modalità:

• Questa macchina (localhost) — il default affidabile. Uno scan 127.0.0.1 calibrato che sonda ogni porta con fetch-timing e WebSocket-timing, impara prima la baseline RST di questa macchina, poi segnala qualsiasi cosa che si risolve, si blocca o gira più lentamente come APERTA, etichetta il probabile servizio e mostra se fetch, ws o entrambi concordano. Funziona oggi in Chrome e Firefox.
• Host LAN — scansiona un IP privato. Funziona solo se il browser lo lascia passare; Chrome 142+ di solito lo blocca (il modulo lo rileva e lo dice).
• Scopri host LAN — sweep di sottorete. Per lo più bloccato da LNA ora; tenuto per mostrare il blocco come lezione.

Come si mappa a BeEF (per la lezione)

"In cosa è diverso da blind XSS, Evilginx o EvilGoPhish?"

Questi strumenti vivono in fasi diverse dell'attacco e abusano di contesti di fiducia diversi. Sono complementari e si concatenano tra loro.

La distinzione onesta da insegnare: il nostro phish con overlay raccoglie ciò che l'utente digita — non cattura una sessione reale né batte l'MFA. È esattamente il motivo per cui è un grande contrasto, e perché il settore si è mosso verso auth resistente al phishing e legata all'origine (FIDO2 / WebAuthn / passkey). Una kill chain realistica usa tutti e tre: il blind XSS trova e consegna l'esecuzione di codice, un hook WRAITH dà controllo interattivo in-sessione (e, via Page Mirror, raggiunge direttamente le funzionalità dell'app), e un redirect può incanalare la vittima in un flusso Evilginx per una sessione reale con MFA superata.

Configurazione

Tutto è guidato da variabili d'ambiente; la stessa build funziona ovunque perché hook.js deriva il suo URL di callback da dove viene servito. setup.sh le scrive in .env.

Un cookie di sessione HttpOnly firmato copre sia il pannello sia il WebSocket live. Il payload hook, la pagina demo e il canale /ws/hook restano pubblici così che le vittime possano raggiungerli. Come fail-safe, il server rifiuta di legarsi a un'interfaccia pubblica a meno che non sia impostata una password.

Per un deployment bare-metal / systemd invece di Docker, vedi deploy/DEPLOY.md.

File

Licenza e attribuzione

WRAITH è © 2026 Arcanum Information Security, rilasciato sotto la Apache License 2.0.

Sei libero di usarlo, modificarlo e ridistribuirlo — incluso nella tua formazione — ma devi mantenere l'attribuzione: conserva i file LICENSE e NOTICE e l'avviso di copyright Arcanum in qualsiasi cosa distribuisci o fork, e dichiara eventuali modifiche apportate (Apache-2.0 §4). Vedi NOTICE. La licenza non concede l'uso del nome o dei marchi Arcanum oltre alla descrizione della provenienza del codice.

Costruito con ❤️ da Arcanum — https://arcanum-sec.com