SRI International Technical Report
An Analysis of Conficker's Logic and Rendezvous Points Phillip Porras, Hassen Saidi, and Vinod Yegneswaran
Release Date: 4 February 2009 Last Update: 19 March 2009
Computer Science Laboratory SRI International
333 Ravenswood Avenue Menlo Park CA 94025 USAIntroduction
Conficker is one of a new interesting breed of self-updating worms that has drawn much attention recently from those who track malware. In fact, if you have been operating Internet honeynets recently, Conficker has been one very difficult malware to avoid. In the last few months this worm has relentlessly pushed all other infection agents out of the way, as it has infiltrated nearly every Windows 2K and XP honeypot that we have placed out on the Internet. From late November through December 2008 we recorded more than 13,000 Conficker infections within our honeynet, and surveyed more than 1.5 million infected IP addresses from 206 countries. More recently, our cumulative census of Conficker.A indicates that it has affected more than 4.7 million IP addresses, while its successor, Conficker.B, has affected 6.7M IP addresses (see SRI Appendix I: Conficker Census). Our analysis finds that the two worms are comparable in size (within a factor of 3) and the active infection size of Conficker A and B are under 1M and 3M hosts, respectively. The numbers reported in the press are most likely overestimates. That said, as scan and infect worms go, we have not seen such a dominating infection outbreak since Sasser [6] in 2004. Nor have we seen such a broad spectrum of antivirus tools do such a consistently poor job at detecting malware binary variants since the Storm [4] outbreak of 2007.
Early accounts of the exploit used by Conficker arose in September of
2008. Chinese hackers were reportedly the first to produce a commercial package to sell this exploit (for $37.80) [5]. The exploit employs a specially crafted remote procedure call (RPC) over port 445/TCP, which can cause Windows 2000, XP, 2003 servers, and Vista to execute an arbitrary code segment without authentication. The exploit can affect systems with firewalls enabled, but which operate with print and file sharing enabled. The patch for this exploit was released by Microsoft on October 23 2008 [3], and those Windows PCs that receive automated security updates have not been vulnerable to this exploit. Nevertheless, nearly a month later, in mid-November, Conficker would utilize this exploit to scan and infect millions of unpatched PCs worldwide.Why Conficker has been able to proliferate so widely may be an interesting testament to the stubbornness of some PC users to avoid staying current with the latest Microsoft security patches [2]. Some reports, such as the case of the Conficker outbreak within Sheffield Hospital's operating ward, suggest that even security-conscious environments may elect to forgo automated software patching, choosing to trade off vulnerability exposure for some perceived notion of platform stability [8]. On the other hand, the uneven concentration of where the vast bulk of Conficker infections have occurred suggest other reasons. For example, regions with dense Conficker populations also appear to correspond to areas where the use of unregistered (pirated) Windows releases are widespread, and the regular application of available security patches [9] are rare.
In this paper, we crack open the Conficker A and B binaries, and analyze many aspects of their internal logic. Some important aspects of this logic include its mechanisms for computing a daily list of new domains, a function that in both Conficker variants, laid dormant during their early propagation stages until November 26 and January
1, respectively. Conficker drones use these daily computed domain names to seek out Internet rendezvous points that may be established by the malware authors whenever they wish to census their drones or upload new binary payloads to them. This binary update service essentially replaces the classic command and control functions that allow botnets to operate as a collective. It also provides us with a unique means to measure the prevalence and impact of Conficker A and B. The contributions of this paper include the following:- * A static analysis of Conficker A and B. We dissect its top level control flow, capabilities, and timers. * * A description of the domain generation algorithm and the rendezvous protocol. * * An empirical analysis of infected hosts observed through honeynets and rendezvous points. * * Exploration of Conficker's Ukrainian evidence trail. * * A first look at a variant of Conficker B (which we call B++) and the implications of its binary flash mechanism.
...
New: Free Detection Utilities
Conficker C P2P Snort Detection Module