Signal Detection Rules

[tanner8302 (Tanner Smith)]

These don't seem to be working for me. I have enabled all rules for Linux and Windows. There are two rules based upon the whoami command. One for windows and one for linux. I performed the whoami command on both hosts and did not receive a signal detection. Is there something else that I need to do other than enabling the signal detection rules and ensuring that the appropriate *beat is feeding into my SEIM? These screen shots show the logs are making it to the discover module

There is also another rule for clearing windows logs. I went into event viewer on my windows host and cleared the security, application, system logs. No detection signals. See screen shot

In fact the only detection signal I am receiving is the DNS to Internet signal......

Running 7.6 in Kibana, ARM, and Elasticsearch

[tudor (Tudor Golubenco)]

Hi,

The Linux one looks for this query process.name: whoami and event.action:executed in the auditbeat-* indices (you can see this in the Rule details page). Can you try that query in Discover to see if you get any matches?

Similarly, the Windows one searches for process.name:whoami.exe and event.code:1 in winlogbeat-*.

Let me know if those return data, if they don't, we need to check the ingestion piece.

[tanner8302 (Tanner Smith)]

Thank you for your response. I have checked both auditbeat and winlogbeat. I do see the field process.name but do not see whoami in that field. In performing a simple query in auditbeat I do not see the entry "whoami" at all. In winlogbeat I do see the entry and log events as shown above.

I wonder if my *.yml's are not parsing this data correctly and therefore my process.name fields are not picking up this command?

[hilt86]

is the event.action correct? I' running Auditbeat 7.6.0 and when I run hping3 on a host and the event.action is process.started..?

[hilt86]

@tudor what could be missing to prevent the event.action: executed from being generated? Is it something to do with an ingest pipeline or the way the executable was run?

[Craig_Chamberlain]

Hi, in the case of the Linux events, are you using the "Executions" Auditbeat rule (https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-reference-yml.html) ?

In the case of the Windows events, I see the Image field but not the event.code or process.name field contents that the rule evaluates. Can you share these fields or the entire event text?

[hilt86]

Are you referring to this @Craig_Chamberlain ?:

## Executions.
-a always,exit -F arch=b64 -S execve,execveat -k exec

[Craig_Chamberlain]

So yes, with that rule enabled you should receive events from auditbeat with an event.action of executed, like this one with a process.name of whoami

[hilt86]

By default auditbeat logs executions as "process_started" - is there a benefit to enabling the extra auditd rules (other than the rules working out of the box)?

Would there be a performance impact by enabling the -a always,exit -F arch=b64 -S execve,execveat -k exec part of the config?

[jane]

Hi Craig,
In my case event.code field name matches with default detection rule, but I don't have process.name I have winlog.event_data.Image. Does it mean that I have to manually check every detection rule and edit field names according to my system?

[Craig_Chamberlain]

Hi Jane - it looks like ECS (Elastic common schema) fields like process.name are not being created and populated. Could this be coming from an older version of Winlogbeat?

[jane]

Thanks. Since I have Winlogbeat 7.6 - that wasn't the issue. You mentioned ECS and I found out about Sysmon and Security modules, so I added them in .yml config file. Now I have new field names including process.name.