Carberp - Tricks and Traps - A technical overview

Written by Alex Shipp Thursday, 18 November 2010 11:16

In our recent TrustDefender Labs report, we looked at the Carberp Trojan in great detail from a forensics point of view.

However during analysis, we realized that the Carberp Trojan employs many tricks and traps to make life hard for anti-malware researchers.

We are always up for a challenge and one of our goals was to fully reverse-engineer Carberp to get a full understanding of its inner workings (including the decryption of the downloaded plugins and configuration file.)

Along the way, we encountered many nasty tricks. This document looks at some of them; we’re sure there are probably lots more.

Assumptions about the Readers

It is assumed that readers of this document will have a passing knowledge of the Intel Pentium chip machine codes. If not, a good reference document to help with this is available on the Intel site[1].

First Impressions

The sample analysed had an MD5 of 9209bcea94e4dc160587e64600a1297b. This sample causes other files to be downloaded and installed. The files are encrypted at the point of download, and one of the goals of TrustDefender labs was to break this encryption, thus gaining further knowledge of the inner workings of the malware.

As a first step, the encrypted files were looked at using a hex editor. Several patterns could be distinguished by eye. This suggested some form of weak encryption was used, probably XOR based. A few attempts were made to crack the encryption by hand; however, even though the encryption was ‘weak’ it proved resistant to these brute force attempts.

Figure 1:Hex dump of Carberp encrypted file. Patterns such as the 7's in column one, and the D's in column F indicate some form of weak encryption.

The next strategy was to analyse the program code and attempt to find the decryption algorithm.

The program is packed, and so it is not possible to immediately identify the decryption algorithm. This is fairly standard practice these days – indeed it would be very unusual to find malware that is not packed. However, packing a file is merely a temporary barrier to malware researchers.

As a side note, the free CrypTool [2] application can produce a graphical representation of the amount of ‘local chaos’ within a file, which is very useful for quickly estimating whether a program is packed or not. The following pictures show how typical packed and unpacked programs look.

Figure 2: A typical unpacked file (calc.exe) as analysed by CrypTool

Figure 3: Example showing a typical packed file (Carberp)

If the program is packed using a well-known packer, then we can use a corresponding unpacker to reveal the original code. This often used to be the case with malware several years ago. However nowadays the malware authors almost invariably use custom packers. This usually means that we have to unpack the code by hand, and this is the case with the Carberp program.

As we will see, the Carberp Trojan has several layers of packing and we’ll look at each of these in more detail below.

Layer One

At first, unpacking proceeds deceptively easily. It is fairly easy to guess the point at which unpacking ends and where the unpacked code starts. However, when we get to this point we see that the job has not ended and that we have merely stripped away the outer layer of packing. There are more layers to be stripped away before the original code will emerge.

Layer two

This second layer is more interesting. It contains many calls to system functions such as mouse and window calls, and also takes around seven seconds to execute. Some of the system calls contain invalid parameters and therefore will always fail. Since the program functions entirely without user interaction it is initially puzzling as to what their purpose is. Why have visible elements when you are trying to hide and escape detection? Why track mouse movements when you are not interested in user input? Although we second guess malware author’s intentions at our peril, the most likely purpose is to defeat real-time analysis. Some anti-malware programs, such as Norman’s Anti-Virus, contain a sandbox which will attempt to execute unknown programs. If they exhibit suspicious behaviour in the sandbox they can be identified as malware. This layer is attempting to make it hard for such sandboxes. First, by calling many system calls, often with invalid parameters, it forces the sandbox to emulate these calls perfectly. Not only must the sandbox cope with valid calls, but also invalid calls. Secondly, by taking such a long time to complete, the malware tests the patience of the sandbox. Most sandboxes are set to execute for a maximum time or a maximum number of instructions, and they will give up if nothing suspicious happens within this time.

Figure 4:A call to TrackMouseEvent has been made, but the malware author deliberately set an invalid memorypointer

The next nasty thing we discover is a series of instructions designed as anti-disassembly tricks. These are designed to make it hard for both human researchers and debugger programs to analyse the program. For instance, here we see a series of instructions as displayed by one debugger.

004012C8   EB 05            JMP SHORT 9209bcea.004012CF
004012CA   0303             ADD EAX,DWORD PTR DS:[EBX]

004012CC   0303             ADD EAX,DWORD PTR DS:[EBX]

004012CE   A0 33FE8B5D      MOV AL,BYTE PTR DS:[5D8BFE33]

004012D3   F4               HLT                                     

The first instruction is a jump to location 0x4012cf. But we see that location 0x4012cf is right in the middle of the 5 byte MOV instruction at location 0x4012ce. Here we have a jump seemingly into the middle of another instruction.  The next instruction is a HLT, which would seem to terminate the program.

So what is happening here? A look at the code with a different debugger clears things up.

.data:004012C8 EB 05        jmp     short loc_4012CF

.data:004012CA 03 03        dw 303h

.data:004012CC 03 03 A0     db 2 dup(3), 0A0h

.data:004012CF          loc_4012CF:                            

.data:004012CF 33 FE        xor     edi, esi

.data:004012D1 8B 5D F4     mov     ebx, [ebp-0Ch]

This debugger realises that the 5 bytes starting at 0x4012ca are just junk filler bytes, and are never executed. It declares them as data. We now see that jump is to an XOR instruction, and because of the different instruction lengths now, the HLT disappears and becomes part of another MOV instruction.

This layer has some other tricks to make analysis difficult. At one point, instead of jumping to a code block it pushes the address of the code block onto the stack, and then does a return statement. Unless you know the value of the EAX register at this point, it is difficult to see where the jump will take you.

.data:00401348                 add     eax, offset loc_40134F
.data:0040134D                 push    eax
.data:0040134E                 retn

The layer also has several JUMP <condition> statements where the condition will always be set so that the jump will occur. Again, these are only there to make life hard for researchers.

Figure 5: IDA Pro output showing two branches which can be ignored for flow analysis purposes

However, modern tools are now able to cope with these tricks. The IDA pro analyser is able to produce a visual graph of the flow of this layer, and using that it is fairly easy to track down the point at which this later ends and the next layer starts.

Figure 6: IDA Pro graph showing program flow

Layer three

This next layer is still not the last, and proves to be the trickiest to analyse. This layer actually modifies itself while executing, and so it is not possible to easily analyse it by looking at the original code.

Here is one example.

0085007D   8040 02 A2       ADD BYTE PTR DS:[EAX+2],0A2

00850081   0F0140 81        SGDT FWORD PTR DS:[EAX-7F]

00850085   E2 FF            LOOPD SHORT 00850086

00850087   0000             ADD BYTE PTR DS:[EAX],AL

00850089   0080 EA3080FA    ADD BYTE PTR DS:[EAX+FA8030EA],AL

0085008F   3072 01          XOR BYTE PTR DS:[EDX+1],DH

00850092   CC               INT3

The instruction at 0x85007d adds 0a2 to memory pointed to by the value of register EAX plus 2. If we inspect EAX at this point we find it contains the value 0x850081, and thus the byte at 0x850083 will be modified. This byte is in the middle of the next instruction to be executed, and is coloured red in the above example.

Therefore, once we execute this instruction, the code changes as follows

0085007D   8040 02 A2       ADD BYTE PTR DS:[EAX+2],0A2

00850081   0F01E2           SMSW DX

00850084   81E2 FF000000    AND EDX,0FF

0085008A   80EA 30          SUB DL,30

0085008D   80FA 30          CMP DL,30

00850090   72 01            JB SHORT 00850093

00850092   CC               INT3

The next instruction has now changed length, and thus 5 instructions have changed meaning.

Here is another example. This time the instruction at 0x850099 changes the next instruction at 0x85009b by setting it to the value of the DL register. At this point in the program, the DL register has a value of 0x0B

00850093   8D85 CD3C4000    LEA EAX,DWORD PTR SS:[EBP+403CCD]

00850099   8810             MOV BYTE PTR DS:[EAX],DL

0085009B   EE               OUT DX,AL                               

0085009C   C2 83EC          RETN 0EC83

0085009F  ^74 81            JE SHORT 00850022

008500A1   EE               OUT DX,AL                               

008500A2   0010             ADD BYTE PTR DS:[EAX],DL

008500A4   0000             ADD BYTE PTR DS:[EAX],AL

008500A6   81E6 00F0FFFF    AND ESI,FFFFF000

008500AC   66:813E 4D5A     CMP WORD PTR DS:[ESI],5A4D

This example is even sneakier. Because it changes the first byte of the instruction, the researcher must be careful not to set a breakpoint here. A breakpoint is usually created by placing an INT3 byte, 0xcc, at a particular code location, which causes a trap to the debugger. However, if the researcher does this, the byte will be removed by overwriting with 0x0b. Thus the breakpoint will disappear, the code will run on, and the researcher will have infected their machine – hopefully a virtual machine and not their main work PC!

00850093   8D85 CD3C4000    LEA EAX,DWORD PTR SS:[EBP+403CCD]

00850099   8810             MOV BYTE PTR DS:[EAX],DL

0085009B   0BC2             OR EAX,EDX

0085009D   83EC 74          SUB ESP,74

008500A0   81EE 00100000    SUB ESI,1000

008500A6   81E6 00F0FFFF    AND ESI,FFFFF000

008500AC   66:813E 4D5A     CMP WORD PTR DS:[ESI],5A4D

The self modifying aspects are not limited to modifying single statements or even the next statement. This next example calls a subroutine which modifies a large amount of code at the subroutine exit.  Here is what the code looks like before the subroutine call.

0085010A   FFD0             CALL EAX

0085010C   89AB 0B85FF20    MOV DS:[EBX+20FF850B],EBP

00850112   A7               CMPS DS:[ESI],DWORD PTR ES:[EDX]

00850113   B8 7FDFB6E5      MOV EAX,E5B6DF7F

00850118   23E3             AND ESP,EBX

0085011A   2E:27            DAA                                     

0085011C   52               PUSH EDX

0085011D   EB 6F            JMP SHORT 0085018E

0085011F   B9 895A56AD      MOV ECX,AD565A89

…

And here is what it looks like afterward. (The amount of code changed is a lot more than shown here). The code has been completely transformed.

0085010A   FFD0             CALL EAX

0085010C   8B7C24 54        MOV EDI,DWORD PTR SS:[ESP+54]

00850110   81C7 98070000    ADD EDI,798

00850116   8B7424 04        MOV ESI,DWORD PTR SS:[ESP+4]

0085011A   03B5 733C4000    ADD ESI,DWORD PTR SS:[EBP+403C73]

00850120   8B8D 6B3C4000    MOV ECX,DWORD PTR SS:[EBP+403C6B]

…

Once again, the researcher needs to be careful how breakpoints are used in case they are overwritten while tracing this routine.

The presence of so many self modifying code constructs makes unpacking this layer more difficult than the others, as each construct has to be identified and negotiated successfully, and the researcher has to be very careful how they trace through the code to avoid setting breakpoints which might be overwritten.

Finally, however, the layer is removed. This turns out to be the last layer. We have finally arrived at the actual code that does things, rather than just unpacking.

Layer four

At this point it is fairly trivial to locate and reverse engineer the decryption routine, which does indeed turn out to be XOR based…with a few wrinkles.

Figure 7:IDA pro view of the start of the decryption routine

The next step was to recreate the decryption routine in a small Perl program which could be used by researchers to decode the Carberp configuration files and downloaded modules.

Figure 8: Part of perl program used to decode Carberp encrypted files.

Using this, it was trivial to decrypt the Carberp configuration file.

Figure 9: part of the decrypted configuration file

We have therefore achieved our goal. Now we can see what financial institutions are attacked by Carberp and also get a flavour of the sneaky tricks it is playing on its victims; ‘Meestal duurt het 1-2 minuten’ asks the user to wait for a few minutes…while the Carberp operators are transferring all the money from the victim’s accounts.

Now we have stripped away Carberp’s protection we can analyse more fully what it actually does. There is an in-depth article on Carberp’s behaviour available from the TrustDefender blog [3].

And as it turns out, there are yet more tricks and traps Carberp uses. These will be the subject of a future in-depth report.

We have implemented the decryption of the Carberp plugins and configuration files as a perl program and if you are interested in this decryption program, just send us an email to This e-mail address is being protected from spambots. You need JavaScript enabled to view it

Comments

Name *
Email
Code   

Submit Comment

TrustDefender Labs Report 1 (you will be directed to a contact form and we will send one out to you)

TrustDefender Labs Report 2 (you will be directed to a contact form and we will send one out to you)