0% found this document useful (0 votes)
59 views20 pages

Forensics of A Rogue Base Transceiver Station

Uploaded by

Caio Cruz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
59 views20 pages

Forensics of A Rogue Base Transceiver Station

Uploaded by

Caio Cruz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/366760619

Forensics of a Rogue Base Transceiver Station

Article in International Journal of Electronic Security and Digital Forensics · January 2023
DOI: 10.1504/IJESDF.2023.10047307

CITATIONS READS

0 180

3 authors, including:

Ramya Shah Digvijaysinh M Rathod

6 PUBLICATIONS 0 CITATIONS
National Forensic Sciences University
33 PUBLICATIONS 113 CITATIONS
SEE PROFILE
SEE PROFILE

All content following this page was uploaded by Digvijaysinh M Rathod on 18 April 2023.

The user has requested enhancement of the downloaded file.


124 Int. J. Electronic Security and Digital Forensics, Vol. 15, No. 2, 2023

Forensics of a rogue base transceiver station

Ahmed Landry Sankara, Ramya Shah and


Digvijaysinh Rathod*
School of Cyber Security and Digital Forensics,
National Forensic Sciences University,
Gandhinagar, Gujarat, India
Email: ahmedlandry.sankara@yahoo.com
Email: ramyashah4@gmail.com
Email: todigvijay@yahoo.com
*Corresponding author

Abstract: Mobile communication systems have become an integral part of


daily life, and GSM networks are the most widely used telecommunication
technology among mobile users in many nations. In recent years, the incidence
of attacks with rogue BTS has risen unexpectedly, primarily in nations where
GSM remains the primary telecommunications infrastructure. Using YateBTS
as the BTS software, we simulated an attack scenario with IMSI catcher,
calls/SMS spoofing and calls/SMS interception. Using forensic software such
as EnCase and FTK, we examined Raspberry OS (a Linux-based operating
system) and YateBTS. We gathered and recovered important artefacts related
to user activity, user authentication activity, system calls messages from Blade
RF, call logs, internet traffic log, custom SMS and BTS configurations that
would be useful in a court of law. We can reconstruct the truth of the crime
using the artefacts recovered. Law enforcement, computer forensic
investigators, and the digital forensics research community will benefit greatly
from the findings of this study.

Keywords: GSM; rogue BTS; SDR; YateBTS; BladeRF; BTS forensics;


digital forensics; IMSI catcher; SMS spoofing; FTK; EnCase.

Reference to this paper should be made as follows: Sankara, A.L., Shah, R.


and Rathod, D. (2023) ‘Forensics of a rogue base transceiver station’,
Int. J. Electronic Security and Digital Forensics, Vol. 15, No. 2, pp.124–142.

Biographical notes: Ahmed Landry Sankara is a Burkina Faso citizen,


graduated in MSc Digital Forensics and Information Security from the
outstanding National Forensics Sciences University (NFSU). He is an
independent digital forensic and security researcher since 2017 recognised by
INTEL and similar organisations. He has earned numbers of professional’s
certifications such as OSCP, OSWP, CRTP, Mile2 CPTC and CEH. He helps
numbers of organisations to secure their systems and track miscellaneous
activities.

Ramya Shah is working as an Assistant Professor at the School of Cyber


Security and Digital Forensics, National Forensic Sciences University,
Gandhinagar, Gujarat. His areas of interest are digital forensics, incident
response and threat intelligence, internet of things security forensics,
ICS/SCADA security and forensics. He received his Master of Technology in
2019 for Cyber Security and Incident Response from Gujarat Forensic Sciences
University, Gujarat, India.

Copyright © 2023 Inderscience Enterprises Ltd.


Forensics of a rogue base transceiver station 125

Digvijaysinh Rathod received his BSc in Electronics and Master’s in Computer


Application (MCA) respectively. He completed his PhD in Computer
Application from the Ganpat University (GUNI), India. He is currently working
as an Associate Professor (Cyber Security) in the School of Cyber Security and
Digital Forensics, National Forensic Sciences University (Institution of
National Importance), India. He has around 18 years of teaching and research
experience, and has published more than 30 research papers in the reputed
journals, conferences, and seminar and workshop proceedings. His area of
interest includes mobile and web application security, blockchain and ICS/
SCADA security.

1 Introduction

One of the most widely used cellular technologies in the world is the global system for
mobile (GSM) communications (Redl et al., 1995). GSM communications is a digital
mobile telephony network in which mobile phones interact using phone numbers as
identifiers. For GSM, a mobile number is equivalent to an internet protocol (IP) address
on the internet. This network is based on base stations, analogous to access points in IP
networks and provide direct contact with mobile phones. The base station is connected to
the rest of the network, and the only one who knows the path to the remainder of the
network is the base station. GSM is a widely utilised telephonic technology in many
countries, a threat to the GSM network is the most serious threat to the mobile
communication system.
Vulnerabilities are flaws in a system’s security that can be exploited by a malicious
individual to compromise its information assurance. The only way to prevent such flaws
from being exploited is to uncover them before an attacker does and quantify their impact
on the system. Simulating an attack on such a system allows the system’s owner to
identify the system’s vulnerabilities and patch them before a malicious person uses it.
Unfortunately, many operators continue to have serious vulnerabilities in their
networks, putting their consumers at danger and allowing attackers to use open-source
solutions like YateBTS (Finley, 2014) to prey on them. Simulating a BTS in the early
days of GSM networks appeared to be prohibitively expensive (Cooper, 2012), but
solutions like YateBTS and a software define radio (SDR), attacker with minimal
abilities may carry out an attack. Attackers employ rogue/fake BTS (Song et al., 2012) to
exploit GSM network weaknesses and fool users into connecting to the rogue BTS
assuming it is a legitimate BTS. YateBTS and SDR is used to recreate an assault scenario
in order to grasp the importance of the proposed forensics concept of rogue BTS.
The rest of this paper is laid out as follows: Section 2 discusses the results of a
literature review on GSM network security and rogue/fake BTS forensics. In Section 3,
we talked about configuration of laboratory with hardware and software recruitment,
methodology is discussed in Section 4. Section 5 describes forensic ways for collecting
evidence from Raspberry OS (Linux-based OS) and YateBTS, and Section 6 concludes
the work with research comments.
126 A.L. Sankara et al.

2 Related work

Tencent Security (June 2016) revealed that a mobile banking trojan called Swearing
Trojan attacked a large number of Android users in China, stealing their bank passwords
and other sensitive personal information. Attackers use fake base transceiver stations
(BTSs) to send phishing SMS messages posing as messages from Chinese telecom
companies such as China Mobile and China Unicom. The use of a BTS to transmit fake
messages is complex, and the SMS content is misleading. Users are tricked into visiting a
fraudulent URL, which downloads malware. The Swearing Trojan is capable of
bypassing the security of two-factor authentication (Ahvanooey et al., 2017). The Federal
Communications Commission (FCC) established a task force in 2014 to look into the
extent to which criminal gangs and foreign intelligence services utilise IMSI catchers to
locate and identify nearby phones, intercept calls and text messages (Timberg, 2014). In
2012, there were reports of IMSI catchers being widely used in the Czech Republic
(Volynsky, 2012). Hadžialić and Mušovic (1999) discussed a GSM network one-way
authentication vulnerability that can be exploited to intercept mobile phone traffic and
track position data using an international mobile subscriber identity-catcher (IMSI
catcher) device. Song et al. (2012) described the use of software radio technologies to
create fake BTSs and demonstrated IMSI/IMEI catch and selective jamming assaults.
Glendrange et al. (2010) discussed combining AirProbe, the Universal Software Radio
Peripheral (USRP) radio platform, and GNU radio to create an IMSI catcher. Hadžialić
et al. (2014) presented the creation of an open-source IMSI catcher utilising a USRP
device, as well as a security attack based on sending malicious SMS to many mobile
users.
It is worth noting that the majority of researchers used rogue BTS to implement
various GSM network attack scenarios, according to the literature. Cybercriminals can
use such rogue BTS to perform crimes, and no research focusing on the forensics of
rogue BTS. The purpose of this research study is to describe methods for gathering
evidence in cases where a rogue BTS was used to perform a crime.

2.1 YateBTS
Yet Another Telephony Engine (YateBTS, n.d.) is a C++-based telephony engine that
supports a variety of scripting languages, including PHP, Python, Perl, JavaScript
libraries, and even any UNIX shell. To make developing external capabilities for Yate
easier, PHP, Python, Perl, and JavaScript libraries have been built and made accessible.
Its present focus on voice over internet protocol (VoIP) and the public switched
telephone network (PSTN). Its strength comes from its ability to be quickly expanded,
and it may be used for mobile telephony, VoIP networks, and PBX systems. Under
Yate’s flexible routing engine, voice, video, data, and instant messaging may all be
merged, maximising communications efficiency and lowering infrastructure costs for
enterprises. Yate has a JavaScript interpreter enabling easy-to-build telephony and
supports protocols such as Signalling System 7 (SS7) (Qasim et al., 2018), session
initiation protocol (SIP) (Jennings et al., 2016), diameter and radius, and media gateway
control protocol (MGCP) (Bertrand, 2007). It can be used as a VoIP server/client,
200-channel conference server, ‘call centre server’, SS7 switch, H.323 -> SIP proxy,
jabber server/client, conference server, IVR engine, ISDN passive and active recorder,
PC2Phone, or VoIP to PSTN gateway, among other things.
Forensics of a rogue base transceiver station 127

3 Laboratory setup

An software defined radio (SDR), two quad-band cellular duck antennas SMA, a
Raspberry Pi 3 model B and laptop Idea Pad Z580 Intel Core i5, telephony engine Yate,
and the BTS (YateBTS) were configured (Appendix). Figure 1 depicts the configuration
of a rogue BTS laboratory, and an attacker can use the same hardware and software to
setup the laboratory for numerous attacks. Our goal is to employ rogue BTS to carry out a
series of attacks and then use various digital forensics techniques (Rathod, 2017) to
capture or retrieve crucial artefacts that can be used to verify that the same hardware and
software were used to carry out the attacks.
In the following section, Yate and YateBTS Open Source software is discussed with
different goals.

Figure 1 Rogue BTS lab setup (see online version for colours)

4 Methodology

A laptop, a telephony engine called Yate, the BTS (YateBTS), and a Raspberry Pi 3
model B were used to configure the rogue BTS. The investigator gathers and analyses
information from the devices used by the attacker to replicate the attack. Figure 2(a)
depicts a process for investigating such devices. The investigator must remove the SD
card from the Raspberry Pi and use the FTK imager to produce an image of it. EnCase is
used to collect the files or folders from which the investigator can gather evidence from
the produced image. In the instance of the Raspberry Pi 3, we found key evidence in files
such as bash history, user.log, auth.log, and messages, as shown in Figure 2(a).
In the case of YateBTS, we used manual digital forensics (Rathod and Wangchuk,
2021) procedures to collect the important file. We discovered crucial files such as
BladeRF-cli, cdrfile.conf, ggsn.log, nib.js, tmsidata.conf, and subscribers.conf, as shown
in Figure 2(a).
In Section 6, the importance of gathered evidence in the cases of Raspberry Pi 3 and
YateBTS, as well as their relevance to the case, is explored in depth. The investigator
must demonstrate in court that the attacker simulated an attack utilising the rogue BTS,
which includes a laptop, YateBTS, and Raspberry Pi, and these devices are connected
with each other.
128 A.L. Sankara et al.

Figure 2 (a) Methodology (b) Hashes (see online version for colours)

(a)

(b)

The SD card of the Raspberry Pi 3 was imaged using FTK imager (Dykstra and Sherman,
2012), and the same image was processed using EnCase (Garber, 2001) to extract
evidence, as shown in Figure 3.

5 Recovered artefacts

In this section, we explained the process of extracting evidence from rogue BTS devices
and Raspberry Pi that had been seized, as well as we analysed the devices using various
tools and methodologies to extract as much information as possible.
After acquiring and processing the image file, we must verify the hashes calculated
while acquiring the image and those by EnCase. Figure 2(b) shows that both the hash
value is matched. It will allow to prove to the court that the file has not been modified
during acquisition and analysis.
Forensics of a rogue base transceiver station 129

5.1 Forensics of Raspberry OS (Linux-based OS)


The investigators remove the SD card and use the FTK imager to make the image. The
identical image is analysed with EnCase, and the recovered files containing key evidence
are detailed in the section below.

5.1.1 User bash history


This file contains all the commands typed by the attacker and the investigator can
understand exactly which types of actions were performed by the attacker shown in
Figure 3. We found the following important commands typed by the attacker:
• Command typed: cd/var/www/html/.
• sudo ln-s/usr/local/share/yate/nib_web nib-used to symlink the NIB web user
interface into the apache www folder.
• Grant write permission to the Yate configuration file with: sudo chmod-R
a+w/usr/local/etc/yate.
• The investigator can access the rogue BTS web user interface using http://ip-of-
rpi/nib.
• Command typed: ‘sudo yate’ is used to start the rogue BTS.
• Evidence file: .bash_history from the home directory

Figure 3 User bash history (see online version for colours)


130 A.L. Sankara et al.

5.1.2 Activities
This file contains the list of activities performed by the attacker, activities related to
opening a particular YateBTS configuration file with the exact time and date at which the
operation was carried out, as shown in figure 4.
Attackers altered the Ybts.conf file, which contains parameters inherited from
OpenBTS as well as a few other YBTS-related parameters that were introduced to
regulate the connection between MBTS and YBTS, according to the user.log entries.
Time stamp is very important to re-construct the case.
• Evidence file: /var/log/user.log.

Figure 4 Activities performed by the attacker (see online version for colours)

Figure 5 Log of authentication activities (see online version for colours)


Forensics of a rogue base transceiver station 131

5.1.3 Authentication activities


Using the manner illustrated in Figure 5, we recovered evidence such as where the user
signed in to the Raspberry. The file’s content reveals the IP address from which the SSH
session was started. It is especially critical in circumstances when the attacker used the
internet to carry out the attack.
Figure 5 shows how Pi accepted the password from IP address 10.42.0.1 over SSH
connection, authenticated successfully, and established the session to do more operations.
It is possible that 10.42.0.1 could be the IP address of laptop or desktop computer, for
which investigator need to seize the computer.
• Evidence file: /var/log/auth.log.

5.1.4 System calls messages


All system calls messages were captured in this file, which included the serial number,
manufacturer, and brand of the RF that was used to perform the crime. The Raspberry
kernel machine model: Raspberry Pi 3 model B Rev 1.2 and Raspberry Pi’s MAC
address: sms95xx.macaddr = B8:27:EB:95:8B:E is shown in Figure 6. Figure 7 displays
the manufacturer – Nuand, serial number – d5d3825968478160e185e00745a856b5 and
product – BladeRF is utilised to commit the crime along with time stamp.
• Evidence file: /var/log/messages.

Figure 6 Log shows machine model and MAC address of Raspberry Pi (see online version
for colours)

5.2 Forensics of YateBTS


In this section, we discussed the extraction of evidence from collected YateBTS.
132 A.L. Sankara et al.

Figure 7 Log shows manufacturer, serial number and manufacturer of Raspberry Pi


(see online version for colours)

5.2.1 Binaries of the BladeRF command line interface


It comprises details about the BladeRF (Home – Nuand, 2021) that was connected, as
well as the software version and field-programmable gate array (FPGA) that was loaded
(ld-linux-armhf.so), as seen in Figure 9. This can be used to prove that the BladeRF that
was confiscated was the one that was utilised as an SDR.
• Evidence file: /usr/local/bin/BladeRF-cli.

Figure 9 BladeRF-cli: shows firmware and FPGA (see online version for colours)
Forensics of a rogue base transceiver station 133

The bladeRF-cli utility is used to flash firmware files, load FPGA bitstreams, and
perform other tasks on the Nuand Bladerf software-defined radio system.

5.2.2 Calls logs of connected devices


As seen in Figures 10 and 11, the log file provides evidence of calls such as caller,
receiver, call status (Ringing/Accepted/Rejected…), and duration. If the attacker has only
enabled call logging in the YateBTS setup, this file will be present.
• Evidence file: /usr/local/etc/yate/cdrfile.conf.
• Evidence file: /var/log/yate-cdr.csv.

Figure 10 Location of yate-cdr file (see online version for colours)

Figure 10 shows that call detail records (CDRs) are saved in the yate-cdr.csv file and the
format of the file is format = ${time}, “${billid}”, “${chan}”, “${address}”, “${caller}”,
“${called}”, ${billtime}, ${ringtime}, ${duration}, “${direction}”, “${status}”,
“${reason}” (CDR File Module – Yate Documentation, n.d.). As shown in Figure 11,
column A shows ${time}, column D shows ${address}, column E shows ${caller},
column F shows ${called}, column I shows ${duration}, column J shows ${direction}
and column K shows ${status} which is very important evidence for the investigator to
understand how an attacker simulated attacks.
A (1) (Figure 11) indicates the date and time of the call as 1489149738.254, which is
in Unix epoch time format. Date and time = ((A1 + 19800) / 86400) + 25569 is the
formula for converting epoch to IST date and time.
Where A1 is the epoch number and 19800 is the IST time zone adjustment.
((1489149738.254 + 19800) / 86400) + 25569 = 42804.76.
We have used the format cell functionality of Microsoft Excel with the date and time
option to convert 42804.76 to IST. The final calculated date and time value is 10 March
2017 06:12:18 PM.
134 A.L. Sankara et al.

The investigator can interpret (Figure 11) the call received (K (1)) by mobile number
ended with 0019 mobile number and they talked for 30.143 seconds (I (1)). This evidence
is very important to find out whether a hacker has called whom or received a call from
whom.

Figure 11 Call detail record (see online version for colours)

5.2.3 Internet traffic logs


The internet traffic of mobile phones connected to the BTS depicted in Figure 12 is
stored in this file.
• Evidence file: /usr/local/lib/yate/ggsn.log.
The base IP address allocated to MS.IP is displayed in Figure 12 at line number 0135,
base = 192.168.99.1, line no. 0241 shows a route address to be used for downstream
clients by default; OpenBTS generates this value from the GGSN.MS.IP.Base assuming a
24 bit mask; and line no. 0423 shows DNS servers to be used by downstream clients;
DNS servers are taken from the host system by default (Recent Posts, n.d.). For the
investigator, these are also intriguing pieces of evidence.

5.2.4 Custom SMS sent from BTS


This file contains the attacker’s custom message intended for specific victims. In the case
of malware spreading, the following file (msg_text) can be used to prove that the SMS
received (msisdn) by the victim was sent by the attacker shown in Figure 13.
• Evidence file:/usr/local/share/yate/scripts/nib.js.
Forensics of a rogue base transceiver station 135

Figure 12 Log of internet traffic (see online version for colours)

Figure 13 Custom SMS (see online version for colours)

5.2.5 Temporary mobile subscriber identifier details


This file contains the temporary mobile subscriber identifier (TMSIs) assigned by the
BTS. The file’s content is in the following formats: tmsi, imsi number, country id,
number, shortcut number.
Line no. 0028 indicates the information of the mobile (attacker) connected as a caller
with BTS, and line no. 0112 shows the information of the person to whom he has phoned,
as illustrated in Figure 14. This evidence can be utilised by the investigator to show that
136 A.L. Sankara et al.

the phone was linked to BTS and was used to commit the crime. This information is also
important in cybercrime situations using the IMSI-catcher.
• Evidence file:/usr/local/etc/yate/tmsidata.conf.

Figure 14 TMSI details (see online version for colours)

5.2.6 Subscribers targeted


The information such as IMSI, spoofed number, or short number allocated to the victims
was obtained and is depicted in Figure 15.
• Evidence file:/usr/local/etc/yate/subscribers.conf.
The YateBTS LMI Web GUI (Network in a PC – YateBTS, n.d.) is used by attackers to
set subscribers and adjust regexp. The subscriber data, as well as other crucial details, are
found in the subscribers.conf file by the investigator.
The file has the following format: ‘IMSI’, ‘MSISDN’, ‘short number’, ‘active’, ‘Ki’,
‘OP’, ‘OMSI type’, ‘ICCID’, ‘SMSC’, and ‘OPC’, where IMSI (SIM card identifier) and
mobile station international subscriber directory number (MSISDN) are two important
numbers used to identify a mobile subscriber. Each IMSI uniquely identifies the mobile
station (Javascript NiPC – YateBTS, n.d.). MSISDN also carries a country code in our
situation. The active parameter indicates whether or not a subscriber is permitted to
utilise the service (ON or OFF). When SIMs are written, the KI parameter is either
secretly placed on the card or created. Allows values: empty for 2G IMSIs, zeroes for 3G
IMSIs, OMSI SIM type; permissible values: 2G, 3G, and short numbers – subscribers can
use these to dial each other, and it can be empty or not set.
Forensics of a rogue base transceiver station 137

Figure 15 Targeted subscribers (see online version for colours)

Figure 16 BTS configuration (see online version for colours)

5.2.7 BTS configuration


The attackers’ exact configuration was obtained from this file. Investigators can acquire
BTS details such as MNC, MCC (http://www.mcc-mnc.com/), and LAC as illustrated in
Figure 16 from the evidence obtained from this file, which can be utilised to prove that
specific GSM networks were targeted.
• Evidence file: /usr/local/etc/yate/ybts.conf (Ybts.conf – YateBTS, n.d.).
138 A.L. Sankara et al.

The following are the important parameters that the investigator is interested in: Identity.
MCC stands for mobile country code. The MCC indicates the country, for example, 460
for China and 310 for the USA. Mobile network code (identity, MNC) is a code that
identifies a mobile network and the mobile operator is identified by this code
(CellIdFinder, n.d.). Identity, location area code (LAC) is a unique number within the
current location area. A location area is a collection of base stations grouped together to
improve signalling. A unique LAC is assigned to each BTS unit in multi-BTS networks,
and CellID (CID) – a CID is a generally unique number used to identify each BTS or
sector of a BTS inside a geographic area code.

6 Conclusions and future work

In many nations, GSM is the most frequently utilised telecommunications technology.


Through the deployment of rogue BTS, criminals have begun to exploit vulnerabilities in
the telecommunications system. Simulating a BTS appeared to be prohibitively
expensive, however attackers with minimal abilities can trick users into connecting to the
rogue BTS, believing it to be a legitimate BTS, using technologies like YateBTS and
SDR. The frequency of attacks involving a rogue BTS has risen dramatically in recent
years, posing a significant problem for investigators.
The investigator’s challenge is to get the device from the attacker through any legal
means available, such as a police raid, while also learning about the internal design of
YateBTS and the Raspberry Pi.
To perform a successful investigation, we first setup the lab with the necessary
hardware, including SDR, a Raspberry Pi, and a power bank, as well as software,
including Raspberry Jessie Lite, Nuand BladeRF source code, Nuand BladeRF x40
Firmware, and BTS open source software. Various attacks, such as IMSI catcher, calls/
SMS spoofing, and calls/SMS interception, are used to simulate the attack scenario. To
have a better understanding of the investigator’s perspective, we collected and recovered
evidence from YateBTS and Raspberry Pi utilising digital forensics tools and
technologies such as FTK and EnCase. Important artefacts pertaining to user
authentication, user activity, system calls, messages, call logs, internet traffic logs, and
custom SMS and BTS setups were successfully recovered. We have shown the file
location and types of evidence in considerable detail so that the investigator could
comprehend the artefacts’ location and importance, and then use that information to
reconstruct the crime scene. Law enforcement, computer forensic investigators, and the
digital forensics research community will benefit greatly from the findings of this study.
We will have plan to develop automated tools to find the important evidences with their
location and also interpret the evidence as per investigator requirements.
Forensics of a rogue base transceiver station 139

References
Ahvanooey, M.T., Li, Q., Rabbani, M. and Rajput, A.R. (2017) ‘A survey on smartphones security:
software vulnerabilities, malware, and attacks’, International Journal of Advanced Computer
Science and Applications, Vol. 8, pp.30–45, DOI: 10.14569/IJACSA.2017.081005.
Bertrand, G. (2007) The IP Multimedia Subsystem in Next Generation Networks, Network,
Multimedia and Security Department (RSM)-GET/ENST Bretagne.
CDR File Module – Yate Documentation (n.d.) [online] http://docs.yate.ro/wiki/CDR_File_
Module (accessed January 2021).
CellIdFinder (n.d.) How to Find the Cell ID Location with MCC, MNC, LAC and CellID (CID)
[online] https://cellidfinder.com/articles/how-to-find-cellid-location-with-mcc-mnc-lac-i-
cellid-cid (accessed January 2021).
Cooper, T.A. (2012) Integration of Open-Source GSM Networks, PhD Diss., Virginia Polytechnic
Institute and State University.
Dykstra, J. and Sherman, A.T. (2012) ‘Acquiring forensic evidence from infrastructure-as-a-service
cloud computing: exploring and evaluating tools, trust, and techniques’, Digit. Investig.,
Vol. 9, pp.S90–S98, DOI: 10.1016/j.diin.2012.05.001.
Finley, K. (2016) Out in the Open: This Super-Cheap Cellphone Network Brings Coverage Almost
Anywhere, 6 September 2014 [online] http://www.wired.com/2014/06/openbts/ (accessed 6
August 2016).
Garber, L. (2001) ‘EnCase: a case study in computer-forensic technology’, IEEE Computer
Magazine, January.
Glendrange, M., Hove, K. and Hvideberg, E. (2010) Decoding GSM, Norwegian University of
Science and Technology, Department of Telematics.
Hadžialić, M. and Mušovic, J. (1999) ‘An approach to analyze security of GSM network’, ETSI,
Digital Cellular Telecommunications System (Phase 2), Security-Related Network Functions,
3GPP TS 03.20 version 8.2.0 release.
Hadžialić, M., Škrbić, M., Huseinović, K., Kočan, I., Mušović, J., Hebibović, A. and
Kasumagić, L. (2014) ‘An approach to analyzing the security of GSM network’, in
Telecommunications Forum Telford (TELFOR), IEEE, 22 November, pp.99–102.
Home – Nuand (2021) Nuand, 12 January [online] http://nuand.com/ (accessed 12 January 2021).
Javascript NiPC – YateBTS (n.d.) [online] https://wiki.yatebts.com/index.php/Javascript_
NiPC#subscribers.conf (accessed September 2018).
Jennings, C., Peterson, J. and Rescorla, E. (2016) Authenticated Identity Management in the
Session Initiation Protocol (SIP) draft-ietf-stir-rfc4474bis-09, IETF.
Network in a PC – YateBTS (n.d.) [online] https://wiki.yatebts.com/index.php/Network_in_
a_PC#Web_UI_for_NiPC_Management (accessed September 2018).
Nuand – Configuration of Firmware [online] http://www.nuand.com/fx3/bladeRF_fw_v1.9.1.img
(accessed January 2021).
Nuand – Configuration of FPGA [online] http://www.nuand.com/fpga/v0.1.2/hostedx40.rbf
(accessed January 2021).
Nuand – Setting Up Yate and YateBTS with the BladeRF [online] https://github.com/Nuand/
bladeRF/wiki/Setting-up-Yate-and-YateBTS-with-the-bladeRF (accessed January 2021).
Ooi, J. (2015) IMSI Catchers and Mobile Security [online] https://www.cis.upenn.edu/
currentstudents/undergraduate/courses/documents/EAS499Honors-IMSICatchersandMobile
Security-V18F-1.pdf.
Qasim, T., Durad, M.H., Khan, A., Nazir, F. and Qasim, T. (2018) ‘Detection of signaling system 7
attack in network function virtualization using machine learning’, 15th International Bhurban
Conference on Applied Sciences and Technology (IBCAST), 9–13 January.
Rathod, D. (2017) ‘Web browser forensics: Google Chrome’, Intl. J. Adv. Res. Compu. Sci., Vol. 8,
No. 7, pp.518–522.
140 A.L. Sankara et al.

Rathod, D. and Wangchuk, T. (2021) ‘Forensic and behavior analysis of free android VPNS’,
J. Adv. App. Eng. Tech. and Mang., Vol. 1, No. 1, pp.91–101.
Recent Posts (n.d.) [online] https://forum.yate.ro/index.php?action=recent (accessed September
2018).
Redl, S., Weber, M. and Oliphant, M. (1995) An Introduction to GSM, Artech House, Norwood,
MA, USA.
Song, Y., Zhou, K. and Chen, X. (2012) ‘Fake BTS attacks of GSM system on software radio
platform’, Journal of Network, Vol. 7, No. 2, pp.275–281.
Timberg, C. (2014) Feds to Study Illegal Use of Spy Gear [online] https://www.washingtonpost.
com/blogs/the-switch/wp/2014/08/11/feds-to-study-illegal-use-of-spy-gear
(accessed 12 January 2021).
Volynsky, M. (2012) Spy Games Turn Real as Eavesdropping Technology Spreads [online]
http://www.radio.cz/en/section/curraffrs/spy-games-turn-real-as-eavesdropping-technology-
spreads (accessed 12 January 2021).
YateBTS (n.d.) YateBTS – LTE & GSM Mobile Network Components for MNO & MVNO [online]
http://yatesbts.com/ (accessed September 2018).
Ybts.conf – YateBTS (n.d.) [online] https://wiki.yatebts.com/index.php/Ybts.conf (accessed
September 2018).

Appendix

A.1 Laboratory setup


We used following hardware and software for the laboratory configuration shown in
Figure A1. Setting up a lab reflecting an attacker would be the best thing to be relevant in
our findings.

Figure A1 Laboratory setup (see online version for colours)


Forensics of a rogue base transceiver station 141

A.1.1 Hardware requirements


• A SDR with a frequency band range 800 MHz–1,000 MHz (Nuand BladeRF x40
USB 3.0).
• Two quad-band cellular duck antennas SMA (SubMiniature version A) – (25 metres
radius): GSM/850E.
• 824 to 894 MHz, GSM: 880 to 960 MHz, DCS: 1,710 to 1,880 MHz and PCS: 1,850
to 1,990 MHz.
• A Raspberry Pi 3 model B.
• Power bank with 26,800 mAh capacity.
• The experiment is performed on a laptop Ideapad Z580 Intel Core i5 – 3210M CPU
@ 2.5 GHz with 6 GB RAM and Kali Linux 2017.1 operating system.

A.1.2 Software requirement


• Raspbian Jessie Lite (2016-03-18 and above).
• Nuand BladeRF source code.
• Nuand BladeRF x40 Firmware (1.9.1) and FPGA (0.1.2) [10, 11].
• BTS open source software’s (Yate and YateBTS) (Song et al., 2012).
• The laptop here helps us to connect through SSH to the Raspberry system.

A.1.3 Configuration of YateBTS and Raspberry


• Update the Raspbian OS: apt-get update.
• Install the dependencies: apt-get-y install git telnet apache2 php5 libusb-1.0-0 libusb-
1.0-0-dbg libusb-1.0-0-dev libgsm1 libgsm1-dev cmake automake.
• Connect the SDR to the Raspberry and type dmesg to make sure it is plugged.
• Download Nuand drivers and software’s for BladeRF: wget-c
https://github.com/Nuand/bladeRF/archive/master.zip then unzip it unzip master.zip.
• Move to the following directory: cd bladeRF-master/host/ && mkdir build && cd
build.
• Compile an executable: cmake-DCMAKE_BUILD_TYPE=Release-
DCMAKE_INSTALL_PREFIX=/usr/local-DINSTALL_UDEV_RULES=ON../.
• Build an executable: make – j10.
• Install the executable: make install.
• Create links: ldconfig.
• Running BladeRF command line interface, make the firmware version is 1.9.1 and
the FPGA version is 0.1.2: bladeRF-cli-i.
142 A.L. Sankara et al.

A.1.4 Installation of telephony engine Yate and the BTS (YateBTS)


• Clone YateBTS binaries from GitHub: git clone https://github.com/0patch/Yate-
YateBTS.git SubversiveBTS (Nuand – Setting Up Yate and YateBTS with the
BladeRF, https://github.com/Nuand/bladeRF/wiki/Setting-up-Yate-and-YateBTS-
with-the-bladeRF).
• Move to the following directory and compile an executable: cd SubversiveBTS/yate
&& ./autogen.sh.
• Configure it: ./configure--prefix=/usr/local.
• Build the executable: make – j10.
• Install the executable: make install.
• Create links: ldconfig.
• Move to this directory and compile an executable: cd ../../SubversiveBTS/yatebts
&& ./autogen.sh.
• Configure it: ./configure--prefix=/usr/local.
• Build the executable: make – j10.
• Install the executable: make install.
• Create links: ldconfig.
• Move to this directory: cd/var/www/html/.
• Create symbolic link and attribute rights: ln-s/usr/local/share/yate/nib_web nib &&
chmod-R a+w/usr/local.
• Type: Yate in command line to launch YateBTS and access it through the web
browser at http://ip-raspberry/nib.
• Yate and YateBTS, we are using are compatible with BladeRF x40 only when the
device is running with respective version of firmware and FPGA.
• For configuration of FPGA (Nuand – Configuration of FPGA, http://www.nuand.
com/fpga/v0.1.2/hostedx40.rbf): bladeRF-cli-L hostedx40.rbf-v verbose.
• For configuration of firmware (Nuand – Configuration of Firmware,
http://www.nuand.com/fx3/bladeRF_fw_v1.9.1.img): bladeRF-cli-f
bladeRF_fw_v1.9.1.img-v verbose/etc/yate nib.

View publication stats

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy