MITRE ATT&CK T1556 Modify Authentication Process Guide: Detecting Tampered Authentication

When an attacker changes how authentication works, every later login looks legitimate, because the system that is supposed to say no has been taught to say yes. MITRE ATT&CK tracks this as T1556 Modify Authentication Process, a technique that sits in three tactics in ATT&CK v20: Defense Impairment (TA0112), Persistence (TA0003) and Credential Access (TA0006). It covers tampering with the code and policy that validate credentials, from LSASS and PAM to cloud MFA and conditional access. This guide covers all nine v20 sub-techniques, their mapped detection strategies and log sources, and the hardening that makes changes hard to make and quick to spot. It is written for detection engineers, identity administrators and incident responders, and covers defence only.

Key takeaways

• The target is the gatekeeper, not the account. T1556 modifies the authentication process itself, so it survives password resets and often grants access to every account the process serves.
• Nine sub-techniques, two families. Some patch code in the authentication path (DCs, password filters, PAM, network images, network providers); others only change configuration (reversible encryption, MFA, hybrid identity, conditional access).
• Configuration changes are the cheaper attack and the easier detection. Every cloud MFA or conditional access change is audited; the gap is that nobody alerts on it.
• Hybrid identity servers are Tier 0. PTA agents, AD FS and sync servers authenticate on behalf of the cloud tenant, so a compromise there equals a compromise of the identity provider.
• Prevention is integrity plus least privilege. LSA protection, controlled DLL registration, file integrity monitoring on authentication modules, signed images on network devices and very few people who can edit authentication policy.

How the attack works

ATT&CK describes the authentication process as the mechanisms that gather, store and validate credentials: LSASS and the Security Accounts Manager on Windows, pluggable authentication modules on Linux and macOS, authorisation plug-ins on macOS, and the policy engines of identity providers. An adversary with administrative access modifies one of these to reveal credentials as they pass through, or to accept credentials that should be rejected. In the cloud the same outcome comes from weakening policy, such as an MFA exclusion or a new trusted IP range.

T1556 is a post-compromise technique. It needs local administrator, root, domain admin or a privileged directory role first, which is why it often follows MITRE ATT&CK T1078 Valid Accounts and sits alongside MITRE ATT&CK T1098 Account Manipulation. The difference is scope: T1098 changes one identity, T1556 changes the rules that apply to many identities.

Where it shows up

• Domain controllers: the highest-value Windows target for .001, .002 and .008, because one implant affects every domain logon or password change. See the Golden Ticket, Silver Ticket and DCSync Guide for the related Kerberos persistence techniques that responders should check at the same time.
• Linux bastions and network infrastructure: PAM on jump hosts that many administrators and automation accounts pass through, and routers, firewalls and VPN concentrators whose image integrity is rarely checked after deployment.
• Hybrid identity servers: Microsoft Entra pass-through authentication agents, AD FS farms and synchronisation servers. Microsoft's PTA security deep dive says to treat every agent server as Tier 0, hardened like a domain controller. See the Federation and Trust Relationships Guide.
• Cloud identity providers: Entra ID, Okta and similar platforms, where MFA and conditional access are editable by any sufficiently privileged admin. See the Conditional Access Guide.
• Cloud IAM: AWS and Google Cloud policy conditions on source IP, MFA or region, a quieter target than a new role.

Impact

The impact is broad persistence that ordinary remediation does not remove, and, because T1556 is also mapped to Defense Impairment, weaker controls: MFA prompts stop appearing and sign-in logs show successful, compliant authentications.

• Credential exposure at scale: filter and network provider DLLs on a DC collect plaintext passwords for privileged and service accounts; resets just feed them new ones.
• Silent bypass: a patched DC or network image accepts a master password while normal passwords keep working.
• Cloud-wide reach: a tampered PTA agent or AD FS server approves sign-ins for every synchronised user in the tenant.
• Lock-out of the real owner: in the Storm-2949 Azure attack, after a social-engineered reset the attacker removed the user's existing phone, email and Authenticator methods and enrolled its own Authenticator, which both kept access and locked the user out.

Detection

ATT&CK v20 maps one detection strategy to each sub-technique (DET0104 for the parent). The pattern is the same: detect the change, then correlate it with authentication that should not have succeeded. Many signals need auditing that is off by default. The ITDR Guide covers how these detections fit into a wider identity threat programme.

Detection rules worth building first

1. Any change to authentication policy outside a change window: conditional access, authentication method policy, federation settings and domain authentication type. Volume is low, so alert on every event and require a ticket reference.
2. Method swap after reset: a password reset or temporary access pass followed within an hour by deletion of existing methods and registration of a new one, especially for administrators.
3. Exclusion growth: any account added to an MFA or block policy exclusion.
4. New code in the authentication path: new Notification Packages or NetworkProvider\Order entries, or an unsigned module loaded into LSASS, the PTA agent or AD FS; on Linux, PAM writes not explained by a package update.
5. Success without the expected step: sign-ins that skipped MFA for accounts in an MFA-required scope.

Metrics that show coverage is working

• Policy change attribution rate: percentage of conditional access, MFA and federation changes in the last 30 days matched to an approved change. Target 100 percent.
• Tier 0 integrity coverage: percentage of DCs, AD FS, PTA and sync servers with registry auditing on the authentication keys, Sysmon module load logging and LSA protection confirmed.
• MFA enforcement gap: number of successful interactive sign-ins without MFA for accounts in an MFA-required scope, trending to zero.
• Exclusion count: total accounts excluded from MFA or block policies, reviewed monthly and trending down.
• Time to detect a test change: minutes from a scheduled benign test exclusion to an alert.

Prevention and hardening

Windows hosts and domain controllers

• LSA protection (M1025): set RunAsPPL under HKLM\SYSTEM\CurrentControlSet\Control\Lsa to 1 (with UEFI lock) or 2 (without), or use the policy "Configures LSASS to run as a protected process" on Windows 11 22H2 and later. Run audit mode first (AuditLevel = 8 under the LSASS.exe Image File Execution Options key) and review CodeIntegrity events 3065 and 3066 to find plug-ins that would fail. Confirm with System event 12 from WinInit. On Windows 11 22H2 and later it is on by default for new, enterprise-joined installs on HVCI-capable devices.
• Password filter control (M1028): baseline the Notification Packages value on every DC and member server; a legitimate filter (for example a password-strength product) should be a documented exception, with its DLL in System32 and its hash recorded.
• Network provider control (M1024, M1028): restrict write access to Control\NetworkProvider\Order, and on Windows 11 22H2 and later leave the policy "Configure the transmission of the user's password in the content of MPR notifications sent by winlogon" disabled or not configured, so winlogon sends empty password fields to network providers.
• Reversible encryption (M1027): keep "Store passwords using reversible encryption" disabled in the default domain policy and every fine-grained password policy, and report any account with the flag set.

Linux, macOS and network devices

• PAM integrity (M1026, M1022): manage /etc/pam.d/ through configuration management, verify PAM packages against the package database, run file integrity monitoring on the modules, and restrict root with SELinux or AppArmor as ATT&CK suggests. On macOS restrict write access to /Library/Security/SecurityAgentPlugins.
• Network device images (M1026, M1032): compare image hashes with the vendor's published SHA-512 values, use signed images and secure boot where supported, centralise authentication through TACACS+ or RADIUS with command accounting, and watch boot variables and unexpected reloads, as Cisco's integrity assurance guidance recommends.

Identity providers and hybrid identity

• Few policy editors (M1018): limit who can edit conditional access and authentication method policies to a small, named group using just-in-time elevation. See the Active Directory and Entra ID Hardening Guide.
• Phishing-resistant, verified recovery (M1032): require phishing-resistant MFA for administrators and a verified process for method resets, so a single approval cannot replace all factors. See the Phishing-Resistant MFA Guide and the MFA Fatigue and Bypass Guide.
• Fail closed: ATT&CK recommends MFA that blocks rather than allows when the MFA service is unreachable.
• Cloud-only administrators: Microsoft advises cloud-only accounts for privileged cloud roles, no cloud privileges for synchronised accounts, and Tier 0 monitoring of hybrid components.
• Hybrid server review (M1047): remove unknown PTA agents and check that AD FS and Global Assembly Cache DLLs are Microsoft-signed.

Choosing where to start

Phased rollout

1. Collect and baseline: enable the telemetry above, then record current password filters, network providers, PAM hashes, PTA agents, policies and exclusions.
2. Audit mode: run LSA protection in audit mode and alerts in report-only for two to four weeks.
3. Enforce on a pilot ring: enable LSA protection on a few DCs and servers, with a documented rollback (set the policy to Disabled; if UEFI lock was used, Microsoft's opt-out tool is required).
4. Restrict editors: move authentication policy rights to just-in-time roles and tie changes to tickets.
5. Test: make scheduled benign test changes and measure time to alert.

Lessons from incidents

• Method changes after a reset are a high-signal event: the Storm-2949 Azure attack shows a reset followed by removal of every existing method and enrolment of an attacker Authenticator, then the same pattern on three more accounts.
• Exclusions accumulate: accounts excluded "temporarily" from MFA look exactly like a malicious exclusion unless each is documented.
• Remediation that ignores the process: mass password resets while a password filter or network provider DLL is still registered hand the attacker the new passwords. See the Identity Recovery Guide.

Framework mapping

Practitioner checklist

• Inventory every component in your authentication path: DCs, PAM hosts, network devices, PTA agents, AD FS, sync servers and IdP policies.
• Enable LSA protection, starting in audit mode, and confirm System event 12 on DCs.
• Baseline and alert on Lsa\Notification Packages and NetworkProvider\Order registry values.
• Put PAM under file integrity monitoring and verify network device images against vendor hashes.
• Alert on every conditional access, authentication method policy and federation setting change, and require a ticket.
• Alert on method deletion plus new registration after a reset, with priority for administrators.
• Limit authentication policy editing to a small just-in-time group with phishing-resistant MFA.
• Review MFA and conditional access exclusions monthly and remove undocumented ones.
• Check the authentication path for implants before mass password resets.

Standards and references

• MITRE ATT&CK: Modify Authentication Process (T1556)
• MITRE ATT&CK: Multi-Factor Authentication (T1556.006)
• MITRE ATT&CK: Hybrid Identity (T1556.007)
• Microsoft Learn: Configure added LSA protection
• Microsoft Learn: Installing and registering a password filter DLL
• Microsoft Learn: Microsoft Entra pass-through authentication security deep dive
• Microsoft Learn: Microsoft Entra audit log activity reference
• Cisco: Cisco IOS Software Integrity Assurance

Related NHI Mgmt Group resources: ITDR Guide · Conditional Access Guide · MITRE ATT&CK T1606 Forge Web Credentials Guide · MITRE ATT&CK T1484 Domain or Tenant Policy Modification Guide · MITRE ATT&CK Guide for Defenders