PowerShell Timestamp Manipulation

Manipulating timestamps on Unix and Linux systems is as simple as touching a file on the file system. Of course, the individual attempting to modify timestamps will need to have permissions to do so on the file(s) in question.

On Windows based systems changing time stamps has historically required the use of third-party tools. However, Windows 7 and Windows Server 2008 will reportedly ship with Windows PowerShell installed.

Among the many advanced capabilities of Windows PowerShell is the ability to modify three different timestamps for Windows file systems. These are the file creation time, last access time and modification time. Forensic analysts should also be familiar with the metadata change time that is updated to reflect changes in a file's permissions, link count or other metadata properties. To my knowledge, there is no capability for directly modifying the metadata change time via PowerShell. As with Unix and Linux, a user must have appropriate rights to modify these timestamps.

Manipulating timestamps is easy with PowerShell.

I have written elsewhere about manipulating timestamps with PowerShell, but after a recent mailing list discussion, I decided to delve more deeply to see what artifacts are left on a system where PowerShell has been used to change timestamps.

For behavioral analysis of this sort, I generally reach for Process Monitor. In the next screen shot, you can see I configured it to filter out everything except PowerShell related events.

Configuring ProcessMonitor to filter everything except PowerShell related processes.

With ProcessMonitor running, I fired up PowerShell. In an instant, ProcessMonitor displayed around 10K events. Who says Windows isn't complicated. Most of the hits were registry and file system reads with a small number of writes.

Unfortunately, the registry and file system writes are of limited use to forensic examiners. When PowerShell is spawned, the usual suspects are updated. An entry will be created in the Windows Prefetch with a timestamp reflecting the most recent run time. On the fully patched XP Pro system I used for testing, PowerShell created a new category of entries in the the Event Viewer though none of the entries gave specific information about what was done at the command line.

There's a record of PowerShell being run, but no details as to what was done at the command line.

Additionally, the UserAssist keys in the registry (HKCU\Software\MS\Windows\CurrentVersion\Explorer\UserAssist) are also updated to reflect the fact that PowerShell was run, but again, no details as to what commands were run from the CLI.

UserAssist Keys from HKCU -- note the use of ROT-13!

ROT-13 Sidebar

You did catch the ROT-13 in the UserAssist Keys, right? Over the weekend as I was finishing up this entry, Didier Stevens posted that ROT-13 has been superseded by a Vigenère cipher in Windows 7.* The same may be true for Windows Server 2008, I haven't looked. The key used in the Vigenère cipher appears to be the same across all Windows installations, though it may be too early to tell.

Long story short, attackers may use PowerShell on new Windows systems to manipulate timestamps. Forensic examiners will be able to see that PowerShell was run, but won't have any evidence as to what it was actually used for.

* Update: 20100201 — The commercial release of Windows 7 saw the use of Vigenere cipher replaced with trusty, rusty old ROT-13 again.

Dave Hull, GCFA Silver #3368, is an aspiring maker and technologist specializing in information security. He is the principal consultant and founder of Trusted Signal.