DNS traffic can look very different from one network to the next. A hospital system, a retail chain, and a financial services firm all generate wildly different DNS traffic, shaped by different applications and different user behavior. As a result, detection rules that work well in one environment may create noise or miss unusual activity entirely in another.
Why This Matters
Phishing is still one of the most common ways attackers get a foothold, and the domains behind it are cheap to register and quick to discard. A single campaign can stand up thousands of lookalike domains in a day, faster than a list built from reports can keep pace with. During the beta, a campaign on August 10 and 11 took the number of phishing domains our analysis flagged from no more than about 820 a day to more than 6,300 in a single day.
Improved phishing detection here means a sharper focus on the domains that matter to your network: lookalikes of your own brand and vendors, and campaign infrastructure your users are actually reaching for. Instead of sifting an industry wide list for domains that might be relevant, your security team starts with the domains your network really queried. And for customers using Protective DNS, domains identified this way can be stopped at resolution, before a user ever reaches the phishing page.
Public phishing blocklists can only flag domains that have already been reported and confirmed somewhere else. They have no way of knowing which brands or vendors matter to a specific customer, so a domain built to impersonate that customer's own brand, or a vendor unique to their business, can go unnoticed until it has already been used successfully.
Analysis that is scoped to what a customer is actually seeing in their own DNS traffic starts from a far more relevant set of candidate domains, the ones that the network is actually querying, not the full universe of domains reported industry wide.
ThreatSTOP's Security, Intelligence, and Research team is rolling out a new capability that focuses phishing detection on what opted in customers are actually seeing in their own DNS traffic, rather than relying solely on public threat feeds and generic domain data. The detection model itself is shared across customers, trained on general phishing feed data and continuously retrained using false positives and other signal pulled from customer logs. What is customer specific is the candidate set: for opted in customers, the analysis is focused on the domains that customer's own network actually queried, rather than the full universe of domains in the feed.
The analysis considers signals such as:
A single characteristic may not mean much on its own. A combination of them, however, can point to a domain that is likely part of a phishing campaign, including domains impersonating known brands, newly registered lookalike domains, and other patterns associated with credential theft or malicious redirection.
From customer logs to tailored protection
A domain that closely mimics a customer's own brand or a frequently used vendor might not appear on any public blocklist yet. Because analysis for opted in customers is scoped to the domains their own network is actually querying, rather than the full industry wide feed, that kind of impersonation attempt is more likely to surface here than it would from checking against a generic list alone.
We know that sharing network logs is not a decision any organization makes lightly, and it remains entirely optional. Log data used for this program is handled under the same security discipline we apply to our own infrastructure: encrypted in transit and at rest, restricted to the team and systems that need it to scope the analysis and retrain the model, and retained only as long as it serves that purpose. Nothing about opting in changes how your existing protections work, and log data is never shared outside the scope it was collected for.
This capability is currently in beta, and the protection feed built from it is now available to customers who want to test it. A number of customers have already opted in and are sharing log data that our research team uses to retrain and validate the detection model. As with any beta, the feed and the model are still being tuned and trained.
During the first ten days of August, this analysis flagged anywhere from about two dozen to just over 800 unique phishing domains a day across opted in customer traffic. On August 10, that jumped to more than 5,400 unique domains in a single day, and topped 6,300 the day after.
That spike turned out to be a real phishing campaign, not a data or pipeline artifact. Our research team traced it to a cluster of newly registered domains, most on the .top domain extension, following a pattern of randomized prefixes attached to a small number of shared suffixes, along with a batch of domains formatted as raw identifiers rather than readable words. That kind of mass registered, templated domain pattern is a signature of phishing kit infrastructure, not routine traffic or a measurement error. The first of these domains was flagged directly from live, opted in customer DNS query data on August 10, before the campaign showed up anywhere else our team tracks.
Additional customer data gives the research team more real world signal for retraining the model, and expands how many customers get analysis scoped to their own traffic.
Customers interested in testing the protection feed in beta can contact their ThreatSTOP representative for more information.
DNS provides an opportunity to block many malicious connections before they are established. DNS Defense Cloud and DNS Defense can prevent resolution when a request is made for a domain identified as malicious. Depending on the threat, that can prevent an endpoint from reaching phishing infrastructure, retrieving a malicious payload, or establishing a command and control (C2) connection.
DNS Defense Cloud provides protective DNS using ThreatSTOP hosted DNS servers, so customers do not need to deploy additional DNS infrastructure. DNS Defense applies ThreatSTOP intelligence to a customer's existing DNS servers, which may be preferable when DNS infrastructure needs to remain under the customer's control.
ThreatSTOP's threat intelligence can also be applied to IP based security controls. IP Defense manages block lists for routers, firewalls, intrusion prevention systems, and supported cloud security services such as AWS WAF. The same intelligence can also be used with supported A10 Networks deployments and other network enforcement points.
Connect with Customers, Disconnect from Risks.
To learn more about ThreatSTOP's DNS and IP protection, visit our product pages. Pricing scales with organizations of any size, and you can contact us to schedule a demo.
The DNS behaviors and malicious infrastructure identified through this work can be associated with, or help disrupt, several adversary techniques described in the MITRE ATT&CK framework.
|
Tactic |
Technique |
ThreatSTOP Protection |
|
Initial Access (TA0001) |
Phishing (T1566), particularly Spearphishing Link (T1566.002) |
Phishing domain detection scoped to a customer's own DNS traffic, combined with DNS Defense Cloud and DNS Defense, can identify and block resolution of phishing domains, including those impersonating a customer's own brand, before they are widely known. |