Push rules into Splunk or Sentinel
A deployment usually means Huntbase searches your store on a schedule. For Splunk and Microsoft Sentinel there is a second way: Huntbase can push the watcher into the SIEM as one of its own rules.
| SIEM | What Huntbase creates |
|---|---|
| Splunk | A scheduled saved search with an alert |
| Microsoft Sentinel | A scheduled analytics rule |
The SIEM runs the rule on its own schedule, so it uses none of your query budget. Its alerts come back to Huntbase.
Allow a connection to write rules
Your connections are read-only by default. To push rules, a connection admin adds a second, separate credential to the connection: a rule-write credential.
- Huntbase uses it only to create, update and delete the rules it pushes.
- Searches never use it, and it can't become the connection's default credential.
- Deleting it ends the permission. Rules already pushed stay in the SIEM until you remove their deployments, so remove them first.
Adding the credential needs permission to manage the connection's credentials. Sample and simulated connections can't write rules.
What to grant in Splunk
Create a dedicated user, for example svc_huntbase_rules, with its own role,
and give Huntbase that user's authentication token. The role needs:
- the schedule_search capability;
- write permission on the app the searches go in:
search, or ahuntbaseapp made for this; - read access to the indexes the rules search;
- the webhook alert action. On Splunk 9.0.1 and later, add the Huntbase webhook host to the webhook allow list. In Splunk Cloud it is under Settings › Server settings › Webhook allow list.
Huntbase must reach Splunk's management port (8089 by default). In Splunk Cloud, add Huntbase's addresses to the REST API allow list.
Don't grant admin_all_objects. Without it, the user can change only the
searches it owns, which are Huntbase's.
What to grant in Sentinel
Register an app in Microsoft Entra ID, or reuse one (a separate app is cleaner), and create a client secret. Then:
- assign the app the Microsoft Sentinel Contributor role on the workspace's resource group, or on the workspace itself. Reader roles aren't enough;
- give Huntbase the tenant ID, client ID, client secret, subscription ID, resource group name and workspace name.
The connection keeps its read credential for searches and for collecting alerts.
Push a watcher
On a Sigma watcher's Deploy tab, each Splunk or Sentinel connection the watcher doesn't run in yet has a line:
- Push to Splunk or Push to Sentinel when the connection has a rule-write credential. A new push starts in Shadow.
- Add a rule-write credential otherwise, with the reason. It opens the connection's credentials.
Pushing, changing, re-pushing and removing a rule needs permission to manage watchers, to use the connection, and to write rules on it. Connection admins and organisation admins have that last permission.
In Splunk, the saved search is named Huntbase - <watcher> [<id>]. In both SIEMs, the rule's description ends with a Huntbase marker. Leave it in place: Huntbase uses it to recognise its rules.
Modes
| Mode | In the SIEM |
|---|---|
| Off or Paused | The rule stays in the SIEM, turned off. |
| Shadow | The rule runs. In Sentinel it raises no incidents. Nothing reaches Needs you. |
| On | The rule runs, with incidents in Sentinel. |
When you edit the watcher, Huntbase pushes the new version for you.
Statuses
Besides the usual statuses, a pushed rule can show:
| Status | What it means |
|---|---|
| Needs a rule-write credential | Add one to the connection. Huntbase pushes the rule shortly after. |
| Push failing | The SIEM refused the last push, for example because the credential lost a permission. |
| Still in Splunk / Still in Sentinel | You removed the deployment, but Huntbase couldn't delete the rule yet. It keeps trying. |
Drift
Someone can edit or delete the rule inside the SIEM. Huntbase reads each rule back every hour and compares the parts it manages: query, schedule, time range, severity, on/off, alert actions, description and ATT&CK tags.
| Chip | What it means |
|---|---|
| Matches Huntbase | The rule in the SIEM is the one Huntbase pushed. |
| Edited in Splunk | Someone changed it. The detail names what changed. Re-push puts the Huntbase version back. |
| Deleted in Sentinel | The rule is gone from the SIEM. Re-push adds it again. |
| Couldn't check | Huntbase couldn't read the rule back, so it doesn't know. It is never shown as matching. |
| Not checked yet | The first check hasn't run. |
Where alerts are handled
Each pushed rule has a Where alerts are handled setting:
| Choice | What happens |
|---|---|
| In Huntbase (default) | Alerts from the rule become detections in Needs you. Use this when your team triages in Huntbase. |
| In Splunk only / In Sentinel only | Your team triages in the SIEM. Huntbase records each detection and where it came from, but asks no one to review it, so nothing is triaged twice. |
Either way the detection lists the SIEM under Seen in. A pushed rule's match is always a Store verdict: the SIEM's query decides, and Huntbase doesn't re-check the rows.
How alerts come back
- Splunk sends each alert to the connection's Huntbase webhook. The connection needs an active webhook. Without one the push still works, but the deployment warns that alerts stay in Splunk.
- Sentinel has no outbound webhook. Huntbase collects the rule's alerts from the workspace every few minutes, using the read credential.
Remove a pushed rule
Remove on the row deletes the rule Huntbase pushed into the SIEM. Alerts it already raised stay where they are. You can't delete a watcher while it still has rules in a SIEM: remove them on the Deploy tab first.