CloudSEK is an artificial intelligence technology-based risk monitoring enterprise, which focuses on customized, intelligent security monitors.
CloudSEK’s SaaS-based products help a client, assess security real-time from the perspective of an attacker 24*7. Our monitors track our client’s various Internet-based resources for potential security risks. Instead of using traditional static threat detection engines and manual verification process our monitors use Artificial Intelligence to identify threats.
The blog is an analysis of some critical information CloudSEK acquired from our data partner.
At CloudSEK we monitor and attribute all potential threats that affect Cloud services. In our previous blog we wrote about a group of attackers code named as Santa-APT that was functioning as a cyber crime unit as well as an APT. This team targeted Cloud servicing vendors as well.
Santa-APT team had multiple games and apps on Playstore as well as other android markets. These games never had all permissions required to do full data theft. The actual malware payloads came as updates. They not only had Android Malware but Blackberry versions too. In this blog we will provide more technical details regarding their payloads.
Screenshot of Santa-APT mobile malware interface.
Part 1 attribution: https://cloudsek.com/harbour-aimed-a-slowen-down-in-singer-city-screening/
As mentioned before, the payloads come in the form of an Update. Here we are sharing the analysis of three different updates [2 for android and 1 for Blackberry] that are used by Santa-APT.
Android SMS stealers:
These updates are for stealing SMS information, similarly they have updates that can perform various other functionalities as mentioned in our previous article.
MD5 (remote.apk) = af543393e0d6da372cd781a928895c79
MD5 (IncomingSMSApp-1.apk) = 5bd71e7b465c1a8435ff0d4b093289
This update steals messages from devices and sends it off to a CNC server. From the looks of it, this is just testing app which will later be integrated to a full-fledged malware.
Sending text message code:
It connects to the backend, which pushes xml. The xmlpullparser modules parses the received xml and executes the tasks in the application accordingly.
Android Call, Camera and GPS collection:
App Name : Android Care
Launcher Display name: update
Malware Class: droidFakePatch
This module has the functionality to collect call, GPS and camera data. This mostly works on triggers. Like lets say the user is in a specific building , then it sends an sms to the Master number. Various other triggers like talking while driving etc is calculated . It is possible from the admin site to configure what all triggers are configured and so on. This data comes from the server in XML format which is parsed by the Spyware app. We have previously documented the controller interface that does this functionality .
While trying to un-install, it gives an intimidating message like below, where in the user thinks that he should be doing something wrong and doesn’t un-install.
This is achieved by fiddling with the android:label section in the androidManifest.xml file.
From the phone dialer, its possible to check if this spyware is running or not by dailing
*#0006#, this must be added for testing purpose.
There is an XML endpoint which gets config data such as “set Master Number” etc. The alerts are sent to this number when a trigger is activated. Following are the data it collects.
A module that steals pretty much everything.
Type: Class file
The application disguises itself as an android secure patch, when installed disappears from the Android Launcher, which convinces the user to believe that the patch would be applied. The app runs as a background service and provides no GUI or App icons for a user to interact with. It monitors for calls, sms, contacts, Images and Videos in the device and connects to a CNC server over network. While reverse engineering the malware, it appears to be well structured and carefully planned.
The app requests permissions for almost all the data it needs to spy on. It also requests for certain system level permissions that would be granted if the device running the app runs an outdated version of android, since some permissions were moved to signature level recently in the latest releases of android.
– make calls and reroute calls
– read and send sms
– read Bookmark, history
– read/write to SDcard
– full network access
– run at startup
– change system settings, prevent sleep, change audio settings etc
Once the application has started, it removes itself from the Launcher Screen and starts the background activity. It achieves this by calling the below API.
Most of application logic is run within the background service. The Controller Class verifies if it’s the first run or not by reading values from shared preferences and issues intents accordingly.
OnStart Method of the MainService Class also registers an Intent Filter for two events, i.e. android.intent.action.SCREEN_ON, android.intent.action.SCREEN_OFF, which enables the application to be aware of the above events while a user turns on and off his mobile device screen.
The app then checks for the SimIMSI number, logs SIM change events and updates its internal database. It also logs the users phone number, the state of the phone etc. and also registers observers for contacts, SMS, images and video as shown below. These observers notify the application in their onChange methods, where there is code to update the new entries in the internal database and later upload it to the CNC.
The application has capabilities for camera, audio, video and call recording which it has permissions for. The data is either stored in the SDcard or within the sandbox and later uploaded to the CNC. The data uploaded is done using plain http, xml data over http as well as by an sftp module.
Most of the structured data; like incoming / outgoing call lists, contacts, SMS, GPS information etc. is stored in the database and uploaded to the CNC when a network connection is available. There are no native binaries used in the application. Shared preferences file is used to maintain the state of service that is run in the background.
Blackberry Malwares :
The group performed operations similar to the android updates for stealing Blackberry users data.
Type: Java archive
Blackberry version of the malware steals the following information.
- Media files
- MMS data
- Audio recording
- GPS location
- Installed applications
The collected data is uploaded and visualised on the same controller that is used by the android malware. The Blackberry malware uses Blackberry APIs . The code flaw and feature sets are all identical to the android malware. A more detailed analysis would be added if required in our next blog.
The group has full-fledged malware capable of spying users in almost all avenues possible. Santa-APT team doesn’t utilize any root / privilege escalation exploits, but makes use of the permissions the user granted it and quietly skims data to the CNC server. Hardcoded server addresses and API endpoints is spread in the binary and the networking module and uses both HTTP and sFTP communication to the CNC. Even though santa-APT had OSX developers and OSX applications, we have not identified any OSX malware form this group.
The target of this APT is so diverse, ranging from government officials, high profile individuals to engineers from technology companies. More attribution , victim informations and artifacts about Santa-APT could be provided on request at [theoracle (-@-) cloudsek.com ]