Defensive Research

Defensief dreigingsonderzoek: verdachte URL's bezoeken via proxy-isolatie

3 min read Published Updated 654 words

Het rechtstreeks bezoeken van een verdachte URL vanaf je onderzoekswerkstation is roekeloos — meer dan 70% van de kwaadaardige landingspagina's neemt een vingerafdruk van het verbindende IP en toont ofwel een onschuldige pagina of blokkeert het verzoek volledig. Proxy-isolatie is niet optioneel; het is de basis voor elke geloofwaardige verzameling van dreigingsinformatie. Zonder dit geef je de netblock van je infrastructuur aan tegenstanders die binnen enkele minuten overschakelen naar het targeten van je interne diensten.

Waarom direct browsen faalt voor dreigingsinformatie

Moderne exploitkits en phishingkits controleren REMOTE_ADDR tegen dreigingsinformatie-blocklists, geolocatiedatabases en zelfs reverse-DNS-zoekopdrachten. Een directe verbinding vanaf een bekend onderzoeks-ASN leidt tot een redirect naar een schone pagina of een 404. Erger nog, veel kits gebruiken JavaScript om het lokale IP van de client op te sommen via WebRTC-lekken (RFC 8834) — waardoor je echte netwerk wordt blootgesteld, zelfs achter een VPN. Proxy-isolatie doorbreekt deze keten door de verbinding te beëindigen bij een externe tussenpersoon die niet de reputatie van jouw infrastructuur deelt. De proxy zelf moet wegwerpbaar zijn: een eenmalig te gebruiken cloudinstantie of een roterende pool van residentiële proxies. Statische proxies van één enkele provider worden binnen dagen verbrand.

Gelaagde isolatie: proxy + VM of container

Een proxy alleen is onvoldoende als de browser gegevens lekt via DNS, tijdsgebaseerde nevenkanalen of browserfingerprinting. Combineer de proxy met een speciaal gebouwde VM of container die geen permanente opslag heeft, geen host-bestandssysteemmounts en een uitgekleed browserprofiel. Gebruik iptables op de container om alle uitgaande verkeer via de proxy te dwingen en al het verkeer naar RFC 1918-adressen te laten vallen. Bijvoorbeeld een Docker-container met --network none en een SOCKS5-tunnel via ssh -D 1080 naar een wegwerpbare jumpbox. Dit voorkomt dat de browser de proxy omzeilt via WebSocket of WebRTC — een veelvoorkomende foutmodus bij het gebruik van alleen een proxy-instelling op browserniveau. De VM of container moet na elke sessie worden vernietigd; snapshots zijn alleen acceptabel als je alle cookies, cache en localStorage wist.

Tools: Burp Suite met proxyketen en headless browsers

Voor handmatige analyse kun je Burp Suite koppelen via een SOCKS5-proxy (RFC 1928) door User options > Connections > SOCKS Proxy te configureren naar 127.0.0.1:1080 en Do DNS resolution via SOCKS proxy in te schakelen. Dit dwingt alle DNS-zoekopdrachten via de proxy, waardoor DNS-lekken worden vermeden. Voor geautomatiseerde verzameling zijn headless browser farms met Puppeteer of Playwright de standaard. Hieronder staat een minimaal Puppeteer-script dat al het verkeer via een SOCKS5-proxy routeert en WebRTC uitschakelt:

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();

Deze aanpak werkt, maar let op: veel headless browsers zijn detecteerbaar via navigator.webdriver en ontbrekende chrome.runtime. Gebruik puppeteer-extra-plugin-stealth of de ingebouwde stealth-patches van Playwright om fingerprinting te verminderen. Zelfs dan detecteren geavanceerde kits headless Chrome door te controleren op ontbrekende window.chrome-eigenschappen of abnormale navigator.plugins-lengte. De enige betrouwbare tegenmaatregel is het draaien van een volledige browser (niet headless) in een VM met een echte beeldschermdriver — maar dat schaalt slecht.

Alternatieven voor urlscan.io voor zelfgehoste analyse

urlscan.io is handig, maar deelt je scanmetadata met de community en logt je IP. Voor gevoelige onderzoeken kun je beter een zelfgehoste capture-platform gebruiken. PhantomJS is dood; gebruik Playwright met een aangepaste HAR-logger en een lokale mitmproxy-instantie. mitmproxy (--mode socks5 --listen-port 8080) registreert alle request/response-paren en maakt inline wijziging van headers of responses mogelijk. Combineer het met wireshark voor PCAP-analyse. Een andere optie is ThreatPinch Lookup — een Chrome-extensie die lokale dreigingsinformatie-feeds opvraagt — maar het is geen volledige isolatie-oplossing. Voor bulk-scannen kun je PhishingKitTracker inzetten of een aangepast Python-script met requests en een roterende proxylijst van proxybroker. De afweging: zelfgehoste systemen vereisen onderhoud van proxypools en browserprofielen, maar geven je volledige controle over gegevensbewaring en voorkomen dat je onderzoeksdoelen naar derden lekken.