So, here's a thought...
At a well-attended DFIR conference, there should be a DFIR open mic comedy night. In the evening, after the event is done for the day, use the venue for something a little light-hearted. For example, OSDFCon has had a mixer at the end of one of the days, where there've been finger foods and adult beverages, and there's a bar right there in the lobby. Since the venue already has chairs and a mic, why not use them?
So, Chatham House rules apply, as well as:
No sales pitchesNo shaming anyone, any company or organization, product, etc.Use no names, unless you're sending praise/shout-outsBe cool - a little light profanity isn't an issue, but don't be vulgar or disgusting
I think a lot of folks would enjoy something like this...it's a great way to engage, and provide some folks who maybe didn't get their talk accepted a chance to get up on stage and see how they do with public speaking.
After all, there are a LOT of weird or funny things that go on during an IR engagement. Some may not be funny at the time, but with a little embellishment ("don't let the facts get in the way of a good story...") some time later, they're freakin' hilarious! So why not share these with everyone else?
For example, I did an IR years ago with a global organization, one that had multiple tools available. We'd seen Mimikatz being run in the environment; in fact, the SOC (which was located in another country) had alerted the headquarters organization to this finding. A manager in charge of one the other tools was running searches for "mimikatz" across the infrastructure; unfortunately, one of the detections being used was, "any command line that includes "mimikatz"". This was intended to catch things like "Invoke-Mimikatz", but it caught everything else. The first couple of times this happened, the SOC would send an alert, and the local SOC manager (a guy about 6' 7", 275 lbs, bodybuilder type) would go nuts, telling (well, not "telling", per se...) us that the bad guy was back, while the veins in his head and neck were popping out.
So, not funny at the time, but something we can laugh about now...
Thoughts? Go? No go? Is this something you'd participate in, or just want to watch? Or watch until maybe you got your nerve up (liquid courage) and then got up on stage?
KAPE 0.8.7.0 released!
Changelog - Refactored --sync command to allow for and respect subdirectories in Targets and Modules. --sync will reorganize things based on the KapeFile repo. Configs not in KapeFiles repo end up under !Local directory
- Overhauled Targets and modules organization. Compound targets and modules DO NOT need to be updated to new locations. KAPE will locate the base configs as needed on the fly
- With the new config organization, KAPE can now pull all configs under a directory specified in --target or --module. In this way, directories act like a compound config
- tlist and mlist now expect a path to look for configs. Use . to start. All configs in the provided path are displayed as well as subdirectories
- Added Folder column in gkape in Targets and Modules grids. Grouping by this column makes it easy to see what is in various folders
- Tweaks to transfer setting validation to ensure destination is writable
- Removed --sow switch
- When in SFTP server mode, display the KAPE switches needed to connect to the SFTP server for each defined user. This makes it as easy as copy/paste to tell KAPE to push to SFTP server
- Add --sftpu switch, which defaults to TRUE, that determines whether to display SFTP server user passwords when in SFTP server mode
- Added FollowReparsePoint and FollowSymbolicLinks to Target definition. These are optional and should be used on an as needed basis. The default for both is false if they are not present. This is the behavior KAPE has always had up to this point. Setting to true will follow the reparse or sym link which some programs use (Box, OneDrive, etc)
- Other minor tweaks and nuget updates
The highlights New layout for Targets and ModulesBoth the Targets and Modules directories have been reorganized. This will make it easier going forward to find and add new things in the correct place. The new organization looks like this (partial output):
There are several things to be aware of due to this change.
You can now use the names of the directories in --target and --module switches. This makes directories serve as a type of auto-generated compound configuration. This means something like this: --target WebBrowsers
is functionally the same as:
--target Browsers
assuming WebBrowsers.tkape contains references to each of the tkape files underneath
the Browsers folder.
You DO NOT need to specify the directory name before the config you want, both on the command line AND in compound targets and modules. KAPE will find and resolve everything automagically, so using KAPE has not changed at all in this respect.Read the previous point again.Any Targets and Modules NOT from the KapeFiles repository will be moved to the !Local folder when --sync'ing Target names and modules names must be unique. In other words, do not have a Target named 'MyTarget.tkape' in more than one folder or KAPE will inform you of this. The --tlist and --mlist switches now expect a path after them, like '--tlist .' for example. This will display all the configurations in the specified location, followed by a list of any directories found, like this:
Other changesFor SFTP server mode, the default is to show all the configured users' connection switches (except IP since you have to pick one), like this:
This makes it easy to get up and running quickly with almost no typing at all! Disable this option via '--sftpu false'
Finally, this version also includes updated EZ Tools and new configurations for cloud based storage (Thanks Chad Tilbury!). Along with the new cloud storage stuff are new properties to handle reparse points and symbolic links on a case by case basis. Be sure you test and validate things when using these properties!!
Enjoy and please let me know if you have any issues!!!
- Overhauled Targets and modules organization. Compound targets and modules DO NOT need to be updated to new locations. KAPE will locate the base configs as needed on the fly
- With the new config organization, KAPE can now pull all configs under a directory specified in --target or --module. In this way, directories act like a compound config
- tlist and mlist now expect a path to look for configs. Use . to start. All configs in the provided path are displayed as well as subdirectories
- Added Folder column in gkape in Targets and Modules grids. Grouping by this column makes it easy to see what is in various folders
- Tweaks to transfer setting validation to ensure destination is writable
- Removed --sow switch
- When in SFTP server mode, display the KAPE switches needed to connect to the SFTP server for each defined user. This makes it as easy as copy/paste to tell KAPE to push to SFTP server
- Add --sftpu switch, which defaults to TRUE, that determines whether to display SFTP server user passwords when in SFTP server mode
- Added FollowReparsePoint and FollowSymbolicLinks to Target definition. These are optional and should be used on an as needed basis. The default for both is false if they are not present. This is the behavior KAPE has always had up to this point. Setting to true will follow the reparse or sym link which some programs use (Box, OneDrive, etc)
- Other minor tweaks and nuget updates
The highlights New layout for Targets and ModulesBoth the Targets and Modules directories have been reorganized. This will make it easier going forward to find and add new things in the correct place. The new organization looks like this (partial output):
There are several things to be aware of due to this change.
You can now use the names of the directories in --target and --module switches. This makes directories serve as a type of auto-generated compound configuration. This means something like this: --target WebBrowsers
is functionally the same as:
--target Browsers
assuming WebBrowsers.tkape contains references to each of the tkape files underneath
the Browsers folder.
You DO NOT need to specify the directory name before the config you want, both on the command line AND in compound targets and modules. KAPE will find and resolve everything automagically, so using KAPE has not changed at all in this respect.Read the previous point again.Any Targets and Modules NOT from the KapeFiles repository will be moved to the !Local folder when --sync'ing Target names and modules names must be unique. In other words, do not have a Target named 'MyTarget.tkape' in more than one folder or KAPE will inform you of this. The --tlist and --mlist switches now expect a path after them, like '--tlist .' for example. This will display all the configurations in the specified location, followed by a list of any directories found, like this:
Other changesFor SFTP server mode, the default is to show all the configured users' connection switches (except IP since you have to pick one), like this:
This makes it easy to get up and running quickly with almost no typing at all! Disable this option via '--sftpu false'
Finally, this version also includes updated EZ Tools and new configurations for cloud based storage (Thanks Chad Tilbury!). Along with the new cloud storage stuff are new properties to handle reparse points and symbolic links on a case by case basis. Be sure you test and validate things when using these properties!!
Enjoy and please let me know if you have any issues!!!
Program Execution…Or Not
Over the years, different means have been used to discuss the DFIR analysis process, and one of those has been artifact categories. This is where categories are created and artifacts placed in the various columns, as they relate to those categories. One such example is the SANS IR poster, which provides a great visual reminder for folks looking to employ this approach. Honestly, it is a good way to approach analysis...looking at even a single system image, artifacts have grown over the years as the versions of Windows have progressed from XP to Win7, through to Win10, and as such, it benefits a large portion of the community to have a repeatable approach to analysis.
However, when using approaches such as this, we need to keep in mind the context of the category titles. Yes, the artifacts of "program execution" provide an indication of applications that were launched on a system, but what does that mean?
At this point, I can guess what you're thinking...wait, what?? And believe me, I get it. "Program execution" means exactly that...that a program was executed. End of story. But wait...is that what it really means?
Consider this for a second...someone unfamiliar with a program or application might "open" it on their first try, to see what it does. Command line tools, for example, often contain information about their usage, which we can see by either typing the name of the program at the command prompt (no arguments), or by adding "/?" or "-h" ("--help" for Linuxphiles). This causes the program to run, but not in the sense that the functionality of the program is actually used.
As an example, I opened a command prompt, and changed directories to the C:\Windows\Prefetch folder. Most analysts who've been in the industry for some time are familiar with the application prefetch files, often referred to as simply "Prefetch". Specifically, these are files are widely known as an artifact of "program execution".
I first typed "dir ftp*.pf" to see if there were any Prefetch files that appeared to point to the use of ftp.exe, and got the expected result: File Not Found. Next, I typed "ftp /?" at the prompt, which displayed the usage syntax of the application.
I then retyped (actually, I hit the up arrow twice...) the 'dir' command, and this time, I found that there was a file named FTP.EXE-7BA637EA.pf, which was 2,685 bytes in size.
So, what happened? I ran the program, but only to the point where I could read the usage syntax. I didn't actually use the program to transfer files or exfil data in any way. However, the artifacts of program execution were populated.
Now, the same thing applies to GUI applications, maybe even more so. You can launch a GUI application, look around at the interface, maybe click a few of the options to see what functionality is available, and then close the UI without ever having employed the functionality provided by the application.
Case in point...consider this analysis of the DefCon 2018 CTF file server image. Other publicly available write-ups addressed the question of interest (which application was used to delete forensic artifacts?) with various findings. One was the result of the itempos.pl RegRipper plugin; not an artifact normally associated with program execution, but rather that the application was resident on the desktop. The two other write-ups went with the UserAssist artifacts, widely associated with program execution; however, there was no verification that the application was actually used to, as stated in the CTF question, delete forensic artifacts. As such, the GUI application could have been launched, closed, and then something else could have been used to take the specified actions. In fact, the actions in question were never verified.
As such, something to consider going forward is, when artifacts of program execution are found, what do they really mean?
Finally, a question...there is a way to make use of the FTP protocol on Windows workstations (XP, 7, 8, 10) that does not leave the 'normal' artifacts of program execution (i.e., Prefetch file, UserAssist entry) that does not involve disabling any default functionality. What is it, and how would you determine/verify it?
Addendum, 18 Aug: So far, there's only been one attempt to answer the final question. I know that there's more out there...check the comments to see the answer, but there's at least one more, and maybe even more than one!
However, when using approaches such as this, we need to keep in mind the context of the category titles. Yes, the artifacts of "program execution" provide an indication of applications that were launched on a system, but what does that mean?
At this point, I can guess what you're thinking...wait, what?? And believe me, I get it. "Program execution" means exactly that...that a program was executed. End of story. But wait...is that what it really means?
Consider this for a second...someone unfamiliar with a program or application might "open" it on their first try, to see what it does. Command line tools, for example, often contain information about their usage, which we can see by either typing the name of the program at the command prompt (no arguments), or by adding "/?" or "-h" ("--help" for Linuxphiles). This causes the program to run, but not in the sense that the functionality of the program is actually used.
As an example, I opened a command prompt, and changed directories to the C:\Windows\Prefetch folder. Most analysts who've been in the industry for some time are familiar with the application prefetch files, often referred to as simply "Prefetch". Specifically, these are files are widely known as an artifact of "program execution".
I first typed "dir ftp*.pf" to see if there were any Prefetch files that appeared to point to the use of ftp.exe, and got the expected result: File Not Found. Next, I typed "ftp /?" at the prompt, which displayed the usage syntax of the application.
I then retyped (actually, I hit the up arrow twice...) the 'dir' command, and this time, I found that there was a file named FTP.EXE-7BA637EA.pf, which was 2,685 bytes in size.
So, what happened? I ran the program, but only to the point where I could read the usage syntax. I didn't actually use the program to transfer files or exfil data in any way. However, the artifacts of program execution were populated.
Now, the same thing applies to GUI applications, maybe even more so. You can launch a GUI application, look around at the interface, maybe click a few of the options to see what functionality is available, and then close the UI without ever having employed the functionality provided by the application.
Case in point...consider this analysis of the DefCon 2018 CTF file server image. Other publicly available write-ups addressed the question of interest (which application was used to delete forensic artifacts?) with various findings. One was the result of the itempos.pl RegRipper plugin; not an artifact normally associated with program execution, but rather that the application was resident on the desktop. The two other write-ups went with the UserAssist artifacts, widely associated with program execution; however, there was no verification that the application was actually used to, as stated in the CTF question, delete forensic artifacts. As such, the GUI application could have been launched, closed, and then something else could have been used to take the specified actions. In fact, the actions in question were never verified.
As such, something to consider going forward is, when artifacts of program execution are found, what do they really mean?
Finally, a question...there is a way to make use of the FTP protocol on Windows workstations (XP, 7, 8, 10) that does not leave the 'normal' artifacts of program execution (i.e., Prefetch file, UserAssist entry) that does not involve disabling any default functionality. What is it, and how would you determine/verify it?
Addendum, 18 Aug: So far, there's only been one attempt to answer the final question. I know that there's more out there...check the comments to see the answer, but there's at least one more, and maybe even more than one!