AN0546: Analytic 0546
Detects PAM module modifications or removal of MFA hooks in /etc/pam.d/ configurations, correlated with successful authentications lacking MFA prompts.
Analyst context for executives and security teams
This analytic matters because it focuses on a high-value identity control failure on Linux: changes to PAM authentication configuration that may remove or weaken MFA enforcement, especially when followed by successful logins without MFA prompts. For leaders, the practical issue is not just file integrity; it is whether critical Linux systems can still prove that privileged and remote access is being gated by expected authentication controls.
Executive priority
Prioritize this as an identity and operational resilience validation item for Linux environments that rely on PAM and MFA. Security leaders should ask whether changes to /etc/pam.d/ are authorized, monitored, and reviewable, and whether authentication records can demonstrate MFA enforcement during audits or incident response. The budget and control decision is whether Linux authentication control integrity is continuously evidenced, not assumed.
Technical view
For SOC, detection engineering, and IR teams, validate monitoring around PAM module modifications and removal of MFA-related hooks in /etc/pam.d/ configurations, then correlate those events with successful authentications where expected MFA prompts are absent. Because ATT&CK provides no separate detection logic, tactic mapping, or relationships for this object, local engineering must define baselines for approved PAM configuration changes and expected MFA challenge behavior on Linux systems.
Likely telemetry
- Linux file integrity or configuration monitoring for /etc/pam.d/
- Authentication logs showing successful Linux logins
- MFA prompt, challenge, or enforcement logs where available
- Change management records for approved PAM configuration updates
- Administrative activity logs tied to Linux authentication configuration changes
Detection direction
- Confirm that /etc/pam.d/ changes are collected with enough detail to identify modification, removal, timing, user, and host context.
- Correlate PAM configuration changes with subsequent successful authentications that lack expected MFA evidence.
- Tune for legitimate operating system, package, or administrator-driven PAM changes to reduce false positives.
- Create environment-specific allowlists only where backed by change records, because over-broad exceptions can hide meaningful authentication control changes.
- Validate visibility gaps on Linux hosts where file integrity monitoring, authentication logs, or MFA prompt telemetry are incomplete.
Mitigation priorities
- Establish change control for PAM configuration files on Linux systems.
- Restrict administrative access capable of modifying /etc/pam.d/ configurations.
- Maintain monitoring and alerting for unauthorized PAM configuration changes.
- Ensure MFA enforcement evidence is retained and can be correlated with Linux authentication outcomes.
- Periodically test that expected MFA prompts still occur after approved authentication stack changes.
Analyst notes and limits
This is a detection analytic object, AN0546, for Linux. The official description is specific to PAM configuration changes and successful authentications lacking MFA prompts, but no official detection content, tactics, labels, aliases, or relationship context were supplied. Treat this as a coverage-validation prompt rather than a complete rule.
The source object does not provide query logic, data source mappings, tactic/technique relationships, adversary context, or mitigation mappings. Local PAM design, MFA integration, logging quality, and change-management records are required to determine severity and detection fidelity.
Analytic 0546
Detects PAM module modifications or removal of MFA hooks in /etc/pam.d/ configurations, correlated with successful authentications lacking MFA prompts.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 3e1d97e3dbd5… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0546Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.