Devilray: A Systematic Adversarial Model Revealing Blind Spots in Fake Base Station Detection Taekkyung Oh* KAIST
Duckwoo Kim* KAIST
arXiv:2605.19232v1 [cs.CR] 19 May 2026
CheolJun Park Kyung Hee University
Hansung Bae The Affiliated Institute of ETRI
Tyler Tucker University of Florida
Byeongdo Hong The Affiliated Institute of ETRI
Patrick Traynor University of Florida
Abstract
Sangwook Bae Cape
Yongdae Kim KAIST
FBS detection has been extensively studied in academia for over two decades [11,23,51,54,67]. Industry has deployed OSlevel protections such as disabling 2G connectivity [30, 72], government authorities have issued warnings against SMS blaster fraud [27, 32, 75], and civil society organizations have released detection tools and guidance [29, 63, 64]. However, significant financial and regulatory barriers to accessing commercial FBS devices [12, 24, 58, 76, 81] have limited direct visibility into real-world adversary operations. As a result, detection systems are often designed and evaluated around the threat behaviors that self-built prototypes can realize. In this paper, we examine whether the threat models underlying current detection systems remain robust against realistic FBS operations. We define the discrepancies between these realistic behaviors and prevailing threat models as adversarial blind spots. Systematically identifying these gaps necessitates a structured adversarial baseline that encompasses realistic, specification-driven threat behaviors and supports rigorous assessments. To build such a baseline and assess current practice, we first establish an empirical basis by analyzing a commercial FBS (C-FBS); however, as access to the comprehensive commercial FBS ecosystem is limited, observations from a single device offer only a partial view of operational capabilities. We therefore extend this foundation by incorporating specification-driven variations permitted by 3GPP standards, thereby capturing a broader range of operational possibilities. We proceed in three steps: (1) empirical analysis of a CFBS to capture real-world operational behaviors, (2) systematic derivation of the adversarial design space from permissible 3GPP behaviors independent of detector assumptions, and (3) evaluation of existing detectors against this realistic threat space. Specifically, we make the following contributions: • Empirical grounding: We conduct the first academic analysis of a C-FBS, establishing operational ground truth and identifying gaps between academic assumptions and realworld threat capabilities. • Standards-driven adversarial modeling: We systematically derive an adversarial design space from permissible behaviors in 3GPP standards, independent of existing de-
Fake Base Station (FBS) detection has been a critical focus of cellular security research for over two decades. However, significant financial and regulatory barriers to accessing commercial FBS (C-FBS) devices have limited direct visibility into real-world operations, forcing detection systems to be designed and evaluated around self-built prototypes. In this paper, we present Devilray, a reconfigurable and referencegrade adversarial baseline designed to systematically explore the realistic adversarial space and identify adversarial blind spots in current detection – regions of realistic adversarial behavior excluded by prevailing threat models. We establish an empirical ground truth through the first academic analysis of a C-FBS and extend these observations into specification-driven operational variants permitted by 3GPP standards. Devilray enables the systematic exploration of 2,592 feasible and realistic FBS instances, capturing a wide range of operational possibilities. Using Devilray, we evaluate seven representative accessible FBS detectors and uncover coverage gaps across all seven, revealing blind spots rooted in assumptionbound design and evaluation. Our work provides the first robust adversarial model grounded in real-world behavior and specification analysis, enabling the community to develop and evaluate future detection mechanisms in a rigorous manner.
1
Nathaniel Bennett University of Florida
Beomseok Oh KAIST
Introduction
An FBS impersonates legitimate cellular infrastructure to intercept user connections and conduct privacy and security attacks. Known as Rogue Base Stations, Cell Site Simulators, IMSI-catchers, or Stingrays, these devices are deployed by governments for surveillance [14, 26, 35, 62, 77, 78] and exploited by criminals for SMS phishing [27, 32, 56, 75, 86] and illegal surveillance [17, 45]. Despite advancements in standards, weaknesses in initial connection procedures, the lack of base station authentication, and legacy fallback continue to expose users to tracking, disruption, and message injection. * Both authors contributed equally to this work.
1
tector implementations. We present Devilray, a reconfigurable and reference-grade adversarial model that captures the full operational pipeline of FBS attacks and enables systematic exploration of 2,592 standard-driven adversarial instances through combinatorial operational configurations. • Systematic evaluation: We evaluate 7 accessible FBS detectors under adversaries configured by Devilray and characterize adversarial blind spots in their coverage1 . We release Devilray and configuration profiles to vetted research groups as a shared baseline for systematic and reproducible FBS detection research. Demo videos of representative attack workflows are available at our website [25].
2
Cell ID: 256 PCI: 179 ARFCN: 2500 TA: 1
UE
Cell ID: 257 PCI: 181 ARFCN: 275 TA: 1
eNB 1
TA 1
MIB SIB
Cell ID: 512 PCI: 183 ARFCN: 100 TA: 2
SIB MIB
Connected UE
eNB 2 Paging ZZ
Idle UE
TA 2
Fig. 1: LTE architecture and broadcast messages
to the UE’s state. UEs without an active radio connection (idle state) apply cell reselection to select the optimal cell. While in idle mode, UEs monitor broadcast messages from nearby cells and also measure their signal quality. Based on the cell reselection priority and the signal quality, UEs select and camp on the optimal cell that meets the requirements. UEs with an active radio connection (connected state) utilize handover to swtich the cell while maintaining the connectivity. Handover is initiated when the UE reports cell measurement results to the network, triggered periodically or under bad signal conditions. After analyzing these reports, the network lets the UE switch the cell if a target cell has significantly better signal quality than the serving cell. Simultaneously, the network forwards session information and radio configurations to the target cell. UEs are not required to send additional information to the target cell, leading to fast switching and reliable connection throughout the process.
Background
LTE architecture. An LTE network consists of three main components: the User Equipment (UE), Radio Access Network (RAN), and Core Network. UEs are end-user devices that connect to base stations (eNBs) via wireless channels. The RAN manages radio resources and relays traffic, with each eNB covering three sectorized cells. The Core Network handles functions such as authentication, session management, and mobility control. UEs interact with the network through the Radio Resource Control (RRC) with the eNB and the Non-Access Stratum (NAS) with the core network. Network identifier. LTE cells broadcast identifiers that let UEs recognize the network, associate with the operator, and manage mobility (Fig. 1). Key identifiers include the Public Land Mobile Network (PLMN), indicating the operator, and the Tracking Area Code (TAC), defining a logical region for mobility and paging. Each cell is further distinguished by a Cell Identity (Cell ID), unique within the LTE network, and a Physical Cell Identity (PCI), used for synchronization, initial access, and mobility. Cells also operate on frequency channels defined by Absolute Radio Frequency Channel Numbers (ARFCN), from which UEs derive PCI through synchronization signals such as the Primary Synchronization Signal (PSS). Broadcast message. eNBs broadcast two main message types: Master Information Block (MIB) and System Information Block (SIB). MIB contains information including frame timing and bandwidth. SIB consists of several types (SIB1 to SIB24). SIB1 contains cell information including PLMN ID, TAC, cell ID, and scheduling information of other SIBs. SIB3 (intra-frequency) and SIB5 (inter-frequency) contain LTE cell reselection priority information, which informs UEs about preferred frequency band and reselection criteria. Paging is another broadcast message type used to notify idle UEs about incoming services. The network broadcasts paging to UEs that require service, prompting them to establish a connection. Mobility management. For reliable communication, LTE handles UE mobility through different mechanisms according
3
Motivation
The current landscape of FBS detection research is largely constrained by restricted access to real-world commercial devices. This accessibility barrier has forced the academic community to rely on isolated, self-built implementations that often act as static and naive adversaries. To investigate the extent of this limitation in current detection paradigms, we first present four core research questions to guide our study (§3.1). We then conduct an empirical analysis of a commercial FBS to characterize actual adversarial capabilities (§3.2) and identify the inherent limitations in existing threat models (§3.3). Based on these, we establish threat modeling requirements for robust detection research (§3.4).
3.1
Research Questions
To provide the motivation for our work, we address four fundamental research questions: • RQ1. Operational reality: How does real-world FBS actually operate in practice? • RQ2. Academic assumptions: Which academic assumptions are violated by commercial FBS operations? • RQ3. Threat modeling requirements: What requirements must adversarial models satisfy to enable systematic detec-
1We argue that blind spots stem not from flawed detection principles, but from the absence of a structured adversarial space against which detectors can be systematically designed and evaluated.
2
tion research and effective real-world detection? • RQ4. Security risks: How do these gaps translate into security risks when encountering realistic FBS threats?
3.2
regional radio environments and initializes its broadcast identifiers (e.g., PCI, TAC, cell ID) with random values. This configuration serves as the baseline for initiating attacks; the device is pre-configured to prioritize IMSI-catching as the primary vector, followed by options for location tracking, downgrading, and SMS injection using the captured IMSIs. Attack execution. Once configured, the C-FBS activates its RF output, broadcasting MIB and SIB (type 1-5) messages to lure victims. Upon a successful connection, it executes user-level attacks. For IMSI-catching, it sends an Identity Request, logs the response with captured IMSIs, and immediately terminates the connection via a NAS Reject message. With the captured IMSIs, it supports targeted location tracking, downgrading, and SMS injection. For location tracking, it triggers uplink traffic from the target via paging and Identity Request messages to measure the received signal strength and propagation delay for distance estimation. Downgrade and SMS injection attacks are performed by forcing the target UE to connect to its concurrent 2G cell via RRC redirection, enabling message injection over unencrypted links.
FBS in Practice (RQ1)
We analyze a C-FBS to understand the capabilities of actual threats in the wild. We gained temporary access to a C-FBS, sold to law enforcement and intelligence agencies for about $50K. The product name is not being disclosed due to a confidentiality agreement. We first detail its hardware architecture (§3.2.1), followed by its structured operational workflow (§3.2.2). We then investigate the advanced configurable capabilities that allow for granular, manual attack adjustments (§3.2.3). To analyze its full-chain behavior, we utilize UE-side diagnostic logs with SCAT [39] and C-FBS’s internal log, including configuration details. To our knowledge, this is the first academic effort to provide an end-to-end analysis of a real-world FBS product. 3.2.1
Integrated Hardware Architecture 3.2.3
The C-FBS is built on a Software Defined Radio (SDR) with an onboard processor designed for mobility and dynamic remote operation. It integrates a dual-channel Radio Frequency (RF) transceiver, Wi-Fi module, and Android control app. The transceiver supports 2G/3G/LTE across 400 MHz–6 GHz, and each channel is configurable as an independent base station working at different frequencies. This allows both multi-RAT (Radio Access Technology) deployment and simultaneous dual-channel operation in the same RAT. While this provides simultaneous operations on multiple frequencies, its operational bandwidth remains fixed at 5 MHz due to compact hardware constraints. The device also includes a GPS module for precise clock synchronization, and external storage for configuration and logs. 3.2.2
Extended Adversarial Capabilities
Our analysis highlights that the C-FBS is not merely a static tool but a configurable device, supporting extensive control over attack parameters beyond well-known operational logic to enable diverse operational strategies. These configurable capabilities are analyzed based on our cellular knowledge. Flexible configuration. Beyond the default automated configuration, the C-FBS offers manual cell initialization to facilitate environment adaptation. This allows operators to flexibly configure target bands, broadcast identifiers (e.g., PCI, TAC, cell ID) to clone legitimate neighbor cells based on prior reconnaissance, thereby enhancing stealthiness. The device also incorporates tailoring of protocol messages through the strategic selection of NAS Reject cause used for UE connection termination. This feature enables the operator to adjust the denial impact or introduce variability to attack patterns; for instance, by selecting a specific cause (e.g., #13 Roaming not allowed vs. #22 Congestion vs. #42 Severe network failure [2]), the device can strategically control the victim’s state. Depending on the chosen cause, it can compel the UE to blacklist the specific TAC, induce a DoS status that prevents reconnection to any network [50], or force a redirection [44] to the C-FBS’s concurrent 2G/3G cell, thereby controlling the victim’s behavior. This capability facilitates adaptive or multi-step attack strategies, such as minimizing redundant attempts or enabling further exploitation. Adaptive temporal and frequency hopping. For both coverage and stealthiness, the C-FBS enables dynamic frequency transitions with a configurable dwell time. By setting specific time intervals, the operator can program the device to automatically migrate across different frequencies and RATs. This allows the attacker to sweep multiple bands to target a
Operational Logic
The C-FBS provides a structured operational workflow designed even for non-expert users, consisting of three sequential phases. These phases are operator-facing and bundle multiple protocol-level steps, especially during execution. Reconnaissance. As a first step, the C-FBS profiles the surrounding radio environment. It scans nearby cells to retrieve network parameters such as PLMN, RAT, PCI, cell ID, ARFCN, TAC, and signal strength for each cell. The C-FBS then stores the scanned information into its storage, and these results are used to guide subsequent cell configuration. Along with this real-time scanning, it also provides preset network configuration information for each country and operator. Automated configuration. Leveraging the scanned data, the C-FBS automatically configures its cell parameters. By default, it targets frequency bands corresponding to all identified 3
Tab. 1: Gaps in academic FBS models. This highlights their limited capabilities and assumptions, compared to C-FBS.
wider range of nearby UEs, while simultaneously confusing detection due to its transient nature and distribution of signals. Multi-RAT orchestration. Leveraging its dual-channel architecture, the C-FBS supports concurrent operations of arbitrary network combinations to facilitate tailored attack vectors. For instance, operators can deploy an LTE-to-2G setup for conventional downgrades, or an LTE-to-3G configuration to target modern UEs that support the 2G disable option [30,72] and execute further exploitation via legacy technology. Beyond heterogeneous pairings, the device also supports homogeneous instances – such as two distinct LTE cells – to efficiently target multiple bands simultaneously, along with frequency hopping. This allows the attacker to construct a high-fidelity synthetic topology by mirroring legitimate neighbor relationships, effectively and stealthily expanding the attack surface. Dynamic transmission management. The device offers adjustable transmission power and Tx attenuation, allowing the operator to fine-tune the effective coverage range (within 2-10 m) and modulate RF characteristics. This capability allows the operator to balance between stealth by minimizing signal anomalies and attack efficiency by prioritizing extensive coverage. It supports external power amplifiers to boost the signal range. Flexible cell configuration capabilities and this dynamic transmission facilitate the covert luring of nearby UEs by exploiting handover and cell reselection (§5.2).
self-built prototypes with simplified operational behaviors: static adversaries with predictable patterns such as distinctive cell identifiers, constant high power, and static frequency residency. Our C-FBS analysis reveals its operational capabilities are absent from most models, including environment adaptation, frequency hopping, and dynamic transmission control. Lack of operational diversity. Academic models typically represent case-specific threat designs by considering limited adversarial capabilities rather than combinatorial complexity of diverse operations observed in C-FBS. While some studies [28, 59, 67] attempted to incorporate operational diversity with flexible configuration, Tab. 1 reveals that most still provide only partial coverage across operational dimensions: implementing subsets of flexible configuration, frequency hopping, multi-RAT orchestration, or dynamic transmission without systematic integration enabling operational diversity. Fragmented operational scope. Academic models typically represent isolated aspects of FBS operations rather than integrated attack chains. Tab. 1 shows existing models lack fullchain coverage spanning (hardware-originated) physical-layer features, protocol-layer behaviors, and multi-phase workflows (reconnaissance, launching, attack execution). Our C-FBS analysis reveals these elements operate in concert: hardware constraints influence protocol behaviors (e.g., bandwidth information and multi-RAT RF-channels), attack phases depend on prior configurations, operational success requires end-to-end coordination. Fragmented models miss these cross-component dependencies observed in C-FBS. Implications. These gaps create systematic blind spots. Detection research relying on simplified threat models with static behaviors, case-specific implementations, and fragmented operational scope optimizes against narrow adversarial assumptions, potentially overlooking operational capabilities available in commercial FBS implementations. Additionally, most academic models remain unavailable as artifacts (Tab. 1), hindering research continuity. Without accessible reference implementations, each study develops isolated prototypes, preventing cumulative progress and objective benchmarking. Specifically, although some studies [28, 59, 67] attempted to diverge from static assumptions by incorporating flexible configurations, the lack of reference relegates such advancements to isolated efforts. These gaps motivate systematic requirements for adversarial modeling (§3.4).
3.3 Limitations in Prior Threat Models (RQ2)
3.4
We identify limitations in academic adversary modeling by comparing prior models against our C-FBS analysis to reveal systematic gaps between academic assumptions and realworld capabilities. This section focuses on characterizing threat modeling rather than detection mechanisms. As summarized in Tab. 1, academic models exhibit three systematic gaps when compared against C-FBS capabilities: Simplified operational behaviors. Academic models employ
Based on gaps identified in §3.3, we derive five requirements for adversarial modeling. These requirements address both research evaluation and representation of commercial threats, including high-end systems reportedly priced up to $1M+ [41]. R1: Empirical grounding. Adversarial models require concrete starting points rooted in actual threats. Our C-FBS analysis (§3.2) reveals real-world operational capabilities absent from self-built prototypes: flexible configuration in cell
Adversarial capabilities of C-FBS (§3.2.3) Flexible configuration Cell-clone Ali et al. [9] Apple’s patent [16] Bitsikas et al. [15] CellGuard [11] Crocodile Hunter [63] FBS-Radar [48] FBSDetector [67] FBSleuth [87] FlashCatch [57] GSMK Overwatch [79] Heijligenberg et al. [37] Huang et al. [40] IMSI-catcher-catcher [23] LeopardSeal [60] Marlin [80] Murat [52] Park [59] Phoenix [28] Rayhunter [64] Seaglass [54] Shaik et al. [69] Steig et al. [73]
Msg-varying
Frequency hopping
Multi-RAT orchestration
Dynamic transmission
Modeling basis
Reference model
Full-chain view∗
Design artifact availability
†
†
†
∗ Comprehensive understanding from physical-layer features dictated by hardware to complex protocol behaviors. † Provide traffic gathered from their own FBS implementation or field measurements.
4
Threat Modeling Requirements (RQ3)
cloning and message tailoring, frequency hopping, multi-RAT orchestration, and dynamic transmission management. While limited to a single $50K device, this empirical baseline captures the basis of realistic adversarial behaviors – establishing the grounding for systematic extension (R2). R2: Specification-driven coverage. Analyzing all commercial FBS is infeasible. Systematic threat modeling requires exploring the adversarial design space – operations adversaries can perform within protocol constraints defined in 3GPP specifications. For example, IMSI-catching supports multiple compliant methods (Identity Request, NAS Reject with specific causes [2, 80]). Specification-driven exploration extends empirical observations (R1) to systematic coverage. R3: Configuration-driven coverage. The commercial FBS ecosystem exhibits heterogeneity, spanning $10K portable units to $1M+ integrated systems [41] with different radio resources, RF capabilities, and feature sets. Adversarial models must support instantiation across this spectrum through configuration diversity, ensuring detection research covers realistic commercial breadth rather than narrow assumptions. R4: Operator-driven adaptation. Beyond configuration diversity (R3), adversarial models must capture how operators strategically adapt behaviors to operational context, reflecting recent field observations in Marlin [80] identify an adaptive attacker reducing IMSI-catching volumes and varying messages (i.e., favoring NAS Reject over the conventional Identity Request). Adversarial models must support tunable capabilities allowing operators to enable, disable, or adjust features based on circumstances, rather than fixed behaviors. R5: Full-chain integration. While operator-driven adaptation (R4) captures strategic decisions, adversarial models must represent manifestation across the complete operational pipeline. Each configuration must operate end-to-end across the full attack chain. Without full-chain integration, detection opportunities at intermediate phases remain unexplored.
4
existing detection, which arises from simplified threat assumptions. Devilray is further designed to serve both as a realistic adversary model and as a standardized reference baseline, enabling objective benchmarking and comparative evaluation of disparate detection systems under consistent ground truth. We identify key design challenges (§4.1), and outline our methodology to address them (§4.2). Architectural and implementation details follow in §5.
4.1
Challenges
Addressing modeling gaps introduces four design challenges: C1: Establishing a unified operational baseline. Modeling an extensive threat space requires an end-to-end baseline covering the full scope of FBS operations. However, prior efforts have largely relied on simplified and fragmented prototypes, lacking a unified view. C2: Capturing operational realism. Systematically extending the empirical behaviors observed in C-FBS into the broader design space presents a significant design hurdle. The challenge lies in reflecting potential operations of realistic and adaptive threats by enabling the granular tuning of behaviors to suit specific operational contexts. C3: Ensuring adversarial feasibility. Specification-driven exploration naturally yields numerous adversarial alternatives, but not all configurations are operationally valid. Without careful validation, adversary generation risks producing configurations that violate protocol semantics, hardware constraints, or cross-phase dependencies, undermining realism. C4: Reproducing combinatorial diversity. Achieving adversarial diversity requires a reconfigurable architecture capable of systematically instantiating a wide range of configurations to cover a wide spectrum of adversarial behaviors.
4.2
Methodology
We address the identified challenges through the following structured methodologies as illustrated in Fig. 2: M1: Empirically grounded operational pipeline. Devilray adopts a unified four-phase operational pipeline – scanning, launching, hijacking, and application – derived from analysis of existing literature and our C-FBS study. The C-FBS workflow (§3.2.2) is operator-facing and presents a coarsegrained progression; in Devilray we refine execution into launching, hijacking, and application to isolate protocol-level behaviors, enable phase-specific variants, and support dependency checking. This pipeline captures end-to-end operation spanning physical-layer and protocol-layer behaviors. M2: Specification-driven variations derivation. To model diverse realistic adversarial strategies beyond single-device observations, Devilray systematically derives operational variations and adaptation from spec-based adversarial strategy and detection primitive analysis. This approach captures standard-compliant alternatives that adversaries can exploit in
Approach: Devilray (RQ4)
To address modeling gaps identified in §3 and enable exploration of the adversarial space, we introduce Devilray, a reconfigurable and reference-grade FBS model. Rather than assuming hypothetical capabilities, Devilray is grounded in our empirical analysis of a C-FBS and extended through specification-driven exploration of the adversarial design space. This combination enables Devilray to represent both observed real-world behaviors and standard-compliant alternatives beyond a single device. As a result, Devilray spans a broad range of adversarial configurations – covering 2,592 distinct instances – that capture the diversity of the commercial FBS ecosystem while remaining operationally feasible. Our goal is not exhaustive enumeration of the adversarial space, but systematic exploration of adversarial structures and revealing unexplored adversarial space (blind spots) in 5
1 Unified Operational Pipeline
C-FBS Characterization
Vendor Manuals
Scanning
Launching
2
Integrating Variants
Spec/Detection Analysis Adversarial Strategies
3GPP, Papers
Specifications
3 Dependency Checker Spec/Empirical Knowledge Dependency Rule set
4 Reconfigurablity
.YAML
Detection Primitives Tech reports, Literature
Hijacking
Application
Config. Validation
Derived Variants
Generated FBS Instances
Fig. 2: The Devilray methodology. ①-④ correspond to stages M1-M4 detailed in §4.2. practice, avoiding ad-hoc or hypothetical assumptions while enabling principled expansion of the adversarial design space. M3: Configuration validation. Devilray incorporates a semantics-aware dependency checker that validates protocol compatibility and cross-phase dependencies for each configuration based on empirical and domain knowledge. This ensures all instantiated adversaries are operationally feasible rather than merely specification-driven. Without such validation, configurations may include infeasible instances. M4: Reconfigurable implementation. Devilray is built as a modular, reconfigurable system that supports systematic instantiation across configuration space. This design enables 2,592 feasible adversarial instances spanning the commercial ecosystem from feature-constrained deployments to highend systems. It supports storing and reusing these instances via YAML-formatted configuration profiles, which will be released alongside the model to facilitate reproducible research.
5
anism coverage and adaptive operational variants, (2) absence of diversity through 2,592 specification-driven configurations validated via dependency checking, and (3) fragmented scope through end-to-end integration spanning physical-layer to protocol behaviors. Compared to C-FBS (§3.2), Devilray extends baseline capabilities through specification-driven exploration, anticipating evolution toward higher-end commercial deployments. Compared to academic prototypes (Tab. 1), Devilray provides the first accessible reference implementation spanning realistic operational diversity. Novelty. First, Devilray consolidates fragmented behaviors into a four-phase model providing unified end-to-end perspective. Second, it introduces operational variants from commercial practices and 3GPP specifications. Beyond presenting novel operations – including Timing Advance (TA) diversification, redirection via idleModeMobilityControlInfo, and hardware compensation – it provides the first systematic integration of disparate elements into functional architecture. Third, it introduces a semantics-aware dependency checker that validates the domain-specific constraints between hardware, protocols, and operational phases. By focusing on operationally feasible combinations, it enables the systematic configuration of 2,592 realistic instances, achieving a structured exploration of adversarial space, not exhaustive enumeration. This enables evaluation of detection mechanisms under realistic threat assumptions, positioning Devilray as a reference model for reproducible research.
Design of Devilray
In this section, we design Devilray based on our methodology. We first establish a unified four-phase operational pipeline (§5.1) extending C-FBS capabilities. Building on this, we derive and integrate operational variants (§5.2). Our approach characterizes FBS operational features from our empirical grounding and pipeline, followed by a specificationdriven expansion of feature dimensions based on detection domain analysis and 3GPP standards. We then introduce a dependency checker (§5.3) to ensure operational feasibility and enable systematic exploration of configuration-space diversity. Finally, we present a reconfigurable implementation (§5.4) enabling systematic instantiation of 2,592 configurations spanning realistic adversarial capabilities. The full spectrum of Devilray, including its modular, reconfigurable architecture and variants, is illustrated in Fig. 3. Note that Devilray primarily targets LTE to align with current detection systems, which predominantly focus on LTE and 5G-NSA due to their widespread deployment, persistent vulnerabilities, and expected operation for the next decade. Addressing limitations. Devilray addresses three gaps from §3.3: (1) simplified behaviors through systematic mech-
5.1
Unified Four-Phase Operational Pipeline
We establish a unified operational pipeline of FBS that consists of four distinct phases – Network Scanning, Cell Launching, Connection Hijacking, and Application – and design fundamental adversarial behaviors of Devilray for each phase. This pipeline consolidates fragmented and inconsistent views from prior literature into a cohesive framework where each phase produces specific outputs that constrain subsequent operations, thereby guaranteeing operational consistency. To construct this pipeline, we synthesize knowledge from a broad range of sources: literature on cellular surveillance [24, 29,31,49,62,76], academic studies [9,11,15,23,28,37,40,43, 48, 52–54, 57, 59, 63, 64, 67, 69, 73, 79, 80, 85–87], 3GPP speci6
Connection Hijacking & Application Configuration
Cell Launching Configuration Network scanning
Country/MNO_DB.json
Search neighbor cell
(V1) Broadcast parameter adaptation Adaptation mode
EARFCN/TAC
None Full-adaptation UE recovery
Auto Manual
PLMN
PCell SCell/NCell Random Manual
Auto Manual
(V1, V3) Collect broadcast msg.
PCI
Paging reproduction
Cell_DB.json
(V2) TA diversification
bool bool
Application mode
Cell iteration
(V3) Hijacking mechanism
Fixed cell Round Robin
Jamming Handover Cell reselection
2G redir./SMS injection
(V4) Victim targeting
(V4, V5, V6) App-variation
Multi-cell config.
IMSI-catching Location tracking Denial-of-service
Duration
uint bool
Non-target
(V7) HW compensation
Adaptive sampling Targeted operation Adaptive ratio float IMSI / GUTI pool list
Time sync. RF tuning
Alternative IMSI catching
Log .pcap .txt
.yaml
Concurrent cell num uint 2G cell config.
Config. DB
bool
Save & load config.
Store Devilray log
Launch DEVILRAY Dependency rule
Alternative redirection uint
Resolve conflicts
Exclude REJECT bool
Configuration Dependency checker
REJECT cause
uint
Fig. 3: Modular and reconfigurable architecture of Devilray, showing four operational phases and seven variant dimensions. fications [1,3,5], technical reports [26,35,45,77,78], publicly available vendor manuals [14, 18–22], and C-FBS (§3.2). 5.1.1
fixed or round-robin. Fixed mode maintains static cell parameters (PLMNs, ARFCNs, PCIs) throughout a dwelling duration. Round-robin mode rotates through different cell parameters at each interval, cycling across multiple PLMNARFCN–PCI combinations with frequency hopping to target different bands while distributing signal patterns. Multi-cell operation. Devilray can utilize its multi-channel capability with multiple SDRs to support concurrent multicell operations across homogeneous or heterogeneous RATS.
Network Scanning
Devilray begins with reconnaissance to identify target networks with which nearby UEs are communicating and gather configuration details from legitimate cells, necessary for subsequent cell setup and impersonation of those cells. Collected information is stored in a JSON-based database for later use. In this phase, Devilray scans available frequency bands to passively collect broadcast information, including MIB, all SIBs (type 1-24), and paging patterns from legitimate cells. Beyond the basic metadata (e.g., PLMN, PCI, signal strength) captured by C-FBS, Devilray harvests fine-grained parameters and operational behaviors, including random access configurations, scheduling settings, and cell reselection properties. Devilray can effectively achieve this through frequency hopping across detected cells for pre-configured durations, a process that can be parallelized using multiple radios to maximize coverage and minimize scanning latency. 5.1.2
5.1.3
Connection Hijacking
Devilray provides configurable adversarial strategies in this phase by supporting three hijacking mechanisms to lure nearby UEs: jamming, handover, and cell reselection. Here we address jamming as the baseline hijacking strategy, which operates with significant transmission power to lure UEs. Beyond jamming, more strategically complex, standard-driven mechanisms – handover and cell reselection – are extended as operational variants in §5.2. These strategies are grounded in specification and empirical study (see Appendix C for details), with detailed message flows illustrated in Fig. 8 (Appendix). The basic strategy of Jamming2 that Devilray provides is to force UEs to disconnect from legitimate cells and redirect them by overwhelming legitimate signals with higher-power transmissions. This exploits that UEs inherently prefer the strongest available cell [31]. The specific effect of hijacking depends on the UE’s state. For connected UEs, jamming triggers a Radio Link Failure (RLF) and the transmission of an RRC Reestablishment Request to Devilray, which fails because Devilray lacks the UE context, ultimately redirecting them to Devilray through a new connection. For idle mode UEs, which camp on the serving cell by listening to broadcast messages, jamming disrupts the reception of these messages, causing them to eventually camp on Devilray’s broadcasts. Although ef-
Cell Launching
Devilray offers a configuration space for fine-grained cell parameters, broadcast signals, and RF operations to emulate benign base stations. This phase involves strategic decisions on cell identifiers, power levels, and air-interface settings to make nearby UEs recognize Devilray as a viable candidate. Configuration of cell parameters. Devilray initializes exhaustive broadcast identifiers and radio configurations, including PLMN, TAC, PCI, bandwidth, ARFCNs, paging content, and reselection priorities. Devilray supports the complete definition of these settings by utilizing reconnaissance data harvested during the scanning phase to populate the cellular configurations. This capability facilitates granular control over comprehensive broadcast and unencrypted channel information, surpassing the capability of C-FBS to reflect network environments. Cell-iteration. Devilray supports two operational methods:
2 Unlike conventional jamming as a means to force UEs to migrate to different frequency bands through signal interference, Devilray’s jamming refers to overwhelming legitimate signals on the same frequency with a power advantage, exploiting cell selection logic to directly hijack UEs.
7
Application
Devilray provides four primary attack capabilities: IMSIcatching, location tracking, 2G redirection, and DoS. IMSI-catching. The fundamental IMSI-catching functionality collects the UE’s IMSI by sending an Identity Request message and then promptly disconnects the UE via a NAS Reject message. Beyond this, it also supports further variants, which will be detailed in §5.2. Location tracking. Using IMSIs, Devilray can track UEs’ locations by periodically issuing IMSI paging and Identity Request messages to trigger UE responses. It measures the response signal strength. This design, inspired by the C-FBS, allows for both coarse-grained presence checks and fine-grained localization when combined with a directional antenna. DoS. Devilray can disrupt UEs’ network access by sending crafted NAS Reject messages with cause #22 (Congestion [2]), which force UEs to suspend network search for extended periods (up to 30 minutes) [50]. By repeatedly injecting such messages, it can maintain persistent service unavailability. 2G redirection and SMS injection. Devilray can redirect hijacked UEs from LTE to legacy 2G bands via unprotected RRC redirection procedures (redirected CarrierInfo in RRC Connection Release) or inter-RAT cell reselection (SIB7). This enables Devilray to perform SMS injection, known as the SMS blaster [56], which exploits the weak authentication and encryption of 2G networks. By operating both LTE and 2G channels simultaneously, Devilray hijacks the UE on LTE, redirects it to 2G, and performs SMS injection. Also, Devilray includes an alternative redirection vector (§5.2).
5.2
RF char.
Timing err.
TA cmd.
Null cipher
Redirection
Cell info.
Ali et al. [9] ◦ Apple patent [16] ◦ ◦ ◦ ◦ ◦ ◦ CellGuard [11] ◦ ◦ ◦ Crocodile Hunter [63] ◦ ◦ EAGLE Security [42] ◦ ◦ FBSDetector [67] ◦ ◦ ◦ ◦ ◦ ◦ FBSleuth [87] ◦ FBS-Radar [48] ◦ ◦ GSMK Overwatch [79] ◦ ◦ ◦ Heijligenberg et al. [37] ◦ ◦ Huang et al. [40] ◦ IMSI-Catcher-Catcher [23] ◦ ◦ ◦ Karaçay et al. [43] ◦ LeopardSeal [60] ◦ Marlin [80] ◦ Murat [52] ◦ ◦ Nakarmi et al. [53] ◦ Park [59] ◦ ◦ ◦ PHOENIX [28] ◦ ◦ ◦ ◦ Rayhunter [64] ◦ ◦ ◦ ◦ SeaGlass [54] ◦ ◦ ◦ ◦ ◦ Steig et al. [73] ◦ Operational Variants V3 V3 V4 V6 V1 V5 ∗ V2 V7 V7 ∗ Null ciphering can be covered by V5. Rather than triggering easily observable protocol anomalies (null cipher use in LTE/5G), an adversary without security keys can alternatively exploit legacy networks via standardcompliant redirection, where encryption is inherently weak or absent (2G/3G).
fective against both UE states, jamming requires substantial transmission power (> 20 dB than benign cells), limiting its attack range. 5.1.4
Reject msg.
Variants V1 V2 V3 V4 V5 V6 V7
IMSI-exp. msg.
Related Standards TS 24.301 [2], TS 36.331 [5] TS 36.321 [4] TS 36.304 [3], TS 36.331 [5] TS 24.301 [2] TS 36.331 [5] TS 24.301 [2], TS 36.331 [5] TS 36.401 [6], TS 38.401 [8]
Signal strength
Feature dimension Cell parameters Restricted coverage Signal power Identity signaling Legacy redirection Protocol sequence HW dependency
Tab. 3: Detection primitives across FBS detection systems and operational coverage of Devilray’s variants. RRC failure
Tab. 2: FBS operational features and corresponding Devilray’s variants based on related standards.
We first establish seven representative FBS operational features based on our study of C-FBS and operational pipeline, as described in Tab. 2. We then use detection primitives (Tab. 3; Appendix A for detail) as an indexing lens to align feature dimensions with observable artifacts and navigate relevant standards, rather than for detector-specific tailoring. Finally, we systematically derive Devilray’s operational variants across seven dimensions (Tab. 2) by expanding the identified features based on relevant standards, where each dimension addresses distinct aspects of realistic FBS operation. Accordingly, these operational variants characterize the feasible design space that realistic adversaries may occupy within specification constraints. Coverage gaps observed in §6 reflect assumptionbounded design and evaluation, rather than targeted evasions. Tab. 3 summarizes 10 detection primitives identified across 22 existing detection systems – observable artifacts that can be leveraged to distinguish FBSs from legitimate infrastructure – and shows operational coverage of variants across primitives. Notably, while V2, V5, and V7 are first introduced to serve as FBS operations, others – though previously discussed in theory – are first systematically designed and integrated as functional variants into an end-to-end system by Devilray. V1) Environment adaptation. Rather than fixed or randomized configurations, C-FBS supports adapting broadcast identifiers [5] based on reconnaissance. Devilray extends this into fine-grained dynamic adaptation through three strategies: (1) full parameter alignment (full-adaption) – replicating collected identifiers, radio configurations, and reselection properties to match observed network environment, (2) Paging reproduction – matching timing, structure, and content of legitimate paging broadcasts, and (3) controlled parameter variation (UE-recovery) – selective TAC modification to enable post-attack UE recovery to legitimate networks while preserving other parameters [2]. C-FBS implements limited identifier
Integrating Operational Variants
Building on Devilray’s fundamental operational pipeline, we systematically derive operational variants and integrate them that span realistic adversarial capabilities beyond the single empirical observation. These variants represent specificationcompliant operational diversity derived from three sources: empirical observations of C-FBS (§3.2), analysis of detection primitives, and systematic exploration of 3GPP standards. 8
configuration; Devilray extends this through systematic parameter control, enabling environment-specific adaptation. V2) TA diversification. 3GPP TS 36.321 [4] specifies TA commands in random access, with values 0-1,282 representing propagation delay compensation (each unit: 78m). In our empirical observation, C-FBS typically exhibits limited geographic coverage with a distribution of lower TA values (≤ 1) due to transmission power constraints. Meanwhile, legitimate networks serving larger geographic areas produce distributed TA measurements. Realistic adversaries with constrained coverage may diversify TA distributions to reflect broader operational context. Devilray models TA diversification by randomizing command values within 0-30 range – we empirically validated that it does not impair UE connectivity while producing geographic distribution diversity. V3) Power-efficient hijacking. Although C-FBS allows for reduced transmission power to enhance stealth and power efficiency, achieving hijacking with constrained power requires extensions grounded in specification-informed logic; 3GPP standards define multiple mobility management mechanisms – handover for connected UEs [5] and cell reselection for idle UEs [3]. By exploiting them, Devilray can succeed with modest relative power differences to effectively take over UE connections in hijacking phase (Appendix C and Fig. 8). Devilray manipulates the handover process [5] by emulating legitimate neighbors through PCI reuse and transmitting stronger signals, influencing the UE’s Measurement Report [15,67,69]. The Measurement Report, which includes the signal strength and quality of neighboring cells, is crucial for triggering handover decisions in the network. For instance, when a neighboring cell’s signal meets the measurement criteria and exceeds the threshold configured by the serving network, the UE triggers a Measurement Report (Event A4) to the network, which then decides to initiate a handover [5, 15]. By manipulating this report, Devilray can induce the network to initiate a handover through an RRC Connection Reconfiguration. Although this procedure fails on Devilray’s side due to the lack of legitimate UE context (i.e., handover failure), the UE eventually connects to Devilray by redirecting to the strongest available cell, completing the hijacking process. This mechanism is only effective for connected mode UEs, yet requires a lower power advantage (> 3 dB) than jamming. To target idle mode UEs with lower transmission power, Devilray supports cell reselection based hijacking [37]. When in idle mode, UEs periodically evaluate surrounding cells and reselect the serving cell based on signal quality and reselection criteria broadcast in SIB [3]. These criteria, which vary depending on intra-frequency or inter-frequency, include signal thresholds and frequency priorities. Devilray can exploit this mechanism by configuring its operating frequency band to have the highest reselection priority and broadcast stronger signals (> 5 dB). Since SIB messages are transmitted in plaintext, reselection priorities can be iden-
tified, allowing Devilray to adjust its settings accordingly. Through this mechanism, Devilray increases the likelihood that idle UEs will reselect to it. Furthermore, connection hijacking often induces abnormal failures, such as RLFs or handover failures. These disruptions leave observable anomalies in the form of RLF reports or RRC Reestablishment Requests. With cell reselection, Devilray can redirect UEs without generating such RRC failures. Although UE states cannot be directly controlled, the cellular nature of frequent transitions between idle and connected modes allows Devilray to capture targets while reducing both signal and failure anomalies. V4) Alternative/Adaptive identity collection. While C-FBS adopts an aggressive volume of Identity Request followed by NAS Reject for IMSI-catching, realistic adversaries may employ specification-compliant alternatives and adaptive application strategies. 3GPP TS 24.301 [2] and a prior study [80] specify multiple ways of triggering identity exposure. Devilray models identity collection diversity: (1) alternative signaling (Reject-based IMSI catching) – sending crafted NAS Reject with specific causes (e.g., #9 UE identity cannot be derived by the network) instead of issuing explicit Identity Request, (2) adaptive sampling – identity collection applied to arbitrary or selectively applied to only a fraction of UEs (e.g., 10–20%) rather than universal, and (3) targeted operation – IMSI/GUTI-based victim filtering for focused collection. Thanks to Devilray’s reconfigurable nature, adaptive and targeted operations are also extended to other applications. V5) Alternative redirection. 3GPP TS 36.331 [5] specifies idleModeMobilityControlInfo as an optional field in RRC Connection Release, designed to provide dedicated cell reselection priorities upon radio connection termination. This mechanism serves as a further redirection vector beyond conventional methods utilized by C-FBS and actively monitored by detectors – SIB7 for cell reselection guidance [16, 64] or redirectedCarrierInfo in RRC Connection Release [64]. Devilray models idleModeMobilityControlInfo-based redirection by configuring the highest reselection priority for target legacy frequencies in RRC Connection Release, enabling UE transition to Devilray’s concurrent 2G/3G cells through standard reselection procedures. This specificationcompliant alternative is featured alongside conventional mechanisms (SIB7, redirectedCarrierInfo), demonstrating protocol flexibility for legacy network transitions. C-FBS implements conventional redirection with redirectedCarrierInfo; Devilray extends coverage to alternative redirection beyond fixed commercial implementations. V6) Reshaping message sequence. Realistic adversaries may diversify protocol message sequences based on operational context. Representatively, although C-FBS employs NAS Reject [2] for connection termination as a post-attack operation, it can be replaced with RRC Connection Release [5]. They are connection termination mechanisms defined in the 3GPP specifications across different layers. 9
Devilray models this type of sequence reshaping through connection management flexibility (Exclude REJECT): (1) RRC Connection Release as a specification-driven alternative to NAS Reject, terminating connections at radio layer [59] or (2) silent – connection timeout through non-response to UE signaling [57]. These alternatives reflect protocol-layer flexibility enabling operational sequence variation. V7) Hardware compensation. 3GPP specifications [6, 8] define synchronization features for physical-layer signal integrity – encompassing both frequency stability and timing accuracy – to prevent inter-cell interference and maintain network stability. Legitimate infrastructure typically utilizes high-precision synchronization (from external elaborate clocks or operator-provided sources) and calibrated radio front-ends. In contrast, adversaries often rely on low-cost or resource-constrained hardware, e.g., the bandwidth-restricted SDR utilized by C-FBS. Such hardware imperfections manifest as observable physical-layer artifacts, including timing misalignments in transmitted radio frames [16], center frequency offsets (CFO), and modulation distortions [87]. Devilray models physical-layer diversity through hardware compensation strategies: (1) Time synchronization: employing external timing sources (e.g., GPSDO) to align frame timing with sub-microsecond accuracy and stabilize the internal clock, effectively mitigating timing errors and addressing hardware-originated artifacts, and (2) RF tuning: adjusting RF outputs and reducing modulation imperfections by injecting controlled CFO or shaping pilot signal magnitudes to reflect the RF characteristics of legitimate cells or represent the breadth of diverse hardware, ranging from entry-level SDRs to high-end systems ($1M [41]).
5.3
rates 3GPP specifications and our empirical validation results with COTS devices to account for UE behaviors. A representative example involves NAS Reject cause selection for alternative identity collection (V4); certain causes intended for Reject-based IMSI-catching force the victim UE to blacklist the current PLMN/TAC and attempt an IMSI Attach to alternative networks, incompatible with single-cell operation. In empirical study, we confirmed that only cause #9 is effective for single-cell operation (Rule 19). When the checker identifies such conflicts between the launching and application phases, it resolves them by applying context-aware solutions, such as enforcing multi-cell deployment or reject cause #9. Conflict resolution and validation. The dependency checker performs rule-based validation and resolution by prioritizing semantics of latter-phase configurations (hijacking and application) over the former one (launching) to ensure operational feasibility. Depending on the nature of the conflict, Devilray is designed to respond through one of the following ways: • Automatic Resolution: The checker adjusts lower-priority parameters to satisfy higher-priority constraints, such as filtering PCI candidates from the scanning database to match the selected hijacking strategy (Rule 17). • Strict Validation: Unresolvable conflicts – such as requesting handover without corresponding neighbor cell data – trigger configuration rejection with diagnostic output. • Prerequisite Enforcement: It also enforces prerequisite requirements – e.g., ensuring that IMSI/GUTI acquisition precedes targeted attacks (Rule 11) and validating redirection parameters match configured 2G carrier. Consequently, the Devilray dependency checker identifies and resolves a total of 21 comprehensive rules across intraphase and inter-phase conflicts to ensure every configuration is both logically consistent and operationally feasible. Our systematic conflict rules are available on our website [25].
Dependency Checker
We integrate a rule-based dependency checker into Devilray to ensure operational feasibility across configuration-space diversity. It validates configurations spanning four-phase behaviors and operational variants, preventing invalid parameter combinations that would violate specifications or operational constraints, as exemplified in Fig. 7 (Appendix). These encompass logical constraints in operational variants and practical requirements for luring UEs and executing attacks. Categorizing dependencies. Dependencies are classified into two conflict types. Intra-phase dependencies involve parameter constraints within a single phase, such as mutual exclusivity between full parameter alignment (V1) and manual network parameter selection (Rule 2 in Fig. 7). Inter-phase dependencies span multiple phases where high-level phase configurations impose constraints on subsequent phases. For instance, selecting handover as hijacking mechanism necessitates that PCI configuration reuse neighbor cells from the scanning phase, band allocation match observed networks, and power margin meet over 3 dB in launching (Rule 17). Knowledge-driven constraint rules. The rule set incorpo-
5.4
Reconfigurable Implementation
We build Devilray as a reconfigurable system by extending srsRAN [36], OpenBTS [61], and LTESniffer [38] with 8K lines of code. It supports diverse hardware setups from singleto multi-SDR operations, including USRP B210s [65] and high-end X310s [66], for scalable multi-cell combinations. Based on its implementation, Devilray enables the generation of a total of 2,592 feasible instances through the combinatorial configuration across different operational phases, with configuration space illustrated in Fig. 9 (Appendix). The total number of unique instances (Ntotal ) is derived as follows: Ntotal = Nlaunch × Nhijack × Napp = 32 × 3 × 27 = 2, 592 • Nlaunch (32): 2 (broadcast parameter adaptation) × 2 (cell iteration) × 2 (paging reproduction) × 2 (TA diversification) × 2 (hardware compensation). Each factor represents a binary configuration for its respective strategy (e.g., two broadcast parameter adaptation: unadapted or adapted). 10
Tab. 4: Evaluation results of IMSI-catcher instances. Devilray identifies adversarial blind spots in six detectors.
• Nhijack (3): Jamming, cell reselection, and handover. • Napp (27): 3 (victim targeting) × 9 (app variation). App variations are derived from 3 (IMSI-catching) + 2 (location tracking) + 1 (DoS) + 3 (Redirection and SMS injection). This counting is conservative: we enumerate only highlevel factors that admit a clean Cartesian-product structure (32×3×27), and intentionally coarsen other within-variant degrees of freedom instead of expanding them. For example, while some variants admit multiple standard-defined choices (e.g., different reject causes), we treat them as a single category to keep the space interpretable. Complete end-to-end configurations can be exported and reused as YAML-based profiles, facilitating usability and reproducibility. By releasing our implementation alongside YAML profiles and packet captures, we provide a reproducible reference platform for the community. This contribution of availability also allows researchers to integrate new attack vectors, fostering collaboration and innovation in FBS research.
6
Detection system C-FBS J + I + NA J+I+A J + IR + A J + Ir + A H+I+A H + IR + A H + Ir + A C+I+A C + IR + A C + Ir + A
PHOENIX∗ [28]
Rayhunter† [64]
– – – – – –
CellGuard‡ [11] (51)
Crocodile Hunter‡ [63] (13)
EAGLE Security‡ [42] (10)
FBSDetector♯ [67] 0% / –
(50) (30) (30) (0) (30) (30) (0) (30) (30) (0)
(21) (20) (21) (21) (5) (5) (4) (6) (7) (4)
(35) (25) (25) (25) (10) (10) (10) (10) (10) (10)
0% / 47.8% 50% / 44.6% 0% / 45.7% 33.3% / 82.3% 0% / 43.7% 0% / 46.8% 0% / 72.5% 0% / 61.5% 0% / 47% 50% / 74.7%
: Detected, : Suspect, : Missed. Detection score given in parentheses (‡ below). J: Jamming, H: Handover, C: Cell reselection, I: IMSI-catching with Identity Request, IR: IMSI-catching with NAS Reject, Ir: IMSI-catching with Identity Request then RRC release, NA: Non-Adaptation, A: Adaptation. ∗ We evaluate PHOENIX using the implementation provided by the FBSDetector [67], as the original system is not publicly available. † Rayhunter requires a separate Orbic mobile hotspot [83], which in our region could connect to commercial eNBs but failed to attach for mobile data. This prevents handover and cell reselection experiments that require data connectivity, leaving jammingbased hijacking as the only option. Nevertheless, the jamming experiments fully reflect Rayhunter’s protocol message based detection behavior, and we expect handover and reselection would yield the same results. ‡ They score suspiciousness on a (0-100) scale. CellGuard classifies 0-5 trusted, 6-50 anomalous, and 51-100 suspicious. Crocodile Hunter considers scores of 20 or higher suspicious. EAGLE Security uses 0-19 trusted, 20-25 anomalous, and 26-100 suspicious. ♯ Each result corresponds to detection accuracy on the NAS-layer (left) and RRC-layer (right) models, respectively. For the C-FBS, only NAS-layer detection is available, as it does not provide RRC-layer packet captures compatible with this system.
Evaluation
We examine security risks (i.e., blind spots) in existing FBS detection mechanisms (RQ4) by evaluating representative accessible detectors under realistic, specification-driven adversarial instances configured by Devilray3 . Rather than ranking detectors, our goal is to assess how current detection logic behaves when rigid threat assumptions (§3.3) are relaxed to reflect realistic operational diversity. We first evaluate currently available IMSI-catcher detectors in §6.1 and then extend the evaluation to physical-layer detection primitives in §6.2. Our setup consists of a laptop running Devilray software connected to two USRP B210s.
We first instantiate a diverse set of IMSI-catcher variations based on the Devilray configuration space (Fig. 9) to evaluate detector behavior. We prioritize IMSI-catching as it remains a primary FBS operation for surveillance and is correspondingly addressed by the majority of detectors. To instantiate IMSI-catchers, we adopt a controlled selection process that filters the vast configuration space of 2,592 combinations down into a variation set of phase-oriented dimensions. Specifically, within the IMSI-catcher subspace, we treat variants in launching phase – cell adaptation (V1) along with TA diversification (V2) – as a bundled baseline parameter, categorized into two binary settings: NA (adaptation disabled) and A (enabled). While using NA to establish a naive baseline for initial comparison, we explore the impact of connection hijacking (V3) and application-phase variations (V4, V6) by fixing V1 to A and performing a 3 × 3 cross-product sweep of
three hijacking mechanisms (J, H, C) and three applicationphase variations (I: Identity Request then NAS Reject, IR: Reject-based catching, Ir: Identity Request then RRC release). This process yields 10 instances, as shown in Tab. 4. An additional variation, adaptive IMSI-catching (V4), is examined separately against the statistical approach [80] later. Detection results on 10 instances. Tab. 4 presents evaluation outcomes for six publicly obtainable detectors [11, 28, 42, 63, 64, 67]4 using the 10-instance set, comparing with C-FBS. PHOENIX [28] exhibits limited visibility toward the Exclude Reject variant, which utilizes a specific sequence of an Identity Request followed immediately by an RRC Connection Release. Rayhunter’s [64] protocol-based anomaly detection does not trigger for the Alternative IMSI-catching variant that leverages NAS Reject instead of the widely expected Identity Requests. For detectors primarily monitoring signal strength and cell parameters – Crocodile Hunter [63] and EAGLE Security [42] – suspiciousness scores remain below detection thresholds when Devilray utilizes cell reselection or handover alongside environment adaptation. CellGuard [11] effectively identifies non-adaptation and the use of reject messages, yet it classifies Devilray as a trusted network when such specific indicators are replaced by operational variants. Finally, the ML-based FBSDetector [67] shows a decrease in accuracy compared to its reported performance (over 90%) when evaluated across 1,000 test trials of Devilray’s packet captures featuring specification-compliant variants. Adaptive IMSI-catching.
3 Prior to this evaluation, we validate Devilray’s effectiveness on con-
4 IMSI-catcher-catcher [23] and Seaglass [54] are excluded due to their
6.1
IMSI-catcher Instances
nection hijacking and application across seven COTS UEs in Appendix C.
decade-long lack of maintenance.
11
2nd principal component
IMSI Exposure Ratio
100% 80% 60% 40% 20% 0%
Cell Provider Football Game Bus Terminal from Marlin from Marlin
Adaptive Devilray
Court Event from Marlin
Extreme Devilray
Fig. 4: Distribution of IMSI-exposing messages. It shows the impact of Devilray’s variation on statistical significance. MNO 2 Devilray X310 Devilray X310+GPSDO
Error [us]
MNO 1 Devilray B210 Devilray B210+GPSDO
10 8 6 4 2 0
0
5
10
15
Elapsed time [s]
20
0.8 0.6 0.4 0.2 0
0
20
40
60
Amari Callbox Commercial FBS
2
1 0 1 1st principal component
2
3
ing misalignment between received radio frames using LTESniffer [38] and track cumulative drift over time. Specifically, we compute per-frame timing error and compare cumulative error across benign cells from three MNOs, Devilray (B210 and X310), and C-FBS. To assess the effect of external clock, we include measurements for GPSDO-equipped setups. Fig. 5 presents cumulative timing error across different cells. While the B210 and C-FBS without GPSDO exhibit substantial cumulative drift, the right plot reveals that equipping the C-FBS and X310 with a GPSDO reduces cumulative drift to sub-microsecond ranges. This hardware compensation (V7) renders Devilray nearly indistinguishable from legitimate infrastructure. RF characteristics. We extend RF fingerprinting – originally proposed by FBSleuth [87] for 2G – to LTE and evaluate it under hardware compensation (V7). We utilize three features: CFO, time synchronization error, and magnitude error (Appendix D for detail). To examine their effectiveness, we measured these features across three MNOs, Devilray, Amari Callbox [10], and C-FBS. While these devices initially exhibit distinct patterns that differentiate them from legitimate cells, we further explore the impact of hardware compensation. Using Principal Component Analysis (PCA), we visualize the projection space defined by legitimate cells and uncompensated FBS instances. As shown in Fig. 6, legitimate cells form tight clusters, while uncompensated FBS devices form separate, distinguishable clusters. However, by applying RF manipulation on Devilray (V7) – which introduces controlled software-based CFO injection – the resulting features become indistinguishable from those of legitimate cells. These results reveal blind spots in detection logic that assumes FBS operations are inherently limited by hardware imperfections; we demonstrate that operational variants involving hardware compensation (V7) in Devilray leads to gaps for detection relying on physical-layer artifacts. Takeaway. Our evaluation confirms that current detection paradigms suffer from adversarial blind spots. Narrow threat assumptions lead to systematic detection gaps when encountering realistic adversaries. These findings underscore the necessity of developing and evaluating future detection against
80
Fig. 5: Cumulative timing misalignment of radio frames. Left plot shows non-legitimate cells w/o GPSDO exhibiting significant misalignment. Right plot illustrates the effect of GPSDObased hardware compensation in mitigating timing errors to levels nearly indistinguishable from legitimate cells. Note the different axis scales used to highlight both the magnitude of misalignment and the precision of the compensation.
We evaluate Marlin [80], which performs statistical monitoring of IMSI-exposing messages, by comparing extreme (100% exposure) and adaptive (10%, V4) Devilray instances. Using five COTS UEs and 50 trials per instance with LTESniffer [38], we find that adaptive Devilray produces a distribution centered around 10% – overlapping with benign environments in Marlin’s dataset and our bus-terminal captures – whereas the extreme instance approaches 100% (Fig. 4). This suggests that Marlin’s statistical logic is sensitive to the aggregate rate of IMSI-exposing messages; by moderating this rate through adaptive collection, Devilray shifts its profile into the benign range, affecting detection logic primarily tuned for typical aggressive behaviors. These results demonstrate that narrow and fragmented threat models in current detection mechanisms lead to adversarial blind spots on different realistic threats. By leveraging Devilray to relax these rigid threat assumptions, we show that even established detection logic struggles to generalize to the realistic diversity of specification-driven operations.
6.2
Devilray B210 Devilray+RF manip.
Fig. 6: PCA results of RF features. It highlights Devilray successfully modulates its hardware profile to align with legitimate cells via RF tuning.
MNO 3 C-FBS C-FBS+GPSDO
Elapsed time [s]
2 1 0 1
Legitimate BS Devilray X310
Physical-layer Instances
We now evaluate physical-layer detection with Devilray under hardware compensation (V7), which uses external synchronization and RF parameter calibration to control hardware-level timing and RF-characteristic artifacts. Transmission timing error. To evaluate the robustness of transmission accuracy primitives against V7, we measure tim12
Tab. 5: Devilray vs. prior FBS implementations Connection hijacking
Variants (§5.2)
Reconfigurable instances
Availability
Bitsikas et al. [15] CellGuard [11] FBSDetector [67] FlashCatch [57] Heijligenberg et al. [37] Park [59] PHOENIX [28] Shaik et al. [69]
H J J, H J C J, H J H
V3∗ V1, V3∗ , V6 V6 V3∗ V1, V3∗ , V6 V6 V3∗
1 1 5 1 1 11 1 1
× × × × × × × ×
Devilray
J, H, C
V1 - V7
2,592
✔
Future use of Devilray and implications for countermeasures. Devilray helps detection validation by providing a controlled and extensible baseline anchored in a commercial device analysis and expanded via standard-compliant variants. Prior research characterizing FBS behavior has primarily relied on black-box, in-the-wild observations of suspected events, such as SMS fraud [86], anomalous identity broadcasts [23,54], or surges in identity-request signaling [80]. Without independent ground-truth confirmation, these analyses face a validation challenge: field measurements are often interpreted through the lens of detection logic, while detection efficacy is assessed based on those same unverified results. Beyond immediate validation, Devilray facilitates a systematic quantification of detection latency across the entire pipeline. While many current protocol-based defenses effectively trigger after connection hijacking or application phases – at which point user privacy may already be at risk – practical mitigation benefits from early-warning signals during the launching or pre-hijacking phases. Devilray provides the controlled environment required to measure this lead time, the temporal window between an initial alarm and actual harm. Separately, Devilray can support the design and evaluation of a complete countermeasure pipeline across detection, identification, and localization. Even against advanced adversaries, robust detection may be improved by cross-validating protocol-layer primitives with physical-layer ones. Such crosslayer correlation can provide higher-confidence identification needed to distinguish rogue transmitters from legitimate networks. Once identified, this evidence enables physical localization (e.g., Angle-of-Arrival (AoA) [47, 55] or Time Difference of Arrival (TDoA) [46]), supporting efforts to trace and confiscate them. Since these complex artifacts arise through full UE-infrastructure interactions, Devilray’s end-to-end testbed is available for comparative experiments across different vantage points (UE, sniffer, or MNO). Furthermore, Devilray enables a rigorous assessment of detector robustness against overfitting and false positives. By instantiating edge cases (e.g., rare but benign signaling configurations), it allows researchers to stress-test detectors and isolate the specific design assumptions driving spurious alarms. Extending to 5G-SA. While Devilray is currently implemented for LTE, it can be extended to 5G-SA as future work, since its operational pipeline aligns with the common nature across both cellular generations. Beyond this architectural compatibility, it can be extended to target 5G-SA users by exploiting inter-RAT transition to force a fallback to LTE – such as interfering with 5G-SA signals to trigger cell reselection to LTE, manipulating SIBs to induce an intentional redirection, or injecting NAS Reject messages to disable 5G-SA [44].
J: Jamming, H: Handover, C: Cell reselection. ∗ Focusing exclusively on either handover or cell reselection.
a structured adversarial space in an end-to-end manner to ensure robustness across a diverse operational range.
7
Related Work
Tab. 5 summarizes representative prior FBS implementations used in attack and detection studies. Within this set, implementations are often tied to a single hijacking mechanism or a narrow set of operational variants. Several works [11, 15, 28, 37, 57,69] evaluate a static adversary (one instance), which limits coverage of configurations that vary across UE states, network conditions, or operational sequences. Although FBSDetector [67] and Park [59] consider more adversarial conditions (five and eleven, respectively), their evaluations still cover specific combinations of hijacking methods (J, H), adaptation, and sequence reshaping. In contrast, Devilray supports combinatorial configuration across hijacking mechanisms and variants (V1-V7), yielding 2,592 feasible instances. A practical hurdle is availability. While some detection mechanisms are released as tools, the adversary implementations listed in Tab. 5 are not publicly available in reusable form, which limits reproducibility and cross-detector comparison under consistent adversarial settings. Devilray addresses this gap by providing a reconfigurable adversarial baseline that integrates multiple hijacking mechanisms with specification-driven operational variation and reusable configuration profiles, enabling reproducible research.
8
Discussion
Limitation. While this study establishes a foundational ground truth by analyzing real-world adversarial capabilities, it is not without limitations. Due to restricted access to comprehensive products, our empirical analysis was constrained to a single C-FBS product. However, our analysis underscored the narrow scope of existing threat models and directly motivated our systematic approach. Additionally, we address this, extending our observations into spec-driven variants. We further envision Devilray as an extensible platform that will undergo continuous refinement as the community identifies and integrates additional FBS traits from in-the-wild observations through collaborative feedback and insights.
9
Concluding Remarks
Due to the lack of a structured adversarial space, FBS detection research often relies on self-built prototypes with 13
simplified threat assumptions, leading to adversarial blind spots. In this work, we introduce Devilray, a reconfigurable and reference-grade adversarial baseline, to explore the structured adversarial design space and systematically uncover blind spots in current detection paradigms. Devilray extends real-world FBS capabilities into 2,592 specification-driven, realistic FBS instances, enabling systematic assessments of detection systems in a rigorous manner.
Ethical Considerations We obtained temporary access to a commercial FBS ($50K) from a third party under anonymity. The device was used only in a shielded, access-controlled laboratory and immediately returned after testing, with no exposure to public networks. We also considered the dual-use risks of releasing Devilray. While community access improves reproducibility and defense research, broad release could cause harm. To minimize risks, Devilray will be released only to vetted academic and government research groups through means such as email verification, with guidance for safe experimental setups (e.g., Faraday cage, RF configurations). We follow the Menlo Report principles of beneficence and respect for law [13]. All active experiments requiring signal generation in our paper are conducted in electromagnetically shielded basement laboratories to address ethical concerns. The testbed is enclosed in conductive mesh effectively preventing signal leakage. The controlled environment includes Devilray, the C-FBS, target UEs, and a cellular repeater relaying legitimate network signals to UEs. During our experiments at -70 dB, no signal frames were detected outside the enclosure using LTESniffer [38], consistent with the ≥50 dB attenuation provided by the shielding and normal UEs were not affected. Experiments involving only passive measurements (e.g., measuring RF signals from legitimate networks) were performed under normal conditions without shielding.
14
References
[14] Sam Biddle. Long-Secret Stingray Manuals Detail How Police Can Spy on Phones. https://theinterce pt.com/2016/09/12/long-secret-stingray-man uals-detail-how-police-can-spy-on-phones/, 2016. Accessed: 2025-04-02.
[1] 3GPP. TR 33.809, v18.1.0. Study on 5G security enhancements against False Base Stations (FBS), 2023. [2] 3GPP. TS 24.301, v15.8.0. UMTS; LTE; 5G; NonAccess-Stratum (NAS) Protocol for Evolved Packet System (EPS), 2019.
[15] Evangelos Bitsikas and Christina Pöpper. Don’t Hand It Over: Vulnerabilities in the Handover Procedure of Cellular Telecommunications. In Proceedings of the Annual Computer Security Applications Conference (ACSAC), 2021.
[3] 3GPP. TS 36.304, v18.3.0. LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) Procedures in Idle Mode, 2025.
[16] Elliot Briggs and Zhu Ji. Detection of a Rogue Base Station, 2018. US Patent 10,129,283.
[4] 3GPP. TS 36.321, v18.4.0. Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) Protocol Specification, 2025.
[17] CBC News. Someone is Spying on Cellphones in the Nation’s Capital. https://www.cbc.ca/news/poli tics/imsi-cellphones-spying-ottawa-1.40500 49, 2017. Accessed: 2025-04-15.
[5] 3GPP. TS 36.331, v18.4.0. LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol Specification, 2024.
[18] Harris Communications. iDEN 2.4 Operator Manual. https://embed.documentcloud.org/document s/3105641-iDEN-2-4-Operator-Manual/, 2013. Accessed: 2025-04-02.
[6] 3GPP. TS 36.401, v18.1.0. LTE; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Architecture Description, 2024. [7] 3GPP. TS 37.340, v18.4.0. Universal Mobile Telecommunications System (UMTS); LTE; 5G; Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-connectivity; Overall Description; Stage-2, 2025.
[19] Harris Communications. Gemini 3.3 Quick Start Guide. https://embed.documentcloud.org/documents/ 3105793-Gemini-3-3-Quick-Start-Guide/, 2014. Accessed: 2025-04-02.
[8] 3GPP. TS 38.401, v18.4.0. 5G; NG-RAN; Architecture Description, 2025.
[20] Harris Communications. Arrowhead 1.0.1 Release Notes. https://embed.documentcloud.org/do cuments/3105805-Arrowhead-1-0-1-Release-N otes/, n.d. Accessed: 2025-04-02.
[9] Arslan Ali and Georg Fischer. Enabling Fake Base Station Detection through Sample-based Higher Order Noise Statistics. In IEEE International Conference on Telecommunications and Signal Processing (TSP), 2019.
[21] Harris Communications. Gemini RayFish Controller R3.3.1 Release Notes. https://embed.document cloud.org/documents/3105849-Gemini-RayFish -Controller-R3-3-1-Release-Notes/, n.d. Accessed: 2025-04-02.
[10] Amarisoft. AMARI Callbox Classic. https://www.am arisoft.com/test-and-measurement/device-t esting/device-products/amari-callbox-class ic, n.d.
[22] Harris Communications. iDEN 2.4 Release Notes. ht tps://embed.documentcloud.org/documents/31 05806-iDEN-2-4-Release-Notes/, n.d. Accessed: 2025-04-02.
[11] Lukas Arnold, Matthias Hollick, and Jiska Classen. Catch You Cause I Can: Busting Rogue Base Stations using Cellguard and the Apple Cell Location Database. In Proceedings of the International Symposium on Research in Attacks, Intrusions and Defenses (RAID), 2024.
[23] Adrian Dabrowski, Nicola Pianta, Thomas Klepp, Martin Mulazzani, and Edgar Weippl. IMSI-Catch Me If You Can: IMSI-Catcher-Catchers. In Proceedings of the Annual Computer Security Applications Conference (ACSAC), 2014.
[12] DAN ATKINSON. Stingrays, Simulators, Surveillance, and Silverados. https://horizonmass.news/2024/ 02/06/stingrays-simulators-surveillance-a nd-silverados/, 2024. Accessed: 2025-09-02.
[24] Dan Atkinson. Mass Surveillance: Cell Tower Simulator Coming to a Silverado Near You. https://theshoes tring.org/2024/04/05/mass-surveillance-cel l-tower-simulator-coming-to-a-silverado-n ear-you/, 2024. Accessed: 2025-04-19.
[13] Michael Bailey, David Dittrich, Erin Kenneally, and Doug Maughan. The Menlo Report. IEEE Security & Privacy, 2012. 15
[25] Devilray. Our public website about Reconfigurable and Reference-grade Fake Base Station. https://sites. google.com/view/devilray.
[36] I. Gomez-Miguelez, A. Garcia-Saavedra, P. D. Sutton, P. Serrano, C. Cano, and D. J.Leith. srsRAN: An OpenSource Platform for LTE Evolution and Experimentation. https://github.com/srsran/srsRAN, 2019. Accessed: 2025-04-19.
[26] Dhruv Mehrotra. We Hunted Hidden Police Signals at the DNC. https://www.wired.com/story/dnc-h idden-signal-hunt, 2024. Accessed: 2025-04-15.
[37] Thijs Heijligenberg, David Rupprecht, and Katharina Kohls. The attacks aren’t alright: Large-Scale Simulation of Fake Base Station Attacks and Detections. In Proceedings of the 17th Cyber Security Experimentation and Test Workshop, 2024.
[27] Dhruv Mehrotra, Matt Burgess. Cybercriminals Have a Weird New Way to Target You With Scam Texts. https: //www.wired.com/story/sms-blasters-scam-t exts/, 2025. Accessed: 2026-01-17.
[38] Tuan Dinh Hoang, CheolJun Park, Mincheol Son, Taekkyung Oh, Sangwook Bae, Junho Ahn, Beomseok Oh, and Yongdae Kim. LTESniffer: An Open-source LTE Downlink/Uplink Eavesdropper. In Proceedings of the ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec), 2023.
[28] Mitziu Echeverria, Zeeshan Ahmed, Bincheng Wang, M Fareed Arif, Syed Rafiul Hussain, and Omar Chowdhury. Phoenix: Device-centric Cellular Network Protocol Monitoring using Runtime Verification. In Proceedings of the Network and Distributed System Security Symposium (NDSS), 2021.
[39] Byeongdo Hong, Shinjo Park, Hongil Kim, Dongkwan Kim, Hyunwook Hong, Hyunwoo Choi, Jean-Pierre Seifert, Sung-Ju Lee, and Yongdae Kim. Peeking over the cellular walled gardens-a method for closed network diagnosis. IEEE Transactions on Mobile Computing, 2018.
[29] Electronic Frontier Foundation. Gotta Catch ’Em All: Understanding How IMSI-Catchers Exploit Cell Networks. https://www.eff.org/wp/gotta-catch-e m-all-understanding-how-imsi-catchers-exp loit-cell-networks, 2019. Accessed: 2025-04-02.
[40] Ke-Wen Huang and Hui-Ming Wang. Identifying the Fake Base Station: A Location Based Approach. IEEE Communications Letters, 2018.
[30] Electronic Frontier Foundation. Apple and Google are Introducing New Ways to Defeat Cell Site Simulators, but is it Enough? https://www.eff.org/deeplink s/2023/09/apple-and-google-are-introducing -new-ways-defeat-cell-site-simulators-it-e nough, 2023. Accessed: 2025-04-19.
[41] Jacobs Technology Inc. Proposal Response for Cell Site Simulator (CSS) Program for the Massachusetts StatePolice (MSP). https://www.documentclou d.org/documents/24733508-2024_ma-state-p olice_css-proposal_jacobs/, 2024. Accessed: 2026-01-21.
[31] Electronic Frontier Foundation. Street Level Surveillance. https://sls.eff.org/technologies/cel l-site-simulators-imsi-catchers, 2023. Accessed: 2025-04-19.
[42] Int64 Team. EAGLE Security. https://play.googl e.com/store/apps/details?id=com.integer.ea glesecurity_free, 2014. Accessed: 2025-08-09.
[32] Eric Priezkalns. Minister Refuses to Answer Questions about Chinese Scam SMS Blasters Circling Japan. http s://commsrisk.com/minister-refuses-to-ans wer-questions-about-chinese-scam-sms-blast ers-circling-japan/, 2025. Accessed: 2026-01-17.
[43] Leyli Karaçay, Zeki Bilgin, Ayşe Bilge Gündüz, Pinar Çomak, Emrah Tomur, Elif Ustundag Soykan, Utku Gülen, and Ferhat Karakoç. A Network-Based Positioning Method to Locate False Base Stations. IEEE Access, 2021.
[33] Simon Erni, Martin Kotuliak, Patrick Leu, Marc Roeschlin, and Srdjan Capkun. AdaptOver: Adaptive Overshadowing Attacks in Cellular Networks. In International Conference on Mobile Computing And Networking (MobiCom), 2022.
[44] Bedran Karakoc, Nils Fürste, David Rupprecht, and Katharina Kohls. Never Let Me Down Again: BiddingDown Attacks and Mitigations in 5G and 4G. In Proceedings of the ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec), 2023.
[34] GALAN. GSM Spy Finder. https://apk.support/ app/kz.galan.antispy. Accessed: 2025-04-18.
[45] Merrit Kennedy. Feds Say They’ve Detected Apparent Rogue Spy Devices In D.C. https://www.npr.org/ sections/thetwo-way/2018/04/04/599428495/ feds-say-theyve-detected-apparent-rogue-s py-devices-in-d-c, 2018.
[35] Gesellschaft für Freiheitsrechte. IMSI Catcher. https: //freiheitsrechte.org/en/themen/digitale-g rundrechte/ismi-cathcer, 2020. Accessed: 202504-15. 16
[46] Martin Kotuliak, Simon Erni, Patrick Leu, Marc Roeschlin, and Srdjan Capkun. LTrack: Stealthy Tracking of Mobile Phones in LTE. In USENIX Security Symposium, 2022.
[56] Hilary Osborne. Police warn of SMS scams as ‘blaster’ is used to send thousands of texts. https://www.th eguardian.com/money/2025/jun/24/police-sms -scams-blaster-texts-smishing, 2025. Accessed: 2025-08-25.
[47] Swarun Kumar, Ezzeldin Hamed, Dina Katabi, and Li Erran Li. LTE Radio Analytics Made Easy and Accessible. In Proceedings of the ACM SIGCOMM, 2014.
[57] Andrea Paci, Gabriele Bologna, Ivan Palamà, and Giuseppe Bianchi. FlashCatch: Minimizing Disruption in IMSI Catcher Operations. In Proceedings of the ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec), 2025.
[48] Zhenhua Li, Weiwei Wang, Christo Wilson, Jian Chen, Chen Qian, Taeho Jung, Lan Zhang, Kebin Liu, Xiangyang Li, and Yunhao Liu. FBS-Radar: Uncovering Fake Base Stations at Scale in the Wild. In Proceedings of the Network and Distributed System Security Symposium (NDSS), 2017.
[58] Pierluigi Paganini. Cellphone Surveillance: The Secret Arsenal. https://www.infosecinstitute.com/r esources/general-security/cellphone-surve illance-the-secret-arsenal/, 2016. Accessed: 2025-09-02.
[49] Beryl Lipton and Cooper Quintin. The Next Generation of Cell-Site Simulators is Here. Here’s What We Know. https://www.eff.org/deeplinks/2024/06/next -generation-cell-site-simulators-here-her es-what-we-know, 2024. Accessed: 2025-04-19.
[59] Shinjo Park. Why We Cannot Win: On Fake Base Stations and Their Detection Methods. Technische Universitaet Berlin (Germany), 2023. [60] Christian Peeters, Tyler Tucker, Anushri Jain, Kevin Butler, and Patrick Traynor. LeopardSeal: Detecting Call Interception via Audio Rogue Base Stations. In Proceedings of the International Conference on Mobile Systems, Applications and Services (MobiSys), 2023.
[50] Wei Liu, Yuanjie Li, Hewu Li, Yimei Chen, Yufeng Wang, Jingyi Lan, Jianping Wu, Qian Wu, Jun Liu, and Zeqi Lai. The Dark Side of Scale: Insecurity of Directto-Cell Satellite Mega-Constellations. In IEEE Symposium on Security and Privacy (S&P), 2024.
[61] PentHertz. OpenBTS. https://github.com/PentH ertz/OpenBTS, 2014. Accessed: 2025-09-01.
[51] Ulrike Meyer and Susanne Wetzel. A Man-in-theMiddle Attack on UMTS. In Proceedings of the 3rd ACM workshop on Wireless security, 2004.
[62] Privacy International. IMSI catchers legal analysis. ht tps://privacyinternational.org/sites/defau lt/files/2020-06/IMSI%20catchers%20legal% 20analysis.pdf, 2020. Accessed: 2025-04-18.
[52] Prajwol Kumar Nakarmi, Mehmet Akif Ersoy, Elif Ustundag Soykan, and Karl Norrman. Murat: MultiRAT False Base Station Detector. arXiv preprint arXiv:2102.08780, 2021.
[63] Cooper Quinti. Detecting Fake 4G LTE Base Stations in Real Time. https://www.usenix.org/confere nce/enigma2021/presentation/quintin, 2021.
[53] Prajwol Kumar Nakarmi, Jakob Sternby, and Ikram Ullah. Applying Machine Learning on RSRP-Based Features for False Base Station Detection. In Proceedings of the International Conference on Availability, Reliability and Security (ARES), 2022.
[64] Cooper Quintin and Will Greenberg. Recording PCAPs from Stingrays With a $20 Hotspot. https://www.yo utube.com/watch?v=meC2JqNAbCA, 2025. [65] Ettus Research. USRP B210, 2013.
[54] Peter Ney, Ian Smith, Gabriel Cadamuro, and Tadayoshi Kohno. SeaGlass: Enabling City-Wide IMSI-catcher Detection. Proceedings on Privacy Enhancing Technologies, 2017.
[66] Ettus Research. USRP X310, 2014. [67] Kazi Samin Mubasshir, Imtiaz Karim, and Elisa Bertino. Gotta Detect ’Em All: Fake Base Station and Multi-Step Attack Detection in Cellular Networks. arXiv e-prints, 2024.
[55] Taekkyung Oh, Sangwook Bae, Junho Ahn, Yonghwa Lee, Tuan Dinh Hoang, Min Suk Kang, Nils Ole Tippenhauer, and Yongdae Kim. Enabling Physical Localization of Uncooperative Cellular Devices. In Proceedings of the Annual International Conference on Mobile Computing and Networking (MobiCom), 2024.
[68] SecUpwN. AIMSCD: Android IMSI-Catcher Detector. https://github.com/CellularPrivacy/Android -IMSI-Catcher-Detector, n.d. Accessed: 2025-0418. 17
[69] Altaf Shaik, Ravishankar Borgaonkar, Shinjo Park, and Jean-Pierre Seifert. On the Impact of Rogue Base Stations in 4G/LTE Self Organizing Networks. In Proceedings of the ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec), 2018.
[80] Tyler Tucker, Nathaniel Bennett, Martin Kotuliak, Simon Erni, Srdjan Capkun, Kevin Butler, and Patrick Traynor. Detecting IMSI-Catchers by Characterizing Identity Exposing Messages in Cellular Traffic. In Proceedings of the Network and Distributed System Security Symposium (NDSS), 2025.
[70] Skibapps. Cell Spy Catcher. https://www.appbrain .com/app/cell-spy-catcher-anti-spy/com.ski bapps.cellspycatcher, n.d. Accessed: 2026-02-01.
[81] United States House Committee on Oversight and Government Reform. Law Enforcement Use of Cell-Site Simulation Technologies: Privacy Concerns and Recommendations. https://oversight.house.gov/ wp-content/uploads/2016/12/THE-FINAL-bipar tisan-cell-site-simulator-report.pdf, 2016. Accessed: 2025-04-19.
[71] SRLabs. SnoopSnitch. https://github.com/srlab s/snoopsnitch, 2014. Accessed: 2025-04-18. [72] Nataliya Stanetsky and Roger Piqueras Jover. Keeping Your Android Device Safe from Text Message Fraud. https://security.googleblog.com/2024/08/ke eping-your-android-device-safe-from.html, 2024.
[82] Unwired Labs. OpenCellid: The World’s Largest Open Database of Cell Towers. https://www.opencellid .org, n.d. Accessed: 2025-04-19. [83] Verizon. Verizon Orbic Mobile Hotspot. https://www. verizon.com/support/verizon-orbic-speed-m obile-hotspot/, n.d.
[73] Simen Steig, Andre Aarnes, Thanh Van Do, and Hai Thanh Nguyen. A Network-Based IMSI Catcher Detection. In IEEE International Conference on IT Convergence and Security (ICITCS), 2016.
[84] Ash Wilson. SITCH: Situational Information from Telemetry and Correlated Heuristics. DEF CON, 2016.
[74] Swapnil Udar, Ravishankar Borgaonkar. Darshak. ht tps://github.com/darshakframework/darshak, 2014. Accessed: 2025-04-18.
[85] Hojoon Yang, Sangwook Bae, Mincheol Son, Hongil Kim, Song Min Kim, and Yongdae Kim. Hiding in Plain Signal: Physical Signal Overshadowing Attack on LTE. In USENIX Security Symposium, 2019.
[75] Swiss National Cyber Security Centre. Week 36: New risk from SMS blasters. https://www.ncsc.admin .ch/ncsc/en/home/aktuell/im-fokus/2025/wo chenrueckblick_36.html, 2025. Accessed: 2026-0117.
[86] Yiming Zhang, Baojun Liu, Chaoyi Lu, Zhou Li, Haixin Duan, Shuang Hao, Mingxuan Li, Ying Liu, Dong Wang, and Qiang Li. Lies in the Air: Characterizing Fake-BaseStation Spam Ecosystem in China. In Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, 2020.
[76] Aleksa Tesic. Serbia Imports Wireless Equipment Capable of Indiscriminate Mass Surveillance. https: //balkaninsight.com/2024/12/12/serbia-imp orts-wireless-equipment-capable-of-indis criminate-mass-surveillance, 2024. Accessed: 2025-04-19.
[87] Zhou Zhuang, Xiaoyu Ji, Taimin Zhang, Juchuan Zhang, Wenyuan Xu, Zhenhua Li, and Yunhao Liu. FBSleuth: Fake Base Station Forensics via Radio Frequency Fingerprinting. In Proceedings of the Asia Conference on Computer and Communications Security (Asia CCS), 2018.
[77] Mikael Thalen and Simone Del Rosario. Exclusive: Evidence of Cell Phone Surveillance Detected at AntiICE Protest. https://san.com/cc/exclusive-e vidence-of-cell-phone-surveillance-detecte d-at-anti-ice-protest/, 2025. Accessed: 202508-29. [78] The Bristol Cable. Revealed: Bristol’s police and mass mobile phone surveillance. https://thebristolca ble.org/2016/10/imsi, 2016. Accessed: 2025-0415. [79] Trent Smith. Project Overwatch: Multinational Effort to Combat IMSI Catchers. https://www.youtube.com/ watch?v=UG5juhuhE2g, 2017. Accessed: 2025-04-18. 18
A
Systematic Analysis of FBS Detection
as evidence of FBS activity [42]. In addition to thresholding, some systems treat signal strength as a consistency/localization signal by (i) comparing reported Reference Signal Received Power (RSRP) or Reference Signal Received Quality (RSRQ) against expected values from a signal-strength map or known base station locations/topology [37, 40, 53], or (ii) using multi-point signalstrength patterns to localize a suspected FBS [43]. RRC procedure failures. Victims experience RRC procedure failures during the connection hijacking phase that can reveal FBS presence. Specifically in jamming, following to our empirical study (Fig. 8), the FBS disrupts the UE’s link to the legitimate cell, causing Radio Link Failure (RLF) and leading to RRC Connection Reestablishment Request with “other failure” causes. In case of handover, the UE sends RRC Reconfiguration Complete but the FBS cannot proceed due to missing context, triggering “handover failure” and subsequent RRC Connection Reestablishment Request with “handover failure” causes. These failure patterns can help detecting hijacking, though similar traffic patterns also arise in specific benign situations including UE in congestion or mobility. Prior works [28, 59, 67] focus on failure outcomes as standalone indicators, or treated them as part of a broader detector system.
In this section, we systematically investigate existing FBS detection mechanisms to establish the analytical foundation for Devilray’s operational variants in §5.2. We decompose detection techniques into underlying primitives – observable features that reveal FBS presence. Tab. 6, the full table from which Tab. 3 is derived, presents a comprehensive analysis of 22 existing FBS detection works. We focus on characterizing detection primitives across operational layers (§A.1); seven operational variants (V1-V7) in §5.2 are derived from these primitives combined with protocol specifications. We then examine how existing systems combine these primitives (§A.2).
A.1
Detection Primitives
We identify three domains where FBS behavior can be detected – access-layer, protocol-layer, and physical-layer – based on our unified model and the characteristics of cellular communications. Access-layer. This domain corresponds to the connection hijacking phase where FBS operations transition from passive observation and signal broadcasting to actively interacting with UEs to set up the link. In this process, the FBS disconnects UEs from legitimate cells and redirects them to itself, generating observable artifacts such as radio link failures. Protocol-layer. FBSs execute attacks over hijacked connections, a process that primarily aligns with the application phase and requires communication with UEs through standard cellular protocols. Such communication produces detectable patterns in signaling messages, reject sequences, and protocol violations. The standardized nature of cellular protocols thus offers a rich foundation for detection mechanisms based on message analysis and behavioral patterns. Physical-layer. Beyond the active interaction domains, physical-layer characteristics also provide useful indicators for FBS detection. When the hardware setup of FBSs relies on relatively low-cost components with limited capabilities compared to commercial infrastructure, they exhibit distinctive RF characteristics and signal quality variations [87]. A.1.1
A.1.2
Protocol-layer Primitives
IMSI-exposing and reject messages. IMSI-exposing message patterns can reveal FBS activities aimed at identity tracking. Legitimate networks typically request IMSI sparingly and under specific conditions such as initial network attach or GUTI expiration [2], while FBS generates excessive identity requests for IMSI-catching. To collect IMSIs, FBS can send various signaling messages to UEs, such as Identity Request, NAS Reject, and others [2, 7, 80]. Based on this knowledge, several prior works detect FBS activity by monitoring for IMSI-exposing messages on the control plane [28, 54, 64, 67, 80]. Specifically, Marlin [80] identifies suspicious situations of IMSI-catcher presence by monitoring statistical increases in 53 IMSI-exposing messages, including NAS Reject with specific causes and Identity Request messages. Rayhunter [64] monitors IMSI-relevant messages including IMSI paging and IMSI Identity Request messages. Reject messages are another indicator of FBS activities, typically issued when authentication is required but cannot be completed, as FBSs lack the capability to correctly perform authentication procedures. This process disconnects UE links and returns them to legitimate networks after performing attacks. As an attack purpose, they are also exploited for service denial and downgrade attacks along with IMSIcatching. These patterns can be used to identify FBS activities by monitoring the frequency, cause values, and contextual abnormalities of reject messages [11, 28, 67].
Access-layer Primitives
Signal strength. A core behavior of FBSs during connection hijacking is attracting UEs by transmitting stronger signals than legitimate base stations [31]. This effect is particularly pronounced when hijacking is assisted by jamming: by suppressing legitimate cells, an FBS can more readily dominate UE measurements and induce selection via the capture effect [33, 55, 85]. Accordingly, prior work has attempted to detect hijacking by monitoring whether received signal power exceeds an absolute threshold [11, 48] or by using the disappearance of neighboring legitimate cells (e.g., under jamming) 19
Tab. 6: Detection primitives used across FBS detection studies and systems Detection primitives Access Protocol Physical Detection Detection Signal RRC IMSI-exp. Reject Cell ReNull TA RF Timing Timing entity strength failure msgs. msgs. info. direction cipher cmd. char. error Crocodile Hunter [63] ◦ ◦ pre-hijack FBS-Radar† [48] ◦ ◦ post-attack GSMK Overwatch [79] ◦ ◦ ◦ pre-hijack 3rd party IMSI-Catcher-Catcher‡ [23] ◦ ◦ ◦ mid-attack Marlin [80] ◦ post-attack SeaGlass [54] ◦ ◦ ◦ ◦ ◦ pre-hijack Heijligenberg et al. [37] ◦ ◦ post-attack Karaçay et al. [43] ◦ post-attack Anomaly Murat [52] ◦ ◦ post-attack Network Detection Nakarmi et al. [53] ◦ post-attack Park [59] ◦ ◦ ◦ post-attack Steig et al. [73] ◦ post-attack Apple’s patent [16] ◦ ◦ ◦ ◦ ◦∗ ◦ post-hijack CellGuard [11] ◦ ◦ ◦ mid-attack EAGLE Security [42] ◦ ◦ post-hijack UE Huang et al. [40] ◦ mid-hijack ♯ LeopardSeal [60] ◦ mid-attack Rayhunter♭ [64] ◦ ◦ ◦ ◦ mid-attack FBSleuth [87] ◦ pre-hijack 3rd party Signature-based Ali et al. [9] ◦ mid-hijack ♮ Detection UE FBSDetector [67] ◦ ◦ ◦ ◦ ◦ ◦ post-attack PHOENIX [28] ◦ ◦ ◦ ◦ post-attack Note that we do not cover tools that have not been maintained in the past decade, such as AIMSICD [68], SnoopSnitch [71], Darshak [74], Cell Spy Catcher [70], SITCH [84], and GSM Spy Finder [34], as they are no longer updated and their technical approaches have been largely incorporated into or superseded by more recent detection systems. ∗ Monitoring Doppler effect for detecting mobile FBSs. † Operating as a UE-assisted and cloud server-based system. ‡ IMSI-Catcher-Catcher can be built on mobile UEs (M) and stationary 3rd party devices (S) to form a sensor network. ♯ Monitoring round trip timing (latency) of voice signals for detecting call interception by FBS. ♭ Rayhunter can be built on Orbic mobile hotspots [83] and Qualcomm-based devices, equipped with a SIM card. ♮ FBSDetector can operate either as an Android application on the UE or as standalone machine-learning models that process packet captures. Detection Technique
Previous studies
Cell information. FBS deployments can be detected by anomalies of several configurations. These include misconfigurations of cell information parameters, such as invalid TAC, cell IDs, or use of non-standard frequency bands that can be indicators of FBS. Monitoring broadcast messages can also be helpful, as FBSs may transmit malicious messages to influence UE behavior. For instance, cell reselection priorities or barred cell status in SIB messages can mislead UEs into connecting to an FBS or prevent them from connecting to legitimate networks. Additionally, malicious paging messages may be used to elicit UE responses, enabling identity exposure or DoS through repeated, targeted paging. Based on these observations, detectors flag an FBS when the observed cell information appears abnormal or distinguishable from legitimate cells. Common examples include cells advertising PLMN/TAC/cell IDs that are different from neighbors or not registered in a database [11, 23, 23, 37, 42, 48, 52, 63, 64], as well as cells whose broadcast information is inconsistent such as containing unusually small timer values or missing neighbor-cell information [16, 54, 79]. 3G/2G redirection and null ciphers. Detection systems can also monitor redirection messages and null cipher usage [16,28,64,67]. These indicators target specific application scenarios: redirection to legacy networks and SMS injection or eavesdropping through encryption downgrade. Redirection occurs through multiple mechanisms specified in 3GPP standards. Regarding RRC connection man-
agement, RRC Connection Release messages may contain redirectedCariierInfo to force cell selection steering UEs toward specific RATs or frequencies. Additionally, SIB messages can specify legacy technology priorities to induce interRAT reselection. On the one hand, null cipher can be exploited to eavesdrop on UE communications. During the RRC connection and NAS Attach procedure, it can propose null encryption algorithms via Security Mode Command to disable encryption and expose UE data. Note that redirection and ciphering changes can occur in benign operations. For example, UE autonomously performs cell search on lower-generation RATs if it fails to find any suitable cells [3]. Additionally, networks can use redirection for congestion management and load balancing, and ciphering changes for emergency calls. A.1.3
Physical-Layer Primitives
RF characteristics. FBS signals might exhibit unique RF characteristics that can be used to differentiate them from legitimate network transmissions. These include signal bandwidth variations, frequency stability (center frequency offset), time synchronization offset, phase characteristics, and magnitude deviations in pilot signals, reflecting hardware specifications and transmission conditions. For example, FBSleuth [87] demonstrates this detection approach by measur20
ing these physical-layer features. Other approaches [9, 60] utilized signal noise distributions or round-trip time analysis for additional RF characteristics. Transmission timing error. Apple’s patent [16] describes using clock synchronization capabilities and Doppler effects for FBS detection. Building on this concept, transmission timing error can serve as a detection primitive. Legitimate cells typically achieve precise clock synchronization through GPS or external clock sources from their mobile operators, which provide accurate timing information to all cells in the network and ensure coordinated operation across the network. This synchronization is critical for maintaining network stability, enabling seamless handovers between cells, compensating for timing/frequency offsets, and preventing inter-cell interference [6, 8]. In contrast, resource-constrained FBS relies on less accurate internal clocks, which introduce timing misalignment and signal distortions such as frequency offset. By focusing on the clock synchronization capabilities of legitimate cells, the inherent timing misalignment in FBS transmissions can be utilized to differentiate them from legitimate cells.
A.2
message transmissions, unexpected cell location and unusual cell information. CellGuard [11] determines the presence of FBS by scoring the likelihood of a cell being malicious based on the Apple Location Service (ALS) database including cell information. With cell location information in the ALS database, CellGuard running on iPhone verifies the existence of connected cells and cell configurations (frequency channel and cell ID) against the database. Additionally, it calculates the distance between the UE and approximate location of the cell and monitors network reject messages, bandwidth, and signal power level to determine anomalies in cell behavior. Crocodile Hunter [63], developed by Electronic Frontier Foundation (EFF), also scores suspiciousness of cells by collecting their configurations (PLMN, TAC, cell ID, frequency channel) and its location to compare with open cell database, OpenCelliD [82], and monitoring signal power fluctuations. EFF recently released Rayhunter [64], a new FBS detection tool that monitors specific indicators including IMSI paging, IMSI Identity Request, SIB and RRC Connection Release messages associated with 2G redirection, and null ciphers over Security Mode Command and RRC Connection Reconfiguration messages to identify FBS activities. Marlin [80] identifies IMSI-Catchers by monitoring the statistical increase of 53 IMSI-related messages, including NAS Reject with specific causes, and Identity Request messages. EAGLE Security [42], developed by Int64 Team, also operates as a UE-side Android application that validates cell configurations against the OpenCelliD database similar to Crocodile Hunter. The app evaluates multiple criteria to assign “wiring probability” scores: database presence verification, distance comparison between recorded and measured cell locations, PLMN validity checks, and analysis of whether multiple cells or only single cells are visible at the current location. Violations of these criteria increase the suspicion score for potential FBS detection. FBS-Radar [48] collects recently connected cell information (e.g., cell ID, signal strength, and connection time), MAC addresses of nearby WiFi access points, and SMS contents from UEs and stores this data in a cloud server. Based on the collected data, FBS-Radar analyzes cell information using a location database of cells and WiFi, and examines SMS contents using machine learning models to identify FBS activities sending spam SMSes. Heijligenberg et al. [37] suggested an FBS detection method monitoring Tracking Area Update (TAU) messages with dummy TAC values and comparing cell power from UE measurement reports with the signal strength map at the network side. Similarly, Huang et al. [40] and Nakarmi et al. [53] proposed methods to identify FBS by modeling expected signal strength received at the UE. Additionally, Karaçay et al. [43] introduced an FBS localization method using observed signal strengths of cells in UE measurement reports and trilateration with a signal propagation model. Other ap-
Existing Detection Techniques
We now examine how existing detection systems combine these primitives in practice. We analyze existing detection systems across three dimensions: Detection technique. Anomaly detection identifies deviations from normal network behavior while signature-based detection matches observed patterns against known attack signatures Detection timing. We define five phases: pre-, mid-, and posthijacking (before any FBS interaction, during redirection, and after UE connection but before attacks); and mid-/post-attack (during misuse and after-the-fact detection). Early phases allow prevention; later ones support confirmation and forensics. Detection entity. FBS detection can occur on the UE side, network side, or via third-party systems. UE-side detection runs on user devices, often via apps, relies on local observation. Network-side detection uses MNO infrastructure to aggregate data from UEs or base stations. Third-party detection leverages external systems – independent of both MNO and UE – using dedicated hardware or data from multiple sources. We organize our analysis primarily by detection technique as this captures the core operational logic underlying different systems. A.2.1
Anomaly Detection
Identifying deviations from normal behavior in legitimate networks, suspicious patterns can be detected and flagged as potential FBS activity. This approach typically focuses on monitoring emerged cells showing abnormal signal strength, 21
proaches [52, 59, 73] collect measurement reports from UEs, including neighboring cell lists, signal strength, or RLF reports, and analyze them against network databases to identify FBS activities. IMSI-Catcher-Catchers [23], Overwatch [79] and SeaGlass [54] are designed to collect cell information or monitor IMSI-exposing messages through scalable deployments of UEs or sensor networks and build a database of regional cells to identify suspicious activities. These systems rely on the assumption that legitimate base stations exhibit consistent and predictable behaviors over time and across geographic locations. They collect information such as cell IDs, signal strength, broadcast parameters, and encryption status, along with precise GPS coordinates. By aggregating this data, they construct a baseline model of known legitimate cells. Detection is then performed by identifying inconsistencies such as previously unseen cell IDs and unexpected changes in broadcast configurations and cell locations when compared to the reference database. As a comprehensive documentation, Apple’s patent [16] presents a detection technique that combines various detection primitives, including monitoring signal strength, cell information, TA commands, time synchronization capability, and Doppler effect for detecting mobile FBSs. However, the document only theoretically describes this detection technique without providing experimental results or practical implementation details. Separately, LeopardSeal [60] introduces a method to detect call interception by FBS by monitoring the round trip timing of voice signals. A.2.2
proposed a similar approach to detect FBS by analyzing signal distortion derived from hardware limitations of FBS.
B
Dependency Checker
Inter-phase conflicts 1
Scanning - Launching R14) If [PCI] is set to SCell, → [Cell_DB] should include ≥ 2 cells with different PCI for selected PLMN
Intra-phase conflicts & Inter-phase relations Network scanning phase configuration 1
Cell launching phase configuration 2
Launching - Hijacking R17) If [Hijacking mechanism] is Handover, → [PLMN]/[EARFCN]cannot be Manual → [PCI] should be SCell → [Power margin] should be ≥ +3 dB
3
Launching - Application R19) If [Alternative IMSI catching] and [Concurrent cell num.] is set to 1, → [Reject cause] should be #9 R20) If [Adaptation mode] is set to UE recovery, → [Exclude reject] cannot be turned on → [Reject cause] should be TAC-blacklist
R2) If [Adaptation mode] is set to Full-adapt, → [PLMN]/[EARFCN]/[PCI]/[TAC] cannot be Manual → [PCI] cannot be Random 2 Connection hijacking phase configuration
3
Application phase configuration a R11) If [Victim targeting] is Targeted Attack, → [IMSI/GUTI pool] should ≥ 1 (check IMSI/GUTI acquisition)
Fig. 7: Dependency checker with example rules. Arrows denote inter-phase relations. Colors indicate resolution types: automatic (blue), strict validation (red), prerequisite enforcement (green).
C
Connection Hijacking and Applications
In this section, we demonstrate Devilray’s effectiveness on connection hijacking and applications. Our setup consists of a laptop running Devilray software connected to two USRP B210s. Target devices include seven COTS UEs – Galaxy S10e, S20, S21, S23, iPhone XS, 12 and 13 Pro – each equipped with commercial SIM cards issued for research use. To ensure generalizability and reproducibility, we perform these experiments across two countries on different continents. Connection hijacking. We evaluate the effectiveness of Devilray’s connection hijacking mechanisms on COTS UEs to confirm their practical impact and to characterize their operational requirements. Target UEs are controlled into idle or connected states according to the tested mechanism: cell reselection trials start with UEs camping in idle mode, handover trials are performed during active voice sessions to maintain connected mode, and jamming is tested against both idle and connected UEs. Each experiment is repeated ten times across five relative power margins, up to 30 dB. Tab. 7 presents the connection hijacking success rates for different relative signal power levels across all methods. The table show the results against one representative device, the Galaxy S23. While jamming-based hijacking requires a minimum of 20 dB signal advantage and achieves a 100% success rate at 30 dB, cell reselection and handover-based hijacking
Signature-based Detection
As another methodology, attack signatures can be used to identify FBS activities. These signatures are typically based on known attack patterns, such as specific message sequences or behaviors associated with FBS operations. By comparing observed behaviors against these signatures, detection systems can identify FBS attacks. PHOENIX [28] utilizes a signature-based approach to detect FBS attacks by monitoring specific message patterns, including RLF reports. It focuses on identifying attack signatures, which consist of undesired message sequences not present in benign cellular behaviors. FBSDetector [67] employs signatures of abnormal activities and multi-step attacks of FBS with large-scale datasets. Based on machine learning techniques, it is also designed to cover unseen and reshaped FBS attacks. FBSleuth [87] is a representative work that employs RF fingerprinting as signatures to distinguish signals between FBS and legitimate cells in 2G networks. Based on the hardware imperfections inherent in FBS equipment, it models fingerprints with RF characteristics such as modulation errors and instantaneous phase and frequency, and applies machine learning techniques to classify these fingerprints. Ali et al. [9] 22
Tab. 7: Devilray’s connection hijacking success rate (%) Relative power Jamming Handover Cell reselection
3 dB 0 20 0
5 dB 0 70 20
10 dB 0 100 70
20 dB 30 100 100
mobile network for up to 30 minutes. Notably, we observe that the disruption is not resolved by common user actions such as toggling airplane mode or rebooting the device. Furthermore, after recovery, reapplying the same attack re-induces the disruption, confirming its repeatability. We execute up to 5 consecutive DoS attempts, all of which are successful.
30 dB 100 100 100
* Relative power indicates the signal strength advantage compared to legitimate serving cells of target UEs (shown here for representative UE, Galaxy S23). * We conducted 10 trials for each method and relative power.
D
Tab. 8: Connection hijacking requirements Requirements Frequency PCI Relative power† UE state
Jamming Serving Any > 20 dB Any state
Handover Any Neighbor > 3 dB‡ Connected
Cell reselection Serving∗ Higher-priority Different∗ Any > 5 dB‡ Idle
Measurements of RF Characteristics Tab. 9: Measurement results of RF characteristics
Target
Condition CFO (Hz) Sync. error (ns) Mag. error (%) Day1 −1,416 ± 154 1,493 ± 77 1.3 ± 0.3 Day7 −1,402 ± 119 1,129 ± 91 1.2 ± 0.1 Day1 −1,316 ± 115 1,927 ± 294 1.7 ± 0.1 MNO2 Day7 −1,419 ± 201 2,526 ± 889 1.3 ± 0.3 Day1 −1,541 ± 101 238 ± 81 1.9 ± 0.5 MNO3 Day7 −1,501 ± 122 382 ± 63 2.7 ± 0.2 B210 −475 ± 145 −866 ± 59 16.9 ± 2.9 Devilray ∗ X310 −4,130 ± 93 1,937 ± 59 2.1 ± 0.2 RF manip. −1,346 ± 176 1,563 ± 492 3.3 ± 0.4 Amari Callbox∗ −3,376 ± 377 8,147 ± 622 6.4 ± 0.9 C-FBS∗ −1,443 ± 116 506 ± 12 12.1 ± 1.6 ∗ Measurements on Devilray, Amari Callbox, and C-FBS are conducted in the controlled room with conductive mesh shielding for ethical considerations. In contrast, all passive measurements on MNOs are performed in normal conditions. MNO1
Frequency and PCI rows describe whether Devilray should match or differ from the UE’s serving cell – i.e., the cell to which the UE is currently connected or camping on – in terms of operating frequency and PCI. ∗ For the idle UE camping on the serving cell with the highest priority frequency, Devilray’s PCI must differ from the serving cell’s, while operating on the same highest priority band to be perceived as a distinct, higherpower cell for reselection exploitation. † See Tab. 7 for detailed results. ‡ Depending on the network configuration [3, 5].
require much less relative power. Cell reselection is effective with as little as 5 dB advantage, while handover to Devilray is performed even with just a 3 dB stronger signal. Tab. 8 summarizes the operational requirements for each hijacking mechanism. Across all seven tested UEs, Devilray succeeds in performing connection hijacking under the expected conditions, though the success rate for each mechanism varies depending on the relative power margin. While jamming-based hijacking requires a minimum of 20 dB signal advantage, cell reselection and handover-based hijacking require much less relative power. Cell reselection is effective with as little as 5 dB advantage, while handover to Devilray is performed even with just a 3 dB stronger signal. Jamming influences both idle and connected UEs on the serving frequency, requiring a high relative power advantage. Handover applies only to connected UEs and can succeed with a subtle power margin while reusing neighbor PCIs. Cell reselection targets only idle UEs and leverages higher-priority frequency settings with a modest power margin. Application We evaluate on-board attacks of Devilray (i.e., IMSI-catching, location tracking, 2G redirection, SMS injection, and DoS) with a jamming as hijacking. As a result, all IMSI-catching modes of Devilray successfully extract IMSIs from target UEs immediately after connection hijacking. We further confirm that it can continuously trigger UE traffic with IMSI paging and Identity Request, enabling location estimation through measurements of arrival signal strength. For 2G downgrades and SMS injection, five COTS UEs (Galaxy S10e, S21, iPhone XS, 12 Pro, and 13 Pro) were successfully redirected to Devilray’s 2G cell and received malicious SMS messages over the unencrypted link. The remaining two devices were redirected to the 2G band but did not connect to Devilray’s 2G cell. For the DoS attack, we confirm that every UE that receives Attach Reject with cause #22, is unable to reconnect to the
FBSleuth [87] introduces RF fingerprinting for 2G FBS detection, proposing to fingerprint FBSs based on signal distortions stemming from hardware imperfections. In this paper, we extend this primitive to LTE FBS detection and evaluate it under hardware compensation (V7). We utilize three features as RF characteristics, selected based on FBSleuth [87] and channel estimation methods in srsRAN [36]: CFO, time synchronization error, and magnitude error. CFO captures frequency mismatches between the received PSS and center frequency, while time synchronization error is the timing offset of received pilot signals, and magnitude error indicates amplitude deviations in pilot signals caused by modulation imperfections. To examine RF characteristics’ effectiveness in LTE, we measure three features from six operational cells across three MNOs, Devilray, Amari Callbox [10], and the C-FBS. Measurements on MNOs are taken on Day 1 and Day 7 at the same location to capture temporal variations. Each measurement is 10 seconds long and repeated 10 times. We utilize LTESniffer’s [38] built-in functions for CFO and synchronization error measurements, while extending it to measure magnitude error with FBSleuth’s [87] methodology. As a result, we confim that the RF characteristics of the three MNOs remain consistent between Day 1 and Day 7. Additionally, Devilray, Amari Callbox, and the C-FBS exhibit distinct patterns that differentiate them from legitimate cells (see Tab. 9 for detailed numbers). For intuitive interpretation, we visualize the results using PCA. PCA is first performed using Day 1 and 7 measurements from legitimate cells, combined with measurements from Devilray with B210, and Amari Callbox, to define the 23
projection space. Subsequently, measurements from the CFBS and Devilray with X310 are projected to validate the projection space and evaluate the effectiveness of this detection primitive. Fig. 6 shows that legitimate cells form tight clusters, while Devilray, Amari Callbox, and the C-FBS each form separate, distinguishable clusters. Then we project measurement results of Devilray with RF tuning to explore the effect of hardware compensation (V7). Specifically, it applies software-based RF characteristic manipulation by deliberately introducing signal distortions, such as injecting CFO. The resulting measurements clustered together with those of legitimate cells, showing that RF tuning can influence RF characteristic-based detection.
24
Serving Cell
Victim
Devilray
RRC Connected
Network scan Set neighbor PCI
Broadcast messages
Measurement report
Measurement Event
Handover trigger
Neighbor cell
Security context
RRC Connection Reconfiguration
RRC Connection Reconf. Complete
No UE context
No response Timeout
RRC Connection Reestablishment (HO fail.) No UE context
RRC Connection Reest. Reject Cell search
New connection with FBS
(b) Handover Victim
Serving Cell
Victim in RRC CONNECTED
Victim in RRC IDLE
Devilray
Network scan Strong broadcast messages
RRC Connected Jammed, Radio link failure RRC Connection Reestablishment Cell search
RRC conn. release
No traffic
Move to IDLE Camp on serving cell Cell reselection
Network scan Strong broadcast messages
Signal jammed
Devilray
RRC Connected
No UE context RRC Connection Reest. Reject
Camp on serving cell
Victim
Serving Cell
Network scan Config. high priority band
Broadcast Messages Camp on
New connection with FBS
Cell search Camp on
New connection with FBS
(a) Jamming
(c) Cell reselection
Fig. 8: Message flow for three connection hijacking methods by FBSs ROOT: Devilray Total Threat Space (Ntotal = 2,592 Instances) Calculation: Nlaunch(32) × Nhijack(3) × Napp(27) = 2,592 [Phase 1: Cell Launching Phase] (Nlaunch = 25 = 32 Variations)∗ 1. Broadcast Parameter Adapt. (2) [Unadapted vs Adapted] (V1)
2. Cell Iteration (2)
[Fixed vs Round-Robin]
3. Paging Reproduction (2) [On vs Off] (V1)
4. TA Diversification (2) [On vs Off] (V2)
5. Hardware Compensation (2) [On vs Off] (V7)
[Phase 2: Connection Hijacking Phase] (Nhijack = 3 Variations) A. Jamming
B. Handover (V3)
C. Cell Reselection (V3)
[Phase 3: Application Phase] (Napp = 3 × 9 = 27 Variations)♯ 1-A. Non-target Attack
2-A. IMSI-Catching (3 variants) 1. Identity Request-based
3. IMSI catching 2. NAS Rejectexcluding based (V4) NAS Reject (V6)
1-B. Adaptive Sampling (V4) 2-B. Location Tracking (2 variants)
5. Location tracking 4. Ordinary excluding location tracking NAS Reject (V6)
1-C. Targeted Operation (V4)
2-C. Denial-ofService (1 variant)
2-D. 2G Redirection & SMS Injection (3 variants)
6. DoS via Reject cause #22
7. redirectedCarrier 8. SIB7 priority 9. idleModeMobilityInfo-based injection ControlInfo-based (V5)
∗ Nlaunch consists of 5 independent binary configurations ♯ Napp consists of 3 victim configuration(1-A ~ 1-C) and 9 application variations (2-A ~ 2-D)
Fig. 9: Devilray’s configurations space to explore FBS instances
25