Using Infrastructure Analysis to Get Ahead of Attacks in Cyber Defense: Part 3

In part 1 of this series, we looked at how Internet observables—objects such as domains, IP addresses, name servers, and such—fit into various stages of a cyber attack as described in popular models such as MITRE’s ATT&CK and the Cyber Kill Chain, all in service of helping SOC personnel move “left of boom,” getting out ahead of incipient or early-stage attacks. In part 2, we examined some of the objectives your organization might develop around the use of Internet observables in your larger threat intelligence and blue teaming operations. In this final installment of the series, we’ll look at how you can use various DomainTools applications and data sets to operationalize the theory we examined in the first two parts.

Characterizers, Connectors, and Identifiers

The various pieces of metadata about a domain, IP address, name server, or other Internet assets can serve various purposes for the analyst. We can organize them into the following informal categories:

• Characterizers
• Connectors
• Identifiers

Just as the name suggests, characterizers tell you something about the infrastructure element. Examples of characterizers are:

• Domain name
• DomainTools Risk score
• Country
• (rarely) Alexa ranking (could be useful in sussing out legit domains that were pwned)
• Website response code
• MX, SPF records
• Screenshot

As you might have guessed, connectors are pivot points that help you find related assets. Sometimes connectors work by themselves (such as a name server that has a tightly-correlated set of domains for which it is authoritative) or in combination (a pattern of individually-uninteresting connectors which, together, form the basis of queries into DNS OSINT that can tie together seemingly unrelated assets. Connectors include:

• Unique emails (vs privacy service contact info) (Registrant or Start of Authority [SOA])
• Registrant contact information
• IP address
• SSL hash, subject, organization, or email
• Name server sometimes a connector, and (rarely) an identifier
• Google Analytics codes
• Redirects
• Subdomains

Identifying adversaries is its own bucket of worms, worthy of at least its own blog series, if not a book or two. Positive identification of malicious actors is usually elusive, and rarely actually important for blue teams. However, a “John Doe” profile that ties various assets to a common actor is valuable. Some data points, then, serve as identifiers:

• Organization names
• Email addresses (registrant or SOA)
• Registrant names
• Name servers
• SSL certificate information

Remember, the names in these identifiers don’t have to be real names to be useful identifiers. If an actor consistently uses the same fake name, that’s still helpful as an identifier. Also, as you might guess, many of these data points can fit two or even all three of these categories, depending on the specifics. We saw an example of this with some UNC 1878 Ryuk infrastructure, which used “lol” as the SSL Organization in a series of domains:

It is a connector because there were (as of this writing) some 140 domains sharing that datapoint, and a characterizer because “lol” all but confirms that the domains don’t belong to well-intentioned companies providing backup or other IT-related services.

Identifying Adversary Infrastructure Before an Attack

Sometimes it is possible to identify malicious assets before any of them have been operationalized. This is the ideal scenario for the defender, and while it’s not always possible, it is sometimes. Proactively monitoring for new, dormant infrastructure can be done in the following ways:

• DomainTools PhishEye monitors new domain registrations for exact and fuzzy matches of given keywords. The place most organizations start is by monitoring their own name (or names, since larger organizations typically have multiple names or brands) via the PhishEye UI or API in order to build detections or block lists to protect against these assets as soon as they come online. It is worth considering monitoring any other organizations with which your firm does sensitive business, as well, since spoofing a trusted partner is a common spearphishing attack.
• Using the DomainTools Iris Investigate API, a query that matches criteria that represent a “fingerprint” of a specific campaign can surface new domain registrations matching those criteria. In the example from above, an Iris API call could be scripted to check daily for new domains whose SSL Organization was “lol.” Often, these fingerprints encompass several components; common ones are name server, registrar, TLD, and SSL fields, sometimes combined with operators such as “domain begins with.”
• To automate these processes, many organizations build SOAR playbooks that combine the steps of retrieving DomainTools hits with creating internal detections or deny lists.
• An additional step, which adds complexity to a SOAR playbook but which is still within the grasp of most organizations running such technology, is to automate some pivots on the domains surfaced by the monitoring tools, so as to expand the reach of detections or blocking. Such a playbook would make use of the techniques described in the next section.

Thwarting an Intrusion in Progress

Suppose an adversary has attempted to spearphish an employee at the targeted company. Phishing is identified by ATT&CK, Kill Chain, and similar models as an early-stage activity. If this phish is identified (ideally before anyone falls victim, but sometimes it will only be identified after the fact), the infrastructure tied to the phish serves as a starting point to develop a picture of additional assets held by the phishing actor. Most phishing emails are of forensic value because attack infrastructure is involved in one or more of the following ways:

• The domain sending the email may be a spoof of the targeted company’s own domain
• The email may contain a piece of malware that connects to adversary C2 infrastructure
• There may be a link to a credential-harvesting domain, drive-by download site, etc.

Searching on such a domain in Iris, the analyst will frequently find one or more connectors or characterizers in the collected data about the domain. Pivoting on connectors may yield additional domains that are closely related to the first.

Guided pivots are an Iris Investigate UI and API feature that highlight the pivots that are most likely to pay off in developing a picture of adversary holdings. A pivot is highlighted if the number of domains sharing that attribute is more than zero and fewer than 500 (by default). When the numbers of connected domains are in this range, the likelihood of a relationship among those domains is much higher than when the number is higher. For example, the email address “[email protected]” is not a useful pivot because millions of domains share that email address. An email address corresponding to a person, by contrast, is much more likely to connect many fewer domains, and those domains are also more likely to be positively connected to each other. The counts tied to each datapoint are returned by the Iris Investigate API so that Guided Pivots can form part of an automated sequence of lookups.

Armed with an expanded set of infrastructure, the analyst can form hypotheses that will guide response, hunting, and defensive actions. Such hypotheses could include:

• The actor controlling the phishing domain is targeting my organization specifically
• The actor is targeting multiple organizations in my industry
• The domain from the phish is just one component of a larger campaign
• This phish is not the first contact my organization has had with assets controlled by this actor—nor will it be the last

The analyst can then look both forward and backward in time to test these hypotheses:

• (Back in time) Search logs/SIEM for earlier hits on any domain or IP in the correlated infrastructure developed in Iris
• (Forward in time) Configure alerts for any of the correlated infrastructure

A further step for looking forward in time would be to use the Iris Investigate API to repeat the query that found the correlated infrastructure, in case the actor is continuing to stand up additional assets that share the same connectors or characterizers that helped the analyst find the first set of correlated domains.

Detections or blocks on any of the adversary domains related to the domain from the phish may assist in thwarting the attack. Suppose, for example, that some of the correlated domains are intended for C2, downloads of later-stage tooling, or data exfiltration. Blocking these domains as soon as the phish was discovered may be sufficient to put a stop to the campaign. Blocking new infrastructure based on connections found in Iris may also identify or stop entirely new campaigns by the same actor.

The Quest for Relevant Intel

Threat intelligence holds a lot of promise and a lot of challenges. Ultimately, the only threat intelligence that is of practical use to defenders is that which is relevant to the organization. There is far more threat intelligence available than any organization, much less individual, could use. However, it is not only possible, but within the grasp of most security shops, to develop intelligence that has an anchor of relevance by starting at some of the places discussed here: domains spoofing the organization or those with which it shares sensitive information, or domains closely correlated with malicious or suspicious traffic originating in the protected environment. DomainTools has worked with many security teams throughout the globe who are using these techniques to make important strides to defeat a broad spectrum of adversaries, from mass-spread commodity malware opportunists to state-sponsored actors of significant capability. It is our hope that your organization will find these techniques fruitful as well.