Detecting T1105 Ingress tool transfer

How T1105 ingress tool transfer shows up in an intrusion and why SOC teams miss it

T1105 Ingress tool transfer is the step where an adversary brings additional tools or files into a environment it already controls, after initial access has been gained. MITRE ATT&CK places it under the Command and Control tactic (TA0011), which ATT&CK describes as the adversary trying to communicate with compromised systems to control them. For a SOC, the practical question is simple: when a server, hypervisor or network device suddenly receives a file it never needed, can the team tell whether that file was a patch, a backup job, or a second-stage tool. This page treats T1105 as tracked under Enterprise ATT&CK version 20.0, and any detection mapping you write should name that version explicitly, because releases can rename, deprecate or revoke techniques.

The transfer itself often looks ordinary. Attackers commonly reuse protocols and binaries already present on the host, such as built-in download utilities, package managers, or administrative file copy paths, so the signal is rarely a single malicious-looking file. On ESXi hosts, Linux servers and macOS endpoints, the evidence tends to be split across Network Connection Creation and Process Creation records, while on network devices the only visible trace may be an unexpected configuration or image pull. SOC teams miss the activity for three reasons: the transfer runs under a trusted parent process, the destination is an external content host that also serves legitimate updates, and the file lands in a path that backup or deployment tooling also writes to. Confirm which of these telemetry sources your environment actually retains, and for how long, before assuming the transfer would be visible.

The decision to make now is which hosts and device classes must produce transfer-relevant telemetry at all. Hypervisors and network devices are frequently excluded from endpoint agents, so ask your vendors and platform team whether logs of outbound fetches and file writes are available, and whether they reach your SIEM. Build an inventory of approved download sources per host class, because a file arriving from outside that list is the anomaly worth investigating. Treat any ingress transfer from a management or hypervisor segment as high priority, since a tool placed there can reach many workloads.

Which telemetry reveals ingress tool transfer on each platform

This table maps the ATT&CK data components most relevant to T1105 to the signal each one reveals, the platforms where it applies, and the open-source collector that gathers it. Read it as a starting point for coverage, not a final mapping, because the facts supplied do not list which data components ATT&CK ties to T1105 itself. Confirm each mapping in the STIX bundle for the ATT&CK version you target before you rely on it.

Data component	Signal to look for	Platforms and collector
Network Connection Creation (DC0082)	Hosts initiating outbound transfers to external or unusual destinations, or downloading from hosts that have never served files to them	Linux, macOS, Windows, ESXi and network devices. Wazuh agent or auditd on hosts, ESXi syslog forwarding for hypervisors, Zeek connection logs at the perimeter
Process Creation (DC0032)	Download or transfer utilities launched by unexpected parent processes, or from service accounts and interpreters that normally do not fetch files	Linux, macOS and Windows endpoints. Wazuh agent with command auditing, Velociraptor hunts, Sysmon-style process events where deployed
Network Traffic Flow (DC0078)	Large or unusual inbound byte volumes to internal hosts from sources outside the baseline, and transfers that bypass proxies	Network-wide, including network devices. Zeek conn and files logs, Suricata flow records, Security Onion dashboards
Network Traffic Content (DC0085)	Executable, script or archive file types in HTTP, FTP or TLS-adjacent transfers where inspection is possible, and mismatched file headers	Network-wide where traffic is visible. Zeek file extraction, Suricata file and protocol rules, Security Onion alerts. Encrypted content often limits visibility.
File Creation (DC0039)	New executable, script or archive files appearing in temporary, user or system directories shortly after an outbound connection	Linux, macOS and Windows. Wazuh file integrity monitoring, auditd file watches, Velociraptor artifacts
Command Execution (DC0064)	Execution of files that were just written to disk, or of shell commands that reference remote addresses	Linux, macOS, Windows and ESXi shell logging where enabled. Wazuh command monitoring, ESXi syslog forwarding

Detection ideas for T1105 that SOC teams can tune

T1105 Ingress tool transfer is hard to spot because the download itself often looks like normal traffic. The ideas below combine network flow, process and file telemetry so that a transfer is judged by who moved it, where it went and what landed on disk. Each one needs thresholds set from your own baseline and an allow list for known administrative tools.

Outbound transfers from non-downloading hosts

Build a baseline of which hosts normally pull executables, archives or scripts from external destinations, such as build servers or jump hosts. Alert when a server, ESXi host or network appliance that has no such history makes an outbound HTTP, HTTPS or FTP transfer of executable or script content. Start with a rolling baseline of at least several weeks of Network Connection Creation and Network Traffic Flow data. Expect false positives from patch agents, vendor update channels and monitoring tools, so allow list them by destination and process rather than by host alone.

Binaries written shortly after a download

Correlate a network download event with a File Creation event on the same host within a short window, then check whether the new file is executable, a script or an archive that is later unpacked. Tune the window to your environment, starting with a value that matches how your download clients and browsers write temporary files. Package managers, container image pulls, backup restores and configuration management runs produce the same pattern, so tag their paths and parent processes as known sources before you raise severity.

Transfers to newly seen destinations

Track destination domains, IP addresses and autonomous systems that a host or group of hosts has never contacted before, and flag first-seen contacts that also carry file content. Weight the alert by destination age, hosting type and whether the same destination appears in threat intelligence feeds you trust. Cloud storage, content delivery networks and vendor mirrors often appear as new destinations after a provider change, so review them against change records before treating them as suspicious.

Firmware and configuration pulls from unexpected sources

Network devices should retrieve firmware images and configuration files only from approved management servers, TFTP or SFTP hosts and vendor sites. Alert on any pull of these file types from a source outside that list, or from a management session that started outside a change window. Confirm with your network team which automation accounts, backup jobs and vendor support tools are expected, because scheduled configuration backups and controller-driven updates generate legitimate traffic of the same shape.

Tune with change and asset context

Feed change tickets, maintenance calendars and asset inventory into the detection pipeline so that known patch windows, backup runs and deployment jobs suppress alerts automatically. Review suppressed events each month to check that the exemptions have not grown beyond their purpose. This card supports the other detections, since a transfer alert without ownership and change context is hard for analysts to act on quickly.

How to validate that T1105 detections fire before relying on them

This sequence proves, in a private cyber range, that each T1105 detection sees a benign file transfer on every platform in scope, that the alert reaches an analyst, and that the gaps are written down before anyone relies on the rule in production.

Agree the emulation plan in writing
The security lead, the platform owners for ESXi, Linux, macOS and network devices, and the SOC manager agree the scope, the hosts and segments involved, the benign transfer method to be emulated, the time window and the rollback steps in a signed plan. Each platform owner confirms which systems are in the range and which must not be touched. The plan is done when every named system has an owner and a stop condition, and the range team has signed off on the scope.
Baseline the telemetry sources first
Before any emulation, the detection engineer confirms that Network Connection Creation, Process Creation and Network Traffic Flow records are arriving from each host and sensor in scope, with the expected fields and time stamps. Gaps in forwarding, parsing or agent coverage are logged as findings before testing starts, so a missing alert is not mistaken for a missing behavior. The step closes when a benign test connection on each platform appears in the data store with all required fields populated.
Run benign transfer emulations per platform
Under the agreed plan, the red team or range operator performs a benign, pre-approved file transfer on each platform in scope, such as a file pulled from an internal staging host that the test team placed there for this exercise. Each run is labeled with a unique identifier, start time and host so it can be matched later. The step closes when every platform has at least one logged run with its identifier and time recorded. Exact transfer methods should be chosen and documented by the range team, not improvised during the exercise.
Confirm each telemetry source recorded the transfer
The detection engineer searches each data source for the run identifiers and checks that the network connection, process and traffic flow records show the expected direction, endpoints and process context. Any run that produced no record in a source is marked as a telemetry gap, not a detection failure. The step closes when every run is accounted for against every data source it should appear in.
Verify the rule matched and the alert reached the queue
The detection engineer checks whether the Sigma or platform rule mapped to the behavior evaluated the telemetry and produced an alert, then confirms that the alert appears in the analyst queue with the expected severity, host and context. Rules that matched but did not alert, and alerts that were suppressed or routed elsewhere, are recorded separately. The step closes when each run has a documented outcome: matched and alerted, matched but not alerted, or not matched.
Record analyst decisions and timing
An analyst who was not involved in writing the rule works the alerts as they arrive, records the triage decision and the escalation path, and notes how long the alert took to appear after the run. The detection engineer compares those timings with the expected time window in the plan. The step closes when every alert has an analyst decision and a timing record, and any delay or unclear triage step is written down.
Document gaps and retest before reliance
The team compiles one record for each platform and detection that lists telemetry present, rule matched, alert fired, analyst decision and timing, along with every gap and its owner. Gaps are fixed or formally accepted with a named risk owner, and the affected checks are rerun after the fix. The mapping states the ATT&CK version it targets so future releases can be compared. The sequence is complete when the signed record is filed and the rule is approved for production use.

Preventive controls that reduce ingress tool transfer

Ingress tool transfer succeeds when a host can fetch a tool from an unexpected source over an unmonitored path. The cards below cover the preventive layers that narrow those paths, from network intrusion prevention and traffic filtering to the segmentation and web content controls that support them.

Network intrusion prevention (M1031)

MITRE maps Network Intrusion Prevention (M1031) to T1105 as a preventive control that inspects traffic for known malicious tool downloads and blocks them inline. Confirm whether your IPS or next-generation firewall can inspect the protocols your administrators use for downloads, such as HTTP, HTTPS and FTP, and whether it can act on file types and signatures rather than only on IP reputation. Test blocking mode against a known-good download workflow before enabling it across all segments, so that administrative tasks are not broken without warning.

Filter network traffic (M1037)

Filter Network Traffic (M1037) covers egress and ingress rules that limit which destinations and protocols a host may reach. For T1105, the practical goal is to stop servers and workstations from pulling binaries from arbitrary internet hosts, cloud storage buckets or file-sharing sites. Review outbound rules for file-transfer protocols and for general-purpose web access from server subnets, and document the business owner for each allowed destination. Confirm what your firewall or proxy can match on, such as domain categories, URL paths or certificate attributes.

Allow-list administrative download sources

Most legitimate tool downloads on servers come from a short list of internal repositories, package mirrors and vendor update hosts. Build that list deliberately, pin it to specific hostnames, and block direct downloads from everything else on production segments. Expect exceptions for emergency patching, and route them through a documented change process. Ask your platform team which package managers and update channels each system requires, because an incomplete list causes operational friction and pressure to remove the control.

Inspect tool downloads before execution

Where your architecture allows it, send downloads through a controlled proxy or sandbox that checks file hashes against threat intelligence, scans content and records the source URL. This turns an anonymous transfer into a logged, reviewable event. Confirm whether your scanning tools support the file types you handle, and whether inspection of encrypted downloads requires TLS interception, which carries its own trust and privacy implications under the SSL/TLS Inspection (M1020) control.

Segment server networks (M1030)

Network Segmentation (M1030) is a related control rather than a direct block for T1105. Separating management, build and production zones limits where a downloaded tool can reach and how far it can spread once staged. Confirm that your segmentation policy restricts outbound internet access from each zone, and that build servers and jump hosts are not reachable from general user networks.

Restrict web-based content (M1021)

Restrict Web-Based Content (M1021) supports T1105 by limiting access to categories of sites that commonly host attacker tooling, such as file-sharing and anonymous hosting services. Review category policies for server subnets and confirm with your proxy vendor which categories are available and how exceptions are approved. Keep the list under review, because overly broad blocks often drive staff toward unmonitored personal devices.

What a SOC does in the first hour after a T1105 alert fires

The first hour after a T1105 alert is about establishing three facts quickly: where the file came from, where it landed, and what happened to it next. Start by confirming the source and destination of the transfer from the network telemetry that raised the alert, such as Network Traffic Flow or proxy logs, and note the destination address, port and protocol. Then check the host side: was the file written to disk (File Creation), was it executed (Process Creation), or was the transfer blocked by an intrusion prevention or filtering control? Each outcome changes the severity, so record it explicitly in the case before moving on. Identify the host, the account that owned the session and the time window, and confirm whether the host is a production ESXi host, a Linux or macOS workstation, or a network device, because the containment options differ by platform.

Preserve evidence before anything is changed. Collect the file hash, the file path, the parent process and the relevant network sessions, and capture a live triage package with Velociraptor or, where it is already deployed, a Wazuh active response script. Document who triggered each collection, the exact time and the tool version, since the chain of custody will be questioned later. Then scope the incident: search the same destination address, domain and file hash across other hosts and sensors to find every system that contacted the destination or received the same artifact. Treat any host that also reached the destination as a candidate for the same activity until it is cleared. Finally, decide on containment. Typical options are blocking the destination at the perimeter, isolating the host at the network layer, or disabling the account, and each carries an availability cost that the system owner should accept in writing. Confirm in your own environment which of these actions your change process allows outside business hours and who has authority to approve them. Record the decision, the reason and the owner, so the hour's work can be reviewed afterward.

How to rehearse T1105 detection and response in a private cyber range

The range for this tab mirrors a small virtualization cluster: two or three ESXi hosts managed by a vCenter-style management plane, a segregated management network, a datastore for guest images, and a logging path that forwards host and management events to a Wazuh manager or Security Onion sensor. Hosts should be isolated from production and from the internet except through a controlled egress path that the exercise team can observe and cut.

Injects to plan:

Benign transfer: an approved administrator copies a patch bundle onto a management host through the standard channel, so the team confirms the detection does not fire on sanctioned maintenance.
Unexpected destination: a scripted transfer pulls a file from an address that is not on the approved list, to test whether the destination is flagged.
File write after download: a file lands in a datastore or host directory that no change ticket covers, to test whether file creation telemetry links it to the transfer.

Good detection means the transfer appears in host or network telemetry within the time the team agreed in advance, with the source, destination and process context attached. Good response means the on-call engineer isolates the affected host from the management network, preserves the file and logs, and confirms the change record before any recovery step.

Check that the exercise scope names every host and datastore in the range and that rollback is tested before the exercise begins.

Questions SOC leads and detection engineers ask about T1105

How do you separate legitimate package downloads from ingress tool transfer?

Start by baselining which hosts, service accounts and processes normally fetch software, and treat deviations from that baseline as the signal, not the download itself. Package managers, update agents and configuration tools usually pull from a short list of known repositories on predictable schedules. A download that originates from a server that never installs software, uses an unusual user context, or writes an executable into a temporary or user-writable directory deserves review. Combine network connection creation with file creation and process creation so you can see the full chain: what connected, what was written, and what ran afterward. Confirm the exact logging fields your platform provides before writing correlation rules, because coverage differs by operating system and by network device.

Do we need TLS inspection to see what is being transferred?

Not always. Connection metadata such as destination, port, timing, byte counts and the initiating process often reveals a transfer without decrypting it. TLS inspection, mapped to the ATT&CK mitigation SSL/TLS Inspection (M1020), gives you the content and file hashes, but it adds certificate management, privacy review and performance load, and it can break certificate pinning in some applications. Decide based on your risk tolerance and legal constraints. Many teams start with metadata-based detection and file hash checks at endpoints, then add inspection for specific high-risk segments. Ask your network team to confirm which traffic their sensors can decrypt before you promise coverage in a detection design.

How should we handle encrypted downloads on ESXi?

ESXi hosts usually have a narrow, known set of outbound destinations, so the practical approach is to define an allow list for management traffic and alert on anything outside it. Because encrypted transfers hide content, focus on the destination, the initiating service, and the time and volume of outbound connections from the hypervisor. Any unexpected file retrieval from a management host is significant. Confirm with your virtualization vendor which services legitimately make outbound calls on your version, and test that list in a lab before production. Restrict access to the management network through segmentation so hypervisors cannot reach arbitrary internet hosts in the first place.

How often should we re-map detections when ATT&CK releases a new version?

Re-map on each release you adopt, and record the ATT&CK version in every detection mapping so you know what it targets. MITRE publishes updates in versions such as v18 (October 28, 2025), v19 (April 28, 2026) and v20 (October 13, 2026), and releases can rename, deprecate or revoke techniques and change detection strategies and data components. Review the release notes for T1105 and related Command and Control techniques, then check your rule repository against the STIX bundle for the version you target. Assign an owner and a review cycle so mappings do not drift silently. Confirm the cadence your team can sustain before committing to it.

What should we tune first when a T1105 rule floods the queue?

Tune in order of noise and business impact. First, build an allow list of known update sources and package repositories per asset group, keyed to specific processes and service accounts rather than broad IP ranges. Second, exclude paths and tools that your configuration management legitimately uses, and document each exclusion with an owner and a review date. Third, raise severity when a download is followed by execution of a newly written file from a non-standard directory, since that chain matters more than the download alone. Validate every change in your cyber range by replaying benign and malicious samples, so you can show that a tuning change did not remove coverage.

Can our own team run this detection program without outside help?

Often yes, if you already run a SIEM and EDR and have engineers who can write and test detection rules. The work divides into data onboarding, rule engineering, validation, tuning and response playbooks. Teams usually need outside help when they lack network or hypervisor telemetry, when sensors cannot cover encrypted traffic, or when they have no safe environment to test attacks. A fixed-scope engagement can define which parts you will build and which you will run yourself, and it can include validation in a private cyber range. Ask any provider to put the scope, deliverables and handover in writing before work starts.

How do we prove the T1105 detection actually works?

Validate it with repeatable tests in a controlled environment, then record the results. Define the expected telemetry for each platform, run agreed test scenarios in a private cyber range that mirrors your production logging, and confirm that the expected alerts fire with the right fields and severity. Track false positives and missed events, and rerun the tests after each rule change or ATT&CK update. Keep the test plans, results and rule versions together so an auditor or internal reviewer can trace detection coverage to the control objective. Ask your validation partner to define pass criteria before testing begins.

Where to confirm T1105 mappings and ATT&CK version changes

Before you build or accept any detection for T1105 Ingress tool transfer, confirm which ATT&CK version your mappings target and check the technique against that version. Start with the MITRE ATT&CK tactic page for Command and Control, which defines TA0011 and lists the techniques that roll up under it. Use that page to confirm that T1105 still sits under Command and Control and that its description still matches the behavior your detections target. Record the version you checked alongside the date, so your detection register can be reviewed later against a known baseline.

Next, read the MITRE ATT&CK updates page for every release between the version you last validated and the one you are targeting. Releases can rename, deprecate or revoke techniques and sub-techniques, and in ATT&CK v18 MITRE replaced technique-level detections with detection strategies and analytics and changed data components. Check whether the data components your T1105 analytics depend on, such as Network Connection Creation, Process Creation and Network Traffic Flow, were renamed or revised. For the authoritative mapping, load the enterprise-attack STIX bundle for your chosen version from the mitre-attack/attack-stix-data repository and query the T1105 object and its relationships directly rather than relying on summaries, including any mitigations linked to it.

Ask your implementation partner and your own detection engineers to attach the version identifier, the STIX bundle hash or file name, and the review date to every T1105 rule in your repository, and to re-run this check at each ATT&CK release. Where a mapping changes, decide whether the existing rules still cover the behavior, whether the Network Intrusion Prevention and Filter Network Traffic mitigation records need updating, and whether the cyber range scenarios need to be rerun. Confirm the release cadence and your change process in writing before the engagement starts.

How DeployOpen builds T1105 detections, purple team exercises and range scenarios

DeployOpen works on T1105 Ingress tool transfer as a fixed-scope engagement inside your own infrastructure, with the scope agreed in writing before any work starts. We build detections against the ATT&CK version you name, test them in a private cyber range, and hand over the rules, runbooks and evidence your team can operate without us.

How we scope

Confirm which platforms are in scope for T1105, such as ESXi, Linux, macOS and network devices, and which are excluded.
Agree the telemetry sources in writing, including Network Connection Creation, Process Creation and Network Traffic Flow.
Record the ATT&CK version the detections target, since releases can rename or deprecate techniques.

How we build

Map T1105 detection strategies to available data components and identify logging gaps before writing rules.
Build open-source detection content in Wazuh, Security Onion, Suricata, Zeek or Sigma formats, as the written scope specifies.
Document the mitigation coverage for Network Intrusion Prevention and Filter Network Traffic against your current controls.

How we hand over

Deliver detection rules with plain-language logic, known false positive sources and tuning notes for your analysts.
Provide cyber range test results showing which simulated transfer scenarios fired, missed or needed tuning.
Hand over response runbooks and evidence packs that your compliance team can review with its independent auditor.

How we support

Ongoing support, rule updates and continuous testing for T1105 are available as a retainer, scoped separately.
Re-test detections when ATT&CK releases change the technique or its mapped data components.
Ask any provider to confirm in writing which tasks are one-time deliverables and which recur under a retainer.

T1105 Ingress tool transfer