Gozi, also known as Ursnif or ISFB, is a banking trojan which has been around for a long time and currently multiple variations of the trojan are circulating after its source code got leaked. Every variant that is distributed has interesting aspects, with Gozi version 3 the most eye-catching in the field of detection evasion.
In this blog we will discuss some of the techniques which Gozi V3 uses in an attempt to bypass endpoint defense. Additionally we will also discuss how researchers can use these evasion techniques to their advantage, since they produce a unique and distinctive behavioral pattern.
Gozi’s infection chain
Gozi V3 is distributed via spam mails which link to a malicious file, such as an obfuscated Visual Basic script, which acts as a dropper component. The dropper component downloads and executes an executable with a valid digital signature. We will refer to this executable as the Gozi loader.
The function of this loader is to reach out to the command-and-control (C2) server to retrieve the main Gozi executable. The threat actors behind Gozi try to prevent researchers from interacting with the C2 and obtaining payloads.
One way the Gozi attackers do this is by restricting payload delivery at the server side: The Gozi dropper only works if the IP address of the machine requesting the file geolocates to a region targeted by the malspam (geo restriction), and if the request comes in within a relatively short time frame relative to the start of the spam campaign. This strategy may result in a smaller infection rate, but it avoids the chance that researchers obtain the payload and write detections against it.
If the victim’s machine gets a valid C2 response, the Gozi payload is stored in the registry in the form of a PowerShell script. This fileless technique allows the Gozi threat actors to avoid traditional static (file on disk) detection. Upon system startup the PowerShell script injects the Gozi worker into the explorer process, at which point the infection chain is complete and Gozi again reaches out to the C2 server.
The C2 server this time responds with components which aid Gozi in its money-stealing activities, such as webinjects.
These two stages are described in more detail below.
Hiding in memory
When we take a look at a Gozi V3 loader sample, we can see that it’s protected by a packer in an effort to evade static detection. With the help of IDA’s graph view, we can unpack the Gozi loader by following calls or jumps to registers, which usually are positioned at the bottom of each graph view. The below video illustrates how the loader can quickly be unpacked in IDA’s debugging mode in under a minute.
When we analyze the code at the beginning of the unpacked Gozi loader, we can notice a second stage PE executable being loaded into memory. Parts of the second stage executable have been removed, other parts have been overwritten with null bytes. The image below shows a dump of the memory area after the second stage has been mapped to memory.
As we can see from the image, the ‘DOS header’ has been removed and the PE magic value and section names have been nullified. Other parts of the PE header, such as the compilation timestamp are still present in memory. By performing these actions, Gozi makes it harder to dump the unpacked executable from memory, as most dumping tools search for the DOS header to determine where the executable has been mapped in memory. At the same time, this evasion technique produces a fairly unique memory pattern which endpoint defense solutions could target during a memory scan.
Executing the fileless component
The goal of the second stage loader is to reach out to the C2 server and to store a PowerShell script in the registry. The PowerShell script is executed using forfiles.exe, a Windows component that can be abused to execute a shell instruction in the (process) context of another executable. The forfiles executable is executed with the following argument:
forfiles /p C:\Windows\system32 /s /c "cmd /c @file -ec BASE_64_ENCODED_COMMAND" /m p*ll.*e
where the base64 encoded command decodes to:
iex (gp 'HKCU:\Identities\{4EBA1D2A-127F-6AB1-EE6C-E4061B0483AD}').S
By using the forfiles executable, Gozi may evade certain detection mechanisms which partly rely on the creation of persistency entry (e.g. a scheduled task) which points to a known script engine such as PowerShell or MSHTA. At the same time, the launching of a forfiles executable with an argument to launch PowerShell with the goal of evaluating the contents of a registry key as code makes for a unique pattern which is strong enough to block as a threat.
The fileless PowerShell script which gets executed loads shellcode into memory and executes said shellcode via the QueueUserAPC injection mechanism. The script is slightly obfuscated via Base64 encoding, as can be seen on the following image:
What is interesting to notice is that Base64 decoded contents aren’t passed to the ‘invoke-expression (iex)’ commandlet for evaluation in one go. Instead, the contents are passed in two iterations, which might be done intentionally as it influences the amount of script contents which are passed to the Anti Malware Scan Interface (AMSI) for inspection.
The executed shellcode injects the Gozi worker binary into the explorer process, which results in several new process threads being created inside Explorer. One of the newly created threads looks similar to the “PipeServerThread” which can be found in the leaked Gozi sourcecode.
Summary
In this blog post we have looked at some of the tricks the latest version of Gozi uses to try and bypass defenses:
- protecting C2 assets
- fileless persistence
- patching of mapped executable in memory
- inventive LOLbin usage
- AMSI content chunking
The threat actors behind Gozi are clearly interested in keeping the latest version under the radar. By using the above techniques in addition to only targeting specific GEOs (GB, IT, AU) SophosLabs data shows V3 as less prevalent than V2. Importantly for the defender side the above techniques can often be something of an Achilles heel, providing detection opportunities because of the distinctive characteristics they provide.
Detections
Components of the Gozi malware are reported as one or more of the following definitions in Sophos endpoint detection products:
- HPmal/Gozi-*
- Mal/Ursnif-A and -C
- Mal/EncPk-AOY
Acknowledgments
SophosLabs would like to thank independent malware hunter JamesWT for his contributions towards mapping local Gozi Version 3 campaigns.
