Webhook endpoint domain resolved by a script host or transfer tool

Siemphony@siemphonylowT1567.004unverified

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

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.

Lessondata staging exfil

data staging exfil

01 · What this rule detects

Collection before departure: files gathered from profiles and shares, compressed — often into a password-protected archive — dropped into a staging directory, and then moved out of the environment. The staging half is the reliably detectable half, and it usually happens close enough to the transfer that catching it still leaves time to act.

02 · Telemetry you need

Process creation with full command lines for archiving utilities — 7z, rar, WinRAR's console build, tar.exe, makecab, and PowerShell Compress-Archive; the switches are the interesting part, so a truncated command line is worthless here
Sysmon EventID 11 (FileCreate) for archive extensions written under Temp, ProgramData, Public and the recycle bin
Sysmon EventID 3 (NetworkConnect) with DestinationIp, DestinationHostname, DestinationPort and Initiated, tied to the uploading process
Proxy, firewall or flow logs with bytes sent per session — these are the only records that carry volume and direction, and neither Sysmon nor the Security log has them
Security 5145 (detailed file share access) and 4663 (object access) for reads across shares — 5145 requires Audit Detailed File Share, 4663 requires Audit Object Access plus a SACL on the data itself, and all of it is off by default
DNS query logs, for the cloud storage and tunnelling destinations the transfer half resolves

03 · How the logic works

Split this into two rules, because it is really two behaviours with different telemetry. The staging rule is a process rule: an archiving utility invoked with a recursion switch, an output path under a staging directory, or a password flag, over a source path that holds user data or share content. Anchor on the switches and the paths rather than the tool name — a renamed rar.exe still needs the same arguments to do the same job — and keep the password flag as its own higher-severity condition, since ordinary backup rarely needs one. The transfer rule is a volume and destination rule, and it does not express well in Sigma: there is no aggregation, so the bytes-sent threshold and the per-destination grouping live in the backend query or the correlation layer. The pairing that makes both worth having is sequence — an archive created, then that same file opened by a process that immediately connects outbound.

04 · Common false positives

Backup and archiving agents doing precisely this by design, including Veeam, Acronis and Windows Server Backup
Sanctioned cloud sync clients — OneDrive, Dropbox, Box — moving large volumes to destinations that are supposed to receive them
Developers and build agents compressing source trees, artefacts and logs, and CI runners uploading them
IT collecting diagnostic bundles and log archives for a vendor support case
E-discovery, DLP and data-classification scanners reading broadly across shares, and migration tooling moving mailboxes or file servers

05 · Detection maturity

Tier 1 — starting point: Matches archiving utility command lines by tool name.
Tier 2 — tuned: Matches recursion and password switches over sensitive source paths, with backup and sync clients excluded by signed path.
Tier 3 — correlated: Correlates archive creation with the subsequent read and outbound transfer of that file, scored on destination novelty and volume.

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

Password-protected archives of user data are the highest-payoff single condition in this category; alert on those before anything else
Scope the staging rule by source path — profile directories and file shares — rather than by the utility, so unfamiliar tools still match
Exclude sanctioned cloud sync by the signed path of the client process, not by destination domain, or you excuse anything that can reach the same domain
Keep staging and transfer as separate alerts so each stays actionable, and correlate them for severity rather than merging them into one rule
Where the archive is written matters more than what wrote it: a user-writable staging directory holding an archive of someone else's data is the shape you are looking for

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.

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.

Verification1 run

Not verified

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

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.

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