🚷

Anti-Analysis in Malware

In this post we’re going to look at some anti-analysis techniques that malwares use to prevent, or at least give a hard time to researchers to analyze them

Anti-VM

  1. Processor Checks
    1. VMs are usually allocated one processor, which is unlikely a user machine.
  1. RAM memory check
    1. VMs are usually allocated a small amount of RAM, which is unlikely a user machine
  1. Running Processes Checks
    1. Hypervisors and VMs usually have their own software running within the VMs
    2. The malware checks if such processes exists in the process list
  1. Registry Key Checks
    1. Virtual Machines usually have special registry keys written in the registry
  1. CPUID
    1. The CPUID opcode allows the program to get information on the processor
    2. If EAX==0 then the processor manufacturer string will be returned
    3. In the case of VMWare, the string would be VMwareVMware
APIs called
CPUID() CreateToolhelp32Snapshot() Process32First() Process32Next() RegOpenKey() RegQueryValue() GetLogicalProcessorInformation() GetSystemInfo()

Anti-Sandbox

  1. Processor Checks
    1. Sandboxes are usually allocated one processor, which is unlikely a user machine.
  1. RAM memory check
    1. Sandboxes are usually allocated a small amount of RAM, which is unlikely a user machine
  1. Storage Checks
    1. Sandboxes are usually allocated a small amount of Storage, which is unlikely a user machine
  1. Registry Key Checks
    1. Sandboxes usually have special registry keys written in the registry
  1. Username Checks
    1. Sandboxes typically have default names or names like SANDBOX\
  1. Sleep
    1. Sandboxes don’t run forever and terminate after some time. A malware may therefore sleep for a few hours before executing
APIs called
Sleep() GetUserNAme() GetComputerName() GetModuleHandleA() RegOpenKey() RegQueryValue() GetLogicalProcessorInformation() GetSystemInfo()

Anti-Debug

  1. IsDebuggerPresent/Process Environment Block → Being Debugged
    1. Returns 1 if the process is being debugged
  1. Self-Debugging
    1. Spawns a child process to debug itself
    2. A process can only be debug by 1 process, so if the child process fails, the malware know it’s being debugged
  1. Timed checks
    1. Stepping over code is slow than the code executing
    2. If the time it takes to finish a function is too slow, it means the process is being debugged
  1. Running Process Checks
    1. Gets a list of running process and checks for process like Wireshark, IDA or x32dbg
  1. GetModuleHandle
    1. Malwares will try to open common DLLs that are specific to sandboxes and debuggers like dbghelp.dll or sbiedll.dll
    2. If the file is present, its likely that the malware is being analyzed
  1. File Checks
    1. Checks for files present that are specific to some software like Wireshark, which has \\.\NPF_NdisWanIp file located on the machine
APIs called
IsDebuggerPresent() CreateToolhelp32Snapshot() Process32First() Process32Next() GetModuleHandle() CreateFile() GetTickCount() NtQueryPerformanceCounter() DebugActiveProcess()
Gets information from the Process Environment Block within the Thread Environment Block
Within the PEB there are flags like BeingDebugged which can tell the malware if it’s being debugged
notion image
Getting the value from [eax + 2] will return the value of BeingDebugged in the PEB
notion image
Getting the value of [eax + 68] will return the value of NtGlboalFlag in the PEB, which will be 0x70 if the process is being debugged
notion image
notion image