Introduction
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 this installment, we’ll look at some of the specific goals and objectives a blue team needs to think about in this process. Obviously, everyone would agree that getting ahead of attackers is a great idea; but how does that happen as a practical matter? What steps are involved? What groundwork has to be laid to make it possible? That’s where this installment, and part 3, come into play.
Distant Early Warning
Part of the Cold War-era nuclear defense strategy involved knowing as early as possible if enemy missiles had been launched. One of the technologies the US deployed for this was a set of radar installations called the Distant Early Warning (DEW) line. In the days before satellite imagery was as good and as real-time as it is today, the DEW line radars (and the Soviet equivalent) were the best means the nuclear powers had of preparing for an attack (not that you could do much about missiles whose flight times were around 20 minutes, but that’s a different blog). It turns out that in cybersecurity, you can also construct a DEW system of sorts.
The key to getting ahead of certain kinds of attacks is to have a view into the infrastructure that the adversary is setting up. To revisit the Cold War analogy, this is what spy planes and satellites did: they photographed known or suspected missile site or air base construction so that their respective governments could adopt defensive postures aligned with the threat. Malicious domains, the IP addresses that host them, and the name servers that are authoritative for them are all key pieces of adversary infrastructure that have to be in place and functional in order for the operation to begin and progress. Examples of how this infrastructure plays out in attack scenarios could be:
- Domains: phishing email spoof domains; phishing link target domains (for malware distribution or credential harvesting); malware command and control (C2); data exfiltration servers
- IP addresses: hosting of the domains serving any stage of the incursion or attack; attacker client machines; hard-coded destinations for C2 or exfiltration
- Name servers: domain to IP resolution for any of the above purposes; exfiltration or C2 servers for DNS tunneling techniques
Data and metadata about all of these infrastructure components are invaluable in analyzing what the adversary has in mind. A good analyst can make a lot of useful inferences about infrastructure without waiting to see what happens when traffic goes to or from it.
The Whens, Hows, and Ifs of Detecting and Blocking
In a perfect world, defenders would always know about malicious campaigns before they started, and thus could block known adversary infrastructure every time it was brought to bear. In the real world, there are times when defenders can get all the way “left of boom,” and times when the only way to know about an emerging campaign is after the discovery of at least some stage of the attack in progress. In the first scenario, you can block everything that particular campaign might throw at you. In the second, you can interrupt an intrusion in progress, or at minimum, have good forensic data about an attack that may have succeeded.
Before the Attack
Some intrusions or attacks rely on domains that mimic either the target company or possibly another company with which the intended victim shares sensitive information, federated login credentials, supply chain, etc. By monitoring for newly created domains that spoof your own company and those in your inner circle, such as your supply or distribution chains, you can build detections or block rules against newly-registered malicious domains. Other attacks may be part of a campaign that you previously exposed, and thus may use infrastructure that you can identify via monitoring, and block before its use by the adversary.
Intrusion in Progress
Internet observables can trigger alerts based on (in very basic chronological order) phishing emails, connections to mid-stage tooling servers, connections to C2, or connections to exfiltration targets. From any of these, an analyst may have the opportunity to find related infrastructure and create detection or blocking rules based on it; but only if some of the earlier-stage traffic is caught in time can the organization still avoid the worst part of the “boom.” If it’s discovered in later stages, the operation becomes more forensic than preventative.
Whenever you have evidence of an intrusion or attack that has your organization in its crosshairs, it’s obviously important to enable—or create—detections for it. In many cases, especially when confidence in the assessment of a given indicator is not at an extremely high level, organizations opt for detection over-blocking. There is an understandable reticence about blocking domains that might be innocent; moreover, threat intel teams in many organizations are separate from the folks who administer the security controls, and the latter group is ultimately responsible for making the decisions. Where the “confidence threshold” is drawn is deeply rooted in an organization’s security DNA; some shops embrace a zero-trust model, with curated allow lists amid a default-deny rubric. Some have policies not to allow traffic to *any* newly-created domains, regardless of any risk scores that may be applied to them. Only your security leadership can decide where the confidence threshold should be, based on your threat modeling, risk tolerance, business needs, and various other considerations.
Using Internet Observables to Infer Adversary TTPs
For this discussion, we’ll look at two categories of tactics, techniques, and procedures (TTPs).
- Standard TTPs: the ones defined in MITRE ATT&CK and other frameworks
- Infrastructure TTPs: patterns exhibited by actors in infrastructure configuration to support campaigns
You can use Internet observables to infer an adversary’s TTPs of both categories. For standard TTPs, here are some reasonable inferences:
- Domains spoofing the target organization via typosquatting, lookalike domain names, etc: spear phishing, Business Email Compromise, credential harvesting, counterfeiting, eCommerce fraud, other fraud
- Domains with high-entropy names likely created by a domain generation algorithm (DGA): command and control (C2), exfiltration, malware distribution
- Unusual/long subdomain strings: DNS tunneling for data exfiltration or C2
When you detect DNS lookups or actual traffic to domains in any of those categories, you can make educated guesses about what the intent of the domain in question is, and you can form testable hypotheses about what the actor is trying to accomplish. You can also make inferences about where an intrusion or attack’s progress may be. Traffic to a C2 domain implies that the attacker has already established at least a minimal foothold in your network, which carries a particular set of IR implications. Traffic—or DNS lookups—to a domain spoofing your organization, or an organization with which you share sensitive information, suggest early intrusion stages. You can further narrow down how a spoof domain is being used by the context in which you see it. If it shows up in your SMTP logs, for example, that’s an indication that it may be part of a spearphishing attempt by an adversary mimicking the email address of someone in your organization—which of course would be confirmed if such an email was delivered (or blocked/quarantined). If a spoof domain shows up in HTTP/S logs, it may be a credential harvesting operation.
Domain Generation Algorithms (DGAs) create domains with nonsensical names. Some of them are random groups of characters, while others use real words in random combinations. If you discover anomalous traffic to such a domain, there’s a good chance that a bot is using the communication to that domain for accessing later-stage tooling or for exfiltrating data.
DNS tunneling is a popular adversary technique. There are various methods for detecting it as outlined in this excellent paper from SANS; some of the things to watch for are unusually long DNS A record or TXT record request strings. Such strings can be hashed or encrypted representations of internal data that the actor is exfiltrating to the domain in question.
Infrastructure TTPs are identifiable patterns followed by malicious actors when they register and host domains intended for attack campaigns. To discover these patterns requires a pivoting investigation tool such as DomainTools Iris, which allows you to map related infrastructure via common linking data points. An example of such a pattern could be a set of domains sharing these characteristics:
- Registrar
- Naming scheme
- Hosting provider
- IP range or ASN
- Create dates are within a narrow range or set of ranges
- SSL certificates or metadata (SSL org name etc); self-signed certificates
- MX records or SPF rules
Notice how each of the items could be, by itself, uninteresting as a connector or characterizer of domains, but in combination, they can allow you to “triangulate” a set of common infrastructure. In part 3 of this blog, we’ll go into much more detail about how to do this kind of analysis.
Begin With the Wolf, Track the Pack
Suppose you are monitoring new domain registrations for domains that spoof your organization, or other companies with whom you share sensitive data, and you get a hit. This domain would be suggestive of an early attack stage—Resource Development or Initial Access (ATT&CK) or Delivery (Kill Chain). By studying registration and hosting OSINT, you may discover other infrastructure that looks like it is a) connected to the spoof domain and b) suggestive of later attack stage preparation. You now have a set of indicators that can inform your detection engineering and possibly your blocking/email quarantining/deep packet inspection rules.
Key Takeaways
- Attackers use infrastructure for various stages of an operation and almost always leave some clues behind in the form of Internet observables
- These can form a sort of Distant Early Warning system for an incipient intrusion or attack
- Such indicators can form the basis of detection or blocking rules that are specific to a particular adversary or campaign
- You can use these Internet observables to infer adversary TTPs
- Regular TTPs as defined in ATT&CK, Kill Chain, etc
- Infrastructure-specific TTPs (registration/hosting patterns)
- Finding any one of these indicators can lead to the discovery of a larger campaign, which may be active or may be dormant and waiting to be activated
In the next installment, we will see how to get hands-on with these analysis techniques to defend your organization.
