[Rule Tuning] Fixes FPs related to a process.args_count bug

[w0rk3r]

Issues

Resolves #4944
Endpoint dev issue: 16786
sdh-endpoint issue: 630
Community user on slack: https://elasticstack.slack.com/archives/CRGSUQC20/p1753795588123129

Summary

There’s a hard-to-reproduce bug in process events where a missing closing double quote in the command line causes it to be counted as a single argument. For more technical details, see Gabe’s explanation in the SDH.

This PR adds a regex pattern to exclude matches from this bug. The most affected rule is Unusual Process Execution Path - Alternate Data Stream, which has been triggering on commonly used software (e.g., browsers) and causing 130k+ false positives in the last 30 days.

[github-actions]

Rule: Tuning - Guidelines

These guidelines serve as a reminder set of considerations when tuning an existing rule.

Documentation and Context

• Detailed description of the suggested changes.
• Provide example JSON data or screenshots.
• Provide evidence of reducing benign events mistakenly identified as threats (False Positives).
• Provide evidence of enhancing detection of true threats that were previously missed (False Negatives).
• Provide evidence of optimizing resource consumption and execution time of detection rules (Performance).
• Provide evidence of specific environment factors influencing customized rule tuning (Contextual Tuning).
• Provide evidence of improvements made by modifying sensitivity by changing alert triggering thresholds (Threshold Adjustments).
• Provide evidence of refining rules to better detect deviations from typical behavior (Behavioral Tuning).
• Provide evidence of improvements of adjusting rules based on time-based patterns (Temporal Tuning).
• Provide reasoning of adjusting priority or severity levels of alerts (Severity Tuning).
• Provide evidence of improving quality integrity of our data used by detection rules (Data Quality).
• Ensure the tuning includes necessary updates to the release documentation and versioning.

Rule Metadata Checks

• updated_date matches the date of tuning PR merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive. Review to ensure the original intent of the rule is maintained.

Testing and Validation

• Validate that the tuned rule's performance is satisfactory and does not negatively impact the stack.
• Ensure that the tuned rule has a low false positive rate.

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Unusual Process Execution Path - Alternate Data Stream (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Unusual Network Connection via RunDLL32 (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Potential Windows Error Manager Masquerading (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Unusual Child Processes of RunDLL32 (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[w0rk3r]

FP example

[w0rk3r]

Example FP

[w0rk3r]

Example FP

[w0rk3r]

Example FP

[Samirbous]

g2g (verified that there is no impact on TPs)

[Mikaayenson]

Great idea!

[richlv]

I guess having another .exe in the commandline would silence all the affected alerts, but that's probably still better than the noise.
That is, path/here.exe/something.exe or really.exe.something.exe.

[w0rk3r]

@richlv I'm not sure if I got your point, can you elaborate?

[richlv]

The change adds:

not process.command_line regex~ """\".*\.exe[^\"].*""")] 

Assuming .* is greedy, would this also exclude cases like this?

c:\something.exe\anotherthing.exe c:\temp\this.exe.excluded.exe 

[w0rk3r]

@richlv, the expression requires a leading ", and a missing " after the .exe

[richlv]

Ah, OK - with the regexp evaluated left-to-right, the first .* would greedy-match until the last .exe, and thus these would not be excluded unexpectedly:

"c:\something.exe\anotherthing.exe" "c:\temp\this.exe.excluded.exe" 

But wouldn't somebody be able to trigger the exclusion by passing a parameter with .exe?

"c:\something.exe" excluded.exe 

[w0rk3r]

But wouldn't somebody be able to trigger the exclusion by passing a parameter with .exe?

Something like that would be 2 args. Here, we’re just mitigating a bug that makes the args_count show as 1 even when there are multiple args. The regex wouldn’t match any command line that includes a closing quote.

[richlv]

So the only edge case would be encountering the bug which goes args = 1 on something like this, right?

"c:\something.exe excluded.exe.stuff 

[w0rk3r]

Here is what an event that has this bug looks like:

[richlv]

Yep, thus the matching would be:

 " c:\something.exe excluded.exe . stuff \" .* \.exe[^\"].* 

It's not a huge concern, was just wondering whether there are some slightly unexpected matches possible.