Post cover image

June 22, 2026

Detection Engineering Fundamentals for SOC Analysts

Detection Rules Development

ghosteye

4 min read

Detection Rules Development

https://tryhackme.com/room/detectionrulesdevelopment

Overview

This walkthrough covers the complete Detection Rules Development room on TryHackMe, where we build and tune detection rules in Elastic SIEM against a real attack scenario involving RDP brute-force, post-exploitation recon, and password spraying.

Tools Used:

  • Elastic Security (SIEM)
  • Kibana Discover
  • Sysmon (Event ID 1)
  • Windows Security Event Logs (Event ID 4625)
  • KQL (Kibana Query Language)
  • EQL (Event Query Language)

Attack Scenario Summary

The attacker:

  1. Brute-forced RDP to gain initial access
  2. Performed host reconnaissance using built-in Windows tools
  3. Conducted password spraying against domain accounts

The lab environment runs Elastic Stack with Sysmon and Windows event logs ingested via Filebeat.

Task 3 — Research Process

Finding the Attacker

Before writing any detection rule, we first researched the attack data in Kibana Discover.

Query used:

event.code: 1 AND (winlog.event_data.Image:*whoami* OR *net* OR *ipconfig* OR *systeminfo*)

Time range: Apr 27, 2026 → Apr 29, 2026

Q: What user executed the recon commands?

Answer Format: domain.thm\userFiltering on winlog.event_data.User across the results revealed:

tryhatme.thm\sysadmin

Finding the False Positive

Running the suggested query returned 22 results — but not all were attacker activity.

To isolate the false positive, I ran:

event.code:1 AND winlog.event_data.Image:*NET*

This revealed a legitimate Windows process being caught by the *net* wildcard:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngentask.exe

Why is this a false positive?

  • ngentask.exe is a legitimate .NET Framework background compilation process
  • It lives under C:\Windows\Microsoft.NET\ path
  • The wildcard *net* matched Microsoft.NET in the path — not a net command
  • It has nothing to do with attacker reconnaissance

Q: What is the Image of a false-positive identified in the results of the suggested query? Answer Format: Paste the full path, such as "C:\Windows\System32\net1.exe"

None 
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngentask.exe

Finding the Missing Recon Tool

The original query missed nltest.exe — a domain reconnaissance tool commonly used post-exploitation:

nltest /domain_trust

Q: What is the executable name of the recon tool used by the attacker that is missing in the suggested query?

Answer Format: The exact executable name, such as "whoami.exe"

None 
nltest.exe

Task 4 — Atomic Detections

Building the Custom Query Rule

After research, we refined the query to:

  • ✅ Remove the ngentask.exe false positive
  • ✅ Add the missing nltest.exe
  • ✅ Use precise field targeting

Refined KQL Query:

event.code: "1" AND (
  winlog.event_data.Image:*whoami* OR
  winlog.event_data.Image:*net.exe* OR
  winlog.event_data.Image:*ipconfig* OR
  winlog.event_data.Image:*systeminfo* OR
  winlog.event_data.Image:*nltest*
)

Key change: *net* → *net.exe* to exclude Microsoft.NET path matches.

Rule Configuration

Field Value Name T1059.001 - Suspicious Reconnaissance Command Execution Severity Low Risk Score 21 MITRE Tactic Discovery MITRE Technique T1082, T1087 Runs every 5 minutes Look-back time 1 minute

Rule Preview Results

Time range tested: Apr 28, 2026 @ 14:00 → Apr 28, 2026 @ 18:00

The Rule Preview showed 22 alerts using the original suggested query (including false positives from ngentask.exe and net1.exe).

None

**Q:**Considering that 1 alert was generated for each recon command performed by the attacker, how many alerts were generated?

22

Q: What is the name of the detection rule type responsible for creating atomic detections on Elastic?

Custom query

Task 5 — Stateful Detections (Password Spraying)

Building the Threshold Rule

Password spraying generates multiple failed logon attempts (Event ID 4625) across different usernames from the same source IP.

Query:

event.code: "4625" AND winlog.event_data.LogonType: "3"

Threshold configuration:

  • Group by: source.ip
  • Threshold count: ≥ 10
  • Unique values of: user.name ≥ 5

Finding the Attacker IP

In Discover, filtering on source.ip field statistics revealed the attacker IP with the highest failure count.

Q: What is the attack IP, and how many total failure attempts did the attacker IP have?

Answer Format: "IP, Failures", such as "192.168.1.1, 78"

Run this query and check source.ip field stats:

5.62.18.132, 50

event.code: "4625" AND winlog.event_data.LogonType: "3"
None 
1

(One alert fires because there is 1 attacker IP crossing the threshold)

Task 6 — Correlation-Based Detections (EQL)

EQL Sequence Rule

For detecting RDP brute-force followed by successful login, we used an EQL sequence rule combining failed logons → successful logon.

Q: What field would be the best to be configured as a suppression field for your detection?

source.ip

Suppressing on source.ip ensures only 1 alert fires per attacker IP regardless of how many sequence matches occur.

Q: How many usernames did the attacker test?

10

Q: Removing the with runs condition from the EQL sequence would reduce the number of duplicate alerts. What type of alerts would your detection be more susceptible to generating with that change?

Answer Format: True Positive

False Positive

Removing with runs means the sequence triggers on the first failed logon + success, which includes legitimate users mistyping passwords.

Task 7 — Anomaly Detections (ML)

Q: What Elastic rule type uses anomaly detection jobs and statistical baselines to identify deviations from normal activity?

Machine Learning

Q: A user who normally logs in between 08:00 and 18:00 authenticates at 03:00. This data point is only abnormal because of the timing context. What type of anomaly is this?

Contextual

The data point is only abnormal because of timing context — not the action itself.

Task 8 — Detection Tuning

Finding the Attacker's LogonId

From the Sysmon process creation logs, every recon command shared the same LogonId:

"winlog.event_data.LogonId": ["0x557e9"]

This confirms all commands were executed in the same RDP session.

Q: What is the attacker's LogonId?

0x557e9

Tuning Strategy

The final task converts the atomic rule into a threshold-based rule using winlog.event_data.LogonId as the grouping field — only alerting when 3+ recon commands run in the same session.

Q: What type of tuning strategy did you apply in this task?

Full Rework

Key Takeaways

  1. Always research before writing rules — the *net* wildcard caught Microsoft.NET framework processes as false positives
  2. Atomic rules are fast but noisy — use threshold/correlation rules for higher fidelity
  3. LogonId is a powerful correlation field — links all attacker activity in one session
  4. Rule Preview is essential — always test with historical attack data before deploying
  5. ngentask.exe is a common false positive in environments with .NET applications

Detection Engineering Workflow Summary

Research → Build → Test → Tune → Deploy
    ↓          ↓       ↓       ↓        ↓
Discover   KQL Rule  Preview  Refine  Enable

Written based on hands-on lab work in TryHackMe Detection Rules Development room. All findings verified in live Elastic SIEM environment.