AV vs FakeAV
Hi, Habr. In touch Vyacheslav Zakorzhevsky, senior virus analyst LC. While the editors are writing regular announcements and other poetry, it is possible to surprise you with a little bit of technical material.
Everyone probably knows that there are a lot of different chips with which Malvarkschiki protect their offspring. Usually they try to determine if the application is working under a virtual machine, circumvent a heuristic or proactive defense, etc. We decided to write a small example of how virus writers try to circumvent AV products, sandboxes, etc. in modern FakeAV (received just a couple of days ago). In the investigated file, I found a call to the exported function with a curious name:
Screenshot of malware from Hiew
The name of the function “antiemu33” speaks for itself - ANTiEMUlation - anti-emulation. On the screen you can see 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 performs the completion of the process. Let's look inside the function using IDA.
Screen feature antiemu33 from IDA
')
In this procedure, a rather rare API function “ldap_count_references” from the “WLDAP32.dll” library is called. And then there are two possible scenarios:
1) Nothing happens, the function returns control, and antiemu33 returns "0";
2) An exception will be thrown, an exception handler will be called at the address 0x401025, which will return the desired "1".
Generating an exception in IDA
The exception handler was installed using C ++ try / catch, IDA was even able to statically determine this, displaying the structure on the screen entirely. Thus, the calculation of the attackers is that some emulator or heuristic analyzer will incorrectly handle the call of this API function or the exception handling, which will result in the return of “0” and the subsequent completion of the file.
And one more example of anti-emulation on an already different, but completely fresh FakeAV. Below I have attached a screenshot from Hiew, the cursor points directly to the entry point.
Screenshot FakeAV from entry point
One by one, the function EnumResourceTypesA is called and then it is checked whether the return value is zero or not. If the function returns zero, the program will go into an infinite loop, which obviously should not happen on a normal system. Thus, this is the first anti-emulation, simple enough, but quite possible, able to bypass 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, the transition is performed according to the obtained value. On a normal machine in eax, after GetLastError, 0x714 should lie, after the shift, 0xE, after addition, 0x1003D7. Thus, in a live system, it will be a transition to this address. And if the heuristic analyzer or emulator could not adequately process the call to GetLastError, the application will terminate or fall.
Screenshot of the same FakeAV from IDA
But that’s not the end of the story - if you look at the code, you can see that the function EnumSystemLocalesA is then called, after which it is executed ... the transition to ExitProcess! And the whole point is that in this function the first parameter is passed to indicate 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 specialists rely on the imperfection of antiviruses processing API functions.
Everyone probably knows that there are a lot of different chips with which Malvarkschiki protect their offspring. Usually they try to determine if the application is working under a virtual machine, circumvent a heuristic or proactive defense, etc. We decided to write a small example of how virus writers try to circumvent AV products, sandboxes, etc. in modern FakeAV (received just a couple of days ago). In the investigated file, I found a call to the exported function with a curious name:
Screenshot of malware from Hiew
The name of the function “antiemu33” speaks for itself - ANTiEMUlation - anti-emulation. On the screen you can see 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 performs the completion of the process. Let's look inside the function using IDA.
Screen feature antiemu33 from IDA
')
In this procedure, a rather rare API function “ldap_count_references” from the “WLDAP32.dll” library is called. And then there are two possible scenarios:
1) Nothing happens, the function returns control, and antiemu33 returns "0";
2) An exception will be thrown, an exception handler will be called at the address 0x401025, which will return the desired "1".
Generating an exception in IDA
The exception handler was installed using C ++ try / catch, IDA was even able to statically determine this, displaying the structure on the screen entirely. Thus, the calculation of the attackers is that some emulator or heuristic analyzer will incorrectly handle the call of this API function or the exception handling, which will result in the return of “0” and the subsequent completion of the file.
And one more example of anti-emulation on an already different, but completely fresh FakeAV. Below I have attached a screenshot from Hiew, the cursor points directly to the entry point.
Screenshot FakeAV from entry point
One by one, the function EnumResourceTypesA is called and then it is checked whether the return value is zero or not. If the function returns zero, the program will go into an infinite loop, which obviously should not happen on a normal system. Thus, this is the first anti-emulation, simple enough, but quite possible, able to bypass 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, the transition is performed according to the obtained value. On a normal machine in eax, after GetLastError, 0x714 should lie, after the shift, 0xE, after addition, 0x1003D7. Thus, in a live system, it will be a transition to this address. And if the heuristic analyzer or emulator could not adequately process the call to GetLastError, the application will terminate or fall.
Screenshot of the same FakeAV from IDA
But that’s not the end of the story - if you look at the code, you can see that the function EnumSystemLocalesA is then called, after which it is executed ... the transition to ExitProcess! And the whole point is that in this function the first parameter is passed to indicate 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 specialists rely on the imperfection of antiviruses processing API functions.
Source: https://habr.com/ru/post/133621/
All Articles