ExamFinch.com My Study

Study guide

12.1 SIEM Deployments, Parsing, and Raw Logs to Alerts

Practice this exam

TryHackMe Security Analyst Level 1 SAL1

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current SAL1 Exam Facts 1.2 24-Hour Window, Check-In, and Delivery 1.3 Scoring, Retakes, Validity, and Access 1.4 MCQ Section Strategy

2 SOC Simulator Exam Skills

2.1 Analyst VM, Splunk, and Dynamic Alerts 2.2 Classification and Escalation Scoring 2.3 Case Reports and Investigation Notes

3 Network Essentials

3.1 OSI, TCP/IP, Devices, and the Three-Way Handshake 3.2 HTTP, TLS, VPN, Web Browsing, and Email Transmission

4 Operating System Basics

4.1 Windows and Linux Architecture, Auth, Filesystems, Processes 4.2 Active Directory and Event Logs for Tracing Activity

5 Cryptography, Cloud, Web and Scripting Basics

5.1 Encoding, Encryption, Hashing, and Decoding Tools 5.2 VMs vs Hosts, Cloud vs Virtual Hosting, SaaS and IaaS 5.3 Web Apps, APIs, JSON/XML, Scripts vs Compiled Programs

6 Cybersecurity Fundamentals and MITRE ATT&CK

6.1 CIA, Least Privilege, Human Factors, Log4Shell, EternalBlue 6.2 Navigating MITRE ATT&CK: Tactics, Techniques, Sub-techniques 6.3 Mapping Real Attacks onto ATT&CK Techniques

7 Kill Chain, NIST CSF, and Attack Indicators

7.1 Cyber Kill Chain Stages vs MITRE ATT&CK 7.2 NIST CSF: Identify, Protect, Detect, Respond, Recover 7.3 IoC vs IoA and the Pyramid of Pain

8 Social Engineering and Network Attacks

8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis 8.2 SPF, DKIM, DMARC, and Email Authentication Results 8.3 Port Scanning, DDoS, and Man-in-the-Middle 8.4 DNS Poisoning, ARP Spoofing, Exfiltration, and C2 Traffic Patterns

9 Web Exploitation and Endpoint Attacks

9.1 Client vs Server Vulnerabilities, XSS, and SQL Injection 9.2 Code Injection, Path Traversal, Input Validation, Patching, WAF 9.3 Initial Access (RDP/SSH), Persistence, Privilege Escalation 9.4 Credential Theft, Mimikatz, Sysmon, and Auditd

10 Command and Control, Malware, and LOLBAS

10.1 Forward vs Reverse Shells, Beaconing, Metasploit, Cobalt Strike 10.2 Malware Types, Static vs Dynamic Analysis, LOLBAS

11 EDR, Firewalls, and WAF

11.1 EDR vs AV, Telemetry, Containment, Remote Shell 11.2 Firewall Deployments, Limits, and Log Analysis 11.3 WAF Capabilities, Limits, and Rule Creation

12 SIEM and SOAR

12.1 SIEM Deployments, Parsing, and Raw Logs to Alerts 12.2 Alert Management, Threat Hunting, Triage, Reporting 12.3 SOAR Playbooks, Enrichment, and TI Integration

13 Threat Intelligence and Vulnerability Scanning

13.1 Feeds, Indicators, Classifying IPs, Domains, and Hashes 13.2 YARA and TI Integration with SIEM/SOAR 13.3 External vs Internal, Web vs Network Scanning

14 SOC Team, Activities, and Alert Triage

14.1 Blue/Red Teams, Hierarchy, and SOC Roles 14.2 Proactive vs Reactive: FP Remediation, Detection Engineering, Tabletop, DFIR, Threat Hunting 14.3 Workbooks; Ticket vs Alert vs Detection Rule 14.4 Triage Workflow, Severity, Status, and Verdicts

15 SOC Metrics, Escalation, and Communication

15.1 MTTA, MTTD, MTTR, SLA, and Lookups 15.2 Escalation Matrix, Urgent Remediation, and Cross-Team Communication

12.1 SIEM Deployments, Parsing, and Raw Logs to Alerts

Key Takeaways Explain This Topic AI

A SIEM deployment is a pipeline: collect, parse, index, correlate, then alert — not a single server that 'has the logs.'

Parsing turns raw Windows XML, syslog, proxy lines, firewall records, and cloud JSON into named fields; correlation counts or joins those fields to create an alert with severity and status.

Windows Event ID 4625 is a failed logon. A single 4625 is usually noise; a High brute-force notable appears when many 4625s share a user and source in a short window.

Keep _raw even after fields extract correctly. The TryHackMe SAL1 SOC Simulator is Splunk-first; Elastic Stack uses the same ingest-parse-index-search idea under different product names.

Last updated: September 2026

From Log Files to a SOC Queue

A Security Information and Event Management (SIEM) platform is the searchable memory of a Security Operations Center (SOC) . It pulls logs from many systems, turns messy text into consistent fields, stores those events so you can search them months later, and runs correlation logic that raises alerts when a pattern looks like abuse or a policy break.

SAL1 training content groups SIEM with the other “tools of the trade”: deployments, log parsing, how raw logs become alerts, then alert management, hunting, triage, and reporting. This section is the pipeline. Section 12.2 is how you work the queue in Splunk. Section 12.3 is what a Security Orchestration, Automation, and Response (SOAR) playbook should (and should not) do with those alerts.

The TryHackMe SAL1 SOC Simulator puts Splunk on the Analyst VM. That is the console you will actually search during the hands-on scenarios. Employers also run Microsoft Sentinel, IBM QRadar, Google Chronicle, LogRhythm, Sumo Logic, and the Elastic Stack . Learn Splunk field names and search habits for SAL1, then map the same stages — ingest, parse, index, search, alert — onto whatever brand you meet later. Splunk is the simulator SIEM, not the only SIEM in the industry.

SIEM Deployments

A deployment is not “install one box and hope.” Production SIEMs are staged pipelines:

Collection — agents, syslog listeners, API pulls, cloud connectors, HTTP event collectors.

Transport — encrypted forwarding so logs are not copied in plaintext across jump hosts.

Parsing and normalization — extract fields; map vendor names onto a shared schema.

Indexing and storage — make events searchable; apply retention (Splunk’s hot / warm / cold / frozen buckets are one way to say “fast recent data, cheaper old data”).

Detection — scheduled searches, correlation, notable events / alerts.

Presentation — dashboards, incident queues, and reports.

Splunk roles you will hear in a deployment diagram

Role Job Analyst implication

Universal Forwarder (UF) Lightweight agent: tails files, reads Windows Event Log, ships data If the UF is missing on a host, that host is invisible no matter how good your search is

Heavy Forwarder (HF) Optional parse/filter/route tier Used to drop noise or mask data before license volume hits the indexers

Indexer Parses (if needed), writes the index, answers search peers Slow searches often mean too much unparsed data or a too-wide time window

Search head Runs Search Processing Language (SPL) , dashboards, alert actions This is the UI in the SAL1 Analyst VM

Syslog / API receiver Network devices and SaaS cannot run a UF Firewalls and cloud trails arrive here, not as Windows XML

On-prem Splunk is often UF → (optional HF) → indexers → search head. Splunk Cloud hides the indexer tier; you still own inputs, sourcetype (the parsing contract), and saved searches. Splunk Enterprise Security adds a notable-event incident model; the SAL1 sim is described as Splunk plus dynamic alerts — treat “alert” as a correlation output with properties, not as a guarantee that Enterprise Security is installed.

Elastic Stack as a comparison, not a replacement

The Elastic Stack uses the same mental model with different names: Beats or Elastic Agent collect (Winlogbeat is the closest analogue to a Windows UF); Logstash or Elasticsearch ingest pipelines parse (grok, JSON, date); Elasticsearch stores and searches; Kibana is the search and alerting UI. Elastic Common Schema ( ECS ) plays a similar role to Splunk’s Common Information Model (CIM) — shared field names such as source.ip / src so one brute-force detection can cover Windows, VPN, and cloud identity. For SAL1, when you see index=wineventlog EventCode=4625 , that is Splunk spelling. The idea “filter failed logons by field” is not Splunk-only.

Deployment patterns and what each is good for

Pattern How logs arrive Typical sources What you can prove

Agent / forwarder Host software ships local files and Event Log Windows, Linux, domain controllers Host-centric: host , EventCode, user, process

Syslog receiver UDP/TCP/TLS syslog (often 514 or 6514) Firewalls, switches, rsyslog 5-tuple plus a vendor message blob until parsed

API / cloud connector SIEM polls SaaS APIs AWS CloudTrail, Azure/Entra sign-in, Microsoft 365 JSON control-plane and identity events

HTTP Event Collector / webhook Apps POST JSON Custom apps, some EDR/SOAR callbacks Structured if the sender is well written

Proxy / NDR Web proxy or Zeek/Corelight-style sensors HTTP/S metadata, DNS, connections URLs, user-agent, bytes, dest that hosts never log

Traps in deployments: collecting without parsing (terabytes of _raw and no src_ip field); mixing time zones so a “10-minute burst” is split across clocks; duplicate forwarding so one 4625 is indexed twice and looks like brute force; dropping verbose logs to save ingest cost and then discovering the forensic trail was in the dropped channel.

Log Sources a Junior Analyst Actually Reads

Windows Security (and Sysmon if present). Failed logon is Event ID 4625 . Success is 4624 . Lockout is 4740 . Explicit credentials are 4648 . Sysmon Event ID 1 is process create; 3 is network connect; 10 is process access (credential-dumping hunts). Windows events are XML; a Splunk Windows technical add-on turns them into EventCode , TargetUserName , IpAddress , LogonType , Status , FailureReason .

Linux / syslog. sshd may log Failed password for invalid user admin from 203.0.113.44 port 55821 ssh2 . Until a parser extracts user , src_ip , and action , the SIEM only has a sentence.

Web proxy. Method, URL, status, bytes, user, destination. Phishing clicks often show status=200 to a young domain; data leaving over HTTPS may appear as CONNECT tunnels.

Firewall. Source, destination, port, action, rule id. A deny storm to TCP/3389 is scanning. An allow from a finance server to a rare country on 443 can matter more than the denies.

Cloud. AWS CloudTrail ConsoleLogin with a failed authentication error; Entra ID sign-in ResultType values for bad password or lockout; Okta user.session.start failures. These are already JSON, but field names still differ ( sourceIPAddress vs ipAddress vs src_ip ) until CIM/ECS mapping.

LogonType values worth memorizing for 4624/4625

  • LogonType Meaning Why a SOC cares
  • 2 Interactive (console / unlock at keyboard) Typo at the desk; less often remote brute force
  • 3 Network (SMB, many service auth) Classic remote password guessing against file shares or LDAP
  • 5 Service Service account password problems
  • 7 Unlock Screensaver unlock failures
  • 10 RemoteInteractive (RDP) Remote desktop guessing; pair with 4624 success

Status 0xC000006A (wrong password, often in SubStatus) and 0xC000006D (generic logon failure) are “tried a password.” 0xC0000064 is unknown user (spray against names). 0xC0000234 is locked out. Correlation rules should not treat every 4625 as equal: unknown-user sprays, one-account brute force, and lockouts tell different stories.

Parsing: Raw Event, Fields, Then a Common Schema

Think in three layers:

Raw event — Splunk’s _raw . Always keep it. When a regex is wrong, _raw is the court record.

Parsed fields — key-value pairs from sourcetype rules (JSON, XML, CSV, grok-like regex). Example: EventCode=4625 , TargetUserName=svc_backup , IpAddress=203.0.113.88 , LogonType=3 .

Normalized fields — CIM (Splunk) or ECS (Elastic) names such as src , user , action , signature_id . Detection searches should prefer these so one rule covers Windows and VPN and Okta.

Sourcetype is the parsing contract: WinEventLog:Security is not linux_secure and not aws:cloudtrail . Onboard a firewall as generic syslog with no props/transforms and you will hunt with * in _raw while the brute-force saved search looks at empty src fields and never fires.

Parsing failures that look like “the SIEM is broken”: using receipt time instead of the log’s own timestamp (forwarder delay); splitting multiline Windows XML; ingesting JSON cloud logs as a single syslog message so quotes never become fields. Index time vs search time extraction both exist in Splunk; you do not need to administer props.conf for SAL1, but you do need to notice when a field is missing and fall back to _raw plus rex (section 12.2) instead of inventing a verdict.

Correlation: Many Events, One Alert

A single 4625 is usually a typo, a cached credential, or a scanner. Correlation is the logic that says this set of events is notable:

Threshold: 20 failed logons for the same TargetUserName from the same IpAddress in 5 minutes.

Diversity (password spray): one source, many distinct TargetUserName values, often 0xC0000064 .

Chain: 4625 burst then 4624 LogonType 10 from the same source — guessing that worked .

First-seen / impossible travel: more often cloud identity than 4625, but the idea is the same: join two successes that cannot both be physical.

Allow-list gap: process create for a known-bad name where the hash is not in software inventory.

The correlation search writes an alert (saved-search alert, notable, detection alert — product vocabulary varies). That object is not the raw logs. It carries severity (informational, low, medium, high, critical) and status (new, in progress, pending, suppressed, closed). Severity is how loud the queue should shout if the hypothesis is true . Status is whether a human already owns it. A Critical alert in New jumps the queue. A High alert in Suppressed because it is Tuesday’s authorized scanner may be working as designed. You triage with both properties; you do not mentally downgrade every High because the queue is long.

False-positive engineering happens after you understand this pipeline. If morning VPN reconnects trip brute force, tune the threshold or exclude the concentrator IP. Do not stop collecting 4625.

Loading diagram... Raw logs to a SIEM alert with severity and status

Worked Pipeline: Windows 4625 to a Brute-Force Alert

Environment. A domain controller runs a Splunk Universal Forwarder. Security events land in index wineventlog , sourcetype WinEventLog:Security . CIM maps IpAddress toward src and TargetUserName toward user , but the add-on fields are what you will type first in the simulator.

One raw event (simplified). Event ID 4625, account svc_backup , source IP 203.0.113.88 (documentation TEST-NET), Logon Type 3 (network), Status 0xC000006D , SubStatus 0xC000006A (wrong password), Workstation WIN-SCAN01 . _raw still contains the full XML. After parsing you can filter without grepping XML tags.

Fields the correlation search actually uses.

  • Field Example Why it matters
  • EventCode 4625 Failure, not 4624 success
  • TargetUserName svc_backup Service-style name; higher impact if guessed
  • IpAddress 203.0.113.88 Shared across the burst
  • LogonType 3 Remote network logon, not a console typo
  • SubStatus 0xC000006A Wrong password, not “account disabled”
  • _time 2026-09-19 14:02:11 Sliding window for the count

Correlation logic (concept, not a full SPL course). Over 10 minutes, count 4625s where user svc_backup and source 203.0.113.88 . If count ≥ 15, create alert Possible brute force against svc_backup . Because the account looks privileged, LogonType is 3, and volume is high, the rule assigns severity High . Status starts as New . The alert record stores a sample event, the count, the first and last _time , and a link back to the search.

What the alert is not. It is not proof of compromise. It is a hypothesis: this source tried many passwords. Your next job (section 12.2) is to search for a following 4624, unusual process activity, or threat-intel on that IP. If 203.0.113.88 is the vulnerability scanner’s jump box running an authorized password audit, the closing verdict may be false positive or benign true positive depending on local policy — but the pipeline still did the right thing: raw → fields → correlation → alert with severity and status.

If parsing had failed. You would only have _raw XML. A human might still find 4625 and svc_backup with a string search. The saved correlation would not see IpAddress as a field, the count would be wrong or zero, and no High/New notable would enter the queue. Deployment quality is detection quality.

Password spray vs brute force on the same 4625 stream. Twenty failures, one user, one IP is brute force (the worked case). Twenty failures, one IP, twenty users, often unknown-user statuses, is a spray. Same log source, different stats shape, possibly different severity (spray against many employees vs hammering one service account). Write the distinction in the case note; do not use the words interchangeably.

Independent ExamFinch material covering these SAL1 SIEM topics will keep using Splunk-oriented examples because that is what the SOC Simulator presents. If a future job hands you Kibana, you will still ask: where is collection, where is parse, where is the correlation that created this alert, and what are its severity and status?