elastic
[Security Solution] "Modification of Safari Settings via Defaults Command" rule seems to be broken after update
The "Modification of Safari Settings via Defaults Command" rule update appears to have introduced a bug in v9.0.0 where lots of unrelated events are being picked as alerts.
The updated prebuilt EQL rule is:
process where host.os.type == "macos" and event.type in ("start", "process_started") and
process.name == "defaults" and process.args like~ ("com.apple.Safari", "write") and
not process.args like~ ("UniversalSearchEnabled", "SuppressSearchSuggestions", "WebKitTabToLinksPreferenceKey",
"ShowFullURLInSmartSearchField", "com.apple.Safari.ContentPageGroupIdentifier.WebKit2TabsToLinks")
The bug I believe is in this part of the query: process.args like~ ("com.apple.Safari", "write"), the like~ lookup operator "returns true if the string matches a wildcard pattern in the provided list", which I believe is not what was intended. Now the rule is picking up anything that uses the write argument without the com.apple.Safari argument having to be present at all. I believe the rule EQL was intended to be more like: ... process.args: "com.apple.Safari" and process.args: "write" and ....
Here's a link to the rule on the elastic site: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/macos/defense_evasion_safari_config_change#rule-query
Unfortunately I'm finding it hard to find the old query for the rule, hope this is enough to go off for now.
@banderror would you help me here with the correct team to assign this prebuilt rule issue?
Hey @pborgonovi, this is an issue about a specific prebuilt Elastic rule. The @elastic/threat-research-and-detection-engineering team would be the owners and the issue should be opened in the detection-rules repo. I'll transfer.
@saernz You are right. Those process arguments should be broken out. I'll get a tuning PR in for the next release to fix.
