November 29, 2011 at 15:37AV vs FakeAV
Hi, Habr. In touch Vyacheslav Zakorzhevsky, senior viral analyst of LC. While editors write regular announcements and other poetry, there is an opportunity to surprise you with a little technical material.
Everyone, probably, knows that there are many different chips with which help the little ones protect their offspring. Usually they try to determine if the application is running under a virtual machine, bypass heuristic or proactive protection, etc. We decided to write a small example of how in modern FakeAV (received just a couple of days ago) virus writers try to bypass AV products, sandboxes, etc. In the file I examined, I found a call to the exported function with a curious name: Screenshot of the malware from Hiew
The name of the function "antiemu33" speaks for itself - ANTiEMUlation - anti-emulation. The screenshot shows that the result of the function is checked. If it is not equal to "0", then the malware continues to work further. And if the result is “0”, control is transferred to the code that completes the process. Take a look inside the function using the IDA.
Screen of antiemu33 function from IDA
In this procedure, a rather rare API function “ldap_count_references” from the library “WLDAP32.dll” is called. And then there are two possible scenarios:
1) Nothing will happen, the function will return control, and antiemu33 will return “0”;
2) An exception is thrown, an exception handler is called at the address 0x401025, which will return the desired "1". IDA exception throwing
The exception handler was set using C ++ try / catch, the IDA was even able to statically determine this by displaying the entire structure on the screen. Thus, the calculation of the attackers consists in the fact that some emulator or heuristic analyzer will incorrectly handle the call of this API function or exception handling, which will lead to the return of "0" and the subsequent completion of the file.
And another example of anti-emulation on another, but very fresh FakeAV. Below I have attached a screenshot from Hiew, the cursor points directly to the entry point. Screenshot of FakeAV from the entry point
In order - the EnumResourceTypesA function is called, and then it is checked whether the returned value is zero or not. If the function returns zero, then the program will go into an infinite loop, which, obviously, should not happen on a normal system. Thus, this is the first anti-emulation, quite simple, but quite possibly capable of circumventing something. Next, the GetLastError function is called, and the return value is shifted to the right by 7 bits and added to the address 0x1003C9. Then, using call, a transition is performed according to the received value. On a normal machine, in eax after GetLastError, it should be 0x714, after the shift - 0xE, after addition - 0x1003D7. Thus, in a living system, the transition will be performed to this address. And if the heuristic analyzer or emulator could not adequately handle the GetLastError call,
Screenshot of the same FakeAV from IDA
But this does not end there - if you look at the code, you can see that the EnumSystemLocalesA function is called further, after which the transition to ExitProcess is performed! And the whole trick is that the first parameter is passed to this function to point to CALLBACK (LOCALE_ENUMPROC), which is called by the system. It is in this CALLBACK that the entire “payload” of the malware is located. Here again, malware developers rely on the imperfection of antiviruses that process API functions.
Everyone, probably, knows that there are many different chips with which help the little ones protect their offspring. Usually they try to determine if the application is running under a virtual machine, bypass heuristic or proactive protection, etc. We decided to write a small example of how in modern FakeAV (received just a couple of days ago) virus writers try to bypass AV products, sandboxes, etc. In the file I examined, I found a call to the exported function with a curious name: Screenshot of the malware from Hiew
The name of the function "antiemu33" speaks for itself - ANTiEMUlation - anti-emulation. The screenshot shows that the result of the function is checked. If it is not equal to "0", then the malware continues to work further. And if the result is “0”, control is transferred to the code that completes the process. Take a look inside the function using the IDA.
Screen of antiemu33 function from IDA
In this procedure, a rather rare API function “ldap_count_references” from the library “WLDAP32.dll” is called. And then there are two possible scenarios:
1) Nothing will happen, the function will return control, and antiemu33 will return “0”;
2) An exception is thrown, an exception handler is called at the address 0x401025, which will return the desired "1". IDA exception throwing
The exception handler was set using C ++ try / catch, the IDA was even able to statically determine this by displaying the entire structure on the screen. Thus, the calculation of the attackers consists in the fact that some emulator or heuristic analyzer will incorrectly handle the call of this API function or exception handling, which will lead to the return of "0" and the subsequent completion of the file.
And another example of anti-emulation on another, but very fresh FakeAV. Below I have attached a screenshot from Hiew, the cursor points directly to the entry point. Screenshot of FakeAV from the entry point
In order - the EnumResourceTypesA function is called, and then it is checked whether the returned value is zero or not. If the function returns zero, then the program will go into an infinite loop, which, obviously, should not happen on a normal system. Thus, this is the first anti-emulation, quite simple, but quite possibly capable of circumventing something. Next, the GetLastError function is called, and the return value is shifted to the right by 7 bits and added to the address 0x1003C9. Then, using call, a transition is performed according to the received value. On a normal machine, in eax after GetLastError, it should be 0x714, after the shift - 0xE, after addition - 0x1003D7. Thus, in a living system, the transition will be performed to this address. And if the heuristic analyzer or emulator could not adequately handle the GetLastError call,
Screenshot of the same FakeAV from IDA
But this does not end there - if you look at the code, you can see that the EnumSystemLocalesA function is called further, after which the transition to ExitProcess is performed! And the whole trick is that the first parameter is passed to this function to point to CALLBACK (LOCALE_ENUMPROC), which is called by the system. It is in this CALLBACK that the entire “payload” of the malware is located. Here again, malware developers rely on the imperfection of antiviruses that process API functions.