Introduction
It is a common technique for criminals to target gaming applications as a propagation vector for malware distribution. Recently, I observed just such a malicious Android app, which acted as an interesting information stealer and then self-destructed. I took this case to investigate further as an interesting research.
VT Report Statistics
Analysis Report: https://www.virustotal.com/en/file/922741596dde5081760706c653a7b2bd4634c832b648cd3d06f7edca8ea8d1b7/analysis/1380705085/
Figure 1: VT Statistics
Dynamic Analysis
The application was successfully installed into an emulator for performing behavioral analysis.
Figure 2: Application Installed in emulator
Figure 3: Emulator Showing Installed Application
The following suspicious activities were observed from the dynamic analysis.
- The application access user details such as recent call histories, browser cached URLs, messages and contact details
- The application uploads user details into remote server http://gi60s.com/upload.php along with a randomly generated token.
- Once the uploading is done, the application asks for un-installation and gets destroyed by itself.
Figure 4: Application Running in the Emulator
Figure 5: Wireshark Captured the Spying HTTP Traffic
I loaded my emulator with test user details such as SMS, browser cache, contacts etc., and observed the pattern of upload data as follows.
Figure 6: Simulating Incoming SMS
Figure 7: Encoded POST Request
Figure 8: Decoded POST Request
Static Analysis
I converted the APK file into ZIP archive and extracted the file contents. The extracted files contain following items.
- META-INF
- CERT.RSA
- CERT.SF
- MANIFEST.MF
- res
- drawable-hdpi
- drawable-ldpi
- drawable-mdpi
- layout
- classes.dex
- AndroidManifest.xml
These files are certificates, resources, permission manifest file, and DalvikEXecutable(DEX) used in the application.
The AndroidManifest.xml file shows suspicious file permission granted to the application.
Figure 9: Suspicious Permission Observed
I de-compiled the application (APK) file into Java Archive file (JAR) for further code analysis
Figure 10: De-compiling DEX Code
The major class structure looks like follows:
Figure 11: Extracted Java Class Structure
MyService class file contains functions to extract contacts, messages, call histories, browser URLs etc.
Figure 12: MyService class extracting user data
gone60 class deals with functions to confirm the extraction of user details, uploading the stolen details into the remote web server, and self-distraction of the application.
Figure 13: gone60 self destraction code
json_class class file upload the user data into the remote server using HTTP calls.
Figure 14: json_class is Uploading to Remote HTTP Server
Conclusion
The application will extract user information such as contacts, recent call histories, messages, and browser caches. It uninstalls itself after it has successfully uploaded the extracted user data into a remote web server – www.gi60s.com. Symantec classifies this malware as Android.Gonesixty and the detailed reference is given here.
Figure 15: gi60s.com information from http://distst.com/domain/gi60s.com
Kapil Khot
Amazing! Thanks to Sanoop! 🙂
archit mehta
I need little help
Currently I have just started to work in android security , which do some dynamic analysis in phone itself and notify user if there is something wrong . It is my first experience with android
now for example if some app stores password in plaintext or its behaviour is different then what user sees (means some hidden permission ) how can we add something at system level or at application level that can monitor this.
because if I make my own app to do this other app will not allow my app to see its data.
and in your case there is some error in app coding that is why malicious app can steal other app’s data
Chris Stelly
My recent work for my thesis deals with instrumenting the bytecode of applications in order to implement a dynamic permissions model. This way, users can selectively revoke (or grant) permissions for individual applications after installation. This method requires no rooting or boot loading — a solution which would effectively stop this kind of attack.
Thanks for the good write-up.