Threat actors are increasingly abusing Discord webhooks as covert command-and-control (C2) channels inside open-source packages, enabling stealthy exfiltration of secrets, host telemetry, and developer environment data without standing up bespoke infrastructure.
Socket’s Threat Research Team has documented active abuse across npm, PyPI, and RubyGems, where hard-coded Discord webhook URLs act as write-only sinks to siphon data over HTTPS to attacker-controlled channels.
Because webhook posts resemble ordinary JSON traffic to a widely allowed domain, these operations often bypass perimeter filtering and signature-based controls.
How Discord Webhooks Become Exfiltration Pipes
Discord webhooks are HTTPS endpoints that require only possession of a URL containing an ID and secret token to post messages to a channel.
Live endpoints typically return 204 No Content on success or 200 OK with ?wait=true, while 401, 404, and 429 indicate invalid tokens, deletion, or rate limits respectively.
Critically, webhook URLs are write-only—defenders cannot read prior channel history from the URL alone—making takedown and retrospective investigation harder while lowering attacker friction and cost.
- Write-only access: Webhook URLs only allow posting messages, not reading channel history.
- Minimal authentication: Only requires possession of URL containing ID and secret token.
- Standard HTTP responses: Live endpoints return predictable status codes for validation.
- Stealth advantage: Traffic appears as legitimate JSON posts to popular Discord domain.
Malicious Packages Across Ecosystems
In npm, mysql-dumpdiscord targets sensitive configuration artifacts such as config.json, .env, ayarlar.js, and ayarlar.json (Turkish for “settings”), reading and chunking file contents before POSTing them to a hard-coded Discord webhook.
Even simpler, nodejs.discord implements a thin wrapper around discord.js that forwards arbitrary strings to an embedded webhook URL; while sometimes used for logging, this pattern can trivially become a data sink if invoked during install scripts or runtime.
On PyPI, malinssx overrides setuptools’ install command to silently trigger a POST to a Discord webhook during pip install, sending a notification message in Vietnamese.
Identical packages (malicus, maliinn) were published by the same actor handle, sdadasda232323, reusing the same webhook—an indicator of automated or iterative seeding across names to evade single-package takedowns.
- npm targeting: Configuration files like .env, config.json, and Turkish “ayarlar” settings files.
- PyPI infiltration: Install-time hooks that execute during pip install process.
- RubyGems exploitation: Host-level data collection including /etc/passwd and system metadata.
- Cross-platform persistence: Same threat actors deploying across multiple package ecosystems.
On RubyGems, sqlcommenter_rails goes further, collecting host-level signals including /etc/passwd contents, DNS resolvers from /etc/resolv.conf, username, hostname, working and home directories, package metadata, and public IP via api.ipify.org, before serializing and shipping the full payload to a hard-coded Discord webhook. Errors are suppressed throughout, favoring silent failure over noisy exceptions.
Why This Tactic Works—and What To Do
Discord webhook C2 flips the economics of supply-chain abuse. It’s free, fast, blend-in traffic over TLS to a popular domain, and requires no authentication workflow beyond URL possession.
When paired with install-time hooks, postinstall scripts, or Ruby/Python setup overrides, these packages can exfiltrate secrets from developer laptops and CI runners long before application runtime controls or EDR detections engage.
Similar patterns are also observed with Telegram, Slack, and GitHub webhooks, underscoring a broader pivot to “commodity C2 as a service” that erodes the value of static IOCs.
- Economic advantage: Free infrastructure eliminates hosting costs and technical complexity.
- Evasion tactics: TLS traffic to trusted domains bypasses most security controls.
- Timing exploitation: Install-time execution occurs before runtime security monitoring.
- Expanded attack surface: Similar patterns emerging across Telegram, Slack, and GitHub webhooks.
Mitigations should center on behavioral and egress controls. Treat webhook endpoints as potential exfiltration vectors and enforce allow-lists with DNS and TLS SNI filtering where feasible.
Pin dependencies with lockfiles, require provenance/SLSA attestations, and gate dependency updates through PR scanning that flags hard-coded webhook URLs, outbound network calls, and install-time execution.
Scan for secret access in package diffs and rotate developer credentials with least-privilege scopes. In CI, deny outbound internet by default for build and test steps, granting narrowly scoped exceptions.
Finally, equip developer workflows with package reputation and malware detection that can intercept webhook-based exfiltration patterns before they land.
Indicators of Compromise (IoCs):
| ID | Technique Name |
|---|---|
| T1005 | Data from Local System |
| T1016 | System Network Configuration Discovery |
| T1020 | Automated Exfiltration |
| T1033 | Account Discovery |
| T1059 | Command and Scripting Interpreter |
| T1059.006 | Command and Scripting Interpreter: Python |
| T1059.007 | Command and Scripting Interpreter: JavaScript |
| T1071.001 | Application Layer Protocol: Web Protocols |
| T1082 | System Information Discovery |
| T1119 | Automated Collection |
| T1195.002 | Supply Chain Compromise: Compromise Software Supply Chain |
| T1552.001 | Unsecured Credentials: Credentials In Files |
| T1567 | Exfiltration Over Web Service |
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
