Alert Stop Bad Rabbit Ransomware In Its Tracks. Learn more

Threat Analysis: Recent Attack Technique Attempts to Bypass Whitelisting by Leveraging MS Office Document Macros, MSBuild, Certutil

March 15, 2018 / Jared Myers

Carbon Black continues to monitor and track evolving techniques that attackers leverage. Over the last several years, there has been an increase in attackers leveraging open source frameworks and proof of concept (POC) techniques that are released publically by researchers.

A document was recently submitted to the Carbon Black Threat Analysis Unit (TAU), for analysis. The technique, which leverages certutil.exe and MSBuild, uses a carrier file (MS Office Document) and an embedded VBA macro to initiate techniques initially discussed publicly by Casey Smith (@SubTee). This specific document that was analyzed for this post was also publicly discussed by  John Lambert.

Carbon Black previously made an internal release the analysis of this document and the used techniques, in the Carbon Black User Exchange. After request from partners, this analysis is being provided publicly to assist other researchers and practitioners that may be researching or investigating these types of attacks.  Content related to Carbon Black’s detection of this technique can be located in the following TAU notification. Each of Carbon Black’s solutions, Cb Defense, Cb Response, and Cb Protection are able to detect this attack.

The metadata for the document that was analyzed is listed in the table below.

File Name       : mal.doc

File Size       : 46,080 bytes

MD5             : aef655c3f255cc7ff12c45a9c9a9f0b0

SHA1            : 988b84dc8de0e37c95a38958feb1ed223309f9b5

SHA256          : 1d213aef54174a22ecdd052f9ccb9aaee9ae50b67201b8b0551db008e5ef4278

Fuzzy           : 768:o+1o92DGxz993+YocoQRAJNgH6+MggQ2:o+a92DG3oY1c6H6+MggQ2

Magic           : CDF V2 Document

                  Little Endian

                  Os: Windows

                  Version 6.1

                  Code page: 1252

                  Template: Normal

                  Revision Number: 3

                  Name of Creating Application: Microsoft Office Word

                  Total Editing Time: 07:00

                  Create Time/Date: Sun Mar 04 03:50:00 2018

                  Last Saved Time/Date: Sun Mar 04 04:04:00 2018

                  Number of Pages: 1

                  Number of Words: 0

                  Number of Characters: 0

                  Security: 0

Table 1: Document Information

Technical Details

First Stage

The document contains embedded VB macros, which can be observed in the image below (highlighted in red), which was extracted using Oledump.

Image 1: Document Streams

The metadata for the extracted file is listed in the table below.

File Name       : doc_stream7_out_decompressed

File Size       : 2,227 bytes

MD5             : 491ae56532ae4ab95272e3147f2a98d8

SHA1            : 05b7c8751eff2a1e540bdae908bcc269241bf13f

SHA256          : 10f07d8bf268d26cbcec814d419f1c26df5bfe578098613204acb7e4cad52bfc

Table 2: Extracted VBScript Information

The extracted VB code is responsible for downloading the second phase of this attack. The image below depicts the code gathering the fully qualified path (FQP) for the current user profile, which is then concatenated with a hard coded file path, resulting in the file path C:\Users\[Current User]\AppData\Local\Microsoft\Office\Word (which is highlighted in  blue in the image below). The actors presumably chose a path and file name (without a file extension), that looked legitimate to not raise suspicion of the malicious activity. The VBScript will then download the file pc_2.png from a hard coded C2 (hXXps://pointfax[.]com/jp/pc_2.png – highlighted in red below), saving the file to the previously created file path.

Image 2: Second stage download

The image below displays an overview of the pc_2.png file’s data. This appears to be a legitimate file that was present on a compromised third party website. The attackers then appended base64 encoded data (highlighted in red) to the end of the file. This data was appended after the PNG file’s End of File (EOF) marker and a series of hex values that correspond to newline characters, which were chosen due to how the file is parsed in the next step.

Image 3: PNG file data overview

The VBScript will then create an object where the pc_2.png file is read into memory. The VBScript will then read each line of the file as text, not including new line characters (highlighted in red in the image below). Once the base64 encoded string is located, only the base64 encoded string will then be written back to the file location on disk (C:\Users\[Current User]\AppData\Local\Microsoft\Office\Word), overwriting the original data (highlighted in blue in the image below).

Image 4: PNG file parsing

The VBScript will then create two commands by concatenating different string variables in order to evade detection. The first command will call certutil.exe to base64 decode the previously parsed base64 encoded string. The decoded data will then be saved back to the file itself. This command is highlighted in red in the image below, it should be noted that the comment string in grey below the line was added by analyst. The second command will call MSBuild.exe to execute the file containing the now decoded data from the previous step. This command is highlighted in blue in the image below, it should be noted that the comment string in grey below the line was added by analyst.

Image 5: String command concatenation

The above created commands will then be executed by the VBScript by creating a WMI object (highlighted in red below). These commands ultimately leverage wmiprvse.exe, which is the executable responsible for implementing WMI calls, to carry out the invocation of the commands (highlighted in blue below). The same set of instructions that are listed below were used to implement both commands.

Image 6: WMI instruction execution

The below image depicts the process analysis overview from Cb Response. The certutil.exe command line is highlighted in red, and its parent process is listed as wmiprvse.exe. Due to the manner in which wmiprvse.exe is called in the above VBScript code, its parent process will be svchost.exe which is the standard in Windows. Unfortunately this process lineage will not be directly tied to Word process (and embedded macros), which were responsible for its creation.

Image 7: Cb Response overview certutil.exe

The process analysis overview for the MSbuild.exe command can be seen in the image below, and reflects the same process lineage. Also highlighted (in green) in the image is a child process of wsmprovhost.exe which was created when MSBuild.exe invoked the C# project file (named Word with no extension) that was base64 decoded from the command detailed above. The importance of the wsmprovhost.exe process is detailed below.

Image 8: Cb Response overview msbuild.exe

Second Stage

The metadata for the extracted and decoded Second stage is listed in the table below.

File Name       : Word (C# Project File)

File Size       : 7,310 bytes

MD5             : 25019964baaacc752c87e18a07f2feae

SHA1            : c4b04681af5aebfbe27da281296feb26bd9a1a09

SHA1            : 516a4a3cc3533bb6b077c260986c0e7bfba0d83b2005e807d395a82df5ac9c70

Magic           : ASCII HTML document text, with CRLF line terminators

Table 3: Decoded Word Information

Once the second stage C#  (Word) is running it will download another PNG file (pc.png) from the same C2 that was previously leveraged (highlighted in red below). Like the previous PNG file, this file also has a base64 encoded string that was appended to the file after its end of file marker and a series of 0xA (new line) values.

Image 9: Second stage PNG download

The C# script will read the file into memory and locate the base64 encoded string, which is first decoded. The resulting data is a space separated list of integers represented as ASCII strings (which are depicted in the image below). The C# script will use this decoded buffer to create an array using the split method. The individual array elements are then converted from the ASCII string numbers to their respective byte equivalent (highlighted in blue in the image above). The resulting data from this operation is 855 bytes of shell code.

Image 10: Overview of base64 decoded buffer

Once the shellcode payload has been decoded the C# script will create the process wsmprovhost.exe in a suspended state (highlighted in red in the image below). The C# script will then reserve a region of memory in the newly created wsmprovhost.exe process’ address space, which is marked as RWX. The shellcode buffer is then written to that location (highlighted in blue in the image below).

Image 11: Shellcode injection

The C# script will then locate and open a thread of the wsmprovhost.exe process. This will be the thread that the C# script will create an Asynchronous Procedure Calls (APC) object for. This APC object will point to the memory address of the shell code that was written in the previous step. This will cause the thread from the  wsmprovhost process to load and execute the shell code, once the thread is resumed. This series of steps is highlighted in green in the image above. It should be noted that this technique of using APC user-mode objects to execute shell code or Dlls has been documented publicaly for several years. This implementation used in this attack appears to be a modified version of of open source project, like the samples found here (1, 2, 3, and 4)

Third Stage

Once the APC queue loads the shell code, it will be running in the context of wsmprovhost.exe. The shellcode was created or built using a framework such as metasploit or cobalt strike. The shellcode itself looks to be a variant of open source projects by enigma0x3 or 3gstudent. Once the shellcode executes it will initially use a API name hashing algorithm, which is common in shellcode, to locate the LoadLibrary API. It then loads the Wininet Dll and locates the InternetOpenA API in that library (highlighted in red and blue in the left image below).

Image 12: Shellcode C2 communication Setup

The shellcode will then use the InternetConnect API to beacon, over TCP Port 443 or 0x1BB (highlighted in green in the right image above), to the hard code C2 personalsurvey-196718[.]appspot[.]com (which is highlighted in the image below in red).

Image 13: Shellcode hard coded C2

This network connection to the above listed C2, will be registered and listed under the wsmprovhost.exe process, depicted below.

Image 14: Shellcode C2 communication event

This shellcode will then resolve several different APIs, which are depicted in the images below. These APIs are used to communicate with the above listed C2. The shellcode will allocate memory for the C2 response, which is additional shellcode modules that implement different capabilities.


Image 15: Shellcode C2 communications

The initial shellcode payload will download and execute additional shellcode and commands. The image below depicts the shellcode running in the wsmprovhost.exe process, which is invoking cmd.exe to perform network reconnaissance.  

Image 16: Shellcode executing additional commands


TAGS: Carbon Black / Carbon Black TAU / Carbon Black Threat Research