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.
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/passwdThe 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
aclpackage must be present. The post notes it is not installed out-of-the-box on newer Ubuntu —setfaclreturns "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
aclpackage installed on sensitive systems where it isn't needed. - Audit for files carrying unexpected extended ACLs (the
+marker viagetfacl), 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
- Ubuntu
- setfacl
- getfacl
- acl
- LinPEAS
- Elastic
- Linux
- Elasticsearch
Techniques named here
- ACL-based privilege escalation via /etc/passwd
- Granting write ACL to non-owner user
- Detection via process monitoring for setfacl execution
Related in Offensive Security