Malware Analysis Beginner Guide - Diary of a Cyber Mid-Careerist

I am still new to this so the methodology would improve with time. This post is written while going through TCM Security’s Practical Malware Analysis & Triage course with a view of taking the PMRP

Preparations

FLARE-VM (with cosmos.jpg as the target for the custom malwares in PMAT)
Remnux VM (Article on how this can be set up here >>> )

Always be safe. Defang your malware. Zip up malware with password when moving the malware from location to location.

Static Analysis

The idea for static analysis is to (1) see if it has already been captured in the wild (making our analysis work easier) and/or (2) generate hypotheses on the malware’s purpose and actions which can be tested during dynamic analysis.

Hashing

Ah yes the bottom layer of the Pyramid of Pain. File hashes are an easy and low hanging fruit to go after though hashes can be easily changed with a single byte. That said, attackers can be lazy chaps as well and hashes are easy to get and check.

#powershell
Get-Filehash -Algorithm sha256 evil.exe.malz

# Alternatively FlareVM has a lot of tools that allows you to just right click a file and get their hashes

Sooo what do you do with a hash? Head to Virustotal(VT) and slam in your hashes and see if it is found in the wild. (*Warning: You should not upload files to VirusTotal for OpSec reasons as threat actors will monitor VirusTotal to see if their malware has been discovered)

Now VT can give a lot of information such as the assessed malware name, family and even details.

STRINGS

Collecting ASCII strings from a binary can reveal potential Indicators such as ip address, domain names, mutexes, import libraries, winapi function calls and many interesting stuff that can fingerprint the binary/malware.

Floss is strings on steroids.

#cmd

# -n 6 is to pull only strings of length 6 or greater
floss -n 6 evil.exe.malz

Malware authors may not hardcode any domains or ip and those will only be compiled at run time.

Import Tables/ Section Headers

I will be using PEStudio here to analyse the PE. (https://www.winitor.com/download). PEStudio does strings, hashing, analyses the PE for indicators, output the IATs and the various sections.

The example malware we are using here is the “Malware.unknown.exe” from the PMAT repo.

What we want to look out for:

Time Date Stamp/compiler stamp (from IMAGE_NT_HEADERS)

Virtual Size vs Raw Data size (will be in hexa) (can be found in .text Section Header)

Import Address Table ( malapi.io is a good resource to see which winapi functions are used for which TTPs;note what kind of APIs are being called to form hypotheses)

Is malware packed or not packed? Packing is kinda like compressing the malware code. At run time, the stub will then look at the small little code and then decompress. May evade some AV that is looking for overt signatures that may not be found when packed.
Another way of seeing if a malware is packed is to compare the raw size versus the virtual size. if the raw data is much smaller than the virtual size, likely that it is packed. Packed malwares requires detonation to examine its behavior

Analysing via PEStudio

We import the malware and wait for PEStudio to fully analyze the file. We should see something like this

The awesome thing about PEStudio is that it does its own initial assessment of the binary and we can see it flagging out some indicators that are worth examining further. For example we see urlmon.dll and WININET.dll which suggests that the malware may involve some kind of network connection outwards to download follow on tools or to the C2. We also see “url-patterns” that may be used for beaconing or C2 or to download additional tooling. This supports the .dll indicators. We see potential human signatures such as compiler software, and debugging information.

CAPA (A Static Analysis Tool)

https://github.com/mandiant/capa

The github also has pre-defined rules that can be used

#cmd
-r <path to rules>
-f <format>
-v # reports match locations


capa evil.exe -r <custom rules>

What to have at the end of Static Analysis

File hash
VT Analysis
Strings of interest (check for indicators)
Import Address Tables
API Calls

Basic Dynamic Analysis

Will allow us to collect host and network indicators

We will be using the Malware.unknown.exe. We have established a couple of hypotheses based on static analysis.

Before detonating the malware, lets prepare the following:

Remnux VM with inetsim set up. (ensure DNS service is running). Set up Wireshark/TCPDump and start listening on the network interface. At this point in time, we will want to run the malware two times (one with inetsim and the other without)
On FlareVM, prepare ProcMon. For Procmon, stop capturing events and then go to the Filter tab and Drop Filtered Events. Afterwards, press the eraser icon near the Capture button to clear all existing events. This is to reduce the amount of noise before we detonate the malware.

Once you are ready, go to Filter and then select Process Name IS <name of malware> and ensure that it is include. Press Add to add our malware process name into the filter.

Once we are gucci, click Start Capturing (which we paused earlier) and then execute the malware.

What we want to examine initially are things like CreateFile (which includes files that could be dropped). We find that a suspicious .dat file was created and dropped into a folder. We can check and see that this is true!

Another thing to look at is to look at Parent-Child Processes. We can look at this using the Process Tree option in ProcMon. You can also pivot off PID of the malware and see what it spawns.

Another thing we want to examine is a command line from the static analysis that appears to have the malware delete itself via cmd.exe if the url it is trying to reach does not exist

From our basic static analysis, we see a string of a url address that contains favicon.ico. Hence on our Remnux Wireshark, we can set a display filter to output any packets that contains favicon.ico to examine what it is linked to. The display filter is

http.request.full_uri contains favicon.ico

At this stage, we can create a basic program execution flow:

if URL Exists:
- Download favicon.ico
- execute favicon.ico
If URL does not exist
- Delete itself

Additional Network Analysis

Besides running Wireshark to capture traffic on Remnux, it is also important to see what kind of sockets are opened as a result of detonation on the Flare-VM Host as well. We can use TCPView and see what ports and ip addr are opened as a result of the detonation. (we can also use ProcMon and filter for TCP operations to see the same thing)

Once we figure out which ports are open, we can go back to remnux and then use nc to connect to the port to see what happens!

Redirection to localhost

Sometimes a malware might be trying to reach out to some domain. A way to attempt to trick the malware is to simply edit the /etc/hosts of the FLARE-VM and just direct the domain to localhost of the FLARE-VM.

We then run a listener on the port that the malware might reach out to (ncat -nvlp <port>) then execute the malware

Diversion: Simple Overview of x86 CPU Instructions, Memory Registers and the Stack

CPU Instructions

Generally three types: Arithmetic, data movement, control flow
common instructions include sub, mov, jmp
x86 is little endian and instructions are from right to left

mov edx, eax  # move eax into edx
jmp <memory location> 
jnz # jump if not zero

# stack instructions
push
pop

Stack

stack grows downwards. The highest memory address is 0xffffffff and the lowest is 0x00000000
the first variable is on the highest memory register. (first in, last out)/Last In, First Out
When new stuff is push, they go downwards
when pop from stack, the bottom gets removed first

Memory Registers

The important ones are (eax, edx,ebx,esp, ebp and eip

EXAMPLE: HELLOWORLD.C

We are going to look at a program written in C through the lens of Cutter.

# The below shows up when calling a function such as main
push ebp // preserves the calling fxn base address so that once the function executes, we can return back to that address

mov ebp, esp //move the stack pointer value into the base pointer to set up our stack frame

ret value, any other registers we want to hang onto

add local variables here

add parameters

stack pointer itself

Advanced Static Analysis

We will be using Cutter to examine the Dropper.DownloadFromURL.exe.malz sample.

Open the malware sample using cutter and you should get a screen like this

Typically we look at the entry point which is usually main function. We can also look at what the disassembler interprets as the program flow using the Graph tab

The decompiler tab attempts to reconstruct the code

Lets take a look at the main function (comments added)

—

Process Injector Analysis (Malware.stage0.exe.malz)

Static Analysis

Hashes	fca62097b364b2f0338c5e4c5bac86134cedffa4f8ddf27ee9901734128952e3 (SHA256)
PE characteristics	32-bit PE Compiled 7 Oct 2021, 17:43(UTC)
Strings of Interest	C:\Users\Administrator\source\repos\CRTInjectorConsole\Release\CRTInjectorConsole.pdb ./mingw-w64-crt/misc/invalid_parameter_handler.c
Packed?	?
IAT
Fingerprints	Tooling: MinGW GCC \| Nim Compiler (Source:PEStudio)

Initial Assessment

VT Results –

Dynamic Analysis (No INETSIM)

Upon Detonation, on Procmon, using the process tree, we see the following Parent-Child relation

We see that our malware spawned a child process of werflt.exe which was found in the C:\Users\Public folder. Now the Public folder is one of those directories where malware drop their files as it is by default writable by all and I am fairly certain that this PE did not exist pre-detonation which makes this mighty suspicious. Checking the hash of this PE on VT reveals that this is likely malicious. We also see the same debugger string from the malware when we used PE Cutter to examine this PE.

On TCPView, i did see briefly an attempted connection by Werfault.exe on port 8443. Hence I opened up a netcat listener on port 8443, detonated the malware and lo and behold, it appears I have command execution with a reverse shell.

As of now the program flow appears to be as such:

Upon execution of the malware, drops werflt.exe into C:\Users\Public
Execute werflt.exe with a random parameter (which appears to be a desired PID)
This appears to spawn the legit 32bit version of Werfault.exe with the PID of whatever that was passed to werflt.exe.
This exe then attempts to open a connection to localhost on 8443
- If nothing happens, there does not appear to be any re connection attempts
If connection is successful, open a reverse shell with full command execution

Advanced Static Analysis

We analyse werflt.exe using cutter.

This is a classic process injection where the malicious code is injected into the memory of a benign process to evade detection

Advanced Dynamic Analysis :O

We will be using the x32dbg to debug the Dropper.DownloadFromURL.exe