Note - You can view my video writeup below 📺🎬🎥 https://youtu.be/xnjWVL7i7HA 📺🎬🎥
This room covers an incident Handling scenario using Splunk. An incident from a security perspective is "Any event or action, that has a negative consequence on the security of a user/computer or an organization is considered a security incident." Below are a few of the events that would negatively affect the environment when they occurred:
Crashing the system
Execution of an unwanted program
Access to sensitive information from an unauthorized user
A Website being defaced by the attacker
The use of USB devices when there is a restriction in usage is against the company's policy
Learning Objective
Learn how to leverage OSINT sites during an investigation
How to map Attacker's activities to Cyber Kill Chain Phases
How to utilize effective Splunk searches to investigate logs
Understand the importance of host-centric and network-centric log sources
In this exercise, we will investigate a cyber attack in which the attacker defaced an organization's website. This organization has Splunk as a SIEM solution setup. Our task as a Security Analysis would be to investigate this cyber attack and map the attacker's activities into all 7 of the Cyber Kill Chain Phases. It is important to note that we don't need to follow the sequence of the cyber kill chain during the Investigation. One finding in one phase will lead to another finding that may have mapped into some other phase.
Cyber Kill Chain
Scenario
A Big corporate organization Wayne Enterprises has recently faced a cyber-attack where the attackers broke into their network, found their way to their web server, and have successfully defaced their website http://www.imreallynotbatman.com. Their website is now showing the trademark of the attackers with the message YOUR SITE HAS BEEN DEFACED as shown below.
A Big corporate organization Wayne Enterprises has recently faced a cyber-attack where the attackers broke into their network, found their way to their web server, and have successfully defaced their website http://www.imreallynotbatman.com. Their website is now showing the trademark of the attackers with the message YOUR SITE HAS BEEN DEFACED as shown below.
Exploitation
Answer the questions below
1. What was the URI which got multiple brute force attempts?
This is a fun question to get us started. Initially I recalled various directory bruteforcing techniques and as I thought about the process and operations in relation to our end goals, it helped me to paint a picture of what I would be looking for. Firstly, directory brute forcing is typically used through a ready to go tool such as OWASP directory buster, dirb, or in tools within the burp suite platform. Secondly, these tools often just check each URL/directory one at a time. If a directory is found, it will report response code of HTTP/S 200.
However this question forces us to deviate from the standard operation of a directory brute forcing attack or also known as a directory discovery technique. It would not be common for a directory discovery tool to send multiple HTTP GET a requests to a URL. However with brute forcing techniques within the web application context there would be multiple requests to a URL. Typically these requests will be type of 'form data' with encoded content.
The brute forcing aspect forces us to deviate away from the narrow process of directory discovery, as a brute forcing technique on a single URL is indicative of a credential stuffing attack. In a practical context, if a correct password was found you could look for a HTTP response 200, or duplicate form data to realize the step where the attacker logs in to confirm a successful password found.
Our search query aims to return results of web requests that had a response of 200, suggesting a successful response.
Appending the search query with http.url helped to narrow down are scope and then the visualization functions changes our perspective allowing us to quickly identify the URL with the most common queries.
2. Against which username was the brute force attempt made?
While we can make the assumption that the URL from the previous question is the correct URL, I did initially take a step back and operated in the possible world where the URL may in fact be different. In this approach, I started from the top and drilled down noticing the http.url we see several URL's containing 'login'. While I did drill down into the login URL's, this was a dead end with a small exception of a string that did contain admin as a username, but the request was not a type of form-data, nor was it an http response of 200.
Having spent some time reviewing the above URL's, It was time to drill down on one field in particular. The "Form_data" is a highly relevant form field here. The hope is we can format this into a table to quickly review enabling us to effeciently identify form_data of interest.
However there could be many post requests in the logs and some further narrowing down is well warranted. In this case by appending our search query with a form_data field containing the string "username" will hopefully identify login related form data.
index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST form_data=*username*We can see the field of username multiple times, with different passwords. A text book dictionary brute force technique.
3. What was the correct password for admin access to the content management system running imreallynotbatman.com?
I switched up a small portion of the query, just the form data specifier to our known user of "admin". This further narrowed down relevant logs and the password for user admin was quickly identified in the results, as seen in the image below. Granted, I did change the search query to include "http_method=POST" to help narrow down our pool of relevant logs.
index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST form_data=*admin*
Alternatively if we took another approach and enriched our data with stats and tables we could come across the password, by drilling down on our src_ip and form_data in a quick and easy to digest table perspective.
As well, it is worth noting that the use of regular expression is required as apart of the tutorial. The value with the regular expression, is we can extract the info we want from a larger string to make analyzing in a table view more desirable. With the use of regular express, as per the tutorial, we can select the form data field, and extract the password to be reflected in the table, with the below command.
4. How many unique passwords were attempted in the brute force attempt?
This one was simple, as I figured that your typical bruteforce attack involves using a dictionary and going through the entire list. However, I figured that once a successful password was found, the attacker would naturally attempt to formally login. So if we role back the total events we see at the top by 1, while operating under the assumption that each event returned is a unique set of credentials, then we will have all the automated brute force login attempts. We take the total 413 events, and minus 1 for the non automated login, and arrive at 412 which was accepted.
5. What IP address is likely attempting a brute force password attack against imreallynotbatman.com?
This question was a quick win by pivoting fields to "src_ip" and it was clear that the IP address with a 412 count, was the culprit.
6. After finding the correct password, which IP did the attacker use to log in to the admin panel?
This question was increadibly simple as the context acquired to get to this point, has preparred you the participant, to identify the answer readily. We can see the "src_ip" field contains only 2 ip's and if our conjecture from earlier is correct, this second IP maybe the manual login from the attacker, after running an automated tool.
THE END
