연구용 워크스테이션에서 의심스러운 URL을 직접 방문하는 것은 무모한 행동입니다. 악성 랜딩 페이지의 70% 이상이 연결 IP를 핑거프린팅하여 무해한 페이지를 제공하거나 요청을 완전히 차단하기 때문입니다. 프록시 격리는 선택 사항이 아니라 신뢰할 수 있는 위협 인텔리전스 수집의 기본 조건입니다. 이를 갖추지 않으면 인프라의 넷블록을 적에게 넘겨주는 셈이며, 적은 몇 분 안에 내부 서비스를 표적으로 삼을 것입니다.
위협 인텔리전스에 직접 브라우징이 실패하는 이유
최신 익스플로잇 킷과 피싱 킷은 REMOTE_ADDR을 위협 인텔리전스 차단 목록, 지리적 위치 데이터베이스, 역방향 DNS 조회와 대조합니다. 알려진 연구 ASN에서 직접 연결하면 깨끗한 페이지나 404로 리디렉션됩니다. 더 나쁜 점은, 많은 킷이 JavaScript를 사용하여 WebRTC 누출(RFC 8834)을 통해 클라이언트의 로컬 IP를 열거한다는 것입니다. 이는 VPN 뒤에 있더라도 실제 네트워크를 노출시킵니다. 프록시 격리는 인프라의 평판을 공유하지 않는 원격 중개자에서 연결을 종료함으로써 이 체인을 차단합니다. 프록시 자체는 일회용이어야 합니다. 즉, 단일 사용 클라우드 인스턴스 또는 순환 레지덴셜 프록시 풀이어야 합니다. 단일 제공업체의 정적 프록시는 며칠 내에 소진됩니다.
계층형 격리: 프록시 + VM 또는 컨테이너
브라우저가 DNS, 시간 기반 부채널 또는 브라우저 핑거프린팅을 통해 데이터를 유출하는 경우 프록시만으로는 충분하지 않습니다. 프록시를 영구 저장소가 없고, 호스트 파일 시스템 마운트가 없으며, 최소화된 브라우저 프로필을 갖춘 전용 VM 또는 컨테이너와 결합하세요. 컨테이너에서 iptables을 사용하여 모든 이그레스를 프록시를 통해 강제하고 RFC 1918 주소로의 모든 트래픽을 차단하세요. 예를 들어, --network none가 있는 Docker 컨테이너와 ssh -D 1080를 통한 SOCKS5 터널을 일회용 점프 박스로 연결하는 방식입니다. 이렇게 하면 브라우저가 WebSocket 또는 WebRTC를 통해 프록시를 우회하는 것을 방지할 수 있습니다. 이는 브라우저 수준 프록시 설정만 사용할 때 흔히 발생하는 실패 모드입니다. VM 또는 컨테이너는 각 세션 후에 폐기해야 하며, 모든 쿠키, 캐시 및 localStorage를 삭제하는 경우에만 스냅샷을 허용합니다.
도구: 프록시 체인 및 헤드리스 브라우저를 사용한 Burp Suite
수동 분석의 경우, RFC 1928을 User options > Connections > SOCKS Proxy에서 127.0.0.1:1080로 구성하고 Do DNS resolution via SOCKS proxy을 활성화하여 Burp Suite를 SOCKS5 프록시에 체인으로 연결하세요. 이렇게 하면 모든 DNS 조회가 프록시를 통해 강제되어 DNS 누출을 방지합니다. 자동 수집의 경우, Puppeteer 또는 Playwright를 사용한 헤드리스 브라우저 팜이 표준입니다. 아래는 모든 트래픽을 SOCKS5 프록시를 통해 라우팅하고 WebRTC를 비활성화하는 최소한의 Puppeteer 스크립트입니다:
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();이 접근 방식은 작동하지만, 많은 헤드리스 브라우저가 navigator.webdriver 및 누락된 chrome.runtime을 통해 탐지 가능하다는 점에 유의하세요. puppeteer-extra-plugin-stealth 또는 Playwright의 내장 스텔스 패치를 사용하여 핑거프린팅을 줄이세요. 그럼에도 불구하고 정교한 킷은 누락된 window.chrome 속성이나 비정상적인 navigator.plugins 길이를 확인하여 헤드리스 Chrome을 탐지합니다. 유일한 신뢰할 수 있는 대책은 실제 디스플레이 드라이버가 있는 VM에서 전체 브라우저(헤드리스 아님)를 실행하는 것이지만, 이는 확장성이 떨어집니다.
urlscan.io의 대안: 자체 호스팅 분석
urlscan.io는 편리하지만 스캔 메타데이터를 커뮤니티와 공유하고 IP를 기록합니다. 민감한 조사의 경우 캡처 플랫폼을 자체 호스팅하세요. PhantomJS는 사용이 중단되었습니다. Playwright을 사용자 정의 HAR 로거 및 로컬 mitmproxy 인스턴스와 함께 사용하세요. mitmproxy(--mode socks5 --listen-port 8080)은 모든 요청/응답 쌍을 기록하고 헤더 또는 응답을 인라인으로 수정할 수 있습니다. wireshark과 함께 사용하여 PCAP 분석을 수행하세요. 또 다른 옵션은 ThreatPinch Lookup입니다. 이는 로컬 위협 인텔리전스 피드를 쿼리하는 Chrome 확장 프로그램이지만 완전한 격리 솔루션은 아닙니다. 대량 스캔의 경우 PhishingKitTracker 또는 requests을 사용하는 사용자 정의 Python 스크립트를 proxybroker의 순환 프록시 목록과 함께 배포하세요. 절충점: 자체 호스팅 시스템은 프록시 풀과 브라우저 프로필 유지 관리가 필요하지만, 데이터 보존을 완전히 제어하고 조사 대상을 제3자에게 유출하는 것을 방지할 수 있습니다.