How T1565 data manipulation quietly changes what your organization trusts
T1565 Data manipulation is the ATT&CK technique in which an adversary changes data so that your systems, reports or decisions reflect something untrue. It sits under the Impact tactic (TA0040), which ATT&CK describes as an adversary trying to "manipulate, interrupt, or destroy your systems and data." This page targets Enterprise ATT&CK version 20.0. The technique has three sub-techniques, and you should confirm their current names and scope on the technique page for that version before you map any detection to them. Here we stay at the level of what the SOC needs to recognize and decide.
Manipulation is often quieter than destruction. In an intrusion, it tends to follow access rather than announce it, and the goal is usually to change what people believe. A ledger entry shifts by a small amount, a configuration value is edited, or a log record is altered, while the application keeps running and no service stops. Because nothing is offline, outage-driven alerts stay silent. Backups can also copy altered data forward if they are taken after the change, which weakens the assumption that a restore will undo the damage. Expect the first signal to come from an inconsistency someone notices, not from a clean alert.
Start by naming the data you treat as authoritative. Ask the business owners which datasets drive financial reporting, clinical or case decisions, access control and security monitoring, then record who can write to each one and through which paths. Confirm whether integrity baselines exist for those stores, how long backups are retained, and whether you could identify a version of each dataset that predates a suspected change. These answers decide which telemetry you need later, so resolve them before selecting detection content or planning an exercise.
Which telemetry reveals data manipulation and which open-source tool collects it
This table maps each data component relevant to T1565 to the signal defenders should look for and the open-source collector that gathers it. Read each row as a starting point: confirm data component coverage for each sub-technique against the enterprise-attack 20.0 bundle before building analytics. The main takeaway is that no single source covers all three sub-techniques, so file, network and aggregation telemetry must be planned together.
| Data component | Signal to look for | Open-source collector |
|---|---|---|
| File Creation (DC0039) | Unexpected new files in monitored data stores, or files written by processes outside the expected application owner | Wazuh file integrity monitoring, Velociraptor for on-demand endpoint sweeps |
| File Modification (confirm DC ID in bundle) | Changes to records, reports or configuration files that lack a matching change ticket or application transaction | Wazuh file integrity monitoring with hash and attribute baselines on critical paths |
| Network Traffic Content (DC0085) | Payload or field values in data exchanges that differ from the expected schema, source or sequence | Zeek for protocol-level logs, Suricata for content-matching rules |
| Application Log Content (DC0038) | Database, application or API audit entries showing edits made outside normal workflows or by unexpected accounts | Wazuh log collection, with Security Onion as the aggregation and search layer |
| Cross-source aggregation | Correlating a file change with the process, account and network session that preceded it | Security Onion to join Zeek, Suricata and Wazuh events in one search and dashboard view |
| Endpoint forensic collection | Snapshots of file hashes, permissions and recent writes taken during an investigation to confirm what changed | Velociraptor artifacts run against the affected hosts |
| Sub-technique coverage check | Confirm which data components each sub-technique references in the enterprise-attack 20.0 bundle before writing analytics | Local review of the STIX bundle for the target platform and version |
Detection ideas for data manipulation that do not rely on known tooling
T1565 covers changes to data that look legitimate to the system holding it, so signatures for specific tools miss most of it. The four ideas below watch the data itself: its integrity, when it changes, whether it agrees with its source of record, and whether the audit trail still accounts for every change.
Integrity baseline deviations on critical stores
Hash or fingerprint the records, configuration files and reference datasets that drive business or safety decisions, then alert when current values drift from the approved baseline. Start with a small set of stores whose contents are well understood, such as payment reference tables, clinical code sets or firewall policy files. Tune the threshold by counting how many fields change in a normal week, and alert only on changes that no approved change record explains. Expect false positives from scheduled batch jobs and ETL pipelines that rewrite whole tables, so the baseline must be recalculated after each approved load rather than compared to a static snapshot. Use a baseline that moves only through approved change records.
Modification outside change windows
Compare the timestamps of file creation and modification events on protected data paths against the change calendar your organization publishes. Any write outside an approved window, or by an account that is not on the change roster for that system, deserves review. The check depends on File Creation and File Modification telemetry reaching your SIEM with the writing account and process recorded. Expect false positives from approved patches that run at odd hours, backup restores, and maintenance by vendors on emergency tickets. Confirm with the platform owner which jobs write to each path and whether they run under service accounts that are documented.
Data in transit that disagrees with the source of record
Reconcile values seen on the wire against the system of record for the fields that matter most, such as account numbers, dosages, prices or routing identifiers. Network Traffic Content collected by Zeek or Suricata can show payloads moving between services, and a scheduled reconciliation can flag records where the transmitted value differs from the authoritative copy. Set the tolerance at zero for identifiers and a defined variance for computed amounts, and document both. Expect false positives from rounding, currency conversion, format changes after upgrades and records corrected by approved workflows. Reconciliation must be run by a team that does not own the system being checked.
Audit trail gaps and sequence breaks
Look for gaps in the sequence of audit records for a data store, such as missing record identifiers, jumps in logical clocks or periods with no log entries from a system that normally logs continuously. A gap can mean that logging was disabled, that records were removed from the log, or that a change was made through a path that bypasses auditing. Use Application Log Content from the database or application to establish the normal heartbeat of entries, and alert when the expected rate drops below the tuned threshold. Expect false positives from planned log rotation, maintenance windows and services that legitimately stop logging during failover. Ask each platform owner to document which events are expected to be silent.
Unexplained bulk edits by a single identity
Measure how many records a single account or service identity modifies in a time window and compare that count with its historical pattern. A spike in updates from an identity that normally reads data, or edits spread across unrelated tables, is a useful signal even when no known tool is involved. Set the threshold from several weeks of normal activity and review the top changed records each time it fires. Expect false positives from bulk corrections, data migrations and quarterly close processes. Ask the data owner to confirm which identities are allowed to perform bulk writes and to keep that list current.
How to validate that a T1565 detection actually fires
This sequence proves, in a private cyber range, that each T1565 detection produces a timely, high-fidelity alert the SOC can act on, and it records the gaps to fix before the next ATT&CK release changes the mapping.
Scope the test data and target systems
The detection owner and the platform engineering lead agree which systems, file shares, databases and network segments the emulation may touch, and which datasets are synthetic. Use dedicated test records that mirror the structure of production data, so a manipulated value can be traced and reverted without affecting real customers or regulated records. Confirm that backups of every test dataset exist and have been restored successfully once before the exercise starts. Done when the scope document lists each target, its owner and its rollback method.
Agree rules of engagement and stop conditions
The security lead, the system owners and the SOC manager sign a short rules of engagement document that names the exercise window, the approved emulation activities for each sub-technique, the named contacts, and the conditions that halt the test. Stop conditions should include any impact to production services, any unexpected access outside scope, and any alert storm that threatens SOC capacity. Record who can call a stop and how the emulation team confirms it. Done when every system owner has signed and the stop procedure has been tested by phone or chat.
Map each sub-technique to a test case
The detection engineer writes one test case per T1565 sub-technique in plain language, covering the expected behavior, the telemetry the detection depends on, and the expected alert name and severity. Cases reference the ATT&CK version the detection targets, so results remain comparable after a release. Confirm the test cases against the current detection strategies and data components in the ATT&CK knowledge base before running anything. Done when each case has a written expected outcome and a named reviewer.
Run the emulation and record timestamps
The red team or the range operator executes the approved test case for each sub-technique within the agreed window, while a separate observer logs the wall-clock start and end of each action. Keep the observer independent of the emulation so the timeline is trustworthy. Note any action that the environment blocked, logged or ignored. Done when the timeline lists every action with its start time, and no activity has run outside the approved scope.
Confirm the alert reaches the SOC queue
The SOC analyst checks the queue in the SIEM or case management platform, such as Wazuh or a comparable console, and confirms that each expected alert arrived, carried the right host, user and file or network context, and was routed to the correct team. Compare the alert's arrival time against the observer's timeline to calculate time to detection for each case. Done when every test case has a recorded alert identifier, or a documented reason for its absence.
Score alert fidelity and log gaps
The detection engineer grades each alert on fidelity: whether it names the manipulated asset, separates the test activity from normal business changes, and contains enough evidence for triage without extra searching. Record any missing telemetry, such as file integrity events not collected or network content not captured, and trace each gap to the data source responsible. Done when each gap has an owner, a description and a proposed fix in the backlog.
Document results and schedule re-validation
The detection owner produces a short report with the test cases, timelines, alert outcomes, gaps and remediation owners, then files it with the compliance lead as evidence of detection testing. Repeat the same test cases after each ATT&CK release, because releases can rename, deprecate or revoke techniques and change the data components a detection depends on. Ask the vendor or the testing partner to confirm the exact re-validation schedule and the ATT&CK version each run targets. Done when the report is approved and the next validation date is on the calendar.
Preventive controls that limit data manipulation
Two mitigations do most of the work against T1565 Data manipulation. Restrict File and Directory Permissions (M1022) limits who can change data, and Network Segmentation (M1030) limits where a change can travel. Filter Network Traffic (M1037) and Data Backup (M1053) support inspection and recovery, and each card names what to check in your environment.
Restrict write access to data
Restrict File and Directory Permissions (M1022) is the first control to set. Grant write access to data directories, exports and shared folders only to the service accounts and roles that need it, and remove write rights from interactive users and broad groups. Most unauthorized changes need a writable path, so an audit of who can write to each data store is the first check. Ask for the access list, the named owner and the date of the last review for every data location in scope.
Review inherited and shared permissions
Permissions often drift through inheritance, copied directories, restored backups and shared mounts, so the intended settings may not match what is applied. On Linux and macOS, look for world-writable directories and unexpected group ownership on data paths. On Windows, check inherited write grants on file shares and on the folders beneath them. Compare the effective permissions against the documented design, not against the defaults of the platform.
Segment the data tier
Network Segmentation (M1030) places databases, file stores and backup targets in their own zones, with allow lists that permit only the application tiers and administrative paths that need them. This limits how far a manipulated record or file can travel: a compromised workstation should not reach a data store directly. For T1565 Data manipulation, check every path into the data zone, including management ports, vendor connections and admin jump hosts, and confirm that each flow has a named owner and a documented reason.
Inspect traffic that reaches data
Filter Network Traffic (M1037) supports detection of T1565 Data manipulation by letting you restrict and inspect flows into data zones. Network Traffic Content telemetry, collected from sensors such as Zeek or Suricata where they are deployed, can show unexpected write requests or unusual sources. Content inspection depends on protocol visibility and on where encryption ends, so confirm which protocols are visible in plaintext, which terminate at the data tier and who reviews the resulting alerts.
Keep recovery copies separate
Data Backup (M1053) gives you a known-good reference when manipulated data is suspected, and a path to restore it. Keep copies outside the write permissions of the accounts that can alter production data, and test restores on a schedule so the comparison is trustworthy. Ask for the backup catalog, the retention policy for each data set, the location and access list of backup copies, and the date of the last restore test.
Confirm mappings against ATT&CK
The mitigation mappings in this section reflect how ATT&CK currently relates controls to Impact techniques, and they can change between releases. Confirm each mapping on the T1565 technique page and on each sub-technique page before you cite it in a control matrix. Record the ATT&CK version you used, such as Enterprise 20.0, and recheck it against the MITRE ATT&CK site during each review cycle.
What the SOC does in the first hours after a manipulation alert
The first task is to decide whether the change is authorized. Before anyone restores or reverts anything, the analyst confirms with the data owner and the change record whether the modification was planned, such as a batch job, a schema migration or a scheduled import. Check the identity behind the write, the originating host or service account, and whether the change matches an approved window. If the change is unexplained, treat the alert as a live incident and preserve evidence first. Affected files, database extracts and the relevant audit logs should be copied to write-protected storage with hashes recorded, because a restore that overwrites the modified state can destroy the very artifacts needed to reconstruct how the data was altered.
Next, scope the damage. Identify which data sets were touched, over what time range, and which downstream consumers read them, including reports, reconciliation jobs, APIs, partner feeds and dashboards that may have already acted on the bad values. Notify the data owners early with a factual summary: what changed, what is known and not yet known, and whether any customer-facing or regulated outputs are affected. Decide whether to contain the source host or the network segment it sits in. Isolating the host protects the evidence and stops further writes, but it can also interrupt legitimate processes, so the decision should be made jointly with the platform owner. Confirm in your own environment which isolation actions your EDR and network controls support without disrupting unrelated services.
Restoration is the last step, not the first. Restore from a backup only after the team has verified that the backup predates the manipulation, that it has not itself been altered, and that restoring it will not reintroduce a known vulnerability or a planted persistence mechanism. The data owner should sign off on the restoration point and on the reconciliation plan for transactions written after that point. Ask your backup platform owner to confirm the retention window and immutability settings in writing, since these determine which restore points can be trusted in practice. Record every decision, timestamp and approver in the incident ticket so the post-incident review and any regulator inquiry can reconstruct the sequence.
How to rehearse T1565 detection in a private cyber range
The Linux file server range is a private, isolated network segment holding a file share, a monitoring host running Wazuh or a comparable file integrity monitoring agent, and a network sensor such as Zeek or Suricata placed on the segment that carries the share traffic. Benign activity includes scheduled report writes, routine edits by service accounts and normal read traffic, so analysts learn the baseline before anything unusual is introduced. Emulated injects are limited to changes to files in agreed directories, with content modifications staged to resemble an integrity attack, and every inject is logged with a timestamp so it can be matched to alerts later. Expected detections include file modification events for the scoped paths from file integrity tooling, and network content observations if protocol-level changes cross the sensor. Good detection means an alert reaches the queue within the agreed window, names the affected path and the account, and includes the prior file hash for comparison. Good response means the analyst can confirm the change against backup or version history and document scope.
- Topology: one file server, one monitoring host and one sensor on a mirrored or tapped segment, all inside the range.
- Benign injects: scheduled jobs and ordinary user edits recorded as the baseline.
- Emulated injects: agreed content changes to pre-selected files, with exact timestamps recorded.
- Expected signals: file modification alerts with hashes, plus protocol-level observations where applicable.
- Response check: restore from a known-good copy and confirm the restored hash matches the pre-exercise value.
Confirm with your team that the monitored paths, alert routing and backup retention match what the rehearsal is meant to test.
The Windows application host range models a line-of-business application server whose database connection strings, configuration files and application data sit on local disk. The monitoring stack collects Windows event data and file activity through agents, and a network sensor watches the application's traffic to its back-end service. Benign activity includes application deployments, configuration updates made through the normal change process and routine data writes, so the team can separate authorized change from suspicious change. Emulated injects alter application data or configuration in agreed locations, with the change window and account identity recorded in advance. Expected detections include file modification and creation events on monitored application paths, along with content anomalies in the application's network flows where the sensor can parse them. Good detection means the alert separates a change made by the change pipeline from one made outside it, and that the analyst can see the process context. Good response means the application owner is engaged, the change is reverted from a verified source and the application's own integrity checks are rerun.
- Topology: application server, database or service back end, monitoring agents and a sensor on the application segment.
- Benign injects: approved deployments and configuration changes executed through the change pipeline.
- Emulated injects: out-of-process changes to agreed configuration and data files during a declared window.
- Expected signals: file change events with process attribution and network content anomalies on the application protocol.
- Response check: the application owner confirms the restored state and the change record matches what was actually executed.
Confirm with the application owner which data stores are in scope and whether the application supports its own integrity verification.
The macOS workstation range uses a managed test endpoint with an endpoint agent and file integrity monitoring configured for user document folders and selected application support paths. A network sensor observes the workstation's sync and collaboration traffic. Benign activity includes normal document edits, sync client updates and application autosaves, which generate frequent legitimate modifications that analysts must learn to filter. Emulated injects modify documents in a designated user folder, with the test account and the exact file list agreed beforehand, and no real user data is involved. Expected detections include file modification events attributed to the process that wrote them, and content-level observations if the sync traffic is inspected. Good detection means the alert distinguishes autosave and sync behavior from unexpected writes, using process lineage and file path rules rather than alert volume. Good response means the analyst identifies the scope across the test account's files, restores from the versioned copy and documents why the baseline rules did or did not fire.
- Topology: one managed macOS test endpoint, its endpoint agent, a file share or sync target and a sensor on the traffic path.
- Benign injects: autosaves, sync client activity and ordinary document edits from the test account.
- Emulated injects: agreed modifications to a designated folder of synthetic documents.
- Expected signals: file modification events with writing process attribution, and sync-path anomalies if inspected.
- Response check: versioned copies are restored and the tuning notes for benign autosave noise are recorded.
Confirm the agent's macOS file event coverage and permission requirements with your endpoint vendor before scheduling the exercise.
Questions detection engineers ask about T1565
How do I separate data manipulation from legitimate ETL changes?
Start by baselining the jobs, service accounts and write paths that legitimately change data, then alert on writes that fall outside those known paths. Legitimate ETL runs on a schedule, from a known host, under a known identity, and writes to expected tables or directories. Manipulation tends to break one or more of those patterns: an unexpected account, an off-hours write, a new source host or a change that no change ticket explains. Correlate file or database change events with the job scheduler and your change management records so every alert has an owner to confirm or dismiss it. Tune the baseline per job, not per environment, and review it after each pipeline release.
Which T1565 sub-technique telemetry matters most on each operating system?
The answer depends on where the data lives, so map telemetry to the sub-technique rather than to the operating system alone. For stored data, File Creation and File Modification events from file integrity monitoring on Linux and Windows hosts give you the clearest signal, with Application Log Content covering changes made inside databases and business applications. For data in transit, Network Traffic Content is the main data component, but it only helps where traffic is visible to you. On macOS, confirm which file events your endpoint agent can see before you write rules against them. Check the current ATT&CK data component definitions for the version you target, because data components change between releases.
How do I detect data manipulation in encrypted network traffic?
You usually cannot read the payload of encrypted traffic, so detection shifts to metadata and to the endpoints. Use Zeek or Suricata to record connection, certificate and session metadata, then alert on unexpected destinations, unusual volumes or new flows to systems that should only receive reads. Where your policy permits TLS inspection at a controlled point, decrypt only for defined, documented services and keep the decrypted data within the monitoring boundary. Pair network signals with host-level file and application events, since those see the data before it is encrypted or after it is decrypted. Confirm with your security and legal teams what inspection is permitted for each data class.
How often should I revalidate T1565 detections after ATT&CK releases?
Revalidate whenever you adopt a new ATT&CK version and whenever a release changes a technique you rely on. MITRE publishes ATT&CK updates on its updates page, and the recent releases listed there show that techniques can be renamed, deprecated or revoked. Because ATT&CK v18 replaced detections in technique pages with detection strategies and analytics, rule mappings written against older pages may need rework. Record the ATT&CK version in every detection's metadata, rerun your validation tests after each upgrade and track mapping drift in your detection-as-code repository. Confirm the revalidation cadence you can sustain with your team before you commit to it in a written plan.
How do I tune file integrity baselines without missing manipulation?
Tune by scope and by change type, not by suppressing noisy paths. Begin with the files and directories that hold regulated or business-critical data, then record a known-good baseline after a verified change window. Exclude only paths that are demonstrably ephemeral, such as caches and temporary job directories, and document each exclusion with an owner and a review date. Separate expected changes, such as scheduled imports, from unexpected ones by joining integrity events with job identity and change tickets. Test your tuning in a cyber range by replaying known manipulation scenarios and confirming the alerts still fire after each change to the baseline.
Which mitigations reduce T1565 risk, and how do I confirm they work?
The ATT&CK mitigations most relevant here are Restrict File and Directory Permissions (M1022) and Network Segmentation (M1030). Restricting write access to data stores limits which identities can manipulate files, while segmentation limits which hosts can reach them. Confirm each control by testing it: attempt authorized and unauthorized writes from representative accounts in a staging environment, then check that the expected denials and alerts appear in your logs. Record the results as evidence. Keep in mind that these controls reduce exposure but do not replace detection, so keep your monitoring running alongside them.
Can my own team run T1565 detection exercises in a cyber range?
Yes, if your team has the skills, the isolated environment and the time to plan and debrief. A cyber range lets you rehearse data manipulation scenarios against copies of your data stores, without touching production. The work breaks into scenario design, environment build, telemetry checks, execution, and review of which alerts fired and which did not. Many teams start with their own staff and bring in outside help for scenario design or independent review. DeployOpen provides private cyber ranges and security training, and it scopes that work in writing before it starts, so ask for a written scope that names the systems, data and rules to be tested.
How DeployOpen builds T1565 detections and range scenarios
DeployOpen works on T1565 Data manipulation as a fixed-scope engagement inside the client's own infrastructure, using open-source tooling. The work covers the telemetry, detection logic, validation and response steps needed to spot unauthorized changes to data on Linux, macOS and Windows.
How we scope
- Agree in writing which platforms, applications and data stores fall under T1565 monitoring.
- Confirm which telemetry is available for Network Traffic Content, File Creation and File Modification.
- Record the ATT&CK version the detection mappings target, so later updates can be tracked.
How we build
- Map detection logic to the three T1565 sub-techniques in words, then implement it in Wazuh, Sigma or Security Onion rules.
- Set up file integrity monitoring on critical datasets, configuration and business records, tuned to known change windows.
- Document Restrict File and Directory Permissions and Network Segmentation controls and check them against the monitored assets.
How we hand over
- Deliver a written detection inventory with data sources, alert logic, tuning notes and known blind spots.
- Run a private cyber range exercise that simulates benign and unauthorized data changes, with results recorded for your team.
- Provide response runbooks for triage, evidence preservation, rollback from backup and communication to data owners.
How we support
- Ongoing support and continuous testing are available as a retainer after handover.
- Review detection mappings when MITRE ATT&CK releases rename, deprecate or revoke techniques that affect T1565.
- Ask for the scope, deliverables and handover format in writing before work starts, so the quote matches the agreed scope.
