🛡️ TryHackMe — Introduction to SIEM | Learning Guide
Platform: TryHackMe Room: Introduction to SIEM Path: Cyber Security 101 → Security Solutions Estimated Time: 120 Minutes Status: Completed ✅
Spoiler-Free Learning Guide: This article contains no TryHackMe flags, lab-specific answers, or direct task solutions. It focuses on the concepts, tools, investigation methodology, and practical skills I learned while completing the room.
Introduction
After learning Windows, command-line basics, and networking concepts, I moved into an important area of defensive cybersecurity:
SIEM
SIEM stands for:
Security Information and Event Management
A SIEM is one of the core technologies used inside a:
SOC
=
Security Operations Center
Modern organizations have hundreds or thousands of systems constantly generating security information.
For example:
Windows Workstations
Linux Servers
Firewalls
VPN Gateways
Web Servers
Routers
IDS / IPS
Applications
Cloud Services
Every one of these systems generates logs.
The challenge is:
How can a security analyst monitor all of these logs without manually checking every machine?
That is where SIEM becomes useful.
TryHackMe's Introduction to SIEM room explains how SIEM solutions collect logs from different devices, normalize them, correlate activity, trigger alerts, and help SOC analysts investigate suspicious behavior. (TryHackMe)
The room follows this learning path:
Introduction
↓
Logs Everywhere, Answers Nowhere
↓
Why SIEM?
↓
Log Sources & Ingestion
↓
Alerting Process & Analysis
↓
Hands-On SIEM Lab
↓
Conclusion
Task 1 — Introduction
The first task introduces SIEM from the perspective of a SOC analyst.
A typical organization's network may contain:
Endpoints
Servers
Network Devices
Security Appliances
Applications
Cloud Infrastructure
Each device records events.
Those events might tell us:
Who logged in?
Which file was accessed?
Which process executed?
What website was visited?
Which IP made a connection?
Was authentication successful?
Was a security rule triggered?
Individually, these are just logs.
When brought together, they can describe an entire security incident.
What Problem Does SIEM Solve?
Imagine a small company with:
100 Windows endpoints
20 Linux servers
5 firewalls
2 VPN gateways
10 web servers
Suppose each device produces hundreds of events every minute.
Without centralization:
Incident occurs
↓
Analyst logs into Server 1
↓
Checks logs
↓
Logs into Server 2
↓
Checks logs
↓
Checks firewall
↓
Checks endpoint
↓
Checks VPN
This is extremely inefficient.
Instead:
Windows ─────┐
Linux ───────┤
Firewall ────┤
VPN ─────────┤
Web Server ──┤
↓
SIEM
↓
Centralized Analysis
That is the core idea behind the entire room. (TryHackMe)
🛠️ Hands-On / Tools — Task 1
Tools / Concepts Used
TryHackMe Room
SIEM concepts
SOC workflow
Log-source identification
This task was mainly conceptual.
My first mental model became:
Devices
↓
Generate Logs
↓
SIEM Collects Them
↓
Analyst Investigates
No task-specific answer or flag is included here.
Task 2 — Logs Everywhere, Answers Nowhere
This task explains where security logs come from.
TryHackMe divides log sources into two broad categories:
Host-Centric Logs
+
Network-Centric Logs
Understanding this distinction is important because each source provides a different part of the security story. (TryHackMe)
Host-Centric Log Sources
Host-centric logs describe activity occurring:
On a computer
or
directly related to that computer
Common sources include:
Windows workstations
Linux hosts
Application servers
Database servers
Examples of host activity include:
User authentication
File access
Process execution
Registry changes
PowerShell execution
Service activity
Example
Suppose a workstation records:
10:10 → User logs in
10:12 → powershell.exe starts
10:13 → New registry key created
10:15 → Sensitive file opened
These events tell us what happened inside the endpoint.
Network-Centric Log Sources
Network-centric logs describe communication taking place across the network.
Typical sources include:
Firewalls
Routers
VPN devices
IDS
IPS
Proxy servers
Examples include:
SSH connections
FTP activity
Web traffic
VPN access
Network file sharing
Firewall connections
Example
A firewall might record:
Source IP : 10.10.20.15
Destination IP : 192.0.2.50
Destination Port: 443
Action : Allowed
That tells us something about the network communication, but not necessarily what happened inside the endpoint.
This is why multiple sources matter.
The Problem With Isolated Logs
The task then explains why checking individual logs manually does not scale.
TryHackMe highlights several major problems. (TryHackMe)
1. Too Many Log Sources
Organizations may have thousands of devices.
Each device may generate:
Hundreds
or
Thousands
of events every second.
Manually reading everything is unrealistic.
2. No Centralization
Without SIEM, logs may remain on the systems that produced them.
The analyst might need:
SSH → Linux Server
RDP → Windows Host
Web UI → Firewall
VPN Console → VPN Logs
just to investigate one incident.
3. Limited Context
This is one of the most important lessons from the task.
Consider the event:
User accessed confidential.pdf
By itself, this may be normal.
But now correlate it with:
09:01 → Login from unfamiliar VPN IP
09:03 → Access to shared drive
09:05 → PowerShell execution
09:06 → Large outbound transfer
Suddenly:
One harmless-looking event
+
Other related events
=
Potential security incident
Context changes everything.
4. Too Much Data for Manual Analysis
Humans cannot realistically inspect every event manually.
Important activity would inevitably be missed.
This creates a need for:
Automation
Detection Rules
Correlation
Alerting
5. Different Log Formats
Another major problem is that different systems represent information differently.
For example:
Windows
Event ID
Account Name
Process Name
Computer
Linux
Timestamp Host Process PID Message
Web Server
IP
Request
Status Code
User-Agent
An analyst should not have to manually interpret dozens of incompatible formats every time an incident happens.
🛠️ Hands-On / Tools — Task 2
Concepts Practiced
Host-centric logs
Network-centric logs
Log-source classification
Incident correlation
A useful exercise is asking:
Where did this event occur?
If it describes activity inside the host, I think:
Host-centric
If it describes network communication, I think:
Network-centric
The exact TryHackMe task answers are intentionally not included.
Task 3 — Why SIEM?
Now the room introduces the solution.
A SIEM collects logs from multiple systems and gives analysts a centralized place to work with them.
The high-level flow is:
Log Sources
↓
Collection
↓
Parsing
↓
Normalization
↓
Correlation
↓
Detection
↓
Alert
↓
Investigation
TryHackMe introduces five especially important SIEM capabilities: centralized collection, normalization, correlation, real-time alerting, and dashboards/reporting. (TryHackMe)
1. Centralized Log Collection
Instead of investigating every system separately:
Endpoint 1 ───┐
Endpoint 2 ───┤
Linux ────────┤
Firewall ─────┤
VPN ──────────┤
Web Server ───┤
↓
SIEM
Everything becomes accessible from one location.
This significantly improves investigation speed.
2. Parsing
A raw log might look like:
2026-09-07 18:22:14 user=alice src=10.0.0.5 action=login status=failed
A parser breaks this into fields:
Time = 18:22:14
User = alice
Source = 10.0.0.5
Action = login
Status = failed
That process is called:
Parsing
3. Normalization
Different products may use different field names.
For example:
src_ip
source_ip
client_ip
remote_address
might all represent the same concept.
A SIEM can convert them into a consistent structure.
Different Log Formats
↓
Normalization
↓
Common Representation
Normalization makes searching and correlation much easier.
4. Correlation
Correlation is where SIEM becomes especially powerful.
Imagine four different systems report:
VPN:
Unusual login
File Server:
Sensitive document accessed
Windows:
PowerShell executed
Firewall:
Large outbound connection
Each event alone may not trigger concern.
Together:
VPN
+
File Access
+
PowerShell
+
Outbound Connection
↓
Potential Account Compromise / Data Exfiltration
SIEM helps connect these events.
TryHackMe demonstrates the same idea by showing how individually normal-looking events can become suspicious when combined. (TryHackMe)
5. Real-Time Alerting
SIEM platforms contain:
Detection Rules
When log activity matches rule conditions:
Events
↓
Detection Rule
↓
Condition Matched
↓
Alert Created
A SOC analyst then investigates the alert.
6. Dashboards
SIEM dashboards summarize security information.
Examples include:
Triggered alerts
Failed logins
Events ingested
Top domains
System health
Rule triggers
Security trends
This gives analysts fast visibility into the environment.
Examples of SIEM Platforms
Common technologies include:
Splunk
Microsoft Sentinel
Elastic Security
IBM QRadar
Google Security Operations
The exact products differ, but the fundamental SIEM workflow remains similar.
🛠️ Hands-On / Tools — Task 3
Tools / Concepts Used
SIEM architecture
Parsing
Normalization
Correlation
Detection rules
Dashboards
Alerting
My quick revision flow:
Collect
↓
Parse
↓
Normalize
↓
Correlate
↓
Detect
↓
Alert
↓
Investigate
This is probably the most important sequence I took away from the room.
Task 4 — Log Sources and Ingestion
This task moves from SIEM theory to actual log sources.
The room explores examples from:
Windows
Linux
Web Servers
and then explains how those logs reach the SIEM. (TryHackMe)
Windows Logs
Windows records operating-system and application events that can be viewed using:
Event Viewer
Windows events often contain information such as:
Event ID
Timestamp
Account
Computer Name
Process
Logon Information
Security Activity
🛠️ Windows Hands-On
On a Windows machine:
Start Menu
↓
Search "Event Viewer"
Typical categories include:
Windows Logs
├── Application
├── Security
├── Setup
└── System
From a cybersecurity perspective, I may look for:
Login attempts
Account changes
Process-related activity
Service events
Security-policy changes
Linux Logs
Linux commonly stores logs under:
/var/log/
The room introduces examples including authentication, kernel, cron, and web-server logs. (TryHackMe)
Common examples:
/var/log/auth.log
/var/log/secure
/var/log/cron
/var/log/kern
/var/log/httpd/
Exact files vary by distribution and installed services.
🛠️ Linux Hands-On
List available logs:
ls -lah /var/log/
Read a log:
cat /var/log/auth.log
For long output:
less /var/log/auth.log
Watch new entries:
tail -f /var/log/auth.log
Search for a keyword:
grep "failed" /var/log/auth.log
These are general Linux log-analysis commands rather than room-specific answers.
Web Server Logs
Web servers generate extremely valuable security information.
A simplified request log might look like:
192.0.2.25 - - [07/Sep/2026:18:30:00] "GET /login HTTP/1.1" 200
From this we might extract:
Source IP
Timestamp
HTTP Method
Requested Resource
Status Code
User-Agent
These fields can help investigate:
Brute-force attempts
Web attacks
Reconnaissance
Suspicious scanning
Abnormal requests
Log Ingestion
Logs need to reach the SIEM somehow.
TryHackMe introduces four common ingestion approaches. (TryHackMe)
1. Agent / Forwarder
A lightweight program is installed on the endpoint.
Endpoint
|
Agent
|
v
SIEM
The agent monitors relevant logs and forwards them.
Splunk commonly refers to this type of component as a:
Forwarder
2. Syslog
Syslog is widely used for centralized logging.
Conceptually:
Router ─────┐
Firewall ───┤
Linux ──────┤
Server ─────┤
↓
Syslog
↓
SIEM
3. Manual Upload
Sometimes analysts already have an offline log file.
A SIEM may allow:
Upload Log
↓
Parse Data
↓
Search / Analyze
This can be useful during investigations and training.
4. Port-Based Forwarding
A SIEM can listen on a configured network port.
Endpoint
|
| Log Data
v
SIEM Listening Port
Logs received on that port are then processed.
🛠️ Hands-On / Commands — Task 4
Tools Used
Windows Event Viewer
Linux /var/log
Web-server logs
Agent / Forwarder
Syslog
Manual ingestion
Port-based ingestion
Useful Linux commands:
ls /var/log
less /var/log/auth.log
tail -f /var/log/auth.log
grep -i "error" <logfile>
A useful investigation habit is:
Identify log source
↓
Understand fields
↓
Determine ingestion method
↓
Normalize data
↓
Search centrally
Task 5 — Alerting Process and Analysis
Collecting logs is useful.
But a SOC analyst cannot manually inspect every event.
That is why SIEM solutions use:
Detection Rules
A detection rule contains logic describing activity we want to identify.
TryHackMe uses examples such as repeated failed logins, successful login after multiple failures, USB insertion, and unusually large outbound transfers. (TryHackMe)
Detection Rule Logic
A simplified rule might say:
IF
failed_login_count >= threshold
WITHIN
short_time_window
THEN
Create Alert
Another example:
Multiple Failed Logins
+
Successful Login
↓
Possible Account Compromise
Why Normalization Matters
Suppose one system records:
username=alice
another records:
user=alice
and another records:
account_name=alice
Detection rules become much easier when normalization converts them into a consistent field such as:
user = alice
Therefore:
Raw Logs
↓
Normalization
↓
Consistent Fields
↓
Detection Rules
Alert Investigation
Once an alert appears, the analyst does not immediately assume:
Alert = Attack
Instead:
Alert
↓
Open related events
↓
Check detection rule
↓
Review user / host / IP / process
↓
Build context
↓
Determine verdict
True Positive vs False Positive
This distinction is extremely important.
True Positive
The SIEM raised an alert and actual suspicious/malicious activity exists.
Alert Raised
+
Threat Exists
=
True Positive
False Positive
The SIEM raised an alert, but the activity was legitimate.
Alert Raised
+
No Real Threat
=
False Positive
False positives are not useless.
They can indicate that the detection logic needs:
Rule Tuning
TryHackMe specifically notes that false positives may require rule adjustments to avoid repeatedly alerting on expected behavior. (TryHackMe)
Possible Analyst Actions
After investigation, actions might include:
Close benign alert
Tune detection rule
Investigate further
Contact asset owner
Block malicious IP
Isolate infected host
Escalate incident
The action depends on context.
🛠️ Hands-On / Methodology — Task 5
Tools / Concepts Used
Detection rules
Event correlation
Alert investigation
True positives
False positives
Rule tuning
Response actions
My investigation checklist became:
1. What rule triggered?
2. Which event matched?
3. Which user was involved?
4. Which host was involved?
5. Which process was involved?
6. What source/destination IPs exist?
7. What happened before and after?
8. Is the activity expected?
9. True Positive or False Positive?
10. What response is appropriate?
This is a workflow I can reuse in future SIEM labs.
Task 6 — Lab Work
This was the practical part of the room.
TryHackMe provides a simulated SIEM dashboard where suspicious activity can be generated and investigated. (TryHackMe)
The goal is not simply to identify an alert.
The real workflow is:
Suspicious Activity
↓
Alert Triggered
↓
Open Alert
↓
Inspect Related Event
↓
Identify Process
↓
Identify User
↓
Identify Host
↓
Inspect Detection Rule
↓
Find Matching Condition
↓
Determine Verdict
↓
Choose Response
Step 1 — Start With the Alert
When the alert appears, I first ask:
What exactly triggered?
Useful fields may include:
Alert name
Timestamp
Rule
Severity
Host
User
Process
Step 2 — Examine the Event
Next:
Alert
↓
Related Event
I inspect fields such as:
process_name
user
hostname
command_line
timestamp
depending on what the platform provides.
Step 3 — Inspect the Detection Rule
A detection rule may contain something conceptually like:
IF process_name contains suspicious_term
THEN raise alert
I compare:
Actual event
vs
Rule condition
to understand why the SIEM generated the alert.
Step 4 — Build Context
An isolated process name is not enough.
I ask:
Who executed it?
On which machine?
When?
Was the action expected?
What else happened around the same time?
Context determines whether an alert is actually malicious.
Step 5 — Classify the Alert
After investigation:
Legitimate activity?
↓
False Positive
or:
Confirmed suspicious activity?
↓
True Positive
Step 6 — Take the Correct Action
A SIEM analyst does more than observe.
Depending on the incident:
False Positive
↓
Close / Tune
True Positive
↓
Investigate / Contain / Escalate
The lab reinforces this complete alert-analysis cycle.
I am intentionally not publishing the lab's process name, username, hostname, matching term, classification answer, action choice, or flag.
🛠️ Hands-On / Tools — Task 6
Tools Used
TryHackMe SIEM simulator
Dashboard
Alert view
Event details
Detection rule
Process information
User information
Host information
Alert classification
Response action
My repeatable SOC workflow:
ALERT
↓
EVENT
↓
RULE
↓
CONTEXT
↓
VERDICT
↓
ACTION
That is probably the most valuable practical takeaway from the room.
Task 7 — Conclusion
By the end of Introduction to SIEM, SIEM no longer felt like simply:
"A dashboard containing logs"
Instead, I understand it as an entire security workflow:
Endpoints
Servers
Firewalls
Routers
VPN
Web Servers
|
v
LOG SOURCES
|
v
INGESTION
|
v
PARSING
|
v
NORMALIZATION
|
v
CORRELATION
|
v
DETECTION RULES
|
v
ALERT
|
v
INVESTIGATION
|
v
TRUE / FALSE POSITIVE
|
v
RESPONSE
The room concludes by pointing learners toward more advanced SOC and SIEM material including Splunk and incident-investigation rooms. (TryHackMe)
Tools & Concepts Practiced
| Tool / Concept | Purpose |
|---|---|
| SIEM | Centralized security monitoring |
| Windows Event Viewer | Inspect Windows events |
/var/log/ |
Common Linux log location |
cat |
Read log files |
less |
Review long logs |
tail -f |
Monitor new log entries |
grep |
Search logs |
| Agent / Forwarder | Send endpoint logs to SIEM |
| Syslog | Centralized log forwarding |
| Parsing | Split logs into useful fields |
| Normalization | Convert logs to a consistent structure |
| Correlation | Connect related events |
| Detection Rules | Identify suspicious activity |
| Alerts | Notify analysts of rule matches |
| SIEM Dashboard | Summarize security activity |
| True Positive | Alert corresponds to real suspicious activity |
| False Positive | Benign activity triggered detection |
| Rule Tuning | Improve detection quality |
Key Lessons Learned
1. Logs Are Evidence
A single log may appear insignificant.
But logs can reconstruct:
Who
Did What
Where
When
From Which System
Using Which Process
That makes logging fundamental to cybersecurity investigations.
2. Centralization Saves Investigation Time
Without SIEM:
Check Host A
Check Host B
Check Firewall
Check VPN
Check Web Server
With SIEM:
Search One Central Platform
That is a huge operational advantage.
3. Correlation Creates Context
This was one of my biggest takeaways.
Event A
+
Event B
+
Event C
+
Event D
=
Security Story
Individual events may look harmless.
Together they may expose malicious behavior.
4. Normalization Enables Detection
Detection rules need consistent data.
Different formats
↓
Normalization
↓
Consistent fields
↓
Reliable searching & detection
Without normalization, SIEM analysis would be much harder.
5. An Alert Is the Beginning, Not the Answer
One of the most important SOC lessons:
Alert ≠ Incident
An alert means:
Something matched a detection rule.
The analyst still needs to investigate.
6. False Positives Are Part of Detection Engineering
A false positive does not automatically mean the rule is useless.
Instead:
False Positive
↓
Understand cause
↓
Tune rule
↓
Better future detection
Detection improves continuously.
My Final Mental Model
SECURITY ENVIRONMENT
|
┌──────────────────┼──────────────────┐
| | |
ENDPOINTS NETWORK SERVERS
| | |
└──────────────────┼──────────────────┘
|
LOGS
|
v
SIEM
|
┌─────────────────┼─────────────────┐
| | |
COLLECT NORMALIZE CORRELATE
| | |
└─────────────────┼─────────────────┘
|
DETECTION RULE
|
v
ALERT
|
v
SOC ANALYST
|
┌───────┴───────┐
| |
FALSE POSITIVE TRUE POSITIVE
| |
TUNE RESPOND
Ethical Learning Note
This article is a learning guide, not an answer dump.
I included:
✅ SIEM concepts
✅ Log-analysis methodology
✅ Generic commands
✅ Alert-investigation workflow
✅ Detection concepts
✅ Defensive-security lessons
while intentionally excluding:
❌ TryHackMe flags
❌ Direct room-question answers
❌ Lab-specific usernames
❌ Lab hostnames
❌ Suspicious-process answer
❌ Detection-rule answer
❌ Final lab flag
The goal is to document what I learned while still allowing other students to solve the TryHackMe room independently.
Resources
🌐 TryHackMe Room: Introduction to SIEM
👨💻 TryHackMe Profile: sunnysharma11200
💻 GitHub Repository: tryhackme-writeups
✍️ Hashnode Blog: cybersecurity-learning.hashnode.dev
Connect with Me
TryHackMe: sunnysharma11200
GitHub: SunnySharma04
Hashnode: cybersecurity-learning
LinkedIn: Sunny Sharma
Happy Learning! 🚀
