Detection Alert on a Process Exhibiting CPU Spike
This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/01/26"
3maturity = "production"
4updated_date = "2026/03/09"
5
6[rule]
7author = ["Elastic"]
8description = """
9This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process
10ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit
11payload execution, or abuse of system resources following initial compromise.
12"""
13from = "now-9m"
14interval = "5m"
15language = "esql"
16license = "Elastic License v2"
17name = "Detection Alert on a Process Exhibiting CPU Spike"
18setup = """## Setup
19
20This rule requires host CPU metrics collected via the Elastic Agent **System** integration.
21
22### System Metrics Integration Setup
23The System integration collects host-level metrics such as CPU usage, load, memory, and process statistics and sends them to Elasticsearch using Elastic Agent.
24
25#### Prerequisite Requirements:
26- Elastic Agent managed by Fleet
27- A Fleet Server configured and reachable
28 Refer to the Fleet Server setup guide:
29 https://www.elastic.co/guide/en/fleet/current/fleet-server.html
30
31#### The following steps should be executed in order to enable CPU metrics collection:
32- Go to the Kibana home page and click **Add integrations**.
33- In the search bar, enter **System** and select the **System** integration.
34- Click **Add System**.
35- Configure an integration name and optionally add a description.
36- Under **Metrics**, ensure the following datasets are enabled:
37 - `system.cpu`
38 - `system.load` (optional but recommended)
39 - `system.process` (optional, if process-level CPU is required)
40- Review optional and advanced settings as needed.
41- Add the integration to an existing agent policy or create a new agent policy.
42- Deploy the Elastic Agent to the hosts from which CPU metrics should be collected.
43- Click **Save and Continue** to finalize the setup.
44
45#### Validation
46After deployment, verify CPU metrics ingestion by confirming the presence of documents in:
47- `metrics-system.cpu-*`
48- `metrics-system.load-*` (if enabled)
49
50For more details on the System integration and available metrics, refer to the documentation:
51https://docs.elastic.co/integrations/system
52"""
53risk_score = 73
54rule_id = "df9c0e92-5dee-4f1d-a760-3a5c039e4382"
55severity = "high"
56tags = [
57 "Use Case: Threat Detection",
58 "Rule Type: Higher-Order Rule",
59 "Resources: Investigation Guide",
60 "Domain: Endpoint",
61 "Tactic: Impact"
62]
63timestamp_override = "event.ingested"
64type = "esql"
65
66query = '''
67FROM metrics-*, .alerts-security.* METADATA _index
68| where not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
69| eval
70 // processes with more than 70% total CPU use
71 cpu_metrics_pids = CASE(_index like ".ds-metrics-system.process-*" and system.process.cpu.total.norm.pct >= 0.7, process.pid, null),
72 // any security alert with process.name and ID populated excluding low severity ones
73 alerts_pids = CASE(_index like ".internal.alerts-security.*" and kibana.alert.rule.name is not null and process.name is not null and process.pid is not null and host.id is not null and kibana.alert.risk_score > 21, process.pid, null)
74| stats pid_with_cpu_spike = COUNT_DISTINCT(cpu_metrics_pids), pid_with_alerts = COUNT_DISTINCT(alerts_pids),
75 Esql.max_cpu_pct = MAX(system.process.cpu.total.norm.pct),
76 Esql.alerts = VALUES(kibana.alert.rule.name),
77 Esql.process_hash_sha256 = VALUES(process.hash.sha256),
78 process_path = VALUES(process.executable),
79 parent_process_path = VALUES(process.parent.executable),
80 user_name = VALUES(user.name),
81 host_name = VALUES(host.name),
82 cmdline = VALUES(process.command_line) by process.pid, process.name, host.id
83| where pid_with_cpu_spike > 0 and pid_with_alerts > 0
84// populate fields to use in rule exceptions
85| eval process.hash.sha256 = MV_FIRST(Esql.process_hash_sha256),
86 process.executable = MV_FIRST(process_path),
87 process.parent.executable = MV_FIRST(parent_process_path),
88 process.command_line = MV_FIRST(cmdline),
89 user.name = MV_FIRST(user_name),
90 host.name = MV_FIRST(host_name)
91| KEEP user.name, host.id, host.name, process.*, Esql.*
92| where `process.executable` != "C:\\Program Files\\ESET\\ESET Security\\ekrn.exe" and
93 `process.executable` != "C:\\Windows\\System32\\CompatTelRunner.exe" and
94 `process.executable` != "C:\\Program Files\\UiPath\\Studio\\UiPath.ActivityCompiler.CommandLine.exe"
95'''
96note = """## Triage and analysis
97
98### Investigating Detection Alert on a Process Exhibiting CPU Spike
99
100This rule identifies processes that both triggered a security alert and exhibited unusually high CPU utilization on the
101same host and process ID within a short time window. This combination may indicate malicious execution, resource abuse, or
102post-compromise activity.
103
104### Possible investigation steps
105- Review the correlated alert(s) to understand why the process was flagged by Elastic Defend.
106- Examine the process name, command line, and SHA-256 hash to determine whether the process is expected or known to be malicious.
107- Validate the observed CPU usage and duration to determine whether the spike is abnormal for this process and host.
108- Check for related process activity such as parent/child processes, suspicious process spawning, or privilege escalation attempts.
109- Review additional host telemetry including:
110 - Network connections initiated by the process
111 - File creation or modification events
112 - Persistence mechanisms (services, scheduled tasks, registry keys)
113- Determine whether similar activity is observed on other hosts, which may indicate a broader compromise.
114
115### False positive analysis
116- Legitimate high-CPU processes such as software updates, backup agents, security scans, or system maintenance tasks.
117- Resource-intensive but benign applications (e.g., compilers, video encoding, data processing jobs).
118- Security tools or monitoring agents temporarily consuming high CPU.
119
120### Response and remediation
121- If malicious activity is confirmed, isolate the affected host to prevent further impact.
122- Terminate the offending process if safe to do so.
123- Remove any identified malicious binaries or artifacts and eliminate persistence mechanisms.
124- Apply relevant patches or configuration changes to remediate the root cause.
125- Monitor the environment for recurrence of similar high-CPU processes combined with security alerts.
126- Escalate the incident if multiple hosts or indicators suggest coordinated or widespread activity."""
127
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130
131[rule.threat.tactic]
132id = "TA0040"
133name = "Impact"
134reference = "https://attack.mitre.org/tactics/TA0040/"
Triage and analysis
Investigating Detection Alert on a Process Exhibiting CPU Spike
This rule identifies processes that both triggered a security alert and exhibited unusually high CPU utilization on the same host and process ID within a short time window. This combination may indicate malicious execution, resource abuse, or post-compromise activity.
Possible investigation steps
- Review the correlated alert(s) to understand why the process was flagged by Elastic Defend.
- Examine the process name, command line, and SHA-256 hash to determine whether the process is expected or known to be malicious.
- Validate the observed CPU usage and duration to determine whether the spike is abnormal for this process and host.
- Check for related process activity such as parent/child processes, suspicious process spawning, or privilege escalation attempts.
- Review additional host telemetry including:
- Network connections initiated by the process
- File creation or modification events
- Persistence mechanisms (services, scheduled tasks, registry keys)
- Determine whether similar activity is observed on other hosts, which may indicate a broader compromise.
False positive analysis
- Legitimate high-CPU processes such as software updates, backup agents, security scans, or system maintenance tasks.
- Resource-intensive but benign applications (e.g., compilers, video encoding, data processing jobs).
- Security tools or monitoring agents temporarily consuming high CPU.
Response and remediation
- If malicious activity is confirmed, isolate the affected host to prevent further impact.
- Terminate the offending process if safe to do so.
- Remove any identified malicious binaries or artifacts and eliminate persistence mechanisms.
- Apply relevant patches or configuration changes to remediate the root cause.
- Monitor the environment for recurrence of similar high-CPU processes combined with security alerts.
- Escalate the incident if multiple hosts or indicators suggest coordinated or widespread activity.
Related rules
- Multiple Alerts on a Host Exhibiting CPU Spike
- Potential Malicious PowerShell Based on Alert Correlation
- Hosts File Modified
- Newly Observed Process Exhibiting High CPU Usage
- Unusual Discovery Signal Alert with Unusual Process Command Line