Correct "remote_access_software" Lookup to Match macOS Processes from NVM Input

[gneff]

Details

What does this PR have in it? Screenshots are worth 1000 words 😄

Checklist

• Validate name matches <platform>_<mitre att&ck technique>_<short description> nomenclature
• CI/CD jobs passed ✔️
• Validated SPL logic.
• Validated tags, description, and how to implement.
• Verified references match analytic.
• Confirm updates to lookups are handled properly.

Validated lookup changes with this query on the CSIRT Splunk Development cluster:

earliest=-24h index=nvm process_name=* AND dst_name!=*.cisco.com 
| stats values(dst_name) as Destination by logged_in_user_name, process_name 
| join process_name 
    [| inputlookup remote_access_software_combined
    | where isnotnull(process_name) 
    | table process_name, category, comment_reference, description, remote_appid, remote_domain ]

(The 'inputlookup' name is unique to the CSIRT Dev server and should normally reflect the standard remote_access_software name.)

Notes For Submitters and Reviewers

• If you're submitting a PR from a fork, ensuring the box to allow updates from maintainers is checked will help speed up the process of getting it merged.
• Checking the output of the build CI job when it fails will likely show an error about what is failing. You may have a very descriptive error of the specific field(s) in the specific file(s) that is causing an issue. In some cases, its also possible there is an issue with the YAML. Many of these can be caught with the pre-commit hooks if you set them up. These errors will be less descriptive as to what exactly is wrong, but will give you a column and row position in a specific file where the YAML processing breaks. If you're having trouble with this, feel free to add a comment to your PR tagging one of the maintainers and we'll be happy to help troubleshoot it.
• Updates to existing lookup files can be tricky, because of how Splunk handles application updates and the differences between existing lookup files being updated vs new lookups. You can read more here but the short version is that any changes to lookup files need to bump the date and version in the associated YAML file.

[ljstella]

AppInspect failure in CI is expected for PRs coming from a fork.

[nasbench]

This lookup is used by other analytics. Why not rename the field in your search instead?

[gneff]

The original query had a rename (left it in here commented out), but it never matched any processes on macOS hosts:

earliest=-24h index=nvm process_name=* AND dst_name!=*.cisco.com 
| stats values(dst_name) as Destination by logged_in_user_name, process_name 
| join process_name 
    [| inputlookup remote_access_software_combined
        ```| rename remote_utility as process_name``` 
    | where isnotnull(process_name) 
    | table process_name, category, comment_reference, description, remote_appid, remote_domain ]

[nasbench]

Here is a working example from the repo renaming the field to process for use

security_content/detections/endpoint/detect_remote_access_software_usage_process.yml

Lines 23 to 32 in 5fa7311

	[| inputlookup remote_access_software where isutility=TRUE
	| rename remote_utility AS Processes.process_name
	| fields Processes.process_name]
	AND Processes.dest!="unknown"
	AND Processes.user!="unknown"
	by Processes.action Processes.dest Processes.original_file_name Processes.parent_process Processes.parent_process_exec Processes.parent_process_guid Processes.parent_process_id Processes.parent_process_name Processes.parent_process_path Processes.process Processes.process_exec Processes.process_guid Processes.process_hash Processes.process_id Processes.process_integrity_level Processes.process_name Processes.process_path Processes.user Processes.user_id Processes.vendor_product
	| `security_content_ctime(firstTime)`
	| `security_content_ctime(lastTime)`
	| `drop_dm_object_name(Processes)`
	| lookup remote_access_software remote_utility AS process_name OUTPUT isutility description AS signature comment_reference AS desc category

I'm no expert on SPL but I think this might be an issue in your search.

But imo the solution is not renaming the lookup to fit (only) your need.

[patel-bhavin]

@gneff : i think @nasbench is correct here. This lookup file is used in several other detections and changing the lookup field here will cause many other detections to not work.

I also think there may be an opportunity to make this detection work for Mac OS processes but we do not have appropriate attack data to test that change. What data are you ingesting for processes from macOS hosts?

Can you help provide a sample event and we can have this change tested ?

[patel-bhavin]

@gneff : Any thoughts on the above ask wrt attack_data ?

[patel-bhavin]

@gneff : hello there! Can you please help us with a sample event that you have been testing with for Mac OS? That will help with testing this PR and getting it shipped!