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
URL:  https://app.any.run/tasks/41fcc642-2a73-42ab-9e6a-cc7f0d8f3423/

Monday, April 20, 2020

Detecting Malicious Activity in Network Traffic

 During my usual scour of any.run for interesting samples, I came across a .bat batch file which included both Koadic and Cobalt Strike infections. Not being sure how common it is to see both frameworks used almost simultaneously, I wanted to take a further look with a focus on the network traffic.

I have not been able to find similar campaigns or come across other samples to suggest this attack is being seen elsewhere. The focus of this post will be on conducting a quick "hunt" through the traffic in the PCAP of the infection. Zeek will be heavily utilized, with Wireshark making an appearance a few times.

Sunday, March 15, 2020

Malware Traffic Analysis "MondoGreek" Exercise Write-Up


Below is my incident report for the most recent malware traffic analysis exercise ( https://www.malware-traffic-analysis.net/2020/03/14/index.html). I won't bore you with a long introduction, let's jump straight into the contents of the report.

Victim machine
IP Address: 10.3.11[.]194
MAC: b8:ca:3a:ec:3b:8f
Host Name: laptop-sqsa42o$
User Account: otis.witherspoon

Environment
LAN segment range:  10.3.11[.]0/24 (10.3.11[.]0 through 10.3.11[.]255)
Domain:  mondogreek.com
Domain controller:  10.3.11[.]3 - Mondogreek-DC
LAN segment gateway:  10.3.11[.]1
LAN segment broadcast address:  10.3.11[.]255

Analysis

On 11 March 2020, at 21:24:36 UTC, a Windows client under the user account Otis Witherspoon was compromised by what appears to be Trickbot malware.

The infection kicked off when the user at IP address 10.3.11.194 made a GET request to http://bolton-tech[.]com. This request contained an executable which turned out to be a Windows PE named "YAS20.exe".

Figure 1
- Infection traffic (TCP):
50.87.248[.]17 port 80 - bolton-tech[.]com - GET /YAS20.exe

Associated with the download of this executable, there is an alert for a WinHTTPRequest, which could possibly mean malicious macros are being downloaded via a maldoc.

Figure 2

Follow-on alerts associated with this binary consisted of:

50.87.248[.]17 port 80
• ET POLICY Binary Download Smaller than 1 MB Likely Hostile
• ET POLICY PE EXE or DLL Windows file download HTTP
• ET CURRENT_EVENTS WinHttpRequest Downloading EXE

Following the above traffic, the infected machine connects over TLS to the below hosts over port 443:
185.141.27[.]238
 45.148.120[.]143
51.245.164[.]244

185.141.27[.]238 port 443
• ET CNC Feodo Tracker Reported CnC Server group 8

45.148.120[.]153 port 443
• ET CNC Feodo Tracker Reported CnC Server group 18

51.254.164[.]244 port 443
 • ET CNC Feodo Tracker Reported CnC Server group 19

During the above traffic, a GET request is made to checkip.amazonaws.com to get the public IP address of the infected machine.  Immediately following that check, two more Windows PE's are downloaded from an additional malicious site.

- Infection traffic (TCP):
64.44.133[.]131 port 8082 GET /images/imgpaper.png
64.44.133[.]131 port 8082 GET /images/cursor.png

Upon further inspection, the PNG image files appear to be executables as the tell-tale "MZ" header is present in the 200 reply.

Figure 3

Figure 4 


The network traffic following the request of the two binaries appears to be normal Trickbot traffic. Social media and browser account information including passwords are exfiltrated from the infected machine via POST requests to 203.176.135[.]102 also listening on port 8082. Additionally, system discovery commands are also exfiltrated from the network.

Figure 5 

Figure 6

Indicators/Files From Infection

File: YAS20.exe
SHA256: 02db3c6b9aff73bf8a11c41107c836b6c800c919c5d3d1304f336aee03f79f4c
Information: This file was not able to be successfully run in a sandbox.

File: imgpaper.png.exe
SHA256: 8aa9c596dd3eb7560bc7416ba181e858f1174fcbcb5432050f3f9a663ed1ffa2
Sandbox Description: Trickbot installer
Information: This file uses cmstplua for privilege escalation
Ref: https://app.any.run/tasks/e5044b8b-8e1d-4442-8447-5c73f9628bb5/

File: cursor.png.exe
SHA256: 68798ccf8e2a5f9682a4e011bec288ad9b3f900244f82c6ae5e8ca538725f92e
Sandbox Description: Trickbot installer
Information: This file uses cmstplua for privilege escalation
Ref:  https://app.any.run/tasks/2bb8d90a-7217-45bf-b889-3d63f2633247

Saturday, March 14, 2020

Authoring a Sigma Rule for CSI.Exe


I have continued down the rabbit hole with how to detect different .NET framework executable's.  In this blog post, I will cover a quick proof of concept and a soft detection rule via a Sigma rule. Not only does Sigma allow for the quick creation of rules across multiple SIEM environments, but the authors are also nice enough to let anyone submit their own newly created rules.

For those new to information security and looking to get their foot in the door, contributing amongst to projects amongst your peers is a great confidence builder. It took me weeks to get the guts to make my first pull request with a Sigma rule. My first rule breezed right through the pull request and was merged into the Sigma repository.

Continuing on from my last foray into csi.exe, I wanted to find some ways to detect malicious use of this binary without getting overwhelmed by ETW logs. This process also allowed me to see just what I was able to detect in my lab environment. I have moved to researching Reflective DLL injection, that will definitely be another blog post for another time, an eye opening experience indeed.

Saturday, February 15, 2020

Sifting Through ETW for Persistence in C#



 Introduction

Continuing my deep dive into how .NET can be used maliciously, this blog post will cover hunting for and detecting persistence created by a toolkit written in C#.

While persistence is considered what some refer to as "right of boom/breach", its importance cannot be understated for an attacker. If the attacker cannot maintain a hold on the system to move laterally and exfiltrate data, all is lost.

Background

Today I will be looking at the SharPersist toolkit by Brett Hawkins (https://github.com/fireeye/SharPersist). There are a number of ways to establish persistence in Windows environments,  via the registry, services and startup folder. With multiple detection opportunities in place for PowerShell, it only seems right to start looking for alternate means of holding onto access.

SharPersist offers a number of options to create persistence, for this post we will focus on creating a service. On one side, detecting a new service should be relatively easy with logging in place, but without event tracing, visibility into .NET execution is severely limited.

What do All These Event Logs Mean?

While not ideal, all logging was conducted on the target Windows 10 system due to the amount of logs generated by event tracing. Our fictitious story begins after some log analysis identifies a new service installed on the system via Event ID 4697.

Figure 1

Okay, so the file name for service information is definitely interesting and will require some further digging. Since we are auditing the registry, we are able to identify when a value is set/modified. When there is a change to the registry, specifically the Services hive, this notifies the analyst that someone or something has attempted to modify the configuration of a service.

Figure 2

I think if I had to choose just one event ID from Sysmon, it would be EID 1. In the log for process creation, an analyst can note the image, the full command executed as well as the parent image for the process. As seen below in Figure 3, we can now identify the application responsible for this new service, as well as find out what application ran the executable.

Figure 3

Unfortunately, this is where information on SharPersist ends. To gain more visibility into what exactly this is tool doing and to start creating detections based on anomalous behavior, we turn to event tracing for the Microsoft Windows DotNet Runtime channel.

Tracing All The Things

After installing and setting up SilkETW to run as a service, I adjusted the configuration file to log all events to an event log which could be opened in Event Viewer. Event tracing provides a view into .NET that most may not be ready for. While there is a wealth of information to be pulled out of ETW, it takes almost as much time to filter out what really is important to the analyst and what strays away from "normal".

To wade through all the logs that event tracing provides, I want to focus on monitoring events  that should stand out from what we know as normal:

  - Image/Module & Assembly loading
  - Use of P/Invoke and follow on calls to Win32 API's
  - Loading of .NET DLL's that may be unusual (mscoree, mscorelib, clr, ...)
  - Processes loading .NET assemblies that do not usually load them

This list is by no means all inclusive, but is a good starting point to detect out of the ordinary behavior from .NET.


Figure 4
Above we can see the Assembly Loading for the SharPersist tool. As I stated earlier, we have to filter out the noise to get to the parts of the log that are important.

Figure 5
Again, we can view the command line for the created service, but if you look real hard you can see *clr.dll (.NET Common Language Runtime or CLR) has been loaded by the SharPersist process. Some processes may invoke CLR, whether the event is malicious or not requires further digging and knowing your environment.

Figure 6
The use of P/Invoke allows developers to call Windows API's (unmanaged) to interact with managed code. When discussing P/Invoke for offensive purposes, think of any Win32 API you may need and what you can do with it.


In Figure 6 we can also see a number of SharPersist libraries that are called, but more importantly references to the Service Control Manager. Putting all the pieces together, we can start to understand the purpose of the SharPersist tool that created the "FINDME" service.

Figure 7

To declare P/Invoke, we need to include the "using System.Runtime.InteropServices;" namespace. In addition to the numerous libraries for Service Control  called in Figure seven, the "CreateService" method should remove any more doubt we have as to what created the service.

Conclusion

Piecing the above events together and zeroing in on the suspicious calls to the Service Control Manager class and abused DLL's, we have enough information to initiate an incident response. While it is highly unlikely an attacker would drop the SharPersist tool on the system, I believe this was a successful exercise in using ETW to identify malicious indicators.

The SharPersist toolkit offers many paths to create persistence along with some interesting tradecraft options. Combined with the numerous tools being created for .NET exploitation, I plan to keep digging into ways to identify malicious use of the framework.

As I continue learning about C# tradecraft, I plan to focus more on creating solid detections and how the use of Dynamic Invoke over P/Invoke effects visibility. Below are some links to interesting articles if your interested.

Links:

- https://www.fireeye.com/blog/threat-research/2019/09/sharpersist-windows-persistence-toolkit.html
- https://blog.f-secure.com/detecting-malicious-use-of-net-part-1/
- https://blog.f-secure.com/hunting-for-silenttrinity/
- https://thewover.github.io/Mixed-Assemblies/
- https://posts.specterops.io/offensive-p-invoke-leveraging-the-win32-api-from-managed-code-7eef4fdef16d?gi=1ad9ead0486d
- https://www.youtube.com/watch?v=FuxpMXTgV9s&t=39s

Thursday, February 6, 2020

Putting a Spotlight on CSI… the Binary, Not the Show

6 Feb 2020

While PowerShell is likely to be the go to for threat actors looking to gain an initial foothold, the power of .NET development tools cannot go overlooked. A few of these tools come native with a fresh download of Visual Studio and allow for unsigned C# code to be executed.

The focus of this post will be on csi.exe, which provides an interactive console to run C# scripts (.csx). Even for someone like me still learning, C# script files are unbelievably easy to whip up and run. The usual path for csi.exe is:

- C:\Program Files(x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\

You may be saying, 'This comes with VS? Who cares, that means it's trusted".  A few lines of C# can be executed with the same ease as in the VS IDE. If this doesn't get your attention, what if I told you there isn't a great deal of visibility into this tool?

Thursday, November 21, 2019

Easy Wins for All…Slowing Attacks With the Basics

Disclaimer:

The below was conducted in my home lab, configurations may/may not scale to an enterprise network. A good bit of work still needs to be done to the policies and configuration files.

It seems like nearly everyday a new "NextGen" product is debuted with the latest bells and whistles to stop the next APT attack.  Not many of us have the resources to update infrastructure to the latest and greatest, nor have time for a defense team to learn the product. With a majority of attacker gaining access to networks by way of LOLBINS/LOLBAS, natively on Windows, why not protect/prevent those same attacks with native tools?

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:

https://drive.google.com/file/d/19AhMG0ZCOt0IVsPZgn4JalkdcUOGq4DK/view?usp=sharing

https://medium.com/threat-hunters-forge/threat-hunting-with-etw-events-and-helk-part-1-installing-silketw-6eb74815e4a0

 https://blog.iisreset.me/tracing-as-a-service-with-silketw-pt/

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!

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.

Wednesday, August 28, 2019

Quick Network Analysis of Excel Document Utilizing WS-Discovery Protocol

 I thoroughly enjoy analyzing how malware slithers through endpoints using new/novel techniques to evade detection.  Searching through network traffic packets and putting together the "story" of the infection is just as if not more exciting.

I came across this sample some time ago, and did not immediately look at the network traffic in depth. Out of nowhere, I got the itch to analyze the traffic and found some techniques I was not familiar with.  The below will include a quick analysis of what I was able to pull from the network traffic captures.

Saturday, August 10, 2019

Malware Traffic Analysis Exercise (July 2019)

It had been a while since the last time I completed one of Brad's exercises. I felt I might be a little rusty with Wireshark and Scapy, so I decided to lookup the latest blog entry.

The exercise for this post can be found at: https://www.malware-traffic-analysis.net/2019/07/19/index.html

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