Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new(rules): introduce rule to detect drop and execute pattern in cont… #20

Merged
merged 3 commits into from
Mar 15, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 26 additions & 2 deletions rules/falco_rules.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@

# Starting with version 8, the Falco engine supports exceptions.
# However the Falco rules file does not use them by default.
- required_engine_version: 13
- required_engine_version: 16

# Currently disabled as read/write are ignored syscalls. The nearly
# similar open_write/open_read check for files being opened for
Expand Down Expand Up @@ -490,6 +490,30 @@
WARNING
tags: [host, container, filesystem, mitre_discovery, T1546.004]

# List of allowed container images that are known to execute binaries not part of their base image.
# Users can use this list to better tune the rule below (i.e reducing false positives) by considering their workloads,
# since this requires application specific knowledge.
- list: known_drop_and_execute_containers
items: []

- rule: Drop and execute new binary in container
desc:
Detect if an executable not belonging to the base image of a container is being executed.
The drop and execute pattern can be observed very often after an attacker gained an initial foothold.
is_exe_upper_layer filter field only applies for container runtimes that use overlayfs as union mount filesystem.
condition: >
spawned_process
and container
and proc.is_exe_upper_layer=true
and not container.image.repository in (known_drop_and_execute_containers)
output: >
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the output is a bit too much.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would you drop from here?

Executing binary not part of base image (user=%user.name user_loginuid=%user.loginuid user_uid=%user.uid comm=%proc.cmdline exe=%proc.exe container_id=%container.id
image=%container.image.repository proc.name=%proc.name proc.sname=%proc.sname proc.pname=%proc.pname proc.aname[2]=%proc.aname[2] exe_flags=%evt.arg.flags
proc.exe_ino=%proc.exe_ino proc.exe_ino.ctime=%proc.exe_ino.ctime proc.exe_ino.mtime=%proc.exe_ino.mtime proc.exe_ino.ctime_duration_proc_start=%proc.exe_ino.ctime_duration_proc_start
proc.exepath=%proc.exepath proc.cwd=%proc.cwd proc.tty=%proc.tty container.start_ts=%container.start_ts proc.sid=%proc.sid proc.vpgid=%proc.vpgid evt.res=%evt.res)
priority: CRITICAL
tags: [container, mitre_persistence, TA0003]

- macro: user_known_cron_jobs
condition: (never_true)

Expand Down Expand Up @@ -3335,4 +3359,4 @@

# Application rules have moved to application_rules.yaml. Please look
# there if you want to enable them by adding to
# falco_rules.local.yaml.
# falco_rules.local.yaml.