Summary
A document was submitted to the Carbon Black Threat Analysis Unit (TAU), for analysis and to determine if Cb products were able to detect this attack. The attack uses a carrier file (MS Office Document) and embedded VB macros to initiate a series of techniques, which utilizes approaches to bypass allow-listing applications and ultimately injects a shellcode payload into memory. The shell code will beacon to an attacker controlled Command and Control (C2).
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.
Figure 1: Document Streams
The document contains embedded VB macros, which can be observed in the image below (highlighted in red), which was extracted with Oledump. 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 Carbon Black 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 7: 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 8: 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 9: 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 10: 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 11: 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 12: 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 12: 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 13: 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 14: Shellcode executing additional commands
