Panda Banker hits Italy – Analysis Part 3

Overview

This is the third and last part of the analysis of the Zeus Panda banker discovered inside the network of our customers thanks to our system “CyberAlastair sensor”.
In part 1 we have analyzed the initial infection vector that leverages the old-school Microsoft Office VBA macro to download a .exe from a  C&C. While in part 2 we have formulated a couple of hypothesis about the malware behavior by analyzing the sample statically and we have eventually validated some of them dynamically thanks to a sandbox environment and a manual analysis with a debugger. Moreover, in the latter blog post we have exposed some of the evasion tricks implemented by the malware in order to hinder our analysis, and finally , we managed to arrive at the final payload.

In this last blog post we are going to show the injection mechanism exploited by the binary in order to execute stealthily in a seemingly innocent process, the persistence method used in order to execute the malware even after a reboot of the infected system and a couple of other details about this last stage. Finally, we are going to briefly discuss about the malicious activity that the malware can do inside a system and we provide all the IOC needed in order to discover and defend your environment from this threat.

Process Injection

During tha last phase of the analysis we have discovered that the new binary copied inside C:\Users\%USER%\AppData\Roaming\Notepad++\plugins\config\ launches two new svchost processes.

What is going on here is that the malware is surely exploiting some kind of process injection mechanism in order to execute malicious code inside a clean svchost process. Lots of different process injection techniques exist there and some of them are well documented, these techniques are usually used in order to accomplish 2 objectives:

  1. Evade AV and endpoint security systems.
  2. Excute stealthily on the machine by basically having no process directly related to the malware itself and so hindering a possible forensic analysis.

In order to discover the technique implemented here we are going to use API-Monitor to trace all the WinAPI called by this second stage.
So let’s launch API-Monitor, configure it to trace our program – in this run the dropped binary was called Vim Dark Blue.exe -, start it and continue the tracing until we are going to see the two new svchost processes.

After this, let’s kill the svchost processes -we don’t want to run the malware payload now on our machine- and let’s investigate the WinAPI trace collected.
Searching for a CreateProcess inside the trace show this result:

Investigating the attributes of this call, we can see that this is indeed the creation of the first svchost.exe process and the returned handle for this created process is 0x1e0.
We can also notice that the process is created in SUSPENDED mode since the CreateThreadFlags is set to 0x1 ( THREAD_CREATE_FLAGS_CREATE_SUSPENDED according to the header file ntsapi.h)

Few rows below, some interesting things happen: a couple of NtWriteVirtualMemory with process handle 0x1e0, some NtProtectVirtualMemory with PAGE_EXECUTE_READWRITE permissions -always against the same process- and finally a NtCreateThreadEx followed by a NtResumeThread.

Good, it seems that we have our process injection technique: the malware allocates some memory inside the suspended process svchost, then writes new code inside it, turns that page executable and eventually creates and resumes a new thread as a target of the newly injected code!
It turns out that the same technique is used in order to inject code inside the second svchost.
Now, in addition to this, let’s see inside our debugger what actually the malware has injected. In order to do this, we are going to put a breakpoint on the CreateProcessW and then we run the sample.

We know from the previous analysis of the trace that the malware is going to write something inside this process memory, create a new thread and then resume the execution of that thread in the process.
In order to visualize what is happening, we are going to let the malware create the suspended process, then we spawn ProcessHacker and we visualize its memory mapping.

After that, we are going to put a breakpoint on NtCreateThreadEx and continue the execution.
Let’s now refresh the memory mapping and let’s see what happen.

A new RWX memory region starting from 0x8000 to 0x9bff0 (112kb) has been mapped inside the svchost process address space.
And, guess what, where does the new Thread entry point start? According to the WinApi documentation:

typedef NTSTATUS (WINAPI *LPFUN_NtCreateThreadEx)
(
OUT PHANDLE hThread,
IN ACCESS_MASK DesiredAccess,
IN LPVOID ObjectAttributes,
IN HANDLE ProcessHandle,
IN LPTHREAD_START_ROUTINE lpStartAddress,
IN LPVOID lpParameter,
IN BOOL CreateSuspended,
IN ULONG StackZeroBits,
IN ULONG SizeOfStackCommit,
IN ULONG SizeOfStackReserve,
OUT LPVOID lpBytesBuffer
);

we need to dump the 5th parameter of the stack in order to have this information. It turns out that this address is exactly in that RWX memory region and it is: 0x895bc.

Great, we have the malicious thread entry point into the remote process!
In order to understand what the thread is going to execute, we put a breakpoint on NtResumeThread, then we attach a new instance of the debugger on the svchost process and put another breakpoint on the entry point we have discovered before: 0x895bc.

Finally, let’s resume the execution on Vim Dark Blue.exe and we should hit our break inside the remote process.

Indeed.
It seems that this is a big shellcode that will set up the process to eventually execute the malicious payload of the malware.
We can replicate the same procedure in order to analyze what is injected inside the second svchost process since the injection technique is exactly the same.

Anyway, now that we have covered the injection technique let’s forget this final payload for a moment and let’s focus on another topic: the persistence method exploited by the malware in order to survive a reboot of the system.

Persistence Technique

As you probably know there are lots of persistence techniques.
Unfortunately, we don’t have any information from our sandbox since the sample evades it, so we are going to use a simple trick in order to discover it by leveraging autoruns.exe!
Autoruns is a great tool in the swiss-army-knife of a malware analyst, since it shows you lots of different places in which programs are going to be executed during the startup of the operating system. If we have lazy malware authors, we are probably going to spot the persistence technique implemented here simply by using this tool.

First of all, let’s roll back our machine in a clean state, then we are going to follow the procedure explained in post 2 in order to bypass evasion and let the malware drop our second stage again.
Now let’s open autoruns and when it finishes collecting data on the machine – give it a couple of seconds – we are going to save the current state ( .arn ) with File->Save.

Now let’s run the second stage of the malware, let the two svchost processes spawn and, after this, let’s terminate them.
Now we are going to use the function “Compare” of autoruns.exe in order to compare the current state of the machine with the pre-infection state and let’s see if we can spot any difference.

Well, well, it seems that we have spotted the persistence technique very easily, and yes, we have a lazy malware author here.

Malware Network Traffic

One of the golden prices an analyst can win while reversing such kind of backdoors is the domain/IP of the malware’s C&C, since it allows to develop network signatures useful to defend infrastructures against this threat and eventually issue a takedown of the C&C, in order to stop the malware infection as soon as possible.
During our malware analysis sessions, we want to understand quickly if our sample contacts any C&C and, if so, whether they still answer back with valid data or not; indeed, it sometimes happens that either the campaign is already finished and our bot has been banned, or the C&C has/have already been taken down and so our sample can’t receive any more instructions from the mother ship.

The download of the malware documented in part 1 was in HTTPS, so we expect this behavior also while communicating with C&C.
In order to intercept this, we are going to route all the traffic of the infected Windows VM to another Linux VM in which we have Burpsuite HTTP/HTTPS proxy running; we are also going to install the burp certificate ( .der ) as a Trusted Root Certification Authority inside the Windows victim machine in order to allow our proxy to MITM HTTPS communications, if any.
After this configuration, let’s launch the malware and see if something pops up in Burp.

Yeah, HTTPS network traffic as predicted!
Unfortunately, as we can see, the HTTPS request receives as answer a 502 Bad Gateway: it seems that this C&C is not alive anymore.

After a couple of minutes we can see a couples of other requests:

It seems that the malware tries to contact one of its C&C every 5 minutes. Since we don’t want to spend all the afternoon watching the malware do what it likes, we have forced the algorithm to contact a domain after a fail attempt every 1 minute instead of 5 – we opted for 1 minute since it’s a safe interval that won’t risk destroying any synchronization mechanism inside the malware logic -.
In this way we have extracted in a matter of minutes all the C&C that the malware tries to contact by default:

As we feared, either all the C&C have been taken down or the campaign has ended and the bad guys have switched off the C&C servers. This means that we can’t download dynamic configuration for this sample and we can’t actually see all its actions.

From the HTTPS requests, we can formulate some hypothesis about this initial network traffic of the malware:

  • There is a connection attempt every 5 minutes.
  • URLs are generated dynamically.
  • The body of the POST probably contains the same data – encrypted and encoded in base64 – since its length is always the same.
  • There is a list of pre-configured different C&C servers that the malware uses as a mother ship.

The network information collected in this session regarding the C&C, even though they are not answering back, is really useful to understand if your machine has ever been fully compromised by this Panda banker campaign. In fact, if you spot a 200 OK answer from a request to one of this addresses you can assume that the machine was compromised.

Final Payload & Malware Functionality

As said before, the malicious payloads are injected into the two svchost processes.
Without entering too much into the pure technical details of the code – it would require a separate blog post since there are super interesting things like unpacking procedures and techniques for dynamic resolution of WinAPI – we are more interested here in the big picture of the sample; so let’s investigate a little bit the trace that we have collected with APIMonitor.

We can see that the entry point address of the thread with ID 1 – the first launched by the process – is the one we have discovered during the analysis of the process injection technique. In addition, we see a couple of other threads, chance is that these are launched by Thread 1.
Following this intuition, let’s search for the CreateThread WinAPI inside the trace.

 

Indeed, we can see calls to CreateThread WinAPI related to the other threads discovered in the trace.

Most of the discovered threads don’t detonate since, as said before, we are missing the dynamic configuration from the C&C. However, thanks to the analysis of the traces collected with API monitor, we can formulate a couple of hypotheses:

  • Thread3 is responsible for the persistence mechanism over the infected machine
  • Thread4 activities are strictly related to the webinject features of the malware
  • Thread5 is responsible for contacting the C&C and downloading the dynamic configuration and further infection payloads

The activities of all these threads eventually implement all the malicious tasks that Panda banker is capable of:

  1. Injection of malicious javascript code inside a bank’s site, which is capable of stealing sensitive data used to make further fraudolent transactions.
  2. Credential theft from various software such as browsers and FTP clients.
  3. Possibility to transform the infected machine in a SOCKS proxy to cover other illegal activities of the bad guys.
  4. Drop other malware inside the infrastructure of the victim (as for example ransomware or miners).
  5. Possibility to fully control the machine by exploiting a VNC module.

 

Further investigation and analysis

A couple of interesting analyses have been made during the year 2017 regarding Zeus Panda.
Some of them analyze deeply the payloads and all the dynamic configuration retrieved by the malware during the bootstrap, we strongly recommend the readings to whoever is interested in this kind of threat:

  1. https://cyberwtf.files.wordpress.com/2017/07/panda-whitepaper.pdf
  2. https://blogs.forcepoint.com/security-labs/zeus-panda-delivered-sundown-targets-uk-banks

 

IOC

Dropped file Md5 7D898B1260C0EA760C1DE7D586CF8527
RegKey “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Tysuca”
RegValue “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Tysuca\Ivvuutza”
RegValue “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Tysuca\Oqgiloe”
RegValue “HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\<malware_file>”
Domain contacted 3f4326f29598.cf
Domain contacted 262d65fc7f47.tk
Domain contacted 922b031aac47.tk
Domain contacted 262d65fc7f98.ml
IP contacted  145.239.21.254
IP contacted  89.18.27.155
 IP contacted  155.94.67.27
 IP contacted  94.156.128.207

 

Conclusions

In this series of blog posts, we have analyzed one of the most complex banking trojan in the wild. Its capabilities are not only limited to stealing sensitive information from end users pc, but they can also be a serious threat inside any company network since it can be used as an open backdoor to deploy new malware like ransomware or cryptocurrency miners.

Contact us for any further information: www.inthecyber.com

 

Panda Banker hits Italy – Analysis Part 2

Overview

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
:d
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:

BOOL WINAPI WriteFile(
_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.