How to Enhance Threat Intelligence with Newly Observed Domains

Domain names life cycle…

Domain names are used as a way to abstract the location of the related application or service and hide its IP address to the user. It is much easier to remember a meaningful name than a meaningless IP address, particularly when it comes to IPv6 addresses.

Before anything, one needs to register the new domain name in a Domain Name Registrar. This corresponds to reserving the name so no one else can use it from then onwards. In order to use it, one needs to create such a newly registered domain name on an active DNS authoritative server. This corresponds to making it available to the users so it can be requested. However, it’s important to note that nothing happens until someone requests it for the first time.

New domain names are created everyday as part of the Domain Name System. They serve various purposes – some are legitimate and useful while others are malicious and used for cybercriminal activities. As we say in the DNS world community, “Of course, not all new domains are bad, but many bad domains are recent”. So, while new domain names are mandatory and really useful for any service provider, they can also be used by cybercriminals or nation-state attacks, all leveraging DNS to execute their fraudulent activities, such as hosting new attack services, command and control servers, phishing websites, spread of malware, spam, botnets, etc.

A global 2021 DNS Security survey conducted by IDC revealed that 87% of respondents said they had been targeted by a DNS attack in the last 12 months so the threat is very real.

What to do with Newly Observed Domain?

In essence, any newly registered and created domain is not yet well known and therefore cannot yet easily be in any global security database. As a consequence it is not easy to filter them out as there is no basis to do so. Legitimate are not, a new domain is just unknown to anyone before it has been observed and proven being suspicious or not.

A simplistic and conservative approach could be to restrict any content hosted on an unknown domain name. DNS is by design very well positioned at the intent of any IP communication to perform this simple check.

But this raises the question of What is a Newly Observed Domain (NOD)? How can a given recursive DNS server know that a domain name is new?

As we saw earlier, information about newly registered domain names is at the registrar level to start with. It may be available in the Whois database provided one knows what and how to look for it. This you need to know it has been created even though it might have never been configured on an authoritative server nor used yet. In addition, Whois information won’t be really useful to determine if such a new domain name could be trusted or not.

Ideally, a feed consolidating the information from all registrars worldwide would be necessary to aggregate such data and make it available to all. Nevertheless this would not be sufficient as a domain can be registered, linked to an authoritative DNS server but not yet configured on it. When it is used, so being requested, we can start being informed about its actual usage, legitimate or malicious and this is when it becomes “observed”.

Eventually, in order to keep such a database manageable, we need to stay at the “registrable” level, as all FQDN are not domain names.

Where should the collection occur?

This has to start at any recursive DNS server level. The data collected on multiple servers can be filtered and merged. As one can imagine, it is nearly impossible to know for sure a Domain has been observed for the very first time on the Internet. This would require all the resolvers to work together in synchronization which is beyond the current state of the technology. But by sampling using enough of these servers on multiple regions we can assume that the information is correct and that a domain has been observed for the first time: “newly observed”. Now at an organization level, collecting and consolidating the requests on all the resolvers is scalable and can be done. This should be enough to protect all the clients from new potential threats. Looking also at the source can help analyse the propagation scheme for both licit and illicit domain names.

Combine NOD with Allow/Deny lists

How can someone use the information about Newly Observed Domains?
Of course, a new domain is not automatically malicious but as a precaution principle, waiting before using it is a safe option. Letting NOD be categorised and gathered by a security feed might save the day.

How long should you wait before granting access to a Newly Observed Domain?
A “certain time” is the good response as stated in the punchline of a famous sketch from an old French standup comedian… It actually depends on the security policy and of course the resources at stake to be protected. For some it will be a matter of hours and for others it would go up to a month.

What if the Newly Observed Domain is critical for my business operations?
In this case, the solution is to use a DNS allow list (whitelist) and include such mission critical domain names in it. On the contrary, if the new domain can be ignored for a while, the quarantine period will allow us to know if the domain has been incorporated into a security feed through any Threat Intelligence Process and therefore should never be trusted, or if it is safe after all.

Security teams need up-to-date information about domain names and which ones are known to have a compromised reputation. That’s the role of Security Feeds as part of a DNS Firewall implementation to protect against DNS threats. Among those are specific Security Feeds dedicated to Newly Observed Domains (NOD), those for which no one can be sure yet.

This is where using allow/deny lists at the DNS level to filter access to domain names can be handy, allowing all already known legitimate domain names while denying malicious categories and NOD even before they appear in the licit or illicit categories.

Here’s an example policy which includes NOD management:

1. Allow: Organization Business domains (internal and known SaaS/services/suppliers/partners/customers)
2. Deny: well known malicious domains from security feeds
3. Allow: some commonly used services by users (can include social media, news, travels, public webmail, etc.)
4. Deny: NOD
5. Allow: the rest and monitor tightly any detected NOD at your organization’s level

Policies should be adapted per client type e.g. an IoT device should not access the internet like a user from the HR department. As is always the case with Security, no one size fits all – each case is specific and should be studied based on the actual requirements of the organization.

As a rule of thumb, avoiding sending all the organization’s traffic to a central recursive service in the cloud is best for performance and efficiency, but also more importantly for data security to stay in control. Allow lists as suggested above will drastically reduce the amount of traffic to look at for NOD.

Maximum Security is about adding multiple layers of protection

NOD control linked to DNS is a simple and good tool in the arsenal for safer user access to applications. Organizations would do well to consider it on top of all other existing security measures, for improving their overall security.