Linux host rewrites /etc/hosts or /etc/resolv.conf

Siemphony@siemphonylowT1557unverified

AN0824 groups two different mechanisms under one analytic — file tampering with the files that steer name resolution, and ARP-layer traffic anomalies. Only the first has a real observable in the strategy's log sources: no logSource here carries raw ARP frames or NIC-level traffic, so an ARP-cache poisoning attempt is invisible to this rule and needs packet-level telemetry no analytic in this brief supplies. What is observable is the host-side enabler MITRE calls out in the technique description — an adversary steering a victim to attacker infrastructure by rewriting where DNS resolution points. The rule matches the auditd PATH record naming either file, kept separate from the SYSCALL record's own fields since the two arrive as distinct record types for the same event. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0296, 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="/etc/hosts" OR name="/etc/resolv.conf"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(type) == "path" AND (TO_LOWER(name) == "/etc/hosts" OR TO_LOWER(name) == "/etc/resolv.conf"))

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)(^/etc/hosts$|^/etc/resolv\.conf$)</field>    <description>Linux host rewrites /etc/hosts or /etc/resolv.conf</description>    <mitre>      <id>T1557</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: lateral_movement_remote_exec
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: f6badd94-fb66-4853-ac6d-930a44190d5c

ATT&CKT1557

T1557Adversary-in-the-Middle

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.

Lessonlateral movement remote exec

lateral movement remote execAI draft — unreviewed

01 · What this rule detects

AN0824 bundles two different mechanisms into one analytic: tampering with the files that steer name resolution (/etc/hosts, /etc/resolv.conf), and ARP-layer traffic anomalies. This rule matches only the first half. None of the strategy's log sources carry raw ARP frames or NIC-level traffic, so ARP-cache poisoning is invisible here and needs packet-level telemetry this brief doesn't supply — the rule's own description says so directly rather than quietly narrowing scope without saying it. What remains observable is the host-side enabler: an adversary steering a victim toward attacker infrastructure by rewriting where DNS resolution points.

02 · Telemetry you need

Linux auditd, product: linux / service: auditd, matching type: PATH records naming either watched file. This depends entirely on an operator having already configured a -w watch on both paths — auditd doesn't audit file access by default, and unlike this corpus's Windows rules, that prerequisite is not stated in the rule's own description the way AUTHORING.md asks for off-by-default telemetry elsewhere. That's a real gap: a reader could deploy this rule assuming auditd "just works" and get nothing, or get something very different from what they expect depending on how the watch was scoped.

03 · How the logic works

One selection: type: 'PATH' and name matching /etc/hosts or /etc/resolv.conf. Simple on its face, but a reviewer's central finding is about what's not in the selector — there's no syscall or permission gate at all. auditd's PATH record type fires for whatever the underlying watch rule was configured to catch. AN0824's own log-source note names open, write as the intended scope, implying the watch should be permission- restricted with -p wa (write, attribute-change) — but this rule's selector can't enforce that from the Sigma side. If the deployed watch is broader (-p rwxa, or an exit,always syscall rule), every read-only open of these files by any resolver-consuming process on the host also produces a matching PATH record, and neither of the two listed false positives describes that case — both describe legitimate rewrites, not routine reads.

04 · Common false positives

As documented, the two false positives are both write-triggered: systemd- resolved or a DHCP client (dhclient, NetworkManager) regenerating /etc/resolv.conf on every lease renewal or VPN connect/disconnect, described as "the highest-volume match by a wide margin on any laptop or cloud instance"; and configuration-management agents (Ansible, Puppet, Chef) reapplying /etc/hosts from a golden template on every convergence run, whether or not the file actually changed. level: low is well-calibrated against those two. What it isn't calibrated against is the read-volume case above — if your watch rule isn't permission-scoped, expect substantially more noise than these two entries predict.

05 · Detection maturity

tier_1: . Derived from a MITRE scaffold with no query logic, never run against a log line. The permission-scope gap above is a design question this rule hasn't answered, not a measured false-positive rate.
tier_2: means confirming the deployed watch rule's actual scope, then measuring read-versus -write volume against real traffic before trusting `level: low`.
tier_3: ** would pair this with genuine ARP-layer telemetry — Zeek or a NIDS feed — to cover the half of AN0824 this rule structurally cannot see.

Tuning & false positivesexperimental · 2 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

Before deploying, confirm your auditd watch rule is scoped to -p wa, not a broader watch — this is a precondition, not an optional tightening. If it can't be scoped that narrowly in your environment, add a third false-positive entry naming the read-volume source explicitly, because right now the rule's noise profile silently depends on an assumption it never states. On evasion: a bind mount over /etc/hosts (mount --bind) or a hardlink/alternate path the watch wasn't configured against changes the file's effective contents without ever producing a PATH record naming the canonical watched path — worth knowing alongside the already-disclosed ARP gap.

Declared by the author

systemd-resolved or a DHCP client (dhclient, NetworkManager) regenerating /etc/resolv.conf on every lease renewal or VPN connect/disconnect — this is the highest-volume match by a wide margin on any laptop or cloud instance.
Configuration-management agents (Ansible, Puppet, Chef) reapplying /etc/hosts from a golden template on every convergence run, independent of whether the file actually changed.

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

Share this rule

/u/siemphony/f6badd94-fb66-4853-ac6d-930a44190d5c

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 host rewrites /etc/hosts or /etc/resolv.conf

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it