M1029 Remote Data Storage: Off-Host Logs and Data That Survive Attackers

An attacker with administrator rights on a host can delete or edit anything stored on that host, including the logs that would reveal them and the backups that would let you recover. MITRE ATT&CK M1029 Remote Data Storage is the mitigation that answers this: move security logs, command history, mail events and critical data to an off-host store the attacker cannot reach with the same credentials. This guide looks at M1029 from the ATT&CK point of view: the 11 techniques ATT&CK v20 maps it to, how to implement it so the remote copy really is out of reach, what it does not stop, and how to measure it. It is written for SOC leads, detection engineers and platform teams who own log pipelines and backup design.

Key takeaways

• Speed of forwarding is the control. ATT&CK's own usage text says to "minimize time delay on event reporting"; an event that sits on the host for an hour can be cleared before it leaves.
• Remote is not the same as protected. A log bucket or backup vault the compromised identity can write to is just another target. Separate the credentials, then add write-once retention.
• Most coverage sits in Stealth and Defense Impairment. Seven of the 11 mapped techniques are log clearing and indicator removal (T1070 family, T1685.005, T1685.006); the rest are data manipulation, collection and signing-key placement.
• Immutability must be locked to matter. AWS S3 Object Lock compliance mode, Azure Backup immutable vault in the locked state and Google Cloud Bucket Lock are irreversible by design; unlocked modes can be switched off by a sufficiently privileged attacker.
• Measure gaps, not volume. Track forwarding latency, hosts silent for longer than expected, and the share of critical log sources landing in a store with independent credentials.

What M1029 is

ATT&CK v20 describes Remote Data Storage as "moving critical data, such as security logs and sensitive files, to secure, off-host locations to minimize unauthorized access, tampering, or destruction by adversaries." The mitigation text lists five implementation areas: centralised log management, remote file storage with encryption and access control, forwarding of IDS and IPS logs, immutable backup configurations (it names AWS S3 Object Lock as an example), and encryption at rest and in transit (AES-256 and TLS 1.2 or later).

The underlying idea is a trust boundary. Everything on a compromised host is under the attacker's control, so evidence and recovery data have value only once they sit somewhere that a different set of credentials governs. D3FEND lists M1029 in its ontology but notes that "IT disaster recovery plans are outside the current scope of D3FEND", so there is no direct D3FEND countermeasure mapping for this mitigation.

M1029 overlaps two neighbouring mitigations. M1053 Data Backup covers backup process and restore testing; M1029 covers where data lives and who can touch it. M1047 Audit covers what to log; M1029 covers getting it off the host. For log pipeline design and retention periods see the Log Management and Retention Guide, and for backup architecture the Backup Security and Immutable Backup Guide; this page does not repeat them.

Techniques ATT&CK says it mitigates

ATT&CK v20 maps M1029 to 11 current techniques and sub-techniques. The table groups them by tactic and summarises ATT&CK's own usage text for each.

The T1072 entry is easy to miss and matters for non-human identities: the signing key is a machine credential, and storing it on the deployment server means one compromise gives the attacker both the distribution channel and the trust anchor. Keep signing keys in an HSM or a separate signing service with its own access path.

Implementing it so the copy is really out of reach

The following order reflects what removes the most attacker options first. Each step is an NHI Mgmt Group recommendation built on the ATT&CK text and the vendor documentation cited.

1. Inventory log sources against the mapped techniques. For each technique in the table, name the log that records it (Windows Security and System channels, Linux auditd and journald, shell history, mail audit logs, cloud control plane logs) and check whether it leaves the host today.
2. Forward Windows events with a push model. Microsoft recommends source-initiated Windows Event Forwarding for simplicity and scale: clients are configured by Group Policy and forward to a Windows Event Collector over WinRM, authenticated with Kerberos in a domain. Use Microsoft's baseline subscription for all devices (it includes log-clearing events 1102 and 104, service installs 7045 and 4697, and scheduled task changes) and a targeted subscription for suspect hosts. Set the delivery mode to Minimize latency for subscriptions that carry clearing and tampering events.
3. Forward Unix and network device logs over authenticated TLS. RFC 5425 defines syslog over TLS on TCP port 6514 and recommends mutual certificate authentication as the default policy. Plain UDP syslog on port 514 is unauthenticated and lossy; do not rely on it for evidence.
4. Put the collector behind a different trust boundary. The log platform, its storage and its administrators should not share credentials with the estate it watches. A SIEM administered from domain admin accounts is lost along with the domain.
5. Add write-once retention at the storage layer. Use the cloud provider's immutability feature in its strict mode for the log archive and backup copies (details below), with retention at least as long as your investigation and regulatory windows.
6. Prove integrity, not just presence. Where the platform offers it, turn on signed integrity checks. AWS CloudTrail log file integrity validation produces hourly digest files using SHA-256 hashing and SHA-256 with RSA signing, chained to the previous digest, so a modified or deleted log file is detectable.
7. Pilot, then expand. Start with domain controllers, identity providers, jump hosts and backup servers. Watch collector load (Microsoft plans for about 3,000 events per second on average per Windows Event Collector on commodity hardware) before adding all endpoints.

Rollback: forwarding changes are reversible by Group Policy or configuration management. Locked immutability is not reversible, so test retention periods in governance or unlocked mode first and lock only once the period is agreed.

Cloud immutability settings

Platforms are listed alphabetically. Each row describes the provider's own feature and its documented behaviour.

Two details trip teams up. S3 Object Lock protects specific object versions: a simple delete adds a delete marker while the protected version stays intact, so restore processes must know how to read prior versions. And Azure notes that operational backups for blobs, files and disks are not covered by vault immutability, so check which copies the setting actually protects.

Where identity fits

M1029 only works if the identities that can write, delete or change retention on the remote store are different from the identities an attacker gains on the source systems. In practice the failures are non-human: a log shipper agent with delete rights on the archive bucket, a backup service account that is also a domain admin, a CI pipeline key with s3:PutObject on everything. Scope forwarding identities to append-only actions, keep retention administration with a small, separately authenticated group, and keep these credentials out of the systems being protected. The Codefinger S3 ransomware campaign in January 2025 shows the pattern: leaked AWS keys with read and write object permissions were used to re-encrypt S3 objects with customer-provided keys and schedule them for deletion, and recovery depended on independent backups and versioning that the stolen keys could not reach. See the Secrets Management Guide for managing these machine credentials.

What M1029 does not stop

• Events that never get generated. If audit policy is weak or logging is disabled before the attack, there is nothing to forward. That is the job of M1047 Audit and of detecting logging changes (Defense Impairment techniques such as T1685 Disable or Modify Tools).
• The window before forwarding. Batching or a collector outage leaves events on the host. ATT&CK's guidance to minimise delay exists because this window is exploitable.
• Attacks on the central store itself. If the attacker obtains the log platform's or backup service's administrative credentials, remote storage becomes a single, richer target.
• Data theft. ATT&CK is explicit that off-system storage may not stop collection by a persistent intruder. Exfiltration needs data loss prevention and access control, not just relocation.
• Encryption of the live copy. Ransomware still encrypts production data. M1029 changes whether you can investigate and restore, not whether impact happens. See the MITRE ATT&CK T1486 Data Encrypted for Impact guide.

Detection and measurement

Remote storage also creates detection opportunities: the clearing action is itself recorded and forwarded before the local log is gone. Alert on Windows event 1102 (Security log cleared) and 104 (other logs cleared), on auditd or journald service stops, on history file truncation, and on changes to forwarding configuration or Windows Event Forwarding subscriptions. On the storage side, alert on retention or lock configuration changes, bulk overwrites and new lifecycle rules.

Testing is straightforward and safe: clear a test machine's event log in a lab and confirm the 1102 event and the prior events are in the central store; try to delete a locked test object with an administrative identity and confirm the refusal.

Common failure patterns

• The SIEM shares the domain. Collectors and storage administered with the same directory accounts as the estate fall with it.
• Immutability left in the flexible mode. Governance mode or an unlocked vault is useful for testing, but a privileged attacker can bypass or disable it.
• Agents with delete rights. Shipping identities that can delete or overwrite what they wrote turn every endpoint into a path to the archive.
• Retention shorter than dwell time. If the archive keeps 30 days and the intrusion started 60 days ago, the evidence is gone legitimately.
• Backups reachable with production keys. As the Codefinger campaign showed, keys that can write production data can often damage the copies too, unless versioning and separate backups sit outside their reach.
• Nobody watches for silence. A host that stops forwarding looks identical to a quiet host unless heartbeat gaps alert.

Framework mapping

Related mitigations

• M1047 Audit: generates the events M1029 protects.
• M1053 Data Backup: the backup process and restore testing behind the remote copies.
• M1041 Encrypt Sensitive Information: protects stored and forwarded data in transit and at rest.
• M1030 Network Segmentation: places collectors and backup stores in a zone the production network cannot freely reach.

Practitioner checklist

• Map each of the 11 techniques in the table to a log source and confirm that source leaves the host.
• Deploy source-initiated Windows Event Forwarding with a baseline subscription on every Windows host.
• Replace UDP syslog with syslog over TLS (TCP 6514) and mutual certificate authentication for Unix and network devices.
• Administer the log platform and backup stores with identities that do not exist in the production directory.
• Restrict shipping and backup service identities to append-only actions; remove delete and retention rights.
• Enable the strict immutability mode for evidence and backup stores after testing retention in the flexible mode.
• Turn on log integrity validation where offered and run it on a schedule.
• Alert on log clearing, forwarding configuration changes, retention changes and silent sources.
• Keep code signing keys off deployment servers, in an HSM or separate signing service.
• Restore from the immutable copy at least quarterly and record the time taken.

Standards and references

• MITRE ATT&CK: M1029 Remote Data Storage
• MITRE ATT&CK: T1070 Indicator Removal
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• IETF: RFC 5425 Transport Layer Security (TLS) Transport Mapping for Syslog
• Microsoft Learn: Use Windows Event Forwarding to help with intrusion detection
• AWS: Locking objects with Object Lock
• Google Cloud: Retention policies and Bucket Lock
• Microsoft Learn: Immutable vault for Azure Backup

Related NHI Mgmt Group resources: Log Management and Retention Guide · Backup Security and Immutable Backup Guide · T1070 Indicator Removal Defensive Guide · CIS Control 8 Audit Log Management Guide