head firewall.log head ids_alerts.log head vpn_auth.log 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). 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. cat firewall.log | grep [REDACTED] | 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.cat vpn_auth.log | grep FAIL | cut -d' ' -f3 | sort -nr | uniq -c - In the VPN Logs, let's first examine the number of failed attempts; we can clearly see that the suspicious IP has multiple failed VPN login attempts.cat vpn_auth.log | grep [REDACTED] - the multiple login attempt was made against a certain user svc_REDACTED, 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. 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 IP REDACTED
cat firewall.log | grep [REDACTED] | grep "ALLOW" | head - the compromised IP is probing internal machines on various ports on three main ports SMB/RDP/SSH (445/3389/22).cat ids_alerts.log | grep [REDACTED] | head - Let's now pivot to ids_alerts logs, and filter through the compromised IP and see if we can find any intrusion rules triggered. It seems, the compromised host is trying to exploit various vulnerabilities against the services mentioned above on those hosts. cat ids_alerts.log | grep -n [REDACTED] | grep 'SMB' | cut -d' ' -f6,7,8,9,10,19,21 | head - the compromised host was able to exploit SMB service and was able to achieve lateral movement.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:
cat ids_alerts.log | grep C2 | head - It clearly confims our suspicion against one of the internal compromised host.cat ids_alerts.log | grep -n [REDACTED] | cut -d' ' -f6,7,8,9,10,19,22,23 | head -n 15 - the infected host is further performing susicious activities. cat ids_alerts.log | grep -n [REDACTED] | 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.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:
cat firewall.log | grep [REDACTED] | 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.