PAM configuration or MFA module file touched under /etc/pam.d

Siemphony@siemphonylowT1556.006unverified

Matches the Linux leg of AN0546 on the single log source it offers: an auditd PATH record naming either a file directly under /etc/pam.d/ (the stack of config files an admin edits to remove or reorder an MFA requirement) or one of a short list of well-known open-source MFA PAM module .so files. The pam.d selection is MITRE's own log source, taken verbatim ("open/write to /etc/pam.d/*"); the module-file selection populates MITRE's MFAHooks knob ("paths to organization-specific PAM modules enforcing MFA") with pam_google_authenticator.so, pam_duo.so, pam_oath.so, pam_yubico.so, pam_u2f.so and pam_radius_auth.so -- a list this pipeline assembled from common open-source MFA integrations, not a set of values MITRE supplied. Both selections are on the PATH record type because that is the established shape for "a specific file path was touched" elsewhere in this corpus (T1547.006, T1561.001); neither can tell a write from a read, since access-mode (O_WRONLY vs O_RDONLY) lives in the paired SYSCALL record's flags argument and no rule in this corpus decodes that field, so "removal of an MFA hook" and "cat /etc/pam.d/sshd" produce the identical event here. AN0546's own correlation half -- joining this with "successful authentications lacking MFA prompts" -- is not attempted: that is a second event type with no shared key this corpus's Sigma models a join across. Two other legs of this strategy are not attempted. AN0543 (Windows) offers Security EventCode 4739 and a PowerShell operational-log cmdlet pairing, but neither is usable: 4739 is Domain Policy Changed, and its own fields (DomainPolicyChanged, DomainValue) cover password length, lockout and Kerberos policy generically -- nothing in the brief names a bit or value that is MFA-specific, so a bare EventCode=4739 selection would match every routine password-policy edit in the domain, not this technique. The PowerShell leg names Set-ADUser and Set-ADAuthenticationPolicy but no AD attribute for "MFA disabled" -- Active Directory carries no native MFA flag, which is exactly why the CISA advisory this technique's own description cites (Russians Exploit Default MFA Protocol, March 2022) describes attackers editing a fail-open policy in the Azure MFA NPS extension's own config file instead, a log source this brief's AN0543 does not offer. AN0547 (macOS) offers only macos:unifiedlog, which has no field vocabulary anywhere in this corpus -- the same blocker recorded against T1553.001 and T1556's own parent-technique decline. Prerequisite: raw auditd watches nothing by default. This returns zero rows until watches such as `-w /etc/pam.d -p wa -k pam_config` and one per module path (e.g. `-w /lib/x86_64-linux-gnu/security/pam_google_authenticator.so -p wa -k pam_mfa`) are loaded, and zero rows reads as quiet when it actually means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0190, 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="*/pam_google_authenticator.so" OR name="*/pam_duo.so" OR name="*/pam_oath.so" OR name="*/pam_yubico.so" OR name="*/pam_u2f.so" OR name="*/pam_radius_auth.so")))

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 "*/pam_google_authenticator.so" OR TO_LOWER(name) LIKE "*/pam_duo.so" OR TO_LOWER(name) LIKE "*/pam_oath.so" OR TO_LOWER(name) LIKE "*/pam_yubico.so" OR TO_LOWER(name) LIKE "*/pam_u2f.so" OR TO_LOWER(name) LIKE "*/pam_radius_auth.so")))

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. -->  <!-- 2 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 MFA module file touched under /etc/pam.d (1/2)</description>    <mitre>      <id>T1556.006</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)(/pam_google_authenticator\.so$|/pam_duo\.so$|/pam_oath\.so$|/pam_yubico\.so$|/pam_u2f\.so$|/pam_radius_auth\.so$)</field>    <description>PAM configuration or MFA module file touched under /etc/pam.d (2/2)</description>    <mitre>      <id>T1556.006</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: 2c4659e4-1d18-4e01-b47c-86d9462498c9

ATT&CKT1556.006

T1556.006Multi-Factor Authentication

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

This rule covers only the Linux leg (AN0546) of DET0190, MITRE's strategy for detecting MFA modification or disabling. It fires when an auditd PATH record names either a file directly under /etc/pam.d/, or one of six well-known open-source MFA PAM module .so files: pam_google_authenticator.so, pam_duo.so, pam_oath.so, pam_yubico.so, pam_u2f.so, pam_radius_auth.so. Either match alone is enough — touching the PAM stack config or touching a specific MFA module file both satisfy the rule.

02 · Telemetry you need

Auditd watches on /etc/pam.d and on each MFA module path, e.g. -w /etc/pam.d -p wa -k pam_config plus one -w per .so path. Raw auditd watches nothing by default — without these loaded, the rule returns zero rows, which reads as quiet but actually means blind.

03 · How the logic works

Two OR'd selections (1 of selection*), both on type: PATH. selection_pamd_config matches name|contains: '/etc/pam.d/' — MITRE's own log source, taken verbatim ("open/write to /etc/pam.d/*"). selection_mfa_module matches name|endswith against the six .so paths above, populating MITRE's MFAHooks knob; that list of six is this pipeline's own assembly of common open-source MFA integrations, not values MITRE supplied. Neither selection can distinguish a write from a read — access-mode (O_WRONLY vs O_RDONLY) lives in the paired SYSCALL record's flags argument, which this rule doesn't decode — so "removed an MFA hook" and cat /etc/pam.d/sshd produce the same event here. AN0546's own correlation half, joining this with "successful authentication lacking an MFA prompt," is not attempted: that is a second event type with no shared key this corpus's Sigma models a join across.

04 · Common false positives

Three named benign sources. Configuration-management agents (Ansible, Puppet, Chef, SaltStack) rewriting or re-checking pam.d files on every scheduled run — on a short CM interval, this is the loudest source of matches by a wide margin. Package management rewriting the PAM stack during routine maintenance: apt/dnf upgrading a PAM package runs pam-auth-update or authconfig, which opens and rewrites every file under /etc/pam.d/ regardless of whether MFA was touched. Compliance and vulnerability scanners (Lynis, OpenSCAP, CIS-CAT) reading every pam.d file during a routine audit pass — a read this rule cannot distinguish from a write.

05 · Detection maturity

tier_1: Lowest tier. This rule is UNVERIFIED and has never been run against a log line. level: low matches its loudest disclosed false positive (CM agents rewriting pam.d on every run), not any evidence of real-world precision. Promotion out of this tier requires execution against real pam.d read/write traffic and a working correlation with authentication events.

Tuning & false positivesexperimental · 3 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

Narrow MFAHooks to the module paths actually deployed in your environment rather than this generic open-source list. Build the missing correlation layer separately — a subsequent successful login lacking the expected MFA challenge — since AN0546 is designed as one half of a two-part detection. Exclude your CM tool's service account or process where identifiable, and consider suppressing matches inside a known package-manager transaction window. Note this rule is Linux-only: the Windows leg (Security 4739 has no MFA-specific field) and the macOS leg (unifiedlog has no field vocabulary anywhere in this corpus) were not attempted.

Declared by the author

Configuration-management agents (Ansible, Puppet, Chef, SaltStack) that rewrite or re-check /etc/pam.d/common-auth or /etc/pam.d/sshd on every scheduled run as part of routine, sanctioned MFA provisioning -- on an estate with a short CM interval this is the loudest source of matches by a wide margin.
Package management rewriting the PAM stack during normal maintenance: apt/dnf upgrading libpam-google-authenticator or a similar package runs pam-auth-update or authconfig, which opens and rewrites every file under /etc/pam.d/ regardless of whether MFA was touched.
Compliance and vulnerability scanners (Lynis, OpenSCAP, CIS-CAT) that read every file under /etc/pam.d/ during a routine audit pass, which this rule cannot distinguish from a write since access-mode is not part of the selection.

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.006, evaluated against their — events.

Share this rule

/u/siemphony/2c4659e4-1d18-4e01-b47c-86d9462498c9

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 MFA module file touched under /etc/pam.d

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it