Conficker (aka W32.Downadup) is a complex multi-mode worm that exploits Windows platform computers, using the MS08-067 vulnerability. Despite being patched by Microsoft on October 23, 2008, Conficker.A was picked up by security researchers in late November exploiting the large number of remaining unpatched systems without firewall protection. In January 2009 almost 30% of machines affected by the vulnerability remained unpatched, according to Wolfgang Kandek of Qualys.

This article examines the features of the worm, drawing on research by Symantec, SRI and others to present the methods of exploitation, propagation, auto-update and defence. A follow-up article will present some analysis of the use of DNS-blacklisting by industry to attack the distributed update mechanism utilised in early Conficker variants. The worm features are presented as a progression from Conficker.A through to Conficker.E, introducing innovations in timelime order.

Conficker.A

Conficker.A was first detected on 21 November 2008 and exploited MS08-067. Propogation was noted in November by Symantec but using only a single exploit, it didn’t achieve a great deal of traction.

Xiao Chen reported that the exploit code that Conficker uses is from the Metasploit framework, specifically the ms08_067_netapi module.

DNS Rendezvous Update Mechanism

Conficker.A incorporated an update mechanism that was designed to mitigate standard IP and DNS blacklisting attempts. Each day it would generate a list of domain names using a Pseudo-Random Number Generator (PRNG) seeded with the current date as taken from a series of large public websites. Each worm would calculate the same set of 250 addresses and then select a random subset of 50 of those addresses to poll for updates. The virus authors could thus pre-position updates on a single pre-calculated domain, on the correct date, knowing that approximately 20% of the Conficker population worm would check in for an update. Five domains would increase that percentage to nearly 100% under ideal conditions.

Symantec and others took advantage of this update mechanism by having their analysis teams register a series of the domain names in advance and monitor the number of worms checking in for updates. Over the course of a week Symantec saw over 3,000,000 unique IP addresses check in for updates, probably indicating a worldwide population of at least that number.

Dictionary Attack

Conficker.B, spotted in the wild on 29 December 2009, supports multiple infection vectors. In addition to exploiting the NetBIOS MS08-067 vulnerabilty, this multimode variant attempts a dictionary attack on the Windows ADMIN$ share. Using a NetServerEnum request to enumerate the Windows machines on the local network it queries each for a list of usernames, though this request is denied by default in XP. Using either the returned usernames, or the usernames on the current host, Conficker attempts to mount the share using over 250 common passwords and variations of the username (reversing, duplicating etc). An unexpected denial-of-service side effect of this dictionary attack is to lock out the Active Directory accounts of users of exploited machines.

Autoplay Infection

The updated Conficker.B also supports propagation via Autoplay. Though not the first worm to make use of this method, Conficker doesn’t disappoint us through the addition of a series of twists. Hiding itself in the recycle bin is the first. In this hidden folder Conficker masquarades as a Security Identifier (SID) with a file inside using a random name and file extension. The aim of this cloaking is to avoid being spotted as a Dynamic Linked Library (DLL). Conficker also takes advantage of the implementation of the Windows parser for autorun.inf files. Windows detects this file and then extracts only those lines of text that it expects. Any lines not conforming to the specification are ignored. Conficker takes advantage of this by filling up the file with junk lines and hiding the real autorun configuration near the end of the file. Lastly, Conficker registers with Windows as a listener object for the WM_DEVICECHANGE method. This ensures the O/S notifies the worm when removable devices change – enabling real-time infection.

Active Defences

Conficker.B introduces two simple methods of defence against AV. Firstly it disables auto-update, to mitigate the risk that the O/S will patch the NetBIOS service that allowed the exploitation in the first place. Secondly it blocks DNS lookups for a number of domains associated with AV, anti-malware and other update services.

Avoiding Low Return Netblocks

Conficker.B introduced an IP blacklist containing netblocks for common AV providers and Corporations (e.g. Microsoft). This could well have been an attempt to avoid detection by the whitehat community, though also have had the effect of avoiding low return netblocks – those likely to be adequately patched and firewalled.

Threat Mitigation

Both up-to-date patching and firewalls blocking NetBIOS port 445 from the Internet will protect against Conficker. Disabling auto-play in Windows will also prevent being infected through the use of USB removable media. In an attempt to understand the high propagation rate, Symantec geo-correlated the infection rate of the worm with instances of software piracy. The hypothesis was that pirates disable Windows Update to avoid Windows Genuine Advantage (WGA) or other updates compromising their ability to continue use without paying. Thus, countries with high instances of piracy will be exposed to increased risk of a worm attack that exploits a patched vulnerability.

In February, at the height of the Conficker.B/C infections, the biggest concern by Security Researchers was that the worm authors could use the auto-update facilty to operationalise a botnet of at least 10 million nodes (by late February 3 million Conficker.A and 6 million Conficker.B victims had been mapped). Attacking the auto-update system was therefore the highest priority.

Microsoft announced a Conficker Working Group who would register or block the rendezvous domain names used in the update mechanism. In most cases these domain names were pointed towards Conficker sinkhole networks that gathered data. Arbor Networks were involved in the analysis of some of this data. Digital Threat is currently analysing DNS rendezvous data from November through May that looks like it will illustrate well the scale of the industry intervention.

Conficker.C

The DNS rendezvous mechanism used in Conficker.C increased the number of domain names generated by the PRNG from 250 to 50,000, with a subset of 500 polled each day by the worm. This was probably an attempt to mitigate the Conficker Working Group’s policy of domain blacklisting / sinkholing. The change also has a DDOS protection side-effect – by reducing the number of worms expected to check in to any one rendezvous point to 1% of the global population, the load on each update service is dramatically reduced.

Conficker.C also increases its defensive posture by killing processes with names that match those of common AV products. This is in addition to the existing policy of blocking DNS requests to a number of update and AV sites.

Conclusion

As a multi-mode worm that went through a series of well managed update cycles, each mitigating a threat posted by the AV industry, Conficker represents the most evolved worm to achieve global penetration to date. Since the years of heavy worm infestation (1999-2001), malicious coders had moved to smaller scale, targetted attacks that operationalised exploitation. Credit card fraud, identity theft and denial of service in support of extortion being the major operational outcomes.

Conficker returned to mass scale exploitation, but importantly included ability to operationalise the network at any point through its disruption-resistant update process. Towards the end of its lifecycle, Conficker showed attempts to sell victim users fraudware to remove itself, but the release was buggy and ineffective.

As the next article in this series will show, the industry acted quickly against the threat posed by Conficker.A/B/C through reverse-engineering the binary, breaking the PRNG algorithm and mass blacklisting the update domains. Ultimately, though, Conficker disappeared because it wanted to. The final revision self-destructed on May 5th before industry had a chance to combat its new peer-to-peer distributed update technology. Though a positive outcome, it certainly was not one of our making. It will be interesting to see how effective the industry response is to the next undoubtedly stronger challenge.