Building a Cellular Surveillance Testbed to Detect IMSI Catchers

TLDR: This research demonstrates how to build a low-cost, open-source cellular network testbed using software-defined radios to identify and analyze IMSI catchers. By configuring core network components like srsRAN and OpenAirInterface, researchers can monitor attach requests and signaling traffic to spot malicious cell-site simulators. This setup allows security professionals to move beyond theoretical discussions and perform hands-on traffic analysis of cellular protocols in a controlled environment.

Cellular security often feels like a black box for most penetration testers. We treat the connection between our mobile devices and the nearest tower as a trusted pipe, but the reality is that the underlying protocols are riddled with legacy design choices that prioritize availability over authentication. While law enforcement and intelligence agencies have long used IMSI catchers to track and identify targets, the barrier to entry for researchers to study these devices has remained high due to the cost of proprietary hardware and the complexity of cellular infrastructure.

The research presented at DEF CON 2025 changes that dynamic by providing a blueprint for a functional, open-source cellular testbed. By leveraging srsRAN or OpenAirInterface, you can stand up a 4G or 5G core network on a single board computer like a Raspberry Pi. This isn't just about theoretical research; it is about giving you the ability to capture and inspect the signaling traffic that occurs when a device attempts to attach to a network.

The Mechanics of the Testbed

At the heart of this setup is the realization that you do not need a million-dollar lab to replicate the behavior of a cell tower. You need a software-defined radio (SDR) capable of handling the required frequency bands and a core network implementation that can process the signaling messages. The presenter highlights the use of the uBlox EVB-WL3 and the Nuand bladeRF as viable hardware options for this purpose.

The core network acts as the brain of the operation. When a device attempts to connect, it sends an attach request. In a standard environment, this request is handled by a legitimate base station. In a testbed environment, your SDR acts as the base station, and your software stack processes the incoming packets. By using Wireshark to capture the traffic on the S1 interface, you can inspect the specific parameters of the attach request, including the Mobile Country Code (MCC) and Mobile Network Code (MNC).

The critical technical insight here is how these testbeds handle authentication. Many IoT devices and older cellular modules are configured to fall back to 2G if a 4G or 5G connection fails. Because 2G lacks mutual authentication, it is trivial to force a device to connect to a rogue tower. By configuring your testbed to accept these connections, you can observe the exact moment a device leaks its identity.

Practical Implementation and Configuration

Setting up the software stack requires careful attention to the configuration files. For those using srsRAN, the configuration is split between the User Equipment (UE), the Evolved NodeB (eNB), and the Evolved Packet Core (EPC). The goal is to create a environment where you can manipulate the network identity to see how devices respond.

One of the most useful aspects of this research is the focus on SIM card personalization. Using a USB SIM card reader/writer and software like GRSimWrite, you can program your own SIM cards to match the PLMN (Public Land Mobile Network) of the network you are simulating. A key detail often missed is the AD (Administrative Data) field on the SIM card. Setting this value to 9 is often required to allow the device to connect to non-standard or test networks.

# Example of checking the status of your srsRAN EPC
# Ensure your configuration files match your SDR capabilities
./srsepc /etc/srsran/epc.conf

Once the core is running, you can use CellMapper to identify the local cellular landscape. This allows you to see which bands are being used by commercial providers in your area, which is essential for ensuring your testbed operates on the correct frequencies without interfering with licensed spectrum.

Real-World Applicability for Pentesters

For a penetration tester, this research is invaluable for engagements involving IoT devices or mobile applications that rely on cellular backhaul. If you are testing a medical device or a drone that uses cellular connectivity, you can now simulate a rogue tower to test how the device handles a forced network handover. Does the device attempt to encrypt its traffic? Does it fail open when it cannot authenticate the tower? These are questions that can now be answered in a lab setting.

The impact of these vulnerabilities is significant. An attacker who can successfully spoof a network can perform a man-in-the-middle attack, intercepting traffic or simply denying service to the target. By understanding the signaling flow, you can identify whether the devices you are testing are susceptible to these types of attacks.

Defensive Considerations

Defending against IMSI catchers is notoriously difficult because the vulnerability is baked into the cellular protocol stack. However, organizations can mitigate risk by ensuring that devices are configured to prefer 4G/5G-only modes and by implementing end-to-end encryption at the application layer. If the application does not trust the network, the network's ability to intercept data is severely limited.

This research provides the tools to move cellular security from a theoretical concern to a practical testing requirement. If you are working with hardware that uses cellular connectivity, stop assuming the network is secure. Build a testbed, capture the traffic, and see exactly what your device is saying to the tower. The next time you are on an engagement, you will have the technical foundation to prove whether that "secure" connection is anything of the sort.