Boss of the SOC Version 1

Introduction

This is a small write up of my first attempt at Boss of the SOC Version 1’s scenarios. This is an ongoing test, so I will be updating it when I can.

Scenario 1: Web Site Defacement

Question #101:

What is the likely IPv4 address of someone from the Po1s0n1vy group scanning imreallynotbatman.com for web application vulnerabilities?

Workings:

I should be on the lookout for hosts that reach out for more than 500 IP’s or ports at the same time, this can indicate scanning.

I first ran a scan on the web address in question.

I next needed to search an actual source type, I needed an IP address. I found that Stream is an app on Splunk that collects data from various different protocols, ftp http etc. Using this I was able to find an IP address that had been routinely interacting with our defaced website.

It looks like the main source of the traffic was coming from a single IP address.

Question #102:

What company created the web vulnerability scanner used by Po1s0n1vy? Type the company name.

Workings:

The next thing on the list to do was finding which type of vulnerability scanner was used. It’s best to look at the headers of the requests sent to our destination IP address.

index=botsv1 src=40.80.148.42 sourcetype=stream:http

It was pretty clear that the scanner used was made by a company called Acunetix.

Another place that you can use to double check is the http_user_agent strings. This also gave the indication that Acunetix was being used.

Question #103:

What content management system is imreallynotbatman.com likely using?

Workings:

This was already revealed to me. I have worked on pen testing Joomla in the past. It is also referenced a bunch in the screenshots above.

Question #104:

What is the name of the file that defaced the imreallynotbatman.com website? Please submit only the name of the file with extension?

Workings:

After finding the destination IP of the attack, I was able to determine the IP address of the web server hosting imreallynotbatman.com.

index=botsv1 src=192.168.250.70 sourcetype=stream:http

I then used that as a source to see what I could find in the headers again.

There is 1 final name in there that sticks out as the answer to this question.

Question #105:

This attack used dynamic DNS to resolve the malicious IP. What fully qualified domain name (FQDN) is associated with this attack?

Workings:

Question #104 gave me the guidance on this answer. The image was hosted on a website in the screenshot below.

Question #106:

What IPv4 address has Po1s0n1vy tied to domains that are pre-staged to attack Wayne Enterprises?

Workings:

This was a case of checking the destination IP addresses that came along with searching for activity on the web hosting server.

Question #107:

What IPv4 address is likely attempting a brute force password attack against imreallynotbatman.com?

Workings:

Now I have to find out what IP address is sending the brute force attacks. I used the following the find what IP address were interacting with the web host IP that I found earlier.

index=botsv1 sourcetype=stream:http dest="192.168.250.70"

It came up with pretty familiar values:

Now I needed to check the GET and POST requests to see where the brute force was coming from.

A POST request could be the indication of a brute force attack. Since they are the majority its worth digging further. I used this to narrow down the search and find any interactions with the web server that contain the data username and password. Using wildcards to capture any anomalies:

index=botsv1 sourcetype=stream:http dest="192.168.250.70" http_method=POST form_data=*username*passwd*

Interestingly enough, after thinking it was 40.80.148.42 address at first because of the sheer amount of POST requests. It turns out it was the 23.22.63.114 address, after using the above query.

Question #111:

GCPD reported that common TTPs (Tactics, Techniques, Procedures) for the Po1s0n1vy APT group, if initial compromise fails, is to send a spear phishing email with custom malware attached to their intended target. This malware is usually connected to Po1s0n1vys initial attack infrastructure. Using research techniques, provide the SHA256 hash of this malware.

Workings:

This one took me a little bit to figure out. I forgot about running different IP address through VirusTotal to find anything malicious associated with them.

It looks like there is a rather suspicious file named MirandaTateScreensaver.scr.exe that has an association with the IP address.

Question #112:

What special hex code is associated with the customized malware discussed in question 111?

Workings:

This answer was a little easier than I thought. Just looking through the comments on the Malware on VirusTotal gave me the answer.

Question #114:

What was the first brute force password used?

Workings:

I search for requests coming from the IP address that I had found previously and looked for form data that was posted in rapid succession and found the password they first tried to use.

Question #115:

One of the passwords in the brute force attack is James Brodsky’s favorite Coldplay song. We are looking for a six character word on this one. Which is it?

Workings:

This one took a little brute forcing from my end. Looking up the most popular Coldplay songs and search them individually.

Question #117:

What was the average password length used in the password brute forcing attempt?

Workings:

After doing a little research I found that you can do a basic maths query. I also needed to find out how to use the rex command to extract data from the field.

index=botsv1 sourcetype=stream:http dest="192.168.250.70" http_method=POST form_data=*username*passwd* src_ip="23.22.63.114"
| rex field=form_data "passwd=(?<passwd>\w+)"
| eval length=len(passwd)
| stats avg(length)

Using rex, I got the field I wanted to search and the term, passwd. I think get the length of the passwords that were used then get the average length of them. This took a little bit of research to get right. The answer being 6, rounded down.

Question #118:

How many seconds elapsed between the time the brute force password scan identified the correct password and the compromised login?

Workings:

So I first need to find the correct login packet. For this, I needed to remove the attacker IP address from the query. So that legitimate ones can also be searched. I first filtered out every query from the IP address that was trying to brute force, using NOT.

index=botsv1 sourcetype=stream:http dest="192.168.250.70" http_method=POST form_data=*username*passwd* NOT src_ip="23.22.63.114"
| table form_data

Then looking into the 1 query that remained and found the password that was used. Then I searched for the use of that password from the brute force IP.

10/08/2016
21:46:33.689

I sort of forgot that the scanner had a different source IP address. So by looking at the different events that contained the password batman. Its quite obvious that it took around 92 seconds to login after the brute force was successful.

Below is the search I used within splunk to find this result.

index=botsv1 sourcetype=stream:http dest="192.168.250.70" http_method=POST ("batman") uri_path="/joomla/administrator/index.php"
| rex field=form_data "passwd=(?<passwd>batman)"
| table src_ip _time