Listen to this Post
Introduction:
Most organizations are drowning in logs but starving for detections. The difference between visibility and security isn’t data—it’s the ability to transform raw telemetry into actionable threat intelligence. Detection engineering is the systematic process of designing, building, and tuning the logic that identifies threats, mapping attacker behaviors to specific detection rules before adversaries achieve their objectives. A SIEM like Splunk isn’t valuable because it stores data; it becomes valuable when it helps analysts identify threats continuously, not just when someone remembers to search.
Learning Objectives:
- Master the detection engineering lifecycle from threat modeling to continuous validation
- Build and deploy Splunk detection queries for 10 critical attack vectors including brute force, LOLBAS, and credential dumping
- Implement risk-based alerting and MITRE ATT&CK mapping to prioritize threats effectively
- Differentiate between dashboards that show data and detections that uncover adversaries
You Should Know:
- The Detection Engineering Mindset: From Reactive to Proactive
Traditional security monitoring relies on out‑of‑the‑box rules that catch obvious threats but create excessive noise. Detection engineering represents a more mature evolution—building custom logic tailored to your specific environment and risks. Instead of waiting for a known signature or threshold to be met, detection engineering focuses on identifying attacker behaviors and patterns before they escalate into major breaches.
The detection engineering lifecycle is a continuous feedback loop involving visibility, threat modeling, Detection‑as‑Code (DaC), and continuous validation through threat hunting. Every detection should answer six critical questions: What happened? Who performed the activity? Which systems were affected? Is the behavior expected or anomalous? Which MITRE ATT&CK technique does it map to? What should the analyst investigate next?
Step‑by‑Step Guide to Building Your First Detection:
- Identify the threat behavior you want to detect (e.g., LSASS credential dumping)
- Map to MITRE ATT&CK technique (e.g., T1003.001 for LSASS Memory)
- Determine required data sources (Windows Security Event 4688, Sysmon Event 1)
- Write the SPL query using the Endpoint.Processes data model
- Test against known attack data to validate detection logic
- Tune false positives using the empty filter macro provided in Splunk Enterprise Security
- Schedule the detection with appropriate cron settings and risk scoring
2. Brute Force and Password Spray Detection
Brute force attacks remain one of the most common entry vectors. A mature Splunk environment should detect excessive failed login attempts across multiple accounts. The `Excessive Failed Logins` search is designed to detect brute force access attempts.
SPL Query for Brute Force Detection:
index=wineventlog EventCode=4625 | stats count by src_ip, user, dest | where count > 10 | eval risk_score = 50 | `security_content_ctime(firstTime)`
Windows Hardening Command (PowerShell):
Enable advanced audit policy for logon events auditpol /set /subcategory:"Logon" /success:enable /failure:enable Set account lockout threshold to 5 failed attempts net accounts /lockoutthreshold:5
Linux Command to Monitor Failed Logins:
Check failed login attempts from /var/log/auth.log
grep "Failed password" /var/log/auth.log | awk '{print $9}' | sort | uniq -c | sort -1r
Monitor SSH brute force in real-time
tail -f /var/log/auth.log | grep "Failed password"
- Windows Event Log Tampering and Suspicious Service Creation
Attackers frequently clear or tamper with event logs to cover their tracks. Detecting EventCode 1102 (audit log cleared) is critical. Additionally, adversaries create malicious services for persistence—monitoring EventCode 7045 (new service creation) can reveal this activity.
SPL Query for Log Tampering:
index=wineventlog EventCode=1102 | stats count by user, src, dest | `security_content_ctime(firstTime)`
SPL Query for Suspicious Service Creation:
index=wineventlog EventCode=7045
| search NOT Service_Name IN ("Windows", "Microsoft", "Security")
| table _time, Service_Name, ImagePath, Account_Name
Windows Commands to Audit Services:
List all running services with their paths
Get-Service | Where-Object {$_.Status -eq "Running"} | Select-Object Name, DisplayName, ServiceType
Check for unsigned services (potential malware)
Get-WmiObject Win32_Service | Where-Object {$_.PathName -1otlike "Windows"}
4. LSASS Credential Dumping and Shadow Copy Deletion
Credential dumping—gathering credentials from a target system, often hashed or encrypted—is a common attack technique. Detecting access to the LSASS process and shadow copy manipulation is essential.
SPL Query for LSASS Dumping:
index=wineventlog EventCode=4663 Object_Name="\lsass.exe" | stats count by process_name, user, dest | `security_content_ctime(firstTime)`
SPL Query for Shadow Copy Deletion:
| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes WHERE `process_cmd` Processes.process=mklink Processes.process=HarddiskVolumeShadowCopy BY Processes.process Processes.user Processes.dest | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `credential_dumping_via_symlink_to_shadow_copy_filter`
This analytic detects the creation of a symlink to a shadow copy, which may indicate credential dumping attempts. Attackers often use this technique to manipulate or delete shadow copies, hindering system backup and recovery efforts.
Windows Detection Commands:
Check for LSASS access attempts
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4663} | Where-Object {$_.Message -like "lsass.exe"}
Monitor shadow copy deletions
vssadmin list shadows
Check for suspicious vssadmin usage
Get-WinEvent -LogName "Security" | Where-Object {$_.Message -like "vssadmin"}
Linux Equivalent (using auditd):
Monitor access to /etc/shadow auditctl -w /etc/shadow -p rwa -k shadow_access Check audit logs for shadow access ausearch -k shadow_access
5. LOLBAS Activity and Internal Port Scanning
Living Off the Land Binaries and Scripts (LOLBAS) are Windows native binaries that can be abused by threat actors to perform tasks like executing malicious code. Detecting LOLBAS processes executed outside expected paths is critical.
SPL Query for LOLBAS Execution:
| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime
FROM datamodel=Endpoint.Processes
WHERE NOT Processes.process_path IN ("\PROGRA~", "\Program Files", ":\Windows\System32\", ":\Windows\SysWOW64\")
BY Processes.action Processes.dest Processes.process_name Processes.process_path Processes.parent_process_name Processes.user
| `drop_dm_object_name(Processes)`
| lookup lolbas_file_path lolbas_file_name as process_name OUTPUT description as desc
| lookup lolbas_file_path lolbas_file_name as process_name lolbas_file_path as process_path OUTPUT description as is_lolbas_path
| search desc!="false" AND is_lolbas_path="false"
| `windows_lolbas_executed_outside_expected_path_filter`
This analytic identifies a LOLBAS process being executed outside its expected location, which may indicate an adversary attempting to evade defenses or execute malicious code.
SPL Query for Internal Port Scanning:
| tstats `security_content_summariesonly` values(All_Traffic.action) as action count FROM datamodel=Network_Traffic
WHERE All_Traffic.src_ip IN ("10.0.0.0/8","172.16.0.0/12","192.168.0.0/16")
BY All_Traffic.src_ip All_Traffic.dest_port All_Traffic.dest_ip All_Traffic.transport span=1s _time
| `drop_dm_object_name("All_Traffic")`
| bin span=1h _time
| stats dc(dest_ip) as totalDestIPCount BY src_ip dest_port _time transport
| where totalDestIPCount>=250
| `internal_horizontal_port_scan_filter`
This analytic identifies instances where an internal host attempts to communicate with 250 or more destination IP addresses using the same port and protocol—a clear indicator of reconnaissance or scanning activities.
Linux Commands for Port Scanning Detection:
Detect port scanning from local host
netstat -tunap | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -1r
Monitor for nmap scans
tcpdump -i any 'tcp[bash] & (tcp-syn) != 0 and tcp[bash] & (tcp-ack) == 0'
6. Malware Re-Infection Patterns and Privilege Escalation
Detecting malware re-infection requires monitoring DNS queries to known malicious domains and identifying privilege escalation attempts through Active Directory group modifications.
SPL Query for Malware Re-Infection (DNS-based):
index=dns query=malwarecheck.info | stats count by src_ip, query | `security_content_ctime(firstTime)`
SPL Query for Privilege Escalation (AD Group Manipulation):
`wineventlog_security` EventCode IN (4728) | where user=src_user | stats min(_time) as _time dc(user) as usercount, values(user) as user BY signature, Group_Name, src_user, dest | `windows_ad_add_self_to_group_filter`
This analytic detects instances where a user adds themselves to an Active Directory group—a common indicator of privilege escalation. Attackers often add user accounts to privileged AD groups to escalate privileges or maintain persistence within an Active Directory environment.
Windows Commands to Detect Privilege Escalation:
Check for recent AD group membership changes
Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name, ObjectClass
Monitor for suspicious scheduled tasks (persistence)
Get-ScheduledTask | Where-Object {$_.TaskPath -1otlike "Microsoft"}
Linux Commands for Privilege Escalation Detection:
Check sudoers file for recent changes cat /etc/sudoers | grep -v "^" | grep -v "^$" Monitor for su/sudo execution ausearch -m USER_AUTH,USER_ACCT
7. Risk-Based Alerting and Continuous Validation
Splunk Enterprise Security uses risk-based alerting (RBA) to accelerate and simplify the process of detecting risk. RBA collects all intermediate findings into a single risk index, assigning risk scores to users and systems based on multiple correlated events.
Implementation Steps:
- Enable the Risk-Based Alerting framework in Splunk Enterprise Security
- Configure risk incident rules and risk factors to detect and prioritize risk
- Map each detection to a MITRE ATT&CK technique for contextual enrichment
- Use the Use Case Library to operationalize ESCU detections
- Continuously validate detections using attack data to balance threat coverage with manageable alert volumes
What Undercode Say:
- Key Takeaway 1: Dashboards show information; detections uncover adversaries. The most effective SOC teams don’t search for threats manually—they engineer detections that continuously search for them. A SIEM evolves from a monitoring platform into a security capability only when detection logic is prioritized over dashboard aesthetics.
-
Key Takeaway 2: The real challenge isn’t collecting telemetry—it’s transforming that telemetry into actionable detections. Every detection must answer who, what, when, where, why, and how, mapped to MITRE ATT&CK. Teams that spend years building dashboards while neglecting detection logic remain visible but vulnerable.
Analysis: The cybersecurity industry is shifting from reactive monitoring to proactive detection engineering. Organizations that treat their SIEM as a log search platform are missing the point entirely—Splunk and similar platforms are detection engineering platforms capable of identifying brute force, PowerShell abuse, event log tampering, service creation, LSASS dumping, shadow copy deletion, LOLBAS activity, port scanning, malware re-infection, and privilege escalation. The gap between visibility and security is filled by detection logic, not data volume. SOC analysts must transition from manual threat hunting to automated detection engineering, leveraging risk-based alerting and MITRE ATT&CK mapping to prioritize threats effectively. The most mature teams adopt Detection-as-Code (DaC), treating detection rules as software that undergoes continuous development, testing, and refinement. This approach reduces dwell time and breach impact by identifying advanced persistent threats earlier in the attack chain. The future of security operations belongs to those who engineer detections, not those who merely collect logs.
Expected Output:
Introduction:
Most organizations are drowning in logs but starving for detections. The difference between visibility and security isn’t data—it’s the ability to transform raw telemetry into actionable threat intelligence. Detection engineering is the systematic process of designing, building, and tuning the logic that identifies threats, mapping attacker behaviors to specific detection rules before adversaries achieve their objectives.
What Undercode Say:
- Key Takeaway 1: Dashboards show information; detections uncover adversaries. The most effective SOC teams don’t search for threats manually—they engineer detections that continuously search for them.
- Key Takeaway 2: The real challenge isn’t collecting telemetry—it’s transforming that telemetry into actionable detections. Every detection must answer who, what, when, where, why, and how, mapped to MITRE ATT&CK.
Prediction:
- +1 The adoption of Detection-as-Code (DaC) will accelerate, with security teams treating detection rules as software that undergoes CI/CD pipelines, version control, and automated testing.
- +1 AI and machine learning will increasingly augment detection engineering, establishing behavioral baselines and identifying subtle, multi-stage attacks that evade traditional rule-based monitoring.
- -1 Organizations that fail to transition from log collection to detection engineering will experience longer dwell times and more severe breach impacts as adversaries leverage increasingly sophisticated living-off-the-land techniques.
- -1 The cybersecurity skills gap will widen as detection engineering requires specialized expertise in SPL, MITRE ATT&CK mapping, and continuous tuning—leaving many SOC teams understaffed and overwhelmed.
- +1 Risk-based alerting (RBA) will become the standard for prioritizing threats, enabling analysts to focus on high-risk findings rather than drowning in alert noise.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Yildizokan Splunk – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
