M1043 Credential Access Protection: Credential Access Protection Mapped to Dumping Techniques

Once an attacker has local administrator rights, the credentials held in memory and on disk are usually the next thing they take, and M1043 Credential Access Protection is the ATT&CK mitigation that tries to make that step fail. MITRE ATT&CK v20 defines M1043 as measures that stop adversaries obtaining passwords, hashes, tokens or keys: restricting access to credential stores, hardening configuration against dumping, isolating secrets and monitoring for dumping activity. This guide reads the mitigation from the ATT&CK point of view: which techniques it is mapped to, what each mapping actually asks you to do, where the gaps are and how to measure coverage. It is written for detection engineers, Windows platform owners and security architects who already know the controls and want to prioritise them against the technique list.

Key takeaways

• The mapping is narrow but high value. In ATT&CK v20, M1043 mitigates 10 active techniques and sub-techniques, and the most important are T1003 OS Credential Dumping and T1003.001 LSASS Memory.
• Credential Guard is the core Windows control. It isolates NTLM hashes, Kerberos TGTs and domain credentials in a virtualisation-based environment, but Microsoft states it does not protect the SAM or the Active Directory database.
• LSA protection is a separate, complementary setting. RunAsPPL makes lsass.exe a protected process and blocks unsigned LSA plug-ins, which also addresses T1547.008 LSASS Driver.
• Half the mappings are about network devices. For T1599 and T1601, ATT&CK's guidance is simply to store local device passwords encrypted, which is easy to miss if M1043 is treated as a Windows-only mitigation.
• Cloud and workload tokens sit mostly outside M1043. Token theft, credentials in files and forged web credentials are covered by other mitigations, so a credential protection programme for non-human identities needs more than this one control.

What M1043 asks a team to implement

The ATT&CK v20 description of M1043 lists five measures. Read them as a short control set rather than a single product feature.

For the deployment detail of VBS and Credential Guard (requirements, licensing, Intune profiles, known compatibility issues) see the Credential Guard and VBS guide. This page does not repeat it.

Techniques M1043 mitigates in ATT&CK v20

The table lists every active technique that has a "mitigates" relationship from M1043 in the ATT&CK v20 Enterprise dataset, grouped by tactic, with the substance of ATT&CK's own usage text. Priority is an NHI Mgmt Group judgement based on how often the technique appears in intrusions and how much M1043 changes the outcome.

Linked technique guides: T1003 OS Credential Dumping, MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide and T1547 Boot or Logon Autostart Execution.

Windows controls by technique

Credential Guard against T1003.001 and T1547.008

Microsoft documents that Credential Guard protects NTLM password hashes, Kerberos Ticket Granting Tickets and credentials stored by applications as domain credentials, which blocks pass the hash and pass the ticket style reuse of those secrets. Starting in Windows 11 22H2 and Windows Server 2025 it is enabled by default on domain-joined systems that are not domain controllers and meet the hardware and licence requirements, and that default is without UEFI lock. Three limits matter for ATT&CK coverage:

• SAM and NTDS are out of scope: Microsoft states Credential Guard does not protect the SAM or the Active Directory database, so T1003.002 Security Account Manager and NTDS extraction need other controls.
• Explicit opt-outs persist: a device where Credential Guard was explicitly disabled before upgrading keeps that setting, so "default on" does not mean "on everywhere".
• Domain controllers are excluded: Microsoft does not recommend Credential Guard on domain controllers, which are the highest-value dumping targets. They depend on tiering, LSA protection and monitoring instead.

LSA protection (RunAsPPL) against T1003.001 and T1547.008

LSA protection runs lsass.exe as a protected process and only loads plug-ins and drivers that meet Microsoft's signing requirements. It is configured with the REG_DWORD value RunAsPPL under HKLM\SYSTEM\CurrentControlSet\Control\Lsa: 1 enables it with UEFI lock, 2 enables it without UEFI lock (Windows 11 22H2 and later). ATT&CK does not name RunAsPPL in the M1043 text, so treat it as an NHI Mgmt Group recommendation that sits naturally with this mitigation and with privileged process integrity.

Audit mode is set with AuditLevel = 8 under the Image File Execution Options key for LSASS.exe. Microsoft notes that audit mode for added LSA protection is on by default from Windows 11 22H2, and that automatic enablement applies only to new, enterprise-joined, HVCI-capable installations rather than upgrades.

Cached credentials against T1003.005

The Group Policy setting "Interactive logon: Number of previous logons to cache (in case domain controller is not available)" defaults to 10 and accepts 0 to 50. Setting it to 0 removes cached domain logons that can be cracked offline, but users then cannot sign in when no domain controller is reachable. Microsoft suggests 2 as a compromise for mobile users. ATT&CK lists reducing cached credentials in the M1043 description; T1003.005 Cached Domain Credentials itself is not one of the technique relationships, so count it as coverage you add, not coverage ATT&CK credits.

Linux and network device controls

• SELinux for Kerberos material (T1558, T1558.005): ATT&CK's guidance is to define entry points, process types and file labels so that only the intended processes can read ticket caches and keytabs. In practice this means confining the services that hold keytabs and checking that ccache files in /tmp are not readable by other domains. Pair this with short ticket lifetimes from the Kerberos Security Guide.
• Encrypted device passwords (T1599, T1601): where a router, firewall or switch stores local account passwords, use the vendor's strongest supported password storage type rather than reversible or plain-text forms. A configuration backup or a patched system image then does not reveal working credentials.
• Configuration backups as a credential store: network configuration backups held in a configuration management tool are themselves credential stores. Apply the same access restriction ATT&CK asks for on the SAM.

Where identity fits: non-human credentials

Dumped LSASS memory on a server rarely yields only human passwords. Service accounts, scheduled task accounts and application pool identities sign in interactively or as services and leave reusable material behind, and they are often privileged across many hosts. Three NHI Mgmt Group recommendations follow:

• Prefer managed identities over passwords: group managed service accounts and workload identity reduce what a dump can reuse.
• Constrain where service accounts log on: deny interactive and remote interactive logon rights so their credentials are not cached on general servers.
• Treat Kerberos keytabs and ccache files as secrets: inventory them, restrict their permissions and rotate the keys. See the Kerberos Delegation Security Guide for delegation settings that also conflict with Credential Guard.

Gaps: what M1043 does not stop

For the cloud side, see the M1026 Privileged Account Management and M1041 Encrypt Sensitive Information pages in this series.

Implementation priorities

1. Measure the current state: collect Credential Guard and VBS status (Win32_DeviceGuard WMI class or msinfo32) and WinInit event 12 across the estate, split by workstation, member server and domain controller.
2. Turn on LSA protection in audit first: deploy AuditLevel = 8, collect events 3065 and 3066 for two to four weeks, and clear incompatible security or smart card plug-ins with their vendors.
3. Enforce RunAsPPL in rings: pilot IT devices, then general workstations, then member servers, then domain controllers. Start with value 2 (no UEFI lock) so you can roll back by registry; move to value 1 only once stable.
4. Close Credential Guard opt-outs: find devices where it was explicitly disabled and decide case by case; remove legacy dependencies such as NTLMv1, Kerberos DES and unconstrained delegation that block it.
5. Reduce cached logons: set 0 on servers and fixed desktops, 1 or 2 on laptops.
6. Cover Linux and network devices: review SELinux policy for keytab-holding services and audit device configurations for reversible password storage.
7. Rollback plan: keep a documented path for each setting: registry removal for non-locked RunAsPPL, the Microsoft LSA protected process opt-out tool for UEFI-locked devices, and a Credential Guard disable policy for affected applications.

Detection and measurement

M1043 reduces success, it does not remove attempts. Monitor for:

• LSASS access: Sysmon Event ID 10 (ProcessAccess) where the target is lsass.exe and the source is not an expected security or management process. See the Sysmon Guide.
• Blocked LSA loads: CodeIntegrity events 3033 and 3063.
• Protection tampering: changes to the RunAsPPL value or to VBS and Credential Guard registry and policy settings.
• Hive access: processes reading or saving the SAM, SECURITY or SYSTEM hives outside backup windows.

Framework mapping and related countermeasures

Common failure patterns

• Assuming default on means deployed: upgraded devices, explicit opt-outs, Pro editions and devices without VBS support stay unprotected.
• Leaving domain controllers last and forgotten: Credential Guard is not recommended there, so if LSA protection and tiering are not done, the most valuable LSASS stays exposed.
• Enforcing RunAsPPL without audit: unsigned smart card or security plug-ins fail to load and the change is reversed estate wide.
• Treating M1043 as Windows only: network device password storage and Linux keytabs remain in plain or reversible form.
• Ignoring service account logon rights: privileged service credentials keep landing in LSASS on many servers, so one dump gives lateral movement.

Practitioner checklist

• Report Credential Guard, VBS and LSA protection status per device class.
• Run LSA protection in audit mode and clear events 3065 and 3066 before enforcing.
• Enforce RunAsPPL on domain controllers and tier 0 servers first.
• Remove dependencies on NTLMv1, Kerberos DES and unconstrained delegation.
• Set cached logons to 0 on servers and 1 or 2 on laptops.
• Alert on Sysmon Event ID 10 against lsass.exe and on CodeIntegrity events 3033 and 3063.
• Deny interactive logon to service accounts and move them to managed identities.
• Confine keytab and ccache access with SELinux on Linux hosts.
• Audit network device configurations for reversible password storage.

Standards and references

• MITRE ATT&CK: M1043 Credential Access Protection
• MITRE ATT&CK: T1003.001 LSASS Memory
• MITRE D3FEND: Hardware-based Process Isolation
• Microsoft Learn: Credential Guard overview
• Microsoft Learn: Configure added LSA protection
• Microsoft Learn: Interactive logon: Number of previous logons to cache

Related NHI Mgmt Group resources: Credential Guard and VBS · T1003 OS Credential Dumping · Kerberos Security Guide · M1044 Restrict Library Loading · M1045 Code Signing