# How to exploit rules
**URL:** https://discuss.elastic.co/t/how-to-exploit-rules/328174
**Category:** Elastic Security
**Created:** [March 21, 2023, 2:53pm UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174 "2023-03-21T14:53:40Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@Iroshu](https://discuss.elastic.co/u/Iroshu)
#### Post date: [March 21, 2023, 2:53pm UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/1 "2023-03-21T14:53:40Z")
Dear team,
We are actually playing with the detection of elastic and something seems weird for us.
We have created a Rule and we add an action in order to populate an index using our collector :
We choose all fied found on the documentation in order to have everything and to choose the proper field to work on. It's working fine but we discovered that all important information are stored in json format into the field context alerts and it seems it's not possible to exploit them using stand visualisation.
After some research we found that result are stored into the .siem-signals are properly dispatch into several exploitable fields.
We have also noticed that when using the machine learning solution as the results are stored into index using the json format.
Our solution will to have a logstash to read the information and to push it back using good fields but i think we are missing something here. Can you help us ?
---
### Author:  [@georgii](https://discuss.elastic.co/u/georgii)
#### Post date: [March 22, 2023, 1:20pm UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/2 "2023-03-22T13:20:49Z")
Hey @Iroshu, welcome to the community! 👋
Can you please share what stack version are you on and what are you ultimately trying to achieve?
Detection alerts are Elasticsearch documents that a rule writes to `.siem-signals-*` or `.alerts-security.alerts-*` indices (depending on the stack version you use). Every alert is written as a separate document, but the rule might write multiple alerts per run. You shouldn't need to reindex alerts as is to a separate index using an Index Connector -- unless you have specific requirements. It should be possible to build visualizations and dashboards on top of the alerts indices -- just make sure your users have access to them. You can learn more about the RBAC in the docs:
> **[Detections prerequisites and requirements | Elastic Security Solution \[8.6\] |...](https://www.elastic.co/guide/en/security/current/detections-permissions-section.html)**
---
### Author:  [@Iroshu](https://discuss.elastic.co/u/Iroshu)
#### Post date: [March 22, 2023, 2:10pm UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/3 "2023-03-22T14:10:48Z")
Hi @georgii ! Thanks 🙂
We are actually using the 7.17.9 version. We would like to push theses informations into another index as we plan to add more stuff with other solutions... And we prefer to avoid playing with the system index.
How we can change that ? Any specific options to put into the connector ?
Thanks for your help
---
### Author:  [@georgii](https://discuss.elastic.co/u/georgii)
#### Post date: [March 22, 2023, 5:36pm UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/4 "2023-03-22T17:36:22Z")
Hey @Iroshu, the way you can use placeholders in a rule action's body is documented here:
> **[Create a detection rule | Elastic Security Solution \[8.11\] | Elastic](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#rule-action-variables)**
In this doc you can find a few examples, including the one showing how you can iterate over the `context.alerts` array that contains all detection alerts generated during a rule run.
The mustache syntax which is used in rule action bodies is suitable for generating text documents, but falls short when you need to generate valid JSON.
For example, this would be a valid text payload for sending to a webhook:
```auto
{{#context.alerts}}
Detection alert for user: {{user.name}}
{{/context.alerts}}
```
However, generating a JSON doc is problematic. The only easy thing you can do is string concatenation:
```auto
{
"user_names": "{{#context.alerts}}{{user.name}}, {{/context.alerts}}"
}
```
Or you could index all generated alerts concatenated into a string field, which I'm not sure would be useful at all:
```auto
{
"alerts": "{{context.alerts}}"
}
```
Some folks managed to workaround this problem for webhooks, you can read more here:
> [@Elastic Rule Connector sends a String instead of JSON to the Webhook](https://discuss.elastic.co/t/elastic-rule-connector-sends-a-string-instead-of-json-to-the-webhook/313833):
>
> Hey there! First of all, I'd like to describe my situation. I have an Elastic Rule, that successfully creates the Alerts in the Elastic Security. Now I have configured a connector, that allows me to send those Alerts to my custom webhook. It works, but all Alert data (in JSON format by default) is sent as a string. Then I added the Content-Type header with the value application/JSON, but nothing changed. this is a sample of what I receive at webhook when I use a JSON content-type header.
However, indexing ndjson is not an option for the Index Connector, where we'd have to create a valid document. I'd imagine something like that could work:
```auto
{
"alerts": [
{{#context.alerts}}
{{{.}}},
{{/context.alerts}}
{"last_alert": "fake_document"}
]
}
```
but the form of the index connector doesn't allow to specify non-valid JSON ([related issue](https://github.com/elastic/kibana/issues/141176)) and it seems you can't save a rule with a non-valid action body anymore. UPD: you can save a Webhook action with an invalid body (so you can use the workaround), but you can't do the same with an Index action - this one strictly requires the body to be valid JSON (so the workaround won't work).
FWIW one of our teams was planning to work on adding support for triggering rule actions per each generated alert separately, which might be a good option for reindexing them as is into a separate index. I'm not aware of any timeframes though.
> And we prefer to avoid playing with the system index.
Unless you need additional or transformed data in your own index (meaning not the alerts as is), you should feel safe and free to read from the system `.alerts-security.alerts-*` index. This index is managed by the Security app and alerts are written to it by the app itself, you don't need to configure anything to enable that.
Let me know if this information was helpful or not.
---
### Author:  [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)
#### Post date: [March 22, 2023, 6:05pm UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/5 "2023-03-22T18:05:55Z")
> [@georgii](#):
>
> FWIW one of our teams was planning to work on adding support for triggering rule actions per each generated alert separately, which might be a good option for reindexing them as is into a separate index.
Just curious, do you have any public issue tracking this? This is one of the main features that the Kibana Alert is lacking and that is forcing us to stay using a third-party tool, ElastAlert, to trigger our alerts.
---
### Author:  [@georgii](https://discuss.elastic.co/u/georgii)
#### Post date: [March 23, 2023, 10:12am UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/6 "2023-03-23T10:12:05Z")
@leandrojmp I reached out to my colleagues and found out that this is on the short-term roadmap, but is going to be done as part of another feature called Conditional Actions. There's a public issue for that:
>
>
> As a user, I would like my actions to allow me to filter my alert by query and t…ime range to avoid noise on my rule notifications.
>
> \### Server side work
> \- \[x\] Update data model to allow conditional actions
> \- \[x\] Update CRUD API to deal with new attributes from the data model
> \- \[x\] Update API integration to reflect this new changes
> \- \[x\] As of today, alert summary feature only work on querying alert as data indices. Therefore, we should allow to pass the filtering from the conditional actions.
> \- \[x\] We will need to update our \`forEach alert\` feature to filter alert using alert as data when conditional actions are defined. We will still use the in memory alert to build our actions (for example our context and state)
>
> \### Frontend work
> \- \[x\] To allow a better developer experience around our actions, we would like to research if it is possible to migrate our actions form to a kbn packages
> \- \[x\] Build our alert filter for conditional actions by using this \`\[AlertSearchBar\`\](https://github.com/elastic/kibana/tree/main/x-pack/plugins/triggers\_actions\_ui/public/application/sections/alerts\_search\_bar) components
> \
>
> \- \[x\] Build our alert time range filter for conditional actions
> \
>
> \- \[x\] Add unit test around new components
> \- \[x\] Integrate/test with security solutions
>
> \### Docs work
>
> \- \[x\] https://github.com/elastic/kibana/issues/158014
>
> \### Bonus/Stretch goals
> \- \[\] Integrate conditional actions with rule type using alert as data
> \- \[\] Add \`must\_not\` filter on alert as data in actions
>
> \- - -
>
> \### Designs
> \[Figma\](https://www.figma.com/file/LfWMYvLpG5doNcOH4qKWse/Conditional-Actions---Designs?node-id=3874%3A543974&t=RcrBcO7IDzkY67He-1)
> !\[image\](https://user-images.githubusercontent.com/3756330/223442959-8cdc6c4b-9707-4188-a89b-175b51c1f9c0.png)
> We will need to update our `forEach alert` feature to filter alert using alert as data when conditional actions are defined. We will still use the in memory alert to build our actions (for example our context and state)
As I was told, this item refers to the ability to trigger actions per each generated alert separately.
Also, there's another public issue for adding support for writing multiple documents via the Index connector:
>
>
> The ES Index action currently asks users to create a single document to index ea…ch time the action runs. This action can incorporate context variables using mustache templating. It would be useful to allow the Index action to use mustache templating to iterate over a context variable that is an array and specify a document to index for each element of that array.
>
> This was discussed specifically as part of the action handling for the \[search alert\](https://github.com/elastic/kibana/issues/61313) when the hits are passed as an action variable. If we have 1,000 hits for an execution of this alert, we should be able to bulk index 1,000 documents with a single ES index action.
>
> As a reference, other connectors, like the slack connector, can do something like this:
>
> \`\`\`
> You have {{context.value}} matches!
> {{#context.hits}}
> Document with {{\_id}} and hostname {{\_source.host.name}} has {{\_source.system.memory.actual.free}} bytes of memory free
> {{/context.hits}}
> \`\`\`
---
### Author:  [@georgii](https://discuss.elastic.co/u/georgii)
#### Post date: [March 23, 2023, 10:17am UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/7 "2023-03-23T10:17:49Z")
@Iroshu It turns out there's a recent thread where another user had a similar question about reindexing alerts into a separate index.
> [@Creating Multiple Alert Documents when Alert is Triggered](https://discuss.elastic.co/t/creating-multiple-alert-documents-when-alert-is-triggered/327088):
>
> Hi all, I've got a bit of a unique issue. For the system I am developing, data records will be ingested and compared against thresholds to confirm if values are anomalous. To test out this functionality I've set up an alert that applies a range query to check if a value is acceptable or not. I've set up an index connector, so that when the alert is triggered, a document is written to a specific index. The issue I've encountered is that we require one alert document to match up to each docume…
In that thread, it was suggested that for the time being, the best workaround would be leveraging Logstash pipelines for reindexing alerts elsewhere. Related documentation:
- [Creating a Logstash pipeline | Logstash Reference [8.11] | Elastic](https://www.elastic.co/guide/en/logstash/current/configuration.html)
- [Elasticsearch input plugin | Logstash Reference [8.11] | Elastic](https://www.elastic.co/guide/en/logstash/current/plugins-inputs-elasticsearch.html)
---
### Author:  [@georgii](https://discuss.elastic.co/u/georgii)
#### Post date: [March 24, 2023, 9:47am UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/8 "2023-03-24T09:47:21Z")
@leandrojmp We now have a dedicated public issue:
>
>
> \*\*Describe the feature:\*\*
> As a user, I would like the ability to trigger a rule… action (i.e email, slack, jira, etc) per alert generated. Currently, a single rule action is triggered for the group of alerts that were fired during the specified action frequency (i.e rule execution, hourly, daily).
>
> When configuring rule action frequency, the user should have a few options:
>
> \- Summary of alerts
> - Per rule run
> - Custom Frequency
> - Every X hours/days/weeks
> \- For each alert
> - Per rule run
>
> \*\*Proposed Design\*\*
> \[Design Link\](https://www.figma.com/file/5gNkqBLWgtg2TlbGqjGI01/Conditional-logic-for-alert-actions-%232894?node-id=1-38&t=gjljzUPXttOmYUNx-0)
>
> \
---
### Author:  [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)
#### Post date: [March 24, 2023, 11:55am UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/9 "2023-03-24T11:55:23Z")
> [@georgii](#):
>
> We now have a dedicated public issue
Thanks, I will track this as without the ability to trigger a rule action per alert we cannot fully use the Kibana Alerts interface.
We were trying to migrate from ElastAlert and use only Kibana Alerts for a long time, but decided to keep ElastAlert because of all the Kibana Alerts limitations.
Hope this change in the near future.
---
### Author:  [@Iroshu](https://discuss.elastic.co/u/Iroshu)
#### Post date: [March 28, 2023, 1:19pm UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/10 "2023-03-28T13:19:18Z")
Hi @georgii,
Thanks for your feedback and explanation provided. I will give you more details about what we try to achieve.
We are actually testing the elastic solution to see if this on is able to generate alertes to another solution. We try to send information by email and by index connector to see what happens.
Below we generate an event and we would like to receive an alerte with as much as possible information about the log.
> POST /sf-generate-events/\_doc/?pretty
> {
> "@timestamp": "2023-03-28T12:08:00",
> "device": "Fake-solutions1",
> "nomderègle": "i can see yoou1",
> "numeroalerte": "123d",
> "unpeudecontext": "blablablablablbalbalbad",
> "meta1":"meta1",
> "meta2":"meta2",
> "meta3":"meta3",
> "meta4":"meta4",
> "meta5":"meta5",
> "meta6":"meta6"
> }
and rule associated :
We would like to receive (in the index or event by mail) some information about rules conditions and also information about meta1 for exemple.Do you think it's possible ?
Again thanks for your help on this .
---
### Author:  [@Iroshu](https://discuss.elastic.co/u/Iroshu)
#### Post date: [April 11, 2023, 8:58am UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/11 "2023-04-11T08:58:30Z")
Hi teams,
We have done more test about this and we found that we are able to retrieve information in the Signal index when we are using a custom query :
Below the sample of information used :
And the result in the .siem-signals\*
As soon as we use a threshold alerts we lost all information.
Any ideas ? We are losing the interest of the alerting in elastic without this feature.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [May 9, 2023, 8:59am UTC](https://discuss.elastic.co/t/how-to-exploit-rules/328174/12 "2023-05-09T08:59:17Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.