---
{
  "title": "Lateral Tool Transfer",
  "summary": "Lateral tool transfer copies files between systems already inside an accessed environment.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1570"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1570: Lateral Tool Transfer",
      "url": "https://attack.mitre.org/techniques/T1570"
    }
  ],
  "editorialVersion": 2
}
---

## Files can move between internal systems

Lateral tool transfer copies tools or other files between systems inside an accessed environment. The transferred material may support later execution, investigation evasion, or another objective. The transfer itself is a file-movement event, not proof that the destination executed the content.

Internal file copying is routine administration and collaboration. Investigators need the source, destination, identity, artifact, method, and business purpose to distinguish authorized movement from activity supporting an intrusion.

## A program arrives before an unusual process

In a fictional company, an executable is copied from a staff workstation to a server, followed by an unfamiliar process on that server. The analyst reviews source and destination file records, remote-access events, identities, hashes where available, and process activity.

An approved deployment could explain the sequence. The team checks the release source, change record, destination scope, and responsible owner. A common administrative protocol does not establish legitimacy; an unfamiliar filename alone does not establish abuse.

The investigator links the transferred artifact to execution only when evidence supports that relationship. A matching filename is weaker than a supported path and content identity, and even a hash match should be interpreted with timing and process context.

## Distinguish movement stages

Transfer into the organization from an external source differs from transfer between internal systems. [[lateral-movement]] describes expansion of access more broadly, while [[remote-services]] may explain the authenticated route used for the copy.

A failed copy attempt should remain an attempted action in the timeline. A destination file establishes arrival, but not necessarily its origin unless the available records connect both ends. Preserve source and destination evidence before cleanup where practical.

Review the permissions that allowed the transfer and the reach of the identity used. An account capable of copying to one administrative location may have access to additional systems, but scope those searches using evidence and risk rather than assuming universal compromise.

## Remove access and artifacts thoughtfully

Contain the affected source, destination, or identity as justified. Review whether the transferred file executed or created other changes. Deleting the destination file alone may not address an active process, scheduled mechanism, or credential already used elsewhere.

Coordinate with operations because broad restrictions on deployment paths can interrupt legitimate maintenance. Define how approved transfers will continue while the suspicious path is investigated.

For practice, compare a documented software deployment with a fictional copy from an unrelated workstation to a server. Identify provenance, identity, transfer completion, and execution evidence. [[logs-and-telemetry]] supports the chain, while [[incident-reporting]] separates confirmed file arrival from suspected use and downstream impact.

## Related concepts

- [[mitre-attack]]
- [[incident-response]]
- [[ingress-tool-transfer]]
- [[web-service]]