File attribute tampering

A file's permissions or extended attributes were changed in one of the two ways attackers use them:

* chattr +i / chattr -i — the immutable attribute. Setting it makes a dropped payload, a modified cron file, or a rogue authorized_keys undeletable even by root until the attribute is cleared, which is how a foothold survives cleanup. Clearing it is the step before editing a file the system deliberately protects. * chmod 777 — world-writable AND world-executable. It is almost never the right permission for anything, and on a downloaded script or a kernel module it is the "make it run" step of a drop-and-execute.

• T1222.002File and Directory Permissions Modification: Linux and Mac File and Directory Permissions Modification· Defense Evasion

chmod 777 is depressingly common in legitimate work — build scripts, tutorials copied verbatim, developers unblocking themselves on a shared directory. Judge it by the target: a source tree or a scratch directory is carelessness, while a binary, a .ko, a script in /tmp, or anything under /etc is a finding. Where a team does this habitually, suppress that account and path pair and keep the rule.

chattr +i is rarer and more interesting. Legitimate uses exist — hardening baselines set the immutable bit on /etc/passwd, /etc/shadow and /etc/resolv.conf precisely to stop tampering — so the question is whether a hardening tool was running and whether the target is on its list. chattr -i on a file your baseline set immutable is the inverse and deserves attention on its own: something wanted that protection removed.

Declarative YAML read by the detection engine — data, never executed. Confidence 55%. Source: rules/linux/file_attribute_tampering.yaml, licensed under the Apache License 2.0.

id: linux.defense_evasion.file_attribute_tampering
version: 1.0.0
status: stable
severity: medium
confidence: 0.55
platforms: [linux]
mitre_techniques: [T1222.002]
description: |
  A file's permissions or extended attributes were changed in one of the two ways
  attackers use them:

  * `chattr +i` / `chattr -i` — the immutable attribute. Setting it makes a dropped
    payload, a modified cron file, or a rogue authorized_keys undeletable even by
    root until the attribute is cleared, which is how a foothold survives cleanup.
    Clearing it is the step before editing a file the system deliberately protects.
  * `chmod 777` — world-writable AND world-executable. It is almost never the right
    permission for anything, and on a downloaded script or a kernel module it is the
    "make it run" step of a drop-and-execute.
match:
  command_line_regex: '(?i)(\bchattr\b[^\n]*\s[-+]i\b|\bchmod\b[^\n]*\s0?777\b)'
false_positive_guidance: |
  `chmod 777` is depressingly common in legitimate work — build scripts, tutorials
  copied verbatim, developers unblocking themselves on a shared directory. Judge it
  by the target: a source tree or a scratch directory is carelessness, while a
  binary, a `.ko`, a script in /tmp, or anything under /etc is a finding. Where a
  team does this habitually, suppress that account and path pair and keep the rule.

  `chattr +i` is rarer and more interesting. Legitimate uses exist — hardening
  baselines set the immutable bit on `/etc/passwd`, `/etc/shadow` and `/etc/resolv.conf`
  precisely to stop tampering — so the question is whether a hardening tool was
  running and whether the target is on its list. `chattr -i` on a file your baseline
  set immutable is the inverse and deserves attention on its own: something wanted
  that protection removed.