Investigate Three
Analysis
In this post, I explain analysis and the associated techniques to mean at the lowest possible level a human’s ability to consume external stimulus of its near-infinite complexity and produce thoughtful and data-backed decisions.
Within our industry, we are plagued with information twisted and corrupted by entities wishing to profit, As such this is where your analysis starts as a human. At every moment at every crossroad, you must take a data point and allow it to flower into thousands of other thoughts, then you must evaluate each subsequent thought and draw a line back to “what is already” known, The further away the thought the thinner the line back to known but the greater room the flower to bloom. That is to say don’t discount radical ideas.
When presented with an alert security vendors expend significant energy into putting “options” available to the individual reviewing the alert. In general, there will never be an option you should not explore what is key is evaluating the options to what you already know (drawing the ling back) and asking yourself if is this the best possible option to go with first.
With what’s often described as low-hanging fruit those options that you can consciously recall aiding you a benefit in the past maybe the best option but were those options picked last time just because they were new or do you have documentation?
Dilemma
Analysis & Triage
Tool Knowledge
First and foremost equip yourself with a tool and understand all its facets and features, understand when an option will work and how your expecting it to behave, options are grouped together by types as assigned by UX/UI developers so identify where those groups are to get to other options faster.
Investigative Questions
These are the queries you ask of the data you have retrieved whether this is literal data in a computer system or visualizations and graphics as part of interfaces. To begin we can start as simple as possible:
What is this alert about?
Well, the top heading on the page under the option ‘Manage Alert’ details “Possible theft of passwords and other sensitive browser information”. With this information, we know immediately the adversary is already on the system and information such as credit cards and corporate authentication information may be at risk.
We also know that browsers keep their data in sqlite databases in directories like LocalAppData\Google\Chrome\User Data\Default\Login Data. So Already we have have our first investigative question and a strong lead to pursue
Were there any interactions with sensitive browser locations?
If so was activity observed on any other assets?
Were further payloads delivered to the system?
We know that adversaries often rely on low-sophistication techniques to pass initial access and establish a foothold to ensure they are not prevented too early into their kill chain so other files being involved is likely. Selecting the alert within the timeline reveals other binaries
Now we have a collection of new questions to explore
What operations have the newly found files done?
What information can we gather on the IP address?
And with that, we have already established 6 investigative questions to explore further and add to your triage notes.
What makes a
good investigative question?
Investigative questions that are comprised of
already enumerated information and recognition of patterns are the heart of a
complete investigation. Investigative questions can be divided into two primary
groups
What is that?
These investigative questions aim to give you information that previously made
you feel like you were not currently equipped to arrive at causality, they
contribute to a concrete foundation from other questions and even declarations
can stand. Common examples of these questions are “Does this file or address
have known threat intelligence against it” or “Is the file new to the system”
I wonder if?
These investigative
questions serve to play to your own creativity and intuitiveness, for example,
its universally shared persistence is an incredibly common adversary objective
so you may ask yourself where could that be established on your system or
preceding that thought where would an adversary give away were they kept their
persistence perhaps a temp file or command line history
Applying what you know an
adversary could do and your own expertise as to what adversaries have done will
defeat most incidents.
Its Grasp on You
As an analyst performing analysis, especially during what is perceived to be a major incident you have to achieve the quality of thought and considerations of facts at a pace not often expected of humans in any other situations. Personally, it feels like I injected adrenaline into my thigh (I'm addicted). Fortunately, analysis during a live engagement has only four focuses and these are listed in priority:
Get to a reasonable statement of facts quickly
In the most immediate possible instance you need a minor conclusion on to what you can see is happening and the criticality of the events. Usually, it's pretty easy to gather scope and or a patient 0 so ensure that is captured in your initial notification of a major breach. This first statement needs to remain unified when communicated by any party and discrepancies should be highlighted
Discover adversary behaviour in detail
At this point, you will want to prioritize speed over accuracy but do ensure you can look back at what you have recorded and have enough metadata to justify its inclusion.
Create a formal timeline
Once you have gathered the information and validated its relevancy add each item to a list in chronological order.
Formulate a summary of events
Ensure you review the data you have and begin detailing what the adversary achieved, what they looked to achieve further and if possible what their final objective likely was. It is also important not to fill in gaps where data doesn’t exist and instead articulate those gaps with recommendations to prevent the occurrence in the future.