Firewall, WAF, and VPN manual log Analysis using command line.

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.

You have been given three sets of logs from the time of the incident. The logs can be found in the Perimeter_logs/challenge directory on the Desktop.


  • Firewall Logs:firewall.log

  • WAF Logs:ids_alerts.log 

  • VPN Logs:vpn_auth.log 






LOG ANALYSIS


Let's start by exploring the logs, as shown below:


Commandline: head firewall.log



Explore ids logs, as shown below:


Commandline: head ids_alerts.log


Examine VPN Logs, as shown below:


Commandline: head vpn_auth.log


Reconnaissance attempt

Let's begin our analysis by analyzing the blocked requests in the firewall logs, as shown below:


Commandline: cat firewall.log | grep "BLOCK" | head

Examining the blocked requests indicates that an external IP has been found probing against internal IPs using various ports (22,23,21,445,3389).


Let's use the following filtering to understand which IP is responsible for the maximum BLOCK requests.

Commandline: cat firewall.log | grep "BLOCK" | cut -d' ' -f5 | cut -d: -f1 | sort -nr | uniq -c



We have identified a suspicious IP, which we can use to pivot, examine other log files, and understand the correlation.


Let's use the following query to find if our firewall has allowed any requests to the suspicious IP, as shown below:


Commandline: cat firewall.log | grep 203.0.113.45 | grep "ALLOW"


It seems that the attacker was able to gain access to the internal network through exploitation. Let's examine the VPN logs and see if we can find further footprints of the attack.

VPN Brute-force / Credential Access


In the VPN Logs, let's first examine the number of failed attempts, using the following command, as shown below:

Commandline: cat vpn_auth.log | grep FAIL | cut -d' ' -f3 | sort -nr | uniq -c



We can clearly see that the suspicious IP has multiple failed VPN login attempts. Let's now use the following command to narrow down on the suspicious IP, as shown below:


Commandline: cat vpn_auth.log | grep 203.0.113.45

Above result shows, that, the multiple login attempt was made against a certain user svc_backup, followed by a success login, resulting in the attacker being assigned a local IP address. We will pick the first assigned IP and extend our analysis to look for traces in the log files.

Lateral Movement

By now, it is confirmed that, that attacker has successfully gained the initial access and got hold on to an internal IP address. Let's filter through the firewall logs and see if we can find the footprints of any lateral movement from the compromised host 10.8.0.23.


Commandline: cat firewall.log | grep 10.8.0.23 | grep "ALLOW" | head  

It is observed that, the compromised IP is probing internal machines 10.0.0.20, 10.0.0.51, 10.0.0.60 on various ports on three main ports SMB/RDP/SSH (445/3389/22). 


Let's now pivot to ids_alerts logs, and filter through the compromised IP and see if we can find any intrusion rules triggered, as shown below:


Commandline: cat ids_alerts.log | grep 10.8.0.23 | head 



It seems, the compromised host is trying to exploit various vulnerabilities against the services mentioned above on those hosts. One of the IDS alerts indicates SMB exploit, which look interesting. Let's narrow down our search by using the following search query:


Commandline: cat ids_alerts.log | grep -n 10.0.0.51 | grep 'SMB' | cut -d' ' -f6,7,8,9,10,19,21 | head


Above results confirm that, the compromised host was able to exploit SMB service and was able to achieve lateral movement.

C2 Beaconing

Now that, we have an evidence of the lateral movement of the attacker. Let's hunt for any indicator of C2 communication. If we look at the IDS alerts, we can find a specific alert related to C2 Beaconing, indicating possible C2 communication. Let's use the following search query to see the results:

Commandline: cat ids_alerts.log | grep C2 | head

clear


It clearly confims our suspicion against one of the internal compromised host.

Let's slice and dice through the results, to filter against the compromised IP responsible for C2 beaconing, as shown below:


Commandline: 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 further performing susicious activities. 


We can use the following command to show the stats of the alerts triggered against infected host.


Commandline: cat ids_alerts.log | grep -n 10.0.0.60 | cut -d' ' -f6,7,8,9,10,19,22,23 | uniq -c | sort -nr | head 


Above analysis clearly indicates that our internal network is fully compromised, and we now have the external IP address acting as a C2 server, recieving the C2 beacons from our compromised host.


Commandline: cat ids_alerts.log | grep -n 198.51.100.77   | cut -d' ' -f6,7,8,9,10,19,22,23 | uniq -c | sort -nr | head 



Data Exfiltration Attempt


Now that, we have identified the C2 communication and examined other alerts as well against suspicious Is, let's now investigate, if there are any indicators of data being exfiltrated out of our network. We will apply filter on the compromised hosts, and examine the traffic originating from those to an external destination IP, as shown below:


Commandline: cat firewall.log | grep 10.0.0.60  | cut -d' ' -f5,6,7  |   uniq  | sort 


The output clearly shows, the compromised host REDACTED is sending extensive amound of traffic on external IP address. We can also filter on IDS logs, to see the alerts being triggered on these activities from the internal IP. 


cat ids_alerts.log | grep 10.0.0.51 | tail


We have found evidence of data exfiltration attempts. If we dig deep into the ids alerts and pivot correlate the alerts through other log files, we can find more suspicious activities as well. 

Comments

Post a Comment

Popular posts from this blog

Data Exfiltrtation Detection (DNS, FTP, HTTP, ICMP)

Image
Learning Objectives In this entry, we will cover the following learning objectives: - Understand the common methods used for data exfiltration. - Learn how to detect exfiltration attempts using network traffic analysis. - Identify signs of exfiltration on endpoint devices. - Correlate logs in a SIEM to uncover hidden exfiltration channels. 1) Data Exfil: Overview Tech, and indicators -> unauthorized data transfer from in to out by adversaries -> can be by insider or malware 1.1) Why they do data exfil?  Reason Description Financial Gain Stolen data (e.g., credit card information, personal records) can be sold on the dark web or used for fraud. Espionage Nation-state actors target intellectual property, trade secrets, or classified information for strategic advantage. Ransomware & Extortion Attackers steal data and threaten to leak it unless a ransom is paid. Disruption & Sabotage Adversaries aim to damage an organization's reputation or operations by exposing sensitiv...
Read more

Reversing ELF TryHackMe

Image
  1) crackme1 for the first challenge all we need to do is run the file named "crackme1" and we got the flag. 2) crackme2 when we try to run the file, it correct us and say the right usage is ./crackme2 + password, and we need to find this password. As we open the file in ghidra, we can see if we use "super_secret+password" it will give us access granted as the output. and as we suspected, once we use it as the password, it will give us the flag.  3) crackme3 The same case as crackme2, so first let's see if there is any interesting strings that we can see.  here we can see there is a base64 strings as we open the file in ghidra, it says that if we input the base64 strings as the password, then the password is correct.  so we decode the strings first and then use it as the password.  4) crackme4 This launches GDB (GNU Debugger) and loads the executable crackme4. This tells GDB to print all the functions found inside the binary. This lets you identify where the re...
Read more