Have you ever considered how dangerous malicious traffic can be for your network?
Every unusual data packet could be a clue to a hidden cyber threat.
If we don’t analyze this traffic, hackers could slip through unnoticed.
That’s why understanding malicious traffic analysis is so important—it helps uncover and stop these threats before they cause damage.
In this article, we’ll look at a real-world example, using a PCAP file from letsdefence website to answer nine important questions about suspicious web activity.
Check out: “Introduction to SOC Analysis and Its Role in Network Logs“
Get ready to learn simple and effective ways to find and stop malicious traffic in its tracks!
What is Malicious Traffic on the Web?
Malicious traffic on the web is a harmful or dangerous activity that can damage computers, steal information, or disrupt services.
Hackers create this traffic to break into systems, trick people, or cause problems online.
Common Types of Malicious Traffic
- Bots: Automated programs that send spam, crash websites, or steal data.
- Phishing Links: Fake websites that try to steal your passwords or credit card details.
- Exploits: Attacks that take advantage of weak spots in apps or programs to cause harm.
- Hacker Commands: Messages sent by attackers to control infected computers.
- DDoS Attacks: Sending too many requests to a server to make it crash or stop working.
Why Is Malicious Traffic Dangerous?
- Stealing Data: Hackers can take personal or business information.
- Disrupting Systems: Malicious traffic can overload systems and make them stop working.
- Costly Fixes: Repairing the damage caused by these attacks is expensive.
- Ruined Trust: People may stop trusting a website or company after an attack.
How Can You Spot Malicious Traffic?
- Weird Traffic Patterns: Sudden spikes or strange activity on a network.
- Security Tools: Firewalls and other software can block harmful traffic.
- Packet Analysis: Experts can study data from the network to find problems.
How Can You Stop Malicious Traffic?
- Firewalls: These act like barriers to block harmful traffic.
- Stay Updated: Regularly update apps and software to close security gaps.
- Use Trusted Sources: Avoid visiting suspicious websites or clicking unknown links.
- Monitor Traffic: Keep an eye on network activity for anything unusual.
By understanding malicious traffic, we can protect ourselves and make the internet safer for everyone!
Malicious Traffic Web Analysis: Uncovering Threats in Suspicious Network Patterns
- What is the IP address of the web server?
To identify the IP address of the web server in my PCAP file, I started by filtering for HTTP and HTTPS traffic using http || ssl || tls in Wireshark.
ip.dest == 10.1.0.4
This helped me isolate web traffic and focus on packets containing server responses, like 200 OK or 301 Moved Permanently.
The server’s IP was visible in these response packets’ ip.src column.
Next, I used Statistics > Conversations to analyze communication patterns.
Sorting by the number of packets or bytes allowed me to pinpoint the IP with the highest communication, likely the web server.
To confirm, I followed specific sessions by right-clicking an HTTP packet and selecting Follow > HTTP Stream, which displayed the entire client-server interaction.
Finally, I checked the HTTP Host field for domain names and matched them to the IP address. By combining these methods, I confidently identified the web server’s IP.
- What is the attacker’s IP address?
To identify the attacker’s IP address, I analyzed the PCAP file in Wireshark, focusing on unusual traffic patterns.
Using Statistics > Conversations, I identified IPs with high activity and applied filters like tcp.flags.syn == 1 && tcp.flags.ack == 0 to detect port scans and brute force attempts.
Protocol-specific filters, such as dns or http, helped uncover anomalies like DNS tunneling or suspicious data transfers.
By correlating suspicious activity with internal IPs and verifying the suspected IP using tools like IPVoid, I confirmed the attacker’s identity and documented the findings for evidence.
ip.src == 197.32.212.121
- The attacker first tried to sign up on the website. However, he found a vulnerability in that he could read the source code. What is the Name of the Vulnerability?
To analyze the attack in Wireshark and identify the vulnerability, I followed these steps:
Filter HTTP and IP Address Traffic:
I applied the http && ip.addr == 197.32.212.121 filter to isolate HTTP requests and responses, the IP address of the attacker in the PCAP file, focusing on each of the registered targets (e.g.,. /register/register.php.)
Inspect HTTP POST and IP Address Requests: I examined POST requests by right-clicking and selecting Follow > HTTP Stream to view the complete request and response.
This revealed the XML payload with the suspicious &xxe; in the <email> field.
Look for Patterns: I checked the payload for unusual elements like XML external entities (&xxe;) that might indicate an XXE attack.
Analyze the Response: The server’s response, “Sorry, is already registered!” suggested that the request was processed, but the server either ignored or mishandled the &xxe; entity.
Assess Vulnerability: Based on the payload structure and response behavior, I concluded that the attacker was likely attempting an XXE attack to exploit impropr XML processing. Further testing would confirm if the server is vulnerable.
These steps allowed me to determine the potential vulnerability and its impact.
4. There Was A Note In The Source Code: What Is It?
By exploiting the XML External Entity (XXE) vulnerability, I extracted the source code of the targeted file using a decoding tool (https://www.base64decode.org/) to extract the plaintext content.
Decoding the Base64-encoded data revealed the embedded note, “yougotme,” intentionally placed in the PHP file.
This demonstrates how the XXE attack was successfully used to expose server-side information.
5. After Exploiting The Previous Vulnerability, The Attacker Got A Hint About A Possible Username. What Is The Username That The Attacker Found?
After exploiting the XML External Entity (XXE) vulnerability, I looked at the server’s responses and files to find a possible username.
I followed the HTTP streams using Wireshark and checked the server’s replies.
I found a note in the source code that said, “Admin comment: Let you know that we updated your CRS with a very secure password.”
This note pointed to the username admin, often used as a default for administrators. Based on what I found, the username the attacker discovered is admin.
6. The attacker tried to brute force the password of the possible username he found. What Is The Password Of That User?
To determine which password is valid for the user “admin,” I used a filter to narrow the search in Wireshark. The filter I applied was:
http.request.method == “POST” and frame contains “login”
With this filter, I could see all the brute-force attempts to guess the password. Analyzing the last packet’s HTTP stream in the filtered results, I noticed that the brute force attempt succeeded. The password {fernando} was used, and it worked.
Here’s how I knew the login was successful: the HTTP request showed a POST method submitting login details, which is typical for login forms. The server’s response had a 302 Found status code.
This status code means the server temporarily redirected the browser to another page, likely the dashboard or homepage for the logged-in user. This redirect confirmed that the login attempt with the password {fernando} was successful.
7. The attacker gained admin access; they explored another vulnerability that led the attacker to read internal files located on the server. What Payload Did The Attacker Use?
To identify the payload used in the directory traversal attack, I opened the capture file in Wireshark and applied a filter to isolate HTTP requests.
Specifically, I focused on GET requests originating from the attacker’s IP address. I initially examined the URI field for suspicious patterns, such as repeated ../ sequences or %2F, URL encoding for /. However, this search yielded no results, as those strings were absent in the payload.
Realizing this, I revisited the nature of the vulnerability and considered alternative approaches. First, I examined the XXE (XML External Entity) vulnerability the attacker might have exploited. Then, I used a refined Wireshark filter:
http.request.method == “GET” and ip.src == 197.32.212.121
This filter allowed me to capture all GET requests sent by the attacker’s IP to extract information from the web server.
Upon analyzing the requests, I identified a suspicious one targeting a vulnerable endpoint. I followed the HTTP stream to view the complete conversation, which revealed the payload:
../../../../../../../../../../../../../../../../etc/passwd
This payload was designed to exploit a directory traversal vulnerability and access sensitive files. Further inspection of the server’s response showed an HTTP 200 OK status, confirming that the exploit successfully retrieved the contents of the /etc/passwd file.
I pinpointed the attacker’s payload and validated its effectiveness by systematically analyzing the traffic and verifying the server’s response.
I noticed data extraction in the packet header, but the information must be decoded to reveal the correct path.
To achieve this, I used (https://www.url-encode-decode.com/) to decode the request. I could uncover the original path and analyze the malicious activity using appropriate decoding techniques.
8. The attacker could view all the users on the server. What is the last user that was created on the server?
To determine the last user created on the server using Wireshark, I started by looking for traffic where the attacker accessed the /etc/passwd file. This file contains all the user accounts on the server, and the user with the highest UID (User ID) is usually the one created last.
{username:password:UID:GID:GECOS:home_directory:shell}
First, I applied a filter in Wireshark to focus on HTTP traffic using this filter:
(http && ip.addr == 197.32.212.121)
This helped me find packets where the attacker may have requested or received the file.
If the attacker used a different protocol, like FTP or SMB, I adjusted the filter to include those protocols, such as ftp or smb2.
Once I found a relevant packet, I right-clicked it and chose Follow > HTTP Stream (or TCP Stream for other protocols). This showed me all the content exchanged, including the /etc/passwd file.
When I found the file, I copied it into a text editor to examine it. Each line of the file had information like the username and UID. The UID is assigned incrementally, so I looked for the highest number. In my case, the file included lines like this:
web_user:x:1000:1000::/home/web_user:/bin/bash
lxd:x:999:100::/var/snap/lxd/common/lxd:/bin/false
web_user:x:1000:1000:Ubuntu:/home/web_user:/bin/bash
a1l4mFTW:x:1001:1001::/home/a1l4mFTW:/bin/bash
Here, I saw that a1l4mFTW had a UID of 1001, which was higher than web_user’s UID of 1000. This told me that a1l4mFTW was the last user created on the server.
I could identify the last user created by carefully filtering the packets and analyzing the file’s content. It felt great to trace this step-by-step and see how the UID reveals the order of user creation!
9. The attacker also found an open redirect vulnerability. What is the URL the attacker tested the exploit with?
In this last question, we can again use the evidence obtained by the previous filter (http.request.method == “GET” and http contains “redirect” and ip.src == 197.32.212.121);
we see 2 “GET” requests where we see the suspicious “redirect” content.
We checked the last packet returned by this filter; we could identify the URL the attacker used to exploit this vulnerability.
When I decoded the URL https%3A%2F%2Fevil.com%2F using ChatGPT, I used the prompt
“Please help to decode the following URL to the correct format: https%3A%2F%2Fevil.com%2F HTTP/1.1”.
I found that it translates to https://evil.com/.
The encoding uses special characters, where %3A represents: and %2F represents /. After decoding, I confirmed that the full URL the attacker tested is:
All Answers
- What is the IP address of the web server? 10.1[.]0.4
- What is the IP address of the web server? 10.1[.]0.4
- What is the attacker’s IP address? 197.32.212[.]121
The attacker first tried to sign up on the website but found a vulnerability with which he could read the source code. What is the name of the vulnerability? XXE - There was a note in the source code; what is it? Yougotme
- After exploiting the previous vulnerability, the attacker got a hint about a possible username. What is the username that the attacker found? Admin
- The attacker tried to brute-force the password of the possible username that he found. What is the password of that user? Fernando
- Once the attacker gained admin access, they exploited another vulnerability that led the attacker to read internal files on the server. What payload did the attacker use? ../../../../../../../../../../../../../../../etc/passwd
- The attacker was able to view all the users on the server. What is the last user that was created on the server? a1l4mFTW
- The attacker also found an open redirect vulnerability. What is the URL the attacker tested the exploit with? https://evil.com/
FAQs: Understanding Software and Tools for Malicious Traffic Network Protection
What type of software will help protect your computer from malicious network traffic?
Firewall and Intrusion Detection Systems (IDS) are essential for safeguarding your computer. Firewalls block unauthorized access, while IDS monitors traffic for suspicious activity.
What action will an IDS take upon detection of malicious traffic?
An IDS typically alerts administrators to suspicious traffic and logs the details for further analysis.
Unlike an IPS (Intrusion Prevention System), an IDS does not block traffic automatically.
What tool can identify malicious traffic by comparing packet contents to known attack signatures?
A signature-based IDS tool, such as Snort, uses a database of known attack signatures to compare packet contents and flag malicious traffic.
What are the three types of malicious traffic detection methods?
- Signature-Based Detection: Identifies traffic patterns matching known attack signatures.
- Anomaly-Based Detection: Flags traffic that deviates from normal patterns.
- Hybrid Detection: Combines signature-based and anomaly-based methods for comprehensive monitoring.
These FAQs offer clear guidance on protecting your system and understanding critical detection tools and methods for malicious network traffic.
Conclusion
Malicious traffic can threaten your network, but understanding how to analyze and detect it helps you stay secure.
This article has provided you with tools to identify threats, spot vulnerabilities, and protect your systems effectively.
Take action today!
Use these insights to analyze your traffic and safeguard your network before it’s too late.
Empower yourself with these strategies to stay ahead of cyber threats.
A colleague once applied these methods and stopped a breach before it caused damage.
Check out: “SOC Fundamentals: Mastering Tools, Roles, and Practices“ and unlock your full cybersecurity potential!