Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1556.003: Pluggable Authentication Modules

Adversaries may modify pluggable authentication modules (PAM) to access user credentials or enable otherwise unwarranted access to accounts. PAM is a modular system of configuration files, libraries, and executable files which guide authentication for many services. The most common authentication module is pam_unix.so, which retrieves, sets, and verifies account authentication information in /etc/passwd and /etc/shadow.[1][2][3]

Adversaries may modify components of the PAM system to create backdoors. PAM components, such as pam_unix.so, can be patched to accept arbitrary adversary supplied values as legitimate credentials.[4]

Malicious modifications to the PAM system may also be abused to steal credentials. Adversaries may infect PAM resources with code to harvest user credentials, since the values exchanged with PAM components may be plain-text since PAM does not store passwords.[5][1]

EnterpriseT1556.003Sub-techniqueObject v3.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

PAM is a core authentication layer on Linux and macOS. If an adversary changes PAM configuration, libraries, or executables, they may be able to keep access, bypass normal authentication expectations, or collect credentials during legitimate logons. For leaders, this matters because a compromised authentication component can undermine trust in accounts, logs, and access decisions on critical Unix-based systems.

Executive priority

Treat this as an identity and resilience risk for Linux and macOS estates, especially systems where privileged access, service authentication, or administrative logons depend on PAM. Priority questions: which servers use PAM for important services, who can change PAM resources, are privileged changes logged and reviewed, and can the organization prove PAM integrity during an incident or audit? The supplied mitigations point to privileged account management and MFA, but local assurance depends on controlling and monitoring privileged modification paths.

Technical view

This is a sub-technique of Modify Authentication Process under defense-impairment, persistence, and credential-access. SOC and IR teams should validate monitoring around PAM configuration files, PAM libraries such as pam_unix.so, PAM-related executables, and related authentication stores such as /etc/passwd and /etc/shadow. ATT&CK provides no official detection text, but the related detection strategy DET0454 indicates focus on detecting malicious modification of PAM. Correlate PAM resource changes with privileged account activity and authentication events on Linux and macOS. Related software examples in ATT&CK include Ebury and Skidmap, both tied to Linux context, so Linux server coverage should be explicitly checked.

Likely telemetry

  • File change or integrity events for PAM configuration files, PAM shared libraries, and PAM-related executables
  • Authentication logs from Linux and macOS services that rely on PAM
  • Privileged account activity, root-level command execution, and administrative change logs
  • Package or binary integrity evidence for PAM components where available
  • Changes involving /etc/passwd and /etc/shadow

Detection direction

  • Confirm whether DET0454-style logic is implemented: detection of malicious or unexpected modification to PAM resources.
  • Baseline approved PAM files and libraries, then alert on unauthorized changes, especially to pam_unix.so or PAM configuration paths.
  • Correlate PAM changes with privileged account use; false positives may include legitimate OS updates, package maintenance, or approved authentication configuration changes.
  • Review blind spots on unmanaged Linux/macOS hosts, systems without file integrity monitoring, and environments where root activity is not centrally logged.
  • During IR, do not rely only on successful/failed login patterns; a modified authentication process may make normal authentication telemetry less trustworthy.

Mitigation priorities

  • Prioritize privileged account management: restrict who can modify PAM resources, apply least privilege, and require accountability through logging and auditing.
  • Use MFA for critical systems and services where PAM-backed authentication is in scope, recognizing that MFA does not by itself prove PAM file integrity.
  • Maintain auditable change control for authentication configuration and PAM-related components.
  • Ensure incident response playbooks include validation of PAM configuration, libraries, and related authentication files on Linux and macOS systems.
Analyst notes and limits

This take is based on ATT&CK T1556.003 version 3.0 and supplied relationships. MITRE describes PAM modification as a way to enable unwarranted access or harvest credentials; relationships identify privileged account management and MFA as mitigations and DET0454 as a relevant detection strategy.

ATT&CK does not provide official detection guidance for this object, and the supplied relationship to DET0454 does not include detection logic details. Local file paths, approved PAM modules, log sources, and update processes must be validated in the customer environment before judging coverage or risk.

Official MITRE ATT&CK definition

Pluggable Authentication Modules

Adversaries may modify pluggable authentication modules (PAM) to access user credentials or enable otherwise unwarranted access to accounts. PAM is a modular system of configuration files, libraries, and executable files which guide authentication for many services. The most common authentication module is pam_unix.so, which retrieves, sets, and verifies account authentication information in /etc/passwd and /etc/shadow.[1][2][3]

Adversaries may modify components of the PAM system to create backdoors. PAM components, such as pam_unix.so, can be patched to accept arbitrary adversary supplied values as legitimate credentials.[4]

Malicious modifications to the PAM system may also be abused to steal credentials. Adversaries may infect PAM resources with code to harvest user credentials, since the values exchanged with PAM components may be plain-text since PAM does not store passwords.[5][1]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1556 Modify Authentication Process This object subtechnique of Modify Authentication Process.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S0377: Ebury

Ebury is an OpenSSH backdoor and credential stealer targeting Linux servers and container hosts developed by Windigo. Ebury is primarily installed through modifying shared libraries (`.so` files) executed by the legitimate OpenSSH program. First seen in 2009, Ebury has been used to maintain a botnet of servers, deploy additional malware, and steal cryptocurrency wallets, credentials, and credit card details.[1][2][3][4]

Linux
Relationship explorer

All related ATT&CK context

uses · Malware S0377: Ebury Enterprise mitigates · Mitigation M1032: Multi-factor Authentication Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise uses · Malware S0468: Skidmap Enterprise detects · Detection Strategy DET0454: Detect Malicious Modification of Pluggable Authentication Modules (PAM) Enterprise subtechnique of · Technique T1556: Modify Authentication Process Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1032: Multi-factor Authentication

Multi-Factor Authentication (MFA) enhances security by requiring users to provide at least two forms of verification to prove their identity before granting access. These factors typically include:

- *Something you know*: Passwords, PINs. - *Something you have*: Physical tokens, smartphone authenticator apps. - *Something you are*: Biometric data such as fingerprints, facial recognition, or retinal scans.

Implementing MFA across all critical systems and services ensures robust protection against account takeover and unauthorized access. This mitigation can be implemented through the following measures:

Identity and Access Management (IAM):

- Use IAM solutions like Azure Active Directory, Okta, or AWS IAM to enforce MFA policies for all user logins, especially for privileged roles. - Enable conditional access policies to enforce MFA for risky sign-ins (e.g., unfamiliar devices, geolocations). - Enable Conditional Access policies to only allow logins from trusted devices, such as those enrolled in Intune or joined via Hybrid/Entra.

Authentication Tools and Methods:

- Use authenticator applications such as Google Authenticator, Microsoft Authenticator, or Authy for time-based one-time passwords (TOTP). - Deploy hardware-based tokens like YubiKey, RSA SecurID, or smart cards for additional security. - Enforce biometric authentication for compatible devices and applications.

Secure Legacy Systems:

- Integrate MFA solutions with older systems using third-party tools like Duo Security or Thales SafeNet. - Enable RADIUS/NPS servers to facilitate MFA for VPNs, RDP, and other network logins.

Monitoring and Alerting:

- Use SIEM tools to monitor failed MFA attempts, login anomalies, or brute-force attempts against MFA systems. - Implement alerts for suspicious MFA activities, such as repeated failed codes or new device registrations.

Training and Policy Enforcement:

- Educate employees on the importance of MFA and secure authenticator usage. - Enforce policies that require MFA on all critical systems, especially for remote access, privileged accounts, and cloud applications.

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Change history

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 .

ATT&CK release
19.1
Object version
3.0
Created
Modified
Raw hash
8bb11886602cf705...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 3.0 Current bundle 8bb11886602c…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Apple PAM

    Apple. (2011, May 11). PAM - Pluggable Authentication Modules. Retrieved June 25, 2020.

    Open source URL
  2. [2]
    Man Pam_Unix

    die.net. (n.d.). pam_unix(8) - Linux man page. Retrieved June 25, 2020.

    Open source URL
  3. [3]
    Red Hat PAM

    Red Hat. (n.d.). CHAPTER 2. USING PLUGGABLE AUTHENTICATION MODULES (PAM). Retrieved June 25, 2020.

    Open source URL
  4. [4]
    PAM Backdoor

    zephrax. (2018, August 3). linux-pam-backdoor. Retrieved June 25, 2020.

    Open source URL
  5. [5]
    PAM Creds

    Fernández, J. M. (2018, June 27). Exfiltrating credentials via PAM backdoors & DNS requests. Retrieved November 17, 2024.

    Open source URL
  6. [6]
    mitre-attack T1556.003
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use