🛡️ SSH Brute Force Detection - Splunk + Linux Secure Logs

Summary: I detected a brute force SSH attack in the BOTSv3 dataset using Splunk. The attacker IP 197.52.75.218 attempted to log in to the internal server mars.i-08e52f8b5a034012d (172.31.12.76) via SSH on port 22 using the invalid username admin. The attack originated from an IP block registered to TE Data, an Egyptian ISP, which is commonly seen in global brute force scan activity.

Skills: SSH Brute Force Detection, Log Analysis, Threat Hunting, Splunk SPL, Network Security
Tools: Splunk, BOTSv3 Dataset, Linux Secure Logs, stream:tcp, stream:ip, stream:dns

🔍 Discovery

The first red flag appeared in the linux_secure logs, showing reverse DNS failures:

reverse mapping checking getaddrinfo for host-197.52.75.218.tedata.net [197.52.75.218] failed - POSSIBLE BREAK-IN ATTEMPT!
        

Screenshot – Reverse DNS Failure in Splunk:

Soon after, the attacker attempted to login using an invalid user:

Invalid user admin from 197.52.75.218 port 58357
Connection closed by 197.52.75.218 port 58357 [preauth]
        

Screenshot – Invalid User Attempt in Splunk:

📡 Network Activity

TCP stream logs showed a connection attempt on SSH port 22. The log confirmed that the attacker from TE Data (Egyptian ISP) successfully reached the SSH service on the server, but authentication failed.

protocol_stack: ip:tcp:ssh
src_ip: 197.52.75.218
dest_ip: 172.31.12.76
dest_port: 22
        

Screenshot – SSH Connection Flow in Splunk:

🧪 Investigation

DNS logs also showed queries and multiple NXDOMAIN replies, likely due to the attacker's scanning tools attempting to resolve internal or fake hostnames. These DNS requests also confirmed the IP’s association with the Egyptian ISP tedata.net, providing insight into geographic origin.

query: host-197.52.75.218.tedata.net
reply_code: NXDomain
        

⚙️ Mitigation (Simulated)

• Blocked attacker IP using UFW:

sudo ufw deny from 197.52.75.218
            

• Configured Fail2Ban to auto-block brute force attempts
• Enforced key-based SSH authentication only

✅ Outcome

This lab demonstrated how to detect and analyze SSH brute force activity using Splunk and multiple log sources. By correlating linux_secure, DNS, TCP, and IP logs — along with identifying the geographic origin via ISP metadata — I completed the full lifecycle of threat detection and documentation for this simulated incident.

🛡️ NXDOMAIN Attack (DNS Enumeration) - Splunk

Summary: I detected an NXDOMAIN attack using Splunk and the BOTSV3 dataset. The attack involved querying non-existent subdomains on the brewertalk.com domain, triggering NXDOMAIN responses. This is a typical DNS enumeration attack aimed at discovering subdomains and potentially identifying vulnerable infrastructure.

Skills: DNS Enumeration, Splunk Log Analysis, Threat Detection, Network Security
Tools: Splunk, BOTSV3 Dataset, Nslookup, Nmap, Linux

🔍 Discovery

Using the BOTSV3 dataset in Splunk, I identified multiple NXDOMAIN responses triggered by DNS queries for non-existent subdomains under brewertalk.com. These queries were logged with the IP addresses that initiated the requests.

Splunk Search Query:

index=botsv3 sourcetype=aws:cloudwatchlogs "NXDOMAIN" 
| stats count by src_ip
| where count > 10
        

This search identified IP addresses that made more than 10 DNS queries in a short time period, which is indicative of a DNS enumeration attack. The IP addresses involved were flagged for further investigation.

Screenshot – Splunk Search Results for NXDOMAIN Attack:

🧪 Investigation

The attack was identified through a pattern of repeated DNS queries for subdomains that do not exist (NXDOMAIN responses). I noticed several queries for non-existent subdomains, such as:

users1.brewertalk.com AAAA NXDOMAIN
ccmail.brewertalk.com AAAA NXDOMAIN
koko10.brewertalk.com A NXDOMAIN
        

These queries triggered NXDOMAIN responses, indicating that the attacker was attempting to gather information about the structure of the domain, potentially looking for valid subdomains or services by forcing NXDOMAIN errors.

I used the **Splunk logs** to look for patterns that showed multiple NXDOMAIN responses coming from the same IP addresses in a short time window. The IPs involved were:

src_ip       | count
52.78.247.225 | 7
13.209.8.105  | 5
13.209.43.220 | 6
        

These IP addresses initiated multiple queries for non-existent subdomains within a brief time frame, a common characteristic of **DNS enumeration** or **reconnaissance attacks**. The attacker is likely trying to find subdomains and test for misconfigured or vulnerable DNS records.

⚙️ Mitigation

To mitigate this attack, I blocked the suspicious IP addresses using the UFW (Uncomplicated Firewall) on the target server to prevent further queries from these attackers.

sudo ufw deny from 52.78.247.225
sudo ufw deny from 13.209.8.105
sudo ufw deny from 13.209.43.220
        

✅ Outcome

This lab demonstrated how to detect NXDOMAIN attacks using Splunk and the BOTSV3 dataset. By identifying the suspicious IPs, blocking them with a firewall, and preventing further DNS queries, I successfully mitigated the attack. This lab also showcased the importance of monitoring DNS traffic to prevent such attacks.

🛡️ C2 Beaconing Detection - Splunk + Cisco ASA

Summary: I detected Command and Control (C2) beaconing activity in the BOTSv3 dataset using Splunk and Cisco ASA firewall logs. The internal host 192.168.9.50 attempted to reach the external IP 204.107.141.25 on port 4282 at regular intervals. This repeated outbound traffic is consistent with beaconing behavior, where malware tries to contact its control server.

Skills: Network Threat Detection, Firewall Log Analysis, Splunk Search Language (SPL), C2 Beaconing Analysis
Tools: Splunk, BOTSv3 Dataset, Cisco ASA, MITRE ATT&CK

🔍 Discovery

Using Splunk, I searched for repeated deny events in Cisco ASA firewall logs. I noticed that the internal host 192.168.9.50 was repeatedly denied outbound TCP connections to the same external IP 204.107.141.25 on port 4282. The activity occurred at regular time intervals over several minutes.

Splunk Search Query:

index=botsv3 sourcetype="cisco:asa" "Deny"
| rex "src inside:(?<src_ip>\d+\.\d+\.\d+\.\d+)"
| rex "dst outside:(?<dst_ip>\d+\.\d+\.\d+\.\d+)"
| search dst_ip="204.107.141.25"
| stats count by src_ip, dst_ip, _time
        

This confirmed that the firewall blocked all connection attempts, preventing the malware from establishing a C2 session.

🧪 Investigation

The repeated, timed connection attempts to a non-standard external IP and port indicate malware beaconing behavior. The internal host 192.168.9.50 attempted to reach 204.107.141.25 multiple times per minute using increasing source ports, such as:

192.168.9.50:63307 → 204.107.141.25:4282
192.168.9.50:63310 → 204.107.141.25:4282
192.168.9.50:63313 → 204.107.141.25:4282
        

I searched for malicious commands in bash_history to identify the infection source, but no relevant execution artifacts were found. This suggests that the lab focuses on network detection of beaconing rather than command-line evidence of malware execution.

Screenshot – ASA Deny Logs in Splunk:

⚙️ Mitigation

In a real environment, mitigation would involve:

• Isolating 192.168.9.50 from the network
• Blocking the external IP 204.107.141.25 at the firewall
• Scanning the host with EDR or antivirus tools
• Reviewing related hosts for lateral movement or similar behavior

✅ Outcome

This lab demonstrated how to detect C2 beaconing using Splunk and Cisco ASA logs. The suspicious host was identified, the communication pattern analyzed, and the external C2 IP flagged for malicious behavior. This scenario closely mimics real-world malware that attempts to maintain persistence via external control servers.