T1565: Data Manipulation

Data manipulation targets the most fundamental assumption in any information system: that the data can be trusted. Every business decision, financial transaction, medical diagnosis, and engineering calculation depends on the integrity of the underlying data. When an adversary alters that data — changing a financial transaction amount, modifying a database record, tampering with an email in transit, or manipulating the values a process reads from memory — the consequences cascade through every system and decision that depends on that data.

T1565 is classified under the Impact tactic because its effect is integrity destruction. The CIA triad (Confidentiality, Integrity, Availability) treats these as distinct categories of harm, and while ransomware (T1486) and DDoS (T1498) attack availability, and data exfiltration attacks confidentiality, data manipulation attacks integrity — arguably the hardest of the three to detect and the most difficult to recover from. You can restore encrypted files from backups, and you can recover from a service outage, but you cannot easily determine which records in a database have been silently altered, or when the alteration occurred, or how far the corrupted data has propagated through downstream systems.

The technique requires significant reconnaissance. Unlike a ransomware deployment that can be executed within hours of initial access, effective data manipulation requires the attacker to understand the target's data structures, business processes, and transaction workflows well enough to make changes that achieve the desired outcome without triggering validation checks or anomaly alerts. This is why T1565 is most often associated with advanced threat actors who spend weeks or months inside a network before executing their manipulation operations.

How Data Manipulation Works

The attack chain follows a consistent pattern regardless of the specific target. After gaining access to the network and establishing persistence, the attacker enters a prolonged reconnaissance phase focused on understanding the data environment. They map database schemas, study transaction workflows, identify validation controls and audit mechanisms, and determine which data changes will produce the desired outcome — whether that outcome is financial theft, intelligence corruption, or operational sabotage.

The manipulation itself is designed to be invisible. The attacker makes changes that pass validation checks, that do not trigger alerts in monitoring systems, and that produce outputs consistent with what operators expect to see. In financial systems, this means creating transactions that match the format, size, and timing patterns of legitimate activity. In industrial systems, it means altering sensor readings or control parameters within ranges that operators would consider normal. The sophistication lies not in the technical act of modifying a database record or intercepting a network packet — those are straightforward — but in knowing exactly what to change and by how much to achieve the objective without detection.

Sub-Techniques

T1565.001 — Stored Data Manipulation

Stored data manipulation targets data at rest: database records, files on disk, configuration files, source code repositories, and any other persistent data store. The attacker directly modifies the stored values, and the altered data is then served to applications and users as if it were legitimate.

This sub-technique encompasses a wide range of operations. In financial environments, it includes altering transaction records, account balances, wire transfer parameters, and payment routing information. In software development environments, it includes modifying source code in build systems — the technique used by the SUNSPOT implant in the SolarWinds attack, which injected malicious code into the Orion build process while replacing source files with original versions after compilation so that manual code reviews would not discover the modification. In operational environments, it includes altering sensor data, control system parameters, or safety-critical records.

The key characteristic of stored data manipulation is permanence. Once the data on disk or in a database is altered, the change persists until it is discovered and corrected. Every application that reads the corrupted data operates on false information, and every backup taken after the manipulation preserves the corrupted state. Recovery requires identifying exactly which records were altered, determining the correct values, and propagating the corrections through every downstream system that consumed the corrupted data.

T1565.002 — Transmitted Data Manipulation

Transmitted data manipulation intercepts and alters data in transit between systems. Rather than modifying the data where it is stored, the attacker positions themselves in the data flow and changes values as they pass through. The source system sends correct data, the destination system receives altered data, and neither endpoint detects the modification.

This sub-technique is central to financial fraud operations. Banking trojans like Metamorfo, Grandoreiro, and Casbaneiro intercept browser sessions and modify transaction details in real time — changing the destination account number, the transaction amount, or both — while displaying the original values to the user. The user sees their intended transaction on screen, but the bank receives a different one. Turla's LightNeuron backdoor, deployed on Microsoft Exchange servers, demonstrates another variant: it intercepts and modifies emails in transit, allowing the attacker to alter message content, add or remove attachments, and redirect messages to different recipients — all without the sender or intended recipient knowing the message was tampered with.

In operational technology environments, transmitted data manipulation can alter commands sent to physical control systems or modify sensor readings being reported back to operators, creating a false picture of the physical process that can lead to equipment damage or safety incidents.

T1565.003 — Runtime Data Manipulation

Runtime data manipulation targets data in memory — values stored in running processes, application state, and variables that exist only during execution. The attacker modifies these values while the application is running, causing it to produce different outputs or make different decisions than it would with the original data, without changing anything on disk.

This is the most technically sophisticated sub-technique because it requires the attacker to understand the target application's internal data structures and memory layout well enough to locate and modify specific values in a running process. APT38's attacks on SWIFT banking systems used this approach: after gaining access to the banking environment and spending months studying the SWIFT transaction workflow, the attackers manipulated in-memory data during transaction processing to alter wire transfer destinations and amounts, allowing them to redirect funds to accounts they controlled. The manipulation was designed to pass the application's runtime validation checks while producing fraudulent transaction messages that the SWIFT network would process as legitimate.

Real-World Case Studies

APT38 / Lazarus — SWIFT Banking System Fraud

APT38, the financially motivated North Korean threat group, has executed the most consequential data manipulation operations in recorded history. The group's campaigns against banks connected to the SWIFT interbank messaging system have collectively attempted to steal over $1.1 billion, with confirmed losses exceeding $100 million from publicly reported incidents alone.

The operation against Bangladesh Bank in February 2016 is the defining case study for T1565. After spending months inside the bank's network studying the SWIFT transaction workflow, APT38 manipulated the bank's SWIFT-connected systems to generate 35 fraudulent transfer requests totaling $951 million to the Federal Reserve Bank of New York. The attackers also manipulated the bank's internal records and printed confirmations to conceal the fraudulent transactions from bank staff. Five of the 35 requests, totaling $101 million, were processed before the fraud was detected — $81 million of which was never recovered. Subsequent attacks targeted TP Bank in Vietnam ($1 million attempted), Far Eastern International Bank in Taiwan ($60 million stolen), Bancomext in Mexico (blocked), and Banco de Chile ($10 million stolen).

APT38's operations demonstrate every sub-technique of T1565. They manipulated stored data (altering transaction records and printed confirmations), transmitted data (modifying SWIFT messages in transit), and runtime data (altering in-memory values during transaction processing). The average dwell time before executing the theft was 155 days, with one case involving nearly two years of access. After completing the theft, the group routinely deployed destructive malware to destroy evidence and complicate forensic recovery.

By 2024-2025, the group pivoted to cryptocurrency, stealing approximately $1.34 billion across 47 incidents in 2024 and executing the $1.5 billion Bybit exchange heist in February 2025 — the largest recorded cryptocurrency theft. The underlying technique remains data manipulation: altering transaction records, wallet addresses, and authorization tokens to redirect funds.

Elephant Beetle (FIN13) — Incremental Financial Theft Over Months

Elephant Beetle, tracked by Sygnia as TG2003 and by Mandiant as FIN13, operates a patient, methodical data manipulation campaign that siphons millions of dollars from financial and commerce organizations through fraudulent transactions that mimic legitimate activity. The group targets organizations in Latin America and the Latin American operations of multinational companies, using an arsenal of over 80 custom tools and scripts.

The group's methodology is a textbook example of T1565.001 (Stored Data Manipulation). After gaining initial access through legacy Java applications on WebSphere and WebLogic servers, Elephant Beetle spends up to a month building operational capabilities, then several additional months studying the victim's financial systems and transaction workflows. Only after developing a thorough understanding of how legitimate transactions are processed do they begin injecting fraudulent transactions. The amounts are small enough to avoid triggering fraud detection thresholds, and the transactions are formatted to match the patterns of legitimate activity. When individual fraudulent transactions are discovered and blocked, the group does not leave — it goes quiet for a period then resumes operations against a different system within the same environment.

SolarWinds / SUNSPOT — Source Code Manipulation in the Build Pipeline

The SUNSPOT implant, deployed as part of the SolarWinds supply chain attack, represents T1565.001 applied to software development infrastructure. SUNSPOT monitored the Orion build server and, when a build was initiated, replaced a specific source code file with a modified version containing the SUNBURST backdoor. After compilation was complete, SUNSPOT replaced the modified file with the original, so that any manual code review or subsequent build from the same source would produce clean results. The manipulation was limited to the build output — the compiled binary contained the backdoor, but the source code repository did not.

This case demonstrates data manipulation at its most sophisticated: the attacker did not modify the authoritative data (the source code repository) but instead manipulated the data during a transformation process (compilation), ensuring that the output was corrupted while the input appeared clean. The technique evaded code reviews, static analysis of the source, and repository integrity checks because the manipulation only existed during the brief window of the build process.

Agonizing Serpens (Agrius) — Data Manipulation for Destruction

Agonizing Serpens, an Iranian-linked threat group, targeted Israeli higher education and technology organizations with campaigns that combined data manipulation with destruction. The group altered stored data in compromised systems before deploying wiper malware, ensuring that even if the organization recovered from the wiper attack, the restored data would contain the attacker's modifications. This dual-purpose approach — manipulation for corruption followed by destruction to complicate forensic reconstruction — demonstrates how T1565 can be combined with T1485 (Data Destruction) to maximize impact.

Detection Strategies

Detecting data manipulation is one of the hardest challenges in cybersecurity because the modified data, by design, looks legitimate. Detection strategies must focus on three approaches: monitoring for the access patterns that precede manipulation, implementing integrity verification that can detect unauthorized changes, and building audit trails that cannot be tampered with by an attacker who has compromised the application layer.

Key Data Sources and Indicators

Data Source	What to Monitor	Detection Value
Database audit logs	Direct SQL modifications (UPDATE, INSERT, DELETE) executed outside application context; bulk record changes; schema modifications	Legitimate applications modify data through application logic; direct database manipulation bypasses application-level controls and audit trails
File integrity monitoring	Unauthorized changes to critical files: configuration files, source code, build outputs, financial data files	Cryptographic hash baselines detect any modification to monitored files regardless of whether the modification was designed to appear legitimate
Transaction audit logs	Transactions that do not match expected patterns: unusual amounts, unusual timing, unusual destinations, transactions without corresponding user activity	Financial manipulation creates transactions that must eventually flow through auditable systems; independent audit logs that cannot be modified by the attacker are essential
Network traffic analysis	Man-in-the-middle indicators: certificate anomalies, unexpected proxy insertion, ARP spoofing, DNS redirection	Transmitted data manipulation requires the attacker to position themselves in the data flow; network monitoring can detect the positioning even if the manipulation itself is invisible
Process memory monitoring	Unexpected process injection, memory modification in critical applications, debugging interfaces active on production systems	Runtime data manipulation requires the attacker to interact with process memory; EDR and process integrity monitoring can detect the access pattern

Detection Queries

# Detect direct database modifications outside application context
# Flags SQL commands executed from unexpected sources
# (interactive sessions, admin tools, non-application accounts)

index=database sourcetype="oracle:audit" OR sourcetype="mssql:audit"
| where match(sql_command, "(?i)(UPDATE|INSERT|DELETE|ALTER)")
| where NOT match(source_program, "(?i)(app_server|web_api|batch_processor)")
| table _time, db_user, source_host, source_program, sql_command, affected_rows
| sort -_time

# Detect file integrity changes on critical systems
# Uses Sysmon or FIM agent to track modifications
# to financial data, configuration, and source code files

index=fim sourcetype="fim:event" action="modified"
| where match(file_path, "(?i)(\\\\finance\\\\|\\\\billing\\\\|\\\\src\\\\|\\\\build\\\\|config)")
| where NOT match(user, "(?i)(deploy_service|build_agent|backup_svc)")
| table _time, host, user, file_path, previous_hash, current_hash
| sort -_time

# Detect anomalous financial transactions
# Flags transactions outside normal patterns using
# statistical deviation from per-account baselines

index=transactions sourcetype="financial:ledger"
| stats avg(amount) as avg_amt, stdev(amount) as stdev_amt, count by account_id
| where count > 30
| join account_id [search index=transactions sourcetype="financial:ledger" earliest=-24h
    | fields account_id, amount, _time, dest_account, initiator]
| where amount > (avg_amt + (3 * stdev_amt)) OR amount < 0
| table _time, account_id, dest_account, amount, avg_amt, initiator
| sort -amount

Known Threat Actors

• APT38 / Lazarus / Bluenoroff (North Korea) — SWIFT banking system fraud totaling $1.1 billion in attempts; cryptocurrency theft including the $1.5 billion Bybit heist (2025); 155-day average dwell time; uses all three T1565 sub-techniques
• Elephant Beetle / FIN13 — Incremental financial theft through fraudulent transaction injection; months-long operations against financial and commerce organizations in Latin America; 80+ custom tools
• Turla (Russia) — LightNeuron backdoor on Exchange servers intercepts and modifies emails in transit (T1565.002); used for intelligence manipulation and espionage operations
• Agonizing Serpens / Agrius (Iran) — Data manipulation combined with wiper deployment against Israeli higher education and technology sectors; corrupts data before destroying recovery capability
• SUNSPOT operators (Russia, attributed to SVR) — Source code manipulation during the SolarWinds build process (T1565.001); replaced source files during compilation to inject SUNBURST backdoor while leaving repository clean
• Metamorfo / Grandoreiro / Casbaneiro (Latin American criminal groups) — Banking trojans that manipulate transmitted financial data in real time (T1565.002); intercept browser sessions to alter transaction details while displaying original values to users

Defensive Recommendations

1. Implement independent, immutable audit logging for critical data: All modifications to financial data, critical databases, and sensitive records must be logged to an audit system that is architecturally separate from the data it monitors. The audit system must use append-only storage that cannot be modified even by administrators of the primary system. This ensures that an attacker who compromises the application layer cannot erase evidence of their manipulation.
2. Deploy cryptographic integrity verification for critical files and records: Maintain hash baselines for all critical files — source code, build outputs, configuration files, and financial data files. Verify integrity on a scheduled basis and alert on any unauthorized change. For database records, implement row-level checksums or blockchain-based ledger verification that detects any modification to stored values.
3. Enforce separation of duties for financial and critical transactions: No single account should be able to create, approve, and execute a financial transaction or critical system change. Implement multi-party authorization for transactions above defined thresholds. This forces an attacker to compromise multiple accounts and systems rather than a single point of control.
4. Monitor for direct database access outside application channels: In production environments, all data modifications should flow through the application layer. Direct SQL access to production databases from interactive sessions, admin tools, or non-application service accounts is a high-priority alert. Restrict database access to application service accounts and monitor for any deviation.
5. Implement transaction anomaly detection: Build behavioral baselines for financial transactions and critical data modifications: normal amounts, normal timing, normal counterparties, normal frequency. Alert on statistical outliers. Elephant Beetle's transactions were specifically designed to stay under fraud detection thresholds — detection must therefore look at aggregate patterns (volume of small transactions, new counterparties, unusual timing clusters) rather than individual transaction values alone.
6. Secure build pipelines and source code integrity: The SolarWinds attack demonstrated that build infrastructure is a high-value target for stored data manipulation. Implement reproducible builds, verify build output against source, and monitor build servers for unauthorized process activity. Code signing with hardware-backed keys ensures that tampered build outputs are detectable by consumers of the software.
7. Implement end-to-end encryption and integrity verification for data in transit: TLS protects data in transit from external interception, but an attacker who has compromised an endpoint or intermediary system can still manipulate data as it passes through. Implement application-layer message signing and integrity verification (HMAC, digital signatures) for critical data flows so that the receiving system can independently verify that the data has not been altered.
8. Maintain offline, integrity-verified backups with extended retention: Data manipulation may not be discovered for months or years. Backup retention policies must account for this by maintaining offline, integrity-verified backups with sufficient retention to predate any potential manipulation. Test restoration procedures regularly and verify that restored data matches known-good integrity baselines.

MITRE ATT&CK Mapping

Field	Value
Technique ID	T1565
Technique Name	Data Manipulation
Tactic	Impact
Impact Type	Integrity
Platforms	Windows, Linux, macOS
Sub-Techniques	T1565.001 (Stored Data Manipulation), T1565.002 (Transmitted Data Manipulation), T1565.003 (Runtime Data Manipulation)
Data Sources	File (Creation, Modification), Network Traffic (Content, Flow), Process (OS API Execution)
Mitigations	Remote Data Storage (independent audit), Encrypt Sensitive Information, Network Segmentation, Restrict File and Directory Permissions
MITRE Reference	attack.mitre.org/techniques/T1565

Sources and References

• MITRE ATT&CK — T1565 Data Manipulation: attack.mitre.org
• FireEye / Mandiant — APT38: Un-usual Suspects (SWIFT banking fraud): cloud.google.com
• CISA, FBI, Treasury — TraderTraitor: North Korean State-Sponsored APT (AA22-108A): cisa.gov
• Sygnia — Elephant Beetle: Uncovering an Organized Financial-Theft Operation: sygnia.co
• CrowdStrike — SUNSPOT: An Implant in the Build Process (SolarWinds): crowdstrike.com
• Brandefense — APT38: From SWIFT Heists to Crypto Fortresses (2025): brandefense.io