Simjacker
Technical
Paper
10OCT19-v1.01
Simjacker Technical Report
©2019 AdaptiveMobile Security
Legal Notices
© 2019 AdaptiveMobile. All rights reserved. This document, or any part thereof, may not,
without the written consent of Adaptive Mobile Security Limited, be copied, reprinted or
reproduced in any material form including but not limited to photocopying, transcribing,
transmitting or storing it in any medium or translating it into any language, in any form or by
any means, be it electronic, mechanical, optical, magnetic or otherwise.
AdaptiveMobile, Network Protection Platform and PolicyFilter are trademarks of Adaptive
Mobile Security Ltd.
All other products are trademarks or registered trademarks of their respective owners and
are hereby recognised as such.
The information contained herein is believed to be accurate and reliable. Adaptive Mobile
Security Ltd. accepts no responsibility for its use by any means or in any way whatsoever.
Adaptive Mobile Security Ltd. shall not be liable for any expenses, costs or damage that may
result from the use of the information contained within this document. The information
contained herein is subject to change without notice.
Simjacker
Technical
Paper
10OCT19-v1.01
Simjacker Technical Report
©2019 AdaptiveMobile Security
Legal Notices
© 2019 AdaptiveMobile. All rights reserved. This document, or any part thereof, may not,
without the written consent of Adaptive Mobile Security Limited, be copied, reprinted or
reproduced in any material form including but not limited to photocopying, transcribing,
transmitting or storing it in any medium or translating it into any language, in any form or by
any means, be it electronic, mechanical, optical, magnetic or otherwise.
AdaptiveMobile, Network Protection Platform and PolicyFilter are trademarks of Adaptive
Mobile Security Ltd.
All other products are trademarks or registered trademarks of their respective owners and
are hereby recognised as such.
The information contained herein is believed to be accurate and reliable. Adaptive Mobile
Security Ltd. accepts no responsibility for its use by any means or in any way whatsoever.
Adaptive Mobile Security Ltd. shall not be liable for any expenses, costs or damage that may
result from the use of the information contained within this document. The information
contained herein is subject to change without notice.
8
Simjacker Technical Report
©2019 AdaptiveMobile Security
Figure 2: S@T 01.50[2] v4.0 Section 5.5.2 Security Levels
Four categories of message are included in the S@T Browser specifications:
• Pull
• Administration
• High Priority Push
• Low Priority Push
High Priority Push and Low Priority Push are the type of messages that are used in the
Simjacker attack.
As we can see above [2] recommends that the “no security applied” level is used for Pull
messages, and that the Triple-DES cryptographic checksum level is used for Administration
messages. The issue is there is no explicit recommendation for what security level should be
used for Push messages, but it is clear that the zero-security level is widely used for these in
practice. In our analysis of potentially affected operators (see section 7.1), we observed that
the overwhelming number of operator implementations of S@T Browser High Priority Push
and S@T Low Priority Push used the non-security parameters settings for these messages.
This means that any attacker can send a Push message to the target device, with no need to
apply any kind of cryptographic authentication, and the S@T Browser will accept the
message.
3.1.3 Other Conditions
There is additional condition on the attack being successful, that is related to the capabilities
of the SIM Card itself, namely the EFSST .
The values in EFSST are defined in 3GPP TS 51.011[9], but the relevant ones are
• Service no. 26 – Data Download via SMS-PP
• Service no. 29 – Proactive SIM
These two services must be allocated and activated for the message to actually be
processed by the SIM Card, but these capabilities are normally common.
9
Simjacker Technical Report
©2019 AdaptiveMobile Security
3.2 Structure of a typical Simjacker Message
At a logical high level, a typical Simjacker message observed in the wild has the following
structure.
Figure 3: Simjacker Attack Message Structure
The following is the explanation of the commands. Note, in most of the below there are
many variations of the attack observed, these are covered in more detail in Section 5.
3.2.1 Simjacker S@T/STK Command Order
We use for shorthand S@T for commands that are defined in [3] , and STK for command that
are defined in [10]. If other commands use different specifications they are indicated. Both
the S@T and STK commands are defined as TL[A]V variables.
- S@T Push/ Create Dynamic Deck/ Create Card
A sequence of Push, Create Dynamic Deck and Create Card commands are run. In the
attacker’s case they normally set a bit that indicates that the Deck shall not be cached by the
S@T browser. This is done to ensure there isn’t any trace of the message preserved on the
SIM. In addition, the attackers often use a ResetVar Attribute value in the Card declaration to
ensure that the Variables are reset, after the commands finish see Section 3.2.2 - S@T Create INIT Variable
The first INIT Variable contains a fully formed SMS-SUBMIT Message Header which was
received in the Simjacker message. Its main interest to us is that it contains a TP-DA. This is
the Destination address to which the subsequent Data Message should be sent to (i.e. the
Exfiltration Address). This information is stored in Variable 1.
11
Simjacker Technical Report
©2019 AdaptiveMobile Security
3.2.2 Variable Management in the Simjacker Attack
Variables in the S@T environment are where the respective pieces of information (SMS-
SUBMIT Header, Location, IMEI, Filler etc) are stored prior to be sent externally. For the
Simjacker attacks the Variables themselves are always stored as temporary variables - see
Section 5.3 of [3] -this means they are cleared when:
• the S@T browser goes to the idle state;
• the S@T browser starts a card with ResetVar flag set in the card attribute;
• high priority push is received.
The S@T browser goes to the idle state (S@T browser exits) after the last command of the
card has been executed and no branching has been done.
In observation, we see that the attackers are well aware of the need to keep the temporary
variables cleared. In situations where they request Location information in quick succession
(2 messages to the same target in less than a few seconds) they specify the 2nd request as a
High Priority Push, to ensure that there is no retention of the previous temporary values set
in the 1st
, Low Priority Push Message.
In addition, to further ensure variables are not overwritten, the ResetVar flag is set in the
Card value over >44% of the time. The ResetVar is used to reset (i.e. remove) all the
temporary variables before executing the first command in the card.
12
Simjacker Technical Report
©2019 AdaptiveMobile Security
4 Simjacker Attacker Structure and
Operating Procedure
The attackers we detected using the Simjacker message vary their methods and use of the
Simjacker vulnerability constantly. This is due to changing conditions, objectives and
defences being put in place.
This makes profiling what is the ‘normal’ use of the vulnerability difficult. Nevertheless, we
can show what is the typical activity in a time period, as a representative guide. In the below
analysis, we have taken a typical 31-day continuous time period, from sometime within the
last year. This period is a time where we actively engaged in detecting and blocking these
attacks with our mobile customers. From retrospective analysis, it is also similar to other
time periods when blocking was not occurring, so this 31-day period is representative of the
activity throughout the larger timespan.
4.1 Volumes in Period Targeted
In this time period we observed > 25k Simjacker messages attempted to be sent to >1500
Unique Identifiers. These identifiers represent unique Mobile Subscribers being targeted.
The overwhelming majority of targeted mobile subscriber we have observed are from
Mexico. We have observed at times these particular attackers occasionally target mobile
subscribers from Colombia and Peru but these are far smaller compared to Mexican
targeted devices.
In this time period, 45% of subscribers were targeted only once, while a few individual
subscribers were targeted thousands of times in this period.
13
Simjacker Technical Report
©2019 AdaptiveMobile Security
Figure 4: Distribution of number of attacks per each subscriber
Over 69% of targeted Mobile Subscribers were only targeted on one day, a very small
number were targeted almost every single day.
Figure 5: Number of Attacks per Subscriber v Number of Days Subscriber was Targeted
14
Simjacker Technical Report
©2019 AdaptiveMobile Security
Overall, we can see that a large amount of targeted subscribers are only queried once. On
the other hand, a few subscribers are intensely tracked over long duration periods. There is
also a long continuum in between these two extremes. Generally, the system seems to be
used for multiple different tracking models.
4.2 Information Retrieved
The primary objective (89.19%) in these attacks is to obtain both Location Information
according to current NAA (Serving Cell ID) and IMEI of the terminal. These are obtained via
the Proactive Provide Local Information command. Other Proactive commands are also
intermittently (4.25%) executed.
Figure 6: Types of Proactive Command Executed
Other Activity in this case are commands that the attackers execute probably for testing of
the functionality and effectiveness of the attacks, i.e.
• Display Text (Test Messages),
• Launch Browser (Test websites),
• Set Up Call (test recipient number) and
• Send USSD (test PIN change)
15
Simjacker Technical Report
©2019 AdaptiveMobile Security
The breakdown of Information retrieved is of the following type:
Figure 7: Type of Information being Retrieved
4.3 Simjacker Attack Packet Format
4.3.1 High Priority Push v Low Priority Push
The vast majority (99.23%) of Attack messages sent in this period were S@T Browser Low
Priority Push messages. High Priority Push messages were only used when targeting the
same victim in quick succession after a Low Priority Push message, see Section 3.2.2 for
more details on how exactly this works.
4.3.2 SMS Packet Header Encoding
Within this specific time period, we observed over 1000 different types of encoding
combinations attempts of the Simjacker Attack Packet Header i.e. the Protocol ID, message
class and the user data header.
We believe that the varying encoding combinations of the header was done to attempt to
avoid Mobile Operators network defences (see sections 5.1.3).
4.3.3 Simjacker Attack Message Variants
Within this specific time period, we observed we detected over > 860 Simjacker Attack
sub-variants in the actual SMS Packet. We identify variants that execute different features,
have different values (excluding source/exfiltration addresses) and different Variable IDs.
16
Simjacker Technical Report
©2019 AdaptiveMobile Security
We believe the variations in the actual Simjacker Attack packet itself was done to also
potentially avoid defences, or potentially to tailor the attack per specific Sim card type.
Section 5 explains in more detail the techniques used by the attacker.
4.4 Infrastructure Used by Attacker Network
Sending Attack Message: In this period, the Sending Infrastructure comprised of over 70
sending number of devices sending the attack messages. The main sender sent nearly 22%
of attacks, but most sending devices sent less than 5% of attacks in this time.
Figure 8: Simjacker Sender % Volumes
Receiving Data Message: Within the Simjacker Attack Messages, we identified over 60
unique Exfiltration address numbers in the embedded SMS-Submit, these are sent the
subsequent Data Message. It seems there were 4 main exfiltration numbers that were
designated to receive any subsequent Data Messages in this period, every other number
received less than 5%.