Detection rules › Splunk
Cisco Isovalent - Kprobe Spike
This analytic detects excessive kernel probe (kprobe) events in a Kubernetes cluster over a short period of time. Kprobes are a Linux kernel debugging and instrumentation mechanism that allows dynamic monitoring and tracing of kernel functions and system calls. In containerized or cloud-native environments, kprobes are occasionally used for legitimate low-level diagnostics; however, monitoring a spike in kprobe activity is important because malware or attackers may abuse this mechanism to gain insights into the kernel, attempt privilege escalation, or tamper with host processes. More than 10 kprobe events within 5 minutes may indicate suspicious activity, such as an attacker probing the kernel through repeated system calls (e.g., nsenter, mount, sethostname). Such abnormal volume and frequency of kprobe usage within application pods or on nodes can signal container escape attempts or low-level tampering with the host, thereby representing a potential security threat.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Privilege Escalation | T1068 Exploitation for Privilege Escalation |
Rule body splunk
name: Cisco Isovalent - Kprobe Spike
id: 3df0e9a8-7d5e-4b2f-bcd7-bf93e671d1f2
version: 4
creation_date: '2026-01-05'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: production
type: Hunting
description: |
This analytic detects excessive kernel probe (kprobe) events in a Kubernetes cluster over a short period of time.
Kprobes are a Linux kernel debugging and instrumentation mechanism that allows dynamic monitoring and tracing of kernel functions and system calls.
In containerized or cloud-native environments, kprobes are occasionally used for legitimate low-level diagnostics; however, monitoring a spike in kprobe activity is important because malware or attackers may abuse this mechanism to gain insights into the kernel, attempt privilege escalation, or tamper with host processes.
More than 10 kprobe events within 5 minutes may indicate suspicious activity, such as an attacker probing the kernel through repeated system calls (e.g., nsenter, mount, sethostname).
Such abnormal volume and frequency of kprobe usage within application pods or on nodes can signal container escape attempts or low-level tampering with the host, thereby representing a potential security threat.
data_source:
- Cisco Isovalent Process Kprobe
search: |
`cisco_isovalent` process_kprobe.action!=""
| bin _time span=5m | rename process_kprobe.parent.pod.name as pod_name
| stats count as kprobe_count
values(process_kprobe.function_name) as functions
values(process_kprobe.process.binary) as binaries
values(process_kprobe.args{}.string_arg) as args
by pod_name _time
| where kprobe_count > 10 | `cisco_isovalent___kprobe_spike_filter`
how_to_implement: |
Requires Cisco Isovalent Runtime Security with kprobe tracing enabled and logs
forwarded into Splunk. Ensure that your Splunk Technology Add-on (TA) for Cisco
Security Cloud parses the kprobe JSON correctly. Tune the threshold based on
your workload baseline.
known_false_positives: |
Busy or noisy pods may legitimately produce bursts of kprobe events during normal
operation. Tune thresholds and filter by function_name to reduce false positives.
references:
- https://docs.isovalent.com/user-guide/sec-ops-visibility/process-execution/index.html
analytic_story:
- Cisco Isovalent Suspicious Activity
- VoidLink Cloud-Native Linux Malware
asset_type: Endpoint
mitre_attack_id:
- T1068
product:
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
category: endpoint
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/cisco_isovalent/kprobe_spike.log
source: not_applicable
sourcetype: cisco:isovalent
test_type: unit
Stages and Predicates
Stage 1: search
`cisco_isovalent` process_kprobe.action!=""
Stage 2: bucket
| bin _time span=5m
Stage 3: rename
| rename process_kprobe.parent.pod.name as pod_name
Stage 4: stats
| stats count as kprobe_count
values(process_kprobe.function_name) as functions
values(process_kprobe.process.binary) as binaries
values(process_kprobe.args{}.string_arg) as args
by pod_name _time
Stage 5: where
| where kprobe_count > 10
Stage 6: search
| `cisco_isovalent___kprobe_spike_filter`
Indicators
Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.
| Field | Kind | Values |
|---|---|---|
kprobe_count | gt |
|
process_kprobe.action | ne |
|
sourcetype | eq |
|