# 10 — SIEM and Log Analysis
## 1. SIEM Fundamentals
A Security Information and Event Management (SIEM) platform is the centralised hub for security operations. It ingests logs from thousands of sources, normalises disparate data formats, correlates events in real-time, and generates alerts for suspicious activity.
### What is a SIEM and How It Works
**Core functions:**
1. **Log collection**: Receives syslog, JSON, CEF, LEEF, and proprietary formats from endpoints, network devices, cloud services, applications
2. **Parsing and normalisation**: Translates vendor-specific formats into a standard schema (e.g., Elastic Common Schema, Splunk's default fields)
3. **Storage and indexing**: Stores terabytes of logs in searchable indices (full-text or field-level indexing)
4. **Correlation**: Applies rules to detect multi-event patterns (e.g., failed login followed by success = brute force)
5. **Alerting**: Triggers notifications when rules fire, integrates with ticketing systems
6. **Reporting and dashboards**: Visualises trends, compliance metrics, drill-down investigative views
### Use Cases: Detection, Investigation, Compliance
- **Detection**: Real-time alerts on suspicious patterns (impossible travel, credential dumping, C2 beaconing)
- **Investigation**: Forensic search across months of historical logs; timeline reconstruction
- **Compliance**: Evidence for SOC 2, ISO 27001, HIPAA audits; retention policies enforced
- **Threat hunting**: Proactive searches for IOCs, MITRE ATT&CK coverage gaps, suspicious user behaviour
### Major SIEM Platforms
| SIEM | Strengths | Weakness | Typical Cost |
|---|---|---|---|
| **Splunk** | Most flexible; excellent for SOC; Enterprise Security (ES) add-on for MITRE ATT&CK correlation | Expensive; high learning curve | £50k–500k+/year |
| **Microsoft Sentinel** | Cloud-native; tight Azure/M365 integration; cost-effective for Microsoft shops | Limited on-prem flexibility; smaller ecosystem | £1–3 per GB ingested |
| **IBM QRadar** | Strong network forensics; good for regulated industries; built-in USM (User and Entity Behaviour Analytics) | Expensive; slower on large data volumes | £100k+/year |
| **Elastic SIEM** | Open-source Elasticsearch core; cost-effective; modern UX | Requires operational expertise; less out-of-box rules | £0–50k/year (Elastic Cloud paid tier) |
| **Chronicle** | Google Cloud native; fast ingest (not indexed); threat intelligence integration | Proprietary language (YARA-L); limited on-prem | £50k+/year |
### SIEM vs SOAR vs XDR
- **SIEM**: Log aggregation, correlation, detection, investigation
- **SOAR** (Security Orchestration, Automation and Response): Automated playbooks, ticket management, integrations with tools (e.g., trigger EDR isolation on Splunk alert)
- **XDR** (Extended Detection and Response): Unified analytics across endpoints, network, cloud; correlates data at source before SIEM
Modern deployments often combine: EDR agent → logs sent to SIEM → SOAR automation triggered on alert → XDR console shows correlated evidence.
---
## 2. Critical Log Sources for IR
### Windows Event Logs
Windows generates over 1,000 event types across multiple channels. IR focuses on a subset of critical events.
**Master table of critical Event IDs:**
| Event ID | Source | Description | IR Significance |
|---|---|---|---|
| **4624** | Security | Successful login | Detect legitimate admin access or attacker using valid credentials |
| **4625** | Security | Failed login | Brute force detection; detect scanning |
| **4648** | Security | Login with explicit credentials | `runas` command; unusual user running as another |
| **4634** | Security | Logoff | Normal user activity baseline |
| **4647** | Security | User logoff | Planned session termination |
| **4672** | Security | Privilege use (administrator logon) | Critical for lateral movement detection |
| **4768** | Security | Kerberos pre-authentication request | Golden ticket detection; brute force on DC |
| **4769** | Security | Kerberos service ticket request | Lateral movement via Kerberos |
| **4771** | Security | Kerberos pre-authentication failure | Brute force; ticketing issues |
| **4776** | Security | NTLM credential validation | Credential theft; pass-the-hash attempts |
| **4720** | Security | User account created | Detect rogue admin account creation |
| **4722** | Security | User account enabled | Reactivation of dormant backdoor account |
| **4723** | Security | Attempt to set password | Password reset by admin (suspicious if out-of-band) |
| **4725** | Security | User account disabled | Indicator of containment action |
| **4726** | Security | User account deleted | Cleanup; account destruction |
| **4728** | Security | Member added to security group | Privilege escalation via group membership |
| **4732** | Security | Member added to local group | Local admin group changes |
| **4740** | Security | User account locked out | Brute force consequence |
| **4673** | Security | Process with privileged service called | Process attempting privilege escalation |
| **4697** | Security | Service installed | Persistence mechanism (backdoor service) |
| **4698** | Security | Scheduled task created | Persistence via scheduled task (off-hours execution) |
| **4702** | Security | Scheduled task updated | Modification of legitimate task for persistence |
| **4688** | Security | Process created | Malware execution, command-line audit logging |
| **4689** | Security | Process terminated | Process injection clues if unexpected termination |
| **4663** | Security | File access attempt | Data exfiltration; document access patterns |
| **4670** | Security | Permissions changed | File ACL modification; access control evasion |
| **5140** | Security | Network share connected | Lateral movement to UNC path |
| **5142** | Security | Network share object added | Share creation (possible C2 staging) |
| **5145** | Security | Detailed file share access | Directory access on share (requires audit policy) |
| **5156** | Security | Windows Filtering Platform allowed connection | Firewall allow rule; DNS queries |
| **5157** | Security | Windows Filtering Platform blocked connection | Outbound C2 attempt blocked; detection success |
| **7034** | System | Service failed to start | Backdoor service failed (incomplete persistence) |
| **7035** | System | Service sent stop signal | Service was stopped (manual or automatic) |
| **7036** | System | Service stopped/started | Maintenance activity or forensic shutdown |
| **7040** | System | Service startup type changed | Automatic → Manual change (evasion tactic) |
| **7045** | System | Service installed | Second indicator of service persistence (System channel) |
| **1100** | Security | Audit log was cleared | Cover-up activity; must alert |
| **1102** | Security | Audit log was cleared | Second source of log clearing (Event Viewer source) |
| **1104** | Security | Audit log is full | Insufficient retention; logs may be overwritten |
#### Logon Types Reference
| Logon Type | Code | Description | IR Relevance |
|---|---|---|---|
| Interactive | 2 | User logged in locally (console, RDP) | Detect lateral movement via RDP |
| Network | 3 | Share/file access, network login | Normal network traffic; less suspicious |
| Batch | 4 | Scheduled task execution | Legitimate automation; check for rogue tasks |
| Service | 5 | Service account activation | Service-based C2; backdoor service start |
| Unlock | 7 | Screen unlock after locked | Normal user activity |
| NewCredentials | 9 | `runas /netonly`; credential delegation | Attackers accessing network as another user |
| RemoteInteractive | 10 | RDP login | Primary lateral movement vector |
| CachedInteractive | 11 | Domain login with cached credentials | Offline attacks; domain unavailable |
**Splunk search to detect privileged account misuse:**
```spl
index=windows source=*Security* EventCode=4672 Account_Name != "SYSTEM" NOT Account_Name IN (admin, svc_*)
| stats count, latest(ComputerName) by Account_Name, Logon_ID
| where count > 5
```
### Sysmon Event IDs
Sysmon is a Windows system service providing system activity logging with forensic granularity. It complements native Windows Event Logs.
**Critical Sysmon events:**
| Event ID | Description | IR Use |
|---|---|---|
| **1** | Process created | Malware execution; command-line args visible; parent process chain |
| **2** | File creation time changed | Timestomping detection |
| **3** | Network connection | C2 beaconing; lateral movement to unusual IP/port |
| **7** | Image loaded (DLL, driver) | DLL injection; loading from unusual paths |
| **8** | CreateRemoteThread | Process injection; Metasploit stager execution |
| **10** | Process accessed | Credential dumping (LSASS access); debugging |
| **11** | File created | Malware staging area; dropper file paths |
| **12/13/14** | Registry events | Registry modification; persistence mechanism installation |
| **15** | FileCreateStreamHash | Alternate data stream detection (file:zone.identifier) |
| **22** | DNS query | C2 domain resolution; data exfiltration domain queries |
**Sysmon configuration best practice:**
```xml
powershell
-enc
-NoProfile
mimicat
procdump
crypt32.dll
```
### Linux Logs
Linux centralises logs in `/var/log/`. Key IR files:
| File | Content | IR Use |
|---|---|---|
| `/var/log/auth.log` (Debian) or `/var/log/secure` (RHEL) | SSH logins, sudo usage, authentication failures | Brute force, privilege escalation, lateral movement |
| `/var/log/syslog` | System messages, cron jobs, kernel warnings | System compromise indicators |
| `/var/log/audit/audit.log` | auditd output (if enabled) | Syscall-level visibility; file access |
| `/home/[user]/.bash_history` | User's command history | Attacker's typed commands (if not cleared) |
| `/root/.bash_history` | Root's command history | Root-level compromise indicators |
| `journalctl` | Systemd journal (modern distros) | Process starts, errors, service changes |
| `/var/lib/apt/history.log` (Debian) | Package installation history | Supply chain compromise, tool installation |
**Example: Detect SSH brute force in auth.log:**
```bash
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn
# Output: 1234 192.168.1.50 (IP with 1000+ failures = brute force)
```
### Network Device Logs
Firewalls, routers, and IDS/IPS devices log allowed/denied traffic.
**Firewall logs:**
```
Source_IP,Dest_IP,Dest_Port,Protocol,Action,Timestamp
203.0.113.45,10.0.0.50,445,TCP,ALLOW,2026-04-07T09:15:00Z
203.0.113.45,10.0.0.50,445,TCP,ALLOW,2026-04-07T09:15:05Z
203.0.113.45,10.0.0.50,445,TCP,ALLOW,2026-04-07T09:15:10Z
```
Interpretation: Attacker 203.0.113.45 scanning port 445 (SMB) on internal network 10.0.0.50 = lateral movement attempt.
**IDS/IPS alerts:**
```
Alert: ET MALWARE DNS Query to Known Malicious Domain
Src: 192.168.1.50:54321 | Dest: 8.8.8.8:53 | Query: malware.com | Confidence: High
```
### Cloud Logs
Cloud services generate API-level audit logs distinct from host/network logs.
**AWS CloudTrail:**
```json
{
"eventTime": "2026-04-07T09:15:00Z",
"eventSource": "iam.amazonaws.com",
"eventName": "CreateAccessKey",
"sourceIPAddress": "203.0.113.45",
"userIdentity": {
"principalId": "AIDAJ1234567890ABCDE",
"userName": "admin"
},
"requestParameters": {
"userName": "new_backdoor_user"
}
}
```
Interpretation: Attacker created new IAM user for persistent AWS access.
**Azure Activity Log:**
```json
{
"authorization": {
"action": "Microsoft.Compute/virtualMachines/write",
"scope": "/subscriptions/[ID]/resourceGroups/prod/providers/Microsoft.Compute/virtualMachines/webserver-01"
},
"caller": "attacker@company.com",
"eventTimestamp": "2026-04-07T09:15:00Z",
"resourceType": "Microsoft.Compute/virtualMachines"
}
```
Interpretation: Attacker modified production VM (possible lateral movement or persistence).
**Microsoft 365 Unified Audit Log:**
```json
{
"CreationTime": "2026-04-07T09:15:00Z",
"Operation": "New-InboxRule",
"ObjectId": "admin@company.com",
"Parameters": {
"Name": "Archive",
"Enabled": true,
"ForwardTo": "attacker@external.com"
}
}
```
Interpretation: Attacker created email forwarding rule for data exfiltration.
---
## 3. SIEM Correlation Rules for IR
Correlation rules detect multi-event patterns in real-time. Effective rules have:
- **Clear trigger condition**: What events/fields must match
- **Time window**: Events within N seconds/minutes
- **Threshold**: Minimum count to fire alert
- **Context enrichment**: Lookup against known-good lists (admin IPs, service accounts)
- **Alert severity**: Critical (requires immediate action) vs informational (tune weekly)
### Example: Brute Force Detection
**Pseudocode:**
```
DETECT: Same user fails login 10+ times within 5 minutes
WINDOW: 5 minutes
SOURCE: Windows Event Log, Event ID 4625 (failed login)
GROUPBY: Account_Name, ComputerName
IF COUNT(EventCode=4625) >= 10:
FIRE ALERT: "Brute force detected"
SEVERITY: High
CONTEXT: Lookup Account_Name in admin_accounts; suppress if admin (false positive)
```
**Splunk SPL:**
```spl
index=windows source=*Security* EventCode=4625
| stats count as failures by Account_Name, Computer
| where failures >= 10
| lookup admin_accounts.csv Account_Name OUTPUT is_admin
| where is_admin != "true"
```
### Example: Successful Login After Many Failures
```
DETECT: User fails login multiple times, then succeeds
PURPOSE: Detect successful brute force or credential compromise
WINDOW: 15 minutes
```
**Splunk SPL:**
```spl
index=windows source=*Security* (EventCode=4625 OR EventCode=4624)
| eval type=case(EventCode=4625, "failure", EventCode=4624, "success")
| stats count(eval(type="failure")) as failures, count(eval(type="success")) as successes by Account_Name, Computer
| where failures >= 5 AND successes > 0
| fields Account_Name, Computer, failures, successes
```
### Example: Account Created and Used Immediately
```
DETECT: New user account created (4720), then logs in within 1 hour
PURPOSE: Detect rogue admin account creation
```
**Splunk SPL:**
```spl
index=windows source=*Security* EventCode=4720
| transaction Account_Name startswith=(EventCode=4720) endswith=(EventCode=4624) maxpause=1h
| stats count by Account_Name, Computer
| where count > 0
```
### Example: Process Spawned from Unusual Parent
```
DETECT: Office application (Word, Excel, etc.) spawns cmd.exe or PowerShell
PURPOSE: Detect malicious macro execution
```
**Splunk SPL:**
```spl
index=sysmon source=*sysmon* EventCode=1
| eval parent_image=lower(parent_image), image=lower(image)
| where
(match(parent_image, "(winword|excel|powerpnt|onenote)")
AND match(image, "(cmd|powershell|rundll32)"))
| stats count by Computer, parent_image, image, CommandLine
```
### Example: PowerShell with Encoded Commands
```
DETECT: PowerShell execution with encoding parameters
PURPOSE: Detect obfuscated malware execution
```
**Splunk SPL:**
```spl
index=windows source=*PowerShell* EventCode=4104
| search "*-enc*" OR "*-NoProfile*" OR "*-NonInteractive*"
| eval script_text=substr(ScriptBlockText, 1, 200)
| stats count, latest(host) by script_text
| where count > 1
```
### Example: Lateral Movement via SMB
```
DETECT: Process creates network share connection (Event 5140), followed by process execution on remote system
PURPOSE: Detect pass-the-hash or live migration
```
**Splunk SPL:**
```spl
index=windows source=*Security* (EventCode=5140 OR EventCode=5145)
| search "\\*\Admin$" OR "\\*\C$"
| stats count by Source_IP, Account_Name, Share_Name, Computer
```
### Example: Data Exfiltration (Large Outbound Transfer)
```
DETECT: User/host transfers >100 MB outbound to non-business IP in 10 minutes
PURPOSE: Detect data exfiltration, ransomware C2, cryptomining
```
**Splunk SPL:**
```spl
index=network source=proxy bytes_out > 104857600
| stats sum(bytes_out) as total_bytes, count as connections by src_ip, dest_ip
| where total_bytes > 104857600
| lookup trusted_ips.csv ip AS dest_ip OUTPUT is_trusted
| where is_trusted != "true"
```
---
## 4. Splunk for IR
Splunk is the leading commercial SIEM, especially in SOC environments. IR teams use Splunk to search historical logs, create dashboards, and investigate incidents.
### Basic SPL (Search Processing Language)
SPL is a piped command language: `index=foo | stats count by field | where count > 10`
**Key syntax:**
```spl
# Retrieve all Windows security events
index=windows source=*Security*
# Filter to specific event IDs
index=windows source=*Security* EventCode=4624 OR EventCode=4625
# Show only failed logins with failed count
index=windows EventCode=4625
| stats count as failures by Account_Name
# Time range (must be in search bar or -earliest/-latest parameters)
index=windows earliest=-24h@h latest=now
# Case-insensitive pattern match
index=windows EventCode=4688 | search CommandLine="*mimikatz*"
```
### Common IR Searches
**Failed logins by user (last 24 hours):**
```spl
index=windows EventCode=4625 earliest=-24h
| stats count as failures by Account_Name, ComputerName
| sort - failures
| head 20
```
**Account lockouts (possible brute force containment):**
```spl
index=windows EventCode=4740 earliest=-7d
| stats count as lockouts, latest(_time) as last_lockout by Account_Name
| convert ctime(last_lockout)
```
**Process execution timeline (forensic reconstruction):**
```spl
index=windows source=*Sysmon* EventCode=1 Computer=WEBSERVER-01 earliest=-2d
| eval Process_Start=strftime(_time, "%Y-%m-%d %H:%M:%S"), ParentImage=split(ParentImage, "\\")
| table Process_Start, ParentImage, Image, CommandLine
| sort _time
```
**Outbound connections from host:**
```spl
index=sysmon EventCode=3 Computer=COMPROMISED-HOST
| stats count as connections, latest(_time) as last_connection by DestinationIp, DestinationPort, Protocol
| sort - connections
```
**Data volume by destination (exfiltration baseline):**
```spl
index=network earliest=-30d host=INTERNAL
| stats sum(bytes_out) as total_bytes by dest_ip
| where total_bytes > 1000000000
| convert ctime(latest_time)
```
**Scheduled task creation/modification:**
```spl
index=windows EventCode=4698 OR EventCode=4702
| stats count by TaskName, Account_Name, ComputerName, EventCode
| eval action=case(EventCode=4698, "Created", EventCode=4702, "Modified")
```
### Splunk Enterprise Security (ES)
Enterprise Security is a premium add-on providing:
- **MITRE ATT&CK correlation**: Maps observed events to techniques/tactics
- **Risk scores**: Accumulates risk per user/asset
- **Notable events**: High-fidelity alerts automatically marked for investigation
- **Threat intelligence**: Feeds imported (IOCs, malware names, IP lists)
**Using ES for triage:**
```spl
index=notable severity=high status=new
| stats count by threat_object, threat_category
| sort - count
```
---
## 5. Elastic/Kibana for IR
Elasticsearch (ELK Stack) is an open-source alternative, widely adopted. Kibana is the visualisation/query interface.
### KQL (Kibana Query Language) Basics
KQL is simpler than SPL, field-focused:
```kql
# Match specific field value
host.name: "webserver-01"
# Wildcard
process.name: pow*
# Range
event.timestamp > now-24h
# AND/OR/NOT
(host.name: webserver* AND event.code: 4625) OR (event.category: network AND network.protocol: http)
# Exists (field has any value)
event.code:*
```
### Common IR Queries in KQL
**Detect PowerShell execution with encoding:**
```kql
process.name: powershell.exe AND process.command_line: (*-enc* OR *EncodedCommand*)
```
**List all failed SSH logins:**
```kql
event.action: "authentication_failure" AND event.category: authentication
```
**Outbound HTTPS from unusual process:**
```kql
process.name: ("firefox.exe" OR "svchost.exe") AND network.protocol: https AND network.direction: outbound
```
### ECS (Elastic Common Schema) Field Mapping
ECS is a standardised schema for event logs. Key fields:
- `host.name` — Computer hostname
- `process.name`, `process.pid` — Process name and ID
- `process.parent.name` — Parent process name
- `process.command_line` — Full command line
- `event.code` — Event ID (Windows), syslog severity (Linux)
- `network.protocol` — TCP, UDP, ICMP, etc.
- `network.transport` — Layer 4 protocol
- `user.name` — Username
- `file.path` — File path
- `destination.ip`, `destination.port` — Network destination
- `event.action` — Specific action (authenticate, modify, delete)
**Mapping native logs to ECS:**
```json
{
"event": {
"code": 4625,
"action": "authentication_failure"
},
"user": {
"name": "admin"
},
"host": {
"name": "DC-01"
},
"source": {
"ip": "203.0.113.45"
}
}
```
### Detection Rules and Alerts
Elastic provides pre-built detection rules covering MITRE ATT&CK techniques. Organisations customise for their environment.
**Example rule: Suspicious Process Creation (Execution T1059)**
```yaml
name: Suspicious PowerShell Execution
rule_id: c123d456e7890f1a2b3c4d5e6f7a8b9c
severity: high
query:
- process.name: powershell.exe
- process.command_line: (*Invoke-WebRequest* OR *IEX* OR *-enc*)
- NOT process.parent.name: (explorer.exe OR cmd.exe)
lookback: 5m
alert:
condition: WHEN count() > 0
output: Alert on suspicious PowerShell execution
```
### Timeline Investigation Feature
Kibana's Timeline allows interactive forensic investigation:
1. Create new timeline
2. Add events from search results
3. Pinpoint timeline (drag to specific timespan)
4. Add annotations (attacker action notes)
5. Export for report
---
## 6. Log Retention and Management
Proper log retention balances cost, legal requirements, and IR capability.
**Recommended retention periods:**
| Log Type | Retention | Rationale |
|---|---|---|
| Security events (Windows, auth) | 90–180 days | Typical incident discovery window; regulatory (PCI-DSS 90d min) |
| Application logs | 30 days | High volume; slower forensic value |
| Network/proxy logs | 30–90 days | Volume vs exfiltration detection window |
| Cloud audit logs (AWS, Azure) | 90–365 days | Regulatory (HIPAA 6 yr); cost manageable in cloud |
| Change logs (configuration) | 180 days | Persistence mechanism timeline |
| DNS logs | 30 days | C2 detection window; volume-heavy |
**Log forwarding architecture (best practice):**
```
[Endpoint] → (syslog/JSON/CEF) → [Log Collector] → [SIEM/Cloud]
↓
[Local Buffer]
(survive outage)
```
**Log integrity (signing):**
Prevent attacker from modifying forwarded logs:
- **TLS encryption** in transit (syslog over TLS)
- **HMAC-SHA256** signing at source
- **Syslog server** validates signatures before storage
- **Immutable archive** (append-only storage, WORM — Write Once Read Many)
**Cloud log archiving (cost optimisation):**
```
Hot storage (0–30 days): Fast, expensive (SSD)
Warm storage (30–90 days): Slower, moderate cost (HDD)
Cold archive (90–365 days): Very slow, cheap (cloud archive)
```
Example AWS S3 lifecycle policy:
```json
{
"Rules": [
{
"ID": "Archive old logs",
"Status": "Enabled",
"Transitions": [
{
"Days": 30,
"StorageClass": "STANDARD_IA"
},
{
"Days": 90,
"StorageClass": "GLACIER"
}
]
}
]
}
```
---
## 7. Building a Detection Engineering Practice
Modern SOCs adopt detection-as-code: detection rules are version-controlled, tested, deployed systematically.
### Detection as Code Concept
Rather than manual rule creation in SIEM UI:
1. **Write rule in YAML/JSON** (version control friendly)
2. **Test against baseline** (true positive: rule fires on known bad activity; false positive: rule fires on benign activity)
3. **Deploy to production** (automated via CI/CD)
4. **Monitor tuning metrics** (false positive rate, alert volume, MTTR)
5. **Iterate** (reduce false positives, increase coverage)
### MITRE ATT&CK Coverage Mapping
Track which techniques are detected:
```
T1055 Process Injection:
✓ Covered by: Sysmon Event 8 (CreateRemoteThread) rule
✓ Covered by: Memory forensics (volatility malfind)
✗ Not covered: Reflective injection (in-memory only)
T1078 Valid Accounts:
✓ Covered by: Event 4624 + 4625 brute force rule
✓ Covered by: Privilege use (Event 4672) rule
✗ Not covered: Cloud identity (AWS IAM)
```
### Detection Rule Lifecycle
```
[Develop] → [Test on baseline] → [Deploy to staging] → [Tune] → [Promote to production]
↓ ↓
↓ [Monitor MTTR, FP rate] ←--
↓
[Gather requirements from incident post-mortems]
```
### False Positive Management
High false positive rates cause alert fatigue and missed real incidents.
**Techniques to reduce FPs:**
- **Whitelist known-good activity**: Service account logons, scheduled backups
- **Time-based exceptions**: Maintenance windows (suppress alerts 2am–4am Sunday)
- **User-based exceptions**: High-velocity users (bulk file operations)
- **Process-based exceptions**: Known benign processes (antivirus scans, updates)
**FP tracking template:**
| Rule | False Positive | Root Cause | Fix | Date Resolved |
|---|---|---|---|---|
| PowerShell Encoding Detection | Windows Update PS script | Update uses -enc parameter | Exclude UpdateOrchestrator.exe | 2026-04-05 |
| Lateral Movement SMB | Legitimate backup to \\nas\share | Backup job runs nightly | Whitelist backup service account | 2026-04-06 |
### Sigma Rules (Universal Detection Format)
Sigma is a standardised rule format translating to Splunk SPL, KQL, Elastic rules, etc.
**Sigma rule example:**
```yaml
title: Suspicious PowerShell Execution
id: 0af1d8b3-c8d1-4ff5-a4c2-c4b8c4d3b3a1
status: test
date: 2026-04-07
modified: 2026-04-07
author: SOC Team
references:
- https://mitre.org/techniques/T1059/004
logsource:
category: process_creation
product: windows
service: sysmon
detection:
selection:
Image|endswith: powershell.exe
CommandLine|contains:
- '-enc'
- 'IEX'
- 'Invoke-WebRequest'
filter:
ParentImage|contains: 'explorer.exe'
condition: selection and not filter
falsepositives:
- Legitimate PowerShell scripts for system administration
level: high
```
**Generate SPL/KQL from Sigma:**
```bash
# Install pySigma
pip install pysigma
# Convert to Splunk SPL
sigma convert --target splunk rule.yml
# Output: (Image="*powershell.exe" AND (CommandLine="*-enc*" OR CommandLine="*IEX*")) OR (Image != "*explorer.exe")
```
---
## Related Files
- [[01-Incident-Response-Foundations]]
- [[06-Containment-and-Eradiation]]
- [[09-Digital-Forensics-for-IR]]
- [[11-Threat-Intelligence]]
## Tags
#SIEM #LogAnalysis #Splunk #ElasticSearch #Kibana #WindowsEventLogs #Sysmon #Detection #CorrelationRules #BlueTeam