A database that allowed hackers to monitor systems infected through a maliciously modified CCleaner installer was erased on September 12, Avast has discovered.
The MariaDB (fork of MySQL) database had been created on August 11, in preparation for the release of a backdoored CCleaner installer, but ran out of space. Coupled with the corruption of the database, the lack of space on the server resulted in the attackers erasing it entirely, the security researchers have discovered.
The attack on the popular Windows maintenance tool started in early July, before Avast purchased Piriform, the maker of CCleaner. Hackers managed to infiltrate the company’s systems and modify the 32-bit CCleaner v5.33.6162 and CCleaner Cloud v1.07.3191 releases to add backdoor code to them.
The code was designed to collect user information and send it to an attacker-controlled server, which was taken down on Sept. 15. The incident resulted in 2.27 million users downloading the infected CCleaner variants between Aug. 15 and Sept. 12, when the compromise was discovered.
The attack proved to be sophisticated and highly targeted rather than just a supply chain incident. The attackers had the ability to control which machines to be served a heavily obfuscated Stage 2 payload that packs various anti-debugging and anti-emulation capabilities.
The security researchers investigating the incident have discovered on the command and control (C&C) server a database containing information on the number of infected machines. It revealed that 700,000 machines reported to the C&C server between Sept. 12 and Sept. 16, and that the secondary payload had been delivered to at least 20 of them, affecting 8 organizations worldwide.
Avast now says that a database containing information on the machines that reported to the C&C before Sept. 12 was erased because it was stored on a low-end server that ran out of space. The attackers apparently attempted to fix the issue on Sept. 10, but decided to completely erase the database two days later, after discovering it was corrupted.
“It is unfortunate that the server was a low-end machine with limited disk capacity, because if weren’t for this (just 5 days before we took the server down), we would likely have a much clearer picture of exactly who was affected by the attack as the entire database would have been intact from the initial launch date,” Avast notes.
The security researchers also discovered that a Stage 3 payload might have been involved in the incident as well. The second-stage payload was designed to contact another C&C server, send some information on the infected machine, and retrieve and execute additional code from the server.
The Stage 2 payload uses the GeeSetup_x86.dll installer, which can fetch different malware depending on the infected system’s architecture. The embedded malware is saved into registry and elaborate tactics are used to extract the registry loader routine and run it, the researchers say.
On x64 systems, the attackers modified the C runtime (CRT) by adding a few instructions to the function __security_init_cookie, responsible for securing the code from buffer overflows. They added instructions to have the _pRawDllMain function pointer link to the special function that extracts a hidden registry payload loader.
The researchers also discovered that a kill switch was included in the second-stage payload as well, but that it was triggered only after infection. Specifically, when executed, the payload checks the presence of a file %TEMP%spf and terminates execution if the file exists.
The payload was also designed to retrieve the C&C IP address through one of three approaches: a GitHub page, a WordPress-hosted page, or by reading DNS records for an unnamed domain. During its investigation, Avast discovered that the GitHub and WordPress pages no longer exist, and that the unnamed domain doesn’t have an IP addresses registered to it. Thus, communication with the second C&C wasn’t possible and a Stage 3 payload couldn’t be delivered.