Mohamed Hajji

Component	Details
SIEM Tool	Splunk Enterprise (Free Tier)
Telemetry Sources	Sysmon (modular config) + native Windows Event Logs
Log Forwarding	Splunk Universal Forwarder installed on endpoint
Endpoints	Windows 11 Workstation (main telemetry source)
Network Segmentation	OPNsense Firewall isolates Windows machine from internet (except logging)
Logging Server	Ubuntu 22.04 server running Splunk over a separate WAN subnet

🚨 Alert 1: High-Frequency Failed Logon Attempts (EventCode 4625 – Brute Force Detection)

Detection Overview

This alert identifies potential brute force activity targeting local Windows accounts by detecting multiple failed login attempts within a short timeframe. It leverages native Windows Security event logs from theSecurity channel, specificallyEventCode 4625, which indicates failed logon attempts.

Monitoring for repeated authentication failures can help detect early signs of credential brute forcing, account compromise attempts, or automated attacks such as credential stuffing. This detection is especially relevant in:

Initial Access detection — MITRE ATT&CK T1078 (Valid Accounts)
Internal threat simulation (e.g., red teaming, penetration testing)
Identifying credential stuffing attempts from internal or external sources

Tip: To reduce false positives, consider filtering by interactive logon types and excluding known service or misconfigured accounts.

🔍 SPL Query

 index=your_index sourcetype=WinEventLog:Security EventCode=4625 earliest=-5m@m latest=now | search Account_Name!="" AND Account_Name!="-" | eval Logon_Type=coalesce(Logon_Type, LogonType) | where Logon_Type IN ("2", "10") | stats count AS FailedAttempts, min(_time) AS FirstAttempt, max(_time) AS LastAttempt BY Account_Name, Logon_Type | where FailedAttempts >= 5 | eval Duration = tostring(LastAttempt - FirstAttempt, "duration") | sort -FailedAttempts

💡 Query Explanation

🔍

1. Filter for Failed Logon Events in the Last 5 Minutes

We begin by narrowing the dataset to only failed login attempts on Windows systems. - `index=your_index` specifies where the data is stored. - `sourcetype=WinEventLog:Security` ensures we’re only looking at Windows Security logs. - `EventCode=4625` is specific to failed logon attempts (Audit Failure). - `earliest=-5m@m latest=now` limits the timeframe to the last 5 minutes, rounded to the minute, to detect real-time brute-force activity.

index=your_index sourcetype=WinEventLog:Security EventCode=4625 earliest=-5m@m latest=now

🚫

2. Exclude Empty or Anonymous Accounts

Some failed logons have no account name (e.g., system-level failures, service noise). - `Account_Name!=""` removes events where the username is missing. - `Account_Name!="-"` filters out anonymous or system-generated attempts. This cleans up noise and focuses only on human-targeted attacks.

| search Account_Name!="" AND Account_Name!="-"

🔄

3. Normalize Logon Type Field for Compatibility

Depending on how the event was ingested, the logon type may be recorded as `Logon_Type` or `LogonType`. - `coalesce(Logon_Type, LogonType)` picks the first non-null value between the two, standardizing the field name. This makes the logic portable across different environments.

| eval Logon_Type=coalesce(Logon_Type, LogonType)

👤

4. Focus on User-Driven Logons (Types 2 and 10)

We are only interested in logon types that represent human interaction: - `2`: Interactive logon (e.g., keyboard and screen at local console) - `10`: RemoteInteractive logon (e.g., RDP) This excludes irrelevant events like batch jobs (Type 4) or services (Type 5).

| where Logon_Type IN ("2", "10")

📊

5. Count Failed Attempts per Account and Logon Type

We use `stats` to aggregate logon failures: - `count AS FailedAttempts` counts the number of failed logons. - `min(_time)` and `max(_time)` give us the timestamp of the first and last failure. - `BY Account_Name, Logon_Type` groups results per user per type (local vs remote). This sets us up to detect bursts of failed attempts per user session type.

| stats count AS FailedAttempts, 
     min(_time) AS FirstAttempt, 
     max(_time) AS LastAttempt 
BY Account_Name, Logon_Type

⚠️

6. Flag Users with 5+ Failed Attempts

We define a brute-force threshold: 5 or more failed attempts in 5 minutes. - `where FailedAttempts >= 5` filters to only suspicious accounts. This threshold is realistic and low enough to catch early brute-force behavior.

| where FailedAttempts >= 5

⏱️

7. Calculate the Attack Duration per User

To understand how quickly the attack occurred, we calculate the time difference between first and last failure: - `LastAttempt - FirstAttempt` gives the duration in seconds. - `tostring(..., "duration")` converts it to a readable format (e.g., 1m30s). This provides useful context: rapid failures in a short time may suggest automation.

| eval Duration = tostring(LastAttempt - FirstAttempt, "duration")

📌

8. Prioritize Most Attacked Accounts

We sort the results by descending number of failures: - `sort -FailedAttempts` ensures that the most aggressively attacked accounts appear first. This allows analysts to focus on the highest-risk cases first during triage.

| sort -FailedAttempts

📋 Attack Simulation

Create a Local Test User (PowerShell)
Use the command below to create a new local user named testuser with a known password. This will be the target of simulated brute-force attempts. The password is securely converted using ConvertTo-SecureString.

Simulate Brute Force Attempts via PowerShell
The following script tries multiple incorrect passwords for testuser using runas. Each attempt launches a harmless process (notepad.exe) to trigger logon failures (Event ID 4625). This mimics real-world brute-force activity and should trigger your Splunk alert within the 5-minute window.

$username = "testuser"
$passwords = @("WrongPass1", "BadPass2", "Invalid123")
$attempts = 3
$dummyProgram = "notepad.exe"

for ($i = 0; $i -lt $attempts; $i++) {
    foreach ($pwd in $passwords) {
        Write-Host "Trying $username with password: $pwd"
        $cmd = "echo $pwd | runas /user:$env:COMPUTERNAME\$username $dummyProgram"
        cmd.exe /c $cmd | Out-Null
        Start-Sleep -Milliseconds 300
    }
}

💡 Tip: You can increase the number of attempts or use a larger password list to test different thresholds. The failed logons will appear as Event ID 4625 in the Security log.

⚔️ Mitigation Steps

🔒
Implement Account Lockout Policies: Configure Group Policy to lock user accounts after a defined number of failed login attempts (e.g., 5). This blocks automated brute-force attacks while alerting administrators to suspicious behavior.
🛡️
Enforce Multi-Factor Authentication (MFA): Require MFA for all users, especially for RDP, VPN, or administrator accounts. Even if credentials are guessed or stolen, MFA prevents unauthorized access.
🔔
Detect and Alert on Brute-Force Attempts: Use your SIEM (e.g., Splunk or Elastic) to alert when multiple failed logons occur in a short time frame. Tie it with endpoint detection for context-aware defense.
🔑
Harden Password Policy: Mandate complex passwords, block commonly used credentials, and enable regular password rotation. Consider using LAPS for local admin password management.
👤
Reduce Local Account Exposure: Disable or rename the default local Administrator account, remove unused local users, and prefer domain accounts with proper RBAC whenever possible.

🚨 Alert 2: Detection of Suspicious Process Creation via Sysmon EventCode 1

Detection Overview

Threat actors often establish persistence by creating malicious Windows services. While legitimate software also installs services, certain characteristics—like unusual file paths, obfuscated names, or unexpected installation times—can signal malicious activity. This alert leverages native Windows Event Log7045to detect newly created services and highlight those that:

+ Were installed recently, indicating possible post-exploitation persistence
+ Execute from suspicious paths (e.g., %TEMP%, %APPDATA%, mounted USB drives)
+ Use service names that appear random, obfuscated, or inconsistent with standard software

🔍 SPL Query

 source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 | search (Image="*\powershell.exe" AND CommandLine="*EncodedCommand*") OR (Image="*\mimikatz.exe") OR (Image="*\procmon.exe") OR (Image="*\rundll32.exe" CommandLine="*urlmon.dll,Download*") | table _time, ComputerName, User, Image, CommandLine

💡 Query Explanation

1. Filter Sysmon Process Creation Events

We begin by targeting Sysmon EventCode=1, which logs every process execution with detailed metadata such as parent-child relationships, user, and command line. This event is foundational for threat detection involving process behavior.

source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1

2. Detect Known Suspicious Execution Patterns

We apply logic to identify suspicious tools and behaviors. This includes encoded PowerShell commands (common for obfuscation), Mimikatz (credential theft), Procmon (reconnaissance), and rundll32 executing URL-based DLL downloads — all signs of post-exploitation or red team tooling.

search (Image="*\powershell.exe" AND CommandLine="*EncodedCommand*") OR (Image="*\mimikatz.exe") OR (Image="*\procmon.exe") OR (Image="*\rundll32.exe" CommandLine="*urlmon.dll,Download*")

3. Present High-Value Investigation Fields

Finally, we display the most critical fields for an analyst: event timestamp, hostname, user context, executable path, and the full command line. These help correlate activity, identify execution sources, and pivot for deeper analysis.

| table _time, ComputerName, User, Image, CommandLine

📋 Attack Simulation

✅ Simulate encoded PowerShell command: This example uses-EncodedCommand, a common attacker technique to obfuscate intent.

🔍 This decodes to:

✅ Simulate DLL-based LOLBin download: The following command usesrundll32.exeand urlmon.dllto simulate malicious file download.

🔐 This mimics a common post-exploitation technique without causing harm in a lab.

⚔️ Mitigation Steps

🛡️
Enable Application Whitelisting: Use Microsoft AppLocker or Windows Defender Application Control (WDAC) to permit only trusted apps, blocking suspicious binaries like mimikatz or unauthorized PowerShell scripts.
🔐
Restrict PowerShell Usage: Configure PowerShell execution policies to limit script execution, disable or tightly control encoded commands, and use Constrained Language Mode where possible.
📈
Deploy Endpoint Detection and Response (EDR): Implement EDR solutions to detect and block malicious process behaviors, including command line injections and known malicious executables like mimikatz and procmon.
🛑
Monitor and Alert on Suspicious Processes: Configure your SIEM to alert on Sysmon EventCode=1 events with suspicious process names and command lines, enabling early detection and investigation.
🛠️
Harden Systems and Limit Privileges: Apply least privilege principles, disable unnecessary admin rights, and regularly audit system configurations to prevent unauthorized use of tools like mimikatz or procmon.
🌐
Block Malicious Network Activity: Enforce firewall and proxy rules to block known malicious URLs and restrict outbound traffic from suspicious processes such as rundll32 attempting downloads.
📚
User Awareness and Training: Train users about phishing and social engineering risks, which often lead to execution of malicious tools and scripts, to reduce initial compromise chances.

🚨 Alert 3: Detection of Potentially Malicious Service Creation (Event 7045)

Detection Overview

Attackers often gain persistence by creating new Windows services. Legitimate software also installs services, but new or suspicious ones — especially those created recently, running from unusual paths, or with obfuscated names — can indicate malicious activity. This alert detects such service creation events by monitoring Windows EventCode 7045.

+ Newly created services that did not exist before
+ Services running from non-standard locations like %TEMP%, %APPDATA%, or removable drives
+ Services with suspicious or obfuscated names designed to evade detection

🔍 SPL Query

 sourcetype=WinEventLog:Security OR sourcetype=WinEventLog:System EventCode=7045 | rex "Service File Name:s+(?<ImagePath>.+)" | rex "Service Name:s+(?<ServiceName>.+?)s+Service File Name:" | rex "Account:s+(?<Account>.+)" | eval LowerPath=lower(ImagePath) | where like(LowerPath, "%temp%") OR like(LowerPath, "%appdata%") OR like(LowerPath, "%downloads%") OR like(LowerPath, "%:\users\public%") OR like(LowerPath, "%:\windows\temp%") | table _time, host, ServiceName, ImagePath, Account | sort -_time

💡 Query Explanation

1. Filter Windows Service Creation Events

We start by searching for EventCode=7045 from Security or System event logs to capture service creation events.

sourcetype=WinEventLog:Security OR sourcetype=WinEventLog:System EventCode=7045

2. Extract Service and Account Details

Using regex, we extract key fields: Service File Name, Service Name, and Account to analyze who created which service and where.

| rex "Service File Name:\s+(?<ImagePath>.+)"
| rex "Service Name:\s+(?<ServiceName>.+?)\s+Service File Name:"
| rex "Account:\s+(?<Account>.+)"

3. Normalize Service File Path

We convert the service file path to lowercase for easier pattern matching and detection of suspicious paths.

| eval LowerPath=lower(ImagePath)

4. Identify Suspicious Service Paths

We filter services running from suspicious directories like temp folders, AppData, Downloads, Public users, or Windows temp folders which are uncommon for legitimate services.

| where like(LowerPath, "%temp%") OR like(LowerPath, "%appdata%") OR like(LowerPath, "%downloads%") OR like(LowerPath, "%:\users\public%") OR like(LowerPath, "%:\windows\temp%")

5. Display Important Fields

We display timestamp, host, service name, service executable path, and account that created the service for further investigation.

| table _time, host, ServiceName, ImagePath, Account

6. Sort by Most Recent

Results are sorted by event time descending to prioritize the most recent suspicious service creation events.

| sort -_time

📋 Attack Simulation

Safely Create a Dummy Service in PowerShell

You now have a fake service running from %TEMP%, which will:

Trigger Event ID 7045
Get caught by the alert logic

⚔️ Mitigation Steps

🔒
Restrict Service Creation Permissions Limit which users or groups can create or modify Windows services by configuring Group Policy or Local Security Policy to prevent unauthorized or malicious service installations.
🕵️‍♂️
Monitor Service Creation Events Continuously monitor EventCode 7045 logs for new service creation events, with special attention to services installed in non-standard directories such as Temp or AppData.
📁
Enforce Application Whitelisting Deploy application whitelisting solutions to allow only approved executables to run as services, effectively blocking unauthorized or suspicious binaries.
⚙️
Harden Endpoint Security Configurations Restrict or disable execution of persistent executables or services from directories like Temp, AppData, and Downloads to reduce the attack surface.
🔔
Set Up Alerting for Suspicious Paths Configure your SIEM or endpoint protection tools to generate alerts for services installed from unusual paths or created by unknown accounts.
👥
Review and Audit Service Accounts Regularly audit service accounts and permissions to ensure no excessive privileges are granted to non-administrative users.

🚨 Alert 4: Suspicious Parent-Child Process Relationships (e.g., winword.exe spawning powershell.exe)

Detection Overview

Detecting suspicious parent-child process relationships is essential for identifying abnormal activity often leveraged by attackers during lateral movement or execution of malicious code. Common indicators include trusted Microsoft Office applications spawning unexpected processes like PowerShell, cmd.exe, or regsvr32.exe, which frequently suggest malicious macros or background scripts.

+ WINWORD.EXE → powershell.exe
+ EXCEL.EXE → cmd.exe
+ OUTLOOK.EXE → regsvr32.exe

🔍 SPL Query

source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 | where (ParentImage="*\winword.exe" AND Image="*\powershell.exe") OR (ParentImage="*\excel.exe" AND Image="*\cmd.exe") OR (ParentImage="*\outlook.exe" AND Image="*\regsvr32.exe") | table _time, ComputerName, User, ParentImage, Image, CommandLine | sort -_time

💡 Query Explanation

1. Filter Sysmon Process Create Events

Start by filtering EventCode=1 (Process Create) from Sysmon logs to get process creation events.

source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1

2. Detect Suspicious Parent-Child Process Pairs

Look for known abnormal parent-child process pairs such as winword.exe spawning powershell.exe or excel.exe spawning cmd.exe.

| where (ParentImage="*\\winword.exe" AND Image="*\\powershell.exe")
    OR (ParentImage="*\\excel.exe" AND Image="*\\cmd.exe")
    OR (ParentImage="*\\outlook.exe" AND Image="*\\regsvr32.exe")

3. Select Relevant Fields

Display important fields like timestamp, computer name, user, parent process image, child process image, and command line for context.

| table _time, ComputerName, User, ParentImage, Image, CommandLine

4. Sort by Recency

Sort results by time descending to investigate the latest suspicious process relationships first.

| sort -_time

📋 Attack Simulation

Simulate this alert by opening Microsoft Word and running a macro or use PowerShell to spawn a suspicious child process manually:

Or simulate parent-child manually with PowerShell:

⚔️ Mitigation Steps

🔒
Enforce Application Control Use application whitelisting to restrict which applications can spawn child processes, preventing unauthorized code execution.
🛡️
Monitor Parent-Child Process Behavior Continuously monitor and alert on unusual or suspicious process spawning, especially from trusted apps like Office suite spawning scripting engines.
⚙️
Implement Macro Security Policies Configure Office macro settings to disable or restrict macros, especially those that can execute external processes.
👥
Educate Users About Phishing and Malicious Macros Train users to recognize and avoid opening suspicious documents that may contain malicious macros.
🔔
Set Up Real-Time Alerts Configure your SIEM or endpoint detection tools to alert on parent-child process relationships that deviate from normal baselines.

🚨 Alert 5: Detection of LSASS Memory Access (Potential Credential Dumping)

Detection Overview

Credential dumping from lsass.exe is a well-known attacker technique to steal Windows credentials using tools like Mimikatz. This alert detects processes that open handles to LSASS with suspicious access rights, providing a high-fidelity indicator of compromise on Windows systems.

Key fields to understand in this alert:

+ EventCode=10: Sysmon ProcessAccess event indicating a process handle was opened.
+ TargetImage: The target process (typically lsass.exe).
+ Image: The process requesting access (often mimikatz.exe or powershell.exe).
+ GrantedAccess: The access rights granted — watch for suspiciously high privileges such as 0x1fffff.

This detection is critical because unauthorized access to LSASS strongly indicates credential theft activity.

Common use cases include:

+ Incident response and threat hunting for credential theft attempts.
+ Red team simulations and blue team detection tuning.
+ Identifying malware or attacker tools accessing LSASS memory.

🔍 SPL Query

 source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 | where TargetImage="*\lsass.exe" | table _time, ComputerName, User, Image, TargetImage, GrantedAccess, CommandLine | sort -_time

💡 Query Explanation

1. Filter Sysmon ProcessAccess Events

Start by filtering Sysmon EventCode=10, which logs process handle open events, to capture all process access attempts.

source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10

2. Detect Access to LSASS

Filter for events where the TargetImage is lsass.exe, the process responsible for managing Windows login sessions and credentials.

| where TargetImage="*\\lsass.exe"

3. Select Relevant Fields

Display key fields such as timestamp, computer name, user, requesting process image, target image, granted access rights, and command line for detailed investigation.

| table _time, ComputerName, User, Image, TargetImage, GrantedAccess, CommandLine

4. Sort by Recent Events

Sort results by descending timestamp to prioritize the most recent and relevant suspicious access events.

| sort -_time

📋 Attack Simulation

For authorized testing, download and run Mimikatz on a Windows 11 test machine. Then, open an Administrator PowerShell and run these commands:

This will trigger Sysmon EventCode 10 events as Mimikatz accesses LSASS memory.

⚔️ Mitigation Steps

🔐
Enable LSASS Protection Features Enable Windows Defender Credential Guard and Protected Process Light (PPL) to harden LSASS against unauthorized access.
🛑
Restrict Privileged Access Limit administrative privileges and enforce the principle of least privilege to reduce the attack surface for credential dumping.
📜
Monitor Sysmon EventCode 10 Continuously monitor Sysmon ProcessAccess (EventCode 10) logs to detect suspicious handle opens to lsass.exe.
🛡️
Deploy Endpoint Detection and Response (EDR) Use EDR tools to detect and block known credential dumping tools like Mimikatz and suspicious memory access patterns.
🔔
Set Up Real-Time Alerting Configure SIEM solutions to alert on suspicious LSASS access attempts and anomalous process behavior.
🧹
Regularly Update and Patch Systems Keep Windows OS and security tools up to date to protect against known exploits targeting LSASS.

🚨 Alert 6: Ransomware Behavior Detection via Suspicious File Renaming and Extension Change

Detection Overview

Ransomware often encrypts files by renaming them and appending suspicious extensions such as .locked, .encrypted, .crypt, .ransom. Detecting mass renaming of files to these extensions, combined with simultaneous file modifications, is a strong indicator of an ongoing ransomware attack.

Key aspects to monitor in this alert:

+ EventCode=11: Sysmon event for file creation or renaming.
+ TargetFilename: The file being renamed or created.
+ File Extension Extraction: Detect suspicious ransomware-related file extensions.
+ Grouping and Threshold: Trigger alert when 10 or more files are renamed with suspicious extensions within 5 minutes.

This alert enables early ransomware detection, helping security teams respond quickly before widespread file encryption occurs.

🔍 SPL Query

 source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11 | where TargetFilename != "*" | eval FileExt = lower(replace(TargetFilename, ".*(\.[^\.]+)$", "\1")) | where FileExt IN (".locked", ".encrypted", ".crypt", ".ransom", ".enc", ".aes") | stats count AS RenameCount, values(TargetFilename) AS FilesRenamed BY ComputerName, User, ParentImage, _time span=5m | where RenameCount >= 10 | sort -RenameCount

💡 Query Explanation

1. Filter Sysmon File Create and Rename Events

Monitor Sysmon EventCode=11, which logs file creation and rename activities on endpoints.

source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11

2. Extract and Filter Suspicious File Extensions

Extract file extensions from TargetFilename and filter for ransomware-related extensions like .locked, .encrypted, .crypt, .ransom, .enc, and .aes.

| eval FileExt=lower(replace(TargetFilename, ".*(\.[^\.]+)$", "\1"))
| where FileExt IN (".locked", ".encrypted", ".crypt", ".ransom", ".enc", ".aes")

3. Aggregate Suspicious Rename Events

Group events by ComputerName, User, ParentImage, and 5-minute time windows, counting the number of suspicious renames.

| stats count AS RenameCount, values(TargetFilename) AS FilesRenamed BY ComputerName, User, ParentImage, _time span=5m

4. Filter for High Counts of Suspicious Renames

Flag groups where 10 or more files were renamed with suspicious extensions within a 5-minute window.

| where RenameCount >= 10
| sort -RenameCount

📋 Attack Simulation

To test this alert, create a folder on your Windows 11 machine with multiple test files. Then run PowerShell as Administrator and execute:

This script renames all files by appending .locked, simulating ransomware-like file encryption behavior. The alert should trigger within 5 minutes in Splunk.

⚠️ Warning: Use only on non-critical test files and folders!

⚔️ Mitigation Steps

🛑
Isolate Infected Machines Immediately To stop ransomware spread, isolate affected endpoints from the network once suspicious file rename behavior is detected.
💾
Maintain Regular Backups Keep secure, offline backups of important data to enable recovery without paying ransom.
🔍
Deploy Endpoint Protection Use advanced endpoint protection and ransomware behavior detection tools that monitor file renaming and extensions.
🚨
Configure Real-time Alerts Set up your SIEM to alert on mass suspicious file renames to respond quickly to ransomware attacks.
🧑‍💻
User Awareness Training Educate users on ransomware risks and safe computing practices to prevent initial infections.

🚨 Alert 7: Detect Lateral Movement via Remote PowerShell Session Creation

Detection Overview

Attackers leverage remote PowerShell sessions (e.g. Enter-PSSession or Invoke-Command) to move laterally inside networks stealthily. Detecting these remote PowerShell connections, especially from suspicious hosts or users, is a critical detection point for SOC analysts.

This alert correlates:

+ PowerShell process creation with remote commands
+ Windows Security logs indicating remote session logons
+ Optional: Network connections on PowerShell ports (5985/5986) if network logs are ingested

🔍 SPL Query

 ( source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 | search Image="*\powershell.exe" | search CommandLine="*Invoke-Command*" OR CommandLine="*Enter-PSSession*" | table _time, ComputerName, User, Image, CommandLine, ProcessId ) OR ( sourcetype="WinEventLog:Security" EventCode=4624 | search LogonType=3 | search AuthenticationPackageName="Kerberos" OR AuthenticationPackageName="Negotiate" | table _time, ComputerName, UserName, SourceNetworkAddress, LogonType ) | stats values(CommandLine) AS PowerShellCommands, values(SourceNetworkAddress) AS SourceIPs BY ComputerName, User | where isnotnull(PowerShellCommands) AND isnotnull(SourceIPs) | table _time, ComputerName, User, PowerShellCommands, SourceIPs | sort -_time

💡 Query Explanation

⚙️

Correlate Sysmon Process Creation

Detect Sysmon process creation events (EventCode=1) for PowerShell running remote commands like Invoke-Command or Enter-PSSession.

source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| search Image="*\\powershell.exe"
| search CommandLine="*Invoke-Command*" OR CommandLine="*Enter-PSSession*"
| table _time, ComputerName, User, Image, CommandLine, ProcessId

🔐

Detect Remote Logons from Security Logs

Capture Windows Security logon events (EventCode=4624) with LogonType=3 indicating remote network logons authenticated via Kerberos or Negotiate.

sourcetype="WinEventLog:Security" EventCode=4624
| search LogonType=3
| search AuthenticationPackageName="Kerberos" OR AuthenticationPackageName="Negotiate"
| table _time, ComputerName, UserName, SourceNetworkAddress, LogonType

🔎

Correlate Process Creation and Logon Events

Combine Sysmon PowerShell process creation with remote command execution and Security remote logon data to identify lateral movement via remote PowerShell sessions, including user and source IP context.

(
  source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  | search Image="*\\powershell.exe"
  | search CommandLine="*Invoke-Command*" OR CommandLine="*Enter-PSSession*"
  | table _time, ComputerName, User, Image, CommandLine, ProcessId
)
OR
(
  sourcetype="WinEventLog:Security" EventCode=4624
  | search LogonType=3
  | search AuthenticationPackageName="Kerberos" OR AuthenticationPackageName="Negotiate"
  | table _time, ComputerName, UserName, SourceNetworkAddress, LogonType
)
| stats values(CommandLine) AS PowerShellCommands, values(SourceNetworkAddress) AS SourceIPs BY ComputerName, User
| where isnotnull(PowerShellCommands) AND isnotnull(SourceIPs)
| table _time, ComputerName, User, PowerShellCommands, SourceIPs
| sort -_time

📋 Attack Simulation

To test this alert on your Windows 11 machine:

Enable PowerShell Remoting on the target machine (if not already enabled):
```
Enable-PSRemoting -Force
```
From another machine or PowerShell session, run a remote PowerShell command against the target:
```
Invoke-Command -ComputerName TARGET_HOSTNAME -ScriptBlock { hostname }
```
This will generate PowerShell process creation and remote logon events.
Verify that the alert triggers in Splunk by checking the query results.

⚔️ Mitigation Steps

🔒
Restrict PowerShell Remoting: Limit PowerShell remoting access to authorized administrators and trusted systems only.
🛑
Monitor PowerShell Usage: Continuously monitor PowerShell activity, focusing on remote command executions to detect suspicious behavior early.
🚨
Alert on Remote Sessions: Configure your SIEM to alert on unusual or unauthorized remote PowerShell sessions.
🔐
Implement Network Segmentation: Segment your network to limit lateral movement and reduce attack surface exposure.

🚨 Alert 8: Detection of Suspicious Scheduled Task Creation (Persistence Technique)

Detection Overview

Scheduled tasks are frequently abused by attackers to maintain persistence on compromised systems. Monitoring the creation of scheduled tasks—especially those initiated by unusual users or executing suspicious commands and scripts—is essential for detecting stealthy backdoors and malware persistence mechanisms.

This alert focuses on monitoring:

+ Creation of new scheduled tasks on endpoints
+ Unusual or non-administrative users creating tasks
+ Tasks executing suspicious scripts or commands
+ Task triggers that could indicate stealthy persistence
+ Changes to existing scheduled tasks

🔍 SPL Query

 source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 | search ParentImage="*\\schtasks.exe" OR (Image="*\\taskeng.exe" AND CommandLine="*/create*") | table _time, ComputerName, User, Image, ParentImage, CommandLine, ProcessId | sort -_time

💡 Query Explanation

🕒

Monitor Scheduled Task Creation via Process Events

Sysmon logs process creation events (EventCode=1) that indicate when scheduled task utilities like 'schtasks.exe' or 'taskeng.exe' create new tasks. Monitoring these events helps spot when scheduled tasks are being created or modified.

source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| search ParentImage="*\\schtasks.exe" OR (Image="*\\taskeng.exe" AND CommandLine="*/create*")
| table _time, ComputerName, User, Image, ParentImage, CommandLine, ProcessId
| sort -_time

🔍

Identify Anomalies in Scheduled Task Creators and Commands

Analyze the creators of scheduled tasks and their command lines for unusual patterns, such as uncommon users creating tasks or commands that execute suspicious scripts or payloads. This helps differentiate benign administrative tasks from potential malware persistence techniques.

source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| search ParentImage="*\\schtasks.exe" OR (Image="*\\taskeng.exe" AND CommandLine="*/create*")
| stats count by User, CommandLine, ComputerName
| sort -count

⚠️

Set Up Real-Time Alerting for Suspicious Task Creations

Implement this detection query as a real-time alert in your SIEM to get immediate notifications whenever new scheduled tasks are created. This enables rapid investigation and response to potential persistence attempts by attackers.

source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| search ParentImage="*\\schtasks.exe" OR (Image="*\\taskeng.exe" AND CommandLine="*/create*")
| table _time, ComputerName, User, Image, ParentImage, CommandLine, ProcessId
| sort -_time

📋 Attack Simulation

To trigger this alert, open an elevated PowerShell prompt (Run as Administrator) on your Windows 11 machine and run the following command:

This command creates a scheduled task named TestTask that will run once at 11:59 PM, executing a harmless PowerShell command silently. Your alert should detect this scheduled task creation event promptly.

⚔️ Mitigation Steps

🔒
Restrict Scheduled Task Creation Ensure only trusted administrators and service accounts have permissions to create or modify scheduled tasks, reducing the risk of attacker persistence.
🛡️
Monitor Scheduled Task Activity Continuously review and generate alerts for new or modified scheduled tasks, especially those created outside established maintenance windows or by unusual users.
🚨
Alert on Suspicious Commands Set alerts for scheduled tasks that execute PowerShell, scripts, or commands with hidden, encoded, or suspicious flags indicative of stealthy attacker activity.
📜
Implement Application Whitelisting Use strict application whitelisting policies to block unauthorized scripts or executables from running as scheduled tasks, effectively preventing persistence attempts.

🚨 Alert 9: Detection of Outbound Network Connections to Rare or Suspicious External IPs

Detection Overview

Attackers often communicate with Command & Control (C2) servers using rare or previously unseen external IP addresses or domains. Detecting endpoints making outbound connections to rarely contacted IPs or suspicious geolocations helps uncover stealthy exfiltration or beaconing activity.

This alert focuses on:

+ Identifying outbound connections to rare or new external IP addresses
+ Flagging network traffic directed toward suspicious or high-risk geolocations
+ Highlighting possible C2 communications or data exfiltration attempts
+ Correlating network data with endpoint activity for comprehensive detection

🔍 SPL Query

 index=network OR index=endpoint sourcetype IN ("WinEventLog:Security", "netflow", "firewall") | search direction=outbound | stats count BY src_ip, dest_ip, dest_port, dest_country, ComputerName, User | eventstats dc(dest_ip) AS DestIPCount BY src_ip | where DestIPCount = 1 | lookup threatintel_ip_blacklist ip AS dest_ip OUTPUT ip AS BlacklistedIP | where isnotnull(BlacklistedIP) OR dest_country IN ("CN", "RU", "KP", "IR") | table _time, ComputerName, User, src_ip, dest_ip, dest_port, dest_country, BlacklistedIP | sort -_time

💡 Query Explanation

🌐

Search Outbound Network Connections

Aggregate network and endpoint logs to identify all outbound connections originating from hosts within your environment. This helps establish baseline network communication patterns.

index=network OR index=endpoint sourcetype IN ("WinEventLog:Security", "netflow", "firewall")
| search direction=outbound
| stats count BY src_ip, dest_ip, dest_port, dest_country, ComputerName, User

🔎

Identify Rare or Unique External IP Contacts

Calculate the number of distinct external destination IPs contacted by each source IP. Flag sources that connect to only a single unique external IP, which may indicate suspicious beaconing or C2 communication.

| eventstats dc(dest_ip) AS DestIPCount BY src_ip
| where DestIPCount = 1

🚨

Correlate with Threat Intelligence and High-Risk Countries

Enrich results by checking destination IPs against a threat intelligence blacklist and flag connections to countries frequently associated with threat actors (China, Russia, North Korea, Iran). This increases detection fidelity.

| lookup threatintel_ip_blacklist ip AS dest_ip OUTPUT ip AS BlacklistedIP
| where isnotnull(BlacklistedIP) OR dest_country IN ("CN", "RU", "KP", "IR")
| table _time, ComputerName, User, src_ip, dest_ip, dest_port, dest_country, BlacklistedIP
| sort -_time

📋 Attack Simulation

To trigger this alert, simulate an outbound connection from your Windows 11 machine to a rarely contacted or blacklisted IP address:

(Replace 203.0.113.45 with a known blacklisted IP, an unused IP you control, or an IP from threat intelligence sources.) Alternatively, use a browser or curl to access a suspicious external site. Then, verify in Splunk that the alert fires for the connection to the suspicious destination IP.

⚔️ Mitigation Steps

🛡️
Enforce Network Egress Filtering Restrict outbound traffic strictly to approved external IPs and domains, minimizing the risk of connections to malicious command-and-control servers.
🔍
Integrate Threat Intelligence Feeds Continuously update and leverage threat intelligence to identify, block, and investigate communications with known malicious IPs and domains.
🚨
Alert on Rare or Unique External IP Connections Configure real-time alerts for endpoints that connect to rare, unique, or blacklisted IPs, as this behavior may indicate beaconing or data exfiltration attempts.
🔒
Monitor Geolocation of Outbound Connections Focus monitoring and alerting on outbound connections to high-risk or unexpected geographic locations that fall outside normal business operations.

🚨 Alert 10: Detection of Network Scanning or Reconnaissance Activity

Detection Overview

Attackers often perform network reconnaissance by scanning multiple IP addresses or ports to identify vulnerable services. Detecting unusual patterns of network connections or connection attempts from internal or external hosts can help identify early stages of an attack.

🔍 SPL Query

 index=network OR index=firewall sourcetype="netflow" OR sourcetype="firewall" | stats dc(dest_ip) AS unique_dest_ips, dc(dest_port) AS unique_dest_ports, count AS total_connections BY src_ip | where unique_dest_ips > 20 OR unique_dest_ports > 50 | table _time, src_ip, unique_dest_ips, unique_dest_ports, total_connections | sort -_time

💡 Query Explanation

📊

Aggregate Network Connection Attempts

Collect network and firewall logs and count distinct destination IP addresses and ports contacted by each source IP over a short time window.

index=network OR index=firewall sourcetype="netflow" OR sourcetype="firewall"
| stats dc(dest_ip) AS unique_dest_ips, dc(dest_port) AS unique_dest_ports, count AS total_connections BY src_ip

⚠️

Flag High Volume Scanning Behavior

Identify source IPs that contact more than 20 unique destination IPs or more than 50 unique destination ports, indicating possible scanning or reconnaissance.

| where unique_dest_ips > 20 OR unique_dest_ports > 50

📋

Display and Prioritize Results

Show the timestamp, source IP, unique destination IP and port counts, and total connections, sorted by the latest event time for timely investigation.

| table _time, src_ip, unique_dest_ips, unique_dest_ports, total_connections
| sort -_time

📋 Attack Simulation

To trigger this alert, run a simple port scan from your Windows 11 machine against a range of IP addresses or multiple ports using tools like Nmap:

This scan should generate numerous connection attempts logged in your network/firewall data, triggering the alert for high unique destination IPs or ports.

⚔️ Mitigation Steps

🛡️
Implement Network Segmentation Limit scanning scope and reduce lateral movement by segmenting your network into secure zones.
🚫
Restrict Unnecessary Network Traffic Block unused ports and restrict access to critical systems to minimize attack surface.
🔍
Monitor Network Traffic Patterns Continuously analyze network logs for abnormal connection patterns that could indicate reconnaissance.
⚠️
Respond Quickly to Scanning Alerts Investigate flagged source IPs promptly to determine if they represent attackers or false positives.

Connect With Me

Real-World SIEM Lab: Splunk, Windows Event Logs, Sysmon, and High-Fidelity Threat Detection Alerts

Overview

Objectives

Lab Overview

🌐 Network Architecture Overview

Comprehensive Installation Guide: Docker, Splunk

Step 1: Install Docker

Step 2: Install Splunk Enterprise with Docker Compose

Alert Showcase: 10 High-Fidelity Detections

🔍 SPL Query

💡 Query Explanation

1. Filter for Failed Logon Events in the Last 5 Minutes

2. Exclude Empty or Anonymous Accounts

3. Normalize Logon Type Field for Compatibility

4. Focus on User-Driven Logons (Types 2 and 10)

5. Count Failed Attempts per Account and Logon Type

6. Flag Users with 5+ Failed Attempts

7. Calculate the Attack Duration per User

8. Prioritize Most Attacked Accounts

📋 Attack Simulation

⚔️ Mitigation Steps

🔍 SPL Query

💡 Query Explanation

1. Filter Sysmon Process Creation Events

2. Detect Known Suspicious Execution Patterns

3. Present High-Value Investigation Fields

📋 Attack Simulation

⚔️ Mitigation Steps

🔍 SPL Query

💡 Query Explanation

1. Filter Windows Service Creation Events

2. Extract Service and Account Details

3. Normalize Service File Path

4. Identify Suspicious Service Paths

5. Display Important Fields

6. Sort by Most Recent

📋 Attack Simulation

⚔️ Mitigation Steps

🔍 SPL Query

💡 Query Explanation

1. Filter Sysmon Process Create Events

2. Detect Suspicious Parent-Child Process Pairs

3. Select Relevant Fields

4. Sort by Recency

📋 Attack Simulation

⚔️ Mitigation Steps

🔍 SPL Query

💡 Query Explanation

1. Filter Sysmon ProcessAccess Events

2. Detect Access to LSASS

3. Select Relevant Fields

4. Sort by Recent Events

📋 Attack Simulation

⚔️ Mitigation Steps

🔍 SPL Query

💡 Query Explanation

1. Filter Sysmon File Create and Rename Events

2. Extract and Filter Suspicious File Extensions

3. Aggregate Suspicious Rename Events

4. Filter for High Counts of Suspicious Renames

📋 Attack Simulation

⚔️ Mitigation Steps

🔍 SPL Query

💡 Query Explanation

Correlate Sysmon Process Creation

Detect Remote Logons from Security Logs

Correlate Process Creation and Logon Events

📋 Attack Simulation

⚔️ Mitigation Steps

🔍 SPL Query

💡 Query Explanation

Monitor Scheduled Task Creation via Process Events

Identify Anomalies in Scheduled Task Creators and Commands

Set Up Real-Time Alerting for Suspicious Task Creations

📋 Attack Simulation

⚔️ Mitigation Steps

🔍 SPL Query

💡 Query Explanation

Search Outbound Network Connections