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.
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.
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.
