Threat Detected, What Next?
Do you have a business that has been the victim of a cyber attack? If so, then you might be wondering if it’s even worth your time to investigate what happened. It may seem like there are plenty of other security concerns to deal with first, but investigating breaches is important for several reasons. Let me illustrate a live investigation case using DNIF HyperScale SIEM which makes investigating cybersecurity incidents extremely smooth.
DNIF provides various integrations which can be used to carry out investigations and responses easily for containment of an incident.
Let us consider a Brute Force attack scenario. On the Signals page in the following screenshot, I see a list of signals. What next? How do I go about with my investigation? Here’s how DNIF can help you.
Our first steps would be Triage. Collect all the information — you can see the detection name is ‘Brute Force Attack’ and ‘Suspected’ source is 41.67.XXX.XX
To get more information about the suspected source, I made use of the following Lookup panel
A VirusTotal lookup showed the Location of the suspected source as NG(Nigeria), however, since my organisation does not have any branches there, according to me logins from Nigeria would be least likely. I researched more to be sure though.
I opened this workbook with Time Travel, to know the logic of the detection that triggered the signal. I ran the workbook to see if there was an explanation for what caused them. I could see 153 failed login attempts from the suspected source IP whereas there are 3 successful logins.
I then used Authentication logs to find out the users who were successfully logging in from the suspected IP. I looked them up and figured out their base location is shown as UK.
I checked the user’s login history for the past day to investigate further. The only successful logins were from the UK. This can mean one of two possibilities, that either there was a breach of security or that one user is logging into two different locations at the same time.
Now that I see all the evidence pointing towards this brute force attack being a true positive, I took steps to contain the users who were compromised.
Active Directory’s integration with DNIF will reset the user’s password in a click. In our example, successful logins were seen on Microsoft o365, and in order to stop attackers from accessing a user’s mailbox, I initiated a process to migrate the user’s mailbox. I followed the containment procedures for the compromised users.
The compromised users have been dealt with and it is now time to work on the damage caused by the attacker.
I created a list of all the things accessed by the compromised users and reviewed all the actions taken by them during the time of compromise. I then reviewed their access logs, compared them to any other similar incidents, and made sure that no one else could have gained access.
Next, I reverted any changes that had caused damage and contained them.
This has brought us to the end as everything compromised has been contained, going back to where we left off. I got a list of any other users from my organisation whose logins were attempted by the attacker and failed. I saw a few users here, but since they failed we need not take any actions for these. Now I know that the attacker has a list of credentials from my organisation. I did not block the IP as blocking IP addresses can help prevent unauthorised access, but it leaves you vulnerable to distributed brute force. Instead I added it to a watch list to monitor any other successful login attempts from the suspected IP.
This is how we investigate and contain a brute force attack using DNIF. Any kind of attack is critical, but if you take the right steps, you can recover your system to normal operation.
Blog by: Sharron Quadros