Last week, we released information on a new Trojan affecting Android devices and detailed some of its capabilities and who it affects. In this post we will dive deeper into how Geinimi works and explore the additional capabilities discovered, which include:
- Read and collect SMS messages
- Send and delete selected SMS messages
- Pull all contact information and send it to a remote server (number, name, the time they were last contacted)
- Place a phone call
- Silently download files
- Launch a web browser with a specific URL
While the intent is still undetermined, Geinimi is clearly well equipped to perform malicious activities without a user’s knowledge.
Click here to download a .pdf of the full teardown of the Trojan. The remainder of this post is a summary of the teardown. Both the post and the full teardown are technical in nature and intended for developers and security experts.
Geinimi Teardown Summary
How it starts:
Geinimi has three different methods of starting itself. First the Trojan will launch it’s own Service (a background component of an Android app) prior to the launch of the main Activity (UI dialog) associated with the application. The Service allows the Trojan to start while the host application appears to function normally. The other two ways Geinimi starts revolve around BroadcastReceivers (components of Android apps that start upon certain events occurring). The Trojan will start itself either when an SMS has been received or when the phone starts (BOOT_COMPLETE event). The BroadcastReceiver events can be clearly seen in an infected application’s AndroidManifest.xml (file in Android apps that describes application components):
In order to go undetected, Geinimi uses two anti-analysis methods, encryption and obfuscation, which makes it harder to analyze than previously found Android malware. The authors of Geinimi encrypted the embedded strings within the client and all communications between the client and the remote server to which it tries to connect. The encryption is relatively weak, using a DES cipher with the key of “12345678”. The encrypted strings make static analysis more difficult; instead of seeing the string “&msgType=” referenced in network communications code, we only see the following reference to decrypt an encrypted string:
Command and Control:
The communications between the server and the Trojan are also encrypted using the same key referenced above, resulting in less conspicuous network traffic than if the communications occurred in plain text. While pushing data to the server, the Trojan issues a GET request every five minutes asking for new commands and uses HTTP POST requests to send results of commands. This is illustrated in the following capture from an infected emulator sending an encrypted request for commands to the Command & Control server:
The values in the request for commands can be used by the C&C server to identify information about infected devices. The IMEI and IMSI can be used to uniquely identify the user, as no phone should have the same values for either of these fields. PTID, SALESID, DID and CPID values all appear to be unique for each infected package, possibly to indicate what infected application the user is running. The longitude and latitude can then be used to track the location of this specific user – remember this request is sent every five minutes. Lastly the “sdkver” and “autosdkver” values appear to identify the version of the Trojan. With all this information, the person controlling the C&C server can uniquely identify the location of each infected phone, what version of Geinimi they are running, the infected application they have installed, and most likely issue commands specific for this infected device.
The response payload returned by the server is also encrypted in a similar manner. An XML command list is encrypted with the same DES key and then prepended with the string “himi”. For example, the following XML issues a send SMS command to Geinimi:
After receiving a command, the Trojan will first search for the control string of “himi” and then attempt to decrypt the rest of the bytes using the previously mentioned DES key. After getting the raw XML, Geinimi converts it to a HashMap which it will check against two types of commands.
These commands are then read by the client into a hashmap with the command as the key and the parameter as the value. A command engine within Geinimi then goes through these functions and executes them with the given parameters. We’ve set up our own command and control server to analyze how, and if, all these functions work, and most do. Some of the interesting ones are gathering a list of applications and their activities on the device, sending an SMS to any recipient, deleting SMSes, listing SMSes to specific contacts, listing contacts and their information, calling any number, silently downloading files and launching a web browser with a specific URL.
As we’ve stated before, this is the most sophisticated Android malware we’ve seen to date. The creator(s) attempt to conceal the Trojan from analysis, obfuscate the code and reduce plaintext strings. Click here to see our full teardown of the Trojan, including more specifics on the encryption it uses, how it communicates with and is controlled by the C&C server, and the commands it can perform.