Grube Security

Introduction:

There are many different tools, settings, configurations, etc. when it comes to sandboxing so I figured I would write about some that I've used and had success with. This tutorial will cover Sysmon event / network connection logging and PowerShell logging. In future blog posts I will write about many other sandboxing tools, techniques, and use cases.

What you will need :

Virtualization software: VMware, VirtualBox, etc.
Windows 10 ISO or virtual hard disk with Windows 10 installed

Notes:

PowerShell logs and Sysmon logs are great tools to have in a sandbox environment. However, having them enabled on as many machines across your network as possible is where the real value is it. Having these logs (in addition standard Windows logs) centrally stored and readily accessible can drastically improve your ability to detect and respond.

Please use extreme caution when working with live malware. I am not responsible for anything as a result of this tutorial

Tutorial

Installing Sysmon

1.) Install your virtualization software (VMware, VirtualBox, etc.)

2.) Boot up Windows 10

3.) Install Sysmon:

Browse to https://technet.microsoft.com/en-us/sysinternals/sysmon and download the latest version
Unzip the zip file it came in

Inside of the zip file you will see three files:

A EULA
Sysmon.exe
Sysmon64.exe

In an administrative command prompt navigate to the unzipped Sysmon directory
In the command line Type “Sysmon64.exe –i –n –l”

-i = Install the Sysmon service and drivers
-n = log network connections
-l = Log loading of modules (DLLs loaded by processes, etc.)

Note: By default Sysmon will automatically log the SHA1 hashes of created processes and libraries. You can change the hashing algorithm by throwing the -h flag

Ex: “Sysmon64.exe –i –n –l -h md5”

To check and see if Sysmon was installed correctly, type the following command:

Sysmon.exe -c

You should now see the following output:

Locating the Sysmon output

The Sysmon output is stored in Windows event logs under the following file path

C:\Windows\System32\winevt\Logs\ Microsoft-Windows-Sysmon%4Operational.evtx
I recommend increasing the max log size of this particular log. To do this, open event viewer and go to àApplications and Services Log à Microsoft à Windows à Sysmon à Operational. Right click on this log and set the “Max Log Size” field to your liking. One GB or more should be enough in most cases.

Introduction To PowerShell Logging

Investigating PowerShell based attacks is an essential skill to have in your forensics investigative skillset. Without some sort of logging, process monitoring, etc. it can be rather difficult to figure out what happened on a host based level when it comes to PowerShell based attacks. The next section of this tutorial will show you how to implement PowerShell logging in your sandbox. To begin, it is important to understand the capabilities of PowerShell logging and what each log type means. I highly recommend reading this article written by Matthew Dunwoody of FireEye that describes the capabilities of PowerShell logging in great detail.

Enabling PowerShell Logging

To turn on PowerShell logging perform the following:

Press the Windows Key + R (to open run)
type gpedit.msc

This will open the local group policy editor

Browse to Administrative templates ---> Windows Components ---> Windows PowerShell

Double click on the logging option that you want to turn on and click "enable"
When enabling transcript logging make sure you specify an output directory.

The other PowerShell logs are written to an event log that can be found at C:\Windows\System32\winevt\Logs\Microsoft-Windows-PowerShell%4Operational.evtx

I also recommend increasing the maximum size of these logs (just like we did for the Sysmon logs)

Examples

PowerShell Logging Example

For this example, I have created a macro enabled Word document that when opened, executes a fake piece of malware via PowerShell located at the root of the C drive. All this fake malware does is query the name of the machine, gets the current time, and will ping grubesecurity.blogspot.com. Shown below is a screenshot of my macro enabled word document and its corresponding macro code. Often this code will be obfuscated, but for the purpose of this tutorial it is not (part of it is only base64 encoded.)

Sub AutoOpen()
Dim exec As String
exec = "powershell.exe -nologo -executionpolicy bypass -noninteractive -windowstyle hidden -EncodedCommand QwA6AFwAZQB2AGkAbABfAG0AYQBsAHcAYQByAGUALgBwAHMAMQA="
Shell (exec)
End Sub

The first log we will look at is the output of the transcription log. Now remember that the results we be stored inside of the directory you specified via group policy. For this example I decided to place my output at "C:\PowerShell Transcription Logging Output." Notice in the screenshot below that the output folders are named based on the date.

When viewing the output you can see the command that the macro ran. When you base64 decode the EncodedCommand parameter it reads "C:\evil_malware.ps1" which tells PowerShell to run the fake malicious script. Notice that you can only see the output of the evil_malware.ps1 script. I am highlighting this because it's very important to know what you can expect to see when looking at any sort of log. In this case, you will see exactly what the attacker saw, which is the output of the fake malicious code. If this had been Mimikatz you would have seen which credentials, hashes, etc. that the attacker was able to obtain on the system. In the next example, we will look at the output from the PowerShell script block logging which will show us the source code of the evil_malware.ps1 file.

To recap, in the last example we looked at the output of the fake malicious code via PowerShell transcription logging. Now we will look at PowerShell script block logging. This means that we will now see the deobfuscated code of the evil_malware.ps1 file. To view the log file, open Event Viewer and go to Application and Service Logs --> Microsoft --> Widows --> PowerShell --> Operational. Shown below is the data for event ID 4104 which contains the source code of the evil_malware.ps1 file.

Sysmon Example

The last item we will look at is the output of Sysmon. To view the log file, open Event Viewer and go to Application and Service Logs --> Microsoft --> Widows --> Sysmon --> Operational. In the screenshot below you can see the malicious PowerShell command was run by a Microsoft Word document named "Grube Tax Document.docm."

Sources

Introduction

Every now and then I like to poke around on the internet and find malware samples, packet captures, challenges, etc to mess around and have fun with. The following packet capture was obtained from http://www.malware-traffic-analysis.net. My objective on these posts is to try and solve them myself in my own style and post my analysis in hopes to help and entertain other security professionals.

Exploit Kit Overview

There are many different types of exploits kits out there. At the time of this blog post perhaps four of the more famous ones are named Angler, Rig, Nuclear, and Neutrino. Although they have different names, they fundamentally operate in the same way. This section will give a brief overview of how exploit kits work. Shown below are five components of an exploit kit to think about during an investigation.

Initial delivery

Legitimate compromised site, malicious email link, malvertising, etc.

Gateway (optional)

A gateway is essentially a initial screening mechanism.

Ex: Only try to exploit Windows machines.

Landing Page

The landing page is where the magic happens. Here, the landing page will gather information about about the victim and choose an exploit based on its results.

Exploit

Exploit kits generally target applications like, but not limited to, Adobe Flash Player, Silverlight, Java, web browsers, etc. If the landing page finds a vulnerable application it will deliver the corresponding exploit for that vulnerability.

Payload

Exploit kits can drop whatever they wish as a their payload. In this example, I will be investigating a case where the payload is Spora ransomware.

Investigation

This particular investigation is composed of the following:

Initial delivery = compromised website
Gateway (optional) = There is no gateway in this example
Landing Page = Rig Exploit Kit
Exploit = Shockwave Flash
Payload = Spora Ransomware

While investigating the compromised website I ran across an interesting snippet of JavaScript that had been injected at the bottom of the webpage. In short, this section of the JavaScript is creating an inline frame (iframe) to load the Rig-V exploit kit landing page. From here the exploit kit will try to determine if the victim is vulnerable to any of its exploits. If so, it will attempt to compromise the victim's machine with its chosen exploit. All of this is happening in the background without the end user knowing. All the end user did was browse to a completely legitimate website.

In this case, the exploit kit determined that the victim was running a vulnerable version of Adobe Shockwave Flash. You can determine this by looking at the packet capture and seeing the "CWS" file header in the server response. When looking at this type of material it's a good idea to look at the file headers and footers and not rely on the content-type HTTP header. The only HTTP header that is required in the server response is the response code. Everything else is optional and arbitrary.

After carving out the Shockwave Flash file from the packet capture, I submitted the SHA1 hash of the file to VirusTotal and got the results shown below. The objective of this Shockwave Flash file is to act as a downloader and install other malware (in this case it installed the Spora Ransomware.) I was going to include a host based analysis on this ransomware but I figured this post was already getting lengthy and I thought it might be good for another day.