“I didn’t do it.”
– Bart Simpson
It Was Windows, Not Me… I Swear!!
I spent a lot of time in my law enforcement career digging through “who done it” details. As a detective, attributing an act (especially a crime) to the right individual is of utmost importance. It’s exceedingly common for someone who has done something wrong to point the finger at someone else. The hope is to escape responsibility in placing blame elsewhere. Once in a while, someone else DID do it.
When one points their finger, that finger typically points to another human being. But in this case, it was pointed at an operating system update.
In today’s case study, our client was an employer who turned to Gillware for forensics assistance after an employee left for a competitor. The employer told us that within hours of notification that she intended to quit, the employee in question’s work computer came back to HR “wiped clean” almost as if by magic. They went on to say that her email, work documents, Salesforce, and Internet browsing activity, were all miraculously purged. When questioned, she claimed that a Windows update was responsible for cleaning up her computer and that she had nothing to do with it.
Employee Misconduct or Windows Misconduct?
Our client was understandably skeptical. Their concern was that that the mysterious failed Windows update was a cover-up for more nefarious activities. Had the suspected employee deleted her data on purpose? Had she taken sensitive data with her when she left? If so, had she shared that company data with the competitor? Was she in violation of her non-compete agreement?
Everyone knows that Windows can be fickle. We all love to complain about Windows 10, particularly that sometimes it seems to have a mind of its own. Sometimes during operating system updates, unexpected things can happen.
Our client didn’t want to confront the ex-employee without ammunition, and they didn’t want to engage in false accusations, either. They hoped that we could provide answers they needed to proceed with any potential legal action.
The Forensic Examination:
Windows Reset user interface in Windows Update control panel
After we received the drive and imaged it, I dug in to see what I could find. The ex-employee hadn’t wiped the machine, that much was certain. Rather, their old computer appeared to have a brand new installation of Windows 10 Professional on it.
There was one non-standard user account on the machine named with the employee’s first name misspelled. The installation date, coincidentally, matched the evening before the employee put in her notice. Registry examination of SAM files on the hard drive revealed a previously existing user account that used the correct spelling of the employee’s name. Windows may do wacky things occasionally, but it won’t re-name and misspell a user account name as part of the normal update process.
A quick review of the file system showed many artifacts indicative of the Window Reset having run its course. The user can access Windows Reset through Recovery Options in the Control Panel, and the user can choose to reset Windows and either keep their files or not. This procedure doesn’t happen on its own.
Windows Update Recovery Partition
Many laptops have a recovery partition for reinstalling Windows if something goes wrong. In this case, the computer was a Lenovo, and it had a recovery partition. When somebody runs the WindowsRE restore function, it updates the “date modified” and “date accessed” metadata for the recovery partition. I quickly discovered that the “modified” and “accessed” date/time stamps from the Lenovo Windows recovery partition reflected the night before the employee submitted her resignation. The clues were all adding up.
Lost Secrets of the Great “Windows.Old” Ones
My next clue came from a Windows.old folder in the file system. Since Windows Vista, Windows has created the Windows.old folder when the user upgrades from one version of Windows to another, as well as when you reset Windows. The Windows.old folder contains all the files and data from your previous Windows installation. If the user isn’t happy with the newest or changed version of their operating system, they can use it to restore the old version of Windows The Windows.old folder may delete automatically after 10 to 30 days depending on the version of Windows. In this case, it’s presence in a non-deleted state indicated that the change to Windows happened recently.
The Windows Bluewire Push Button Page
I also found a $SysReset directory in the file system on the drive. This folder appears when a user performs a Windows system reset. Within the $SysReset directory is a log file named setupact.log that tracks the actions taken during a reset. I reviewed this file and found reference to the Windows “Bluewire Push Button Page.” This page is a direct reference to the user dialog box within Windows settings that lets the user perform a Windows reset.
The Bluewire Push Button Page provides an option to “Keep my files” and one to “Remove everything.” Conveniently, the setupact.log file tracks which option the user chooses when the reset occurs. In this case, the ex-employee had chosen the “Remove everything” option.
Excerpt from setupact.log file
This process removes user files and directories but does not overwrite the data. Most of the user’s data still existed as “Orphaned” files, some of which I could easily recover. Many preexisting system files such as registry artifacts move to the Windows.old directory during a reset and can be easily examined. Because the username had been renamed with a misspelling, sorting out new activity from the old was even easier.
The employee had also attached to her home wireless network when she reset-up Windows. And she entered user credentials to do so.
And as the saying goes, boom went the dynamite.
An Easy “Who Done It”
In this case, the mystery about who was responsible for the disappearance of the ex-employee’s files was quite easy to solve. Multiple artifacts pointed to the user doing a Windows Reset.
The reset process requires active user intervention to complete. Considering the number of steps a user has to go through to accomplish a reset, there’s little chance that it was accidental. Though a Windows update can seem to do a lot of mysterious things, our forensic footwork exonerated Microsoft’s handiwork in this case. Thankfully, update and reset activities are well-logged, and a good forensic investigator can unravel them after the fact.
Hi Folks, This post is about a case study that illustrates the troubleshooting steps taken to modify an existing custom ConfigMgr report to return the correct results when compared to Windows update when checked on Internet. I have included the details and the path taken to achieve the same.
The updates returned from the Windows update are less than what is returned from the Reports we are using in ConfigMgr.
When we run against the windows update we get only 2 updates marked as high importance. And when we run the report (Custom created) it returns as 11 updates required. As per them the report should return only 2 but its not.
From the initial thought it was sure that there was something definitely missing in the query. So have a look at the query:
So this query sums all the update for which the status compliance status is 2. The status 2 is for missing updates. It does not check in anywhere for any specific category updates.
The next plan of steps was to modify the query to return the Update IDs also that are missing. By this we can check what all are the updates that are shown as missing and compare with the windows update results and check if it only shows the high importance updates or does it include the optional updates too.
Query modified added Unique ID:
Output (As expected returned 11 results):
When compared the same with the windows update results found that the 2 high importance updates were present here. They are one which start with Update ID bd7d.. and c352..
Also, checked the optional updates that were returned by the windows update. There were 7 Software optional and 2 hardware optional updates. Then checked their update ids and found the same in the above list.
From this it was clear that the query was not only returning the High importance updates but also the software and hardware optional updates.
But now as I was doing this, The need then modified to change the query to return only the High priority updates from the reports.
Here the challenge was that Windows update divided the update in 3 categories i.e.
1. High Importance
2. Software optional
3. Hardware optional
In the ConfigMgr, we have the categories:
1. Critical updates
2. Definition updates
3. Security updates
4. Service packs
7. Tools etc.
So the point to check was on what basis the updates are categorized as High importance by windows update and under category they fall in the ConfigMgr.
After some research, We found that the security updates are always put under high importance and the one we checked in the optional were belonging to the software optional.
The next thing was where does the information on the updates category reside? It does not took us much time and we found out that CategoryInstanceName column from view v_CICategoryInfo
Will yield us the category information (i.e. critical, security). So now I just needed to add one condition in the query that will tell it to filter for only the security updates.
Modified the query:
Cloned the existing report with the above modified query. It worked for us and retuned only the two updates that we needed.
Hope you liked it.
Support Escalation Engineer | Microsoft System Center ConfigMgr
This posting is provided "AS IS" with no warranties and confers no rights.