How do attackers use Udev Rules?

Why Udev Rules Work as an Execution Hook

udev rules are a Linux device-management mechanism that reacts to hardware events, so they can be abused as an execution hook rather than a traditional login or startup persistence path. When a matching device is added, removed, or re-enumerated, the rule can invoke commands, alter permissions, or redirect how the device is handled. That makes the technique attractive because it blends into normal system activity.

Attackers typically rely on a rule placed where udev will read it on boot or during device discovery. If they can write to a rule file, influence a watched directory, or tamper with ownership and permissions, the rule can fire automatically without user interaction. This is less about noisy malware and more about embedding execution in infrastructure behaviour that defenders may not inspect often.

Because the trigger is tied to device events, the attacker does not need a constantly running process to retain access. A rule may be enough to re-establish execution whenever a target device or subsystem appears, which is why udev abuse often sits in the same broader persistence family as other event-driven autostart methods. The practical concern is not only command execution, but also the possibility of hiding a callback inside device handling that looks operational at first glance. See Persistence Techniques Guide for the wider persistence pattern.

How Attackers Turn Device Events into Persistence

The simplest abuse pattern is to attach a command to a predictable device action, such as a USB insertion, disk attach, or subsystem reload. That command might start a payload, stage a second script, modify another startup location, or re-create access after reboot. In practice, the event is just the trigger, while the real objective is to anchor malicious activity to a dependable system lifecycle moment.

Attackers also benefit from the fact that device-handling rules can be distributed across multiple locations and may inherit from default templates. If defenders only check obvious startup paths, they can miss a rule file that looks legitimate, has a believable name, or is hidden among vendor-managed content. The abuse is especially effective when the command is brief, wrapper-based, or points to a script buried elsewhere on the host.

This is why udev abuse should be treated as both a persistence and an execution-control problem. The dangerous part is not merely the rule syntax, but the trust the system places in local configuration and the relative rarity of routine review. In attacker terms, udev gives them a low-friction way to convert one local configuration change into repeated execution. For broader intrusion patterns that include persistence, credential theft, and post-compromise actions, The State of NHI & AI Agent Breach Report 2026 is a useful reference point.

What Defenders Should Check First

The most important control is to confirm which udev rule files are writable, by whom, and why. If non-administrative users or unexpected service accounts can alter rule paths, the environment already has a privilege boundary problem. Review file ownership, directory permissions, package-managed locations, and any local overrides that shadow standard rules.

Then look for rule content that launches shells, interpreters, downloaders, or opaque helper scripts when device events occur. The most suspicious entries are those that transform a simple hardware match into command execution, especially if the command path is unusual or references a script outside a managed software location. Also check for recently changed timestamps, unexpected symlinks, and changes that do not align with approved hardware or automation workflows.

If a rule is needed for legitimate operations, the safer posture is tight change control, constrained write access, and explicit review of any command-bearing device rule. Hardware events are normal; arbitrary code execution in response to them should not be. That same principle appears in adversary tradecraft reporting, where trusted event paths are used to make malicious activity look like routine administration. For more threat context, review CISA cyber threat advisories.

Risk and Threat Considerations

Udev rule abuse is risky because it converts a low-level system mechanism into stealthy persistence. Once an attacker can write or alter a rule, they can bind execution to future device activity and keep re-triggering their code without maintaining an obvious service, cron entry, or interactive foothold.

Failure mechanism: The attacker gains write access to a udev rule location, inserts a command-bearing rule, and relies on predictable device events to execute that command repeatedly. If monitoring focuses on only the usual startup mechanisms, the malicious rule can persist unnoticed.

Impact: The host can repeatedly launch attacker-controlled code, re-establish access after reboots or device events, and expose the system to follow-on compromise, including lateral movement or secondary persistence mechanisms.

Practitioner Guidance

What to verify: Build a short inventory of every writable udev rule path and compare it with expected ownership, package source, and change history. Any rule that can execute a command should have a clear business justification and a known maintainer.

Common mistake: Teams often check for malicious services and startup items, but forget device-triggered execution paths. That gap matters because a rule can be dormant until a specific hardware event occurs, which makes casual inspection unreliable.

Decision rule: If a rule executes code on add or remove events and the path is writable outside tightly controlled administration, treat it as a high-priority review item and rotate any related credentials or access tokens if the command path suggests post-exploitation use.

Practitioner takeaway: The key judgement is to treat device-event handlers as executable trust boundaries, not configuration trivia, because a single writable rule can turn ordinary hardware activity into durable persistence.

Related resources from NHI Mgmt Group

• How do attackers use list planting?
• How do attackers use invisible Unicode?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?