efforg/rayhunter#1043

View on GitHub →
#1043 Proposal: Heuristic Module for Identifying Anomalous Femtocell Behavior via Qualcomm DIAG Data

Proposal: Exploratory Heuristic Module for Identifying Anomalous Femtocell Behavior Using Qualcomm DIAG Data

Hi everyone — I’d like to propose an exploratory module for Rayhunter that focuses on identifying suspicious or anomalous femtocell / small‑cell behavior using the Qualcomm DIAG telemetry Rayhunter already parses.

This is not intended as definitive rogue‑cell detection. Instead, the goal is to surface contextual indicators that may warrant further investigation, using lightweight heuristics layered on top of Rayhunter’s existing DIAG pipeline.

Motivation

Rayhunter already provides strong visibility into OTA signaling through Qualcomm DIAG logs. However, one category of infrastructure that remains difficult for users to understand or contextualize is consumer femtocells / microcells, especially when:

  • deployed in unexpected locations,

  • misconfigured,

  • or repurposed for behavior that differs from normal carrier‑managed small cells.

There is currently no open‑source tool that focuses specifically on identifying anomalous femtocell patterns using DIAG‑level data. This module aims to fill that gap in a cautious, heuristic‑driven way.

Proposed Heuristic Indicators

These are preliminary ideas for patterns that could be surfaced to the user. All would be framed as “potential anomalies”, not as definitive findings.

1. Unmapped or Anomalous PLMN / MCC / MNC Patterns

Examples include:

  • PLMN identifiers that do not map cleanly to expected regional carriers.

  • MCC/MNC combinations typically associated with consumer femtocell hardware appearing in contexts where they would not normally be deployed.

  • PLMN tiers that do not match the expected hierarchy for the region.

2. Contextually Implausible Small‑Cell Identifiers

For example:

  • The same small‑cell ID appearing in geographically distant or contextually implausible locations.

  • Low‑power cells broadcasting identifiers inconsistent with the surrounding macro network.

3. Forced Protocol Downgrades

Sudden transitions to older RATs (e.g., LTE → UMTS → GSM) in situations where the surrounding macro network normally maintains higher‑tier coverage.

4. Suspiciously Static Signal Characteristics

Consumer femtocells often produce:

  • unusually stable RSRP/RSSI values,

  • minimal fluctuation relative to device movement,

  • or consistent high‑strength signals in environments where macro‑cell variability is expected.

These patterns could be surfaced as “unusual stability” rather than labeled as malicious.

Implementation Approach

The module would:

  • use the existing DIAG parsing infrastructure,

  • add a lightweight heuristic layer,

  • avoid introducing new dependencies,

  • and operate purely as an analysis module, not a detection engine.

No changes to Rayhunter’s capture pipeline would be required.

Limitations

To avoid overclaiming, the module would explicitly acknowledge:

  • femtocell behavior varies widely by carrier and region,

  • anomalies do not imply malicious intent,

  • DIAG data can be noisy or incomplete,

  • and heuristics must be conservative to avoid false positives.

The goal is to provide context, not conclusions.

Next Steps

I’m currently building out a test environment to gather DIAG logs from a variety of real‑world scenarios. Once the lab is fully operational, I’ll share:

  • sample DIAG snippets,

  • examples of anomalous patterns,

  • and early prototype heuristics.

For now, I’d appreciate feedback on:

  • whether this direction aligns with Rayhunter’s roadmap,

  • which DIAG fields or message types would be most appropriate to target,

  • and any prior work or constraints I should be aware of.

Thanks for taking the time to review this — looking forward to your thoughts.

— Eric

1
Comments (1)

Please don’t use AI for your written communication, because as a direct result, a lot of this is super vague and not only doesn’t consider prior art, but doesn’t reference the existing codebase at all.

What makes femtocells special compared to fake base stations in general?

The same small‑cell ID appearing in geographically distant or contextually implausible locations.

Do you want to refer to past recordings to find previous locations of a given ID? Do you want to integrate with public DBs?

MCC/MNC combinations typically associated with consumer femtocell hardware appearing in contexts where they would not normally be deployed.

Where do you get that “context” from? I.e. is the goal here to:

  • write a heuristic that somehow understands on its own whether femtocells are expected in the current area?
  • write a heuristic that triggers anytime a femtocell is detected, and it’s up to the user to understand whether a femtocell is to be expected in this area?]

Consumer femtocells often produce […] unusually stable RSRP/RSSI values

Consumer femtocells often produce […] minimal fluctuation relative to device movement

How did you come to these conclusions?

1