Analysis of Dridex (II) - Analysis of malicious executables with ProcDOT

During the last post I ended up with an executable file downloaded by a malicious macro embedded in a MS Office Word file. This was the first part of the infection.

Dridex has been in the wild for a while and has evolved with the time in order to by-pass security controls and be more difficult to detect. The first phase of the infection, through the weaponization of a MS Office doc, usually has been similar and the main technique has been always to trick and fool the victim in order to enable macros, which afterwards download the executable file.

There is a good paper about the historical analysis of Dridex in terms of the network traffic in SANS reading room.

As I said in the first post I managed to get an executable and along this post I will explain the steps I follow to analyse the executable.

The tools I use:

• Virtual Machine running Windows 7 64bit: where the malware will run.
• Process Monitor (ProcMon): running in the Windows VM machine. This tool captures everything happening in the system (files, registers, processes, threads, etc)
• Wireshark: running in the Windows VM machine. Captures all network traffic in the infected system.
• ProcDOT: Links all the events captured by ProcMon with the captured network traffic in order to create a visual graph which permits to follow up easily the set of steps.

There are several manuals and blogs about how to setup the tools, so I am not going to repeat the same again :-). Some easy going guides are here and here.

The EXE file (1074ba1f0b56d503ff088d31dcb55b1fc8ba2bbc8cd002f4ebcfe617acd6125a) is in VT since yesterday, in case someone want to take a look.

Once we have executed the malware in the VM Machine and the events have been captured with ProcMon, saved as CSV, and we have done the same with the network traffic (exported as .pcap), we can import in in ProcDOT (running in Remnux) as showed in the screenshow below:

Note that I have just renamed the EXE file as 'file.exe' and in the 'Launcher' box this is the process I choose.


Now it is time to produce the graph:



While running ProcDot, on the bottom of the window, I can visualise and follow the set of events the step-by-step.

Following the flow of events it is possible to spot when a new thread is invoked or created by a process:

Or when a thread is injected in a process:

Information about network traffic is gathered:

The interaction with the filesystem is there as well:

 

Anything related to Windows registers (create, accessed, modified):

When a DLL is loaded:

All this information, together with the data from ProcMon (stored in a file) is really key to follow up the infection.

What is this Dridex sample doing?

Preparing the network through accessing several registers

During the first phase, one of the threads of the malware, is in charge of checking the network settings and configure some specificregisters. 

• Read: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings
• Write: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Content\CachePrefix
• "23:12:14.7450229","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Content\CachePrefix","SUCCESS","Type: REG_SZ, Length: 2, Data: ","2372"
• Write: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Cookies\CachePrefix
• "23:12:14.7469883","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Cookies\CachePrefix","SUCCESS","Type: REG_SZ, Length: 16, Data: Cookie:","2372"
• Write: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Cookies\CachePrefix
• "23:12:14.7486601","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\History\CachePrefix","SUCCESS","Type: REG_SZ, Length: 18, Data: Visited:","2372"
• Read HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable
• "23:12:14.7636584","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","2372"
• Read HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\SavedLegacySettings
• "23:12:14.7637494","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\SavedLegacySettings","SUCCESS","Type: REG_BINARY, Length: 184, Data: 46 00 00 00 39 00 00 00 09 00 00 00 00 00 00 00","2372
• Read HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings
• "23:12:14.7638545","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings","SUCCESS","Type: REG_BINARY, Length: 184, Data: 46 00 00 00 21 00 00 00 09 00 00 00 00 00 00 00","2372"
• Write HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable
• "23:12:14.7639128","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","2372"
• Write HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\UNCAsIntranet"
• 23:12:14.7709781","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\UNCAsIntranet","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","2372" 
• Write HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\AutoDetect
• "23:12:14.7709864","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\AutoDetect","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","2372" 

Then there are some access to registers (read, write and delete) related to WPAD (Web Proxy Automatic Discovery). 

"23:12:14.8157365","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecision","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","792"

"23:12:14.8157438","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecisionTime","SUCCESS","Type: REG_BINARY, Length: 8, Data: 70 66 92 08 90 3E D1 01","792"

"23:12:14.8158211","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecisionReason","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","792"

"23:12:14.8159248","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecision","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","792"

"23:12:14.8159318","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionTime","SUCCESS","Type: REG_BINARY, Length: 8, Data: 70 66 92 08 90 3E D1 01","792"

"23:12:14.8159387","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionReason","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","792"

"23:12:14.8160255","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionReason","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","792"

"23:12:14.8160366","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionTime","SUCCESS","Type: REG_BINARY, Length: 8, Data: 70 66 92 08 90 3E D1 01","792"

"23:12:14.8160428","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecision","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","792"

"23:12:14.8158425","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDetectedUrl","NAME NOT FOUND","Length: 144","792"

"23:12:14.8159555","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDetectedUrl","SUCCESS","Type: REG_SZ, Length: 2, Data: ","792"

"23:12:14.8160546","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDetectedUrl","SUCCESS","Type: REG_SZ, Length: 2, Data: ","792"

"23:12:17.4741684","file.exe","4960","RegDeleteValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDetectedUrl","NAME NOT FOUND","","4384"

"23:12:17.4743114","file.exe","4960","RegDeleteValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDetectedUrl","SUCCESS","","4384"

"23:12:17.4744248","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDetectedUrl","NAME NOT FOUND","Length: 144","4384"

"23:12:17.4744675","file.exe","4960","RegDeleteValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDetectedUrl","NAME NOT FOUND","","4384"

Connection to C&C  23.88.104.64 on port 243/TCP

Following to this, the malware connects to the C&C as can be seen in the logs from ProcessMonitor

"23:12:15.0342773","file.exe","4960","TCP Connect","192.168.1.5:49863 -> 23.88.104.64:243","SUCCESS","Length: 0, mss: 1460, sackopt: 0, tsopt: 0, wsopt: 0, rcvwin: 64240, rcvwinscale: 0, sndwinscale: 0, seqnum: 0, connid: 0","0"

"23:12:15.0424283","file.exe","4960","TCP Send","192.168.1.5:49863 -> 23.88.104.64:243","SUCCESS","Length: 160, startime: 243947, endtime: 243947, seqnum: 0, connid: 0","0"

"23:12:15.2373867","file.exe","4960","TCP Receive","192.168.1.5:49863 -> 23.88.104.64:243","SUCCESS","Length: 977, seqnum: 0, connid: 0","0"

During the communication there are some specific items configured, likely as a result of the commands sent by the C&C.

Setting the language List

A register related to the Language is setup as en-US.

"23:12:15.5676959","file.exe","4960","RegSetValue","HKCU\Software\Classes\Local Settings\MuiCache\50\52C64B7E\LanguageList","SUCCESS","Type: REG_MULTI_SZ, Length: 20, Data: en-US, en","2372"

Setting a unique ID to identify the compromised host

A unique ID is assigned in a specific register. 

"23:12:16.5362192","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{99885010-7AE0-0140-9910-EDA8E5CA4696}\ShellFolder\0","SUCCESS","Type: REG_BINARY, Length: 470, Data: A5 EB 36 77 5A 8E 64 34 A4 32 DF 9A D6 E8 78 AA","2372"

Setting WPAD configuration

Some registers for the WPAD are again modified.

23:12:17.4740557","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecisionReason","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","4384"

"23:12:17.4740646","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecisionTime","SUCCESS","Type: REG_BINARY, Length: 8, Data: 79 02 A4 26 98 3E D1 01","4384"

"23:12:17.4741473","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecision","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","4384"

"23:12:17.4742259","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionReason","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","4384"

"23:12:17.4742322","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionTime","SUCCESS","Type: REG_BINARY, Length: 8, Data: 79 02 A4 26 98 3E D1 01","4384"

"23:12:17.4743048","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecision","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","4384"

Downloading a file from the C&C

During the communication with the C&C there is quite a few data transmitted. This looks like the infected host is downloading some file

"23:12:17.7427869","file.exe","4960","TCP Send","192.168.1.5:49864 -> 23.88.104.64:243","SUCCESS","Length: 192, startime: 243974, endtime: 243974, seqnum: 0, connid: 0","0"

"23:12:20.5362365","file.exe","4960","TCP Disconnect","192.168.1.5:49864 -> 23.88.104.64:243","SUCCESS","Length: 0, seqnum: 0, connid: 0","0"

Thread injection

Threat creation and injection into Explorer.exe

Some new thread is created by the main file.exe process.

This new thread is injected in the Explorer.exe:

Then, the Explorer.exe generates another thread: 4755-n164

Temporal file created

There is a temporal file created by the the thread 4755-n164 which has been created by the thread injected into Explorer.exe (4456-n162)

The most suspicious thing here is that the file is stored where all the keys (public/private) keys are stored, which means that the file is a key/certificate.  

"23:12:22.1647265","Explorer.EXE","2960","CreateFile","C:\Users\angel\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-3207478364-1257758836-272776370-1001\50acd1cc9d8c60665c5c9c0c498ede76_88854119-2691-4352-be47-af20ed1e43f7","SUCCESS","Desired Access: Generic Write, Read Attributes, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: S, ShareMode: None, AllocationSize: n/a, OpenResult: Opened","4756"

"23:12:22.1650013","Explorer.EXE","2960","ReadFile","C:\Users\angel\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-3207478364-1257758836-272776370-1001\50acd1cc9d8c60665c5c9c0c498ede76_88854119-2691-4352-be47-af20ed1e43f7","SUCCESS","Offset: 0, Length: 46, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal","4756"

"23:12:22.1652740","Explorer.EXE","2960","SetDispositionInformationFile","C:\Users\angel\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-3207478364-1257758836-272776370-1001\50acd1cc9d8c60665c5c9c0c498ede76_88854119-2691-4352-be47-af20ed1e43f7","SUCCESS","Delete: True","4756"

New threads created and injected TCP/443

Again, several threads are created and injected in other processes. Like for example taskhost.exe

Connection to 41.38.18.230 443/TCP

Later one, there is a HTTPS connection to host 41.38.18.230, however this host responds with RST, which means the port is not open or is being filtered.

Connection to 81.82.210.239 443/TCP

As there is no possibility of connection to the 41.38.18.230, another connection is established with 81.82.210.239 through HTTPS. 

Information of the certificate 

The certificate for 81.82.210.239 is not signed by a valid CA and accessing from any browser will trigger a warning. If we look to the content of the certificate we can see it has been recently created (24/12/2015) which is the same day of the analysis.

Certificated valid from the infected host

But looking to the same certificate from the infected host (Internet Explorer) doesn't trigger any alert. This means that the root CA certificate signing that rogue certificate is already trusted in the system. This is likely why there was a temporal file stored in "Roaming\Microsoft\Crypto\RSA\" 

TCP flow

There is a bunch of traffic with through HTTPs, this traffic likely is due to some file being downloaded.

DLL files 

Temporal file created by Explorer.EXE

As pointed previously, it looks like some file was being downloaded through the HTTPS connection, and later on a temporal file is created.

"23:17:08.3199249","Explorer.EXE","2960","CreateFile","C:\Users\angel\AppData\Local\tRq4VYnd","SUCCESS","Desired Access: Generic Read/Write, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: S, ShareMode: None, AllocationSize: 0, OpenResult: Created","3864"

Fake DLL created

The  temporal is later opened by the DLLHost.exe. Which means is a DLL file. Actually, in the end there is a new DLL named cryptbase.dll. 

This DLL is a valid DLL for Windows 7, however the folder where it has been stored is not valid, which demonstrates this is a fake DLL.

"23:17:10.1100720","DllHost.exe","2704","ReadFile","C:\Users\angel\AppData\Local\tRq4VYnd","SUCCESS","Offset: 0, Length: 3'072, Priority: Normal","3032"

"23:17:10.1101002","DllHost.exe","2704","WriteFile","C:\Windows\System32\sysprep\cryptbase.dll","SUCCESS","Offset: 0, Length: 3'072, Priority: Normal","3032"

Fake DLL loaded

The DLL is loaded which is another phase of the malware infection.

Firewall changes

Some firewall changes are implemented in order to allow any connection for the application Explorer.EXE. 

"23:17:10.9104709","sysprep.exe","748","Process Create","C:\Windows\system32\netsh.exe","SUCCESS","PID: 4416, Command line: netsh advfirewall firewall add rule name=""Core Networking - Multicast Listener Done (ICMPv4-In)"" program=""C:\Windows\Explorer.EXE"" dir=in action=allow protocol=TCP localport=any","352"

DLL and temporal files deleted

After the DLL has been loaded, the files are removed from the sytem

Conclusion

With ProcDot it is really easy to follow up what the malware does. This version of Dridex does the following:

1. Some threads are created in order to check the network settings and perform some specific configuration
2. A TCP connection to 23.88.104.64:243 is established. This is the C&C.
3. While the communication with the C&C some custom settings are configured. A unique ID is assigned to the compromised host through a unique register. 
4. A file is downloaded from the C&C. This file is stored in the repository where all the certificates are stored. Some injected threads are on charge of this
5. A new connection is established to 81.82.210.239 through HTTPS. The certificate used by that server is signed by not trusted CA, however IE on the compromised host doesn't complain about this, which means that the CA certificate has been imported and is trusted. This is basically why there is a file downloaded and stored in step 4. SSL is used to perform the analysis more difficult and to encrypt the communication 
6. During the SSL communication with 81.82.210.239, a new file is downloaded. This file is a DLL file and is loaded by the OS. The name of the DLL is the same than a valid Windows DLL in order, but it is place in a different folder.
7. The DLL and the temporal files are deleted from the system

Next step will be to analyse the DLL downloaded in order understand what it does, as this is the core of the malware.

Reversing the C2C HTTP Emmental communication

In last post l explained how it was possible to decrypt the initial C&C communication from the data dumped from memory, with the support of a python script. In this post, I am going to follow the same approach, but using the information from the captured network traffic.
For that I will capture with Wireshark all the communication with the C&C while the malware is running. Then I can export all the 'objects' in the HTTP connection, which means the content of the HTTP request and response.

Now, I have e in a folder all the files with the objects from the HTTP request:

$ ls main

main(1).php   main(11).php  main(13).php  main(15).php  main(3).php   main(5).php   main(7).php   main(9).php

main(10).php  main(12).php  main(14).php  main(2).php   main(4).php   main(6).php   main(8).php   main.php

$ more main.php

i=McsZtRV7Bv7ZjMSzwk5aIyZEiijP8F38NJcxd5VNElaIVxctxxX9UWCGbUaOIYRxhMxTtA8nBYmT%0A%2FkgJOPilsUZZyvc2swCziOJC5ae17wUorRhyx48b3kIReFjFdcomTsuyE8PNXnthpE3oWi%2F%2BV%2Btg%0AT%2Bcp2CCNstrLbeKReraPgFcgZKAlluZKoVG6SxwgKzzt0MxQFlobMu21L%2BmlA2DJ2pj8buhKtEOs%0AGAH9H6kSzdxaKks6lIynIzHLsLfyIKpHqWeTAynnJdBzcKsCIFeNvWzDdrD7Q3By3JgNN6RrgE2l%0A1z5FuY6CihbBi4hUWN36%2F2Gvtg%2BOpSz6********************zk4US3U2GPhp4C3L5%2FcA4a0nroBhndxpaDIjN4ftS0%0ACxg2100kZN9YsaLUXHvJ6Yg9jY7TJzsd8PhlNq%2FWyl1pP5YoOejbO1cFA7jj0RG%2F9Tp60zj1HpDy%0AIFOb9z5FNRI3JjGh3P4V%2Bg0iVWee2FM5Jk4k2ABcGEK5mS8MJnax3iiLEitzTnYb2zgO2V9uO9Bu%0AMq%2BswCEDk2yLmZJJ1ptAUIwj0pXqchauQ1cbikRrMOD5xTprWuQ62iS6kVtvQosA%2BfnxyresiWbs%0Am4B7s3xb%2BSV7ORouF9tQMk68thyu0NXfnSNJxuXm00FXsXMoFt%2Biw4IbtLLyhPjL3QfpMJqX4X0g%0AMmWMMQ81GIbF5Wv%2FR416%2BRCo%2BXBWDabDnwMWDY0M%2FD3G5DcXa5mVRtDJ8CDQol05s0BH9RsBNQsB%0AMFEev%2BHVGfKFCntlAy2If8lNL5k0Rx39g5QKfGIKEOxbxUfsIe0MG1TEs5ABUZBR3g3Ipz0AY9Ax%0ATekUoKpSdg4l7W7v0DFPoHmKD6WqhpPF%2B%2BFPo2CvkhWRKn0IzWcUbyGK%2Fg6ngmIv2%2F8w8nwSt3w0%0AVEZYdQns5zBFPGo6%2B9pZyceFt77QcBcrTGBheKMCsDlGfua3pGKBcxitkvWWdNmcKEP11TjLkEpb%0A4B83AHatDzOwTmh7iYz07GOU7CQXxI93q65Dc1crEEpH7rycKhc7KUZvkWYcmn8dayifCXDpEr%2Bl%0Akonl7bWWLqGDvFJ617dZ1pe9IGUCLCKmV5aunHGC8Zk9iVwELhfkMEv0a9SoxsnNnUIzSGV5hZZu%0A&s=&

As the HTTP request is URL encoded, I need first to decode it, so I will adapt the python script created in this post to do it automatically. This is the script:


#!/usr/bin/python

from Crypto.Cipher import Blowfish
from Crypto import Random
from struct import pack
from binascii import hexlify, unhexlify
import sys
import urllib

file1 =  sys.argv[1]
file_out = sys.argv[2]

blfs_key =  open('/path/to/the/blfs.key','r')

url_encode = open(file1,'r')
url_encode_2 = url_encode.read()

url_decode = urllib.unquote(url_encode_2).decode('utf8')

file_ciphertext_base64 = url_decode
file_blfs_key = blfs_key.read()
ciphertext_raw = file_ciphertext_base64.decode("base64")

IV = "12345678"
_KEY = file_blfs_key
ciphertext = ciphertext_raw
KEY = hexlify(_KEY)[:50]
cipher = Blowfish.new(KEY, Blowfish.MODE_CBC, IV)
message = cipher.decrypt(ciphertext)
config_plain = open(file_out,'w')
config_plain.write(message)


With this script it is easy to run a shell command with a loop 'for' to decrypt all the files in the directory. Bare in mind than the HTTP response are not URL encoded, so I will not need to perform that step on some of the files. 

Now I should have decrypted all the information from each object. Looking at the first two HTTP POST requests I see this is the case, but for the third one, this is not the case and the data is still encrypted. What's going on here?

I am going to take a look to the HTTP response from the server, what information is being sent?

 A Public Key!! really interesting stuff...

Actually, if I look further in the second HTTP request from the screenshot above I can see the following:


$ more "main(3).php"
a:4....
.....
cjogVGhlIEFuZHJvaWQgUHJvamVjdCB8IGphdmEudmVyc2lvbjogMA==

";s:3:"cmd";s:7:"get_key";s:3:"rid";s:2:"25";s:4:"data";s:0:"";}

This looks to me like the malware sends a request for a key and the server replies with the public key. So the only possibility is that the malware is using that key to encrypt the data so only the C&C can decrypt it with the private key.

To confirm this is the case, I am going to check the source code of the malware with 'androguard' as I explained in previous post.

Looking at the code, I see there is a method with the string 'get_key' and I can see which other method is calling it:


In [10]: d.CLASS_Lorg_thoughtcrime_securesms_h_c.METHOD_c.pretty_show()
########## Method Information
Lorg/thoughtcrime/securesms/h/c;->c()V [access_flags=public]
########## Params
local registers: v0...v2
- return: void
####################
***************************************************************************
c-BB@0x0 :
0  (00000000) const-string        v0, 'get_key'
1  (00000004) const-string        v1, ''
2  (00000008) invoke-virtual      v2, v0, v1, Lorg/thoughtcrime/securesms/h/c;->a(Ljava/lang/String; Ljava/lang/String;)Ljava/lang/String;
3  (0000000e) move-result-object  v0
4  (00000010) iput-object         v0, v2, Lorg/thoughtcrime/securesms/h/c;->c Ljava/lang/String;
5  (00000014) invoke-virtual      v2, Lorg/thoughtcrime/securesms/h/c;->b()Ljava/lang/Boolean;
6  (0000001a) move-result-object  v0
7  (0000001c) invoke-virtual      v0, Ljava/lang/Boolean;->booleanValue()Z
8  (00000022) move-result         v0
9  (00000024) if-eqz              v0, 5 [ c-BB@0x28 c-BB@0x2e ]

c-BB@0x28 :
10 (00000028) invoke-direct       v2, Lorg/thoughtcrime/securesms/h/c;->d()V [ c-BB@0x2e ]

c-BB@0x2e :
11 (0000002e) return-void

***************************************************************************
########## XREF
F: Lorg/thoughtcrime/securesms/h/i; b (Landroid/content/Context;)V be
T: Lorg/thoughtcrime/securesms/h/c; b ()Ljava/lang/Boolean; 14
T: Lorg/thoughtcrime/securesms/h/c; d ()V 28
T: Lorg/thoughtcrime/securesms/h/c; a (Ljava/lang/String; Ljava/lang/String;)Ljava/lang/String; 8

####################

When decompiling the code I end up with some interesting Java methods:

Looking tat the Java code I can see that the public key is used. But also, looking deeper into the code, I find another interesting method:

private String a(String p9)
    {
        String v1_0 = 0;
        String v0_0 = "";
        try {
            javax.crypto.Cipher v2_1 = javax.crypto.Cipher.getInstance("RSA/ECB/PKCS1PADDING");
            v2_1.init(1, this.d);
            String[] v3_2 = this.a(p9, 100);
            java.util.ArrayList v4_2 = new java.util.ArrayList();
            int v5 = v3_2.length;
        } catch (String v1) {
            return this.a.c(v0_0);
        }
        while (v1_0 < v5) {
            v4_2.add(android.util.Base64.encodeToString(v2_1.doFinal(v3_2[v1_0].getBytes()), 0));
            v1_0++;
        }
        v0_0 = android.text.TextUtils.join(".", v4_2);
        return this.a.c(v0_0);

    }

So basically, one method is for encryption and the other for decryption, and both of them are using the same public key. This is really interesting stuff. 

So this is whats going on so far:

1. The compromised device sends the information encrypted with blowfish to the C&C
2. The C&C server replies with OK
3. The compromised device requests the public key
4. The C&C server replies with the public key
5. The compromised device encrypts the information with the public key and sends to the C&C
6. The C&C server can decrypt with it's private key
7. The C&C server sends data encrypted with the private key ->I need to verify this 
8. The compromised device can decrypt with the public key > I need to verify this 

To verify step 6 and 7, and as very quick PoC, I have created some Java code which takes the public key sent by the C&C and try to decrypt the successive messages sent by the C&C.

Bingo! When I run the code I clearly see it works and my 'guess' was right:

What is the information sent by the C&C? it looks like a new config.xml with new C&C URL..
Very interesting..

Looking to the code again,  I see methods which performs the request for a new configuration file:


In [7]: d.CLASS_Lorg_thoughtcrime_securesms_xservices_b.source()
package org.thoughtcrime.securesms.xservices;
 class b extends android.os.AsyncTask {
    android.content.Context a;
    final synthetic org.thoughtcrime.securesms.xservices.XRepeat b;

    public b(org.thoughtcrime.securesms.xservices.XRepeat p1, android.content.Context p2)
    {
        this.b = p1;
        this.a = p2;
        return;
    }

    protected varargs String a(String[] p4)
    {
        org.thoughtcrime.securesms.h.i.a(this.a);
        org.thoughtcrime.securesms.h.i.c("CONF", "Check pull off urls", this.a);
        org.thoughtcrime.securesms.h.i.b(this.a);
        org.thoughtcrime.securesms.h.i.c(this.a);
        org.thoughtcrime.securesms.h.i.c("CONF", "Get config data from server", this.a);
        org.thoughtcrime.securesms.h.i.j(this.a);
        org.thoughtcrime.securesms.h.i.c("DATA", "Send data to server", this.a);
        return "OK";
    }

    protected void a(String p1)
    {
        super.onPostExecute(p1);
        return;
    }

    protected synthetic Object doInBackground(Object[] p2)
    {
        return this.a(((String[]) p2));
    }

    protected synthetic void onPostExecute(Object p1)
    {
        this.a(((String) p1));
        return;
    }

}


As the HTTP request to the C&C are encrypted with the Public key, I can't decrypt it. However, I could check in memory the information before is encrypted.

And this is what I found:

a:2:{s:7:"LogCode";s:4:"CONF";s:7:"LogText";s:27:"Get config data from server";}

Which matches the methods I checked previously :)