New Year and Browser Helper Objects


The New Year brings in interesting things (or so we hope). My friend came up to me with an “infected” computer with a fantastic piece of malware installed. The malware was presented the user with a completely different HTML page when something was searched on Google. Browser Helper Objects (BHOs) are Dynamic Link Libraries (DLLs) that are installed in Internet Explorer (IE) and have a complete access to the DOM tree of the browser window. The name of the DLL was xyusx.dll (or something like that). This DLL was packed so that it wouldn’t permit a clean disassembly. The usual tricks seemed to work and I was able to unpack the DLL.

The procedure is simple. Open the DLL in OllyDbg. Search for the PUSHAD instruction (this instruction stores all the registers on the top of the stack) and set a breakpoint (F2 key in OllyDbg) on that instruction.

Press F9 to continue the debugging. Press F8 to execute the instruction, and then set a hardware breakpoint on the top of the stack in the Dump Window as shown in the image. You can do this easily by right clicking on the ESP register and clicking on “Follow in Dump”.
Once you reach the POPAD instruction or the hardware breakpoint is activated, this shows that the registers that were saved on the stack are now going to be restored in the respective registers. This indicates that the program has now finished extracting itself and is ready to execute the instructions.
I used OllyDump to dump out the contents of this DLL and then used LordPE to repair the import table. This process, however, needs more work due to the nature of the automated import address table repairing as some things can be missed.
Once this repairing was finished, I opened the file in IDA Pro to disassemble the unpacked DLL. This did give me a lot of information about this DLL, however, I’m still in the process of completing a good disassembly of this DLL.
As for now, I can say that this DLL installed a bunch of spyware CLSIDs into the system.
Some of the CLSIDs (out of the 45 that it uses) by this malware are listed below:


This DLL also seemed to communicate to :

Whatever you do to these servers is upto you. Some google searches allude that this is a “Vundo infection”. I’m also not sure what solutions people are posting to this problem but I’d not feel safe if this malware was on my computer and I’d definitely format my Windows install, patch it and change my passwords! I’m not completely dne with the disassembly and reversing of this malware yet, but I’m sure I’ll post more when I delve into this disassembled code deeper.


Echo Mirage and UHooker


It can get interesting to test the security of thick client applications. If you start debugging you could end up losing a lot of time with not too many results. Of course, time is always at a premium when you pen testing in a week long gig. There are a couple of tools that can really help you to gain insight into a thick client (i.e., an application written in a binary format such as an executable, ActiveX control, flash object, etc.) and communicating to a server using the client/server model.
The need for a proxy to hook into the communications is a prime need and EchoMirage can do a great job of hooking into function calls related to win32 sockets, openssl functions. You have to select an active process for Echomirage to inject into or you can even spawn a process from the menu options in EchoMirage itself. It’s a great tool with a built-in editor so you can edit the traffic. However, sometimes you have to be careful because it’s binary data that you are editing so while editing it is easy to mess up a few flags, etc.
Another great tool is actually a plugin for OllyDbg called UHooker that can let you specify which functions you want to place a hook into. You have to configure a binary editor of your choosing and the functions to be hooked into in a .cfg file. The documentation for Uhooker is located here.