Malware 2 - From Infection to Persistence

The initial analysis of this sample identified that the subsequent download was in fact a dangerous data theft Trojan known as Carberp. This Trojan is primarily associated with financial and data theft and has been compared to the more prevalent Zeus and SpyEye families. This is due to the similar data exfiltration capabilities of the Carberp family.

Carberp exhibits similar functionality to that of Zeus and may be controlled from a central administrator control panel that provides statistics related to infections and allows the owner to control various hosts and mine the data that has been stolen. Carberp includes functionality for data theft and credential harvesting from an infected system and can also target user credentials for specific websites. Carberp is considered to be an information theft Trojan, but it also forms part of a botnet that offers full control over infected hosts. Although Carberp was originally designed for attacks motivated by financial gain; its complicated infection mechanisms and extensive functionality make it a prime candidate for more targeted attacks.

The analysis in this blog post looks at the "infection to persistence" process of Carberp.

Encryption, compression and obfuscation

As with all investigations into executables, the initial analysis begins with determining if the executable is packed or protected in some manner. Initial inspection of this particular sample suggests that the executable is packed with UPX. Portable Executable (PE) files typically have code, data and resource sections labelled ‘text’, ‘data’ and ‘rsrc’ but in the case of UPX-packed files the code and data sections are renamed to UPX0 and UPX1.

Figure 1: UPX Section Headers

This is unusual for Carberp as it has been packed with ASPack 2.1 in previous samples that have been observed. At this stage, the packer can be interpreted as being the initial layer of obfuscation, but the UPX layers are generally trivial to remove from applications as the packer contains the decompression functionality. This can be achieved using the UPX application with the "–d" option or alternatively, the file may be manually unpacked by finding PUSHAD, JMP EAX instructions. The location of EAX is the Original Entry Point (OEP) of the unpacked executable.

It is worth noting that some malware will fake the UPX headers to fool analysts into believing that it is in fact packed with UPX, or use modified or ‘hacked’ versions of UPX. In such cases, the automated approach to unpacking will often fail.

The Carberp sample under analysis has anti-debug code to attempt to “detect” when it has been unpacked using UPX or similar method to dump the executable. At the very start of execution, the malware contains a check to allow it to determine if it has already been unpacked (suggesting analysis). The UPX unpacking process always leads to a JMP

Figure 2: UPX Jump to OEP

In this case, execution arrives at the following instructions:

OR EAX, EAX 
JE 00418615

This code will check for the value in EAX to determine if it is zero. If so, then the code will jump to the ExitProcess call. This effectively checks if the executable has been unpacked to disk before execution, as Windows sets EAX to zero when creating a new process, whereas UPX will leave a non-zero value here when it reaches the OEP.

After the initial UPX packing layer has been bypassed, we find a large number of junk instructions that modify registers and bytes in memory which form another layer of obfuscation. These areas of opcodes are interspersed with jumps in the form of JMP

Figure 3: Nested Calls

After a large number of calls, the code begins to return from the calls using multiple call returns (RETN) chained together to navigate back up from the call tree. Eventually it returns to the top level before proceeding to a new area of code which is used to make a small set of API calls such as GetModuleHandle, RtlValidateHeap and VirtualAlloc. These are seen below in Figure 4.

Figure 4: API Calls

Calls to VirtualAlloc are used to allocate memory from the heap which the malware uses to write additional code to. In this case, Windows allocated memory at address 0x3B0000 but this address may be different depending on analysis environment or Windows version. The Trojan then creates code in this region which acts as the last layer of decryption that is encountered before the malware begins to execute its malicious infection code.

Figure 5: Memory Region before Write

Figure 6: Memory Region after Write

A new thread is created which begins executing the code in this newly allocated memory region. This code consists of decryption loops which proceed to decrypt the Trojan’s main malicious functionality into memory to be executed. The screenshots demonstrate the multi-staged approach to the decryption. The standard PE header string is visibly being decrypted which leads to a full executable contained in one of the memory regions. This can be considered to be the last stage of deobfuscation.

Figure 7: Executable Decryption Stage One

Figure 8: Executable Decryption Stage Two

The code is now decrypted fully to a separate memory region and forms a complete executable image where numerous strings and filenames are visible. It was possible to observe strings that hint at the modular plugin functionality offered by Carberp and some strings are seen such as "/cfg/stopav" and "/cfg/miniav". Similar capabilities have been observed in malware such as Tatanga and SpyEye that take a modular approach to extended functionality.

The region also contains a large number of strings and various references to DLLs. This content provides evidence of the additional botnet/remote control functionality that Carberp is known to possess:

• update
• updateconfig
• download
• loaddll
• grabber
• alert
• GET /stat?uptime=%d&downlink=%d&uplink=%d&id=%s&statpass=%s&comment=%s

The newly decrypted executable code is used to overwrite the original code section marked UPX0 at 401000 in memory. The original code is first overwritten with zeroes and then subsequently overwritten with the new code. The updated disassembly can clearly be seen in the debugger. The screenshots in Figure 9 &10 below illustrate the final stage malware code and strings related to Carberp’s functionality.

Figure 9: Infection Code after Deobfuscation

Figure 10: Carberp Deobfuscated

Analysis of main executable content

After the previous layers of protection are stripped away the code ends up decrypted and looking similar to a typical (non-packed) executable. The malware's main functionality begins by resolving imports and extracting information about the OS. Malicious functionality of Carberp has now been entered and infection of the system begins; dropping files injecting into other processes. At this point, Carberp uses function calls such as GetSystemDirectory and GetTempPath to enable it to drop files on the host. The files are created as ".tmp" files and will reside in the user’s TEMP folder. The files that are created consist of copies of system files such as NTDLL.dll and kernel32.dll among others.

Figure 11: Carberp Locating System Directory

Carberp enumerates the currently running processes on the system and writes the process names into newly created memory regions and stores currently running process names in each one. These will be used for process injection later in the infection process.

A separate decryption function is now encountered that starts to deploy the locally stored plugins contained within Carberp. The first file to be decrypted is a DLL called r00f_dll.dll that that contains a single exported function called "LetsDance", which maps some kernel files (win32k.sys, ntkrnlpa.exe etc.) into memory and then writes them to files named TMA.TMP and TMB.tmp within the user’s TEMP folder.

The DLL appears to demonstrate functionality for kernel level operations and rootkit kernel hooks. In particular, there is a function that is used for manipulating control registers. These control registers can be used to remove write protection from System Services Descriptor Table (SSDT) protection by setting the write bits to 0 (more information can be found in the Intel architecture manuals). Malware will commonly implement this code to create or manipulate SSDT hooks that can bypass various anti-virus applications or used to hide files.

The instructions below will save the original value of the write bits into [EBP-8] and then set the value to 0, so that the SSDT table may be manipulated.

MOV EAX, CR0 
MOV DWORD PTR SS:[EBP-8], EAX 
AND EAX, FFFEFFFF 
MOV CR0, EAX

After the operations, the protection is restored using the code located at the end of the routine.

MOV EAX, DWORD PTR SS:[EBP-8] 
MOV CR0, EAX

Further analysis of the kernel level code would require the use of WinDbg or a similar kernel debugger; but deeper analysis is outside the scope of this blog posting. As a subject, the area of root kits and kernel-mode techniques are worth an entire blog post on its own and as such I will return to these techniques.

At this point, the infection begins the process injection stage. A number of techniques may be used to continue the investigation of the infection process. This methodology is covered in the next section.

Process injection

After resolving imports and creating additional files the sample begins the process injection part of the infection process. The method used is different to the normal injection techniques that I have observed in the analysis of past samples. The common approach is to use the following calls:

• OpenProcess – Get handle to process
• VirtualAllocEx – Allocate memory in remote process for writing DLL name
• WriteProcessMemory – Write the DLL name and path into remote process
• CreateRemoteThread & LoadLibrary – Call thread in remote process to invoke DLL loading

Carberp takes a different approach that can hinder the analysis of the next stage of infection. This approach can also yield the additional benefit of avoiding detection from heuristic based antivirus software because native API calls (ntdll.dll) are less likely to be hooked by the antivirus. Carberp uses the following approach:

• CreateProcess – Create explorer process that is suspended
• MapViewOfFile – Map a view of the file
• NtQueueApcThread – Queue Asynchronous Procedure Call (APC) remote function
• NtResumeThread – Resume victim process and execute injected code

Figure 12: CreateProcess Step of Injection Process

The function of the injected DLL is to create a new host process to execute further malicious functionality. As can be seen in the above image, the CreateProcess function is used to create a new process instance of explorer.exe, with the CREATE_SUSPENDED flag. In order to trace the new process in a debugger, it is first necessary to patch the process so that it will enter an infinite loop, allowing a debugger to be attached before any further code is executed. This is achieved by overwriting the first instruction with a ‘JMP $-2’ instruction, which will jump to itself repeatedly. This instruction corresponds to the machine code bytes ‘EBFE’ which are patched at the entry point of the target process image. When execution of the process begins, a debugger can be attached, at which stage the entry point is patched back to the original instruction and execution of the process can proceed under control of the debugger.

Figure 13: Suspended Explorer Process

However, debugging an instance of an ‘explorer.exe’ process can prove difficult as it affects the ability to manipulate the desktop and can cause crashes when breakpoints are hit (this prevents opening of files, folders, etc). Instead, the analysis process can be made simpler by altering the intended target of the CreateProcess call to another executable such as "notepad.exe". Using this approach and taking the function address that is pointed to by the argument lpApcRoutine in the NtQueueApcThread call, the entry point of the injected code can be patched with the infinite loop jump instruction, a debugger attached to the process and the injected code patched back to its original instructions and execution allowed to continue. From this point, dynamic analysis can resume from the function in the new process.

As execution continues, Carberp firstly generates a new explorer process and injects a copy of its own code into it. From here, it then injects into the original Explorer process using the function CreateRemoteThread to execute the malware code in the context of the main Explorer process.

Carberp then starts to drop files on the system by acquiring the location of the system startup folder. Using this location it creates a file called igfxtray.exe that is a copy of the code being injected into various processes on the hosts. The file attributes from smss.exe in the Windows folder are copied to this executable to mask the new attributes for this file. This file will serve as the persistence mechanism for Carberp on the host, as it will execute across system restarts. Usually, malware will create persistence registry keys, but this is another method which can be used. During analysis, the malware does not create any registry keys on the infected host for this particular sample.

Now that Carberp has been installed on the host, it now proceeds to install the system-wide hooks and launches the command & control communication aspects of its code. The initial stage of this process is concerned with the setup of the data theft code hooks and usermode rootkit capabilities of this Trojan.

User mode root kit & data theft hooking

As part of its defensive functionality, Carberp also possesses user mode root kit functionality to allow it to remain hidden on the system. User mode root kits implement code hooks in user/application space on the operating system by modifying code in memory. During the infection process, Carberp installs a number of these usermode hooks that consist of changes to system API functions used by other applications or the operating system. Carberp overwrites specific functions responsible for listing files in directories. The function prologue for NtQueryDirectoryFile is overwritten with a call directed into its own code. In normal code, the pointer to KiFastSystemCall (7FFE0300 on analysis system) is placed into EDX.

Carberp replaces the code with a call to its own function that is responsible for parsing the filenames found. It compares a hash of the filename with a stored hash of the filename "igfxtray.exe". If the file is located in the directory and the hashes match, the function will prevent the name from being returned and as a result, the file is not visible to the user. When the function is called (such as when explorer is viewing directories), the malicious routine is run and its files are hidden from view.

Figure 14: NtQueryDirectoryFile Rootkit Hooks

With these code changes made by Carberp, it then spawns several instances of svchost.exe using the CreateProcess API call. Again, the code is injected into all instances of svchost and the analysis continues by following the execution flow through to the svchost executables. Carberp now attempts to install code hooks for information stealing across processes.

Data theft hooks

Initially, the code hooks are set on various functions for Wininet.dll by overwriting the function prologues with a jump to the Carberp code responsible for extracting data and HTTP communications. In the image below, the hooks can be seen after an infection has taken place. The function prologues are this time replaced with simple jump instructions that lead to a function within the Carberp binary. An example of the Windows Wininet hooks, responsible for intercepting HTTP information, are shown below in Figure 15.

Figure 15: Data Stealing Hooks

Now that Carberp has successfully embedded its executable and malicious hooks, the malware begins the next stage of its lifecycle, by performing the initial communications to the remote C&C server containing the control panel. The malware attempts to download the additional functionality required for the next stage of infection and the network communications are used to obtain these DLLs. The next posting in this blog series will take a look at the communications and remote control features of the Carberg Trojan.

Conclusion

This series of blog postings has sought to provide an overview of the various stages involved in malware infections. The initial posting observed the exploitation phase of a targeted infection; a stage normally associated with malicious files (PDFs, Excel documents, etc) and drive-by downloads delivered via email or malicious links. It also provided an overview of the analysis of malware-laden PDF files.

Part two of this series of blog postings dealt primarily with the process of infection in an advanced piece of malware as a result of the initial exploitation. In this instance, the PDF delivered a data theft Trojan with sophisticated infection capabilities that make analysis of such samples by researchers difficult. Also observed were multiple layers of obfuscation and encryption, which eventually led to files being dropped and userland code hooks being installed, that provide the malware authors with a stealthy backdoor to the host.

The functionality observed in these early stages of infection provides an overview of the advanced nature of the latest malware attacks currently facing Context Information Security’s clients and standard Internet users. The underlying Trojan features that are available to malware authors and botnet owners for threats such as Carberp are even more worrying and will be covered in the next blog post.

References