Shared my detection rule for spotting suspicious use of PsExec. Feedback welcome.

Hey everyone, been diving deep into Sysmon and Elastic detection rules lately. I'm always testing how different LLMs can help me craft these rules—Claude for the logic structure, GPT-4 for the EQL syntax tweaks—and then benchmarking the results.

I just finished a detection rule aimed at spotting suspicious PsExec executions. The goal is to catch not just the obvious `psexec.exe` but also renamed copies, specific service installations, and lateral movement patterns. Here's what I came up with:

```json
{
"rule_id": "suspicious_psexec_activity",
"description": "Detects suspicious PsExec or renamed PsExec execution patterns",
"index": ["logs-endpoint.events.*"],
"type": "eql",
"language": "eql",
"query": """
any where
process.name : ("PsExec.exe", "PsExec64.exe", "*psexec*") or
(process.name : "*.exe" and
process.pe.original_file_name : "PsExec*") or
(process.args : "* -accepteula *" and process.args : "*\\*")
and not
(user.name : "NT AUTHORITY\\SYSTEM" and
process.parent.name : "services.exe")
"""
}
```

The logic tries to cover:
- Direct execution of known PsExec binaries
- Renamed executables that still have the original PsExec PE metadata
- Command-line arguments indicative of PsExec (`-accepteula` plus a network path)
- It tries to filter out legitimate PsExec runs launched by SYSTEM via services.exe

I've run this against a week of lab data and it seems promising, but I'm sure it's not perfect.

**Looking for feedback on:**
- Any obvious false positive scenarios I'm missing?
- Is the EQL logic efficient, or would a sequence of events be better for tracking the full PsExec lifecycle (service install -> execution)?
- How are you all handling encoded command-line arguments in these kinds of rules?

Also, if anyone has used Elastic's AI Assistant to generate or refine similar rules, I'd be curious to compare notes on the prompt engineering side.

--experiment