RTF-Embedded malware performing process hollowing

Delivery and Weaponization:

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:

---------------------header start-------------

Received: from abc.com (123. 123.123.123) by

 Xyz.com (456. 456. 456. 456) with Microsoft SMTP Server id 34.34.34.34;

 Tue, 13 Oct 2015 10:34:12 +0400

X-EMAILSEC-AV: E=ABC;i="34.343.344";

   d="rtf'96,212?scan'96,212,208,217,212,96";a="1355956"

Received: from bosmailout01.eigbox.net ([66.96.185.1])  by

 Lmno.com with ESMTP; 13 Oct 2015 10:32:58 +0400

Received: from bosmailscan02.eigbox.net ([10.20.15.2])              by

 bosmailout01.eigbox.net with esmtp (Exim)                 id 1Zlt8o-0004BU-Em                       for

 iok@efg.com; Tue, 13 Oct 2015 02:32:54 -0400

Received: from [10.115.3.31] (helo=bosimpout11)   by bosmailscan02.eigbox.net

 with esmtp (Exim)     id 1Zlt7y-00068k-5q for abc@efg.om; Tue, 13 Oct

 2015 02:32:53 -0400

Received: from bosoxweb02.eigbox.net ([10.20.16.129])            by bosimpout11 with                      id

 UWSp1r0032n4cGA01WWq4i; Tue, 13 Oct 2015 02:32:01 -0400

X-Authority-Analysis: v=2.1 cv=XNO+SGRE c=1 sm=1 tr=0

 a=ZIL9R3slh7IdqhIfVTHUXw==:117 a=QPcu4mC3AAAA:8 a=9cW_t1CCXrUA:10

 a=42P2sm4lAAAA:8 a=-_WXIlxriiAA:10 a=5lJygRwiOn0A:10 a=xsF35SsV_EaMuivSbgQA:9

 a=QEXdDO2ut3YA:10 a=SSmOFEACAAAA:8 a=51R12IuPrxiqbFFGrGIA:9

 a=cM0N_5ZptdcXglYH:21 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=p403mkujtbAA:10

 a=yMhMjlubAAAA:8 a=hqncwlCRse8zBt5N2-8A:9 a=wPNLvfGTeEIA:10

Received: from localhost ([127.0.0.1] helo=bosoxweb02.eigbox.net)         by

 bosoxweb02.eigbox.net with esmtp (Exim 4.72)       (envelope-from

 <sales@ref-tek.com>)                    id 1Zlt2u-0001zo-9r; Tue, 13 Oct 2015 02:26:48 -0400

Date: Tue, 13 Oct 2015 02:26:48 -0400

From: sales <sales@ref-tek.com>

Reply-To: sales <sales@ref-tek.com>

Message-ID: <997110163.17128.1444717608181.JavaMail.open-xchange@bosoxweb02.eigbox.net>

Subject: Re: Re: Re: Revised invoice

MIME-Version: 1.0

Content-Type: multipart/mixed;

                        boundary="----=_Part_17126_2064955765.1444717608157"

X-Priority: 3

Importance: Medium

X-Mailer: Open-Xchange Mailer v7.6.2-Rev20

X-Originating-IP: 60.49.75.156

X-Originating-Client: com.openexchange.ox.gui.dhtml

To: Undisclosed recipients:;

Return-Path: SRS0=d7ZOBc=KR=ref-tek.com=sales@eigbox.net

X-MS-Exchange-Organization-OriginalArrivalTime: 13 Oct 2015 06:34:12.6818

 (UTC)

X-MS-Exchange-Forest-ArrivalHubServer: tgd.com

X-MS-Exchange-Organization-OriginalClientIPAddress: 123.123.123.123

X-MS-Exchange-Organization-OriginalServerIPAddress: 456.456.456.456

X-MS-Exchange-Organization-AuthSource: IJK.com

X-MS-Exchange-Organization-AuthAs: Anonymous

X-MS-Exchange-Organization-MessageDirectionality: Incoming

X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: IGK.com

X-MS-Exchange-Organization-OriginalSize: 3867737

X-MS-Exchange-Forest-MessageScope: 00000000-0000-0000-0000-000000000000

X-MS-Exchange-Organization-MessageScope: 00000000-0000-0000-0000-000000000000

X-MS-Exchange-Organization-HygienePolicy: Standard

X-MS-Exchange-Organization-Recipient-Limit-Verified: True

X-MS-Exchange-Forest-RulesExecuted: IJK

X-MS-Exchange-Organization-Rules-Execution-History: Email Disclaimer

X-MS-Exchange-Organization-Journaled-To-Recipients:

 jrl@abc.com

X-MS-Exchange-Organization-JournalRecipientList:

 1021f245-1951-4342-bc08-6bed08920597

X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

---------------------header ends-------------

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

 Let us take one sample of encrypted text from memory stream:

DHT4nnojMu97NSJKlRBnu6FnKLYBqeeHnjqNzUy107nfuhF6rFwfxGH2MLu068Jndmy57CeqoqqzY5MLQnRnANjdAYQOcIZV+gmzZEQnCAsdIMpCyLI0hYnw9loKk25g

Encrypted Memory stream:

tøžz#2ï{5"J•g»¡g(¶©ç‡ž:ÍLµÓ¹ßºz¬\­Äaö0»´ëÂgvl¹ì'ª¢ª³c“BtgØÝ„p†Uú³dD' ÊBȲ4…‰ðöZ“n`

Following is the decrypted array in the Output Buffer of the cryptography object

 Once we convert the above decrypted data in hex to ASCII, we see the decrypted text which, if you remember, the sample executes to add itself to the registry entry for persistence.

We can see below that the registry entry has been created:

Some more cipher text from memory stream which decrypts to environment variable WINDIR:

Ñ‑Ò©(’V&3ÎùÕ

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.

Next we see that another bat file melt.bat is created:

This batch file “melt.bat” is used to delete the original binary:

Shell is used to run the batch file:

The parent process file.exe ends here. However the spawned process Net Work.exe with injected code keeps running in an infinite loop:

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

Intelligence:

Weaponized RTFs with embedded binaries delivered through email from domain hosting email servers. Multiple persistence mechanisms, .NET compiled binaries as opposed to natively compiled and .NET code obfuscation used. Increase usage of batch files for persistence and other low level malware operations. C2 hosts are using free dyndns services.

Internal DNS queries to google DNS servers

Both artifacts are till now unknown to VirusTotal:

File.exe: decb9b7c3a45786714d31936d25fd33a

Net Work.exe (injected): fc96827800915fc5fa42553e640717ff

C2 domains: goodnews.no-ip.biz and 1goodnews.dyndns.biz