Modification of an SSH authorized_keys file

Siemphony@siemphonylowT1098.004unverified

AN0350 asks for writes to ~/.ssh/authorized_keys, sourced from auditd, and optionally correlated with the process that made them inside a TimeWindow. The correlation half is not expressible here — lib/sigma has no timeframe and no join — so this rule takes the file-modification leg on its own and matches the auditd PATH record for any object whose name contains authorized_keys. A contains match rather than an exact one is deliberate: editors and scripted writers rarely touch the file in place, they write authorized_keys.tmp or .authorized_keys.swp and rename it over the original, and OpenSSH still reads authorized_keys2 where a site has kept it, so all of those spellings are the same event. The analytic's other leg, process creation, was not used, because the most common way an adversary adds a key is an in-shell redirection — echo ... >> ~/.ssh/authorized_keys — which is a shell builtin and produces no execve record at all, so a process-creation rule would miss the majority case while looking tighter. The prerequisite matters more than the logic here. auditd emits no PATH record for this file unless a rule tells it to watch it, and auditd watches do not accept wildcards, so covering every user means a syscall rule over the parent directories — something on the order of -a always,exit -F arch=b64 -S open,openat,truncate,rename,renameat -F dir=/home plus explicit watches for /root/.ssh and /etc/ssh — not a single -w line. With no such rule loaded this returns zero rows forever, and zero rows reads as a quiet estate when it actually means the sensor is blind. Use -p wa on watches: with read permission included, every sshd authentication reads the file and this rule matches on every successful login. Finally, the PATH record names the file but not the writer; the uid and exe live in the SYSCALL record of the same event, so attributing a hit to a process depends on the collector keeping those records joined. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0126, not hand-written and not tested by its author. Any lab result is on this rule's own page.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="PATH" AND name="*authorized_keys*")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(type) == "path" AND TO_LOWER(name) LIKE "*authorized_keys*")

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)^PATH$</field>    <field name="name" type="pcre2">(?i)authorized_keys</field>    <description>Modification of an SSH authorized_keys file</description>    <mitre>      <id>T1098.004</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: account_manipulation
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 144fb5e9-5944-4542-b3dd-d9143d2ce868

ATT&CKT1098.004

T1098.004SSH Authorized Keys

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.

Lessonaccount manipulation

account manipulationAI draft — unreviewed

01 · What this rule detects

Appending a public key to a user's ~/.ssh/authorized_keys gives an adversary a credential that survives password resets and rarely looks out of place. This rule takes the file-modification leg of MITRE's DET0126 / AN0350 and matches the auditd PATH record for any object whose name contains authorized_keys. It is authored, not extracted, and has never been executed against a log line.

02 · Telemetry you need

product: linux, service: auditd — and this is the rule where the prerequisite outweighs the logic. auditd emits no PATH record for the file unless a rule tells it to watch, and auditd watches take no wildcards, so covering every user means a syscall rule over the parent directories, roughly -a always,exit -F arch=b64 -S open,openat,truncate,rename,renameat -F dir=/home, plus explicit watches for /root/.ssh and /etc/ssh. With nothing loaded the rule returns zero rows forever, and zero rows reads as a quiet estate when it means a blind sensor. Use -p wa: include read permission and every sshd authentication reads the file, so the rule fires on every login.

03 · How the logic works

One selection, two predicates ANDed: type: 'PATH' and name|contains: 'authorized_keys'. The contains is deliberate rather than lazy — editors and scripted writers seldom modify the file in place. They write authorized_keys.tmp or .authorized_keys.swp and rename over the original, and OpenSSH still honours authorized_keys2 where a site kept it, so all those spellings are the same event. The analytic's process-creation leg was left out because the commonest addition is echo ... >> ~/.ssh/authorized_keys, a shell redirection that produces no execve record at all. Note the PATH record names the file but not the writer; uid and exe live in the SYSCALL record of the same event, so attribution depends on your collector keeping the records joined.

04 · Common false positives

Configuration management is the dominant source: the Ansible authorized_key module, Puppet's ssh_authorized_key, Chef and Salt rewrite the file every run whether or not the content changed, on a fifteen- to thirty-minute agent interval across the whole fleet. That is why the level is low. Cloud-init and the AWS, GCP and Azure guest agents refresh the default user's keys at every boot, so an autoscaling group churning nodes produces a steady stream. ssh-copy-id and hand edits add more. And because the predicate has no directory anchor, anything merely containing the string matches — a Git checkout holding files/authorized_keys, a Jinja template, /etc/skel, a backup staging tree.

05 · Detection maturity

tier_1: Lowest tier, and it will stay there until someone runs it. Nothing here has met real data: no match counted, no false positive dismissed, no measurement of how often your fleet's configuration management touches the file. Establish the audit rule, then baseline for a week before treating any hit as signal.

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

MITRE's knobs on AN0350 are TimeWindow, UserContext and TargetPath. TimeWindow and the correlation it enables are not expressible in this dialect, so nothing here uses them. TargetPath is where the real work is: anchor the match by adding a predicate on /.ssh/ or /etc/ssh/keys- so source trees and repositories fall out, and audit-exclude your configuration management agent's uid rather than filtering on filename. Two blind spots to state plainly. sshd_config can point AuthorizedKeysFile at a name this predicate never sees, and AuthorizedKeysCommand sources keys from a helper program touching no file at all — a companion watch on /etc/ssh/sshd_config is needed for both. Separately, auditd hex-encodes name= when a path contains a space, so users with a display-name home directory vanish silently unless the collector normalises PATH names first.

Declared by the author

Configuration management enforcing SSH access. The Ansible authorized_key module, Puppet's ssh_authorized_key resource, Chef and Salt all rewrite the file on every run regardless of whether its contents changed, and agent-based runs are commonly on a 15 to 30 minute interval across the whole estate. On a managed fleet this is the highest-volume match by a wide margin, and it is the reason this rule is scored low rather than high.
Cloud instance key provisioning. cloud-init, the AWS and GCP guest agents and the Azure Linux agent refresh the default user's authorized_keys from instance metadata at every boot and whenever the key is changed in the console, so an autoscaling group replacing nodes produces a steady stream of matches with no human involved.
Administrators granting access by hand. ssh-copy-id run from a jump host appends to the file on the server side, and an administrator editing it with vim or nano produces PATH records for the file plus the editor's swap and backup copies, all of which the contains match picks up as separate hits for one edit.
Backup and integrity-monitoring agents. If the auditd watch was loaded with read permission rather than -p wa, file-integrity tooling such as AIDE or Tripwire and any backup agent walking home directories will match this rule on every scheduled scan of every account on the host.

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 T1098.004, evaluated against their — events.

Share this rule

/u/siemphony/144fb5e9-5944-4542-b3dd-d9143d2ce868

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.

Modification of an SSH authorized_keys file

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it