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 solving the puzzles, 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 do nothing more than determine the batch file that a user saved; there was always something more.
We know from the comdlg32.pl plugin the date/time when the batch file was saved.:
Mon Jul 23 16:48:15 2018 Z
REG mpowers - ComDlg32: OpenSavePidlMRU\bat - My Computer\C:\Production\update_app.bat
Creating a micro-timeline using the mpowers UserAssist, RecentApps, and RecentDocs Registry entries, and IE browser history, we get some additional detail:
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, less than an hour after saving the batch file, the user launched it. Incorporating this information into an overall timeline of system activity, or using it as a pivot point within such a timeline, we would see effects of the batch file within the file system.
As it is, viewing the contents of the batch file, we can see that it includes two copy commands, each of which copies a file from a Z:</i> volume to the C:\Production folder.
We can see from our micro-timeline of user activity that the mpowers user accessed the Z:</i> volume pretty extensively. But where does that 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. But what 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:</i> volume.
Also, we have a lot more information about this batch file. Looking at the micro-timeline, 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, neither of those files appear in that folder. 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<br />dir Z:\project_0x02\tcontinuous\dist<br />dir Z:\project_0x02\tcontinuous\production<br />copy Z:\project_0x02\tcontinuous\production\tcontinuous.exe C:\Production<br />$PSVersionTable.PSVersion.toString()
Creating a micro-timeline of PowerShell events 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
In this case, we have a good bit of information available to us from these logs, but 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. The events 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. 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 a batch file was used.
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.
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.
Article Link: https://windowsir.blogspot.com/2019/05/defcon-2018-ctf-plus.html