Wednesday, September 18, 2019

Analyzing an RTF document from Cyber Comm Drop

18 Sep 2019

About a week ago, U.S. Cyber Command made public a number of malware samples purported to be from North Korea via Twitter.  It's not often these samples are made public outside of VirusTotal (I am not cool enough for a full account). The folks at Hybrid-Analysis were kind enough to release them for us regular folk.

I have a particular liking for malicious Microsoft Office documents and how adversaries package them to bypass EDR solutions. While browsing the samples, a .doc file caught my eye.


The sample I will be analyzing can be found at https://www.hybrid-analysis.com/sample/1199753d8f7c26890d690236273c855eaa4830ba9d26839e0cd778a714e1c033?environmentId=100

This will not be a deep dive into the document as the sample I believe is rather old and the malware serving domain the document called out to is no longer active.  Additionally, trying to attribute the attack to one country or the other is out of the scope of this post. I will leave that to the professionals.


Overview

 The author(s) of the document utilized a Word doc to pose as a sample "Blackboard" test evaluation. Specifically this document was sent targeting Carnegie Mellon University.  The blackboard site is for instructors and students to build courses, evaluate student grades, etc. Carnegie Mellon University is one of America's storied educational institutions with a number of think tanks that call the school home. It would be easy to see why foreign threat actors may want to invite themselves into the school's network.

Figure 1: Document posing as CMU


 The link at the bottom leads to an actual directory file on CMU's BlackBoard server. The interesting thing is that there are no macros to click and the link is non-malicious. In the background the Word document opens Excel.exe utilizing svchost.exe DCOMLaunch.  The Excel file launches PowerShell using WMI which in turn opens and executes C# code. The aforementioned script calls out to dawoomang[.]co.kr. Multiple threat intelligence platforms recognize the legitimate site as being compromised and a known malware source.


Technical Details

Figure 2: Process graph courtesy of app.any.run




Figure 3: Process Hacker view of Excel.exe

Because even in the world of cyber security things aren't always what they seem, let's run our obligatory initial commands.

Figure 4: Output of file & strings commands

Shown in the above output, the Word document is actually a RTF document. In the lower picture, ansi 1254 is the value for the Turkish language, however this value is easily modifiable and not a strong IOC.

To take a further look into the RTF document, I will be using a number of open source tools, namely rtfdump and rtfobj (https://www.decalage.info/python/oletools).

Figure 5: Tool output showing presence of OLE streams




So far it has been confirmed that the initial document is actually an RTF document with Object Linking and Embedding (OLE) streams in it. With this information in hand, we should be able to locate the OLE compound file and it's accompanying header.


Figure 6: OLE compound file at offset 0x6F



The cool thing about carving up this RTF file is that everything we saw in the first image on the Word document can be seen in our tool output. The file was heavily obfuscated, I was able to find some interesting PDB paths, a Root Entry, as well as what I think may have been the beginning of the malicious PowerShell code. Without bogging you down in more screen shots,  I wanted to share one other item I found that I cannot put a finger on exactly what it is.

Figure 7: Possible CLSID of MS Exel

After researching the above sequence of letters and numbers, I am somewhat certain that we are looking at a CLSID that identifies Microsoft Excel. To my untrained eye, this would make sense as we know from the process graphs that Excel.exe is opened via DCOMLaunch.


Execution

Thanks to PowerShell scriptblock logging, Event viewer was able to capture the script that was run from Excel. First let's take a look at what we see in the event logs.


Figure 8: Logging of malicious PowerShell

The above isn't very much help, and quite honestly makes my head hurt.  A great plus with scriptblock logging is that the actual payload is also provided how it would look at the command line. As I referred to earlier in the post, the PowerShell script starts up a C# compiler and executes code. I have no prior experience in C#, but everyday you learn something new you are better than yesterday.

Taking the decoded script, I was able to piece some of it back together even though most of the variables were still obfuscated. I replaced some variable names with what I believe is their function to help understand what the code is doing.


Figure 9: Unscrambled C# code



As can be seen in both Figure eight and nine, the PowerShell utility "Add-Type" is used in the script. This utility allows the author to define a .NET class  and then create new objects, all within the PowerShell session.

Utilizing this method of execution while done in memory, leaves behind a number of artifacts. I could not reproduce the same files as the report cites are dropped, I have gaps to fill on my detection strategies.

Much of the first few lines are self-explanatory as to their purpose in executing the script. Where the good stuff comes in starts at line 35. We can see a WebClient created that will attempt to download and drop "ab88ddd.exe" into the \AppData folder.  Further down, the process is started and the code exits.

Using PowerShell in addition to csc.exe the C# compiler, but likely whitelisted on most workstations is ingenious. This attack method also makes it difficult to detect in Sysmon since much of the code is executed in memory then deleted thus not creating any known load events that configurations would catch.

In my spare time I want to throw together a Sysmon configuration that logs when csc.exe is a child of PowerShell.  I have seen many configs that log when csc.exe is launched, but I am interested to see how the aforementioned config would work in my lab environment.


Network

In addition to the file ab88ddd.exe being downloaded and dropped to disk, the PowerShell script additionally reaches out to download another executable.

Figure 10: GET requests to download EXE
The first executable downloaded had no AV detections when I submitted it, and the above domain is no longer active so we are not able to get an idea of what 8741000.exe does. Notice in the next Figure 11 below the lack of a User-Agent (PowerShell doesn't have one) and the tell-tale MZ header.

Figure 11: TCP stream of GET request for executable

Outlook

While I would have liked to have been able to look deeper into the file and the second downloaded malware, this was a great exercise in what I see as more advanced (sorry) malware.

In my home lab, I was able to detect a great deal of what was discussed above, but I am not happy with it and am going to take the time to look deeper into csc and cvtres.exe which assisted the C# script in executing. I am not sure how often these two applications are used in an enterprise setting or if they could be blocked on normal user workstations altogether.

For the meantime, a good bit of information was pulled from the document which I will put towards additional maldocs I find along the way.


References/Continued Learning

 http://www.exploit-monday.com/2017/07/bypassing-device-guard-with-dotnet-methods.html

 https://blog.talosintelligence.com/2018/06/my-little-formbook.html

 https://www.fireeye.com/blog/threat-research/2016/05/how_rtf_malware_evad.html

 https://www.youtube.com/watch?v=4ACmjUNZOZw

Tracing The Route of A Malicious Document

08 Oct 2019 This post will follow on from where my last one left off. I did a quick analysis of a malicious Word document that turned out ...