CCleaner forensics

Rédigé par Nathanael Ndong - 20/06/2022 - dans CSIRT - Téléchargement
During a ransomware attack, right after the ransomware was launched, we noticed the use of CCleaner as an anti-forensic tool to cover the attacker’s action. The following article aims to explore some key features of this tool from a forensic perspective. We will see how to identify the items that have been deleted and how they could be recovered. We focused on the free desktop version v6.00.9727.

CCleaner belongs to a suite of cleaning and optimization tools developed by Piriform. The utility is able to delete files, registry keys and many others items in order to make the computer more efficient (let’s hope so).

The tool is highly configurable as we can see in the main screen. Its capabilities are divided into two categories of items:

  • Windows class, which mainly consists of built-in items of the Windows system including Windows event logs, temporary files, DNS cache, registry hives and many other system metadata.
  • Applications class, which includes all metadata associated with the applications installed on the system, including data compression applications, the non-native web browsers, etc. Globally all the non-native built-in applications.

Each element can be selected independently of the others to provide more granularity. So we decide to dig into its functioning to understand how an attacker can take advantage of such tool. Specifically, we try to answer the following questions:

  • Is it possible identify items that have been cleaned ?
  • Are these items recoverable ?

Previous research

Thankfully the subject has already been widely covered. In this article, the author investigates the capabilities of a similar tool CleanAfterMe. As CCleaner is more widespread, our research led us to another article where the author used Process Monitor to develop a regripper plugin to retrieve CCleaner installation and settings information.

CCleaner working

As mentioned in this SANS blog post, CCleaner used to store the configuration of cleaned items inside the registry hive, but now it is stored in .INI files embedded inside the binary instead. After digging into the documentation of the editor's website, Piriform, we found a command  to retrieve the configuration files from the command line: CCleaner.exe /EXPORT.

This command will generate 3 configurations files under C:\Program Files\CCleaner : Winapp.ini, Winreg.ini and Winsys.ini.

All these files have attributes with the following structure:

  • [Application], the name of the reference or the application.
  • LangSecRef, a four-digit number that indicates the item’s category (Applications, Utilities, Windows...etc.).
  • Detect, a registry key that detects the existence of the program on the system.
  • DetectFile, a path or a file which detects the existence of the program on the system.
  • Default, a boolean value which seem to indicate items selected by default (True) or cleared (false).
  • FileKeyX, the file to delete.
  • RegKeyX, the key to delete.

In the last two items, the X represents a number in case of multiple files and/or keys to delete.

Each configuration file corresponds to an item type:

  • The Winapp.ini file contains a list of desktop applications (web browser, data compression software...) with elements that could be deleted. The utility detects the presence of the software either with the executable file or a specific configuration file or a registry key. Currently, 476 entries are listed in this configuration file. An example of one of these entries with Windows Defender where both the executable and the corresponding key are checked out (note: this give a good reference set for DFIR people :). Then CCleaner scans the disk and removes the corresponding logs files :
[Windows Defender]
Detect=HKLM\SOFTWARE\Microsoft\Windows Defender
DetectFile=%ProgramFiles%\Microsoft AntiSpyware\GIANTAntiSpywareMain.exe
FileKey1=%CommonAppData%\Microsoft\Windows Defender\Scans\History\Results\Quick|*.*
FileKey2=%CommonAppData%\Microsoft\Windows Defender\Scans\History\Results\Resource|*.*
FileKey3=%CommonAppData%\Microsoft\Windows Defender\Support|*.log
FileKey4=%ProgramFiles%\Microsoft AntiSpyware|errors.log;tracksEraser.log;cleaner.log
  • The Winsys.ini contains system references of recently typeds urls, runmru, network usage and several others related items to built-in applications and metadata system. Currently this file contains 62 entries. We noticed the use of SpecialDetect and SpecialKeyX which seem to correspond to a set of variables directly embedded into the binary and not available with the exported configuration file. Here is an example of an entry in this file with Edge Chromium Session :

[Edge Chromium - Session]
  • The Winreg.ini files contains a set of references to registry, including applications, installer, mui cache, windows service, applications paths, run at startup and many others which can be deleted. Actually the file contains 15 entries and use the type of special variable reference like in the Winsys.ini file.

When a new application is installed on the system, if this new application matches with an entry in the configuration file, the application is automatically added to the GUI interface. We observe such behavior after installing 7-Zip and Winrar utilities for example.

Now we have the list of items that can be cleaned, except for a few special references that still give us a rough indication of corresponding items. We try to find out how to know which items have been selected. Our first attempt was the search for logs files. At runtime, we notice the possibility to display the list of all items involved in the cleaning.

In the example above we can see a complete list and the corresponding size of cookies deleted from Firefox. This may indicate the existence of a log file somewhere. The analysis of file system before and after execution highlighted the deletion of several files. However we found no evidence of any file that could correspond to a log file. So we ran numerous tests with Process Monitor to observe the different operations performed by the tool. The tests revealed various operations with a specific registry key (discussed later). As we were focus on file operations, we notice the presence of a file CC7FD93.tmp (filename varies) inside the folder C:\Users\<username>\AppData\Local\Temp\ which was renamed and deleted after the execution.

"03:07:19,0214890","CCleaner64.exe","8596","WriteFile","C:\Users\Nath\AppData\Local\Temp\CC7D93.tmp","SUCCESS","Offset: 12 710, Length: 59"
"03:07:19,0217212","CCleaner64.exe","8596","CreateFile","C:\Users\Nath\AppData\Local\Temp\CC7D93.tmp","SUCCESS","Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened"
"03:07:19,0217385","CCleaner64.exe","8596","QueryAttributeTagFile","C:\Users\Nath\AppData\Local\Temp\CC7D93.tmp","SUCCESS","Attributes: A, ReparseTag: 0x0"
"03:07:19,0218106","CCleaner64.exe","8596","QueryStandardInformationFile","C:\Users\Nath\AppData\Local\Temp\CC7D93.tmp","SUCCESS","AllocationSize: 16 384, EndOfFile: 12 853, NumberOfLinks: 1, DeletePending: False, Directory: False"
"03:07:19,0218214","CCleaner64.exe","8596","QueryStreamInformationFile","C:\Users\Nath\AppData\Local\Temp\CC7D93.tmp","SUCCESS","0: ::$DATA"
"03:07:19,0218299","CCleaner64.exe","8596","QueryBasicInformationFile","C:\Users\Nath\AppData\Local\Temp\CC7D93.tmp","SUCCESS","CreationTime: 16/05/2022 03:07:19, LastAccessTime: 16/05/2022 03:07:19, LastWriteTime: 16/05/2022 03:07:19, ChangeTime: 16/05/2022 03:07:19, FileAttributes: A"
"03:07:19,0239150","CCleaner64.exe","8596","QueryBasicInformationFile","C:\Users\Nath\AppData\Local\Temp\CC7D93.tmp","SUCCESS","CreationTime: 16/05/2022 03:07:19, LastAccessTime: 16/05/2022 03:07:19, LastWriteTime: 16/05/2022 03:07:19, ChangeTime: 16/05/2022 03:07:19, FileAttributes: A"
"03:07:19,0240841","CCleaner64.exe","8596","SetRenameInformationFile","C:\Users\Nath\AppData\Local\Temp\CC7D93.tmp","SUCCESS","ReplaceIfExists: False, FileName: C:\Users\Nath\AppData\Local\Temp\ZZZZZZ.ZZZ"

Among all the temporary files generated, it was the only one to be renamed and deleted at the end of each execution. During the execution time, the file was locked and deleted right after. We did not manage to catch it with the usual methods : suspending the process and thread, memory dump after the execution... The likelihood of recovering such a file after an incident is low and we need a more reliable way to find selected items. The structure of the configuration files, especially the “Default” field give us a clue we will explore in the next section.

As mentioned earlier, we noticed many registry operations on a particular key : HKCU\Software\Piriform\CCleaner\. The exploration of this key inside the NTUSER.DAT hive gave us a good deal of interesting information. First of all, the value name field containeds many entries starting with the prefix (App). All those entries match with items that can be selected in the GUI.

The data field with the value "True" seems to correspond to the selected items. The value of the field “Last Write Timestamp” is consistent with the execution time.

After performing many tests and selecting more items, we noticed an increase in the value of the "values" field, from 55 to 81 inside the registry key.

All these new entries in the field "data" with the value “True” matched with selected items. It seems that if all items of Firefox are not selected they won’t be present in the registry key. We also noticed a new entry LTR that appears after several runs. We didn’t figure out its purpose, we just found that its value corresponds to the value of the “Last Write Timestamp” with the time adjusted to the computer’s timezone. And unlike to the previous value of “Last Write Timestamp” which corresponds to the execution time, the new value is shifted by few minutes. Despite the shift, it is a good starting point for an investigation to search through files system, event log and others artifacts evidence of deletion.

Evidence of execution and deletion

As the tool is very powerful and allows you to select many items to be deleted, we decided to focus on the deletion of EventLog, Registry Keys, Prefetch and browser artifacts. The first three are likely the most interesting items to remove for an attacker who wants to cover his tracks. This allows us to focus our search on a smaller set of items to look for in this article. We also decided to limit ourselves to looking at these same artifacts as well as the Master File Table and the USN Journal for execution and deletion traces. The article in the next section will cover both executions and deletions of each selected elements.

Event Log

By default, during the installation, CCleaner creates a shortcut available in Microsoft-Windows-Shell-Core/Operational with EventID 28115:

Event Id 28115
Provider Microsoft-Windows-Shell-Core
Channel Microsoft-Windows-Shell-Core/Operational
Map Description Shortcut creation log after program installation
Payload Data1 AppID:
Payload {"EventData":{"Data":[{"@Name":"Name","#text":"CCleaner Homepage"},{"@Name":"AppID","#text":""},{"@Name":"Flags","#text":"544"}]}

Event Id 28115
Provider Microsoft-Windows-Shell-Core
Channel Microsoft-Windows-Shell-Core/Operational
Map Description Shortcut creation log after program installation
Payload Data1 AppID: {6D809377-6AF0-444B-8957-A3773F02200E}\CCleaner\CCleaner64.exe
Payload {"EventData":{"Data":[{"@Name":"Name","#text":"CCleaner"},{"@Name":"AppID","#text":"{6D809377-6AF0-444B-8957-A3773F02200E}\\CCleaner\\CCleaner64.exe"},{"@Name":"Flags","#text":"32816"}]}}

Event Id 28115
Provider Microsoft-Windows-Shell-Core
Channel Microsoft-Windows-Shell-Core/Operational
Map Description Shortcut creation log after program installation
Payload Data1 AppID:
Payload {"EventData":{"Data":[{"@Name":"Name","#text":"CCleaner"},{"@Name":"AppID","#text":"{6D809377-6AF0-444B-8957-A3773F02200E}\\CCleaner\\CCleaner64.exe"},{"@Name":"Flags","#text":"16"}]}}

At installation time, shortcuts are optional, so this event is not 100% reliable in determining the installation of the utility.

At execution time, the following event with is written with no further information :

Event Id	916
Provider	ESENT
Channel 	Application
Payload 	{"EventData":{"Data":"CCleaner64, 8,G,98, EseDiskFlushConsistency, ESENT, 0x800000","Binary":""}}

The deletion of Windows Event Log results in the following common events :

Event Id	1102
Provider	Microsoft-Windows-Eventlog
Channel 	Security
Map Description	 Event log cleared
Payload 	{{"UserData":{"LogFileCleared":{"SubjectUserSid":"S-1-5-21-856292604-1411310282-3852757162-1001","SubjectUserName":"<username>","SubjectDomainName":"DESKTOP-E1D1PGI","SubjectLogonId":"0x22E42"}}}

Event Id	104
Provider	Microsoft-Windows-Eventlog
Channel 	System
Map Description	 Event log cleared
Payload 	{"UserData":{"LogFileCleared":{"SubjectUserName":"<username>","SubjectDomainName":"DESKTOP-E1D1PGI","Channel":"System","BackupPath":""}}}

Event Id	104
Provider	Microsoft-Windows-Eventlog
Channel 	System
Map Description	 Event log cleared
Payload 	{"UserData":{"LogFileCleared":{"SubjectUserName":"<username>","SubjectDomainName":"DESKTOP-E1D1PGI","Channel":"Windows PowerShell","BackupPath":""}}}

These events provide us with two main piece of information:

  • the cleared Event Log (Security and System), information that is not available inside the configuration file.
  • the associated timestamps match with the time of execution of the utility.

The Windows Event Log provide us reliable information in the case of logs deletions. From a forensic perspective, the Security Log is one of the most valuable source of information and to know the clearing period could give clues about incident timeline. Moreover, even if the Security Log is cleared, other logs (eg: RDP) are still available and could be another source of information about attacker’s presence.


At installation's time, running regripper on all hives gives us trace of the utility in the following entries in the NTUSER.DAT hive:

  • appcompatflags, with both the installer and the utility. Unfortunately the associated timestamp is not reliable.
  • Jumplistdata contains the trace of installer with the associated installation timestamps.
  • Run contains the trace of /MONITOR command line use by the utility when running in background with the associated installation timestamps.
  • Shc contains the trace of the shortcut create during the installation of the utility. The timestamp associated is close to the installation time.
  • UserAssist contains a trace of the utility with the associated installation timestamp.

At runtime, running regripper on all hives reveals the following entries in the SOFTWARE hive:

  • Apppaths contains a trace of the utility with no reliable timestamp.
  • Taskcache contains a task “CCleanerSkipUAC - <Username>, with a timestamp close to the execution's time ( with 5 minutes shift from the installation). This task is used to silently launch the utility in background.
  • Tasks contains a “\CCleaner Update” task without a reliable timestamp. This task is used to periodically check software updates.
  • Uninstall contains a trace of the utility with his version. The associated timestamp corresponds to the installation's time.

As mentioned earlier, the utility creates an entry in the NTUSER.DAT hive. The hive is opened in Registry Explorer to closely examine what happens in the case of deletion. We notice several things :

  • The Last Write Timestamp gives us the time of execution only if the hive is combined with the transaction hive.
  • As seen previously we have the list of selected element during execution.
  • There is no trace inside the timestamp of the applications concerned of deletion. We took the example of the Winrar application, we manually explored with Registry Explorer the associated key in the application and we executed regripper to find out trace of the key mentioned in the configuration files :
Configuration file :

Regripper output :
winrar v.20200526
(NTUSER.DAT) Get WinRAR\ArcHistory entries
Software\WinRAR\ArcHistory not found.

We found no trace of deleted keys with regripper and Registry Explorer.


At installation and execution time, we have evidence of the utility with the corresponding timestamp of each time. We found a specific case where timestamps were not reliable. If the deletion is not executed when the utility is launched, the associated timestamp will be the launch timestamp, not the deletion timestamp. As we don’t have the time of running, it would be necessary to start investigation from that point (i.e timestamp reference).

We didn’t successfully observe the deletion of prefetch files because of the way the utility process them. It processes only old prefetch files, in general those which haven’t been used for a period of time. From a forensic perspective this is valuable because that means Pretetch might still contain evidence of suspicious execution.

Master File Table and USN Journal

We decide to group both artifacts to make it easier to follow and understand.

At installation time, we noticed the creation of corresponding directory, \Program Files\CCleaner, in both artifacts, following by scheduled task \Windows\System32\Tasks\CCleanerSkipUAC - <username> (use to launch CCleaner without UAC) and shortcut with installation timestamp.
In the case of file deletions we can apply a filter on Last Modification macb timestamp and observe many files that aren’t marked as used in MFT(orphan). Those files could be compared with the beginning of the massive file deletion and overwritten in USN journal to confirm both the list of deleted files and the execution times.


In the previous section we saw what traces the utility left behind at installation and execution time, and during item’s deletion. Now that we have a rough
idea of which items are deleted, we wonder if it possible to recover these files and how.

We particularly focused on the recovery of the Windows Event Log, the Registry Hives which are probably the most important artifacts in understanding
what happened after an incident.

We must warn that almost all the tools we have tried to require access to a full disk image.

Event Log

When CCleaner is used to clear Windows Events Log, thanks to the USN journal we found that log are not really cleared, but they are overwritten to the
minimum size that corresponds to evtx header’s size. We tested several tools to find one that would allow us to recover deleted Event Logs, especially
Security logs. Finally we have chosen Bulk_extractor_rec  which is a fork of Bulk_extractor including a plugin for “evtx” files.

As mentioned earlier the tool requires a disk image to search for evtx files in chunk data. The output of the tool is a series of evtx files with random names.
The size of the files is a good indicator of whether the tool was able to recover records.

When we opened the file selected in the image above, we could see through Windows Event Viewer that it contained part of the Security Event Log.

Afterwards, we used EvtxECmd to parse all these files. And as we made a copy of Windows Event Logs before and after running CCleaner, we made a
comparison and found that we were able to recover all the deleted logs.

Registry Hive

Registries can be seen as databases where each entry/each key is represented by a cell. When a key is deleted, the cell is simply marked as unused until a
new value is written. So we looked after a tool which could help us to recover keys deleted by CCleaner.

Registry Explorer can parse and process deleted keys. Moreover, it doesn’t require full disk image and can process directly dirty hive and transaction log. So
we decided to give a try with it.

As we can see in the above picture, registry explorer gives us two types of deleted keys:

  • associated deleted records are the keys that the tool was able to reconstruct with timestamp of the run (or deletion).
  • unassociated deleted records are the keys the tool find but wasn’t able to reconstruct.

In this case we can see that the tool have been able to retrieve several keys and value associated. Other values can be found in unassociated deleted
records but without proper association to the right keys.


There are many utilities that allow us to recover deleted files, however most of them are based on file format. We were looking after a reliable method
which will be file format independent. So we decide to use the SleuthKit framework with fls and icat. In our case, we use fls to display recently deleted files
and we recover the files from their id with icat.


We made many tests so this one with Windows Event Trace logs above.

Fls get the list of recently deleted files. Among metadata available with fls output we have the inode number which we used to retrieve the WindowsUpdate.20220523.162042.883.1.etl file (previously deleted by CCleaner) with the following commands :

fls.exe -d -m C:\ r \\.\C: > outputdir\fls_deleted_files_list.tx

//Extract of fls output with inode number underlined
0|C:/Windows/Logs/WindowsUpdate/WindowsUpdate.20220523.162042.883.1.etl (deleted)|100284-128-4|-/rrwxrwxrwx|0|0|45056|1653316413|1653316413|1653914021|1653315642

icat.exe -r \\.\C: 100284 > outputdir\deleted_ WindowsUpdate.20220523.162042.883.1.etl

We ran many others tests with different types of files than we copied to compare and we successfully retrieve all deleted file (no secure delete used by


CCleaner has powerful capabilities to be use has an anti-forensic tool which can delete most useful artifacts. If on an incident response the tool is
encountered the following steps could be used to find which items have been deleted:

  • Retrieve configuration of CCleaner with the argument /EXPORT from the installation folder;

  • Inspect the NTUSER.DAT hive by merging with transaction log, specifically the key Software\Piriform\CCleaner to find all the entries
    with the value “True” which is an indication of selected items;

  • Pay attention to the Last Write Time Value of the HKCU\Software\Piriform\CCleaner which gives an indication of the execution time of

  • For deleted files, compare the “selected list” with configurations files. Confirm with the MFT and the USN journal deleted files it possible to retrieve
    them with fls and icat;

  • Deleted entries from the NTUSER hive can be partially recovered with Registry Explorer and transaction logs.

  • Deleted event log can be recovered with bulk-extractor-rec from a full disk image.


As we’ve seen, CCleaner is a powerful tool with many features and for the purpose of this article we didn’t explored his full capacities. In particular the
possibility to use custom configuration files and the portable version of CCleaner. Those features have significant impact on CCleaner functioning.

The use of custom configuration can replace or be added to the existing configuration.


As mentioned before, the configuration file Winsys.reg does not contain the list of registry keys that can be cleaned, but references directly embedded in
CCleaner. Our different tests have allowed us to determine precisely which keys are concerned:

  • Missing Shared DLLs item :
    • Configuration file reference : R_SHARED_DLLS
    • Corresponding key : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls
  • Unused File Extensions item :
    • Configuration file reference : R_FILE_EXTS
    • Corresponding key : HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\
  • ActiveX and Class Issues item :
    • Configuration file reference : R_ACTIVEX
    • Corresponding key : HKCR\CLSID\{*}
  • Applications item :
    • Configuration file reference : R_APP_OPENWITH
    • Corresponding key : HKCR\Applications\*\shell\open
  • Application Paths item :
    • Configuration file reference :R_APP_PATHS
    • Corresponding key : HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store
  • Obsolete Software item :
    • Configuration file reference : R_OLDSOFTWARE
    • Corresponding key : HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\FirewallRule
  • MUI Cache item :
    • Configuration file reference : R_MUICACHE
    • Corresponding key : HKCU\Soft\Classes\Local Settings\Soft\Micro\Windows\Shell\MUICaches