Panda Banker hits Italy – Analysis Part 2


In part 1 of this series of blog posts about Zeus Panda, we have analyzed the infection vector of the attack explaining how a simple click on “Enable Content” on a seemingly harmless document will trigger the execution of a malicious VBA macro code and consequently the execution of an obfuscated Powershell script that eventually downloads and launches a .exe that represents the second stage of this attack.

In this second blog post we are going to analyze better what the Powershell script has downloaded by showing a possible way to detonate the malware in a controlled environment and expose its mechanism.

Static Analysis

Before any dynamic analysis or automated sandbox analysis, we usually invest a bit of our time to study the sample statically.
This step is usually worth an analyst’s time since it can give you interesting and useful insight into what you are going to ‘fight’; also, this step allows you to start formulating some hypotheses about the malware behavior, its anti-analysis techniques and many other useful hints that will help during a manual dynamic analysis – if needed.

First things first, let’s drop the executable inside PE-Studio in order to perform an initial malware assessment.

The first information that we can grab here is that this is a 32 bit binary with an old compilation timestamp – probably faked – that tries to disguise itself as a legit product with the description: “Initialized Component Authenticated Pocket Syntactic”.

Detection on VT during the last days of the malware campaign – last analysis at 12-12-2017 – is quite low, this probably means that we are going to fight with a malware that will use some tricks in order to remain under the radar of AV – injection techniques, packing, evasion.

Let’s re-submit the sample on VT and let’s see at the time of writing if something changes…

Good, detection on VT is pretty high now. The signatures seem to agree on the fact that this is a Trojan and in particular Zbot – another alias for Zeus – with a mention to Panda.

File version information reveals a product name “CarpalTelemetry” and an owner Company called “Moo0“. It seems that this company actually exists and develops utilities for Windows. However, this can’t be obviously used as attribution since this could be fake.

Let’s now investigate a bit the structure of the PE, starting from its sections.

We have pretty common sections names here, the only thing that we notice is that the .rsrc section has got an entropy value of nearly 7, this could indicate that there are possibly some encrypted resources, let’s check them indeed.

Our hypothesis was correct, we have 5 resources of type “RPDATA” with an interesting high entropy; These binary blobs could contain anything from configuration files for the malware, to new packed code or any other kind of data. However, let’s forget this for a moment, let’s keep in mind that we expect the malware to access this data sooner or later during the execution.

Then, let’s take a look at the imports of the file.

From the list of imports we can formulate a couple of hypotheses:

  1. LoadLibrary and GetProcAddress make us think that the malware will use dynamic resolution of Windows API in order to hide its real imported functions and therefore its real intentions.
  2. CreateToolhelp32Snapshot and Process32Next make us expect that the malware, sooner or later, will enumerate the processes on the system.
  3.  CreateFileW will be used to drop new files on the infected system
  4.  FindResource, LoadResource and WinAPI related to resources in general strengthen our hypothesis that the malware will sooner or later access the encrypted resources.

Obviously, these are only weak hypotheses, but they can give us a first direction in the next steps of the analysis.

Finally, this binary was compiled in debug mode since we have a string that reveals a .pdb path: “C:\Kennel\Typewriter\sees.pdb“.

Now that we have a couple of base hypotheses about our possible enemy’s behavior, it’s time to actually fight him.

Dynamic Analysis | Sandbox 

An automated analysis of a sample inside a sandbox is usually our first approach to understand the malware activity in a system.
We have analyzed the sample inside our own sandbox, however, you can also find a public report here.

The sandbox report is quite bare, no network activity and from the process tree we can see only an execution of a .bat script.

Our sandbox reports us the contents of this .bat as:

@echo off
del /F /Q “C:\Users\******\AppData\Local\Temp\localappdata.exe”
if exist “C:\Users\******\AppData\Local\Temp\localappdata.exe” goto d
del /F “C:\Users\******\AppData\Local\Temp\upd8ad90570.bat”

Well, it seems that the sample deleted itself after basically doing nothing…this smells of evasion!
There are tons of evasion techniques, anyway as a first insight on what are the techniques implemented here, we can use our hypothesis formulated before and take a look into the created file – it is possible to detect an analysis environment by checking for particular files.

Well, well, we have this strange CreateFileW and when checking online for this path, we discover that these are typical checks leveraged in order to discover sandbox environment, interesting.
Additional interesting information regards checks for the presence of the following mutex objects:

It seems that our malware doesn’t want to see Sandboxie and Deep Freeze on the victim machine.

With this new information, it’s time to drop the sample inside a debugger and try to bypass all these evasion techniques to finally reach our goal: seeing the real face of our enemy!

Dynamic Analysis | Debugger

We are going to use x32dbg inside our own VM for malware analysis. Remember to snapshot the VM before any activity and then let’s open the sample and stop the execution at the EntryPoint.

We are going to put breakpoints on the CreateFileW and CreateFileA, then let’s run the sample with F9 until we can see that we are trying to access one of the files we have identified before.

Here we are, the malware checks if popupkiller.exe is inside the system by trying to open it with the CreateFileW functions. Since we have no such file inside our VM this is going to fail, but let’s run it until it returns from this call and let’s see where we are.

The code is really explicit here, it is going to check if the previous CreateFile fails or not and, if it fails, it is going to check the LastError value and expect to see an ERROR_FILE_NOT_FOUND ( 0x2 ) or an ERROR_PATH_NOT_FOUND ( 0x3 ). If the error is not the one expected or the open didn’t fail, it is going to set the bl register to 0x1 and return. This latter variable is used in order to signal the fact that the execution must be terminated since an analyst environment has been detected.

Given that, let’s continue the execution and let’s see if any of these file checks will trigger any of the conditions that the malware expects in order to evade the analysis.

Ah! The check for this file (probably related to the presence of Wireshark on the machine) triggers an ERROR_SEEK that the malware didn’t expect in its checks and this is one of the causes of the termination of the program. We are going to step the code and patch the bl register with 0x0 when it will be set to 0x1 in order to bypass this.

Now, since we don’t know what’s next, let’s put a couple of breakpoints on these functions:

  • CreateToolhelp32Snapshot
  • Process32Next
  • CreateProcess

The first two breaks are justified since we made the hypothesis about process enumeration, the last one is a safe assumption that sooner or later the malware will spawn a new process.

After a hit on CreateToolhelp32Snapshot, if we continue the execution we hit Process32Next. Here the code grabs the name of the process and eventually execute a StrStrI in order to check the name of the process with – in this case – “Wireshark”.

This procedure is repeated for all the processes in the blacklist of the malware:

  • wireshark
  • immunity
  • processhacker
  • processexplorer
  • procmon
  • idaq
  • regshot
  • aut2.exe
  • perl
  • python

We have no process active right now with any of these names, so we can disable breaks on CreateToolhelp32Snapshot/Process32Next and resume execution with F9.

Continuing the execution we hit CreateFile a couple of times again. The malware checks for the presence of these device names related to RegMon:

  • “\\.\REGVXG”
  • “\\\\.\\REGSYS”

Checks related to FileMon:

  • “\\\\.\\FILEVXG”
  •  “\\.\FILEM”

And finally for a device name related to a debugger included in Windows 9x-based platforms

  • “\\.\TRW”

After these checks, the malware drops 4 new files in a subfolder picked from C:\Users\%USER%\AppData\Roaming\, in this run the picked folder is C:\Users\%USER%\AppData\Roaming\Notepad++\plugins\config\ and the 4 files are:

  • data_3.ipo
  • data_3.qiv
  • data_2.ihi
  • Obsidian.exe

The name of these files and the folder picked up are randomly generated and selected with an internal algorithm not documented here.
We expect that sooner or later something will be written inside these files, so let’s put a breakpoint on the function WriteFile and let’s continue the execution.

Bam! Hit the break on the WriteFile, let’s analyze the parameters of this WinApi and let’s see what we are writing inside it.
According to msdn, WriteFile has the following prototype:

_In_ HANDLE hFile,
_In_ LPCVOID lpBuffer,
_In_ DWORD nNumberOfBytesToWrite,
_Out_opt_ LPDWORD lpNumberOfBytesWritten,
_Inout_opt_ LPOVERLAPPED lpOverlapped

dumping the input parameters from the stack we have:

  • hFile: 0x1cc
  •  lpBuffer: 0x390000
  •  nNumberOfBytesToWrite: 0x3f600 ( 259584 bytes )

So we are writing bytes from 0x390000 to 0x3CF600 inside that file.
Following the address in the memory dump, we can see, unsurprisingly, an MZ header and so a full PE file following.

Let’s dump these bytes with the command:

savedata “C:\Users\%USER%\Desktop\dump.exe”,0x390000,0x3f600

finally, let’s open the file with CFFexplorer:

MD5 is identical to the original dropped file, it seems that this was merely an attempt to copy the original file inside the path picked up initially.
Let’s continue the execution.

After some other hits on CreateFile – used in order to check if everything has been set up correctly – the malware calls a CreateProcess with the Obsidian.exe as target.

Finally, two new svchost.exe processes show up, it seems that we have arrived at the final payload! – data_2.exe is the same as obsidian.exe, the name of this copy is random and changes from execution to execution.

We are pretty sure that some kind of injection techniques has been used here in order to have a seemingly legit process called “svchost.exe” executing malware payload instead.
But wait, aren’t we missing something? If the PE launched is exactly the same as before, why the malware changes behavior dynamically? How does it know that it has already made the evasion checks and the initial setup?

Let’s check the two ProcMon traces side by side. The trick that we usually do here is to start from the bottom of the trace and scroll up until the traces are identical, the reason of the divergence should lay more or less there ( don’t get confused, config.exe is always obsidian.exe, but as said before it has another name because it is a different execution )

Ah! It seems that the malware decides to start or not the evasion routine based on that IRP_MJ_QUERY_EA – you can see that in the trace of the original file this query fails and so the malware starts the evasion routine with the checks presented before- but what exactly does this query mean?
Let’s investigate the event a bit:

So this event has been generated by a call to ZwQueryEaFile.
According to MSDN, this API “returns information about extended-attribute (EA) values for a file”.
These are not exactly ADS, tools like AlternateStreamView don’t find anything indeed.

In order to see this attributes, we are going to use EAQuery64:

Bingo, we can see that the newly-copied PE has indeed an EA attribute called “DATA”, while the originally dropped malware has none. In particular, this seems an encrypted binary blob – entropy is indeed quite high:

So, this seems to be the mechanism that our bad guys are using in order to understand whether they need to activate the evasion routines, or whether they have already set up the environment and they have to trigger the machine infection.
We can indeed see the call to NtSetEaFile after the copy of the malware has been created inside the random folder picked up during startup:

This post ends here, in the next one we are going to analyze this new stage of the malware, what process injection techniques are used in order to make the two svchost processes execute malicious code and eventually we are going to do a brief description of the malicious activities that this malware can do on the victim’s machine.

Stay tuned and stay safe.