Monday, May 18, 2020

Another Maldoc Analysis Article

19 May 2020

Recently, I have been dove headfirst into learning about how adversaries utilize the Microsoft binary, MSBuild. When I came across an interesting malicious document that made use of MSBuild in its execution chain, I had to take it apart and see what I could find.

This blog will cover the investigation of the following document:

"home working guidelines.wbk"
SHA256:   BB0FFC8CD1FC4D83510AE0F5D6DE5FA471C49067DD4479307EF5321883660B6F
MD5: 743F9956DAB862CEE41098AFF054BFDA

Since the document has already been executed in an analysis environment,  we are provided with a number of indicators (process graph, network communications, etc.). This saves us some time in analyzing the document or setting up a local sandbox environment.

Figure 1

Not much in the way of creativity with the document as shown in Figure 1. However, the embedded object with the extension .lnk, sure is interesting. The actual title of the embedded object is "Home Working Guidelines.doc.lnk".

The document itself is a Word Backup file, hence the .wbk extension. When the option to "Always create backup copy" is selected in Word, these files are automatically created.

Figure 2

Hopefully seeing MSBuild as a child process to Winword.exe piques your interest in just what exactly is going on in this document. Additionally, if you take a look at rundll32.exe in the process graph, you notice the two arrows icons indicating connection to a network.

The sandbox environment has provided us with a great deal of information to get at least an understanding that this document is up to no good. MSBuild may regularly make network connections in certain environments, but being a child process to Microsoft Word definitely calls for further investigation.

My go-to initial tool for analyzing malicious documents is Didier Stevens' oletools. Thinking the document was using OLE as part of its exploitation process, I came up empty handed until I ran the rtfobj tool.

Figure 3

MSBuild is primarily used to assist in the build of .NET applications. Where things get sneaky, is that XML files and C# project files (.csproj) files are executed with ease by this signed application. As you have probably have guessed, an adversary can easily provide malicious C# code within these documents to execute code.

Changing up the previous rtfobj commands slightly, we can extract both the XML file in ID 0, as well as the shortcut file in ID 1.

Figure 4

Figure 5
There is no surprise when we open the shortcut file properties and see MSBuild being executed. The XML file is quite lengthy, which a good portion is obfuscated. In the interest of time and keeping your attention, let's focus on some of the more interesting part of the code.

A well known trick to execute malicious code in XML, is by utilizing an inline task tag. Depending on what the author's intentions are within the task, a fragment of code can be added to the task and automatically executed upon successful build of the project.

Figure 6

Figure 7

There are repeated calls to kernel32.dll as well as calls to Windows API's regarding processes. This leads me to believe there is some type of injection going on within the code. The huge string of garbled text at var sc32 is roughly ~200 lines itself.

Figure 8

Figure 9
In Figure 8, we can see the initial key and cipher being setup for encryption in addition to rundll32.exe and an execute method on a function. Figure 9 provides even more clues in addition to my assumption that some type of process injection was taking place. The string titled "aUqZUAhapJ" contains what I believe is the hardcoded RC4 passphrase, which is setup in the function below it.

With a possible passphrase in hand, I utilized CyberChef to see what additional output could be extracted from the large obfuscated mess.

Figure 10
Figure 11
The "MZ" header appearing at the top of the semi de-obfuscated code leads me to believe we are dealing with an executable. The abundance of error messages and instructions is also interesting.

Figure 12

Figure 13 
Figure 12 contains more calls to Windows API's, which provides information on what the intentions of the executable were.  Figure 13 contains more API calls, a partial PDB path, and what appears to be shellcode, however this requires additional analysis.

In the sandbox environment, the malware C2 is at do[.]skype[.]com. Upon looking further into the traffic, this domain is hosted through Azure Content Delivery Network. A few Google searches identified that the above site is a well known domain used for domain fronting. Further analysis would be required for a more concrete decision.

I have not tied this malware to a specific malware family or actor, as this was not the intention of the blog post. Even with application allow lists enabled in your environment, MSBuild can easily bypass most detection's. Windows Defender Application Control (WDAC) configured correctly to monitor for MSBuild can successfully stop these attacks. This also comes with a cost depending on your environment, as well that MSBuild comes standard on Windows builds.

This particular document may have been a test run or in the early stages of development, as the sandbox received the C2 connection, but it appears the code ran in a loop and no further exploitation could be identified. In my lab, I found the same to be true regarding executing the XML file. I was able to find logs identifying a MSBuild process walking through the C:\ drive, but nothing else.

In the following blog posts I hope to cover some possible techniques to detect malicious use of MSBuild besides WDAC. In the few tests I have run in my lab, I have had limited success with monitoring ETW, as well as utilizing Sysmon and the Windows Event Logs.

JPCert's Log Analysis Training

6 Aug 2020 About a week or so ago, JPCert released their Log Analysis training slides and corresponding CSV files for each hands-on exercise...