Carberp Reverse Engineering

From UIC

Carberp from a Reverse Engineering Perspective

Carberp Reverse Engineering
Author:	Evilcry
Email:	aaa@bbb.it
Website:	-
Date:	03/07/2011 (dd/mm/yyyy)
Level:
Language:	English
Comments:	Comments, if you want

Introduction

We are going to talk about Trojan Banker Carberp from a Reverse Engineering point of view. Carberp is a Botnet delivered in the usual ways of Blackmarket selling, designed to be a Trojan Spy and specifically a Banker similar to SpyEye and ZeuS, able to perform Man in the Browser attacks, steal victim credentials, kill antivirus softwares, remove other bots like SpyEye and Zeus and much more...

Tools & Files

• IDA
• OllyDbg
• CFF

Essay

Carberp is a Botnet delivered in the usual ways of Blackmarket selling, designed to be a Trojan Spy and specifically a Banker similar to SpyEye and ZeuS, able to:

• Perform Man In The Browser
• Steal Victim Machine Credentials
• Kill AntiVirus Software
• Remove Competitors Bots (SpyEye and ZeuS and others)
• Plugin System
• Screenshot Ability
• Form Grabber
• Backconnect

Works from XP to 7 even with limited accounts, and performs injections on IE, Firefox, Opera and Chrome.

Like the most famous Trojan Bankers, Carberp has a Plugin and Config structure, that during infection process are downloaded and decrypted by the bot, here a quick list of the most known plugins:

• cfg/miniav.psd
• cfg/stopav.psd
• cfg/passw.psd

We have also a Configuration File that contains URL Triggers and Malicious JavaScript code to Inject.

The C&C server could present also the following additional files:

• random_name.7z
• /get/key.html
• random_name.php3
• w.php3
• random_name.doc

Sample Generic Overview

The sample we are going to deal presents the following base characteristics

• FileSize: 130.00 KB (133120 bytes)
• MD5: C2D749950BFD092E5E3AD96EB64D4990
• SHA1: 0C51FEC8397088F3E8AA7B9FDBF4DFB0EEF3D7BB

• Company Name: Lriptddh Bhybugb
• Product Version: 98.78.16.10

The binary presents a layer of UPX compression.

Section Header is composed as usual by the following sections:

• .UPX0
• .UPX1
• .rsrc

Code Entry Point is located at 000358E0 inside UPX1 section, ImportTable and Resources Directory are both placed into rsrc.

Preliminary Analysis

As you have seen from the previous paragraph the binary is packed with UPX, so the first obvious operation should be the usual unpacking.

But let's see what happens to the unpacked code, here is the Original Entry Point:

As you can see, the start code is quite atypical, we have a conditional check, in our case jump is taken, this lead us to the following piece of code

Aim is clear, eax drives the call flow, in this way we have a sort of Unpacking Awareness. Let's considerate the alternative branch solution, in other words we assume a NON zero value for EAX. Test can be quickly done by using IDA x86 Emulator plugin.

EAX has a dummy value, now we can see that application correctly flows into a second layer of decryption. Following the way of manually changing register value is not secure, because entire stack and register values could affect the correct code flow o successive decryption stages. This implies that would be a good practice to follow code of the UPX packed sample.

The picture above shows UPX packed structure of the executable, it's also pretty trivial to identify in the last block the jmp to the OEP, alias the previously seen code.

In this way, we are now able to continue the code flow analysis without the risk of incongruences. Here also a view of the second layer call flow.

We will keep an eye on the evolution of the code flow during the various decryption layers.

We meet here a very long sequence of 0 opcodes and repeated pieces of code as you can see above.

Code can be seen from two points of view now:

   * Direct Analysis
   * Higher Abstraction Level

Second point implies some assumption to be done, this allow us to see the code from an higher perspective. Assuming that there are no pieces of SMC code, to break the flow we could have:

   * Jumps
   * RETs

Further observation will confirm the presence of a final jump, code is structure as follow:

• Zero_Opcode_Padding
• Real_Code
• Zero_Opcode_Padding
• Jmp to the Next Block

What we gain from this pattern? should be easy to understand, how to speed up debugging process by looking directly for jmp instruction. For some people this could be an obvious observation, here I wanted to show the process that lead us to such conclusions.

After traversing all these chained blocks we land to the following piece of code:

Due to the change of code structure we can identify here a Third Layer of Decryption. Respect to the previous block we have an additional element, that affects code flow, is the CALL. The code that follows is composed by several nested calls.

After that bundle of calls, we can see some api call performed in the following way:

Function GetModuleFileNameW is called indirectly. In the same way is called a VirtualAlloc that will host another decryption layer, with a new kind of obfuscation.

The structure is pretty clear:

• Real_Code
• Jmp
• Real_Code
• Jmp

Following a block of code like this could be a bit messy, especially on jmp based loops, in that case just locate:

• Conditional_Jump
• Jmp

and place a breakpoint on Jmp.

This was the last spaghetti code layer, finally we land to the unpacked and active infection layer.

Core Infection

This can be considered the True EntryPoint, in other words here starts the Infection Process.

Let's see the call flow graph of the core infection executable:

As you can see from the above graph, structure of the malicious code can be divided in 4 regions, each one identified by a different color rectangle.

The most interesting thing that we can observe is that after the first region, we have a bifurcation of the code path, and finally a common ending region. The double path as you can see, does not have intersection points except Start and End regions. This means the code flow could take two different ways of execution. Without going too deep in explanation, we should formulate two basic questions in order to achieve a complete functional and technical understanding.

   * What's the condition that determine the path ?
   * What are the differences between the two path ?

We can immediately identify who determines the path, simply by looking better at the final zone of the start region:

call sub_406240 affects the EAX value, that will influence the code flow.

The second question to be answered, obviously, implies that we need to debug both branches.

The main routine does not uses directly Function Addresses, we will meet always the following construct:

We have an hash, given by the third parameter that identifies unequivocally the function that need to be called, call 00409730 returns the address of the specified function and successively is called. In this case we have a GetModuleFileNameW.

The core point of Carberp functionalities can be summarized in one call.

First call, contains entire code injection routine that will target explorer.exe

  # explorer.exe path is resolved
  # CreateProcess of explorer, with creation flag CREATE_SUSPENDED
  # Create a Map View of the File
  # Map View of the Section
  # NtQueueApcThread
  # NtResumeThread

At this point code injection is completed and dropper ends its function.

Catching the Injection

As previously seen, to continue infection Carberp performs an Injection by creating a suspended explorer.exe process and mapping successively a view. We obviously need to keep track of the injected code, but we are in front of a Child Process created by main carberp executable which resides in suspended state.

The situation we have pose two problems:

   * The Process does not Appear in the Process List
   * Problems in Attaching a Debugger.

Here the plan, we reach NtResumeThread, so we are sure that all is ready for execution, patch the malicious injected code with a classical 0xEBFE which means an endless jump over itself, and finally let the process run. The process will be now running, and available into the process list like every other process, both problems posed above are now solved.

But, how we can know the address where to inject our 'EBFE' ? As you have previously seen the third parameter of ZwMapViewOfSection is BaseAddress, a pointer to a variable that receives the base address of the view.

Keeping an eye over this variable, at NtResumeThread we have the correct value where to place the patch. We can use Olly Advanced plugin ( Process Patcher ) to apply our modifications, here a screenshot:

Now process is ready to be resumed and debugged, so we can execute NtResumeThread. This is the situation seen from Process Explorer:

The second explorer as you can see produces an high consumption of CPU, this is caused by the endless loop we placed on the top of the code. We can now attach a debugger to the process, we land here:

Now we can restore the original bytes -> 0x558B but before committing the patch we have to place a breakpoint in the location immediately after the Prelude, or the code will run automatically immediately after changing the bytes.

The freshly injected code, drops a copy of the main dropper (the packed one) into automatic execution directory under the name of igfxtray.exe. Code performs also api hooking (presented in the next paragraph) and completes injection by downloading and decrypting configuration and plugins.

Revealing Hooks via Windbg

We can use WinDbg to discover hooks installed by Carberp in a very easy way. As you have seen, the trojan injects code into Explorer.exe process, this implies that in explorer.exe address space we will have traces of infection, a Full Dump can be taken via Process Explorer.

At this point we can enumerate all module and look for differences between functions in the dump and relative symbol in the following way:

> !for_each_module !chkimg @#ModuleName -d

Here what we have

DBGHELP: C:\WinDDK\7600.16385.1\Debuggers\sym\wininet.dll\41252C1Ba7000\wininet.dll - OK

   77194ac5-77194ac9  5 bytes - wininet!HttpOpenRequestA

[ 8b ff 55 8b ec:e9 06 69 f7 89 ]

   771961dc-771961e0  5 bytes - wininet!InternetCloseHandle (+0x1717)

[ 8b ff 55 8b ec:e9 5f 51 f7 89 ]

   771976b8-771976bc  5 bytes - wininet!HttpSendRequestA (+0x14dc)

[ 8b ff 55 8b ec:e9 03 3b f7 89 ]

   77199555-77199559  5 bytes - wininet!InternetReadFile (+0x1e9d)

[ 8b ff 55 8b ec:e9 26 1d f7 89 ]

   771a325f-771a3263  5 bytes - wininet!InternetQueryDataAvailable (+0x9d0a)

[ 8b ff 55 8b ec:e9 ac 80 f6 89 ]

   771a53eb-771a53ef  5 bytes - wininet!HttpSendRequestExW (+0x218c)

[ 8b ff 55 8b ec:e9 60 5e f6 89 ]

   771a6345-771a6349  5 bytes - wininet!HttpOpenRequestW (+0xf5a)

[ 8b ff 55 8b ec:e9 c6 50 f6 89 ]

   771c7e9a-771c7e9e  5 bytes - wininet!InternetReadFileExA (+0x21b55)

[ 8b ff 55 8b ec:e9 11 34 f4 89 ]

   771c88d6-771c88dd  8 bytes - wininet!InternetWriteFileExW (+0xa3c)

[ 6a 78 ff 15 34 14 18 77:e9 05 2a f4 89 90 90 90 ]

   771e1808-771e180c  5 bytes - wininet!HttpSendRequestW (+0x18f32)

[ 8b ff 55 8b ec:e9 e3 99 f2 89 ]

   771e190d-771e1911  5 bytes - wininet!HttpSendRequestExA (+0x105)

[ 8b ff 55 8b ec:e9 0e 99 f2 89 ] 58 errors : wininet (77194ac5-771e1911)

Meaning should be clear, wininet modules presents some 'errors', more specifically some differences between functions in memory and the ones used as symbols.

Let's inspect the code of HttpOpenRequestA

0:000> u 77194ac5

As you can see, first instruction is a jump to a suspicious location, this piece of code clearly demonstrates the presence of an hook. We can know more about this location

0:000> !address 0110b3d0

In this way we know where Starts and Ends the piece of code responsible of handling hooks. These are two precious informations, especially the first one, because we have a range where to look for memory mapped executables.

0:000> s -a 01100000 l0112d000/4 "MZ"

The presence of "MZ" obviously is Necessary but NOT Sufficient condition to say that this is an executable, we need more proofs. These can be obtained by checking the validity of executable presumably located at 01100000.

0:000> !dh -a 01100000

This is an Executable. Now let's suppose that we want to carve it from memory, how to do ?

0:000> .writemem carved_from_explorer 01100000 0112d000 Writing 2d001 bytes....

The injected executable contains Hook Handlers and Routines to Deal with Captured data.

Carberp Analysis via Volatility

Identification of the System

We are dealing with a Windows XP on x86 Platform with Service Pack 2.

Process Enumeration

These informations are enough to make some speculation and obtain an investigation direction.

As you can see we have various svchost.exe processes, the first 4 have a Parent PID (652) that belongs to services.exe PID (652) with a time of 14:14:40/41/42.

Successively you can see other 3 svchost.exe processes, but this time Parent PID is different (1480) that belongs to explorer.exe (PID= 1480), additionally these processes have the same Timing 15:17:32.

This basically means that there are some implications connected to explorer.exe that needs further investigations.

Due to the fact that our suspects are on svchost.exe, actively involved into network activity of a system, let's scan physical memory for _TCPT_OBJECT objects (tcp connections) via

As you can see activity pertains mainly to Firefox (PID: 1332); we have also PID 984 and 1212 (suspect svchost) that aren't of great help and finally

0x06a1ac10 10.0.2.15:1059 195.184.86.34:80 1132

Where we have an interesting IP that belongs to a suspect svchost.

Looking for 195.184.86.34 lead us to an interesting result:

the IP is malicious, belongs to Carberp ( 08C01BBE430F9FEA1A532DFD13F2836A )

Proven that svchost is malicious, due to its strict relationship with explorer.exe we are allowed to think that Carberp performed code injection.

Here comes a great and really handy plugin for Volatility called malfind.

malfind automatically locates and extract suspicious memory regions ( injected code ); dumped content is placed into /vol_dump, you must create an output directory for malfind.

Besides all the entries printed out during scan process let's check the first entry saved into /vol_dump, explorer.exe.7585ca8.00e20000-00e5afff.dmp

Start Address is 0x00e20000, here its content

Let's take a list of the strings that appears into the executable

These strings clearly indicates that malfind correctly catched the malicious executable injected.

It's important to say that in this phase of analysis VAD (Virtual Address Descriptor) could give pretty interesting hints. We have four plugins that deals with VAD vadwalk, vadinfo, vadtree, vaddump. Let's see usage of vadinfo

The VAD entry I've chosen to show belongs to the memory range in which stands the executable previously carved, as you can see informations indicates a Protection of 6 belongs PAGE_EXECUTE_READWRITE.

As we know, Carberp is a Banking trojan which performs Web Code Injections, this means that we should find traces of its presence into the Browser Process.

As you can see first 5 entries are classical inline hooks on the most common APIs used to intercept and modify user's browsing activity. Successively we have some 'syscall' hooking type, further investigations can be done by using another Volatility plugin, called volshell plugin.

Where 0x7FFE0300 is a pointer to KiFastSystemCall

Further informations here http://www.honeynet.org/node/578

Now we can check for Registry and FileSystem presence of Carberp in the victim system.

Usually malicious applications uses registry to ensure survival (malware execution) on system restart.

This can be done via printkey plugin in the following way.

We have only ctfmon.exe as entry, nothing interesting, we can now look directly into the filesystem for some suspicious entry. This can be accomplished by using filescan plugin that enumerates _FILE_OBJECT pool allocations.

igfxtray.exe it's exactly the name that Carberp uses to copy itself into automatic execution directory.

Conclusion

According to the title, the main scope of this blog post, is not a complete functional analysis (that will be covered in another one) but a simple view of the 'problem carberp' under a reverse engineering point of view.

Final Notes

Final Notes

Evilcry

Disclaimer