Why an SS7 honeypot
Attackers still probe interconnects for location, call and SMS manipulation, and subscriber data. A honeypot turns the interconnect from a blind spot into an insight source. Done well, it attracts mapping and abuse traffic, fingerprints adversary tools, and gives operators early warning without touching real subscribers.
Design goals
- Look authentic to outside networks
- Never touch real customer data or production switching paths
- Produce high quality labeled telemetry for analysis and sharing
- Be simple to reset and safe to fail
High level architecture
Think of three concentric parts.
Perimeter exposure
A controlled SS7 SIGTRAN entry that peers like a small operator. It accepts SCTP with realistic point codes and Global Titles and speaks limited MAP and CAP. It answers enough to keep scanners interested but never forwards into production.
Honeynet core
Virtual HLR and VLR logic, a tiny MSC like call flow engine, and SMSC simulators. These components generate believable responses such as roaming status or SMS delivery receipts, while clearly watermarked for later correlation.
Safety and analytics
A screening layer that enforces strict allow lists and rate limits, then a recorder that stores decoded messages, correlation IDs, and transport context. All storage is separate from any customer dataset and lives behind write only ingestion.
Identity and peering that look real
- Allocate a distinct point code range and Global Titles that do not collide with production
- Use routing rules that keep all honeypot traffic inside a sealed SIGTRAN domain
- Publish minimal but plausible information to partners or directories if required in your region
- If you must announce any reachability to IPX or private peers, do it from dedicated IP ranges with no path back into core networks
Realistic personas that bait common flows
Create a small catalog of synthetic subscribers with believable attributes. Each persona has
- MSISDN and IMSI that pass basic checksum tests
- Location states such as home, roaming, or unreachable
- SMS behavior that sometimes fails, sometimes succeeds
- Optional CAMEL service flags for prepaid or fraud baiting
Rotate persona states on a schedule so that repeated probes see change over time. Never reuse real numbers.
What the honeypot should answer
Prioritize the few MAP operations that attackers and scanners love.
- ProvideSubscriberInfo and AnyTimeInterrogation to simulate location
- SendRoutingInfoForSM to simulate SMS routing
- UpdateLocation and InsertSubscriberData to test write attempts but always return controlled errors after minimal handshake so you can fingerprint intent
- MAP AlertServiceCentre to entice delivery probes
Return responses that are technically valid but carry watermarks. Examples include location areas in a reserved range and SMSC addresses that resolve only inside the honeypot. Every reply includes a correlation token in an otherwise unused field or tag that your analytics knows how to parse.
What the honeypot must never do
- Never forward MAP or CAP into real HLR, MSC, or SMSC
- Never route SMS toward live interconnects
- Never accept UpdateLocation that would change state outside the sandbox
- Never share raw pcap without sanitization and timing jitter if collaboration is required
Telemetry to capture
Collect a single coherent record per session or attempt that includes
- Full decoded MAP or CAP with message sequence
- Transport context with SCTP verification tags and IPs
- Timing between requests to classify tools and scripts
- Honeypot persona that was targeted and its state
- Decision outcome such as allowed, simulated success, or blocked
- Confidence score and rule that triggered the classification
Store raw captures with strict access controls and generate privacy safe summaries for routine dashboards.
Detection logic that pays off
Start with five families and expand.
- Mapping and discovery repeated PSI and ATI across ranges
- Location abuse targeted PSI for a single persona at abnormal rates
- SMS manipulation SRI for SM followed by fake delivery confirmations
- Write attempts UpdateLocation and InsertSubscriberData from untrusted peers
- Tool fingerprints message timing and parameter defaults that match known kits
Add partner context where possible. For example, a trusted peer that suddenly changes SCTP behaviors deserves a higher score.
Response playbooks
- Partner misbehavior temporarily quarantine at the screening edge and send an engineering notice with exact message examples
- Malicious scanner silently tarp it with higher latency and nonsense but valid looking responses to collect more fingerprints
- Active abuse lock to read only mode, snapshot the environment, and export an incident bundle for legal and sharing
All actions are reversible and do not affect production routing.
Validation through red and purple teaming
Before going live, let an internal team attempt the classic plays.
- Location retrieval of a specific MSISDN
- SMS routing enumeration through SRI for SM
- Unauthorized profile write through UpdateLocation
- CAP based prepaid trickery attempts
- Floods that try to exhaust SCTP associations
Success criteria are simple. The honeypot should record, classify, and throttle every attempt while never touching production.
Legal and policy guardrails
- Use synthetic identities only and document their provenance
- Keep retention short for raw payloads, longer for anonymized statistics
- Coordinate with regulatory and lawful intercept teams so the honeypot is not mistaken for a rogue node
- Prepare clear sharing templates for industry groups that exclude sensitive transport data
Operations and hygiene
- Immutable deployment with signed images and parameterized configs
- Daily rotation of persona states and correlation tokens
- Separate admin identity for honeypot management with short lived credentials
- Health checks that verify both exposure and recording even when there is no incoming traffic by generating internal MAP probes
KPIs that show value
- Number of unique peers that interacted with the honeypot during the period
- Percentage of interactions that match known attack families versus unknown
- Mean time from first interaction to partner notification when applicable
- Reduction in unknown family share over time as signatures improve
- Zero incidents of cross talk with production proven by periodic audit
Minimal build list
- SIGTRAN stack with MAP and CAP decoding and scripting
- Screening gateway with protocol awareness and per peer policy
- Lightweight HLR, VLR, MSC and SMSC simulators with watermark capability
- Storage and analytics pipeline that correlates sessions and produces dashboards
- Automation for persona rotation and environment reset
Rollout blueprint in one week worth of work
Day one and two build the sealed SIGTRAN domain and screening rules.
Day three stand up simulators and a first set of personas.
Day four wire telemetry and dashboards and run red team tests.
Day five and six open a single peering in a very limited way and watch.
Day seven review signals and adjust watermarks and throttles.
Closing thought
An SS7 honeypot is a small investment that converts interconnect risk into intelligence. Keep it believable, keep it fenced, and keep the data useful. Measure progress, share what you can, and treat every new fingerprint as a chance to harden the real network.
