Recherche défensive de menaces : visiter des URL suspectes via l'isolation par proxy

Visiter une URL suspecte directement depuis votre poste de recherche est imprudent — plus de 70 % des pages d’atterrissage malveillantes identifient l’IP de connexion et soit affichent une page bénigne, soit bloquent complètement la requête. L’isolation par proxy n’est pas optionnelle ; c’est le socle de toute collecte crédible de renseignements sur les menaces. Sans elle, vous livrez le bloc réseau de votre infrastructure à des adversaires qui se tourneront vers vos services internes en quelques minutes.

Pourquoi la navigation directe échoue pour le renseignement sur les menaces

Les kits d’exploitation et de phishing modernes vérifient REMOTE_ADDR par rapport aux listes noires de renseignement sur les menaces, aux bases de données géolocalisées, et même aux recherches DNS inversées. Une connexion directe depuis un ASN de recherche connu déclenche une redirection vers une page propre ou une 404. Pire encore, de nombreux kits utilisent JavaScript pour énumérer l’IP locale du client via les fuites WebRTC (RFC 8834) — exposant votre véritable réseau même derrière un VPN. L’isolation par proxy brise cette chaîne en terminant la connexion sur un intermédiaire distant qui ne partage pas la réputation de votre infrastructure. Le proxy lui-même doit être jetable : une instance cloud à usage unique ou un pool de proxies résidentiels rotatifs. Les proxies statiques d’un seul fournisseur sont brûlés en quelques jours.

Isolation en couches : Proxy + VM ou conteneur

Un proxy seul est insuffisant si le navigateur fuit des données via DNS, des canaux latéraux temporels ou l’empreinte numérique du navigateur. Combinez le proxy avec une VM ou un conteneur dédié, sans stockage persistant, sans montage du système de fichiers hôte, et avec un profil de navigateur allégé. Utilisez iptables sur le conteneur pour forcer tout le trafic sortant via le proxy et abandonner tout le trafic vers les adresses RFC 1918. Par exemple, un conteneur Docker avec --network none et un tunnel SOCKS5 via ssh -D 1080 vers une boîte de rebond jetable. Cela empêche le navigateur de contourner le proxy via WebSocket ou WebRTC — un mode de défaillance courant lorsqu’on utilise uniquement un réglage de proxy au niveau du navigateur. La VM ou le conteneur doit être détruit après chaque session ; les instantanés ne sont acceptables que si vous nettoyez tous les cookies, le cache et le localStorage.

Outils : Burp Suite avec chaîne de proxy et navigateurs sans tête

Pour l’analyse manuelle, chaînez Burp Suite via un proxy SOCKS5 (RFC 1928) en configurant User options > Connections > SOCKS Proxy sur 127.0.0.1:1080 et en activant Do DNS resolution via SOCKS proxy. Cela force toutes les requêtes DNS via le proxy, évitant les fuites DNS. Pour la collecte automatisée, les fermes de navigateurs sans tête utilisant Puppeteer ou Playwright sont la norme. Voici un script Puppeteer minimal qui achemine tout le trafic via un proxy SOCKS5 et désactive 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();

Cette approche fonctionne, mais attention : de nombreux navigateurs sans tête sont détectables via navigator.webdriver et l’absence de chrome.runtime. Utilisez puppeteer-extra-plugin-stealth ou les correctifs furtifs intégrés de Playwright pour réduire l’empreinte numérique. Même ainsi, les kits sophistiqués détectent Chrome sans tête en vérifiant l’absence de propriétés window.chrome ou une longueur anormale de navigator.plugins. La seule contre-mesure fiable est d’exécuter un navigateur complet (pas sans tête) dans une VM avec un véritable pilote d’affichage — mais cela passe mal à l’échelle.

Alternatives à urlscan.io pour une analyse auto-hébergée

urlscan.io est pratique mais partage les métadonnées de vos scans avec sa communauté et enregistre votre IP. Pour les investigations sensibles, auto-hébergez une plateforme de capture. PhantomJS est mort ; utilisez Playwright avec un enregistreur HAR personnalisé et une instance locale de mitmproxy. mitmproxy (--mode socks5 --listen-port 8080) enregistre toutes les paires requête/réponse et permet la modification en ligne des en-têtes ou des réponses. Associez-le à wireshark pour l’analyse PCAP. Une autre option est ThreatPinch Lookup — une extension Chrome qui interroge les flux locaux de renseignement sur les menaces — mais ce n’est pas une solution d’isolation complète. Pour l’analyse en masse, déployez PhishingKitTracker ou un script Python personnalisé utilisant requests avec une liste de proxies rotatifs provenant de proxybroker. Le compromis : les systèmes auto-hébergés nécessitent la maintenance des pools de proxies et des profils de navigateurs, mais ils vous donnent un contrôle total sur la conservation des données et évitent de divulguer vos cibles d’investigation à des tiers.