Anatomy of a Phishing URL: How Attackers Weaponize Web Addresses

In 2025, phishing stayed exactly what it has been for two decades: a mass-volume numbers game. APWG tallied roughly 3.8 million phishing attacks across the year, statistically flat against 2024. Interisle’s Phishing Landscape 2025, which analyzed nearly four million reports between May 2024 and April 2025, counted 1.96 million phishing attacks — a 182% jump since 2021 — spread across more than 1.5 million distinct domain names, the highest figure ever recorded. But the number that should reshape how you think about a “phishing URL” is this: Interisle found that 77% of those domains were maliciously registered by criminals rather than compromised from legitimate owners, a 36% year-over-year increase in such registrations, with 37% acquired through bulk registration. Most abusive hostnames aren’t hijacked WordPress blogs. They’re attacker-owned, freshly minted, and disposable — which is precisely why freshness, entropy, and structural heuristics have any hope of catching them.

This post dissects the phishing URL down to its grammar. A URL is not a blob of text; it is a formally defined structure, and every phishing trick is the abuse of one specific grammatical slot. Learn the grammar and you can read a malicious link the way a scanner does — and understand why even a good scanner sometimes loses.

The URL as a Grammar: RFC 3986

RFC 3986 defines the generic URI syntax that browsers, mail clients, and every parser you touch are supposed to follow. Stripped to its spine, the ABNF looks like this:

URI       = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
authority = [ userinfo "@" ] host [ ":" port ]
host      = IP-literal / IPv4address / reg-name

Map that onto a benign link and every component has a job:

  https://www.paypal.com:443/signin?locale=en_US#top
  \___/   \____________/ \_/ \____/ \__________/ \_/
 scheme       host       port  path     query   fragment
              |
              +-- registrable domain (eTLD+1): paypal.com

The single most important idea in this whole article: the browser only grants trust to the registrable domain — the “effective TLD plus one label” (eTLD+1), here paypal.com. Everything else in the authority is where deception hides. The scheme can lie about protocol. The userinfo can impersonate a brand. The subdomains can spell out anything. The path and query can carry a decoy that reads like a real site. RFC 3986 anticipated all of this: Section 7 is titled “Security Considerations,” and Section 7.6 covers “Semantic Attacks,” where a URI is deliberately crafted to mislead a human about its true nature. The rest of this post walks each slot and the abuse that lives there.

Anatomy of the Abuse, Component by Component

The userinfo “@” trick

Consider:

  Looks like:   https://paypal.com@evil.tld/login
  Browser sees: userinfo = "paypal.com"
                host     = "evil.tld"     <-- connects HERE

Per RFC 3986, everything to the left of the last @ in the authority is userinfo — historically a username. The real host is whatever follows. This isn't a bug; it's the spec. And it is definitionally detectable: the @ character is not in the unreserved or sub-delims sets, so it cannot appear as a literal inside a reg-name. If you see an @ in the authority of an http(s) URL, everything before it is, by definition, a delimiter and a potential decoy. RFC 3986 §7.6 says applications should render userinfo distinctly precisely because it may have "been misleadingly crafted to look like a trusted domain name." The HTTP-specific standard goes further: RFC 9110 (HTTP Semantics) states that a recipient of an http/https URI from an untrusted source SHOULD parse for userinfo and treat its presence as an error, since it is likely being used to obscure the authority for the sake of a phishing attack.

The rule of thumb for humans: read the host right to left from the first /, :, or end of string. The true site is the last name before the TLD, and any @ means everything before it is scenery.

This ancient quirk keeps drawing blood in modern code. CVE-2026-27959, a "userinfo host header injection" in the Koa framework, exploits exactly this ambiguity: a syntactically valid authority like evil.com:fake@legitimate.com:3000 smuggles an attacker-controlled hostname past a naive parser that splits on the first colon before it strips the userinfo, so ctx.hostname returns evil.com. And when Google launched the .zip TLD, researchers combined the @ operator with a Unicode slash (∕, U+2215, which is not a path separator) to craft links that visually read like a legitimate GitHub download but resolve to an attacker's .zip domain.

Homoglyphs, IDN homographs, and Punycode

The host itself can be a visual forgery. Internationalized Domain Names (IDNs) let registrants use non-ASCII scripts, but DNS still moves ASCII — so IDNs are stored and transmitted in Punycode, an ASCII encoding marked by the xn-- prefix, and only rendered as Unicode for display. A domain built from Cyrillic lookalikes — аррӏе.com, using Cyrillic а, р, and ӏ — is transmitted as:

  Displayed:    аррӏе.com     (Cyrillic а р р ӏ е)
  On the wire:  xn--80ak6aa92e.com

The detection recipe is concrete:

If any label starts with xn--, decode it back to Unicode.
Map each codepoint through the Unicode UTS #39 confusables table (which maps, e.g., Cyrillic small "а" to Latin "a") to build a normalized skeleton.
If that skeleton matches a known brand's skeleton (e.g., decodes to "apple") but the underlying codepoints aren't plain ASCII, flag it.

This is not theoretical — it is essentially what Chrome ships. Chromium's idn.md documents that Chrome renders a label as raw Punycode (defeating the illusion) when it detects mixed-script confusables, whole-script confusables lacking a matching-script TLD (the Cyrillic аррӏе.com case), or a spoofing skeleton identical to a top domain (the googlé.com case). It applies the UTS #39 "Highly Restrictive" profile with an additional restriction on Latin, and can show a full-page lookalike-URL warning on suspicious navigations.

Typosquatting vs. combosquatting

Two different games get conflated. Typosquatting is misspelling: paypa1.com (digit-for-letter), paypai.com, fat-finger neighbors of the real domain. Combosquatting keeps the brand spelled correctly and bolts on a keyword: paypal-secure-login.tld, account-paypal-verify.tld. The distinction matters for detection because they defeat different heuristics — edit distance catches the first, substring matching the second.

The scale is lopsided. The landmark study here is Kintis et al., "Hiding in Plain Sight: A Longitudinal Study of Combosquatting Abuse" (ACM CCS 2017), which mined more than 468 billion DNS records over almost six years. They found combosquatting roughly 100 times more prevalent than typosquatting — 2.7 million combosquatting domains targeting just 268 popular trademarks — and, alarmingly, nearly 60% survived more than 1,000 days. Combosquatting is durable precisely because the brand is spelled correctly, so trademark-based takedowns are legally muddier.

Excessive subdomains and brand-in-subdomain

Since the browser only trusts the eTLD+1, attackers stuff the brand into a subdomain, where it carries zero authority but plenty of visual reassurance:

  https://paypal.com.secure-login.tld/...
          \________________________/
          registrable domain = secure-login.tld  (NOT paypal.com)

To a hurried reader, "paypal.com" appears first and the eye stops. But the real site is secure-login.tld. This same pattern powers a wave of legit-infrastructure abuse: Azure Blob Storage phishing uses brand-laden subdomains under blob.core.windows.net — office365totalized87.blob.core.windows.net, dropboxmarling951049.blob.core.windows.net — that carry valid Microsoft-issued TLS certificates on a Microsoft-owned domain. More on why that is so effective below.

Cheap, abused, and lookalike TLDs

TLD choice is an economic signal. Interisle found that 51% of abusive registrations were in new gTLDs and 32% in .com/.net, with phishers systematically exploiting domains priced at $2 or less plus free promotions. On a per-capita "phishing score," the spread is dramatic: .xin scored 10,810 versus 1,759 for .bond and just 30 for .com (nearly all .xin phishing traced to a single bulk registrar). Spamhaus maintains an ongoing "World's Worst Top Level Domains" ranking that a scanner can consume as a live reputation feed.

Then there are TLDs that are dangerous by design. Google's .zip and .mov, launched May 2023, collide with ubiquitous file extensions — and because messaging apps auto-linkify any text ending in a valid TLD, a message mentioning update.zip becomes a clickable link to someone's domain. Netskope tracked that within one month of general availability, 18% of the .zip and .mov domains its users visited were distributing malicious content.

IP-literal hosts

A host can skip DNS entirely and be a raw IP: http://192.0.2.50/login/ or a bracketed IPv6 literal. Legitimate consumer-facing brands essentially never send you a bare-IP link, so an IP-literal host in an authority is a cheap, high-signal red flag. It sidesteps domain reputation because there's no domain to reputationally score.

Path, query, redirects, and shorteners

Even with a clean-looking host, the path and query hide two things: entropy and redirection. Kits generate long, high-entropy path tokens and query parameters — victim identifiers, campaign trackers, base64 blobs — that look nothing like the short, human-readable paths of real sites.

Redirection is worse, because it hides the final destination behind a trusted one. Open redirects on reputable domains (job boards, Google services) let an attacker pass ?url=https://evil.tld through a domain the scanner trusts. URL shorteners and security-vendor "link wrapping" stack this into chains: Cloudflare documented attackers abusing Proofpoint and Intermedia link-wrapping combined with Bitly to layer redirects through trusted vendor domains, and Cofense found t.ly to be the most-abused shortener between July 2024 and June 2025, with 28% of campaigns using common shorteners delivering malware such as Pure Logs Stealer. The newest twist is OAuth redirect abuse: Microsoft's security team (March 2026) documented campaigns that manipulate the redirect_uri parameter of legitimate providers like Entra ID and Google Workspace to bounce victims to attacker landing pages, riding entirely on trusted authorization endpoints.

Scheme abuse: data: and javascript:

The scheme slot can also be weaponized. A data: URI can embed an entire phishing page inline (data:text/html;base64,...), and javascript: URIs execute in the current origin. Browsers pushed back specifically on anti-phishing grounds: Mozilla shipped blocking of top-level navigation to data: URLs in Firefox 59 (blocking location.href/assign/replace, window.open, and even 302/meta-refresh redirects to data:), and Edge/IE blocked top-frame data: navigation earlier. javascript: URLs, by contrast, can't be fully blocked without breaking legitimate web functionality, so they remain a live vector.

The Reputation-Killer: Hosting on Legit Infrastructure

Here is the trend that has quietly broken half the heuristics in this article. If an attacker hosts the phishing kit on trusted infrastructure, the host inherits good reputation and a valid TLS certificate for free. There is no suspicious domain to register, no shady TLD, no self-signed cert warning.

The documented list is long and growing: Malwarebytes traced banking scams hidden behind free Cloudflare Pages in December 2025, each served from a legitimate *.pages.dev host with a valid certificate. Firebase's *.web.app, Azure's blob.core.windows.net, IPFS gateways (which Netcraft notes make takedown brutal because content must be purged from every caching node), and ngrok.io tunnels all offer the same deal. Interisle and others have observed that U.S. companies have hosted more than half of all phishing sites for five straight years — not because U.S. firms are careless, but because that's where the cheap, trusted, cert-bearing hosting lives. For a defender, the mental model must shift to: trusted host, untrusted content.

How a Scanner Scores a URL

No single signal wins. A real scanner tokenizes the URL into its RFC 3986 components and runs each through independent heuristics, then sums weighted scores. The core signals:

Punycode decode + confusable skeleton match. Decode any xn-- label, build a UTS #39 skeleton, compare to a brand list. Catches homographs.
Levenshtein (edit) distance to known brands. Splunk's guidance: mycampany.com vs mycompany.com is distance 1; practitioners alert at a threshold of 1-2, because distance > 2 produces heavy false positives. Catches typosquatting.
Shannon entropy of labels and path tokens. Random strings carry more bits per character than human words: google.com sits around 2.65, while a DGA-style c32DyQG9dyYtuB471Db.com is near 4.2. Splunk suggests filtering on entropy > 3, while cautioning that its usefulness drops as strings get longer.
TLD reputation. Score the TLD against Spamhaus / Interisle data.
Structural scoring. Boolean and numeric features: userinfo present? IP-literal host? subdomain depth? brand token in subdomain rather than eTLD+1? known shortener or redirect parameter? high-entropy query token?

Layered academic systems formalize this — PhishMatch (arXiv 2112.02226) combines structural and string-similarity techniques in stages rather than relying on any one metric. And the ecosystem backstop is Google Safe Browsing, which helps protect over five billion devices a day and assesses more than ten billion URLs and files daily; note, though, that Google archived its public Safe Browsing statistics overview on January 30, 2025, so the granular public numbers are now stale.

A worked scoring example

Target URL:

  https://paypal.com@secure-login.paypa1.xin/webscr?cmd=_verify&t=8f3a1c9e7b2d4f60a1

RFC 3986 decomposition:
  scheme    = https
  userinfo  = paypal.com                 <-- everything left of the last '@'
  host      = secure-login.paypa1.xin
  registrable domain (eTLD+1) = paypa1.xin
  path      = /webscr
  query     = cmd=_verify&t=8f3a1c9e7b2d4f60a1

Structural + heuristic score (illustrative weights):
  +40  userinfo present AND looks like a brand host ('paypal.com@')   [RFC 9110 anti-phishing rule]
  +25  Levenshtein('paypa1','paypal') = 1  (digit-for-letter typo)    [Splunk threshold 1-2]
  +20  brand token 'paypal'/'secure-login' in subdomain, not eTLD+1   [combosquat / brand-in-subdomain]
  +20  TLD .xin  (Interisle phishing score 10,810 vs .com 30)         [TLD reputation]
  +10  query token entropy H('8f3a1c9e7b2d4f60a1') ~ 3.8 bits/char >3 [high-entropy tracking token]
   +5  subdomain depth = 2 labels before registrable domain           [structural]
  ----
  120  TOTAL  ->  verdict: BLOCK   (threshold e.g. >= 70 = high risk)

Contrast -- a benign URL scores ~0:
  https://www.paypal.com/signin?locale=en_US
  userinfo = none, eTLD+1 = paypal.com (exact brand match, reputable),
  .com TLD, low-entropy query -> 0 points -> ALLOW.

That crafted URL lights up every heuristic. The problem is the one that doesn't.

Where Detection Breaks

Rehost the exact same phishing kit on trusted infrastructure and the score collapses:

  https://paypal-signin.pages.dev/

  userinfo    = none          -> 0
  typosquat   = none          -> 0   ('pages.dev' is not a brand near-miss)
  host rep    = Cloudflare, valid TLS, good reputation  -> 0
  TLD rep     = .dev is reputable                        -> 0
  entropy     = low                                      -> 0
  structural  = brand token in subdomain 'paypal-signin' -> +20 only
  ----
  ~20 TOTAL  ->  may fall UNDER the block threshold -> ALLOW

This is the central weakness, and it generalizes. Legit-infra hosting nullifies TLD and host reputation — the two heaviest-weighted signals. Short brand names blow up edit-distance false positives (a four-letter brand is within distance 2 of countless innocent domains). Single-script whole-confusables in scripts a scanner doesn't handle can slip the skeleton check, and legitimately high-entropy CDN URLs (hashed asset paths) trigger the entropy signal on benign traffic. On top of that, attackers rotate domains fast, cloak content behind geofencing and user-agent checks so the scanner sees a benign page, and bury the payload at the end of a multi-hop redirect chain. And the public Safe Browsing statistics that used to let defenders benchmark the ecosystem went dark in January 2025.

The one delivery channel worth flagging separately is the QR code, or "quishing," which sidesteps URL scanning at the email gateway entirely by hiding the link in an image. Vendors including Mimecast report quishing rising sharply through 2024-2025, with hundreds of thousands of unique malicious QR codes observed per quarter — a reminder that the URL still has to be evaluated, just later, after the phone camera decodes it.

No single heuristic is a detector; it is a vote. Robust defense is layered scoring plus honest user-facing rendering — distinct userinfo, Punycode display of confusables, and full-page lookalike warnings — so that when the score is ambiguous, the human still gets the truth.

// try it live

Paste any suspicious link and watch it get decomposed into RFC 3986 components and scored against every heuristic in this article — userinfo, Punycode, edit distance, entropy, and TLD reputation.

URL SCANNER →

Defender Playbook: Reading a URL Like a Scanner

Turn the theory into muscle memory. Whenever a link matters, do this by eye before you click:

Read the host right to left. Find the first / after the scheme, then walk backward. The registrable domain is the last name plus its TLD. That, and only that, is who you're talking to.
Distrust any @ in the authority. Everything before the last @ is a decoy by definition. Real sites don't need it.
Check for xn--. A Punycode label in a brand context is guilty until decoded.
Treat trusted PaaS hosts as "trusted host, untrusted content." *.pages.dev, *.web.app, *.blob.core.windows.net, IPFS gateways, and *.ngrok.io prove nothing about the page's intent — evaluate the content, not the cert.

Key Takeaways

A URL is a formal grammar (RFC 3986). Every phishing trick abuses one slot — userinfo, host, subdomain, TLD, path, query, or scheme — so learn the grammar and you can read the attack.
Trust attaches only to the registrable domain (eTLD+1). Brand names in userinfo or subdomains carry zero authority; read the host right to left and treat any @ as a decoy delimiter.
Most phishing domains (77%, per Interisle) are attacker-registered and fresh, which is why freshness, entropy, edit distance, and TLD reputation work at all.
Detection is layered scoring, not a single test: Punycode/confusable skeletons, Levenshtein distance (threshold 1-2), Shannon entropy (>3), TLD reputation, and structural features — each a weighted vote, not a verdict.
Hosting on legit infrastructure (Cloudflare Pages, Firebase, Azure Blob, IPFS, ngrok) is the dominant 2025-26 evasion: valid TLS plus a trusted host neutralizes the two strongest reputation heuristics.
Heuristics have hard limits — short brands, non-Latin confusables, high-entropy CDNs, cloaking, redirect chains, and quishing — so pair automated scoring with user-facing rendering that surfaces the truth to the human.

References

« Anatomy of a Ransomware Attack:… Static Malware Triage: Reading a… »