<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2180921&amp;fmt=gif">

Incorporating Newly-Registered Domains into Stamus Security Platform Workflow

Every day, new Internet domains are registered through the Domain Name System (DNS) as a natural expansion of the Internet for legitimate purposes. However, it's important to note that not all these domains are used with good intentions. Some individuals with malicious intent can exploit freshly created domains for criminal activities like phishing, spam, distributing malware, or setting up botnets within mere minutes of their registration.

Enterprise security teams need updated intelligence on these new domains to promptly identify their usage within the organization and prevent potential threats from causing damage. However, security analysts currently lack an efficient method to collect and analyze this information promptly since it is dispersed across various domain registrars worldwide. As a result, there is a need for a streamlined source of this threat intelligence.

In this blog, we introduce several new threat intelligence feeds from Stamus Networks that can help users of the Stamus Security Platform (SSP) quickly spot malicious activity related to these newly registered domains.

If you already know about newly registered domains, you can click HERE to skip right to the section that explains how to enable these new threat intelligence feeds in SSP

What is a Newly Registered Domain (NRD)? 

It is actually straightforward. An NRD is a domain that was recently registered - for example within the last day, week, or month. Being newly registered does not indicate - by itself - that they are good or bad. It is just a piece of information that can be used to spawn further analysis, generate an automated escalation, or be included in a hunting formula. Believe it or not, each day there may be anywhere between 100,000 and 400,000 new domain registrations. So if we are to consider the last 30 days, the list could be 10 million or more.  

Domains are used in nearly all communication transactions. Most of us understand that domains will appear in DNS queries when a client needs to map a hostname to an IP address. But domains are also used in HTTP and TLS protocols where they appear, for example, in TLS Server Name Indication (SNI) or in  HTTP hostnames or the HTTP referrer among other things. As you can see, domains can therefore be observed on the network in many transactions.

Why newly registered domains matter

Malware actors often register domains “en masse.” They then deploy them temporarily for command-and-control (or C2) communication. As these are new, unanalysed, and not previously seen domains - it is very difficult (impossible) for defending blue teams to block the communication in advance. 

The reason malware actors frequently register new domains is because these temporary ‘burner’ domains represent a moving target and are difficult to defend against. The use of Domain Generation Algorithms (DGAs) allows attackers to be really dynamic. Now,  some of the algorithms can be spotted with clever detection techniques. Although, this is certainly not always the case.

Those freshly-registered domains may also be used in conjunction with subdomain variations, making it even more difficult to form an exact match. 

For example:

Ijnkwnkxeguxaxmldwyogggwfk[ .]sbs
pfktaacgojiozfehwkkimhkbkm[ .]cfd

cteasc.ijnkwnkxeguxaxmldwyogggwfk[ .]sbs
ahaaer.pfktaacgojiozfehwkkimhkbkm[ .]cfd 

So, knowing if and when these suspicious domains are being used in your organization’s network communications could indicate a threat actor has infiltrated your network or is actively attempting to do so.

NRD lists from Stamus Labs

When evaluating new domain registrations, some domains immediately appear suspicious, some are automatically generated (Domain generation algorithms, DGAs), some are simply too long and random to manually type in, and – of course – some are perfectly legitimate.

With U39, Stamus Networks made available six domain-related threat intelligence feeds to all Stamus Security Platform (SSP) users. 

By subscribing to these threat intelligence feeds, SSP users will increase their visibility into potential threats and increase the body of evidence available when performing an incident investigation. 

Stamus Labs runs hourly and daily routines with multiple providers to harvest newly-registered domains (NRD). Using multiple methods and checks, including machine learning, entropy analysis and other algorithms, Stamus Labs creates two major list batches: for domains that were registered within the past 14 days and those registered within the past 30 days.

Each batch is further organized into:

  • All NRDs: A complete list of newly-registered domains
  • High Entropy NRDs: Newly-registered domains exhibiting high entropy, including those created by domain generation algorithms (DGAs). 
  • Phishing NRDs: Newly-registered domains that mimic popular domains, highly likely to be used in phishing campaigns

So, this creates a total of 6 suspicious domain sources/lists. Allow me to further explain how we got to six:

If your SSP detects DNS, TLS or HTTP communications containing a domain on the High Entropy NRDs or Phishing NRDs list, you would naturally want to immediately investigate and check it out.

The All NRDs list provides hunting information that could be interesting due to the novelty of the domain - if, for example, we have a download from a NRD.

Those 3 main sources each have 2 time range variations - 14 and 30 days. For example, domains with high entropy are organized into 2 lists : a list that contains domains registered in the past 14 days and a list that contains domains registered in the last 30 days.

These are each run through a rigorous QA process and global live traffic sensor testing before we release them.

With these feeds installed, Security teams can use SSP to easily identify when these domains are being accessed by their organization and quickly determine if they pose a threat.

How you can use this threat intelligence

At Stamus Networks we believe that complete coverage can only be achieved from a combination of detection methods, not just one type. The examples below are quite revealing by themselves, however the Stamus Security Platform provides other detection logic as demonstrated below with inclusion of organizational context and Stamus Sightings™ (first time seen) indicators and artifacts like network protocol logs, file transfers, transactions and extraction, flow records and packet capture (PCAP).

Below, we describe a few example use cases based on TLS and HTTP detection of newly registered domains with entropy.

Suspicious Domains in TLS Server Name Indication

A TLS Server Name Indication can include a newly registered DGA domain, domain with high entropy, or also a newly registered phishing domain. From an enterprise security monitoring perspective , we would definitely like to know when and where such communication is triggered especially if it is from or to critical infrastructure or coming from end users/clients devices.

Below is one such example of a NRD with higher entropy that was used in a TLS encrypted communication: 

Some more information about the TLS communication including some encryption analysys like Cipher Security, Cipher Suite, JA3/JA3S hashes and others if present.

This domain was apparently registered just 19 days ago (as of the moment of this writing) and has already been flagged by researchers in Virustotal (accessible via a simple click while hovering over the name in Hunt and selecting External info):

Any domain in general, regardless if it is NRD or not can be checked via a simple click from the FQDN helper break down section of the Stamus Hunt/Evidence interface, like on the screenshot below: 

or in it’s respective application layer protocol section:

Suspicious Domains in HTTP Transactions

In another example, a clear text (HTTP) communication to a newly registered domain with higher entropy in the HTTP hostname.

In this case the domain was registered 21 days ago and already flagged as malicious in Virustotal by multiple security researchers.   

Suspicious Domains in DNS

NOTE: The NRD communication is identified and highlighted for all subdomain variations.

How big are the lists and what is the impact on performance?

Because it is based on real-world registration activity, the list size varies. For example, the total list size of a recently published list can be seen in the screenshot below. In this case, we have nearly 8.2 million entries in total.

We have performed extensive testing with the complete lists loaded on  Stamus Network Probe appliances. And regardless of size (from 100Mbps to  40Gbps + installations) there was minimal performance impact. This is due to the efficient matching mechanism  which can process lists containing  millions of entries.

How is matching performed?

Matching of the NRD is performed on the Stamus Network Probe during DNS, HTTP or TLS transaction processing on the following buffers, respectively: DNS query, HTTP hostname, and/or TLS SNI entry.

Matching is performed on the domain name itself and therefore will trigger for any subdomain variations.

Reviewing the NRD results in the Stamus Security Platform

From the SSP interface on the Stamus Central Server, users can simply navigate to the Hunt section, then filter on “NRD” (Newly Registered Domains). That will produce a complete list of any NRD communication detections to date - via the TLS, HTTP or DNS inspection:

Reviewing the NRD results in your SIEM

All Stamus Security Platform detection logic and the evidence it produces is transparently available to all user interfaces. If the IDS alerts described in the previous paragraph can be inspected in any data lake, the NSM events are also coming with a twist. If an NRD signature triggered on a flow, then the NSM events will have information coming from the NRD signature. For example, a useful one is “metadata.stamus_classification” that is set to “nrd”, so all events related to a flow where a NRD has been observed can be found easily and correlation can be performed. Another useful artifact produced by SSP is the  “nrd_key” field whose values indicate which JSON key in the event is containing the NRD. 

The following screenshots show the JSON log results containing the relevant fields in a TLS SNI transaction: 



How to enable the suspicious domain feeds

The Newly Registered Domain list variations (Complete, Entropy, and Phishing) are available to any Stamus Networks customer with release U39 by default.

The steps for adding these into SSP are as follows:

  • Make sure you have updated SSP software to at least version U39.0.0 (If you have not please reach out to support and we can help you with this)
  • Log into the Stamus Security Platform and go to Administration -> Other from the left navigation panel
  • Click on the Stamus Networks logo on the upper left to bring down the pull down menu
  • Click “System Licenses” (see below)

  • Copy the “License number” (You will use this for your Secret code later)
  • Click Sources from the top of the page
  • Click “Add Public Source” on the left side of the page
  • Scroll down to find the “Stamus/NRD” sources
  • Click the Enable button on the right of the one you would like to enable
  • Enter the license you copied earlier into the “Secret code” field
  • Then click the checkbox in front of the ruleset(s) you would like to ad the new source to
  • Your screen should look something like this:


  • Click the submit button
  • Finally update your ruleset(s)

NOTE: You should not use both the 30 day version and the 14 day of the same NRD list.


See the screenshot example below showing enabled sources below form the Administration console of the Stamus Security Platform: 

NOTE: For customers who are operating SSP in an air gapped environment, please contact Stamus Networks support for help installing these threat intelligence lists.

How you can automate notifications

Many practitioners would like to be notified automatically of certain NRD events as opposed to just hunting for them manually. Stamus Security Platform supports this automation use case. By escalating a hunt filter to a Declaration of Compromise™ (DoC), users can be notified via webhook or can trigger an automated response when the DoC detection event takes place.  

For example, the following filter is based on an high-entropy NRD detected in communication involving a “client/user PC in the Accounting department at HQ” (organizational context thanks to pre-configured network definitions) :

From this filter, the escalation is basically a click on “Create DoC” (Declaration of Compromise) events from the Hunting tab in the Stamus Central Server.  : 


The rapid expansion of the Internet leads to the daily registration of millions of new domains through the Domain Name System (DNS), catering to both legitimate and malicious purposes. Criminal elements exploit freshly created domains for spam, malware distribution, and botnet setups within minutes of registration, posing significant threats. 

Enterprise security teams can play a crucial role in identifying and mitigating such risks by promptly gathering information on these domains. Unfortunately, current methods of collecting and analyzing this dispersed data from various name servers worldwide have proven inefficient. 

The good news is that Stamus Networks now offers a solution with several NRD threat intelligence feeds that seamlessly integrate with the Stamus Security Platform (SSP), enabling users to promptly detect and address malicious activities associated with newly registered domains. This new resource equips security teams with the necessary tools to safeguard their organizations.

Finally, the post-hunt activities completed in the final example are just the tip of the iceberg when it comes to the automation and escalation capabilities of Stamus Security Platform. To learn more about these features and how to implement them, read our article titled “After the Hunt”

To learn more about Stamus Security Platform (SSP) and see the enriched hunting interface for yourself, click the button below and schedule a live demo.

Peter Manev

Peter Manev is the co-founder and chief strategy officer (CSO) at Stamus Networks. He is a member of the executive team at Open Network Security Foundation (OISF). Peter has over 15 years of experience in the IT industry, including enterprise-level IT security practice. He is a passionate user, developer, and explorer of innovative open-source security software, and he is responsible for training as well as quality assurance and testing on the development team of Suricata – the open-source threat detection engine. Peter is a regular speaker and educator on open-source security, threat hunting, and network security at conferences and live-fire cyber exercises, such as Crossed Swords, DeepSec, Troopers, DefCon, RSA, Suricon, SharkFest, and others. Peter resides in Gothenburg, Sweden.

Schedule a Demo of Stamus Security Platform


Related posts

In the Trenches with NDR: NDR Discovers Crypto Wallet Stealer on U.S. University's Network

Tl:DR: A Large U.S. university lacked sufficient visibility into a large segment of its environment...

The Rise of Network Infrastructure Attacks and What to Do About Them

TL;DR: In recent months, CISA, MITRE, CVE.org, and others have announced critical vulnerabilities...

In the Trenches with NDR: K-12 School District Maximizes Visibility While Avoiding Alert Fatigue

TL;DR: An American school district needed to monitor over 5000 school-owned student devices, making...