How lateral tool transfer shows up after an attacker gets inside
Once an adversary has a foothold, moving tools between hosts is one of the ways it extends its reach. MITRE ATT&CK places this behavior under the Lateral Movement tactic (TA0008), which ATT&CK describes as the adversary trying to move through your environment. T1570 Lateral tool transfer covers the case where the adversary brings a utility, script or payload from one system onto another system it has reached, so the next stage of the intrusion can run there. For a SOC lead, the practical question is not whether a foothold exists but whether the team can see a file arriving on a host it had no business receiving it from, and whether that event is tied to a session, an account and a time window that can be investigated. In intrusions, this technique usually appears between other lateral movement steps. An adversary that has already used a valid account or a remote service to reach a second host often needs a tool that is not present there. The same pattern can repeat across Linux servers, Windows endpoints, macOS workstations and ESXi hosts, which is why the detection plan should cover each platform in the estate rather than only the one the team watches most closely. The defender's job is to decide which hosts should never accept inbound executable or script content from other internal systems, which administrative paths are expected to move files, and which events prove that a transfer happened. The page targets Enterprise ATT&CK version 20.0. Technique IDs, sub-technique structure, data component references and mitigation mappings can change in later releases, and ATT&CK has already published newer versions. Before you build or accept a detection, confirm the current technique page and its mappings in the MITRE ATT&CK tactic page for Lateral Movement and in the ATT&CK updates page, and record which version your detection content targets so later reviews can see what changed.
Which telemetry reveals lateral tool transfer and which open-source collector provides it
This table maps the four data components most relevant to T1570 (Process Creation, Command Execution, File Creation and Network Traffic Content) to the signal each gives on ESXi, Linux, macOS and Windows, and to the open-source collector that gathers it. Read each row as a question to answer in your own environment: which platforms can you actually see, and where are the logging gaps? The main takeaway is that no single source covers every platform, so coverage gaps on ESXi and network paths need explicit confirmation before you rely on a detection.
| Data component | Signal for lateral tool transfer | Open-source collector or sensor | Platform gaps to confirm |
|---|---|---|---|
| Process Creation (DC0032) | Execution of file transfer or copy utilities shortly after a remote session starts, especially with a binary that was not previously present on the host | Wazuh agent on Linux, macOS and Windows; Velociraptor for on-demand process history | Confirm audit policy or process auditing is enabled on each Windows and Linux image; confirm macOS logging scope in your fleet |
| Command Execution (DC0064) | Shell or interpreter command lines that move files between hosts, including use of standard copy, fetch or encoded transfer patterns | Wazuh agent with command log collection; Velociraptor artifacts for shell history and command capture | Shell history is often incomplete or disabled; confirm PowerShell script block logging on Windows and equivalent shell auditing on Linux and macOS |
| File Creation (DC0039) | New executable, script or archive appearing in a user-writable or staging directory on a host that did not previously hold it, followed by execution | Wazuh file integrity monitoring; Velociraptor file hunts and collection | File integrity monitoring must be scoped to staging paths; confirm coverage of temporary and user profile directories on each platform |
| Network Traffic Content (DC0085) | Transfers of executable or archive content between internal hosts over protocols that do not normally carry binaries, or unexpected file-type signatures in transit | Zeek for protocol and file extraction; Suricata rules for content matching on monitored segments | Encrypted sessions hide content; east-west visibility depends on sensor placement; confirm whether ESXi management traffic is mirrored to any sensor |
| ESXi hosts | Limited native signal: review of management interface access, shell enablement and file activity on datastores as seen through host and vCenter logs | Wazuh or syslog forwarding from ESXi hosts, with Zeek or Suricata on the management network where traffic is mirrored | ESXi logging depth and forwarding options vary by version and configuration; confirm with the VMware or Broadcom documentation for your release what is logged and what must be enabled |
Detection ideas for T1570 that SOC teams can tune
T1570 Lateral tool transfer shows up as a small set of observable events: executable or script content appearing on a host, a process running from that new file, and binary content moving between internal hosts. The cards below describe each signal in words, with the thresholds to tune, the baseline to build and the benign activity that will trigger it first.
Executable content on unexpected hosts
Alert when file creation events show executable, script or archive content written to hosts that never receive software from your deployment channels. Start by building a baseline of which hosts normally receive packages, scripts and installers, grouped by role such as workstation, domain controller, database or ESXi management host. The main false positives are software deployment tools, patching agents and configuration management runs. Exclude their known service accounts and install paths, and record the exclusions so reviewers can see what was tuned and why.
Execution tied to new file arrival
Correlate a process creation event with a file creation event on the same host within a short window, where the new file is the image or script being run. The logic is useful because an adversary who stages a tool on a host then runs it, while a patch or backup job usually runs an installed binary. Tune the window and limit the alert to hosts outside the approved baseline. Expect false positives from installers that unpack and run in one step, so review parent process and signing status before escalation.
Binary transfer between internal hosts
Look for network connection events between internal workstations or servers that carry binary content, such as portable executable headers or compressed archives, over protocols that normally carry only management or application traffic. Network Traffic Content depends on decryption, inspection coverage and protocol parsing, so confirm your sensors can see the content on each internal segment before relying on this logic. Set a byte-volume threshold per host pair and exclude backup replication, software distribution servers and vulnerability scanners.
Repeated transfers from one source host
Track how many distinct internal destinations receive new executable content from a single source within a set time frame. A lateral movement pattern often fans out from one host to several peers, while deployment tools usually follow a published schedule and a named server. Set the destination count threshold from your own baseline, not from a vendor default. Watch for false positives from imaging systems, endpoint management consoles and any new application rollout, and link alerts to change records where possible.
Sigma rules as portable logic
Express the logic above as Sigma rules so the same detection can move between SIEM platforms, including Wazuh and other tools in your stack. Keep each rule tied to a named ATT&CK version in its metadata so it can be reviewed when techniques are renamed or revoked in later releases. Store rules in version control, document the baseline and exclusions beside each rule, and test every change against recorded benign activity before deployment.
How to validate that a T1570 detection fires
This sequence proves, in a private lab or cyber range, that the T1570 Lateral Tool Transfer detections collect the right telemetry, raise the expected alert, and leave a record that another analyst can audit. It produces a validation record tied to a named ATT&CK version.
Scope the test and approve the plan
The detection owner, the SOC lead and the range operator agree in writing on the hosts in scope, the operating systems covered (ESXi, Linux, macOS and Windows), the test window and the emulation plan. The plan describes the behavior to be simulated in words only and names the ATT&CK version targeted, such as Enterprise ATT&CK 20.0, so that later readers know which technique definitions the test checked against. Nothing runs until the plan is signed off and the range is confirmed as isolated from production networks.
Confirm baseline telemetry on each host
Before any activity, the operator checks that the telemetry sources expected for T1570 are present and healthy on every in-scope host. For this technique that means Process Creation, Command Execution and File Creation events from endpoint logging, and the agent or collector status in the SIEM. The output is a per-host checklist showing which sources reported in the last hour, with any gaps recorded as known limitations before the test starts.
Verify telemetry arrives in the SIEM
Using a benign, pre-approved activity that produces the same event categories, the operator confirms that events reach the SIEM with the expected fields populated, such as host name, user, process or file path, and timestamps. Ingestion delay is measured and noted. If events arrive late, unparsed or with missing fields, the test stops and the gap is fixed or documented, because an alert cannot fire on data the platform never received.
Trigger the emulated transfer behavior
The range operator runs the approved emulation step that mirrors the T1570 pattern described in the plan, on the agreed hosts, and logs the exact time window and host list. The operator does not share technique-level instructions beyond the plan. The step is complete when the operator records that each planned action ran, along with any action that failed or did not execute as designed.
Check the alert and its fields
The analyst reviews the alert or correlation rule that should fire and compares it with the expected outcome. The check covers whether the alert triggered, which hosts and accounts it names, whether it maps to T1570 and the targeted ATT&CK version in its metadata, and whether the fields needed for triage are present. The result is recorded as fired, fired with missing fields, or not fired, with a screenshot or saved query reference.
Record timestamps, host coverage and missed events
The validation record lists the time of the emulated action, the time each event was ingested, the time the alert fired, and the resulting detection latency. It also lists which in-scope hosts produced alerts, which did not, and every event expected but absent. Missed events are classified by cause, such as log source gap, parsing failure, rule logic or threshold, so the owner knows where to act.
Rerun after tuning and retain the evidence
After rule tuning or telemetry fixes, the same scoped test is rerun and compared with the first record. The record names the ATT&CK version again, notes any version change since the last test, and is stored with the rule version and change ticket. The sequence is complete when the rerun shows the expected alerts on all in-scope hosts, or when remaining gaps are accepted in writing by the risk owner.
Mitigations that limit where tools can travel
Lateral tool transfer succeeds when a tool can cross from one host to another without meeting a control. The cards below cover the two ATT&CK mitigations aimed at that path, then two related mitigations that shrink how far a transferred tool can reach. Confirm each capability against your own network and sensor stack before relying on it.
Filter network traffic
Filter Network Traffic asks whether east-west file movement is allowed at all. Host-to-host protocols used to copy files, such as SMB, administrative shares, and remote copy services, should be allowed only between systems with a documented business need. The network layer needs host-based or network firewall rules that are default-deny for workstation-to-workstation and workstation-to-server file transfer. Check that rules are logged, that exceptions have owners, and that the firewall logs reach your SIEM so blocked attempts are visible, not only allowed ones.
Network intrusion prevention
A network intrusion prevention sensor inspects traffic between segments and can block known transfer patterns, such as suspicious file payloads moving over internal file-sharing protocols. Open-source options include Suricata in inline mode. This requires the sensor to sit where east-west traffic is visible, which often means mirroring or inline placement on segment boundaries, not only at the internet edge. Confirm which protocols the sensor can decode, how it handles encrypted sessions, and whether blocking is tuned to avoid disrupting backup and patching traffic.
Network segmentation
Network Segmentation (M1030) limits how far a transferred tool can travel even when it lands on one host. Place user endpoints, administrative workstations, and production servers in separate zones with explicit rules between them. Administrative paths should pass through a controlled jump point. Ask your architecture team to document which zones may exchange files and to test that a workstation in one zone cannot reach file shares in another. Segmentation changes need change control, because drift is a common reason flat paths reappear.
Audit and file visibility
Audit (M1047) makes transfers reviewable after the fact. Enable operating system auditing for network share access and file creation on servers that hold tools or sensitive data, and forward those events to your central log platform. Without this telemetry, the filter and intrusion prevention controls above can only report what they blocked, not what slipped through. Confirm retention is long enough for your investigation cycle, and test that a copied file produces a traceable event on both the source and destination host.
Triage and response when a T1570 alert fires
The first decision on a T1570 alert is whether the transferred file is real and whether it reached a host where it could run. Start by confirming the file itself: its name, path, size, hash and the process that wrote it. Then identify the source and destination hosts from the telemetry that raised the alert, whether that is Process Creation, Command Execution or File Creation on the endpoint, or network content on the path between them. Next, pull the surrounding context. Look at the parent and child processes around the file write, and at the logon sessions active on both hosts at that time, including which account initiated the activity and whether it is expected for that account and system. A transfer from a build server or a known administration jump host may be benign, while the same transfer from a workstation with no change record is not. Record each answer in the case notes as you go, because the isolation decision depends on them.
Decide on isolation early, and base the decision on what the destination host can still do rather than on alert severity alone. Isolate the destination host when the file is confirmed, executable or script content, and there is evidence it was run or is set to run at startup. Keep the source host under observation unless its logon or process context shows it is the origin of the activity, in which case treat it the same way. Before isolating anything, confirm with your incident response runbook how isolation is performed in your environment and whether it preserves the endpoint's ability to report to your monitoring stack. Preserve volatile and file evidence before you remove or reimage anything. Use your existing forensic collection tooling, such as Velociraptor where it is deployed, to capture the file, the relevant process listing, network connections and logon records, and keep hashes and collection timestamps with each artifact.
Scope the incident by searching for the same file hash, file name and destination path across other endpoints, and by searching the same network source and destination pairs over the same time window. Every host that received identical content is a candidate for the same response. Once scope is known, feed confirmed indicators back into detection content: add the confirmed hashes and file patterns to your file-based rules, tune Sigma or Wazuh rules where the alert was noisy or missed the transfer, and record which benign administration paths generated false positives so they can be documented as approved exceptions. Each change should name the ATT&CK version it targets, since technique mappings can change between releases. Finally, record the lessons in a short post-incident review and rehearse the same path in your private cyber range, so the team has practiced triage on realistic but controlled artifacts before the next alert.
Rehearsing T1570 detection and response in a private cyber range
A private cyber range for T1570 should mirror the operating systems your organization actually runs, so that the telemetry you rehearse against is the telemetry you will see in production. Include Linux, Windows, macOS and ESXi hosts, each forwarding logs to the same SIEM or Wazuh deployment used in production, with file creation, process creation and command execution sources enabled at the levels you intend to rely on. Keep the range isolated from production networks and from the internet, and document every host image, agent version and logging configuration so the exercise can be repeated against the same baseline.
- Representative hosts: Include at least one host per platform family in scope, plus a jump or administration host that staff use for routine file distribution.
- Logging parity: Confirm each host sends the same data components the production estate sends, including ESXi and macOS sources that are often under-collected.
- Network paths: Recreate the segments that separate administrative, server and user traffic so that network-level transfer signals can be tested.
- Baseline capture: Record a clean baseline of normal file movement before any injects run, so analysts have a reference for what routine looks like.
- Version pinning: Name the ATT&CK version (for example, the Enterprise ATT&CK release your mapping targets) and the detection rule versions used.
Before the first exercise, confirm with your platform team that the range telemetry matches production configuration, because an exercise run on a range that logs more than production proves less than it appears to.
Injects are scripted events that the exercise control team triggers on the range. For T1570, the injects should simulate file movement between hosts that looks like approved administrative work, along with variants that differ in source, destination, file type and timing. Describe each inject in a written runbook that states the intended actor, the source and destination hosts, the expected telemetry and the expected analyst action. Keep the actual operational steps in the controlled range runbook rather than in shared training notes, and have exercise control record the time each inject fires so that analyst timelines can be compared against it.
- Routine distribution: An administrator copies an approved software package from a management host to several servers during a scheduled change window.
- Off-hours movement: The same kind of transfer occurs outside the change window, from a host that does not normally distribute files, to test time-based and context-based review.
- Unusual file type: A transfer of a script or archive to a host that does not normally receive that file type, to test content-aware rules.
- Cross-platform hop: A file moves from a Linux host to a macOS or ESXi host, to test coverage on the platforms most often missed.
- Quiet variant: A transfer that is brief and well-timed, so analysts must rely on correlation rather than volume.
Run each inject with a known expected outcome, and mark which ones should alert, which should be correlated only, and which should be filtered as approved, so that the results can be scored later.
Good detection and response for T1570 is judged by what analysts do after an alert fires, not only by whether it fires. SOC analysts should identify the source host, destination host, file and actor, check whether the transfer matches an approved change, and decide whether to escalate, contain or close. Incident leads should confirm that the escalation path works at the hours the exercise runs, that containment decisions are recorded, and that communication to system owners happens within the time set in the organization's own procedures. Confirm your target times with your own incident response plan, since no industry timing is supplied here.
- Triage accuracy: Analysts correctly classify each inject as approved, suspicious or undetermined, with a written reason.
- Scope identification: Analysts identify all hosts that received the file, not only the first one that alerted.
- Evidence preservation: Analysts capture the file hash, the transfer record and the relevant host telemetry before any cleanup.
- Containment decision: The incident lead decides, with a recorded rationale, whether to isolate hosts, block the path or monitor.
- Handoff quality: Notes are complete enough that a second shift could continue the investigation without re-asking questions.
Ask the exercise control team to score each of these points against the expected outcome, so that strong analysts are recognized and weak steps are visible.
Success criteria should be written before the exercise, so that the debrief measures the same things the injects tested. Useful criteria include whether each inject produced the expected telemetry, whether the detection fired at the intended severity, whether analysts reached the correct disposition, and whether the response met the time targets in your own procedures. The debrief record should capture the inject timeline, the alerts generated, the analyst actions, the gaps found and the owner and due date for each gap. Store the record in the same system as your other control evidence so that it can be reviewed by internal audit or an independent auditor, who determine whether it meets their needs.
- Pass or fail per inject: Each inject has a recorded outcome against its written expectation.
- Coverage gaps: Platforms or transfer types that produced no telemetry are listed separately from detection logic failures.
- False positive review: Approved injects that alerted are recorded with the rule that fired and the tuning option considered.
- Action owners: Every gap has a named owner and a date agreed in the debrief.
- Repeat plan: The exercise is scheduled to run again after changes, so that fixes are verified rather than assumed.
At the close of the debrief, confirm that the record is complete and that every open gap has an owner, because unassigned findings are the most common reason a rehearsal does not change production.
Findings from a cyber range rehearsal should feed back into three places: detection rules, data collection and response procedures. Detection rules that fired on approved injects need narrowing, typically by adding context such as the approved change identifier, the source host group or the time window, while rules that missed an inject need broader logic or additional data sources. Collection gaps, such as an ESXi or macOS source that did not forward file events, should go to the platform team with the exact configuration that was missing. Response gaps should update the runbook used in the next exercise. Keep each tuning change linked to the exercise that justified it, and record the ATT&CK version and rule version so that later reviews can trace the change.
- Rule changes: Each change to a Sigma or SIEM rule is version-controlled and tested against the same inject set.
- Allow-list discipline: Approved transfers are filtered using documented change records, not broad exceptions on hosts or users.
- Collection fixes: Missing telemetry is restored in production and verified with a repeat inject.
- Runbook updates: Response steps that were unclear are rewritten and rehearsed again.
- Regression testing: Previously passing injects are rerun after each change to catch side effects.
Before closing the loop, confirm that the next exercise uses the updated rules and runbooks, because a tuning change that is not tested again has not yet been shown to work.
Questions SOC leads and detection engineers ask about T1570
How does T1570 lateral tool transfer differ from T1021 remote services in detection?
T1570 is about the file moving between systems, while T1021 is about the remote session used to reach a system. Detection for T1021 leans on logon and network connection telemetry, whereas T1570 leans on File Creation, Process Creation and Command Execution on the receiving host, plus network content where a sensor can see it. The two often appear together in one intrusion, so correlate them: a remote logon followed shortly by a new executable in a user-writable or administrative share is a stronger signal than either event alone. Confirm which of these data components your endpoint agent and sensors actually collect before writing the rule, because the ATT&CK mapping only helps if the telemetry exists in your environment.
Is ESXi file telemetry reliable enough to alert on for T1570?
It can support alerting, but only for the file and command events your ESXi logging actually emits, and that set is narrower than on Linux or Windows. Confirm with your hypervisor vendor and your own build which events reach your SIEM, how they are timestamped, and whether datastore file operations are logged at all. Where coverage is partial, pair host-side events with management plane audit logs and network sensor data, and treat a single missing event as a coverage gap to document rather than a clean result. Validate the rule in a cyber range built to match your ESXi version before relying on it in production.
How do we avoid false positives from configuration management tools?
Configuration management, patching and backup agents copy binaries and scripts across hosts as a normal function, so a raw file-copy rule will be noisy. Start by inventorying which tools, service accounts and source hosts legitimately transfer files, then build exclusions around the combination of account, source host, destination path and parent process rather than around the tool name alone. Exclusions should be reviewed on a schedule and tied to change records so that a compromised management server does not become a silent allow-list. Keep a separate, higher-severity rule for transfers that fall outside those approved paths.
How often should we re-map detections when ATT&CK releases change?
Re-check mappings at every ATT&CK release you adopt, because releases can rename, deprecate or revoke techniques and change how detections are described. Recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Record the ATT&CK version each detection targets, diff the Enterprise STIX bundle for your domains against your rule inventory, and confirm the data component references still match what your sensors collect. Many teams tie this review to an existing change cycle rather than running it ad hoc, and they document the version in every rule's metadata.
What should we confirm about network sensor coverage for T1570?
Confirm where your sensors see east-west traffic, not only north-south traffic, because lateral tool transfer happens inside the network. Check which segments are mirrored or tapped, whether encrypted sessions such as SMB are visible to your sensor or only their metadata, and whether your Suricata or Zeek deployment logs file transfer activity in a form your detections can query. The ATT&CK mitigations Filter Network Traffic and Network Intrusion Prevention depend on the same visibility, so document which segments are covered and which are blind spots, and accept those gaps explicitly in your risk register.
Can our own team build and test T1570 detections without outside help?
Often yes, if you already run a SIEM, endpoint telemetry and a lab that resembles production. The work splits into rule authoring, telemetry validation, exclusion management, and rehearsal in a range that can generate benign and suspicious file movement safely. Teams that lack a range or spare engineering time often bring in an implementation partner for a fixed scope, such as building the rules and the range exercise together. Ask any partner to state in writing which platforms, log sources and ATT&CK version the work covers, and who owns the rules after handover.
What evidence should we keep to show T1570 detection works?
Keep the rule definition with its ATT&CK version, the log sources it depends on, the test cases run in the cyber range, and the results of each run including misses. Record exclusions with owner, reason and review date, and keep alert handling notes that show how analysts triaged a sample. Auditors and internal assessors generally want to see that controls were tested and that gaps were tracked, not a claim that detection is complete. DeployOpen can prepare this kind of evidence within a written scope, but independent auditors and certification bodies make the assessment decision.
How DeployOpen builds T1570 detections and range exercises
DeployOpen works on T1570 Lateral tool transfer as a fixed-scope engagement inside the client's own infrastructure. The work covers detection content for the telemetry the client already collects, tested in a private cyber range before it reaches production.
How we scope
- Written scope names the platforms in play, such as ESXi, Linux, macOS and Windows, before any work starts.
- Scope lists which telemetry sources the client collects today, including process, command and file creation logs.
- Scope states the ATT&CK version targeted, so detection mappings stay tied to a named release.
How we build
- Detection logic is written for the client's chosen stack, such as Wazuh, Security Onion, Suricata or Zeek.
- Sigma-format rules are drafted for the agreed platforms and reviewed against the client's log schema.
- Mapping to the mitigations Filter Network Traffic and Network Intrusion Prevention is documented per rule.
How we hand over
- Cyber range test results show which T1570 detections fired, which were missed and why.
- Runbooks describe triage steps, evidence to collect and escalation paths for analysts on shift.
- Documentation records coverage gaps and the data each rule depends on, so the client can confirm them internally.
How we support
- Ongoing support is available as a retainer for tuning rules after the client's environment changes.
- Retesting can follow ATT&CK version updates, since releases can rename or deprecate techniques.
- Clients should confirm retainer terms and retest frequency in the written quote before committing.
