Linux_anomalous_process_all_hosts_ecs apparently not only covering Linux, but full auditbeat

[willemdh]

Hello,

I was a bit surprised to see the "Anomalous Process For a Linux Population" SIEM rule trigger for Windows hosts.

After some investigation, I noticed there is no filter for host.os.type or host.os.family or sth similar. The anomaly job linux_anomalous_process_all_hosts_ecs looks at anomalous processes for Auditbeat in general, so also on Windows hosts...

It seems to me that this confusion can be solved by adding a filter on host.os.family in the linux_anomalous_process_all_hosts_ecs job...

So changing the default config:

{
  "bool": {
    "filter": [
      {
        "terms": {
          "event.action": [
            "process_started",
            "executed"
          ]
        }
      },
      {
        "term": {
          "agent.type": "auditbeat"
        }
      }
    ],
    "must_not": [
      {
        "bool": {
          "should": [
            {
              "term": {
                "user.name": "jenkins-worker"
              }
            },
            {
              "term": {
                "user.name": "jenkins-user"
              }
            },
            {
              "term": {
                "user.name": "jenkins"
              }
            },
            {
              "wildcard": {
                "process.name": {
                  "wildcard": "jenkins*"
                }
              }
            }
          ],
          "minimum_should_match": 1
        }
      }
    ]
  }
}

To:

{
  "bool": {
    "filter": [
      {
        "terms": {
          "event.action": [
            "process_started",
            "executed"
          ]
        }
      },
      {
        "term": {
          "agent.type": "auditbeat"
        }
      },
      {
        "term": {
          "host.os.type": "linux"
        }
      }
    ],
    "must_not": [
      {
        "bool": {
          "should": [
            {
              "term": {
                "user.name": "jenkins-worker"
              }
            },
            {
              "term": {
                "user.name": "jenkins-user"
              }
            },
            {
              "term": {
                "user.name": "jenkins"
              }
            },
            {
              "wildcard": {
                "process.name": {
                  "wildcard": "jenkins*"
                }
              }
            }
          ],
          "minimum_should_match": 1
        }
      }
    ]
  }
}

Should do the trick?

The ML job rare_process_by_host_linux_ecs for the SIEM rule Unusual Process For a Linux Host has the same issue..

The ML job suspicious_login_activity for the SIEM rule Unusual Login Activity has signal.rule.tag Linux (not Windows..), but also triggers on Windows events... Imho this job should be called suspicious_linux_login_activity and "host.os.type": "linux" should be added in the query..

There might be others..

Willem

[Craig_Chamberlain]

Hello, so there are newer versions of the Linux ML jobs in 7.11 and later in a module named Security: Linux. The jobs in this module test for operating system type. The new version of this particular job is the one named v2_linux_anomalous_process_all_hosts_ecs.

[willemdh]

Thanks for your answer @Craig_Chamberlain

I have found some 'new' v2 jobs with better queries including os type..

v2_linux_anomalous_process_all_hosts_ecs
v2_rare_process_by_host_linux_ecs

But I could not immediately find a v2 version of the ML job suspicious_login_activity for the SIEM rule Unusual Login Activity? This one also applies to Windows hosts and the SIEM rule also only has a Linux tag.. (Unusual Login Activity | Elastic Security Solution [7.16] | Elastic)

Something else I noticed is that the v2_linux_anomalous_network_port_activity_ecs only queries events where event.type equals start. The result is only auditd events are captured and not system.socket. In the Auditbeat system.socket dataset, event.type equals connection...

Is there a reason only event.type:start events are included in this ML job and not event.type:connection?