Killing Conficker, 1000 days on

Comment: Why is a 'headless' worm still top of the malware ecosystem?

More than 1000 days has passed since the Conficker worm first appeared on 21st November 2008.

When Conficker first appeared, we received a trickle of reports through our ThreatSense.NET telemetry system. By January 2009, that had become a flood, then a deluge, as this ‘super worm' rose to meteoric infection levels.

Since then, Conficker has consistently shown up as one of the top ten infections in our monthly Global Threat Reports, usually in the number one or two slot.

Microsoft has released guidance explaining how to patch and protect computers and the Conficker Working Group toils on in semi-obscurity, providing ISPs with a blocklist of 50,000 pseudo-random domain names that some variants of Conficker use to look for updates in order to pre-empt the worm's update mechanism.

The worm received massive amounts of attention in the news as April 2009 approached, when a change to the worm's update mechanism began. This change ultimately seemed to have little effect on the worm.

As for the Conficker worm itself, it appears to have been abandoned by the criminal gang operating it later in 2009. In June of this year, the FBI and US Department of Justice announced arrests of individuals who may have been its authors.

So why is it that nearly three years later, the Conficker worm is running ‘headless' without command and control (C&C), using a three-year-old exploit, yet is still top of the malware ecosystem?

The answer is complicated, because it lies not in the cyber realm of ones and zeroes, but far above it in circles where questions of doing what's right and proper give way to concerns of budgets, policies and convenience.

To illustrate this, take the story of John who worked as an administrator at a healthcare business. The organisation grew by acquiring smaller companies meaning John supported thousands of desktops across several US states.

The company has hundreds of different networks, computers, operating environments, best practices and standards for managing all of these. It is an enterprise-sized deployment of workgroups.

While it had made some inroads towards establishing universal standards, the organisation's computer security was still a patchwork at best. There was no centralised management of security and some users had administrative access to their PCs due to legacy software.

Users had been infected with Conficker somewhere in the company every single day since the worm came out.

While there were technical issues that facilitate this pandemic, the underlying cause was not really technical: John's employer has not implemented the means to protect its employees because of the expense of installing a centralised management and security solution.

Such an implementation also had to factor in the cost and inconvenience of replacing legacy programs and computers and training employees on the replacement systems.

Solving this problem would be very costly, even using open source software.

But the sooner his company switched to a centralised management and security model, the better off it would be.

Killing Conficker

So what would it take to kill Conficker? That's a difficult question to answer. Clearly, anti-malware software and other technical solutions and prescriptive guidance are not enough, nor is the prospect of being fined for violating industry-specific regulations.

Some of the most successful actions against botnets have been taken by US authorities acting in conjunction with Microsoft, to shut down such botnets such as Waledac, Coreflood and most recently, Rustock.

These botnets relied on accessing specific domains or computers for their C&C servers and began to vanish as soon as these were seized by the authorities.

While the earliest version of Conficker accessed a single domain, later versions switched to access hundreds and then tens of thousands of random domains on a daily basis, making the worm highly resistant to this type of infrastructural attack.

Providing patches, prescriptive guidance and software to combat the worm are the tools that security and operating system vendors provide to ameliorate threats.

Just because they are available however, does not mean they are going to be used or managed correctly, as in the example of John's company.

So where does that leave us? If we cannot do anything now to secure some of our systems, it seems like we will have to rely on future mitigations.

When Microsoft released Windows 7, it made a seemingly small change to the way in which the system handles the behaviour of AutoRun, its technology for starting programs from removable media.

This effectively immunised that operating system against worms that spread via AUTORUN.INF files. Microsoft eventually made this available as an update to Windows Vista and Windows XP, although installation isn't mandatory.

Windows 7 and Windows Server 2008 R2 were released after the vulnerabilities exploited by Conficker were fixed, which hampers its spread in those environments.

Microsoft has not shared much information with the public about the next version of Windows, but hopefully Windows 8 will contain additional anti-Conficker refinements.

Variants of Conficker attempt to spread over network shares, guessing the password based on some commonly used methods and words.

Hard-coding the list into Windows 8 might be overkill for a threat as old as Conficker, but if Windows users are unable or unwilling to manage their security correctly, then enforcing more secure choices, as Microsoft has done with its changes to AutoRun behaviour, may be the only solution.

Aryeh Goretsky is a researcher at ESET. This column first appeared on the company's blog.