Windows and its anti-forensic side, (Plug and Play Cleanup and setupapi[.]dev)

Hi, minions:

The article that I present to you today is a work that I had pending to publish for almost a year... Today, at last, I can cross it off my 'To Do' list. These are the things that have to be merely a curious in the matter. That you can only do what you can do, with the means you have and with the time you have. But I don't like to be with a half-hearted job. So I've finished what I started and I hope you enjoy it as much as I do.

Let me put you a little in the background of this project, with a brief introduction on how this work came about...

After my presentation at the CONPilar Cybersecurity Congress, (April 28, 2018), under the title "Think twice before you insert it", and after the corresponding publication of a very brief article in 'Follow the White Rabbit', (May 1, 2018), Alexis Brignoni was kind enough to make an observation that same day, by means of a tweet, which perplexed me. In that tweet, Alexis mentions that it seems that Windows likes to remove entries from USB devices if they are not connected in 30 days. Accompanying this tweet is a link to an article by David Cowen, (published on April 19, 2018), under the title "Windows, Now with built in anti forensics!". In that article, David says that: "Windows, by itself and without the user's request, is systematically removing some unused device entries from the Registry, driven by the task scheduler". David also refers to the source of the news but, unfortunately, is no longer available, (http://textlab.io/doc/431305/pdf-version---dpmforensics).

So I set to work and announced it in another tweet, (May 4, 2018). I lifted some virtual machines, installed several versions of Windows and made the relevant tests. Once these tests were finished, I let David know by means of another message, (on June 7, 2018), because this 'new' feature of Windows had me completely confused.

Shortly after, (July 29, 2018), David posted a new challenge in his Blog, with a very clear question: "Windows 10 keeps changing and with it its behavior. In Windows 8.1 and the first versions of Windows 10 there was the task of removing plug and play devices that had not been connected for 30 days. In the most recent versions of Windows 10 this seems to be disabled. For this challenge, document which versions of Windows 10 have the task enabled and whether it survives the upgrade."

I already had half a job done... but the lack of foresight led me astray. I didn't consider the hard disk space needed for upgrades and fell short of assigning an appropriate disk size. (Back to start with testing).

But... there is no evil that for good does not come, because Adam Harrison did an excellent job publishing a resolution to the challenge, in his Blog, (on July 30, 2018), with the article "Windows Plug and Play Cleanup".

I thought it appropriate to give you this brief chronology so that you can see that, at times, there are great works, projects and ideas, which arise from a mere observation, from a small comment.

That said,

Apparently, this is a scheduled task that will remove all devices that haven't been connected for 30 days. How? A new anti-forensics feature in Windows? That's against my curiosity.

Plug and Play Cleanup

'Plug and Play Cleanup' is a scheduled task that comes integrated with some versions of Windows 10. It is created by the System itself and is executed with the System user. This task says in its description, verbatim: "Windows keeps copies of all device driver packages installed before from Windows Update and other sources, even after installing newer versions of the drivers. This task will remove older versions of drivers that are no longer needed. The most recent version of each driver package will be preserved. It will also remove the status used by devices that have not been detected in the System for a long time".

To understand how the scheduled task works, you need to study it. Windows creates for each scheduled task a file that is hosted in the path "%systemroot%\system32\Tasks\". In this case, the task file is in:

%systemroot%\System32\Tasks\Microsoft\Windows\Plug and Play\Plug and Play Cleanup

If it is opened with a suitable viewfinder it can be studied comfortably and different sections and fields with different values can be clearly seen. 

The first thing you can see is that it refers to a file called 'pnpclean.dll', (which I will tell you a little later), which is in:

%SystemRoot%\system32\pnpclean.dll

According to the Microsoft site, there are two versions of tasks: 1.0 and 2.0. The version of this task corresponds to 1.0.

The field named 'RunLevel', has a value of 'HighestAvailable' and indicates that, according to the Microsoft site, the task will be executed with the highest user permissions available, (System user).

The field named 'ExecutionTimeLimit' has a value of 'PT1H' and indicates that, according to the Microsoft site, the task will be executed for a maximum time of one hour.

The field named 'UseUnifiedSchedulingEngine' has a value of 'true' and indicates that, according to Microsoft's site, the unified programming engine will be used to perform the task.

In the 'MaintenanceSettings' section you can see two fields. The 'Period' field, which has a value of 'P1M', indicates that, according to Microsoft's site, the task will be executed once a month during automatic maintenance. The 'Deadline' field, which has a value of 'P2M', indicates that, according to the Microsoft site, the task will be executed once every two months during the emergency automatic maintenance, if it could not be completed during the regular automatic maintenance.

If you wish, you can view the existing official Microsoft documentation on maintenance settings.

The file 'pnpclean.dll', to which the task refers, is responsible for carrying out the removal of unused 'old' devices and drivers (depending on the System).

This file is located in the path:

%SystemRoot%\system32\pnpclean.dll

This file searches for devices and drivers that have not been connected and used recently and can be removed from the System.

I remind you that an attacker with privileges could run this file to try to remove some evidence, making use of:

rundll32.exe pnpclean.dll,RunDLL_PnpClean /DEVICES /DRIVERS /MAXCLEAN

I can assure you that many of those devices that have been eliminated use them frequently.

The test environment

To shed a little more light on this behavior, a little dark, of Windows I have chosen to perform clean installations of the following versions of Windows 10, virtualized under VirtualBox

• Version 1507, OS build 10240.16384
• Version 1607, OS build 14393.0
• Version 1709, OS build 16299.15
• Version 1803, OS build 17127.1
• Version 1803, OS build 17134.1
• Version 1803, OS build 17134.112

After completing the installation, I have decided to carry out a series of steps common to all tested versions:

• Check the existence of the 'Plug and Play Cleanup' task
• Install a single USB device on all machines, (serial number 070B59BB1CB2234)
• Extract the following files with FTK Imager Lite:
• Plug and Play Cleanup
• pnpclean.dll
• setupapi.dev.log
• System
• Upgrade all systems to the latest version available
• 'Travelling to the future', changing the date of the System
• Re-extract the same files as before the update

I have taken into account the creation date of the 'Plug and Play Cleanup' and 'pnpclean.dll' files, as well as the version of the '.dll' files and compared their contents by calculating the hash value in MD5, using the HasMyFiles tool.

All systems have been updated to OS build 17134.619, except for OS build 10240, which has been updated to 17763.316, (for reasons I don't know).

You can check the version, release date and other information about the different versions on Microsoft's official site.

The tests

OS build 10240.16384

This version presents the scheduled task.

The 'Plug and Play Cleanup' file has a hash value of a637c76f51d93371487db5b64e1333a6.

The file 'pnpclean.dll' has a creation date of 10/07/2015 8:23:38, a version of 10.0.10240.16384 and a hash value of 3b24ac437d7ea0df8bde0d7cfbc5d6ad.

After the update,

The original 'Plug and Play Cleanup' file has been moved to "Windows\System32\Tasks_Migrated\Microsoft\Windows\Plug and Play\" and another file with the same hash value of a637c76f51d93371487db5b64e1333a6 takes its place.

The original 'pnpclean.dll' file is no longer in the System. Another file takes its place, with a creation date of 15/09/2018 5:07:07, with a version of 10.0.17763.1 and a hash value of 5bc372bd55b3c1506f9ffabda9f11639. There is also another file 'pnpclean.dll' in the path "Windows.old\System32\", which presents a creation date of 30/09/2016 3:13:53, with a version of 10.0.10240.17146 and a hash value of c8703a9e9c5ca37439a37a0af3a535e7.

In this version, the scheduled task is still enabled after the update.

OS build 14393.0

This version presents the scheduled task.

The 'Plug and Play Cleanup' file has a hash value of a637c76f51d93371487db5b64e1333a6.

The file 'pnpclean.dll' has a creation date of 16/07/2016 11:42:16, a version of 10.0.14393.0 and a hash value of e8ac0747384c96c23ca5e84ee79492bd.

After the update,

The original 'Plug and Play Cleanup' file has been moved to "Windows\System32\Tasks_Migrated\Microsoft\Plug and Play\" and another file with the same hash value of a637c76f51d93371487db5b64e1333a6 takes its place.

The original 'pnpclean.dll' file is no longer in the System. Another file takes its place, with a creation date of 11/04/2018 23:34:32, with a version of 10.0.17134.1 and a hash value of 4fa8d3cb0ef46be97cd4314617db94dc. There is also another file 'pnpclean.dll' in the path "Windows.old\System32\", which presents a creation date of 16/07/2016 11:42:16, with a version of 10.0.14393.0 and a hash value of e8ac0747384c96c96c23ca5e84ee79492bd.

In this version, the scheduled task is still enabled after the update.

OS build 16299.15

This version does not have the scheduled task.

The file 'pnpclean.dll' has a creation date of 29/09/2018 13:41:56, a version of 10.0.16299.15 and a hash value of c2374548a0b171794628a136cf4507da.

After the update,

The original 'pnpclean.dll' file is no longer in the System. Another file takes its place, with a creation date of 11/04/2018 23:34:32, with a version of 10.0.17134.1 and a hash value of 4fa8d3cb0ef46be97cd4314617db94dc. Another file 'pnpclean.dll' is also found in the path "Windows.old\System32\", which presents a creation date of 29/09/2017 13:41:56, with a version of 10.0.16299.15 and a hash value of c2374548a0b171794628a136cf4507da.

OS build 17127.1

This version does not have the scheduled task.

The file 'pnpclean.dll' has a creation date of 18/03/2018 17:29:24, a version of 10.0.17127.1 and a hash value of 8eb85239c3e8e7bb8dd070b722e60da.

After the update,

The original 'pnpclean.dll' file is no longer in the System. Another file takes its place, with a creation date of 11/04/2018 23:34:32, with a version of 10.0.17134.1 and a hash value of 4fa8d3cb0ef46be97cd4314617db94dc. Another file 'pnpclean.dll' is also found in the path "Windows.old\System32\", which presents a creation date of 18/03/2018 17:29:24, a version of 10.0.17127.1 and a hash value of 8eb85239c3e8e7bb8dd070b722e60da.

OS build 17134.1

This version does not have the scheduled task.

The file 'pnpclean.dll' has a creation date of 11/04/2018 23:34:32, a version of 10.0.17137.1 and a hash value of 4fa8d3cb0ef46be97cd4314617db94dc.

After the update,

The file 'pnpclean.dll' has exactly the same features as before the update.

OS build 17134.112

This version does not have the scheduled task.

The file 'pnpclean.dll' has a creation date of 11/04/2018 23:34:32, a version of 10.0.17134.1 and a hash value of 4fa8d3cb0ef46be97cd4314617db94dc.

After the update,

The file 'pnpclean.dll' has exactly the same features as before the update.

Results

Here are the results I have obtained in a table, divided into two parts by size, (and therefore for greater understanding). The first part corresponds to the information before the update of the systems and the second part corresponds to the information related to the systems once they have been updated.

As you can see, in my tests, the versions with the scheduled task are 1507, (10240), and 1607, (14393). As of version 1709, inclusive, the scheduled task is not presented.

The existing scheduled tasks are identical in all systems that have it activated and, in addition, they persist after the update, since they are still present.

In a clean installation, each version of the Operating System has its own version of the file 'pnpclean.dll', which is modified when the version is updated.

All systems, once updated, (with the exception of version 1507, which has some peculiarities), present the same version of the file 'pnpclean.dll', created on 11 April 2018.

From version 1803, (17134.1), launched on 11 April 2018, the same version of the file 'pnpclean.dll' is presented in all systems, which do not undergo changes in their update.

A couple of pecualities

During the execution of my tests I was able to observe a couple of peculiarities.

I could read in some articles that the devices are removed when they have not been connected in 30 days, when the task is executed. As I have seen in my tests, this is not the case.

To understand this operation we must understand when it comes into operation. As I have explained before, the 'Plug and Play Cleanup' task is performed once a month, during automatic maintenance or once every two months, during emergency maintenance, if automatic maintenance fails. Therefore, you have to take into account how the automatic maintenance occurs, which can be consulted on the official Microsoft site. You should know that it is the System that chooses when the automatic maintenance is executed, when it is on or at rest and, by default, it is carried out daily, (at 3 AM), with a maximum duration of one hour.

When the task runs, it always calls the file 'pnpclean.dll'. The System considers the execution of the task successful even if an error is shown in it. And if the task presents after its execution the code 0x0 means, according to the Microsoft site, that the task has been executed successfully.

All the tasks programmed by the Windows System itself have a last execution date of 30 November 1999.

In order to carry out the tests of execution of the task I have chosen to carry out several 'trips to the future', changing the date of the System.

I advance the date of the System, (which is isolated from the network), until March 28 to leave it inactive. The task was executed after 10 minutes of inactivity, on March 28, at 07.52.11 hours.

Again, I bring forward the date of the System until April 15 to leave it again inactive. The task is executed that day, at 08.05.58 hours.

I make a last 'trip to the future', bringing forward the date of the System to May 10 to leave it inactive for the last time, until the execution of the task, which occurs at 09.06.48 hours.

All these actions carried out by this scheduled task can be seen in the log 'setupapi.dev.log', which is in charge of registering driver installations and uninstallations.

(In this case nothing is eliminated because there is nothing to eliminate).

This means that there is no need to be 30 days after the last use of a driver or a device, although I cannot, as of today, determine the exact frequency of its execution.

Another peculiarity that I have come across is related to version 10240 of Windows which, besides having the programmed task 'Plug and Play Cleanup' enabled and with persistence after its update, does not register the drivers of connected devices in its log 'setupapi.dev.log'.

I connect device 070B59BB1CB22334 to the updated System, from version 10240 to version 17763, on February 25, 2019, at 09.52.55.

And I proceed to examine the log 'setupapi.dev.log', where I can't find the device connected.

This updated version of the 10240 does not save the USB devices in that file, although I have found those values in the log 'setupapi.upgrade.log', in the section corresponding to the PnP migration configuration.

Given this detail, I choose to do a series of tests with the 10240 version clean and isolated from the network. I connect that same device and study again the log 'setupapi.dev.log', with negative result.

Thus, at least this version of Windows does not save the USB devices in the corresponding log.

Conclusions

There are several conclusions I can think of...

The first of them is that, if you are planning to publish a work but another person has anticipated it and it is already published, publish it as well because that will serve for two things:

• Recognize other people's work. (That's good)
• Validate other people's tests. (That's good)

Collaboration, directly or indirectly, is very good for seeking results.

Another conclusion I draw is that, more and more, it is necessary to know the original version of the installed system because it is possible that we find cases in which the USB devices that are connected are not recorded, (as happens with version 10240), or cases in which these are eliminated together with their controllers, by the action of the system itself or by the action of the user.

If you find a 'Windows.old' folder, you should study it because it is possible that what you are looking for is there, if the drivers and devices have been connected before an update. Don't forget that there are some forensic tools that base their operation on finding data from the files affected by the 'Plug and Play Cleanup' task.

I can confirm the tests that Adam did in his article and say that the last version that included the task 'Plug and Play Cleanup' has been the 1607, ceasing to be present in the following versions. I can also say that the file in charge of this 'cleaning', the file 'pnpclean.dll', has a stability since version 17134.1, since it does not vary with the following versions. 

We can't rule out that, as Windows versions progress and change, we may find the 'Plug and Play Cleanup' task again.

If you liked this little job, let me know. (That's good).

That's all.

Marcos

Share: