Webhook endpoint domain resolved by a script host or transfer tool

Siemphony@siemphonylowT1567.004unverifiedPlaybook · Collection and exfiltration

Matches a DNS lookup for a webhook-dedicated hostname — hooks.slack.com or webhook.site — made by a scripting host or a command-line transfer tool, which is the outbound leg of AN0436 reduced to a single event. The domain list populates MITRE's WebhookDomains knob, but the two values are chosen here, and chosen narrowly: only hostnames that exist to serve webhooks qualify. discord.com and discordapp.com were removed because Discord has no dedicated webhook subdomain, so at the DNS layer a webhook post is indistinguishable from the chat client, and because both names are already in the published parent T1567 rule paired with a superset of this rule's process list — every event they could match here matches there, under the parent ID, with no webhook-specific evidence added. The only sibling that genuinely uses this dns_query pattern is T1567.001 (code repositories); T1567.002 moved to process_creation to avoid duplicating the parent, and T1567.003 was declined outright for that duplication, so this rule follows one precedent rather than three. The process gate is what keeps a match meaningful: pairing the lookup with a scripting engine or transfer utility separates a scripted post from a browser session. AN0436's other legs — the HTTP method (POST/PUT), MITRE's UploadSizeThreshold knob, and the file-access step that is supposed to precede the post — need a request body, a numeric comparison and a correlation that Sigma cannot express, so this rule sees only that a webhook domain was contacted, never what was sent or whether a file was read first. It also sees nothing at all unless the running Sysmon configuration enables DNS query logging, which is off in a default Sysmon deployment and has to be added explicitly. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0153, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

1title: Webhook endpoint domain resolved by a script host or transfer tool2id: 32cc1959-e7d5-42dc-8291-096d7f238b6d3status: experimental4description: |5  Matches a DNS lookup for a webhook-dedicated hostname — hooks.slack.com or6  webhook.site — made by a scripting host or a command-line transfer tool, which7  is the outbound leg of AN0436 reduced to a single event. The domain list8  populates MITRE's WebhookDomains knob, but the two values are chosen here, and9  chosen narrowly: only hostnames that exist to serve webhooks qualify.10  discord.com and discordapp.com were removed because Discord has no dedicated11  webhook subdomain, so at the DNS layer a webhook post is indistinguishable12  from the chat client, and because both names are already in the published13  parent T1567 rule paired with a superset of this rule's process list — every14  event they could match here matches there, under the parent ID, with no15  webhook-specific evidence added. The only sibling that genuinely uses this16  dns_query pattern is T1567.001 (code repositories); T1567.002 moved to17  process_creation to avoid duplicating the parent, and T1567.003 was declined18  outright for that duplication, so this rule follows one precedent rather than19  three. The process gate is what keeps a match meaningful: pairing the lookup20  with a scripting engine or transfer utility separates a scripted post from a21  browser session. AN0436's22  other legs — the HTTP method (POST/PUT), MITRE's UploadSizeThreshold knob, and23  the file-access step that is supposed to precede the post — need a request24  body, a numeric comparison and a correlation that Sigma cannot express, so25  this rule sees only that a webhook domain was contacted, never what was sent26  or whether a file was read first. It also sees nothing at all unless the27  running Sysmon configuration enables DNS query logging, which is off in a28  default Sysmon deployment and has to be added explicitly.29  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0153, not hand-written and not tested by its author. Any lab result is on this rule's own page.30references:31  - https://attack.mitre.org/techniques/T1567/00432  - https://attack.mitre.org/detectionstrategies/DET015333author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)34date: 2026-08-1635tags:36  - attack.exfiltration37  - attack.t1567.00438logsource:39  category: dns_query40  product: windows41detection:42  selection_process:43    Image|endswith:44      - '\powershell.exe'45      - '\pwsh.exe'46      - '\cscript.exe'47      - '\wscript.exe'48      - '\mshta.exe'49      - '\curl.exe'50      - '\certutil.exe'51  selection_webhook:52    QueryName|endswith:53      - 'hooks.slack.com'54      - 'webhook.site'55  condition: selection_process and selection_webhook56falsepositives:57  - "CI/CD pipelines and monitoring agents posting build, deployment or alert notifications to a Slack webhook from PowerShell or curl.exe on a build or admin host — this is the single largest legitimate use of hooks.slack.com and is likely the dominant source of matches by volume."58  - "Developers and QA engineers deliberately resolving webhook.site via a curl.exe smoke-test script while building or debugging an HTTP integration, which is the tool's entire supported purpose."59  - "ChatOps bots and RPA scripts that bridge ticketing, backup or patch-compliance status into a Slack channel on a fixed schedule, producing the same lookup from the same PowerShell wrapper on every run."60  - "Security, backup or monitoring products with a built-in Slack notification feature, resolving hooks.slack.com from a PowerShell-based agent or connector service as part of normal, unattended operation."61level: low

Splunk · SPL

Run this as a search.

index=* ((Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR Image="*\\cscript.exe" OR Image="*\\wscript.exe" OR Image="*\\mshta.exe" OR Image="*\\curl.exe" OR Image="*\\certutil.exe") AND (QueryName="*hooks.slack.com" OR QueryName="*webhook.site"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.executable) LIKE "*\\\\powershell.exe" OR TO_LOWER(process.executable) LIKE "*\\\\pwsh.exe" OR TO_LOWER(process.executable) LIKE "*\\\\cscript.exe" OR TO_LOWER(process.executable) LIKE "*\\\\wscript.exe" OR TO_LOWER(process.executable) LIKE "*\\\\mshta.exe" OR TO_LOWER(process.executable) LIKE "*\\\\curl.exe" OR TO_LOWER(process.executable) LIKE "*\\\\certutil.exe") AND (TO_LOWER(dns.question.name) LIKE "*hooks.slack.com" OR TO_LOWER(dns.question.name) LIKE "*webhook.site"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,dns_query,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)(\\powershell\.exe$|\\pwsh\.exe$|\\cscript\.exe$|\\wscript\.exe$|\\mshta\.exe$|\\curl\.exe$|\\certutil\.exe$)</field>    <field name="QueryName" type="pcre2">(?i)(hooks\.slack\.com$|webhook\.site$)</field>    <description>Webhook endpoint domain resolved by a script host or transfer tool</description>    <mitre>      <id>T1567.004</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"category":"dns_query","product":"windows"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: dns_query / windows
Level: low
Category: data_staging_exfil
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 32cc1959-e7d5-42dc-8291-096d7f238b6d

ATT&CKT1567.004

T1567.004Exfiltration Over Webhook

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Evidence

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Noise check0 of 1 fired

The baseline holds exactly one ordinary behaviour for this log type, and the rule does not fire on it. One event is close to no evidence: this says the rule is not caught by that one behaviour, and nothing more.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1567.004, evaluated against their dns_query events.

Using it

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Add more specific process exclusions based on known legitimate software that uses the same executable names
Filter out queries for specific webhook domains that are known to be used for legitimate purposes in the organization
Consider adding additional conditions, such as the presence of suspicious command-line arguments or network connectivity patterns

Declared by the author

CI/CD pipelines and monitoring agents posting build, deployment or alert notifications to a Slack webhook from PowerShell or curl.exe on a build or admin host — this is the single largest legitimate use of hooks.slack.com and is likely the dominant source of matches by volume.
Developers and QA engineers deliberately resolving webhook.site via a curl.exe smoke-test script while building or debugging an HTTP integration, which is the tool's entire supported purpose.
ChatOps bots and RPA scripts that bridge ticketing, backup or patch-compliance status into a Slack channel on a fixed schedule, producing the same lookup from the same PowerShell wrapper on every run.
Security, backup or monitoring products with a built-in Slack notification feature, resolving hooks.slack.com from a PowerShell-based agent or connector service as part of normal, unattended operation.

Lessondata staging exfil

data staging exfilAI draft — unreviewed

01 · What this rule detects

This Sigma rule detects potential data exfiltration via webhooks by identifying DNS queries for known webhook endpoint domains that are initiated by script hosts or transfer tools. The key factor that separates this behavior from normal activity is the combination of the querying process and the specific domain being resolved, which may indicate malicious data staging.

02 · Telemetry you need

Log source: DNS query logs
Specific fields: Image (process image path), QueryName (DNS query name)
Audit setting: DNS query logging must be enabled, which may be off by default in some environments

03 · How the logic works

The rule selects DNS query events where the process initiating the query is a script host or transfer tool, such as PowerShell, cscript, or curl, as indicated by the Image field ending with specific executable names. It also selects events where the DNS query is for a known webhook endpoint domain, such as hooks.slack.com or webhook.site, as indicated by the QueryName field ending with these domain names. The rule triggers an alert when both conditions are met, suggesting potential data exfiltration via a webhook.

04 · Common false positives

Legitimate use of PowerShell or other script hosts for automation or development tasks that involve querying webhook domains
Use of curl or other transfer tools for downloading or uploading files from webhook sites
Integration tools or services that use webhook endpoints for legitimate data transfer or notification purposes

05 · Detection maturity

tier_1: The rule as written provides a basic detection capability but may generate noise due to legitimate use of script hosts and transfer tools.
tier_2: With tuning, such as adding process exclusions and filtering out known legitimate webhook domains, the rule can become more effective at detecting malicious activity while reducing false positives.
tier_3: Correlating this rule with other signals, such as network traffic analysis or endpoint detection, can provide a more comprehensive understanding of potential data exfiltration attempts and improve the overall maturity of the detection capability.

Related detections6 nearby

Ranked by how alike the detection logic reads, computed offline. Proximity is not evidence — each of these carries its own verification state on its own page.

Share this rule

/u/siemphony/32cc1959-e7d5-42dc-8291-096d7f238b6d

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Webhook endpoint domain resolved by a script host or transfer tool

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it