Following on from my last blog post, which detailed how I’d approach analysing a firewall log, the room I’m currently working through on THM (Network Security Essentials) challenges you to investigate a breach.
This challenge provides you with the steps to follow which weren’t entirely dissimilar from the approach I took for analysing a firewall log, but goes into more detail and expands upon the previous commands I used.
Incident Scenario
“Initech Corp, a mid-sized financial services company, has recently deployed a new firewall and intrusion detection system (IDS) to monitor its network perimeter. Over the past month, security analysts have noticed abnormal traffic patterns, but the SOC team has been overwhelmed and missed deeper analysis.
As a new security analyst, you have been tasked with reviewing one month of perimeter logs to determine what techniques the adversary used, and whether they succeeded in breaching the perimeter.”
The scenario also provides three sets of logs from the time of the incident which are as follows:
Firewall Logs: firewall.log
WAF Logs: ids_alerts.log
VPN Logs: vpn_auth.log
The challenge also provides you with details of Initech Corp’s network assets to use as a reference.
Manual Log Analysis
To start with, THM says to use the ‘head’ command to look at each of the log files. This was similar to the approach I took when looking at the firewall log in my previous blog post.
Firewall.log
ids_alerts.log
vpn_auth.log
Reconnaissance Attempt
Next, THM says to begin the analysis by looking at blocked requests in the firewall log.
From this, we can see that the external IP of 203.0.113.45 has been probing multiple internal IPs using ports 21, 22, 23, 445 and 4444.
There were also some blocked attempts from the IP 203.0.113.10 but the majority here and which appear to show reconnaissance is the IP 203.0.113.45.
The internal IP probed here is for the File/Finance Server (10.0.0.20). And the ports scanned were FTP (21), SSH (22), Telnet (23), SMB (445) and port 4444 which is a a commonly used, but non-standard, network port with various legitimate uses.
Next, THM says to use the following filtering to understand which IP is responsible for the maximum number of ‘BLOCK’ requests, which in this case is 203.0.113.45.
As I’m already familiar with the cat command, piping, and grep, I won’t explain what they do here. However, I’d like to explain what the rest of the command and filtering is doing in the remaining segment of ‘cut -d’ ‘ -f5 | cut -d: -f1 | sort -nr | uniq -c’.
Please note, the IP of 203.0.113.10 in the example below is different from the IP identified above of 203.0.113.45. And I’m just using the screenshot below taken for the firewall log to explain what the filters are doing.
cut– extracts sections of text
-d ‘ ‘ – use a space as the delimiter
-f5 – selects the 5th field
So, the first part of the filter ‘cut -d ‘ ‘ -f5’ means to split each line wherever there is a space, and to give me the fifth chunk of the text from the file.
And the fifth chunk of text in the firewall log that’s separated by a space is ‘203.0.113.10:64292‘ for example.
This part of the filter is then piped to the next filter which is ‘cut -d: -f1‘.
What this part of the filter is doing is taking the output from the previous filter, and then sorting things further, by splitting the text where there is a colon and giving me the first part of that.
So, the output from the previous part of the filter is ‘203.0.113.10:64292‘ with the first part being ‘203.0.113.10’ and the second part being ‘64292’. And as we’re only asking for the first part, then we should only be getting ‘203.0.113.10’ with the filter ‘cut -d: -f1’ .
Essentially what’s happening here is that delimiters are being chained with the first delimiter isolating the IP and the port, and the second delimiter then removing the port from the output result.
The final part of the filter ‘sort -nr’ and ‘uniq -c’ then tidies things up further with ‘sort -nr’ sorting numerically and descending, and ‘uniq -c’ removing duplicate lines and counting them. And the final result we then get is as follows.
Now, since we’ve identified a suspicious IP we can examine other log files to try and correlate things. For example, we can check to see if the firewall has allowed any requests from the suspicious IP 203.0.113.45.
Based on the output here, it appears an attacker has managed to gain access to the network. So, we can now look at the VPN logs to see if there are further footprints of the attack.
For example, we can look for evidence of brute-force or credential access.
VPN Brute-force / Credential Access
We can first look at the number of failed attempts using the command ‘cat vpn_auth.log | grep FAIL | cut -d’ ‘ -f3 | sort -nr | uniq -c’.
Similar to before, ‘cut -d’ ‘ -f3’ will filter for the following field, using space as the delimiter.
And the full command produces the following.
From this, we can see multiple failed VPN login attempts with a significant amount coming from 203.0.113.45.
We can also narrow things down further on the suspicious IP as follows.
This pattern of failed attempts using the username ‘svc_backup’ continues for quite some time in the logs, and eventually leads to a successful login with the attacker first assigned a local IP of 10.8.0.23.
From here, we can extend the analysis and look for further traces in the log files.
Lateral Movement
At this point, we’ve confirmed an attacker has gained initial access and obtained an internal IP address. So, we can now filter through the firewall logs to see if we can find any more footprints of lateral movement from the compromised host with the IP of 10.8.0.23.
We can see the compromised IP 10.8.0.23 probing other internal machines such as 10.0.0.20 (File/Finance Server), 10.0.0.51 (Internal Web/App) and 10.0.0.60 (Employee Workstation) on ports 22 (SSH), 445 (SMB) and 3389 (RDP).
Now going back to ids_alerts.log, we can filter through the compromised IP to see if any intrusion rules were triggered.
From this, we can see that the compromised IP is trying to exploit various vulnerabilities against the services mentioned on the hosts above, and one of the alerts indicates SMB exploit. So we can again narrow down our search further with the following query.
I’d like to highlight here that ‘grep -n’ just prefixes each matching line with its line number in the file. Whereas ‘head’ on it’s own will just give me the first 10 lines in the file.
Having reviewed the results from the command above, these confirm that the compromised host with the IP 10.8.0.23 was able to exploit the SMB service to achieve lateral movement.
C2 Beaconing
Now we’ve identified evidence of lateral movement, we can look for any indicators of C2 communications.
And if we look at the IDS alerts, we can find a specific alert relating to this using ‘cat ids_alerts.log | grep C2 | head’ which confirms our suspicions against one of the internal compromised hosts (10.0.0.60).
We can then filter against the compromised IP responsible for the C2 beaconing with ‘cat ids_alerts.log | grep -n 10.0.0.60 | cut -d’ ‘ -f6,7,8,9,10,19,22,23 | head -n 15’.
This further affirms that the infected host is performing suspicious activities.
Now, using a similar command to before, but with the addition of the ‘uniq -c’ and ‘sort -nr’ filters, we can see the stats of the alerts triggered against the infected host.
This now confirms that our network is fully compromised, and we’ve also identified the external IP acting as the C2 server (198.51.100.77) receiving the C2 beacons from our compromised host IP of 10.0.0.60.
From here, we can further look at the external IP using the same command as before but swapping out the IP as follows.
Data Exfiltration
Now, we can look for evidence of any data being exfiltrated from the network on any compromised hosts, using the following command and grepping with the C2 server IP.
Here, we can see a significant amount of traffic coming from 10.0.0.51 on ports 80 and 8080 going to the external IP address of 198.51.100.77.
Finally, we can also filter on IDS logs, to see the alerts being triggered on these activities from the internal IP 10.0.0.51, which further confirms that data is being exfiltrated via 10.0.0.51.
Conclusion
Having now followed this walkthrough, I was able to gain a better understanding of how to investigate a breach and what actions a SOC analyst would take.
Whilst this is the second time I’ve gone through this task, I feel I could benefit from more practice. So moving forwards, I’ll try to find other challenges I can work through both on THM and independently.
Overall though, I’m certain that with more practice, I’ll become proficient and eventually able to carry out an analysis quickly, accurately, and to the standard required of a SOC analyst in a real world environment.
Finally, I was glad to see that after working through this task, I was able to successfully answer all of the questions asked by THM at the end of this task.
