I wrote a bit about previous versions of the trojan in several posts:
http://blog.angelalonso.es/2015/10/android-memory-analysis-preparing.html
http://blog.angelalonso.es/2015/10/decrypting-emmental-blowfish-and-base64.html
http://blog.angelalonso.es/2015/10/android-memory-analysis-iii-analyzing.html
http://blog.angelalonso.es/2015/10/malware-analysis-with-androguad.html
http://blog.angelalonso.es/2015/10/reversing-c2c-http-emmental.html
http://blog.angelalonso.es/2015/11/reversing-sms-c-protocol-of-emmental.html
http://blog.angelalonso.es/2015/10/android-memory-analysis-iii-analyzing.html
The sample I got (49a7217ea3af4f4254fe8acbf221263afee24900193870dcc094fac39858e5c4) is not reported in VT yet. However, there are similar samples already reported in VT since few weeks:
3cbe649958ab07238c2e4145f37f04bc4f4fd1e3a12f55129355a72e04ffe8da
c88bb1eb09246e52b009386066da3b3b74a4c3f791a0ccc8d5b641ca5c365d1e
What is new in this version of the malware?
There are several interesting new things that have been introduced in this new version of the malware, but I am going to focus in what I have seen as the most interesting feature: the persistence in the device.
Looking at the initial encrypted configuration file, where all the C&C URL are stored, I see a new field named 'download_url'
$cat config_plain.txt
<?xml version="1.0" encoding="utf-8"?>
<config>
<data rid="25"
shnum10="" shtext10="" shnum5="" shtext5="" shnum3="" shtext3="" shnum1="" shtext1=""
del_dev="0"
url_main="http://mbarbaram.com/Tri-Oval/09291245410kk.php;http://hoteldellenazionimilan.com/wp-includes/main.php"
phone_number=""
download_url="http://hardits.com/seta.apk"
ready_to_bind="0" />
</config>
This field contains a link to another APK. This is really interesting and worth to investigate.
When I installed the APK in my device, the new application "CreditSuisse SMSSecurity" is there
When launching it, I get a new windows which requires 'additional settings to work'
In the accessibility options, it exists now a new option for the CreditSuisse SMSSecurity
Going to that option I can see that it is asking to enable some 'updates', which it is really suspicious
After I have enabled the 'new service', I see a new 'Messaging' application is installed.
At the same time I can see HTTP traffic to the C&Cm but also to the URL configured in the initial configuration which points to the APK (http://hardits.com/seta.apk)
There are now in the system two different new applications with different names running.
root@hammerhead:/ # ps | grep sms
root 20 2 0 0 c01af260 00000000 S smsm_cb_wq
u0_a143 3096 199 1572676 72728 ffffffff b6e6c898 S com.google.smsmms
u0_a143 3173 199 1498728 41028 ffffffff b6e6c898 S com.google.smsmms:remote
u0_a142 30882 199 1529224 65980 ffffffff b6e6c898 S com.google.securesms
u0_a142 31068 199 1501308 49196 ffffffff b6e6c898 S com.google.securesms:remote
com.google.securesms is the first installed application (CreditSuisse SMSSecurity), and com.google.smsmms has been installed by com.google.securesms. However, it looks like only the first one has the proper configuration file MainPref.xml with the C&C
Although, if I uninstall the original 'CreditSuisse SMSSecurity', the MainPref.xml with the C&C appears. But in this case the download_url field pointing to the APK doesn't exist.
After this, the connections to the C&C are normally done.
What's going on here?
- The initial APK fools the user to allow some special 'permissions' in order to perform updates
- Once those 'permissions' are granted, the application installs another 'Messaging application'. The URL of the APK is in the initial configuration file MainPrefs.xml
- This second 'Messaging Application' doesn't do anything and doesn't contain the C&C configuration MainPref.xml file in the beginning
- The second application becomes active and with the MainPref.xml populated once the first application CreditSuisse SMSSecurity is uninstalled in order to guarantee persistence
More to come in next posts :)
