Tuesday, October 8, 2019

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 to be a RTF document with a whole lot of flare. While digging more into the C# code buried in the Excel file that was part of the document, I came across a couple awesome posts/talks:




The above resources were a great help in understanding how to detect .NET malware. Not knowing a thing about C# or the .NET framework, I installed SilkETW ( https://github.com/fireeye/SilkETW) and went to work in my lab.

This post will not go into the specifics of event tracing for Windows (ETW) or the software needed to get your hunt on. The authors above dropped enough knowledge bombs and step-by-step instructions to keep you busy for a while. As I said, I utilized SilkETW, set up the program to use SilkService, identified providers, and sent the output from the collectors to a separate server running Splunk.

In addition to introducing myself to the providers, I must say that the output of the collectors is quite overwhelming and may take a while to determine what is malicious and what is benign.

Going back in time, below is the C# code that is executed as part of the malicious document.

Figure 1

Detection, on Detection, on Detection

As identified in the last post, the above code is executed via Powershell which in turn calls on csc.exe to compile the code. There are two function calls that are especially interesting; RtlMoveMemory,  and Marshal.Copy. The first function as the name implies, has the ability to move unmanaged memory into a destination memory block. In this case kernel32.dll is called.

The second function is similar to the first, however its purpose is to move unmanaged memory to an unmanaged memory array or managed array. While I am sure that little lesson was not the most exciting, what we do know is that this malicious code is making use of unmanaged memory blocks to weasel it's way into networks.

Before we start looking at ETW output, I wanted to touch on some interesting finds using everyday tools.

Figure 2

The above figure depicts the process tree starting with Powershell, but also briefly catching the execution of csc.exe.

If we hover over the currently running PS process, we can view the obfuscated code that was caught by script block logging. Note* I ran (detonated) the sample a few times, hence the multiple instances of PS running.

Figure 3

Looking deeper into the PowerShell process properties reveals additional information that may stand out to us.

Figure 4
I am not 100% positive, but I don't think wmic spawning PowerShell is normal activity and would constitute anomalous actions. Before sounding the alarm, this particular find may have to be analyzed across the network and what is normal for computers with specific roles (admins).

If you remember the last post, the above PowerShell command kicked off a GET request to a malicious domain with no User-Agent. Again not earth shattering, but worth taking a deeper look.

The PowerShell and wmic pairing will come into play again later when we get into analyzing output from our traces of the system.

The last item in our look at the PowerShell properties deals with .NET Assemblies. The loading of .NET runtime DLL's may not be anomalous in all cases, but this seems like it may be one of those events.

Figure 5

The Assemblies tab allows for the viewing of event assembly loads. Normally, each assembly loaded would include a path. The lack of a path for an assembly load could possibly indicate in-memory evasion.

Please note at the bottom of the above figure that "swvggacb" has no path and is a dynamically loaded assembly. Although this sample does not utilize Cobalt Strike, a great series on in-memory evasion can be found at: https://blog.cobaltstrike.com/2018/02/08/in-memory-evasion/ .

Event Tracing For Windows FTW?

While setup  and ensuring logs were flowing was relatively straight-forward and very user friendly, a few things about collecting ETW have to be stated.

Before you start ingesting the logs into your SIEM of choice, it may be smart to first filter exactly what you are hunting for.  I collected the following providers Microsoft-Windows-WMI, Microsoft-Windows-PowerShell, and Microsft-DotNetRuntime. In the short time I started the SilkService and ran the malicious sample, my splunk instance received 50k+ events!

After reading some of the above posts, I decided to have my WMI events output to a json file. Again, this was a very noisy file and quickly grew in size. Thanks to @IISReseMe 's blog, parsing the JSON file via PowerShell was pretty easy.

Figure 6

As seen in @mattifestation 's slides, when it comes to WMI detection, EventID 23 is a good place to start.  I ran a couple of tests prior to running the malware to ensure everything was working. Nevertheless, we can see there are at least a few events that may be worth looking at.

It should be noted that the other events are just as important as EventID23.  For example, EvenID 5858 logs all WMI query errors.

Figure 7

While the above query may seem harmless, there were a number of other query errors that when combined can provide an adversary with valuable information.

The above query could provide an attacker with particular software and hardware installed on a system. This could identify sandboxes or virtual machines, which could result in the malicious program stopping/deleting itself.

Moving back to our EvenID23 cases, some quick PowerShell can provide us with the client ID and commandline parameter used.

Figure 8

WMI and PowerShell may be utilized heavily on your network, but is there really a reason to be hiding a window if this wasn't anomalous? The hunt continues...

Messing around some more with PowerShell and the JSON file, we can get additional WMI classes that were called in relation to the malware being run.

Figure 9

While we clearly have enough information to elevate these events to an incident, this post was supposed to be about ETW, so I should probably cover what was found in Splunk.

Figure 10

Above figure depicts domain module loads of .NET assemblies with the process name of PowerShell.

Figure 11

While the output isn't the best (I will change that for the next go round), we can see a number of .NET DLL's loaded by PowerShell. This may not be overtly malicious, but is worth looking into when you start to filter on ProcessID:5000.

Figure 12
Utilizing the PowerShell provider, we can again view the malicious obfuscated code that was run on the system.

Looking at the logs can definitely lead down a rabbit hole. Other interesting events that can be identified are Interop Method calls, as well as DomainModule events with PDB information.

This was just a short introduction into ETW and it's capabilities. This would be a great detection method alongside Sysmon and other endpoint solutions.

Hopefully someone found the above useful. Playing around with additional detection methods for this malware sample, I came up with the below extremely beginner Snort rule. Please hate on it all you want, just let me know how to better it.

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:" Possible Malicious Document - Retrieving Payload"; flow:established,to_server; content:"GET"; http_method; content:".exe"; http_uri; pcre:"/\/[0-9]{1,7}\.exe$/U"; content:!"User-Agent"; content:!"Referer|3A|"; http_header; sid:2; rev:1;)

Happy Hunting!

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...