How do attackers use wget?

How wget becomes useful in attacker tradecraft

Attackers rarely use wget for the binary itself. They use its normal behaviour, HTTP and HTTPS retrieval, to pull down payloads, scripts, staged archives or configuration files from infrastructure they control. That makes it attractive in hands-on-keyboard intrusion work, because it blends into legitimate administration and is often already present on Linux and Unix-like systems.

The key security point is that wget is usually an execution enabler, not the end goal. It helps move code or data into the environment so the next stage can run locally, whether that is a shell script, a second loader, or a configuration file that changes how the intrusion behaves.

On managed systems, wget also gives defenders a clear opportunity for detection. Command-line telemetry, process ancestry, destination hosts, user context and file creation events often reveal whether a download is routine patching, automation, or an unusual retrieval from an external server.

Why staged downloads matter to defenders

Staging lets an attacker separate delivery from execution. A short initial command can fetch the real payload later, which reduces the amount of malicious material exposed in a single event and lets the operator swap payloads without changing the first command. That pattern is common in intrusion chains that start with a simple downloader and end with a more capable tool.

Attackers also use wget to retrieve supporting files that make the intrusion durable or easier to operate, such as configuration files, lists of targets, or scripts that handle follow-on actions. In practice, that means a suspicious wget invocation may be the first visible sign of a broader compromise, not just an isolated download.

Defenders should treat unexpected outbound retrieval as an investigation lead even when the downloaded content is not immediately executable. A benign-looking text file can still be an indicator of staging, credential use, command dispatch, or preparation for later persistence.

For broader threat context, the use of a common utility as a downloader fits the same attacker pattern described in the Living off the Land Guide. It is also consistent with the kinds of intrusion paths collected in The State of NHI & AI Agent Breach Report 2026, where stolen access and staged retrieval often appear together.

How to investigate suspicious wget activity

Start with the process context, not just the file transfer. A wget command launched by an interactive admin session is a different signal from the same command running under a service account, a scheduler, or an application process. Parent process, command-line arguments, working directory and destination path usually tell you whether the download is part of normal automation or a likely intrusion step.

Next, inspect the target URL and the downloaded object. Suspicious signs include unusual domains, raw IP addresses, temporary hosting, file names that do not match the host role, and downloads into writable directories that later feed execution paths. If the transfer is followed by chmod, shell execution, script interpreters or archive extraction, the case for malicious staging becomes much stronger.

Network controls matter because wget is often used to reach out to external infrastructure after initial access. Restricting outbound access where practical, monitoring rare destinations, and alerting on downloads from servers that normally should not fetch code all reduce the attacker’s room to operate. This is especially important on servers, automation hosts and jump systems where outbound access is usually narrower than on user workstations.

Where Linux and Unix estates are in scope, the detection problem overlaps with general command-and-control via legitimate tooling. The MITRE ATT&CK Enterprise Matrix is a useful reference for mapping download activity to follow-on execution and persistence behaviours, while CISA cyber threat advisories provide current adversary tradecraft and defensive priorities.

Risk and Threat Considerations

Wget becomes risky when it is available on systems that can reach sensitive internal assets or the internet without tight egress control. An attacker who already has a foothold can use it to fetch a second-stage payload, retrieve a script that performs discovery or credential theft, or repeatedly pull updated tooling until the intrusion is stable.

Failure mechanism: The control failure is usually not wget itself, but the combination of outbound reachability, weak command-line visibility, and trusted execution from a legitimate utility. That lets malicious downloads look like routine administration unless defenders inspect the parent process, destination and post-download behaviour.

Impact: Successful use can lead to staged malware delivery, rapid tool changes, persistence setup and faster lateral movement, especially when service accounts or automation identities are the ones making the request. Once the attacker can fetch what they need on demand, containment becomes harder because the environment is already acting as its own downloader.

Practitioner Guidance

What to verify: Confirm whether wget use is expected for the host role, the account and the destination. A download from a server or workstation that normally should not reach the internet is more important than the mere presence of wget in process logs.

Decision rule: If the command is executed by a service account, scheduler or automation path, treat it as higher priority than the same command from an interactive admin session. If the download is followed by execution, archive extraction or script interpreter activity, escalate immediately and look for staging of a second phase.

What practitioners underestimate: The first wget call is often not the payload, it is the delivery mechanism. The real question is whether the system should have been allowed to retrieve anything at all, and whether that retrieval created a path to execution, persistence or further outbound contact.

Practitioner takeaway: The most useful defender mindset is to treat unexpected wget activity as a boundary event, not a utility event, because the security significance usually comes from who ran it, where it went, and what happened immediately after the download.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?