Detect unusual wget or curl use by looking for outbound transfers to external hosts, especially from servers that rarely browse the internet. Correlate command-line arguments, destination domains, file write activity, and bursts of uploads or downloads from service accounts. Watch for execution from scripts, cron jobs, web shells, or temporary directories, and review proxy, DNS, and process telemetry together.
How wget and curl become useful exfiltration signals
wget and curl are not suspicious just because they exist on Linux, but they are high-signal when they make outbound transfers that do not fit the host’s normal role. The strongest clue is context: a server that rarely reaches the internet, then suddenly pulls from or pushes to an unusual host, often through a script, cron entry, or interactive shell.
Detection works best when you treat the command, the destination, and the file activity as one event. A lone network alert is weaker than a chain that shows a shell launching curl or wget, a new file being written or staged, and a burst of uploads, downloads, or follow-on execution. That pattern is especially useful when the command runs from a temporary path or a service account that should not be browsing outward.
On Linux, the practical question is not whether curl or wget ran, but whether the transfer was expected. A package update mirror, an admin download, and a scripted backup job can all be legitimate. What makes them stand out is drift from baseline, such as a web server reaching a file-sharing domain, a database host contacting an archive site, or a container pulling data from a host it has never contacted before.
Telemetry that makes the activity provable
Process telemetry gives you the first anchor: parent process, command line, working directory, user context, and timing. A curl or wget process started by php, nginx worker activity, cron, a one-off shell, or a suspicious script path is much more informative than the binary name alone. Preserve the exact arguments, because attackers often hide the target in redirects, short-lived URLs, or shell expansions.
Network telemetry adds the second anchor: destination domain, resolved IP, port, protocol, and byte counts. DNS logs help when the process uses a fresh or rare domain, while proxy logs help when the transfer is hidden inside normal egress. If you can correlate the process start with a DNS query and then a new outbound session, you get a much stronger signal than any one source in isolation.
File telemetry closes the loop by showing whether the transfer touched sensitive paths, created archives, or dropped staging files. Look for compressed output in /tmp, /var/tmp, hidden directories, or application-specific scratch space, then check whether that file is later reused, renamed, or sent out again. In many cases, the exfiltration story is not a single transfer but a short workflow: collect, compress, transfer.
For a broader detection model, the Living off the Land Guide is useful because wget and curl often appear as dual-use utilities inside normal administrative activity and attacker tradecraft.
How to separate routine transfers from data theft
Start with the host’s expected behavior. Internet-facing Linux systems are more exposed than internal-only systems, but even then, the outbound destinations should usually be narrow and stable. A good triage rule is to give higher priority to transfers that involve unusual destination domains, uncommon user accounts, non-interactive execution, and a file write pattern that suggests packaging data for removal.
Then compare volume and cadence. Exfiltration often shows bursts, repeated small transfers, or a one-time large upload after a local collection phase. That differs from routine software pulls, which are often predictable in destination, time, and size. When possible, inspect whether the same process or script runs repeatedly on a schedule, because scheduled theft can look clean in isolation but obvious across time.
Do not ignore proxy and DNS suppression. Attackers who want to blend in may use plain HTTP(S), common CDNs, or domain fronting-like patterns, while others may tunnel through allowed egress paths. If your only control is perimeter blocking, you may miss the local process that initiated the transfer. Matching endpoint process data with egress data is what makes the detection defensible.
What to do when the signal is strong
Once curl or wget is tied to suspicious outbound movement, determine whether the host is the source of the data, the pivot point, or both. If the command touched credential stores, application exports, archives, or tokens, the response should widen from endpoint triage to data exposure assessment. If the transfer was launched from a service account or automation account, review what that account could access before deciding the event was low impact.
When you have evidence of unauthorized collection or transfer, preserve command history, shell artifacts, scheduled tasks, logs, and network records before containment changes them. Then search for the same pattern elsewhere in the fleet, because attackers often reuse the same method across multiple hosts. A single confirmed wget or curl exfiltration event is often a discovery point, not the finish line.
If you want a deeper ATT&CK-style view of how transfer utilities fit into exfiltration tradecraft, the Data Exfiltration Guide covers the surrounding collection, staging, and egress patterns that make these transfers easier to spot.
Risk and Threat Considerations
wget and curl are attractive because they are native, trusted, and widely permitted. That makes them useful for both legitimate automation and attacker-led exfiltration, especially on servers where outbound internet access is uncommon and monitoring is thin. The risk increases when scripts, cron jobs, or service accounts can move data outward without a clear business justification.
Failure mechanism: The defender sees a normal utility instead of a suspicious data path, so the transfer blends into administrative noise unless process, DNS, proxy, and file-write telemetry are correlated. Attackers can also split collection and transfer across multiple steps, which makes each individual event look harmless.
Impact: Sensitive files, tokens, or application data can leave the host before anyone notices, and the same technique can be repeated across systems with little operational friction. Once the pattern is established, it can support broader staging, persistence, or follow-on compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1048 — Exfiltration Over Alternative Protocol | wget and curl are common tools for outbound exfiltration paths. |
| T1059 — Command and Scripting Interpreter | The activity often starts from shell, script, cron, or web-shell execution. | |
| Recommendation — Map unusual wget and curl transfers to exfiltration techniques and hunt for matching network and process chains. Correlate wget and curl use with script or shell execution to distinguish automation from abuse. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on correlating endpoint, DNS, proxy, and process telemetry. |
| CIS-12 — Network Infrastructure Management | Outbound control and egress visibility are central to spotting suspicious external transfers. | |
| Recommendation — Centralize process, DNS, proxy, and file logs so suspicious transfer chains can be reconstructed quickly. Restrict and monitor outbound destinations so unexpected transfers from servers stand out. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Reviewing correlated logs is necessary to identify suspicious exfiltration chains. |
| SI-4 — System Monitoring | Continuous monitoring is needed to detect suspicious wget or curl behavior on Linux. | |
| Recommendation — Analyze correlated audit records to connect process launches with outbound transfers and file activity. Monitor process, network, and file activity to flag unauthorized data transfers in near real time. | ||
Practitioner Guidance
What to verify: Confirm the initiating process, the user context, the destination, and the file path before you decide the transfer was legitimate. If any one of those four is weak or missing, treat the event as incomplete evidence rather than a closed case.
Common mistake: Teams often alert on the binary name and stop there. That misses the real distinction between a routine package fetch and an outbound transfer that is attached to sensitive file creation, unusual parentage, or a host that should not be talking to the internet at all.
Practitioner takeaway: The best detections are correlation problems, not keyword problems, because wget and curl are only suspicious when the command, the destination, and the file activity line up in a way that matches theft rather than administration.
Related resources from NHI Mgmt Group
- How should security teams detect SAP compromise before data exfiltration starts?
- How do security teams detect package-based data exfiltration in practice?
- How should security teams detect data exfiltration when policy rules are too rigid?
- How should security teams detect AI-mediated data exfiltration in cloud environments?