RTF-Embedded malware performing process hollowing

The sample was delivered (embedded)
through a weaponized RTF file in form of an email, which seems to be coming
from some server hosted by the eigbox.net .

Evasion and Obfuscation:

The sample was well obfuscated and had
multiple encryption routines to hide the system calls. It has most probably
used some sort of .NET code obfuscator to obfuscate the code to hell!

I faced multiple challenges while
reversing this piece, first being finding a good free .NET debugger, which I
somewhat found in form of DILE (Dot NET IL Editor). Thanks to Petrény Zsolt for
that. The other challenge was to de-obfuscate the code, which took me a while,
and for that I had to identify the purpose of each obfuscated function call and
then remember that. The sample also tries to evade analysis by sleeping
multiple times in between the communication and prior to that at multiple
points.

TTP:

The sample deploys the process
hollowing technique to run in suspended state, hollow out a process, allocates
memory to the hollowed out process, writes to the process memory, set the
thread context and resume the thread. Since I was using DILE I could not figure
out a way to attach the debugger to the suspended process so instead I used the volatility framework to dump the injected process out of the memory image of the analysis VM.

Following it the SMTP header,
extracted from the email security gateway:

Recently a lot of email based malware are being delivered through eigbox.net domain:

McAfee identifies the sample as Zbot:

Following is the malicious email with the rtf attached

On preview of the attachment we can see the two embedded
binaries but with misleading icons to fool the user in thinking that these are
attached excel and word documents. That is why it is always a good idea to
preview the attachments before opening them.

I used the rtfobj python script from the oletools suit to
extract the binary objects from the rtf

Performing a cat on one of the extracted binary artifact,
and piping the output to a hexdump cmd, clearly shows the MZ. See the
highlighted offset in the hexdump, which is from where we need to carve the
binary out.

The offset value is d2 which is 210 in decimal

Using the good old dd tool, we are able to carve out our PE
file from the bin file (skipping the first 211 bytes) and outputting to
pe1.exe. Running the file command on the carved out file shows that this is a
Win 32 binary coded and compiled using .NET framework:

We go on and perform the same carving activity for the rest
of the binary objects (some of them are just false positives).

Another good and easier tool to carve out these binary files
was rtfscan from the OfficeMalScanner toolkit, which also gave us two binaries:

The OfficeMalScanner (info mode) is run against the
extracted binary files to see if any further embedded objects like macros etc
are present:

Performing a
dynamic analysis:

I chose to click on the Excel icon and execute it in the VM
to analyze the dynamics of the sample. Windows security warning appears and
therefore this attack relies on social engineering for its success:

Doing a packet analysis reveals that the sample communicates
with the google DNS servers for resolution of the C2 domains
(goodnews.no-ip.biz and 1goodnews.dyndns.biz). I gateway-ed all sample traffic
from the infected VM to a honeypot VM and used fakeDNS to reply to the sample’s
DNS queries.

It seemed that the sample was trying to perform a TCP
handshake on port 6625:

In order to have the three-way TCP handshake complete
successfully, I start nc listener on the honeypot VM and notice the traffic
coming from the sample, which seems to be encrypted or could be some encoded
message to the C2 server.

This is the TCP conversation extracted from the Wireshark:

Going through the process hacker’s process tree view we can
see multiple processes spawned out of the malicious parent process, including:
Net Work.exe, cmd.exe/conhost.exe, timeout.exe. Further down the article we
will see the sequence of these spawned processes.

As part of the dynamic
analysis, registry writes are discovered. It can be seen that the dropped
binary “file.exe” is being made persistent:

We can see that the path shown in the screen shot above is
\appdata\roaming\foldername. The folder “FolderName” is created with hidden
attributes to avoid detection, as seen below. You can also see the dropped “Net
Work.exe” binary

Within the hidden “FolderName” folder, we can also see some
other dropped files including a batch file:

From the screenshots below, you can see that the MD5 for
both the dropped file “file.exe” and the binary object extracted by the
OfficeMalScanner matches:

Having a look inside the batch file:

We
can see that the batch file starts in the _Start block and there is wait/pause of
300 seconds (5 minutes). This is also visible in form of argument to the
“timeout.exe” process in the “Process Hacker” tool, when mouse is hovered above
the timeout.exe process. This implies that timeout.exe runs because of the
batch script which is executed by the malware

In the batch file the tasklist
runs to check all the running processes and the imagename “Net Work.exe” is
sought in the result of tasklist. The “|” directs the output of the searching
tasklist (with columns suppressed) with imagename filter of “Net Work.exe”, to
the find command. The find commands is looking for the string “Net Work.exe” in
the output and the whole result is redirected to NUL (so nothing is displayed). Then we see an “&&”,
which means that Goto _Start block only if the previous command was successful
and did not return any error code. Then we see that the batch file is to run
another command “Start /W “” “c:\users\rem\appdata\roaming\foldername\file.exe”
only if the previous commands has failed (that is Net Work.exe did not start).

So basically this is an infinite loop whereby after every 5
minutes it is checked that “Net Work.exe” process is running and if it is not
running then the file.exe in the hidden folder is executed which will again
kick start the “Net Work.exe”. This continues indefinitely. We can see the
“timeout.exe” also running.

Once I terminate the “Net Work.exe” process, exactly after
300 seconds the batch process started file.exe which in turns starts “Net
Work.exe” again. This can be seen below:

After a while the file.exe terminates itself and Net
Work.exe and the batch files keep running. This is a typical persistence
mechanism.

We can see the file activity summary of the sample
execution:

We can see the files created above. As a backup persistence
mechanism the file.exe is also added to the “Startup” folder. Some files were
created and renamed/deleted. All the files in the temp folders were deleted
after a while. Another peculiar file “run.dat” is also created:

Another
mechanism of persistence is deployed where we can see the Winlogon/Shell key
being written

Some other HKCU entries written to:

We can see the file.exe dropped also in the startup folder
for persistence:

Now let us examine the dropped file.exe. From various tools
we can see that this is a .NET compiled binary:

After a brief search I discovered DILE, the free .NET
debugger, which is not really a comprehensive debugger, but in any case it
helped me to some extent for debugging:

Dynamic Code
Analysis using DILE

The sample made system calls to get the filepath for itself:

It also make queries to get the environment variables, like
WINDIR, APPDATA etc:

Next we see that the path is being formulated to drop “Net
Work.exe”:

We can see multiple level of obfuscation in the code below,
where function names and class names are obfuscated:

You remember the strange communication to port 6625? We can see the port being built:

We can see this port being created as 0x19 (25) and 0x42
(66)

All processes running on the machine are enumerated by the
sample

The OSversion is found out:

The process names are compared against a certain “NS”
string, where the sample is most probably looking to see if a certain process
is running or not.

Several of the following sleep calls are encountered
throughout the analysis. Most probably to evade sandbox analysis:

One of the interesting functions “#Gb” is used throughout
the code on several occasions and its main purpose is reading from the sample’s
memory stream on certain offsets and then performs AES (Rijndael) decryption of
the selected memory area using salt value “MySaltValue”, and password as the
Chinese characters (at least I think it is Chinese) shown below. The decrypted
text gives hint on what is coming next.

Below we see a block of encrypted text

And then decryption is called and we can clearly see the
parameters being passed on to the decryption routine:

We
get confirmation that this is AES encryption by observing the CipherMode to be Rijndael

We see some other weird string comparisons which do not seem
to make sense now but we will see further what is happening:

Next we see the hidden folder “FolderName” is being created:

Multiple memory areas are decrypted like the below and
string comparison is made:

"n69MBsHJ6Kj7YypGxhASwA=="

"n69MBsHJ6Kj7YypGxhASwA=="

And finally we see that the string comparison
succeeds. I think this is done to locate the code which needs to be dropped
within the memory

The malware is comparing all processes names with “explorer”

It creates the hidden directory Foldername in the appdata:

Here we see that cmd.exe is being passed on to a function
called set_FileName.

We see initialization of a process (cmd.exe):

We can see below that the sample (file.exe) is starting up
the process (cmd.exe):

Now we see that the malware is copying itself to the Startup
folder for persistence:

We see that IO.StreamWriter is being used to write some
information which has been decrypted from the memory into a batch file:

We also see that the sample is copying itself to the hidden
folder “FolderName”:

Further decryption leads to the following strings, where
RegASm.exe is being located in the WINDIR/Microsoft.NET/Framework//v2.0.50727/

RegAsm.exe is a genuine file signed by
Microsoft. This file is copies to the appdata folder and renamed as “Net
Work.exe”. This Net Work.exe is then executed. Why is this done? Because the
sample then injects malicious C2 communication code to the memory space of the
running Net Work.exe, which when executes and talks to the C2 domains.

We also see that a huge array is passed on as argument to
the #0b function. What does this array contain? Let us see.

We see a several transformation runs happening in the
special function @ IL_0157 uint8[]
##::#0b(uint8[], string) to which the huge array is passed on to.

After the transformation we see that the v_8 array now
contains the decrypted text. Once we capture the first few hex from the array
we convert it into ASCII and observe the “MZ“, which confirms our assumption
that the array is basically the malicious binary which will be injected into
the memory space of Net Work.exe:

The copy operation of RegAsm.exe to Net Work.exe in Appdata
folder:

I believe the following function (#nb), which is taking as
parameters, both the file name which will be executed as the process and the
huge array which contains the malicious code to be injected to the process:

We can see several local variables on the stack for this
function from V1-V42 something.

All these variables are assigned encrypted values:

V_4 "5BWv2UbLHY/glqhTiXBeZg=="

V_21 "dTbI2rgmsc1BbfFH90CMppg1K3Hs1ql/6/t4Mfd4/bk="

V_10 "WsaCymtPaQY07mOBktBUssOSEThxxyQW7Q4zq5eScc0="

V_16 "xfbDBii9ojbhElpzyeYkgw=="

We take one of the variable V_14 and see that string array
is containing “kernel32”, indicating that kernel32 library will be accessed
further down for performing the memory injection:

The following routing will perform the memory injections
task:

We
see kernel32 and ReadProcessMemory is being passed on to a function, most
probably to locate the address offset in memory for the ReadProcessMemory API
function

We see below that we have got the function pointer for the
kernel32.ReadPRocessMemory function:

Similarly we see that the function pointer for other
functions like CreateProcessA, ntdll.ZwUnmapViewofSection, WriteProcessMemory, GetThreadContext,
SetThreadContext, VirtualAllocEx and ResumeThread are also acquired as seen
below:

So what does all of this points to? It points to a malware technique called process hollowing. Hollowing out a process is a simple technique. First the malware creates a process in a suspended state by calling CreateProcess, calls ZwUnmapViewSection to un-reserve the memory, allocates memory using VirtualAlloc, writes data to the process memory using WriteProcessMemory, retrieves the context of the thread using GetThreadContext, modifies the context and then sets the context using SetThreadContext and then call ResumeThread to start the process

So the address pointers to the above process hollowing
related API functions are stored as objects in local variables as seen above.

Once the new process Net Work.exe is started using, we see
below that file.exe has spawned and injected code into Net Work.exe as we can
see the strings from the memory of Net Work.exe contains the malicious domain
connection as shown below:

I thought of using procdump from SysInternals to dump the
process

Meanwhile the parent process file.exe continues and we see
that it creates the batch file “file.exe.bat” in the hidden folder
“FolderName”, this is the same batch file we witnessed during the dynamic
analysis above:

Initializing StreamWriter object to write batch file:

Again decryption routine #Gb is used to decrypt the contents
of the batch file and writing to it:

We can see file.exe then creates the process to run the bat
file which spawns timeout.exe because of the timeout /t 300.

Let us try to dump Net Work .exe (with injected code) from the
memory image of the VM (vmem file) using Volatility memory forensics framework.
Note: I had to use Volatility 2.5 to support dumping the process from vmem of
Windows 8.1:

Once we get the dumped process we start debugging it again
in DILE and we see all the relevant code for opening the connection to the C2
domains:

First we see that even this code is also obfuscated to the
same degree. We notice a C# Dictionary object which has Keys and values. Some
Keys are related to DNS servers, some malware-specific keywords like
INVOICE-247, PrimaryConnectionHost etc:

We can see the values for the PrimaryConnectionHost and
BackupConnectionHost which are the malicious C2 domain the malware connects to:

Some other interesting key-value pairs in the Dictionary

The Mutex created is the System GUID:

Here we see the google DNS servers which are contacted to
resolve the malicious domains:

The port 6625:

The Net work.exe process runs multiple threads for every
connection attempt to the malicious domain