Skip to content

Siemphony is in beta and still being built. How a rule earns its badge.

Siemphonybeta
Siemphony’s repertoire

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

Siemphony@siemphonylowT1222.002unverifiedPlaybook · Defence evasion
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 detection

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

title: Linux syscall changes a file's permissions, owner, or xattrsid: 502ef5a9-8430-494d-9e05-b0458b22048estatus: experimentaldescription: |  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.references:  - https://attack.mitre.org/techniques/T1222/002  - https://attack.mitre.org/detectionstrategies/DET0351author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)date: 2026-08-16tags:  - attack.defense-evasion  - attack.t1222.002logsource:  product: linux  service: auditddetection:  selection_permission_syscalls:    type: 'SYSCALL'    syscall:      - 'chmod'      - 'fchmod'      - 'fchmodat'      - 'chown'      - 'fchown'      - 'fchownat'      - 'lchown'      - 'setxattr'      - 'lsetxattr'      - 'fsetxattr'      - 'removexattr'      - 'lremovexattr'      - 'fremovexattr'  condition: selection_permission_syscallsfalsepositives:  - "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."level: low

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.

Verdicts · reactions · comments

Community

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

Log in to react
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.

Log in to report a verdict.

Log in to join the discussion.

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