As before, not having signed up for the CTF itself, I found the questions associated with the image at the following sites:
HackStreetBoys
InfoSecurityGeek
Caffeinated4n6
One of the CTF questions that caught my attention was, What tool was used to delete forensic artifacts? I've long been interested in two aspects of DFIR work that are directly associated with that question; anti- (or counter-) forensics, and what something looks like in the data (i.e., how is the behavior represented in the data?).
I found the answers to the question were interesting. The HackStreetBoys response referenced the output of the itempos.pl plugin, which listed the contents of the mpowers user desktop. A reference to a program was found, one that was determined to be used for counter-forensic purposes, and that program was the response to the CTF question. The other two responses referenced the UserAssist data, and similarly, it seems that something was found that could be an anti-forensic tool, was found on Google and seen to be an anti-forensics tool, and that was the answer.
However, beyond that, there was little in the way of verification that the program had actually been used to perform the specified task. This is not to say that any analysis was incorrect; in the publicly available write-ups I reviewed, the answers to this question were reasonable guesses based on some modicum of the available data.
We know that the system was running Windows 2008 R2, and that tells us a good bit in and of itself. For example, being a server version of Windows, application prefetching is not enabled by default, something we can easily verify both via the Registry, as well as via visual inspection of the image. Something else that the version information tells us is that we won't have access to other artifacts associated with program execution, such as the contents of the BAM subkeys. Further, there are other artifact differences with respect to the first image in the CTF; for example, the File Server image contains a SysCache.hve file, but not an AmCache.hve file.
As such, the InfoSecurityGeek and Caffeinated4n6 blogs focused on the UserAssist data, and rightly so. If you look closely at the Registry Explorer screen capture in the InfoSecurityGeek blog, you'll see that the identified value in the UserAssist data does not have a time stamp associated with it. I've seen this happen, where the value data in the Registry either does not contain the time stamp associated with when the user launched the program, or the data itself is all zeros.
As a bit of a side note...and this is more of a personal/professional preference..I tend to prefer to not hang a finding on a single data point. What I try to do is find multiple data points, understanding the context of each, that help build out the story of what happened. For example, the fact that a program file existed on a system does not directly correlate to the fact that it was executed or launched. Similarly, the fact that a GUI program was launched does not definitively state that it had be run. I can open RegEdit and browser the Registry (or not) and then close it, but that does not definitively demonstrate that I changed anything in the Registry through the use of RegEdit.
From reviewing all three blog posts, we know that a file exists on the mpowers user desktop that, based on Google searches, is capable of taking anti- or counter-forensics actions (i.e., deleting forensic artifacts). We also know that it is a GUI program, and that indications are that the user launched the GUI. But what we don't know is, was the program actually run, in order to "delete forensic artifacts"?
Or do we?
Based on the question, the assumption is that forensics artifacts had been deleted, and as such, would not be found via our 'normal' processes. This is illustrated by the fact that a good bit (albeit not all) of the data we'd normally look to with regard to user activity appears to have been removed; the RecentDocs key for the user isn't populated, there are no visible LNK files in the user's Recent folder, and there are only two JumpLists in the user's AutomaticDestinations folder. Not definitive, but it's something.
So, my approach was to look to deleted keys and values within the user's NTUSER.DAT hive. One of the values found was:
P:\Hfref\zcbjref\Qrfxgbc\CevinMre.rkr
Knowing that the value names are Rot-13 encoded, that entry decodes to:
C:\Users\mpowers\Desktop\PrivaZer.exe
Tracking the value data based on the offset listed in the value node structure, and then parsing the data at that location, here is what I found:
00 00 00 00 01 00 00 00 02 00 00 00 E4 6B 01 00 .............k..
00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
00 00 80 BF 00 00 80 BF FF FF FF FF 30 DA 50 46 ............0.PF
8C 2E D4 01 00 00 00 00 ........
As you can see, there are 8 bytes toward the end of the data that are a FILETIME object. With a little scripting-action, I was able to extract the data and translate the time stamp into something human-readable:
Tue Aug 7 20:21:51 2018
The process of getting the above time stamp involved getting the offset to the data from the value structure, locating the data in the binary contents of the NTUSER.DAT file (via a hex editor) and then writing (well, not writing so much as copy-paste, right from the RegRipper userassist.pl plugin...) a small bit of code to go in and extract and process the data. Remember, the "active" value within the hive file contained data for which the time stamp was all zeros; in this case, we now have a time stamp value that we can work with. Within a micro-timeline of user activity, we see the following:
Tue Aug 7 20:24:14 2018 Z
REG mpowers - M... HKCU/mpowers/Software/Microsoft/Windows/CurrentVersion/Explorer/StreamMRU
REG mpowers - M... HKCU/mpowers/Software/Microsoft/Windows/CurrentVersion/Explorer/ComDlg32/CIDSizeMRU
Tue Aug 7 20:24:13 2018 Z
REG mpowers - M... HKCU/mpowers/Software/Microsoft/Windows/CurrentVersion/Explorer/ComDlg32/OpenSavePidlMRU
REG mpowers - M... HKCU/mpowers/Software/Microsoft/Windows/CurrentVersion/Explorer/ComDlg32/LastVisitedPidlMRU
REG mpowers - M... HKCU/mpowers/Software/Microsoft/Windows/CurrentVersion/Explorer/RecentDocs
So, we see a number of Registry keys modified, and from our use of the appropriate RegRipper plugins (as well as a viewer, to verify) we can see that all of these keys are empty; that is, none is populated with any values. This may be the "delete forensic artifacts" that we were looking for...
Pivoting into a more comprehensive timeline of system activity based on the time stamp, we see the following activity:
Tue Aug 7 20:23:53 2018 Z
FILE - MA.B [43680] C:\Users\mpowers\AppData\Local\Temp\000\717000000000000000000_p.0x0
Tue Aug 7 20:22:18 2018 Z
FILE - M... [221] C:\Users\mpowers\AppData\Local\Temp\000\new_version.txt
Tue Aug 7 20:22:17 2018 Z
FILE - .A.B [221] C:\Users\mpowers\AppData\Local\Temp\000\new_version.txt
Tue Aug 7 20:22:15 2018 Z
FILE - MA.. [4096] C:\Users\mpowers\Downloads\$I30
FILE - MA.. [56] C:\Users\mpowers\Downloads\
Tue Aug 7 20:21:56 2018 Z
FILE - .A.B [314] C:\Users\mpowers\AppData\Local\Temp\000\data.ini
Tue Aug 7 20:21:55 2018 Z
FILE - MA.B [3096] C:\$Extend\$RmMetadata\$Txf\00000000000060CC\
FILE - MA.B [870278] C:\Users\mpowers\AppData\Local\Temp\000\sqlite3.dll
FILE - MA.B [56] C:\$Extend\$RmMetadata\$Txf\00000000000060CC\$TXF_DATA
FILE - ...B [4096] C:\Users\mpowers\AppData\Local\Temp\000\$I30
FILE - ...B [48] C:\Users\mpowers\AppData\Local\Temp\000\
Following the activity illustrated above, we see a significant series of events within the timeline that may be indicative of artifacts being "cleaned up"; specifically, folders and Registry keys are being modified presumably emptied), and files deleted.
Something else that is very instructive from the system timeline is that while the apparent deletion activity is going on, there is also an update being applied. This is a great example demonstrating how verbose Windows systems can be, particularly when it comes to creating events on the systems. When reviewing the timeline, I noticed that there were more than a few files being created, rather than modified, that appeared to associated with a Windows update. There were also some Registry keys that were being "modified". I then checked the following log file:
C:\Windows\Logs\CBS\DeepClean.log
The entries in this log file indicated not only that there were updates being applied, but also which updates were applied, and which were skipped. This is great illustration of why micro-timelines, pivot points, and overlays are so valuable in timeline analysis; throwing everything into a single file or view would lead to a massive amount of data, and an analyst might miss important artifacts, or "signal", buried amongst the "noise".
Finally, there was a whole swath of events similar to the following:
- MA.B [0] \[orphan]\00000000000000000000000000000000552.0x0
After all of that activity, we see the following:
Tue Aug 7 20:31:36 2018 Z
FILE - M... [314] C:\Users\mpowers\AppData\Local\Temp\000\data.ini
Tue Aug 7 20:30:59 2018 Z
FILE - M... [0] C:\Users\mpowers\Desktop\PrivaZer registry backups\WIN-M5327EF98B9\00000000000000.0x0
FILE - MA.. [48] C:\Users\mpowers\Desktop\PrivaZer registry backups\WIN-M5327EF98B9\
REG - M... HKLM/Software/Microsoft/Windows/CurrentVersion/RunOnce
FILE - M... [0] C:\Users\mpowers\Desktop\PrivaZer registry backups\WIN-M5327EF98B9\000000000000000000.0x0
We see that the data.ini file associated with the PrivaZer tool was last modified in the timeline extract above. The final 2 lines in the file are:
[last_erase_date2]
717=131781474597770000
That long string of numbers could be a FILETIME object; assuming it is and converting it to something human readable, we get:
2018-08-07T20:31:00+00:00
Okay, the granularity of the time stamp is only to the minute, and it is stored in a 100-nanosecond-epoch format, but what it seems to give us is the last date that the program was run. What's interesting is that within the timeline of system activity, there doesn't seem to be any more activity following that time stamp that is associated with mass deletion or counter-forensics activity, likely as a result of the PrivaZer program. There is a significant amount of failed login activity that picks up shortly thereafter within the overall timeline; this activity could be seen as counter-forensics in nature.
Why is this important? Well, about 3 minutes prior to the above activity kicking off, there were two attempts to install CCleaner on the system. I say "attempts", because the timeline contains several application error or crash events related to the following file:
C:\Users\mpowers\Downloads\ccsetup544pro.exe
Following these crashes, there does not appear to be any timeline data indicative of the program being installed (i.e., files and Registry keys being created or updated, etc.), nor does there seem to be any indication of the use of CCleaner.
By correlating the time that the PrivaZer program was launched to additional events that occurred on the system, we now have much more solid information that the program was used to "delete forensic artifacts". This is important because some of the deleted artifacts could have been removed with native tools such as RegEdit or reg.exe; having an apparent privacy tool on the user desktop does not necessarily mean that it was used to perform the actions in question. Yes, it is a logical guess, based on the data. However, by looking a bit closer at the data, we can see further activity associated with program execution.
Conclusion
Again, my reason for sharing this isn't to point out anything with anyone else's analysis...not at all. But something I've seen repeatedly during my time in the industry has been statements made regarding findings that are not tied to data. One example of this is the question of data exfiltration; often exfiltration is assumed when data has been staged and archived. After all, why would an actor go through the work of collecting, staging, and archiving data if they weren't going to exfiltrate it? But why assume data exfiltration in that case when the data available to illustrate data exfiltration (i.e., packet captures, netflow data, logs, etc.) isn't available; why not simply state that the data was not available?
That's what I attempted to illustrate here. Yes, there is a file on the user's desktop called "PrivaZer.exe", and yes, per Google searches, this program can be used to "delete forensic artifacts". But how do we know that it was, in fact, used to "delete forensic artifacts", if we don't look at the data to see if there were indications that the program was actually run? Think about it...RegEdit could have been used to "delete forensic artifacts", specifically those within the Registry. The user could have used RegEdit to delete the contents of the keys themselves.
However, this activity would have left artifacts itself. RegEdit is an "applet", in MS terms, and one of the artifacts retrieved by the RegRipper applets.pl plugin is the last Registry key that had focus when RegEdit was closed. Not only was this appropriate key (i.e., the RegEdit subkey beneath the Applets key) not present within the 'active' Registry, I did not find an indication of the key having been deleted.
No comments:
Post a Comment