Visitare un URL sospetto direttamente dalla propria workstation di ricerca è avventato: oltre il 70% delle pagine di atterraggio malevole effettua il fingerprinting dell'IP di connessione e mostra una pagina benigna o blocca del tutto la richiesta. L'isolamento tramite proxy non è opzionale; è il requisito di base per qualsiasi raccolta credibile di threat intelligence. Senza di esso, stai consegnando il netblock della tua infrastruttura agli avversari, che in pochi minuti passeranno a colpire i tuoi servizi interni.
Perché la navigazione diretta fallisce per la Threat Intel
I moderni exploit kit e phishing kit controllano REMOTE_ADDR rispetto a liste di blocco threat-intel, database geolocalizzazione e persino reverse-DNS lookup. Una connessione diretta da un ASN di ricerca noto attiva un reindirizzamento a una pagina pulita o a un 404. Peggio ancora, molti kit usano JavaScript per enumerare l'IP locale del client tramite perdite WebRTC (RFC 8834) — esponendo la tua vera rete anche dietro una VPN. L'isolamento tramite proxy spezza questa catena terminando la connessione su un intermediario remoto che non condivide la reputazione della tua infrastruttura. Il proxy stesso deve essere usa e getta: un'istanza cloud monouso o un pool di proxy residenziali rotanti. I proxy statici di un singolo fornitore vengono bruciati in pochi giorni.
Isolamento a Strati: Proxy + VM o Container
Un proxy da solo è insufficiente se il browser perde dati tramite DNS, canali laterali basati sul tempo o fingerprinting del browser. Combina il proxy con una VM o un container appositamente costruito, senza storage persistente, senza mount del file system host e con un profilo browser ridotto all'osso. Usa iptables sul container per forzare tutto il traffico in uscita attraverso il proxy e bloccare tutto il traffico verso indirizzi RFC 1918. Ad esempio, un container Docker con --network none e un tunnel SOCKS5 tramite ssh -D 1080 verso un jump box usa e getta. Questo impedisce al browser di bypassare il proxy via WebSocket o WebRTC — una modalità di fallimento comune quando si utilizza solo un'impostazione proxy a livello di browser. La VM o il container dovrebbero essere distrutti dopo ogni sessione; gli snapshot sono accettabili solo se si cancellano tutti i cookie, la cache e localStorage.
Strumenti: Burp Suite con Catena di Proxy e Browser Headless
Per l'analisi manuale, collega Burp Suite a catena attraverso un proxy SOCKS5 (RFC 1928) configurando User options > Connections > SOCKS Proxy su 127.0.0.1:1080 e abilitando Do DNS resolution via SOCKS proxy. Questo forza tutte le query DNS attraverso il proxy, evitando perdite DNS. Per la raccolta automatizzata, i farm di browser headless che utilizzano Puppeteer o Playwright sono lo standard. Di seguito uno script Puppeteer minimale che instrada tutto il traffico attraverso un proxy SOCKS5 e disabilita WebRTC:
const puppeteer = require('puppeteer');
const proxy = 'socks5://127.0.0.1:1080';
const browser = await puppeteer.launch({
args: [
`--proxy-server=${proxy}`,
'--disable-webrtc',
'--no-sandbox',
'--disable-setuid-sandbox'
]
});
const page = await browser.newPage();
await page.authenticate({ username: 'user', password: 'pass' });
await page.goto('http://malicious.example', { waitUntil: 'networkidle0' });
// Capture screenshot, HAR, DOM snapshot
await page.screenshot({ path: 'screenshot.png' });
await browser.close();
Questo approccio funziona, ma attenzione: molti browser headless sono rilevabili tramite navigator.webdriver e l'assenza di chrome.runtime. Usa puppeteer-extra-plugin-stealth o le patch stealth integrate di Playwright per ridurre il fingerprinting. Anche in questo caso, kit sofisticati rilevano Chrome headless controllando l'assenza di proprietà window.chrome o una lunghezza anomala di navigator.plugins. L'unica contromisura affidabile è eseguire un browser completo (non headless) in una VM con un driver di visualizzazione reale — ma questo scala male.
Alternative a urlscan.io per l'Analisi Self-Hosted
urlscan.io è comodo ma condivide i metadati delle tue scansioni con la community e registra il tuo IP. Per indagini sensibili, ospita autonomamente una piattaforma di cattura. PhantomJS è morto; usa Playwright con un logger HAR personalizzato e un'istanza locale di mitmproxy. mitmproxy (--mode socks5 --listen-port 8080) registra tutte le coppie richiesta/risposta e consente la modifica inline di header o risposte. Abbinalo a wireshark per l'analisi PCAP. Un'altra opzione è ThreatPinch Lookup — un'estensione Chrome che interroga feed locali di threat intel — ma non è una soluzione di isolamento completa. Per scansioni di massa, distribuisci PhishingKitTracker o uno script Python personalizzato usando requests con una lista di proxy rotanti da proxybroker. Il compromesso: i sistemi self-hosted richiedono manutenzione di pool di proxy e profili browser, ma ti danno il pieno controllo sulla conservazione dei dati ed evitano di far trapelare i tuoi obiettivi di indagine a terze parti.