Although we developed several other applications to test against the malware analysis services, we conclude this chapter for sake of brevity and lack of significant results observed by these other applications. The applications included:
An SMS application, which inspected a device’s Inbox and Sent SMS messages for phone numbers, date, content, status (e.g., did the message go through and was an incoming message actually viewed) and total number of messages.
A CallHistory application, which inspected a device’s call history (incoming, missed, and outbound) for phone numbers, dates, duration, and total number of calls.
A ContactList application, which inspected a device’s contact list (address book) for names, phone numbers, last time contacted, number of times contacted, email address, and total number of contacts in the address book.
Although some of the services showed zero contacts, zero calls, or zero SMS messages, it wasn’t consistent across the applications or services and therefore could not be relied upon as sole indicators for detection of emulated runtime environments. Additionally, a realistic scenario on a physical device could be that its user had recently deleted all SMS and call history logs. Some of the dates observed across these applications also seemed incorrect, similar to results seen in the LocationGPS and LocationNetwork applications; however, it was not consistent and again, a realistic scenario could be envisioned where a phone call record on a device was from several years ago (this could be partially mitigated by sorting the most recent calls).
MD5 hash values for each APK file submitted of the three applications and additional source code are provided in Appendix A.
Interestingly, and almost as a tip of the hat to the information security community, Andrubis gave results from executing our ContactList application that provided the names of Bob, Alice, and Eve. Their phone numbers are 080–012-3456789, 013– 1337, and 065–031-337, respectively. Sadly, Mallory was left out.
V.
ANDROID EMULATOR EVASION
The previous chapter’s enumeration findings show there are multiple heuristics that a malicious Android app developer could use to determine whether an application he or she created is executing in an emulated environment or on a physical device. This technique allows a malicious app to determine whether it should trigger functionality to execute its malice (because it is executing on a physical device), or if it should trigger evasion techniques (because it is executing in an analysis environment).
This chapter details two proof-of-concept applications that we developed to test evasion techniques on mobile malware analysis services, or—more specifically—on the emulated environments they utilize for mimicking Android devices.
A. METHODOLOGY
Both Android applications we developed for evasion testing first attempt to capture basic values and attributes of sensors, hardware features, or other dynamic resources. These values and attributes are directly accessible through proper Android API method calls and, when required, proper Android permissions declared in the AndroidManifest.xml configuration file. Similar to applications developed for Chapter IV, we do not attempt to circumvent or exploit any Android platform feature for purposes of these tests.
We continued to utilize our EC2 server for logging results sent by the physical devices and the analysis services during our tests. Similar to Chapter IV applications, results are also displayed on the Android device or emulator screen using a TextView object. Several of the services provided screen captures of submitted applications during runtime as part of their resulting report, so this served as a secondary measure for capturing data generated from each service.
During runtime of both applications, we also captured various static heuristics about the device or emulator performing code execution. The Android android.os.Build API provides various public member fields such as
Build.DEVICE, Build.BRAND, Build.MANUFACTURER, Build.MODEL, Build.PRODUCT, Build.BOARD, and Build.VERSION.SDK_INT, which all give some insight as to the type of hardware and operating system version (i.e., Android API level) utilized for executing an application. Although these values in of themselves could be used for detection and evasion, we specifically designed our applications to utilize values and attributes of sensors or other dynamic resources.
Both applications attempt to determine if they are executing on a physical device, and, if so, retrieve the device’s unique ID (i.e., its IMEI, ESN, or MEID value) and send that value to our EC2 server. If the application determines it is executing in an emulated environment, it will not send the device’s unique ID. Of note, sending the device’s unique ID is a common trend associated with malware and aggressive malware, as described in [55] and evidenced in a profile of the NickiSpy.A malware instance detected in 2011 [56].
The remainder of this chapter details each application test and the results observed by running an application on four physical devices (Samsung Galaxy S4, Samsung Galaxy S5, Samsung Galaxy Note 4, and LG Nexus 5) and within seven different analysis services. As mentioned in Chapter III, we chose not to submit any more applications to Joe Sandbox Mobile due to previous bans caused by our failings to adhere to their Terms and Conditions. Additionally, at the time of our testing for these two applications, the Android Sandbox online submission service appeared to be unreachable. We named these applications after the well-known video game Konami Code105
cheat, which appeared in multiple games and is still referenced today as a nod to past gaming culture.106 It involved users entering a sequence of button pushes at a specific time in the gaming (typically the beginning) to unlock a secret cheat (usually in the form of additional player lives being given).
105 Details of the Konami Code can be found at: http://en.wikipedia.org/wiki/Konami_Code. 106 The Google Play Games app even used this cheat to display a hidden message, as described at: http://www.androidpolice.com/2013/07/25/konami-code-easter-egg-discovered-in-google-play-games/.