MALWARE PROOF ON MOBILE PHONE EXHIBITS BASED ON GSM/GPRS TRACES

Philip Schtz1, Michael Breuer2, Hans Hfken1, Marko Schuba1 1 Aachen University of Applied Sciences, 2State Office of Criminal Investigation North Rhine-Westphalia philip.schuetz@alumni.fh-aachen.de, michael.breuer@polize.nrw.de, hoefken@fh-aachen.de, schuba@fh-aachen.de

ABSTRACT
This paper presents a system for proving the existence of malware on mobile phones that are exhibits in a criminal investigation. The system masquerades as legitimate GSM/GPRS network and thus is able to intercept and process all traffic sent from and received by the mobile. Eavesdropping the complete traffic is important, as mobile malware applications use IP as well as SMSs for communication. Some malware apps even check the type of IP connectivity and require both, GPRS and GSM to be present to work correctly. The proposed system intercepts the traffic in a simulated GSM/GPRS environment and additionally provides a connection to the real or a simulated Internet. After the traffic has been recorded it is post-processed using various filter options and presented in the form of an HTML report for further analysis.

According to McAfee [1] the total number of mobile malware samples in their database has increased from approx. 2,000 to more than 13,000 within a year (cf. figure 1).

Figure 1. Mobile malware samples in McAfees database

KEYWORDS
Malware proof, mobile phone, GSM, GPRS, exhibit, forensics

1 INTRODUCTION Proving the existence of malicious software (malware) on computer systems is a task that many digital forensic investigators have been facing during the last years. The reason is that in cases of computer crime, the machine owners often claim that the computers acted on their own, i.e. must have been infected with malware. In some cases those claims might even be valid, given the fact that close to 100 million unique malware samples were counted by McAfee mid of 2012 [1]. And indeed law enforcement personnel often finds malware on systems; whether the malware found was the reason for the criminal activity the owner is accused of is a different story. The increasing usage of smartphones has opened a new sales channel for the malware industry.

Currently malware developers focus on mobiles based on the Android operating system [1]. Prominent examples of such malware are FakeInst (a variant OpFake will be investigated in the course of this paper), SMSZombie, NotCompatible, Android.Bmaster and LuckyCat [2]. The threat of infection with mobile malware is real as many users download and install mobile applications (apps) not only from trusted but also from untrusted sources. As can be seen from table 1, the total number of downloaded apps is very high and expected to continue to grow in the next years [3]. What is also visible is that users tend to go for the free apps, which increases the malware risk.
Table 1. Mobile appstore downloads, worldwide, 20102016 (millions of downloads) [3]
2011 2012 2013 2014 2015 2016 Free Downloads 22,044 40,599 73,280 119,842 188,946 287,933 Paid-for 2,893 5,018 8,142 11,853 16,430 21,672 Downloads Total Downloads 24,937 45,617 81,422 131,695 205,376 209,605 Free Downloads % 88.4 89.0 90.0 91.0 92.0 93.0

Mobile malware is a new challenge for forensic investigators. Not only do they need to forensically analyse an ever increasing number of new systems, they are also confronted with systems that might be compromised. In some criminal investigations the proof of a mobile malware infection might be crucial to the case. Therefore appropriate methods and tools are important to forensic investigators. 2 MOBILE PHONE MALWARE DETECTION Various methods to detect mobile malware have been developed, often benefiting from the techniques known from computer malware detection. A comprehensive survey on malware detection in general is given by Egele et al. [4]. An overview on mobile phone specific malware description is provided for instance by Schmidt [5]. Both surveys distinguish between static analysis of potential malware, i.e. analyzing the suspicious software without executing it, and dynamic analysis, which executes the software and then observes the softwares behaviour. As a static analysis usually requires the source code of the program to be available or at least to be reverse engineered (e.g. using disassemblers like IDA Pro [6]), the static approach can be ruled out for most forensic investigations, as it is to time consuming. This leaves the dynamic analysis, which can either be performed on the system that is executing the software, e.g. through function call monitoring, function parameter analysis or information flow tracking, (see again [4]), or by monitoring the communication of the system with the environment e.g. out of a sandbox or via network. Some authors compare this difference to host-based intrusion detection systems (HIDS) versus network-based intrusion detection systems (NIDS) [4, 7]. Both types have their pros and cons for malware analysis. The HIDS type can detect anomalies deep in the observed system. On the other hand, malware that controls the system might be able to switch off or trick the mechanisms. The NIDS type on the other hand cannot detect any internal behaviour but solely depends on the communication of the malware. However, as

most malware communicates with the outside (e.g. as part of a botnet), monitoring of the communication is usually sufficient to detect the existence of malware. From a digital forensics perspective the approach to monitor network traffic has the further advantage, that it does not require any additional software on the phone. The only changes which can happen to the evidence come from the execution of the app as such. Therefore all steps taken during the execution should be well documented. Detection of malware through observation of network traffic has been done before. A number of Android apps have for instance been investigated in [8] through recording and analyzing of a mobiles WLAN communication including hijacking of SSL sessions to get access to the unencrypted traffic. Apvrille uses a system based on OpenBTS to sniff the GSM traffic of mobiles and at the same time records the mobiles WLAN traffic for interception of IP packets [9, 10]. As a shortcoming of her solution Apvrille mentions the lack of GPRS traffic support. Without GPRS support devices that do not have built in Wi-Fi cannot be fully analysed. Also, some malware samples explicitly select certein bearers for connectivity to the Internet (see e.g. [11]), i.e. an investigator would also require access to the GPRS traffic to get access to all traffic. The system described in this paper can intercept traffic on the GSM and GPRS interfaces of the mobile, thus overcoming the shortcomings of existing malware detection systems. 3 SETTING UP A GSM/GPRS SYSTEM 3.1 Brief Introduction to GSM/GPRS Networks A simplified architecture of a GSM/GPRS network is depicted in figure 2 (for details see for instance [12]). Note that this figure contains only the most important node types and each node type only once. A real network can consist of multiple nodes of each type.

Figure 2. Simplified GSM network

The base transceiver station (BTS) is responsible for transmitting data over the air interface, i.e. it contains the antenna and manages one or several radio cells of the mobile network. When cell phones are switched on, they register with their GSM network via the nearest BTS, which is selected based on the received signal strength. This process includes subscriber authentication and the calculation of cipher keys for data encryption. The base station controller (BSC) manages several BTSs. Its tasks include the evaluation of measurements done by the BTS and the mobile and related power control adjustments. It also administrates the radio resources on different interfaces. The mobile switching center (MSC) and the visitor location register (VLR) are typically colocated in a single node. The MSC part is essential to establish connections between communicating parties (e.g. the handset and a fixed line telephone) and to route voice data, circuit switched data or SMS. The VLR part is a database in which stores data about subscribers visiting the responsibility area of the MSC. This includes information necessary to (re-)authenticate the subscriber. The home location register (HLR) is the central database of a GSM network. It holds information about subscribers like telephone numbers, service characteristics and the VLR in which subscribers are currently registered. An integral part of the HLR is the authentication center, which stores secret keys and provides challenge and response values to other nodes of the network. As part of the evolution of GSM networks towards UMTS, higher bandwidths and packet switched communication was introduced in the

form of the general packet radio service (GPRS). There are two essential nodes for this service, namely the serving GPRS support node (SGSN) and the gateway GPRS support node (GGSN). The task of the SGSN is to deliver packets to and from the mobiles within a specific geographical service area. It is responsible to route and transfer packets, to authenticate and charge subscribers and to manage a number of other mobility and link related tasks. The GGSN provides Interworking between the GPRS network and other packet switched networks like the Internet. 3.2 GSM/GPRS Network in a Lab Environment To get access to the mobile network traffic of a potentially malware infected mobile, a simple GSM/GPRS network has been set up in a lab environment. Mobiles under investigation can be registered in this network, resulting in isolated and controllable traffic to and from the mobile. To be able to intercept all GSM/GPRS communication different interfaces need to be tapped. For GSM the link between BTS and BSC is a suitable interception point (voice, circuit switched data and SMS), as the traffic is only encrypted on the radio link and passes unencrypted on the wire. The packet switched GPRS traffic is intercepted on the link from the GGSN to the Internet, which carries the normal IP packets that are exchanged between the mobile handset and the Internet. The solution used to set up the simulated GSM/GPRS network consists of two parts: the GSM picocell solution nanoBTS [13] and a sysmoBSC base station controller [14]. Note that the general setup is not new, but similar to many IMSI catcher systems [15] used for instance by law enforcement worldwide with the goal to eavesdrop voice calls of suspects. The system nanoBTS is a complete GSM base transceiver station which supports the delivery of voice, data and SMS to 2G and 3G mobile phones. The deployment is simple, as it only needs a single Ethernet connection for user traffic, signalling and even power. The Ethernet link is connected to the sysmoBSC, an embedded Linux system which runs the OpenBSC software [16]. The OpenBSC software simulates the non-

BTS mobile network components necessary for voice, SMS or GPRS data traffic. For GPRS support, the OpenBSC software uses the Free Software OsmoSGSN [17] and the implementation OpenGGSN [18]. The setup in relation to the simulated nodes is shown in figure 3.

nanoBTS and sysmoBSC are connected via Ethernet hub. Additionally, a PC is connected to the hub to intercept all data between the nodes. Another hub is used to connect the uplink interface of the sysmoBSC with the Internet. This connection is equivalent to the GGSNInternet interface in the simulated GSM/GPRS system. A third port of the second hub is connected to the PC and intercepts all IP traffic coming from or going to the GGSN. Note that the Internet can either be the real Internet or a simulated environment (e.g. a web server). As the mobile phone must be considered to be evidence in a criminal investigation, it is essential to be able to control the communication flow from the Internet to the mobile, as IP traffic directed to the phone could result in unwanted changes of the exhibit. An example is a remote wipe operation, which would destroy all potential evidence on the device. On the other hand, it might also have negative effects to block all traffic from the Internet, as the proof of malware on the mobile might require at least a minimum of communication. It could for instance be necessary to permit TCP handshake messages to pass back to the mobile, as an established TCP connection is the prerequisite to detect malicious data, which is sent over HTTP/TCP. To this end, a firewall is set up between the GGSN and the Internet. This firewall provides the flexibility needed to control and potentially block traffic from the Internet to the mobile under investigation. Note also that it is quite simple in the given system to send SMSs to the mobile that could trigger malware reactions (e.g. sending a copy of a received SMS to an attacker). 4 GSM TRAFFIC RECORDING, ANALYSIS AND REPORTING The software to intercept and further process traffic is called Mobile Wiretap. It runs on the PC of the system shown in figure 4. The process implemented by the software is split into several phases, which are depicted in figure 5.
Log User Interaction

Figure 3. System setup with real BTS connected to a simulated mobile network

To permit normal mobile phones to register with the simulated system, the international mobile subscriber identity (IMSI) needs to be configured in the HLR part of OpenBSC. This is done via a command line interface which also allows the configuration of the mobile network code (MNC), the mobile country code (MCC) and the name of the network. When operating such a network with a real BTS in a lab, interference with normal GSM/GPRS networks needs to be prevented. To this end the system could either be operated in a Faraday cage or as in the presented solution use a resistor as dummy load for the antenna, thus limiting the signal to a few meters maximum. The complete laboratory system setup is depicted in figure 4.

Start

Insert Case Data

Record Data Traffic

Generate Report

Stop

Figure 4. System setup Figure 5. Mobile Wiretap process

After program start, the investigator enters case specific data including information about investigator, a case identifier, evidence identifier and the type of mobile under investigation. The respective Mobile Wiretap GUI is shown in figure 6.

investigator to determine the timestamps of all packets in the trace files. On the other hand the Log User Interaction part (cf. figure 5) allows the investigator to log the timestamps of the manual interactions with the mobile. To this end the investigator first enters a short description of the planned interaction in the GUI. After that, she simultaneously executes the action on the mobile (e.g. clicks on a button) and at the same time presses the Enter button on the PC, which logs the timestamps with the short description entered before. Tests done by the authors showed that this kind of manual synchronization between activities on the phone and the generated traffic is sufficient to correlate causes and effects. Apart from the correlation of timestamps it also documents the interaction with the evidence and thus complements the existing chain of custody. Figure 7 shows the respective interface for logging the interactions.

Figure 6. Case data insertion

Once the data has been inserted the malware detection test can begin. Firstly, recording of traffic on the two previously mentioned interfaces is turned on. The recording is done by a program called tshark [19], which is a textbased variant of the well known program Wireshark [20] and is distributed with the Wireshark installation package. As tshark is able to record traffic on several interfaces simultaneously, both GSM and GPRS traffic can be logged in the same trace file. In a second step the investigator starts the suspicious app on the mobile and interacts with it, trying to provoke the application to start malicious activities that become visible in the traffic generated by the mobile (e.g. sending a premium SMS). In order to being able to correlate the investigators interactions with the intercepted traffic, different timestamps are logged as part of the process. On the one hand, the start and end time of the tshark recording is logged, which enables the

Figure 7. Logging user interactions

After the last interaction of a test has been executed the investigator waits for a short time period to allow for the last data to travel back and forth over the links - and then stops traffic recording. In a next step the investigator can store the test results in a report. Mobile Wiretaps reports currently contain different data about the test, including statistics of intercepted data, an overview of all IP connections, SMSs, calls and actions of the investigator. Special focus is put on HTTP requests and SMSs, which often transport data from the mobile phone to an attacker. Therefore, both types of data have their

own section in the report in which details of the data are described. To extract both data types from the traces the filter capabilities of the tshark are integrated into the Mobile Wiretap software on the PC. Based on all extracted data an HTML report is generated, which can be further analysed by the investigator. Note that this final analysis part of the malware detection process is not covered by the implementation but requires further manual work. Figure 8 shows an example of a report generated by the software.

a Speeddating app (which was confirmed). The second app shortcut opens another web page. After these activities, the test was stopped, the report generated and the analysis of the intercepted traffic began. 5.1 IP Addresses The generated report shows that during the short test period described above a total of 966 IP packets were sent and received. 34 of those were normal packets of the local environment, including DHCP messages, time synchronization and DNS queries. Of the remaining ones 775 packets were exchanged with the server aristole.timeweb.ru, which was the server from which the Speeddating app was downloaded. The domain is registered to a Russian web hosting provider. Another 157 packets were exchanged with servers in the IP address range 93.170.107.0. 5.2 HTTP Requests The HTTP Requests section of the report gives more details on the IP packets transporting HTTP traffic, a method often used by malware to transport information to a server. The data to be transported is usually encoded in the URL (GET request or are transmitted via POST. The tested OpFake malware accesses a number of URLs, most of them in the background i.e. not visible to the user. After a more detailed analysis of the recorded traffic with Wireshark, the following URLs turn out to be the most interesting from a malware perspective and will be analyzed separately. (1) http://m-l1g.net/q.php (2) http://gogos1.net/index.php (3) http://friends4mobi.com/get.php An examination of packets sent to (1) discloses that phone data is exfiltrated and sent via HTTP POST to a PHP script on the server side. The Wireshark trace depicted in figure 9 shows a part of the encoded data of the transmitted data. Figure 10 shows the complete set of data from the HTTP request in decoded form.

Figure 8. Report generated by the software

5 ANALYSIS OF AN EXAMPLE APP To demonstrate proper functioning of the setup, tests on various malware samples and devices were executed. This section presents the findings of one of those tests, for which the widely distributed Android malware OpFake was used [21]. OpFake masquerades as legitimate app or content and thus is installed and executed by the user herself, who for instance thinks that she is installing Opera Mini. The OpFake sample tested was downloaded from [22], which provides a collection of malware samples for further analysis. The sample was installed using the Android Debug Bridge (ADB) on a previously master reset Samsung Galaxy SL with Android OS version 2.2.1. When the OpFake-infected app is started, a web page is opened automatically, asking the user to insert some credentials. Independent of the given input,the app continues and adds two new app shortcuts to the home screen of the phone. When the first one is clicked, the user is asked to install

mobile is transmitted (cf. rows 1-2 of figure 10). Row 4 points to an HTML file on the local system, which could be analyzed further. The main part of the POST request (rows 7 ff.) gives a strong indication of the malwares purpose: sending (premium) SMS. The malicious code for instance sets a limit of SMSs to be sent (max_send = 100), tracks the number of SMSs sent already (sendCount = 3, curLimit = 97) and uses a number of other variables to control the handling of SMSs. Using those settings a fine granular control of the malware behaviour is possible and detection by the user can be delayed, as the number of premium SMSs sent in a certain time period can be limited. Further down (rows 14 ff.) the decoded data indicates that the three SMSs were sent to the numbers 2858, 9151 and 7151, which can be used as a filter for potential SMSs in the rest of the Wireshark trace (see section 5.3). The second URL is a POST request as well (2). The data transferred in this request contain the IMEI, IMSI and phone number. The third URL (3) initiates the download of the an app installation file SpeedDating.apk, which triggers the user prompt that has already been mentioned. The test was stopped after installation of this app without further analysis of its potentially malicious behaviour. 5.3 SMS The Wireshark analysis of the SMSs sent by the mobile confirms the examination of the HTTP request related to the first URL (1): three SMSs with the numbers identified in section 5.2 were indeed sent (cf. figure 11). Internet research related to the three numbers reveals that they are phone numbers for Russion premium SMSs services. The prices seem to depend on the victims provider and have a maximum charge according to table 2 (in Rubels and Euro respectively).

Figure 9. Wireshark trace with exfiltrated data (highlighted in the frame at the bottom right corner)
1 log901700000000668=901700000000668 log.v1.0.2853: 2 Android version: REL 2.2.1, SDK: 8; Board: GT-I9003; Brand: samsung; Device: GT-I9003; Display: FROYO.XWKB1; Fingerprint: samsung/GT-I9003 /GT-I9003/GT-I9003:2.2.1/FROYO/XWKB1:user/release-keys; Host: SE-S608 ; ID: FROYO; Manufacturer: samsung; Model: GT-I9003; Product: GTI9003; Tags: release-keys; Type: user; User: root; Battery: 86%; Operator: XXX; Internet connection: trueAAAAA Alpha start 3 4 JJJJJ Executing URL: file:///android_asset/payed.html 5 6 7 JJJJJ JSHandler.sendSMS 8 9 10 SSSSS Start sending: 11 SSSSS max_send = 100, p_count = 0, p_time = 0, max_cost = false, final_send = false, final_count = 0, final_time = 0, numbers_count = 3 12 SSSSS curLimit = 97, sendLimit = 97, sendCount = 3 13 14 sssss Sending one sms curSms = 1, number: 2858, text: 701233671509131159834802 15 sssss success sending sms 16 17 ccccc Checking if another one sms can be sent: 18 ccccc curLimit = 96, curReceived = 0, lastReceived = false, circleReceived = false 19 20 sssss Sending one sms curSms = 2, number: 9151, text: 783413671412741159828912 21 sssss success sending sms 22 23 ccccc Checking if another one sms can be sent: 24 ccccc curLimit = 95, curReceived = 0, lastReceived = false, circleReceived = false 25 26 sssss Sending one sms curSms = 3, number: 7151, text: 701363671537161159870182 27 sssss success sending sms 28 29 ccccc Checking if another one sms can be sent: 30 ccccc curLimit = 94, curReceived = 0, lastReceived = false, circleReceived = false 31 32 FFFFF Circle stop sending 33 FFFFF Stop sending

Figure 10. Decoded data of the HTTP request

The transmitted data includes the IMSI and other detailed information about the infected device and its OS. Even the charging status of the

effectiveness of the approach needs to be proven in the field, i.e. demonstrating the usefulness beyond the few application cases in a research lab. 7 REFERENCES
1. McAfee Labs, McAfee Threats Report: Second Quarter 2012, 46 (2012). 2. Top 5 Deadliest Mobile Malware Threats Of 2012, http://www.darkreading.com/mobilesecurity/16790111 3/security/news/240006056/top-5-deadliest-mobile-mal ware-threats-of-2012.html (August 2012). 3. Gartner, www.gartner.com/newsroom/id/2153215, (September 2012). 4. Egele M., Scholte, T., Kirda, E., Kruegel, C.: A Survey on Automated Dynamic Malware Analysis Techniques and Tools, Journal ACM Computing Surveys, Volume 44, Issue 2, 149 (February 2012). 5. Schmidt, A.: Detection of Smartphone Malware, Dissertation, TU Berlin (2011). 6. IDA Pro, https://www.hex-rays.com/index.shtml. 7. Burguera, I., Zurutuza, U., Nadjm-Tehrani, S.: Crowdroid: Behavior-Based Malware Detection System for Android, SPSM11, Chicago, Illinois, USA (October 2011). 8. Stahl, M., Galauner, A.: Analysis of the communication of Android apps, http://www.itforensik.fh-aachen.de/images/download/WS2012/ 2012_stahl_galauner.pdf (in German), 2. IT-Forensik Workshop, Aachen, Germany (April 2012). 9. Apvrille, A.: An OpenBTS GSM Repplication Jail for Mobile Malware, Virus Bulletin Conference, Barcelona (2011). 10. RangeNetworks OpenBTS, http://wush.net/trac/ rangepublic. 11. Apvrille, A.: Symbian worm Yxes: towards mobile botnets?, Journal in Computer Virology, Volume 8, Issue 4, 117--131 (November 2012). 12. Heine, G., Sagkob, H.: GPRS Gateway to Third Generation Mobile Networks, Artech House Mobile Communication Series (2003). 13. nanoGSM The worlds most deployed GSM picocell, http://www.ipaccess.com/en/nanoGSM-picocell. 14. sysmoBSC, http://www.sysmocom.de/products/ sysmobsc-base-station-controller. 15. Piper, F., Walker, M.: Cryptographic solutions for voice telephony and GSM, Network Security, Volume 1998, Issue 12, 1419 (December 1998). 16. OpenBSC, http://openbsc.osmocom.org/trac/wiki /OpenBSC. 17. osmo-sgsn, http://openbsc.osmocom.org/trac/wiki/ osmo-sgsn. 18. OpenGGSN, http://sourceforge.net/projects/ggsn/. 19. tshark, http://www.wireshark.org/docs/man-pages/ tshark.html. 20. Wireshark, http://www.wireshark.org/. 21. Suenaga, M.: Android.Opfake In-Depth, Symantec Security Response (2012). 22. Contagio malware dump, http://contagiominidump. blogspot.com/.

Figure 11. Wireshark trace of the SMS (type, address and content are highlighted) Table 2. Maximum prices of sent premium SMSs

Number 2858 7151 9151

max. price in RUB 146.32 45.01 200.60

max. price in EUR 3.62 1.11 4.96

Based on the prices indicated in the table the total cost for a victim can be estimated to almost 500 Euro for 100 SMSs in the worst case. 6 CONCLUSION The system presented in this paper helps to provide evidence for malware on mobile exhibits by recording and pre-processing the GSM/GPRS traffic generated by the phone. As malware usually communicates with the outside world such an approach will be sufficient in many cases as long as the investigator is able to trigger respective malware communication activities and can identify such activities in the reports and traces generated by the Mobile Wiretap software. The system is inexpensive as well as easy to set up and use. Therefore, it can be considered as a suitable alternative to more expensive and time consuming setups and techniques like reverse engineering of suspicious apps. A possible improvement of the Mobile Wiretap software would be an automation of the report analysis (e.g. by including filters for keywords). Also the