Conficker Clarified

I just happened upon a blog that made an interesting point about the information that’s been made about Conficker. Essentially, the writer was fulsome in her praise of an article by Gary Hinson here, which gave some simple advice on dealing with Conficker/Downadup. As it happens, I’m familiar with the name Gary Hinson: he also contributes to a blog here to which I also contribute occasionally, and has posted some excellent stuff there. In fact, Randy and I wrote a paper for AVAR last year that cites one of those posts (it should be available on our white papers page here soon).

I have to agree that the simpler the better in a case like this. and most people are probably more interested in how to avoid or remove the thing than they are in the complexities of estimating how many infected machines there really are.

(Not that I mean to criticize F-Secure in any way for making that information available: after all, I belong to a community that finds that stuff fascinating. And they’ve certainly provided provided plenty of information more immediately relevant to the man-in-the-street, or perhaps I should say the end-user-on-the-information-superhighway.)

I felt that in this case, Gary had missed one or two essential points and perhaps had slightly oversimplified the issues. So here’s an attempt to be a little less geeky than Pierre-Marc and I were in an earlier post on the topic and boil it down to a more accessible form.

As there’s a great deal of malware around that exploits the autorun facility (autoinfect, as we sometimes rather harshly refer to it round here), it’s an excellent idea to disable it, but to do so effectively is a lot less straightforward than the procedure in Gary’s blog (though even that will lower the risk). Microsoft have revised their procedure for doing so at http://support.microsoft.com/kb/953252, but US CERT’s note at http://www.us-cert.gov/cas/techalerts/TA09-020A.html addresses some weaknesses in the procedure. I agree, though, that if looking at these procedures makes you nervous, you probably need support from someone more confident with PC maintenance.

But there’s a lot more to Conficker than autorun. The main reason that so many -corporate- systems are infected is that they haven’t patched the vulnerability described here, www.microsoft.com/technet/security/Bulletin/MS08-067.mspx  and they ought to be patching MS08-068  and  MS09-001 at the same time. (See the earlier blog for more details.)

There’s also an issue with weakly passworded network shares that will certainly affect many corporate networks, though few home users, I’d guess. Like so much modern malware, Conficker will slip onto your system by any route it can find.

And because many home users will be using free but unsupported AV software, and in any case Conficker tries to stop infected systems from accessing vendor web sites, contacting the vendor may not be so simple. For cleaning purposes, the best option for many will be to get one of the Conficker-specific tools some vendors have made available, which will probably require access to an uninfected machine. Ours is here, but other vendors have similar tools. 

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

Author David Harley, ESET

  • palmiche

    I’m ok with all the trouble disabling autorun as explained in http://support.microsoft.com/kb/953252 as long as someone can tell me why is it better than my own way: Disable “Shell Hardware Detection” service. In http://www.microsoft.com/technet/security/bulletin/ms07-006.mspx they said Fast User Switching might be affected but so far** I haven’t had any kind of issue.

    *** More than 7 years using different XP builds/servicepacks in 3 different languages.

  • http://www.smallblue-greenworld.co.uk David Harley

    The point isn’t to do it the Microsoft way, or the US-CERT way: it’s to do it as best you can. There is more than one approach, as we’ve pointed out many times in these blogs, and where feasible, I’d suggest hedging your bets!

  • http://www.agileInstitute.com Rob

    Does ESET have documentation of whether or not NOD32 would detect anything, and what EConfickerRemover will actually do to a system? People are hoping for very simple instructions, if that’s possible. Thanks!

  • David Harley

    NOD32 has very efficient detection for current (and, hopefully future) Conficker versions, and we’re watching what happens next very carefully.
    http://www.eset.com/threat-center/blog/?p=835

    I haven’t actually run the removal tool: obviously, it disinfects the system, but I don’t know if it requires any interaction from the user, if that’s what you’re asking. I’ll ask.

  • David Harley

    Or, better still, I’ll try it out, since it’s unfair to expect the lab to answer too many questions on a Sunday.

    It’s a command line tool: if you run it from the icon, it tells you the two options for running it (autoclean, i.e. disinfection without user prompts, and reboot, i.e. reboot the machine after cleaning). If it doesn’t find Conficker in memory, it will tell you so and ask you if you want to scan and disinfect anyway. I went ahead and did that on a clean system, and it did no harm. You need to run the utility from the DOS prompt to use the options.

    I can see that the command line interface might be a little intimidating to people who didn’t cut their teeth on early MS-DOS versions, so I’ll check it out more thoroughly and come back to it in a new blog.

Follow Us

Automatically receive new posts via email:

Delivered by FeedBurner

26 articles related to:
Hot Topic
ESET Virus Radar

Archives

Select month
Copyright © 2014 ESET, All Rights Reserved.