SOC Incident Report: Investigation of a Volt Typhoon-Inspired Intrusion
A Complete Write-Up Demonstrating Real SOC Investigation Methodology
Exposing a Network-Based Attack: TryHackMe First Shift CTF — Task 7: The Crown Jewel
Network Traffic Analysis and Forensics to Identify C2 Channels, ARP Spoofing, and Data Exfiltration Techniques
Scenario
An alert was triggered: “Reverse Shell Outbound Connection Detected.”
Tools and Data Provided:
- Raw PCAPs
- Splunk logs
Objective:
Analyze the network traffic and logs to reconstruct and halt a sophisticated attack targeting the theft of “Crown Jewel” data.
Questions:
Q1. From which internal IP did the suspicious connection originate?
Process:
Since everything started by an IDS alert, I began by creating a query to extract log data from the Intrusion Detection System (IDS). This returned a single event that detailed the detection of a reverse shell outbound connection. Among the information provided, the Source IP address was included.
Query:
index=network_logs log_type=ids
Answer:
10.10.10.100
Insights:
By using the IDS logs, I quickly identified the internal IP responsible for initiating the suspicious connection. This step is crucial as it helps isolate the compromised system within the network for further investigation.
Q2. What outbound connection was detected as a C2 channel?
Process:
To identify the Command and Control (C2) channel, I used the same query as before. This time, I focused on extracting the Destination IP and Port from the event’s fields.
Query:
index=network_logs log_type=ids
Answer:
1.1.1.1:8080
Insights:
The identification of the C2 channel is critical in understanding the scope of the attack. This connection to an external server on port 8080 could be used for remote control or exfiltrating stolen data.
Q3. Which MAC address is impersonating the gateway?
Process:
I used Wireshark to filter packets involving the suspicious IP address (10.10.10.100) identified in the previous question. After analyzing the frame details of related connections, I discovered a suspicious MAC address. To confirm it was a gateway impersonation, I used the arp filter and found the host advertising itself as both the target IP (10.10.10.150) and the gateway’s IP (10.10.10.1).
Filter:
ip.addr == 10.10.10.100
Answer:
00:0c:29:11:22:33
Insights:
ARP spoofing is a common tactic in man-in-the-middle (MITM) attacks. By impersonating the gateway’s MAC address, the attacker can intercept and manipulate network traffic between other hosts.
Q4. What is the non-standard User-Agent hitting the Jira instance?
Process:
In this step, I focused on searching for HTTP logs containing the User-Agent field. . Upon finding the C2 IP (1.1.1.1) in the results, I refined the query to investigate its involvement further. This led me to discover an anomalous User-Agent containing the word EXPLOIT. This suspicious agent was attempting to interact with the Jira instance, likely exploiting a known vulnerability.
Query:
index=network_logs log_type=http 1.1.1.1
An alternative approach to the C2 IP would be to apply an additional filter such as host=jira to further narrow down the results, and then analyze the User-Agent field for anomalies.
Answer:
CVE-202X-EXPLOIT
Insights:
The discovery of a non-standard User-Agent reveals an attempt to exploit a vulnerability in the Jira application. This can indicate a targeted attack, emphasizing the need for continuous patching and vulnerability management in production environments.
Q5. How many ARP spoofing attacks were observed in the PCAP?
Process:
I filtered the PCAP for ARP packets and observed the results for the MAC address identified in Q3 (00:0c:29:11:22:33). I found multiple ARP responses, all indicating an ARP spoofing attack where the attacker’s host was impersonating the gateway. I observed the total number of instances at the bottom of the application, which displayed the number of ARP spoofing events associated with the identified MAC address.
Filter:
arp
Answer:
90
Insights:
ARP spoofing attacks are a common method used to gain access to network traffic. By impersonating the gateway, the attacker could intercept communication between devices, steal sensitive information, or inject malicious traffic.
Q6. What’s the payload containing the plaintext credentials found in the POST request?
Process:
I filtered for POST HTTP requests using Wireshark, as this method was used for submitting credentials. I found a single request containing a set of plaintext credentials in the payload.
Filter:
http.request.method == POST
Answer:
username=dev_user\&password=SecretPassword!
Insights:
Exposing credentials in plaintext is a significant vulnerability. It’s critical for security teams to implement secure transmission methods such as HTTPS to prevent sensitive information from being leaked over the network.
Q7. What domain, owned by the attacker, was used for data exfiltration?
Process:
To detect data exfiltration, I began by querying DNS logs. Upon inspecting the logs, I observed that one Source IP had an unusually high number of connections. This could indicate that data was being exfiltrated. After running a targeted query, I found the attacker’s domain.
1st Query:
index=network_logs log_type=dns
2nd Query:
index=network_logs log_type=dns event.src_ip=10.10.10.200
Answer:
exfil-domain.xyz
Insights:
Data exfiltration is often masked using DNS queries. By monitoring for abnormal patterns, such as high-frequency DNS requests, defenders can identify and mitigate such attacks before they result in significant data loss.
Q8. After examining the logs, which protocol was used for data exfiltration?
Process:
Upon reviewing the log entries, it became evident that data exfiltration was occurring through DNS. Specifically logs were:
1. associated with the DNS server (host: dns_server),
2. categorized as DNS traffic (log_type: dns),
3. and identified under the network:dns sourcetype,
pointing to DNS as the protocol used for exfiltration.
Answer:
DNS
Insights:
DNS tunneling is a stealthy method of exfiltrating data. By encoding data in DNS queries, attackers can bypass firewalls and data loss prevention (DLP) systems that might not inspect DNS traffic as closely as other protocols.
Conclusion
In this investigation, I successfully reconstructed various stages of the attack using network traffic and log analysis. By identifying critical elements such as the source of the suspicious connection, C2 channels, ARP spoofing, and data exfiltration methods, I was able to piece together the attacker’s methods and mitigate the threat to the “Crown Jewel” data. This task highlights the importance of thorough network monitoring and log analysis to detect sophisticated, multi-phase attacks.
Additional Sections for Recruiters
Skills Demonstrated:
- Network Analysis & Forensics: Proficient in using tools like Wireshark to analyze PCAPs and identify attack vectors such as ARP spoofing and DNS tunneling.
- Log Analysis: Experienced with Splunk and other SIEM tools to detect and investigate suspicious network activities.
- Incident Response: Demonstrated the ability to follow a systematic approach in analyzing and mitigating security incidents.
Professional Experience:
While I am an aspiring entry-level security analyst, this blog and my work on platforms like TryHackMe have provided me with hands-on experience in the field. I continuously improve my skills and knowledge through challenges and practical exercises like the one presented here.
✨ Enjoyed this write-up?
If you found this investigation useful and want to see more TryHackMe write-ups, SOC workflows, and real-world cybersecurity analysis, feel free to follow my RSS feed.
I regularly share detailed, step-by-step breakdowns designed to help aspiring analysts develop practical skills in network traffic analysis, threat detection and attacker behavior analysis.
