SSH config modified
An SSH configuration file under /etc/ssh was created or replaced.
What it detects
An SSH configuration file under /etc/ssh was created or replaced. Editing sshd_config is how an attacker turns a foothold into durable, quiet access — enabling root login, permitting empty passwords, adding an AuthorizedKeysFile in a path they control, or loosening authentication so a stolen credential keeps working. Unlike dropping a key into one account, a server-config change affects every login to the host.
Matches CREATE and DELETE, which together are what an in-place edit looks like in auditd: an editor writes sshd_config~ or a temp file and renames over the original, so the change surfaces as a create and a delete rather than a write. A plain read of the config — which sshd does on every restart — is NORMAL and does not fire.
MITRE ATT&CK mapping
False positives and triage
Configuration management (Ansible/Puppet/Chef), package upgrades of openssh-server, and hardening baselines all rewrite these files legitimately, and they do it in exactly the same create-and-replace shape. The question is never "was it edited" but "by whom, and was it expected" — correlate with the acting user, whether a package manager or config-management agent was running at that moment, and whether the change is on your change calendar.
Read the resulting file before deciding: PermitRootLogin yes, PermitEmptyPasswords yes, PasswordAuthentication yes on a key-only host, or an AuthorizedKeysFile pointing somewhere world-writable are the settings that turn this from an edit into an incident.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/linux/ssh_config_tampering.yaml, licensed under the Apache License 2.0.
id: linux.persistence.ssh_config_modified
version: 1.0.0
status: stable
severity: high
confidence: 0.6
platforms: [linux]
mitre_techniques: [T1098.004, T1556]
description: |
An SSH configuration file under /etc/ssh was created or replaced. Editing
`sshd_config` is how an attacker turns a foothold into durable, quiet access —
enabling root login, permitting empty passwords, adding an AuthorizedKeysFile in a
path they control, or loosening authentication so a stolen credential keeps
working. Unlike dropping a key into one account, a server-config change affects
every login to the host.
Matches CREATE and DELETE, which together are what an in-place edit looks like in
auditd: an editor writes `sshd_config~` or a temp file and renames over the
original, so the change surfaces as a create and a delete rather than a write. A
plain read of the config — which sshd does on every restart — is `NORMAL` and does
not fire.
match:
file_path_regex: '^/etc/ssh/(ssh_config|sshd_config)(\.d/[^/]+)?~?$'
event_action_any:
- file_created
- file_deleted
false_positive_guidance: |
Configuration management (Ansible/Puppet/Chef), package upgrades of openssh-server,
and hardening baselines all rewrite these files legitimately, and they do it in
exactly the same create-and-replace shape. The question is never "was it edited"
but "by whom, and was it expected" — correlate with the acting user, whether a
package manager or config-management agent was running at that moment, and whether
the change is on your change calendar.
Read the resulting file before deciding: `PermitRootLogin yes`,
`PermitEmptyPasswords yes`, `PasswordAuthentication yes` on a key-only host, or an
`AuthorizedKeysFile` pointing somewhere world-writable are the settings that turn
this from an edit into an incident.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.