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:
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!
No comments:
Post a Comment