The Link That Passed Every Filter
A regional logistics company received a wave of emails purportedly from their freight partner. The links inside pointed to a domain registered 11 days prior, hosted on a shared cloud IP with a valid TLS certificate and a URL path that mimicked the partner's internal portal structure. The secure email gateway scored it clean. The proxy logged it as uncategorized. A warehouse coordinator clicked it, entered credentials, and within 40 minutes an attacker had authenticated into the company's freight management system from a residential proxy exit node in Eastern Europe.
The URL was never flagged because no single layer of detection owned the full picture. The domain was new but not blocklisted. The certificate was legitimate. The path structure looked plausible. Each detection control evaluated one slice of the signal and returned a verdict of pass. This is the operational problem that phishing URL detection has to solve in 2026, and solving it requires understanding what your pipeline actually sees and how to sequence that analysis so the slices add up to something actionable.
Why Phishing URLs Are Harder to Catch Than They Were Three Years Ago
The threat landscape has shifted considerably. Attackers now operate with industrialized tooling, using automation to generate large volumes of plausible-looking domains, abuse legitimate hosting infrastructure, and cycle through URLs fast enough to outpace blocklist propagation. The July 2026 CVE landscape has included multiple vulnerabilities in URL parsing libraries and email gateway components, which means the inspection tools themselves carry risk. Meanwhile, ransomware groups increasingly use phishing as the initial access vector, making URL detection a first-line control against campaigns that eventually become much larger incidents.
Phishing infrastructure has also moved toward blending with legitimate services. Attackers host credential harvesting pages on SharePoint, Google Sites, and AWS S3 buckets. They use URL shorteners, redirect chains through trusted domains, and QR codes that bypass text-based URL scanning entirely. Detection approaches built around simple domain reputation or keyword matching are systematically outpaced by these techniques.
Decomposing a Phishing URL Into Detectable Components
Effective detection starts by treating the URL as a structured artifact with multiple independent signals, not a single string to match against a list. Each component of a URL carries information that can feed detection logic.
Domain Age and Registration Signals
Phishing domains are overwhelmingly new. Attackers register domains shortly before campaigns launch to avoid pre-campaign detection. A domain registered within the last 30 days deserves elevated scrutiny regardless of other signals. WHOIS data provides registration dates, but many registrars now redact ownership information under privacy policies, so the registration date is often the most reliable field available.
Beyond raw age, look at the registrar. Certain registrars are disproportionately represented in phishing infrastructure because they offer low-cost bulk registration, minimal identity verification, and fast provisioning. Building a lightweight scoring model that weights registrar reputation alongside domain age gives detection logic a stronger signal than age alone.
Lexical Analysis of the Domain Name
Phishing domains frequently use typosquatting, homoglyph substitution, and brand-name insertion to appear legitimate. Lexical analysis examines the domain string itself for these patterns. Common techniques include computing edit distance between the observed domain and known brand domains, flagging domains that contain brand names as substrings (paypal-secure-login[.]com), detecting homoglyph substitution where characters like the Cyrillic letter 'а' replace the Latin 'a', and identifying excessive hyphenation or numeric padding in domain names.
Entropy scoring is useful here. Legitimate domains tend to have lower character entropy than algorithmically generated or deliberately obfuscated ones. A domain like xn--pple-43d[.]com has a very different entropy profile from apple[.]com, and that difference is computable at scale.
URL Path and Query String Patterns
The path structure of a phishing URL often mimics the target organization's legitimate URL patterns while appending tracking parameters, encoded user identifiers, or redirect tokens. Analyzing path depth, the presence of base64-encoded strings in query parameters, and the use of redirect parameters (url=, redirect=, continue=, next=) provides additional signal. Redirect parameters in particular are worth flagging aggressively because they are used in open redirect abuse, where a trusted domain's redirect functionality is exploited to forward victims through a legitimate domain before landing on the phishing page.
TLS Certificate Intelligence
A valid TLS certificate is no longer an indicator of trustworthiness. Attackers obtain free certificates from Let's Encrypt for phishing domains routinely. Certificate transparency logs, however, are a useful detection source. CT logs record every publicly trusted certificate issued, and monitoring them for certificates issued to domains that match your brand, your organization's name, or your key executives' names provides early warning before phishing campaigns go live. Tools like CertStream provide a real-time feed of CT log entries that security teams can filter against a watchlist of protected terms.
Certificate metadata can also reveal patterns. A certificate issued to a domain within hours of its registration, covering a wildcard with no organizational validation, is structurally different from a certificate covering a domain operated by a known legitimate organization, even if both are technically valid.
Building a Layered Detection Pipeline
No single signal catches every phishing URL. The operational approach that holds up against sophisticated campaigns is a layered pipeline that aggregates multiple weak signals into a composite score, with hard blocks at known-bad indicators and escalation to sandbox analysis for borderline cases.
Layer One: Reputation Feeds and Blocklists
Reputation feeds remain a necessary first layer despite their known latency problem. The goal at this layer is to catch known-bad infrastructure quickly, not to catch novel phishing. Operationally, this means integrating multiple feeds (commercial threat intelligence, open-source feeds like PhishTank and OpenPhish, ISAC sharing), deduplicating, and applying them at the DNS resolver level, the proxy, and the email gateway. Running a single feed creates gaps that attackers have often already mapped.
The latency problem is real. A phishing domain may be active for 48 to 72 hours before it appears in widely distributed blocklists. During that window, users are unprotected by reputation-only controls. This is why reputation feeds must be one layer, with additional detection logic covering the gap.
Layer Two: Real-Time DNS and IP Analysis
When a URL is observed, DNS resolution provides the hosting IP, and that IP carries its own signals. Check the IP against reputation data, but also examine the autonomous system it belongs to. Phishing campaigns frequently use hosting providers known for permissive abuse handling. An IP belonging to a bulletproof hosting ASN is a strong signal regardless of whether the specific IP has been blocklisted.
Passive DNS data shows how the domain's resolution history looks. A domain that resolved to dozens of different IPs in its first week of existence is exhibiting a pattern consistent with fast-flux infrastructure used to evade blocklists. A domain that has never been queried before the current moment has no resolution history at all, which is itself a signal worth weighting.
Layer Three: Dynamic Analysis and Sandboxing
URLs that pass the first two layers but score above a risk threshold should be submitted to a URL sandboxing system. Sandboxes render the page in an isolated browser environment, capture network traffic, DOM content, form fields, credential capture mechanisms, and redirect chains. This layer catches phishing pages hosted on otherwise clean infrastructure, redirect chains that pass through legitimate domains, and content that only renders malicious behavior under specific conditions (user-agent matching, geolocation checks, time-of-day gating).
Sandboxing is resource-intensive, which is why it belongs at layer three rather than being applied to all URLs. The scoring from layers one and two determines what gets escalated here. Tune the threshold based on your organization's risk tolerance and the volume of URLs your infrastructure processes.
Layer Four: Machine Learning Classification
ML models trained on phishing URL datasets provide a complementary signal that catches patterns too subtle for rule-based systems. Features used in effective phishing URL classifiers include lexical features (domain length, character entropy, TLD type, presence of IP addresses in the URL), structural features (redirect depth, number of subdomains, query string length), content features from rendered page analysis (presence of login forms, brand logos, mismatched page title versus domain), and behavioral features (page requests credentials while having no historical traffic, domain was registered recently).
AI-augmented threat intelligence has expanded the capacity to train and update these models at scale, with recent analysis showing that ML classifiers retrained on fresh phishing data outperform static rule sets within days of a new campaign pattern emerging. The challenge is keeping training data current and ensuring the model is evaluated on adversarially crafted examples, not just historical phishing samples.
Deployment Points: Where to Apply Detection Controls
Detection logic needs to run at multiple points in the user's path to a phishing URL. Applying it only at the email gateway misses URLs delivered through SMS, QR codes, collaboration platforms, and web advertising. Applying it only at the proxy misses email clients that open links without routing through the corporate proxy.
Email Gateway Integration
At the email gateway, URL rewriting is the standard approach. Every URL in an inbound message is rewritten to pass through a scanning proxy. When the user clicks, the proxy resolves the original URL, runs detection logic at that moment (not at delivery time), and either blocks or forwards. Time-of-click analysis catches URLs that were benign at delivery and turned malicious after the email was in the inbox, a technique called delayed activation that attackers use specifically to evade gateway scanning.
DNS Filtering
DNS filtering blocks resolution of phishing domains at the resolver level. This works for all traffic regardless of delivery mechanism. Recursive resolvers that apply reputation filtering catch phishing domains even when URLs arrive through channels the email gateway never sees. DNS filtering is also fast and low-overhead compared to full content inspection. The limitation is that DNS filtering operates on domain-level signals and cannot inspect path or query string content.
Browser-Based Controls
Browser extensions and enterprise browser policies provide a detection layer closest to the user. Google Safe Browsing, Microsoft SmartScreen, and enterprise security products that offer browser integration apply detection logic at the moment the page loads. This catches URLs that were missed at every prior layer. The operational value is catching late-stage phishing when other controls have failed, but browser-level detection is also the layer most exposed to user bypass.
Monitoring Certificate Transparency for Early Warning
One of the highest-value proactive controls available to security teams is continuous monitoring of CT logs for domains that impersonate your organization. The workflow is straightforward: define a list of protected terms (organization name, key product names, executive names, key domains), subscribe to a CT log feed, filter for certificates issued to domains containing those terms, and route alerts to a team that can assess whether the domain is legitimate or phishing infrastructure being staged.
This approach frequently surfaces phishing domains before the campaign launches. A domain registered and certified on a Monday may not be used in a phishing campaign until Wednesday. The two-day window is enough to submit the domain to threat intelligence sharing platforms, request blocklist inclusion, and notify brand protection teams. For organizations in sectors currently being targeted by cyber-espionage campaigns similar to the OctLurk and SilkLurk backdoor operations seen in Central Asia, early warning through CT monitoring may be the difference between detecting infrastructure staging and responding to a breach.
Handling Redirect Chains and URL Shorteners
Redirect chains are one of the more effective attacker techniques for bypassing URL reputation checks. The URL in the email points to a legitimate or uncategorized domain, which redirects through one or more intermediate domains, ultimately landing on the phishing page. Simple blocklist lookups against the first URL miss the destination entirely.
Detection logic needs to follow redirect chains at scan time, resolving each hop and applying scoring to every URL in the chain. Set a maximum hop count (five is a reasonable default) and treat chains that exceed it as suspicious. Log the full redirect chain, not just the initial URL and final destination, because intermediate domains are often reused across campaigns and become valuable IOCs.
URL shortener abuse requires a similar approach. Unshorten every shortened URL before analysis. Many URL shorteners provide preview APIs that return the destination without following the redirect, which speeds analysis. Treat any URL that passes through a shortener as requiring elevated scrutiny because legitimate enterprise communications rarely use URL shorteners for sensitive links.
Incident Response Integration
When a phishing URL is detected, the response workflow needs to move quickly on several fronts simultaneously. Identifying who received and who clicked the URL determines scope. Pulling proxy and DNS logs for the phishing domain surfaces users who may have been missed by email gateway detection. Resetting credentials for any user who clicked is the immediate protective action. Reviewing authentication logs for the minutes following any click identifies whether credentials were used before the reset was completed.
Document the full phishing infrastructure: the initial domain, all redirect chain domains, the hosting IPs, the certificate details, and the email sender infrastructure. Submit IOCs to your threat intelligence sharing community. Attackers frequently reuse infrastructure across multiple campaigns targeting different organizations in the same sector, so sharing quickly amplifies the value of your investigation into a defensive signal for others.
Measuring Detection Effectiveness
Security teams should track specific metrics to understand how well their URL detection pipeline performs over time. False negative rate requires periodic testing using phishing simulation platforms that send known-safe simulated phishing URLs through your production detection stack to verify they are caught. Dwell time from URL delivery to detection measures how long phishing URLs are active in user environments before the pipeline catches them. Coverage across delivery channels identifies gaps where URLs arrive through channels not covered by current detection logic.
Review these metrics quarterly and after any phishing incident that reached a user. Each incident is a data point showing where the pipeline had a gap, and iterating on that data improves detection over time in a way that no static configuration achieves.
What Security Teams Should Prioritize in the Near Term
Given current threat trends, including the rise in ransomware campaigns using phishing as initial access, the continued abuse of legitimate hosting infrastructure, and the increasing sophistication of credential-targeting operations, the highest-impact investments for phishing URL detection are time-of-click analysis in email gateways, CT log monitoring for brand impersonation, redirect chain following in URL scanners, and ML-based classifiers retrained regularly on current phishing data.
Organizations should also audit their detection coverage across delivery channels. Email is the most monitored channel, but phishing via SMS, collaboration platforms, and QR codes is growing and often reaches users with no detection layer between the link and the browser. Closing those coverage gaps is a structural improvement that holds value regardless of which specific phishing campaign is active at any given time.
