In Part 1 of this blog, we examined what I called the “Network forensics contact patch”–the place where the “tire tracks” of network traffic are observable, and the point at which observations can be made. We saw how some of the fundamental objects for infrastructure-related forensics—domain names and IP addresses—are (or are not) made available in device logs and alerts. We also saw how, once we identified the sources of those forensic objects, we might approach paring down the potentially huge volumes of noise to get down to the important signals. In Part 2, we will look at what to do with the domain names we’ve identified.
As a reminder, the general criteria for “interesting” domain names are these:
- The domain name is not common (as specified by web ranking services)
- The domain is “uncategorized” by web filters/proxies (typically because there is not enough—or any—web content for the filter to analyze; this often happens with brand-new domains)
- The traffic to the domain originated with especially important devices (often referred to as “crown jewels”)
Of course, you may have other criteria as well. The above are useful in cutting out a lot of volume, boosting the signal to noise ratio, and giving analysts a manageable amount of reasonably interesting traffic to examine.
Enrichment of Domain Indicators
So now we have a set of domain names. What do we do with them? This is where enrichment comes into play. Most readers of a blog like this already know what enrichment means, but for anyone newer to the concept: enrichment (occasionally also called “decoration”) of indicators is the attachment of relevant data or metadata that helps us understand more about the indicator. In the case of a domain name, enrichment can tell us things such as:
- When the domain was registered
- What registrar administered the registration
- What entity registered the domain (this is often, but not always, masked by a privacy proxy)
- What name servers are authoritative for the domain
- What IP address(es) the domain resolves to
- What the risk level of the domain is (for example, from the DomainTools Risk Score)
- What shows up on a screenshot of the domain
- What SSL/TLS certificates the domain uses, if any
- What tracking/advertising codes the domain uses
We can often develop certain insights about the domain from first-order enrichment (looking up metadata about the indicator but not analyzing patterns found in the metadata). Examples would be knowing how new the domain is, or whether it has a high risk score.
Enrichment can be done manually by analysts, or at scale by SIEM connector apps, SOAR playbooks, homegrown scripts, and any number of other methods. When it is done manually, this is usually in an incident response or alert triage scenario. Automatic enrichment, conversely, can be one of the means by which an incident is discovered in the first place. Because this enrichment could add up to a lot of data when the volume of domain names is high, many SOCs choose to use a minimum of enrichment data as a first-pass. This approach is embodied in several apps DomainTools has developed with integration partners such as Splunk, IBM QRadar, etc, where at a dashboard level, only the age and risk score of the domains are used as criteria for identifying risk. Very few of the other enriching datapoints would be sufficient to enable efficient triage. For example, while domain registrars can be forensically interesting, it wouldn’t make much sense to do first-order triage on domains based on their registrars.
We can think of the process of identifying domains for humans to analyze (and ultimately take potential action on) as having stages. The first stage is identifying candidates for enrichment (the “interesting” criteria mentioned earlier). The next stage is identifying what we might call candidates for analysis, which automatic enrichment can give us.
| Stage 1: Candidate for Enrichment | Stage 2: Candidate for Analysis |
| Uncommon domain name (not in top <n> ranking of popular domains)Uncategorized by web filtersAccessed by a “crown jewel” device | Recent registrationHigh risk scoreDomain name is suspicious (e.g. spoofing the organization) |
The stages filter traffic down successively. If we’re looking at logs from a DNS resolver, then the Stage 1 criteria will greatly cut down the number of domains in play. Stage 2 can provide a second cut, with only the domains passing those criteria moving along to analysts (or to some of the more sophisticated SOAR playbooks that enable a degree of second-order enrichment).
Deeper Analysis
Once the analysts have the candidates for analysis, they can use some of those other enriching datapoints to gain more context. For example, by knowing what IP address the domain uses, we can then consult tools that can tell us what other domains share that address. The same principle applies to other data points such as registrants, name servers, SSL certificates, and more. Knowing the other populations of domains associated with these items can often give us more clarity on what the domain in focus (let’s call it “Domain 1”) is really all about. Two things can then happen at this point (and they are not mutually exclusive):
- We can render a “verdict” on Domain 1; if it is considered dangerous, then the SOC may choose to write alerting or blocking rules to address any future traffic destined for it.
- We can investigate any other domains that our analysis showed to be closely connected to Domain 1. This can help us locate any earlier communications to those related domains which could have signaled trouble; or we could write rules to address any future traffic to any of those other domains.
Let’s zoom in on the above for a moment, since our focus is on network traffic analysis. If we find that Domain 1 is closely linked to one or more additional domains, then any traffic flows to those additional domains are significant (assuming Domain 1 looks or conclusively is a threat). As indicated above, these additional traffic flows may be in the past, present, or future. Looking into the past, if we search logs for the connected domains, any “hit” may signify that a compromise was underway before the traffic flow to Domain 1 that first got our attention. Similarly, even if there was no past traffic to any of the related domains, it could make sense to write alerting or blocking rules for those other domains (or for IP addresses they have in common, if said addresses don’t seem to have a lot of benign domains on them that could create a false positive risk). We would want to be aware of any future attempts to connect to any infrastructure that’s part of a campaign.
Taking Action
When dangerous domains are confirmed, it can make sense to block them in security controls such as firewalls, proxies, DNS RPZs, E/XDR systems, etc. Often, the administrators of those controls are not part of the same team that is doing the analysis, so there is a handoff of sorts. Most security controls have the means of ingesting custom objects (such as domains or IP addresses) for alerting or blocking; this guide provides some examples.
Conclusion and Key Takeaways
Network traffic offers a major forensic window into the risk level in the protected environment, and the controls of that traffic are one of the most important categories of protection for users and resources. While most enterprises have massive volumes of network traffic, there are steps you can take to keep the forensic gold while discarding the dirt and rocks, and for getting the most from the data you’re starting with.
- Adopting criteria and building tools to identify candidates for enrichment
- Automating first-order enrichment to identify candidates for analysis
- Carrying out second-order enrichment and analysis to identify related infrastructure that should be hunted for
- Taking action regarding any domains or IPs shown to be part of a malicious campaign.
Adversary infrastructure analysis in conjunction with observed network traffic has been proven effective by many of the most advanced hunting, analysis, and incident response teams around the globe. May your team find continued success in the struggle against online foes.
