{ "id": "db6a3f2b-d25f-4b0b-a8fe-9dbd1c62a5c9", "created_at": "2026-04-06T00:11:25.011026Z", "updated_at": "2026-04-10T03:32:15.058649Z", "deleted_at": null, "sha1_hash": "338d45f22da005d25da690adf8d0083d0df2a39d", "title": "Avast Threat Labs analysis of CCleaner incident", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 621664, "plain_text": "Avast Threat Labs analysis of CCleaner incident\r\nBy Threat Intelligence Team 22 Sep 2017\r\nArchived: 2026-04-05 17:48:43 UTC\r\nTechnical update and ongoing analysis of the APT security incident\r\nExperts at Avast Threat Labs have been analyzing the CCleaner advanced persistent threat (APT) continuously for\r\nthe past few days and apart from the information in recent blog posts (CCleaner and Avast posts),  we are starting\r\na series of technical blog posts describing  details and technical information that we encountered during our\r\nanalysis. Today, we will cover the ongoing analysis of the CnC server and the 2nd stage payload.\r\nJust 4 days of data?\r\nShortly after receiving the initial notification about the incident from Morphisec, we reached out to law\r\nenforcement agencies to help us take down the Command and Control (CnC) server and get access to its contents.\r\nWhile analyzing the data, we noticed that there were only a few days’ worth of data in the logs, and we wondered\r\nwhy? We knew the server was installed on July 31st so there had to be more than a month’s worth of data since\r\nthen:\r\nJul 31 06:32:53 seassdvz3.servercrate.com systemd[1]: Started First Boot Wizard.\r\nAlthough the server was up and running since the end of July, data gathering started on August 11\r\nth\r\n, in preparation\r\nof the release of the compromised CCleaner executable file:\r\nAug 11 07:36:52 seassdvz3 mariadb-prepare-db-dir[10729]: Initializing MySQL database\r\nAug 11 07:36:52 seassdvz3 mariadb-prepare-db-dir[10729]: Installing MariaDB/MySQL system tables in\r\n'/var/lib/mysql' ...\r\nThe database didn’t contain data older than September 12th, so we originally thought someone might have deleted\r\nthe data to avoid being traced, but then we found this log:\r\n170830 20:36:17 [Note] /usr/libexec/mysqld: ready for connections.\r\nVersion: '5.5.52-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server\r\n170910 8:47:40 InnoDB: Error: Write to file ./ibdata1 failed at offset 11 2854223872.\r\nInnoDB: 1048576 bytes should have been written, only 0 were written.\r\nInnoDB: Operating system error number 122.\r\nInnoDB: Check that your OS and file system support files of this size.\r\nInnoDB: Check also that the disk is not full or a disk quota exceeded.\r\nInnoDB: Error number 122 means 'Disk quota exceeded'.\r\nhttps://blog.avast.com/avast-threat-labs-analysis-of-ccleaner-incident\r\nPage 1 of 8\n\nThe MariaDB (fork of MySQL) database—which stored the data acquired by the backdoor—ran out of disk space.\r\nNot coincidentally, there was a connection to the machine just a few hours after the database died:\r\nroot pts/0 Sun Sep 10 20:59 - 23:34 (02:34) 124-144-xxx-xxx.rev.home.ne.jp\r\n(actual address was redacted)\r\nThe user behind this connection came to free up some disk space. He (or she) started by erasing all the logs in the\r\nhope that this would quickly fix the issue, but the logs show the database also encountered some serious issues\r\nand was corrupted:\r\n170910 8:47:43 [ERROR] mysqld got signal 6 ;\r\nTwo days later, another connection was made, and this time, the attacker decided to resurrect the database by a\r\ncomplete reinstall:\r\nSep 12 07:56:13 Erased: 1:mariadb-server-5.5.52-1.el7.x86_64\r\nSep 12 07:56:13 Erased: 1:mariadb-5.5.52-1.el7.x86_64\r\nSep 12 08:02:43 Installed: 1:mariadb-5.5.52-1.el7.x86_64\r\nSep 12 08:02:44 Installed: 1:mariadb-server-5.5.52-1.el7.x86_64\r\nIt is unfortunate that the server was a low-end machine with limited disk capacity, because if weren’t for this (just\r\n5 days before we took the server down), we would likely have a much clearer picture of exactly who was affected\r\nby the attack as the entire database would have been intact from the initial launch date.\r\nWhere did the attackers come from?\r\nTo figure out who the attackers were, we looked for any breadcrumbs the attackers might have left for us to\r\nfollow. As Costin Raiu pointed out on Twitter (https://twitter.com/craiu/status/910148928796061696), there are\r\nsome striking similarities between the code injected into CCleaner and APT17/Aurora malware created by a\r\nChinese APT group in 2014/2015.\r\nIndeed, the similarity between the code linked to group APT17 and the recent payload is quite high. Some of the\r\nfunctions are almost identical (e.g. the base64 encoding function on the following image) while other functions\r\nhave a partial match, but the structure is overall very similar.\r\nhttps://blog.avast.com/avast-threat-labs-analysis-of-ccleaner-incident\r\nPage 2 of 8\n\nNext, we looked at where the attacker was connecting from to the CnC server.\r\nroot pts/0 Tue Sep 12 18:11 - 18:50 (00:39) xxxx.ap.so-net.ne.jp\r\nroot pts/0 Tue Sep 12 09:23 - 14:14 (04:51) xxxxx.bbtec.net\r\nroot pts/0 Sun Sep 10 20:59 - 23:34 (02:34) 124-144-xxx-xxx.rev.home.ne.jp\r\n(+ other 32 connections)\r\nInterestingly enough, most of the connections came from Japanese networks. Although these addresses are likely\r\njust infected PCs and servers used as proxies, it suggests that the attackers might be familiar with Asian networks.\r\nThe list of targeted companies contained quite a few Asian companies but none from China. Lastly, the time zone\r\nin the PHP scripts feeding the database were set to PRC (People’s Republic of China) although the system clock is\r\nin UTC.\r\nEven with all of these clues, it is impossible at this stage to claim which country the attack originated from, simply\r\nbecause all of the data points could easily be forged to hide the true location of the perpetrator. \r\nTargeted companies - South Korea or Slovakia?\r\nIn addition to the domain names of targeted companies already published, there were four more domains\r\nbelonging to two more companies that haven’t been mentioned publicly (we don’t want to disclose the names of\r\nhttps://blog.avast.com/avast-threat-labs-analysis-of-ccleaner-incident\r\nPage 3 of 8\n\nthese companies as they were potentially subjected to the attack). These domains were commented out in the\r\nscripts, which can indicate the list of targeted companies had changed repeatedly over time. This is further\r\nsupported by the fact that some of the 20 computers that we know received the 2nd stage payload were in domains\r\nthat were also not included in the original list.\r\nAs a side note, the attackers seem to have made a mistake with the domain name of one company specified as\r\n“\u003ccompany\u003e.sk”. We suppose they wanted to target the South Korean users (i.e. the headquarters), but the domain\r\n.sk actually belongs to the Slovak Republic so they were unknowingly trying to infect users from the Slovakian\r\nbranch of the company!\r\nMatryoshkas\r\nEver heard of the Russian nesting doll Matryoshka? It’s a set of dolls of decreasing size placed one inside another,\r\nand while analyzing the 2nd stage payload binary, we had a sense of playing with Matryoshkas ourselves as there\r\nwere multiple levels of indirection that we had to go through.\r\nThe backdoor in CCleaner called home to receive the second stage payload which we found in the server dump\r\nunder the name GeeSetup_x86.dll.\r\nOpening the first Matryoshka, we see two more containing 32- and 64-bit payloads, each of which piggybacked\r\non a different legitimate binary along with additional malware for the appropriate architecture. The 32-bit version\r\nused patched TSMSISrv.dll which originally is a VirtCDRDrv32.dll created by Corel. The 64-bit version used a\r\npatched EFACli64.dll originally developed by Symantec. The 2nd stage is illustrated in the next figure:\r\nhttps://blog.avast.com/avast-threat-labs-analysis-of-ccleaner-incident\r\nPage 4 of 8\n\nWhen the DLLs were loaded, they saved the embedded malware into the registry and used elaborate tactics to\r\nextract the registry loader routine and run it. This procedure is described in the following section.\r\nHacked CRT\r\nOne way to show how sophisticated the attackers were is to look at the way they modified the C runtime (CRT).\r\nWe will demonstrate this on the 64-bit version. CRT is a piece of code that contains important functions needed\r\nfor the program to run. The modified CRT code can be found in the second stage payload which is embedded in\r\nthe original Symantec code. The modifications are performed by adding a few instructions to the function\r\n__security_init_cookie which is ironically responsible for securing the code from buffer overflows—the well-known “canary”. The added instructions change the _pRawDllMain function pointer to point to the special\r\nfunction that extracts a hidden registry payload loader. The following figure explains the functionality behind the\r\n_pRawDllMain.\r\nhttps://blog.avast.com/avast-threat-labs-analysis-of-ccleaner-incident\r\nPage 5 of 8\n\nThere is an added jump and a few instructions at the end of CRT function __security_init_cookie.\r\nThe attackers found a nice way to hide the loader within the second stage. There are just a few bytes woven into\r\neach padding which is commonly put in place by a compiler between function code. The following figure shows\r\nthe difference between the original file by Symantec (left) and the weaponized one (right):\r\nThe (not so good) kill switch\r\nMany of you may have heard about the WannaCry ransomware and its weak spot called the kill switch. The good\r\nnews in our case is that one of the payloads delivered by the backdoored CCleaner also contains a code\r\nmechanism similar to a kill switch. The bad news is that it is not as powerful as a kill switch in a WannaCry\r\nattack, i.e. no silver bullet.\r\nThe most important outcome of the analysis is definitely the discovery of a kill switch. More details about this\r\nfinding: The second stage payload checks for the presence of a file %TEMP%\\spf. If the file exists, the payload\r\nhttps://blog.avast.com/avast-threat-labs-analysis-of-ccleaner-incident\r\nPage 6 of 8\n\nwill terminate.\r\nAs you may notice from the code above, this payload is running in an endless loop. Within this loop, the payload\r\ntries to communicate with one of its CnC servers. The previously described kill-switch can be used to exit the loop\r\nand thus the whole program. In other words, this will prevent any other connections to the CnC server. Sadly, the\r\nkill-switch is checked after a communication attempt is made, so if the server responded, the user has already\r\nreceived and ran the second stage payload which renders the kill-switch almost useless.\r\nGetting to Stage Three\r\nSimilar to the first stage payload, the second stage also relies on communication with CnC servers. However, there\r\nis no hardcoded IP address nor any DGA (domain generation algorithm) like there was in the former payload.\r\nInstead, there are three different approaches to retrieve the CnC IP address and one of them is picked randomly\r\neach time by the algorithm.  The three approaches are:\r\n1. Via a hidden message stored in user profile details on a GitHub page (this doesn’t exist anymore; it was\r\nprobably deleted after the attackers realized something was going on). The URL string is parsed by payload\r\nin the reply from GitHub and by using simple binary operations. The result is an IP address of another\r\nCnC, which the payload uses for communication over TCP port 443 (usually HTTPS). In other code parts,\r\nthere is also a UDP communication over port 53, which mimics DNS protocol.\r\nhttps://blog.avast.com/avast-threat-labs-analysis-of-ccleaner-incident\r\nPage 7 of 8\n\n2. Alternatively to approach 1, it also tries to retrieve an IP address from a WordPress-hosted page. Once\r\nagain, this web page is not active at the moment so the payload is unable to retrieve any information from\r\nit.\r\n3. Finally, there is a third way to get a CnC IP address and it is very similar to the approach used in the DGA\r\nof the first payload. It tries to read DNS records for a domain “get.adxxxxxx.net” (exact domain name\r\nredacted). It requires at least two IP addresses from which it computes the target CnC address.\r\nTo illustrate the algorithm, we demonstrate how it would work for the avast.com domain and its two IP addresses\r\n77.234.43.52 and 77.234.45.78.\r\nAt first the IP addresses are represented as hexadecimal numbers:\r\n77.234.43.52 = 4D EA 2B 34\r\n77.234.45.78 = 4D EA 2D 4E\r\nThen the bytes of these numbers are XORed together:\r\n4D EA 2B 34 = /xor/ = C1 79\r\n4D EA 2D 4E = /xor/ = C7 03\r\nThese four bytes are grouped together forming four octets of the CnC address\r\nC1 79 C7 03. (Note: we omit displaying the resulting IP address because this was only an illustrative example\r\nusing the avast.com domain). In the case of the get.adxxxxx.net domain, there are no IP addresses registered to\r\nthis domain right now, thus the algorithm is once again not working and no CnC IP address is served at the time of\r\nwriting this article.\r\nAs you can see, none of these three methods is able to retrieve the CnC IP address at this moment. If it could\r\nretrieve the CnC IP address, however, it would start a bidirectional socket-based communication with the CnC. It\r\nwill once again upload some information (computer name, volume serial number of system drive, installed OS,\r\netc.) about the victims of the attack. More importantly this second stage payload is capable of retrieving and\r\nexecuting additional code from the CnC - the 3rd stage payload.\r\nNext steps\r\nOur investigation and hunt for the perpetrators continues. In the meantime, we advise users who downloaded the\r\naffected version to upgrade to the latest version of CCleaner and perform a scan of their computer with a good\r\nsecurity software, to ensure no other threats are lurking on their PC.\r\nThe companies who we believe were introduced to the second stage payload were notified. If there are any other\r\ncompanies who believe they encountered this malware, please contact us through our legal department at\r\nlegal@avast.com.\r\nSource: https://blog.avast.com/avast-threat-labs-analysis-of-ccleaner-incident\r\nhttps://blog.avast.com/avast-threat-labs-analysis-of-ccleaner-incident\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia" ], "references": [ "https://blog.avast.com/avast-threat-labs-analysis-of-ccleaner-incident" ], "report_names": [ "avast-threat-labs-analysis-of-ccleaner-incident" ], "threat_actors": [ { "id": "2150d1ac-edf0-46d4-a78a-a8899e45b2b5", "created_at": "2022-10-25T15:50:23.269339Z", "updated_at": "2026-04-10T02:00:05.402835Z", "deleted_at": null, "main_name": "APT17", "aliases": [ "APT17", "Deputy Dog" ], "source_name": "MITRE:APT17", "tools": [ "BLACKCOFFEE" ], "source_id": "MITRE", "reports": null }, { "id": "a7aefdda-98f1-4790-a32d-14cc99de2d60", "created_at": "2023-01-06T13:46:38.281844Z", "updated_at": "2026-04-10T02:00:02.909711Z", "deleted_at": null, "main_name": "APT17", "aliases": [ "BRONZE KEYSTONE", "G0025", "Group 72", "G0001", "HELIUM", "Heart Typhoon", "Group 8", "AURORA PANDA", "Hidden Lynx", "Tailgater Team" ], "source_name": "MISPGALAXY:APT17", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "ee39ecf0-d311-49e5-b0ae-3e3d71f71def", "created_at": "2025-08-07T02:03:24.626625Z", "updated_at": "2026-04-10T02:00:03.605175Z", "deleted_at": null, "main_name": "BRONZE KEYSTONE", "aliases": [ "APT17 ", "Aurora Panda ", "DeputyDog ", "Group 72 ", "Hidden Lynx ", "TG-8153 ", "Tailgater Team" ], "source_name": "Secureworks:BRONZE KEYSTONE", "tools": [ "9002", "BlackCoffee", "DeputyDog", "Derusbi", "Gh0stHTTPSDropper", "HiKit", "InternalCMD", "PlugX", "PoisonIvy", "ZxShell" ], "source_id": "Secureworks", "reports": null } ], "ts_created_at": 1775434285, "ts_updated_at": 1775791935, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/338d45f22da005d25da690adf8d0083d0df2a39d.pdf", "text": "https://archive.orkl.eu/338d45f22da005d25da690adf8d0083d0df2a39d.txt", "img": "https://archive.orkl.eu/338d45f22da005d25da690adf8d0083d0df2a39d.jpg" } }