Ollydbg: Opening a file and making the handle available to debugged pr

[PaperBall]

The situation:

 

I have a malicious Word document from which I have extracted the shellcode and loaded it in Ollydbg.

 

The shellcode  assumes it executes within a copy of Microsoft Word which has the malicious DOC file open.

 

The Shellcode will search for the DOC file by going over the list of open open file handles.

 

When it finds a possible match, it (or a part of it) is loaded into memory.

 

The shellcode then proceeds to decrypt the payload in memory etc etc ...

 

 

My question:

 

While debugging a program in Ollydbg, can I manually open a file so that the file handle becomes available to the debugged process?

 

also, is there a way to have the debugger execute my own commands, regardless of what the program code says?

i.e. could I manually open the file so that the filehandle becomes available to the debugged program?

 

Any other suggestions on how I could solve this problems would be appreciated.

 

Thanks,

 

        - Paper

Edited November 14, 2013 by PaperBall

[kao]

I believe the best way to debug such exploits is by debugging shellcode directly inside Microsoft Word. There are lots of reasons, you already found one. Also, shellcode might rely on some MS Office DLLs that won't be loaded in your dummy application.

 

 

is there a way to have the debugger execute my own commands

 

You can assemble some code manually and then change EIP register to run your code. You can automate that with plugin like OdbgScript or MultiAsm which can assemble+run some code in the context of debugged program. Or you can inject your own DLL into debugged process using some Olly plugins (don't remember which one, though).

 

 

can I manually open a file so that the file handle becomes available to the debugged process?

 

Child process can inherit handles from parent processes. But I don't think Olly runs your debugged process with bInheritHandles = true. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

 

 

[PaperBall]

I believe the best way to debug such exploits is by debugging shellcode directly inside Microsoft Word. There are lots of reasons, you already found one. Also, shellcode might rely on some MS Office DLLs that won't be loaded in your dummy application.

 

I agree that would be the optimal method.

Can you give me any hints on what I can break on?

• Start Microsoft Word,
• Start Ollydbg and attach to the Word process
• Set breakpoints on ..??
• Open the infected document in word?
• Debug the Shellcode
• etc ..?

Thanks ,

 

   - Paper

[kao]

If you know which vulnerability is being exploited, you should know which piece of code is vulnerable - and put a breakpoint there.

If you don't know which vulnerability is being exploited, it's a bit harder. I'd start by putting breakpoints on ReadFile and similar functions. Then after Word loads malicious document, put HW on-access breakpoint on the part of the document which contains the exploit. Not sure it's the best way, though..

[PaperBall]

If you know which vulnerability is being exploited, you should know which piece of code is vulnerable - and put a breakpoint there.

If you don't know which vulnerability is being exploited, it's a bit harder. I'd start by putting breakpoints on ReadFile and similar functions. Then after Word loads malicious document, put HW on-access breakpoint on the part of the document which contains the exploit. Not sure it's the best way, though..

 

The vulnerability is "Bloodhound.Exploit.366" or CVE-2010-3333

I tried to attach to Word from Olly and load the file,   

I got a "Access violation" and Olly said it could not show me any code at EIP, (Cannot read memory)

 

[kao]

Quick Googling got me this: http://0x1byte.blogspot.com/2011/02/cve-2010-3333-microsoft-office-rtf-file.html  Using that you should be able to find the vulnerable piece of code in your version of Word and set correct breakpoints.

[Peter Ferrie]

or just change the shellcode to begin with EB FE, let Word run, and then attach.

The shellcode won't be able to continue until you allow it by restoring the bytes.

[PaperBall]

I finally managed to extract the payload with Ollydb, putting the EB FE instructions on the NOP sled and debugging the WinWord process.

Out fell  36 KB RAT.
 

This was a very fun and educative process, 

 

Thanks to both of you,  - PaperBall