Identifying Unencrypted Traffic

1. The Analyst's Toolkit: Wireshark Filters and Streams

Your captured enb_gtpu.pcap file contains the raw IP packets sent by the UE. Our first task is to sift through this traffic to find protocols that are inherently unencrypted. Wireshark's display filters are the primary tool for this.

While you're already familiar with Wireshark, this video provides a focused refresher on the specific filters and tools we'll be using to hunt for cleartext data.

As the video explains, applying a filter like dns or http will immediately isolate the packets related to those protocols, cutting through the noise of other traffic like TCP handshakes or ICMP.

2. Case Study 1: Extracting DNS Queries

Before a UE can establish a connection to a website like google.com, it must first resolve that domain name into an IP address. This is done using the Domain Name System (DNS), which, by default, is unencrypted. By intercepting DNS queries, an attacker can build a profile of the user's online activity, even if the subsequent web traffic is encrypted with HTTPS.

Let's find these queries in your capture file.

Analysis Steps:

1. Open the enb_gtpu.pcap file you created in the previous lesson. If you need to regenerate it, simply repeat the capture steps, and on the UE, open a browser and try to visit any website.
2. In the Wireshark display filter bar, type dns and press Enter.
3. You should now see a list of DNS packets. Look for a packet in the "Info" column described as a "Standard query". This is the UE asking for an IP address.
4. Select this packet. In the packet details pane, expand the "Domain Name System (query)" section. Inside, you will see the exact domain name the UE was looking for.
5. Find the corresponding "Standard query response" packet to see what IP address was returned to the UE.

The following video demonstrates this process clearly.

By capturing DNS, you have successfully intercepted metadata about the user's browsing habits.

3. Case Study 2: Intercepting Unencrypted HTTP Traffic

While DNS reveals where a user is going, intercepting unencrypted HTTP traffic can reveal what they are doing. Any data sent over HTTP—including usernames, passwords, session cookies, and form data—is transmitted in cleartext. Your man-in-the-middle position allows you to read it all.

A key Wireshark feature for this is "Follow TCP Stream". Since a single web page request can be split across many TCP packets, this tool reassembles them into a single, readable conversation.

Let's try to capture login credentials.

Analysis Steps:

1. If you haven't already, perform a capture where you use the test UE to visit an HTTP-only login page (e.g., http://testphp.vulnweb.com/login.php) and attempt to log in.
2. Open the resulting enb_gtpu.pcap in Wireshark.
3. Apply the display filter http.request.method == "POST". POST requests are commonly used to submit login forms.
4. You should see a packet with info similar to POST /login.php HTTP/1.1. Select it.
5. In the packet details pane, expand the "Hypertext Transfer Protocol" layer. You may be able to see the form data directly, including username and password fields in cleartext.
6. For an even clearer view, right-click the packet and select Follow > TCP Stream. A new window will appear showing the entire conversation. The client's request (including the password) will be in one color (typically red), and the server's response will be in another (typically blue).

This video provides a complete, practical lab demonstrating exactly this attack.

By following these steps, you have moved from passively capturing traffic to actively extracting sensitive user credentials, fulfilling the goal of this lesson.

4. Decrypting the User Plane (When Necessary)

In our srsRAN setup, we are capturing traffic on the gtpu interface after the base station has handled the radio-layer encryption. This means the IP packets inside the GTP tunnel are already decrypted for us.

However, if you were to capture traffic at a lower layer (e.g., the MAC layer), the user data payloads would still be encrypted. The Analysing the srsRAN LTE MAC layer with Wireshark article you've seen before discusses this. In Section 4, "User data: ping packets", the author shows how to provide Wireshark with the user plane encryption keys (K_up_enc) from the srsUE logs to decrypt the traffic.

For our current goal, this step isn't necessary, but it's crucial to understand that access to these keys is what allows the eNodeB—and by extension, our rogue eNodeB—to decrypt user traffic before tunneling it to the core.

Conclusion

In this lesson, you leveraged your man-in-the-middle position to move from capturing traffic to actively analyzing it for sensitive information. You have demonstrated how a rogue base station can compromise user privacy and security by intercepting unencrypted communications.

Key Takeaways:

• GTP-U traffic captured from srsenb contains the UE's raw, decrypted IP packets.
• Wireshark display filters like dns and http are essential for isolating unencrypted protocols.
• DNS queries can be intercepted to track a user's browsing activity.
• The "Follow TCP Stream" feature is powerful for reconstructing entire conversations and extracting data from unencrypted sessions, such as HTTP login credentials.
• Any application that uses unencrypted protocols is vulnerable to this form of interception when connected to a malicious base station.

Preview of the Next Lesson:

So far, our attacks have focused on LTE. However, many vulnerabilities arise from forcing a device onto older, less secure standards. In our next lesson, we will tackle the learning outcome: "Execute a downgrade attack by advertising a rogue 2G cell to an LTE-capable UE." You'll learn how to exploit the backward-compatibility of cellular networks to push a modern phone onto a 2G network, opening it up to a new class of attacks.