Try   HackMD

Falco Detections - Threat Modeling - drop+exec use case

Description and Motivation

Dropping an implant, making the file executable and executing the implant is amongst one of the oldest tricks. While memory based cyber attacks mostly circumvent touching disk, reliably detecting drifts, that is, a suspicious new executable is executed is often considered a crucial baseline detection.

Three Falco contributors have come to similar conclusions, that is, (1) it is at process startup where we need to fetch better kernel signals and (2) this old problem "drop+exec" has not yet been well addressed.

This document is for discussing the development of a more generic and robust solution to detect the classic drop an implant and execute it TTP called "drop+exec". In addition, perform threat modeling not limited to this use case, e.g. "fileless" attacks or malicious scripts run by interpreter …

Desired Outcome

Robust and stable Falco rules that work in new / unknown environments with acceptable FP (False Positives) rate, no FNs (False Negatives). Falco rules shall work especially in containers, hopefully also on the host. Threat actors reading this will need to work harder to circumvent new more robust detections.

"drop+exec" Discussion (file on disk)

@LucaGuerra, @loresuso, @incertum kicked off discussions in below PRs:

Reference libs issue that includes some engineering roadmap.

-> Come up with ways to correlated all those new signals and also leverage existing metadata fields around process collection.

Discuss new Falco rule based on new signals

Initial proposal @incertum (2022-11-10): A simple rule like the one proposed below should work well for most end users and environments. Working well means the new Falco rule does not generate too many logs and can be enabled by default. End users likely need some "anomaly detection" that at first can be performed off host. Time between ctime file change and proc clone was choosen to be very conservative for now. It's a paramter end users can tune. %evt.arg.flags also contains the information from the exe_writable signal, e.g. "EXE_WRITABLE|EXE_UPPER_LAYER"

- condition: proc.exe_ino.ctime_duration_proc_start <= 3600000000000
  macro: executable_drop_exec
- condition: proc.is_exe_upper_layer=true and proc.exe_ino.ctime_duration_pidns_start >= 10000000000
  macro: executable_new
- condition: spawned_process and container and executable_drop_exec and executable_new
  desc: New executable spawned in container (drop+exec)
  enabled: true
  output: '%container.id %container.image.repository %container.image.tag %evt.type
    %proc.aname[2] %proc.aname[3] %proc.cmdline %proc.cwd %proc.exepath
    %proc.loginshellid %proc.name %proc.pid %proc.pname %proc.ppid %proc.sid %proc.sname
    %proc.tty %proc.vpgid %user.loginuid %user.name %user.uid %proc.vpid
    %evt.arg.flags %fd.name %fd.type %evt.res %k8s.ns.name %k8s.pod.name %proc.exe_ino
    %proc.exe_ino.ctime %proc.exe_ino.mtime %proc.exe_ino.ctime_duration_proc_start 
    %proc.pidns_init_start_ts %proc.exe_ino.ctime_duration_pidns_start'
  priority: NOTICE
  rule: New executable spawned in container (drop+exec)
  tags:
  - filesystem
  - mitre_execution

"memfd+exec" Discussion (fileless)

@loresuso proposal:

To detect fileless execution done via the attack pattern memfd_create + execve, I think we have a few alternatives, each one with its pros and cons:

  1. when creating a file descriptor via memfd_create and then execute, we could try to detect the superblock magic upon execve event, similar to what we are trying to do with exe_upper_layer. I believe we might discover that:

    • the superblock magic is unique to fds created with this syscall. In this case we could set a new flag in the execve event. This would be ideal, but I am not so confident, since in the syscall implementation it seems that a generic shared memory is used. https://elixir.bootlin.com/linux/v5.19.9/source/mm/memfd.c#L266
      • @incertum: @loresuso only one way to find out, would you want to experiment?
    • the superblock magic is not enough for the detection, meaning that the same constant is reused in other use cases. This can lead to false positives, but we may have a way to treat them from userspace.
      • @incertum: No worries kernel side this will be a great signal, rest we fix in userspace!

  2. resolve the name of the executable on execve and check if it begins with memfd: . See https://elixir.bootlin.com/linux/v5.19.9/source/mm/memfd.c#L260. I really believe that this would work. However, we cannot blindly resolve the name upon each execve event (I am thinking about using d_path https://elixir.bootlin.com/linux/v5.19.9/source/fs/d_path.c#L264) because it has a cost, and we don't want to pay it for every execve event, it might slow down too much.

    • @incertum: small note in general would not worry too much about execve family syscalls, comparatively they happen really not that often compared to all file and dir related syscalls and the super noisy syscalls we have turned off for Falco anyways. If the superblock logic does not pan out I think we should still do it, we can optimize on other ends or maybe reverse it. Could there we a different logic where we know it's for sure a file and then not do the lookup? Like when we have an ino number it's a file or even easier when the path in filesystem is empty / null? We can pick either one since given the instruction limits in bpf we have the ino in the last filler but looked up path in first or second? Other projects seem to have it already implemented, so it may be fine in terms of lookup cost https://github.com/aquasecurity/tracee/blob/e53c5c0cd143a90a9e31469cc549a7cc62565306/pkg/ebpf/c/tracee.bpf.c#L2269

  3. Mix it up!! We could try to understand if the superblock magic can act as a good filter for trying resolving the name, so that we do it only when there is a bigger chance that fileless execution really took place!

    • @incertum: This is amazing and exactly how database queries perform pushdown optimizations! Let's do it, we should treat the kernel structures more as a database and do more cross-lookups. See above comment for a suggestion to simplify.
// pseudocode
if(sb_magic == MEMFD_MAGIC){
    name = d_path(...)
    if (name begins with "memfd"){
        set new exe_fileless flag
    }
}

These are just ideas, they might be completely wrong or maybe they are a candidate to start experimenting, feedback appreciated!

Userland exec - Process Injection / Process Hollowing Discussion (no new exec, most tricky scenario)

Some relevant references in this line:

Experiments / attempt that did not yet pan out:

  • @incertum: side note LD_PRELOAD env variable isn't that rare since it was mentioned as possibly easy signal
  • @incertum: Accessing another processe's proc maps file also not exactly rare

Data Modeling - Advanced Signals Correlations / Anomaly Detection

Likely won't get away without determining a pattern of past behavior of the applications that are running, and analyze behaviors outside the past behavior. There will be both data modeling challenges and software implementation challenges, the good news is similar problems have been solved in the industry before and we can build upon this. Needless to say let's start more basic and iterate.

Options and discussion TBA once we finish discussions around better kernel signals …

Last changed by 
 
Leonardo Grasso
0
2
373

Read more

FAL-01-004 Dependencies pulled via hard-coded HTTP links

Impact What kind of vulnerability is it? Who is impacted? This vulnerability might impact users or automated system that are building Falco from source. Basically, it was noticed that some dependencies in the CMake-files were download via hard-coded HTTP links. Since the dowload happened via a clear-text connection, an attacker with Man-in-the-Middle capabilities could spoof the connection to dowload malicius content instead of the legitimate dependencies. Patches Has the problem been patched? What versions should users upgrade to? The problem has been addressed by https://github.com/falcosecurity/falco/pull/774 on Aug 17, 2019.

Apr 8, 2021
Read more from Leonardo Grasso
Published on HackMD