Scenario "auditd-postexploit-pkill" filter matches pgrep, not pkill (name/filter mismatch)

[Githopp192]

What happened?

Description

The scenario crowdsecurity/auditd-postexploit-pkill is named and described as
detecting pkill execve bursts, but its actual filter matches pgrep, not
pkill. The scenario's own source comment appears to acknowledge this:

https://github.com/crowdsecurity/hub/blob/master/scenarios/crowdsecurity/auditd-postexploit-pkill.yaml

type: leaky
name: crowdsecurity/auditd-postexploit-pkill
description: "Detect post-exploitation behaviour : pkill execve bursts"
#we're looking for the EXCVE syscalls to 'pkill' (which is actually pgrep)
filter: evt.Meta.log_type == 'execve' && evt.Meta.exe == '/usr/bin/pgrep'
groupby: evt.Meta.ppid
leakspeed: 1s
capacity: 5
blackhole: 1m

The filter checks evt.Meta.exe == '/usr/bin/pgrep' exclusively. As shipped:

• A real pkill execve (/usr/bin/pkill) never triggers this scenario at all.
• A pgrep execve is what actually triggers it, even though the scenario's
  name and description say "pkill".

For comparison, the sibling scenario crowdsecurity/auditd-postexploit-rm
correctly lists both real binary paths for the same tool:

filter: evt.Meta.exe in ['/usr/bin/rm', '/bin/rm']

Impact

Any alert from crowdsecurity/auditd-postexploit-pkill is actually reporting
a pgrep execution, not a pkill execution.

This is confusing when triaging alerts (the alert metadata shows comm=pgrep, exe=/usr/bin/pgrep,
which looks inconsistent with a scenario literally named "pkill"), and it also
means genuine pkill post-exploitation activity is currently not detected by
this scenario at all.

.

What did you expect to happen?

Suggested fix

One of:

1. Fix the filter to actually match pkill (e.g.
   evt.Meta.exe in ['/usr/bin/pkill', '/bin/pkill']), and add a separate
   scenario for pgrep if that detection is also wanted, or

2. Rename the scenario (and description) to reflect that it detects pgrep
   bursts, if that was the actual intent, or

3. Expand the filter to cover both binaries under one scenario, with the
   name/description updated accordingly.

How can we reproduce it (as minimally and precisely as possible)?

Any alert from crowdsecurity/auditd-postexploit-pkill is actually reporting
a pgrep execution, not a pkill execution.

Anything else we need to know?

Environment

Observed on CrowdSec running the auditd collection on a Linux host (auditd
rule key mitre_post_login_exec, -S execve). Alert metadata consistently
showed comm=pgrep, exe=/usr/bin/pgrep for every fired
auditd-postexploit-pkill alert investigated

Crowdsec version

version: v1.7.8-rpm-pragmatic-amd64-63227459
Codename: alphaga
BuildDate: 2026-05-11_12:36:32
GoVersion: 1.26.2
Platform: linux
libre2: C++
User-Agent: crowdsec/v1.7.8-rpm-pragmatic-amd64-63227459-linux
Constraint_parser: >= 1.0, <= 3.0
Constraint_scenario: >= 1.0, <= 3.0
Constraint_api: v1
Constraint_acquis: >= 1.0, < 2.0
Built-in optional components: cscli_setup, datasource_appsec, datasource_cloudwatch, datasource_docker, datasource_file, datasource_http, datasource_journalctl, datasource_k8s-audit, datasource_kafka, datasource_kinesis, datasource_loki, datasource_s3, datasource_syslog, datasource_victorialogs, datasource_wineventlog, db_mysql, db_postgres, db_sqlite

OS version

On Linux:

NAME="AlmaLinux"
VERSION="8.10 (Cerulean Leopard)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.10"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.10 (Cerulean Leopard)

Enabled collections and parsers

No response

Acquisition config

No response

Config show

Details

Global:

• Configuration Folder : /etc/crowdsec

• Data Folder : /var/lib/crowdsec/data

• Hub Folder : /etc/crowdsec/hub

• Notification Folder : /etc/crowdsec/notifications

• Simulation File : /etc/crowdsec/simulation.yaml

• Log Folder : /var/log

• Log level : info

• Log Media : file
  Crowdsec:

• Acquisition File : /etc/crowdsec/acquis.yaml

• Parsers routines : 1

• Acquisition Folder : /etc/crowdsec/acquis.d
  cscli:

• Output : human

• Hub Branch :
  API Client:

• URL : http://127.0.0.1:8080/

• Login : xxxx

• Credentials File : xxxx
  Local API Server:

• Listen URL : 127.0.0.1:8080

• Listen Socket :

• Profile File : xxxx

• Trusted IPs:

  • 127.0.0.1
  • ::1

• Database:

  • Type : sqlite
  • Path : xxxx
  • Flush age : 168h0m0s
  • Flush size : 5000

Prometheus metrics

Details

$ cscli metrics
# paste output here

Related custom configs versions (if applicable) : notification plugins, custom scenarios, parsers etc.

Details

[github-actions]

@Githopp192: Thanks for opening an issue, it is currently awaiting triage.

In the meantime, you can:

1. Check Crowdsec Documentation to see if your issue can be self resolved.
2. You can also join our Discord.
3. Check Releases to make sure your agent is on the latest version.

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.