When the Link Looked Legitimate Enough
A mid-sized law firm received what appeared to be a DocuSign notification in June 2025. The URL passed every filter in the email gateway, cleared the sandbox, and landed in an inbox. The domain was eleven days old, hosted on a cloud provider with a clean reputation score, and used a valid TLS certificate. The link structure mimicked a legitimate document-sharing pattern well enough that no heuristic fired. A paralegal clicked. The credential harvester loaded in under two seconds. The firm's security team learned about it from the user, not from any alert.
That scenario is not an edge case. It is the standard operating model for modern phishing infrastructure. Understanding why detection failed there, and what would have caught it earlier, is the most practical frame for building phishing URL detection that holds up against current adversary technique.
The Silent Ransom Group, which has been targeting law firms through fake IT support calls in recent reporting, relies on social engineering to bypass technical controls entirely. But URL-based phishing is still the dominant initial access vector across industries, and the detection gap is measurable and closeable if you understand what the toolchain is actually evaluating.
What URL-Based Detection Actually Evaluates
Most commercial email gateways and web proxies evaluate phishing URLs across a few major dimensions: domain reputation, URL structure, redirect chains, page content at detonation, and certificate data. Each of these has blind spots that adversaries have mapped and exploit systematically.
Domain reputation relies on historical observation. A domain registered today with no prior associations carries a neutral score. Adversaries use fresh domains deliberately, sometimes rotating them every 48 to 72 hours to stay ahead of reputation accumulation. Shared hosting platforms with generally good reputations become vehicles because the parent ASN's score doesn't reflect the individual subdomain's behavior until enough reports accumulate.
URL structure analysis looks for suspicious patterns: excessive subdomains, homoglyph characters, URL encoding tricks, and brand name embedding. This catches unsophisticated attacks efficiently. Sophisticated actors avoid these markers entirely, using short, clean paths on plausible-looking domains. A URL like review-documents[.]net/d/4f8a2 contains nothing structurally anomalous.
Sandbox detonation evaluates what actually loads when the URL is visited. This is effective against static redirectors but fails against time-gated payloads, geofenced delivery, and user-agent filtering. A phishing kit that serves benign content to sandbox IP ranges and activates only for residential connections from target geographies will detonate cleanly in every automated analysis environment.
Domain Age and Registration Signals
Domain registration data is among the most reliable early indicators available, but it requires active querying rather than passive reliance on reputation feeds. A domain registered within the past 30 days carrying a TLS certificate from a free authority, with privacy-protected WHOIS and hosting on a major cloud provider, matches the registration fingerprint of the overwhelming majority of phishing domains.
Implementing domain age checks at the proxy layer or in your email security pipeline adds meaningful signal. The implementation looks straightforward: query WHOIS or a passive DNS service at evaluation time and flag or quarantine links pointing to domains under 30 days old. The practical caveat is false positive rate. New legitimate SaaS tools, vendor portals, and marketing campaigns also use fresh domains. Flagging rather than blocking, combined with user warning banners, tends to be operationally sustainable in most environments.
Certificate transparency logs offer a detection opportunity that most teams leave unused. CT logs record every certificate issuance in near real time. Services like crt.sh and commercial feeds built on CT data allow you to monitor for certificate issuance patterns matching your organization's name, brand terms, or executive names. Phishing actors frequently register domains that incorporate target brand strings and immediately provision certificates. Monitoring CT logs gives you visibility into this activity before the phishing campaign launches.
Lookalike Domain Detection at Scale
Lookalike and typosquat domains are a durable technique because generating them is automated and cheap. Tools like dnstwist enumerate permutations of a target domain across multiple mutation categories: character substitution, addition, deletion, homoglyphs, TLD swaps, and combosquatting. Running this against your own primary domains and brand terms on a scheduled basis gives you a discovery mechanism that surface-mounted detection misses.
The workflow for operationalizing this looks like: run dnstwist or an equivalent against your primary domain weekly, pipe results to a feed that checks which of the generated permutations have resolved DNS records, and route any that do into a triage queue. Registered permutations with active DNS are not all malicious, but they warrant investigation. Adding a hosting provider check and a certificate lookup to that triage narrows the signal substantially.
For organizations in sectors that face consistent targeting, like legal, financial services, and healthcare, this kind of proactive enumeration is not optional. The threat actor deploying lookalike infrastructure for a law firm campaign is not going to register a domain that looks obviously wrong. They are going to register something that reads as plausible in peripheral vision under time pressure, which is exactly how phishing works.
Lexical and NLP Analysis of URL Strings
Machine learning models trained on URL strings have improved meaningfully over the past three years, and several commercial platforms have moved from purely heuristic approaches to models that evaluate URL lexical features, entropy, n-gram patterns, and structural anomalies simultaneously. If you are building or tuning detection in-house, understanding what features matter helps you calibrate.
Effective lexical features include: URL length, number of dots and hyphens, presence of IP addresses in the host portion, ratio of digits to letters, number of subdomains, use of URL shorteners, and presence of brand or financial keywords in the subdomain or path. None of these features is individually decisive. Their combination, evaluated against a trained model, produces meaningful discrimination between phishing and legitimate URLs at scale.
A practical example: the URL secure-login.bankofamerica-verify[.]com/account/confirm contains a brand keyword in the domain, a hyphen, and a plausible-seeming path. Individual heuristics might fire or might not depending on threshold tuning. A trained model evaluating the full feature vector will score this much higher than a clean URL with similar structural elements.
The limitation of pure lexical analysis is that it evaluates the URL string, not the destination. A short, clean URL pointing to a redirector that chains through multiple hops before reaching the phishing page scores low on lexical features while representing a real threat. This is why layered detection matters: lexical analysis at email ingestion, combined with redirect chain analysis at proxy, combined with sandbox detonation for high-value users, covers more of the attack surface than any single method.
Redirect Chain Analysis and Link Unshortening
Phishing operators use URL shorteners, redirect chains, and intermediate landing pages for two reasons: they obscure the final destination from scanners that evaluate only the submitted URL, and they allow payload swapping after delivery, changing what the link resolves to after initial scanning is complete.
Redirect chain analysis means following every hop in a URL chain until you reach the terminal destination, then evaluating that destination rather than the submitted URL. Most enterprise proxies support this in some form. The implementation detail that matters is how deep the analysis goes and whether it follows JavaScript-based redirects, which many tools do not. A phishing page that uses a JavaScript redirect as its second hop will pass a scanner that only follows HTTP 30x redirects.
Link unshortening should be implemented at both the email gateway and the proxy layer. Services like those built on top of the urlscan.io API or commercial equivalents provide terminal destination data and page content indicators without requiring live detonation in all cases. The tradeoff is that cached data may be stale on rapidly rotating infrastructure. For high-risk scenarios, live detonation in a clean sandbox environment remains necessary.
Passive DNS and Infrastructure Correlation
Phishing infrastructure tends to cluster. A threat actor running a campaign against financial services will often use the same registrar, the same hosting provider, and the same certificate authority across dozens of domains. If you identify one domain in a campaign, passive DNS correlation frequently surfaces the rest of the infrastructure.
Passive DNS databases record historical resolution data: which IP addresses a domain has resolved to, which domains have resolved to a given IP, and when those associations changed. Commercial services including Farsight DNSDB, RiskIQ PassiveTotal, and several others expose this data via API. When a phishing domain is identified, querying passive DNS for co-hosted domains and then evaluating those domains against your threat intelligence creates a multiplying effect on a single confirmed indicator.
This matters operationally because phishing kits are often deployed in batches. The actor behind the law firm credential harvester from the opening scenario likely had five to ten other domains active simultaneously, hosted on adjacent infrastructure. Blocking only the one confirmed URL leaves exposure on the rest of the campaign's active surface.
The ISC Stormcast and threat intelligence reports from early June 2026 highlight ongoing scanning and probing activity across multiple sectors. Infrastructure correlation is one of the few techniques that lets defenders get ahead of actors rather than simply reacting to each confirmed indicator as it arrives.
Real-Time Threat Feed Integration and Its Limits
Threat intelligence feeds are the most commonly deployed phishing URL detection mechanism and also the most commonly over-relied-upon one. Feeds from providers like URLhaus, PhishTank, OpenPhish, and commercial sources provide blocklists updated at varying intervals. The coverage they provide is real and meaningful for known campaigns, but the detection model they support is fundamentally reactive.
A phishing URL needs to be observed, reported, processed, and published before feed-based detection provides any protection. For mass-distribution campaigns using well-known brand lures, this process can complete in hours. For targeted campaigns against specific organizations, the URL may never appear in any public feed before the intended victims have already been exposed.
The practical recommendation is to treat feed integration as a baseline, not a ceiling. Integrate multiple feeds with deduplication, prioritize feeds that offer higher update frequency over those with larger but staler datasets, and build feed-based detection as one layer in a stack rather than the primary mechanism. Augment with domain age checks, lexical analysis, CT log monitoring, and passive DNS correlation to cover the gap that feeds leave open on fresh infrastructure.
User Reporting as a Detection Signal
Security teams often treat user-reported phishing as a training artifact rather than a detection signal. This is a meaningful gap. Users encounter URLs in contexts that automated systems do not: in messaging platforms, in collaborative documents, in direct messages on social channels, and in voice-to-text transcriptions of phone calls. Silent Ransom Group's use of fake IT support calls demonstrates that phishing delivery has expanded well beyond email, and automated scanning has no coverage over those channels.
Building a low-friction user reporting mechanism and instrumenting it as a real detection source means: deploying a report button in email clients, establishing a response SLA that validates submitted URLs within minutes rather than hours, feeding confirmed reports back into your internal blocklist immediately, and correlating user reports against infrastructure indicators to identify broader campaigns.
Users who report phishing attempts are providing signal that no automated system generated. Treating that signal with the same operational priority as a SIEM alert closes a detection gap that tooling alone cannot address.
Evaluation Frameworks and Testing Your Own Controls
Detection controls age. A filtering rule or model trained on data from 2023 will have degrading accuracy against adversaries who have adapted their technique since then. Testing phishing URL detection controls against current adversary technique is not a one-time exercise.
Practical testing approaches include: running a set of known-malicious phishing URLs from recent campaigns through your email gateway and proxy stack to verify detection rates, submitting test URLs with characteristics of fresh infrastructure to verify that domain age checks fire correctly, and using red team exercises that include targeted phishing with current techniques against specific user populations.
The 2026 World Cup attack surface discussion in recent threat intelligence highlights how major events generate phishing infrastructure at scale in anticipation of high user engagement. Adversaries build fake ticketing sites, merchandise stores, and streaming services months in advance and rotate them through fresh domains to stay ahead of detection. Testing your controls against this pattern before the event, not during it, is the operationally correct posture.
Closing the Gap Between Detection and Response
Detection that doesn't drive action is observability, not security. Phishing URL detection generates value only when confirmed indicators flow into blocking actions, user notifications, and threat intelligence enrichment in near real time.
The response workflow for a confirmed phishing URL should include: immediate domain and IP blocklist update across proxy, email gateway, and DNS filtering layers; identification of any users who accessed the URL before blocking using proxy logs; credential reset or additional authentication requirements for affected users; and passive DNS correlation to identify related infrastructure for preemptive blocking.
Automating the first three steps through SOAR integration reduces the time between detection and remediation from hours to minutes. The passive DNS correlation step benefits from analyst review because automated expansion of indicators without quality control introduces blocklist bloat and potential false positives. The balance between automation speed and analyst validation is an organizational decision that depends on available staff and risk tolerance, but the minimum viable automation for the first three steps is achievable in most environments with existing tooling.
Phishing URL detection is a solvable problem at the operational level, not a theoretical one. The detection gap is real, but it is measurable, the techniques to close it are documented and deployable, and the adversary techniques driving it are consistent enough that defenders who invest in layered analysis rather than single-point solutions hold a durable advantage over actors whose infrastructure characteristics are, regardless of their sophistication, observable.
