MITRE ATT&CK T1080 Taint Shared Content: Detecting and Containing Lateral Movement

Taint Shared Content (T1080) turns the places people and pipelines trust most, file shares, cloud folders and internal code repositories, into a delivery mechanism that spreads an intrusion every time someone opens a file. MITRE ATT&CK v20 places T1080 in the Lateral Movement tactic on Windows, Linux, macOS, SaaS and Office Suite. Instead of connecting to each target, the adversary changes shared content and waits for users or automated jobs to run it, which makes the activity look like normal work. This page covers the variants ATT&CK describes, the analytics and log sources ATT&CK v20 attaches to them, the mitigations that matter, how to contain an outbreak, and why write access held by service accounts and CI tokens is the main exposure. It is written for detection engineers, incident responders and platform owners. For lateral movement as a whole see the Lateral Movement Guide; for one group that relies on this technique see the Gamaredon Group Threat Actor Profile Guide.

Key takeaways

• Write access is the precondition. ATT&CK's first mitigation for T1080 is M1022: minimise who can write to shared folders. Every writer is a potential spreader.
• Three variants need different detections. Adding malicious files beside real ones, directory share pivots built from LNK shortcuts and hidden folders, and binary infection that modifies healthy executables on the share.
• The technique has moved to SaaS and code. ATT&CK v20 covers cloud-shared folders and Office documents, and its description names internal code repositories as shared locations.
• The ATT&CK v20 detection strategy chains a write with a later execution. A file drop on a share followed by execution or unusual network activity from a host that opened it is the core pattern.
• Non-human identities are frequent writers. Sync services, backup agents, deployment accounts and CI tokens often hold broad write rights, so a stolen token can taint thousands of locations quickly.

How the technique works

ATT&CK describes T1080 as delivering payloads to remote systems by adding content to shared storage locations, such as network drives or internal code repositories, or by adding malicious programs, scripts or exploit code to otherwise valid files. When a user opens the tainted content, the adversary's code runs on that user's system. ATT&CK describes three forms:

ATT&CK notes that when a directory share pivot is placed on frequently used network directories it can cause repeated reinfection and broad access, including to new and higher-privileged accounts. ATT&CK v20 links T1080 to five groups and seven software entries. Examples it gives include Gamaredon Group injecting macros into Word and Excel documents on mapped network drives, BRONZE BUTLER placing malware on file shares under the names of legitimate documents, and Conti spreading through network shared drives.

The same pattern applies to code. The Megalodon GitHub Actions attack in May 2026 used compromised tokens or deploy keys to push malicious workflow changes straight to default branches of thousands of repositories, so that every CI run harvested secrets. Shared repositories without required reviews acted exactly like a writable file share.

Log sources and analytics

ATT&CK v20 attaches one detection strategy, Detection of Tainted Content Written to Shared Storage, with five platform analytics. The table lists them with the log sources ATT&CK names, plus what to correlate.

High-signal rules to build first

• Executable types in document shares: new .exe, .scr, .js, .vbs, .hta or .lnk files in shares that normally hold only office documents.
• Bulk change by one writer: one account creating or modifying many files across many directories in a short window, especially a service or sync account outside its normal schedule.
• Hidden directory plus LNK burst: directory attributes set to hidden in the same window as matching .lnk files are created.
• Binary hash drift: existing installers or tools on software shares whose hash changes without a change ticket.
• Workflow file changes on default branches: pushes that modify CI workflow files without a reviewed pull request.

For share auditing setup see the Unstructured Data and File Share Security Guide.

Mitigations

Two further controls follow directly from the technique. Block or restrict Office macros in documents from shared and external locations, see the Office Macro Blocking Guide. Protect default branches with required reviews and code owners for workflow files, see the Git Repository Security Guide.

Where identity fits

T1080 is lateral movement without logging in anywhere new, so the identity that matters is whoever can write. In most estates that list is dominated by non-human identities: file sync and migration service accounts, backup agents with write-back rights, software distribution accounts, and CI tokens or deploy keys with push access to many repositories. Treat write access to widely read content as privileged. Give each such identity a scope limited to the paths or repositories it needs, prefer short-lived tokens over long-lived personal access tokens and deploy keys, and alert when a service identity writes outside its usual paths. See the CI/CD Pipeline Identity Security Guide.

Implementation roadmap

1. Map widely read locations: department shares, software and scripts shares, SharePoint and Drive libraries with broad audiences, and repositories that feed CI.
2. List every writer: human and non-human, with last write date. Remove write rights not used in 90 days (an NHI Mgmt Group suggested threshold; adjust to your change cycle).
3. Turn on auditing: Security 5145 and Sysmon 11 on file servers (scope 5145 to sensitive shares to manage volume), Microsoft 365 or Workspace file audit logs, and repository push audit logs.
4. Pilot rules in alert-only mode for two weeks per share class, tune out deployment and sync jobs by identity and schedule, then raise severity.
5. Add prevention in rings: block execution from network paths on a pilot group of workstations first, keep an exception process for legitimate software shares, and roll back by removing the policy from the ring if business applications break.
6. Exercise containment: run a tabletop where a shared folder is tainted and practise making it read-only within minutes.

Small and large organisations

• Small organisations: most shared content now lives in SaaS storage; focus on sharing settings, macro blocking and cloud storage malware scanning.
• Large organisations: on-premises shares, NAS devices and many repositories coexist; prioritise software and script shares and CI-feeding repositories, because one tainted item reaches the most systems.

Containment and response

1. Freeze the share: switch affected shares or libraries to read-only, or disconnect them, to stop further spread.
2. Identify the writer: use 5145, file audit and repository logs to find the account that wrote the tainted content and suspend or revoke it, including tokens and deploy keys.
3. Find who opened it: list hosts and users that accessed or executed the content since the first malicious write, and treat them as potentially compromised.
4. Preserve evidence: copy tainted files, LNK files and modified binaries with timestamps before clean-up.
5. Restore clean content: restore from backups or known-good builds taken before the first write, rather than cleaning files in place, and verify hashes. See the NAS Ransomware Playbook for storage restoration steps.
6. Rotate exposed secrets: for repositories, rotate every secret the affected workflows could reach.

Detection metrics

1. Percentage of widely read shares and libraries with write auditing reaching the SIEM.
2. Average number of write-capable identities per widely read share, tracked down over time.
3. Percentage of non-human identities with write access scoped to named paths or repositories.
4. Percentage of CI-feeding repositories with protected default branches and required reviews on workflow files.
5. Time to make a tainted share read-only in exercises (target minutes, not hours).

Framework mapping

Common failure patterns

• Everyone can write. Legacy shares with broad write rights let any compromised account spread code.
• Service accounts with estate-wide write. Sync and deployment identities are rarely scoped and rarely monitored.
• Cleaning files in place. File infectors and LNK pivots are easy to miss; restore from known-good copies.
• Scanning endpoints only. Malware stored on file servers and cloud storage is not scanned until it reaches a client.
• Unprotected default branches. Repositories that accept direct pushes behave like writable shares, as the Megalodon campaign showed.

Practitioner checklist

• Inventory widely read shares, libraries and CI-feeding repositories and every identity that can write to them.
• Make shared locations read-only by default and remove unused write rights.
• Scope non-human writers to named paths or repositories and replace long-lived tokens with short-lived ones.
• Collect Sysmon 11, Security 5145, SaaS file audit and repository push logs.
• Alert on executable types in document shares, bulk writes by one identity and hidden directory plus LNK bursts.
• Block execution from network paths outside approved software shares.
• Require reviewed pull requests for workflow files on default branches.
• Rehearse freezing a share and restoring clean content from backup.

Standards and references

• MITRE ATT&CK: Taint Shared Content
• MITRE ATT&CK: Shortcut Modification
• MITRE ATT&CK: Hidden Files and Directories
• MITRE ATT&CK: Restrict File and Directory Permissions
• MITRE ATT&CK: Gamaredon Group
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Lateral Movement Guide · Gamaredon Group Threat Actor Profile Guide · Malicious LNK Files Guide · Unstructured Data and File Share Security Guide · CI/CD Pipeline Identity Security Guide