SS7: A Classic Case of Abuse of Functions

An old lesson that remains relevant

In December 2008, Tobias Engel presented Locating Mobile Phones using SS7 at the Chaos Communication Congress. The premise was already clear: functionality that makes subscribers reachable across networks can also reveal their whereabouts.[2] His 2014 follow-up, SS7: Locate. Track. Manipulate., revisited the exposure as access to signalling infrastructure kept getting easier “without the security measures keeping up.”[3]

In January 2017, German online banking customers lost money after attackers combined phishing with SS7 forwarding of their SMS messages, as reported by Süddeutsche Zeitung.[9] In March 2018, ENISA published a dedicated assessment of SS7, Diameter and 5G signalling security, finding “a medium to high level of risk in this area” at that time.[4]

In April 2026, Citizen Lab documented two surveillance campaigns exploiting the telecom interconnection ecosystem, by actors it calls STA1 and STA2. Its investigation describes manipulated operator identifiers, carefully selected routing paths and activity spanning SS7 and Diameter.[5]

These publications concern different observations and periods, and they do not establish a mass-market threat. The UK’s NCSC speaks of “a small number of attacks” that are targeted at specific users, while adding that large-scale use cannot be ruled out.[6] Together, they show why this subject cannot be dismissed as an obsolete curiosity.

The attack uses the network’s capabilities

Mobile networks need to exchange information to locate subscribers, support roaming and deliver communications. SS7 provides signalling capabilities for legacy networks; Diameter supports the equivalent functions in 4G and most 5G environments. Both sit within an interconnected ecosystem in which one operator processes requests associated with another.[5]

An attacker with suitable access can exploit that arrangement. A location query such as anyTimeInterrogation or provideSubscriberInfo becomes a surveillance tool.[5] A false roaming claim can cause messages to be delivered somewhere other than the legitimate subscriber’s handset. The NCSC explicitly describes SS7 attacks that make a customer’s device appear to be roaming on a foreign network, so that the attacker can receive SMS messages intended for the customer.[6]

Knowing a telephone number is not the same as possessing the capability to perform these attacks. Access to the signalling ecosystem is a prerequisite. As general routes, Citizen Lab names commercial arrangements with mobile operators, compromised telecom nodes and control of telecom networks; for its two campaigns, it points to third-party providers and commercial intermediaries, while some identifiers appear to have been spoofed.[5] Its conclusion puts the point directly: the two actors “leveraged legitimate operator signalling identities and trusted interconnections.”[5] The victim’s handset need not be infected for a network-side attack to succeed.

The analytical question is therefore: which capability does the attacker misuse, and what makes that misuse possible?

Why this is TLCTC #1

TLCTC distinguishes abuse of designed functionality from exploitation of implementation flaws. It classifies an attack step by the generic vulnerability exploited, rather than by the protocol’s name or the eventual damage.[7]

For the signalling scenarios discussed here, the #1 interpretation is straightforward: the attacker invokes network functions to obtain information or influence routing beyond any entitlement they hold. The query runs as designed. It simply answers the wrong party.

A server receiving the request does not make the step #2 Exploiting Server. That classification would require an implementation flaw in a component acting in a server role. Likewise, calling something a “protocol vulnerability” does not settle its causal classification.

Nor does paid access take the step out of the Attack row. Under R-SCOPE, the question is whether an accountable grantor conferred an entitlement covering this action, not who sent the message or whether the sender is a customer of someone. A roaming partner asking about a subscriber who is visiting its network is inside the grant. A leased operator identity used to track a stranger across borders is not.

This distinction changes the control discussion. Patching a programming defect and restricting the permissible use of a function address different weaknesses. A vulnerability programme needs to ask about both.

The absence of an applicable CVE does not establish that a capability is safe to expose.

Where #1 ends: separate the steps

“SS7 attack” is an umbrella description. Location tracking, message interception and account takeover are different actions and outcomes. My TLCTC interpretation separates them as follows:

The SMS case therefore reads:

#1 ||[signaling][@Attacker⇒@CarrierB→@CarrierA]|| → #5 + [DRE: C] → #4

It is tempting to stop at #1 and say that the SMS simply arrived where the function sent it. R-MITM does not allow that. The misused function gives the attacker the position, and capturing a message meant for someone else is what the position is then used for. The two steps have different generic vulnerabilities and different controls: one is the trust designed into a signalling function, the other is the lack of control over the path that an SMS code travels.

This also explains the SS7 line in the framework’s own papers. The core paper uses #5 ||[signaling][@Attacker⇒@CarrierB(SS7)⇒@CarrierA→@Target]|| to illustrate the transit operator, and the handbook continues it as → #4 → #1 + [DRE: C]. That example starts once the position is held. This article adds the step before it.

Could the first step be #5 as well? The channel clause of R-SPECIFIC sends a defective peer-authenticity control to #5, and SS7’s weak peer authentication looks similar at first sight. My reading is that the first step is still #1: a message that changes where a subscriber is registered is a request to a designed function, and at that moment no communication between two parties is being intercepted. The location query has no such communication at all. R-MITM then sequences the rest.

Two things that are not steps

A forged operator name. Citizen Lab describes both actors spoofing operator hostnames in Diameter’s Origin-Host field to evade firewall controls.[5] A forged operator name in a signalling field does not, by itself, prove the use of stolen or forged authentication credentials. Identifiers and credentials must be distinguished. Here the spoofing is a feature of the #1 step. It would become #4 only if evidence showed a credential being presented to authenticate as that operator.

A blocked exploit. Citizen Lab’s STA2 sequence includes a binary SMS built to run commands in the SIM’s S@T browser and report the device’s location. Had it run, foreign executable content would have executed and R-EXEC would require a #7 step. But the signalling firewall blocked the message: it “never reached the targeted phone.”[5] A cluster assignment asserts that the step succeeded, so this attempt is not a path step. Note also that this is a case where the handset’s SIM, not only the network, was the intended target. “Network-side” describes most of these attacks, not all of them.

The risk crosses organisational boundaries

The 2017 German case shows the whole sequence. According to the reporting, phishing pages collected the account number, password and registered mobile number. Attackers then used a foreign telephony network to instruct, via SS7, that calls and SMS be forwarded to a number they controlled, logged in, initiated a transfer and received the mobile transaction number needed to approve it.[9] My reading of that report:

#9 ||[human][@Attacker→@Customer]|| + [DRE: C] → #1 ||[signaling][@Attacker⇒@ForeignOperator→@HomeOperator]|| → #4 → #5 + [DRE: C] → #4 → #1 + [DRE: I]

The source is secondary and describes two stages, not a timeline, so the order of forwarding and login is my inference. No Δt values are given because the report states none. The article names the function as call forwarding and does not identify the specific SS7 operation.

The password came from the customer, by way of the phishing page. The loss of control over message routing occurred in telecom infrastructure. Disclosure of the code affected a credential. Its use produced a loss of control over the customer’s account at the bank. In business terms, the first event is a payment process executing a transfer the customer never authorised; the financial loss sits on top of it.

This is why the system boundary matters. “The customer’s phone was hacked” obscures where control was actually lost and which organisation could have interrupted the sequence. This path contains no step on the phone at all.

In an event-centred risk model, each transition deserves its own control question: what prevents unauthorised routing changes, what protects the code in transit, what protects the authentication decision, and what stops an unauthorised session from becoming a financial loss?

Put controls where they can interrupt the sequence

For operators, the lever sits at the #1 step: which functions are reachable from the interconnect, by whom, and under what plausibility checks. Signalling firewalls do work. They blocked the STA2 SIM exploit, and in 2017 O2-Telefónica said it had blocked the foreign provider the attackers used.[5][9] They are also a target of evasion: spoofed identifiers and selected routes exist to get past them.[5]

For organisations relying on SMS, NCSC guidance identifies roaming information and device information, such as a known device identifier or geolocation, as possible inputs to risk decisions. It also acknowledges the limitations. The subscriber may be legitimately roaming, and because the attack is short-lived there can be a race between the enterprise and the attacker, so NCSC suggests checking roaming status a second time soon after sending. These signals require interpretation; a roaming event alone is not proof of an attack.[6]

For authentication design, NIST SP 800-63B-4 classifies out-of-band authentication over the public switched telephone network as restricted (Sec. 3.1.3.3, 3.2.9). It requires a non-restricted alternative, meaningful notice to subscribers and explicit acceptance of the associated risks. It also distinguishes phishing-resistant cryptographic authentication from manually entered one-time passwords, which it does not consider phishing-resistant (Sec. 3.2.5).[8] Cryptographic authentication bound to the session removes the code that the #5 position was there to read.

For a bank, my recommendation is to assess the complete authentication and recovery process. Moving a primary login away from SMS leaves a material dependency if SMS can still reset access or enrol a replacement authenticator. NIST treats changing a pre-registered number as binding a new authenticator, and the control design should treat those routes in the same way.[8]

For risk owners, assurance should connect a control to the event it is intended to prevent or detect. A control inventory becomes useful when it shows where the sequence can stop and provides evidence that the control works there.

A lesson for every powerful interface

The broader lesson applies wherever software exposes useful capabilities: administrative APIs, identity services, workflow engines and agent tools. Reviewing implementation security is necessary. Reviewing what an authorised-looking request can cause is necessary too.

SS7 gives us a long-established example of that second problem. Its value as a teaching case is precisely its age: the cause remains recognisable across changes in technology and terminology.

A function can work as implemented while serving an attacker’s purpose. TLCTC #1 makes that possibility an explicit part of the threat model.