Reverse Engineering
Packing and Obfuscation
Sandbox Evasion
In the case of more advanced malwares, they are programmed to detect if they are being run in a sandbox environment, and will instead demonstrate benign behavior.
Obvious next question: how do they identify that they are in a sandbox?
Environment Checks
This is the most common way. The malware looks for specific artifacts like files, processes, register keys that are usually found in virtualization and analysis software.
Files VBoxGuestAdditions.sys - VirtualBox, vmtoolsd.exe - VMware
Registers HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Tools
Processes procmon, x64dbg, windbg, wireshark
Hardware
VMs tend to have pretty obvious names and unusual hardware specs. Malware will use Windows Management Instrumentation to look for names like "VirtualBox Graphics Adapter," and "VMware Virtual IDE Hard Drive," instead of "NVIDIA GeForce RTX 4090". It'll also check for abnormal system resources stuff like 1 CPU core, <8GB RAM, <250GB hard drive.
Stalling (sleep evasion)
Another common way is that the malware will simply call the sleep() function with a duration of more than 30 minutes. This will time out most automated sandboxes as they only have a run time of 10 - 15 minutes.
In the same vein but more advanced, the malware may use CPU instructions like Read Time-Stamp Counter to measure how long it takes to execute certain code. VMs will take longer than bare-metal in cases when instructions like CPUID are run. In the case of sensitive instructions which require higher privileges, the CPU must pause the VM, get the hypervisor to emulate the instruction's result, then resume the VM which causes a notable lag.
User Activity Detection
Malware can also check for the lack of human activity and user history in the environment. Examples include a short uptime of 10 - 15 minutes as the sandbox was just started, or it can wait for mouse movements and clicks as a trigger. It can also check for user history such as ensuring there are files in folders like Downloads or Images or even worse, check for activity in browser history. At that point, just give me the malware instead.
More resources on this topic:
Ghidra
Is a disassembler/RE tool that was created by the US NSA circa 1999, got teased in 2017 but was only released publicly in 2019. Basically helps us to decompile binaries into C to understand what it does, disassemble binaries into assembly so we can figure out low level operations, and debug binaries to examine its behavior.
Getting started:
Shared Project will allow us to share with others. We then drag and drop the file of interest into Ghidra, which will give us a results summary:
We then double click on the uploaded file in Ghidra which will open it in Code Browser, and yes we want to analyze it.
We now choose our analysis options here. For now we'll just stick to basics.
Program Trees We finally get to see the sections we covered in PE headers.
Symbol Tree Has key sections like the imports, exports, and functions that the executable calls or gets called to.
Data Type Manager Shows data types found throughout the program.
Listing Shows the disassembled binary in the following order: virtual address, opcode, assembly instructions, operands, and any comments.
Decompile Translates assembly code into pseudo C. This helps us make sense of the assembly mess Jesus.
Toolbar - Graph view: gives us a graphical view of the disassembly. - Memory map: shows the memory mapping of the program. - navigation toolbar: options to navigate the code - string search: shows the strings
Commonly abused APIs:
The common categories of APIs that malware abuse are:
keylogger
downloader
C2 comms
data exfiltration
dropper
API hooking
anti-debugging and VM detection
Great resource to learn more about malware families: https://malapi.io/
Last updated