One of the more helpful things new analysts can do is to read about different sorts of attacks and understand the timeline of events that occurred in them. This enables something called forecasting, which is an essential skill. Let's talk about that. 1/
Any alert or finding that launches an investigation represents a point on a potential attack timeline. That timeline already exists, but the analyst has to discover its remaining elements to decide if it's malicious and if action should be taken. 2/
Good analysts look at an event and consider what sort of other events could have led to it or followed it that would help them make a judgement about the sequences disposition. 3/
This is where forecasting comes in. Analysts come up with potential timelines that could exist. Then, they ask investigative questions to try and narrow down the one that actually exists. This is bridging perception to reality. 4/
You can try this yourself. Consider an alert from this Sigma rule where a user was denied access to login to a system through RDP:…. 5/
Now, take a few minutes and think about the sequence of events that could be associated with this alert. It helps to break this up into preceding (what led to this) and succeeding (what happened after this) portions of the timeline. 6/
Starting w/ preceding timeline, this might be malicious if you see:
- Similar attempts from the source
- Suspicious downloads from the source
- Suspicious executions from the source
- Events occurring outside normal user baseline
- Evidence of cred dumping on the source
The idea here is that if an attacker is making these attempts, they probably have some foothold on the source host which would mean some other specific events likely already occurred. 8/
For the succeeding portion of the timeline, if it were malicious you might see:
- Similar attempts on other hosts
- Continued scanning from the source
- Attempts to access other services on the target
- An eventual successful RDP login
- Attempts to use those creds elsewhere
The idea here is that the attacker might be targeting this system for a reason and may make additional attempts to access it using stolen credentials after this attempt failed. Or they might use stolen creds somewhere else. 10/
In this scenario, the analyst is able to ask focused investigative questions because they know 1) what would have had to have happened for the attacker to get here, 2) what else the attacker might do based on the result of this event. 11/
Analysts gain this knowledge by dissecting and internalizing other attacks. That occurs at multiple levels of abstraction. 12/
The high level describes broad attack life cycles. For example, knowing that recon often occurs before exploitation or that establishing a foothold often comes after the initial compromise. 13/
The low level describes specific system stimulus and response. For example, knowing that PsExec executed on a source system means that some application may have executed on a remote target. Or, that exec of a cred dumping tool may mean use of those creds on other systems. 14/
I like to think of this forecasting process like Doctor Strange sitting around looking into all the potential futures. But, instead you're looking at all the different pasts that could have occurred instead. 15/
Of course, there are a lot of things that go into deciding which timeline you want to try and prove exists and only one does. Something I talk about often is that, in many cases, it's fastest to try and prove something is benign before you prove it is malicious. 16/
In the earlier example from this thread, it's also likely that the user on the source machine typed the wrong system name or IP when using RDP and it was a mistake. That's easy to investigate -- just call them. But it still requires forecasting. 17/
All told, as a new analyst you want to read about lots of different attacks and understand the timeline of events that happened and what led from one to another. You need to do this with different types of attacks (spyware, ransomware, automated, human-driven, and so on.) 18/
Remember, expertise isn't truly measured in years alone. It's also measured in the diversity of your experiences. We can't all experience lots and lots of breaches, but you can read about them! There's no shortage of examples. 19/
The ability to forecast potential timelines from various points in an investigation is a core, crucial analyst skill. Like all those other skills, you can get better at it with deliberate practice. 20/20

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Chris Sanders 🍯

Chris Sanders 🍯 Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @chrissanders88

24 Jun
While we're doing a Detection Engineering AMA, how do you build these sorta skills if you want to do that job for a living? Big question, but I'd focus on three areas for early career folks...
Investigative Experience -- Tuning detection involves investigating alerts from signatures so you need to be able to do that at some level. A year or two of SOC experience is a good way to start.
Detection Syntax -- You have to be able to express detection logic. Suricata for network traffic, Sigma for logs, YARA for files. Learn those and you can detect a lot of evil. They translate well to vendor-specific stuff.
Read 8 tweets
24 Jun
This relates to my 4th and 5th reasons why these decisions happen -- AV company tactics and giving folks what they need to tune rules. That actually means GIVING analysts the rule logic. I could go on and on about this.
Most companies don't want to give out their rule logic because they see it as a sensitive trade secret. This is nonsense. A rule set isn't a detection companies most valuable intellectual property, it's their processes for creating those rules and the staff that do the work.
Limiting access to detection logic makes it harder for your customer. It is MUCH more difficult to investigate alerts when you don't know what they are actually detecting and how they're doing it.
Read 9 tweets
24 Jun
I usually see two things.

1. Analysts don't have the skills to perform tuning.

2. Management won't prioritize time for it or train analysts to do it.

I rarely see #2 get rectified until new management comes in who understands the importance of tuning.
I've seen many good analysts give clear, compelling explanations as to why tuning is important but fail to convince the decision-makers that this needs a dedicated person or a day a week from an existing person.
The thing that needs to become more commonly accepted is that if you decide your company needs a SOC, then that has to include a detection tuning capability. It also needs to be run by people who've seen this thing work well.
Read 5 tweets
24 Jun
Nope. There's often not even agreement within different detection teams in the same company.

I know of vendors who have used 5+ different languages to express detection logic at various points. Messy.
Some of these are companies that developed their own "standard" for expressing detection logic and don't even use it in most of their tools 😂
This comes from a lot of places. Usually, someone develops a detection tool by themselves or part of a small or isolated team and they choose what they want, then the project grows and it becomes painful to change it.
Read 5 tweets
24 Jun
There's often interesting public discussion about vendor detection tools and what they detect vs expectations. There's some interesting decision making that happens behind the scenes at these vendors when it comes to how they manage detection signatures. A thread... 1/
At a vendor, when you build a detection ruleset for lots of customers, you have to approach things a bit uniquely because you don't control the network where these rules are deployed and can't tune them yourself. 2/
One facet of this challenge is a decision regarding how you prioritize rule efficacy...we're talking accuracy/precision and the number of false positives that analysts have to investigate and tune. 3/
Read 18 tweets
22 Jun
I'm really excited to share that our newest online class, Detection Engineering with Sigma, is open this morning. You can learn more and register at

The course is discounted for launch until next Friday. Image
If you're not familiar with @sigma_hq, you should be! It's the open standard detection signature format for logs. Said another way, Sigma is for logs what Snort/Suricata are for network traffic and YARA is for files.
Perhaps the best thing about Sigma is that you can easily convert its rules into LOTS of other formats using the Sigmac tool. Things like Elastic, Splunk, Graylog, NetWitness, Carbon Black, and so on. Image
Read 11 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!