Detecting and Mitigating Ingress Tool Transfer (T1105)

Ingress Tool Transfer (T1105) is a command and control technique in MITRE ATT&CK. It covers ESXi, Linux, macOS, network devices and Windows, which is a wide net. Almost every intrusion needs it at some point, because the first foothold is usually small and the attacker has to bring more tooling in.

This post walks through what MITRE documents, what to log, and how to make it hard for a compromised server to fetch anything it likes.

How attackers use it

MITRE describes the technique as transferring tools or other files from an external system into a compromised environment. Files can arrive through the command and control channel or through alternate protocols such as FTP. Once a tool is inside, an adversary may copy it between victim devices, which MITRE tracks separately as lateral tool transfer.

The utilities involved are mostly ones already on the box:

• On Windows, MITRE names copy, finger and certutil, plus PowerShell downloads using a web client or Invoke-WebRequest.
• On Linux and macOS, it names curl, scp, sftp, tftp, rsync, finger and wget.
• A number of those, including wget, curl and scp, also exist on ESXi.
• After a download, an adversary may check the file's hash, for example with certutil on Windows.

Two less obvious paths from MITRE:

• Installers and package managers, such as yum or winget, can be abused to download tools onto a host.
• File application features can be abused as well. MITRE names the Windows search-ms protocol handler, which can deliver files through remote file searches launched after a user interacts with a phishing lure.

Files can also move over web services or over other tools already present. Because the tools are native, there is no obvious malware binary at the start of the chain.

How to detect it

MITRE's strategy, Detect Ingress Tool Transfers via Behavioral Chain, looks at what happens around the transfer rather than at one command. The analytics describe:

• Unusual processes opening network connections to external destinations, followed by file creation.
• Shell tools such as curl, wget or scp connecting to external domains, followed by executable files appearing on disk.
• curl or wget execution followed by a network connection and a new file in a temporary or user-specific directory.
• On ESXi, a command line or vCLI triggering a remote transfer with wget or curl, writing into datastore paths or local temp directories.
• On network devices, logs showing anomalous inbound file transfers or high payload flows to devices with storage or automation hooks.

Data to collect:

• Process creation with full command lines. On Windows that means Security event 4688 with command line auditing, or Sysmon event ID 1.
• Network connections tied to a process, such as Sysmon event ID 3.
• File creation events, such as Sysmon event ID 11, especially for executables in temp, downloads and user profile directories.
• Proxy and firewall logs for the destination, byte counts and user agent.

A good rule shape is a sequence: a process connects to an external host, then a new executable or script lands on disk, then it runs. Each piece alone is noisy. The chain is not.

How to reduce the risk

MITRE lists two mitigations:

1. Filter network traffic. Block outbound traffic from compromised systems to unapproved external destinations. Limiting access to known, trusted IP addresses and protocols can stop an attacker from downloading tools or payloads onto a server after initial access.
2. Network intrusion prevention. Use network intrusion detection and prevention with signatures for specific malware or unusual data transfer over known protocols such as FTP. MITRE cautions that signatures are often specific to a tool and that adversaries tend to change their command and control signatures over time, so do not rely on this alone.

In practice, the strongest lever is the first: a default-deny egress policy for servers. A database host or a build agent should reach a short, named list of destinations, and everything else should fail and log.

Two further steps that follow from the description:

• Restrict who can run package managers and download utilities on production hosts, and remove tools that are not needed on a given image.
• Control which package sources servers may use. Pointing hosts at an internal mirror means a rogue download is both blocked and visible.

Check your own environment

Use this checklist:

• Can your production servers reach any external address on 80 or 443? If so, why?
• Do you log process command lines on every server class, including Linux and ESXi hosts?
• Can you tie a network connection to the process that made it?
• Are curl, wget, certutil and similar tools present on images that do not need them?
• Do servers use an internal package mirror, or the public internet?
• Do you alert on a new executable written to a temp directory shortly after an outbound connection?

Some read-only commands:

# Linux (iproute2): list established TCP connections with the owning process (needs sudo for full detail)
sudo ss -tnp state established

# Windows (PowerShell): show recent process creation events from the Security log (needs command line auditing enabled for full detail)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 20

If the Windows query returns nothing or events with no command line, process auditing is not on, which is worth fixing before anything else.

Try it yourself

Tool transfer is not only a network problem. Dependencies and packages are another route onto a build host or server. This demo shows how malicious and typosquatted packages are caught before they land. You can also run a quick check on your own dependency file with the free in-browser scan at gold.safeguard.sh/scan. It needs no login, the file never leaves your machine, and it handles up to 100 dependencies.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK, Ingress Tool Transfer (T1105)