SIEM and Log Analysis — Finding Attacks in the Noise

Every security event leaves a trace in a log somewhere. The attacker who ran mimikatz generated Windows Event ID 4624 (logon) and 4648 (explicit credential use). The ransomware encrypting files generated thousands of file modification events. The insider exfiltrating data generated unusual cloud storage access events. The challenge is not whether the evidence exists — it almost always does — but whether you are collecting the right logs, storing them long enough, and have queries that surface the signal from millions of events per day.

A Security Information and Event Management (SIEM) system centralises log collection, provides search and correlation capabilities, and generates alerts. Understanding how to use one — writing detection queries, building dashboards, and triaging alerts — is the primary skill of a SOC (Security Operations Center) analyst, one of the most in-demand roles in the US security market.

Log Sources — What to Collect and Why

SIEM Architecture — Collecting at Scale

SIEM Architecture Overview:

┌──────────────────────────────────────────────────────────────┐
│ LOG SOURCES                                                  │
│ Windows Events → WEC (Windows Event Collector) or agent     │
│ Linux syslog → rsyslog/syslog-ng → syslog forwarder         │
│ Network devices → Syslog UDP/TCP 514 or SNMP                │
│ Cloud → CloudTrail S3 → S3 ingestion connector              │
│ Applications → structured JSON logs → Kafka or Kinesis      │
└──────────────────────┬───────────────────────────────────────┘
                       │
┌──────────────────────┴───────────────────────────────────────┐
│ LOG COLLECTION LAYER                                         │
│ Elastic Beats / Fluentd / Cribl / Splunk Universal Forwarder │
│ Responsibilities: parse, filter, enrich, batch, compress     │
│ Output: structured JSON events with normalized field names   │
└──────────────────────┬───────────────────────────────────────┘
                       │
┌──────────────────────┴───────────────────────────────────────┐
│ SIEM / DATA LAKE                                             │
│ Splunk: indexed data, SPL queries, correlation rules         │
│ Elastic SIEM (ELK): Elasticsearch + Kibana + detection rules │
│ Microsoft Sentinel: KQL queries, analytics rules, playbooks  │
│ Google Chronicle: YARA-L rules, petabyte-scale retention    │
│                                                              │
│ Retention requirements:                                      │
│ - PCI-DSS: 12 months (3 months online)                      │
│ - HIPAA:   6 years                                          │
│ - SOC 2:   typically 12 months minimum                      │
└──────────────────────────────────────────────────────────────┘


# Log volume estimates (to size SIEM storage):
# Windows endpoint:      ~1,000–5,000 events/day/host
# Domain Controller:     ~100,000–500,000 events/day
# Firewall (enterprise): ~1,000,000–50,000,000 events/day
# Web server (busy):     ~100,000–1,000,000 events/day

# Rule of thumb: 1 GB/day per 1,000 events at ~1KB/event average

Essential Windows Event IDs for SOC Analysts

The following Event IDs form the backbone of Windows threat detection. Every SOC analyst must know these by number and know what suspicious patterns in them indicate.

Windows does not log process creation (4688) or PowerShell activity by default. These must be enabled via Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration. Without these, PowerShell-based attacks and LOLBin abuse are invisible in Windows event logs.

SIEM Query Languages — SPL, KQL, and Elastic EQL

Each SIEM platform has its own query language. The concepts are identical — filtering, aggregating, correlating — but syntax differs. The following examples all detect the same thing: a password spraying attack (many failed logons across many accounts from one source).

# ━━ SPLUNK SPL ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# Password spray detection:
index=wineventlog EventCode=4625 Logon_Type=3
| stats count, dc(Account_Name) as unique_accounts by src_ip
| where count > 50 AND unique_accounts > 10
| sort -count

# Active Directory Kerberoasting detection:
index=wineventlog EventCode=4769 Ticket_Encryption_Type=0x17
| stats count by Account_Name, Service_Name, Client_Address
| where count > 5
| sort -count

# Lateral movement — network logons to many hosts:
index=wineventlog EventCode=4624 Logon_Type=3
| stats dc(ComputerName) as host_count by Account_Name
| where host_count > 5
| sort -host_count

# LOLBin execution (certutil, regsvr32, wmic, mshta):
index=wineventlog EventCode=4688
  (Process_Command_Line="*certutil*" OR Process_Command_Line="*regsvr32*"
   OR Process_Command_Line="*mshta*")
  AND NOT (Creator_Process_Name="C:\Windows\System32\svchost.exe")
| table _time ComputerName Account_Name Process_Command_Line


# ━━ MICROSOFT SENTINEL / AZURE MONITOR (KQL) ━━━━━━━━━━━━━━━━

// Password spray detection:
SecurityEvent
| where EventID == 4625 and LogonType == 3
| summarize count(), dcount(TargetUserName) by IpAddress
| where count_ > 50 and dcount_TargetUserName > 10
| order by count_ desc

// Impossible travel detection (two logins from different continents):
SigninLogs
| where ResultType == 0   // successful login
| summarize by UserPrincipalName, Location, TimeGenerated
| join kind=inner (
    SigninLogs
    | where ResultType == 0
) on UserPrincipalName
| where abs(datetime_diff('minute', TimeGenerated, TimeGenerated1)) < 60
    and Location != Location1
| project UserPrincipalName, Location, Location1, TimeGenerated, TimeGenerated1

// DNS tunneling detection (unusually long subdomain queries):
DnsEvents
| where SubType == "LookupQuery"
| extend subdomain_len = strlen(Name)
| where subdomain_len > 50
| summarize count() by ClientIP, Name
| order by count_ desc


# ━━ ELASTIC / OPENSEARCH (EQL — Event Query Language) ━━━━━━━━

// Process creation with encoded PowerShell (common attacker technique):
process where process.name == "powershell.exe"
  and process.args : ("-enc", "-EncodedCommand", "-e")

// Webshell detection — web server spawning cmd/powershell:
process where process.name in ("cmd.exe", "powershell.exe")
  and process.parent.name in ("w3wp.exe", "nginx", "httpd", "apache2", "tomcat")

// Credential dumping via LSASS access:
process where process.name == "lsass.exe"
  and not process.parent.name in ("wininit.exe", "svchost.exe")

Alert Triage — From Signal to Finding

An alert is a hypothesis: "this looks like an attack." Triage is the process of proving or disproving that hypothesis with enough evidence to make a decision: escalate as a confirmed incident, or close as a false positive.

Alert triage workflow — 15-minute target per alert:

STEP 1: CONTEXT (2 min)
  □ What triggered the alert? Which rule? What event?
  □ Who is the affected user/host? What is their role?
  □ When did it happen? Business hours? Weekend? 3am?
  □ Is this a known system? New asset? Critical infrastructure?

STEP 2: INITIAL INVESTIGATION (5 min)
  □ Pull all events for this user/host in the last 24 hours
  □ Look for related events: same source IP, same user account
  □ Check threat intelligence: is the source IP/domain known malicious?
  □ Check asset inventory: is this host expected to behave this way?

STEP 3: EVIDENCE GATHERING (5 min)
  □ Expand the time window — when did unusual activity start?
  □ Look for the attack chain: recon → initial access → privilege escalation?
  □ Check endpoint data (EDR): what processes ran on the host?
  □ Check authentication logs: any concurrent unusual logins?
  □ Pull raw log evidence for documentation

STEP 4: DECISION (3 min)
  TRUE POSITIVE — escalate:
    - Create incident ticket with all evidence attached
    - Notify incident response team and affected system owner
    - Implement immediate containment if active threat confirmed

  FALSE POSITIVE — document and close:
    - Record why it is false positive
    - Update detection rule to reduce FP rate
    - Note whether tuning is needed (threshold, suppression, context)

  UNCLEAR — escalate for second opinion:
    - Document current evidence, current hypothesis
    - Flag for senior analyst or threat hunter review


# Example: Password spray triage

Alert: "50 failed logons across 15 accounts from 203.0.113.10 in 10 minutes"

Context:
  - Source IP: 203.0.113.10 → Ukraine (unusual for US company)
  - Targeted accounts: random mix of user accounts, not IT team
  - Time: 3:47 AM ET Saturday

Initial investigation:
  - Same source IP: zero prior connections in 30 days
  - TI lookup: IP flagged by AbuseIPDB (141 reports in 30 days)
  - Authentication log: 2 accounts had successful login after failures
    → user jsmith@corp.com: 7 failures then 1 success at 03:51 AM
    → user rbrown@corp.com: 4 failures then 1 success at 03:53 AM

Decision: TRUE POSITIVE — active credential compromise
  → Immediate: force password reset and session revoke for jsmith and rbrown
  → Block source IP 203.0.113.10 at perimeter firewall
  → Check jsmith and rbrown activity since 03:51 AM for lateral movement
  → Create incident ticket, notify CISO

Interview Questions — SIEM and Log Analysis

Common Mistakes — SIEM and Log Analysis