Skillset

In this post, I am going to explain in detail how to go about reversing an exploit with which one can easily insert his/her own payload, providing an exploit sample is available. I have taken exploit sample CVE 2010-3333 in order to complete this exercise. So let’s first explore this document (Laden’s Death.doc) to see whether it’s an exploit or not by just looking at it in hex editor. We know that the vulnerability exists in pFragment, so in the given sample we have to find the parameter of pFragment and have to analyze something suspicious.

When I opened the document in hex, I found something suspicious as an address in pFragment parameter and that is bc41db77; let’s search this address in debugger (77db41bc):

Address not found. That’s why, when I executed this sample, it crashed, as shown in the following picture:

Anyway, I am not going to explain the crash analysis here. Our goal is to replace the payload in this exploit with our own payload. But, in brief, it/s crashing because the address used in this exploit sample (77db41bc) is taken from user32.dll of xp sp2, but I am using xp sp3, so this address is not available. It can be made workable on xp sp3, by taking any address from the xp sp3 dll. I took it from kernel 32.dll ‘jmp esp address and replaced it with 7b46867c (jmp esp address of kernel32.dll xp service pack 3). Then it worked fine.

When the RTF file is opened, the exploit executes the shell code and drops a file named server.exe inside C:/RECYCLER and executes it.

C:/RECYCLER/server.exe does the following:

• Drops a file in the system’s temp folder: vmm2.tmp • File vmm2.tmp is renamed and moved to c:\windows\system32\dhcpsrv.dll • Makes registry modifications in an attempt to hijack the DHCP service

So let me first analyze the shell code for server.exe, where there are actually two ways to analyze it.

1) In hex editor

2) In debugger

Let me open sample in hex editor and try to find the shell code for server.exe.

While analyzing in hex we found something suspicious; that is address 7b46867c. This address has been taken from the ntdll file, and the shell code begins from eb10 till eeeeeeeeeeee, as shown in the following figure:

at eeeeeeeeeeeee

After a deep analysis, we found that the shell code has been encrypted by 8-bit EE XOR, as in the instruction

XOR BYTE PTR DS [EDX+ECX], 0EE

Also encryption begins from last to start, that is from eeeeeeee to the start of the shell code.

Now it’s time to replace the full shell code by your own code. I have the following shell code that will execute calc from our server:

So I will replace the existing shell code with our own code. After replacing, the sample looks like this:

Now, after executing it, it should execute calc.

Wow, calc pops up.

Now it’s time to analyze the drop dll, which has been dropped into system32 with the name of dhcpsrv.dll.

After analyzing, we see that the exploit sample is dropping dhcpsrv.dll in c:\windows\system32 folder, as in picture, and that is going to be executed by rundll32.exe.

We will analyze the dropped dll (dhcpsrv.dll) further, but first we have to attach it with debugger. There is a process in attaching debugger. I am going to attach it with WinWord, as it is an Office document file. After attaching and before executing, we have to set a breakpoint (F2) in debugger on various win32 function. Here you will get a clear picture once you reverse two or three samples yourself. I am going to write here the common functions that are desirable to set a breakpoint before reversing. They are:

After setting a breakpoint, we have to Step Over (F8 ) in debugger and while doing this we will have to look carefully for some suspicious address in the stack windows of debugger (bottom right). We mainly analyze the load library function also and, while analyzing, we look to see if there is any library or any function get loaded by some suspicious address (“suspicious” means an address that does not belong to the kernel ). After a long analysis, we find that the CreateFile function gets loaded at a suspicious address, that is,

The CreateFile function gets loaded at the suspicious address (0011f438). A point to be noted is that this address may change from computer to computer. Now our main job should be to find the actual location of the embedded dll/exe, that is the start location of exe/dll, the end location, the size of the embedded exe/dll, and the algorithm by which exe/dll has been encrypted. We will start analyzing line by line from the beginning of the suspicious address.

In the above picture, look at the stack windows. There is a call to CreateFileA function from address 0011F438. Now our next work is to start analyzing from this address, so we will set a Break Point at 0011F438.

The CreateFile function gets loaded at the suspicious address (0011f438). Note that this address may change from computer to computer. Now our main job should be to find the actual location of the embedded dll/exe, that is start location and end location of exe/dll, and the algorithm by which exe/dll has been encrypted. To do that, we will start analyzing line by line from the beginning of the suspicious address. We find the following instruction:

00115F4E AC LODS BYTE PTR DS : [ESI]

0011F54F 3C 00 CMP AL, 0

0011F551 74 06 JE SHORT 0011F559

0011F553 3C FC CMP AL, 0FC

0011F555 74 02 JE SHORT 0011F559

0011F557 34 FC XOR AL, 0FC

0011F559 AA STOS BYTE PTR ES : [EDI]

0011F55A E2 F2 LOOPD SHORT 0011F54E

Let’s look at the two boldfaced instructions:

00115F4E AC LODS BYTE PTR DS : [ESI]

This instruction reads the address stored at ESI and stores its value to EAX, while the instruction

0011F559 AA STOS BYTE PTR ES : [EDI]

stores the value of EAX to the EDI . So the encryption algorithm is to read each byte of exe; if it is 0 or OFC then leave it as it is, if not then XOR with OFC as in the instruction

0011F557 34 FC XOR AL, 0FC

So we found the encryption. The next steps is to find the start, end, and size of the exe. This can be found in a function like SetFilePointer. But in this sample we found this information by doing some manual analysis, as you can see in dump windows:

There is some sequence of values with ASCII 6161616161, etc.; let’s search this value in the Hex of the exploit sample:

While analyzing in the dump window of the debugger, we found that the decryption starts after }}}} (4 curly braces in dump ), so let’s move into hex to decrypt the value and try to find MZ (as MZ is the start header of the PE file ). If MZ is found, it indicates that this is the beginning of exe. Now what is the total size of exe? For that, we have to check the file that’s dropped into c:/windows/system32 dhcpsrv.dll, open it in the hex editor, and find the total size; this will be the total size of exe/dll. We find the total size of dll is DLL ADD8 in hex, 44504 in decimal. So now we have found:

Encryption algorithm

Start Location of dll/exe

End location of dll/exe

Now our main job is to write the creator with proper encryption key and start and end location. That will generate a malicious .doc file. The creator could be written in any scripting language, that is, Python, Perl, etc. I have chosen Python to write the creator, as I explain below.

The point where MZ is found is the start point of exe.

Anyway, while analyzing this sample, one can get confused about where to insert our own payload. Do keep in the mind that you have to replace the shell code at the server.exe shell code, not at the place where it is dropped in the system32 (dll file ). So now it’s time to write the full creator code that I have written in Python. Here is the full creator:

URL.txt contains the actual URL from where one has to download calc. This URL.txt file should be in the same folder where the creator file will be.

You can also embed the direct text string of the URL in the creator file.

One more point: reversing the exploit sample will vary from exploit to exploit. It’s not that while reversing another sample you will always apply the same process, but in 80% of the cases, it’s what I explain above.

I have been testing this exploit and I tried to change the shellcode to use winexec(‘calc.exe’) but when I change the shellcode, MSWord (or maybe the OS) change it to 00, can you explain why this happens please?

Thanks in advance!

matured fella

I would appreciate if you can send me the malicious doc file (laden’s death.doc).
Thank you!

About InfoSec

InfoSec Institute is the best source for high quality information security training. We have been training Information Security and IT Professionals since 1998 with a diverse lineup of relevant training courses. In the past 16 years, over 50,000 individuals have trusted InfoSec Institute for their professional development needs!

Join our newsletter

File download

First Name

Last Name

Work Phone Number

Work Email Address

Job Title

Does your employer pay for training?

What is your timeline for training?

InfoSec institute respects your privacy and will never use your personal information for anything other than to notify you of your requested course pricing. We will never sell your information to third parties. You will not be spammed.

Comments

What is Skillset?

Skillset

Practice tests & assessments.

Practice for certification success with the Skillset library of over 100,000 practice test questions. We analyze your responses and can determine when you are ready to sit for the test. Along your journey to exam readiness, we will:

1. Determine which required skills your knowledge is sufficient
2. Which required skills you need to work on
3. Recommend specific skills to practice on next
4. Track your progress towards a certification exam