MITRE ATT&CK T1565 Data Manipulation: Detecting and Limiting Damage

Data manipulation is the impact technique that leaves systems running and dashboards green while the records, messages or screens people rely on have been quietly changed. MITRE ATT&CK tracks it as T1565 Data Manipulation, an Impact (TA0040) technique with three sub-techniques, T1565.001 Stored Data Manipulation, T1565.002 Transmitted Data Manipulation and T1565.003 Runtime Data Manipulation, on Linux, macOS and Windows. The goal, in ATT&CK's words, is to influence external outcomes or hide activity by affecting a business process, organisational understanding or decision making. This guide is for detection engineers, application and data owners, and teams running payment, trading or build systems. It covers the cases ATT&CK records, MITRE's detection strategies, the four v20 mitigations and the integrity controls that make tampering visible.

Key takeaways

• Nothing breaks, so nothing alerts. Unlike encryption or wiping, manipulation is designed to go unnoticed. Detection has to compare data against an independent record, not wait for an outage.
• Three places to tamper. At rest (database rows, files, logs), in transit (messages between systems or processes) and at runtime (what an application displays). Each needs a different integrity check.
• Expertise and patience are the cost. ATT&CK notes complex targets need special expertise, often gained through a prolonged information gathering campaign. Mandiant reported APT38 stayed in victim networks for about 155 days on average.
• What people sign can differ from what they see. In the Bybit theft, signers approved what looked like a routine transfer while malicious JavaScript changed what was actually signed. Integrity of the display layer matters as much as integrity of the data.
• ATT&CK lists four mitigations. M1022 Restrict File and Directory Permissions, M1029 Remote Data Storage, M1030 Network Segmentation and M1041 Encrypt Sensitive Information. The strongest practical control, an independent integrity check, sits on top of them.

What the technique covers

ATT&CK v20 (T1565 version 1.1) describes adversaries inserting, deleting or manipulating data to influence external outcomes or hide activity, threatening the integrity of the data.

Boundaries with neighbouring techniques: destroying data is T1485 Data Destruction, intercepting traffic to steal credentials is MITRE ATT&CK T1557 Adversary-in-the-Middle, and changing software before it ships is MITRE ATT&CK T1195 Supply Chain Compromise. Manipulation of AI training data is tracked separately in MITRE ATLAS; see AML.T0059 Erode Dataset Integrity.

How adversaries use it: real cases

Financial fraud

• APT38 (G0082), stored, transmitted and runtime: ATT&CK, citing FireEye's 2018 APT38 report, records DYEPACK creating, deleting and altering records in databases used for SWIFT transactions, manipulating SWIFT messages en route to a printer, and DYEPACK.FOX altering PDF data as it is displayed to remove traces of fraudulent transactions. Mandiant's summary says the group inserted fraudulent SWIFT transactions and altered transaction history on the victims' own SWIFT-facing systems, never the SWIFT network itself, then securely deleted logs and used disk wipers to disrupt forensics. See the APT38 Threat Actor Profile Guide and the SWIFT Customer Security Programme (CSP) Guide.
• FIN13 (G1016): injected fraudulent transactions that mimic legitimate behaviour to siphon off incremental amounts of money (Sygnia, Elephant Beetle, January 2022). Small, normal-looking changes are the hardest to catch.
• Bybit (February 2025), display-layer manipulation: our Bybit Hack 2025 analysis describes malicious JavaScript placed in Safe{Wallet} resources served from AWS S3, activating only for Bybit's contract address and removed about two minutes after the malicious transaction. The signatures were genuine; the transaction was not what signers believed. Initial access came through a developer laptop and hijacked AWS session tokens. The FBI attributed the theft to North Korea (TraderTraitor).
• Melcoz (S0530) and Metamorfo (S0455): watch the clipboard for cryptocurrency addresses and swap in the attacker's address. GlassWorm (S9010) can intercept and modify transaction details for hardware wallet applications before signing (Koi, December 2025). See the GlassWorm VS Code Extension Worm Guide.

Hiding activity and persistence

• SUNSPOT (S0562): on SolarWinds build servers, SUNSPOT found running MsBuild.exe processes, swapped the Orion InventoryManager.cs source file for a backdoored version before compilation, checked MD5 hashes first so it would not break the build, then restored the original after the build exited (CrowdStrike, January 2021). Manipulation of stored data here enabled a supply chain compromise.
• PHASEJAM (S9014): on Ivanti Connect Secure appliances, blocked legitimate upgrades and showed a fake progress bar, copied the new VERSION file so the appliance reported the upgrade as successful, and recalculated the hashes in the integrity manifest to evade the vendor's integrity checker (Google Threat Intelligence, January 2025). See the Ivanti Connect Secure Hardening and Integrity Checking Guide.
• LightNeuron (S0395): modifies email content, headers and attachments in transit on mail servers (ESET, May 2019).
• MultiLayer Wiper (S1135): changes the original path information of deleted files to make recovery harder (Unit 42, 2023).

The SUNSPOT and PHASEJAM cases share a lesson: an integrity check that runs on the system it protects, against a manifest stored on that system, can be manipulated too.

What to detect and where

MITRE's four strategies are host-centric. The table condenses their analytics; the rows below it add the application-level checks that catch manipulation the host cannot see.

Application and business checks

• Independent reconciliation: reconcile transactions against a source the attacker cannot reach, such as counterparty confirmations, statements from the payment network or a separate ledger. APT38's runtime manipulation targeted exactly the reports staff used to reconcile.
• Database audit trails: log data-changing statements on sensitive tables with the database identity and client, and alert on direct changes that bypass the application. See the Database Activity Monitoring buyer's guide.
• Out-of-band verification before high-value actions: confirm destination and amount on a separate device or channel, which removes the display layer from the trust path.
• Front-end integrity: subresource integrity hashes for scripts, alerts on changes to production static assets in object storage, and object versioning so the served file can be compared after the fact. These were the controls the Bybit analysis names.
• Off-host integrity baselines: keep hashes of critical binaries, configuration and build inputs on a separate system, and compare from there.

For implementation of file baselines, see the File Integrity Monitoring Guide.

Mitigations

ATT&CK v20 maps four mitigations across the technique and its sub-techniques. The last column adds NHI Mgmt Group recommendations.

Two further controls carry most of the weight in financial cases. Dual control for high-value changes means a second person or system must approve, ideally on a different device; see Dual control and four-eyes approval for privileged and agent actions. Code signing and reproducible builds limit the SUNSPOT pattern; see the Code Signing Security Guide.

Where identity fits

Manipulation needs write access to data, messages or code, and that access is usually held by a non-human identity: the application's database account, an integration service account on a payment gateway, a CI/CD role that can publish front-end assets, or a developer session token. In the Bybit case, a hijacked developer AWS session with elevated access was enough to change production JavaScript. Scope write access to the single service that needs it, keep cloud sessions short-lived, separate the right to publish production code from everyday developer access, and alert when a service identity writes to data or assets outside its normal pattern.

How to test and roll out

1. Pick the data that matters: list the records, messages and displays where an undetected change would cause financial loss, safety risk or wrong decisions. Start with payments, trading, identity stores and build pipelines.
2. Define the independent check for each: reconciliation source, hash baseline stored off-host, signed message, or out-of-band confirmation.
3. Collect the telemetry: file auditing on data paths, database audit logging on sensitive tables, Sysmon or EDR on application hosts, object storage change logs for front-end assets.
4. Emulate in a test environment: an authorised tester changes a record directly in the database, alters a test message between two services, and replaces a static asset. Confirm each change is caught by reconciliation or integrity checks, not only by host logs.
5. Tighten write paths in stages: remove direct write access for humans and shared accounts first, then move binaries and assets to pipeline-only publishing.
6. Roll back: keep previous permission sets and pipeline configurations versioned; if a business process breaks, restore the previous set for that path only and record the exception.

Metrics

• Share of critical data stores with an independent reconciliation or integrity check.
• Number of identities, human and non-human, with direct write access to critical data outside the owning application.
• Time from an unauthorised change to its detection in emulation tests.
• Percentage of production front-end assets served with integrity hashes and change alerts.
• High-value transactions confirmed out of band, as a share of the total.

Common failure patterns

• Integrity checks that trust the host: PHASEJAM rewrote the integrity manifest on the appliance it was meant to protect.
• Reconciling against the compromised system: APT38 altered the very reports staff used to check transactions.
• Treating display as trustworthy: signers and approvers act on what the screen shows; the Bybit case shows the screen can lie.
• Developer sessions with production publish rights: one hijacked token can change what every customer is served.
• Logging access but not change: read auditing is common on sensitive tables; data-changing statements by unexpected clients often are not logged.
• Restoring without comparing: backups are used only for recovery, never as a reference to spot what changed.

Framework mapping

Practitioner checklist

• List the records, messages and displays where an undetected change would cause real harm.
• Give each one an independent integrity check that does not run on the system it protects.
• Audit data-changing statements on sensitive tables, with the identity and client.
• Restrict write access to data and binaries to the owning service and the deployment pipeline.
• Serve front-end assets with integrity hashes and alert on changes in object storage.
• Require out-of-band confirmation and dual control for high-value transactions.
• Keep immutable, versioned copies and use them to compare, not only to restore.
• Store integrity baselines and logs off the monitored hosts.

Standards and references

• MITRE ATT&CK: Data Manipulation (T1565)
• MITRE ATT&CK: Stored Data Manipulation (T1565.001)
• NIST: SP 1800-26 Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Mandiant: APT38, details on a North Korean regime-backed threat group
• CrowdStrike: SUNSPOT malware technical analysis
• Google Threat Intelligence: Ivanti Connect Secure VPN targeted in new zero-day exploitation

Related NHI Mgmt Group resources: ATT&CK Impact Tactic Guide · Data Integrity Protection Against Destructive Attacks Guide · File Integrity Monitoring Guide · Fraud and Cyber Convergence Guide · MITRE ATT&CK T1195 Supply Chain Compromise