After engaging with the first image from the DefCon 2018 CTF, I thought it would be fun, and instructive, to take a look at the second image in the CTF, the File Server.
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.
DefCon 2018 CTF Plus
I don't often engage in CTFs. Yes, they're fun, but even when an effort is made to have various aspects or stages be representative of real-world use cases, overall, they don't tend to hit the mark. I've done some of the various challenges, and once or twice been part of the test team for CTF challenges.
Not too long ago, I ran across David Cowen's blog post for the DefCon 2018 CTF. I wanted to run through at least the first image, but I didn't want to sign up for the challenge...I was just hoping to find the scenario or questions. Phill pointed me to Google, and I found a couple of sites that included the individual questions, along with responses (HackStreetBoys, InfoSecurityGeek, Caffeinated4n6).
If you look at the questions answered at each of the linked sites, you'll see that there are some commonalities in answering the individual questions in the CTF, and in other cases, there are a few differences. One example of differences is for the question, What was the name of the batch file saved by mpowers? The HackStreetBoys opted to use the MFT, while Caffeinated4n6 went with Registry Explorer. I chose to use the RegRipper comdlg32.pl plugin, and we all arrived at the same answer. This is not to say that one method was better than another, as we all got to the same correct response.
However, IRL, this isn't likely where things will stop. In my experience, there haven't been many (re: none) customers who have asked me to simply determine the batch file that a user saved, and leave it at that; with real-world DFIR, there was always something more to it. As such, I decided to use the question (the one about the batch file being written) as a starting point, and build out an analysis approach that was a bit closer to the sort of thing that you would see as a DFIR consultant, or even as an analyst in an FTE position within a company.
We can see in a timeline of overall system activity when the batch file was created:
Mon Jul 23 16:15:06 2018 Z
FILE - .A.B [169] C:\Production\update_app.bat
We can also see when the file was last modified:
Mon Jul 23 17:35:35 2018 Z
FILE - MA.. [48] C:\Users\mpowers\AppData\Roaming\Notepad++\backup\
FILE - M... [169] C:\Production\update_app.bat
Taking a look at the MFT record for the file, we can confirm this:
166116 FILE Seq: 4 Links: 2
[FILE],[BASE RECORD]
.\Production\update_app.bat
M: Mon Jul 23 17:35:35 2018 Z
A: Mon Jul 23 16:15:06 2018 Z
C: Mon Jul 23 17:35:35 2018 Z
B: Mon Jul 23 16:15:06 2018 Z
FN: UPDATE~1.BAT Parent Ref: 165091/2
Namespace: 2
M: Mon Jul 23 16:15:57 2018 Z
A: Mon Jul 23 16:15:06 2018 Z
C: Mon Jul 23 16:15:57 2018 Z
B: Mon Jul 23 16:15:06 2018 Z
FN: update_app.bat Parent Ref: 165091/2
Namespace: 1
M: Mon Jul 23 16:15:57 2018 Z
A: Mon Jul 23 16:15:06 2018 Z
C: Mon Jul 23 16:15:57 2018 Z
B: Mon Jul 23 16:15:06 2018 Z
[$DATA Attribute]
[RESIDENT]
File Size = 169 bytes
A couple of other bits of information from the MFT record...it doesn't appear as if the file was time stomped, and the file is resident within the record. This isn't surprising, given the size, but it would have an effect on our ability to recover indications of the file, should it be deleted.
Creating a micro-timeline using the mpowers UserAssist, RecentApps, and RecentDocs Registry entries, and IE browser history, we can get a good bit of additional detail regarding just that user's activity. Pivoting into that micro-timeline with the name of the batch file, we can see from the comdlg32.pl plugin the date/time when the batch file was accessed by the user:
Mon Jul 23 16:48:15 2018 Z
REG mpowers - ComDlg32: OpenSavePidlMRU\bat - My Computer\C:\Production\update_app.bat
Continuing to search the micro-timeline for indications of the batch file, we see:
Mon Jul 23 17:35:53 2018 Z
REG mpowers - [Program Execution] UserAssist - C:\Production\update_app.bat (3)
REG mpowers - C:\Production\update_app.bat (3)
In short, not only do we see the file being created and saved, but we can see that the file was executed. This is huge! A batch file, or even malware, sitting on a system is harmless. It doesn't do anything until its launched or executed. Viewing the contents of the batch file within FTK Imager, we can see that it includes two copy commands, each of which copies a file from a Z:\ volume to the C:\Production folder. Incorporating the user-specific timeline information into an overall timeline of system activity as an 'overlay', or using it as a pivot point into the system timeline, we can see the effects that the batch file being executed has upon its overall eco-system (the server file system, Registry, Windows Event Log, etc.)
Using the contents of the batch file as a pivot point, we can see from the micro-timeline of user activity that the mpowers user accessed the Z:\ volume pretty extensively. But where does that volume come from? Is it a USB device? Checking the Software and System hives for indications of connected USB devices reveals that there isn't a great deal of information available to indicate the use of a USB device. How about a mapped share? Our micro-timeline reveals the following:
Mon Jul 23 16:01:14 2018 Z
REG mpowers - ShellBags - Desktop\My Computer\Z:\project_0x02\tcontinuous\dist
Mon Jul 23 16:00:53 2018 Z
REG mpowers - Map Network Drive MRU - \\74.118.139.11\M4Projects
While not directly conclusive, the timing of the above events is close enough that we may be able to reasonably tie the mapped folder to the Z:\ volume.
Further, we still have a good bit of information about the batch file itself. Looking at the micro-timeline, and pivoting on the batch file name without the extension, we see references to update_app.ps and update_app.ps1, both apparently located (per the mpowers micro-timeline) in the C:\Production folder. However, viewing the image via FTK Imager, neither of those files appear in that folder. Searching the overall timeline of system activity similarly provides no indication of the files. These look like they may be PowerShell scripts, but again, we don't see them in the 'active' file system within the image.
Checking the contents of the mpowers ConsoleHost_history.txt file, we see the following:
cd C:\Production\
dir Z:\project_0x02\tcontinuous\dist\
dir Z:\project_0x02\tcontinuous\production\
copy Z:\project_0x02\tcontinuous\production\tcontinuous.exe C:\Production\
$PSVersionTable.PSVersion.toString()
Much like a .bash_history file on Linux systems, the ConsoleHost_history.txt file does not contain time stamps. However, it does provide some useful information, in this case indicating that there was some use of PowerShell by the user. Knowing that, and knowing that PowerShell scripts were likely associated with the user, we can create a micro-timeline of PowerShell events, which requires only two commands (note that I've already extracted Windows Event Log files from the image):
wevtx.bat f:\defcon\files\*powershell*.evtx f:\defcon\files\ps_events.txt
...and...
parse -f f:\defcon\files\ps_events.txt > f:\defcon\files\ps_tln.txt
As a result of the commands, we have a good bit of information available to us from the Windows Event Logs, and it is much easier to go through than if we had a full timeline of all system activity. For example, we can easily see clusters of PowerShell/600 events beginning at Mon Jul 23 16:27:51 2018 Z, which include the following:
HostApplication=Powershell.exe -ExecutionPolicy Bypass C:\Production\update_app.ps1
Ah, okay...so it appears that PowerShell was used to attempt to launch this file; our assumption that the .ps and .ps1 files were PowerShell scripts is in the process of being confirmed. However, at the same time, we also see a PowerShell/300 (warning) event that states:
Could not find the drive 'Z:\'. The drive might not be ready or might not be mapped.
Hhhhmmm...for whatever reason, the script seems to have had issues, and possibly not worked. This may be the reason why the user resorted to a batch file.
But wait...there's more...
Mon Jul 23 17:55:30 2018 Z
REG - M... HKLM/Software/ROOT/Microsoft/Windows NT/CurrentVersion/Schedule/TaskCache/Tree/Update App
FILE - .A.B [3874] C:\Windows\System32\Tasks\Update App
From the above we can see that a Scheduled Task was created, and viewing the contents of the XML file, we can see that the task contains the command "C:\Production\update_app.bat". Shortly thereafter, we see:
Mon Jul 23 17:57:17 2018 Z
FILE - .A.B [742400] C:\Production\tthrow.exe
FILE - .A.B [5425251] C:\Production\tcontinuous.exe
Okay, there are the files that were the targets of the 'copy' commands. Shortly after these events in the timeline, we see:
Mon Jul 23 18:07:14 2018 Z
FILE - M... [474] C:\Users\mpowers\AppData\Roaming\Microsoft\Credentials\F03B2BF5CC26D5309225478FE717BB7E
FILE - M... [1806] C:\Windows\debug\PASSWD.LOG
REG - M... HKLM/Software/ROOT/Microsoft/Windows NT/CurrentVersion/Schedule/CredWom/S-1-5-21-2967420476-1305424719-3994513216-1000
FILE - M... [3872] C:\Windows\System32\Tasks\Throw Taco
From the above, we can see that the "Throw Taco" Scheduled Task XML file was modified. The XML contents of the "Throw Taco" Scheduled Task includes:
C:\Production\tcontinuous.exe
tthrow.exe 74.118.139.11:7420
This gives us some information with respect to our two mystery files, the relationship between them, and how they were used (i.e., one was an argument for the other, and they were run with SYSTEM-level privileges). But what about the other entries in the timeline, at the same time? The Registry key that points to "CredWom" includes the SID for the mpowers user, and the last entry in the passwd.log file reads:
07/23 11:07:14 Attempting password change server/domain WIN-29U41M70JCO for user mpowers
So, at this point, we haven't done actual malware RE on the two mystery files, but we do have a good deal of valuable information for an analyst.
Pivoting back to the Scheduled Tasks, we can develop a good view of task execution activity (or history) by using wevtx.bat to parse the Task Scheduler Event Log file into an events file, and then create individual events files for each task using 'find'. From there, using parse.exe to convert the individual events files into micro-timelines gives us the available execution history for the tasks.
Summary
What started out as a straightforward CTF question developed into a much fuller investigation, using timelines (full, micro), overlays, and pivot points, all in order to build out a pretty interesting picture of activity on the system, around not just the user saving the batch file, but the use of the batch file and the relationship to other activity on the system.
Something else of value you can use from the AmCache.hve file is the following:
Mon Jul 23 17:39:12 2018 Z
AmCache - Key LastWrite - c:\production\tthrow.exe (5267b1da851ce675b1f07e0db03fe12eb51ec43e)
Mon Jul 23 17:25:36 2018 Z
AmCache - Key LastWrite - c:\production\tcontinuous.exe (ad2134b5ad9ed046963c458e2152567b6269235f)
Now we have hashes, and in this case, links to VT detections (which won't always be the case).
We've also seen is the value of knowing the version of Windows you're working with; in this case, Windows Server 2016 DataCenter. This informs us as to things such as the version of PowerShell installed (version 5.1.14393.1884), and that the PowerShell Event Log records would be much more inclusive than they were on Windows 7.
The CTF image provides other interesting opportunities, as well, such as working with Volume Shadow Copies, recovering deleted data (from unallocated space, Registry hives, etc.), working with Registry transaction logs, using hindsight to parse a user's Chrome history, etc.
Take-Away
A big take-away from this analysis walk-thru, for me, is that micro-timelines, overlays, and pivot points are extremely useful during analysis. Windows systems are very noisy and verbose, and taking a minimal view of different data sources so that you can begin orienting yourself helps cut through a lot of that noise. A timeline creation process that isn't completely automated provides room for processes that allow the analyst to target specific data sources and develop mini-timelines, and in turn, pivot points.
As an example, the BITS Client Event Log file from the system image has a number of event records, but none of them necessarily have anything to do with the investigation itself, but rather with Windows and Chrome updates. This also means that data sources such as file system metadata, Windows Event Logs, USN change journal, and possibly even the Registry are going to contain a lot of events related to those updates. As such, creating an overall system timeline, but then using micro-timelines to develop pivot points into the overall timeline will allow for iterative, targeted analysis. Developing micro-timelines and then using what's gleaned from them to pivot into the overall system timeline for context is a great way to build out an investigation, and provide the basis for your analysis.
Final Words
I wanted to give a huge thanks and shout-out to David and Matt for putting this CTF together! It's a lot of work to put together a CTF with just minimal artifacts, and they did so with three full images! Thanks so much for making these available!
Not too long ago, I ran across David Cowen's blog post for the DefCon 2018 CTF. I wanted to run through at least the first image, but I didn't want to sign up for the challenge...I was just hoping to find the scenario or questions. Phill pointed me to Google, and I found a couple of sites that included the individual questions, along with responses (HackStreetBoys, InfoSecurityGeek, Caffeinated4n6).
If you look at the questions answered at each of the linked sites, you'll see that there are some commonalities in answering the individual questions in the CTF, and in other cases, there are a few differences. One example of differences is for the question, What was the name of the batch file saved by mpowers? The HackStreetBoys opted to use the MFT, while Caffeinated4n6 went with Registry Explorer. I chose to use the RegRipper comdlg32.pl plugin, and we all arrived at the same answer. This is not to say that one method was better than another, as we all got to the same correct response.
However, IRL, this isn't likely where things will stop. In my experience, there haven't been many (re: none) customers who have asked me to simply determine the batch file that a user saved, and leave it at that; with real-world DFIR, there was always something more to it. As such, I decided to use the question (the one about the batch file being written) as a starting point, and build out an analysis approach that was a bit closer to the sort of thing that you would see as a DFIR consultant, or even as an analyst in an FTE position within a company.
We can see in a timeline of overall system activity when the batch file was created:
Mon Jul 23 16:15:06 2018 Z
FILE - .A.B [169] C:\Production\update_app.bat
We can also see when the file was last modified:
Mon Jul 23 17:35:35 2018 Z
FILE - MA.. [48] C:\Users\mpowers\AppData\Roaming\Notepad++\backup\
FILE - M... [169] C:\Production\update_app.bat
Taking a look at the MFT record for the file, we can confirm this:
166116 FILE Seq: 4 Links: 2
[FILE],[BASE RECORD]
.\Production\update_app.bat
M: Mon Jul 23 17:35:35 2018 Z
A: Mon Jul 23 16:15:06 2018 Z
C: Mon Jul 23 17:35:35 2018 Z
B: Mon Jul 23 16:15:06 2018 Z
FN: UPDATE~1.BAT Parent Ref: 165091/2
Namespace: 2
M: Mon Jul 23 16:15:57 2018 Z
A: Mon Jul 23 16:15:06 2018 Z
C: Mon Jul 23 16:15:57 2018 Z
B: Mon Jul 23 16:15:06 2018 Z
FN: update_app.bat Parent Ref: 165091/2
Namespace: 1
M: Mon Jul 23 16:15:57 2018 Z
A: Mon Jul 23 16:15:06 2018 Z
C: Mon Jul 23 16:15:57 2018 Z
B: Mon Jul 23 16:15:06 2018 Z
[$DATA Attribute]
[RESIDENT]
File Size = 169 bytes
A couple of other bits of information from the MFT record...it doesn't appear as if the file was time stomped, and the file is resident within the record. This isn't surprising, given the size, but it would have an effect on our ability to recover indications of the file, should it be deleted.
Creating a micro-timeline using the mpowers UserAssist, RecentApps, and RecentDocs Registry entries, and IE browser history, we can get a good bit of additional detail regarding just that user's activity. Pivoting into that micro-timeline with the name of the batch file, we can see from the comdlg32.pl plugin the date/time when the batch file was accessed by the user:
Mon Jul 23 16:48:15 2018 Z
REG mpowers - ComDlg32: OpenSavePidlMRU\bat - My Computer\C:\Production\update_app.bat
Continuing to search the micro-timeline for indications of the batch file, we see:
Mon Jul 23 17:35:53 2018 Z
REG mpowers - [Program Execution] UserAssist - C:\Production\update_app.bat (3)
REG mpowers - C:\Production\update_app.bat (3)
In short, not only do we see the file being created and saved, but we can see that the file was executed. This is huge! A batch file, or even malware, sitting on a system is harmless. It doesn't do anything until its launched or executed. Viewing the contents of the batch file within FTK Imager, we can see that it includes two copy commands, each of which copies a file from a Z:\ volume to the C:\Production folder. Incorporating the user-specific timeline information into an overall timeline of system activity as an 'overlay', or using it as a pivot point into the system timeline, we can see the effects that the batch file being executed has upon its overall eco-system (the server file system, Registry, Windows Event Log, etc.)
Using the contents of the batch file as a pivot point, we can see from the micro-timeline of user activity that the mpowers user accessed the Z:\ volume pretty extensively. But where does that volume come from? Is it a USB device? Checking the Software and System hives for indications of connected USB devices reveals that there isn't a great deal of information available to indicate the use of a USB device. How about a mapped share? Our micro-timeline reveals the following:
Mon Jul 23 16:01:14 2018 Z
REG mpowers - ShellBags - Desktop\My Computer\Z:\project_0x02\tcontinuous\dist
Mon Jul 23 16:00:53 2018 Z
REG mpowers - Map Network Drive MRU - \\74.118.139.11\M4Projects
While not directly conclusive, the timing of the above events is close enough that we may be able to reasonably tie the mapped folder to the Z:\ volume.
Further, we still have a good bit of information about the batch file itself. Looking at the micro-timeline, and pivoting on the batch file name without the extension, we see references to update_app.ps and update_app.ps1, both apparently located (per the mpowers micro-timeline) in the C:\Production folder. However, viewing the image via FTK Imager, neither of those files appear in that folder. Searching the overall timeline of system activity similarly provides no indication of the files. These look like they may be PowerShell scripts, but again, we don't see them in the 'active' file system within the image.
Checking the contents of the mpowers ConsoleHost_history.txt file, we see the following:
cd C:\Production\
dir Z:\project_0x02\tcontinuous\dist\
dir Z:\project_0x02\tcontinuous\production\
copy Z:\project_0x02\tcontinuous\production\tcontinuous.exe C:\Production\
$PSVersionTable.PSVersion.toString()
Much like a .bash_history file on Linux systems, the ConsoleHost_history.txt file does not contain time stamps. However, it does provide some useful information, in this case indicating that there was some use of PowerShell by the user. Knowing that, and knowing that PowerShell scripts were likely associated with the user, we can create a micro-timeline of PowerShell events, which requires only two commands (note that I've already extracted Windows Event Log files from the image):
wevtx.bat f:\defcon\files\*powershell*.evtx f:\defcon\files\ps_events.txt
...and...
parse -f f:\defcon\files\ps_events.txt > f:\defcon\files\ps_tln.txt
As a result of the commands, we have a good bit of information available to us from the Windows Event Logs, and it is much easier to go through than if we had a full timeline of all system activity. For example, we can easily see clusters of PowerShell/600 events beginning at Mon Jul 23 16:27:51 2018 Z, which include the following:
HostApplication=Powershell.exe -ExecutionPolicy Bypass C:\Production\update_app.ps1
Ah, okay...so it appears that PowerShell was used to attempt to launch this file; our assumption that the .ps and .ps1 files were PowerShell scripts is in the process of being confirmed. However, at the same time, we also see a PowerShell/300 (warning) event that states:
Could not find the drive 'Z:\'. The drive might not be ready or might not be mapped.
Hhhhmmm...for whatever reason, the script seems to have had issues, and possibly not worked. This may be the reason why the user resorted to a batch file.
But wait...there's more...
Mon Jul 23 17:55:30 2018 Z
REG - M... HKLM/Software/ROOT/Microsoft/Windows NT/CurrentVersion/Schedule/TaskCache/Tree/Update App
FILE - .A.B [3874] C:\Windows\System32\Tasks\Update App
From the above we can see that a Scheduled Task was created, and viewing the contents of the XML file, we can see that the task contains the command "C:\Production\update_app.bat". Shortly thereafter, we see:
Mon Jul 23 17:57:17 2018 Z
FILE - .A.B [742400] C:\Production\tthrow.exe
FILE - .A.B [5425251] C:\Production\tcontinuous.exe
Okay, there are the files that were the targets of the 'copy' commands. Shortly after these events in the timeline, we see:
Mon Jul 23 18:07:14 2018 Z
FILE - M... [474] C:\Users\mpowers\AppData\Roaming\Microsoft\Credentials\F03B2BF5CC26D5309225478FE717BB7E
FILE - M... [1806] C:\Windows\debug\PASSWD.LOG
REG - M... HKLM/Software/ROOT/Microsoft/Windows NT/CurrentVersion/Schedule/CredWom/S-1-5-21-2967420476-1305424719-3994513216-1000
FILE - M... [3872] C:\Windows\System32\Tasks\Throw Taco
From the above, we can see that the "Throw Taco" Scheduled Task XML file was modified. The XML contents of the "Throw Taco" Scheduled Task includes:
C:\Production\tcontinuous.exe
tthrow.exe 74.118.139.11:7420
This gives us some information with respect to our two mystery files, the relationship between them, and how they were used (i.e., one was an argument for the other, and they were run with SYSTEM-level privileges). But what about the other entries in the timeline, at the same time? The Registry key that points to "CredWom" includes the SID for the mpowers user, and the last entry in the passwd.log file reads:
07/23 11:07:14 Attempting password change server/domain WIN-29U41M70JCO for user mpowers
So, at this point, we haven't done actual malware RE on the two mystery files, but we do have a good deal of valuable information for an analyst.
Pivoting back to the Scheduled Tasks, we can develop a good view of task execution activity (or history) by using wevtx.bat to parse the Task Scheduler Event Log file into an events file, and then create individual events files for each task using 'find'. From there, using parse.exe to convert the individual events files into micro-timelines gives us the available execution history for the tasks.
Summary
What started out as a straightforward CTF question developed into a much fuller investigation, using timelines (full, micro), overlays, and pivot points, all in order to build out a pretty interesting picture of activity on the system, around not just the user saving the batch file, but the use of the batch file and the relationship to other activity on the system.
Something else of value you can use from the AmCache.hve file is the following:
Mon Jul 23 17:39:12 2018 Z
AmCache - Key LastWrite - c:\production\tthrow.exe (5267b1da851ce675b1f07e0db03fe12eb51ec43e)
Mon Jul 23 17:25:36 2018 Z
AmCache - Key LastWrite - c:\production\tcontinuous.exe (ad2134b5ad9ed046963c458e2152567b6269235f)
Now we have hashes, and in this case, links to VT detections (which won't always be the case).
We've also seen is the value of knowing the version of Windows you're working with; in this case, Windows Server 2016 DataCenter. This informs us as to things such as the version of PowerShell installed (version 5.1.14393.1884), and that the PowerShell Event Log records would be much more inclusive than they were on Windows 7.
The CTF image provides other interesting opportunities, as well, such as working with Volume Shadow Copies, recovering deleted data (from unallocated space, Registry hives, etc.), working with Registry transaction logs, using hindsight to parse a user's Chrome history, etc.
Take-Away
A big take-away from this analysis walk-thru, for me, is that micro-timelines, overlays, and pivot points are extremely useful during analysis. Windows systems are very noisy and verbose, and taking a minimal view of different data sources so that you can begin orienting yourself helps cut through a lot of that noise. A timeline creation process that isn't completely automated provides room for processes that allow the analyst to target specific data sources and develop mini-timelines, and in turn, pivot points.
As an example, the BITS Client Event Log file from the system image has a number of event records, but none of them necessarily have anything to do with the investigation itself, but rather with Windows and Chrome updates. This also means that data sources such as file system metadata, Windows Event Logs, USN change journal, and possibly even the Registry are going to contain a lot of events related to those updates. As such, creating an overall system timeline, but then using micro-timelines to develop pivot points into the overall timeline will allow for iterative, targeted analysis. Developing micro-timelines and then using what's gleaned from them to pivot into the overall system timeline for context is a great way to build out an investigation, and provide the basis for your analysis.
Final Words
I wanted to give a huge thanks and shout-out to David and Matt for putting this CTF together! It's a lot of work to put together a CTF with just minimal artifacts, and they did so with three full images! Thanks so much for making these available!
Deep Knowledge, and the Pursuit Thereof
When IR was largely DF-related work, relatively few in the industry held deep knowledge of artifacts. Over the years, IR has moved from "image all the things" to "find and image the impacted systems" to "let's deploy an enterprise agent or sensor and collect data from all the things". As the need for enterprise-wide response became more evident, we developed concepts such as "triage", or collecting specific, targeted data from systems to make a decision as to whether they were "in scope" or not. We adapted concepts such as "sniper forensics", seeking out that targeted data, from disk forensics to the enterprise. As we've moved to this enterprise-scale response, including deploying sensors, agents, and automated means of data collection and parsing, we need to ensure that we continue to progress beyond where we were before, in that practitioners can be even further removed from developing a deep knowledge of the data. This isn't to say that this is the case for all analysts; being absolute would be both incorrect and pointless.
As tools and frameworks have been specifically designed for addressing the enterprise issue, deep knowledge of systems and artifacts can potentially remain with a few, rather than opening the door and extending that knowledge for the many. As practitioners, we have to be wary of tools and frameworks blinding us to the deep knowledge of the nature and context of the data itself.
Many, many moons ago, back when I was QSA-certified and conducting PCI examinations (ssshhh...don't tell anyone...), our team was using a commercial forensic suite to perform searches across acquired images for credit card numbers (CCNs). Our assumption was that the commercial product performed as advertised, in that it found "valid" CCNs, per the definition of the PCI Council (which, at the time, was Visa). We had three checks at the time...BIN, length, and Luhn...and if the CCN that was found passed all three, it was passed along to the appropriate card brand for verification. At one point, we had a case for which we knew CCNs from two specific brands had been used, but running the commercial product produced no results for those brands. Our initial query with respect to what the product considered a "valid" CCN resulted in a link to a wiki page on credit card numbers, but did nothing to explain why we weren't received the expected result. Finally, a deeper investigation, which included further questions and no small amount of testing, revealed that the product at the time did not consider some valid CCNs to be "valid". Rather than waiting for the core, underlying code to be updated, we opted to go with 7 distinct regexs; while this slowed the search process down, it did give us the needed capability.
My point is that all of this came from a few analysts who were close to the data, and had 'deep knowledge' of the artifacts. Or, at least deep enough to know where they needed to go deeper than what the tool was presenting. At the time, this was not something that was plastered all over the Internet; no, it was these few analysts who were looking at the issue, and subsequently, wondering what else had been missed.
When I first released RegRipper over a decade ago, my intention was for it to be a community-based tool. There was one thing that I was absolutely sure of...I would never see everything there was to see, even in the Registry, nor would I know everything there was to know. As such, I wanted to provide a means by which analysts could either write their own plugins (some did, starting with copy-paste...) and share them with the community, or reach out and share data so that a plugin could be written or updated. Over the years, more than a few have done so, but for the most part, those who use the tool do so by downloading and running it.
In 2013, Corey Harrell released auto_rip, a tool that brought a modicum of automation to RegRipper. In releasing it, Corey stepped on to the path of sharing his thought process when it came to analysis; in auto_rip, Corey shared how he structures the collected data for analysis, moving RegRipper from a point-and-fire tool to one used to take a targeted approach to data parsing and presentation. Much more recently, Silv3rHorn released autoripy, in part because auto_rip hadn't been updated in some time.
Nuix has a free extension for their Workstation product for automating the use of RegRipper (and one for Yara, as well), and automatically incorporating the results directly into your Nuix 'case'. This extension automates almost all of what an analyst would need to do to run RegRipper; it automatically locates the hives (independent of the version of Windows), and runs plugins based on the profiles for each hive. But remember, I said, "almost". The analyst has to download RegRipper themselves, as well as ensure that the profiles for each hive are updated, based on the currently available plugins. This is easy enough to do, as the command line tool for RegRipper (i.e., 'rip') includes a switch for automating this process. But this isn't something that the extension does; to make the best use of the extension, the analyst needs to do just a little bit more work.
The question then becomes, are you doing it? Or are you downloading RegRipper and running it via the extension, with no modifications? Are you pulling everything you need for your case from the Registry hives, or are you relying on the tool to do it for you?
While I have a great appreciation and fondness for automation, and respect for the effort that goes into creating automation, my concern with regard to tools such as RegRipper, log2timeline, plaso, KAPE, etc., is that rather than pulling back the "veil of mystery" and making the data more accessible (and therefore, more within their realm of knowledge) to the analyst, and thereby increasing deep knowledge in a much wider range of analysts, the result is the opposite. Instead, are we allowing automation, particularly at the enterprise level, to add additional layers of abstraction between the data and the analyst?
Don't get me wrong...I'm not bashing tools such as plaso, KAPE, or any other tools like them. Not at all. If it makes someone's job easier and more efficient, that's awesome. It doesn't matter if it's a full-blown compiled application or a batch file...if it works, so be it. All of these things are wonderful. But as practitioners, we have to be careful about how we view and use the tools.
A side effect (or ancillary effect, depending upon how you look at it) of this is that the community has weaponized terms like 'expert' and 'authority'. These terms are used to set their designees apart, unreachable and untouchable. "They're the expert, so all of the functionality I would need must be included in that tool that they released for free, and it's not something I need to concern myself with."
Circling back to RegRipper, I don't know everything there is to know about the Windows Registry, and I certainly don't have any insight into your analysis goals, nor the data you're currently examining. If you've updated RegRipper with the latest set of plugins, there's no guarantee that there are plugins that will extract and parse the data pertinent to your case. There may be a plugin that parses data from an older version of that application the user launched, but it hasn't been updated in 8 years. Or maybe the user used an application for which no plugin exists.
Tool and framework development is great; what better to make your work go quicker, more efficient, and less error prone than automation? And I don't expect that all of a sudden, everyone will know everything; again, that just doesn't make sense. However, as practitioners, we shouldn't rely on these tools and frameworks to automagically provide all of the data needed for our case, parsed and displayed for our analysis. Instead, we need to be vigilant, and ensure that we're looking at such things with a critical eye.
My hope is that more folks in the DFIR industry will use these tools and frameworks as a means to develop deeper knowledge of the data and artifacts, rather than an excuse to not do so.
As tools and frameworks have been specifically designed for addressing the enterprise issue, deep knowledge of systems and artifacts can potentially remain with a few, rather than opening the door and extending that knowledge for the many. As practitioners, we have to be wary of tools and frameworks blinding us to the deep knowledge of the nature and context of the data itself.
Many, many moons ago, back when I was QSA-certified and conducting PCI examinations (ssshhh...don't tell anyone...), our team was using a commercial forensic suite to perform searches across acquired images for credit card numbers (CCNs). Our assumption was that the commercial product performed as advertised, in that it found "valid" CCNs, per the definition of the PCI Council (which, at the time, was Visa). We had three checks at the time...BIN, length, and Luhn...and if the CCN that was found passed all three, it was passed along to the appropriate card brand for verification. At one point, we had a case for which we knew CCNs from two specific brands had been used, but running the commercial product produced no results for those brands. Our initial query with respect to what the product considered a "valid" CCN resulted in a link to a wiki page on credit card numbers, but did nothing to explain why we weren't received the expected result. Finally, a deeper investigation, which included further questions and no small amount of testing, revealed that the product at the time did not consider some valid CCNs to be "valid". Rather than waiting for the core, underlying code to be updated, we opted to go with 7 distinct regexs; while this slowed the search process down, it did give us the needed capability.
My point is that all of this came from a few analysts who were close to the data, and had 'deep knowledge' of the artifacts. Or, at least deep enough to know where they needed to go deeper than what the tool was presenting. At the time, this was not something that was plastered all over the Internet; no, it was these few analysts who were looking at the issue, and subsequently, wondering what else had been missed.
When I first released RegRipper over a decade ago, my intention was for it to be a community-based tool. There was one thing that I was absolutely sure of...I would never see everything there was to see, even in the Registry, nor would I know everything there was to know. As such, I wanted to provide a means by which analysts could either write their own plugins (some did, starting with copy-paste...) and share them with the community, or reach out and share data so that a plugin could be written or updated. Over the years, more than a few have done so, but for the most part, those who use the tool do so by downloading and running it.
In 2013, Corey Harrell released auto_rip, a tool that brought a modicum of automation to RegRipper. In releasing it, Corey stepped on to the path of sharing his thought process when it came to analysis; in auto_rip, Corey shared how he structures the collected data for analysis, moving RegRipper from a point-and-fire tool to one used to take a targeted approach to data parsing and presentation. Much more recently, Silv3rHorn released autoripy, in part because auto_rip hadn't been updated in some time.
Nuix has a free extension for their Workstation product for automating the use of RegRipper (and one for Yara, as well), and automatically incorporating the results directly into your Nuix 'case'. This extension automates almost all of what an analyst would need to do to run RegRipper; it automatically locates the hives (independent of the version of Windows), and runs plugins based on the profiles for each hive. But remember, I said, "almost". The analyst has to download RegRipper themselves, as well as ensure that the profiles for each hive are updated, based on the currently available plugins. This is easy enough to do, as the command line tool for RegRipper (i.e., 'rip') includes a switch for automating this process. But this isn't something that the extension does; to make the best use of the extension, the analyst needs to do just a little bit more work.
The question then becomes, are you doing it? Or are you downloading RegRipper and running it via the extension, with no modifications? Are you pulling everything you need for your case from the Registry hives, or are you relying on the tool to do it for you?
While I have a great appreciation and fondness for automation, and respect for the effort that goes into creating automation, my concern with regard to tools such as RegRipper, log2timeline, plaso, KAPE, etc., is that rather than pulling back the "veil of mystery" and making the data more accessible (and therefore, more within their realm of knowledge) to the analyst, and thereby increasing deep knowledge in a much wider range of analysts, the result is the opposite. Instead, are we allowing automation, particularly at the enterprise level, to add additional layers of abstraction between the data and the analyst?
Don't get me wrong...I'm not bashing tools such as plaso, KAPE, or any other tools like them. Not at all. If it makes someone's job easier and more efficient, that's awesome. It doesn't matter if it's a full-blown compiled application or a batch file...if it works, so be it. All of these things are wonderful. But as practitioners, we have to be careful about how we view and use the tools.
A side effect (or ancillary effect, depending upon how you look at it) of this is that the community has weaponized terms like 'expert' and 'authority'. These terms are used to set their designees apart, unreachable and untouchable. "They're the expert, so all of the functionality I would need must be included in that tool that they released for free, and it's not something I need to concern myself with."
Circling back to RegRipper, I don't know everything there is to know about the Windows Registry, and I certainly don't have any insight into your analysis goals, nor the data you're currently examining. If you've updated RegRipper with the latest set of plugins, there's no guarantee that there are plugins that will extract and parse the data pertinent to your case. There may be a plugin that parses data from an older version of that application the user launched, but it hasn't been updated in 8 years. Or maybe the user used an application for which no plugin exists.
Tool and framework development is great; what better to make your work go quicker, more efficient, and less error prone than automation? And I don't expect that all of a sudden, everyone will know everything; again, that just doesn't make sense. However, as practitioners, we shouldn't rely on these tools and frameworks to automagically provide all of the data needed for our case, parsed and displayed for our analysis. Instead, we need to be vigilant, and ensure that we're looking at such things with a critical eye.
My hope is that more folks in the DFIR industry will use these tools and frameworks as a means to develop deeper knowledge of the data and artifacts, rather than an excuse to not do so.