What is it? Supply-Chain Malware
What has been affected? CCleaner v5.33.6162 | CCleaner Cloud v1.07.3191 (32-bit version) | Payload 2
What does it do?
The second part of the payload in the CCleaner infection was delivered to a specific list of computers based on local domain names. The predefined list used in the configuration of the C&C(Command and Control) server was designed to find computers inside the networks of major technology companies, like Google, Microsoft, Cisco, Samsung, Intel, and much more, and eventually deliver the second payload. Researchers at Talos (Cisco cyber threat intel), have confirmed that at least 20 machines were infected with this secondary payload, even though Piriform initially stated that none of its customers were affected by this second payload. Kaspersky researchers have claimed that the malware samples have code similarities to a Chinese affiliated APT known as Group 72.
How does it do it?
A series of PHP files were discovered on the attackers C2 (Command and Control) server. A symlink, which is used to make a symbolic link in PHP, was used to redirect all regular traffic that was requesting ‘index.php’, to the ‘x.php’ file (this contained the malicious PHP script). The C2 server initiated a series of checks to determine if it should proceed with standard operations or redirect to the legitimate Piriform website.
The malicious PHP script compares the infected system that is calling to the C2 server with three values; $DomainList, $IPList, and $HostList. These checks are to determine whether or not the infected system should have the Stage 2 payload delivered.
The stage 2 installer is named “GeeSetup_x86.dll”, this installer identifies the OS version on the system, and drops either a 32-bit or 64-bit version of the trojan. The 32-bit version uses a trojanized TSMSISrv.dill, which drops VirtCDRDrv, this is the filename of a legitimate executable used by Corel(digital drawing suite). The 64-bit version drops a trojanized EFACli64.dll named SymEFA, which is a filename used by Symantec Endpoint, none of the files dropped are signed.
Using a trojanized binary, attackers can decode and execute a PE (Portable Executable) in the register, this PE performs queries to the C2 servers and executes in-memory PE files. This method makes detection by researchers more difficult, this is because the executable files are never stored on the file system, and are just run through memory.
An encoded PE is put into the following registries:
Kaspersky researchers say that the malware samples examined from the CCleaner infections have code similarities to a threat group known as Group 72. The group has been dubbed a number of aliases; Deep Panda, Axiom, and Shell_Crew, but have been suspected of ties to the Chinese government.
Researchers at Avast were able to find kill switch to the malware that would work in certain instances. The second stage of the payload checks for a file “%TEMP%\spf”, if this file is found on the system the payload will terminate itself.
The payload runs in an endless loop, it attempts to communicate with the C2 server, the kill switch can be used to exit this loop. The kill switch is checked after a communication attempt is made, so if the server responds to the request the user has already run the second stage payload which means the kill switch won’t work.
Piriform’s original statement to its customers was that no customers of the company had been infected with the second stage of the malware. Cisco’s Talos team later confirmed that at least 20 users were infected with the second stage. This is a good example of how companies need to keep up-to-date backups to re-image systems after a compromise. They should always treat a vulnerability in third-party vendors with utmost importance.
Initial examinations of the infections didn’t reveal the full motivation or complexity of the attacks. In-depth research proved that a targeted attack was what the attackers were after, and this proves to be much more dangerous.
Avast found evidence that attackers initially had trouble with their command and control server. The server was up and running in July, then data gathering started on August 11, but the database didn’t contain data older than September 12. Researchers say the MariaDB database ran out of disk space, even after a user connected and try to free up space on the database, the logs show that the DB experienced major issues. On September 12 a user logged into the server and did a complete reinstall of the database.