Gone in 60s Malware Analysis Report

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.

Dynamic Analysis

The application was successfully installed into an emulator for performing behavioral analysis.

Application Installed in emulatorFigure 2: Application Installed in emulator

 Emulator Showing Installed Application droidboxFigure 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.

Application Running in the Emulator (1)

Application Running in the Emulator (2)Figure 4: Application Running in the Emulator

Wireshark Captured the Spying HTTP TrafficFigure 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.

Simulating Incoming SMSFigure 6: Simulating Incoming SMS

Encoded POST Request

Figure 7:  Encoded POST Request

Decoded 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.

Suspicious Permission ObservedFigure 9: Suspicious Permission Observed

I de-compiled the application (APK) file into Java Archive file (JAR) for further code analysis

Decompiling DEX CodeFigure 10: De-compiling DEX Code

The major class structure looks like follows:

Extracted Java Class Structure

Figure 11: Extracted Java Class Structure

MyService class file contains functions to extract contacts, messages, call histories, browser URLs etc.

MyService class extracting user data

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.

gone60 self destraction code

Figure 13: gone60 self destraction code

json_class class file upload the user data into the remote server using HTTP calls.

json_class is Uploading to Remote HTTP Server

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.

gi60s information from

Figure 15: gi60s.com information from http://distst.com/domain/gi60s.com

  •  
  •  
  •  
  •  
  •  
  •  
  •  

3 Comments

  1. 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

  2. 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.

Comments are closed.