Cyber Security Academy · Lesson

Writing Detection Rules and Correlation

Create Splunk SPL or Kibana KQL queries to detect brute force, lateral movement, and data exfiltration.

Writing Detection Rules and Correlation is a free Cyber Security Academy lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cyber Security Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Detection Engineering Basics

Detection rules translate attacker behaviors into query logic that fires when the pattern appears in logs. Good detection engineering is specific enough to avoid false positives but broad enough to catch variations of an attack.

Splunk SPL: Search Processing Language

SPL queries use a pipe syntax: search → transform → display. Start with an index and sourcetype, filter for relevant events, and aggregate or alert on the results.

# Basic SPL structure
index=security sourcetype=WinEventLog EventCode=4625
| stats count by src_ip, user
| where count > 10
| sort -count

# Explanation:
# Search Security index for logon failures
# Count failures per source IP + user
# Alert if more than 10 failures
# Sort descending by count

Detecting Brute Force in Splunk

Brute force detection: count failed logins per source, alert when threshold exceeded in a time window. Correlate with successful login after failures for credential stuffing detection.

# Failed logins by source IP
index=security EventCode=4625
| bucket _time span=5m
| stats count as failures by _time, src_ip
| where failures > 20
| table _time, src_ip, failures

# Success after failures (account takeover)
index=security EventCode=4625 OR EventCode=4624
| stats values(EventCode) as events by src_ip
| where mvfind(events,"4625") >= 0 AND mvfind(events,"4624") >= 0

Kibana KQL for Detection

Kibana Query Language (KQL) filters events for investigation. More readable than Lucene for analysts; use in saved searches and alerting rules within Kibana.

# KQL examples:
# Failed SSH logins
event.action: "ssh_login_failed" and source.ip: *

# Nmap scan detection
not destination.port: (80 or 443 or 22) and event.type: "connection"

# Privilege escalation
process.name: "sudo" and process.args: "-s"

Elasticsearch Detection Rules

Kibana's Security app includes a detection rules engine. Rules can be threshold-based (count of events), query-based (specific event pattern), ML anomaly, or EQL (Event Query Language) sequence rules.

# EQL sequence rule example (Kibana Security):
sequence by host.name
  [process where process.name == "cmd.exe"]
  [network where destination.port == 4444]

# Detects: cmd.exe followed by connection to port 4444
# (common reverse shell pattern)

Lateral Movement Detection

Detect lateral movement via: PsExec service creation (Event 7045), remote WMI execution, unusual admin share access (Event 5140), and new scheduled tasks created remotely.

# Splunk: detect PsExec-style lateral movement
index=security EventCode=7045
| where Service_Name="PSEXESVC" OR Service_File_Name="\\*\\*.exe"
| table _time, ComputerName, Service_Name, Service_File_Name

# WMI remote execution
index=sysmon EventCode=1 ParentImage="*WmiPrvSE.exe"
| table _time, host, CommandLine, User

Data Exfiltration Detection

Detect exfiltration via: large outbound transfers to unusual destinations, DNS queries with abnormally long subdomains (tunneling), and HTTPS beaconing at regular intervals.

# DNS tunneling detection in Splunk
index=dns
| eval subdomain_len=len(subdomain)
| where subdomain_len > 50
| stats count by query, src_ip
| sort -count

# Large outbound (NetFlow/firewall logs)
index=firewall action=allow direction=outbound
| stats sum(bytes) as total_bytes by dest_ip, src_ip
| where total_bytes > 100000000  # 100MB threshold

Threat Hunting with Saved Searches

Save frequently used detection queries as scheduled searches that email or create incidents. Set appropriate time windows and thresholds to balance detection speed against false positive rate.

MITRE ATT&CK-Mapped Detection

Map detection rules to ATT&CK techniques. This shows coverage gaps and helps prioritize new rules. Tools like ATT&CK Navigator visualize which techniques you detect vs which you are blind to.

Tuning to Reduce False Positives

New rules often fire too broadly. Tune by: adding exclusions for known-good sources, raising thresholds, adding contextual fields (business hours, known scan IPs), and validating against historical data before activating.

Alert Fatigue

Too many low-quality alerts cause analysts to ignore them — defeating the purpose. Prioritize quality over quantity: 10 high-fidelity alerts per day is better than 500 noisy ones. Suppress, tune, and retire underperforming rules.

Quick Check

What does an EQL sequence rule detect that a simple query rule cannot?

Summary: Detection Rules

Detection engineering converts attacker TTPs into query logic. Use SPL for Splunk, KQL and EQL for Kibana Security. Map rules to MITRE ATT&CK to track coverage. Prioritize high-fidelity, targeted rules over broad noisy ones. Continuously tune — the threat landscape changes, and so should your detection logic.

Frequently asked questions

Is the “Writing Detection Rules and Correlation” lesson free?

Yes — the full text of “Writing Detection Rules and Correlation” is free to read here on the web, and the Cyber Security Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cyber Security Academy course, upgrade to CoddyKit PRO.

What will I learn in “Writing Detection Rules and Correlation”?

Create Splunk SPL or Kibana KQL queries to detect brute force, lateral movement, and data exfiltration. You practise Cyber Security Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Cyber Security Academy?

No prior experience is required. Cyber Security Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Writing Detection Rules and Correlation” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Cyber Security Academy lesson?

Yes. Every Cyber Security Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

Log Sources: OS, Network, and Application Logs
SIEM Architecture and Log Ingestion
Writing Detection Rules and Correlation
Alert Triage and SOC Workflow

← Back to Cyber Security Academy