KAPE modules feature request - file copy

[Qazeer]

Hello!

It would be great to have a module feature to simply copy files that match a file mask to a destination (for better visibility of the artefacts). 

There would be many use cases, notably for text-based logs (PowerShell Console or Transcript, RMM tools, etc.). It is something that has been implemented for the PowerShell_Move-KAPEConsoleHost_history module through a PowerShell script, and I wanted to do the same for PowerShell transcripts, but I think having the feature built-in directly into KAPE would be cleaner and offer better performance.

If at all possible, an option to re-use the file masks from existing targets would be a nice addition to avoid duplicating targets and modules. 

[EricZimmerman]

That's called a target. And besides you can write a program to do that if you like and run it via a module.

You can do this now, as is, via regex.

What am I missing?

[Qazeer]

The goal would be to do what's being done through PowerShell_Move-KAPEConsoleHost_history and Move-KAPEConsoleHost_history.ps1 but directly built-in into KAPE.

I do know that I can write a program / script to do that, but I think it would be nice to have a way to do it directly into KAPE, as it's a need that goes beyond PowerShell console histories.

Alternatively, the Move-KAPEConsoleHost_history.ps1 script could be adapted to support generic file masks (but still with PowerShell performances).

[AndrewRathbun]

The goal would be to do what's being done through PowerShell_Move-KAPEConsoleHost_history and Move-KAPEConsoleHost_history.ps1 but directly built-in into KAPE.

I do know that I can write a program / script to do that, but I think it would be nice to have a way to do it directly into KAPE, as it's a need that goes beyond PowerShell console histories.

Alternatively, the Move-KAPEConsoleHost_history.ps1 script could be adapted to support generic file masks (but still with PowerShell performances).

I'll take this opportunity to lay out the intent of the Move-KAPEConsoleHost_history.ps1 script/Module. TL;DR, KapeTriage packages grab lots of good stuff for an IR investigation, but not all of it is parsed and therefore shows up in a processed form in your specified Module output destination. I found often that quick wins could be found by diving into the ConsoleHost_History.txt for a specific user, and despite the file existing within an acquired KapeTriage package, it often wasn't looked at for whatever reason, but the Module output was examined 100% of the time. Therefore, the idea of this script was born.

First, a visual aid of what typically gets overlooked because it's buried in the tout folder (understandably so)

Using the Module makes it almost impossible for an examiner who looks at the Module output (mout) 100% of the time, as seen below:

That being said, I am confused as to why you'd want this to be done for other artifacts. Can you give some specific use cases so I can better understand? It almost seem like you'd just want to run a KapeTriage Target acquisition against a KapeTriage Target acquisition, but with RecreateDirectories disabled and just throw them into a folder? Or even just copying all the files into a raw files folder in your Module output (mout), I guess? I am struggling to understand, so any further color you can provide would be helpful.

[EricZimmerman]

Nothing that specific is getting added to kape directly.

[Qazeer]

Thank you for taking the time to explain the Move-KAPEConsoleHost_history.ps1 script better than I did @AndrewRathbun!

There would be other, arguably less important, text-based artifacts (without parsers to date) that come to mind: PowerShell Transcripts, RMM softwares logs (AnyDesk, TeamViewer, etc.), some anti-virus logs and quarantine files, etc.

In a way yes, it would be to re-run (some) KAPE targets against a KAPE acquisition, but with the option:

• to specify an output folder to match KAPE module folders (ProgramExecution, RemoteAccess, etc.)
• to create per-user subfolders for logs from %APPDATA% / %LOCALAPPDATA% (as it is being done in Move-KAPEConsoleHost_history.ps1).

The end goal would be to present the various non-parsed text-based artefacts in a more user-friendly way in Module outputs, in order to consolidate the data, ensure such logs are not overlooked, and to avoid having to browse nested application specific folders. I would argue that it's not that specific considering the prevalence of text-based logs in RMM software (and the usage of such software by TA) but understand if it's not worth the addition to KAPE.

If it's not added to KAPE, would there be a way to (temporarily) override the RecreateDirectories parameter without modifying the target files directly?

[EricZimmerman]

What should happen here is a module that looks for the things you want and does stuff to them.

That is the appropriate workflow here.

[AndrewRathbun]

Thank you for taking the time to explain the Move-KAPEConsoleHost_history.ps1 script better than I did @AndrewRathbun!

There would be other, arguably less important, text-based artifacts (without parsers to date) that come to mind: PowerShell Transcripts, RMM softwares logs (AnyDesk, TeamViewer, etc.), some anti-virus logs and quarantine files, etc.

In a way yes, it would be to re-run (some) KAPE targets against a KAPE acquisition, but with the option:

• to specify an output folder to match KAPE module folders (ProgramExecution, RemoteAccess, etc.)
• to create per-user subfolders for logs from %APPDATA% / %LOCALAPPDATA% (as it is being done in Move-KAPEConsoleHost_history.ps1).

The end goal would be to present the various non-parsed text-based artefacts in a more user-friendly way in Module outputs, in order to consolidate the data, ensure such logs are not overlooked, and to avoid having to browse nested application specific folders. I would argue that it's not that specific considering the prevalence of text-based logs in RMM software (and the usage of such software by TA) but understand if it's not worth the addition to KAPE.

Yeah, I would argue that a simple PowerShell script with an array of keywords, i.e. TeamViewer, AnyDesk, etc, could be compiled and then for each file/folder that matches those keywords, copy them all over to your Module destination folder in an appropriately named folder. Definitely not something Eric needs to do but should be pretty easily accomplished with PowerShell.

If it's not added to KAPE, would there be a way to (temporarily) override the RecreateDirectories parameter without modifying the target files directly?

I have thought of this a few times before previously and not in situations related to this issue, TBH. Having a radio button override, for example, would be helpful so you don't have to go into 50+ Targets to change that. That being said, you could always use PowerShell or something like PowerGREP to replace RecreateDirectories: true to RecreateDirectories:False, so there's always relatively simple workarounds if it's a big enough issue.

[Qazeer]

Yeah, I would argue that a simple PowerShell script with an array of keywords, i.e. TeamViewer, AnyDesk, etc, could be compiled and then for each file/folder that matches those keywords, copy them all over to your Module destination folder in an appropriately named folder. Definitely not something Eric needs to do but should be pretty easily accomplished with PowerShell.

Yes that's what I though doing at first, or various modules with a simple PowerShell copy one-liner. Doing it all through a script would imply PowerShell performance and duplicating information already present and maintained in KAPE targets, which is why it did not seem to be the best approach (in my opinion).

Now I understand that it deviates too much from the standard KAPE workflow, and will thus not be implemented. May be the button override for RecreateDirectories would be considered worth implementing?