Add specific artifacts

[SolitudePy]

Hello, in artifacts/files section I think it would be useful to add specific forensic artifacts(persistence mechanisms, etc) such as: sudoers, crontab, /etc/profile and much more. it would be useful for quicker collections, right now the only artifact is simply all of /etc for example which can be somewhat large in certain collections.

[Pierre-Gronau-ndaal]

I think a good idea

[tclahr]

I have been thinking about it, and I think MITRE ATT&CK could be used as a guide (https://attack.mitre.org/matrices/enterprise/linux/).

I think each artifact yaml file could have one or multiple attack TA IDs (i.e.: TA0001 for Initial Access), and subcategories IDs such as T1210 for Exploitation of Remote Services.

Then we could run collections not based on profiles or artifacts yaml files, but on MITRE ATT&CK IDs.

I would like to hear your thoughts.

[Pierre-Gronau-ndaal]

Hi,

Nice idea . Please consider that a static Mapping is causing Many manual work because with each Edition there are changing the numbering. I was in a Position to Deal with. My approach to Use Mapping table based on an specific edition and Update like you call it uac-id-4567 represented by Mitre attack id

[SolitudePy]

@tclahr sounds interesting, however a triage should consist of both artifact yaml files & attack techniques that are described in MITRE for example. so generally such a profile would be same as ir_triage but instead of the large directory collections(e.g /etc it would be pointed to more finetuned artifacts) for example:
persistance.yaml that includes all persistence mechanisms - there are duplicates though from what I see you already have interesting mechanisms such as ssh/authorized_keys.yaml, so instead of persistance.yaml it can be divided more carefully(e.g ssh_persistence.yaml, systemd_persistence.yaml, etc_persistence.yaml)

Also another approach may be that artifacts may include nested artifacts to create pointers instead of duplicates (similar to KAPE Targets in that manner)

would like to hear your thoughts, and I can work on such artifacts right away

[tclahr]

If MITRE is changing IDs once a while then I would not use IDs at all. I think names such as persistence, execution, lateral_movement could be a solution.

I think the first thing to do would be adding compound artifacts capability to UAC (like KAPE). I will think about some ideas and come back to you soon.

[SolitudePy]

yes compound artifacts is what I meant, and afterwards you can put a folder dedicated for compound artifacts(e.g persistence.yaml), technically it can also replace the profiles capability if you create a compound artifact(similar to KAPE's !SANS_Triage)

[SolitudePy]

hello @tclahr - bumpy

[tclahr]

I think the best way would be splitting the artifacts (when applicable) into different yaml files, using directories as "compound files".

Example using /etc artifacts:

• all /etc related artifacts would be stored in live_response/system/etc directory (instead of a single etc.yaml file). So the directory would act as our compound file (as live_response/system/etc/* can always be used to reference all /etc artifacts).
• live_response/system/etc/systemd.yaml would have systemd related artifacts found within /etc.
• live_response/system/etc/cron.yaml would have crontab related artifacts found within /etc, and so on...

This would give us 2 levels of granularity.

1. collecting all /etc related artifacts adding live_response/system/etc/* in any profile, or
2. collecting specific artifacts adding them individually in any profile.

After splitting the artifacts properly, then we could start creating specific profiles related to data theft, persistence, lateral movement, etc...

Let's discuss while I prepare UAC 3.1.0 (which will be released in the next days). After that we can start pushing the changes to develop branch.

[SolitudePy]

I understand, but that means you won't have a single etc.yaml anymore? or you will and then for a profile such as ir_triage you will have to include the targeted etc artifacts e.g:

- live_response/system/etc/cron.yaml
- live_response/system/etc/systemd.yaml
- live_response/system/etc/sudoers.yaml

and so on.
ofcourse, the same is relevant for other type of artifacts.

[tclahr]

Fair question. IMHO, /etc should always be fully collected as the incident responder never knows what tools/applications/software are running and storing data into /etc during an initial IR triage. Also because /etc is mostly made by text files and makes (almost) no difference in the compressed output file size.

But it does not mean we cannot have something like files/system/ssh/config.yaml to collect ssh_config and sshd_config artifacts stored into /etc, or files/applications/apache/config.yaml to collect apache related files stored into /etc. I think that would be the best approach concerning /etc artifacts.