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