Add NETCLRUsageLogs to a compound target

[Qazeer]

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]

@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]

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]

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]

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]

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]

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

[Qazeer]

I can do the PR, no problem :)