Malware Anti-Analysis Techniques and Ways to Bypass Them

This article series will focus on various anti-analysis techniques used by malware, and then we will discuss various ways in which the anti-analysis techniques can be bypassed by the analysts to consider all malware artifacts. In this article, we will focus on anti-analysis techniques and a very basic way to bypass the technique.

Various techniques are employed by analysts to analyze a malware like spawning up an isolated VM and then capturing artifacts, running malware in automated sandbox environments, etc. but most malware have become sophisticated now and they check for the environments in which they are operating, and only when they see the free environment they exhibit their full characteristics. Below are some of the anti-analysis techniques that malware employs to protect themselves from being analyzed

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

• Malware detects whether it runs within a virtualized environment or not. For example:
  • IN instruction is a privileged instruction and cannot be used in user mode unless the necessary privileges are enabled. However, VMware uses IN instruction to read from a special port which is the communication port between host and VM. Here is a code to check for this
    • Mov eax, 'VMXh'
    • Mov ebx,0
    • Mov ecx, 10
    • Mov edx, 'VX'
    • In eax, dx // this will read the value from the port into eax. If VMware is present, then the flow will continue. Otherwise, exception will occur
    • Cmp ebx,'VMXh'
  • Malware can check the location of Local and Global Descriptor tables and Interrupt descriptor table register since in virtualized environment they must be moved to different memory address to avoid conflict with the host.
  • B using CPUID instruction to find out the hypervisor brand. For example by calling CPUID with EAX =4000000 as input 1.
  • Malware looks out for known MAC addresses that products like VMware tend to use.
• Malware detects whether it runs within a sandbox environment or not. For example,
  • Malware check for sandbox by looking for mouse movements
  • Malware can check for active windows
  • Malware can check for size of hard disk
  • Malware check whether foreground color changes or not
  • Malware checks whether clipboard contents are empty or not.
• Malware detects whether any tools are present on system or not. For example,
  • Malware often look at the installed application in the system or running services and look for common analysis tools like Wireshark etc. Upon detecting some malware, it will simply terminate whereas some malware will run completely differently to take the investigation completely off track.
• Malware detects whether it is being debugged or not. For example,
  • The most common way that malware authors check is to find IsDebuggerPresent. If this returns true, then malware often terminates.
  • Another way malware functions is to check for the tick count i.e. they run tests to see how long it takes for the malware to hit a functionality and they set a counter for that because while debugging it will most probably exceed that counter.

Now that we have seen most common ways that malware employs checks for different analysts' techniques, now let's look into an example where a malware checks for Debugger present on the system or not and then how can we bypass that malware check and continue analyzing it.

Below malware, specimen runs normally when it gets launched on the system and connects to its C&C server, but as soon as it is loaded into OllyDBG, it just terminates.

So, let's load the malware into Ollydbg and before running it let's consider names used by this specimen by pressing Ctrl+N.

We see that this malware uses IsDebuggerPresent which means that it is somehow looking for a debugger presence. Let look into the reference of this API call.

There is only one reference to the API call, let's follow the code in dissembler now. Right click and follow in dissembler. Below is the code in the dissembler

Now IsDebuggerPresent returns 1 if Debugger is present in the system else 0. Test EAX, EAX is testing this condition. Let's put a breakpoint at 01001296 and run the sample. We see that EAX return 1, now if we continue running it code jumps to 0100146D and then terminates.

So if we can do something with the code present at 010014D, then this specimen will not terminate and continue executing. Should we change the code at 010014D? Probably not a good idea. What if we change the JMP instruction altogether and change it to JZ. Well, that solves our purpose in this case but will work if the specimen is inside a debugger otherwise it will terminate (because outside IsDebuggerPresent will always give 0 and thus JZ will always execute.).

What we can do in this case is to patch the code. Patching the code is when we replace some instruction without affecting the functionality of binary. There is a NOP instruction whose purpose is to perform no operation. Let's substitute JNZ with NOP to avoid jump altogether.

Put NOP at Address 01001298. Make sure that Keep size and fill rest with NOPs is checked. This is because NOP is 1 byte only whereas instruction it is replacing is 6 bytes, so to perfectly fill the memory address these options are useful. Below is the patched code

After this is patched, let's execute the code, and as expected now the malware is fooled that there it is not being debugged in this case and it continues its execution.

So in this article, we have seen what various checks malware are employed to defeat from analysis techniques and a basic example how we can bypass such malware techniques as well. IN the next part we will take a look at other malware checks and their way of bypassing.