This week’s guided threat hunting blog focuses on hunting for high-entropy NRD (newly registered domains) using Stamus Networks High-Entropy NRD threat intelligence – available by default in Stamus Security Platform U39 – as a starting point.

Stamus Networks’ high-entropy NRD is not usually seen in a production setup. These domains may not necessarily be malicious, however it is often unlikely that they are friendly. A malware actor tactic is to register and/or park domains enmasse in order to be used later in different campaigns. In many of these instances, the new domains are used in command and control (C2 or CnC) communication channels. 

Our team has created several additional resources on this topic:

• BLOG: Threat Hunting with Suricata and Newly-Registered Domain Threat Intel (Open NRD) 
• BLOG: Introducing Open NRD: Newly Registered Domain Threat Intel Feeds for Suricata
• VIDEO: Webinar using the NRD threat intel - "Network Threat Hunting with Suricata and SELKS"

One of the major challenges (and thrills) of unearthing unwanted activity from such types of communication is that the type of malware or tool is likely not yet known. In other words, there is a high probability that you are the first one to observe it.

Stamus Security Platform (SSP) automatically detects and identifies serious and imminent threats on the network, and presents security teams with incident timelines and extensive context for each threat. Many organizations take advantage of advanced SSP features and take an even more proactive approach to their defenses. When this is the case, they might task a security analyst with hunting for specific threat types, anomalous activity, or suspicious behaviors. To do this, they can use the Stamus Enriched Hunting Interface. 

This interface provides security practitioners with over 100 ready-to-use guided threat hunting filters, including various filters for policy violations, that they can use to investigate, classify, escalate, and automate vast amounts of event data, alerts, and contextual metadata. For a more detailed look at the Enriched Hunting Interface, read the blog article titled, “Introduction to Guided Threat Hunting”.

What is a High-Entropy NRD initiated hunt? 

Simply put: we start with the idea that any domain that is newly registered, has higher entropy, and is found in TLS SNI, HTTP hostname, or DNS query (thus covering TLS/HTTP and DNS traffic) is definitely worth looking at to begin a hunt.

In the following example, we want to see if there are any instances of high-entropy NRD use within the organization. If we locate any, then we can investigate further to learn more about the specific communication and network artifacts involved. 

Identifying unauthorized domain policy using SSP

Stamus Security Platform (SSP) does most of this work for you. With Declarations of Compromise™, SSP definitively identifies serious and imminent threats. However, no system can automatically detect everything. That’s why SSP logs every possible indicator of compromise – otherwise known as “alerts”. These alerts can be used to create a trail of evidence in an incident investigation. Additionally – as seen in this series – they can also be used to inform a guided hunt for specific threat types or other unwanted activity. 

So let’s take a look at the current alerts on our system: 

In the past 7 days, SSP has generated about 11 million alert events in addition to protocol, flow, and field transaction logs as well as Host Insights for about 29,000 network endpoints/hosts.

High-Entropy NRD triggered hunt using SSP

To begin this hunt, we can simply zoom in on any and all Entropy NRD communication observations by typing in “Entropy” (hit “Enter” afterwards) in the “Message” box, from the “Filters” drop down in Hunt. 

That immediately takes us from 11 million results to 33 results, giving us an excellent starting point to work from. 

It is important to note that SSP enriched hunting also provides additional organization-specific context. Users can filter for queries from various departments or user groups within the organization, allowing them to hyper-focus on specific areas without having to aggregate events or organize IP addresses to find specific users or departments.This can be done from the same “Filters” drop down menu by way of selecting “Network Def” menu.  For example: 

Just elect the desired area/definition. The selection can also be wildcarded too.

In one of many enrichment processes, the Samus Security Platform automatically breaks down any http, dns, or tls domains as part of those network protocol records into its subforms  - subdomain, domain, tld, host, and domain without tld.

But there is still work left to do. Let’s keep going. 

The “Domains” breakdown capability makes it easy for us to have a quick look at the domains regardless of whether the communication is HTTP, DNS, or TLS.

Some of those caught my attention right away, mainly :

615shakespeare [.]com and superhot-datings [.]life

By clicking on the “Extra info” icon we can check those domains using VirusTotal.

Often enough, these domains may not yet be known or analyzed by security vendors. In some cases, as mentioned before, you could be the first person to investigate the newly registered domain communication.

Obviously there was an intention behind those high-entropy NRD communications with the suspect most likely being an unwanted, covert activity. It’s interesting to look at the surrounding landscape from a network security perspective to determine what else has happened that is potentially suspicious or indicates unwanted activity.

It’s important to know who the client and potentially-offending hosts are and if there’s additional information about those seen on the network. Specifically, we need to see which services are running on the potential asset under attack host.

To do this, we can use Host Insights - a very powerful feature included with the Stamus Security Platform. Host Insights tracks over 60 security-related network transactions and communication attributes of a host. This provides a single place to view many aspects of the network activity relative to a given host, such as network services, users, or TLS fingerprinting forensic evidence. 

We can click the “Hosts” tab on the left hand side menu and be transferred from the actual event logs to the Host Insights screen.

To do this with only one click, we switch from the Dashboard tab to the Host Insights tab.  

This gives us the asset inside the organization that is responsible for those high-entropy NRD communication – a significant improvement from 11 million total alerts and over 29,000 hosts/endpoints. 

We can see here that we have quite an interesting array of TLS SNI communication as seen in the “SIGHTINGS”  tab inside Host Insights – the “CN=” fields. 

We want to quickly zoom in on that user from that part of the organization’s network infrastructure and review the events. To do this, we need to select that host and go to “Dashboards”  to see an aggregated view or to “Alerts” for network forensic details such as: alerts, protocol logs, file transactions, anomaly events, flow records, extracted files, and extracted PCAP.

One event and its surrounding network forensics evidence in particular is very interesting, and appears to have a possible java script obfuscation usage:

From the response body below, we can see that this is coming to and from an external site.

Stamus Networks provides an extremely flexible option to download the exact full pcap of the session that triggered that event. We just have to click on “PCAP Download” in the PCAP tab of that event:

Evidence for Incident Response

With just a few clicks, We are able to view three important sets of evidence: 

• The associated file transaction, network protocol transactions, and flow logs
• Host Insights - a single screen for reviewing 60+ network activity attributes collected for every host
• PCAP and extracted files

An added benefit is the fact that the interface is 100% RestAPI enabled, so anywhere I click there is a RestAPI call available for automation. 

The alert events are already enriched by SSP to include important metadata like DNS records, TLS protocol data containing certificate names, fingerprint JA3/JA3S, connection flow sizes, http user agent, http host, request body, status codes, file transaction info, and more. 

We have the related flow and its metrics and the file transaction logs. We can see it as an archive and we have a checksum, filemagic, and all the rest of the file information needed.

Security analysts can use any piece of metadata to create simple or complex filters for things like wildcarding, negation, or inclusion. You can even include multiple fields for fast drill down capabilities. All domains, TLS SNI, IP addresses, HTTP hosts, and more can easily be checked with an external threat intelligence provider such as VirusTotal.  

Armed with the above information and evidence, a threat hunter has enough information to generate an Incident Response ticket. 

However, there are still two tasks left to complete: 

1. 1. We do not want to have to repeat this exact same process again in the future, so we need to set up classification and auto-escalation for future occurrences. 
2. 2. If anything like this has happened before, we want it to be found and escalated with all the associated evidence - all based on historical data.

Classification

In order to streamline the event review/triage process in the future, an experienced analyst can choose to tag/classify the events associated with this filter  By doing so, SSP will tag future events that match the filter criteria as “relevant” or “informational,” depending upon the analyst’s selection. These tags can be used to automate event review/triage and make it easier for a less-experienced analyst to identify events that are relevant for manual review.

To do so, the analyst selects the Tag option from the Policy Action menu on the right hand side menu. This action will cause SSP to insert a tag into each event record as shown below:   

This allows the analyst to easily filter out or search for them in any SIEM (Chronicle, Splunk, Elasticsearch, etc) or data lake using that tag.

It also allows for easy filtering out of those events in the Stamus Enriched Hunting GUI by switching to “relevant” only classified events. 

Escalation and Automation of this Hunt

To set up an automation which causes SSP to escalate past and future occurrences, we can create a Declaration of Compromise (DoC) event from the Policy Actions drop down menu on the right hand side panel in the Stamus Enriched Hunting Interface. 

The next step is to add some explanation about the type of threat. This also gives us a chance to provide informational context and helps convey knowledge to colleagues.

Select options to generate events from historical data and generate Webhook notifications.

And just like that, the hunt and all related activities are complete. Any past or future generated events from that automation will then be further auto-classified and escalated to the desired response process -  via SOAR playbook, chat notification, or incident response ticket. 

Conclusion

The post-hunt activities completed in this 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.