🦹Malware Analysis
Precautions
Never analyze malware or suspected malware on a machine that does not have the sole purpose of analyzing malware.
When not analyzing or moving malware samples around to different locations, always keep them in password-protected zip/rar or other archives so that we can avoid accidental detonation.
Only extract the malware from this password-protected archive inside the isolated environment, and only when analyzing it.
Create an isolated VM specifically for malware analysis, which has the capability of being reverted to a clean slate once you are done.
Ensure that all internet connections are closed or at least monitored.
Once you are done with malware analysis, revert the VM to its clean slate for the next malware analysis session to avoid residue from a previous malware execution corrupting the next one.
Static Analysis
Dynamic Analysis
Perform it on an isolated VM.
Sandbox construction
For malware analysis using sandboxes, the following considerations make the malware analysis effective:
Virtual Machine mimicking the actual target environment of the malware sample
Ability to take snapshots and revert to clean state
OS monitoring software, for example, Procmon, ProcExplorer or Regshot, etc.
Network monitoring software, for example, Wireshark, tcpdump, etc.
Control over the network through a dummy DNS server and webserver.
A mechanism to move analysis logs and malware samples in and out of the Virtual Machine without compromising the host (Be careful with this one. If you have a shared directory with your malware analysis VM that remains accessible when running malware, you might risk malware affecting all files in your shared directory)
Sandboxes tool
Online Sandboxes (Online Cuckoo, Online Cape, Any.run, Intezer, Hybrid Analysis)
Sandbox Evasion
We can always run a sample in a sandbox to analyze it. In many cases, that might help us analyze samples that evade our basic static analysis techniques. However, malware authors have some tricks up their sleeves that hamper that effort. Some of these techniques are as follows :
Long sleep calls: Malware authors know that sandboxes run for a limited time. Therefore, they program the malware not to perform any activity for a long time after execution. This is often accomplished through long sleep calls. The purpose of this technique is to time out the sandbox.
User activity detection: Some malware samples will wait for user activity before performing malicious activity. The premise of this technique is that there will be no user in a sandbox. Therefore there will be no mouse movement or typing on the keyboard. Advanced malware also detects patterns in mouse movements that are often used in automated sandboxes. This technique is designed to bypass automated sandbox detection.
Footprinting user activity: Some malware checks for user files or activity, like if there are any files in the MS Office history or internet browsing history. If no or little activity is found, the malware will consider the machine as a sandbox and quit.
Detecting VMs: Sandboxes run on virtual machines. Virtual machines leave artifacts that can be identified by malware. For example, some drivers installed in VMs being run on VMWare or Virtualbox give away the fact that the machine is a VM. Malware authors often associate VMs with sandboxes and would terminate the malware if a VM is detected.
Packing/Obfuscating Malware executable : compresses or encrypts the content of malware. These techniques make it difficult to analyze malware statically. Specifically, a packed malware will not show important information when running a string search against it.
Last updated
