Since I began exploring the vast world of cybersecurity, I took a particular interest in the forensic analysis and dissection of computer viruses (malware). Although I spend every waking minute of my spare time researching, exploring and disassembling how these nefarious binaries work, as well as exposing the actors behind them, I always find there is another tool or setting I need to learn that makes me better. Why do I open the post like this? Well, if you are learning, I want to save you time. If you are researching me as a prospect for a potential hire, I believe it’s best for you to understand how I work, what tools I use and what my workflow looks like when I am conducting incident response. Let’s buckle up, settle in and check out my setup.
1) Operating System
Natively, I run Kali Linux. While this distribution is regularly associated with hacking over cyber defense, I like the tools that come pre-installed and it got me up and off the ground rather quickly. After I am on the desktop for Kali, I have virtual machines set up that run several other Operating Systems, dependent on the malware that I am set to analyze. I have Virtual Machines pre-configured to run Windows FLARE or Remnux, depending on if the Malware was written for Windows or Linux. These virtual machines give me an environment that is totally separate from my main operating system with the ability to control their clipboard capabilities, network connections and more. If I am going to connect them to the internet in an attempt to discover where network traffic is being sent to, I will switch to a configuration that routes it’s traffic through WHOINX, which encrypts and sends traffic through the TOR network so they cannot find my routers IP address. However, when performing static analysis, I will have networking capabilities switched OFF so that no contact with the outside world occurs. Sometimes this works, sometimes it does not, as there are many malwares out there that can identify if they are in an analysis environment.
2) Tools – Static Analysis
The majority of my malware analysis takes place on a Windows instance, as there are more than 1,000,000,000 malware programs out there and most take place on Windows machines. This is because Microsoft offers both consumer and enterprise-grade products that all use the same codebase, as well as most gaming devices being Windows based. So large graphics cards or processors are likely to be found in these machines, exploitable for cryptocurrency mining.
When I start my process, I will take my notes in Leafpad on the Kali Linux OS, completely outside of the virtual instance that is dissecting the malware. Inside the virtual instance, I will start with static analysis, the practice of dissecting the executable without actually running it. I will start by running the file through a program called filetype.exe, which comes bundled with FLARE. This program shows me a fiels true intentions, for example: A .png file that is actually an executable (.exe). A user can open the .png, see a picture of a cute puppy, unknowingly installing ransomware to the machine, for example. After this, I will be opening Powershell in the FLARE VM, launching the following code on the executable:
Get-ChildItem | Get-FileHash -Algorithm SHA256
This gets me the SHA256 hash of the executable, whether it is a .exe, .pdf, or .docx, etc. I then compare this hash against the database at VirusTotal, which isn’t perfect, but it will tell me if this virus has been found in the wild before. After this is done, and notes have been added to Leafpad, I will launch a program called ssdeep, which is a tool that computes context triggered piecewise hashes (CTPH). Also called “fuzzy hashes”. I compare these values, running them through VirusTotal.
After I have this information together, it’s time to open up strings.exe in FLARE. This program will dissect the .exe and look for any strings, imports or variable names, which can tell me a lot about how the program runs and which system calls it uses to operate. Here is a photo example of strings being run on a .png that is actually an executable:
As I’m sure you can see, there are several system calls that are concerning: GetCurrentProcessID, MapViewOfFile, SleepEx, etc. This .png ended up being a variant of Qakbot, a very dangerous banking malware that attempts to steal banking information from it’s victims. After I’ve made my notes here in Leafpad, I move on to Dynamic Analysis, where I detonate the virus in the machine and monitor it’s behaviour!
2) Tools – Dynamic Analysis
Okay – the time has come to detonate this malware. Now, before I go ahead and run it, I want to make sure I have a suite of tools running in the Windows environment, capturing logs and saving the files for later analysis. These tools are: Procmon, Wireshark and Task Manager.
Procmon is a tool that monitors the processes on your system hardware. All system calls, registry edits and network activity will pass through this application that is freely offered by Microsoft. After detonating a malware, I will carefully watch to see if files are being downloaded, created, encrypted or edited. I will also watch for changes to the registry, such as creating new users, editing permissions, or creating persistence within the Operating System so the attacker can maintain access to the machine after a restart.
Wireshark is a free-to-use packet inspector. I watch and monitor for calls to external IP Addresses and will eventually follow those trails, performing WHOIS audits or nmap scans against the IP’s to see if I can trace any activity back to a name or pseudonym. Modern malwares deliver a lot of information to Discord, obscuring this feature. However, I still usually find remnants left behind on the system, like when I hunted down the XLD group with their stealer in November of 2022.
Task Manager well, it’s simple and it works. I look to see if a task comes up, or a process is run under another host process that I should investigate. I usually find that similarly named programs to default applications in Windows are running in weird install folders, like the %tmp% or %AppData% directories. This shows me where the malware hides itself.
I note all of these newfound pieces of information in Leafpad, and move on. In the next blog post, we will go over forensic analysis using tools like Ghidra, which allow a user to completely reverse-engineer applications down to ASM (Assembly or Machine Code) to try and understand the source code and what the application is doing. That’s enough typing (and information!) for today, thank you all for coming to my site and reading. I hope you learned something today!