Detecting SS7 spoofing through source point code verification
SS7 spoofing occurs when signalling traffic presents an unauthorised source point code (OPC) or imitates a trusted signalling node. If the receiving network accepts that identity, an attacker may influence call routing, location queries, SMS delivery, roaming services, or inter-carrier communication.
Source point code verification is a practical control within MTP3 and SIGTRAN monitoring. It compares the claimed origin of a message with the signalling link, linkset, destination point code, routing context, and peer relationship expected for that connection.
The method is especially relevant in Australia, where customers frequently rely on SMS for banking alerts, one-time passwords, Medicare-related services, and delivery notifications. A short-lived signalling anomaly can affect subscribers across Sydney, Melbourne, Brisbane, or regional areas before a conventional fraud alert appears.
Detection requires more than matching a number in a packet. Operations teams need a baseline for legitimate point codes, clear handling for roaming traffic, and correlation with SCCP, ISUP, MTP3, and SIGTRAN events. The aim is to identify an impossible signalling identity without disrupting valid traffic.
How the source point code works
In MTP3, the originating point code identifies the signalling point that generated a message, while the destination point code identifies its intended recipient. Together with the service indicator and signalling link selection, these fields guide routing through the SS7 network.
A receiving node should associate each permitted OPC with a defined adjacent signalling point, linkset, or SIGTRAN peer. An OPC that appears on an unexpected link, SCTP association, IP address, or routing context is a strong indication of misconfiguration or impersonation.
Building a trusted point code baseline
Start with an inventory of local point codes, national and international formats, signalling transfer points, service switching points, SMS centres, and application servers. Record which OPC values are expected from each physical or IP-based connection.
The baseline should include legitimate variations caused by roaming and carrier interconnection. Australian operators may receive traffic through different international gateways, so an unfamiliar point code is not automatically malicious. It becomes suspicious when it conflicts with the peer identity and route actually carrying the message.
Checking incoming traffic
For every inbound MTP3 message, compare the claimed OPC with the configured identity of the linkset. On SIGTRAN, extend the check to the SCTP association, source address, destination address, port, routing key, and ASP or AS identity.
A simple rule can raise an alert when an authorised peer sends an unregistered OPC. A stronger rule checks whether the OPC is valid for the specific destination point code and service. For example, an unexpected source claiming to deliver MAP traffic to a home location register deserves closer attention than a harmless test message.
Correlating signs of spoofing
Point code mismatch should be correlated with other indicators, including sudden SMS delivery failures, unusual MAP operations, unexpected subscriber location requests, and routing changes. Repeated traffic from an OPC that alternates between distant network identities is particularly suspicious.
Timer behaviour can also help separate an attack from a transport fault. Delayed acknowledgements and repeated retransmissions may reflect congestion, link failure, or deliberate interference; a practical MTP2 timer guide helps engineers interpret T2, T3, and T4 expiry patterns before labelling the event as spoofing.
Applying controls at the signalling edge
The safest response is to reject or quarantine traffic with an invalid OPC where the network design permits it. Screening rules should operate at signalling transfer points, SS7 firewalls, STPs, and SIGTRAN security gateways rather than relying only on application servers.
Controls should be service-aware. MAP requests, CAP messages, and ISUP call-control messages have different risk profiles, and a policy that is acceptable for one service may interrupt legitimate roaming or emergency call flows. Keep enforcement changes staged and reversible.
Investigating an alert
Preserve the original signalling records, including timestamps, OPC, DPC, signalling link code, network indicator, service indicator, SCCP calling and called party addresses, and SIGTRAN transport details. Accurate time synchronisation is essential when comparing events across carriers and data centres.
Analysts should determine whether the event came from a compromised partner, a routing error, a stale configuration, or an external injection attempt. Australian providers must handle monitoring data carefully under the Privacy Act 1988, while interception-related handling may also engage the Telecommunications (Interception and Access) Act 1979.
Distinguishing faults from deliberate impersonation
A broken link often produces predictable timer expiry, congestion, or route-set changes while retaining a valid peer identity. Spoofing is more likely when traffic remains syntactically valid but claims an OPC that has no relationship with the transport session.
The comparison below provides a concise triage model for a security operations team.
| Signal | Likely network fault | Possible SS7 spoofing |
|---|---|---|
| OPC value | Known and correctly associated | Unknown, duplicated, or linked to another peer |
| Transport source | Expected link or SIGTRAN association | Unexpected IP, ASP, or routing context |
| Timing | Congestion, delay, or timer expiry | Normal-looking bursts or selective requests |
| Routing effect | Broad service degradation | Targeted SMS, location, or call manipulation |
| First response | Repair route or link capacity | Quarantine traffic and validate peer identity |
A useful operational next step is to export the authorised OPC-to-link mapping from each STP or SIGTRAN gateway, then test one controlled alert for any source point code arriving outside its permitted association.
