SMS-Xombie: Android Spyware with a Remote C&C Server
An Android spyware which interacts with a remote C&C server to exfiltrate phone data. Works with the latest SDK (29). Read the full article at here
The app itself contains the following two (2) modules:
Fetcher Service – performs key operations in the background and does not require user interaction;
Autostart Receiver – a component triggered by the boot completion event to invoke the above service.
When the application gets installed and opened, it will register the receiver which will be invoked during Android boot time RECEIVE_BOOT_COMPLETED (after system services get fully loaded that is). The main function of this BroadcastReceiver is to schedule an AlarmManager to start the Fetcher service periodically, thus making it persistent in the device.
Within the Fetcher service, there are several parts of code starting from onStartCommand() which:
Checks or stores permanently a random generated Universal Unique Identifier (UUID) to uniquely identify the device;
Validates device’s network connection and remote server reachability.
Initially, a device GUID is generated to uniquely identify a “zombie”. This ID is later used as a query parameter in its regular GET requests to an API end-point (PHP) which responds JSON encoded data, hence, JsonObject() is used along HttpURLConnection to interact with the API. The response is handled by the onPostExecute() function if the connection was successful and there is a network connectivity as per the isConnected() boolean method.
If everything is correct, the mobile will respond to the task accordingly; whereas to send the data back, I used the Volley HTTP library which makes networking in Android apps easier.
The application itself is a part of a larger system – the Xombie Platform – that we are going to elaborate next. The idea is simple, using a simple SMS message over the GSM network, we are able to control multiple devices that run the APK through the C&C server. The implementation however, is complex due to the following process:
Implementation of a Rasberry Pi device with a GSM shield attached to fetch SMS messages from a controller mobile phone over the GSM network;
Build of an interconnection mechanism between the API and physical device;
The ability to distinguishably process incoming traffic from the other mobile devices and respond with the appropiate content of that device.
For the larger picture, the above procedure is illustrated in the following scheme:
Initially, the controller device sends a command through an SMS message to retrieve all of the mobile phones geographical location (getGeoLocation keyword). The GSM shield, which can operate in Quad 850/900/1800/1900 MHz frequency bands, uses a local SIM card to receive the message, forward the SMS content to the smsXlib API, which then queues the task to the hosting server. Considering the mobile devices sends HTTP requests periodically to check whether there is something to do, in this case, they would immediately send relevant latitude and longitude values as a POST request (given that the user has given the application location service permission).
This app has the following capabilities:
SMS dump (smsdump) – Dumps the entire message history;
Contacts dump (contactsDump) – Dumps the entire contact list;
Call Logs Dump (callsDump) – Dumps call entries;
Geographical Location Fetch (getGeoLocation) – Retrieves device’s current latitude and longitude values;
Application List Dump (appsDump) – Lists user installed applications;
Device Information Retrieval (deviceInfo) – Outputs device hardware and software information;
Usage of this application for attacking targets without prior mutual consent is illegal. It is the end user’s responsibility to obey all applicable local, state and federal laws. I assume no liability and are not responsible for any misuse or damage caused.