Conficker/Conflicker/Downadup as seen from the UCSD Network Telescope
More recently, we released the Two Days in November 2008 and Three Days of Conficker datasets collected with the telescope.
We would like to thank Brian Kantor, Stefan Savage, Rick Wesson, Brandon Enright, Phil Porras, Vinod Yegneswaran, Wolfgang John and Sebastian Castro for discussions, contributions and insights.
Background
On October 23, 2008, Microsoft announced a security update that resolved a critical vulnerability in the Windows Server service (MS08-067) [MSFT08067]. In this bulletin, Microsoft stated, "it is possible that this vulnerability could be used in the crafting of a wormable exploit". While various rumors spread, the first serious evidence of a worm outbreak was reported on November 22 2008 by PC World. Security researchers and companies have given this worm various names including Downadup, Conficker, Conflicker and Kido.
Our network telescope consists of large segments of lightly utilized address space that we monitor with permission of its holders. Because there is little legitimate traffic to this address space, we are able to observe large volumes of non-legitimate traffic, including traffic from worms and other malware scanning address space attempting to find new vulnerable machines to infect. [UCSD network telescope.]
SRI's recent technical report provides background on Conficker [SRI-CONFICKER]. We will focus on Conficker's TCP scanning behavior (searching for victim machines to exploit). Conficker engages in three types of observable network scanning via TCP port 445 (where the vulnerable Microsoft software runs) for additional victims:
- Local network scanning; Conficker determines the broadcast domain from network interface settings, even on multihomed machines
- Nearby other infected hosts; Conficker keeps a list of hosts it infects and will scan the class C network (/24) that it infected a host in, and also the previous 10 class C networks
- Random scanning
We focus this analysis on Conficker behavior observable from traffic scanning TCP/445 on the UCSD Network Telescope, and how this differs or complements other sources of information. We think the data we use is one of the few datasets that provides information on the first few hours of the spread of the Conficker worm.
IP Addresses observed scanning telescope via TCP/445
We started recording TCP/445 scanning to the UCSD Network Telescope on October 23 2008, at which point we saw about 1000-2000 unique source IP addresses per hour scanning TCP/445. Before November 21 we saw up to 3222 unique source IP addresses per hour scanning TCP/445. After November 21 midnight UTC we saw a significant increase in source IP addresses that scan on TCP/445, which has remained high ever since. This matches the earliest date Symantec reported on the Conficker.A variant. The maximum number of IP addresses we saw scanning in an hour in 2008 (ie. pre Conficker.B) was on December 1st 14:00 UTC (145,586 unique source IP addresses per hour).
On the smaller (/16) lens of the telescope, we saw a further uptick in TCP/445 scanning around Dec 30/31, which corresponds to the reported start date for the Conficker.B variant.
Figure 1 plots the unique IP source addresses per day observed scanning the telescope space since October 2008, with day-0's for the two first variants labeled. (Several outages of the telescope caused gaps in data.)
Figure 1: Unique source IP addresses scanning on TCP/445 (hourly binning)
Figure 2 plots the unique IP source addresses per hour for the day Conficker.A took off, 21 November 2008. The S-curve starts early Nov 21 and reaches its maximum of 114,911 unique hosts scanning between 5pm and 6pm UTC.
Figure 2: Unique source IP addresses scanning on TCP/445 (hourly binning)
Figure 3 shows an example of the consistent diurnal pattern, with its peak during 2pm-3pm UTC, that remains relatively stable after November 21 2008 and into December 2008.
Figure 3: Unique source IP addresses scanning on TCP/445 (hourly binning). In this magnification the diurnal pattern of scanning is visible, with peaks at 2pm UTC
Figure 4 zooms in on the diurnal pattern and increased scanning activity at the end of December 2008. For this period we only have data for the /16 lens, so our detection rate is lower. The increase in scanning activity on TCP/445 starts on December 29, which roughly correlates with first reports for Conficker.B.
Figure 4: Unique source IP addresses scanning on TCP/445 (hourly binning). In this magnification increased activity correlated with Conficker.B is visible.
Note that there were approximately 2000 unique IP addresses per hour scanning addresses in our /8 telescope lens before Conficker started, and we do not yet have a good way to filter out that dynamic population of TCP/445 scanning addresses. In the next section we describe known aspects of Conficker scanning, and how we might use them to distinguish background noise on TCP/445 from Conficker data. The background noise is less than 1% of the initial jump on day-0 of Conficker.
Conficker's TCP/445 scanning behavior
Figure 5 shows a typical scan from a confirmed Conficker infected host. A couple of characteristics of packets originating from a Microsoft Windows TCP/IP stack can be seen here:
- TTL within reasonable distance from Windows default TTL 128
- Incremental source port in the Windows default range of 1024-5000
- Incremental IP.ID field
We also observed that the Conficker-type scanning only reaches one quarter of the possible IP addresses in the UCSD Network telescope lens, consistent with early reports on Confickers scanning behavior. Like many other worms, the random spread component of Conficker is not especially random. Due to what is likely a bug in the random number generator of the scanning routine, two of the possible 32 bits of any scanned IPv4 address are invariant [BENRIGHT].
#if time src addr dst addr len pro ts ip.id ttl sport dport tcp.seq tcp.ack flags 0 1227232109.314700 0.0.0.0 0.21.211.81 48 6 00 30944 103 4554 445 86087408 - -S---- 0 1227232109.335235 0.0.0.0 0.72.68.92 48 6 00 30986 103 4597 445 c5c93eb0 - -S---- 0 1227232112.311987 0.0.0.0 0.72.68.92 48 6 00 31098 103 4597 445 c5c93eb0 - -S---- 0 1227232112.325345 0.0.0.0 0.21.211.81 48 6 00 31153 103 4554 445 86087408 - -S---- 0 1227232118.378662 0.0.0.0 0.61.41.10 48 6 00 31728 103 4970 445 a2ba5621 - -S---- 0 1227232121.294971 0.0.0.0 0.61.41.10 48 6 00 31885 103 4970 445 a2ba5621 - -S---- 0 1227232122.842741 0.0.0.0 0.44.170.6 48 6 00 32025 103 1090 445 262f9d19 - -S---- 0 1227232125.682085 0.0.0.0 0.44.170.6 48 6 00 32144 103 1090 445 262f9d19 - -S---- 0 1227232131.855248 0.0.0.0 0.94.158.64 48 6 00 32716 103 1414 445 92d161b3 - -S---- 0 1227232134.752334 0.0.0.0 0.94.158.64 48 6 00 32825 103 1414 445 92d161b3 - -S---- 0 1227232134.758070 0.0.0.0 0.33.95.89 48 6 00 32857 103 1334 445 2caa85a6 - -S---- 0 1227232136.324636 0.0.0.0 0.27.62.87 48 6 00 32974 103 1491 445 4cd0dece - -S---- 0 1227232139.253707 0.0.0.0 0.27.62.87 48 6 00 33145 103 1491 445 4cd0dece - -S---- 0 1227232156.377573 0.0.0.0 0.88.189.45 48 6 00 34574 103 2216 445 f272a7d4 - -S---- 0 1227232158.866263 0.0.0.0 0.106.94.126 48 6 00 34866 103 2332 445 1837abab - -S---- 0 1227232159.285071 0.0.0.0 0.88.189.45 48 6 00 34912 103 2216 445 f272a7d4 - -S---- 0 1227232166.330196 0.0.0.0 0.1.226.52 48 6 00 35434 103 2453 445 3ff4a7ad - -S---- 0 1227232166.343984 0.0.0.0 0.12.104.8 48 6 00 35467 103 2468 445 9de035a6 - -S---- 0 1227232176.808817 0.0.0.0 0.53.61.84 48 6 00 36319 103 2856 445 bbf2675d - -S---- [scan continues]Figure 5: Typical scanning behaviour as observed from a single source IP address to the UCSD Network Telescope. Source IP address zeroed out, first octet of destination IP address zeroed out
Distilling Conficker-type scans
Hoping to identify patient 0 in our dataset, we tried to use these distinguishing characteristics of Conficker-type TCP/445 scanning to distill Conficker-type scanning from other TCP/445 scanning. Using an aggressive heuristic (to minimize the chance of false positives) based on what destination addresses are scanned, as well as TCP-retransmit behaviour, we identified what we think is the first Conficker scan to our telescope from an infected host on November 21 01:44:46 UTC. But this heuristic was so aggressive that it removed 80% of the TCP/445 scanning, which contradicts the outbreak we show in Figure 1. So we are still working on filtering out TCP/445 background noise. (Suggestions welcome!)TCP/445 Scanning from IPs that could have been infected by Conficker random scanning
Figure 6 shows the fraction of new IP addresses scanning TCP/445 since midnight November 21 that could themselves have been reached by TCP/445 quasi-random scanning. Pre-outbreak, we see a baseline of around 25% of IPv4 addresses scanning TCP/445 are addresses reachable by Conficker's TCP/445 scanning. Between 1:30am UTC and 5am UTC this fraction jumps to over 70% which suggests that during this period TCP/445 random scanning was Conficker's main infection vector. After its early peak that day, the fraction slowly decays, diluted by other infection vectors and network effects (NAT, DHCP), but it remains well over 25%, which shows the large role TCP/445 random scanning continues to play.
Figure 6: Fraction of hosts in Conficker-scanning compatible address space
Animations of growth of TCP/445 scanning
(Animations by Sebastian Castro)
To visualize the geographic spread of Conficker, we created an animation of unique source IP addresses scanning TCP/445 per country (hourly binning) between November 21 00:00 and 20:00:
Figure 7: Animation of unique source IP addresses scanning TCP/445 per country (hourly binning)
Since IP addresses are unevenly distributed around the globe, we made a second animation that normalized the scanning host count by number of IP addresses allocated to each country. That is, we divided the number of unique sources scanning TCP/445 in each country by the total IPv4 address pool of that country. (For visibility, this animation uses a log scale, and does not show data for countries with less then 100000 IPv4 addresses.) For IP geolocation we used two resources: Digital Envoy's NetAcuity for mapping the observed IP addresses to geographic countries, and MaxMind's GeoLite database to determine the number of IPv4 addresses allocated per country:
Figure 8: Animation of source IP addresses scanning TCP/445 per country normalized by IP population, in IPs per million IPs (hourly binning)
Argentina stands out has having a disproportionately large number of infected IP addresses. Although Conficker.A specifically does not infect hosts that use a Ukranian keyboard layout [TGDAILY], we still see significant Conficker activity in Ukraine, which could either be an artifact of our geolocation inaccuracy, or because many people in the Ukraine do not actually use a Ukranian keyboard layout (the Russian population is ~17% [CIAFACTBOOK]).
Correlation to other data sources
We have also correlated the TCP/445 scanning to HTTP-sinkhole data. We obtained HTTP-sinkhole data for January 25 2009 with 1.51M infected IP addresses logged, which we compared to the 1.27M IPs TCP/445 scanning on our telescope during the same interval. We only observe 580,722 IP addresses that overlap in both sets. There are several reasons why we might see IP addresses in one data source but not the other:
- TCP/445 scanning that is not caused by Conficker
- HTTP sinkhole-log entries not caused by Conficker
- Packet loss or port filtering between infected hosts and observation points
- No route may exist back to the host (scanning observable, sinkhole connection not)
- Use of HTTP proxies by Conficker hosts
The in-situ Network Analysis of an infected host in SRI's tech report on Conficker [SRI-CONFICKER] shows a host that only attempts a limited number of TCP/445 and TCP/80 connections. Hosts like this may not be detected in either HTTP-sinkhole or TCP/445 scanning data. It is unknown how many Conficker-infected hosts are not showing up in HTTP-sinkhole or TCP/445 scanning data, but the large fraction of hosts exclusively in either dataset hints that the fraction of hosts we can't detect either way could be significant.
Conclusions
We are putting up these extremely preliminary statistics while we try to investigate other techniques for analyzing these massive data volumes. Based on the differential levels of TCP/445 scanning before and after November 21 we conclude that Conficker is the most likely source for the huge jump in IPs seen scanning TCP/445 on the UCSD Network Telescope that day, but we are still researching how to more precisely distill Conficker TCP/445 scanning from all the background TCP/445 scanning observed on the telescope.
If you are interested in access to this or other UCSD Network Telescope data, please contact data-info@caida.org.
References and Media Coverage
[MSFT08067] https://docs.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-067
[SYMANTEC-6JAN] Symantec's "W32.Downadup Infection Statistics", 6 January 2009.
[SYMANTEC-16JAN] Symantec's "W32.Downadup.A & W32.Downadup.B Statistics", 16 January 2009. https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=8ccae68b-9fa5-4dd4-8b9b-503586114c80&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments.
[SYMANTEC-20JAN] Symantec's "Downadup: Geo-location, Fingerprinting, and Piracy ", 20 January 2009. https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=98044b9d-51dd-46b1-93ce-4cc7f4691397&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments.
[SYMANTEC-23JAN] Symantec's "Downadup: Attempts at Smart Network Scanning", 23 January 2009, https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=aba510d3-c64b-4690-bb5f-332fbb1a6c2b&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments
[SNORT] Snort, https://www.snort.org/advisories/vrt-rules-2014-08-21
[TECHNET-MS08-067] Microsoft, "More detail about MS08-067, the out-of-band netapi32.dll security update", https://docs.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-067, October 23, 2008.
[TECHNET] Centralized Information About The Conficker Worm, 22 January 2009, https://www.sans.org/security-resources/malwarefaq/conficker-worm.
[TECHNET] Microsoft out-of-band Security Bulletin (MS08-067) Webcast Q and A, https://docs.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-067, October 27, 2008.
[SANS-08067] SANS Internet Storm Center, "MS08-067 Worm in the wild?", http://isc.sans.org/diary.html?storyid=5275, November 4, 2008.
[MOORE03] David Moore, et al., "Inside the Slammer Worm," IEEE Security and Privacy, vol. 1, no. 4, pp. 33-39, Jul., 2003, https://catalog.caida.org/paper/2003_sapphire2/.
[MARKOFF] John Markoff, "Worm Infects Millions of Computers Worldwide", New York Times, 22 January 2009, http://www.nytimes.com/2009/01/23/technology/internet/23worm.html.
[MESSMER] Ellen Messmer, "Downadup/Conflicker worm: When will the next shoe fall? Concerns raised about second-stage payload", 23 January 2009, https://www.networkworld.com/article/2273085/downadup-conflicker-worm--when-will-the-next-shoe-fall-.html.
[KEIZER] Gregg Keizer, "'Amazing' worm attack infects 9 million PCs", 16 January 2009, https://www.computerworld.com/article/2530494/-amazing--worm-attack-infects-9-million-pcs.html.
[FSECURE] Fsecure.com Blog, "Calculating the Size of the Downadup Outbreak", http://www.f-secure.com/weblog/archives/00001584.html.
[FSECURE-] Fsecure.com Blog, "Where is Downadup?", http://www.f-secure.com/weblog/archives/00001589.html.
[TGDAILY], AP Digital, "Fast spreading Windows virus already compromised 9 million computers", 19 January 2009.
[HOUSTON], Bradley Olson, et al., "Conficker shuts down Houston Municipal Court System", Houston Chronicle, 7 February 2009, http://www.chron.com/disp/story.mpl/front/6250411.html.
[ICANN], ICANN announcement, "Microsoft Collaborates With Industry to Disrupt Conficker Worm", 12 February 2009, https://blogs.microsoft.com/on-the-issues/2009/02/12/microsoft-collaborates-with-industry-to-disrupt-conficker-worm/.
[NETWORKWLD-9FEB] Jeremy Kirk, "Kaspersky, OpenDNS collaborate to slow Conficker worm", IDG News Service, 9 February 2009, https://www.cio.com/article/2430873/kaspersky--opendns-collaborate-to-slow-conficker-worm.html.
[TECHCHUCK], TechChunk Blog, "Conficker Worm Sinks French Navy Network", 2 February 2009, http://www.techchuck.com/2009/02/09/conficker-worm-sinks-french-navy-network.
[REGISTER] Dan Goodin, "OpenDNS rolls out Conficker tracking, blocking", The Register, http://www.theregister.co.uk/2009/02/07/opendns_conficker_protection/.
[BENRIGHT] Brandon Enright, personal communication.
[CIAFACTBOOK] CIA Factbook, Ukraine https://www.cia.gov/the-world-factbook/.
[SRI-CONFICKER] Phillip Porras, et al., "An Analysis of Conficker's Logic and Rendezvous Points", http://www.csl.sri.com/users/vinod/papers/Conficker/.
[NETWORKWLD-20MAR] Robert McMillan, "A search is launched for Conficker's first victim", IDG News Service, 20 March 2009, https://www.computerworld.com/article/2531818/a-search-is-launched-for-conficker-s-first-victim.html.
[DHS-CONFICKER] "DHS Releases Conficker/Downadup Computer Worm Detection Tool", March 30, 2009, http://www.dhs.gov/ynews/releases/pr_1238443907751.shtm.