EDR Detection Rules for 'Process Roulette' Behavior: Hunting for Random Killers

Hook: When endpoints start killing themselves, defenders need fast, reliable rules

Random process termination—what defenders call “process roulette”—is no longer just a prank or stress-test. In 2026 we see more threat actors, red teams and even careless automation inducing random or bulk process kills to cause disruption, hide traces, or deny service. If you manage EDR policy, you need concrete detection signatures, tuned heuristics, and a short, repeatable response playbook that your team can operationalize immediately.

Why this matters now (2025–2026 trends)

Late 2025 and early 2026 brought three factors that make process-termination campaigns a current operational risk:

• Increased availability of adversary tooling and AI-generated malicious scripts that implement randomized behavior to evade static detection.
• Wider adoption of eBPF and kernel-streaming telemetry in EDR vendors, enabling higher-fidelity syscall and process-access visibility.
• More ransomware and extortion groups intentionally use targeted process-killers to stop backup agents, AV services, or cloud agents before the main payload.

Practical takeaway: Detection that relied solely on file hashes or single event signatures is insufficient; you need behavior-based rules that correlate process-access, termination events, and anomalous timing/frequency.

Threat model & common tactics

Adversaries or misbehaving tooling implementing process roulette typically aim to:

• Cause endpoint instability or denial-of-service.
• Evade defense by terminating security processes (AV, EDR, backup agents).
• Disrupt incident response and forensic collection.

Common techniques include calling Win32 APIs like TerminateProcess, using taskkill.exe, injecting threads into target processes, or invoking kill on Linux with randomized PID selection. Detection needs to track both the act (kill) and the means (API, binary, syscall).

High-level EDR detection strategy

1. Capture granular telemetry: process creation (Sysmon/Evtx 4688), process termination (Sysmon 5 / Evtx 4689), process access (Sysmon 10), and kernel syscall traces (eBPF / Auditd / ETW).
2. Create behavioral heuristics that combine frequency, cross-process targeting, and privilege elevation signals.
3. Complement behavior rules with static indicators (YARA/Sigma) where a tool family is known.
4. Define automated containment actions (isolate host, quarantine binary, revoke credentials) and a human-in-the-loop escalation path.

Concrete detection signatures and queries (Windows)

Below are tested queries and rule templates you can drop into MDE advanced hunting, Elastic, Splunk, or convert into Sigma. They assume you ingest Sysmon and Windows Security logs.

Kusto (Microsoft Defender/Advanced Hunting)

// Detect processes that call OpenProcess+PROCESS_TERMINATE or call NtTerminateProcess repeatedly
DeviceEvents
| where EventID in (1,5,10) // 1:ProcessCreate, 5:ProcessTerminate, 10:ProcessAccess
| where Timestamp > ago(1d)
| extend pid = ProcessId, name = FileName, cmd = ProcessCommandLine
| where EventID == 10 and tostring(AdditionalFields) contains "PROCESS_TERMINATE"
| summarize TerminationAccessCount = count() by InitiatingProcessFileName, InitiatingProcessId, bin(Timestamp, 1h)
| where TerminationAccessCount >= 5
| order by TerminationAccessCount desc

Why this works: Sysmon EventID 10 shows when a process requested access to another process; repeated requests for PROCESS_TERMINATE indicate targeted killing behavior.

Sigma rule (generic)

title: Repeated process termination access attempts (Process Roulette)
id: epp.rule.process_roulette
status: experimental
description: Detects processes requesting PROCESS_TERMINATE access multiple times within a short window
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 10
    AdditionalFields|contains: 'PROCESS_TERMINATE'
  timeframe: 1h
  condition: selection | count() by InitiatingProcessFileName, InitiatingProcessId > 4
falsepositives:
  - Legitimate admin tools during patching or orchestration
level: high

Splunk SPL (example)

index=sysmon sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventID=10
| eval targetAccess=mvfind(AdditionalFields,"PROCESS_TERMINATE")
| where targetAccess>=0
| stats count by InitiatingProcessFileName, InitiatingProcessId, _time span=1h
| where count >= 5

Linux detection signatures (auditd, eBPF, Falco)

Linux requires syscall-level monitoring. Focus on kill(2), tgkill, tkill, and sequences of SIGKILL or SIGTERM issued to many PIDs within short windows.

Falco rule (example)

- rule: Multiple kill calls by same process
  desc: Detects a process issuing many kill syscalls within a short window
  condition: proc.name != kbagent and evt.type in (kill) and proc.kname != bash
  output: "Process %proc.name (pid=%proc.pid) called kill %evt.count times in %window seconds"
  priority: Critical
  condition: evt.type = kill and evt.count >= 5 and evt.time.delta <= 60

Auditd rule (augenrules)

-a always,exit -F arch=b64 -S kill -F key=process_kill
-a always,exit -F arch=b64 -S tgkill -F key=process_kill

Then search audit logs for repeated kills by the same auid or exe in a short window. Correlate with pam/sshd sessions to find the operator.

YARA and static detection for known 'process-roulette' binaries

Use YARA to detect embedded strings or unique code patterns in tools that implement randomized kills. Below is a conservative example—tune to your environment.

rule process_roulette_binary
{
  meta:
    author = "SOC Team"
    date = "2026-01-18"
    description = "Detect binaries with strings indicating randomized process killing"
  strings:
    $s1 = "PROCESS_TERMINATE"
    $s2 = "rand("
    $s3 = "taskkill"
  condition:
    (any of ($s1, $s2, $s3)) and filesize < 5MB
}

Heuristics: behavioral rules to reduce false positives

Static rules alone trigger noise. Combine the following heuristics in your EDR rules engine to raise precision:

• Frequency threshold: ≥5 termination attempts or system kill syscalls by the same initiator within 5–60 minutes.
• Cross-target breadth: Termination attempts against ≥3 different critical processes (AV, backup, agent, sshd) in a short window.
• Privilege context: Initiating process has elevated privileges (SeDebugPrivilege on Windows or root effective uid on Linux).
• Tooling and parentage: Initiator is a scripting host (PowerShell, python) or an unexpected parent like explorer spawning taskkill-like behavior.
• Randomized timing signature: Inter-kill intervals follow non-regular distribution (statistically varying), indicating randomness vs. scheduled orchestration.
• Preceding reconnaissance: Recent process discovery, netstat, or credential usage from same initiator—suggests adversary chain.

Indicators of Compromise (IOCs) examples

Use these IOC categories in your threat intelligence feeds and correlate with EDR events:

• Filenames: processroulette.exe, randkill.exe, chaos_killer.py (many legitimate tools will differ—validate).
• Command lines: taskkill /F /PID %d invoked in loops; PowerShell scripts with repeated Stop-Process -Id.
• Syscalls: High volume of kill syscalls, or Windows ProcessAccess requests for termination rights.
• Network: Outbound traffic to C2 around time of killing may indicate coordination.

Response playbook: detection to recovery (operational steps)

Below is a compact, prioritized playbook you can operationalize in your incident response runbook and automate partially in EDR playbooks.

1) Triage & validation (0–10 minutes)

• In EDR alert, collect the initiating process, PID, parent PID, user context, and timestamp.
• Confirm multiple termination accesses/kill syscalls from telemetry within the defined window.
• Check for attempted termination of security or backup agents. If true, escalate to high immediately.

2) Containment (10–30 minutes)

• Isolate the host at the network level via EDR (cut off remote access) to prevent lateral commands.
• Quarantine or block the initiating binary hash and associated scripts across endpoints.
• Disable the account or revoke session tokens if a credentialed user caused the kills.

3) Evidence collection (parallel)

• Collect memory capture of the initiating process and the system (EDR memory snapshot).
• Export Sysmon / auditd logs for the time window; gather process trees and command-line artifacts.
• Hash and preserve suspect binaries for YARA analysis.

4) Eradication and recovery

• If the process is malicious or unauthorized, remove the binary, rotate affected credentials, and restore terminated services from known-good images.
• Reboot and reimage if persistence or kernel manipulation is detected.

5) Post-incident actions

• Update EDR rules with the new indicators and heuristics; tune thresholds to reduce similar false positives.
• Run a hunt for the same IOC across your fleet for lateral infections or pre-existing automation.
• Document lessons learned and adjust controls—consider stricter process creation policies (AppLocker/WDAC) for sensitive hosts.

Example automated EDR response playbook (pseudo-logic)

// Trigger: Sysmon Event 10 with PROCESS_TERMINATE OR auditd kill syscall
if (initiator.terminate_count >= 5 within 15 minutes) AND (targets include security agent or breadth >=3)
{
  action.isolateHost();
  action.quarantineFile(initiator.binaryHash);
  action.collectMemory(initiator.pid);
  notify(SOC, "High - Process Roulette detected on host X");
}
else if (initiator.terminate_count >= 5)
{
  action.alert("Medium - Possible random kills");
  add_to_watchlist(initiator);
}

False positive mitigation & tuning

Process-heavy orchestration (patch windows, automated deployments) will trip naïve rules. Use these techniques to tune:

• Whitelist approved orchestrators (PatchMgmt, Chef, Ansible agent bins) but require explicit owner/account validation.
• Use a burst-frequency model rather than absolute counts (e.g., bursts of kills outside scheduled maintenance windows).
• Correlate with SSO/Privileged Access Manager logs—if admin job ran from a scheduled system instead of interactive session, reduce severity accordingly.

Testing & validation—how to safely evaluate your rules

Create a controlled lab to validate detection and avoid impacting production:

1. Build isolated VMs with representative agents.
2. Use benign test tooling that simulates random kills (open-source process-roulette projects or custom scripts) and label them as test artifacts.
3. Run red-team scenarios that attempt to kill security and backup agents to confirm priority escalation.

Note: In production, never run destructive tests on live systems without written change control and stakeholder approval.

Advanced strategies & 2026 recommendations

Beyond detection signatures, adopt these advanced controls that became practical in 2025–2026:

• eBPF-based blocking (Linux): use eBPF programs to enforce a policy that only specific supervisors can issue kill syscalls to critical processes.
• Process access hardening on Windows: use LSA and token policies to limit which identities can request PROCESS_TERMINATE on security agents.
• Endpoint denial-of-service mitigations: add monitors to trigger failover for backup and AV services if killed repeatedly (auto-restart or host isolation).
• Integrate with change-management: tie EDR suppressions/whitelists to CMDB items—temporary exceptions expire automatically.
• Telemetry retention: ensure you retain detailed process access logs for at least 90 days to investigate slow or delayed attacks (compliance-driven retention is increasingly required in 2026).

Compliance and privacy considerations

Telemetry collection for hunting must respect privacy and regulatory constraints (GDPR, internal policy). When storing memory images or user command-lines, redact or isolate PII, and maintain forensic chain-of-custody. In 2026, auditors expect documented purpose and retention schedules for endpoint telemetry—treat rule updates and hunts as auditable changes.

Playbook checklist for SOC owners

• Ingest Sysmon/auditd + kernel-level telemetry into EDR and SIEM.
• Deploy the provided KQL/Sigma/Falco rules and tune thresholds for your environment.
• Implement automated containment steps for high-confidence detections (isolate/quarantine/collect).
• Establish validation lab for safe testing of process-termination scenarios.
• Document retention and privacy controls for forensic artifacts.

Quick rule of thumb: If a non-admin script or user-initiated process is making repeated, randomized termination attempts—treat the event as suspicious until proven otherwise.

Final notes: balancing protection and availability

Process roulette events sit at the intersection of security and operations. Overly aggressive blocking can disrupt legitimate automation; under-detection can let attackers disable your defenses. The best defense in 2026 is a layered approach: fine-grained telemetry, behavior-driven EDR rules, automated but reversible containment, and an operationalized playbook for incident responders.

Actionable next steps (implement in 1 week)

1. Deploy Sysmon (Windows) and auditd/eBPF (Linux) profiles to collect process creation, termination, access, and kill syscalls.
2. Implement the KQL/Sigma/Falco rules above in your EDR/SIEM and set a watchlist for new alerts.
3. Create an automated containment playbook that isolates the host and quarantines the initiating binary for high-confidence alerts.

Call to action

If your EDR doesn't provide syscall/process-access telemetry or the ability to automate containment, prioritize that capability this quarter. Start by deploying the queries above in a test environment and schedule a tabletop incident drill simulating a process-termination campaign. Reach out to your EDR vendor for kernel-level event streaming (eBPF/ETW) and collaborate with your SOC to codify the playbook above into an automated workflow.

Need help implementing these rules in your stack? Contact your SOC or consult with specialists who can convert these rules into vendor-specific configurations, tune them against your environment, and run controlled validation drills.

Related Reading

• How Smart Lamps Can Transform Your Makeup Routine
• Deploying Secure, Minimal Linux Images for Cost-Effective Web Hosting
• Protecting Listener Privacy When Desktop AI Agents Touch Voice Files
• Buying Glasses on Sale: How to Evaluate Deals on Frames, Smart Lamps, and Tech Accessories
• How to Preserve Your MMO Memories: Archiving New World Before Servers Go Offline