Signal Detection Rules

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


The Linux one looks for this query 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 and event.code:1 in winlogbeat-*.

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

Thank you for your response. I have checked both auditbeat and winlogbeat. I do see the field 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 fields are not picking up this command?

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..?

@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?

Hi, in the case of the Linux events, are you using the "Executions" Auditbeat rule ( ?

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

Are you referring to this @Craig_Chamberlain ?:

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

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

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?

Hi Craig,
In my case event.code field name matches with default detection rule, but I don't have 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? :frowning:

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

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 :slight_smile:

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.