M1041 Encrypt Sensitive Information: ATT&CK Guide

Encryption is on almost every compliance checklist, yet attackers still read sniffed traffic, crack RC4 Kerberos tickets and download "encrypted" cloud data, because the encryption was weak, missing on one hop, or decrypted for whoever held a workload credential. MITRE ATT&CK mitigation M1041, Encrypt Sensitive Information, is the control of protecting data at rest, in transit and in processing with strong cryptography. This guide reads M1041 from the ATT&CK v20 data: the 33 technique relationships it mitigates, which encryption setting answers each, why key custody decides whether the control works, and how to measure it. It is for detection engineers, security architects and identity teams who need to turn "we encrypt" into evidence against specific ATT&CK techniques.

Key takeaways

M1041 is mapped to 33 techniques and sub-techniques in ATT&CK v20. They cluster in Collection, Credential Access and network interception: email collection, cloud storage, SNMP, Kerberos ticket theft, sniffing and adversary-in-the-middle.
Several rows are about cipher strength, not presence. ATT&CK's Kerberos guidance is to use AES rather than RC4, and its SNMP guidance is SNMPv3 at authPriv, not "turn on encryption".
Encryption at rest only helps against principals who cannot decrypt. If a workload role holds both read access and the decrypt permission, transparent encryption gives that role, and anyone who steals its credentials, plaintext.
Keys are non-human identities. KMS keys, private keys and certificates need owners, scoped access policies, hardware protection where possible and rotation, exactly like service accounts.
Measure coverage per technique. Count RC4 ticket requests, non-authPriv SNMP devices, plaintext protocols on the wire and keys without separated custody, rather than counting encrypted volumes.

What ATT&CK means by Encrypt Sensitive Information

The ATT&CK v20 description of M1041 is to protect sensitive information at rest, in transit and during processing using strong encryption, preserving confidentiality and integrity. It names five implementation areas: data at rest (full-disk or file-level encryption such as BitLocker or FileVault), data in transit (TLS, HTTPS, STARTTLS for mail), backups (encrypted in storage and transfer), application secrets (credentials and API keys held in encrypted vaults) and databases (Transparent Data Encryption or column-level encryption).

The engineering of each layer is covered elsewhere: see the Database and Storage Encryption Guide, the Disk Encryption Guide: BitLocker and FileVault and the Encryption Guide. This page stays on the ATT&CK question: which adversary behaviours does each layer actually defeat, and which does it not.

Techniques M1041 mitigates, by tactic

The table covers all 33 non-revoked relationships in the ATT&CK v20 Enterprise data, grouped where ATT&CK uses the same usage text for a parent and its sub-techniques.

Tactic	Technique (ATT&CK v20)	How M1041 helps, per ATT&CK
Collection	T1114 Email Collection, .001 Local, .002 Remote, .003 Forwarding Rule	Public key email encryption means the adversary also needs the recipient's private certificate and key.
Collection	T1119 Automated Collection	Encryption and off-system storage may help, but may not stop a long-running intrusion.
Collection	T1213, T1213.006 Databases	Encrypt data at rest in databases.
Collection	T1530 Data from Cloud Storage	Encrypt data at rest in cloud storage; rotate managed keys.
Collection	T1602, T1602.001 SNMP (MIB Dump), T1602.002 Network Device Configuration Dump	Configure SNMPv3 at the highest security level, authPriv.
Credential Access	T1003, T1003.003 NTDS	Secure domain controller backups.
Credential Access	T1552, T1552.004 Private Keys	Store keys on separate cryptographic hardware, such as a TPM on Windows.
Credential Access	T1558, .002 Silver Ticket, .003 Kerberoasting, .004 AS-REP Roasting	Enable AES Kerberos encryption rather than RC4.
Credential Access	T1649 Steal or Forge Authentication Certificates	Secure certificates and private keys; consider TPM or hardware protection.
Credential Access, Collection	T1557, T1557.002 ARP Cache Poisoning	Encrypt wired and wireless traffic; protect credential-bearing web traffic with TLS.
Credential Access, Discovery	T1040 Network Sniffing	Encrypt all wired and wireless traffic; use strong authentication protocols such as Kerberos.
Initial Access	T1669 Wi-Fi Networks	Encrypt wired and wireless traffic appropriately.
Initial Access, Command and Control	T1659 Content Injection	Encrypt online traffic, for example through trusted VPNs.
Exfiltration	T1020.001 Traffic Duplication	Encrypt traffic so mirrored copies are useless.
Lateral Movement	T1550.001 Application Access Token	Enforce file encryption on sensitive email content reachable with a stolen token.
Stealth, Defense Impairment	T1070, T1685.005 Clear Windows Event Logs, T1685.006 Clear Linux or Mac System Logs	Encrypt or obfuscate event files locally and in transit so adversaries get no feedback.
Impact	T1565, T1565.001 Stored, T1565.002 Transmitted Data Manipulation	Encrypt important data and data flows to reduce tailored modification.

From ATT&CK rows to concrete settings

The table below turns the highest-value rows into settings a team can verify. Vendor details are from the vendors' own documentation, checked November 2026.

Technique	Setting to verify	Evidence
T1558.003, T1558.004 (roasting)	Accounts use AES only: `msDS-SupportedEncryptionTypes` set for service accounts, KDC `DefaultDomainSupportedEncTypes` 0x18 (AES128 and AES256 only), GPO "Network security: Configure encryption types allowed for Kerberos"	Events 4768 and 4769 with Ticket Encryption Type 0x17 (RC4-HMAC) trending to zero
T1602.x (SNMP)	SNMPv3 only, authPriv, SNMP views limiting OIDs, ACLs, management network	Device config audit: no v1/v2c community strings
T1040, T1557, T1020.001	TLS 1.2 minimum, TLS 1.3 supported (NIST SP 800-52 Rev 2 required TLS 1.3 support in government systems by 1 January 2024); mTLS between services; 802.1X with EAP-TLS for Wi-Fi	Network sensor share of plaintext sessions (HTTP, LDAP simple bind, Telnet, FTP)
T1530, T1213.006	Customer-managed keys with key policies separate from data access, plus field or column encryption for the most sensitive values	Number of principals holding both read and decrypt
T1552.004, T1649	Private keys non-exportable, in TPM, HSM or cloud KMS	Count of private keys found on disk by secrets scanning
T1003.003	Domain controller backups encrypted, held off-domain with separate access	Backup job configuration and access list review
T1114.x, T1550.001	S/MIME or message encryption for sensitive mail classes	Share of labelled sensitive mail sent encrypted

Two status notes matter here. Microsoft's RC4 guidance states that, since the November 2022 updates, accounts without an explicit encryption type default to AES-SHA1, that Windows Server 2025 domain controllers do not issue RC4 ticket-granting tickets, and that Microsoft planned to stop assuming RC4 as a default supported type on domain controllers by the end of the second quarter of 2026 (as stated on the page in November 2026). See Kerberos RC4 Deprecation and the Kerberoasting and AS-REP Roasting Defence Guide. For SNMP, the NSA's July 2026 re-issue of its SNMP abuse guidance says SNMPv3 should be the only version used, at authPriv where the device supports it, and adds that SNMPv3 alone is not enough without ACLs, views and a separate management network. See the SNMP Security Guide.

Key custody is an identity problem

Transparent encryption at rest is now the default in most clouds. AWS states that since 5 January 2023 all new S3 object uploads are encrypted with SSE-S3 automatically. That closes the stolen-disk scenario, but not T1530: any principal allowed to call GetObject receives plaintext. With SSE-KMS, AWS documents that downloading an object needs kms:Decrypt on the key, which creates a second, separately grantable permission. M1041 only bites against a stolen workload credential when that second permission is withheld from identities that do not need plaintext.

The Capital One breach illustrates the shape: a firewall's role credentials, obtained through the instance metadata service, could list and read many buckets of customer data. The lesson NHI Mgmt Group draws is to encrypt sensitive fields with keys that ordinary workload roles cannot use. NHI Mgmt Group recommendations for key custody:

Separate key administrators from key users: the people and pipelines that manage key policy should not be the workloads that decrypt data.
Scope decrypt to named workload identities: grant decrypt per role, with encryption context or conditions, not to whole accounts or projects.
Prefer hardware-backed, non-exportable keys: ATT&CK's own T1552.004 and T1649 guidance points to TPMs and hardware protection. See the HSM Deployment and Operations Guide.
Treat application secrets as encrypted data plus an identity: a vault encrypts secrets, but the machine identity that unlocks the vault is the real control. See the Secrets Management Guide.
Log every decrypt: key usage logs are among the best data exfiltration signals available, because legitimate decrypt patterns are stable.

The Cryptographic Key Management Guide covers lifecycle detail.

How to implement M1041, step by step

Inventory by technique: list where each M1041 row applies in your estate: Kerberos service accounts, SNMP devices, plaintext protocols, cloud buckets and databases holding sensitive data, private key locations.
Fix cipher strength first: roasting and SNMP rows are often cheaper to close than at-rest gaps. Audit RC4 usage from 4768/4769 events, set AES on service accounts, then restrict the domain default; move SNMP to v3 authPriv.
Close plaintext on the wire: enforce TLS on LDAP, SMTP relays and internal web apps, and mTLS for service to service traffic where workloads support it. See the mTLS Guide.
Separate custody for sensitive data: move the most sensitive stores to customer-managed keys whose decrypt permission is held by fewer identities than read access.
Move private keys to hardware: TPM-backed or HSM-backed, non-exportable where the platform supports it.
Test before enforcement: RC4 removal and TLS minimums break legacy clients. Use audit events and a pilot group, and keep a rollback (re-enable the old setting for the named exception only, with an expiry).
Measure and hold: add the metrics below to the control dashboard so regressions are seen.

Choosing where to start

Small organisations: start with full-disk encryption on laptops, AES-only Kerberos and TLS everywhere; customer-managed keys can wait until there is a store worth separating.
Large or regulated estates: prioritise key custody separation for crown-jewel data and the RC4 retirement, which affects every service account.
Platform-managed or customer-managed keys: platform-managed keys defend against media theft; customer-managed keys add a policy layer that can stop a compromised workload. Choose customer-managed where the threat is credential theft, not lost hardware.
Field-level or volume-level: field encryption defeats database dumps by an over-privileged service account but costs application changes; reserve it for the highest-value fields.

What M1041 does not stop

Access through the authorised path: an attacker using a valid identity that is allowed to decrypt sees plaintext. That is T1078 Valid Accounts, and the answer is identity scoping.
Data in use on a compromised host: memory scraping, screen capture and keylogging read data after decryption.
Encryption turned against you: ransomware (T1486) uses encryption as the attack; at-rest encryption does nothing against it.
Long intrusions: ATT&CK itself notes that encryption may not stop collection if an intrusion persists over time.
Integrity on its own: confidentiality encryption without authentication does not prove data was not modified; use authenticated modes. See the Authenticated Encryption and Block Cipher Modes Guide.

Common failure patterns

Default encryption counted as protection: transparent at-rest encryption reported as a control against cloud data theft, while every reader role can decrypt.
RC4 left on one service account: a single legacy SPN with RC4-only msDS-SupportedEncryptionTypes keeps roasting viable.
SNMPv3 at authNoPriv or with v2c still enabled: configuration dumps (T1602.002) remain readable on the wire.
Private keys in files: PFX and PEM files on build servers and shares, which T1552.004 harvests directly.
Unencrypted DC backups: NTDS copies in backup storage that a backup operator account can read.
TLS terminated early: encryption at the load balancer, plaintext from there to the application tier, where a sniffer on the internal segment sees everything.

Detection and measurement

Metric	Source	Target
RC4 Kerberos tickets per day	Events 4768/4769, Ticket Encryption Type 0x17	Zero, with named exceptions only
SNMP devices not at v3 authPriv	Network configuration audit	Zero, or upgrade plan per device
Plaintext protocol sessions on internal segments	Network sensor protocol counts	Falling to agreed exceptions
Identities with both read and decrypt on sensitive stores	Cloud IAM and key policy analysis	Only the workloads that need plaintext
Private keys found on disk or in repositories	Secrets scanning	Zero new findings
Anomalous decrypt volume	KMS or HSM usage logs	Every spike investigated

Framework mapping

Framework	Reference	Relevance to M1041
NIST SP 800-53 Rev 5	SC-8 and SC-8(1) Transmission Confidentiality and Integrity; SC-28 and SC-28(1) Protection of Information at Rest; SC-12 Cryptographic Key Establishment and Management; SC-13 Cryptographic Protection	Transit, rest and key management
NIST CSF 2.0	PR.DS-01; PR.DS-02	Data at rest and in transit protected
CIS Controls v8.1	3.6 Encrypt Data on End-User Devices; 3.10 Encrypt Sensitive Data in Transit; 3.11 Encrypt Sensitive Data at Rest	Encryption safeguards
ISO/IEC 27001:2022	Annex A 8.24 Use of cryptography	Cryptographic policy and key management
MITRE D3FEND	D3-DENCR Disk Encryption; D3-ET Encrypted Tunnels; D3-FE File Encryption; D3-MENCR Message Encryption	Related techniques in the D3FEND ontology

Related ATT&CK mitigations: M1043 Credential Access Protection, M1026 Privileged Account Management and M1040 Behavior Prevention on Endpoint (see M1040 Behavior Prevention on Endpoint).

Practitioner checklist

Map each of the 33 M1041 relationships to an owner and a verifiable setting.
Audit RC4 use from 4768/4769 events, set AES on every service account, then restrict the domain default.
Move all SNMP to v3 authPriv with views, ACLs and a management network.
Enforce TLS 1.2 minimum internally and mTLS between services that support it.
Put the most sensitive stores on customer-managed keys and cut the set of identities that can decrypt.
Move private keys to TPM, HSM or KMS and scan for key files on disk.
Encrypt domain controller backups and restrict who can read them.
Alert on unusual decrypt volume from key usage logs.

M1041 Encrypt Sensitive Information: Encrypting Sensitive Information as an ATT&CK Mitigation