


How it Works

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.

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?


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:

    • Location Information, IMEI, Battery, Network, Language, etc

*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.


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 to 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.

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 being made public and we will present on 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.