T1546.017: Udev Rules
Adversaries may maintain persistence through executing malicious content triggered using udev rules. Udev is the Linux kernel device manager that dynamically manages device nodes, handles access to pseudo-device files in the `/dev` directory, and responds to hardware events, such as when external devices like hard drives or keyboards are plugged in or removed. Udev uses rule files with `match keys` to specify the conditions a hardware event must meet and `action keys` to define the actions that should follow. Root permissions are required to create, modify, or delete rule files located in `/etc/udev/rules.d/`, `/run/udev/rules.d/`, `/usr/lib/udev/rules.d/`, `/usr/local/lib/udev/rules.d/`, and `/lib/udev/rules.d/`. Rule priority is determined by both directory and by the digit prefix in the rule filename.[1][2]
Adversaries may abuse the udev subsystem by adding or modifying rules in udev rule files to execute malicious content. For example, an adversary may configure a rule to execute their binary each time the pseudo-device file, such as `/dev/random`, is accessed by an application. Although udev is limited to running short tasks and is restricted by systemd-udevd's sandbox (blocking network and filesystem access), attackers may use scripting commands under the action key `RUN+=` to detach and run the malicious content’s process in the background to bypass these controls.[3]
Analyst context for executives and security teams
Udev Rules is a Linux persistence and privilege-escalation technique where an attacker with root-level ability modifies device-manager rule files so future hardware or pseudo-device events trigger malicious execution. The business issue is not the device event itself; it is that a low-noise, root-owned operating-system mechanism can re-launch attacker code after reboots or operational activity, making eradication harder if Linux endpoint monitoring and file integrity coverage are weak.
Executive priority
Prioritize this where Linux systems support critical services, privileged administration, or regulated workloads. Leaders should ask whether SOC and incident response teams can prove visibility into root-owned persistence locations, not just user logins and network alerts. This technique is also useful as an audit and resilience discussion point: can the organization show approved baselines for system persistence mechanisms, detect unauthorized changes, and validate removal during containment?
Technical view
ATT&CK maps this sub-technique to Linux persistence and privilege escalation under Event Triggered Execution. Defenders should validate monitoring of udev rule directories named by ATT&CK: /etc/udev/rules.d/, /run/udev/rules.d/, /usr/lib/udev/rules.d/, /usr/local/lib/udev/rules.d/, and /lib/udev/rules.d/. Review rules for suspicious action keys such as RUN+= and for executions that detach or launch background processes from systemd-udevd-related activity. Because MITRE provides no official detection text for this object, teams should use the related DET0375 detection strategy as a starting point and test it against local Linux baselines. The relationship to REPTILE shows this behavior is relevant to Linux rootkit tradecraft, but local evidence is required before drawing conclusions in any incident.
Likely telemetry
- File creation, modification, deletion, ownership, and permission changes in udev rule directories
- Process execution telemetry showing commands or child processes associated with udev-triggered activity or systemd-udevd context
- Linux audit or endpoint events for privileged writes by root or administrative users to udev rule files
- File integrity monitoring baselines for approved udev rules and rule filename priority ordering
- Incident response collection of udev rule contents, timestamps, hashes, and related binaries or scripts referenced by RUN+= actions
Detection direction
- Confirm that Linux monitoring includes all ATT&CK-listed udev rule paths, not only /etc/udev/rules.d/.
- Tune detections for new or modified rule files, unusual numeric filename prefixes, suspicious RUN+= action usage, and rules referencing unexpected binaries or scripts.
- Correlate privileged file changes with process execution shortly after hardware or pseudo-device events to distinguish benign device-management changes from persistence behavior.
- Account for false positives from legitimate hardware, driver, security, virtualization, or endpoint-management tooling that installs udev rules.
- Use the related DET0375 detection strategy for coverage validation, but require environment-specific testing because the ATT&CK object does not include official detection logic.
Mitigation priorities
- Maintain an approved baseline of udev rule files on Linux systems and investigate deviations in privileged directories.
- Limit and review root-level administrative access because ATT&CK states root permissions are required to create, modify, or delete these rule files.
- Include udev rule directories in file integrity monitoring, endpoint detection, and incident response triage playbooks.
- During containment and eradication, inspect referenced payloads or scripts as well as the rule file, since removing only the launched process may not remove persistence.
- For compliance readiness, retain evidence of approved udev rules, change control, privileged access review, and alert response for unauthorized modifications.
Analyst notes and limits
This take is based on ATT&CK T1546.017 version 1.0 in enterprise-attack. The supplied relationships identify this as a Linux sub-technique of Event Triggered Execution, note a related detection strategy DET0375, and map usage by the Linux rootkit REPTILE. The official description notes systemd-udevd sandbox constraints and that attackers may attempt to detach malicious execution into the background.
MITRE did not provide official detection text for this object, so detection guidance here is derived from the official description, named file paths, tactics, platform, and supplied relationships. This summary does not establish active exploitation, attribution, customer exposure, or guaranteed detection coverage. Organizations must validate against their own Linux builds, administrative workflows, and telemetry retention.
Udev Rules
Adversaries may maintain persistence through executing malicious content triggered using udev rules. Udev is the Linux kernel device manager that dynamically manages device nodes, handles access to pseudo-device files in the `/dev` directory, and responds to hardware events, such as when external devices like hard drives or keyboards are plugged in or removed. Udev uses rule files with `match keys` to specify the conditions a hardware event must meet and `action keys` to define the actions that should follow. Root permissions are required to create, modify, or delete rule files located in `/etc/udev/rules.d/`, `/run/udev/rules.d/`, `/usr/lib/udev/rules.d/`, `/usr/local/lib/udev/rules.d/`, and `/lib/udev/rules.d/`. Rule priority is determined by both directory and by the digit prefix in the rule filename.[1][2]
Adversaries may abuse the udev subsystem by adding or modifying rules in udev rule files to execute malicious content. For example, an adversary may configure a rule to execute their binary each time the pseudo-device file, such as `/dev/random`, is accessed by an application. Although udev is limited to running short tasks and is restricted by systemd-udevd's sandbox (blocking network and filesystem access), attackers may use scripting commands under the action key `RUN+=` to detach and run the malicious content’s process in the background to bypass these controls.[3]
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.
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1546 | Event Triggered Execution | This object subtechnique of Event Triggered Execution. |
Groups, software, and campaigns
S1219: REPTILE
All related ATT&CK context
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 | a142bd74c0f1… |
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]
Ignacio Udev research 2024
Eder P. Ignacio. (2024, February 21). Leveraging Linux udev for persistence. Retrieved September 26, 2024.
Open source URL -
[2]
Elastic Linux Persistence 2024
Ruben Groenewoud. (2024, August 29). Linux Detection Engineering - A Sequel on Persistence Mechanisms. Retrieved October 16, 2024.
Open source URL -
[3]
Reichert aon sedexp 2024
Zachary Reichert. (2024, August 19). Unveiling "sedexp": A Stealthy Linux Malware Exploiting udev Rules. Retrieved September 26, 2024.
Open source URL -
[4]
mitre-attack T1546.017Open 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.