February 2019 - Stark 4N6

Friday, February 22, 2019

CTF on a Budget - Magnet User Summit 2018 (Part 3)
February 22, 20190 Comments

For part 3, we are looking at the exfiltration section.


1. Application for Exfil: Which application was used to exfiltrate data on the compromised system? 

My first thought was to see what was installed so I took a peek in Program Files and Program Files (x86) as well as what the SOFTWARE registry file had. There was nothing of interest there so I decided to parse shellbags with SBECmd for each user and in doing so I came across Dropbox under "itsupport". This lead to finding the installer for Dropbox on the desktop as well.

2. Browser to Download Dropbox: Which browser was used to download the application that exfiltrated the data?

From previous questions, we knew Edge was a possibility. Google Chrome and Mozilla Firefox were also shown to be installed on the system. In parsing internet history for them all using BrowserHistoryView we don't see anything relevant to Dropbox. Something that did catch my eye in the Firefox history was a download for Maxthon mx5, a lesser known browser (which I only learned about during this CTF).

Digging through the folder structure from AppData we come across a task file:


In plain text we can see the download information for Dropbox including the download location, the executable name, and the URL path it came from:


3. Data Exfiltrated: How much data was sent out via the application exfiltrating the data? [answer in bytes]

Going back to our SRUM output we grabbed for a previous question using srum_dump, we can look at NetworkUsage this time. We can open the CSV into TimelineExplorer, filter on application name and easily see that 1363639 bytes were sent.

Wednesday, February 20, 2019

CTF on a Budget - Magnet User Summit 2018 (Part 2)
February 20, 20190 Comments

In part 1 we broke down the answers to the Miscellaneous category .As we continue on through the Magnet User Summit 2018 CTF we now get to the Anti-Forensics section.In this section I got to use some different free tools as well as some tried and true along the way to answer the questions.


1. Wiping App: Which application was used to wipe files on the compromised system?

In the SOFTWARE registry file we can see a list of installed applications in:
Microsoft\Windows\CurrentVersion\App Paths

The only one that sticks out is Eraser, which is the answer.

2. User that Wiped: What is the name of the user account that performed the wiping? [use a name not a SID]

We found the Eraser installer in the downloads folder for user "itsupport". This doesn't mean this account ran it but gave us a clue to who to look at first. When we parse the NTUSER.DAT file using RegRipper, we can pull out the appcompatflags showing that Eraser.exe was run
This date and time was corroborated by the prefetch file of the Eraser.exe as well so we can determine that "itsupport" ran the executable.

3. Data Written: How much data did the wiping utility write to disk? [answer in bytes] 

Now that we know Eraser was run we can look at the SRUM (System Resource Utilization Monitor) log found here:


We can parse this file using SRUM Dump. We want to look at the Application Resourch Usage tab, and since we know that Eraser was run on April 26th at approximately 6:40pm UTC, we can date filter and filter on the executable name. The only entry that matches is:

We can see the ForegroundBytesWritten column shows how many bytes were written to disk, 27394048.

4. Browser to Download Wiper: What browser was used to download Eraser? [Just the name, no versions]

This one was fairly easy even though I sort of stumbled upon it. Parsing the NTUSER.DAT file for "itsupport" using RegRipper we can see that the Eraser installer was executed. In UserAssist we see that it resided under a Microsoft Edge temp folder, probably set to run after download instead of saving.

1524767943|REG|||[Program Execution] UserAssist - C:\Users\itsupport\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\TempState\Downloads\Eraser (1)

5. Wiped File Names: List 5 original wiped file names. [comma separated]

There were a ton of file names that could have worked for this. What we need to do first is parse the $J file of USNJrnl. I used MFTECmd as this has a switch for it and runs super fast. After it was parsed to CSV I threw that into TimelineExplorer. We can filter down to the date of execution 4/26/2018 and scroll down to the approximate time of 18:41 and we will see some interesting activity.

If you filter the column "Update Reasons" with Rename, you will get a list of old and new file names.

Some sample answers are:


Monday, February 18, 2019

CTF on a Budget - Magnet User Summit 2018 (Part 1)
February 18, 20190 Comments

Last year during the Magnet User Summit, I was able to participate in the excellent CTF from Dave and Matt of G-C Partners. I had so much fun and learned a lot from doing it but I wanted to revisit it before it gets shut down and see if I could answer the questions using only free tools instead of parsing it through AXIOM. The other benefit was to brush up on my knowledge for this year's upcoming challenge.

In this first segment we will take a look at the Miscellaneous category for the CTF.

The first thing I did was use the latest version of KAPE from Eric Zimmerman and fine folks over at Kroll to pull out a bunch of useful files.


1. Timezone: What is the system's timezone set to?

Using RegistryExplorer, drill down into the SYSTEM registry file and go to:

Mountain Standard Time is the timezone.

2. File Sequence Number: What is the MFT file sequence number for the Python27\python.exe file? [This is not the MFT entry number]

Parsing the $MFT file with Eric Zimmerman's MFTECmd, and then dropping the output into TimelineExplorer, you can filter on the file name. This shows a sequence number of 1 for python.exe.

3. FileName Lookup: What is the name of the file that has MFT entry of 86280?

Parsing the $MFT file with Eric Zimmerman's MFTECmd, and then dropping the output into TimelineExplorer, you can filter on Entry Number to show the result, $USNJrnl.

4. FileTimestamp: What is the Standard Information Attribute's Access timestamp of the Windows\Prefetch\CMD.EXE-89305D47.pf file? [UTC in YYYY-MM-DD hh:mm:ss format]

With the MFT still loaded into TimelineExplorer you can filter on the file name and look at the LastAccessed field
So putting the date/time into the requested format you get: 2018-04-26 15:48:40.

5. VSN-C: What is the C: volumes' serial number?

You can look at the $Boot file and go to offset hex 0x48-51 (it will be listed in little endian). An easier way to find this is to load the E01 file into FTK Imager, click on the  C: volume and look at the Properties

6. YouTube Search: What term was searched in YouTube on 3/28/2018?

After loading the E01 into Autopsy you can parse for Internet history, sorting on date stamp and looking for YouTube. Parsed from the Firefox history:

The answer is "simpsons max power".

7. Sleuthkit + PowerShell: Max Powers was playing with ways he could extract files using Sleuthkit and PowerShell. What was the exact command he used in attempting to extract the SRUM database?

PowerShell command history can be found at the following link for user Max Powers:


Searching for SRUM in the text document you see only one line pertaining to it:

$inode = ifind -n /Windows/System32/sru/SRUDB.dat \\.\C: ; icat \\.\C: $inode > SRUDB.dat

8. Administrator Logon Count: How many times did Administrator logon to the system?

We first want to pull out the SAM registry file and parse it with RegRipper. We can run the "samparse" plugin to pull out the information we want

You can see that the login count for Administrator was 14.

9. Install Q: What day was the Go programming language installed on? [Answer format: YYYY-MM-DD

Loading the SOFTWARE registry file into RegistryExplorer, a quick search for "Go programming" lists the install entry for the program. The key value InstallDate shows the date the program was installed.
Autopsy also automatically parses it out nicely too

The answer is 2018-04-11.

10. Who Installed Atom?: Which user installed Atom? [Answer is the complete SID not the username]

When doing a keyword search for Atom, we see hits for the executable downloaded by Max Powers profile. We also see that Atom.exe is loaded into the AppCompatCache found in the NTUSER.DAT file for Max Powers. You can get the SID's for each user parsed from the SOFTWARE registry file.

The answer is "S-1-5-21-2801897208-1878083585-4182000528-1002".

11. Deletion in LogFile: The $LogFile shows at LogFile Sequence Number [LSN] 4433927454 a file is deleted. What is the name of the file that was deleted?

For this, we exported the $LogFile from the root of C: and parsed it using LogFileParser. When looking at the CSV in TimelineExplorer, you can search for the LSN.

As you can see from the screenshot, the LSN previous listed for that entry has a file name of "7z.dll".

And that is all for Part 1, the Miscellaneous category. Look for more write-ups and answers later this week.

Friday, February 1, 2019

Shellbags, Folder Views, and Windows Explorer
February 01, 20191 Comments

I always enjoy working on a Sunday Funday challenge from Dave that I can actually do (I'm terrible at scripting). So I decided to do some research and see what I could find.

It's been well documented just how shellbags work in terms of folder traversing and accessing but not as much information is shown in regards to some of the viewing settings for folders.

DISCLAIMER: Testing was done with Win7, so results may vary on Win10.

1. What within the shellbags entry would tell you how the user had set their directory viewing preferences (sort order, thumbnail view, standard view)?

You would first want to open up the following registry path:


I prefer to use RegistryExplorer for this but there are multiple tools that can do the job. I also used ShellBagsView to help quickly correlate Bag # to a specific folder. We see the following 12 keys for the shell which we will breakdown:

I'm not entirely sure what Vid is but I'm going to assume here that it is the volume identifier (it was consistent across all the shells I looked at).

Sort is an obvious one, it determines what column is currently sorted on and if it is ascending or descending. After running RegistryChangesView, while sorting the Name column from ascending to descending you can see the last 4 bytes of hex change:

So it appears that the "01 00 00 00" refers to Ascending sort and "FF FF FF FF" refers to Descending. When sorting by Type, 24 extra bytes got added to the entry:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0A 00 00 00 01 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 04 00 00 00 01 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0A 00 00 00 01 00 00 00 

What we see is that when sorting by Type, it is actually sorting the Name column as well so that's where the added bytes are coming from (in green). The first 20 bytes don't seem to be important other than a change counter perhaps of how many columns sorted (went from 1 to 2 in yellow). I'm not sure what the first 16 bytes of each 24 byte chunk detail either (maybe a specific folder identifier?). Bytes 17-20 refer to the column being sorted (BOLD) and ITALICS is the bytes reflecting the Ascending/Descending:

0A 00 00 00 = Name
04 00 00 00 = Type
0E 00 00 00 = Date Modified
0F 00 00 00 = Date Created
0C 00 00 00 = Size

There are too many columns to do individual testing on each (at this time).

Rev seemed to be a switch (either 0, 1, 2), which lined up as follows:

0 - Blank (default?)
1 - Tiles
2 - Details

Below is a chart of the separate values for keys Mode, LogicalViewMode and IconSize (hex) that correlate with the different visual settings for folder contents in which Rev seems to be related:

StyleModeLogicialViewModeIconSize (In Pixels)
Extra Large Icons53256
Large Icons53128
Medium Icons5348
Small Icons2332
Tiles6, 8216

GroupView got assigned the value 4294967295 every time I chose an option from Windows Explorer:

GroupByKey:FMTID always seemed to be the same value every time as well so not sure of it's significance other than Microsoft being Microsoft.

For GroupByKey:PID, each category of grouping got an assigned PID value:

Date Modified14
File Version4

I chose my default columns for testing but I'm sure as above with the sorting, each column will get a PID number (some may be duplicative as seen with Type and File Version).

Just a sample showing the change of value from 0 to 10 for Grouping by Name.

GroupByDirection was fairly easy to figure out:
0 = Ascending
1 = Descending

FFlags was a trickier one to actually get to work. I was only able to get it to change when a new shellbag was created, altering the value from default 1092616193 to blank. There could be more options that Win10 has for flipping these switches.

ColInfo needed some massaging but from the look of the data, it is keeping tracking of what columns are shown and in what order they appear in Windows Explorer. Here we have the default hex value of a folder with the standard 4 columns, Name, Date Modified, Type and Size (formatted for better viewing purposes).

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FD DF DF FD 10 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 18 00 00 00

30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0A 00 00 00 E9 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0E 00 00 00 7E 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 04 00 00 00 50 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0C 00 00 00 50 00 00 00

What we see is some buffer information (possibly something relevant) in line 2 then we see the yellow hex which looks like it is a count of columns. We then see the 4 columns in lines 3-6, the same 20 bytes up until the last 4 (exact same bytes as above in Sort). Once we add the column for File Version we get this in ColInfo:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FD DF DF FD 10 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00 18 00 00 00

30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0A 00 00 00 E9 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0E 00 00 00 7E 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 04 00 00 00 50 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0C 00 00 00 50 00 00 00
53 7D EF 0C 64 FA D1 11 A2 03 00 00 F8 1F ED EE 04 00 00 00 A0 00 00 00

The hex in yellow gets a bump to 5 and we see the extra column information in purple. The last test I did was to move the column File Version from slot 5 to slot 2, see how the hex values changed:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FD DF DF FD 10 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00 18 00 00 00

30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0A 00 00 00 E9 00 00 00
53 7D EF 0C 64 FA D1 11 A2 03 00 00 F8 1F ED EE 04 00 00 00 A0 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0E 00 00 00 7E 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 04 00 00 00 50 00 00 00
30 F1 25 B7 EF 47 1A 10 A5 F1 02 60 8C 9E EB AC 0C 00 00 00 50 00 00 00

The last 4 bytes for each column entry appears to be the width of each column but I don't know what sort of format that interprets to.

2. What is the default view if they don't change anything?

Your default view for all folders can be found at the following path:

HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell\{5C4F28B5-F869-4E84-8E60-F11DB97C5CC7}

Default for me looks like this when a new shellbag is added:

This breaks down to Details view, sorting on Name ascending, 4 columns, and no grouping.

3. If a user attempts to access the system volume information directory and a shellbag entry gets created (it should deny them access) what directory viewing settings are left behind?

A shellbag entry does indeed get created for the folder as you can see from the output:

But when looking in RegistryExplorer at the key entry, you only get the following information:

Some more info on the KnownFolderDerivedFolderType and SniffedFolderType settings here in section

It's amazing that this much information can be pulled out of a few simple values in the registry. While the information is not super significant, if it can help with a case then anything is better than nothing. It just goes to show that there is always more to learn about the Windows operating system.