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:
- Brute-forced RDP to gain initial access
- Performed host reconnaissance using built-in Windows tools
- 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*)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\sysadmintryhatme.thm\sysadminFinding 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*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.exeC:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngentask.exeWhy is this a false positive?
ngentask.exeis a legitimate .NET Framework background compilation process- It lives under
C:\Windows\Microsoft.NET\path - The wildcard
*net*matchedMicrosoft.NETin 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"
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngentask.exeC:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngentask.exeFinding the Missing Recon Tool
The original query missed nltest.exe — a domain reconnaissance tool commonly used post-exploitation:
nltest /domain_trustnltest /domain_trustQ: 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"
nltest.exenltest.exeTask 4 — Atomic Detections
Building the Custom Query Rule
After research, we refined the query to:
- ✅ Remove the
ngentask.exefalse 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*
)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).
**Q:**Considering that 1 alert was generated for each recon command performed by the attacker, how many alerts were generated?
2222Q: What is the name of the detection rule type responsible for creating atomic detections on Elastic?
Custom queryCustom queryTask 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"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"event.code: "4625" AND winlog.event_data.LogonType: "3"
Q: How many alerts were generated related to a password spraying pattern?
11(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.ipsource.ipSuppressing 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?
1010Q: 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 PositiveFalse PositiveRemoving 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 LearningMachine LearningQ: 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?
ContextualContextualThe 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"]"winlog.event_data.LogonId": ["0x557e9"]This confirms all commands were executed in the same RDP session.
Q: What is the attacker's LogonId?
0x557e90x557e9Tuning 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 ReworkFull ReworkKey Takeaways
- Always research before writing rules — the
*net*wildcard caughtMicrosoft.NETframework processes as false positives - Atomic rules are fast but noisy — use threshold/correlation rules for higher fidelity
- LogonId is a powerful correlation field — links all attacker activity in one session
- Rule Preview is essential — always test with historical attack data before deploying
ngentask.exeis a common false positive in environments with .NET applications
Detection Engineering Workflow Summary
Research → Build → Test → Tune → Deploy
↓ ↓ ↓ ↓ ↓
Discover KQL Rule Preview Refine EnableResearch → Build → Test → Tune → Deploy
↓ ↓ ↓ ↓ ↓
Discover KQL Rule Preview Refine EnableWritten based on hands-on lab work in TryHackMe Detection Rules Development room. All findings verified in live Elastic SIEM environment.