AN1056: Analytic 1056
Monitor for creation or modification of udev rules files in key directories (/etc/udev/rules.d/, /lib/udev/rules.d/, /usr/lib/udev/rules.d/). Look for RUN+= or IMPORT keys invoking suspicious binaries or scripts. Correlate this with process execution from systemd-udevd context, and file writes near udev reload/restart events. Combine this with unexpected background process spawning from udevd-related forks.
Analyst context for executives and security teams
This analytic matters because Linux udev rules can cause commands or scripts to run automatically when device-related events occur. For security leaders, the practical risk is persistence or unauthorized automation hidden in a low-noise system configuration area. The decision value is to confirm whether Linux servers have file monitoring, process lineage, and service restart visibility sufficient to explain changes to udev rules and any resulting background execution.
Executive priority
Prioritize this where Linux systems support critical services, regulated workloads, or operational infrastructure. Leaders should ask whether changes under udev rules directories are controlled, logged, and reviewed, and whether the SOC can connect a suspicious rules-file change to later execution by systemd-udevd. This is useful evidence for incident response readiness, privileged change control, and auditability of Linux persistence-relevant configuration paths.
Technical view
Validate monitoring for creation or modification of udev rules files in /etc/udev/rules.d/, /lib/udev/rules.d/, and /usr/lib/udev/rules.d/. Review rules containing RUN+= or IMPORT keys that invoke binaries or scripts, especially where the target path, command behavior, or timing is unexpected for the host role. Correlate file writes with udev reload or restart events and with process execution from a systemd-udevd context, including unexpected background processes spawned from udevd-related forks. Because no ATT&CK tactic or relationship context is supplied, treat this as a Linux detection analytic requiring local baselining rather than a complete technique coverage statement.
Likely telemetry
- Linux file creation and modification events for udev rules directories
- File content or configuration change telemetry sufficient to identify RUN+= and IMPORT keys
- Process execution telemetry with parent/child lineage showing systemd-udevd context
- Service management or system events indicating udev reloads or restarts
- Timestamps that allow correlation between rules-file writes, udev events, and spawned background processes
Detection direction
- Confirm that monitored paths include /etc/udev/rules.d/, /lib/udev/rules.d/, and /usr/lib/udev/rules.d/.
- Tune for suspicious RUN+= or IMPORT usage, while accounting for legitimate hardware, driver, management, or distribution-provided rules.
- Correlate file modification events with udev reload or restart timing to reduce isolated file-write noise.
- Review child processes from systemd-udevd and udevd-related forks, especially unexpected long-running or background processes.
- Assess blind spots where endpoint telemetry captures file writes but not file content, process lineage, or service reload events.
Mitigation priorities
- Restrict privileged write access to udev rules directories through standard Linux permission and administrative change-control practices.
- Require review and approval for udev rules changes on important Linux systems.
- Maintain baselines of expected udev rules and expected systemd-udevd child-process behavior by server role.
- Ensure incident response procedures include collection of udev rules files, related timestamps, and process lineage evidence.
- Use the analytic as a validation target for Linux logging and managed detection coverage rather than assuming coverage exists.
Analyst notes and limits
The supplied object is a detection analytic for Linux focused on monitoring udev rules file changes and correlating them with systemd-udevd execution behavior. There are no supplied tactics, technique relationships, aliases, or official detection logic beyond the description, so the take is framed around defensive validation and telemetry readiness.
This summary uses only the supplied ATT&CK fields and external reference. It does not establish active exploitation, adversary attribution, business impact, or guaranteed detection. Local baselines are required to distinguish legitimate udev rules used by operating system, hardware, or management tooling from suspicious changes.
Analytic 1056
Monitor for creation or modification of udev rules files in key directories (/etc/udev/rules.d/, /lib/udev/rules.d/, /usr/lib/udev/rules.d/). Look for RUN+= or IMPORT keys invoking suspicious binaries or scripts. Correlate this with process execution from systemd-udevd context, and file writes near udev reload/restart events. Combine this with unexpected background process spawning from udevd-related forks.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 2628adb39d8b… |
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]
mitre-attack AN1056Open 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.