Empowering SOC teams with predictive risk scoring – Part 1: Evaluating risks posed by domains

Every domain on the Internet has a job to do. And as we in the infosec community are all too aware, many of these jobs are malicious or, at minimum, highly sketchy. And since the point at which we often have the opportunity to receive telemetry or take proactive measures against risk to the organization is in the traffic flows into and out of the protected environment (which should include all the assets the organization is responsible for, not just those inside a firewalled perimeter), the domains that represent the destinations of those traffic flows are of particular forensic and predictive value.

Even SOC teams have a limit!

Security operation center (SOC) analysts, threat hunters, incident responders, and related practitioners are often quite good at quickly evaluating whether a given domain represents a risk. The problem is scale and time—a large organization has vast numbers of traffic flows occurring every minute.

If a human analyst could magically slow down time to a point at which they could evaluate every domain requested in these traffic flows, they could take some valuable actions, including blocking the overtly terrible domains, subjecting others to additional scanning or scrutiny, setting up alerts, etc. Unfortunately, for all their skills, no SOC analyst we’ve ever spoken to happens to be a time magician. So we need technologies that can, at a basic level, mimic some of what the human analyst would do in evaluating the domains that are requested by protected assets.

The usual ‘malicious domain name’ suspects

Domains created for malicious use often make the “job” they are designed to do quite obvious. Some of the basic ways in which the domain’s intent is communicated are overtly visible in the domain names themselves. Let’s consider a range of domain name scenarios:

Domains designed to fool humans

Credential-harvesting, malware-loading, and related domains that are initially requested because a human interacted with a link or an email message will typically have names that tell the story. They spoof the victim organization itself, or those entities with which the target organization shares credentials, intellectual property, etc.

Example: Spotting imitative domains

Let’s say the organization in question is the venerable (if fictitious) Acme Grommet Company, with the (equally fictitious) domain acmegrommets[.]com. Let’s further postulate that Acme uses a contract manufacturer called Amalgamated Metal Parts (amalgamatedparts[.]com, also fictitious). Finally, let’s assume that Acme uses the (very real) Salesforce.com as their customer relationship management (CRM) platform.

An analyst in Acme’s SOC could therefore spot three kinds of imitative domains that could all represent real risk to the company:

• Domains such as acmegr0mmets[.]com that directly spoof Acme for phishing, counterfeit goods sales, etc.
• Domains such as amalgamattedparts[.]com that may seek to phish Acme employees in order to gain access to sensitive intellectual property shared with the contract manufacturer
• Domains such as salesf0rce[.]com that may seek to gain credentials to Acme’s real Salesforce account and steal customer information

Domains just for the machines

These are the domains used for functions such as command and control (C2), data exfiltration, etc, and which are part of automated malware processes and therefore do not involve direct interaction with humans.

These domain names are often random sequences of characters generated by domain generation algorithms (DGAs). They, too, stand out when looking at lists of domains seen in DNS or other logs or alerts because of the nonsensical and often relatively long domain names.

Newly created domains

There may be domains whose names don’t necessarily reveal much about their purpose. But from a risk management perspective, many organizations have found it useful to alert on, or block outright, domains whose age falls below a certain threshold (see Best practice for newly registered domains). The reasoning is that the overwhelming majority of business-critical traffic will be destined for more established domains, and that the risk of a false positive on a newly-created benign domain is acceptable.

Employees blocked from reaching new domains that they have reason to believe (or know with certainty) are legitimate can request overrides of these blocks. Obviously, the risk-convenience tradeoff in new-domain blocking is one that each organization determines through policy and negotiation.

Using alerts to assess domain risk

Because of the scale problem, there’s no way for analysts to individually assess the risk posed by these various domains in real time. But they can, and do, look at those domains that rise to the surface in the form of alerts fired in a security information and event management (SIEM) or within a security control such as a web or email proxy—provided that those products have a means of detecting the sketchy domains and firing the alerts.

But I already use tools to identify and block malicious content

You might be thinking—what about the abundant technologies that can detect and/or block malicious content without humans having to intervene? Obviously, many of these technologies are highly sophisticated and effective. The challenge is that most of them rely on assessing the behavior of the traffic or content tied to those domains. In order for them to render their verdicts, the domains have to already be operationalized and causing harm. This means that there’s a window of vulnerability between the malicious domain’s creation and the time at which observation-based technologies can flag it as malicious. Closing (or at least narrowing) this window of vulnerability is where predictive domain risk scoring becomes incredibly valuable.

Read part two for a deep dive into how predictive risk scoring can assist in addressing the window of vulnerability, enabling the detection of malicious intent at scale.