Skip to content

Back to the catalog

dfir.chwriteup

Today I Learned - setfacl

A DFIR.ch blog post demonstrating how a root-level attacker can use setfacl to grant a low-privileged Linux user write access to /etc/passwd, then edit that user's UID to 0 for a stealthy root backdoor that bypasses traditional chmod-based permission checks. It also covers detection via an Elastic query for anomalous setfacl process execution and recommends running LinPEAS regularly and minimizing the acl package on sensitive systems.

TL;DR setfacl can be abused to backdoor /etc/passwd for root persistence, with an accompanying Elastic detection rule and LinPEAS-based mitigation advice.
Document

What it is

A DFIR.ch "Today I Learned" post on abusing setfacl (POSIX ACL management) as a root-persistence/backdoor primitive on Linux, with a copy-pasteable Elastic detection rule. The summary states the technique; what it omits is the verbatim commands, the detection rule text, and a mitigation the summary never mentions — acl is not installed by default on modern Ubuntu.

How it works

ACLs override traditional chmod owner-group-other permissions, so an attacker who already has root can grant a low-priv user write access to a root-owned file regardless of its mode bits. A file with an extended ACL shows a trailing + in ls -l (-rw-rw-r--+). The attack targets /etc/passwd:

setfacl -m u:malmoeb:rw /etc/passwd

The low-priv user then edits their own /etc/passwd line to UID 0 (malmoeb:x:0:0:...), and su malmoeb yields uid=0(root). This survives closure of the original compromise vector.

Preconditions / Affected

  • Attacker must already have root (this is persistence/backdoor, not initial escalation).
  • The acl package must be present. The post notes it is not installed out-of-the-box on newer Ubuntu — setfacl returns "Command 'setfacl' not found, but can be installed with: apt install acl". An attacker would have to install it or bring the binaries themselves, which is itself a detectable action.

What to do

Deploy the Elastic detection for suspicious setfacl execution:

process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "executed", "process_started") and
process.name == "setfacl" and not (
  process.command_line == "/bin/setfacl --restore=-" or
  process.args == "/var/log/journal/"
)

Note the two legitimate exclusions (systemd journal restore) that will otherwise generate noise. Additional defensive actions from the post:

  • Run LinPEAS regularly and review its output; it flags this and similar low-hanging paths (the post includes the relevant LinPEAS snippet, not reproduced here).
  • Minimize unnecessary tooling — do not leave the acl package installed on sensitive systems where it isn't needed.
  • Audit for files carrying unexpected extended ACLs (the + marker via getfacl), especially /etc/passwd.

Caveats

The setfacl name-only detection will fire on any use, legitimate or not, minus the two hardcoded exclusions — expect tuning. The technique is not novel escalation: it presumes existing root, so its value is as a persistence indicator, not a vuln to patch.

Technologies named here

Techniques named here

  • ACL-based privilege escalation via /etc/passwd
  • Granting write ACL to non-owner user
  • Detection via process monitoring for setfacl execution