elastic / elastic/detection-rules
[Rule Tuning] Potential Privilege Escalation via a Parent Process Sequence (eb8abab8-dea4-4903-a0ad-dfcb09224488)
- Dominant language
- Python
- Stars
- 2.7k
- Forks
- 696
- Avg merge
- 4d 17h
- Merged PRs (30d)
- 87
Description
## Rule Tuning Analysis
**Rule ID:** `eb8abab8-dea4-4903-a0ad-dfcb09224488`
**Rule Name:** Potential Privilege Escalation via a Parent Process Sequence
**Rule Type:** eql
---
### Classification
| Metric | Value |
|--------|-------|
| **Category** | NOISY_PERFORMANT |
| **Priority** | MEDIUM |
| **Tuning Score** | 62.07 |
| **Version Status** | ✅ Established (2 release cycles) |
---
### Alert Telemetry
| Metric | Value |
|--------|-------|
| Total Alerts (3d) | 46,189 |
| Unique Clusters | 3 |
| Cluster Coverage | 0.1% |
| Daily Average | 15396 |
| Days Active | 3 |
| Coefficient of Variation | 0.45 (MODERATE) |
---
### Analysis Flags
- 🔴 Noisy on Latest Version: ✅ Yes
- 🔴 Widespread False Positive: ❌ No
- ⚠️ Version Regression: ❌ No
- ⚠️ Stale and Noisy: ❌ No
- ⚠️ Low Version / High Volume: ❌ No
- ℹ️ Low Activity: ❌ No
---
### Recommendation
**Action:** Tighten the first EQL stage to require the suspicious writable path on `process.executable` only, then add targeted exclusions for the observed `.nvm` runtime and benign `pkexec` backlight helper pattern.
**Rationale:** This rule is producing very high noise on a small number of Linux clusters because the first EQL stage is too permissive for environments that legitimately run software from user home directories, and the second stage does not suppress at least one clearly benign root-transition helper. The samples show benign activity from `/home`-hosted runtimes such as `node` under `~/.nvm`, a home-based Python workflow, and a normal desktop brightness change via `pkexec /usr/libexec/csd-backlight-helper`; the safest fix is to tighten the writable-path logic so it applies to the executed binary itself and add targeted exclusions for the observed benign patterns rather than broad `/home` or `pkexec` suppression.
#### Query Modifications
**The first sequence stage is overly broad because a writable-path match on `process.parent.executable` is enough to seed the sequence, even when the actual executed binary is not in a writable location.** *(Impact: both)*
**Current:**
```sql
(
process.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or
process.parent.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*")
)
```
**Modify →**
```sql
[process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
user.id != "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and
process.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/user/*", "/var/run/user/*", "/home/*/*") and
not process.executable like "/home/*/.nvm/*"]
```
> This better matches the rule description, which says the process executable is in a user- or world-writable directory. It also removes a major source of benign matches from home-based parents. Event 1 (`~/.nvm/node`) and Event 5 (home-based automation) support the need to treat user-home runtimes more carefully.
**The second stage lacks a targeted suppression for a clearly benign desktop helper that legitimately changes UID to root.** *(Impact: accuracy)*
**Current:**
```sql
[process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and
user.id == "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and
not process.executable in ("/usr/bin/sudo", "/bin/sudo")]
```
**Modify →**
```sql
[process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and
user.id == "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and
not process.executable in ("/usr/bin/sudo", "/bin/sudo") and
not (process.name == "pkexec" and process.parent.executable == "/usr/libexec/csd-power" and
process.command_line like "pkexec /usr/libexec/csd-backlight-helper --set-brightness *")]
```
> Events 3 and 4 show a benign Cinnamon/desktop power-management path: `csd-power` launching `pkexec /usr/libexec/csd-backlight-helper --set-brightness ...`. Excluding this exact pattern preserves coverage for other `pkexec` abuse, including exploit activity that does not match this helper command line.
#### Exception Recommendations
**Add exception:** `process.executable` wildcard `"/home/*/.nvm/*"` *(Confidence: MEDIUM)*
> Event 1 shows a benign Node runtime launched from `/home/lrazubi/.nvm/versions/node/v25.9.0/bin/node` on one affected cluster. If this pattern is common in that environment, add it to the first sequence clause as `and not process.executable like "/home/*/.nvm/*"`. This is environment-specific and should not be treated as universal.
**Modify →**
```sql
and process.executable wildcard "/home/*/.nvm/*"
```
**Add exception:** `process.command_line` wildcard `"pkexec /usr/libexec/csd-backlight-helper --set-brightness *"` *(Confidence: HIGH)*
> Events 3 and 4 show a normal desktop brightness workflow using `pkexec /usr/libexec/csd-backlight-helper --set-brightness ...` from parent `/usr/libexec/csd-power`. This is a strong benign pattern for the second sequence clause. Safest insertion is the combined EQL exclusion `and not (process.name == "pkexec" and process.parent.executable == "/usr/libexec/csd-power" and process.command_line like "pkexec /usr/libexec/csd-backlight-helper --set-brightness *")` rather than excluding `pkexec` broadly.
**Modify →**
```sql
and process.command_line wildcard "pkexec /usr/libexec/csd-backlight-helper --set-brightness *"
```
**Add exception:** `process.parent.command_line` wildcard `"/usr/bin/python3 /home/administrator/security-news/worker/scripts/gpt-summary-orchestrator.py*"` *(Confidence: LOW)*
> Event 5 shows a home-based Python orchestration workflow tied to `/home/administrator/security-news/worker/scripts/gpt-summary-orchestrator.py`. If that single cluster continues to dominate alert volume after the broader query fix, add an environment-specific exclusion such as `and not process.parent.command_line like "/usr/bin/python3 /home/administrator/security-news/worker/scripts/gpt-summary-orchestrator.py*"` in the first clause. Use only if validated against raw source events because this is highly customer-specific.
**Modify →**
```sql
and process.parent.command_line wildcard "/usr/bin/python3 /home/administrator/security-news/worker/scripts/gpt-summary-orchestrator.py*"
```
#### Field-Level Recommendations
| Field | Value | Alert % | Cluster % | Confidence | Type |
|-------|-------|---------|-----------|------------|------|
| `process.executable` | `/home/*/.nvm/*` | 0.0% | 33.3% | MEDIUM | EXCEPTION |
| `process.command_line` | `pkexec /usr/libexec/csd-backli...` | 0.0% | 33.3% | HIGH | EXCEPTION |
| `process.parent.command_line` | `/usr/bin/python3 /home/adminis...` | 0.0% | 33.3% | LOW | EXCEPTION |
---
*This issue was generated by the GenAI Tradecraft Rule Tuning Advisor.*
*Analysis timestamp: 2026-08-02T06:56:19.897837*
Contributor guide
Assessment
This issue has not been assessed yet.