Co-Authors: Anoop Saldanha and Paul Kimayong
Gozi, also known as Ursnif, is a well-known banking malware. Many variants of the malware family were identified in different attacks after its source code was leaked sometime back. Various instances of Gozi are still active. Criminals have modified the code and distributed it around the web. The sample was seen in one of our customer premises. Here is the hash of the sample.
IOCs
md5:8e29fa5f88ea28e36893f0b82b4d75e3,
sha1:220c38a509a2f0e62b279ad4f140e0aed79f2816
Attack Vector
Gozi is known to spread through spam emails with JavaScript attachments or Microsoft Office documents. Cisco Talos has referred to the spam campaigns in their blog: https://blog.talosintelligence.com/2018/03/gozi-isfb-remains-active-in-2018.html
The recent Gozi malware we discovered arrives downloaded by malicious Office files. These Office files are sent as attachments to spam, such as the example below:
The Office document contains malicious macros and when enabled, it starts executing a PowerShell script to download the Ursnif binary.
In the past, Gozi also arrived via exploit kits.
Installation
When executed, Gozi drops a copy of itself in the %APPDATA%\{random}\{filename}.exe
In our sample, it drops as:
%APPDATA%\{random}\cicsapi.exe
Please note that the filename (cicsapi.exe) may vary per variant of Ursnif.
It also creates an autostart entry:
Gozi’s main module is a DLL which is injected into explorer.exe
After successfully injecting to explorer.exe, the initial executable, cicsapi.exe, terminates. Variants may exhibit slightly different behavior.
Technical Details
Gozi tries to evade analysis by manually “zeroing” out the PE header in memory. This behavior makes investigation more challenging due to the fact that most of the memory analysis tools usually check the PE header when inspecting a memory region.
Gozi itself has many anti-sandbox tricks, but this sample also has a trick embedded in the covering packer layer. This is a sleep mechanism that has not been implemented directly by calling windows API sleep() but instead uses WaitforSingleObject() API with an invalid handle. This is to avoid sandbox detection.
The malware uses multi-level encryption. The malware unpacks by overwriting itself and upon unpacking, you can see a number of strings specific to the Gozi family.
Here is the unpacked file for the studied sample:
Md5:c6a85b251c197cbe25603468c8df9392
sha1:05afa48a229314b9cc3f785499799403e4f3076c
Here is a screenshot of the strings present in the unpacked file:
Gozi creates mailslot with the name “mailslot\ms10”, which is visible in the memory string. Mailslot is meant for interprocess communication, but Gozi tweaked the usage to make debugging harder. Most of the time malware decrypt the code to memory buffer, but here it tries to write it to a mailslot. Standard debugging tools don’t provide a direct mechanism to look at what’s written to the mailslot.
The malware creates a mailslot using CreateMailslot API from one thread. In another thread, it gets handed to mailslot by using CreatFile API with a mailslot name as parameter. Then it writes the decoded buffer to mailslot.
To see what is written into the mailslot, a reverser can change the file name in CreateFile from the mailslot to “C:\out”. Be sure that you manually create a file with that name as parameter to createFile is “OPEN_EXISTING”.
The WriteFile API writes the decoded content into the file “C:\out” and one can easily visualize it. We see that the partially decrypted DLL is written to the file. Looking into the strings, the DLL name seems to be crm.dll.
Hash for crm.dll
MD5:5afedfdd57b7ea0c03977a10f64fd2f4
SHA1:532ad626191e905010a0c00f3878927bcdfa0173
Crm.dll is responsible for further unpacking the payload into memory. But, this is not the final payload. It loads the actual Gozi payload further. The sample has various well-known anti-sandbox features like sleep delay. But, our deep memory inspection feature allows us to identify the payload in case the sample forbids us to execute completely. We can identify a lot of string in memory that has high resemblance to the leaked source code.
Below is a snapshot of one of the memory regions in the malware.If we search for the URL we can see a a number of GitHub forks.
The sample has additional interesting memory strings that show the pattern of CnC communication.
The sample connects to its C2 server:
- Qf1q48wdq1dd[.]net
It communicates to its C2 server via SSL.
There are other strings ie.. PR_Read that indicates that the malware tries to install a hook into browsers like Firefox in order to steal data.
These patterns can be used in intrusion detection signature and yara rules to identify the malware. The malware hooks API’s WSARecv, WSASend in order to intercept network communications.
In addition to its malware, it also has the following capabilities:
- Cookie theft
- Email Credential theft
- Log Browsing Activity
- Keylogging
The stolen data is stored in the %temp% folder as a bin file with random 4-hexadecimal characters as filename, e.g, 676A.bin. It uses mscab.exe tool to archive the stolen data and sends this data to its C2 server.
Detection
Both Juniper Sky ATP and JATP on-prem solutions detect this threat as seen in the screenshots below. Keeping security solutions up-to-date can keep the customer protected against this threat.
