During one of the SANS sessions for the For408 course, a question (challenge) was raised by me if it was possible to prevent Windows from logging key user-artifacts. Many user-artifacts, such as thumbnail views, Internet history, recent file opened, etc., are written to disk in defined areas. Our test was to attempt to lock down these areas to prevent user-action artifacts from being written and ultimately not being seen by an investigator.
Understanding Where User-Artifacts are Stored
First thing: review this post. It’s an exceptional quick reference guide for where to find evidence of user-actions. Next, ask yourself if you have ever thought about ways to prevent your actions from being logged; surprisingly, I asked this question to several SANS instructors within the forensic tracks and their response was consistent: “We have never seen this tactic during an investigation and never heard of anyone attempting this”. This is a very attack-oriented question, yet one I would have thought has been asked several times before.
Generally speaking, this blog is not about user-artifacts, their locations, how/when they are logged, what information is logged, and how to analyze and interpret that data – this blog is simply about locking down a few directories (Windows 7 test bed) that contain user-artifacts; why not lock down the directories before they have a chance to store your actions? Additionally (not yet), this blog will not go into detail of what forensic artifacts this technique may leave on a system like changes to MFT, volume/shadow copies, restore points, etc. — in other words, a follow up blog logically would describe how an investigator could detect this behavior if an attacker leverage this to prevent logging their tracks.
What are some of the key directories we were concerned with for this challenge?
How Can you Lock Down User-Artifact Directories?
If you have access to cmd, it seemed very simple to implement; use icacls to change effective permissions on key user-artifact directories. Now realize the use of cmd.exe will be logged as a user-artifact; this is an acceptable risk. Initially, obtain the current permission list and store those permissions so they can be reverted back easily. Below is an example of the “Recent” directory:
icalcs \appdata\Roaming\Microsoft\Windows\Recent /save BackupAclFile
- NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
Next, deny access to the “Recent” directory, effectively preventing shortcut (LNK) files from being logged. Each user listed with access to this directory will need a deny entry, i.e. the below will deny access to the ‘SYSTEM’ account. Repeat this process for all legitimate users:
icacls appdata\Roaming\Microsoft\Windows\Recent /deny “NT AUTHORITY\SYSTEM”:(d,wdac,wd)
Next, test the deny statement. Open up a new document, say something like “Test-Perms.txt” from the %USERPROFILE%’s desktop. You will notice this document is not contained within this directory as a recent entry.
Now, repeat the deny statement with other interesting directories, for example:
What Was the Fallout, Did Windows Puke?
The Windows OS did not log permission changes to directories and the use of icacls was not logged within any hives as a program initiated and executed from cmd.exe. Seemingly, we are working with anonymity. There is a caveat: although I used registry and file tracking for indications of my user-actions that locked down key directories, this was done with quick-hitting tactics and validation with known areas to potentially log those actions. No forensic imaging, memory dumps or full file/registry integrity monitoring was performed. This will be an exercise for the near future to perform in order to defensibly validate the tests.
At any rate, the results are as expected based on our icacls entries, albeit somewhat surprising Windows did not throw any errors, freeze, or at least log errors to event logs. Effectively, we are able to perform several user-actions that are no longer logged as expected; and if they are not logged, the action is not recoverable.
Can Anything Be Done to Prevent This?
Do not allow users to have administrative rights. In lieu of restricting administrative rights or enforcing directory restrictions via GPO’s, it would be beneficial to implement file system auditing to track permission changes and write failures to directories, or even more interesting would be to enforce command terminal auditing, which is now a feature with later versions of Windows, such as 8.1 and 2012 R2 (http://www.microsoft.com/en-us/download/details.aspx?id=36036)
The technical details, and even the premise of the question, is not groundbreaking or challenging – but the implications could be very interesting. If an attacker, or probably more importantly an insider, has the ability to change permissions on known (and forensically-used) directories that store user-actions, the potential to work with anonymity exists. I look forward to continuing this investigation for any indication or evidence to show a user is implementing this technique. Additionally, I would be interested to know if this method or similar behavior has been used to work anonymously.