Connect RE&CT with Threat Detection/Hunting, Detection Rules, etc

[yugoslavskiy]

The context

We need to be on the same page to discuss the problem and solution of Incident Response (IR) and Threat Detection (TD) connection. Here is some information that will provide you with the required context.

Threat Hunting or Threat Detection?

There are many definitions of Threat Hunting (and while I am writing this message there would be a new one invented), but here are some most common ones:

1. Proactive hypothesis-based search for threats
2. The way to detect a malicious activity that wasn't detected by automated systems
3. Retrospective search through old data with a new Intel

There are many others, so it's really confusing.
You never know what people mean when they say "Threat Hunting".
And usually, the first thing I do is ask "what is your definition?".

But we are not going to focus on it.

The point here is that anyway, Threat Hunting is always about proactively detecting a threat.
Threat Hunting is a method, a function, an approach of Threat Detection.

Threat Detection is a wider area that includes all methods of detection.

This simplification helps us to be on the same page.

Where IR and TD processes intersect

The Identification Stage of the Incident Response process includes searches/lookups for malicious activity.

When there is a confirmed intrusion ongoing (an attacker is already inside the infrastructure), the Incident Response Team needs to know which hosts/assets were attacked. It could be done by searching for discovered IoC/IoA (related to the operating Threat Actor) for the entire infrastructure and developing new Detection Rules for further attacks.

At the same time, these activities (Detection Rules development, IoC/IoA lookups) are executed by the Threat Detection Team, when there is no ongoing intrusion, during the normal operations. In that case, the source of intel (IoC/IoA) is not the IR process/team but Cyber Threat Intelligence — threat research activities, threat intel feeds, etc.

But it wasn't always this way.

Historical background: TD as a part of IR

In the early to mid-2010s, there were not so many Detection Engineers and information about Threat Detection in general. That time, it was nearly impossible to find information about logs you need to collect, artifacts left by some adversary's TTPs, and any possible ways to detect malicious activity. Of course, there were some research papers on specific attack techniques detection (i.e., DNS tunneling) published, but it wasn't systematized knowledge or an established area of focus.

The only place where detection techniques were somehow collected/systematized was the DFIR area — Digital Forensics & Incident Response articles, courses, books, blogs, researches, etc.

A good example is SANS FOR572 — Advanced Network Forensics & Analysis training, where you could learn how to detect network attacks/malicious activities using networking data.

I felt like only Incident Responders supposed to know how to detect threats, and the only time for it is the ongoing incident.

Mid-2010s, time to change

With time, the global community realized that we need to shift focus from reactive to proactive detection, based not on the ongoing incident and observed IoC/IoA, but by applying general knowledge about threats and researching the TTP in advance. "Intel-Driven" aka "Threat-Based" aka "Threat-Informed" defense started getting more and more popular. MITRE published ATT&CK. This idea started being more and more clear, understood, and getting popular.

And with that — Threat Detection, Threat Simulation, and other areas also grew up quickly. There were (and still are):

• Offensive Security Tools™ detection researches published
• Community Detection Rules collections released
• Community Simulation Tests collections released
• Projects that help to analyze and connect these analytics

And many more.

Later in 2018, SANS renamed the "Advanced Network Forensics & Analysis" training to "Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response" without a dramatic change in its content

There were many signs of ongoing transformation.
The signs that proactive detection is on its way to becoming an independent, separate process of Security Operations.

And now, in 2020, nobody questions that. But still, there is some level of uncertainty.

Back to the topic: The problem

The border between Incident Response (IR) and Threat Detection (TD) is not clearly defined because TD is a relatively new area. It is being established. Or it is already established, but not for all.

If we go "the old" way (not separating TD functions from IR), we would have to develop Response Actions to lookup Indicators of Attack for every potentially malicious activity. And that is all MITRE ATT&CK techniques. And this will make RE&CT extremely comprehensive, hard to understand, hard to maintain, and less useful.

The solution

Go "the new" way. Describe connections between IR and TD processes. Leave in RE&CT only things that are not included in TD, and used exclusively by IR teams. Provide a high-level description of the things that are used by both IR and TD.

The question for the discussion

How to define that split between IR and TD?
How to not go too deep into TD stuff and focus more on IR stuff?

The current proposal and the way RE&CT has been developed so far:

Move forward with investigative searches. The lookups that will help to explain the connection between particular processes/actions on a compromised system. The searches that will help to pivot from one evidence to another.

The only question here is how to organize (develop) Response Actions like "lookups for well-known malicious/suspicious activity", i.e., persistence artifacts, ASEPs, process injections, lateral movement, etc.

We could split them by ATT&CK tactics, creating Response Action per Tactic, i.e. "Lookup for Lateral Movement artifacts".

What do you think?

[socologize]

I was seeing it from your point of view and while I am building content to share with your project and our folks. Identification is more than just a dead ringer detection (good in itself), but also scoping the incident and looking for other tactics.

Because if you are using the techniques to detect, you need to validate and respond to the tactic and follow the attack flow forward and reverse. If you find execution... Did you find privilege escalation or credential actions? Did you find the delivery mechanism?

Techniques can give you a mirada of things to check for with TD and never ending with TH. Because there is an inverse relationship to false positive and false negative detections which is the more you tune out false positives the more you tune in a false negative (true positive) that you can't see. By using the other Tactics as an identification / investigative task you can minimize the chances of missing something you tuned out.

My approach to your project slightly changed in two distinct ways. Customization of the phases to include non-security use cases and different phase interpretations (one I know you have already discussed) and lastly, using phases as compartmentalized process. Example: "investigate - Execution" phase has all the necessary components for that phase and can be used regardless of the attack vector (email, web, host, external device, network). This makes the phases modular and reusable.

So in summary, I would take a more AT&ACK Tactic approach mentioned to validating a detection vs single end to end use case approach to each detection to IR response... This way you can consolidate and reuse responses effectively independent of the TD and techniques.

[reg-reginald]

@socologize I like the concept of

investigate - Execution

and I use a similar method in thehive where I group by ATT&CK tactics. I'd be keen to speak with you more about your implementation

@yugoslavskiy please correct me if I'm wrong. I get the impression that you associate ATT&CK with TH & TD but not IR?

The way I have been implementing the framework for a compromised workstation playbook is by using the ATT&CK framework - especially the tactics - to guide what an analyst should look for (most IR tools use the same data sources).

For example:

#Execution 
analyse_SRUM
analyse_PowerShell_logs
analyse_prefetch 

#Persistence
analyse_run_keys
analyse_startup_folders
analyse_scheduled_tasks

#c2
analyse_DNS_cache
analyse_network_connections

I agree to some degree with

this will make RE&CT extremely comprehensive, hard to understand, hard to maintain,

A way around this would be the ability for subgroups (Initial Action, Execution etc). This would probably a drastic change for the framework but for a compromised workstation playbook (which arguably would be used the most), imo of course, this makes the most sense.

[yugoslavskiy]

Hello @reg-reginald!

Thank you for your interest in the project!

I get the impression that you associate ATT&CK with TH & TD but not IR?

Not really. Short answer: Both ATT&CK and RE&CT could be used for IR. I just don't see the reason why we need to copy the ATT&CK part to the RE&CT, as it could stay there and we can just use references to it; Currently, we are looking for a solution to work it out.

What I've tried to say is that there are functions that both TD and IR use to achieve their goals, and the intersection is in the Identification stage.

As there is already a separate framework that classifies threat behaviors and helps people to Detect threats, there is no reason to copy/paste the stuff to RE&CT.
That would be extra work that will require huge efforts without a huge outcome.

What we really need, is to identify borders and connections with the TD process, that relies on ATT&CK. That would be an optimal way in my opinion.

A way around this would be the ability for subgroups (Initial Action, Execution etc).

Could you please elaborate on this?

but for a compromised workstation playbook (which arguably would be used the most)

The compromised workstation playbook could include most of the existing Response Actions and even more.
It's better to define it more specifically and develop/apply a separate playbook for a specific situation.

At the same time, the playbooks have a very limited scope of cases (simple ones), as most of the complex attacks require a very complex chain of Response Actions, coordination and cannot be described in one playbook (at least in the way it would be useful for a team).

That's why our focus at the moment is to define atomic Response Actions and describe how to make them work in the most efficient way. Then users will compile the Playbooks for themselves, as they are quite different for each organization.

[huntevil]

The border between Incident Response (IR) and Threat Detection (TD) is not clearly defined

I believe that line is, or should be, well defined.

Incident Detection (Threat Detection) is the activity typically performed by the Security team (Cyber or Physical) to determine if suspicious activity is malicious/criminal (a threat) through analysis/investigation/evidence collection/review.

Incident Response is the activity initiated by the Cyber/Physical Security team but performed (or should be performed) by teams other than the Security teams to contain/isolate, eradicate, and recover from the 'incident'. Security can/should oversee those activities, and provide facts/evidence of whats been discovered to guide it.

In some limited cases, the Cyber team can be 'deputized/authorized' to perform limited containment activities (isolate workstations and/or single user accounts, etc).

Beyond that, for me, the 'business' and/or infrastructure teams should be making the decisions (which critical servers/systems/accounts/processes to isolate/disable/shutdown etc), performing the hands on keyboard activities, and they 'should' have DR plans to be followed to recover and restore operations that their teams follow to restore the business back to normal.

Retrospective search through old data with a new Intel

This is my vote and personally I think it its the same as this.

Proactive hypothesis-based search for threats

A good hypothesis should be based on intel. If it's not based on intel its 'chasing rabbits' to me and typically doesn't find anything actually criminal.

When someone hunts deer - will they more likely have a successful hunt if they pick a spot with deer feeders and wildlife cameras showing there are actual deer in the area or would they be more successful if they wanted to 'make it a challenge' and wander around in the back country hoping to cross paths with a 68 point buck? To be a successful hunter, you leverage intel to increase your chances of success. I could have made a football analogy using watching film of your opponents, but I recently went on a successful deer hunt (for me) and decided that analogy would be the one since my son wanted to wander around and try to 'stalk his deer'.. You can guess how that turned out.. lol

[Karneades]

I was thinking again about this issue and thought how about making atc-detect (aka DET&CT) to collect these threat detection activities which are used to prepare, detect, share and communicate in the broader area of threat detection. These steps are important during IR for the TD part / getting more context but too during threat detection outside of incident reponse. While searching for DET&CT I came across DeTT&CT Mapping your Blue Team to MITRE ATT&CK™, their Github Repo DeTTECT and their editor.

If we go "the old" way (not separating TD functions from IR), we would have to develop Response Actions to lookup Indicators of Attack for every potentially malicious activity. And that is all MITRE ATT&CK techniques. And this will make RE&CT extremely comprehensive, hard to understand, hard to maintain, and less useful.

Agree. Adding every counterpart for an ATT&CK technique overloads the IR RE&CT framework.

The solution
Go "the new" way. Describe connections between IR and TD processes. Leave in RE&CT only things that are not included in TD, and used exclusively by IR teams. Provide a high-level description of the things that are used by both IR and TD.
...
The only question here is how to organize (develop) Response Actions like "lookups for well-known malicious/suspicious activity", i.e., persistence artifacts, ASEPs, process injections, lateral movement, etc.

We could split them by ATT&CK tactics, creating Response Action per Tactic, i.e. "Lookup for Lateral Movement artifacts".

So basically, you suggest to bring more response actions to RE&CT from the view of ATT&CK but omit having each techniques covered individually. The use of the tactic is a good way and someone would then jump to ATT&CK for detailed information what to detect exactly. Instead of

• Detect the abuse of local accounts
• Detect rogue accounts on system based on good known
• Detect rogue accounts on system based on known bad
• Detect rogue source IPs based on indicators
• Detect data exfiltration over covert channel
• ...

we would then add more abstract response actions like

• Identify lateral movement
• Identify persistence
• Identify exfiltration
• ...

Here it is important to have a clear way to add specific actions (listing registry keys, listing processes) vs. these generic one for ATT&CK tactic because they will overlap. I currently don't know where the line should be.

And here some ideas (for DET&CT or RE&CT?) with more threat detection focused actions..

• Prepare tool for information sharing
• Prepare tool for integration of threat feeds
• Prepare continious monitoring for threat feeds
• Prepare remote forensics tool to collect forensic evidence
• Prepare tool with pattern matching capability for processes and files
• Prepare detection rule deployment
• Test your detections of current techniques using adversary simulation
• Understand and get to know current attack tactics and techniques
• Find related domain to known IOA/IOC
• Find related files to given malware sample
• Find outliers in persistence mechanisms
• Find registry keys with unusual values, e.g. rundll32, javascript, mshta, ...
• Detect DGA domains
• Add IoC/IoA to continious monitoring
• Add detection rule for attack techniques to continious monitoring
• Share detection rule
• Share new insights with the community
• ...