9 releases

new 0.3.0 Nov 14, 2024
0.2.1 Oct 4, 2024
0.2.0 Jul 29, 2024
0.1.5 Jul 16, 2024
0.1.2 Apr 11, 2024

#207 in Debugging

Download history 161/week @ 2024-07-29 5/week @ 2024-08-05 6/week @ 2024-08-12 4/week @ 2024-09-09 27/week @ 2024-09-16 41/week @ 2024-09-23 139/week @ 2024-09-30 26/week @ 2024-10-07 33/week @ 2024-10-14 5/week @ 2024-10-21 8/week @ 2024-11-04 113/week @ 2024-11-11

127 downloads per month

GPL-3.0 license

5.5MB
5.5K SLoC

Crates.io Version GitHub Workflow Status (with event) Documentation Documentation

Description

This project is a Rust implementation of the Gene project initially written in Go. The main objective of this project is to embed a security event scanning engine to Kunai. Even though it has been built for a specific use case, the code in this library is completely re-usable for other log scanning purposes.

This re-implementation was also the occasion to completely rework the rule format, to make it simpler, better structured and easier to write. It is now using the YAML document format to encode rule information.

name: mimic.kthread
meta:
    tags: [ 'os:linux' ]
    attack: [ T1036 ]
    authors: [ 0xrawsec ]
    comments:
        - tries to catch binaries masquerading kernel threads
match-on:
    events:
        # we match kunai events execve and execve_script
        kunai: [1,2]
matches:
    # 0x200000 is the flag for KTHREAD
    $task_is_kthread: .info.task.flags &= '0x200000'
    # common kthread names 
    $kthread_names: .info.task.name ~= '^(kworker)'
# if task is NOT a KTHREAD but we have a name that looks like one
condition: not $task_is_kthread and $kthread_names
severity: 10

Benchmarks

Even though the following benchmarks were made with real detection rules and real security events performances are indicative. I would say that the throughput is not bad, at least to fulfill the main objective of this project. The most important aspect being that this library does not become the bottleneck of the program in which it is embedded.

To determine whether this library might be a bottleneck for your application, try to evaluate the number of events you want to scan per second and see if it is above the processing throughput.

Engine loaded with hundred-ish rules (1 thread)

Number of scanned events: 1001600 -> 1327.72 MB
Number of loaded rules: 127
Scan duration: 1.279534249s -> 1037.66 MB/s -> 782784.83 events/s
Number of detections: 550

Engine loaded with thousand-ish rules (1 thread)

Number of scanned events: 1001600 -> 1327.72 MB
Number of loaded rules: 1016
Scan duration: 9.535205107s -> 139.24 MB/s -> 105042.31 events/s
Number of detections: 550

Dependencies

~6–8MB
~150K SLoC