Detection Rules Development TryHackMe!

Room: https://tryhackme.com/room/detectionrulesdevelopment

Executive Summary

This room introduces the fundamentals of detection engineering by teaching how to research attacker techniques before building reliable detection rules. Rather than jumping straight into writing detections, the room emphasizes understanding attacker behavior, identifying the appropriate log sources, recognizing common sources of false positives, and refining detection logic to improve accuracy. Throughout the practical exercises, participants investigate Windows process creation events, analyze reconnaissance activity, and learn why detection rules must balance broad visibility with precise matching.

Task 3: The Research Process

Before writing an effective detection rule, analysts must first understand how attackers behave within an environment. During the reconnaissance phase of an intrusion, attackers commonly execute built-in Windows utilities to gather information about the compromised system, enumerate users and groups, identify network configuration, and learn more about the surrounding environment. Since these utilities are legitimate administrative tools, the challenge lies in distinguishing malicious usage from normal system activity.

The recommended starting query focuses on Sysmon Event ID 1 (Process Creation), allowing analysts to inspect the executed process, command line, parent process, and user responsible for launching each command.

Question 1

What user executed the recon commands?

• Starting Query: Run this in Discover using KQL to filter all process creation logs related to common Windows tools:

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

Answer:

tryhatme.thm\sysadmin

Explanation

The first step is identifying who executed the reconnaissance commands. Filtering Sysmon process creation events reveals multiple built-in Windows utilities such as whoami.exe, net.exe, and related commands. Each event records the account responsible for launching the process.

Press enter or click to view image in full size

Within the event details, the User field shows:

User: tryhatme.thm\sysadmin

Because the same account consistently executed the sequence of reconnaissance commands, we can conclude that tryhatme.thm\sysadmin is the user responsible for the observed activity.

Question 2

What is the Image of a false-positive identified in the results of the suggested query?

Answer:

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

Explanation

The supplied query searches for process creation events containing keywords such as:

• whoami
• net
• ipconfig
• systeminfo

The problem lies in the wildcard search for *net*. Rather than matching only the Windows utility net.exe, the wildcard matches any occurrence of the string "net" within the entire executable path.

Press enter or click to view image in full size

As a result, the following legitimate Microsoft process is also returned:

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

This executable belongs to the Microsoft .NET Framework Native Image Generator and is unrelated to attacker reconnaissance. It appears only because the directory name Microsoft.NET contains the substring “net”.

This is a classic example of a false positive, where an overly broad detection query returns benign activity that matches the search pattern but is not actually malicious.

Question 3

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

KQL searches:

event.code:1 AND winlog.event_data.User:"tryhatme.thm\\sysadmin"

Answer:

nltest.exe

Explanation

The original detection query only searched for a small set of common reconnaissance utilities:

• whoami
• net
• ipconfig
• systeminfo

To determine whether the attacker executed additional reconnaissance commands, we broaden the search to include all process creation events for the compromised user:

event.code:1 AND winlog.event_data.User:"tryhatme.thm\\sysadmin"

This query returns every process launched by the sysadmin account during the investigation timeframe. Among the results are many legitimate executables, including DLL utilities, PsExec-related processes, and other Windows binaries. However, not every executable represents reconnaissance activity.

The objective is to identify a reconnaissance tool that satisfies two conditions:

1. It was executed by the attacker.
2. It was not included in the original detection query.

Press enter or click to view image in full size

Reviewing the process creation events shows that nltest.exe was executed as part of the attacker's activity. Unlike background processes or administrative utilities that are unrelated to host or domain enumeration, nltest.exe is specifically designed to query Active Directory and domain services. It is commonly used by administrators to locate domain controllers, verify domain trust relationships, and gather information about the Windows domain. These same capabilities make it a valuable reconnaissance tool for attackers after gaining initial access.

Because nltest.exe performs reconnaissance but was omitted from the original detection query, it represents a detection gap. An analyst reviewing the results should recognize that the existing rule does not cover all common reconnaissance tools and should update it to include nltest.exe in future detections.

Task 4: Atomic Detection

Question 1

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

Answer: 22

Explanation

This task requires building an Atomic Detection Rule in Elastic Security to identify reconnaissance activity executed on a compromised Windows host.

Step 1: Identify the detection scope

The attacker used built-in Windows reconnaissance tools such as:

• whoami.exe
• net.exe
• ipconfig.exe
• systeminfo.exe

These are normal system binaries, so detection must rely on process creation events, not malicious signatures.

We focus on:

• Sysmon Event ID 1 (process creation)
• Windows Security Event ID 4688 (if Sysmon is unavailable)

Step 2: Build the KQL detection query

Navigate to:

Elastic Security → Rules → Detection Rules → Create new rule → Custom query

Press enter or click to view image in full size

Then use the following KQL query:

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

Press enter or click to view image in full size

Why this query works

• event.code: 1 → filters Sysmon process creation events
• Image:*whoami* OR net OR ipconfig OR systeminfo → captures reconnaissance tools
• This ensures we detect execution of built-in enumeration commands

Step 3: Configure the rule

In the rule setup:

• Rule type: Custom Query
• Name: T1059.001 — Suspicious Reconnaissance Command Execution
• Description: Detects execution of an uncommon Windows reconnaissance command that is commonly used during post-exploitation host enumeration. These commands are built-in Windows utilities and can generate false positives from system administrators and automated tools. Investigate the parent process, user context, and timing to determine legitimacy.
• Severity: Low
• Risk score: 21
• MITRE ATT&CK: Tactic → Discovery, Technique → System Information Discovery (T1082) and Account Discovery (T1087)

Press enter or click to view image in full size

Press enter or click to view image in full size

Step 4: Run Rule Preview

Before enabling, open:

Rule Preview

Set timeframe:

Press enter or click to view image in full size

Apr 28, 2026 @ 14:00:00 → Apr 28, 2026 @ 18:00:00

Click Refresh

Press enter or click to view image in full size

Step 5: Interpret results

The preview output shows a table of generated alerts.

Each row represents:

• One recon command execution
• One detection event triggered by the rule

In this case, the preview shows:

22 alert entries

Since the challenge states:

“1 alert is generated per recon command”

We directly map:

Total alerts = 22

Final Answer

22

Question 2

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

Answer: Custom Query

Explanation

When creating a new detection rule in Elastic Security, the platform offers several rule types, including Threshold, Event Correlation, Indicator Match, Machine Learning, and Custom Query.

For atomic detections, the room instructs you to select Custom Query because it allows analysts to define precise detection logic using KQL (Kibana Query Language). This approach is ideal for detecting individual attacker behaviors, such as the execution of reconnaissance commands like whoami, ipconfig, net, or nltest.

The rule is built by navigating to:

Elastic Security
→ Rules
→ Detection Rules
→ Create New Rule
→ Custom Query

This rule type evaluates events against the supplied KQL expression and generates an alert whenever a matching event is found.

Answer: Custom Query

Good — this task is exactly where most people get confused because Threshold rules are not read like normal event logs. You’re now interpreting aggregated detection output, not raw events.

Below is your Task 5 write-up in the correct TryHackMe style, including how to build the rule, what each field means, and how you derive each answer from the preview results.

Task 5: Stateful Detection

Question 1

How many alerts were generated related to a password spraying pattern?

Answer: 5

Explanation

This task focuses on building a stateful detection rule using the Threshold rule type in Elastic Security.

Unlike atomic detections (which trigger per event), threshold rules:

• Group events together
• Count them per group
• Trigger only when a condition is met (threshold exceeded)

Step 1: Create the Threshold Rule

Navigate to:

Elastic Security → Rules → Detection Rules → Create new rule

Press enter or click to view image in full size

Select:

Rule type: Threshold

Step 2: Define the detection query

We are targeting failed login attempts, which indicate brute-force or password spraying activity.

Get Muhammad Faizan’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Use the KQL query:

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

Why this works

• 4625 → Windows failed logon event
• LogonType: 3 → network logon (common in brute-force attacks)
• Together → filters authentication failure attempts over the network

Step 3: Configure threshold logic

Set the rule parameters:

• Group by: source.ip
• Threshold: 10
• Count field: user.name
• Unique values: 5

Press enter or click to view image in full size

What this means

• We are grouping all failed logins by attacker IP
• We count total failures per IP
• We require at least:
• 10 failures total
• 5 unique usernames attempted

This combination detects password spraying behavior (multiple accounts, same attacker IP).

Step 4: Run Rule Preview

Set timeframe:

Apr 28, 2026 @ 14:00:00 → Apr 28, 2026 @ 18:00:00

Click Refresh

Press enter or click to view image in full size

Step 5: Interpret the results

The Rule Preview output shows aggregated detection results.

For threshold rules, each row is NOT a single event — it is a grouped alert result.

We are looking at:

• grouped alerts per source.ip
• total failure count
• cardinality (unique usernames)

Key observation from results

One attacker IP triggered a password spraying pattern:

1 alerts generated for the same attack pattern

Final Answer

1

Question 2

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

Answer: 5.62.18.132, 50

Press enter or click to view image in full size

Explanation

From the threshold aggregation:

• source.ip = attacker identifier
• Total failed attempts = aggregated event count per group

The Rule Preview shows:

• Single attacking IP: 5.62.18.132
• Total failed logons: 50

Interpretation

This confirms:

• A single external host performed repeated authentication attempts
• The volume (50 failures) exceeds the threshold condition (10+)

So Elastic correctly flags this as credential brute-force activity

Question 3

How many usernames did the attacker test?

Answer: 10

Press enter or click to view image in full size

Explanation

This value comes from the cardinality condition in the threshold rule.

We configured:

Unique values: user.name

This means:

• Elastic counts how many distinct usernames were targeted
• Not total events, but unique identities

In the detection output:

"cardinality": {
  "field": "user.name",
  "value": 10
}

Interpretation

• The attacker tested 10 unique usernames
• This is characteristic of password spraying
• low attempts per user
• multiple users targeted

Final Answer

10

Task 6: Correction-Based Detection

Press enter or click to view image in full size

Question 1

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

Answer: source.ip

Explanation

In this task, the EQL correlation rule is built around tracking a password-spraying attack pattern followed by a successful authentication:

sequence by source.ip with maxspan=5m
  [authentication where event.code == 4625 and winlog.event_data.LogonType == 3] with runs = 10
  [authentication where event.code == 4624 and winlog.event_data.LogonType == 10]

This means the detection is fundamentally grouped by the attacker’s source IP address.

During rule execution, Elastic may generate multiple alerts because:

• The same IP produces many overlapping sequences
• Each new failure window can still satisfy the condition
• The same successful login may be reused in multiple matches

This leads to alert duplication for the same attacker activity.

Question 2

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: False Positive

Explanation

The with runs=10 condition enforces a minimum number of failed login attempts before a sequence is considered valid.

[authentication where event.code == 4625] with runs = 10

This is critical because it ensures the detection is focused on:

• High-volume authentication failures
• Likely automated brute-force or password spraying activity

What happens if runs=10 is removed?

The rule becomes:

sequence by source.ip with maxspan=5m
  [4625 failed logon]
  [4624 successful logon]

Now the detection triggers when:

• A single failed login occurs
• Followed by a successful login

Got it — we’re only adding Task 7 into the existing write-up, not restarting anything.

Task 7: Anomaly Detection

Press enter or click to view image in full size

Q1. What Elastic rule type uses anomaly detection jobs and statistical baselines?

The correct answer is:

Machine Learning

Elastic’s Machine Learning rule type uses anomaly detection jobs that build statistical models of normal behavior across users, hosts, and network activity.

Instead of matching fixed conditions (like event.code: 4625 or source.ip), it:

• Learns historical patterns (e.g., login times, process behavior, data access volume)
• Builds probabilistic baselines per entity (user, host, service)
• Flags deviations based on likelihood scores rather than strict thresholds

This allows detection of unknown or evolving attack techniques without needing predefined rules.

Q2. What type of anomaly is a login at an unusual time?

The correct answer is:

Contextual

A contextual anomaly is an event that is only unusual when compared to the surrounding context or baseline behavior.

In this example:

• The login itself is valid (authentication succeeded)
• The account is legitimate
• The anomaly is based purely on timing (03:00 vs normal 08:00–18:00 pattern)

So the deviation is not about the action, but about the context in which it occurs.

Task 8: Detection Tuning

Press enter or click to view image in full size

1. What is the attacker’s LogonId?

The LogonId is extracted directly from the Sysmon Event ID 1 process creation logs.

From the event data:

LogonId: 0x557e9

This value represents the unique Windows logon session under which the attacker executed reconnaissance commands such as whoami.exe and net.exe.

In detection engineering terms, this is important because LogonId allows us to correlate multiple processes back to a single authenticated session, which is essential when identifying chained post-exploitation activity.

Answer:

0x557e9

2. What type of tuning strategy did you apply in this task?

The tuning process involved more than adjusting thresholds or excluding false positives. The original detection was an atomic rule that triggered on every execution of reconnaissance tools such as:

• whoami.exe
• net.exe
• nltest.exe
• ipconfig.exe
• systeminfo.exe

This approach was too noisy in real environments because legitimate administrators also run these commands frequently.

To solve this, the detection was fundamentally redesigned into a session-aware aggregated rule, grouping events by:

• host.name
• winlog.event_data.LogonId

and requiring a minimum number of recon commands within a short timeframe.

This changed the detection logic from:

• “alert on every recon command execution”
  to
• “alert when multiple recon commands occur within the same logon session”

Because the rule structure itself was redesigned (atomic → threshold-based session aggregation), this is classified as a full redesign rather than a simple parameter adjustment.

Answer:

Full Rework

Conclusion

This room demonstrates the full lifecycle of detection engineering inside a SIEM environment, moving from raw log analysis to structured, production-style detection logic. Across the tasks, the focus shifts from identifying individual suspicious events to understanding how attackers operate as a sequence of behaviors across multiple layers of a system.

The first stage introduced detection vs analysis, showing that identifying an alert is only the starting point; true security value comes from understanding scope, impact, and attacker intent. This was reinforced through IR triggers and communication workflows, where structured logging and tracking (via ticketing systems and IOC tracking) ensure investigations remain consistent and auditable.

As the room progressed into practical detection development, four major detection types were explored:

• Atomic detection, which is fast but noisy because it triggers on individual events like recon commands
• Stateful (threshold) detection, which reduces noise by aggregating repeated behavior over time
• Correlation detection, which connects multiple stages of an attack into a single sequence, such as failed logons followed by successful authentication
• Anomaly detection (Machine Learning), which identifies deviations from learned normal behavior rather than relying on static rules

The tuning section highlighted an important real-world challenge: detections are rarely perfect on first deployment. Without tuning, rules either generate too many false positives or miss meaningful attack activity. The transformation of the recon rule from atomic detection into a session-aware threshold rule demonstrated how detection engineering evolves from simple event matching to contextual behavioral analysis.

Overall, the key takeaway is that effective detection engineering is not about writing one perfect rule, but about continuously refining logic, reducing noise, and aligning alerts with real attacker behavior.

43