Today we are announcing the existence of the vulnerability and associated exploits that we call Simjacker. We believe this vulnerability has been exploited for at least the last 2 years by a highly sophisticated threat actor in multiple countries, primarily for the purposes of surveillance. Other than the impact on its victims, from our analysis, Simjacker and its associated exploits is a huge jump in complexity and sophistication compared to attacks previously seen over mobile core networks. It represents a considerable escalation in the skillset and abilities of attackers seeking to exploit mobile networks.

We will be giving technical details on Simjacker during the Virus Bulletin Conference, London, 3rd October 2019 but in this blog we will give an overview of Simjacker, how it works and who is potentially exploiting it, as well as why it is such a significant new type of attack.

 

How does Simjacker attacks Work

At its simplest, the main Simjacker attack involves a SMS containing a specific type of spyware-like code being sent to a mobile phone, which then instructs the UICC (SIM Card) within the phone to ‘take over’ the mobile phone , in order to retrieve and perform sensitive commands.

Get Simjacker Techincal Report >

The attack begins when a SMS – that we term the Simjacker ‘Attack Message’ – is sent to the targeted handset. This Simjacker Attack Message, sent from another handset, a GSM Modem or a SMS sending account connected to an A2P account, contains a series of SIM Toolkit (STK) instructions, and is specifically crafted to be passed on to the UICC/eUICC (SIM Card) within the device. In order for these instructions to work, the attack exploits the presence of a particular piece of software, called the S@T Browser – that is on the UICC. Once the Simjacker Attack Message is received by the UICC, it uses the S@T Browser library as an execution environment on the UICC, where it can trigger logic on the handset. For the main attack observed, the Simjacker code running on the UICC requests location and specific device information (the IMEI) from the handset. Once this information is retrieved, the Simjacker code running on the UICC then collates it and sends the combined information to a recipient number via another SMS (we call this the ‘Data Message’), again by triggering logic on the handset. This Data Message is the method by which the location and IMEI information can be exfiltrated to a remote phone controlled by the attacker.

During the attack, the user is completely unaware that they received the SMS with the Simjacker Attack message, that information was retrieved, and that it was sent outwards in the Data Message SMS – there is no indication in any SMS inbox or outbox.

What makes this Attack work and why is it Special?

The attack relies both on these specific SMS messages being allowed, and the S@T Browser software being present on the UICC in the targeted phone. Specific SMS messages targeting UICC cards have been demonstrated before on how they could be exploited for malicious purposes. The Simjacker attack takes a different approach, and greatly simplifies and expands the attack by relying on the S@T Browser software as an execution environment. The S@T (pronounced sat) Browser – or SIMalliance Toolbox Browser to give it its full name – is an application specified by the SIMalliance, and can be installed on a variety of UICC (SIM cards), including eSIMs. This S@T Browser software is not well known, is quite old, and its initial purpose was to enable services such as getting your account balance through the SIM card. Globally, its function has been mostly superseded by other technologies, and its specification has not been updated since 2009, however, like many legacy technologies it is still been used while remaining in the background. In this case we have observed the S@T protocol being used by mobile operators in at least 30 countries whose cumulative population adds up to over a billion people, so a sizable amount of people are potentially affected. It is also highly likely that additional countries have mobile operators that continue to use the technology on specific SIM cards.

This attack is also unique, in that the Simjacker Attack Message could logically be classified as carrying a complete malware payload, specifically spyware. This is because it contains a list of instructions that the SIM card is to execute. As software is essentially a list of instructions, and malware is ‘bad’ software, then this could make the Simjacker exploit the first real-life case of malware (specificially spyware) sent within a SMS. Previous malware sent by SMS – such as the incidents we profiled here – have involved sending links to malware, not the malware itself within a complete message.

Beyond Location

However, the novelty and potential of Simjacker does not stop there. Retrieving a person’s location is one thing, but by using the same technique, and by modifying the attack message, the attacker could instruct the UICC to execute a range of other attacks. This is because using the same method the attacker has access to a range* of STK command set, some examples of these STK commands are:

 

• PLAY TONE
• SEND SHORT MESSAGE
• SET UP CALL
• SEND USSD
• SEND SS
• PROVIDE LOCAL INFORMATION
  • Location Information, IMEI, Battery, Network, Language, etc
• SEND DTMF COMMAND
• LAUNCH BROWSER

*Note: 25/09/19 – in the earlier version of this blog, a number of additional proactive STK commands were included above. Subsequent analysis has shown that these commands are unlikely to be actionable and so have been removed.

By using these commands in our own tests, we were able to make targeted handsets open up web browsers, ring other phones, send text messages and so on. These attacks could be used to fulfil such purposes as

• Mis-information (e.g. by sending SMS/MMS messages with attacker controlled content)
• Fraud (e.g. by dialling premium rate numbers),
• Espionage (as well as the location retrieving attack an attacked device it could function as a listening device, by ringing a number),
• Malware spreading (by forcing a browser to open a web page with malware located on it)
• Denial of service (e.g by disabling the SIM card)
• Information retrieval (retrieve other information like language, radio type, battery level etc.)

It even may be possible to go even further – depending on handset type – which we will discuss in our VB2019 presentation. Worryingly, we are not the only people to think of these additional attacks, over the last few weeks and months we have observed the attackers themselves experiment with these different capabilities.

Finally, another benefit of Simjacker from the attacker’s perspective is that many of its attacks seems to work independent of handset types, as the vulnerability is dependent on the software on the UICC and not the device. We have observed devices from nearly every manufacturer being successfully targeted to retrieve location: Apple, ZTE, Motorola, Samsung, Google, Huawei, and even IoT devices with SIM cards. One important note is that for some specific attacks handset types do matter. Some, such as setting up a call, require user interaction to confirm, but this is not guaranteed and older phones or devices with no keypad or screens (such as IoT device) may not even ask for this.

Who is Doing this

The next question then is who is exploiting this, and why? We are quite confident that this exploit has been developed by a specific private company that works with governments to monitor individuals. As well as producing this spyware, this same company also have extensive access to the SS7 and Diameter core network, as we have seen some of the same Simjacker victims being targeted using attacks over the SS7 network as well, with SS7 attack methods being used as a fall-back method when Simjacker attacks do not succeed. So far, we have seen phone numbers from several countries being targeted by these attacks and we are very certain that individuals in other countries have also been targeted via Simjacker attacks. Using our collection of Signalling Intelligence (SIGIL) we were able to correlate this Simjacker-related SS7 activity with a group we have already detected attempting to attack targets via SS7 means around the world.

In one country we are seeing roughly 100-150 specific individual phone numbers being targeted per day via Simjacker attacks, although we have witnessed bursts of up to 300 phone numbers attempting to be tracked in a day, the distribution of tracking attempts varies. A few phone numbers, presumably high-value, were attempted to be tracked several hundred times over a 7-day period, but most had much smaller volumes. A similar pattern was seen looking at per-day activity, many phone numbers were targeted repeatedly over several days, weeks or months at a time, while others were targeted as a once-off attack. These patterns and the number of tracking indicates it is not a mass surveillance operation, but one designed to track a large number of individuals for a variety of purposes, with targets and priorities shifting over time. The ‘first use’ of the Simjacker method makes sense from this viewpoint, as doing this kind of large volume tracking using SS7 or Diameter methods can potentially expose these sources to detection, so it makes more sense to preserve those methods for escalations or when difficulties are encountered.

Blocking the Attacks and Thinking Long-term

In order to deal with this vulnerability, we and the mobile industry have been taking a number of steps.

1. We have been working with our own mobile operator customers to block these attacks, and we are grateful for their assistance in helping detect this activity.
2. We also communicated to the GSM Association – the trade body representing the mobile operator community – the existence of this vulnerability. This vulnerability has been managed through the GSMA CVD program, allowing information to be shared throughout the mobile community.
3. As part of this, information was also shared to the SIM alliance, a trade body representing the main SIM Card/UICC manufacturers and they have made new security recommendations for the S@T Browser technology.

In general, our recommendations for the mobile community to deal with the immediate threat is for mobile operators to analyse and block suspicious messages that contain S@T Browser commands. Mobile Operators could also try to change the security settings of UICCs in the field remotely, or even uninstall and stop using the S@T Browser technology completely, but this may be slower and considerably more difficult to do. However, this is very much only a first step, due to the greater implications of the Simjacker attacks.

The existence of Simjacker at all means that we need to radically alter our mindset when it comes to the security of mobile core networks. We believe that the Simjacker attack evolved as a direct replacement for the abilities that were lost to mobile network attackers when operators started to secure their SS7 and Diameter infrastructure. But whereas successful SS7 attacks required specific SS7 knowledge (and access), the Simjacker Attack Message require a much broader range of specific SMS , SIM Card, Handset, Sim Toolkit , S@T Browser and SS7 knowledge to craft. This investment has clearly paid off for the attackers, as they ended up with a method to control any mobile phone in a certain country, all with only a $10 GSM Modem and a target phone number. In short, the advent of Simjacker means that attackers of mobile operators have invested heavily in new attack techniques, and this new investment and skillset means we should expect more of these kinds of complex attacks.

As a consequence, this means that we, in the mobile security community also need to improve our capabilities. For mobile operators, this also means that relying on existing recommendations will not be sufficient to protect themselves, as attackers like these will always evolve to try to evade what is put in place. Instead, mobile operators will need to constantly investigate suspicious and malicious activity to discover ‘hidden’ attacks. We can and should expect other vulnerabilities and attacks that also evade existing defences to be discovered and abused. As the attackers have expanded their abilities beyond simply exploiting unsecured networks, to now cover a very complex mix of protocols, execution environments and technologies to launch attacks with, Operators will also need to increase their own abilities and investment in detecting and blocking these attacks.

Read: Simjacker Frequently Asked Questions and Demos

The Future

We are only scratching the surface of Simjacker in this article. In our presentation at Virus Bulletin Conference, London, on the 3rd of October 2019 we will give more details on the format of the attacks, what the attackers do to attempt to evade detection and how they operate their system, along with a flavour of what has been their reaction since their attacks have been detected and blocked. We will also give our view on what we believe these attacks will evolve into next. We expect a reaction from this news is made public and we will present what (if any) the public revelations have on their malicious activity.

The Simjacker exploit represent a huge, nearly Stuxnet-like, leap in complexity from previous SMS or SS7/Diameter attacks, and show us that the range and possibility of attacks on core networks are more complex than we could have imagined in the past. Now is the time to make sure that we stay ahead of these attacks in the future.