Drive-by download attack chains, URL deception techniques, exploit kits, and safe investigation tools — how to analyse a suspicious URL without visiting it.
Sign in to mark this article as read and track your progress.
Web browsers parse HTML, execute JavaScript, render CSS, handle plugins, and make network requests. Each of these capabilities is an attack surface. Initial compromise in modern intrusions frequently begins not with an executable dropped to disk, but with a user visiting a URL that delivers malicious content through the browser.
A drive-by download attack requires no user interaction beyond visiting a URL.
1. Victim visits a legitimate site that has been compromised
(attacker injected a hidden <iframe> via stolen FTP credentials
or a vulnerable CMS plugin)
2. Browser silently loads iframe content from the exploit kit (EK) server
3. EK fingerprints:
- Browser version and installed plugins
- OS version and patch level
- Language and timezone
4. If a matching exploit exists:
- EK delivers payload (dropper or RAT)
- Payload executes without user interaction
Why hidden iframes? The <iframe> tag embeds another page inside the current one. Setting dimensions to 0x0 pixels makes it invisible. The victim sees only the legitimate site while their browser silently loads the exploit kit.
An exploit kit is a server-side framework that automates exploitation. Notable examples include Angler, RIG, and Magnitude. Each maintains an arsenal of browser and plugin exploits, serves the appropriate one based on fingerprinting, and tracks infection statistics.
Exploit kit activity has declined since Flash and Java were deprecated — the major plugin attack surfaces are gone. However, browser-native JavaScript exploits continue.
Attackers craft deceptive URLs to trick users into visiting malicious infrastructure.
| Technique | Mechanism | Detection |
|---|---|---|
| Typosquatting | Registers domains with minor spelling differences: gogle.com, amaz0n.com | Character-by-character comparison; check WHOIS registration date |
| Homograph (IDN) | Substitutes Latin characters with visually identical Cyrillic or Greek characters | Browser shows Punycode (xn--...); any xn-- URL is suspicious |
| Subdomain abuse | login.microsoft.com.evil.com looks legitimate at a glance | Read domain right-to-left — actual domain is evil.com |
| Redirection chains | 3–5 HTTP 301/302 hops via Traffic Distribution System (TDS) routing by geo/OS/browser | curl -Lv or URLScan.io to follow full chain |
| URL shorteners | bit.ly, tinyurl.com hide true destination | Append + to bit.ly URL to preview; use urlscan.io |
Rule: Always read URLs from right to left. The actual domain is immediately before the first single slash. In
https://secure.bank.com.attacker.net/login, the domain isattacker.net, notbank.com.
Never visit a suspicious URL directly on your workstation. Use these tools to investigate remotely:
| Tool | Capability |
|---|---|
| urlscan.io | Sandboxed browser loads URL; captures screenshot, HTTP transactions, contacted domains/IPs, JavaScript behaviour |
| Any.Run | Interactive cloud sandbox; watch page load in real time; observe dropped files and spawned processes |
| VirusTotal (URL scan) | Submits URL to 70+ scanning engines; aggregates verdicts |
| WHOIS lookup | Check domain registration date; a domain registered yesterday claiming to be a bank is suspicious |
curl -Lv | Follow redirect chain from command line without rendering the page |
1. Check WHOIS: domain registered within last 30 days?
2. Run through urlscan.io: any redirects to unexpected domains?
3. Check VirusTotal URL scan: any engines flag it?
4. Examine URL structure: xn-- prefix? Subdomain impersonation?
5. If shortlink: expand before any further analysis
A TDS sits between the attacker and the exploit kit, routing victims based on:
TDS-based filtering is why sandbox analysis sometimes shows a clean result for a URL that is actively malicious — if the sandbox IP is in the wrong country or uses the wrong User-Agent, the TDS routes it away from the exploit kit.
Bypass: use urlscan.io with a US or EU IP, set a realistic browser User-Agent, and replay the request multiple times. Real TDS routing varies.
1. Full redirect chain (all hops from initial URL to final destination)
2. Final domain and IP address (C2 or payload hosting)
3. WHOIS registration date and registrar
4. Certificate details (self-signed? mismatched domain?)
5. HTTP headers (Server, X-Powered-By — may reveal infrastructure)
6. JavaScript behaviour observed in sandbox
7. Any files downloaded or processes spawned
Each item becomes an IOC in the incident report.