AN0436: Analytic 0436
Unusual processes (e.g., powershell.exe, wscript.exe, mshta.exe) posting data to webhook endpoints (Discord, Slack, webhook.site) using HTTP POST/PUT requests. Defender perspective: suspicious process lineage followed by outbound HTTPS traffic to webhook domains.
Analyst context for executives and security teams
This analytic matters because common Windows scripting and living-off-the-land processes sending data to public webhook services can indicate data staging, exfiltration, or command-style tradecraft that blends into normal HTTPS traffic. For leaders, the decision point is whether the organization can distinguish legitimate automation that uses services like Slack or Discord webhooks from suspicious process-driven outbound posts before an incident becomes a data-loss or investigation problem.
Executive priority
Prioritize this as a validation item for SOC visibility and egress governance on Windows endpoints. The business question is not only “do we block webhooks,” but “can we prove which Windows processes are allowed to post data externally, and can responders quickly determine whether a suspicious POST/PUT was business automation or malicious activity?” This supports incident readiness, audit evidence around monitoring and outbound control, and risk-based decisions about scripting tools such as PowerShell, WScript, and MSHTA.
Technical view
For Windows coverage, validate whether endpoint and network telemetry can correlate suspicious process lineage involving powershell.exe, wscript.exe, mshta.exe, or similar processes with outbound HTTPS HTTP POST/PUT activity to webhook endpoints or domains such as Discord, Slack, or webhook.site. Because the official object provides no ATT&CK tactic and no formal detection logic, teams should treat this as an analytic pattern to operationalize, tune, and test against local business use of webhook services rather than as a complete rule.
Likely telemetry
- Windows process creation events with command line, parent process, user, host, and integrity/context where available
- Process lineage showing scripting or LOLBin-style execution before outbound network activity
- Endpoint network connection telemetry tied to process identity
- Proxy, secure web gateway, firewall, or DNS logs for outbound access to webhook-related domains
- HTTP metadata where available, especially method indicators such as POST or PUT and destination host
Detection direction
- Correlate process creation and process lineage with outbound HTTPS connections rather than alerting on webhook domains alone.
- Tune for unusual parent-child relationships, uncommon users or hosts, and scripting processes making POST/PUT requests to webhook destinations.
- Establish known-good business use of Slack, Discord, webhook.site, or similar webhook endpoints to reduce false positives.
- Validate whether encrypted HTTPS inspection limitations prevent visibility into HTTP method or request metadata; if so, rely more heavily on process-to-destination correlation and proxy/DNS context.
- Avoid assuming every webhook connection is malicious; prioritize cases involving suspicious Windows processes, abnormal lineage, or endpoints that do not normally perform automation.
Mitigation priorities
- Inventory and document approved webhook use across business automation and development workflows.
- Restrict or monitor outbound access to unapproved webhook destinations where business requirements allow.
- Harden and monitor use of Windows scripting hosts and PowerShell according to organizational policy.
- Ensure endpoint logging captures process command line and network connections with enough fidelity for incident reconstruction.
- Create response playbooks for suspected process-driven webhook data transfer, including host isolation criteria, user/account review, and evidence preservation.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Windows describing unusual processes posting data to webhook endpoints over HTTP POST/PUT, with a defender perspective focused on suspicious process lineage followed by outbound HTTPS traffic. No tactic, relationship context, or official detection logic was supplied, so implementation should be based on local telemetry, approved webhook usage, and SOC tuning requirements.
This take is limited to the official STIX fields, external reference, and absence of relationships provided. It does not establish active exploitation, actor attribution, guaranteed detection coverage, impact, or applicability beyond Windows. Local environment baselining is required to separate legitimate webhook automation from suspicious behavior.
Analytic 0436
Unusual processes (e.g., powershell.exe, wscript.exe, mshta.exe) posting data to webhook endpoints (Discord, Slack, webhook.site) using HTTP POST/PUT requests. Defender perspective: suspicious process lineage followed by outbound HTTPS traffic to webhook domains.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 35bddfbfa41b… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0436Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.