How T1080 Taint shared content turns trusted shares into a lateral path
In MITRE ATT&CK, T1080 Taint shared content sits under the Lateral Movement tactic (TA0008), which ATT&CK describes as the adversary trying to move through your environment. For this technique, the movement happens through content rather than through a login: an adversary who can alter files that other users and jobs open can reach those systems without new credentials. For a SOC lead, the risk is that a file server or SaaS document library is trusted by many people and automated processes, so one unexpected change can spread quietly. These pages target Enterprise ATT&CK 20.0, and mapping should be checked against that version because releases can rename or revoke techniques.
At a high level, the technique shows up where shared locations have broad write access and weak change visibility, such as departmental network shares, collaboration workspaces, build or deployment folders and shared templates. Intrusions that use it tend to be discovered through downstream effects, such as unexpected file versions, scripts or macros changing behavior, or users reporting content they did not expect. The practical decision for the SOC is which shares and libraries are treated as high trust, and whose write access to them is logged. Confirm with your file server and SaaS administrators which locations have write rights for service accounts, and which of those rights are actually needed.
The detection work starts with a short inventory: list the shares and document libraries that feed other systems, identify who or what can modify them, and confirm that file creation and file modification events are collected for those locations. Ask your platform team which audit policies and connectors are already active, because gaps in that coverage decide whether the detection in this page can work at all. The sections that follow map the telemetry, the open-source rules and the cyber range exercise to these locations, so this inventory is the first deliverable to agree internally.
Which telemetry reveals shared content tampering
This table maps the signals that reveal T1080 Taint Shared Content to the platform where they appear, the data component they fall under and the open-source collector that captures them. Read each row as a starting point: confirm which data sources your ATT&CK version maps for T1080 before you write detection rules against them.
| Platform and data component | Signal to look for | Open-source collector |
|---|---|---|
| Windows, File Creation (DC0039) | New or renamed executables, scripts or shortcuts written into a share that other users or hosts open, especially from an account not normally writing there | Windows file system audit events forwarded to Wazuh, with Sysmon file creation events where deployed |
| Windows, File Modification | Changes to existing files in a shared folder that alter content while keeping the original name, with writes clustered in time across many files | Wazuh file integrity monitoring on monitored share paths, plus Windows object access audit events |
| Windows, Network Share Access | Write access to administrative or departmental shares from an unusual source host, or bursts of share writes outside normal working hours | Windows security audit events forwarded to Wazuh, with Zeek SMB logs on the network sensor |
| Windows, Process Creation (DC0032) | A process launched shortly after a share write, particularly one that runs a file that was just modified on the share | Sysmon process creation events forwarded to Wazuh |
| Linux, File Modification | Content changes to files under exported or mounted network paths, or changes to file hashes in shared project directories | Wazuh file integrity monitoring on NFS or SMB mount points, with auditd file watch rules |
| Linux, Network Share Access | Writes to mounted SMB or NFS paths by a host or account that does not usually mount them | Zeek SMB and NFS logs, with system logs forwarded to Wazuh |
| macOS, File Creation and Modification | Unexpected writes to shared volumes or Samba-served folders, and changed file hashes in team folders | Wazuh file integrity monitoring where the agent supports the path, with Zeek SMB logs for share traffic |
| SaaS, file audit logs | Bulk file edits or version changes in shared document libraries from a single session, and sharing link changes that point to modified content | Native SaaS audit log export into a log pipeline ingested by Wazuh or Security Onion (confirm supported connectors) |
| Network, Network Share Access | SMB write sessions to file shares that sit outside the normal peer pattern for the host, visible without endpoint agents | Zeek and Suricata on the network sensor, reviewed in Security Onion |
Detection logic SOC teams can build for shared content changes
T1080 Taint Shared Content shows up as changes to files that many users and systems depend on, so detection focuses on who changed what, where, and when. The four cards below pair each signal with a starting threshold and the benign activity that will trigger it, so teams can tune before alerting. Thresholds are starting points for a lab baseline, not fixed values.
Mass writes from read-only accounts
Flag when an account or host that normally only reads from a share begins modifying many existing files within a short window. The logic joins File Modification events on the share with a baseline of each identity's historical write activity, then alerts on a sharp rise in distinct files changed per hour. Start by counting distinct paths, not raw events, so a single large save does not dominate. Typical false positives include backup restore jobs, sync clients re-writing metadata after a reconnect, and document co-authoring sessions that touch many files at once. Confirm the owning team for each share before tuning.
New executable content in shared locations
Alert when File Creation events in a shared folder produce executable-type files, scripts, or macro-enabled documents that were not present in the previous baseline snapshot. Compare file hashes and extensions against an approved inventory of software deployment paths. The key check is whether the new file lands in a location no deployment process writes to. Expected sources include software distribution jobs, installer staging folders, and developer build outputs, so exclude those paths explicitly. Review the creating process and account for each hit before closing the alert.
Off-hours changes outside the owner pattern
Compare each share's modification timing with the owner's usual working pattern, and alert when changes occur outside that window and outside any scheduled job. Build the baseline over several weeks so that shift workers, global teams, and month-end processing are represented. A reasonable first alert is any modification by an identity with no activity in that hour across the prior baseline period. Common false positives include scheduled backups, time-zone mismatches in logs, and automation running under service accounts. Document each scheduled window so analysts can suppress known patterns.
Unusual service identities editing SaaS libraries
In SaaS document libraries, alert when a service principal, integration, or non-human account edits or deletes documents it has not touched before, especially across several libraries. The detection relies on audit log content for document edits and on the identity's history of granted scopes. Check whether the integration was recently granted broader permissions, since a new scope can explain the change. Expected noise comes from sync connectors, DLP and archiving tools, and co-authoring features that record edits under the service identity. Confirm each connector's documented behavior with the vendor before suppressing its events.
How to structure the detection pipeline across Wazuh, Zeek and Sigma
The pipeline for T1080 Taint shared content should start at the file server and endpoint, not at the SIEM. File creation and file modification events on Windows file servers, plus network share access events, need to be enabled in the audit policy before any rule can fire. Wazuh agents on endpoints and file servers can forward those Windows event records to the manager, and Security Onion can ingest the same Windows events alongside network metadata from Zeek. Confirm in your own environment which share, object access and file auditing settings are active on each server, which agent version is deployed, and whether the Windows event channels you depend on are reaching the indexer without drops. Shares on Linux or NAS platforms need their own collection path, and that path is often the weaker link in the chain.
Sigma rules are written once in a vendor-neutral format and then converted by a backend into the query language of the chosen platform. Treat the conversion as a versioned build step: pin the Sigma rule set and the converter version, record which ATT&CK version each rule maps to, and rerun the conversion whenever either changes. Conversion does not guarantee that the field names in a rule match your ingested data, so check field mappings against a sample event from each source before promoting a rule. For Zeek-derived signals, such as SMB session metadata, validate the fields you rely on against your own sensor output rather than assuming the default mapping.
Baselines per share and per owner are what keep this detection usable. Group expected write volume and modification patterns by share, then by the team or service account that normally writes to it, and alert on deviation from that group rather than on a single global threshold. Ask the data owners to name the accounts and maintenance windows that legitimately modify each share, and review that list at a fixed interval. Expect the first baseline period to produce false positives from backup jobs and synchronization tools, and plan the exclusion logic as an audited change, so that suppressions do not quietly widen the blind spot.
How to validate the T1080 detection before trusting it
This sequence turns the T1080 detection from a rule on paper into one the team has proven against a controlled emulation in a lab or cyber range. It produces documented evidence of what fired, how quickly, what it missed and which ATT&CK version the results apply to.
Agree scope with file owners
Before any emulation, the detection engineer, the owners of the file shares in scope and the incident response lead agree in writing which shares, teams and hosts are involved, what data is in the test set and who can stop the exercise. The test share should be a synthetic copy in the cyber range, never a production share. The step is done when the owners sign off the scope document and the stop conditions are known to everyone running the exercise.
Define the behavior to emulate
The detection engineer describes the behavior in plain terms: an account with write access to a shared location modifies or replaces content that other users rely on, in a way that could spread a change to downstream consumers. The description maps the behavior to the telemetry the detection depends on, such as File Creation, Network Share Access and File Modification. It is complete when each expected log field is listed next to the behavior, so the team knows what a successful alert should contain. The emulation plan is written without operational commands; the executor follows an approved test procedure held by the range team.
Stage the test share and baseline telemetry
The range team prepares a test share with representative folder structure, file types and permissions, and confirms that the endpoint, file server and SIEM collectors are forwarding the expected events. The team records a baseline of normal activity on the share for a short period so that false positives can be measured against it. Confirm the collectors in your platform, such as Wazuh agents or Windows event forwarding, actually deliver the file and share events to the analysis platform. The step closes when the baseline shows the expected event types arriving with timestamps and host identities intact.
Run the emulation against the test share
The approved executor runs the planned behavior against the test share during the agreed window, while a second person records the start and end times and the account used. The observer does not interfere with the run, and the lab timeline is kept separate from the analysis data. The step is complete when the timeline is logged and the executor confirms every planned action was performed or noted as skipped.
Confirm the alert and its expected fields
The detection engineer checks whether the rule fired, when it fired and whether the alert carries the fields the detection needs, such as the source account, host, share path, file name and the time of modification. Missing fields point to a parsing or collection gap, not a detection gap, and are logged separately. The check is done when each expected field is present in the alert or a documented reason explains its absence.
Measure time to alert and false positives
The team calculates the elapsed time between the emulated action and the alert reaching the analyst queue, and reviews the baseline period for alerts the rule would have raised without the emulation. Both measurements are written into the validation record. The step produces two numbers and a list of benign events that matched, which the detection engineer uses to tune exclusions such as backup jobs or sync tools. Ask your platform team to confirm how it timestamps events, because ingestion delay can dominate the result.
Record gaps and tie results to ATT&CK version
The team writes down each gap, such as a variant of the behavior that did not alert, a share type that was not instrumented or a field that did not parse, and assigns an owner and a retest date. The validation record names the ATT&CK version the detection targets, because releases can rename, deprecate or revoke techniques and detection mappings must be read against that version. Review the current release notes on the ATT&CK site before reuse. The sequence is closed when the record is approved by the detection owner and filed with the rule version it tested.
Preventive controls that limit taint of shared content
Taint shared content works because many users and systems trust files in shared locations. The controls below reduce who can change that content, how endpoints handle it, and whether file changes leave a record. Each one supports the detection work on the same shares and repositories.
Exploit Protection on endpoints
Exploit Protection is the ATT&CK mitigation that hardens endpoints against techniques that abuse legitimate applications opening shared files. Apply it to the applications and profiles that open documents, scripts and project files from network shares. Confirm in your own environment that the policy covers those applications, that blocked events are forwarded to central logging, and that exceptions are reviewed and recorded. Confirm the current mitigation ID in the ATT&CK 20.0 release before you cite it in documentation.
Restrict file and directory permissions
Separate read access from write access on shared content. Most users need to read templates, scripts and shared libraries, but only a small, named group should be able to modify them. Review access control lists on network shares, shared drives and code repositories, and remove broad write permissions granted to everyone or to large domain groups. Confirm the current mitigation ID for this control in the ATT&CK 20.0 release before you publish it.
Privileged account management
Privileged Account Management (M1026) limits who holds rights to change shared content, including the service accounts used by sync jobs, backup agents and deployment tools. Keep these accounts in a short, reviewed list, rotate their credentials on a schedule your policy sets, and avoid reusing them for interactive logons. Confirm that changes to group membership for these accounts generate alerts, because a single compromised service account with write access can alter content that many users trust.
Audit file access and modification
Without file audit logs, a tainted file leaves no trail. Audit (M1047) means enabling the operating system and platform logging that records file creation, modification and permission changes on shared locations. Confirm that auditing is turned on for each share and repository in scope, that events reach your SIEM, such as Wazuh or Security Onion, and that retention covers the time window your investigations need. Ask your platform owner which events are logged by default and which need explicit configuration.
What to do in the first hour after a shared content alert
Start by confirming that the change is real and bounded. Compare the flagged file against its version history in the document platform or against the most recent known-good backup, and note the last clean version and the first suspicious one. A tainted file usually shows a modification by an account or service that does not normally edit that content, or a change in size, format or embedded objects with no matching business edit. Record the account, host, source address and time of each suspect write. Then check whether the same account or host touched other shares, repositories or document libraries in the same window, because T1080 activity often spreads across several locations rather than one file. Ask the platform owner to confirm which audit events are retained for those locations, since the depth of file modification history differs between Windows file servers, SaaS collaboration suites and Linux or macOS network shares.
Contain the originating session without destroying what you need to investigate. Disable or restrict the suspect account's write access to the affected locations, or move the affected folders to a read-only state, rather than wiping the host or deleting the file. Ask the endpoint team to isolate the originating host through the EDR or network control already in place, and preserve volatile evidence such as running processes and open network connections before reboot. Export the relevant logs from the file server, identity provider, SaaS audit log and endpoint telemetry, and hash the exports. Keep the copies of tainted files in a separate, access-controlled location so they can be compared against restored versions later. Notify legal or compliance early if the affected content carries a data classification, contractual obligation or regulatory notification clock, because those teams decide what must be preserved and who must be told. Your records retention policy should set the minimum retention period for these exports, and that is a point to confirm with your own counsel.
Rehearsing T1080 detection in a private cyber range
The range models a Windows file server joined to a test Active Directory domain, with a departmental SMB share, a few client workstations and a Wazuh manager receiving Windows event logs and Sysmon telemetry. Benign injects include routine document edits, scheduled backups and antivirus scans, so the analysts learn what normal file modification looks like on the share. Scripted injects simulate a user account writing modified copies of existing office files across many folders within a short window, with file creation and modification events forwarded to the SIEM.
- Baseline first: Record normal write volume per share and per account before the exercise so that analysts have a reference for anomalies.
- Telemetry check: Confirm that object access auditing is enabled on the target folders and that file creation and modification events reach the manager.
- Alert quality: Look for a rule that correlates file modification bursts with unusual writer processes and with prior share access events.
- Triage path: Analysts should identify the writing account, the affected folders and the time of first change, then compare against version history or backups.
- Containment: Test whether the team can disable the account, restrict write permissions on the share and preserve evidence without stopping the file server.
A weak result is an alert that fires only after hundreds of files are changed, or a triage that cannot tell legitimate editors from the injected writer. Check the time from first write to analyst acknowledgement.
This tab builds a Linux host exporting a shared directory over NFS or Samba to a mixed group of Linux and Windows clients. The range includes a Zeek or Suricata sensor on the share network and a Wazuh agent on the server, so the team can compare host-side file events with network-side share activity. Benign injects are normal build artifacts, log rotation and user document saves. Scripted injects change shared files from a client account that normally only reads them, and the exercise measures whether the sensor and host logs agree on what happened.
- Export scope: Document which exports, mount options and ownership rules apply, since these determine what a client can change.
- Dual visibility: Verify that share access is visible to the network sensor and that file modification events are captured by the host agent or audit rules.
- Ownership mismatch: Build a detection that flags writes to files whose owner or group differs from the account making the change.
- Triage path: Analysts should confirm the client host, the mount source and the list of changed files, then check version control or snapshots.
- Containment: Test removing write access at the export or file permission level and blocking the client, with a rollback plan for legitimate jobs.
A weak result is one where the network sensor sees the share session but nothing ties it to a file change, or where the team cannot tell which client host performed the write.
This tab models a small group of macOS workstations sharing a project folder through a file share and syncing with a central management tool, with a Wazuh agent or an endpoint telemetry agent on each host. The range is useful because content on macOS is often edited locally and synced, so tainted files may spread through sync rather than direct share access. Benign injects include normal edits, sync conflicts and application updates. Scripted injects modify shared documents on one workstation and let the change propagate to the others.
- Telemetry scope: Confirm which file events the endpoint agent records on the synced folders and whether the logs carry enough context to name the process responsible.
- Sync awareness: Add the sync client to the baseline so that propagation from one host to others is recognized as a single event chain.
- Detection logic: Look for a rule that flags a burst of modifications across several hosts within a short period, linked to one originating host.
- Triage path: Analysts should isolate the originating workstation, identify the first changed files and check which copies on other hosts are affected.
- Containment: Test whether the team can pause sync for the group, restore affected files from versioned storage and revoke the workstation's share access.
A weak result is one where the team only sees changes on the final host and misses the originating workstation, or where containment stops the sync but leaves the tainted files in place.
This tab uses a SaaS document library, such as a hosted collaboration suite, connected to a SIEM through its audit log feed. The range has no servers to manage, so the exercise tests whether the team can read the vendor's audit records, map them to a document, and act through administrative controls. Benign injects include routine co-authoring, version restores and external sharing approved by the content owner. Scripted injects use an account with edit rights to alter many documents in one library over a short period, which the team must spot from audit events alone.
- Audit feed: Confirm which audit events the SaaS tenant exports, how long they are retained and how quickly they arrive in the SIEM. Confirm these details with the vendor.
- Detection logic: Build a rule that counts edit events per account per library and flags sharp increases compared with the baseline.
- Triage path: Analysts should identify the account, the session location and the affected documents, then check the version history.
- Containment: Test suspending the account's sessions, restricting edit rights on the library and restoring prior versions, with the owner's approval recorded.
- Scope limits: Note which actions the team cannot perform from the SIEM and which require tenant administrators.
A weak result is an alert based on a single edit event, or a response that disables the account without restoring the affected documents.
Questions SOC leads and detection engineers ask about T1080
How do I separate backup jobs from tampering with shared content?
Treat backup activity as expected behavior that you can describe precisely, then flag anything that falls outside that description. Record the backup service account, the source host, the schedule, and the share paths it touches. Writes from an unexpected process, writes outside the backup window, or bulk modifications from an account that normally only reads are the signals worth escalating. Keep the allowlist in version control so that every exception is reviewed and logged. Confirm with the backup vendor which file operations the job performs, such as metadata updates or temporary files, so you do not suppress a real modification pattern by accident. Test the rule against a backup run in your range before it reaches production.
How should detections handle sync clients that modify many files?
Sync clients legitimately rewrite large numbers of files, so volume alone is a poor signal. Focus on which process made the change, whether that binary is the vendor's signed client, and whether the change originated from a known device and user. A modification from an unknown executable writing into a synced folder is a stronger indicator than a burst from the client itself. Build a per-user baseline over a normal working period and alert on deviations from it. Ask the sync vendor to document the file operations its client performs, including temporary and rename behavior, because those patterns often trigger false positives. Review the baseline whenever the client version changes.
Do SaaS audit logs capture document edits and sharing changes?
Coverage depends on the platform, the license tier, and the specific event types, so confirm it for each tenant before you write rules against it. Ask the vendor whether edits, version history changes, permission changes, and bulk actions are logged, and whether bulk actions are attributed to the user or to an integration. Find out the retention window and whether the logs can be exported through an API into your SIEM on a continuous basis. Where edit events are missing, you may need to rely on version history or sharing events as proxies, and you should document that gap as a residual risk. Validate each event type by making a controlled change in a test tenant and confirming it appears in your pipeline.
How do I version Sigma rules against ATT&CK releases?
Tag every Sigma rule with the ATT&CK version it targets, store the rules in Git, and pin the version in your rule metadata. ATT&CK v18 replaced technique-level detections with detection strategies and analytics, so map each rule to the relevant DET IDs and data component IDs rather than relying on older free-text references. Releases can rename, deprecate, or revoke techniques, so compare each new version against your mapping by parsing the STIX bundle for that version in the attack-stix-data repository. Keep a changelog that records which rules were reviewed, retired, or updated for each release. Run your range tests again after every mapping change.
How do I measure detection coverage for T1080 without a single percentage?
Measure coverage per sub-technique, per platform, and per data source, because a single percentage hides the gaps that matter. Start from the detection strategies and data components that ATT&CK references for the technique, then record which of those telemetry sources you actually collect on Windows, Linux, macOS, and SaaS. For each source, note whether a rule exists, whether it has been tested in a cyber range, and how often it has produced an alert in production. A simple matrix with these columns gives reviewers something they can challenge. Re-run the matrix after each ATT&CK release and after any change to logging configuration, since a silent logging change can remove coverage without anyone noticing.
Can we rehearse T1080 detections in a private cyber range before production?
Yes. Rehearsal in an isolated environment lets you test rules against synthetic shares, sync clients, and SaaS test tenants without touching business data. DeployOpen runs private cyber ranges and security testing, and most engagements are fixed-scope, with the scope, deliverables, and timelines agreed in writing before work starts. Ask which platforms the range replicates, such as Windows file shares, Linux or macOS endpoints, and the SaaS tenant types you use, and whether it includes the backup and sync software that produces legitimate traffic. Make sure the exercise plan records expected results for each test, so the team can distinguish a missed detection from a misconfigured test.
How DeployOpen builds T1080 detections and range exercises
DeployOpen works on T1080 Taint shared content as a scoped engagement inside your own environment, whether that is cloud accounts, data centers or air-gapped networks. The work covers detection logic, telemetry checks, cyber range rehearsal and the documentation your teams need to run it.
How we scope
- Confirm which Windows, Linux, macOS and SaaS file stores are in scope for T1080 detection.
- Record the ATT&CK version the detection mappings target before any rule is written.
- Agree in writing which telemetry sources, such as file creation and share access logs, the engagement will rely on.
How we build
- Write detection logic for T1080 in plain words, then translate it into Sigma rules for your SIEM platform.
- Configure file creation, network share access and file modification collection in Wazuh or Security Onion where your environment supports it.
- Check mappings of the Exploit Protection and Restrict File and Directory Permissions mitigations against your current controls.
How we hand over
- Deliver a written runbook covering alert triage, containment steps and evidence preservation for T1080 events.
- Run a private cyber range exercise that replays benign tainting scenarios so your analysts can see the alerts fire.
- Document known blind spots and the telemetry gaps your team should close or accept as residual risk.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, rule tuning and re-testing after ATT&CK version changes are available as a retainer.
- Ask for a written quote based on your scope, since DeployOpen does not publish a price list.
