Chapter 4. Find

Be very, very quiet; we are hunting wabbits.

Elmer J. Fudd

The first half of the F3EAD cycle contains the primary operational components—Find, Fix, and Finish. Operations in this context means a planned, coordinated action in response to a developing situation. For us, this means incident-response operations for unauthorized network activity. During these first three phases, the adversaries are targeted, identified, and eradicated. We use intelligence to inform these operational actions, but that’s not the only use of intelligence. Later in the process, the data from the operational phases will feed into the second half of F3EAD, which contains the intelligence-focused phases—Exploit, Analyze, and Disseminate.

This chapter focuses on the Find phase, which is the starting point for both intelligence and operational activities. In the traditional F3EAD cycle, the Find phase starts when the operations team identifies high-value entities to be targeted. In intelligence-driven incident response, the Find phase identifies relevant adversaries for incident response.

In the case of an ongoing incident, you may have identified or been given some initial indicators and need to dig for more, or in the case of threat hunting, you may be searching for anomalous activity in your networks. Regardless of the situation, before you can find anything, you need to have an idea of what it is you are looking for.

Various approaches can be taken in the Find phase. The method you take should be determined by the nature of the situation or incident as well as the goal of the investigation. Different methods may be combined, as well, to ensure that you have identified all possible pieces of information. The methods for the Find phase that we will cover in this chapter are actor-centric, victim-centric, asset-centric, capability-centric, infrastructure-centric, and—the method most folks end up using more often than they would like—media-centric targeting.

Actor-Centric Targeting

When there is credible information on the actor behind an attack or you are being asked to provide information on a particular attack group, it is possible to conduct actor-centric targeting.

Actor-centric investigations are like unraveling a sweater: You find a few little pieces of information and begin to pull on each one. These threads can provide insight into the tactics and techniques that the actor used against you, which then give you a better idea of what else to look for. The result is powerful, but it can be frustrating. You never know which thread will be the key to unraveling the whole thing. You just have to keep trying. Then, suddenly, you may dig into one aspect that opens up the entire investigation. Persistence, and luck, are key aspects of actor-centric investigations.

In some cases, incident responders will go into an investigation with an idea of who the actor behind the incident may be. This information can be gleaned from a variety of sources; for example, when stolen information is offered for sale on underground forums or when a third party makes the initial notification and provides some information on the attacker. Identifying at least some details of an attacker makes it possible to carry out actor-centric targeting in the Find phase.

When conducting actor-centric targeting, the first step is to validate the information that has been provided on the attacker. It is important to understand if and why the attacker in question would target your organization. The development of a threat model, a process that identifies potential threats by taking an attacker’s view of a target, can speed this process and can help identify the types of data or access that may have been targeted. This information can also feed into the Find phase, where incident responders search for signs of attacker activity.

A threat model can allow you to use actor-centric targeting even if you do not have concrete information on the actor by determining potential or likely attackers. Of the hundreds of tracked criminal, activist, and espionage groups, only a small handful will be generally interested in your organization. Assessing which of these groups are truly threats to you is not a perfect science, but you have to make your best guess and keep in mind that the list you come up with will not be an authoritative list but will still be a good place to start. After some time, experience will be your best guide to potential threats.

Once you validate the initial information, the next step is to identify as much information as possible on the actor. This information will help to build the target package on the attacker, which will enable operations to fix and finish the attack. Information on the actor can include details of previous attacks, both internal and external.

Starting with Known Information

In almost every situation, some information will be available on threat actors, whether that comes from previous incidents or attack attempts within your own environment (internal information) or intelligence reports produced by researchers, vendors, or other third parties (external information). Ideally, a combination of both types will be available in order to provide the best overall picture of the threat.

Strategic and tactical intelligence are both useful at this stage. Strategic intelligence on actors can provide information on their potential motivation or goals, where they ultimately want to get to, and what they ultimately want to do when they get there. Tactical intelligence can provide details on how an actor typically operates, including their typical tactics and methods, preferred tools, previous infrastructure used, and other pieces of information that can be searched for during the Fix stage. Both types of intelligence can help to contextualize the information that is found in later stages.

It is also useful, though difficult, to understand whether the actors tend to operate alone or whether they work with other actor groups. Some espionage groups have been known to divide tasks between several groups, with one group focusing on initial access, another focusing on accomplishing the goals of the attack, another for maintaining access for future activities, and so forth. If this is the case, there may be signs of multiple actors and multiple activities in a network, but further analysis should be conducted to see whether the activities fit the pattern of multiple actor groups working together or whether it is possible that several actors are operating independently.

Useful Information During the Find Phase

During the Find phase, our biggest goal is developing information that will be useful during the Fix portion of the F3EAD cycle. The most useful information is information that’s hard for the actor to change. Incident responder David J. Bianco captured this concept, and its impact on the adversary, in his Pyramid of Pain, shown in Figure 4-1.

David J. Bianco’s Pyramid of Pain
Figure 4-1. David J. Bianco’s Pyramid of Pain

The Pyramid of Pain is a model depicting how various types of information are central to an actor’s tool chain and objectives, which corresponds to how hard they are to change. At the bottom, you have basic characteristics that attackers can change regularly by tweaking small details of malware or network configurations such as recompiling malware (to generate a new hash) or pointing a domain name at a new IP address for command and control. At the top, you have core capabilities that are central to who an actor is, such as core techniques and methodologies.

So how do we use this model? The Pyramid of Pain is all about understanding the relative value and temporal nature of different types of indicators of compromise (more on those in the next section!) and actor information. Are hashes useless? Not at all; they’re incredibly useful in many contexts and provide a great starting place for an investigation, but they change often and easily (often just by recompiling a piece of malware). On the opposite end of the spectrum, an actor that specializes in compromising websites with SQL injection would have a relatively difficult time switching tactics to spear phishing with zero-day exploits. When it comes to threat information, we prefer, and get longer use out of, information toward the top of the pyramid. Our goal in both incident response and intelligence analysis is to move higher up the pyramid, thus making it more difficult for the adversary to evade us.

Indicators of compromise

The simplest data to gather (and thus lower on the Pyramid of Pain) is commonly referred to as indicators of compromise (IOCs). While IOCs can come in a variety of formats, which we’ll discuss more in the next chapter, they’re all defined the same way: a description of technical characteristics that identify a known threat, an attacker’s methodology, or other evidence of compromise.

IOCs typically focus on atomic pieces of information at the bottom of the Pyramid of Pain. These can be subdivided based on where the information is found:

Filesystem indicators
File hashes, filenames, strings, paths, sizes, types, signing certificates
Memory indicators
Strings and memory structures
Network indicators
IP addresses, hostnames, domain names, HTML paths, ports, SSL certificates

Each type of indicator has unique uses, is visible in different positions (whether monitoring a single system or a network), and depending on the format it’s in, may be useful with different tools.

Behavior

Far more complex for attackers to change are behaviors, captured in the top level of the Pyramid of Pain as TTPs. This is a loose group that goes beyond tools and instead focuses on how they’re used to achieve an attacker’s goals. Behavior is more abstract than TTPs and can’t be easily described the way IOCs can.

Behaviors can often be best understood in terms of the kill chain from Chapter 3. How does an attacker achieve each piece? Here are a few hypothetical examples:

Reconnaissance
(Usually based on inference) The attacker profiles potential victims based on conference proceedings found online.
Weaponization
The attacker uses a Visual Basic for Applications (VBA) macro embedded in a Microsoft Word document.
Delivery
The attacker sends a phishing email from a spoofed industry group based on information from the conference proceedings identified during Reconnaissance.
Exploitation
The attacker’s VBA macro executes when the victim opens the attached Word document and downloads the second-stage payload.
Installation
The attacker uses a privilege escalation exploit to install a second-stage payload, a remote-access Trojan (RAT), so it starts up at login and achieves persistence.
Command and Control
The RAT uses connections to a micro blogging site to exchange encoded communication for Command and Control.
Actions on Objective
The attacker attempts to steal technical schematics and emails by compressing them and uploading them through a file-sharing service.

As you go through this process of capturing behavior-based information in a kill chain format, make sure that you document any information that you find in a way that will help you remember it for use in future steps of the intelligence-driven incident-response process.

Using the Kill Chain

Actor-centric targeting is often a good place to start, partially because it has the most straightforward model when combined with the kill chain. Any information that you are given or find at the start of your investigation will most likely come from one or, if you are lucky, two phases of the kill chain. A good strategy is to use hints from the preceding and following phases of the kill chain to determine what other information to look for, so identifying where your existing information sits within the kill chain can determine where else you should look.

In the previous example, if the only information you know about the attack is that the attackers used macros in a Word document during the Exploitation phase, you could research that behavior and identify that you should look for artifacts related to privilege escalation to determine whether the exploitation was successful. Another option would be to move in the other direction on the kill chain and look for the delivery method, searching for email senders or subjects related to the original information that you received. Even if the attackers did not keep things 100% identical across attacks, similarities can be identified, especially when you know what you are looking for.

Road Runner: Building an initial kill chain

Building a kill chain for a new attacker is a great place to start when using an actor-centric approach, even if there aren’t a lot of things to fill in at the beginning. One of the great things about the kill chain, even one filled with question marks, is that it provides a structure for what you need to look for next and can be easily updated as new information surfaces.

In Chapter 3 we built out a general kill chain using the typical behaviors and TTPs of an actor we know as Grey Spike. Now we will build another kill chain to enumerate a specific campaign (a series of intrusions carried out in coordination against a goal) that we refer to as Road Runner. In our case, we’re starting with a private report being passed around a variety of organizations similar to ours. Although this report was generated externally, the adversary activities mirror what we have seen in our own network recently. Using this report, along with our internal intrusion documentation, we’re going to start building a kill chain for Road Runner and will document what we know and what gaps we have.

In addition, our organization, which provides operational cybersecurity support to several campaigns, has identified similar phishing emails targeting campaign managers we support. Both the dates and tactics align. Our internal report is here:

Road Runner: Developing the kill chain

Now we have an initial kill chain based on our first pieces of information about Road Runner, which came from both an external report and internal intrusion reporting. While it’s obvious we have huge gaps in the structure of understanding, as we are missing several phases entirely, this activity is starting to come together. We know some of the techniques this actor might use to get into our organization, and based on previous activities of the actor Grey Spike, we have considerable information about what they might try to do once they get in. Our findings are summarized in Table 4-2.

Table 4-2. Developing kill chain for Road Runner activity
Kill chain phase External reporting Internal reporting
Targeting National and State Campaign Staff

National and State Campaign Staff

  • Campaign Finance Manager

  • Chief of Staff

  • Social Media Manager
Reconnaissance Unknown, but targets are listed publicly on their campaign website and have their job titles posted on social media networks. Unknown, but targets are listed publicly on their campaign website and have their job titles posted on social media networks.
Weaponization Macros embedded in PDFs specifically crafted to be appealing to the target receiving it. Macros embedded in PDFs specifically crafted to be appealing to the target receiving it.
Delivery

Emails from:

  • betty.smith@ymail.com

  • support.network@yoohoo.com

Emails from:

  • charlene_abbott@yoohoo.com

  • matt_albridge@yoohoo.com

  • tanya_smitherton@ymail.com
Exploitation CVE-2018-4916 CVE-2018-4916 (Unsuccessful)
Installation Unknown Unknown
C2 Unknown Unknown
Actions on Objective Unknown Unknown

Throughout the rest of the F3 operational phases (Find, Fix and Finish), we’re going to use the information we have to try to track and respond to the adversary and fill in some of these blanks.

Goals

The actor’s goals are the most abstract of all of the information you will gather in the Find stage, because in many cases it has to be inferred from their actions rather than being clearly spelled out. However, an actor’s goal is one of the things that will rarely change, even if it is identified by a defender. An attacker focused on a particular goal cannot simply change goals to avoid detection, even if they may change TTPs, tools, or indicators. No matter what technologies the actor chooses to use or how they choose to use them, they still have to go where their target is. As a result, goals are the least changeable aspect of an actor’s behavior and should be a core attacker attribute to track.

Seeing an actor change goals is a key data point and should always be watched closely. It may signal a shift in interest or could be the setup for a new type of attack. Regardless, it gives considerable insight into attribution and strategic interests.

The goals for Road Runner are based solely on victimology. So far, the only activity we see is targeting campaign staff, indicating that their goal in this particular effort is to gain access to networks or devices associated with upcoming elections in the US. If you recall from the Grey Spike kill chain in Chapter 3, we assess that this actor is a state-sponsored group and receives targeting based on strategic needs of the state.

The goals at this point can be inferred only by looking closer at the victims that they are targeting. Next, we will pivot to victim-centric targeting to see if there is anything else we can identify about this activity that may help us in subsequent phases.

Victim-Centric Targeting

If you are dealing with an active incident, you may or may not have starting information about the actors involved in the incident, but you will almost certainly have some information about the target, or the victim, of the incident. Victim-centric targeting tries to piece together the story of what the adversary was after, how they got to a certain point in the network, and, in some cases, why they are there to begin with.

Victim-centric targeting builds off of victimology, a branch of criminology that studies the relationship between a victim and an offender by examining the causes and the nature of the consequent suffering. In criminology, understanding the victims can give investigators insight into the perpetrator. Understanding the victim’s experience of a crime—for example, were they frightened or intimidated or did the perpetrator attempt to hide the existence of the crime from them—can help understand motivations and even the intention of the perpetrator. In intelligence-driven incident response we tend to think of victims as the devices or servers that were targeted. Although those are very important details to capture in victim-centric targeting, the impact on the human users of those devices is also important to understanding the nature of the incident and the actors.

So how do we begin to leverage victim-centric targeting? Similar to the baseline for beginning with actor-centric targeting, you need to have access to some basic information about the victims to get started. That information can include details about the devices that were targeted, their human users, and the way the device is used. Once we have captured the basic information on the victims, you can begin to ask questions of the data: Why were these victims targeted? What commonalities (if any) do they share? Can the actors’ goals or motivations be inferred from these victims?

Using Victim-Centric Targeting

In Chapter 3 we covered different models that can be used during the incident-response process—or intelligence processes in general—and one model that is especially well suited to victim-centric targeting is the Diamond Model. The Diamond Model has a vertex specifically for capturing the victims in an intrusion. One of the strengths of the Diamond Model is the ability to capture contextual indicators connecting the various vertices, which define the nature of the relationship between different components of the model. In victim-centric targeting these contextual indicators offer key insights that can help you find additional malicious activity in your network.

Victim-infrastructure connection

Adversaries must leverage some sort of infrastructure to carry out their activities, and when those activities directly impact a victim, that means there is a connection between the two. In the Find phase, this victim-infrastructure relationship can be used to find additional victims or uncover additional information about the adversary by following the link and pivoting to infrastructure-centric targeting, which we will discuss later in this chapter.

Questions to ask related to this vertex are:

  • What was the nature of the connection between the victim and the adversary’s infrastructure? Did it reach out to the victim, or did the victim reach out to it?

  • Did any other devices interact with this infrastructure in the same way as the victim?

  • Is there anything unique about the relationship here that could be pivoted on?

In our Road Runner scenario, a Diamond Model would capture the email addresses and the PDFs in the Infrastructure vertex, as they were the means by which the capability was delivered to the victim. In each case, the email address was a generic-sounding name that was not uncommon in the target’s political district. In addition, the subject and the filename of the PDF that were delivered were in alignment with typical emails that the target receives—pivoting on every email about fundraising that is sent to a campaign fundraising chair would likely not be an effective use of time. One potential pivot from this relationship would be the email domain, which in this case is not a common provider.

Victim-capability connection

Similar to infrastructure, there will always be a relationship between the capability leveraged and the victim, although victim can be used in multiple ways. For example, a victim may be the user who clicked a phishing link, or it may be the computer that the user was on when they clicked it. Either way, the relationship can be characterized and captured.

Questions to ask related to this vertex are:

  • What is it about this victim that made this capability successful (or unsuccessful)?

  • Are other victims susceptible to the same capabilities?

For Road Runner, we know that the phishing campaign we identified was designed to leverage CVE-2018-4916, which exploits a vulnerability in older versions of Adobe Acrobat Reader. The attempts we know about were unsuccessful because the recipients were not running vulnerable versions of the software. This is a critical piece of information for the Find phase because we know that any devices running a vulnerable version would potentially be an appealing target to the adversary.

Victim-adversary connection

While there is typically not a direct connection between an adversary and a victim in the Diamond Model, there is the concept of a meta-feature that captures the socio-political relationship between the two. This meta-feature may include contextual information on why an adversary is interested in leveraging its capabilities against a particular victim or set of victims. In the Find phase, in particular, being able to describe potential relationships between the adversary and victim can help identify additional data points to search for as we try to gather as much data as possible.

Some questions to ask when digging into the victim-adversary relationship:

  • What would targeting this victim help an adversary achieve? (Remember, the victim may have been the target or just a hop-point on the way to the target; explore both options.)

  • Are there other victims that share similar characteristics and may have been similarly targeted?

Using victim-centric targeting, we have identified that these key campaign staff are likely to continue to be targeted as they are the best sources for the types of information that Grey Spike is after for the Road Runner operation.

Asset-Centric Targeting

While victim-centric targeting looks at the victims and victim devices that are targeted or have been impacted by an actor and uses that information to find additional signs of activity, asset-centric targeting is possible even when there is no confirmed adversary activity. Asset-centric targeting is all about what you’re protecting and focuses on the specific technologies that enable operations. It can be incredibly useful for instances when you do not have specific information on an attack against your network and want to understand where and how you would look for indications of an attack or intrusion.

One of the most notable examples of this form of targeting is industrial control systems (ICS). These specialized systems, which control things like dams, factories, and power grids, require specific domain knowledge to use and thus attack. A threat intelligence team can limit entire classes of attackers based on their ability to understand, have access to, and test attacks against ICS. We are talking about not only massively complex systems but in many cases massively expensive ones as well. During an attacker’s pre-kill chain phase, they have to invest incredible amounts of time and effort into getting the right software to find vulnerabilities and then getting the right environments to test exploits.

Understanding who is capable of attacking the types of systems you’re protecting is key to asset-centric targeting because it allows you to focus on the kinds of indicators and tools that are useful for attacking your technology. Every extra system an attacker invests in attacking is an opportunity cost, meaning they can’t spend the same time and resources working on another type of technology that needs the same level of resources. For example, a team putting effort into attacking ICS would not have the resources to put into attacking automotive technology.

Third-party research can help and hurt technology-centric attacks, either by aiding the attackers with basic research (thus saving them time and resources) or by helping defenders understand how the attackers might approach it and thus how to defend it. Most defenders have a limited need to dig into these topic-specific issues, but they provide a focused view of the attacker/defender paradigm.

Using Asset-Centric Targeting

Because asset-centric targeting focuses on the assets that an attacker would target, in most cases the organizations that will get the most out of this method are those developing a unique class of technology such as industrial control, power generation, self-driving cars, flying drones, or even Internet of Things devices. Obviously, each organization has its own specific considerations and so asset-centric targeting should be done with a similar but customized kill-chain-style approach. Robert Lee, a noted ICS expert, demonstrated building a custom asset-centric kill chain in his paper “The Industrial Control System Cyber Kill Chain”.

How can we use asset-centric targeting in our Road Runner scenario? So far, we have a few pieces of information that would help us, though they may seem overly broad at this point. We know the Road Runner team has targeted individuals using phishing emails designed to exploit a vulnerability in a PDF reader. While the adversary may be targeting individuals they think are vulnerable to this attack, it seems that they are just targeting specific individuals and we do not have enough information to ascertain whether they may target specific systems, or even whether they will pivot to additional systems after gaining initial access. If the adversary’s goal is information gathering, there is quite a lot to be gained just by getting access to a key staff member’s email account.

Asset-centric targeting is all about narrow specifics, but at this point we do not have enough information about the adversary’s activity for those specifics to manifest. We will continue to gather as much information as we can for the Find phase, but what is most notable here is that we are identifying a gap in information. If it becomes critical to have a better understanding of the assets targeted by this adversary, we will need to come back and address this gap, but for now we have sufficient information to continue with our Find phase.

Capability-Centric Targeting

As you may be picking up on, one of the main points of the Find phase—and the reason that there are so many different approaches—is that much of this work is based on the concept of doing what we can with what we have. Over the years, as intelligence sharing has improved between different companies as well as between the government and the private sector, there have become more options for the types of information available to help with detecting malicious activity. One type of information that can be incredibly useful is information on the capabilities of adversaries.

Capabilities are the tools and methods that adversaries use to achieve their goals. While many may think of things like zero-day exploits and polymorphic malware when we discuss capabilities, it is important to remember that adversaries often use the least sophisticated tool that will achieve their goals. Keeping this in mind can prevent overlooking a less sophisticated method of accessing or traversing a network.

One of the most common uses of capability-centric targeting is pivoting off of a piece of malware that was found in the environment. Using tools like VirusTotal or an intelligence portal provided by an antivirus vendor, an analyst can quickly plug in a malware hash, filename, or other indicator from a compromised system and begin to identify other elements that can help in the Find phase.

Using Capability-Centric Targeting

The types of indicators that can be pivoted off of using capability-centric targeting tend to be lower on the Pyramid of Pain that we discussed earlier in this chapter—hashes, filenames, and strings. That is okay, though! The point of the Find phase is to enumerate as much as possible, and pivoting off of a capability is a good way to find additional information. It is also possible to cluster similar items to start to gather more insight and move up the pyramid. For example, look at the filenames of the attachments sent to the campaign staff:

  • Receipt.pdf
  • Sendingdonation.pdf
  • Volunteer_resume.pdf

There is a clear pattern here, and while it may not be useful to search through the victim’s inboxes for other attachments with receipts or resumes (they likely get a ton!), it could be something to look for in a database of malware, especially when it can be combined with other pieces of information found in the capability, such as an IP the malware reaches out to after executing, signature info, or other types of metadata. It is important to avoid going down a rabbit hole with these pivots. A general rule of thumb during the Find phase is to stop two pivots away from a piece of information that you know is relevant to the investigation. More pivoting can be taken during the later phases of F3EAD, in particular in the data Exploitation and Analysis phases, where there will be much more context to guide you and keep you from pulling on the wrong threads.

For Road Runner, we do have some basic information about the types of capabilities that they have already leveraged against us, and as we discussed with both actor- and victim-centric targeting, we can potentially find additional information using the samples that we have access to, along with the hash that was provided in the external report we received. With the actor that we believe to be behind Road Runner, Grey Spike, we expect there to be other tools in their arsenal, as well, and can leverage information about those capabilities.

Media-Centric Targeting

This is a little bit tongue in cheek, but one of the most common targeting methodologies that occurs in many organizations is often called “CNN-centric targeting” or “media-centric targeting.” This usually starts with an executive seeing something on the public news or hearing an off-handed comment from someone else that trickles down to the threat intelligence team, which then becomes tasked with analyzing the implications of the threat.

Let’s set the record straight: These kinds of investigations are not always a bad thing. There is a reason even the largest traditional intelligence providers monitor news sources—journalism and intelligence are closely related. Current events can often have a dramatic impact on the intelligence needs of an organization. The key is to distill what may seem an unfocused query into something more cogent and clearly defined.

For example, a stakeholder comes to you having seen the news clip “Chinese Hackers Infiltrated U.S. Companies, Attorney General Says” and wants to know whether this is relevant to your organization. There are a few key points to think about for you to answer this question:

  • First, take the time to read the article and watch the video and associated media. Who are the groups and people referenced? Don’t just focus on attackers, but focus on victims and third parties as well.

  • This article is discussing a specific group of attackers. Do you know who those attackers are?

  • What is the question being asked? Start big and then get small. It’s easy, at first, to look into the names mentioned in the article or video and say “We’re not any of those companies, or even related,” but go deeper. The true question is likely, “Are we at risk of intellectual property theft from state-sponsored actors?”

  • If possible, identify any information that will help you determine whether you have been compromised or will help you put defenses into place that would identify similar attack attempts. This is the beauty of the Find phase: You can identify any pieces of information that may be useful moving forward, regardless of what prompted the request, making it part of the formal process.

It is useful to view this type of targeting as an informal request for information, rather than as an offhanded request. The request for information is the process of taking investigation cycle direction from the outside. We will discuss this concept more later in the chapter. For now, though, it is important to remember that there may be key pieces of information about an adversary or activity in media reporting, including trends in activity, information about adversary goals, and other insights that may be useful. While this information may not help you tactically hunt for activity on your network, it can provide you with additional data that may help connect the dots in the future. At the very least, your responding quickly and efficiently to a request from a stakeholder can provide them much-needed support and additional insight into the role of intelligence in the organization.

Targeting Based on Third-Party Notification

One of the worst experiences a team can have is when a third party—whether a peer company, law enforcement, or someone on Twitter—reports a breach at your organization. When a third party notifies you of a breach, in most cases the targeting is done for you. The notifier gives you an actor, or at least some pointers to an actor, and ideally some indicators. From there, the incident-response phase begins by figuring out how to best use the information given, something we’ll talk more about in the next chapter.

The active targeting portion of a third-party notification focuses primarily on what else you can get from the notifier. Getting as much information as possible from a third party involves establishing that you and your organization have a few key traits: actionability, confidentiality, and operational security.

Sharing intelligence in a third-party notification is largely a risk to the sharing party. Protecting sources and methods is tough work and harder when it’s outside your control, such as when giving the information to someone unknown. As a result, it is up to the receiver to demonstrate that information will be handled appropriately, both in protecting it (operational security and confidentiality) and in using it (actionability).

The result is that the first time a third-party shares information, they may be reluctant to share very much, perhaps nothing more than an IP address of the attacker infrastructure and a time frame. As the receiver is vetted and shown to be a trustworthy and effective user of shared intelligence, more context might be shared. These types of interactions are the base idea behind information-sharing groups, be they formal groups like Information Sharing and Analysis Centers (ISACs) or informal groups like mailing lists or shared chats. Mature and immature organizations both gain from being members of these types of sharing groups. Just be sure your organization is in a position to both share what you can and act on what’s shared with you. The more context that an organization can share around a particular piece of information, the more easily and effectively it will be to act on that piece of information.

Note

Many organizations struggle with getting the authority to share information. Although most organizations are happy to get information from other security teams or researchers, many are reluctant to share information back, either to individuals or to groups. This is a natural concern, but to be effective, teams must surmount it. This goes back to the childhood adage that if you don’t share, no one will share with you. In many cases, this means engaging your legal team and developing a set of rules around sharing information.

Prioritizing Targeting

At this point in the Find phase, you have likely gathered and analyzed a lot of information. To move onto the next phase, Fix, you need to prioritize this information so that it can be acted on.

Immediate Needs

One of the simplest ways to prioritize targeting a request from stakeholders is based on immediate needs. Did an organization just release a threat report about a particular group, and now your CISO is asking questions? Is the company about to make a decision that may impact a country with aggressive threat groups, and they have asked for an assessment of the situation? If there are immediate needs, those should be prioritized.

Judging the immediacy of a Find action is a tough thing. It’s easy to get caught up in new, shiny leads. Experience will lead to a slower, often more skeptical approach. It’s easy to chase a hunch or random piece of information, and it’s important to develop a sensitivity to how immediately a lead needs to be addressed. The key is often to slow down and not get caught up in the emergency nature of potentially malicious activity. Many experienced incident responders have a story of getting too caught up in a target that looked important, only to realize later it was something minor.

Past Incidents

In the absence of an immediate need, it’s worth taking time to establish your collection priorities. It’s easy to focus on the newest threat or the latest vendor report, but in most cases the first place to start is with your own past incidents.

Many attackers are opportunistic, attacking once due to a one-time occurrence such as a vulnerable system or misconfiguration. This is particularly common with ransomware operators or less sophisticated attackers. Other actors will attack continuously, often reusing the same tools against different targets. Tracking these groups is one of the most useful implementations of threat-intelligence processes. In many cases, analyzing these past incidents can lead to insights for detecting future attacks.

Another advantage of starting your targeting with past incidents is you’ll already have considerable amounts of data in the form of incident reports, firsthand observations, and raw data (such as malware and drives) to continue to pull information from. Details or missed pieces of past incidents may be re-explored in the Find phase.

Criticality

Some information that you have identified in this phase will have a much more significant impact on operations than other pieces of information that you have gathered. For example, if, during the Find phase, you uncover indications of lateral movement in a sensitive network, that information is of a much higher priority than information indicating that someone is conducting scans against an external web server. Both issues should be investigated, but one clearly has a higher potential impact than the other: The higher-priority issues should be addressed first. Criticality is something that will vary from organization to organization, based on what is important to that particular organization.

Organizing Targeting Activities

It is important to understand how to organize and vet the major outputs of the Find phase. Taking time, whether it’s 10 minutes or 10 hours, to really dig into what information is available and understand what you are potentially up against will put you in a good position to move forward. You must organize all of the information you have just collected and analyzed into a manageable format.

Hard Leads

Hard leads include information you have identified that has a concrete link to the investigation. Intelligence that is in the hard lead category provides context to things that have been identified and that you know are relevant. These leads have been seen in some part of the network, and during the Find phase you will be searching for related activity in other parts of the network. It is important to understand which pieces of intelligence are directly related to the incident and which pieces of intelligence are only potentially related. Similar to the data sources we discussed in Chapter 3, the different types of leads are all useful; they are just used in different ways.

Soft Leads

Much of the information that you have discovered in the Find phase will fall into the category of soft leads. Soft leads may be additional indicators or behaviors that you have identified that are related to some of the hard leads, but at this point you have not looked to see whether the indicators are present in your environment or what the implications of that are; that will be done in the Fix phase. Soft leads also include information from new reports on attacks that target similar organizations to yours, or things that have been shared by an information-sharing group that you know are legitimate threats but that may or may not be impacting you. Soft leads can also include behavioral heuristics, where you are looking for patterns of activity that stand out rather than a concrete piece of information. These types of searches, which are often technically more difficult to carry out, can produce significant results and generate a great deal of intelligence.

Lead Storage and Documentation

All of these leads should be stored and documented in a way that will allow you to easily move into the subsequent phases and add information. There are a variety of ways that this information can be documented. Many teams still use good old Excel spreadsheets. Others have transitioned to tools such as threat-intelligence platforms (there are open source and commercial versions of these), which allow you to store indicators, add notes and tags, and in some cases link indicators together. The most important thing about documenting this stage of the incident-response process is that you find something that is compatible with your workflow and that allows the team visibility into what has been identified and what still needs to be vetted or investigated. We have seen many teams spend far more time than they need to in the Find phase because of duplicated efforts or lack of good coordination. Don’t fall into this trap! Once you have identified information about the threat you are dealing with and documented it properly, you are ready to move into the next phase.

Although we won’t discuss tracking incident-response activity and incident management until Chapter 7, it’s important to quickly discuss lead tracking. Every incident responder has stumbled across a piece of information in a lead that they’ve seen before, only to fail to contextualize it. Taking the time to note your leads, even just solo in a notebook, is essential for success. Here’s a solid format for saving your leads:

Lead
The core observation or idea.
Datetime
When it was submitted (important for context or SLAs).
Context
How was this lead found—internal or external? Was it research-based or incident-based?
Analyst
Who found the lead?

This approach is simple and easy but effective. Having these leads available will give you a starting point for reactive and proactive security efforts and will also contextualize ongoing incidents in many cases.

The Request for Information Process

Similar to leads, a request for information (sometimes called a request for intelligence) is the process of getting direction from external stakeholders into a team’s incident response or intelligence cycle. This process is meant to make requests uniform and to enable them to be prioritized and easily directed to the right analyst.

Requests for information (or RFIs) may be simple (only a sentence and a link to a document) or complex (involving hypothetical scenarios and multiple caveats). All good RFIs should include the following information:

The request
A summary of the question being asked.
The requestor
Who do you send the information back to?
An output
This can take many forms. Is the expected output IOCs? A briefing document? A presentation?
References
If the question involves or was inspired by a document, this should be shared.
A priority or due date
This is necessary for determining when something gets accomplished.

The RFI process needs to be relevant and workable inside your organization. Integration is key. It needs to be easy for stakeholders to submit requests and receive information, whether that be via a portal or email submission. If you or your team are frequently overrun by a high volume of informal RFIs, putting a formal system into place is one of the best ways to manage the workload. We’ll discuss RFIs, specifically as intelligence products, more in Chapter 9.

Conclusion

The Find phase is the critical first step in the F3EAD process that allows you to clearly identify what it is that you are looking for. Find often equates to targeting and is closely related to the Direction phase of the intelligence cycle. If you do not know what your task is or what threat you are addressing, it is hard to address it properly. Find sets the stage for the other operations-focused phases in the F3EAD process.

You will not spend the same amount of time in the Find phase for each project. At times, the Find phase is done for you. Other times it involves only a small amount of digging. Other times the Find phase is a lengthy undertaking that involves multiple people within a team focusing on different aspects of the same threat. When faced with the latter, make sure to stay organized—document and prioritize leads so that you can move into the Fix phase with a comprehensive targeting package that includes exactly what you will be looking for.

Now that we have some idea about who and what we’re looking for, it’s time to dig into the technical investigation phase of incident response. We call this the Fix phase.

Get Intelligence-Driven Incident Response, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial