FD IRQ Test Report May 2017 v1.0 2017-05-20 PDF

SS7 test report for IRQAC – Test date 05/08/2017 to 05/14/2017
Forward Defense
IRQAC SS7 penetration and fraud testing report
v1.0
May 20th, 2017
CONFIDENTIAL
Copyright Forward Defense www.forwarddefense.com
Table of Contents
Background................................................................................................................................................4
Executive summary....................................................................................................................................5
Summary of vulnerabilities........................................................................................................................6
Vulnerability map.......................................................................................................................................8
Leaking of IMSIs and serving MSC..........................................................................................................9
I. SendRoutingInfoForSM.....................................................................................................................9
II. SendRoutingInformation................................................................................................................10
III. SendRoutingInfoForLCS...............................................................................................................10
IV. SendIMSI.......................................................................................................................................11
V. SRI-GPRS.......................................................................................................................................13
VI. Leaking of serving MME by RestoreData....................................................................................15
VII. ProvideRoamingNumber.............................................................................................................16
Leaking of subscriber location.................................................................................................................16
I. AnytimeInterrogation.......................................................................................................................17
II. ProvideSubscriberInformation to MSC..........................................................................................20
III. ProvideSubscriberLocation to MSC..............................................................................................23
IV. ProvideSubscriberInfo to SGSN....................................................................................................24
V. ProvideSubscriberLocation to SGSN..............................................................................................24
Payload Interception................................................................................................................................25
I. Capturing of inbound SMS messages..............................................................................................25
II. Outgoing call interception..............................................................................................................28
III. Call forwarding..............................................................................................................................30
Disruption of a subscriber’s services.......................................................................................................32
I. CancelLocation to the MSC.............................................................................................................32
II. CancelLocation to the SGSN..........................................................................................................34
III. Inbound call and SMS disruption by PurgeMS to HLR................................................................36
IV. Inbound call and SMS disruption by LocationUpdate..................................................................38
V. Call barring by ODB.......................................................................................................................38
VI. Call barring by CAMEL................................................................................................................39
VII. Exhaustion of roaming numbers in MSC....................................................................................41
Toll and billing fraud................................................................................................................................44
I. Avoidance of charges for international calls by ISD........................................................................44
II. Avoidance of charges for international calls by DSD.....................................................................46
III. Avoidance of charges for SMS......................................................................................................48
IV. Fraudulent depletion of subscriber’s account balance by CAMEL IDP........................................48
USSD fraud..............................................................................................................................................51
Wholesale SMS fraud..............................................................................................................................53
I. ForwardSM......................................................................................................................................53
II. MoForwardSM...............................................................................................................................55
IMSI catchers...........................................................................................................................................57
I. Resolving of IMSIs by RestoreData................................................................................................57
CONFIDENTIAL
II. Retrieval of encryption key for over-the-air payload decryption...................................................59

III. Retrieval of authentication keys for man-in-the-middle attacks...................................................61
CONFIDENTIAL
Background
Forward Defense has performed an SS7 penetration test against Asiacell Iraq (IRQAC) to
discover as many SS7 based vulnerabilities as possible.
The test was conducted between May 8 tht and May 14th 2017 by mobile security consultant
Jean Gottschalk.
For any questions regarding these findings, you can contact Jean Gottschalk at
jgottschalk@forwarddefense.com or +1 702 371 2730 (PST timezone).
Forward Defense conducted its tests through an international SS7 connection of an arbitrary
roaming partner of IRQAC who has substantially the same type of connectivity as the majority
of other IRQAC roaming partners. Therefore we believe these tests to be representative of
the vulnerabilities that can be exploited by anyone anywhere with access to IRQAC roaming
partner SS7 connectivity.
Tests were directed at two test subscriptions provided by IRQAC:

Prepaid: +9647717228011
Postpaid: +9647717063017
CONFIDENTIAL
Executive summary
The IRQAC network has been found vulnerable to the following:
Subscriber privacy vulnerabilities
While the IRQAC network is not vulnerable to several of the information disclosure test cases,
it is still possible to obtain a subscriber’s IMSI and serving MSC, and then identify the Cell
ID to which subscribers are attached in order to track them (but not to obtain GPS
coordinates). It is also possible to intercept incoming SMS (which can lead to wire transfer
fraud, Whatsapp and Signal account cloning and Gmail 2FA breach for example), call
forward incoming calls and listen to outgoing calls. The network has also been found
vulnerable to the deployment of both passive and active IMSI catchers.
While not immediately revenue impacting, these techniques are known to be used by foreign
friendly and unfriendly intelligence agencies and can therefore pose a threat to the country’s
security and VIPs.
Service disruption vulnerabilities
Several vulnerabilities have been found that would allow an attacker to disrupt voice and
data services for subscribers. These vulnerabilities are deemed less critical, as they would
not result in a direct financial gain for the attacker and would therefore be less likely to be
exploited, but could be used by a competitor to tarnish the quality reputation of the network for
example, or by enemies during wartime to create intentional service blackouts on a large
scale.
Toll and billing vulnerabilities
Several vulnerabilities have been found that would allow subscribers to place international
calls without being billed, which could be exploited for large scale premium number fraud.
In addition the network is vulnerable to prepaid credit fraud via USSD.
The network is also vulnerable to wholesale SMS fraud which could allow attackers to transit
large amounts of SMS messages to third party networks and cause a large financial loss for
IRQAC.
It is recommended for IRQAC to address these vulnerabilities as soon as possible, starting

with those that can be resolved by simple reconfiguration of existing network nodes, and
moving progressively towards the deployment of a suitable SS7 firewall able to eliminate all
found vulnerabilities.
An external SS7 vulnerability retest is recommended after a firewall has been implemented, to
confirm that no open vulnerabilities remain on the network.
CONFIDENTIAL
Summary of vulnerabilities
Leaking of IMSI and serving MSC
SendRoutingInfoforSM Not vulnerable
SendRoutingInformation Not vulnerable
SendRoutingInfoForLCS Not vulnerable
SendRoutingInfoForGPRS Vulnerable
SendIMSI Vulnerable
Leaking of serving MME by RestoreData Not vulnerable
ProvideRoamingNumber Not vulnerable
Leaking of subscriber location

AnytimeInterrogation Vulnerable
ProvideSubscriberInformation to MSC Vulnerable
ProvideSubscriberLocation to MSC Not vulnerable
ProvideSubscriberInformation to SGSN Not vulnerable
ProvideSubscriberLocation to SGSN Not vulnerable
Payload interception
Capturing of inbound SMS messages Vulnerable
Outgoing call interception Vulnerable
Call forwarding Vulnerable
Disruption of a subscriber’s services

CancelLocation to the MSC Vulnerable
CancelLocation to the SGSN Vulnerable
Inbound call and SMS disruption by PurgeMS Vulnerable
Inbound call and SMS disruption by LU Vulnerable
Call barring by ODB Not vulnerable
Call barring by CAMEL Vulnerable
Exhaustion of roaming numbers in MSC Potentially vulnerable
CONFIDENTIAL
Toll and billing fraud

Avoidance of charges for international calls Vulnerable
by ISD
Avoidance of charges for international calls Vulnerable
by DSD
Avoidance of charges for SMS Not vulnerable
Fraudulent depletion of subscriber’s account Vulnerable
balance by CAMEL IDP
USSD Fraud Vulnerable
Wholesale SMS fraud

ForwardSM Vulnerable
MoForwardSM Vulnerable
IMSI catchers
Resolving of IMSIs by RestoreData Vulnerable
Retrieval of encryption key for over-the-air Potentially vulnerable
payload decryption
Retrieval of authentication keys for man-in- Vulnerable
the-middle attacks
CONFIDENTIAL
Vulnerability map
The following diagram shows the various attack vectors existing on the target network (in the
form of MAP messages) leading to user privacy leaks, DOS and fraud cases:
SMS
intercept
LU
Call
intercept
ISD
Serving Serving Call

MSC SGSN IP S forwarding
S
ter
s
e gi
R
ATI SRI-GPRS ISD D Avoidance
DS of charges
SendIMSI
Subscriber Subscriber IDP
processU
MSISDN IMSI Fo
SS Credit
RestoreData
MO rwa depletion
Fo rdS
rw M
ar
ATI PSI dS
M
SMS
LU L
C D eM
IS urg
fraud
P
Subscriber
location
S
DOS
CONFIDENTIAL
Leaking of IMSIs and serving MSC
In order to perform most remote attacks on a specific target knowing only the target’s phone
number (which is the most typical case), an attacker first needs to discover the IMSI of the
subscriber and, ideally, the MSC serving the subscriber (which also provides hints as to the
country in which the subscriber is currently located), without physical access to the
subscriber's SIM card or phone. Various methods can be used for this purpose.
I. SendRoutingInfoForSM
a. Abstract
One way to obtain the IMSI and serving MSC knowing only the subscriber's phone number is
to send the message SendRoutingInfoForSM, which is normally used for the delivery of
incoming SMS to the subscriber. The message is normally routed to the subscriber's
MSISDN, but can also be routed directly to the network's HLR (or by brute forcing all the
network's HLRs, if one does not know which HLR the subscriber is homed to) in order to
circumvent possible countermeasures. If unprotected, the HLR will return the IMSI of the
subscriber, and the serving MSC.
b. Findings
The network has been found to be not vulnerable to this attack on the following nodes:
MSISDN tested Prepaid/postpaid Tested node

9647717228011 Prepaid 9647701147054
9647717063017 Postpaid 9647701147054
c. Technical description of the vulnerability and test log
The target network uses a home routing platform and answers with a random IMSI,
regardless if the message is routed directly to the HLR or to the MSISDN. Furthermore, the
GT of the HLR is not disclosed.
A test with various spoofed SMSC IE did not succeed in circumventing the homerouting
platform either.
CONFIDENTIAL
II. SendRoutingInformation
a. Abstract
Another way to obtain the IMSI and possibly the serving MSC knowing only the subscriber's
phone number is to send the message SendRoutingInformation, which is normally used by a
GMSC in the home network attempting to deliver incoming calls to a subscriber. The message
is normally routed to the subscriber's MSISDN, but can also be routed directly to the
network's HLR (or all the network's HLRs by brute force, if one does not know to which HLR
the subscriber is homed) in order to circumvent possible countermeasures. The HLR normally
returns the IMSI of the subscriber and often the serving MSC.
b. Findings

9647717228011 Prepaid 96477011440010
9647717063017 Postpaid 96477011440010
The target network responds to SRI with an error message and no information is disclosed
(other than the GT of the HLR), including when the GMSC IE is spoofed and regardless of
whether the message is routed to the HLR or to the MSISDN.
III. SendRoutingInfoForLCS
A. Abstract
Another way to obtain the IMSI knowing only a subscriber's phone number is to send the
request SendRoutingInfoForLCS. The purpose of this message is to request the identity of
the node able to provide location information on the subscriber (usually a MSC). If a response
is provided, it generally also contains the IMSI of the subscriber.
The message is normally routed to the subscriber's MSISDN, but can also be routed directly
to the network's HLR (or all the network's HLRs by brute force, if one does not know to which
HLR the subscriber is homed) in order to circumvent possible countermeasures.
B. Findings
CONFIDENTIAL

9647717228011 Prepaid 96477011440010
9647717063017 Postpaid 96477011440010
The subject network does not answer to SRI-LCS whether it is routed to the subscriber’s
MSISDN or directly to a HLR, and regardless of attempts to spoof the mlcNumber IE.
IV. SendIMSI
A. Abstract
Another way to obtain the IMSI knowing only the subscriber's phone number is to send the
request SendIMSI. The purpose of this message is to request the IMSI of a subscriber from
the HLR!
HLR the subscriber is homed) in order to circumvent possible countermeasures.
B. Findings
The network has been found to be vulnerable to this attack on the following nodes:

9647717228011 Prepaid 96477011440010
9647717063017 Postpaid 96477011440010
CONFIDENTIAL
The subject network answers to a basic SendIMSI request routed to the MSISDN of the
subscriber. The response contains the IMSI of the subscriber and discloses the GT of the
network’s HLR..
Ladder diagram
TD Test platform Operator HLR
SendIMSI
ReturnResultLast
PCAP capture of the test
SendIMSI Postpaid.pcap SendIMSI Prepaid.pcap
CONFIDENTIAL
d. Suggested method of remediation
Answering to SendIMSI messages should not be required neither for roaming partners, nor
within the home network. It is recommended to disable this message altogether, either by
using a feature of the HLR, by performing filtering by operation code on the STP, or by
implementing a suitable SS7 firewall.
GSMA vulnerability category: 1

Remediation methods
STP Mobile node SS7 firewall
Yes Maybe Yes
V. SRI-GPRS
a. Abstract
SRI-GPRS is normally used by the home network to obtain the GRX IP address of the serving
SGSN of a subscriber in order to initiate a data session from the network side. This command
requires knowing the IMSI of the subscriber (obtained through one of the methods above). It
is rarely used on a typical network.
HLR the subscriber is homed) in order to circumvent possible countermeasures. Normally, the
HLR returns the IP address of the SGSN serving the subscriber.
Knowing the IP address of the SGSN serving a subscriber can allow GTP based attacks
towards the SGSN.
b. Findings

9647717228011 Prepaid 96477011440010
9647717063017 Postpaid 96477011440010
c. Technical description of the vulnerability and test result
CONFIDENTIAL
The subject network does not reply to SRI-GPRS in its basic format, regardless of whether it
is routed to the MSISDN or to the HLR. However, when sending a calling SSN of 6 instead of
the usual SSN of 150, the HLR responds to the command, regardless of the GGSNNUMBER
IE. The response discloses the GRX IP address of the serving SGSN.
Ladder diagram
SendRoutingInfoForGPRS
ReturnResultLast
SRI-GPRS Postpaid.pcap SRI-GPRS Prepaid.pcap
CONFIDENTIAL
Answering to SRI-GPRS messages originating from outside networks (roaming partners)

should not be required for any normal roaming function. It is recommended to disable this
message for roaming partners, either by using a feature of the HLR, by performing filtering by
operation code on the international signaling links in the STP, by filtering by operation code
and CgPa on the national STP or by implementing a suitable SS7 firewall.
The target network already implements some form of filtering against SRI-GPRS requests,
presumably in an STP. The filters simply need to be adjusted so that the message is blocked
regardless of source SSN. If the target network does not use SRI-GPRS internally, then the
command should be blocked by operation code, without any further criteria.

Remediation methods
Yes Maybe Yes
VI. Leaking of serving MME by RestoreData
a. Abstract
Many Diameter based attacks rely on knowing the serving MME of a subscriber, so that the
MME may be targeted via Diameter protocol for DOS attacks or to disclose a subscriber’s
location (A separate Diameter penetration tests is available to test any vulnerabilities existing
on MME addresses gathered through this method).
It is sometimes possible to get the HLR to disclose the serving MME via the SS7 message
RestoreData. This message is normally invoked by an MSC who has lost a subscriber’s
profile (for example due to a restart or maintenance) and causes the HLR to provide the full
subscriber profile. This profile sometimes includes the serving MME when the network uses
combined nodes.
The message can be routed by E214 or directly to the HLR (or by brute force, if the HLR to
which the subscriber is homed is not known).
b. Findings
CONFIDENTIAL
9647717228011 Prepaid 96477011440010

9647717063017 Postpaid 96477011440010
The target network answers to the RestoreData message and provides the subscriber’s full
current HLR profile for both the prepaid and postpaid subscribers. However none of the
InsertSubscriberData messages contain the MME currently serving the subscriber.
VII. ProvideRoamingNumber
A. Abstract
When it is not possible to query the serving MSC in a straightforward manner using one of the
above methods, it may still be possible to determine the serving MSC by performing a brute
force attack.
Such a brute force attack is not straightforward, as it requires knowledge of the subscriber’s
IMSI (which may require physical access, such as an IMSI catcher) as well as a list of the
target network’s MSCs that must be sourced via industry insiders or other methods/leaks.
By routing a ProvideSubscriberNumber message to each MSC in the network, it is possible to
determine the MSC serving the subscriber, as it will normally respond with an MSRN.
b. Findings

9647717228011 Prepaid 9647701146902
9647717063017 Postpaid 9647701147002
All MSCs on the target network reply to PRN message with an MSRN, regardless of whether
the subscriber is attached to them or not. Therefore, it is not possible to determine which
MSC is serving the subscriber by using this attack vector.
Leaking of subscriber location
CONFIDENTIAL
If a serving MSC or SGSN can be obtained using one of the methods detailed in the previous
section, one can infer the country where the subscriber is located. Typically, subscribers
roaming overseas can be subject to more privacy related attacks, even when MSCs at home
are protected, so this information may be very valuable to an attacker.
There are additional methods available to obtain a more precise location for the subscriber,
including CellID, LAC and possibly approximate GPS coordinates.
These advanced methods are used by commercial geolocation platforms or services sold
worldwide to the highest bidder by companies such as Verint or Circles.
I. AnytimeInterrogation
a. Abstract
AnytimeInterrogation is a request requiring only the subscriber's MSISDN (knowledge of the

IMSI is not required), and the answer provided by the HLR normally contains information on a
subscriber's location (Cell-ID, LAC, serving MSC). It is typically allowed only inside a home
network for purposes such as public safety or anti theft.
The request can be routed to the MSISDN of the subscriber, or directly to the HLR (or group
of HLRs, if the HLR serving the subscriber is not known).
b. Findings

9647717228011 Prepaid 96477011440010
9647717063017 Postpaid 96477011440010
CONFIDENTIAL
The HLR responds to Anytime Interrogation in its basic form, regardless of whether the
gsmSCF IE is spoofed and provides the subscriber’s location, including Cell ID and current
VLR.
Ladder diagram
AnytimeInterrogation
ReturnResultLast
ATI Postpaid.pcap ATI Prepaid.pcap
CONFIDENTIAL
Answering to ATI messages originating from outside networks (roaming partners) should not
be required for any normal roaming function. It is recommended to disable this message for
roaming partners, either by using a feature of the HLR, by performing filtering by operation
code on the international signaling links in the STP, by filtering by operation code and CgPa
on the national STP or by implementing a suitable SS7 firewall.

Remediation methods
Yes Maybe Yes
e. Subscriptions’ locations
During this test, the location information retrieved for both subscriptions is that of the following
celltower:
CONFIDENTIAL
II. ProvideSubscriberInformation to MSC
a. Abstract
ProvideSubscriberInformation is a request requiring the subscriber’s IMSI (which we obtained

previously) sent to the serving MSC (obtained previously or by brute forcing all known MSCs)
that provides information as to the subscriber's location (CellID and LAC) and sometimes the
Camel profile.
b. Findings

9647717228011 Prepaid 9647701146902
9647717063017 Postpaid 9647701147002
CONFIDENTIAL
The tested MSC on the subject network simply replies to ProvideSubscriberInformation and
returns relevant location information to the attacker, including the CellID and LAC.
Ladder diagram
TD Test platform MSC
ProvideSubscriberInformation
ReturnResultLast
PSI to MSC Postpaid.pcap PSI to MSC Prepaid.pcap
CONFIDENTIAL
In order to prevent this attack, it is necessary for the MSC to verify that the source address
(CgPa) of any PSI request matches the network that owns the subscriber. It should not be
possible for a roaming partner to obtain the location for a subscriber that is not theirs.
This type of screening may be achieved through a vendor feature in the MSC, by STP filtering
rules based on CgPa, operation code and MCC-MNC or by using a suitable SS7 firewall.
It could be easier to block the operation code entirely for roaming partners, and only leave it
accessible for nodes on the home network, however this may lead to protests from roaming
partners who have a legitimate reason to obtain the location of their subscriber in roaming.
Before blocking the operation code in its entirety, a traffic audit would be advisable, in order to
determine if the command is used by any key roaming partners that would need to be given
notice of the change.

Remediation methods
Unlikely Maybe Yes
e. Subscriptions’ locations
During this test, the location information retrieved for both subscriptions is that of the following
celltower:
CONFIDENTIAL
III. ProvideSubscriberLocation to MSC
a. Abstract
ProvideSubscriberLocation is a request requiring the subscriber’s IMSI (which we obtained as

explained in the relevant section) sent to the serving MSC (obtained previously or by brute
forcing all known MSCs) that provides precise location information for the subscriber (CellID,
LAC and often GPS coordinates with a certain level of accuracy).
b. Findings

9647717228011 Prepaid 9647701146902
9647717063017 Postpaid 9647701147002
CONFIDENTIAL
The subject network MSC rejects PSL requests with error “unauthorizedRequestingNetwork”
and does not provide subscriber location, even when attempting to spoof the mlcNumber IE
or altering SSNs.
IV. ProvideSubscriberInfo to SGSN
a. Abstract
ProvideSubscriberInfo is a request requiring the subscriber’s IMSI (which we obtained using a

method explained in the relevant section) that can also be sent to the serving SGSN
(obtained previously or by brute forcing all known MSCs) that provides information as to the
subscriber's location (CellID and LAC) and Camel profile.
b. Findings
The network has been found not vulnerable to this attack on the following nodes:

9647717228011 Prepaid SGSN 9647701145308, 9647701146708,
9647701146808, 9647701146908
9647717063017 Postpaid SGSN 9647701145308, 9647701146708,
9647701146808, 9647701146908
The identities of the subject network’s SGSNs were obtained through industry inside
information. A PSI message was routed by brute force to all SGSNs but the SGSNs did not
process the message.
V. ProvideSubscriberLocation to SGSN
a. Abstract
ProvideSubscriberLocation is a request requiring the subscriber’s IMSI (which we obtained

using one of the methods described in the relevant section) that can also be sent to the
serving SGSN (obtained previously or by brute forcing all known SGSNs) that provides
CONFIDENTIAL
precise location information for the subscriber (CellID, LAC and often GPS coordinates with a
certain level of accuracy).
b. Findings

9647717228011 Prepaid SGSN 9647701145308, 9647701146708,
9647701146808, 9647701146908
9647717063017 Postpaid SGSN 9647701145308, 9647701146708,
9647701146808, 9647701146908
The identities of the subject network’s SGSNs were obtained through industry inside
information. The message was routed by brute force to all SGSNs but the SGSNs on the
subject network did not respond to PSL messages and rejected the request.
Payload Interception
I. Capturing of inbound SMS messages
a. Abstract
If a subscriber can be registered onto a MSC controlled by an attacker, the attacker can
intercept inbound SMS messages. This is achieved by sending a UpdateLocation procedure
to the HLR hosting the subscriber. Inbound SMS messages are then delivered to the attacker
controlled MSC via the ForwardSM message.
This attack vector can be very useful for intercepting tokens to clone messaging app accounts
(Whatsapp, Signal etc), bypass two factor authentication, for example for Gmail, or to execute
fraudulent banking transactions.
This attack was used in January 2017 to perform fraudulent wire transfers from bank
accounts of German consumers.
b. Findings
CONFIDENTIAL

9647717228011 Prepaid 96477011440010
9647717063017 Postpaid 96477011440010
An UpdateLocation procedure was started towards the HLR in order to register the prepaid
subscriber onto a fake MSC under our control.
We then sent an SMS to the subscriber (out of band), and it promptly arrived on our fake
MSC.
Note that while the subscriber is attached to the fake MSC, his cellular service is disrupted,
therefore this method of SMS intercept would be highly detectable by the target subscriber
but very useful if the attacker is after a single token SMS. In real life, these attacks are usually
performed at night, while the subscriber is sleeping.
For the postpaid subscriber, roaming was not allowed. However it was possible to trick the
HLR into executing the UpdateLocation procedure by setting the VLR IE with a GT
corresponding to the target network, following which an SMS was successfully intercepted.
Ladder diagram
CONFIDENTIAL
TD Test platform Operator HLR SMSC
Update Location
InsertSubscriberData
ReturnResultLast
ReturnResultLast
ForwardSM
SMS Intercept Postpaid.pcap SMS Intercept Prepaid.pcap
Several actions are recommended to address this vulnerability:

- the HLR should not process a UpdateLocation operation without first having received a
SendAuthenticationInformation to process authentication, from the same visited network. This
will not prevent this type of attack, but will at least make it one step harder as the attacker
may be dissuaded if the HLR doesn’t reply to a straight UpdateLocation
- for subscribers that do not have roaming allowed, the HLR should not execute the
UpdateLocation procedure when the VLR IE GT is from a different network than the MSC IE
GT
CONFIDENTIAL
There is no easy way to remedy this flaw for subscribers which have roaming allowed, as it is
not possible to accurately predict when a subscriber may appear in a foreign country and
request attachment (which is what we are doing here). If a subscriber is being intercepted
while in the home country, the pattern would show UpdateLocation messages (and possibly
SendAuthenticationInformation) coming from a foreign country (that is likely to sponsor the
intercepting entity) shortly after and shortly before normal signaling activity on the home
network.
An advanced SS7 firewall will be able to monitor these patterns and detect abnormal behavior
(such as a subscriber being attached on a network thousands of miles away within minutes of
normal home signaling activity) thanks to “velocity of roaming” measurement capabilities.

Remediation methods
No Unlikely Yes
II. Outgoing call interception
a. Abstract
As shown on the TV program 60 Minutes in USA in early 2016, it is possible to use SS7
access to intercept and record subscribers’ outgoing calls remotely without any physical
access to their phone or any physical hardware (such as IMSI catchers). This is achieved by
modifying the subscriber’s profile in the service MSC using the insertSubscriberData
message, and inserting the attacker’s camel control point (gsmSCF). Then, on each call
placed by the subscriber, the attacker’s gsmSCF receives a CAMEL IDP message, to which it
replies with a CAMEL Connect message to redirect the call through a media gateway capable
of transiting the call to its intended destination, while recording the audio.
This attack can affect both prepaid subscribers, and postpaid subscribers who normally do
not use CAMEL.
b. Findings

9647717228011 Prepaid 9647701146902
9647717063017 Postpaid 9647701146902
CONFIDENTIAL
For each subscription, the serving MSC was located using a method described in the relevant
section. An InsertSubscriberData message was then sent to the serving MSC to insert
ourselves as the responsible gsmSCF in the CAMEL o-csi subscription.
Then, a call was made from the handset, but the call was automatically redirected to a
different number in Iraq. In a real intercept, the call would redirect through a media gateway
that would terminate it to its originally intended destination and take a recording of the
conversation, without the caller or called party taking notice.
Ladder diagram
TD Test platform Operator MSC
ReturnResultLast
InitialDP
Connect
CONFIDENTIAL
Call intercept Postpaid.pcap Call intercept Prepaid.pcap
(CgPa) of any ISD request matches the network that owns the subscriber. It should not be
possible for a roaming partner to modify the profile of a subscriber that is not theirs.

Remediation methods
Unlikely Maybe Yes
III. Call forwarding
a. Abstract
By unconditionally forwarding a subscriber to a third party number in the HLR, it is possible to

intercept or answer their incoming calls. This is useful for example to commit bank fraud, if the
access to a banking system or a request for a wire transfer requires the receipt of a security
token via a phone call placed by the bank to one’s phone number. The same procedure can
be used to clone messaging app accounts such as Whatsapp or Signal. By diverting the call
to another phone under the attacker’s control, the attacker can answer / receive the calls
containing the security tokens.
b. Findings

9647717063017 Postpaid 96477011440010
CONFIDENTIAL
9647717228011 Postpaid 96477011440010
c. Test methodology and logs
The test scenario consisted in attempting to forward all incoming calls placed to both
subscriptions to a third party number in Iraq. For this purpose, the RegisterSS message was
sent to the HLR with the relevant information. For both subscribers, the unconditional
forwarding was acknowledged by the HLR. Then a call was placed to the subscription, and
the call was promptly forwarded to the third party number.
Ladder diagram
registerSS
ReturnResultLast
Forwarding Postpaid.pcap Forwarding Prepaid.pcap
CONFIDENTIAL
In order to prevent this attack, it is necessary for the HLR to verify that the source address
(CgPa) of a RegisterSS message received on behalf of a subscriber matches the network
where the subscriber is currently believed to be attached. This prevents attackers from using
third party global titles to fraudulently set unconditional call forwarding requests.
This type of screening may be achieved through a vendor feature in the HLR or with a
suitable SS7 firewall that is aware of the current location of each subscriber.
It would however be possible to circumvent the above check by first registering the subscriber
on a fake VLR, and originating the IDP from the same GT as the fake VLR. To prevent this
type of advanced attack, a firewall with roaming velocity checks is required.

Remediation methods
No Unlikely Yes
Disruption of a subscriber’s services
An attacker can disrupt services for a specific subscriber as a retribution or blackmail, or for a
large number of subscribers as blackmail to the operator, for political reasons or during
wartime, using one of the following methods:
I. CancelLocation to the MSC
a. Abstract
When the location of a subscriber is canceled in the serving MSC (determined using one of
the methods in the sections above, or by brute force), the subscriber can no longer receive
incoming calls or SMS. The subscriber’s phone will not notice this and everything will look
normal on the phone. Only when the subscriber tries to place an outbound call, or after some
internal timer (usually of several hours or days) expires, the phone will re-register. Therefore,
canceling the location of a subscriber could be used as a denial of service attack, and if done
in large scale and repeatedly, could be disastrous for the operator.
b. Findings
CONFIDENTIAL

9647717228011 Prepaid 9647701146902
9647717063017 Postpaid 9647701146902
A CancelLocation message was sent to the MSC serving the subscriber which was
determined using one of the methods shown previously. A call was then placed to the
subscriber’s phone which didn’t get delivered to the ME.
Ladder diagram
cancelLocation
ReturnResultLast
CONFIDENTIAL
CancelLocation to MSC Postpaid.pcap CancelLocation to MSC Prepaid.pcap
The MSC should only accept a CancelLocation message from the HLR that participated in the
original attachment procedure, or at least, from an HLR within the same network as the
subscriber IMSI, so that subscribers cannot be maliciously detached by a third party. This
behavior could be implemented by the MSC vendor or screened by a suitable state-aware
SS7 firewall.

Remediation methods
Unlikely Maybe Yes
II. CancelLocation to the SGSN
a. Abstract
When the location of a subscriber is canceled in the serving SGSN (determined using one of
the methods in the sections above, or by brute force), the subscriber can no longer receive
packet switched services. Unlike for the CS registration, most modern phones will usually
reattach to the SGSN automatically within a few seconds. Therefore, to be effective in
degrading the subscriber’s experience, the CancelLocation messages must be sent to the
SGSN at high velocity, which makes this type of attack more detectable. If properly
automated, such and attack could still impact the operator and its subscribers.
b. Findings

9647717228011 Prepaid SGSN 9647701145308
CONFIDENTIAL
Only the prepaid phone was attached to PS service, as the postpaid phone was connected to
Wifi. We sent CancelLocation to the SGSN (determined by brute force) serving the
subscription, and the phone briefly lost PS service. Because the phone is modern, it
immediately established a new PS sessions, so that the actual impact to the subscriber would
be minimal. However this attack could still be used with successive CancelLocation
messages or on a large scale to create disruption or overload the SGSN.
Also some older phones do not automatically reconnect to PS service, which would create a
loss of data connectivity for the subscriber until the phone is restarted or flight mode is
triggered.
Ladder diagram
TD Test platform Operator SGSN
cancelLocation
ReturnResultLast
CONFIDENTIAL
CancelLocation to SGSN Prepaid.pcap
The SGSN should only accept a CancelLocation message from the HLR that participated in
the original attachment procedure, or at least, from an HLR within the same network, so that
subscribers cannot be maliciously detached by a third party. This behavior could be
implemented by the SGSN vendor or screened by a suitable state-aware SS7 firewall.

Remediation methods
Unlikely Maybe Yes
III. Inbound call and SMS disruption by PurgeMS to HLR
a. Abstract
The HLR stores the subscriber’s current serving MSC and is responsible for directing
incoming calls and SMS messages to it.
The PurgeMS message, which is normally sent by an MSC to the HLR, can be used to delete
the subscriber’s location, so that the subscriber can no longer receive incoming calls or SMS.
The message can be routed via E214 or directly to the network’s HLR if it is known.
b. Findings

9647717228011 Prepaid 96477011440010
9647717063017 Postpaid 96477011440010
A PurgeMS message was sent to the HLR for each subscriber, deleting the subscriber’s
location, after which each subscription was called. The incoming calls were not delivered to
the MEs.
CONFIDENTIAL
Ladder diagram
purgeMS
ReturnResultLast
DOS by PurgeMS Postpaid.pcap DOS by PurgeMS Prepaid.pcap
The HLR should only accept the PurgeMS messages where the SCCP sender (CgPa)
matches the MSC/VLR to which the subscriber is currently registered.
This type of filtering may be available as a HLR vendor feature. Otherwise, a SS7 firewall with
state-full filtering capabilities may be required.
CONFIDENTIAL

Remediation methods
No Unlikely Yes
IV. Inbound call and SMS disruption by LocationUpdate
a. Abstract
Similarly to the previous attack, if the subscriber’s location in the HLR can be updated to an
incorrect or wrong location, then inbound calls and SMS can no longer be delivered to the
subscriber.
This can be achieved by sending an UpdateLocation message to the HLR with an inexistent
or non responsive MSC and VLR address.
b. Findings

9647717228011 Prepaid 96477011440010
9647717063017 Postpaid 96477011440010
See the inbound SMS interception scenario for an explanation of the test and remediation
options, as both scenarios rely on the same vulnerability.
V. Call barring by ODB
a. Abstract
By sending an InsertSubscriberData message to the MSC serving the subscriber (determined

using on of the methods described in the relevant section, or by brute force), it may be
possible to set call barring for the subscriber, preventing the subscriber from placing outbound
CONFIDENTIAL
calls. Such a barring would remain in effect until the next UpdateLocation operation, which
can typically take anywhere from a few hours to a few days.
Use of this technique on a large scale across an operator’s subscriber base could be
disastrous.
b. Findings

9647717228011 Prepaid 9647701146902
9647717063017 Postpaid 9647701146902
An InsertSubscriberData message setting operator determined barring of all calls was sent to
the MSC serving each subscriber which was determined using one of the aforementioned
methods. A call was then placed from each handset and the call was let to proceed. Either the
ODB setting is not being accepted, or it is being overridden by the CAMEL trigger procedure.
VI. Call barring by CAMEL
a. Abstract
By sending an InsertSubscriberData message to the MSC serving the subscriber (determined

using on of the methods described in the relevant section, or by brute force), it may be
possible to change the CAMEL subscription in a way that prevents the subscriber from
placing outbound calls. Such a barring would remain in effect until the next UpdateLocation
operation, which can typically take anywhere from a few hours to a few days.
Use of this technique on a large scale across an operator’s subscriber base could be
disastrous.
b. Findings

9647717228011 Prepaid 9647701146902
9647717063017 Postpaid 9647701146902
CONFIDENTIAL
An InsertSubscriberData message containing an OSCI CAMEL subscription with an invalid /

inexistant gsmSCF and a default behavior of release was sent to the MSC serving each
subscriber which was determined using one of the previously shown methods. A call was then
placed from each handset, and the call failed.
Ladder diagram
insertSubscriberData
ReturnResultLast
Camel call barring Postpaid.pcap Camel call barring Prepaid.pcap
CONFIDENTIAL

Remediation methods
Unlikely Maybe Yes
VII. Exhaustion of roaming numbers in MSC
A. Abstract
An MSC needs to temporarily assign a roaming number (MSRN) from a limited pool for each
subscriber receiving an incoming call. By requesting MSRNs in rapid succession, it could be
possible to exhaust the resources in the pool, and prevent the delivery of incoming calls to all
subscribers attached to the MSC. Such an attack could be performed on a large scale across
all MSCs in a network and cause a large scale outage.
Our test consists in requesting a single MSRN, to determine if this attack would even be
possible. We did not perform an actually denial of service attack. Such an attack could only
be tested on a lab MSC.
b. Findings
The network has been found to be potentially vulnerable to this attack on the following nodes:

9647717228011 Prepaid 9647701146902
9647717063017 Postpaid 9647701147002
The tested MSC on the subject network replies to the PRN message with an MSRN. This
provides surface for a MSRN exhaustion attack. The actual attack was not tested, in order not
to interfere with live network operations.
CONFIDENTIAL
Ladder diagram
TD Test platform MSC
ProvideRoamingNumber
ReturnResultLast
PRN Postpaid.pcap PRN Prepaid.pcap
In order to prevent this attack, a throttling mechanism needs to be put in place in order not to
issue more than a certain number of MSRNs in a specified amount of time. Allocating a limit
of MSRNs by requester is not sufficient because the CgPa could be spoofed.
This throttling feature may be available from the MSC vendor. Otherwise an advanced SS7
firewall will be required.
CONFIDENTIAL

Remediation methods
No Maybe Yes
Toll and billing fraud
I. Avoidance of charges for international calls by ISD
a. Abstract
For prepaid subscribers, the balance of a subscriber is tracked in realtime in the billing system
of the operator. This is particularly important for international calls, because there is no
postpaid relationship with the subscriber, and no ability to collect additional funds from them if
the subscriber where to make more calls than they have balance for. An attacker may be able
to disable the real time control by the billing system on a prepaid subscription, and make calls
to international premium rate numbers without being charged. If performing this type of attack
on a large number of subscriptions in an automated fashion and calling premium rate
numbers, the attacker could cause significant financial harm to the operator.
A similar attack on a postpaid subscriber could disable realtime credit control that the operator
may have in place.
b. Findings

9647717228011 Prepaid 9647701146902
The serving MSC for the prepaid subscription was located using one of the methods shown
earlier. An InsertSubscriberData message was then sent to the serving MSC to disable
CAMEL billing for voice calls (gsmSCF address was changed and default behavior on non-
response set to continue).
A call was made to USA and we confirmed that the prepaid balance of the subscriber was not
decremented.
CONFIDENTIAL
A similar method could be used for the postpaid subscriber as the target network seems to
use CAMEL for credit control of postpaid subscriptions.
Ladder diagram
insertSubscriberData
ReturnResultLast
International call fraud Prepaid ISD.pcap
CONFIDENTIAL

Remediation methods
Unlikely Maybe Yes
II. Avoidance of charges for international calls by DSD
a. Abstract
The idea behing this attack is the same as for the previous one, except that it is executed
using a different MAP message.
b. Findings

9647717228011 Prepaid 9647701146902
The serving MSC for the prepaid subscription was located using one of the methods shown
previously. A DeleteSubscriberData message was then sent to the serving MSC to disable
CAMEL billing for voice calls (Camel subscription was withdrawn).
A call was made to USA and we confirmed that the prepaid balance of the subscriber was not
decremented.
A similar method could be used for the postpaid subscriber as the target network seems to
use CAMEL for credit control of postpaid subscriptions.
Ladder diagram
CONFIDENTIAL
deleteSubscriberData
ReturnResultLast
International call fraud Prepaid DSD.pcap
Similarly to the previous attack, it is necessary for the MSC to verify that the source address
(CgPa) of any DSD request matches the network that owns the subscriber in order to prevent
this attack. It should not be possible for a roaming partner to modify the profile of a subscriber
that is not theirs.
CONFIDENTIAL

Remediation methods
Unlikely Maybe Yes
III. Avoidance of charges for SMS
a. Abstract
There are SMSCs connected to the SS7 network that are unprotected, and will process SMS
messages from any subscriber without any billing or screening. The GTs for such SMSCs are
sometimes published online and can be found if a fraudster knows what he is looking for.
By inserting such a “open” SMSC GT into the SMSC field of the phone, the fraudster may be
able to send out free SMS messages, if the operator’s MSCs are not screening for this type of
behavior.
b. Findings

9647717228011 Prepaid
9647717063017 Postpaid
c. Test methodology and logs
In order to test for this vulnerability, we replaced the SMSC GT in each phone by the GT of
our test platform, and originated an SMS from each phone. In both cases, the SMS MO
signaling message was not delivered to us, but the SMS was routed through the normal
SMSC of the network with normal billing being presumably applied. The network seems to be
catching MO messages originating from the phone regardless of the destination GT
configured in the phones, which is good.
IV. Fraudulent depletion of subscriber’s account balance by

CAMEL IDP
a. Abstract
CONFIDENTIAL
The realtime records in the operator’s billing system contain the current balance of each
prepaid subscription, possibly millions of them. In many countries, these credit balances have
become a currency and are being sent back and forth between subscribers to pay for
commodities.
By sending fraudulent information to the billing system of the operator, an attacker can
deplete the credit balance of one or several subscribers as a retribution against the subscriber
or the operator. If such an attack was done on a large scale in a coordinated fashion, it could
be disastrous for the reputation of an operator and even cause civil unrest in an economy that
relies on prepaid credit as a currency.
b. Findings

9647717228011 Prepaid 9647701146968
c. Test logs and methodology
The gsmSCF number was learned through the call intercept test or by sending a
RestoreData. Then an IDP was sent to the gsmSCF on behalf of the prepaid subscriber, for a
call that the subscriber didn’t actually place. The gsmSCF processed the call request and
after various messages being exchanged, the call was successfully billed and the prepaid
subscriber’s balance was depleted.
Ladder diagram
CONFIDENTIAL
TD Test platform Operator gsmSCF
initialDP
...
...
ReturnResultLast
Depletion of credit by IDP Prepaid.pcap
In order to prevent this attack, it is necessary for the gsmSCF to only process IDP messages
originating from the current location of the subscriber. Such a location check may be available
as a feature within the gsmSCF, otherwise an advanced SS7 firewall would be required to
ensure that this check is performed prior to executing the IDP message.
CONFIDENTIAL

Remediation methods
No Unlikely Yes
USSD fraud
a. Abstract
USSD services are used for various purposes, including the ability for customers to recharge
their accounts or for banking purposes including money transfer. Using certain techniques, it
is possible for an attacker to establish a USSD session with the USSD gateway remotely and
impersonate the subscriber’s phone, which can lead to the fraudulent use of any services
available on the USSD gateway.
b. Findings

9647717228011 Prepaid 96477011440010
We generated a USSD command to shortcode *123 to transfer balance from the prepaid
subscription to a third party prepaid subscription via SS7, impersonating the subscriber. The
credit was transferred out successfully.
Besides allowing attackers to consume services free of charge by stealing other subscribers’
credits, such an attack, performed on a large scale across the entire subscriber base could be
disastrous for the target network.
Ladder diagram
CONFIDENTIAL
processUnstructuredSS
UnstructuredSSRequest
ReturnResultLast
...
ReturnResultLast
Stealing of credit by USSD Prepaid.pcap
In order to prevent this attack, it is necessary for the USSD Gateway to verify that the source
address (CgPa) of any USSD message received on behalf of a subscriber matches the
network where the subscriber is currently believed to be attached. This prevents attackers
from using third party global titles to fraudulently establish USSD sessions.
This type of screening may be achieved through a vendor feature in the USSD Gateway or
with a suitable SS7 firewall that is aware of the current location of each subscriber.
CONFIDENTIAL

Remediation methods
No Unlikely Yes
Wholesale SMS fraud
I. ForwardSM
a. Abstract
Many networks implement SMS firewall or SMS home routing platforms to control or limit
SMS-MT messages coming in from other networks for their subscribers. The purpose of the
limitations are ether to keep out unwanted messages (for example spam related to illegal
gambling activities or political propaganda) or to ensure that each message is monetized via
an AA19 agreement. Various signaling techniques exist in order to circumvent such platforms
when they are deployed in the network, which, if exploited, can allow messaging companies
to deliver large numbers of unwanted and unpaid SMS messages to the network’s
subscribers.
b. Findings

9647717228011 Prepaid 9647701146902
9647717063017 Postpaid 9647701146902
The IMSI and serving MSC of each subscription was determined using one of the methods
shown previously. It was then possible to deliver a SMS directly to each subscription by
sending ForwardSM directly to the serving MSC, bypassing the SMS firewall located at
9647701145354. Using this method, it would be possible to terminate SMS spam or
offensive / illegal messages in large volume to the target network’s subscriber base.
CONFIDENTIAL
Ladder diagram
ForwardSM
ReturnResultLast
SMS Firewall bypass Postpaid.pcap SMS Firewall bypass Prepaid.pcap
When a SMS firewall is in place which purpose is to proxy all inbound SMS traffic, the
network must ensure that it is not possible to bypass the platform by targeting ForwardSM
directly to the serving MSC.
It is not possible to just redirect all ForwardSM messages by operation code in the STP, as
ForwardSM from roaming partners targeting their own inbound roaming subscribers must be
allowed to pass to the serving MSC directly. Therefore, a rule in the STP would have to
consider both the operation code and target IMSI range in order to force all relevant
messages through the SMS firewall platform. If such a rule cannot be created in the STP, an
advanced SS7 firewall may be required, as it is unlikely that the MSC nodes would support
this type of advanced filtering.
CONFIDENTIAL

Remediation methods
Unlikely Maybe Yes
II. MoForwardSM
a. Abstract
One popular way to terminate wholesale SMS traffic worldwide without paying for termination
charges is to send SMS messages as a spoofed MoForwardSM towards SMSCs. The
messages then look like they are originated from a mobile subscriber, and most operators
don’t perform any screening and may not have SMS firewalls looking for this type of traffic.
One of the drawbacks is that in most cases, the sender MSISDN cannot be set transparently,
so this method of delivery is mostly useful for A2P traffic such as advertising or propaganda.
However passing this type of traffic in large quantity would cause a significant financial loss to
the subject network because of the termination costs (AA19) that would have to be paid to
roaming partners.
b. Findings

9647717228011 Prepaid 9647701145510
9647717063017 Postpaid 9647701145510
A MoForwardSM message was created, looking as if it originated from one of the 2 test
subscribers, and directed to the SMSC at 9647701145510 which was determined using
industry insider information. The SMSC then processed the message and it was delivered to
its destination (in this case USA). No spoofing of CgPa was required so the target network
does not perform any location checks on the subscriber prior to accepting a MoForwardSM.
As mentioned above though, the sender number cannot be set randomly on this type of
message and always has to match the MSISDN of the abused subscription, so this method
would only be suitable to deliver wholesale A2P traffic, not P2P traffic.
CONFIDENTIAL
Ladder diagram
TD Test platform Operator SMSC
Mo-ForwardSM
ReturnResultLast
MOForwardSM Postpaid.pcap MOForwardSM Postpaid.pcap
It is typical for mobile networks to perform at least a location check prior to accepting a
MoForwardSM message, in order to ensure that the message at least appears to be
originating from the network where the subscriber is deemed to be located. This feature is
sometimes available in the SMSC, and usually available in the SMSC firewall. Since the
target network has already deployed a SMSC firewall, it should inquire with the firewall vendor
as to whether this feature is already available in the product. It may just need to be
configured.
CONFIDENTIAL
In addition the network should prevent traffic with its own CgPa prefix from entering via the
international link, in the STP, so that the location cannot be spoofed when the subscriber is
inside the home country.
This would still open up the network for spoofing in case the subscriber is roaming abroad (or
when a subscriber is attached on a false VLR and traffic is injected with a matching GT). The
only way to fully protect against this type of advanced attack would be with a SS7 firewall that
supports spoofing detection and velocity of roaming checks.
In addition, the operator should ensure that these messages are captured by its monitoring
platform, outside of billing, so as to measure and alert on abnormal levels of traffic on
subscribers, since these types of messages may evade the realtime billing system.

Remediation methods
No Unlikely Yes
IMSI catchers
IMSI catchers are physical devices with a radio. They are also called rogue or fake base
stations. They can either passively capture all radio frames in a certain area, or broadcast an
impersonated mobile network, to which the target subscriber unknowingly attaches. This can
then allows the IMSI catcher to harvest information or to record all conversations, text
messages and data traffic.
I. Resolving of IMSIs by RestoreData
a. Abstract
The most basic IMSI catchers are passively listening to the traffic on the air interface to create
lists of IMSI, for example at ports of entry such as airports. The IMSI is transmitted in clear on
the first registration of the phone to the network.
However lists of IMSIs alone are not very useful if it is not also possible to know which
subscribers these IMSIs belong to. Knowing the MSISDN matching an IMSI goes a long way
in identifying each subscriber, for example against existing persons of interest lists, or when
hunting for the IMSI of one particular target.
To resolve a subscriber’s MSISDN knowing only their IMSI, the RestoreData procedure can
be used. This procedure is sent to the HLR, which provides a copy of the full HLR profile
which includes the MSISDN provisioned to the subscription.
CONFIDENTIAL
b. Findings

9647717228011 Prepaid 96477011440010
9647717063017 Postpaid 96477011440010
The target network answers to the RestoreData message and provides the subscriber’s full
current HLR profile for both the prepaid and postpaid subscriber. The profile contains the
MSISDN registered for the subscription.
Ladder diagram
RestoreData
ReturnResultLast
ReturnResultLast
CONFIDENTIAL
Resolving IMSI Postpaid.pcap Resolving IMSI Prepaid.pcap
The network should only answer to the RestoreData message for the MSC matching the
current HLR subscription for the subscriber. Other MSCs have no valid reason for sending
this message, and the HLR should not reply to it.
This type of filtering may be available from the HLR vendor. It is unlikely that this type of
filtering can be achieved in the STP, as it requires state-full knowledge of the subscriber’s
location, so if it is not available from the HLR vendor, a recent SS7 firewall may be required to
protect against this vulnerability.

Remediation methods
No Unlikely Yes
II. Retrieval of encryption key for over-the-air payload decryption
a. Abstract
Frames transmitted over the air interface are cyphered using the Kc key with various
cyphering algorithms. The Kc is generated when the subscriber first attaches to the network,
and stored in the MSC and the subscriber’s SIM card.
When passively intercepting traffic over the air interface, the attacker needs to crack the Kc
key in order to decrypt the payload (for example a voice conversation). This is possible with
hacking software on some of the more basic algorithms (A5/1 and A5/2) but not so much on
the more recent A5/3 algorithm, or at least not nearly in realtime.
However it may be possible for the attacker to simply exfiltrate the current Kc from the
network using SS7, if left unprotected, which allows the IMSI catcher to decypher all payload
in realtime!
b. Findings
CONFIDENTIAL
The network has been found to be potentially vulnerable to this attack on the following nodes:

Prepaid 9647701146902
Postpaid 9647701147002
The KC key can be obtained from the serving MSC via the message SendIdentification. The
message requires the TMSI of the subscriber which is transmitted in clear over the air
interface, and therefore easy for the attacker to get from the IMSI catcher. The TMSI is also
stored in the SIM card, but since we did not have physical access to the SIM cards, we could
not obtain it from there. Therefore we sent SendIdentification to each MSC using a mock
TMSI, to see if the MSC would provide any kind of response. Both MSC answered to the most
basic form of the message with “Unknown Subscriber”. This indicates a high likelyhood that
the MSC would provide the KC for a query sent with a valid TMSI.
Ladder diagram
sendIdentification
ReturnResultLast
CONFIDENTIAL
Extracting KC Postpaid.pcap Extracting KC Prepaid.pcap
There is no legitimate reason for the SendIdentification message to be sent over international
signaling links as it is only required for inter-MSC handovers which do not occur across PLMN
borders. We recommend blocking the SendIdentification operation by operation code in the
international STP regardless of source or destination SSN.
A basic signaling firewall would also block this message.

Remediation methods
Yes Maybe Yes
III. Retrieval of authentication keys for man-in-the-middle attacks
a. Abstract
2G IMSI catchers are now quite common and can easily be sourced online. In order to be
effective though, the 3G network signal needs to be scrambled / disrupted, in order to
downgrade the phone to the inferior 2G signal broadcast by the IMSI catchers. Being
attached to a 2G network can be visible and unusual for a target, and may lead informed high
profile targets to suspect interception.
The challenge for a 3G IMSI catcher is the fact that in a 3G network, the phone not only
authenticates against the network, but the network also authenticates against the phone. This
is an improvement in the 3G authentication mechanism specifically to prevent the
impersonation of a network.
CONFIDENTIAL
Unfortunately, 3G IMSI catchers have recently appeared on the market. Unlike 2G IMSI
catchers, the 3G IMSI catchers require authentication against the real mobile network in order
to successfully authenticate a 3G subscriber. This is achieved by the IMSI catcher by sending
realtime SendAuthenticationInformation requests to the real HLR in the real 3G network via
SS7, in order to obtain real network authentication data and attach the subscriber.
b. Findings

9647717228011 Prepaid 96477011440010
9647717063017 Postpaid 96477011440010
The test scenario consisted in attempting to obtain authentication vectors for the subscriber
via SS7, while the subscriber was attached in the home country. The HLR replied to the
request and provided the requested authentication information.
Ladder diagram
CONFIDENTIAL
sendAuthenticationInformation
ReturnResultLast
SAI Postpaid.pcap SAI Prepaid.pcap
There is no easy way to remedy this flaw for subscribers which have roaming allowed, as it is
not possible to accurately predict when a subscriber may appear in a foreign country and
request attachment (which always begins with a SendAuthenticationInformation message).
If a subscriber is being attached onto a 3G IMSI catcher while in the home country, the
pattern would show SendAuthenticationInformation messages coming from a foreign country
(that is likely to sponsor the IMSI catcher) shortly after and shortly before normal signaling
activity on the home network.
CONFIDENTIAL
An advanced SS7 firewall with roaming velocity capabilities would be able to monitor these
patterns and detect abnormal behavior (such as a subscriber being attached on a network
thousands of miles away within minutes of normal home signaling activity).
For subscribers that do not have roaming allowed, it would be wise to disable answers to
SendAuthenticationInformation requests from foreign networks in the HLR altogether, a
feature that is not commonly available in stock HLRs. This could also be achieved by filtering
on operation code in the STP, if non roaming subscribers are located within a specific IMSI
range (for example on an MVNO sub-brand).

Remediation methods
Unlikely Unlikely Yes
CONFIDENTIAL

FD IRQ Test Report May 2017 v1.0 2017-05-20 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FD IRQ Test Report May 2017 v1.0 2017-05-20 PDF

Uploaded by

Copyright:

Available Formats

SS7 test report for IRQAC – Test date 05/08/2017 to 05/14/2017

IRQAC SS7 penetration and fraud testing report

May 20th, 2017

II. Retrieval of encryption key for over-the-air payload decryption...................................................59

Tests were directed at two test subscriptions provided by IRQAC:

The IRQAC network has been found vulnerable to the following:

Subscriber privacy vulnerabilities

Service disruption vulnerabilities

Toll and billing vulnerabilities

It is recommended for IRQAC to address these vulnerabilities as soon as possible, starting

Leaking of subscriber location

Disruption of a subscriber’s services

Toll and billing fraud

USSD Fraud Vulnerable

Wholesale SMS fraud

Serving Serving Call

Leaking of IMSIs and serving MSC

MSISDN tested Prepaid/postpaid Tested node

c. Technical description of the vulnerability and test log

MSISDN tested Prepaid/postpaid Tested node

c. Technical description of the vulnerability and test log

MSISDN tested Prepaid/postpaid Tested node

c. Technical description of the vulnerability and test log

MSISDN tested Prepaid/postpaid Tested node

c. Technical description of the vulnerability and test log

TD Test platform Operator HLR

PCAP capture of the test

SendIMSI Postpaid.pcap SendIMSI Prepaid.pcap

d. Suggested method of remediation

GSMA vulnerability category: 1

MSISDN tested Prepaid/postpaid Tested node

c. Technical description of the vulnerability and test result

TD Test platform Operator HLR

PCAP capture of the test

SRI-GPRS Postpaid.pcap SRI-GPRS Prepaid.pcap

d. Suggested method of remediation

Answering to SRI-GPRS messages originating from outside networks (roaming partners)

GSMA vulnerability category: 1

VI. Leaking of serving MME by RestoreData

MSISDN tested Prepaid/postpaid Tested node

9647717228011 Prepaid 96477011440010

c. Technical description of the vulnerability and test log

MSISDN tested Prepaid/postpaid Tested node

c. Technical description of the vulnerability and test result

Leaking of subscriber location

AnytimeInterrogation is a request requiring only the subscriber's MSISDN (knowledge of the

MSISDN tested Prepaid/postpaid Tested node

c. Technical description of the vulnerability and test result

TD Test platform Operator HLR

PCAP capture of the test

ATI Postpaid.pcap ATI Prepaid.pcap

d. Suggested method of remediation

GSMA vulnerability category: 1

II. ProvideSubscriberInformation to MSC

ProvideSubscriberInformation is a request requiring the subscriber’s IMSI (which we obtained

MSISDN tested Prepaid/postpaid Tested node

c. Technical description of the vulnerability and test result

TD Test platform MSC

PCAP capture of the test

PSI to MSC Postpaid.pcap PSI to MSC Prepaid.pcap

d. Suggested method of remediation

GSMA vulnerability category: 2

III. ProvideSubscriberLocation to MSC