For this lab we will use the provided Windows VM. Please download it from here in advance (~12GB archived; you will need ~30-40GB of free storage on your computer).
The VM is compatible with VMWare (Workstation and Player) >16. You can download VMWare here. We recommend Workstation 17.
Tools
.
If needed, we will also use Openstack (limited capacity). Use the isc_prj
project and start a VM with the following specifications:
ISC Malware Lab
m1.isc_malware_lab
You don't need to specify an SSH key, we will be using the browser console to interact with the virtual machine.
You are Gigel, an accountant at some lifeless notary firm. One day you receive an email with an attached Excel from ¿̶̦̞̗́͗̕y̸̳̹̗̆̏̍ǫ̵̭̞́͗͘ṷ̵̝͋̽r̸̢̪̈́ ̵͈̪̥̀̈́̓ḃ̶͇̬͑o̷͙̰̊͜š̷̱͈̐s̴͔͙̿?̵̤̽͆̕ telling you it’s some important financial data that has to be submitted until the end of the day to the authorities. Have you missed something? But you’re a good accountant, how did this happen? It’s probably something the bossman doesn’t really understand and is panicked for no reason, so you decide to open the attachment. You are filled with an extreme boredom and just want to get this stuff done and go back to scrolling Reddit, so you ignore any and all pop-ups, allow everything (despite the constant nagging of those pesky IT guys).
The attachment is on your Desktop. Go ahead, open it. What could go wrong?
One of the most common infection vectors is phishing and social engineering, which relies on the user simply opening a malicious binary. In our case, simply opening that Excel document got you infected. You might not see anything suspicious happening for now, so keep reading.
While the VM we provided has some included tools for analysis, you probably don’t know where to get started. We recommend trying one of the available online sandboxes available.
The sandboxes mentioned above will take the documents you upload, run them (just like you did), but they also run some static analysis and monitor a few other things:
Pick one sandbox and submit the Excel document. See what info you can gather from the results.
From sandbox results, you can probably observe some references to a Powershell process being started by Excel. Powershell is a shell, just like bash
and is (at least from Windows 10/11) the default system shell on Windows. So, why would Excel, a spreadsheet program, need to open a shell prompt and run commands? In usual operation, it doesn’t, but for more advanced use cases, Excel (and some other Office products) allow you to write “macros”, which are functions written in the Visual Basic programming language.
You can read more about this
Since our macro got executed when we opened the document, we need a way to see it without running Excel. We can use the oletools
Python package for this.
Read the documentation for oletools
, available on Github and extract the macro. oletools
is already installed in your virtual machine.
Observe the output you got from oletools
. It also provides some insight into what the macro is doing, including the reason it automatically executes when the Excel workbook is opened.
We recommend using CyberChef to decode the powershell payload that is executed. Some useful CyberChef functions you might want to use (not completely necessary to use all of them): Find/Replace
, Drop Bytes
, some decoding function (figure out the encoding, or let CyberChef help you), Decode text
.
In the end you get a weird looking Powershell script. You don’t need to worry about understanding it, but if you want to read more, you can do it here. Some useful information you can get from this Powershell script:
What you uncovered is a command and control stager. Command and control attacks are a type of attack where a program is used to gain control of the infected computers. This requires a connection to a command and control server, where attackers can see the infected devices and send command to them. Some functionality of command and control binaries:
Attackers might neglect the security of their own infrastructure. Check if this is the case. Maybe try some other known ports? (nmap
is installed, but you probably don't need it)
The C2 stager we used is a pretty simple one. If you want to read more about C2 capabilities you can read this awesome blog post series about Sliver.
As a backup, the ransomware binary can also be found in C:\Users\<your_user>\Documents\backup
As before, go ahead and run it, see what happens.
Ransomware is a type of malware that encrypts documents and files on your computer, demanding a ransom to obtain a decryption key or program. In our case, the entire content of the very_secret_documents
folder on your Desktop has been encrypted.
But is there any way you can recover those files? Since we presume the attacker has a decryption key for your files, that means the ransomware must communicate in some way. Try and use Wireshark to see if any traffic seems out of the ordinary.
Try and find the decryption key.
Decrypt the files, maybe they contained a flag. You can use the provided decryptor.exe
(on your Desktop), or you can challenge yourself and try to decrypt them manually (CyberChef can be of great help here; assume the encryption is a well-known one).
As the name suggests, this type of malware steals information from your system. Usually, they steal browser data, since it can contain:
As before, run the provided infostealer.exe
from your lab assistant (or the backup one)
Seemingly nothing happens (except that your browser might close on you), but let us take a look at what files are accessed by infostealer.exe
. We can use the tool procmon64
from the Sysinternals Suite to analyze some of the runtime behavior of a program, including accessed files and network activity.
Find what information has been stolen from you. There’s a flag in there.
Use procmon64
to look for accessed files and network activity. By default procmon64
shows what all current processes are doing. Try and filter for our process (look at what options procmon64
offers you at the top of the window).
Also try to have a look at the files that are managed by Chrome and check out the links at the end of the lab if you want to better understand how he passwords are stored. You also have a tool to explore SQLite databases installed already.
If you were brave enough to try and decompile the executables, you might have noticed they look like gibberish. If not, use Ghidra to have a look at one of the executables.
The executables are missing any symbols and the code seems very hard to understand. That is because they are packed using UPX. While UPX is an executable packer, meant to be used for executable compression, it is also commonly used to make reverse engineering harder.
The good news is that you can also unpack it using UPX. It is already installed in your VM, so give it a try.
After unpacking it, try to decompile it again using Ghidra. Does it look a little bit more readable?
It is still not as readable as if you were expecting if you ever looked at a C binary decompiled, and that is because our executables were written in Go. Another technique that makes reverse engineering harder is the use of modern languages (Go, Rust, Zig, Nim), as they each come with their own (complex) runtime.