Udev rule file written in a udev rules directory on Linux

Siemphony@siemphonylowT1546.017unverified

Matches an auditd PATH record naming a file inside one of the five directories udev reads rules from, which is where this technique plants the `RUN+=` or `IMPORT{program}` key it wants systemd-udevd to execute the next time a matching device event fires. The directory list is MITRE's `UdevRulePath` knob, populated here with the five paths the technique text names, and it is split across three selections purely to record where the noise comes from: the vendor trees under /usr/lib and /lib are rewritten by ordinary package installs, while /etc, /run and /usr/local are where a rule gets placed by hand — by an administrator, or by an adversary who already has root. The bare /lib tree is anchored with startswith rather than contains, because as a substring it also swallows /usr/lib and /usr/local/lib and would put the hand-placed path on the package-noise side of that split. Three limits are structural. auditd records `name=` exactly as it was handed to the syscall, so an editor invoked from inside /etc/udev/rules.d writes a bare `99-persist.rules` and is missed by every one of these directory anchors. The PATH record carries no file content, so MITRE's `SuspiciousRunPattern` knob — the entire question of whether the new rule contains a `RUN+=` at all — cannot be applied inside this selection, and every rules-file write matches equally. And the analytic's second half, an unexpected process spawning from a systemd-udevd fork inside MITRE's `TimeWindow` knob, is a cross-event correlation lib/sigma has no way to express, so the execution leg of AN1056 is not attempted here. Prerequisite: auditd watches none of these directories in a default install, so this rule returns zero rows until watches such as `-w /etc/udev/rules.d/ -p wa -k udev` are loaded, and zero rows reads as quiet when it actually means blind. The `wa` permission also matters for volume: with it only writes and attribute changes are recorded, whereas a watch that includes `r` makes every udev rule reload match as well. The selection is written in the raw auditd record vocabulary — one document per record, with `type=PATH` and `name=`. A pipeline that collapses the SYSCALL, CWD and PATH records of one event into a single document, as the Auditbeat auditd module does, has no `type=PATH` document at all and carries the filenames under `auditd.paths`; there this rule needs a field mapping before it can match. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0375, 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/udev/rules.d/*" OR name="*/run/udev/rules.d/*" OR name="*/usr/local/lib/udev/rules.d/*")) OR (type="PATH" AND name="*/usr/lib/udev/rules.d/*") OR (type="PATH" AND name="/lib/udev/rules.d/*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "path" AND (TO_LOWER(name) LIKE "*/etc/udev/rules.d/*" OR TO_LOWER(name) LIKE "*/run/udev/rules.d/*" OR TO_LOWER(name) LIKE "*/usr/local/lib/udev/rules.d/*")) OR (TO_LOWER(type) == "path" AND TO_LOWER(name) LIKE "*/usr/lib/udev/rules.d/*") OR (TO_LOWER(type) == "path" AND TO_LOWER(name) LIKE "/lib/udev/rules.d/*"))

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/udev/rules\.d/|/run/udev/rules\.d/|/usr/local/lib/udev/rules\.d/)</field>    <description>Udev rule file written in a udev rules directory on Linux (1/3)</description>    <mitre>      <id>T1546.017</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)/usr/lib/udev/rules\.d/</field>    <description>Udev rule file written in a udev rules directory on Linux (2/3)</description>    <mitre>      <id>T1546.017</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/udev/rules\.d/</field>    <description>Udev rule file written in a udev rules directory on Linux (3/3)</description>    <mitre>      <id>T1546.017</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: registry_persistence
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: cfa2e5ac-92fc-4b6f-9231-d7bf79ced4a3

ATT&CKT1546.017

T1546.017Udev Rules

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.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

A file being written into one of the five directories udev reads rules from. That is where this technique plants a RUN+= or IMPORT{program} key so systemd-udevd executes it as root the next time a matching device event fires — persistence and privilege escalation with no cron job and no unit file. Be clear about what the rule actually sees, though: a udev rules directory changed. It cannot see whether the file that landed there contains an execution key at all.

02 · Telemetry you need

auditd on Linux — the linux / auditd logsource from the brief. The selection is written in the raw auditd record vocabulary: one document per record, with type=PATH and name=. auditd watches none of these directories in a default install, so you need a watch such as -w /etc/udev/rules.d/ -p wa -k udev on each. The wa matters for volume — writes and attribute changes only, whereas adding r makes every rule reload match too. If your pipeline is Auditbeat-shaped it collapses SYSCALL, CWD and PATH into a single type=syscall document carrying filenames under auditd.paths; there is no type=PATH document there, and the rule needs a field mapping before it can match anything.

03 · How the logic works

Three selections joined by 1 of selection*, each requiring type: PATH. selection_admin_paths uses name|contains on /etc/udev/rules.d/, /run/udev/rules.d/ and /usr/local/lib/udev/rules.d/ — the places a rule gets placed by hand, by an administrator or by an adversary who already has root. selection_vendor_usr matches /usr/lib/udev/rules.d/, and selection_vendor_root uses name|startswith on /lib/udev/rules.d/. The split exists to record where the noise comes from, and that startswith is load-bearing: as a contains substring, /lib/udev/rules.d/ also swallows /usr/lib and /usr/local/lib, which would drag a hand-placed path onto the package-noise side of the split. The directory list is MITRE's UdevRulePath knob, populated with the five paths the technique text names.

04 · Common false positives

Package management dominates. systemd, udisks2, libinput, the NVIDIA and AMD drivers, docker, libvirt and most printer and scanner packages drop .rules files from their post-install scripts, so every apt or dnf transaction on a watched host emits a burst. Configuration management re-templates multipath, interface-naming and USB-permission rules into /etc/udev/rules.d on every converge. cloud-init, LVM and mdadm write into /run/udev/rules.d at boot, so those hosts match on every reboot. Even one interactive vim edit produces several PATH records, because editors write a temporary file and rename it into place.

05 · Detection maturity

tier_1: Lowest tier. Derived from MITRE ATT&CK DET0375 and never run against real data — no confirmed match, no measured volume, no evidence the field vocabulary lines up with your pipeline. Until it has been, treat silence from this rule as unproven rather than as absence.

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

The vendor trees are separate selections so you can suppress them independently — suppress selection_vendor_usr and selection_vendor_root, never the admin selection, and anchor your filter the way the rule does. Correlate what remains against the package manager's transaction log: a write into a vendor tree with no matching transaction is the interesting residue. MITRE's SuspiciousRunPattern knob cannot be applied inside this selection at all, because the PATH record carries no content, so pair the rule with file-integrity monitoring or a content check for RUN+=. Two legs of AN1056 are not attempted here: the udevadm control --reload-rules step that makes a planted rule live sits on the brief's auditd CONFIG_CHANGE source, and the systemd-udevd fork correlation inside MITRE's TimeWindow knob is beyond lib/sigma. Finally, an editor invoked from inside the rules directory writes a bare relative name, which every anchor here misses.

Declared by the author

Package installation and upgrade, which is the loudest match here by a wide margin and the reason the level is low. systemd, udisks2, libinput, NVIDIA and AMD graphics drivers, docker, libvirt and most printer and scanner packages all drop .rules files into /usr/lib/udev/rules.d or /lib/udev/rules.d from their post-install scripts, so every apt or dnf transaction on a watched host emits a burst of matching PATH records.
Configuration management writing device rules on every converge. Ansible, Puppet, Chef and Salt commonly template a multipath rule, a persistent network-interface-naming rule, or a GPU or USB-dongle permission rule into /etc/udev/rules.d, and re-write the file on each run whether or not its content changed.
Runtime rule generation during boot and device assembly. cloud-init, LVM and mdadm write rules into /run/udev/rules.d on cloud and storage hosts, so those systems match on every reboot rather than only when something is installed.
An administrator adding a rule by hand for a USB serial adapter, a hardware security token or a backup disk trigger. Editors such as vim and nano write through a temporary file and rename it into place, so a single interactive edit produces several PATH records naming the same target.

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

Share this rule

/u/siemphony/cfa2e5ac-92fc-4b6f-9231-d7bf79ced4a3

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.

Udev rule file written in a udev rules directory on Linux

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it