Some of the actors using Gozi / Ursnif take advantage of compromised emails (BEC) to deliver weaponised Microsoft Office documents. This is not new at all, however in the last week I've seen an increase of such attacks. In recent campaigns, the office document contains a macro which spawn a cmd.exe which executes a PowerShell to download the payload.
This could be easily detected with any end-point use case which monitors processes and parent processes.
Also, Gozi can be easily detected via the registry keys as the malware itself is stored there.
The dropped payload from this Gozi version executes some unique PowerShell command in order to persist in the registry key, which can be easily hunt:
Some endpoints solutions have the capability to run searches against Yara rules. In some cases the searches can cover running processes, live memory and specific files within a given folder. A good example is the open source project malscan which permits to scan process in memory. This is really an interesting way to detect malware in end-points.
For details on how Gozi works, there is a good post from Vitali Kremez explaining how recent versions of Gozi works. In essence, Gozi injects a DLL (client.dll) in the explorer.exe process so it is possible to hunt for the URL C2 strings in this process. I already extracted the URL C2 strings in some past blog entry
rule gozi_C2_memory {
meta:
description = "Gozi C2 memory"
author = "@Angelill0 - Angel Alonso Parrizas"
date = "2018-11-19"
strings:
$s1 = /soft=\S+&version=\S+&user=\S+&server=\S+&id=\S+/ // Gozi V2
$s2 = /soft=\S+&user=\S+&server=\S+&id=\S+/ // Gozi V2
$s3 = /soft=\S+&version=\S+&user=\S+&group=\S+&id=\S+/ //Gozi V3
condition:
$s1 or $s2 or $s3
}
Running the Yara rule against an infected system, it is possible to detect the C2 in memory:
