![]() In this sample, it is used to intercept functions called by browsers for sending HTTP requests, and thus access payload that may contain sensitive data such as credentials or credit card numbers. ![]() ![]() This method is referenced within the book Practical Malware Analysis (Direct Injection, p.257). Inline hooking is a well-known method used to intercept function calls, and execute a detour function that can access function parameters as the original function would have done. ) it calls a per-browser function used to setup inline hooking for the injected process. According to its value ('chrome.exe', 'iexplorer.exe'. To find out, it accesses the InMemoryOrderModuleList LIST_ENTRY within the PEB, and checks the FullDllName associated with the first entry. Since the malware doesn't pass any variable to the thread function, the remote thread doesn't know in which process it is running. Now, the entire PE is mapped within the targeted process address-space, and a last call to CreateRemoteThread() allows the injected thread to start running. This is performed using WriteProcessMemory(). This memory-area is used to store a copy of the PE file currently running, by using its address base (pushed at the end of the 2nd packing stage) as a source address. Then, a call to VirtualAlloc() allows the malware to allocate an executable memory-area within the targeted process address-space. Once a process' name matches an expected one, a call to OpenProcess() is used to get an handle on the targeted process. The malware tries to inject a thread into any process whose name matches one of the following strings: ![]() The process enumeration is done with the following functions from the Windows API: The main thread of the malware is used to perform an infinite loop which enumerates running process on the target operating system, in order to find a browser on which thread injection could be done. The RC4 key used for encryption is 128-bits long and its address is stored at. With an IDA python script, one can easily find cross-references to this function, identify the string's number as the last pushed argument, and thus perform decryption.Įxecuting this script reveals interesting strings such as DLL or function names: Thus, in order to decrypt a string, the malware uses a function that pushes the number of the encrypted string within the array of structs, from which its address and length can be deduced. The struct contains the following fields: data+0x30, an array of structs with one entry per encrypted string is identified. Most of them are DLLs or functions' names and parameters related to web-browser injection, and used to dynamically resolve imports using LoadLibraryA() and GetProcAddress(). In order to delay reverse-engineering and probably to defeat static analysis detection-based methods, the malware implements the RC4 algorithm to encrypt strings. If the magic value isn't the expected one (0圆66), then the malware stops its execution. Thus, it can be drawn that the first function executed by the malware takes 2 input parameters: Push ebx base address of the unpacked PEĬall eax leads to the unpacked PE original entry point Following few calls to VirtualAlloc(), the end of the second unpacking stage can by identified with the following instructions: push 0圆66 magic value checked after unpacking It also involves a small de-obfuscation routine which performs XOR operations with a one byte key (0x0F), used to output decrypted PE sections, within buffers allocated with VirtualAlloc(). The second one is quite simple as well, it implements a small anti-debug trick which reads the 'BeingDebugged' flag within the PEB. ![]() The first one is based on the well-known packer UPX and can be easily defeated. The sample analyzed is packed with 2 layers. Due to the lack of information about this malware, the propagation method of this threat is unknown. Xylitol, a security researcher, has shared a sample of this malware on Virus Total at the end of 2012, but no public analysis seems to be available on the Internet. However, as we will see throughout this blog-post, it is still effective against latest browsers (running in 32-bit mode). The malware is pretty old, its compilation time-stamp points out that it may have been used during November, 2012. In this article I'll try to present a detailed analysis of this malware, with emphasis on the web-browser injection part.
0 Comments
Leave a Reply. |