Rayhunter LTE PCAP Analysis

Rayhunter UI

Objective

To analyze cellular network control plane data captured by a Rayhunter device to detect rogue behavior such as IMSI catching or stingray deployments.

Setup

Usage

The Rayhunter UI is available on port 8080 to any device connected to the hotspot via wifi at:

http://192.168.1.1:8080

When connected via ADB you can view the Rayhunter portal by forwarding port 80 (Orbic) to your local machine via ADB:

adb forward tcp:8080 tcp:8080

Note: you will need to install the Android Debug Bridge (ADB) on your computer

Analysis

Review of captured PCAPs after triggering multiple alerts.

Wireshark

Detectable Indicators

Observations

Null Cipher

Observed Indicators

Findings

If a NAS IMSI Identity Request contains a UE network capabilities element (Element ID: 0x58, Length: 5) with the bit indicating support for EEA0 set (meaning only the null encryption option is supported), it may be caused by:

These factors combined make such a NAS message an indicator, albeit not definitive proof on its own, that a cell site simulator or similar IMSI-capturing device might be in use.

NAS IMSI Identity Request

The NAS IMSI identity request is a true positive but may be benign.

How it works

A NAS IMSI Identity Request is a standard mechanism in cellular networks (especially in LTE/4G) used when the network needs to explicitly obtain the International Mobile Subscriber Identity (IMSI) from a user device (UE) rather than relying solely on a temporary identifier. Several factors or conditions can trigger such a request.

Why it's an indicator

A NAS IMSI Identity Request isn’t in itself proof of malicious intent, but when seen in unexpected contexts it can be a red flag. In a typical network attach procedure, a subscriber device initially uses a temporary identifier (like a GUTI) assigned by the home network. A legitimate network rarely needs to ask for the permanent IMSI except under special conditions—such as when the temporary identity is missing, expired, or mismatched.

While a single IMSI Identity Request can occur during normal attach procedures when temporary identities fail, repeated or contextually inappropriate NAS IMSI requests raise the possibility that a device is interacting with a non-standard, potentially rogue cell site. Such behavior is characteristic of cell site simulators (stingrays) that deliberately force the disclosure of permanent subscriber information in order to track or intercept communications. Therefore, if a device—or the network logs of an operator—record IMSI requests in situations where they would not normally be expected, it can be indicative of the presence of a stingray or similar IMSI-catching device.

When a cell site simulator (often called a “stingray”) is in use, the following anomalies can occur:

Null Cipher (EEA0)

In a typical attach or TAU procedure, the network and the user equipment (UE) perform a security mode command procedure. During this process, they negotiate encryption and integrity protection parameters. Normally, a non-null cipher suite is selected to ensure that both the control plane signaling and any sensitive subscriber information (like identity data or location updates) are protected against eavesdropping.

Due to the standardization of cipher suites, it is not suspicious to see a null cipher offered to the client in this context. However, if ONLY a null cipher was offered during the negotiation and would be unusual in a properly secured network.

How it works

The null cipher suite (EEA0) is supported in cellular networks primarily as a fallback mechanism, ensuring interoperability, simplifying testing and debugging, and maintaining compatibility with legacy or specialized systems. Although using EEA0 means that data is transmitted in cleartext—an option that would not be ideal for general secure communication—it provides a necessary, standardized baseline that guarantees a level of connectivity when no other encryption method is viable. This design choice makes it clear that while security is a high priority, the network must also be resilient and flexible in various operational scenarios.

Why it's an indicator

Tracking Area Update Request

The Tracking Area Update Request is likely a false positive as noted in the projects source code comments. Once the issue is fixed the QMDL files will be reanalyzed by the system.

// FIXME: our RRC parser is reporting false positives for this due to an
// upstream hampi bug (https://github.com/ystero-dev/hampi/issues/133).
// once that's fixed, we should regenerate our parser and re-enable this
// harness.add_analyzer(Box::new(NullCipherAnalyzer{}));

Requests

Troubleshooting Bugs

Fixed in version 0.2.6

Due to corrupted QMDL files, the PCAPs were not visible in the Rayhunter UI. The QMDL and PCAPs were extracted manually with the following procedure:

Manually copy the PCAP files from the device via ADB.

adb pull /data/rayhunter/qmdl .

Convert from QMDL to PCAP using tool.

Parse and convert the baseband dump file using SignalCat:

pip install signalcat
scat -t qc -d 'YOUR_QMDL.qmdl' -F PCAP_OUTPUT.pcap

Next Steps


Tags: IMSI, Cellular, Android, Wireshark, Networking, Defensive Tooling, Featured

← Back home