MITRE ATT&CK T1570 Lateral Tool Transfer: Detecting Tools Copied Between Internal Hosts

Lateral Tool Transfer (T1570) is the moment an intruder copies a tool, script or payload from one internal host to another, and it is one of the last chances to stop a ransomware or wiper deployment before it runs everywhere. MITRE ATT&CK v20 describes files being copied between systems inside a compromised environment, over SMB admin shares, RDP sessions, native tools such as scp, rsync, curl, sftp and ftp, or synced cloud folders. The copy almost always comes just before remote execution, so a file write followed by execution of that file is the pattern to catch. This guide covers the transfer channels, the telemetry that shows them, the ATT&CK analytics, how to restrict file movement between hosts, and how to respond. It is for detection engineers, SOC analysts and Windows and Linux administrators. It does not repeat the credential and remote administration hardening in the Lateral Movement Guide.

Key takeaways

• T1570 is the internal copy, T1105 is the download. ATT&CK separates bringing a tool into the environment (Ingress Tool Transfer) from moving it between internal systems; the internal copy rides on trusted protocols and admin rights.
• Write then execute is the core signal. ATT&CK's Windows analytic correlates a remote file write over SMB or an admin share with process creation of the transferred binary.
• Workstations rarely need to accept files from other workstations. Microsoft recommends blocking SMB by default with Windows Defender Firewall and allowing only the servers that need it, which removes most transfer paths.
• Share auditing is precise but noisy. Event 5145 records each file accessed on a share with its access rights; scope it to admin shares and write rights so it stays usable.
• Fan-out is the emergency. The same file written to many hosts in minutes is a deployment in progress: block SMB at the host firewall and disable the account before chasing root cause.

What T1570 covers and how it relates to nearby techniques

ATT&CK v20 places T1570 under Lateral Movement on ESXi, Linux, macOS and Windows. Once a file is in the environment, adversaries copy it from system to system to stage tools over the course of an operation. The technique has no sub-techniques, and it usually sits between two others: the remote service used to reach the host, and the execution method used to run what was copied.

Transfer channels and what defenders see

ATT&CK's procedure examples show how routine this is. It records ransomware such as BlackCat, Netwalker and Qilin using PsExec to push payloads across systems, BlackByte writing its launcher to mapped shared folders, Wizard Spider copying tools into the temp directory of domain controllers with stolen credentials, Volt Typhoon copying web shells between servers, and Sandworm Team using a Group Policy Object to copy CaddyWiper during the 2022 Ukraine Electric Power Attack. The channels below cover nearly all of them.

For ESXi specifics see the ESXi Log Detection Guide.

Detection: ATT&CK's analytics and how to build them

ATT&CK v20 attaches one detection strategy, Detection Strategy for Lateral Tool Transfer across OS platforms, with four analytics:

• Windows: correlate file transfers over SMB or admin shares with process creation (for example cmd.exe, powershell.exe or certutil.exe) that does not match normal administration, and detect remote file writes followed by execution of the transferred binary. Log sources named are Security event 5140, Sysmon 11 and Sysmon 1.
• Linux: scp, rsync, curl, sftp or ftp transfers to internal systems, combined with new files in unusual directories, then execution of those files. Sources are auditd execve and file creation records.
• macOS: scp, rsync, curl or sync applications placing executables in user directories or LaunchAgents, followed by execution, from the unified log.
• ESXi: datastore uploads or scp and SSH sessions that create new VMX, VMDK or script files, correlated with VM execution or datastore changes, from vmkernel and hostd logs.

Windows audit settings that make it work

Microsoft notes that 5145 is generated every time a network share object is accessed, so volume can be high and log size and filtering need planning. In practice (our recommendation), enable 5140 widely and 5145 on servers, domain controllers and a sample of workstations, then filter at collection to admin shares and write rights.

Correlation rules worth building

1. Remote write then execute: a 5145 write or Sysmon 11 file on host B from source A, followed within 10 minutes by Sysmon 1 executing that path on host B (NHI Mgmt Group suggested window; tune it to your environment).
2. Fan-out: the same file name or hash written to more than a handful of hosts from one source in a short period. Deployment tools do this legitimately, so allowlist their service accounts and servers explicitly.
3. Workstation to workstation SMB writes: any FILE_WRITE in Zeek smb_files.log between client subnets, which should be rare.
4. Executables arriving on domain controllers: new PE files in temp or ProgramData paths on a DC, the pattern ATT&CK records for Wizard Spider.
5. Internal scp or rsync from an unusual source: transfer tools run by accounts or from hosts with no history of server-to-server copies.

Network sensors add value where endpoint coverage is thin. Zeek's SMB logs record file opens and writes with the share path and file name, and its files log identifies Windows executables crossing SMB. See the SMB Protocol Security and Signing Guide.

Prevention: restricting file movement between hosts

ATT&CK lists two mitigations for T1570: M1037 Filter Network Traffic, using the host firewall to restrict file sharing such as SMB, and M1031 Network Intrusion Prevention, using signatures for specific malware or unusual transfers over known protocols. Microsoft's guidance on securing SMB traffic gives the practical detail.

1. Inventory who needs inbound SMB: Microsoft notes that file servers and domain controllers need it, while application servers may need it only from peers on the same subnet, and clients may not need the SMB Server service at all. Use File Share auditing (5140) for a period to find real dependencies.
2. Block inbound SMB by default on endpoints: create Windows Defender Firewall rules that block SMB inbound and allow only a minimal set of servers. Microsoft points to rule templates in its support guidance on preventing lateral SMB traffic, and describes an "Allow the connection if secure" option for domain controllers and file servers backed by a Kerberos connection security rule. Test the connection security rule before broad deployment, because a wrong rule can block access to data.
3. Disable the SMB Server service where unused: after confirming nothing depends on it, set the service to disabled through Group Policy Preferences, as Microsoft describes for large rollouts.
4. Restrict SSH between servers: allow SSH only from bastion or management hosts, and remove scp and rsync trust (shared keys) between peers that have no business reason. See the SSH Key Management Guide.
5. Control what can run after a copy: application control in audit then enforce mode stops many copied tools from executing even when the transfer succeeds. See the Application Allowlisting Guide.
6. Deploy in phases: Microsoft recommends small, hand-built test deployments first, then heavy SMB users such as IT, then a broad test and QA environment, then sampled departments, then the wider estate. Keep a tested rollback, such as unlinking the policy object (our recommendation).

Choosing controls by environment

For the broader host firewall design see the Host-Based Firewall Guide.

Response when a transfer is detected

1. Decide if it is fan-out: search for the same file name or hash on other hosts. One host is an investigation; many hosts is a live deployment.
2. Stop the spread: push a host firewall rule blocking inbound SMB and remote management from the source host, isolate the source with EDR, and disable the account that performed the writes.
3. Find every copy: query Sysmon 11 and 29, 5145 and Zeek logs for the file across the estate, and check Group Policy objects and deployment tool jobs created in the same period.
4. Preserve evidence: keep a copy of the transferred file, the share audit records and process trees before cleaning. See the Malware Outbreak Playbook.
5. Reset the credentials used: the copy needed admin rights on each target, so treat the account and any service accounts on the source host as compromised.

Where identity fits

Every SMB admin share write needs administrative rights on the target, so T1570 is a credential problem as much as a file problem. Shared local administrator passwords, domain accounts with admin rights on every workstation, and service accounts used by deployment tools are what make mass copying possible. Unique local admin passwords, tiered admin accounts and tight scoping of deployment tool accounts reduce how far one stolen identity can push a file. See the Service Account Security Guide.

Metrics that show it is working

• Endpoints accepting inbound SMB: share of workstations with inbound SMB blocked by host firewall. Target close to 100%, with documented exceptions.
• Audit coverage: share of servers and domain controllers sending 5140, 5145 and Sysmon file events to the SIEM.
• Write-then-execute alerts: weekly count and share closed as approved administration; a high benign share means allowlists need work.
• Peer SSH trust: number of server pairs with key-based trust and no documented reason. Target a falling trend.
• Time to contain fan-out: minutes from first fan-out alert to SMB block on affected hosts, measured in exercises.

Framework mapping

Common failure patterns

• Open SMB between all workstations: the default flat network lets one compromised admin account write to every client.
• Allowlisting the deployment tool too broadly: ATT&CK records Medusa Group using a legitimate software deployment service to push binaries; suppress by named job owner and server, not by product.
• Auditing 5145 everywhere with no filter: the volume overwhelms the SIEM and the audit gets turned off.
• Watching downloads only: a tool copied internally from an already compromised server never touches the proxy.
• Ignoring Group Policy as a delivery channel: changes to Group Policy objects and new SYSVOL files deserve the same alerting as PsExec-style copies.

Practitioner checklist

• Map which hosts genuinely need inbound SMB using File Share auditing for a set period.
• Block inbound SMB on workstations with Windows Defender Firewall, allowing only management and file servers.
• Enable 5140 broadly and 5145 on servers and domain controllers, filtered to admin shares and write rights.
• Deploy Sysmon with FileCreate, FileExecutableDetected and process creation on servers.
• Build write-then-execute and fan-out correlation rules, with explicit allowlists for deployment tool accounts.
• Alert on changes to Group Policy objects and new executables in SYSVOL.
• Restrict SSH between servers to bastions and remove unneeded peer key trust.
• Exercise the fan-out response: firewall block, EDR isolation, account disable.

Standards and references

• MITRE ATT&CK: Lateral Tool Transfer (T1570)
• Microsoft: Secure SMB traffic in Windows Server
• Microsoft: 5145(S, F) A network share object was checked to see whether client can be granted desired access
• Microsoft: 5140(S, F) A network share object was accessed
• Microsoft Sysinternals: Sysmon
• Zeek: SMB Logs
• MITRE D3FEND: Executable Allowlisting

Related NHI Mgmt Group resources: Lateral Movement Guide · T1105 Ingress Tool Transfer Defensive Guide · Host-Based Firewall Guide · SMB Protocol Security and Signing Guide