There are two kinds of SS7 commands, my friend: the harmless ones… and the ones that can blow things up…

… Okay, that may be an exaggeration, however just like the characters in Spaghetti Westerns, the commands encountered in the SS7 landscape come in a wide range of shapes and sizes and can sometimes be difficult to interpret (or most importantly, process safely). SS7 commands (or PDUs) that are not processed correctly pose significant risks, potentially resulting in the equivalent of a signaling “zero-day” enabling any of the wide range of attacks possible via SS7.

A Fistful of Exploits

Several effective SS7 bypass attack techniques have emerged in the past few years, to bypass new defences that have been put in place over time. While not numerous, they do emerge on a fairly regular basis, as would be expected from attackers who are paid large sums of money to devise new ways of avoiding defences. A table summarizing the SS7 bypass attacks encountered in real-life over the last few years is below.

[1] Some of these have GSMA CVD numbers, however for these cases the GSMA allocated these not when the vulnerability was first reported or made public, but when formally submitted to the GSMA by different researchers.

You can see that the majority of the above involve what is called the TCAP layer, which is part of the SS7 protocol stack. This layer has turned into an attractive area for attackers to exploit due to its history, nature and specifically, how it is structured. The first reported attack that used an unusual TCAP encoding technique was a method known as global opcode encoding, detected and reported in 2019. Since then a variety of other methods have been observed and shared within the industry. The aim of all of these methods has been to try to avoid (bypass) the increasing security that mobile operators have put in place for their SS7 networks. In recent months, Enea’s Threat Intelligence Unit has detected a new variant of these TCAP manipulation structures, which fits into this trend of exploitation by the attackers.

Every Byte Counts

First some background. TCAP (Transaction Capabilities Application Part) is the layer of the SS7 protocol that carries application data to be exchanged between SS7 nodes. It is encoded in ASN.1 BER (Basic Encoding Rules), in a series of recommendations defined by the ITU. ASN.1 notation was first standardized in 1984 and is a way of specifying abstract data objects being widely used in industries where  “efficient (low-bandwidth, low-transaction-cost) computer communications are needed”.  ASN.1 BER, is a specific set of rules of encoding ASN.1 objects and are characterised by a level of freedom in how the ASN.1 objects can be encoded, in that objects may be encoded in more than one way. This differs from other ASN.1 encoding rules such as DER (Direct Encoding Rules), where there is only one way for objects to be encoded. From a security perspective, the combination of complexity in this layer (due to the need for efficient communication), coupled with flexibility in its structure, means this layer has become a natural choice for attackers looking for encoding exploits, as demonstrated by recent history of reported attacks using TCAP. The principle behind each of these irregular TCAP encoding techniques is the same – structure the PDU in some unexpected, and in some cases legal way – and hopefully the PDU or some of its contents will not be decodable by protection systems or firewalls at the target network, resulting in the bypass of security protection.

Keep Your Eyes on the Wire, Partner

To explain this new TCAP irregular encoding method, which we have detected in the wild, we need to do a crash course on how exactly TCAP messages are structured using ASN.1 BER encoding. The building blocks of TCAP are Information Elements, which always have three fields, that appear in the following order:

1. The Tag distinguishes one type from another and governs the interpretation of the Contents. We will discuss this in detail later.
2. The Length specifies the length of the Contents.
3. The Contents is the substance of the element, containing the primary information the element is intended to convey.

Figure 1: Structure of TCAP message and Information Element, ITU Q.773

TCAP Information Elements can be called one of two types: Primitives or Constructors. The difference between these is that the content for Primitives is just one value, whereas for Constructors it is one or more IEs (which could also be nested constructors and so on).

Figure 2: Primitive v Constructor TCAP IE, from ITU Q.773

Combining these concepts, a full TCAP message then may be comprised of many different parts. Below is taken from ITU Q.773, and is the detailed structure of a typical TCAP message.

Figure 3: Detailed TCAP message structure, from IITU Q.773

As shown above, there are three named parts: Transaction Portion, Dialogue Portion and Component Portion. We won’t go into detail on what they all do here, but the parts we are interested in today are the IEs in the innermost part – e.g. Components in the Component portion. These components can contain information for the layers in the SS7 stack that sit above TCAP – namely GSM-MAP in this case. One of the most important TCAP components in the SS7 system is called an Invoke – it’s the operation that is used to initiate a process in the receiving TCAP element. Its structure is below:

Figure 1: Table of Invoke Component, from ITU Q.773

As you can see it is made up of a Constructor (a nested IE), and then a series of Primitives/Constructors. It is here, in the encoding of one of these Parameters, that the attackers made their move.

The Man With No IMSI

The latest of these TCAP encoding anomalies we have detected focuses specifically on the encoding of a particular IE within an Invoke Component.

What we have observed, is that the encoding of an IE containing the IMSI field – which is the user identity, within a PSI (ProvideSubscriberInfo) Invoke, has been altered. PSI is a GSM-MAP command, which is encapsulated within the TCAP layer. For malicious purposes it can be used for location tracking (see our previous research on this here and here) – by requesting the core network element that received it to send back the location information of the targeted mobile phone user (subscriber). A critical part of the PSI command is the IMSI field contained within it, as this is literally the target being tracked. In a normal PSI, the Invoke component that contains the IMSI could be encoded as follows:

This would not make much sense to people, so let’s break it down visually:

Figure 5: Breakdown of the TCAP Component with Attack

There is a lot to unpack here, but in general you can appreciate the complexity, as well as the variable nature of the encoding. The fields themselves are straightforward once you know the format. The hex indicates it is a ProvideSubscriberInformation command, for a specific IMSI – that we have obfuscated as all FFs – and the requested Information is location information, the state of the subscriber (on or off etc.) and its IMEI (International Mobile Equipment Identity). Visually in Wireshark it would look like this:

Figure 6: Attack using PSI with ‘standard’ fields

So far so good. However, what we have observed, are PSI commands formatted as follows:

Visually, were we to compare this string to the earlier one, eagle-eyed readers would see that it is longer by one octet. As a result some lengths are different. But what is this difference? It turns out, the important difference is in the encoding of the IMSI.

Normally, the start of the IE (Constructor) that contains the IMSI would be encoded as follows: 30 12 80 08. Let’s break this down:

What we have observed from an attacker, is the following sequence:  30 13 9f 00 08. So what is happening here? Basically, it seems the attacker is using a little-known technique of extending the Tag that contains the IMSI. We break it down below:

For a Few Octets More

At this point, people would be forgiven for exclaiming about what is going on, but if we look deeper, some of the issues with ASN.1 BER encoding now become obvious. It turns out, there is a way to extend the Tag code in TCAP IEs. As explained in ITU Q.773, Bits A to E of the first octet of the Tag normally represent a Tag code, so tag codes in the range 00000 to 11110 (0 to 30 decimal) can be provided in one octet. But what if you wanted a Tag code higher than 30?

In that case, the TCAP specification writers specified a case where if you coded bits A to E of the tag code as 11111, then this would indicate that the Tag Code was being extended over the subsequent octet(s). Subsequent octets can then specify if the extension is to continue by setting bit H as 0 or not, as an extension indication. If bit H of the extension octet is set to 0, then no further octets for this tag are used.

Figure 7: Format of the Tag Code, from ITU Q.773

The full details of the extension mechanism are in section 4.1.2.23 of ITU Q.773, but in our case since the octet value that follows is 00, no bits are set, and no further octets are expected for this tag. Below is a Wireshark capture of the attack:

Figure 8: Wireshark of Attack Message

If You’re Gonna Shoot, Shoot. Don’t Talk.

So what is the whole point of the attackers using a weird way to encode a particular field in a particular packet? Well, as mentioned, this SS7 packet – PSI – is used extensively for location tracking. It is perfectly legitimate for mobile operators to use it for their subscribers who may be roaming abroad, for billing and mobility control, but they are the only ones who should be using it. However a mobile operator must handle inbound roamers into their network, and so it must also permit inbound PSIs into its network, which request information on these inbound roamers. What a mobile operator must stop though, are inbound PSIs coming in from outside the home operator, which are trying to get information on home subscribers, and a key way for the mobile operator to know what PSI to permit and what to block is based on the IMSI in the PSI packet. Basically, if the source is not the home network, but the IMSI is from the home network, then the PSI should be blocked. How this blocking is done now varies, but it tends to be via a collection of firewalls and other checks as close as possible to the signaling ‘border’.

This Tag extension though, breaks this check for some mobile operators. We have observed that some (not all) signaling systems permit a packet containing a bad IMSI with this Tag extension set to be sent into the network. We believe this happens for two reasons:

1. Tag Decoding is Not Implemented

The Tag extension method does not actually seem to be used for any TCAP packet in normal operation, yet it remains a valid part of the specification. As a result, it is safe to assume that some SS7 software decoding stacks (on which many security solutions were later built) simply did not have the software logic to understand an extended TCAP code. Why build something which has never been encountered in over 40 years of TCAP usage? 

2. Conservative Treatment of Undecoded Fields

One feature of many SS7 signaling security solutions, is that they are built on top of older SS7 software stacks. These stacks generally came from an environment of permissiveness when it came to undecodable fields, especially if the decoding was happening in a transit node. Generally, the philosophy was/is – if it can be routed – then the end node can worry about the decoding. This was especially important for an old(er) protocol like SS7, where a lot of customizations and specific nature changes have been implemented between mobile operators over the years.

The sum effect of both of these can explain why an attack using a TCAP IE with an extended Tag could work against some signaling security nodes. When used for an IMSI, the software cannot understand it, and then it just permits it. The IMSI is essentially hidden for the purpose of the security checks. A PSI may be received from external sources, but because essentially no readable IMSI is present, then it does not break any home v non-home IMSI check.

The Mercenary

This matches what we have observed in real life. We observed attacks using PSIs with this Tag code set, and subsequent PSI responses being sent back containing the subscriber’s location. We believe that the presence of the extended Tag caused the IMSI field to be ignored by elements that were doing signaling security checks – the targeted IMSI was essentially “hidden” – and so it couldn’t be used in any checks. The end result is that location tracking attacks for home networks subscribers were allowed through.

The source of the attacks matched a surveillance company that we have tracked for many years, and we believe that this was identified and used by them. Subsequent retrospective analysis confirmed that this technique was being used at least as far back as Q4 2024, and it seems to have formed part of their “suite” of tests since then that they try to use to bypass signaling security defences in targeted mobile operators. We don’t have any information on how successful this attack method has been worldwide, as its success is vendor/software specific, rather than being a general protocol vulnerability, but its use as part of a suite indicates that it has had some value.

There’s a New Sheriff in Town

To recap, what we have in this scenario is a TCAP structure that is arguably legal, but may cause problems with some ASN1 decoders, resulting in the failure to extract the IMSI details from within the PSI Request. This could be problematic for firewalls that should block any SS7 packet from OffNet sources where the IMSI is a home network IMSI. While we observed this being used to extract location information, the same method could be used for any IE in the TCAP specification. We have observed this being used in real-life, meaning that there has been some value to this attack technique.

To help prevent these attacks, we have worked with our signaling security customers to ensure that they are safe, and we have disclosed details of the attack, and shared recommendations to prevent it within the GSMA community. To combat this and other related attacks, Enea recommends blocking all malformed PDU structures which are not known to be benign, or blocking any MAP PDUs where an IMSI is expected, but no IMSI was found within the decoded PDU. The attacker in this case is a surveillance company that we have been monitoring and blocking attacks from for many years. We expect that further evolution of attacks will continue, especially in the TCAP layer where the ASN.1 protocol gives many opportunities to evade and disguise the true intentions of any messages sent, but also over the other signaling protocols.

This article was co-authored by Cathal Mc Daid and Martin Gallagher.

With a unique combination of advanced detection methods, developed from extensive signaling threat research and global intelligence, Enea provides expert signaling protection against new, emerging and evolving signaling threats. Discover how>