SANS ISC: Some tricks from Conficker's bag

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

There have been a lot of discussions about various aspects of Conficker, definitely the most prevalent worm in last couple of years. Symantec posted a nice series of articles about how Conficker is innovative in various things. One of those innovative things is the use of the autorun.inf file on USB removable media which I described at http://isc.sans.org/diary.html?storyid=5695.

This time I will write about couple of features of this worm that haven't been mentioned much (or at all – or I missed them :). So, let's get busy.

First thing you will notice when reverse engineering Conficker is that it checks whether it has been executed by rundll32.exe (remote infection through the Windows domain or from a USB stick) or if it was started inside the netsvcs service. Similarly to other malware, Conficker will "inject" itself into a remote process. Usually malware authors copy the whole body, but Conficker uses something different. So, when Conficker identifies the netsvcs process, it retrieves the full path to its DLL (i.e. full path to the USB device it was started from). This path is then copied to the target process in freshly allocated memory. Finally, Conficker calls the LoadLibrary() function in the remote process with the argument pointing to copied data, meaning itself. This results in LoadLibrary() loading the worm and executing it in the netsvcs service as a new thread. Cool trick – below you can see OllyDbg's screenshot when Conficker copies path to itself into the target process.



The second interesting thing is related to the MS08-067 vulnerability. As you probably know by now, Conficker exploits this vulnerability in order to infect new machines. However, it does a very interesting thing once a machine gets infected. On infected machines Conficker will actually patch this vulnerability in memory! This is probably done to prevent other attackers from exploiting the same vulnerability (it will not get double-infected because Conficker uses a global mutex to stop other worms from running). Conficker will patch the NetpwPathCanonicalize() function from netapi32.dll by adding a jump to the patched function in its own body.

This fact is especially important when cleaning machines – if you just remove the Conficker worm your machine will become vulnerable again unless you patched it. The machine might even get infected after you remove the worm and while you're patching it so make sure that you patch it before.

Finally, to end this diary which is getting a bit long (but I hope you found it interesting), we'll analyze another action Conficker performs on infected machines: it will delete all System Restore points so the user will not be able to "just" revert back to a previous System Restore. Conficker does this by calling the srclient.dll library, ResetSR() function which is badly documented by Microsoft as well. This obviously didn't scare or stop the bad guys …



Depending on time and feedback I might do more diaries about Conficker – it's certainly an interesting piece of malware with some (a lot?) of innovative features.


Thanks to h4z4rd for sharing ideas and discussing Conficker with me.

--
Bojan