PAM configuration or module directory written on Linux

Siemphony@siemphonylowT1556.003unverified

AN1250 asks for file modification under /etc/pam.d/ or /lib/security/ correlated with unusual authentication activity. lib/sigma has no cross-event join or timeframe, so this rule takes only the file-write leg — an auditd PATH record naming one of MITRE's own `MonitoredPaths`, populated here with the two directories MITRE names plus the modern multiarch module location (/lib/x86_64-linux-gnu/security/ and /usr/lib/x86_64-linux-gnu/ security/), which is this rule's own addition since most current distributions moved pam_unix.so and friends there rather than the legacy /lib/security/ path MITRE cites. This follows the same {product: linux, service: auditd} PATH-record vocabulary already established for T1053.003, T1543.002 and T1546.017 in this corpus. It shares the crontab rule's exact limitation: auditd's `name=` field records the path exactly as handed to the syscall, so an editor that writes a temporary file and renames it into /etc/pam.d/ (vi, many config-management modules) is caught by the rename target, but a relative write from inside the directory (`cd /etc/pam.d && cp evil sshd`) logs only `name="sshd"` with the directory on a separate, unjoinable CWD record — no path selection here can catch that form. The second AN1250 logsource, {category: process_creation, product: linux} covering the execve leg, is not attempted: MITRE frames it as correlating with the resulting login anomaly, which is the same cross-event join this rule already cannot do, and a bare "some process ran" selector on that category would add no observable beyond the file write already captured here. The macOS leg, AN1251, is not attempted at all: both its logsources, {product: macos, service: unifiedlog} and {product: macos, service: osquery}, have no established Sigma field vocabulary anywhere in this corpus — osquery has never been used as a rule's logsource in this corpus, and unifiedlog carries the same blocker recorded against T1037.002, T1036.004, T1036.006 and others. MITRE's `TimeWindow` and `BaselineAccounts` knobs (correlating the write with anomalous login patterns) go entirely unimplemented for the same cross-event-join reason. Prerequisite: auditd does not watch these paths by default; this returns nothing until watches such as `-w /etc/pam.d -p wa -k pam_tamper` and `-w /lib/x86_64-linux-gnu/security -p wa -k pam_tamper` are loaded, and zero rows reads as quiet when it actually means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0454, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Splunk · SPL

Run this as a search.

index=* ((type="PATH" AND name="*/etc/pam.d/*") OR (type="PATH" AND name="*/lib/security/*") OR (type="PATH" AND (name="*/lib/x86_64-linux-gnu/security/*" OR name="*/usr/lib/x86_64-linux-gnu/security/*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "path" AND TO_LOWER(name) LIKE "*/etc/pam.d/*") OR (TO_LOWER(type) == "path" AND TO_LOWER(name) LIKE "*/lib/security/*") OR (TO_LOWER(type) == "path" AND (TO_LOWER(name) LIKE "*/lib/x86_64-linux-gnu/security/*" OR TO_LOWER(name) LIKE "*/usr/lib/x86_64-linux-gnu/security/*")))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 3 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)/etc/pam\.d/</field>    <description>PAM configuration or module directory written on Linux (1/3)</description>    <mitre>      <id>T1556.003</id>    </mitre>  </rule>   <rule id="100001" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)/lib/security/</field>    <description>PAM configuration or module directory written on Linux (2/3)</description>    <mitre>      <id>T1556.003</id>    </mitre>  </rule>   <rule id="100002" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)(/lib/x86_64-linux-gnu/security/|/usr/lib/x86_64-linux-gnu/security/)</field>    <description>PAM configuration or module directory written on Linux (3/3)</description>    <mitre>      <id>T1556.003</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: account_manipulation
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: b583512e-1718-4d09-be15-439bd77bda6b

ATT&CKT1556.003

T1556.003Pluggable Authentication Modules

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonaccount manipulation

account manipulationAI draft — unreviewed

01 · What this rule detects

AN1250 asks for file modification under /etc/pam.d/ or /lib/security/ correlated with unusual authentication activity — an attacker patching PAM to plant a credential-capturing or authentication-bypassing module. lib/sigma has no cross-event join or timeframe, so this rule takes only the file-write half: an auditd PATH record naming one of the watched PAM directories. The correlation with anomalous logins that AN1250 actually asks for is not implemented; a hit here is "something touched a PAM path," not "PAM was tampered with to enable unauthorized access."

02 · Telemetry you need

{product: linux, service: auditd}, PATH-record vocabulary already established in this corpus for T1053.003, T1543.002 and T1546.017. auditd does not watch these paths by default — this returns nothing until watches like -w /etc/pam.d -p wa -k pam_tamper and one per multiarch security directory are loaded. Zero rows reads as quiet; it means the watches were never set.

03 · How the logic works

Three selection blocks under 1 of selection*: selection_pam_config matches name|contains: '/etc/pam.d/'; selection_pam_modules_legacy matches name|contains: '/lib/security/', MITRE's own named module path; selection_pam_modules_multiarch adds /lib/x86_64-linux-gnu/security/ and /usr/lib/x86_64-linux-gnu/security/ as an OR list. That third block is the rule's own addition — most current distributions moved pam_unix.so and its siblings to the multiarch path, so a rule scoped only to MITRE's legacy path would miss where PAM modules actually live today. The rule inherits a known limitation from the sibling crontab rule: auditd's name= field records the path exactly as the syscall received it. An editor that writes a temp file and renames it into place (vi, most config-management modules) is caught on the rename target. A relative write from inside the directory — cd /etc/pam.d && cp evil sshd — logs only name="sshd" with the directory on a separate, unjoinable CWD record. No path selection here can catch that form. Two other AN1250 legs are declined outright: the process_creation execve leg, because MITRE frames it as correlating with the login anomaly this rule already can't join, and a bare "some process ran" selector adds nothing; and the entire macOS leg (unifiedlog, osquery), because neither has established Sigma fields anywhere in this corpus — osquery has never been used as a logsource here at all.

04 · Common false positives

level: low, and the false positives justify it heavily. Package management is the biggest: apt/dpkg or dnf/rpm installing or upgrading libpam-modules, libpam-runtime, pam_krb5, or SSSD writes into these exact directories on every affected host during routine patching. PAM reconfiguration tooling — pam-auth-update, authconfig, authselect, or an SSSD/LDAP rollout — rewrites /etc/pam.d/ as its normal, supported job. Configuration-management convergence (Ansible, Puppet, Chef, Salt) rewrites managed PAM files on every run regardless of whether content changed, producing one match per host per cycle. Backup, restore, and golden-image provisioning that lays down a full /etc tree adds a fourth source, concentrated around host builds.

05 · Detection maturity

tier_1: .** Derived from a MITRE scaffold with no query logic, never run against real auditd output — the false-positive list above is reasoning about how these directories are normally touched, not measurement.
tier_2: means enabling the watches, running for a patch cycle, and building the package-manager exclusion from what actually fires before this rule is worth trusting for anything beyond "go look."

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Exclude the package manager's own process tree (dpkg, apt, rpm, yum, dnf) as the writing process where that field is available upstream of auditd's PATH record. Suppress convergence-tool runs by correlating with their own scheduled cadence rather than treating every write as novel. Because the rename-target blind spot is structural, pair this rule with integrity monitoring (AIDE, a periodic hash baseline of /etc/pam.d/) for the relative-write case it cannot see, and treat this rule as "something changed here," not as evidence of what.

Declared by the author

Package management: apt/dpkg or dnf/rpm installing or upgrading libpam-modules, libpam-runtime, pam_krb5, sssd or any other package that ships a .so under the security/ module directories or a fragment under /etc/pam.d/, on every affected host during routine patching.
PAM reconfiguration tooling run by administrators as intended — pam-auth-update on Debian/Ubuntu, authconfig or authselect on RHEL/Fedora, or an SSSD/LDAP/Kerberos-integration rollout — which rewrites files under /etc/pam.d/ as its normal, supported mechanism.
Configuration-management convergence (Ansible, Puppet, Chef, Salt) that manages /etc/pam.d/common-auth or similar files as code and rewrites them on every run whether or not the content changed, producing a match per managed host per convergence cycle.
System backup, restore or image-provisioning tooling (rsync-based restores, cloud-init file provisioning, golden-image bakes) that lays down a full /etc tree including /etc/pam.d/ while a host is being built or recovered.

Noise check0 of 5 fired

Fires on none of the 5 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 5 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1556.003, evaluated against their — events.

Share this rule

/u/siemphony/b583512e-1718-4d09-be15-439bd77bda6b

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

PAM configuration or module directory written on Linux

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it