# Signal Detection Rules **URL:** \ **Category:** SIEM\ **Created:** [February 19, 2020, 3:08am UTC](https://discuss.elastic.co/t/signal-detection-rules/219887 "2020-02-19T03:08:47Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![tanner8302](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tanner8302/32/94038_2.png) [@tanner8302](https://discuss.elastic.co/u/tanner8302)\ **Post date:** [February 19, 2020, 3:08am UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/1 "2020-02-19T03:08:47Z")
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 ![image](https://us1.discourse-cdn.com/elastic/original/3X/7/0/7001ac54e0275c0046e35af2061701fdfe542c08.png) 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 ![image](https://us1.discourse-cdn.com/elastic/original/3X/2/a/2ad9cc9f65f652fa703d7fcd37e9e7d7d876bcc0.png) In fact the only detection signal I am receiving is the DNS to Internet signal...... Running 7.6 in Kibana, ARM, and Elasticsearch ---
**Author:** ![tudor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tudor/32/3753_2.png) [@tudor](https://discuss.elastic.co/u/tudor)\ **Post date:** [February 19, 2020, 10:37am UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/2 "2020-02-19T10:37:09Z")
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. ---
**Author:** ![tanner8302](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tanner8302/32/94038_2.png) [@tanner8302](https://discuss.elastic.co/u/tanner8302)\ **Post date:** [February 19, 2020, 11:41am UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/3 "2020-02-19T11:41:10Z")
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? ---
**Author:** ![hilt86](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hilt86/32/20308_2.png) [@hilt86](https://discuss.elastic.co/u/hilt86)\ **Post date:** [February 24, 2020, 7:01am UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/4 "2020-02-24T07:01:20Z")
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..? ---
**Author:** ![hilt86](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hilt86/32/20308_2.png) [@hilt86](https://discuss.elastic.co/u/hilt86)\ **Post date:** [February 24, 2020, 9:43pm UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/5 "2020-02-24T21:43:29Z")
@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? ---
**Author:** ![Craig\_Chamberlain](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/craig_chamberlain/32/70079_2.png) [@Craig\_Chamberlain](https://discuss.elastic.co/u/Craig_Chamberlain)\ **Post date:** [February 29, 2020, 10:33pm UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/6 "2020-02-29T22:33:41Z")
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](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? ---
**Author:** ![hilt86](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hilt86/32/20308_2.png) [@hilt86](https://discuss.elastic.co/u/hilt86)\ **Post date:** [March 5, 2020, 10:09am UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/7 "2020-03-05T10:09:32Z")
Are you referring to this @Craig_Chamberlain ?: ```auto ## Executions. -a always,exit -F arch=b64 -S execve,execveat -k exec ``` ---
**Author:** ![Craig\_Chamberlain](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/craig_chamberlain/32/70079_2.png) [@Craig\_Chamberlain](https://discuss.elastic.co/u/Craig_Chamberlain)\ **Post date:** [March 6, 2020, 10:22pm UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/8 "2020-03-06T22:22:51Z")
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 ![image](https://us1.discourse-cdn.com/elastic/original/3X/b/9/b91fd50e33c21c5440982739beb9df54f3cec6c6.png) ---
**Author:** ![hilt86](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hilt86/32/20308_2.png) [@hilt86](https://discuss.elastic.co/u/hilt86)\ **Post date:** [March 17, 2020, 4:05am UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/9 "2020-03-17T04:05:07Z")
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? ---
**Author:** ![jane](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jane](https://discuss.elastic.co/u/jane)\ **Post date:** [April 8, 2020, 10:02am UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/10 "2020-04-08T10:02:38Z")
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? ☹ ![whoami](https://us1.discourse-cdn.com/elastic/original/3X/5/0/501c9b57be7018848edc3a0d9e0985c03e3f75a8.jpeg) ---
**Author:** ![Craig\_Chamberlain](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/craig_chamberlain/32/70079_2.png) [@Craig\_Chamberlain](https://discuss.elastic.co/u/Craig_Chamberlain)\ **Post date:** [April 8, 2020, 4:28pm UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/11 "2020-04-08T16:28:56Z")
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? ---
**Author:** ![jane](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jane](https://discuss.elastic.co/u/jane)\ **Post date:** [April 21, 2020, 11:08am UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/13 "2020-04-21T11:08:23Z")
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`. 🙂 ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [May 19, 2020, 11:08am UTC](https://discuss.elastic.co/t/signal-detection-rules/219887/14 "2020-05-19T11:08:24Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.