IMSI Catching: Initial Attach Signal Analysis

1. The Vulnerability in the Attach Procedure

To connect to a network, a UE must identify itself. For privacy, it's designed to use a temporary, randomly assigned identifier called a TMSI (Temporary Mobile Subscriber Identity) or its modern equivalent, the GUTI (Globally Unique Temporary Identifier). However, what happens if the network doesn't recognize the TMSI?

This is the crux of the IMSI-catching vulnerability. If an MME (the core network's "brain") receives an attach request with a TMSI it doesn't know, its only recourse is to ask the UE, "Who are you, really?". It does this by sending an Identity Request message, asking for the permanent IMSI. Crucially, this exchange happens before the signaling link is encrypted.

The diagram below shows a simplified attach flow. Note the initial Attach Request containing the IMSI, which happens before security is fully established.

The following reading explains this process and why it constitutes a vulnerability.

2. Forcing the IMSI Reveal

Our goal is to create the exact scenario described above: we want our rogue network to be an "unknown MME" so it's forced to ask for the IMSI.

With srsRAN, this is straightforward. The core network (srsepc) uses a simple text file, user_db.csv, as its subscriber database (the HSS). To perform an IMSI catch, we simply ensure our target UE's SIM credentials are not in this database.

When the UE connects:

1. It sends an Attach Request with its current TMSI/GUTI.
2. Our rogue srsepc doesn't recognize the TMSI and sends back an Identity Request (Type: IMSI).
3. The UE complies and sends an Identity Response containing its cleartext IMSI.
4. Our rogue srsepc receives the IMSI, logs it, but then fails the authentication because the IMSI is not in its user_db.csv.

The attack is successful the moment we receive the Identity Response. The subsequent authentication failure is irrelevant. The paper you just read confirms this is the exact logic for a simulated Stingray.

3. Capturing and Analyzing the Attach

While watching the console logs is useful, a professional analysis requires capturing the traffic for inspection. Since you are proficient with Wireshark, we will configure srsRAN to generate PCAP files that we can analyze.

Step 1: Configure srsRAN for Packet Capture

First, we need to tell srsenb and srsepc to dump their traffic.

In short, you will add/uncomment lines like these in your configuration files (enb.conf and epc.conf), which will save the traffic to /tmp/:

• In epc.conf under [mme]: pcap_enable = true
• In enb.conf under [pcap]: enable = true and mac_net_enable = true

Step 2: Execute the IMSI Catch

Now, run the same procedure as in the last lesson, but with your modified configuration files.

1. Ensure user_db.csv is clean: Make sure the user_db.csv file referenced by your epc_rogue.conf either does not exist or does not contain the IMSI/key of your test SIM.
2. Start the EPC: In a terminal, run sudo srsepc --epc.conf ~/.config/srsran/epc_rogue.conf.
3. Start the eNB: In a second terminal, run sudo srsenb --enb.conf ~/.config/srsran/enb_rogue.conf.
4. Induce Connection: Bring your test UE close to the SDR antenna. The UE will attempt to attach.
5. Stop the Capture: Once you see the connection attempt and subsequent failure in the logs, you can stop srsenb and srsepc (Ctrl+C). The PCAP files (e.g., /tmp/enb_mac.pcap, /tmp/epc.pcap) will have been created.

Step 3: Wireshark Analysis

Now, let's find the IMSI in the captured traffic. Open /tmp/enb_mac.pcap or /tmp/epc.pcap in Wireshark. You will need to apply a display filter to isolate the relevant messages.

A good filter to start with is s1ap || nas-eps. You are looking for a specific sequence:

1. Attach Request: Sent from the UE. Inside this NAS message, you'll find the EPS mobile identity, which will likely be a GUTI.
2. Identity Request: Sent from the MME (your EPC) to the UE. This is the smoking gun. Wireshark will dissect this message and show that it is explicitly requesting the IMSI.

3. Identity Response: Sent from the UE back to the MME. This message contains the payload we want. Wireshark will dissect it and display the UE's IMSI.

The detailed flow of these messages, along with the other RRC and NAS signaling, is complex but very well documented.

This analysis confirms the attack. You have captured the signaling and extracted the IMSI, a permanent subscriber identifier that is supposed to be protected.

To see this flow explained in a video format, you can watch this segment, which analyzes a legitimate attach procedure in Wireshark. The key messages are the same.

Conclusion

In this lesson, we transitioned from simply creating a rogue cell to executing a classic cellular intelligence attack. You've learned the theoretical weakness in the LTE attach procedure and successfully exploited it in a lab environment.

Key Takeaways:

• The IMSI is exposed in 4G LTE when a UE connects to a network that does not recognize its temporary identifier (TMSI/GUTI).
• The network sends an unencrypted Identity Request for the IMSI before establishing a secure signaling channel.
• An attacker can force this exchange by running a rogue base station with an empty subscriber database.
• By enabling PCAP dumps in srsRAN and analyzing the traffic in Wireshark, we can capture the Identity Response message and extract the target's IMSI.

Preview of the Next Lesson:

Catching an IMSI is a powerful tool for tracking, but it's only an identifier. The next logical step is to intercept the user's actual data. In the next lesson, "Capture user-plane traffic from a UE connected to the rogue base station," we will modify our attack. Instead of rejecting the UE after getting its IMSI, we will complete the authentication and establish a data bearer, turning our IMSI catcher into a full man-in-the-middle platform.