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.