Saturday, April 4, 2009

Manual IAT Recovery Using ImpREC

There are a lot of tutorial on the Internet teaching how to use ImpREC to recover Import Address Table (IAT). But those tutorials are only covered using the "Auto IAT Search" function by Imprec. The "auto" function is not able to fully recover the IAT like this:


How do we determine these are the unresolved APIs? Try using OllyDbg, find the OEP, it is fairly easy to find it if the sample was packed by UPX ;) , and Follow in Dump -> Memory Address to any API's call, for example:


Now in the Memory Dump window, switch to Address view and then you can see the list of APIs:



These are the IAT that we missed just now when loading it to IDA. So the next thing is to recover this so that we can continue static analysis on IDA. Scroll up until 0 byte memory address which is beginning IAT relative virtual Address (491cc) and scroll down until 0 byte memory address which is the ending IAT relative virtual address (49338).

Dump the sample using OllyDump, then we can start ImpREC to recover the IAT using the starting RVA we found just now. Using the AutoSearch button will give us:


Notice that the original IAT RVA found at 49284 seems to be incorrect. If you fix the dump with this option you will see the unresolved APIs as shown in the first figure. So we need to set the OEP, RVA and Size (49338-491cc) manually and select Get Imports:



We can now fix the dump using Fix Dump button, select the file that was dumped by OllDbg just now. Done! Next we can load to IDA and see the result:


Signing off
~x9090

Wednesday, April 1, 2009

Customd Detection and Removal Tool

A big april fool worm was setup to be activated today, but it seems that the worm get many security expert disappointed. There are no major havoc caused by this worm yet (at least at the time of writting this blog 12:05 GMT).

For those who suspect their PC is infected with this machine, the easiest way to find out is by visiting some security related websites for example:

  • www.symantec.com
  • www.microsoft.com
  • www.macfee.com
  • www.f-secure.com
and etc.

Conficker/Downadup was designed to block the infected machine from visiting these security websites to prevent victims to find solution to remove this worm. For more technical details on how it prevents from visitng the websites (hooking the Windows API DnsQuery from dnsapi.dll) :

http://mtc.sri.com/Conficker/addendumC/ <-- This is so far the most consolidated analysis that I have ever seen :) The following website is the consolidated methods of detection and removal for Conficker/Downadup from dShield:


http://www.dshield.org/diary.html?storyid=5860


Using Nmap to Perform Conficker Test

I was attracted by the new Nmap scanning features which include the script to scan your network to test if you are infected with the Conficker, thanks to Honeynet Project (Tillmann Werner and Felix Leder) :D

nmap -PN -T4 -p139,445 -n -v --script=smb-check-vulns --script-args safe=1 [host]

typical scan result for infected machine:

Host script results:
| smb-check-vulns:
| MS08-067: FIXED
| Conficker: Likely INFECTED
|_ regsvc DoS: VULNERABLE

The testing was done using Nmap4.85BETA6

Signing off
~x9090