Linux syscall changes a file's permissions, owner, or xattrs

Siemphony@siemphonylowT1222.002unverified

AN0998's first log source lists the exact syscall set that changes a Unix file's discretionary access control — chmod/fchmod/fchmodat, chown/fchown/ fchownat/lchown, and the setxattr/removexattr family that carries POSIX ACLs and extended attributes — and this rule reproduces that list verbatim as an auditd SYSCALL selection. It is deliberately the only log source implemented. AN0998's second source (PROCTITLE "contains chmod, chown, chgrp, setfacl... with suspicious parameters") and third source (osquery process execution) have no established Sigma field vocabulary anywhere in this corpus, and inventing one — the decoded command-line field a PROCTITLE normalisation pipeline exposes, or an osquery process-events column name — would be guessing at exactly the kind of field AUTHORING.md says not to guess. AN0999, the macOS arm (unifiedlog process execution and OpenBSM BSM audit events), is skipped for the identical reason: neither logsource has a field vocabulary this corpus has ever verified, the same gap T1053.003 already declined its own macOS arm for. That leaves a single, coarse selector: the syscall alone, with no argument, path or actor narrowing. This is a real limitation, not cosmetic — the syscalls fire for both a CLI invocation (chmod 777 file) and a program calling chmod(2)/chown(2) directly from library code (installers, archive extractors, language runtimes), auditd's `a1`/`a2` syscall-argument registers are raw and not reliably decodable into a permission mode without backend-specific parsing this rule does not attempt, and the `name` (target path) MITRE's CriticalSystemPaths knob wants lives only on the separate PATH record auditd emits for the same event, which Sigma cannot join to this SYSCALL selection — the same PATH/SYSCALL split T1053.003 already documented. So this rule answers only "did this syscall happen", not "was it suspicious", "was it on a sensitive path", or "was it followed by anything" — the correlation and threshold knobs (TemporalCorrelationWindow, RecursiveOperationThreshold, ACLComplexityBaseline, FileAccessFrequencyBaseline) are all cross-event or statistical and lib/sigma has no aggregation or timeframe to build any of them. Prerequisite: this needs audit rules actually watching these syscalls (e.g. `-a always,exit -F arch=b64 -S chmod,fchmod, fchmodat,chown,fchown,fchownat,lchown -k perm_mod`), which is not present in any Linux distribution's default auditd.rules — without it the rule returns zero rows and that reads as quiet when it means blind. UNVERIFIED — derived from MITRE ATT&CK DET0351 (AN0998) and never executed against logs.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Splunk · SPL

Run this as a search.

index=* (type="SYSCALL" AND (syscall="chmod" OR syscall="fchmod" OR syscall="fchmodat" OR syscall="chown" OR syscall="fchown" OR syscall="fchownat" OR syscall="lchown" OR syscall="setxattr" OR syscall="lsetxattr" OR syscall="fsetxattr" OR syscall="removexattr" OR syscall="lremovexattr" OR syscall="fremovexattr"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(type) == "syscall" AND (TO_LOWER(syscall) == "chmod" OR TO_LOWER(syscall) == "fchmod" OR TO_LOWER(syscall) == "fchmodat" OR TO_LOWER(syscall) == "chown" OR TO_LOWER(syscall) == "fchown" OR TO_LOWER(syscall) == "fchownat" OR TO_LOWER(syscall) == "lchown" OR TO_LOWER(syscall) == "setxattr" OR TO_LOWER(syscall) == "lsetxattr" OR TO_LOWER(syscall) == "fsetxattr" OR TO_LOWER(syscall) == "removexattr" OR TO_LOWER(syscall) == "lremovexattr" OR TO_LOWER(syscall) == "fremovexattr"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^SYSCALL$</field>    <field name="syscall" type="pcre2">(?i)(^chmod$|^fchmod$|^fchmodat$|^chown$|^fchown$|^fchownat$|^lchown$|^setxattr$|^lsetxattr$|^fsetxattr$|^removexattr$|^lremovexattr$|^fremovexattr$)</field>    <description>Linux syscall changes a file's permissions, owner, or xattrs</description>    <mitre>      <id>T1222.002</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: file_permission_tampering
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 3 Sept 2026
Rule ID: 502ef5a9-8430-494d-9e05-b0458b22048e

ATT&CKT1222.002

T1222.002Linux and Mac Permissions

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonfile permission tampering

file permission tamperingAI draft — unreviewed

01 · What this rule detects

This rule fires on the raw Linux syscalls that change a file's discretionary access control: chmod/fchmod/fchmodat, chown/fchown/fchownat/lchown, and the setxattr/removexattr family that carries POSIX ACLs and extended attributes. MITRE's AN0998 describes a five-part behavioral chain — suspicious command-line invocation, the syscall itself, changes targeting critical paths, temporal correlation with subsequent access, and anomalous-baseline deviation — but only the syscall list has an established field vocabulary this corpus can use without guessing. This rule implements that one piece: it answers "did one of these syscalls happen," not "was it suspicious," "was it on a sensitive path," or "was it followed by anything."

02 · Telemetry you need

auditd SYSCALL records, linux/auditd Sigma logsource. This needs audit rules actively watching these specific syscalls — something like -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,chown,fchown,fchownat,lchown -k perm_mod — which is not present in any Linux distribution's default auditd.rules. Without that rule loaded, this returns zero rows forever, and zero rows reads as "quiet" when it actually means "blind": confirm the audit rule is loaded before trusting an empty result set for anything.

03 · How the logic works

There is a single selection, selection_permission_syscalls, matching type: 'SYSCALL' against the thirteen syscall names listed above, copied verbatim from AN0998's first log source. That is deliberately the only log source implemented. AN0998's second source (PROCTITLE containing chmod/chown/chgrp/setfacl "with suspicious parameters") and third source (osquery process execution) both need a field vocabulary — the decoded command-line field a PROCTITLE normalisation pipeline exposes, or an osquery process-events column — that has never been verified anywhere in this corpus, and inventing one would be exactly the kind of guess the authoring rules forbid. The macOS arm, AN0999, is skipped for the identical reason: unifiedlog and BSM audit fields are equally unverified here. The result is coarse on purpose: no argument, path, or actor narrowing. auditd's a1/a2 syscall-argument registers are raw and not reliably decodable into a permission mode without backend-specific parsing this rule doesn't attempt, and the target path MITRE's CriticalSystemPaths knob wants lives on the separate PATH record auditd emits alongside the SYSCALL record — a join Sigma has no construct for. So a hit tells you the syscall class fired and nothing about what it touched.

04 · Common false positives

Package manager activity is the dominant source: dpkg/apt and rpm/dnf/yum postinst and postrm scripts chmod and chown every file they install or remove, under root, on every patch cycle — on a maintained estate this is the highest-volume match by a wide margin, which is exactly why the rule is scored low rather than medium. Configuration management convergence is close behind: Ansible's file/copy/template modules, Puppet's file resources, and Chef/Salt equivalents call chmod/chown on every managed path on every run regardless of whether the value changed. Archive and build tooling that preserves permissions (tar -p, cp -p, rsync -a, install(1)) fires on every deploy or CI unpack. Container builds add a fourth source: Dockerfile COPY --chown and entrypoint ownership fixes on every image build and container start.

05 · Detection maturity

tier_1: Lowest tier. This is a syscall-name filter authored from MITRE's log-source list, never run against real audit output, with every correlation and baseline knob left unimplemented. Treat any match as a lead to enrich, not a verdict, until validated against this environment's own traffic.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

None of MITRE's tuning knobs are implementable here. SuspiciousPermissionValues (777, 4755, etc.) and CriticalSystemPaths both need the PATH-record join described above. AuthorizedSystemAdministrators, TemporalCorrelationWindow, RecursiveOperationThreshold, ACLComplexityBaseline, and FileAccessFrequencyBaseline are all cross-event or statistical constructs lib/sigma has no aggregation or timeframe support for. In practice, tuning has to happen downstream: pair this rule's output with process-tree or PATH-record enrichment before alerting, or restrict deployment to hosts where package-manager and config-management noise can be suppressed by actor.

Declared by the author

Package manager activity. dpkg/apt and rpm/dnf/yum postinst and postrm scripts routinely chmod and chown the files they just installed, on every install, upgrade and removal, under root — on a patched estate this is the highest-volume match by a wide margin and is why this rule is low rather than medium.
Configuration management convergence. Ansible's file/copy/template modules, Puppet file resources with an owner/group/mode attribute, and Chef/Salt equivalents call chmod/chown on every managed path on every run, whether or not the value actually changed, which on a half-hourly schedule means a match per managed file per run.
Archive extraction and build tooling preserving permissions: tar -p, cp -p, rsync -a and install(1) all call chmod/chown as part of normal file-copy semantics, so any deploy, backup-restore or CI build step that unpacks an archive generates a burst of matches.
Container image builds. Dockerfile RUN/COPY --chown steps and entrypoint scripts that fix ownership on a mounted volume at container start call these same syscalls on every build and every container start, under whatever UID the build runs as.

Noise check0 of 5 fired

Fires on none of the 5 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 5 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1222.002, evaluated against their — events.

Share this rule

/u/siemphony/502ef5a9-8430-494d-9e05-b0458b22048e

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Linux syscall changes a file's permissions, owner, or xattrs

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it