doas config modified
/etc/doas.conf was created or replaced.
What it detects
/etc/doas.conf was created or replaced. doas is OpenBSD's smaller replacement for sudo, packaged for most Linux distributions, and its config grants the same thing sudoers does: which users may run what as whom, and whether they are asked for a password. A single line — permit nopass alice as root — is a permanent, passwordless root path for that account.
It matters here because monitoring is asymmetric. Estates watch /etc/sudoers and visudo closely and frequently watch nothing else, so an attacker who installs doas and writes its config gets sudo-equivalent privilege with none of the attention. linux.privilege.sudoers_modified covers the other file; this is the same rule for the door nobody is looking at.
Matches CREATE and DELETE because an in-place edit surfaces in auditd as an editor writing doas.conf~ and renaming over the original — a create and a delete, not a write. A plain read is NORMAL and does not fire.
MITRE ATT&CK mapping
- T1548.003Abuse Elevation Control Mechanism: Sudo and Sudo Caching· Privilege Escalation
False positives and triage
The honest first question is whether doas is installed at all. On a host that has never had it, the config appearing is the finding on its own and needs no further triage. On a host that uses it, the file changes for the same legitimate reasons sudoers does: config management, a package upgrade, an administrator granting access through the normal process.
Read the resulting file before deciding. nopass is the line that matters most — it is doas's NOPASSWD and removes the one control that stops a stolen session becoming root. permit ... as root for an account that is not an administrator, or a keepenv on a rule that did not have it, are the other two worth escalating.
Correlate with who was on the box: a config-management agent rewriting the file is routine, the same edit from an interactive session outside a change window is not.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/linux/doas_config_modified.yaml, licensed under the Apache License 2.0.
id: linux.privilege.doas_config_modified
version: 1.0.0
status: stable
severity: high
confidence: 0.75
platforms: [linux]
mitre_techniques: [T1548.003]
description: |
`/etc/doas.conf` was created or replaced. `doas` is OpenBSD's smaller replacement
for `sudo`, packaged for most Linux distributions, and its config grants the same
thing sudoers does: which users may run what as whom, and whether they are asked
for a password. A single line — `permit nopass alice as root` — is a permanent,
passwordless root path for that account.
It matters here because monitoring is asymmetric. Estates watch `/etc/sudoers`
and `visudo` closely and frequently watch nothing else, so an attacker who
installs doas and writes its config gets sudo-equivalent privilege with none of
the attention. `linux.privilege.sudoers_modified` covers the other file; this is
the same rule for the door nobody is looking at.
Matches CREATE and DELETE because an in-place edit surfaces in auditd as an
editor writing `doas.conf~` and renaming over the original — a create and a
delete, not a write. A plain read is `NORMAL` and does not fire.
match:
file_path_regex: '^/etc/doas\.(conf|d/[^/]+)~?$'
event_action_any:
- file_created
- file_deleted
false_positive_guidance: |
The honest first question is whether doas is installed at all. On a host that has
never had it, the config appearing is the finding on its own and needs no further
triage. On a host that uses it, the file changes for the same legitimate reasons
sudoers does: config management, a package upgrade, an administrator granting
access through the normal process.
Read the resulting file before deciding. `nopass` is the line that matters most —
it is doas's `NOPASSWD` and removes the one control that stops a stolen session
becoming root. `permit ... as root` for an account that is not an administrator,
or a `keepenv` on a rule that did not have it, are the other two worth escalating.
Correlate with who was on the box: a config-management agent rewriting the file is
routine, the same edit from an interactive session outside a change window is not.
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.