Update process mappings with new driver key value

[rc-abodkins]

Which category is the feature part of?

• [x] Carbon Black Response
• [x] Threat Hunter
• [ ] Definition File
• [ ] Code Feature - impacts all products
• [ ] New product support
• [x] S1
• [x] MDE

Use Cases With the new definition file regarding vulnerable drivers we have to add the key for hash to the process mapping for how each EDR calls the hashes.

Proposal A clear and concise description of what you want to happen.

Additional context Add any other context or screenshots about the feature request here.

[rc-abodkins]

Related to #61

[rc-csmith]

Since EDRs use different hashes, proposing that three new keys are created: md5, sha1, and sha256 That way, unsupported hashes won't be queried needlessly

[rc-csmith]

update: Carbon Black Response already has some existing fields for hashes:

• md5 (hash of executing process)
• sha256 (hash of executing process)
• filewrite_md5 (hash of file written to disk)
• filewrite_sha256 (hash of file written to disk)

My proposed solution is to add the above fields to the parameter mappings within each EDR platform. If there's interest/need, I also think these non-CbR fields would be useful but would require the CbR product file to have a parameter mapping dict:

• sha1
• filewrite_sha1
• modload_md5 (hash of loaded image)
• modload_sha256 (hash of loaded image)
• modload_sha1 (hash of loaded image)

[xC0uNt3r7hr34t]

The other option we talked about would be to implement the ability to specify a hash and let each product file determine how to use it. this could also be potentially done within the surveyor.py logic where we use something like https://pypi.org/project/hashID/.

Carbon Black has the trickiest fields for this while S1 and MDE each have more general hash fields.

• MD5
• SHA1
• SHA256

regardless of whether we automatically determine hash type or require users to define it in arguments or definition files, it would be best to pass all hashes to the product file and simply let them discard any that are not supported by that product as is done today with the parameter mapping.

[rc-csmith]

Thanks for keeping me honest! I remember now we did decide to lump all hash types into a single key so we have the foundation for if/when EDR capabilities expand beyond the simple MD5 and SHA256.

One thing to consider is making sure that when we build the parameter mappings, the code supports any occurrence of the hash - be it for process execution, file write, or module load. Otherwise, we'd have to have three separate keys like process_hash, filewrite_hash, modload_hash.