search

EricZimmerman / KapeFiles

This repository serves as a place for community created Targets and Modules for use with KAPE.
MIT License
653 stars 193 forks source link

Add NETCLRUsageLogs to a compound target #846

Closed Qazeer closed 11 months ago

Qazeer commented 1 year ago

Hello!

The .NET CLR UsageLogs (target NETCLRUsageLogs) seem relevant enough to be added to either the EvidenceOfExecution or CombinedLogs compound target (or may be directly to the KapeTriage target). I can do a PR to do so, but would prefer a validation on which compound target to update first.

AndrewRathbun commented 1 year ago

@Qazeer sorry for the delay, been busy the last few days. I'm thinking CombinedLogs, if anything. What do you think? The other two options would fall under KapeTriage so I personally think it should be an add-on to KapeTriage rather than included in it, but happy to hear arguments to the contrary.

Qazeer commented 1 year ago

Hi @AndrewRathbun!

No problem for the delay of course.

I would personally vote for including the .NET CLR UsageLogs under KapeTriage, as they can shed light on in memory .NET assembly execution, something that is otherwise hard to detect from disk artefacts.

From my limited testing, there should be a small number of legitimate entries (for a small total size as well). I don't have access to more endpoint telemetry at the moment, but could do more testing (in a little while though).

AndrewRathbun commented 1 year ago

I think I'd need to see example artifacts to better understand the size, scope, etc. I'll try to generate some this week or see if these are on disk already for review. Kroll uses KapeTriage as our standard remote pull so I'm hesitant to add anything without looking at the data myself and confirming it won't be adding a large amount of unnecessary data to every remote pull.

AndrewRathbun commented 1 year ago

I was looking at some of these artifacts on my system and I wasn't seeing any evidence of execution artifacts on here. Are you seeing something different? Sure, I'm seeing like Fences.exe.log, but inside the .log file there doesn't appear to be anything forensically interesting.

Qazeer commented 11 months ago

Sorry for the late reply.

As far as I know, the content of the .log files are indeed meaningless from a forensic standpoint. However, the mere presence of a file can be an indicator of a (potentially in memory) .NET assembly execution, as detailed by Bohops in the blog post Investigating .NET CLR usage log tampering techniques for edr evasion.

So simply listing the files, and their timestamps, would be sufficient. But for a Kape collection, I would personally collect the files by default, as there should generally be a limited number of (text and small) files. CombinedLogs can also be an option, up to you!

AndrewRathbun commented 11 months ago

CombinedLogs is a better fit, IMO. Did you want to do the PR? I can if you're not able.

Qazeer commented 11 months ago

I can do the PR, no problem :)