In continuation of my first post, picking up where we left off, the second question I would attempt to answer is how to carry out extended searches.
I have encountered new Analysts in the SOC often confused when it comes to carrying out extended searches during security investigations. I often hear questions like, “how do I know the parameters and filters to use for my extended searches?” This article aims to highlight some methodologies that can be used by Analysts to refine searches during security investigations.
Security alerts trigger based on a given set of conditions or filters as stated in my previous article (Refer to how to identify a false or true positive). These conditions will often be based on known indicators of attacks and compromise, specific tactics or techniques, compliance related or anomalies. This implies that the events that contribute to the triggered alert may not have all the information on the attack
chain. What does this mean in terms of our investigation technique: The who, what, why, when, how, and where?
It means that every alert may have events that contain the what, the where, and sometimes the who depending on the data source. The How however, is the make-up of everything that led to the investigation which is not always in the events that contributed to the alert. Investigating security events are like putting together a jigsaw puzzle to see the bigger picture. As an analyst your investigation should always aim to answer the 6 questions. This leads us to discuss some ways of identifying the parameters for extended searches.
- Answer the who, what, why, when, how and where. If any of the answers to these questions are missing, this gives you the basis to perform extended searches. In searching, you need to know the data sources that will help you answer the question.
The Who: authentication logs, event logs. You have the time the event generated, you know the source and destination. These automatically becomes the filters for your extended searches but now, you are focusing on a different data source.
The How: This is a complex question that must be unpacked based on the what. You might not always be able to answer the how, but you can attempt to fill in the blanks as much as you can.
As an example, you are investigating a remote password spraying attack. You aim to answer how this happened. The first thing is to understand the service or destination port the attempt is made to. Since it is remote, this must mean that somehow attackers were able to reach port over the internet. The next question is how did attackers know it was exposed? Was a scan carried out prior, is there a web portal everyone could reach or was a user’s laptop compromised? Was the remote password spraying attack successful? These are all questions that helps to drill into the how and identify the parameters for extended searches. - Map the alert to the attack stages identified by any of the cybersecurity frameworks such as MITRE, kill chain and Mandiant. If a tactic leveraging a certain technique was successful, then you want to walk back to identify the point of initial access often referred to as patient Zero. A good example is when you identify a host communicating with a command-and-control server.
Command and Control is towards the end of the attack lifecycle even though attack phases aren’t linear, but the constant factor is that the first tactic will always be initial access which implies that there must have been a point of initial compromise. It isn’t enough to say it is false
positive because the communication was blocked by the firewall. The alert is just a symptom, what is the cause? Why did the host start to initiate the communication? Who or what (process or user) is initiating the communication? In this case, good data sources will be the endpoint and firewall logs. - Follow the crumbs. An internal host is involved in a security event, check the logs for the specific host shortly before the security alert triggered. Whatever happened must have occurred before. Check the activities of the user involved if it deviates from the standard activities (this would be an anomaly-based investigation). An example is check for authentications from new location by the user, recent password change activities, multiple connections to other hosts. This is basically
using the information you have to find the information you do not have.
The above shows that as an Analyst, you must have qualifying questions you seek to answer through your investigation and identify the data sources that will help you answer those questions.
In summary, why should extended searches be performed?
- To identify the point of initial compromise.
- To identify the extent of the impact in the case of a true positive event.
- To qualify an investigation as True or False positive.
- To identify security risks that should be promptly mitigated.
Leave a comment