GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members

Official Document FS.07 - SS7 and SIGTRAN Network Security

SS7 and SIGTRAN Network Security

Version 4.0
08 December 2017

This is a Non-binding Permanent Reference Document of the GSMA

Security Classification: Confidential - Full, Rapporteur, Associate and Affiliate

Members
Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is confidential to the
Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and
information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those permitted
under the security classification without the prior written approval of the Association.

Copyright Notice
Copyright © 2017 GSM Association

Disclaimer
The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept
any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document.
The information contained in this document may be subject to change without prior notice.

Antitrust Notice
The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy.

V4.0 Page 1 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Table of Contents
1 Introduction 5
1.1 Overview 5
1.2 Scope 5
1.3 Abbreviations 6
1.4 References 9
2 SS7 Networks: A Short Introduction 14
2.1 SS7 Network Architecture 14
2.1.1 Service Switching Point (SSP) 14
2.1.2 Service Control Point (SCP) 14
2.1.3 Signal Transfer Point (STP) 14
2.2 SS7 Protocols 15
2.3 SIGTRAN Network Architecture 18
2.3.1 Signalling Gateway (SG) 19
2.3.2 IP-enabled SCP (IP-SCP) 20
2.3.3 Other SIGTRAN Network Elements 20
2.4 SIGTRAN Protocols 21
2.4.1 SCCP User Adaptation Layer (SUA) 23
2.4.2 ISDN Q.921-User Adaptation Layer (IUA) 23
2.4.3 SS7 Message Transfer Part 3 (MTP3) User Adaptation Layer (M3UA) 23
2.4.4 Message Transfer Part 2 (MTP2) User Adaptation Layer (M2UA) 24
2.4.5 MTP Level 2 Peer Adaptation (M2PA) 25
3 SS7 Open Source Projects 27
3.1 OpenSS7 27
3.2 Libss7 & Asterix 28
3.3 Mobicents 29
3.4 Safeseven 30
3.5 SigPloit 31
4 Security Analysis Taxonomy 32
4.1 Network Attacks Taxonomy 32
4.2 Attack Effects Taxonomy 35
4.3 Attacks-Effects Mapping 36
5 SS7 Security Analysis 37
5.1 ISUP Layer 38
5.1.1 Spoofing via Automated Phone Systems 38
5.1.2 Fake Number Presentation 38
5.2 SCCP Layer 39
5.2.1 Flooding to Know Exact Network Element (NE) GTs 39
5.2.2 Network Element Impersonation 40
5.2.3 TCAP 40

V4.0 Page 2 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

5.2.4 TCAPsec 41
5.2.5 TCAP Handshake 42
5.3 MAP Layer 46
5.3.1 Retrieval of Cryptographic Material 46
5.3.2 Retrieval of the Location of a Mobile User 47
5.3.3 Retrieval of Mobile Subscriber Identity (e.g. IMSI) 48
Denial of Service (DoS) towards a Mobile Subscriber 48
5.3.4 Overload of the SS7 Network and Equipment 50
5.3.5 Fraud Towards Mobile Operators or Mobile Subscribers 51
5.3.6 Interception of User Traffic 52
5.3.7 Retrieval of Subscriber Info (Enabled Services, Service State, etc.) 53
5.3.8 Abuse of SMS Services 53
5.4 CAP Layer 57
5.5 INAP Layer 57
6 SIGTRAN Security Analysis 58
6.1 Overview 58
6.2 SIGTRAN Security Features 59
6.2.1 IP Layer 59
6.2.2 SCTP Layer 60
6.3 SIGTRAN Vulnerabilities and Attacks 61
6.3.1 Address Camping or Stealing or Squatting Attack 61
6.3.2 Association Hijacking Attack Version 1 62
6.3.3 Association Hijacking Attack Version 2 62
6.3.4 Bombing Attack or Amplification Attack 63
6.3.5 Association Redirection 63
6.3.6 SCTP Scan 63
6.3.7 User Adaptation Layers 63
6.4 Other Security Threats 64
7 Risks for Mobile Network Operators 66
8 Recommendations and Countermeasures 69
8.1 SCCP Global Title Anti-Spoofing 71
8.2 MAP Screening Policy Guidelines 71
8.2.1 Category 1 72
8.2.2 Category 2 73
8.2.3 Category 3 74
8.2.4 Filtering Considerations 75
9 Conclusions 76
Annex A SS7/SIGTRAN Network Incident Report Template 77
Annex B Further Attack Scenarios 78
B.1 [Attack Scenario Title] 78
B.2 Remove IMEI from EIR Blacklist Attack 78

V4.0 Page 3 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

B.3 Enable Barred Mobile Services 79

B.4 Redirect Incoming Calls 80
B.5 Intercepting Outgoing Calls 81
B.6 Intercepting Incoming Calls (Using MAP RegisterSS) 82
Annex C Document Management 84
C.1 Document History 84
C.2 Other Information 84

V4.0 Page 4 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

1 Introduction

1.1 Overview
Signalling System 7 (SS7) was designed and initially deployed for a closed telecommunications
community because relatively few telephone companies with well-defined network boundaries
existed. Therefore, SS7 possesses limited security capabilities, but that environment no longer
exists because of market liberalization/deregulation. Nowadays there are more telephony
providers than could have been imagined when SS7 was first designed. There is also increasing
convergence between the public switched telephone network (PSTN) and IP networks,
supported by SS7 protocol extensions such as signalling transport (SIGTRAN), which supports
SS7 capabilities over IP networks.

SS7 has relied on the concept of isolated signalling networks for much of its security but the
new and evolving scenarios change this paradigm, increasing the exposure of the mobile
networks and creating the need for additional security enforcements.

Additionally, the proliferation of open source projects focussed on SS7 might carry a public
disclosure of known or zero-day mobile network vulnerabilities and might make low-cost tools
available that can breach these networks. The open source projects released for radio access
networks (RAN) (e.g. Osmocom) have demonstrated that the walled garden approach used by
mobile network operators (MNOs) is not successful and that the mobile networks could be
exposed to new and unpredictable attacks.

1.2 Scope
This document contains:

• An analysis of the security of each SS7 and SIGTRAN stack layer. Some SS7 threats
have been treated in a limited way in some GSMA permanent reference documents
(PRDs) (e.g. IR.70 [2] and IR.71 [3] only refer to SMS SS7 frauds) but an analysis for
each layer has never been proposed;
• The security threats and vulnerabilities for SS7 and SIGTRAN identified by the analysis
aforementioned;
• A proposed taxonomy of the open source projects available;
• A description of the possible attacks which can be implemented against mobile networks
and an evaluation of the real risks raised by them;
• Proposed best practice counter measures, with guidelines for implementing a screening
policy for MAP messages.
• A SS7/SIGTRAN network incident report template

Risks pertaining to IMS and LTE networks are out of the scope of this document.

V4.0 Page 5 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

1.3 Abbreviations
Term Description
AS Application Server
ASP Application Server Process
BSC Base Station Controller
BSS Base Station Subsystem
BSSAP Base Station Subsystem Application Part
C7 Common Channel 7, name often used for SS7 in ITU communities
CAMEL Customised Applications for Mobile networks Enhanced Logic
CAP Camel Application Part
CF Call Forwarding
CIC Circuit Identification Code
CLEC Competitive Local Exchange Carrier
CLI Calling Line Information
(D)DOS Distributed Denial of Service
DNS Domain Name System
DPC Destination Point Code
eDNS External DNS
GPL General Public Licence
GPRS General Packet Radio Services
GRX GPRS Roaming Exchange
GSM Global System for Mobile Communications
GT Global Title
HLR Home Location Register
HP(L)MN Home Public (Land) Mobile Network
HTTP Hypertext Transfer Protocol
HUR High Usage Report
IAM Initial Address Message
IDP Initial Detection Point
IDS Intrusion Detection Systems
IETF Internet Engineering Task Force
IGP International Gateway Point
IGW Interworking GateWay
IMSI International Mobile Subscriber Identity
IN Intelligence Network
INAP Intelligent Network Application Protocol

V4.0 Page 6 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Term Description
IP Internet Protocol
IPSec Internet Protocol Security
IPSP IP Server Process
ISDN Integrated Services Digital Network
ISUP ISDN User Part
ITU-T International Telecommunications Union – Telecom sector
IUA ISDN Q.921-User Adaptation Layer
IVR Interactive Voice Response
M2UA MTP2 User Adaptation layer
M3UA MTP3 User Adaptation layer
M2PA MTP Level 2 Peer Adaptation
MAP Mobile Application Part
MG Media Gateway
MGC Media Gateway Controller
MGCP Media Gateway Control Protocol
MNO Mobile Network Operator
MS Mobile Station
MSC Mobile Switching Centre
MSISDN Mobile Subscriber ISDN
MSU Message Signalling Unit
MTP Message Transfer Part
MWI Message Waiting Indication
MTU Maximum Transmission Unit
NA Nature of Address
NAT Network Address Translation
NI Network Indicator
NP Numbering Plan
NRTRDE Near Real-Time Roaming Data Exchange
NS Number Series
OPC Originating Point Code
OSI Open Systems Interconnection
PBX Private Branch Exchange
PC Point Code
PLMN Public Land Mobile Network
PRD Permanent Reference Document (GSMA)

V4.0 Page 7 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Term Description
PRI Primary Rate Interface (ISDN)
PRS Premium Rate Services
PSTN Public Switched Telephone Network
RAN Radio Access Network
RANAP Radio Access Network Application Part
ROSE Remote Operation Service Element
SAD Security Association Database (TCAPSec)
SCCP Signalling Connection Control Part
SCF Service Control Function
SCMG SCCP Management
SCN Switched Circuit Network
SCP Service Control Point
SCTP Stream Control Transmission Protocol
SDP Service Data Point
SEG Security Gateway (TCAPSec)
SEP Signalling End Point
SG Signalling Gateway
SGP Signalling Gateway Process
SGSN Serving GPRS Support Node
SI Service Indicator
SIGTRAN Signalling Transport
SIO Service Information Octet
SIP Session Initiation Protocol
SK Service Key
SMS Short Message Service
SMS-C SMS Centre
SNMP Simple Network Management Protocol
SPC Signalling Point Code
SPD Security Policy Database (TCAPSec)
SS7 Signalling System Number 7
SSN SubSystem Number
SSP Service Switching Point
STP Signalling Transfer Point
SUA SCCP User Adaptation
TCAP Transaction Capabilities Application Part

V4.0 Page 8 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Term Description
TDM Time Division Multiplexing
TLS Transport Level Security
TT Translation Type
TUP Telephone User Part
UA User Adaptation
UMTS Universal Mobile Telecommunications System
UTRAN UMTS Terrestrial Radio Access Network
VLR Visitor Location Register
VMS VoiceMail Service
VoIP Voice over Internet Protocol
VPLMN Visited PLMN

1.4 References
Ref Document Link
GSMA PRD FS.11 “SS7 Interconnect Security
[1]
Monitoring Guidelines.”
GSMA PRD IR.82 “SS7 Security Network
[2]
Implementation Guidelines.”
[3] GSMA PRD IR.70 “SMS SS7 Fraud v4.0”
[4] GSMA PRD IR.71 “SMS SS7 Fraud Prevention v5.0”
GSMA PRD SG.07 “The Potential Misuse and a https://infocentre2.gsma.com
[5]
Threat Analysis of the GSM System v2.0”
GSMA PRD SG.22 “SMS Firewall Best Practices and
[6]
Policies”
[7] GSMA PRD FF09 “Introduction to SMS Fraud”, v. 2.1
Securing SS7 Telecommunications Networks.
[8] Proceedings of the 2001 IEEE Workshop on
Information Assurance and Security.
Signalling System 7 (SS7) Message Transfer Part 2 https://tools.ietf.org/html/rfc4
[9]
(MTP2) - User Peer-to-Peer Adaptation Layer (M2PA) 165

Signalling System 7 (SS7) Message Transfer Part 3 https://tools.ietf.org/html/rfc4

[10]
(MTP3) - User Adaptation Layer (M3UA) 666

Signalling System 7 (SS7) Message Transfer Part 2 https://tools.ietf.org/rfc/rfc333

[11]
(MTP2) - User Adaptation Layer 1.txt
Signalling Connection Control Part User Adaptation http://tools.ietf.org/html/rfc38
[12]
Layer (SUA) 68
[13] ITU-T Recommendation Q.1400, “Architecture http://www.itu.int/rec/T-REC-

V4.0 Page 9 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Ref Document Link

framework for the development of signalling and Q.1400/en/
OA&M protocols using OSI concepts“
ITU-T Recommendation Q.714 - Signalling http://www.itu.int/rec/T-REC-
[14]
connection control part procedures Q.714/en
http://www.sigtran.net/sigtran
[15] Introduction to SIGTRAN.
-introduction.pdf
http://www.ietf.org/rfc/rfc2719
[16] Framework Architecture for Signalling Transport.
.txt
http://www.ietf.org/rfc/rfc2960
[17] Stream Control Transmission Protocol
.txt
3GPP TS 25.413. UTRAN Iu interface Radio Access http://www.3gpp.org/ftp/Spec
[18]
Network Application Part (RANAP) signalling. s/html-info/25413.htm
3GPP TS 08.08. Mobile-services Switching Centre -
http://www.3gpp.org/ftp/Spec
[19] Base Station system (MSC-BSS) Interface Layer 3
s/html-info/0808.htm
Specification.
3GPP TS 09.02.Mobile Application Part (MAP) http://www.3gpp.org/ftp/Spec
[20]
Specification. s/html-info/0902.htm
3GPP TS 29.002.Mobile Application Part (MAP) http://www.3gpp.org/ftp/Spec
[21]
Specification (Release 12). s/html-info/29002.htm
3GPP TS 29.078. Customised Applications for Mobile
http://www.3gpp.org/ftp/Spec
[22] network Enhanced Logic (CAMEL) Phase X; CAMEL
s/html-info/29078.htm
Application Part (CAP) specification.
INAP CS1 ITU / ETSI; Q1218 (10 / 95) and ETSI 300
[23]
374 1, Sept, 1994.
[24] INAP CS2 ITU; INAP - Capability Set 2. (Q.1228)
INAP CS2 ETSI; INAP - Capability Set 2. (EN 301
[25]
140-1-v1.3.4-1999-06)
[26] OpenSS7 http://www.openss7.org
https://github.com/barryo/attil
[27] libss7
a-libss7
http://mobicents-
[28] Mobicents www.appspot.com/ss7/intro.h
tml
[29] Asterix Open Source PBX http://www.asterisk.org/
http://www.digium.com/en/pr
[30] Digium products
oducts/telephony-cards
http://code.google.com/p/mo
[31] Mobicents
bicents/
http://code.google.com/p/sctp
[32] SCTP open library
/

V4.0 Page 10 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Ref Document Link

M.Immonen SIGTRAN. Signalling over IP - a step http://people.kth.se/~maguire
closer to an all-IP network, Royal Institute of /DEGREE-PROJECT-
[33]
Technology Master of Science Thesis. Stockholm, REPORTS/050619-Mia-
Sweden 2005. IMIT/LCN 2005-14 Immonen-with-cover.pdf
RFC 3788. Security considerations for SIGTRAN http://www.ietf.org/rfc/rfc3788
[34]
protocols .txt
RFC 5062. Security Attacks Found Against the
http://www.ietf.org/rfc/rfc5062
[35] Stream Control Transmission Protocol (SCTP) and
.txt
Current Countermeasures.
http://www.ietf.org/rfc/rfc3332
[36] SS7 MTP3-User Adaptation Layer
.txt
http://www.ietf.org/rfc/rfc3331
[37] MTP Level 2 User Adaptation (M2UA)
.txt
Message Transfer Part 2 (MTP) User Peer-to-Peer http://www.ietf.org/rfc/rfc4165
[38]
Adaptation Layer .txt
http://www.ciscopress.com/st
L.Dryburgh, J.Hewett, Signalling System No. 7
ore/signaling-system-no.-7-
[39] (SS7/C7) - Protocol, Architecture and Services.
ss7-c7-protocol-architecture-
Published Aug 2, 2004 by Cisco Press
9781587050404.
T.Aura, PNikander, G.Camarillo. “Effects of Mobility
http://research.microsoft.com
and Multihoming on Transport-Protocol Security”. In
[40] /pubs/67320/aura-nikander-
Proceedings: IEEE Symposium on Security and
camarillo-ssp04.pdf
Privacy 2004
Authenticated Chunks for the Stream Control http://www.ietf.org/rfc/rfc4895
[41]
Transmission Protocol .txt
M. Kjaerland, “A taxonomy and comparison of
computer security incidents from the commercial and
[42]
government sectors”. Computers and Security,
25:522–538, October 2005.
C. Meyers, S. Powers, D. Faissol, “Taxonomies of
Cyber Adversaries and Attacks: a Survey of Incidents https://e-reports-
[43]
and Approaches”. Lawrence Livermore National ext.llnl.gov/pdf/379498.pdf
Laboratory. LLNL-TR-419041, April 2009
K. Kotapati, P. Liu, Y. Sun, T.F. La Porta, “A
Taxonomy of Cyber Attacks on 3G Networks”.
[44]
Intelligence and Security Informatics; Lecture Notes
in Computer Science Volume 3495, 2005, pp 631-633
http://www.dustintrammell.co
[45] D.Trammel, VoIP Attacks. CSI 2007 m/presentations/VoIP-
Attacks/img27.html
3GPP TR 23.840 Study into routeing of MT-SMs via http://www.3gpp.org/DynaRe
[46]
the HPLMN. (Release 7) port/23840.htm

V4.0 Page 11 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Ref Document Link

Wireless and Mobile Networks Security, H.Chaouchi,
[47] M.Laurent-Maknavicius. Wiley&Sons, John Wiley &
Sons, 01/mar/2013
3GPP TS 23.040 “Technical realization of the Short http://www.3gpp.org/DynaRe
[48]
Message Service (SMS)”.(Release 12) port/23040.htm
Universal Mobile Telecommunications System
http://www.etsi.org/deliver/ets
(UMTS); 3G Security; Network Domain Security
i_ts/133200_133299/133200/
[49] (NDS); Mobile Application Part (MAP) application
07.00.00_60/ts_133200v070
layer security (3GPP TS 33.200 version 7.0.0
000p.pdf
Release 7)
3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects;
http://www.quintillion.co.jp/3
[50] 3G Security; Network Domain Security (NDS);
GPP/Specs/33204-900.pdf
Transaction Capabilities Application Part (TCAP) user
security (Release 9)
[51] H. Mustafa, W. Xu, A. Sadeghi, S. Schulz.You Can http://www.cse.sc.edu/~must
Call But You Can’t Hide: Detecting Caller ID Spoofing afah/download/cid_USC_CS
Attacks. E_TR-2013-001.pdf
[52] Fraud in Short Messaging in Mobile Networks, Kari- http://www.docstoc.com/docs
Matti Puukangas / TeliaSonera 14.4.2010 /160944679/Fraud-in-Short-
Messaging-in-Mobile-
Networks---Noppa#top
[53] 3GPP TS 33.204, 3rd Generation Partnership Project; http://www.arib.or.jp/english/
Technical Specification Group Services and System html/overview/doc/STD-
Aspects; 3G Security; Network Domain Security T63V9_21/5_Appendix/Rel7/
(NDS); Transaction Capabilities Application Part 33/33204-720.pdf
(TCAP) user security (Release 7)
[54] 3GPP TS 29.204, 3rd Generation Partnership Project; http://www.3gpp.org/DynaRe
Signalling System No. 7 (SS7) security gateway; port/29204.htm
Architecture, functional description and protocol
details
[55] “SS7: Locate. Track. Manipulate.” Tobias Engel, http://events.ccc.de/congress
31C3 /2014/Fahrplan/events/6249.
html
[56] “Mobile self-defense”, Karsten Nohl, 31C3 http://events.ccc.de/congress
/2014/Fahrplan/events/6122.
html
[57] “SS7map : mapping vulnerability of the international http://events.ccc.de/congress
mobile roaming infrastructure”, Laurent Ghigonis and /2014/Fahrplan/events/6531.
Alexandre De Oliveira, 31C3 html
[58] User Adaptation (UA) Layers http://www.informit.com/librar
y/content.aspx?b=Signaling_
System_No_7&seqNum=126

V4.0 Page 12 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Ref Document Link

[59] ITU Q.771: Functional description of transaction http://www.itu.int/rec/T-REC-
capabilities Q.771
[60] ITU Q.774: Transaction capabilities procedures http://www.itu.int/rec/T-REC-
Q.774
[61] 3GPP TR 23.840.Study into routeing of MT-SMs via http://www.3gpp.org/DynaRe
the HPLMN. (Release 7) port/23840.htm
[62] P.Langlois. Telecommunications Infrastructure http://www.frhack.org/slides/
Security: SS7 Signalling Security. FRHACK 2009 FRHACK2009_Attacking-
SS7_Langlois.pdf
[63] Mobile Network Vulnerabilities from SS7. Briefing https://infocentre2.gsma.com
Paper Version 1.0
[64] TCAP ASN1 specification http://www.itu.int/ITU-
T/recommendations/rec.aspx
?rec=4079&showfl=1
[65] Philip Langlois, SCTPscan - Finding entry points to http://www.slideshare.net/p1s
SS7 Networks & Telecommunication Backbones. ec/black-hat-europe-philippe-
Black Hat 2007 langlois-sctpscan
[66] Philip Langlois, Telecom Signaling attacks on 3G and http://www.slideshare.net/PO
LTE networks, 2011 /telecom-signaling-attacks-
on-3g-and-lte-networks
[67] SS7 penetration tool https://github.com/akibsayye
d/safeseven
[68] Tunnel Vision: Malicious data interception via SS7, https://www.adaptivemobile.c
Cathal Mc Daid, 2017 om/blog/malicious-data-
interception-via-ss7
[69] Telecom Signaling Exploitation Framework - SS7, https://github.com/SigPloiter/
GTP, Diameter & SIP SigPloit/tree/master/SS7/src

V4.0 Page 13 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

2 SS7 Networks: A Short Introduction

SS7, or C7, is a global standard for telecommunications defined by the ITU-T that describes the
network architecture, configuration and message transport control protocol for public telephone
networks. Usually, the SS7 network and protocols are used for basic call setup, management,
billing and enhanced call features such as call forwarding. It also supports calling party
name/number display, three-way calling tear down, number portability, location-based services,
access to toll-free and premium services, and mobile-specific services such as roaming and
subscriber authentication.

The SS7 standard defines the signalling architecture and protocols employed for message
transport. This section describes these components in detail.

2.1 SS7 Network Architecture

SS7 separates signalling messages from the voice circuits. An SS7 network must be made up
of SS7-capable equipment from end to end in order to provide its full functionality. The network
can be made up of several link types (A, B, C, D, E and F) and three node type as illustrated in
Figure 1 and described below.

2.1.1 Service Switching Point (SSP)

The Service Switching Point is the switch that originates, terminates, or tandems calls. An SSP
sends signalling messages to other SSPs to setup, manage, and release voice circuits required
to complete a call. An SSP may also send a query message to a centralized database (an SCP)
to determine how to route a call (e.g., a toll-free 1-800/888 call in North America). An SCP
sends a response to the originating SSP containing the routing number(s) associated with the
dialled number. An alternate routing number may be used by the SSP if the primary number is
busy or the call is unanswered within a specified time. Actual call features vary from network to
network and from service to service.

2.1.2 Service Control Point (SCP)

A Service Control Point is a device which interacts with databases known as Service Data
Points (SDP) that provide the tables and information necessary to process calls and provide
advanced services such as number portability, call waiting, call forwarding and more.

2.1.3 Signal Transfer Point (STP)

A Signal Transfer Point is responsible for routing and relaying SS7 messages between
Signalling End-Points (SEPs) and other STPs. Typical SEPs include SSP and SCP. An STP
routes each incoming message to an outgoing signalling link based on routing information
contained in the SS7 message and configured within the STP. An STP may also perform global
title translation, a procedure by which the destination signalling point is determined from digits
present in the signalling message and acts as a "firewall" to screen SS7 messages exchanged
with other networks.

V4.0 Page 14 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Figure 1 - SS7 Network Architecture (from [8])

These nodes can be dedicated appliances sold by manufacturers or merely specialized

software running on legacy operating systems like Solaris, HP-UX. Each node is identified on
the network by a number known as a signalling point code (SPC) or PC for short, noting that a
node can have several SPCs.

In Figure 1 the four main line types connecting end-users to a SSP are shown:

• Analogue lines (voice trunk): analogue signalling messages are converted to digital
signalling messages by the SSP
• Integrated Services Digital line (ISDN) lines (D-Channel): digital signalling messages
very similar to SS7 packets
• Leased lines

2.2 SS7 Protocols

SS7 protocols define the procedures for operating and communicating over SS7 networks.
Figure 2 shows the SS7 stack with a comparison with the OSI model.

V4.0 Page 15 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Figure 2 - SS7 Stack (from [7])

The SS7 Message Transfer Part (MTP) layers 1-3 map respectively to physical, data link and
network layers of the Open Systems Interconnection (OSI) model. The user and application
parts of SS7 correspond to OSI layers 4-7 and these define the connection/connectionless
protocols and the remote database access protocol. In particular, MTP1 defines the physical
characteristics of the signalling link and the type of interface used in the network; MTP2 ensures
the delivery of all SS7 messages point-to-point and provides the tools necessary for reliable
transport of the messages over the network, while MTP3 routes messages to the proper
destinations using the point codes sent in the SS7 network and the configurations stored in the
routing tables.

A point code is a number that uniquely identifies a node in a SS7 network. It resembles an IP
address in the OSI model.

MTP2 and MTP3 also implement protocols for link, routing and traffic management. Link
management at MTP2 oversees the error levels at each link and sends messages advising of
links’ failed or restored status. In cooperation with link management, routing management
facilitates the re-routing of traffic around failed or congested nodes. When certain functions of a
node fail, traffic management notifies other signalling points about congestion or the failure and
only re-routes those signalling messages that are affected by the condition.

Once MTP layers ensure reliable signalling between adjacent nodes, SS7-specific protocols
define cross network communications such as call connections, disconnections and remote
function control. The ISDN User Part (ISUP) is the predominant protocol to provide connection-
oriented services in SS7 networks, to setup and teardown circuits for voice and circuit switched

V4.0 Page 16 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

data exchange. ISUP also offers advanced services like supplementary services for the circuits
carrying the transmission.

The Telephone User Part (TUP) is also able to handle call setup and teardown. It is compatible
with ISUP but it does not facilitate the support of advanced services; consequently it is being
phased out worldwide.

The Signalling Connection Control Part (SCCP) provides extended routing, flow control,
segmentation, connection-orientation, and error correction facilities in SS7 networks when
accessing network databases.

Although MTP provides routing capabilities based upon the point code, SCCP allows routing
using a point code and subsystem number or a Global Title (GT), which could be a dialled
sequence of a toll free 800-number, a calling card number or a mobile subscriber identification
number.

While a PC is used to address a particular node in the network, the Subsystem Number (SSN)
addresses a specific application available on that node. In addition, SCCP enables Global Title
translation, i.e. translation between a GT and a PC. Subsequently, SCCP implements a sort of
Network Address Translation (NAT) preventing outsiders from obtaining internal network point
codes. This function is typically carried out at the STP and can be used to control access to
network resources.

The Transaction Capabilities Application Part (TCAP) employs SCCP connectionless service to
transport non-circuit related information between signalling points.

TCAP implements standard Remote Operation Service Element (ROSE) services for
applications such as GSM Mobile Application Part (MAP) and CAMEL Application Part (CAP).
These applications provide services available from Home Location Registers (HLRs) and
Intelligent Networks (IN).

Three other protocols are layered on top of TCAP:

1. The Mobile Application Part (MAP) is a protocol which provides an application layer for
the various nodes in GSM and UMTS mobile core networks and GPRS core networks to
communicate with each other in order to provide services to mobile phone users.
2. The CAMEL Application Part (CAP) is a signalling protocol used in the Intelligent
Network (IN) architecture. CAP is a Remote Operations Service Element (ROSE) user
protocol.
3. The Intelligent Network Application Protocol (INAP) is a signalling protocol used in the
intelligent network architecture.

Running on SCCP, there are two additional layers named Radio Access Network Application
Part (RANAP [18]) and Base Station Subsystem Application Part (BSSAP, [19]). In particular,
RANAP is a protocol used on the Iu-CS interface which connects a Mobile Switching Centre
(MSC) to the UMTS Terrestrial Radio Access Network (UTRAN), while BSSAP is a protocol

V4.0 Page 17 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

which allows a MSC and a Base Station Controller (BSC) to communicate with each other using
signalling messages supported by the MTP and connection-oriented services of the SCCP.

2.3 SIGTRAN Network Architecture

SIGTRAN was developed to facilitate the transport of signaling messages via an IP network.
The SIGTRAN specifications refer to both SS7 and VoIP networks, as the concept is applied to
both architectures. The purpose of including VoIP is to identify how SS7 protocols (such as
ISUP) can terminate in a VoIP function, such as Media Gateway Controller.

For the SS7 network, the Message Transfer Part (MTP) protocols of the SS7 suite are replaced
by SIGTRAN protocols. Specifically, SIGTRAN protocols emulate the functions that are
provided by MTP2 and MTP3, as well as SCCP. This allows the higher layers of the SS7
protocol (ISUP, SCCP) to be transported over IP networks using Stream Control Transmission
Protocol (SCTP). SIGTRAN is commonly used where IP gradually replaces TDM circuits in the
signaling network.

According to Figure 3, SIGTRAN protocols define the procedures to provide reliable datagram
service and User layer Adaptation (UA) for SS7 and ISDN protocols over IP networks. This
protocol suite is made up of a new transport layer, named Stream Control Transmission
Protocol (SCTP), and a set of UA layers which mimic the services of the lower layers of SS7
and ISDN.

Figure 3 - SIGTRAN Network Architecture (from [15])

V4.0 Page 18 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

2.3.1 Signalling Gateway (SG)

The Signalling Gateway is a signalling agent that receives/sends native signalling at the edge of
the IP network (such as SS7). An SG appears to the SS7 network as an SS7 Signalling Point,
and an IP node to the IP network. The purpose of the SG is to provide the conversion between
the circuit switched and IP domains. The SG must be capable of distributing incoming SS7 data
messages to the appropriate AS.

For the Message Transfer Part 3 (MTP3) User Adaptation (M3UA) [9] and the SCCP User
Adaptation (SUA) [11] (see section 2.4 for details), the SG performs this routing based on static
or dynamic Routing Keys (see description reported hereafter).

Figure 4 shows an example of how an SG might be provisioned with Routing Key, Routing
Context, AS, and Application Server Process (ASP) information. This figure contains a pair of
SGs that also act as STPs for SS7 traffic and share the same AS database. When a SG
receives a message, it tries to match it against its database. In this example, a message arrives
for DPC 1.1.1 at SG2. This message matches AS CHICAGO, so it is forwarded to ASP1.

Figure 4 - SG SS7 Messages Routing Example (from [57])

For the MTP2 User Adaptation Layer (M2UA) and the ISDN Q.921-User Adaptation Layer (IUA)
(see section 2.4 for details), the SG uses an Interface Identifier value (i.e. a 32-bit integer value
or an ASCII string created using the physical slot and port where the SS7 link is connected to)
to determine the distribution of incoming messages. The Interface Identifier is unique between

V4.0 Page 19 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

the SG and the ASP. Unlike Routing Keys, there can be a many-to-one relationship between
Interface Identifiers and AS.

2.3.2 IP-enabled SCP (IP-SCP)

The IP-enabled SCP is a node that exists wholly within the IP network and is addressable
directly from the SS7 network.

2.3.3 Other SIGTRAN Network Elements

In a SIGTRAN network; other network elements can be deployed, as reported in [35]. These are
described below.

2.3.3.1 Application Server (AS)

This is a logical entity that serves just one specific Routing Key (1:1 relationship). Examples of
ASs are:

• A virtual switch element that handles all call processing for a unique range of PSTN
trunks, identified by an SS7 service information octet (SIO) / destination point code
(DPC) / originating point code (OPC) / circuit identification code (CIC) range.
• A virtual database element, handling all HLR transactions for a particular SS7
DPC/OPC/SCCP_SSN combination.
• An AS can contain a set of one or more unique ASPs, of which one or more is normally
actively processing traffic.

2.3.3.2 Application Server Process (ASP)

This is an (active or backup) process instance (or merely process) of an AS. Examples of ASPs
are processes of MGCs, IP SCPs, or IP HLRs. An ASP contains a Stream Control Transmission
Protocol (SCTP) endpoint and can be configured to process signalling traffic within more than
one AS. In the example shown in Figure 5, the ASP runs on a Media Gateway Controller (MGC)
platform that handles the user adaptation (UA) protocol stack. In this diagram, the MGC
represent the AS (AS1) and consists of two separate hosts, each one contains only one ASP
(i.e. ASP1 and ASP2). Depending on the MGC redundancy model (Active-Standby, Load Share,
or Broadcast), one or more of the ASPs are Active (or able to send and receive user data) for
the AS at any given time.

2.3.3.3 Routing Key

A Routing Key [35] is a unique 32-bit value that describes a set of SS7 parameters which
uniquely identify the signalling messages to be routed to a particular AS. The Routing Key has a
one-to-one relationship with an AS and its parameters cannot extend across more than a single
Signalling Point Management Cluster. This key can be any combination of the following SS7
routing information:

• Network Indicator (NI)

• Service Indicator (SI)
• Destination Point Code (DPC)

V4.0 Page 20 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• Originating Point Code (OPC)

• Subsystem number (SSN)

2.3.3.4 Signalling Gateway Process (SGP)

This is a process instance (or merely a process) of a SG (see Figure 5). It serves as an active,
backup, load-sharing, or broadcast process of a SG.

Figure 5 - ASP Example (from [57]]

2.3.3.5 IP Server Process (IPSP)

This is a process instance (or merely a process) of an IP-based application. An IPSP is
essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion.
Conceptually, an IPSP does not use the services of a SG node.

All sub-layers overlying these UA layers implement the user and application parts of the SS7.

2.4 SIGTRAN Protocols

As mentioned, SIGTRAN protocols define the procedures to provide reliable datagram service
and User layer Adaptation (UA) for SS7 and ISDN protocols over IP networks. This protocol
suite is made up of a new transport layer, named Stream Control Transmission Protocol
(SCTP), and a set of UA layers which mimic the services of the lower layers of SS7 and ISDN.

V4.0 Page 21 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Figure 6 - SIGTRAN Stack

The SIGTRAN stack is based on IP. Consequently, the first three layers of this stack correspond
exactly to layers 1-3 of the standard ISO/OSI model.

At layer 4 (Transport) the Internet Engineering Task Force (IETF) SIGTRAN Working Group
defined another protocol named SCTP overcoming the limits identified in UDP and TCP
protocols in real-time applications.

SCTP [16] is designed to transport PSTN/PLMN signalling messages and other real-time
applications over IP networks and is capable of broader applications. It is a reliable transport
protocol operating on top of a connectionless packet network such as IP and offers the following
services to its users:

• Acknowledged error-free non-duplicated transfer of user data.

• Data fragmentation to conform to discovered path Maximum Transmission Unit (MTU)
size.
• Sequenced delivery of user messages within multiple streams, with an option for order-
of-arrival and reliable delivery of individual user messages.
• Optional bundling of multiple user messages into a single SCTP packet.

V4.0 Page 22 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• Network-level fault tolerance through support of multi-homing at either or both ends of an

association.
• Low loss and delay.
• Denial of Service resilience (4-way handshake, cookie).

The design of SCTP includes appropriate congestion avoidance behavior and resistance to
flooding and masquerade attacks.

SIGTRAN implements several user adaptation layers (e.g. layers used to encapsulate several
different signalling protocols for transport over an IP network using SCTP) which include the
following [32]:

2.4.1 SCCP User Adaptation Layer (SUA)

This layer transports SCCP User Part messages (such as TCAP and RANAP) from an SS7 SG
to an IP-based signalling node or database, or between two endpoints in the same IP network.

The SUA-layer’s main tasks are to transfer SCCP user data between a SG and a MGC (client-
server model) and to map between SCCP addresses and IP addresses in the SG. However,
because of SUA´s inability to transport ISUP messages, 3GPP has chosen to use M3UA as the
standard signalling protocol in the central parts of the UMTS network while using SUA as a
complement for nodes with databases, e.g. home location registers (HLRs).

Figure 7 - Backhauling using SUA (from [32]).

2.4.2 ISDN Q.921-User Adaptation Layer (IUA)

This layer transports Q.931 messages between an ISDN SG and a MGC. IUA supports both
Primary Rate Access and Basic Rate Access lines.

2.4.3 SS7 Message Transfer Part 3 (MTP3) User Adaptation Layer (M3UA)
This layer operates on a client-server basis, just as M2UA, to provide remote connection
between two SS7 layers in a SG and a MGC (IP node). However, in this case, the SG has a
MTP3 layer (and a point code) that communicates with the ISUP/SCCP layer of the MGC, see
Figure 8. Even in this case, the nodes are not aware of each other; the MTP3 in the SG does

V4.0 Page 23 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

not know that its client (ISUP or SCCP) is remote and similarly the ISUP/SCCP layer at the
MGC does not know that the SG´s MTP3 layer is not its own and there is a logical link between
the SCCP layer in the IP node and the MTP3 layer in the SG. This is another example of
backhauling.

Figure 8 - Backhauling using M3UA (from [32])

As with M2UA, M3UA does not process signalling packets but it simply forwards them to their
destination. This means that the M3UA in the IP node does not have routing tables and does
not execute any other functions of the corresponding MTP3 layer. If M3UA is used in an all-IP
network with no pure SS7 nodes, it replaces the MTP3 layers of both the IP nodes and operates
in a point to point manner that is known as IP Signalling Point (IPSP) behaviour. M3UA is one of
the user adaptation layer protocols that removes most SS7 layers from the signalling points and
that changes the topology of the network to a more IP-like one. Thus, the system can better
make use of the more efficient IP-solutions and cheaper infrastructure. In an all-IP network,
M3UA is not restricted to the SS7 requirements of a maximum message size of 272 bytes, but
can use the larger bandwidth available via the IP network. The flexibility of M3UA and its ability
to better use the IP network and its advantages lead to it being chosen as the standard protocol
for UMTS networks.

2.4.4 Message Transfer Part 2 (MTP2) User Adaptation Layer (M2UA)

This layer transports the signalling messages between the MTP3 layer on a MGC and the MTP2
layer on a SG, e.g. in a VoIP network. Instead of being a peer-to-peer protocol like M2PA, it
operates on a client-server basis, where the MGC (IP node) is the client and the SG acts as the
server. This way the MTP3 layer on the MGC is the user of the MTP2 layer on the SG, and
neither of them is aware that they actually are remote. This phenomenon, when signalling
messages are transported over IP from the top of one SS7 layer to the bottom of another, is
called backhauling. Since the SG does not have an MTP3 layer, only the MGC has a point
code, see Figure 9.

V4.0 Page 24 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Figure 9 – Backhauling with M2UA in Two Distant Nodes (from [32]).

M2UA is frequently used when there is a low density of physical SS7 links in some particular
part of the network, or if the SGs are at a great distance from each other. In this case
backhauling can connect several of these signalling nodes to one centralized network element,
thus allowing these distant nodes to share a single SG. Since this is done over the IP network, it
is much cheaper than SS7 links, hence M2UA is a cost saving alternative. Another advantage is
the fact that each SG, that connects a remote signalling point to a MGC, does not have a point
code. The point code is assigned to the MGC, which saves many SS7 PCs that would otherwise
have been required by each SG (as when using M2PA).

2.4.5 MTP Level 2 Peer Adaptation (M2PA)

This layer transports MTP Level 3 data messages over SCTP. M2PA effectively replaces MTP
Level 2. It is an adaptation protocol between MTP3 and SCTP and works between pairs of
signalling nodes. Using M2PA makes it possible to maintain the original topology of the SS7
network, i.e. all the network elements such as Signalling Transfer Points (STPs), point codes,
etc.

Figure 10 - Two Distant SS7 Network Islands are Connected over Internet through M2PA
(from [32])

V4.0 Page 25 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

M2PA can be used between two IP-signalling nodes in an IP-network, or between a SG and an
IP-signalling node, but is most common between two SGs, e.g. to interconnect two SS7 network
islands (PSTN A and PSTN B) through an IP network. Figure 10 shows the two distant SS7
networks that are combined together via a less expensive IP network. Since the SS7 links are
dedicated to signalling traffic only, the bandwidth is continuously assigned, hence infrequently
used SS7 links inefficiently use the bandwidth which is a scarce resource. The IP solution mixes
signalling traffic with other IP traffic and therefore reduces the costs of signalling, since a link
can be shared among many users. Since both SGs have an MTP3 layer they also have a point
code and a SS7 PC must be assigned to each SG. Because of the peer-to-peer feature of
M2PA, it is possible for the MTP3-peers to communicate directly. The user of M2PA is MTP3 in
both nodes, just as MTP3 is the user of MTP2 in the SS7 stack. This means that M2PA is
actually just a replacement for MTP2 and therefore has functions similar to MTP2.

Finally, because M2PA is a peer-to-peer arrangement between two IP-based SS7 Signalling
Points, there is no need for message distribution or routing.

V4.0 Page 26 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

3 SS7 Open Source Projects

Many researchers are focusing their activities on mobile security and in particular on mobile
network security as shown by Figure 11 and open source communities have released many
open source implementations of mobile protocols. Telecommunication applications (e.g.
Osmocom, OpenBSC, OpenBTS, open source VoIP gateways, IPX PBX and so on) have been
disclosed.

Figure 11 - 2013 Research Status

The most relevant SS7 open source projects to mobile security are listed and elaborated on
below:

• OpenSS7 [25]
• libss7 [26] integrated into Asterix Project [28]
• Mobicents [27].

3.1 OpenSS7
This is an open-source development project to provide a robust and general public licence
(GPL) SS7, SIGTRAN, ISDN and VoIP stack for Linux and other UN*X operating systems. The
project was announced in the late ‘90s with the latest release dating back to 31st October 2008
and it seems it is no longer maintained.

OpenSS7 provides a largely complete implementation for the following SS7 and SIGTRAN
protocols:

V4.0 Page 27 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• MTP1-MTP3
• SCCP
• ISUP,TCAP, BSSAP
• SCTP
• M3UA, M2UA, M2PA
• SUA, IUA

For the application protocols (e.g. MAP, INAP) based on the SS7/SIGTRAN lower protocols,
several other open source initiatives can be cited (e.g. GSM/MAP HLR GPRS, OpenSwitch,
Asterix PBX).

There are no particular software requirements for installing SS7 tools: it is sufficient to use a
Linux system running a 2.4.10+ kernel and a gcc compiler with an appropriate set of kernel
module tools. On the other hand, in terms of hardware, we have to distinguish between two
cases:

1. The availability of a SS7 link: in this case SS7 link interface cards are necessary.
2. The availability of standard IP Connections: in this case a legacy network interface card
combined with SIGTRAN stack can be used. The result is that in this way SS7 MTP and
SCCP can run on a Linux box which does not have any physical SS7 links attached to it
and multiple SS7 nodes can be set up to communicate with each other using just IP
connections.

In particular, OpenSS7 provides two drivers that provide an IP-based signalling link as follows:

3. M2PA - SS7 MTP2 User Peer-to-Peer Adaptation Layer: Provides an SCTP-based

network driver for an SS7 Signalling Link.
4. SS7 over UDP Driver: Provides a UDP-based network driver for an SS7 Signalling Link.

3.2 Libss7 & Asterix

This is an open-source development project implemented by Digium developers and dates back
to 2006. It is able to provide a robust and GPL user-space library replacing the standard ISDN
primary rate interface (PRI) library and provides SS7 protocol services to applications on Linux
platforms.

The package is integrated in Asterix Open Source toolkit and consequently the source code is
available in the Asterisk source tree [28].

The solution makes use of zaptel channel driver to control incoming and outgoing calls via the
zaptel hardware.

Zaptel hardware are time division multiplexing (TDM) devices which share a common driver
suite called Zaptel/Dahdi Telephony Driver Suite. Most devices sold by Digium [29] are
members of the Zaptel/Dahdi family of hardware devices.

It supports only the ITU variant of SS7 implementing MTP2, MTP3 and ISUP protocols.

V4.0 Page 28 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Two Asterisk configuration files have to be modified to setup the SS7 connection:

5. The configuration of zaptel device in zaptel. Configuration is similar as for ISDN PRI. The
physical interface parameters (number of E1s, synchronization, framing and coding,
etc.), and the channels used for user traffic and signalling shall be defined.
6. The configuration file zapata.conf where the signalling type, SS7 variant, number of
linksets, point codes (OPC, DPC) and traffic and signalling channels shall be defined.

Asterisk supports a wide range of video and Voice over IP protocols, including the Session
Initiation Protocol (SIP), the Media Gateway Control Protocol (MGCP), and H.323 but it does not
support SIGTRAN.

3.3 Mobicents
Mobicents [27] provides a runtime environment and comprehensive suite of tools for
development, deployment and management of services integrating voice, video and messaging
across a range of communications networks, as shown in Figure 12.

Figure 12 - Mobicents communications components

In particular, it provides an open source software solution implementing SS7 stack (MTP2,3,
ISUP, SCCP, TCAP, CAMEL, MAP protocols for a dedicated equipment) and partially SIGTRAN
with M3UA over IP and SCTP ([32], not in a multi-home scenario).

M2UA and M2PA are not yet supported because their implementation depends on community
contribution.

V4.0 Page 29 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Figure 13 - Protocols that are already implemented, in progress and planned in SS7

The Mobicents jSS7 implementation supports the following TDM equipment:

• Intel SS7 family board sold by Dialogic Boards

• Zaptel/Dahdi compatibile TDM device (e.g. Digium, Sangoma Boards)
• TeleStax SS7 Boards

3.4 Safeseven
Safe Seven [67] is an open source SS7 penetration testing tool built for SS7 assessment. It is
Java-based, runs on a standard Linux host and supports several type of SS7 attacks like:

• Subscriber privacy leaks

• Billing frauds
• Denial of service attacks
• Revenue frauds
• Identity impersonation attacks
• Intercepting incoming services
• Illegal redirects

V4.0 Page 30 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

3.5 SigPloit
SiGploit [69] is an open source penetration testing tool built to pentest and exploit vulnerabilities
in the signalling protocols used in mobile networks. SiGploit aims to cover all protocols used in
MNO interconnects i.e. SS7, GTP, Diameter and SIP for IMS and VoLTE infrastructures.

In particular, currently, SiGploit supports SS7 attacks like:

• Location tracking
• Call and SMS interception
• Billing frauds

V4.0 Page 31 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Membe
Official Document FS.07 - SS7 and SIGTRAN Network Security

4 Security Analysis Taxonomy

4.1 Network Attacks Taxonomy

A taxonomy of network attacks is featured in Table 1. A high level description of the attack types is given together with high level
indications of the possible countermeasures which can be adopted to block them or minimize their effects.

This taxonomy is primarily inspired by several works available in published literature and in particular [42], [43] and [44] but it has
been integrated with some attack types strictly related to SS7/SIGTRAN networks.

Attack Type Ref. Description Countermeasure

Passive PI Passive eavesdropping aiming to intercept call and SMS or to sniff traffic for IPSec for SIGTRAN, MAP screening
interception / capturing sensitive information such as authentication data. policies, stricter routing based on
Eavesdropping The captured information can be used later to carry out other types of whitelist of IP origination/destination,
attack/fraud. CgPA/CdPA GT, SSN, and MAP
operation code, SS7 Firewalling.
Man-in-the-Middle/ MITM Active eavesdropping in which the attacker makes independent connections Strong mutual authentication of the
Active Attacks with the victims and relays messages between them, making them believe that peers, IPSec for SIGTRAN, MAP
they are talking directly to each other when in fact the entire conversation is screening policies.
controlled by the attacker. The result of this type of attack is that the attacker is
able to intercept all messages going between the two victims and to modify the
conversation (e.g. by injecting/changing messages).
(Distributed) Denial (D)DoS Malicious attempt to make, temporarily or indefinitely, a service unavailable to Anti-DoS, IP Firewall, stricter routing
of Service its intended users, for example, by overwhelming it in such a way that based on whitelist of IP
messages cannot be processed or they are processed extremely slowly or origination/destination, CgPA/CdPA
disconnecting users so that they are unable to make or receive calls. GT, SSN, and MAP operation code
IDS, MAP screening policies.
Replay Attacks RA Attack based on the retransmission or delay of valid data. This is carried out Timestamps or sequence numbers.
either by the originator or by an adversary who intercepts the data and
retransmits it, possibly as part of a masquerade attack by IP packet
substitution.
Spoofing SP Malicious attempt to impersonate another device or user in order to, for IDS, Anti-spoofing policies, SS7

V4.0 Page 32 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Membe
Official Document FS.07 - SS7 and SIGTRAN Network Security

Attack Type Ref. Description Countermeasure

example, launch attacks against other network hosts or to steal data or to Firewalling, IPSec for SIGTRAN, MAP
bypass access controls. There are several different types of spoofing attacks screening policies
that malicious parties can use to accomplish this. Some of the most common
methods include IP address spoofing attacks, ARP spoofing attacks, and DNS
server spoofing attacks. In SS7 networks a common attack is SCCP address
spoofing.
Insider Attacks IA Malicious attempt carried out by an intruder which is someone who has been Access policies
entrusted by the company, has also a knowledge of the network architecture
and has been authorized to access to the network resources and sensitive
data.
Many insider attacks are detectable if the proper logging mechanisms have
been defined and are appropriately segregated and secured from the
production systems.
Exploit Attacks EA An exploit is a piece of software, a chunk of data or sequence of commands Software Hardening, Patching
that takes advantage of a bug or vulnerability in order to cause unintended
behaviour to occur on software or hardware, for example to gain control of a
computer system or to allow privilege escalation and/or to carry out other
attacks like spoofing or DoS. Example of exploit attacks are buffer overflows.
Password Attacks PWDA Malicious attempt to compromise a user’s account (e.g. gaining password) and Strong password policies (e.g. rules on
use them to access the target machine using normal channels in a seemingly alphabets, on expiration period)
inconspicuous manner.
The majority of password attacks are the result of “social hacking” but
passwords can also be obtained via “brute force”, dictionary attacks.
Information IG Malicious attempt which does not carry damage, but enables the attacker to IP Firewalling, SS7 Firewalling, IDS, IP
Gathering gather information. Access control policies, MAP
Protocol Scanning Attack is one of the most popular information gathering screening policies, topology hiding
techniques used to discover services they can break into. functionality.
Essentially, this attack consists of sending a message to each port of a specific
protocol e.g. TCP, UDP or SCTP. The kind of response received indicates
whether the port is used and can therefore be probed further for weakness.
In SS7 networks scanning refers to GT scanning, i.e. sending SMS Mobile

V4.0 Page 33 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Membe
Official Document FS.07 - SS7 and SIGTRAN Network Security

Attack Type Ref. Description Countermeasure

Originated to all Global Title address from one mobile operator in order to find
unsecured SMS-C (SMS-C that are not validate the A-party). The discovered
GTs can be used to carry out other attacks like SMS spoofing/faking.
Faking FAK Faking occurs when SMS SCCP or MAP addresses are manipulated (SMSC SMS Firewalling, Message Integrity,
Global Title, or A_MSISDN). MAP screening policies, address
matching of different layers, IPSec for
SIGTRAN
Physical Attacks PHA Attacks based on damaging the physical components of a network equipment Physical protections, access control
or system. mechanisms
Misconfiguration MIS An attacker can use a configuration flaw within a particular application to gain Configuration hardening, SS7
access to a network or personal computer to cause a variety of attacks, e.g. Firewalling, MAP screening policies.
settings that are improperly configured, usually default settings, are an easy
target for an attacker to exploit.
Routing Attacks ROA Attacks based on re-route legitimate signalling packets to malicious nodes. SS7 Firewalling, MAP screening
policies, Message Authentication and
Integrity.
Database Attacks DA Attacks aiming to compromise database and stored data (e.g. Access Control Policy, System
subscriber/customer profile). Hardening and Patching, MAP
screening policy, SS7 Firewalling.
SMS Flooding/ SPA/FL Unsolicited flooding/spam SMS received directly by the subscriber, which may SMS Firewalling, MAP screening
Spamming be either valid or fraudulent. policies.
Tracking TRACK To track subscribers by locating them down e.g. to the individual mobile cell Home Routing, SMS Firewalling, MAP
and without seeking permission from the network operators from which the screening policy, SS7 Firewalling.
information are extracted.

Table 1 - Network Attack Taxonomy

V4.0 Page 34 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Membe
Official Document FS.07 - SS7 and SIGTRAN Network Security

4.2 Attack Effects Taxonomy

An attack can have impact on sensitive information or can cause services abuse or affect resources availability.

A proposed taxonomy of possible effects of cyber-attacks is featured in Table 2. This taxonomy is primarily inspired by several works
available in the literature and in particular [42], but it has been integrated with some attack types strictly related to SS7/SIGTRAN
networks.

Attack Results Ref. Description

Call Service Abuse CSA Abuse voice call services (e.g. to make voice calls for free, without paying any bill to the MNO).
SMS Service Abuse SSA Abuse SMS Service (e.g. to send SMS for free, without paying a bill to the MNO).
Data Service Charging
DSCB Make data traffic for free, without paying a bill to the MNO.
Bypass
Other Value Added Free usage of high value added services (e.g. high value services barred by a MNO or premium services
OVASA
Service Abuse without paying a bill to the MNO).
Service Unavailability SU One or more services can be unavailable.
A disclosure of customer’s information, e.g. IMSI, MSISDN, name, surname, address, location, credits, rate
Customer Data
CDD plan, profile, usually providing an attacker with a view of information they would normally not have access to.
Disclosure
This unauthorized disclosure can lead to other compromises.
A disclosure of traffic data details (e.g. CDR, SMS content, voice data, IP data). This unauthorized disclosure
Traffic Data Disclosure TDD
can lead to other compromises.

Impersonation IMP Pretending to be someone else by assuming that identity (e.g. MNO or a customer impersonation).

A manipulation/modification of customer’s information, e.g. IMSI, MSISDN, name, surname, address,

Customer Data
CDM location, credits, rate plan, profile, usually providing an attacker with a view of information they would normally
Manipulation
not have access to. This manipulation can lead to other compromises.
Traffic Data Manipulation TDM A manipulation/modification of traffic data details (e.g. CDR, SMS content, voice data, IP data).
To discover information not previously known. For example, when a scanning tool probes for Information; the
Discovery DIS
information discovered can be used to launch an attack on a particular target.

Table 2 - Attacks Effects Classification.

V4.0 Page 35 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Membe
Official Document FS.07 - SS7 and SIGTRAN Network Security

4.3 Attacks-Effects Mapping

The following table reports the relationship between the attacks listed in section 4.1 and the impacts featured in section 4.2. Of
course, the results of some attacks (e.g. Information Gathering) can be used to conduct other type of attacks causing a certain effect
on the mobile networks but Table 3 describes just the relationship between attacks which, in one single phase, cause the identified
effects (e.g. Information Gathering causes a Discovery and not the effects produced by the usage of the discovered information
involved in a second phase).

CSA OVASA CDD TDD IMP SU DSCB SSA CDM TDM DIS
PI X X X
MITM X X X X X X X
(D)DoS X
RA X X X
SP X X X X
EA X
PWDA X X
MIS X
FAK X
PHA X X X
IA X X X X X X X X X X
IG X X X X X X
ROA X X X
DA X X X X X X X X X
SPA/FL X X
TRACK X X

Table 3 - Mapping between attacks and effects

V4.0 Page 36 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

5 SS7 Security Analysis

Originally, legacy telephony networks (PSTN) provided the infrastructure for mobile
networks. This implied that the traditional SS7 stack would be extended to accommodate
mobile related protocols. Based on the SS7 stack depicted earlier in Figure 2, this security
analysis focuses on ISUP, SCCP, TCAP, MAP and CAP, as they are the most important
roaming and interworking protocols used, while other protocols (MTP, TUP, BSSAP and
RANAP) are excluded from the focus of this document and could be related more to local
core networks.

Figure 14 - SS7 Network Entry Points

Figure 14 shows the possible entry points into a SS7 network which can be used/abused to
conduct attacks against the infrastructure.

The most common method for attackers to gain access to the SS7 network is via re-sold
access to interconnect agreements with operators that do not perform sufficient due
diligence or ongoing monitoring of their interconnect partners. In theory, external attacks
(coming from outside the network) can also be carried out from ISDN connections and/or
Internet connections (such as from GPRS Roaming Exchange, or GRX) or CLEC
(Competitive Local Exchange Carrier) connections.

The following sub-sections describe the possible attacks that can be conducted on the SS7
protocols from these identified entry points.

V4.0 Page 37 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

5.1 ISUP Layer

ISUP messages contain different components including calling and called numbers, voice
channel requirements and so on (for more information please refer to [61]. Attacks can be
performed by using the calling and called numbers. Caller ID (or calling number) services
transmit the phone number and/or the name of a caller to the recipient to provide informed
consent to the recipient before answering calls. Spoofing caller ID is easy in VoIP, since
VoIP transmits both voice and control data in IP packets, and a caller can often set up any
caller ID for an outgoing call. VoIP is the most often used example of spoofed caller ID
because of the lack of authentication of the subscriber, and extends into ISUP as these calls
traverse multiple networks. The protocols that interconnect carriers, which include SS7 and
VoIP, do not contain any caller ID verification mechanisms, and a carrier will simply accept
and forward the claimed caller IDs. Thus, spoofing attacks require very little effort and could
consist of any one of the following:

5.1.1 Spoofing via Automated Phone Systems

Automated phone systems provide Interactive Voice Response (IVR) services for the
purposes of marketing activities, survey collection, etc. Some service providers (e.g. Voxeo,
Nuance Cafe) allow their subscribers to select their own caller IDs and will deliver the
selected caller IDs for their subscribers regardless of what they choose and what their
intentions may be. Because these providers connect to major telephone carriers via SS7 or
VoIP protocols, the downstream telephone carriers could be provided with spoofed caller
IDs.

5.1.2 Fake Number Presentation

Several commercial applications offer the capability to manipulate calling number displays.
Hence call receivers may be subject to fake number presentation. These attacks are
generically referred as “Fake Calling Number” in Table 4 .

Some common attack scenarios are reported below.

5.1.2.1 Spoofing via ‘Fake ID Providers’

These providers offer caller ID spoofing services. They allow their customers to claim any
caller ID by simply dialling a special phone number or by utilizing readily available apps on
smartphones (e.g. Caller ID Faker). The fake ID providers establish SS7/VoIP connections
with various telephone carriers, and act as intermediaries between attackers and victims to
relay the caller IDs specified by their customers (attackers in this case). Because the call into
the spoofing provider is actually terminated in their switch, and re-originated with the spoofed
identity, calls are often impossible to trace to determine their origin beyond that of the
spoofing provider.

5.1.2.2 Spoofing via VoIP Services

Many VoIP carriers allow their customers to specify their own caller ID and will forward the
caller ID to the recipient’s carrier without modification. An adversary can subscribe to a VoIP
carrier that allows caller ID manipulation and can either use VoIP client software (e.g. x-lite)
or a VoIP phone to claim arbitrary caller IDs.

V4.0 Page 38 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

5.1.2.3 IVR (Interactive Voice Response) and VMS (Voice Mail Service) Access
Some ISUP-triggered services like voice mail and IVRs can be tricked as they sometimes
merely use the calling number for customer authentication and service authorization and
hence customer voice messages and services can be accessed by fraudsters. Some
voicemail systems can be set up so that they grant access to stored messages without a
password, relying solely on the caller identity presented.

5.2 SCCP Layer

The SCCP layer is mainly responsible for routing, including fields like Numbering Plan (NP),
Translation Type (TT) and Nature of Address (NA).

To protect the PLMN network equipment identities from exposure to external parties, partial
GTs and other internal routing parameters may be used.In this case only the PC of the
gateway STP is used along with dialled digits.. The gateway STP will then route the
message based on the GT digits provided, but even the gateway STP does not know the
final GTT. The final GTT is provided by an STP, usually adjacent to the HLR, that provides
the SSN and other GTs as part of the final GT. This eliminates the need to make routing
disclosures at the network edge, and also eliminates a lot of provisioning requirements in the
SS7 network.

Some common attacks on SCCP are reported below.

5.2.1 Flooding to Know Exact Network Element (NE) GTs

This kind of attack, referred to as “Message Flooding” in Table 4, can overload the main
signalling point (i.e. STPs, SSPs, SCPs) and compromise its function, causing different kind
of Denial of Service (DoS) attacks.

The STP and the protocol both provide for this threat and use congestion control procedures
to prevent DoS from impacting the network. Link management within the SS7 protocol helps
control traffic at the individual link level (via MTP2) so when congestion does begin to occur,
the traffic can be managed accordingly.

Likewise, MTP3 provides traffic management and route management. Both of these
functions are defined within the SS7 protocol and are implemented at the STP to ensure
traffic can be routed around nodes that are congested, links that become congested, or
nodes that suddenly become unavailable.

At the SCCP layer, the SCCP Subsystem Management (SCMG) provides these functions at
the application layer, alerting the downstream nodes of congestion issues at the application
level. For example, should a HLR begin to become congested, the SCMG would take
measures to throttle lower priority traffic to prevent overload of the HLR.

This makes it highly unlikely that a DoS attack on the SS7 network will carry much impact,
given the task of the STP and the protocol itself. Nonetheless, it is something service
providers must be aware of and plan accordingly for as a precaution.

V4.0 Page 39 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

5.2.2 Network Element Impersonation

A network element impersonation (e.g. STP) can be performed spoofing a Global Title of a
trusted mobile network operator and a SSN of legitimate equipment. Since SS7 incorporates
weak authentication procedures, anyone capable of generating SS7 messages and
introducing them into a network, can perform different kinds of attacks. For example, a STP
impersonation is a serious threat as a fake STP could, generate ad hoc SCCP messages
thus causing call signalling to be misdirected. These types of attacks are referred to as “NE
Impersonation” in Table 4.

At TCAP layer there are three different protocols:

• Transaction Capabilities Application Part (TCAP) protocol defined by ITU-T

recommendations Q.771 [58] or ANSI T1.114 to facilitate multiple concurrent dialogs
between the same sub-systems on the same machines, using Transaction IDs to
differentiate these.
• Transaction Capabilities Application Part User Security (TCAPSec) defined by 3GPP
[52] and [53] consists of a complete set of enhancements and extensions to facilitate
security protection for the TCAP protocol and it covers transport security in the TCAP
protocol itself and the security management procedures.
• TCAPHandshake is a protocol defined by 3GPP [52]. It can be used by SMS
Gateway/Interworking MSC operator and the serving node (MSC or SGSN) operator
to address SMS fraud for messages exchanged between their networks.

5.2.3 TCAP
TCAP is a protocol introduced to facilitate multiple concurrent dialogs between the same
sub-systems on the same machines, using Transaction IDs to differentiate these. It
transports MAP messages, used, for example, for SMS delivery.

Some common attacks on TCAP are reported below.

5.2.3.1 TCAP Begin Scan

TCAP Begin scan is normally used to retrieve all the open SubSystems Numbers that are
available on a GT from interconnection points.

Using the information gathered from this scanning, an attacker can perform other types of
attacks, for example denial of service, network element impersonation, fraud, abuse to
obtaining information about customers or internal infrastructure. These types of attacks are
referred to as TCAP Scan in Table 4.

5.2.3.2 TCAP Traffic Injection

A bad implementation of the TCAP network stack can generate not random or guessable
TCAP transaction identifiers (ID).

In normal call flows, TCAP ID is an integer value used to identify a TCAP transaction and it
is generated by the sender when sending a request, and receiver reuses the same ID when
replying. This allows matching of requests and answers.

There are 2 types of TCAP transaction identifiers:

V4.0 Page 40 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

7. Originating TCAP ID (OTID)

8. Destination TCAP ID (DTID)

Multiple types of TCAP messages exist, each with a different effect on the TCAP session:

• TCAP Begin: Open a new transaction.

• TCAP Continue: Use an existing transaction and keep it open.
• TCAP End: Terminate gracefully an existing transaction.
• TCAP Abort: Terminate a transaction in case of error.

A vulnerable network element generates non random OTID and an attacker can predict the
current ID or the next one and injects TCAP traffic through the existing session.

The impact is either a loss of integrity due to malicious MAP injections on top of TCAP
sessions or a Denial of Service when aborting an existing TCAP.

These types of attacks are referred to as TCAP Traffic Injection in Table 4.

5.2.3.3 TCAP Application Context Scan

TCAP application contexts (AC) scan is normally used to retrieve the supported network
function and version from alive Global Titles responding with a specific SubSystem Number
(e.g. Control of CAP / CAMEL for SSN 146, GSM Service Control Function for SSN 147)
from interconnection points. Depending on SSN, the risk can vary.

Some SSN (e.g. 1, 4, 6, 7, 146, 147) should be opened only for authorized peers as they
represent dangerous entry points to the Signaling Network applications.

Using the information gathered from this scanning, an attacker can perform other types of
attacks, for example denial of service, network element impersonation, fraud, abuse to
obtaining information about customers or internal infrastructure.

These types of attacks are referred to as TCAP Scan in Table 4.

5.2.4 TCAPsec
TCAPSec consists of a complete set of enhancements and extensions to facilitate security
protection for the TCAP protocol and it covers transport security in the TCAP protocol itself
and the security management procedures [52] and [53]. In particular, it was introduced to
ensure:

• Data integrity: is the property that data has not been altered in an unauthorized
manner
• Data origin authentication: is the corroboration that the source of data received is as
claimed.
• Anti-replay protection: is a special case of integrity protection. Its main service is to
protect against replay of self-contained packets that already have a cryptographic
integrity mechanism in place.
• Confidentiality (optional): is the property that information is not made available or
disclosed to unauthorized individuals, entities or processes.

V4.0 Page 41 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

The problem with this protocol is that it requires new components to be added to the network
such as an SS7 Security Gateway (SEG) with databases for security policy (SPD) and a
security association (SAD). The SEG secures the TCAP transactions with the help of the
Policy Database.

Before protection can be applied, Security Associations (SA) need to be established

between the respective SS7-SEG. The call flow of TCAPsec in SMS is illustrated below:

Figure 15 - Call Flow of TCAPsec Use Case in SMS (from [51])

TCAPSec provides good protection against faking case (see section 5.4.9.2). It needs a lot
of interworking between operators and all operators need to use TCAPsec for it to be truly
effective.

For TCAPSec no security issues have been recorded.

5.2.5 TCAP Handshake

TCAP Handshake is defined in [52], [53]. It is based on the TCAP segmentation used in the
long messages. The first two messages are used for the authentication. The mechanism
gives protection against faking (but it requires MAP version 2 or 3). The TCAP Handshake
flow is illustrated in Figure 16.

V4.0 Page 42 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Figure 16 - TCAP Handshake

The SMS gateway/Interworking MSC operator and the serving node (MSC or SGSN)
operator may agree to use the TCAP handshake as a countermeasure against SMS fraud
for messages exchanged between their networks (for detailed message flows see [20]).

A limited level of MAP message authenticity can be achieved by using a TCAP handshake
prior to the MAP payload exchange.

Figure 17 illustrates the use of the TCAP handshake for MAP SMS transfers in case of
Mobile Terminated SMS and Mobile Originated SMS [52].

5.2.5.1 Mobile Terminated SMS

Figure 17 - MAP mt-Forward-SM Messages Using a TCAP Handshake

If the serving network receives an “mt-forward-SM” MAP message which uses the
TC_Continue to transfer the MAP payload then it is guaranteed that the SCCP calling party
address of the (empty) TC_Begin message is authentic, otherwise the first TC-continue

V4.0 Page 43 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

message would be sent to the falsified address. The correct message flow is guaranteed by
the TCAP transaction capabilities (use of Transaction ID).

Unfortunately, there are some ways in which a fraudulent SMS Gateway operator (called the
originator in bullets (a) and (b)) may try to circumvent the implicit SCCP address
authentication provided by the TCAP handshake.

a) The originator includes a falsified SMS-GMSC address as SM-RP-OA in the mt-

forward-SM payload carried by the TC-continue (third message in Figure 17)
b) The originator tries to predict the TCAP transaction ID assigned by the serving
node, which is to be used within the third message, and spoofs the third message
without waiting for the second message. This attack has to be carried out within
the right time window.

If TCAP handshake is to be used, the following measure should be taken within the network
of the serving node in order to counteract the spoofing possibilities of a malicious mt-
Forward-SM originator.

• MEAS-1: The receiving network shall verify if the received SMS-GMSC address (as
SM-RP-OA in the third message) may be used from the SCCP Calling Party Address.
Some operators use a single SMS GMSC address for a range of SCCP Calling Party
Addresses and this will need to be taken into consideration.

If TCAP handshake is to be used, at least one of the following measures should be taken
within the network of the serving node in order to counteract the spoofing possibilities of a
malicious mt-Forward-SM originator.

• MEAS-2a: The receiving node shall use mechanisms to ensure that the destination
TCAP transaction ID which needs to be used within the third message is predictable
with a probability of less than 1 / 210 for a third party knowing all previous TCAP
transaction ID values.
• MEAS-2b: The receiving network shall wait n seconds before it processes the third
message (TC-continue (mtforwardSM with payload)). This should ensure that the
TC_abort from the spoofed network is processed at the destination node earlier than
a TC_continue including a successfully guessed TCAP Transaction ID value.

The following grouping method may be used by an operator to gradually introduce the TCAP
handshake for mt-Forward-SM messages.

• Define an "operator group-1" as a trusted operator group that uses the TCAP
handshake
• Define an "operator group-2" as an untrusted operator group that does not use the
TCAP handshake.

As specified by TS 29.002 [20], this requires that the SMS Gateway operators belonging to
group-1 shall either use application context 2 or 3 for mt-Forward-SM. The management of
the two groups requires that the serving network shall implement a policy table of SCCP
Calling Party Addresses for which a TCAP handshake is required.

V4.0 Page 44 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

If the above described grouping method is used, then the following measure shall be taken
at the serving network in order to counteract the spoofing possibilities of a malicious mt-
Forward-SM originator that tries to circumvent the policy table checks.

• MEAS-3: The serving network shall verify that the SCCP Calling Party Address of a
first message with a payload (i.e. not using the TCAP handshake) is not from an
SMS-GMSC-address as SM-RP-OA that uses the TCAP handshake. The benefit
gained for operators that belong to group-1 is that spoofing of their SMS-GMSC-
addresses is practically difficult if the policy table has been administered accurately.

5.2.5.2 Mobile Originated SMS

Figure 18 - MAP mo-Forward-SM Messages Using a TCAP Handshake

If the serving network sends a mo-forward-SM MAP message which uses the TC_Continue
to transfer the MAP payload then it is guaranteed that the SCCP calling party address of the
(empty) TC_Begin message is authentic, otherwise the first TC-continue message would be
sent to the falsified address. The correct message flow is guaranteed by the TCAP
transaction capabilities (use of Transaction ID).

Unfortunately, there are some ways in which a fraudulent serving (MSC or SGSN) operator
(called the originator in bullets (a) and (b)) may try to circumvent the implicit SCCP address
authentication provided by the TCAP handshake.

c) The originator includes a falsified MSISDN as SM-RP-OA within the mo-

forward-SM payload carried by the TC-continue (third message in figure 18)
d) The originator tries to predict the TCAP transaction ID assigned by the serving
node, which is to be used within the third message, and spoofs the third
message without waiting for the second message. This attack has to be
carried out within the right time window.

If TCAP handshake is to be used, the following measure may be taken within the network of
the SMS Interworking MSC in order to counteract the spoofing possibilities of a malicious
mo-Forward-SM originator.

• MEAS-1: The receiving node (i.e. SMS interworking MSC) may query the HLR to
verify if the received SCCP Calling Party Address of the mo-forward-SM is from the

V4.0 Page 45 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

same network which is currently serving the subscriber (MSISDN contained in SM-
RP-OA in the third message).

If the TCAP handshake is to be used, then at least one of MEAS-2a and MEAS-2b
previously defined for Mobile Terminated SMS should also be applied.

The following grouping method may be used for an operator to gradually introduce the TCAP
handshake for mo-Forward-SM messages:

• Define an 'operator group-1' as a trusted operator group that uses the TCAP
handshake
• Define an 'operator group-2' as an un-trusted operator group that does not use the
TCAP handshake.

As specified by TS 29.002 [20], this requires that the MSC operators belonging to group-1
shall either use application context 2 or 3 for mo-Forward-SM. The management of the two
groups requires that the network of the SMS interworking MSC shall implement a policy
table of originating SCCP-addresses for which a TCAP handshake is required.

If the above described grouping method is used, then the following measure should be taken
at the network of the SMS interworking MSC in order to counteract the spoofing possibilities
of a malicious mo-Forward-SM originator that tries to circumvent the policy table checks.

• MEAS-3: The SMS Interworking MSC shall verify that the SCCP Calling Party
address of a first message with a payload (i.e. not using the TCAP handshake) is not
from an address that shall use the TCAP handshake.

The benefit gained for operators that belong to group-1 is that mo-Forward-SM spoofing for
their subscribers, while roaming within group-1, becomes practically very difficult if the policy
table has been administered accurately.

5.3 MAP Layer

The MAP layer represents the application part for mobile networks. It contains most user
information and is used, for example, in authentication, update location, HLR interrogation
and SMS handling.

MAPsec has been proposed to cover the aforementioned items covered by TCAPsec, and
works in a similar manner in the MAP layer. Most importantly, it may also be used to cipher
MAP messages to overcome security breaches but, practically, it is not yet used.
Consequently, several types of attacks can be performed by maliciously sending SS7 MAP
messages, mainly from an international interconnection point (for more information see [54],
[55], [56], [66] and [67]).

Some attack examples described below are based on some MAP message abuse when
proper countermeasures aren’t adopted.

5.3.1 Retrieval of Cryptographic Material

These type of attacks are generally referred in Table 4 as “Cryptographic Material
Retrieval” and can be performed by using several MAP messages, such as:

V4.0 Page 46 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• SendAuthenticationInformation (SAI):
This message is used by the VLR or SGSN to retrieve, for a given MSISDN / IMSI,
authentication information from the HLR like the Ciphering Key (Kc). If no screening
policy is implemented on the HLR to limit response to only trusted peers, then
malicious SAI can be used to retrieve authentication parameters.

• SendIdentification (SI):
This message is used between a VLR and a previous VLR (as an inter-VLR
procedure) to retrieve IMSI and authentication data for a subscriber registering afresh
in that VLR. It requires the TMSI of the queried subscriber and returns one or more
Authentication set(s).

• SendParameters (SP):
This message is used as an inter-VLR procedure to hand over control of subscriber’s
connection in a home network context. It is also specified to be used to signal to a
HLR to update location, and to exchange authentication information between a
VLR/SGSN and HLR. It requires the IMSI or TMSI of the queried subscriber and
return Authentication set(s).

5.3.2 Retrieval of the Location of a Mobile User

These type of attacks are generally referred in Table 4 as “Subscriber Location Retrieval”
and can be performed by using several MAP messages, such as:

• Any Time Interrogation (ATI):

This message was specified to be used by IN services to locate customers (VLR, Cell
id) in support of supplementary services while subscribers roam. The MAP ATI
message is ordinarily used by CAMEL/IN services to request information (e.g.
subscriber state and location) from the HLR within the home network. There are
cases where ATI is used across network boundaries, especially when service
providers use third party location based services.

• SendRoutingInfo for Location Services (SRIforLCS):

This message is used between the GMLC and the HLR to retrieve the routing
information needed for routing a location service request to the servicing VMSC or
SGSN. When sending a SS7 MAP SRI-For-LCS request towards the HLR, this one
returns the private customer's number IMSI, V-GMLC Address where the subscriber
is attached and other information.

• Provider Subscriber Location (PSL):

This message is used to request location of a customer (VLR, Cell ID) via Location
Based Services (LBS). It is sent from the GMLC to the visited MSC or SGSN at which
the subscriber is currently registered.

• SendRoutingInfo for GPRS (SRIforGPRS):

This message is used by the GGSN to request GPRS routing information from the
HLR. When sending a SS7 MAP request towards the HLR, this one returns the
SGSN address where the subscriber is attached.

V4.0 Page 47 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• SendRoutingInfo (SRI):
This message is invoked by the Gateway MSC to perform an interrogation to the HLR
in order to route a call towards the called MS. When sending a SS7 MAP SRI request
towards the HLR, this one returns the private customer's number IMSI, VMSC GT
where the subscriber is attached and other information.

• SendRoutingInfo for SMS (SRIforSMS):

This message is invoked by the Gateway MSC to interrogate the HLR in order to
route SMS to the called MS. When sending a SS7 MAP SRI for SMS request towards
the HLR, this one returns the private customer's number IMSI, the VMSC GT where
the subscriber is attached and other information.

• ProvideSubscriberInfo (PSI):
This message is used by HLR to request information (e.g. subscriber state and
location) from the VLR or SGSN at any time. One attack has an information gathering
phase where a SendRoutingInfo for SMS (SRIforSMS) is sent and the result is used
to obtain the CellID using the PSI command.

5.3.3 Retrieval of Mobile Subscriber Identity (e.g. IMSI)

These type of attacks are used to explore the network topology and gather information to
launch real attacks. They are generally referred in Table 4 as “HLR Lookup” and can be
performed by using several MAP messages, such as:

• SendIMSI:
This service is used by a VLR in order to fetch the IMSI of a subscriber in case of
some operation & maintenance procedure where subscriber data are needed in the
Visited PLMN and MSISDN is the only subscriber's identity known.

• SendRoutingInfo (SRI):
When sending a SS7 MAP SRI request towards the HLR, this one returns the private
customer's number IMSI.

• SendRoutingInfo for SMS (SRIforSMS):

When sending a SS7 MAP SRI for SMS request towards the HLR, this one returns
the private customer's number IMSI.

• SendRoutingInfo for Location Services (SRIforLCS):

When sending a SS7 MAP SRI For LCS request towards the HLR, this one returns
the private customer's number IMSI

Denial of Service (DoS) towards a Mobile Subscriber

These type of attacks are generally referred in Table 4 as “Subscriber DoS” and can be
performed by using several MAP messages, such as:

• UpdateLocation (UL):
This message is used by the VLR to update the subscriber location information stored
in the HLR (VLR number and the MSC address). When sending an UL request
towards the HLR, and the correctness and trustworthiness of this information (VLR

V4.0 Page 48 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

number and/or MSC address) are not verified, a mobile subscriber can become
unreachable.

• CancelLocation (CL):
The message is used by HLR towards the VLR/SGSN to delete a subscriber record
from the VLR/SGSN. It may be invoked automatically when a MS moves from one
VLR/SGSN area to another, to remove the subscriber record from the old
VLR/SGSN, or by the HLR operator to enforce a location updating from the
VLR/SGSN to the HLR e.g. on withdrawal of a subscription.

• InsertSubscriberData (ISD):
This message is used by an HLR to update a VLR/SGSN with certain subscriber data
(for example after changes of the subscription of one or more supplementary
services, basic services or data, or changes in the Operator Determined Barring and
so on, or by setting a compromised CAMEL node to retrieve the subscriber profile).
When sending this SS7 MAP request towards the VLR/SGSN and the trustworthiness
of the message is not verified, a mobile subscriber may become unable to use some
services. If CAMEL v.3 is used, inserting fake gsmSCF GT information would also
allow DoS of a targeted user’s mobile data connection, because the SGSN that the
subscriber is attached to contacts a compromised gsmSCF which returns back, for
example, a fake APN.

• DeleteSubscriberData (DSD):
This message is used by a HLR to remove certain subscriber data from a VLR or
SGSN if the subscription of one or more supplementary services or basic services is
withdrawn. This service is also used by a HLR to remove GPRS subscription data
from an SGSN.

• Immediate Service Termination Command (ISTCommand):

This message is used by the HLR towards the MSC (may be a Visited MSC or a
Gateway MSC) to terminate the call activities related to a subscriber.

• AnyTimeModification (ATM):
This message is used by the gsmSCF, to modify subscription information of the HLR
at any time. This service is also used by the Presence Network Agent to activate or
deactivate reporting of mobility management events (associated with a presentity)
from the VLR or SGSN. This service is also used by external Short Message
Gateway (IP-SM-GW) for updating the IP-SM-GW Number stored in the HLR. When
sending a SS7 MAP request towards the HLR and the trustworthiness of the
message is not verified, a subscriber could become unreachable.

• ProvideRoamingNumber (PRN):
This message is used between the HLR and VLR. The service is invoked by the HLR
to request a VLR to send back a roaming number to enable the HLR to instruct the
GMSC to route an incoming call to the called MS. When sending a SS7 MAP request
towards the VLR/MSC and the trustworthiness of the message is not verified, a MAP
PRN flood can prevent customers from making new calls and the targeted MSC to
receive new calls.

V4.0 Page 49 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

5.3.4 Overload of the SS7 Network and Equipment

These type of attacks are generally referred in Table 4 as “SS7 Overload” and can be
performed by using several MAP messages, such as:

• AlertServiceCentre:
This message is used when the HLR notices that the Service Centre(s) shall be
alerted in the following case: when HLR detects that a subscriber, whose MSISDN is
in the Message Waiting Data file, is active or the MS has memory available. The
message is sent by the HLR to the interworking MSC.

• RemoteUserFree:
This message is used by the HLR to report to the VLR that a subscriber B is now idle
and that a subscriber A can be notified.

• RegisterSS:
This message is used by the MSC towards the VLR and by the VLR towards the HLR
to register data related to a supplementary service. The VLR will relay the message
to the HLR. The message indicates the supplementary service which the mobile
subscriber wants to register. The service is a confirmed service.

• Reset:
This message is used by the HLR, after a restart, to indicate to a list of VLRs or
SGSNs that a failure occurred. This message is not confirmed. This message
contains the HLR number (HLR GT) and optionally the list of HLR Ids (HLR Id List). If
this list is present in the indication, the VLR or SGSN may base the retrieval of
subscribers to be restored on their IMSI: the subscribers affected by the reset are
those whose IMSI leading digits are equal to one of these numbers. If the parameter
is absent, subscribers to be restored are those for which the OriginatingEntityNumber
received at location updating time matches the equivalent parameter of the Reset
Indication.

• ForwardCheckSSIndication:
This message may be used by a HLR as an implementation option, to indicate to a
mobile subscriber that supplementary services parameters may have been altered,
e.g. due to a restart. If received from the HLR, the VLR shall forward this indication to
the MSC, which in turn forwards it to the MS. The HLR only sends this indication after
successful completion of the subscriber data retrieval from HLR to VLR that ran
embedded in a MAP_UPDATE_LOCATION procedure.

• ActivateTraceMode:
The HLR uses activateTraceMode to activate trace (subscriber tracking) mode for a
particular subscriber (IMSI); the OSS requests activateTraceMode. The VLR waits for
that particular MS to become active, at which time it sends a request to its MSC to
trace the MS.

• ProvideRoamingNumber (PRN):
When sending this SS7 MAP request towards the VLR/MSC and the trustworthiness
of the message is not verified, a C7 network overload can be caused.

V4.0 Page 50 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• InsertSubscriberData (ISD):
When sending this SS7 MAP request towards the VLR and the trustworthiness of the
message is not verified, a C7 network overload can be caused.

• ISTCommand:
When sending this SS7 MAP request towards the MSC and the trustworthiness of the
message is not verified, a C7 network overload can be caused.

• AnyTimeSubscriptionInterrogation:
This message is invoked by the gsmSCF, to request subscription information (e.g.
call forwarding supplementary service data or CSI) from the HLR at any time. When
sending this SS7 MAP request towards the HLR and the trustworthiness of the
message is not verified, a C7 network overload can be caused.

Some of these attacks have an information gathering phase to be able to launch the actual
attack. In that phase the SendRoutingInfo for SMS (SRIforSMS), for example, is used.

5.3.5 Fraud Towards Mobile Operators or Mobile Subscribers

These type of attacks are generally referred in Table 4 as “Illegitimate Charge” and can be
performed by using several MAP messages, such as:

• InsertSubscriberData
When sending this SS7 MAP request towards the VLR and the trustworthiness of the
message is not verified, the barred services of a mobile subscriber can be enabled
causing a charging avoidance for the subscriber..

• ProcessUnstructuredSSRequest:
This message is used between the MSC and the VLR and between the VLR and the
HLR to relay information in order to allow/enable unstructured supplementary service
operation. If the trustworthiness of that message is not verified, then unauthorized
modifications to pre-paid accounts or money transfer could be performed.

• AnyTimeModification:
This message can be used to modify subscription information of subscriber in the
HLR at any time. When sending this SS7 MAP request towards the HLR and the
trustworthiness of the message is not verified, the barred services of a mobile
subscriber can be enabled causing a charging avoidance for the subscriber.

• NoteSubscriberDataModified:
This service is used by the HLR to inform the gsmSCF that subscriber data have
been modified (e.g. Ext Forwarding information-for-CSE, Ext Call barring, information-
for-CSE, ODB Info, CAMEL subscription info).

• DeleteSubscriberData:
When sending this SS7 MAP request towards the VLR and the trustworthiness of the
message is not verified, charging avoidance for the subscriber can be caused.

One attack utilizes an UpdateLocation (UL) message to spoof an MSC and then launch the
actual redirection attack.

V4.0 Page 51 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

5.3.6 Interception of User Traffic

These type of attacks are generally referred in Table 4 as “Subscriber Active Interception”
and can be performed by using several MAP messages, such as:

• UpdateLocation:
When sending a SS7 MAP request towards the HLR, and if the correctness and
trustworthiness of this information (VLR number and/or MSC address) are not
verified, mobile subscriber traffic/call/SMS can be intercepted using a compromised
MSC sending or receiving further messages e.g. ProvideSubscriberInfo (PSI),
ProvideRoamingNumber (PRN) and ForwardSM-MT (FSM).

• AnyTimeModification:
This service is also used by external Short Message Gateway (IP-SM-GW) for
updating the IP-SM-GW Number stored in the HLR. When sending a SS7 MAP
request towards the HLR and the correctness and trustworthiness of this information
(e.g. IP-SM-GW number) are not verified, mobile subscriber SMS can be intercepted.

• InsertSubscriberData (ISD):
This message is used between the HLR and VLR to modify the subscriber’s profile
into the serving VLR. The insert of compromised CAMEL information (i.e. a fake
gsmSCF GT) would lead the gsmSSF to interrogate a fake gsmSCF and allow mobile
originated call interception, call redirection. If CAMEL v.3 is used, inserting a fake
gsmSCF GT would also allow interception of a targeted user’s mobile data
connection, because the SGSN that the subscriber is attached to contacts a
compromised gsmSCF which returns back a malicious APN string. The SGSN
resolves this APN to the corresponding malicious GGSN, and establishes a GTP
tunnel to the malicious GGSN. All IP user traffic is routed via this path and the
attacker would be able to monitor and (and potentially manipulate) this traffic.

User data traffic interception based on CAMEL v3 usage targets a specific user and
the satisfaction of some pre-conditions is required to make the attack successful. In
particular, user data traffic interception requires the APN resolution to be
compromised in some way. This compromised resolution of the APN could occur
when:

• The malicious APN is resolved from a trusted roaming partner DNS that has
provisioned the malicious APN (for example if it had been agreed by a roaming
partner);
• The eDNS servers used for the APN resolution have been compromised;
• The network was able to resolve it in some other way.

Of course, if the attacker is able to hack entries in the eDNS used for APN resolution,
they could directly change the record related to the victim’s APN, but in that case:

• they would need to know which APN the victim is enabled to use;
• the attack would not target just the victim but all users using the hacked APN.

V4.0 Page 52 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

5.3.7 Retrieval of Subscriber Info (Enabled Services, Service State, etc.)

These type of attacks are generally referred in Table 4 as “Subscriber Data Retrieval” and
can be performed by using several MAP messages, such as:

• SetReportingState:
This message is used by the HLR towards the VLR to set the reporting state for a
requested service for example to request to report call results and events.

• AnyTimeSubscriptionInterrogation:
This message is invoked by the gsmSCF, to request subscription information (e.g.
call forwarding supplementary service data or CSI) from the HLR at any time. When
sending a SS7 MAP request towards the HLR, this one returns information about the
user subscriptions (e.g. Call Forwarding Data, Call Barring Data, ODB data, call
forwarding supplementary service data)

5.3.8 Abuse of SMS Services

Several commercial applications allow users to send SMS from any number they choose.
The receiver can be easily tricked into thinking the message is from the real MSISDN owner.
Different types of fraud attack can be performed and these are referred to as “SMS attacks”
in Table 4. For more information see [2]

5.3.8.1 SMS Spoofing

SMS Spoofing occurs when a sender manipulates address information. Often it is done in
order to impersonate a user that has roamed onto a foreign network and is submitting
messages to the home network. Frequently, these messages are addressed to destinations
outside the home network with the home SMS-C essentially being “hijacked” to send
messages into other networks. This is an unauthorised use of the HPLMN SMS-C by a third
party. In this case, a SMS Mobile Originated SMS with a manipulated A-MSISDN (real or
wrong) is coming into the HPMN from a foreign VLR (real or wrong SCCP Address).

Figure 19 - SMS Spoofing (from [51])

V4.0 Page 53 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

5.3.8.2 SMS Faking

In general, a SMS-C is used to send mobile terminated SMs to a PLMN user but in a manner
that hides the true identity of the source SMS-C. Typically, this is done by substituting a valid
address with another PLMN address. When the faking technique is used in conjunction with
spam content, the complaints are then sent to the innocent PLMN. The normal delivery of a
Mobile Terminated SM is in two parts: the SMS-C uses the destination MSISDN to address a
MAP message <Send Routing Information for Short Message> to the HLR for that customer,
to find out whether the MSISDN is valid, can receive SMs, and if so, to determine the current
MSC that the destination user is registered on. The HLR responds to the SMS-C with the
information. In the second phase the SMS-C sends the actual text of the SM to the currently
registered MSC and a MAP message <Forward Short Message>. The MSC responds to
confirm the message was delivered, and generates a CDR containing all relevant
information including the SMS-C address.

In the case of faking, the first part is done exactly as described above. However, the second
part is changed so that the source address in the MAP message <Forward Short Message>
is changed, often to someone else’s SMS-C address. The manipulation of the SMS-C
address causes any inter-PLMN SMS accounting to be incorrect. The faking of the source
address in the SCCP called party Global Title and the Service Centre Address in the MAP
message <Forward Short Message> is impossible without considerable efforts by the
technical staff running the SMS-C. In other words, it does not happen either by accident,
faulty configuration data or as the result of raw text messages received from the Internet. It
happens because in most cases it requires a software patch on the SMS-C. It is fair to say
that the “Faking Case” can only be caused by deliberate activities by a spam-generating
PLMN, a spam-sponsoring PLMN, or a spam-generating SMS-C operator acting
collaboratively with a PLMN.

Figure 20 - SMS Faking (from [51])

V4.0 Page 54 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

5.3.8.3 3rd Party Faking

This is a special case of faking where the third party network uses the real SMS-C address
from another mobile network. The SMS is sent to a real subscriber of mobile network B (the
originator must have the correct IMSI) or could be sent to a wrong IMSI (just to generate C7
Overload). The IMSI can be recovered by detecting the “Send Routing Information for Short
Message". In this case, the third party must use their own real SCCP / MAP SMS-C address.

Figure 21 - 3rd Party Faking (from [51])

5.3.8.4 Flooding
A large number of messages are sent to one or more destinations with the purpose to slow
down the operator network or to jam one or more mobile terminals. Messages may be valid
or invalid. It can be combined with spoofing or spamming.

5.3.8.5 GT Scanning
Refers to sending SMS MO to all Global Title addresses from one mobile operator in order to
find unsecured SMS-C (SMS-C that are not controlling the A number). Multiple SMS
Forward SM Submits are received, generally from the same MSISDN with the Called SCCP
Address and SMS-C Address incremented on each attempt. The easiest of these scans to
spot are sequential in nature scanning 10,000 GT at a time. There can be no valid reason for
such scanning of networks other than locating unsecured SMS-C. With simpler computer
integration with mobiles and SMS emulation software readily available, this type of activity is
likely to increase.

V4.0 Page 55 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Figure 22 - GT Scanning

5.3.8.6 Phishing and Spam Attacks

These are very common, and all address this layer. SMS attacks may also be a bit
ambiguous as they don’t need to wait for a response, hence the sender address can be a
completely random number. If IMSI and VLR-GT are known, a FSM-MT (Forward Short
Message) may be transmitted directly to the V-MSC overcoming home-routing call
scenarios.

5.3.8.7 Open SMSC

Huge quantities of SMS are sent by roaming prepaid SIMs by using third party SMS-Cs,
called “open SMSCs”. Open SMS-Cs are SMS-Cs that do not screen or validate the A-party
(the sending subscriber) that attempts to use them to deliver messages. In the normal
procedure, the on-line charging is usually done via a payment platform that connects the
SMS-C with the SCP. After a successful credit check the SMS is delivered by the SMS-C. In
this particular condition, no preventive information is sent to the Home Operator, that will be
charged via TAP or notified via anti-fraud procedures such as near real-time roaming data
exchange (NRTRDE) or high usage reports (HURs). So, large volumes of SMS are
contained in such records, being sent by “dormant” roaming prepaid SIMs with no
corresponding revenue. According to some operator investigations, such attacks are
perpetrated for spamming or premium rate service purposes (the latter, in particular, toward
international revenue share fraud numbers).

See [2], [3] and [5] for more details.

5.3.8.8 Malicious Use of the MAP-REPORT-SM-DELIVERY-STATUS Message

As reported in [3], “the abnormal use of this message can be used to achieve an MT-SMS
Denial of service attack on a specific customer”. In [47], a Message Waiting Indication (MWI)
function is specified that provides quick delivery of SMS to MS when it again becomes
available for delivery of MT-SM. This function is used after prior delivery has failed due to
temporary absence. In the HLR, the MWI is set from SMSC using the MAP-REPORT-SM-
DELIVERY-STATUS message. Once the MS is reachable again, the VLR will accordingly
inform the HLR via MAP-READY-FOR-SM message. However, if a MAP-REPORT-SM-
DELIVERY-STATUS message is received unsolicited, i.e. without any prior failed SMS
delivery attempt (that is not in accordance with SMS protocols), the impact is that the

V4.0 Page 56 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

targeted customer is put in an abnormal MWI state where he is unable to receive any
subsequent SMS (since he is considered by the HLR as temporarily absent), unless he
changes MSC/VLR or receives priority SMS.

In section 8.1 some practical guidelines are reported to support an operator in putting in
place controls and filtering rules for different categories of MAP messages, depending on the
objectives and the legitimate usage of the messages.

5.4 CAP Layer

CAMEL Application Part (CAP) is the standard interworking protocol for on-line charging and
other Intelligent Network (IN) services. There are no security specific aspects for CAP and
although there are no recorded attacks on this layer, it can be vulnerable and not leak-free.
In fact, with proper information about a target MSISDN, Service Control Function (SCF)
address and service key (SK), the IN profile and services (including credit balance) can be
compromised. From what has been seen in terms of protection of IN networks, access is
granted (by core network) only from within the HPMN, specifically for short codes and IVR
accessibility, so where a network is blocking external access, internal access is open and
vulnerable. This (core network) protection will soon give way as operators race to increase
outbound roaming services to their customers.

5.5 INAP Layer

Intelligent Network Application Part (INAP) is the signalling protocol used in Intelligent
Networking (IN). It is layered on top of the TCAP. There are no security specific aspects for
INAP and although there are no recorded attacks on this layer, it can be vulnerable and is
not leak-free.

V4.0 Page 57 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

6 SIGTRAN Security Analysis

6.1 Overview
MNOs can now be interconnected to each other over IP infrastructures because it is cheaper
and more efficient than traditional SS7 links by means of new protocols based on IP layer
like SIGTRAN and VOIP (e.g.as shown in Figure 23).

Figure 23 - SS7 Network Interconnection Based on IP Backbone

With the introduction of these new protocols the following aspects should be considered:

• Different teams of people with different skills have to work together e.g. IT and
telecom operations teams need to collaborate to protect;
• New open technologies e.g. open stack, open software (as described in section 3)
are understood by a much larger constituency of potential hacker than was the case
with SS7;

These have the potential to open the gates of the traditional walled gardens and expose the
mobile networks to new security threats.

Very often firewalls do not block or analyse or do not log or deny SCTP traffic and traditional
intrusion detection systems (IDSs) do not monitor, for example, SCTP traffic. Consequently,
even simple attacks like scanning can be undetectable on some networks.

Thus the implementation of some security measures is essential to prevent malicious attacks
against SIGTRAN networks.

The major difficulties to implement security in SIGTRAN rests on the fact that all the involved
points should implement security correctly. So, according to [33], secure tunnels like IPSEC
or Transport Level Security (TLS) tunnels are recommended between SIGTRAN nodes in
order to provide the equivalent of an isolated link such as that used in a traditional SS7
network.

V4.0 Page 58 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Figure 24 - SIGTRAN Network Entry Points

Figure 24 shows the entry points for a SIGTRAN network that could be exploited to carry out
attacks against this infrastructure.

In particular, entry points for SIGTRAN network can be:

• Point 1 and Point 2 and Point 3:

• SIGTRAN ASPs within MGC may be violated by authorized peers and abused by
hackers;
• SCTP protocols may be targeted by attackers which have violated authorized
peers, IP multimedia phones or have used insecure configurations (for example
public IP addressing for network equipment).

• Point 1 and Point 2: SIP & H323 protocols can be abused by hackers which can inject
illicit signalling information violating, for example, IP phones.

Sections 6.3.1to 6.3.7briefly describe the vulnerabilities and the attacks which can be
conducted against SIGTRAN stack layers using the entry points reported in Figure 24. A
brief outline of some SIGTRAN security features is first provided below.

6.2 SIGTRAN Security Features

6.2.1 IP Layer
IPSEC tunnels could be used to prevent spoofing, tampering, reply, passive and active
attacks at the IP layer. The usage of IPSEC could raise some issues when SCTP multi-

V4.0 Page 59 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

homing is implemented. In this case an SCTP endpoint could handle more than one IP (for
example in a high availability scenario) and consequently more than one IPSEC tunnel
should be set up.

6.2.2 SCTP Layer

As shown in Figure 6, SCTP runs on top of the IP layer. This protocol natively provides some
security features such as resistance against blind denial of service attacks (flooding,
masquerading and improper monopolization of services) thanks to the introduction of the
following data (see Figure 25):

6.2.2.1 State Cookies

In the SCTP four-way handshake, state cookies are exchanged. This is an important feature
of the SCTP because the receiver (Endpoint B in Figure 25) remains stateless between
sending the second and receiving the third message. The receiver encodes the protocol
state, including the contents of the INIT and a timestamp into a state cookie, which it sends
to the sender (Endpoint A) in the INIT ACK. The sender returns the cookie to the respondent
in the COOKIE ECHO. This new feature prevents attackers from establishing connections
without using them and in that way hindering legitimate users from establishing a
connection. This feature helps to minimize resource exhaustion concerns, to prevent
connection hijacking and (D)DoS attacks, to guard against source address spoofing.

6.2.2.2 Verification Tag

A SCTP packet header contains a random 32-bit nonce (called verification tag and denoted
by TagA and TagB in Figure 25) that indicates if a packet belongs to a certain association. If it
does not, it is dropped. A new Verification Tag value must be used each time the endpoint
tears down and then re-establishes an association to the same peer. This parameter has
been introduced to prevent replay and man-in-the-middle attacks and to reduce the risk of
off-path spoofing attacks. Nodes that want to spoof packets for an association must either be
on the path between the association endpoints or guess the verification tag value. It is
obvious that the 32 secret bits are not sufficient to definitively prevent an off-path attacker
from occasionally guessing the right value and succeeding to spoof a single packet. If the
attacker knows the right port numbers and performs a brute-force sending 232 packets to the
victim, one of them will have the correct verification tag and will be accepted. Therefore this
spoofing attack requires huge effort on the attacker’s part and the benefit is limited to a
single packet. In order to spoof a second packet, the attacker needs to repeat the brute-
force. Probably the best option for the attacker is to send ABORT chunks and try to
terminate the association for denial of service, but this measure is not definitive to prevent
spoofing because other SCTP messages can be targeted by attackers (e.g. ASCONF).

V4.0 Page 60 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Figure 25 - SCTP Handshake

6.3 SIGTRAN Vulnerabilities and Attacks

Despite the new features described above, several other attacks could be carried out against
SCTP [33], [39] and [40] as follows.

6.3.1 Address Camping or Stealing or Squatting Attack

This is a type of DoS attack based on sharing the same IP address between two endpoints
in a SCTP multi-homing scenario (i.e. when an endpoint can be associated with a set of IP
addresses). The attacker (Client A) can prevent a legitimate peer (Client C) from setting up
an association with the Server (Server B), declaring the victim IP address (AddrC) as a
secondary IP address in the INIT message and the same port used by Client C. When Client
C tries to create an association with the Server B, there will be an address conflict between
the two associations (A-B and C-B) and the Server B will reject the INIT from the peer C and
respond with an ABORT. Thus, Client C cannot communicate with Server B until the latter
realizes that the attacker does not hold AddrC.

Figure 26 - Address Camping Attack

In order to carry out a successful attack, the attacker must know in advance the IP address
and the port used by the victim. The IP address can be retrieved by scanning, but the port, if
not already known, must be guessed by brute forcing 216 possible values. This guessing is

V4.0 Page 61 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

not as difficult as it may appear because ports are often used sequentially. In addition, multi-
homing has to be configured.

To limit the risk of this attack, it is recommended to implement the expanded version of
HEARTBEATS mechanism and to ensure the unconfirmed state is supported as specified by
[34]. In addition clients shall select their port numbers randomly. This type of attack is
referred to as “ADDR. CAMP” in Table 4.

6.3.2 Association Hijacking Attack Version 1

This is a Man in the Middle attack. This attack permits an attacker to gain control of a
session created by a legitimate endpoint. To carry out this attack it is necessary that
Dynamic Address Reconfiguration extension for mobility support (i.e. dynamic endpoint
addressing) is implemented.

Figure 27 - Association Hijacking v1

This attack however should not be feasible in a SIGTRAN network used for telephony
signalling services because network nodes should be configured with static IP addresses.
Consequently, in a SIGTRAN network it can be assumed that the transport addresses
belong to the association endpoints until the end of the association lifetime and that the
endpoints which have to communicate know each other’s address sets in advance. The
countermeasures to limit this threat are to add a new pair of two 32-bit nonce used to
represent the real tags with the association and use of the authentication mechanism for
chunks specified in RFC4895 [40]. This type of attack is referred to as “ASS.HIJAC.v1” in
Table 4.

6.3.3 Association Hijacking Attack Version 2

This attack is similar to the previous one. Also, in this case the endpoints should be
configured with dynamic IP addresses and when the IP address changes, the affected
endpoint should not send the correct restart notification to the peer. The probability of this
attack is quite low in a SIGTRAN network if the restart notifications provided by SCTP are
not implemented as described in [16] and [40]. This type of attack is referred to as
“ASS.HIJAC.v2” in Table 4.

V4.0 Page 62 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

6.3.4 Bombing Attack or Amplification Attack

This is a form of a (D)Dos attack based on a mechanism that causes an arbitrary SCTP
endpoint to amplify (in number and/or size) packets sent to a victim. SCTP can suffer several
types of this attack. In particular, this document describes exclusively the implementation
feasible in a mobile SIGTRAN network. In the first implementation, an attacker connects to a
large number of SCTP endpoints. Then the attacker claims his new address is the one
owned by the victim. The SCTP endpoints connected to the attacker after this notification
send back their replies to the victim, so multiple packets are sent in response to one packet
to the victim. In a second implementation, the attacker sends packets containing the victim's
address as the source address and an INIT chunk to a large number of SCTP endpoints.
Each endpoint then replies with a packet containing an INIT-ACK chunk to the victim, which
is most likely larger than the packet containing the INIT. Regarding the first scenario, it is
recommended that the endpoint perform a path verification before sending chunks other
than HEARTBEATs for path verification. This ensures this attack cannot be used against
other hosts. To avoid the attack, an SCTP endpoint should not send multiple packets in
response to a single packet. The chunks not fitting in this packet should be dropped, but
these are “implementation specific” issues and are left to the implementer’s choice.
Regarding the second scenario, unfortunately, the SCTP standard does not specify proper
countermeasures; these are “implementation specific” and issues are left to the
implementer’s choice. This type of attack is referred to as “Bombing/Amplification attack” in
Table 4.

6.3.5 Association Redirection

This attack allows an attacker to wrongly set up an association to a different endpoint. This is
an unexpected feature of the SCTP multi-homing and invoking this feature does not
constitute an attack in itself but if not well understood by application designers, it could be
exploited as a building block in application-level attacks.

6.3.6 SCTP Scan

This is a quite simple attack. To get into SS7/SIGTRAN it is necessary to find entry points
which are basically open ports on live hosts. Through scanning at SCTP level it is possible to
find SCTP live machines and open ports on these machines, and then to use them as entry
points to operator core networks. By adapting typical scanning methods used in TCP/IP
environments, it is possible to scan for services. Many SCTP scanning tools are now
available. For example an SCTP packet containing an INIT chunk is sent; the response is an
INIT_ACK chunk if the port is open or an ABORT chunk if closed. By scanning addresses,
close to the official SMSC, it is possible to find test systems that may not be correctly
connected to systems such as billing systems. It shall be considered that a lot of firewall filter
TCP and UDP traffic but have no rules for SCTP traffic because it is often treated as a
control protocol, like ICMP, and is not filtered. The attack can be configured as a way of
gathering information [64], [65] and it is referred to as “SCTP SCAN” in Table 4.

6.3.7 User Adaptation Layers

Several adaptation layers sit on top of SCTP such as i.e. M3UA, M2UA, M2PA and
SUA/IUA. None of these protocols have been designed to natively meet the following
security objectives:

V4.0 Page 63 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• Availability of reliable and timely user data transport.

• Integrity of user data transport.
• Confidentiality of user data.
• Replay protection.
• Authentication of peers.
• Non-repudiation.

All of these protocols are recommended to be transported on SCTP, which provides certain
transport related security features described above, but SCTP is unable to natively
guarantee authentication of peers, non-repudiation, integrity and confidentiality of the user
data. Consequently, IPSEC or TLS need to be used to ensure these requirements and their
implementations follow the recommendations [33].

6.4 Other Security Threats

A number of companies provide advanced services (e.g. VoIP or SMS services) and are
allowed to connect directly to the SS7/SIGTRAN network. These bring additional
vulnerabilities and security liabilities on a case-by-case basis. Attacks strictly related to
VOIP/IMS infrastructure are out of scope of this document (e.g. signalling attacks as
described in [44] ). The analysis of those attacks is very complex and may be the focus of a
separate document. The possible attacks considered in this document are those which can
be used to open the walled garden of the MNO trusted community.

These systems (e.g. ASP, VoIP gateways, PBX) can use a public Internet interface (e.g.
management interface, web interfaces, unsecure extension modules and so on) which offers
potential hackers an additional avenue of attack to breach SS7/SIGTRAN networks.

As with any system connected to the public Internet, it should be assumed that at some time,
the SMS system would be the target of a malicious attack. Whether the attack is caused by a
group of hackers seeking simply to disrupt the system or is sponsored by a group of
individuals attempting to spy on and mislead competitors, the SMS system must be
protected from outside attacks. As with any complex system composed of multiple parts,
there are numerous vulnerabilities that should be examined thoroughly in an effort to predict
upcoming attacks and defend against them as they occur.

Apart from these particular systems, other security threats can be identified considering that
a mobile node is basically a device composed of hardware (e.g. chip, processors, memory,
network cards) and software (e.g. operating system, drivers, applications, services,
protocols) and each node can be managed and configured locally and/or remotely. All these
features can expose the node to several potential vulnerabilities which can be exploited to
launch attacks if they have not been correctly implemented.

For example, over the years, several vulnerabilities to remote exploitation have been
identified in the signalling points and these systems could also be violated by means of
traditional hacking techniques like:

• Scanning to fingerprint the systems (e.g. operating system version, installed patches,
available services and so on).
• Password brute forcing to guess system passwords and gain the control of the
system or to violate user data and traffic.

V4.0 Page 64 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• HTTP hijacking to violate http service (e.g. used for administrative interfaces) like:
XSS, SQL injection, Path traversal and so on.
• Message Fuzzing (e.g. sending out malformed packets) to discover unknown
vulnerabilities to be exploited for gaining the control of the system and access to the
mobile network.
• Eavesdropping.
• Violating/Hijacking remote management protocols (e.g. Telnet, SNMP).
• Man-in-the-middle attacks, a kind of active eavesdropping in which the attacker
makes independent connections with the victims and relays messages between
them.

Consequently, it is recommended to test the protocol implementations using, for example,

fuzzing tools, to harden the hardware and software configurations of the systems, by
removing unused physical ports, unused services, using secure management protocols, to
verify the patching level of the systems.

V4.0 Page 65 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate
Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

7 Risks for Mobile Network Operators

This section contains tables that map the attacks already described in the document to the impacted protocols and network equipment,
possible defences and detection mechanisms.

This section is not intended to be exhaustive and the goal is to provide useful information to a MNO to understand the main risks to which it
could be exposed and how to reduce them.

The main hypothesises on which the data presented in the tables is based are:

• If the network equipment is reachable from an outside network it can be considered as a possible target for attackers;
• Insider and physical attacks are not considered.

Table 4 shows the classification of some possible attacks towards SS7/SIGTRAN networks identified in sections 5 and 6 according to the
taxonomy described in section 4. This is a high level mapping and does not pretend to be exhaustive.
Protocol

Section

SPA/FL

TRACK
/ Layer

PWDA
MITM

ROA
PHA
FAK
DoS

MIS
RA

DA
EA
SP

IG
IA
PI

Fake Calling Number SS7 ISUP 5.1.2 X X

(Non-SMS) Message SS7 5.1.1
X
Flooding SCCP

Network Element SS7 5.2.2

X X X X X X
Impersonation SCCP

Cryptographic Material SS7 MAP 5.4.1

X X
Retrieval
Subscriber Location SS7 MAP 5.4.2
X X
Retrieval

V4.0 Page 66 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate
Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Protocol

Section

SPA/FL

TRACK
/ Layer

PWDA
MITM

ROA
PHA
FAK
DoS

MIS
RA

DA
EA
SP

IG
IA
PI
HLR Lookup SS7 MAP 5.4.3 X X
Subscriber DoS SS7 MAP 5.4.4 X X
SS7 Overload SS7 MAP 5.4.5 X
Illegitimate Charge SS7 MAP 5.4.6 X X
Subscriber Active SS7 MAP 5.4.7
X X
Interception
Subscriber Data Retrieval SS7 MAP 5.4.8 X
SMS Attacks SS7 MAP 5.4.9 X X X X X
Address Camping SIGTRAN 6.3.1 X X
Association Hijacking v.1 SIGTRAN 6.3.2 X X X
Association Hijacking v.2 SIGTRAN 6.3.3 X X X
Bombing/Amplification SIGTRAN 6.3.4
X X
Attack
SCTP Scan SIGTRAN 6.3.6 X
SS7 5.3.1.1
TCAP Scan X X
TCAP 5.3.1.3
SS7 5.3.1.2
TCAP Traffic Injection X
TCAP

Table 4 - Classification of the analysed attacks

The attacks featured in Table 4, once completed successfully, can lead to the following range of impacts on the MNO:

V4.0 Page 67 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate
Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Protocol

Section

OVASA
/ Layer

DSCB

CDM

TDM
CDD
CSA

TDD

SSA
IMP

DIS
SU
Fake Calling Number SS7 ISUP 5.1.2 X X X X
(Non-SMS) Message Flooding SS7 SCCP 5.2.1 X
Network Equipment impersonation SS7 SCCP 5.2.2 X X X
Cryptographic Material Retrieval SS7 MAP 5.4.1 X X X
Subscriber Location Retrieval SS7 MAP 5.4.2 X X
HLR Lookup SS7 MAP 5.4.3 X
Subscriber DoS SS7 MAP 5.4.4 X
SS7 Overload SS7 MAP 5.4.5 X
Illegitimate Charge SS7 MAP 5.4.6 X X X X
Subscriber Active Interception SS7 MAP 5.4.7 X X
Subscriber Data Retrieval SS7 MAP 5.4.8 X X
SMS Attacks SS7 MAP 5.4.9 X X X
Address Camping SIGTRAN 6.3.1 X X
Association Hijacking v.1 SIGTRAN 6.3.2 X X
Association Hijacking v.2 SIGTRAN 6.3.3 X X
Bombing/Amplification Attack SIGTRAN 6.3.4 X X
SCTP Scan SIGTRAN 6.3.6 X
SS7 TCAP 5.3.1
TCAP Scan X
5.3.3
TCAP Traffic Injection SS7 TCAP 5.3.2 X X X X

Table 5 - Analysed attacks versus the possible effects for MNOs

V4.0 Page 68 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

8 Recommendations and Countermeasures

This section provides some recommended countermeasures for mobile operators to consider
implementing.

• Table 6 identifies some mitigation strategies for the attacks described in sections 5 and
6.
• The following subsections provide guidelines on implementation of a screening policy for
MAP messages, and some references to countermeasures for SMS abuse.

This section does not provide any detailed descriptions of countermeasures for IP attacks.

Target Message Mitigation

Support the expanded version
of HEARTBEATS and
All external
Unconfirmed state is
Address Camp SIGTRAN SCTP INIT
supported as specified by
enabled devices
[34]; select SCTP source port
number randomly.
Association All external
Hijacking v.1 & SIGTRAN SCTP ASCONF Static IP addresses
v.2 enabled devices

Bombing /
All external IP SCTP Firewalling, Traffic
Amplification SCTP INIT, INIT-ACK
enabled devices Rate Limiting, Anti spoofing
Attack
Access control modules (i.e.
Fake Calling IGW, VMS, IVR, all IVR with external network
ISUP messages
Number customers access should be password
protected)
SendRoutingInfo,SendRouti
SMS Firewalling, MAP
ngInfoforSMS,
HLR Lookup HLR screening policies (see
SendRoutingInfo for LCS,
section 8.1)
SendIMSI
(Non-SMS) SS7 Firewalling, MAP
Message All SS7 nodes All SCCP messages screening policies (see
Flooding section 8.1)
All external SCTP Firewalling, IDS,
SCTP Scan SIGTRAN SCTP INIT Access Control List based on
enabled devices source IP
SendAuthenticationInfo, SS7 Firewalling, MAP
Cryptographic
HLR/AUC SendIdentification, screening policy (see section
material retrieval SendParameters 8.1)

V4.0 Page 69 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Target Message Mitigation

SMS Firewalling, MAP
MAP messages related to
SMS Attacks SMSC screening policies (see
SMS service
section 8.1)
SS7 Firewalling, MAP
Network
All SS7 nodes SS7 messages screening policies (see
Equipment section 8.1)
AnyTimeInterrogation,
SendRoutingInfo,
Subscriber SS7 Firewalling, MAP
HLR, SendRoutingInfo for LCS,
Location screening policy (see section
VLR/MSC/SGSN SendRoutingInfo for GPRS,
Retrieval 8.1)
SendRoutingInfo,
ProvideSubscriberLocation
UpdateLocation,
CancelLocation,
InsertSubscriberData, SS7 Firewalling, MAP
VLR, HLR,
Subscriber DoS DeleteSubscriberData,ISTC screening policies (see
MSC/SGSN
ommand, section 8.1)
AnyTimeModification,
ProvideRoamingNumber
AlertServiceCentre,
RemoteUserFree,
RegisterSS,Reset,
ForwardCheckSSIndication,
SS7 Firewalling, MAP
HLR,VLR, ActivateTraceMode,
SOverload screening policies (see
MSC/SGSN ProvideRoamingNumber,
section 8.1)
InsertSubscriberData,
ISTCommand,
AnyTimeSubscriptionInterro
gation
InsertSubscriberData,,
AnyTimeModification,
SS7 Firewalling, MAP
Illegitimate VLR, HLR, ProcessUnstructuredSSRe
screening policies, (see
Charge gsmSCF quest,
section 8.1)
NoteSubscriberDataModifie
d, DeleteSubscriberData
Subscriber SS7 Firewalling, MAP
UpdateLocation,
Active HLR screening policies (see
AnyTimeModification
Interception section 8.1)
SetReportingState, SS7 Firewalling, MAP
Subscriber Data
VLR, HLR AnyTimeSubscriptionInterro screening policies (see
Retrieval gation section 8.1)
SS7 Firewalling, filtering
TCAP Begin
TCAP Scan All NE based on Called Party
SCCP Management
Address and SSN at

V4.0 Page 70 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Target Message Mitigation

SCCP level. This can be
activated in the configuration
of the STP or International
Gateway.
TCAP Traffic
All NE All TCAP messages NE patching
Injection
Table 6 - Analysed Attacks versus possible Countermeasures

8.1 SCCP Global Title Anti-Spoofing

In the case where the SS7 attackers may not care about the response to the sent SCCP
messages, they may use spoofed addresses in their SS7 attacks. These may apply for the
Network Element IS described in 5.2.2 or Subscriber DoS, SS7 Overload, and Illegitimate
Charge attack types described in 5.4. Therefore, validating the originating address of these
messages may no longer be accurate. A mechanism to protect against the spoofing of internal
Global Titles (GT) should be implemented on the national and international interconnection
points (e.g. on STPs). In particular, SS7 messages coming from the interconnection points with
an SCCP Calling Party Address (i.e. the calling GT) and a SCCP Called Party Address (i.e.
Called GT) belonging to the same network should be discarded. These checks may be applied
for the MAP messages listed in section 8.2.1. An STP or an SS7 firewall can reliably implement
and enforce this anti-spoofing check.

It is important to implement this rule to avoid undermining the efficacy of the MAP filtering
criteria, listed in the following sections.

For the MAP messages listed in sections 8.2.2 and 8.2.3, plausibility checks may be required to
detect if spoofed addresses are used associated SS7 attacks.

Detailed guidance on how to detect spoofing can be found in [1].

8.2 MAP Screening Policy Guidelines

This section provides some basic and preliminary guidelines for mobile operators to put in place
a MAP screening policy to ensure that MAP messages are being used legitimately and as
intended. More precise and detailed guidelines for monitoring and filtering can be found in [1]
and [2].

This section does not specifically address SMS related messages abuse – see [3], [4] and [6]
for detailed guidance on that topic.

As reported in section 5, MAP messages can be abused to perform different kinds of attacks. To
identify and block unauthorised MAP messages, the first recommendation is to monitor SS7
network messages being received from international nodes not belonging to an allowed roaming
partner and not related to the delivery of SMS. This will allow operators to determine whether
suspicious messages are coming in, and from which other operators – after which follow-up
investigation and action can be taken.

V4.0 Page 71 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

An alternative approach is to ensure that the routing tables for inbound messages from a
partner’s network limit the access for that network. In today’s networks, interconnect routing is
left open to any and all SS7 messages. By limiting the access being granted to the partner, you
eliminate the need to track black lists, which in themselves have become extremely difficult to
manage.

To reduce the risks of the attacks described in 5.4 and Table 6, a mobile operator should try to
filter out incoming sensitive SS7-MAP messages from nodes that have no legitimate reason to
be sending them, leaving only messages from reasonably trusted nodes. Sections 8.2.1 to 8.2.3
describe three categories [62] of SS7-MAP messages and associated screening
recommendations.

These screening recommendations should be implemented by a MNO to verify that the

incoming MAP messages are coming from its own network or from allowed roaming partners.

These screening recommendations should limit the attacks listed in section 5.4 and Table 6 (i.e.
Cryptographic Material Retrieval, Subscriber Location Retrieval, HLR Lookup, Subscriber Active
Interception and Subscriber Data Retrieval), which requires that an attacker uses his actual
CallingPartyAddress to retrieve network or subscriber information, i.e. not a spoofed
CallingPartyAddress like in other type of attacks where is not needed to receive a response to
the invoked MAP message.

8.2.1 Category 1
The following messages should normally only be received from within the same network, and
not on interconnect links from other networks, unless there is an explicit agreement to do so:

• SendRoutingInfo
• SendRoutingInfo for GPRS
• SendRoutingInfo for LCS
• SendIMSI
• AnyTimeInterrogation (see NOTE 1)
• AnyTimeSubscriberInterrogation
• AnyTimeModification
• SendIdentification
• CheckIMEI
• SendParameters (see NOTE 2)
• FailureReport
• ResumeCallHandling
• NoteSubscriberDataModified
• Unknown PDU (i.e. Any GSM-MAP packet with an Unallocated/Unknown Operation
Code)

V4.0 Page 72 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

NOTE 1 AnyTimeInterrogation should be blocked when coming from the outside of the
home network and when the SCCP Calling Party Address does not belong tp
any 3rd party LBS partners.

NOTE 2 SendParameters is an older GSM MAP v1 packet whose functions have

subsequently been superseded by other packets. This command should only be
used with MAP v1 components and should not be supported by more advanced
nodes.

SendParameters for the purposes of Inter-VLR Information retrieval falls under

this category. In particular this message should be blocked when coming from
the outside of the home network and when the SCCP Called Party Address is a
VLR GT.

This list includes examples of the MAP messages belonging to this category; a complete list of
messages can be found in [1].

The screening policy recommendation for this category of MAP messages is to block them
when coming from the outside of the home network. However, it is recommended that operators
first monitor (as described in [1]) before blocking and check if they have any legitimate reasons
and/or commercial agreements which require them to receive such a MAP messages from
certain operators.

8.2.2 Category 2
The following messages should normally only be received in relation to an inbound roaming
(visiting) subscriber from that subscriber’s own home network:

• InsertSubscriberData
• DeleteSubscriberData
• Reset
• ForwardCheckSSIndication
• ProvideSubscriberInfo
• ProvideSubscriberLocation
• NoteSubscriberDataModified
• ActivateTraceMode
• ProvideRoamingNumber
• SetReportingState
• RemoteUserFree
• ISTCommand
• AlertServiceCentre
• CancelLocation
• BeginSubscriberActivity
• SendParameters (see NOTE)
• DeactivateTraceMode
• UnstructuredSSNotify

V4.0 Page 73 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

NOTE SendParameters for the purposes of signalling to a HLR to update location, and
exchanging authentication information between a visited VLR/SGSN and HLR
falls under this second category of filtering. In particular this message should be
permitted when coming from the outside of the home network, directed towards
HLRs and the SCCP Calling Party Address belongs to a whitelisted set of MAP
v1 operators that are known to use it (This information should be added to IR.21
Mobile Application Part Section).

This list includes examples of the MAP messages belonging to this category; a complete list of
messages can be found in [1].

The screening policy recommendation for this category of MAP messages is to block them if
either of the following criteria are met:

• The MAP messages are coming from the outside of the home network and the SCCP
Calling Party Address does not belong to a roaming partner or a specific whitelist of GT
(e.g. see note for SendParameter)
• The SCCP CallingPartyAddress and the IMSI within the MAP messages do not belong to
the same operator (i.e. there is a mismatch in terms of MCC and MNC)

Also for messages belonging to this category, it is recommended that operators, before
blocking, first monitor as described in [1].

8.2.3 Category 3
The following messages should normally only be received in relation to an outbound roaming
subscriber from the visited network that the subscriber is currently roaming in:

• RegisterSS
• UpdateLocation
• UpdateGPRSLocation
• ForwardSM
• ProcessUnstructuredSS
• PurgeMS
• RegisterSS
• EraseSS
• ActivateSS
• DeactivateSS
• InterrogateSS
• RestoreData
• SendAuthenticationInfo
• NoteMMEvent
• SendParameters

This list includes examples of the MAP messages belonging to this category; a complete list of
messages can be found in [1].

V4.0 Page 74 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

The screening policy recommendation for this category of MAP messages is to block them if
either of the following criteria are met:

• The MAP messages are coming from the outside of the home network and the SCCP
Calling Party address does not belong to a roaming partner
• The SCCP Calling Party Address and the GTs when present in the MAP layer of the
message do not belong to the same network.
• The SCCP CallingPartyAddress does not match the network where the subscriber is
currently located.

This last filtering rules could be more complex to implement because the mobile operator may
need to determine the current location of the subscriber and to verify it against the Calling Party
Address of the received message.

Also for messages belonging to this category, it is recommended that operators, before
blocking, first monitor as described in [1].

8.2.4 Filtering Considerations

As detailed in [2], MAP message filtering can, in principle, be carried out either at the individual
receiving network nodes (e.g. MSC, HLR), at the network interconnect point (STP), or in a
dedicated appliance (e.g. signalling firewall).

Gateway screening capabilities and GT routing at the STP will allow an operator to selectively
choose which networks are allowed access to its internal network, as well as what level of
access they are allowed (i.e. ISUP only, ISUP and SCCP, SCCP only, CgPA/CdPA, SSN, etc.).
Additional MAP screening at the STP provides additional control to the mobile operator over
what specific MAP operation codes are permitted to enter the network.

Not all network equipment will necessarily support all of these filtering operations today,
therefore a dedicated appliance with the necessary filtering capabilities could be required.

Consequently mobile operators may need to talk to SS7 firewall vendors about products
(current or future) that can provide these filtering capabilities.

Mobile operators are also strongly advised and encouraged to consult with their STP vendors
regarding their ability to support and provide the required filtering capabilities.

In all cases it is strongly recommended to try out filtering rules in monitoring mode first, before
actually blocking, as described in [1]; this will help to identify any other legitimate use cases that
may need to be whitelisted.

V4.0 Page 75 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

9 Conclusions
This document has sought to assess security threats related to SS7/SIGTRAN networks, by
identifying vulnerabilities and corresponding countermeasures and mitigation techniques. In
addition,a taxonomy of attacks and their impacts is also provided.

A review of the current open SS7 source projects is also provided. The maturity and quality of
some of them, in terms of number of protocol stack levels and features implemented, is quite
high even if their usage is not so widespread. Consequently, the risk of their usage to
compromise a mobile network can be considered low at present, but should not be dismissed.

Guidelines for implementation of MAP screening policy are proposed.

A “Network Incident Report” template based on the taxonomy is also provided in Annex A for
mobile operators to report network signalling security incidents in a consistent manner within
GSMA.

V4.0 Page 76 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Annex A SS7/SIGTRAN Network Incident Report Template

A “Network Incident Report” template based on the taxonomy described in section 4 is provided
below (embedded file in Microsoft Word format) for mobile operators to exchange information on
network signalling security incidents in a consistent manner within GSMA.

Incident Report

V4.0 Page 77 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Annex B Further Attack Scenarios

In this annex futher attack scenarios that abuse MAP messages are described. The goal is:

• To describe additional attacks and classify other messages not yet included in clause 8.2
• To consider if additional countermeasures are necessary to cover other scenarios related
to the messages already classified in this document.

The structure described in the following section B.1 will be adopted as a reference template to
describe each attack scenario.

B.1 [Attack Scenario Title]

This section will contain a short description of the attack scenario and goal, and the MAP
message(s) used to conduct the attack. If a relevant MAP message is already classified in this
document, the summary here will refer to the specific clause within section 5.3 where the
message is described. Otherwise, a description of the legitimate usage of the MAP message(s)
(why/when they are used and which nodes are involved) is included.

B.1.1 Assumptions & Pre-requisites

A short description of the information that an attacker needs to know to perform the attack.

B.1.2 Attack Description

A short description of the attack

B.1.3 MAP Classification and Countermeasures

A classification of the MAP message(s) abused in the attack based on the three categories
reported in section 8.2 of this document and a description of the countermeasures which help to
prevent the attack.

B.2 Remove IMEI from EIR Blacklist Attack

An attacker has a stolen mobile device that is blacklisted. To sell the device, the attacker wants
to remove this block.

The MAP Check_IMEI message is abused to conduct this attack. In legitimate use, the
Check_IMEI message is sent by an MSC towards an EIR before allowing the mobile device to
register on the network. The Check_IMEI message normally contains only an IMEI. However,
an extension to the message exists which also supports inclusion of the IMSI in addition to the
IMEI within the message parameters, for legitimate use to unblacklist a device if it is recovered
by the owner.

The IMEI parameter is used by the EIR to search in the database the presence of that IMEI in
the three different lists: blacklist, greylist or whitelist. The MAP_CHECK_IMEI_ACK message is
returned by EIR to MSC, containing the equipment status and specifying in which list the IMEI is
found. Depending on this, the MSC takes an appropriate decision about whether to allow
registration of the mobile device or not.

V4.0 Page 78 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

The extended version of this message (a proprietary implementation that is publicly known but
not specified in standard documents) can be misused by an attacker to remove stolen devices
from the EIR blacklist and to increase their black market value.

B.2.1 Assumptions and Pre-requisites

To perform the attack, an attacker needs to:

• know the IMSI that was associated with the device (IMEI) while blocking or last used by
the victim (the original SIM is not necessary)
• know the Global Title (GT) of the EIR
• know the MSC GT (depending on operator configuration it might be not necessary)
• enable feature and IMSI check options in the message
• enable Extended IMEI Check (for operators using the feature to easily whitelist phones,
that check might be already enabled)
• have access to the SS7 network

B.2.2 Attack Description

The attacker sends (posing as a legitimate MSC) the MAP_CHECK_IMEI (extended check IMEI
command) message containing the IMEI along with IMSI to the EIR.

Initially, the IMEI is checked to know the list it belongs to. If it is found on the black list, an
additional check of the IMSI is made. If there is a match between IMSI provisioned with IMEI in
the EIR database (this is the IMSI-IMEI pair in the EIR before the victim blocks his stolen
device) with the IMSI found in MAP_CHECK_IMEI message, then this overrides the blacklist
condition. The mobile device will no longer be blacklisted. This kind of override is used in normal
network operation to whitelist phones that were accidentally blacklisted or were found again
having been originally lost and blacklisted.

B.2.3 MAP Classification and Attack Countermeasures

MAP Check_IMEI belongs to category 1 (section 8.2.1) since it should normally only be
received from within the same network, and not on interconnect links from other networks.

Add ”Check_IMEI” to the filter list of network internal messages to prevent this kind of attack.

Another countermeasure is to not allow dynamic changes (by using MAP messages) of the EIR
blacklist.

B.3 Enable Barred Mobile Services

An attacker wishes to enable barred services, so abuses the MAP Insert_Subscriber_Data
message (ISD) to modify the user profile in the VLR. The enabled services could be used to
increase the volume of traffic generated on a fraudulently acquired subscription. The
Insert_Subscriber_Data message is already described in section 5.3.4, 5.3.5 and 5.3.6. In the
following we mainly consider the attack scenario described in section 5.3.6.

V4.0 Page 79 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

B.3.1 Assumptions and Pre-requisites

The attacker needs to:

• Know the GT of the HLR of the home operator of the targeted user’s IMSI
• Know the GT of the VLR where the targeted user’s IMSI is currently attached
• Know the targeted user’s IMSI
• Have access to the SS7 network

B.3.2 Attack Description

An attacker uses a spoofed GT of a legitimate HLR and uses it as SCCP Calling Address in the
ISD message (no answer to the request is needed). The IMSI in the ISD message belongs to
the spoofed HLR (i.e. there is a match between the CgPA at SCCP layer and the MCC/MNC in
the IMSI at the MAP layer).

The attacker sends the ISD message towards the VLR where the targeted user’s IMSI is
currently registered. The parameters in the message are configured to enable barred
services.The VLR generally does not wait for the TCAP end transaction and enables the
requested services.

B.3.3 MAP Classification and Attack Countermeasures

The ISD message should normally only be received in relation to an inbound roaming (visiting)
subscriber from that subscriber’s own home network. For this reason the message belongs to
category 2.

A check should be implemented to verify if the ISD is a legitimate message. Countermeasures

proposed in section 8.2.2 do not cover the case of illegitimate ISD message sent using an
SCCP CallingPartyAddress and an IMSI at MAP layer belonging to the same operator (i.e. there
is a match in terms of MCC and MNC).

In this case, another countermeasure is needed. A possible measure is for a VLR to execute the
changes requested by a command (e.g. Insert_Subscriber_Data) only when the TCAP
transaction has been completed, NOT when receiving the TCAP begin. If for performance
reasons it is necessary to perform the change before waiting for the TCAP end, the VLR should
support the capability to reverse the change in case the TCAP transaction does not end
correctly. However, this measure would be ineffective if the attacker is able to also complete the
TCAP transaction with a spoofed TC-end.

B.4 Redirect Incoming Calls

An attacker wants to redirect incoming calls and SMS of a given IMSI, so it misleads the HLR by
faking a serving MSC/VLR for the IMSI.

B.4.1 Assumptions & Pre-requisites

The HLR does not verify the correctness and trustworthiness of the MSC/VLR. The attacker
needs to:

V4.0 Page 80 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• Know a valid IMSI (it can be done via “5.3.3 Retrieval of Mobile Subscriber Identity (e.g.
IMSI)”) or a random IMSI
• Own a GT to complete the LocationUpdate transaction and receive further MAP
messages.
• Own number ranges.
• Have access to the SS7 network

B.4.2 Attack Description

The attacker sends a LocationUpdate message with a valid IMSI from a node: the fake
MSC/VLR. With the MGT routing, the LocationUpdate is routed toward the HLR of this IMSI.
The HLR sends a CancelLocation message to the previously serving MSC/VLR and registers
the fake MSC/VLR as the new serving one.

B.4.2.1 Mobile Terminated Call:

Upon reception of a mobile terminated call toward the attacked IMSI, the home GSMC will
initiate a SendRoutingInformation toward the HLR. The HLR will send the
ProvideRoamingNumber request to the fake MSC/VLR, as being the one serving the IMSI. This
fake MSC/VLR will answer with a technical number of its choice. According to Mobile
Terminated Call mechanisms, the call will be routed toward this number. The call is intercepted
or the technical number can be a premium number.

B.4.2.2 SMS Mobile Terminated:

Upon receipt of a terminated SMS toward the attacked IMSI, the delivering SMS-C will send to
the home HLR a SendRoutingInformationForShortMessage. The HLR will answer the SMS-C
with the fake MSC/VLR information, as it is registered as the serving one of the attacked IMSI.
The SMS-C then delivers the SMS to the fake MSC/VLR and the SMS is intercepted.

B.4.3 MAP Classification and Attack Countermeasures

The LocationUpdate procedure belongs to category 3 (see section 8.2.3).

The countermeasures below would prevent such attacks:

• Filter incoming messages for IMSI retrieval (although the attack can be on random IMSI).
• Filter incoming LocationUpdate messages to only allow messages from valid partners.

B.5 Intercepting Outgoing Calls

An attacker wants to intercept mobile originated calls of an identified end subscriber. The
attacker fools the serving MSC/VLR by updating the subscriber’s profile with a fake gsmSCF
address, service key and all necessary CAMEL parameters to ensure an Initial Detection Point
(IDP) trigger.

B.5.1 Assumptions & Pre-requisites

The attacker needs to:

V4.0 Page 81 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• Know the targeted IMSI (it can be done via the methods described in section 5.3.3 or at
random)
• Know the GT of the VLR serving the targeted IMSI (via the methods described in section
5.3.2)
• Know the GT of the HLR of the targeted IMSI
• Own a node that can act as gsmSCF
• Own number ranges
• Have access to the SS7 network

Also, CAMEL phases need to be configured at the MSC/VLR level for the IMSI range of the
targeted IMSI.

B.5.2 Attack Description

The attacker fakes the IMSI’s HLR and sends an InsertSubscriberData message to the VLR
serving the targeted IMSI using the HLR GT as a SCCP Calling Address. The
InsertSubscriberData contains CAMEL information with a fake gsmSCF GT, service key and all
necessary CAMEL parameters to ensure IDP trigger. The VLR does not wait for the TC-End
and updates the subscriber’s profile with this information.

Upon receipt of a mobile originated call, the serving MSC will invoke the gsmSSF which will
interrogate the fake gsmSCF. The fake gsmSCF can then redirect the call at its convenience
(e.g. to a premium rate number) and forward the call to its initial destination.

B.5.3 MAP Classification and Attack Countermeasures

The InsertSubscriberData belongs to Category 2. The validation rules proposed in section 8.2.2
do not cover the case of InsertSubscriberData sent with valid IMSI and correlated spoof HLR.

Two additional countermeasures would be to:

• Ensure the VLR updates the IMSI’s profile with new information upon receipt of the TC-
End, not at the TC-Begin.
• Ensure the gsmSCF GT contained in the InsertSubscriberData belongs to the same
HPMN as the GT HLR. However, some CAMEL services are provided with gsmSCF GT
different than the HPMN’s.

B.6 Intercepting Incoming Calls (Using MAP RegisterSS)

This is an alternate scenario to that described in B.4 where the MAP RegisterSS message is
used by the attacker to redirect and intercept incoming calls using the call forwarding service.
The attacker will enable the call forwarding service for the targeted subscriber by faking as the
serving MSC/VLR to the HLR with the subscriber’s IMSI. Subsequently, the attacker may
reconnect the call to the targeted subscriber in order to intercept the conversation by acting as
the man-in-the-middle.

B.6.1 Assumptions & Pre-requisites

The attacker needs to:

V4.0 Page 82 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

• Know the valid IMSI (as per section 5.3.3 of the targeted subscriber)
• Own an MSISDN to receive the forwarded call
• Own a GT to spoof as an MSC/VLR to originate the MAP message(s) and to reconnect
the call to the targeted subscriber
• Have access to the SS7 network

B.6.2 Attack Description

The attacker may send a fake Register_SS message with a valid IMSI to the targeted
subscriber’s HLR. No response to this MAP operation is expected. If accepted, the HLR shall
register the given MSISDN as the forwarded-to number; so only the MSISDN may be
referenced back to the attacker.

When the targeted subscriber receives any incoming call, the call will subsequently be
forwarded to the attacker’s forwarded-to MSISDN. The attacker may reconnect the call to the
targeted subscriber using the incoming call’s caller ID so as not to raise any suspicion. The
incoming call will be intercepted via this man-in-the-middle attack.

B.6.3 MAP Classification and Attack Countermeasures

The Register_SS message belongs to the category 3 (see section 8.2.3). The following
countermeasures are proposed to prevent/mitigate such attacks:

• Filter incoming messages for IMSI retrieval.

• Filter incoming Register_SS only from valid roaming partners, though the calling
address(es) may be spoofed.
• Validate the targeted subscriber’s location by comparing his/her registered location on
the HLR, against the address(es) originating the Register_SS operation.
• Limit the CF forwarded-to MSISDN to domestic and non-premium numbers.
• The CF service may request for a password to be included when the Register_SS is
received from a roaming partner/non-domestic network.

V4.0 Page 83 of 84
GSM Association Confidential - Full, Rapporteur, Associate and Affiliate Members
Official Document FS.07 - SS7 and SIGTRAN Network Security

Annex C Document Management

C.1 Document History

Version Date Brief Description of Change Approval Editor / Company
Authority
Rosalia D’Alessandro
1.0 4 Jun 2015 First approved version PSMC & Luciana Costa,
Telecom Italia
Proposed new annex B. Rosalia D’Alessandro
2.0 9 Oct 2015 Additions in sections 5.3.4, 5.3.6 FASG & Luciana Costa,
and 5.3.7 plus other clarifications Telecom Italia
Improve alignment with PRDs Rosalia D’Alessandro,
3.0 16 Nov 2016 FASG
FS.11 and IR.82 Telecom Italia
Add Tunnel Vision attack and an
Rosalia D’Alessandro,
4.0 8 Dec 2017 outline of additional open source FASG
Telecom Italia
SS7 tools.

C.2 Other Information

Type Description
Document Owner FASG - RIFS
Rosalia D’Alessandro & Luciana Costa, Telecom
Editor / Company
Italia

It is our intention to provide a quality product for your use. If you find any errors or omissions,
please contact us with your comments. You may notify us at [email protected]

Your comments or suggestions & questions are always welcome.

V4.0 Page 84 of 84