new(rules): detect security tool impairment in containers (T1562.001)

[JayKnowSo]

Summary

Adds a detection rule for MITRE ATT&CK T1562.001 (Impair Defenses: Disable or Modify Tools) scoped to container workloads.

What this detects

• iptables/ip6tables flush or delete-chain commands inside a container
• systemctl stop targeting security daemons (falco, auditd, sysdig, osquery)
• service stop targeting falco or auditd

Why this matters

T1562 was the most prevalent defense evasion technique in malware campaigns in 2025. After achieving initial execution in a container (T1059), adversaries commonly disable runtime security tooling before lateral movement. No existing rule in stable, incubating, or sandbox tiers covers this technique for container workloads.

MITRE ATT&CK

https://attack.mitre.org/techniques/T1562/001/

False positives

Tunable via user_known_security_tool_disable_activities macro. Legitimate iptables usage in containers is rare and should be explicitly allowlisted.

Testing

Rule fires on: iptables -F, systemctl stop falco, service stop auditd executed inside a running container.

[poiana]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: JayKnowSo
Once this PR has been reviewed and has the lgtm label, please assign darryk10 for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• rules/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[leogr]

Hey @JayKnowSo

Thanks for tackling this!

The bulk of my feedback is around substring-matching precision and a couple of output-template alignments, see inline 👇

Otherwise, SGMT.

🙏

[leogr]

Suggested change

	(proc.name = systemctl and proc.args contains "stop" and
	(proc.args contains "falco" or proc.args contains "auditd" or
	proc.args contains "sysdig" or proc.args contains "osquery"))
	or
	(proc.name = service and proc.args contains "stop" and
	(proc.args contains "falco" or proc.args contains "auditd"))
	(proc.name = systemctl and
	(proc.args startswith "stop " or proc.args contains " stop ") and
	(proc.args contains " falco" or proc.args contains " auditd" or
	proc.args contains " sysdig" or proc.args contains " osquery"))
	or
	(proc.name = service and
	(proc.args startswith "falco " or proc.args startswith "auditd ") and
	(proc.args endswith " stop" or proc.args contains " stop "))

The current proc.args contains "stop" and (proc.args contains "falco" or ...) is an unanchored substring search on the full joined args. Both substrings just have to appear anywhere in the string, so the rule can fire on:

• systemctl status mystop.service (if "falco" happens to appear elsewhere, e.g., in an env var path the args carry)
• systemctl reload falco-helper-stopwatch.service (verb is reload, but both stop and falco substrings match)

Our convention for short-token matching is whitespace anchoring, see the netcat rule at falco_rules.yaml:849-851 (proc.args contains "-e ", etc.). The suggestion above anchors both the verb and the daemon name with leading/trailing whitespace, matching realistic usage like systemctl stop falco, systemctl --no-block stop falco, service falco stop while rejecting the substring-noise cases.

[leogr]

Suggested change

	(proc.name in (iptables, ip6tables) and
	(proc.args contains "-F" or proc.args contains "--flush" or
	proc.args contains "-X" or proc.args contains "--delete-chain"))
	(proc.name in (iptables, ip6tables) and
	(proc.args startswith "-F" or proc.args startswith "--flush" or
	proc.args startswith "-X" or proc.args startswith "--delete-chain" or
	proc.args contains " -F" or proc.args contains " --flush" or
	proc.args contains " -X" or proc.args contains " --delete-chain"))

Same precision concern as the systemctl block. proc.args contains "-F" matches the substring -F anywhere in the args, including inside chain names or comment text. Combining startswith for first-position flags with contains " -F" (leading space) for later positions covers both placements while staying anchored to whitespace boundaries - same pattern as falco_rules.yaml:849-851 and falco-incubating_rules.yaml:1162-1165.

[JayKnowSo]

Addressed the yamllint line-length violation introduced by this PR — wrapped the output field in a >- folded block scalar to comply with the 130-char limit.

The remaining CI failures are pre-existing violations in falco_rules.yaml (53 errors) and falco-sandbox_rules.yaml (182 errors) — neither file was touched by this PR. Happy to open a separate chore PR to fix the line-length violations across all three rule files if that would help unblock the merge pipeline.

[leogr]

Suggested change

	(proc.name in (iptables, ip6tables) and
	(proc.args contains "-F" or proc.args contains "--flush" or
	proc.args contains "-X" or proc.args contains "--delete-chain"))
	(proc.name in (iptables, ip6tables) and
	(proc.args startswith "-F" or proc.args contains " -F" or
	proc.args startswith "-X" or proc.args contains " -X" or
	proc.args contains "--flush" or proc.args contains "--delete-chain"))

I have dug a bit more into this since my previous round, and it is worse than I described back then.

proc.args contains "-F" is an unanchored substring search, so it also matches any chain name containing -F. Those are everywhere in container networking:

• iptables -A KUBE-FORWARD ... (kube-proxy) 👉 KUBE-FORWARD contains -F
• iptables -N KUBE-FIREWALL (kubelet) 👉 KUBE-FIREWALL contains -F
• iptables -A cali-FORWARD ... (Calico) 👉 same story

-X has the same problem with the KUBE-SVC-<hash> / KUBE-SEP-<hash> chains, since the base32 hash can start with X.

So, as written, the rule fires on routine CNI and kube-proxy activity in pretty much any Kubernetes cluster.

The suggestion anchors the short flags on a whitespace boundary (startswith for the first position, contains " -F" for the later ones). That is the convention we already use elsewhere, see Netcat Remote Code Execution in Container in falco_rules.yaml (proc.cmdline contains " -e") and the curl_download macro further down in this same file. --flush and --delete-chain are long enough to be unambiguous, so plain contains is fine for them.

[leogr]

Suggested change

	(proc.name = systemctl and proc.args contains "stop" and
	(proc.args contains "falco" or proc.args contains "auditd" or
	proc.args contains "sysdig" or proc.args contains "osquery"))
	or
	(proc.name = service and proc.args contains "stop" and
	(proc.args contains "falco" or proc.args contains "auditd"))
	(proc.name = systemctl and
	(proc.args startswith "stop " or proc.args contains " stop ") and
	(proc.args contains "falco" or proc.args contains "auditd" or
	proc.args contains "sysdig" or proc.args contains "osquery"))
	or
	(proc.name = service and
	(proc.args endswith " stop" or proc.args contains " stop ") and
	(proc.args startswith "falco" or proc.args startswith "auditd"))

Same anchoring concern as above, milder here since both substrings have to match.

proc.args contains "stop" matches the verb anywhere in the args, so read-only queries like systemctl list-units --state=stopped 'falco*' fire too, since stopped contains stop. Anchoring on whitespace keeps systemctl stop falco and systemctl --no-block stop falco while dropping that class.

For service, the SysV syntax is service <unit> <verb> (i.e., service falco stop), so endswith " stop" is the natural anchor there.

Btw, systemctl disable and systemctl mask are arguably stronger signals than stop, since they survive a reboot. Not asking for it in this PR, just something we may want to add later 😇

[leogr]

May you move the new macro and rule below the Delete or rename shell history rule?

The # todo!: block right above belongs to that rule - it is about avoiding evt.arg* in the output when a rule spans more than one event type. Inserting here re-parents the comment to your macro, which is quite confusing, since your rule is spawned_process-only and exe_flags=%evt.arg.flags is exactly the right thing to have there.

[leogr]

Suggested change

	priority:
	WARNING
	priority: WARNING

Nit. 27 of the 31 existing rules in this file keep priority inline. The rule right below happens to be one of the 4 exceptions, so it is an easy one to pick up by accident.