Conficker: rising and shining…

So now for a little more tech detail on Win32/Conficker.AQ (kindly supplied by Juraj Malcho at our labs in Europe – however, if I get anything wrong, that will almost  certainly be down to my faulty interpretation!)

The new variant has two main components. The server component is an .EXE that infects vulnerable PC’s in the network using the same vulnerability described in Microsoft Security Bulletin MS08-067 that Conficker has used since the beginning. This installs the client component, a .DLL (Dynamic Link Library – despite the name, these contain executable code), so as to recruit vulnerable machines into the Conficker botnet.

There is also a driver component that remains on the “server” (the machine that is probing and attempting to exploit other PCs): the driver is used to allow as many machines as possible to connect to the server without the server machine falling over. The infective mechanism stays the same as in previous variants: the shellcode downloads the .DLL from the http server provided by the "server" component (the .EXE) to the targeted, victim machine. The worm starts a HTTP server on a random port. It connects to remote machines via TCP/139 and TCP/445 in an attempt to exploit the Server Service vulnerability. However, the server component will deactive and remove itself after May 3rd, though the client will remain active. The deactivation is carried out using MoveFileEx with the MOVEFILE_DELAY_UNTIL_REBOOT flag, so that the program is removed after the next reboot.

The .DLL contains a newly obfuscated version of the “old familiar” executable, rebuilt using a modified version of the UPX packer. It appears to have been compiled on the 7th April, so the gang seem to be right back in the game and hoping to confuse us by changing the rules. Analysis is ongoing, but a particularly interesting feature is that this version doesn’t contact any of those 50 000 domains a day that we were all so excited about. The new variant, which we call Win32/Conficker.AQ, communicates only within its own peer-to-peer (P2P) network. You’ll find a fuller description of this variant, what it does to the system, which domains it blocks and so forth here.

Curiously, it looks as if the Autorun infection mechanism has been dropped, but it  may still be lurking in a dark corner somewhere: analysis continues, and we’ll confirm that. Our removal tool should work with the new variant, but we’ll be testing and confirming that.

This is, perhaps, the real significance of Conficker: while detection hasn’t presented too many difficulties – the dropper was already detected proactively using a heuristic detection, and all components are detected generically as Win32/Conficker.AQ – guessing where the botnet was going (if anywhere) has been a lot harder. It was for this reason that I was playing with the idea that the whole thing was one immense practical joke. (I yanked that blog because people seemed to think that was serious analysis, not a speculative fancy: however, I might pursue that idea further later on, though not necessarily with reference to Conficker.)

Clearly there’s no out-and-out hoax here, though: reports of an association with Win32/Waledac and the dissemination of spam and fake anti-malware suggests that Conficker is now doing what we always thought it was likeliest to do, and behaving like a botnet. However, despite some reports, I’ve seen no reports of a direct link between Waledac or Conficker and the Storm botnet, though it has been suggested that Waledac comes from the same gang that was responsible for Storm. Hoax or not, the mythmaking goes on.

Director of Malware Intelligence

Author David Harley, ESET

Follow us

Copyright © 2017 ESET, All Rights Reserved.