{
	"id": "ccf5beee-4201-45e8-ae1f-b70973e0a3cd",
	"created_at": "2026-04-06T00:12:23.747681Z",
	"updated_at": "2026-04-10T03:20:28.715899Z",
	"deleted_at": null,
	"sha1_hash": "e8140b26b8ddad258e2cc72c9bff65ce0d086ccd",
	"title": "CCleanup: A Vast Number of Machines at Risk",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 765747,
	"plain_text": "CCleanup: A Vast Number of Machines at Risk\r\nBy Edmund Brumaghin\r\nPublished: 2017-09-18 · Archived: 2026-04-02 10:37:05 UTC\r\nUpdate 9/18: CCleaner Cloud version 1.07.3191 is also reported to be affected\r\nUpdate 9/19: This issue was discovered and reported by both Morphisec and Cisco in separate in-field cases and\r\nreported separately to Avast.\r\nUpdate 9/19: There has been some confusion on how the DGA domains resolve.\r\nThe fallback command and control scheme in use by the CCBkdr involves:\r\n1. Generating a Monthly Domain name (all of which are controlled by Talos for 2017)\r\n2. Request the A records for the domain.\r\n3. 16 bits of the true destination IP are encoded in the first A record, 16 bits are encoded in the second A\r\nrecord\r\n4. The true destination IP is then computed and connected to.\r\nTo control the connections Talos has to create two IPs such that they can be fed into the application to\r\nresolve to the sinkhole IP.\r\n32 bits of random data were generated. 16 bits of that were combined with 16 bits of the destination\r\naddress to create the first A record. The remaining 16 random bits were combined with the remaining\r\nbits of the destination address to create the second A record.\r\nThe resulting two A record IP addresses were then assigned to the DNS configuration.\r\nThere was no analysis performed on the selected addresses beyond that they could be combined to\r\ncreate the destination.\r\nUpdate 9/20: Continued research on C2 and payloads can be found here: /ccleaner-c2-concern\r\nIntroduction\r\nSupply chain attacks are a very effective way to distribute malicious software into target organizations. This is\r\nbecause with supply chain attacks, the attackers are relying on the trust relationship between a manufacturer or\r\nsupplier and a customer. This trust relationship is then abused to attack organizations and individuals and may be\r\nperformed for a number of different reasons. The Nyetya worm that was released into the wild earlier in 2017\r\nshowed just how potent these types of attacks can be. Frequently, as with Nyetya, the initial infection vector can\r\nremain elusive for quite some time. Luckily with tools like AMP the additional visibility can usually help direct\r\nattention to the initial vector.\r\nTalos recently observed a case where the download servers used by software vendor to distribute a legitimate\r\nsoftware package were leveraged to deliver malware to unsuspecting victims. For a period of time, the legitimate\r\nsigned version of CCleaner 5.33 being distributed by Avast also contained a multi-stage malware payload that\r\nrode on top of the installation of CCleaner. CCleaner boasted over 2 billion total downloads by November of 2016\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 1 of 13\n\nwith a growth rate of 5 million additional users per week. Given the potential damage that could be caused by a\r\nnetwork of infected computers even a tiny fraction of this size we decided to move quickly. On September 13,\r\n2017 Cisco Talos immediately notified Avast of our findings so that they could initiate appropriate response\r\nactivities. The following sections will discuss the specific details regarding this attack.\r\nTechnical Details\r\nCCleaner is an application that allows users to perform routine maintenance on their systems. It includes\r\nfunctionality such as cleaning of temporary files, analyzing the system to determine ways in which performance\r\ncan be optimized and provides a more streamlined way to manage installed applications.\r\nFigure 1: Screenshot of CCleaner 5.33\r\nOn September 13, 2017 while conducting customer beta testing of our new exploit detection technology, Cisco\r\nTalos identified a specific executable which was triggering our advanced malware protection systems. Upon closer\r\ninspection, the executable in question was the installer for CCleaner v5.33, which was being delivered to\r\nendpoints by the legitimate CCleaner download servers. Talos began initial analysis to determine what was\r\ncausing this technology to flag CCleaner. We identified that even though the downloaded installation executable\r\nwas signed using a valid digital signature issued to Piriform, CCleaner was not the only application that came with\r\nthe download. During the installation of CCleaner 5.33, the 32-bit CCleaner binary that was included also\r\ncontained a malicious payload that featured a Domain Generation Algorithm (DGA) as well as hardcoded\r\nCommand and Control (C2) functionality. We confirmed that this malicious version of CCleaner was being hosted\r\ndirectly on CCleaner's download server as recently as September 11, 2017.\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 2 of 13\n\nIn reviewing the Version History page on the CCleaner download site, it appears that the affected version (5.33)\r\nwas released on August 15, 2017. On September 12, 2017 version 5.34 was released. The version containing the\r\nmalicious payload (5.33) was being distributed between these dates. This version was signed using a valid\r\ncertificate that was issued to Piriform Ltd by Symantec and is valid through 10/10/2018. Piriform was the\r\ncompany that Avast recently acquired and was the original company who developed the CCleaner software\r\napplication.\r\nFigure 2: Digital Signature of CCleaner 5.33\r\nA second sample associated with this threat was discovered. This second sample was also signed using a valid\r\ndigital certificate, however the signing timestamp was approximately 15 minutes after the initial sample was\r\nsigned.\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 3 of 13\n\nThe presence of a valid digital signature on the malicious CCleaner binary may be indicative of a larger issue that\r\nresulted in portions of the development or signing process being compromised. Ideally this certificate should be\r\nrevoked and untrusted moving forward. When generating a new cert care must be taken to ensure attackers have\r\nno foothold within the environment with which to compromise the new certificate. Only the incident response\r\nprocess can provide details regarding the scope of this issue and how to best address it.\r\nInterestingly the following compilation artifact was found within the CCleaner binary that Talos analyzed:\r\nS:\\workspace\\ccleaner\\branches\\v5.33\\bin\\CCleaner\\Release\\CCleaner.pdb\r\nGiven the presence of this compilation artifact as well as the fact that the binary was digitally signed using a valid\r\ncertificate issued to the software developer, it is likely that an external attacker compromised a portion of their\r\ndevelopment or build environment and leveraged that access to insert malware into the CCleaner build that was\r\nreleased and hosted by the organization. It is also possible that an insider with access to either the development or\r\nbuild environments within the organization intentionally included the malicious code or could have had an\r\naccount (or similar) compromised which allowed an attacker to include the code.\r\nIt is also important to note that while previous versions of the CCleaner installer are currently still available on the\r\ndownload server, the version containing the malicious payloads has been removed and is no longer available.\r\nMalware Installation and Operation\r\nWithin the 32-bit CCleaner v5.33 binary included with the legitimate CCleaner v5.33 installer,\r\n'__scrt_get_dyn_tls_init_callback' was modified to call to the code at CC_InfectionBase(0x0040102C). This was\r\ndone to redirect code execution flow within the CCleaner binary to the malicious code prior to continuing with the\r\nnormal CCleaner operations. The code that is called is responsible for decrypting data which contains the two\r\nstages of the malicious payload, a PIC (Position Independent Code) PE loader as well as a DLL file that\r\neffectively functions as the malware payload. The malware author had tried to reduce the detection of the\r\nmalicious DLL by ensuring the IMAGE_DOS_HEADER was zeroed out, suggesting this attacker was trying to\r\nremain under the radar to normal detection techniques.\r\nThe binary then creates an executable heap using HeapCreate(HEAP_CREATE_ENABLE_EXECUTE,0,0).\r\nSpace is then allocated to this new heap which is where the contents of the decrypted data containing the malware\r\nis copied. As the data is copied to the heap, the source data is erased. The PE loader is then called and begins its\r\noperation. Once the infection process has been initiated, the binary erases the memory regions that previously\r\ncontained the PE loader and the DLL file, frees the previously allocated memory, destroys the heap and continues\r\non with normal CCleaner operations.\r\nThe PE loader utilizes position independent coding practices in order to locate the DLL file within memory. It then\r\nmaps the DLL into executable memory, calls the DLLEntryPoint to begin execution of the DLL being loaded and\r\nthe CCleaner binary continues as normal. Once this occurs the malware begins its full execution, following the\r\nprocess outlined in the following sections.\r\nCBkrdr.dll\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 4 of 13\n\nThe DLL file (CBkdr.dll) was modified in an attempt to evade detection and had the IMAGE_DOS_HEADER\r\nzeroed out. The DLLEntryPoint creates an execution thread so that control can be returned to the loader. This\r\nthread is responsible for calling CCBkdr_GetShellcodeFromC2AndCall. It also sets up a Return Oriented\r\nProgramming (ROP) chain that is used to deallocate the memory associated with the DLL and exit the thread.\r\nCCBkrdr_GetShellcodeFromC2AndCall\r\nThis function is responsible for much of the malicious operations that Talos observed while analyzing this\r\nmalware. First, it records the current system time on the infected system. It then delays for 601 seconds before\r\ncontinuing operations, likely an attempt to evade automated analysis systems that are configured to execute\r\nsamples for a predefined period of time or determine whether the malware is being executed in a debugger. In\r\norder to implement this delay functionality, the malware calls a function which attempts to ping 224.0.0.0 using a\r\ndelay_in_seconds timeout set to 601 seconds. It then checks to determine the current system time to see if 600\r\nseconds has elapsed. If that condition is not met, the malware terminates execution while the CCleaner binary\r\ncontinues normal operations. In situations where the malware is unable to execute IcmpCreateFile, it then falls\r\nback to using Sleep() to implement the same delay functionality. The malware also compares the current system\r\ntime to the value stored in the following registry location:\r\nHKLM\\SOFTWARE\\Piriform\\Agomo:TCID\r\nIf the value stored in TCID is in the future, the malware will also terminate execution.\r\nFigure 3: Delay Routine\r\nThe malware then checks to determine the privileges assigned to the user running on the system. If the current\r\nuser running the malicious process is not an administrator the malware will terminate execution.\r\nFigure 4: Privilege Check\r\nIf the user executing the malware does have administrative privileges on the infected system, SeDebugPrivilege is\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 5 of 13\n\nenabled for the process. The malware then reads the value of 'InstallID' which is stored in the following registry\r\nlocation:\r\nHKLM\\SOFTWARE\\Piriform\\Agomo:MUID\r\nIf this value does not exist, the malware creates it using '((rand()*rand() ^ GetTickCount())'.\r\nOnce the aforementioned activities have been performed, the malware then begins profiling the system and\r\ngathering system information which is later transmitted to the C2 server. System information is stored in the\r\nfollowing data structure:\r\nFigure 5: CCBkdr_System_Information Data Structure\r\nOnce the system information has been collected, it is encrypted and then encoded using modified Base64. The\r\nmalware then establishes a Command and Control (C2) channel as described in the following section.\r\nCommand and Control (C2)\r\nWhile analyzing this malware, Talos identified what appears to be a software bug present in the malicious code\r\nrelated to the C2 function. The sample that Talos analyzed reads a DGA computed IP address located in the\r\nfollowing registry location, but currently does nothing with it:\r\nHKLM\\SOFTWARE\\Piriform\\Agomo:NID\r\nIt is unknown what the purpose of this IP address is at this time, as the malware does not appear to make use of it\r\nduring subsequent operations. In any event, once the previously mentioned system information has been collected\r\nand prepared for transmission to the C2 server, the malware will then attempt to transmit it using an HTTPS POST\r\nrequest to 216[.]126[.]225[.]148. The HTTPS communications leverage a hardcoded HTTP Host header that is set\r\nto speccy[.]piriform[.]com, a legitimate platform which is also created by Piriform for hardware monitoring. This\r\ncould make dynamic analysis more difficult as the domain would appear to be legitimate and perhaps even\r\nexpected depending on the victim infrastructure. The requests also leverage HTTPS but ignore all security errors\r\nas the server currently returns a self-signed SSL certificate that was issued to the subdomain defined in the Host\r\nheader field. In cases where no response is received from the C2 server, the malware then fails back to a Domain\r\nGeneration Algorithm (DGA) as described in the section 'Domain Generation Algorithm' of this post.\r\nOnce a C2 server has been identified for use by the malware, it then sends the encoded data containing system\r\nprofile information and stores the C2 IP address in the following registry location:\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 6 of 13\n\nHKLM\\SOFTWARE\\Piriform\\Agomo:NID\r\nThe malware then stores the value of the current system time plus two days into the following registry location:\r\nHKLM\\SOFTWARE\\Piriform\\Agomo:TCID\r\nData received from the C2 server is then validated to confirm that the received data is in the correct format for a\r\nCCBkdr_ShellCode_Payload structure. An example is shown below:\r\nFigure 6: CCBkdr_ShellCode_Payload Data Structure\r\nThe malware then confirms that the value of EncryptedInstallID matches the value that was previously transmitted\r\nto the C2 server. It then allocates memory for the final shellcode payload. The payload is then decoded using\r\nmodified Base64 and stored into the newly allocated memory region. It is then decrypted and called with the\r\naddresses of LoadLibraryA and GetProcAddress as parameters. Once the payload has been executed, the memory\r\nis deallocated and the following registry value is set to the current system time plus seven days:\r\nHKLM\\SOFTWARE\\Piriform\\Agomo:TCID\r\nThe received buffer is then zeroed out and deallocated. The CCBkdr_ShellCode_Payload structure is also\r\ndeallocated and the malware then continues with normal CCleaner operations. A diagram describing the high level\r\noperation of this malware is below:\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 7 of 13\n\nFigure 7: Malware Operation Process Flow\r\nDomain Generation Algorithm\r\nIn situations where the primary C2 server does not return a response to the HTTP POST request described in the\r\nprevious section, the malware fails back to using a DGA algorithm. The algorithm used by this malware is time-based and can be calculated using the values of year and month. A list of DGA domains is below:\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 8 of 13\n\nFigure 8: 12 Month DGA Genearation The malware will initiate DNS lookups for each domain generated by the\r\nDGA algorithm. If the DNS lookup does not result in the return of an IP address, this process will continue. The\r\nmalware will perform a DNS query of the active DGA domain and expects that two IP addresses will be returned\r\nfrom the name server managing the DGA domain's namespace. The malware will then compute a secondary C2\r\nserver by performing a series of bit operations on the returned IP address values and combine them to determine\r\nthe actual fallback C2 server address to use for subsequent C2 operations. A diagram showing this process is\r\nbelow:\r\nFigure 9: C2 Process Diagram\r\nCisco Talos observed during analysis that the DGA domains had not been registered, so we registered and\r\nsinkholed them to prevent attackers from being able to use them for malicious purposes.\r\nPotential Impact\r\nThe impact of this attack could be severe given the extremely high number of systems possibly affected. CCleaner\r\nclaims to have over 2 billion downloads worldwide as of November 2016 and is reportedly adding new users at a\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 9 of 13\n\nrate of 5 million a week.\r\nFigure 10: CCleaner Consumer Demographics\r\nIf even a small fraction of those systems were compromised an attacker could use them for any number of\r\nmalicious purposes. Affected systems need to be restored to a state before August 15, 2017 or reinstalled. Users\r\nshould also update to the latest available version of CCleaner to avoid infection. At the time of this writing that is\r\nversion 5.34. It is important to note that according to the CCleaner download page, the free version of CCleaner\r\ndoes not provide automated updates, so this might be a manual process for affected users.\r\nIn analyzing DNS-based telemetry data related to this attack, Talos identified a significant number of systems\r\nmaking DNS requests attempting to resolve the domains associated with the aforementioned DGA domains. As\r\nthese domains have never been registered, it is reasonable to conclude that the only conditions in which systems\r\nwould be attempting to resolve the IP addresses associated with them is if they had been impacted by this\r\nmalware. While most of the domains associated with this DGA have little to no request traffic associated with\r\nthem, the domains related to the months of August and September (which correlates with when this threat was\r\nactive in the wild) show significantly more activity.\r\nLooking at the DNS related activity observed by Cisco Umbrella for the month of July 2017 (prior to CCleaner\r\n5.33 being released) we observed very little in the way of DNS requests to resolve the IP address for DGA domain\r\nassociated with this malware:\r\nFigure 11: DNS Activity for July 2017 DGA Domain\r\nAs mentioned earlier in this post, the version of CCleaner that included this malware was released on August 15,\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 10 of 13\n\n2017. The following graph shows a significant increase in the amount of DNS activity associated with the DGA\r\ndomain used in August 2017:\r\nFigure 12: DNS Activity for August 2017 DGA Domain\r\nLikewise, the DGA domain associated with September 2017 reflects the following activity with regards to\r\nattempts to resolve the IP associated with it:\r\nFigure 13: DNS Activity for September 2017 DGA Domain\r\nNote that in on September 1, 2017 it appears that the DNS activity shifted from the DGA domain previously used\r\nin August, to the one used in September, which matches the time-based DGA algorithm described in the \"Domain\r\nGeneration Algorithm\" section of this blog post. After reaching out to Avast we noted that the server was taken\r\ndown and became unavailable to already infected systems. As a result, we saw a significant increase in the amount\r\nof requests that were being directed at the failback DGA domains used by the malware.\r\nFigure 14: Traffic Spike Following Server Takedown\r\nIt is also worth noting that at the time of this post, antivirus detection for this threat remains very low (The\r\ndetections are at 1/64 at the time of this writing).\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 11 of 13\n\nFigure 14: VirusTotal Detections for CCleaner Binary\r\nAs part of our response to this threat, Cisco Talos has released comprehensive coverage to protect customers.\r\nDetails related to this coverage can be found in the \"Coverage\" section of this post.\r\nConclusion\r\nThis is a prime example of the extent that attackers are willing to go through in their attempt to distribute malware\r\nto organizations and individuals around the world. By exploiting the trust relationship between software vendors\r\nand the users of their software, attackers can benefit from users' inherent trust in the files and web servers used to\r\ndistribute updates. In many organizations data received from commonly software vendors rarely receives the same\r\nlevel of scrutiny as that which is applied to what is perceived as untrusted sources. Attackers have shown that they\r\nare willing to leverage this trust to distribute malware while remaining undetected. Cisco Talos continues to\r\nmonitor all aspects of the threat landscape to quickly identify new and innovative techniques used by attackers to\r\ntarget organizations and individuals around the world.\r\nCoverage\r\nThe following ClamAV signatures have been released to detect this threat: 6336251, 6336252.\r\nAdditional ways our customers can detect and block this threat are listed below.\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 12 of 13\n\nAdvanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these\r\nthreat actors.\r\nCWS orWSA web scanning prevents access to malicious websites and detects malware used in these attacks.\r\nAMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.\r\nUmbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs,\r\nwhether users are on or off the corporate network.\r\nIndicators of Compromise (IOCs)\r\nFile Hashes\r\n6f7840c77f99049d788155c1351e1560b62b8ad18ad0e9adda8218b9f432f0a9\r\n1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff\r\n36b36ee9515e0a60629d2c722b006b33e543dce1c8c2611053e0651a0bfdb2e9\r\nDGA Domains\r\nab6d54340c1a[.]com\r\naba9a949bc1d[.]com\r\nab2da3d400c20[.]com\r\nab3520430c23[.]com\r\nab1c403220c27[.]com\r\nab1abad1d0c2a[.]com\r\nab8cee60c2d[.]com\r\nab1145b758c30[.]com\r\nab890e964c34[.]com\r\nab3d685a0c37[.]com\r\nab70a139cc3a[.]com\r\nIP Addresses  \r\n216[.]126[.]225[.]148\r\nSource: https://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nhttps://blog.talosintelligence.com/2017/09/avast-distributes-malware.html\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://blog.talosintelligence.com/2017/09/avast-distributes-malware.html"
	],
	"report_names": [
		"avast-distributes-malware.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434343,
	"ts_updated_at": 1775791228,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e8140b26b8ddad258e2cc72c9bff65ce0d086ccd.pdf",
		"text": "https://archive.orkl.eu/e8140b26b8ddad258e2cc72c9bff65ce0d086ccd.txt",
		"img": "https://archive.orkl.eu/e8140b26b8ddad258e2cc72c9bff65ce0d086ccd.jpg"
	}
}