# 🛡️ TryHackMe — Introduction to SIEM | Learning Guide

> **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:

```text
Security Information and Event Management
```

A SIEM is one of the core technologies used inside a:

```text
SOC
=
Security Operations Center
```

Modern organizations have hundreds or thousands of systems constantly generating security information.

For example:

```text
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](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

The room follows this learning path:

```text
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:

```text
Endpoints
Servers
Network Devices
Security Appliances
Applications
Cloud Infrastructure
```

Each device records events.

Those events might tell us:

```text
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:

```text
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:

```text
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:

```text
Windows ─────┐
Linux ───────┤
Firewall ────┤
VPN ─────────┤
Web Server ──┤
             ↓
            SIEM
             ↓
     Centralized Analysis
```

That is the core idea behind the entire room. ([TryHackMe](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

* * *

## 🛠️ Hands-On / Tools — Task 1

### Tools / Concepts Used

```text
TryHackMe Room
SIEM concepts
SOC workflow
Log-source identification
```

This task was mainly conceptual.

My first mental model became:

```text
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:

```text
Host-Centric Logs
        +
Network-Centric Logs
```

Understanding this distinction is important because each source provides a different part of the security story. ([TryHackMe](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

* * *

# Host-Centric Log Sources

Host-centric logs describe activity occurring:

```text
On a computer
or
directly related to that computer
```

Common sources include:

```text
Windows workstations
Linux hosts
Application servers
Database servers
```

Examples of host activity include:

```text
User authentication
File access
Process execution
Registry changes
PowerShell execution
Service activity
```

* * *

## Example

Suppose a workstation records:

```text
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:

```text
Firewalls
Routers
VPN devices
IDS
IPS
Proxy servers
```

Examples include:

```text
SSH connections
FTP activity
Web traffic
VPN access
Network file sharing
Firewall connections
```

* * *

## Example

A firewall might record:

```text
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](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

* * *

## 1\. Too Many Log Sources

Organizations may have thousands of devices.

Each device may generate:

```text
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:

```text
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:

```text
User accessed confidential.pdf
```

By itself, this may be normal.

But now correlate it with:

```text
09:01 → Login from unfamiliar VPN IP
09:03 → Access to shared drive
09:05 → PowerShell execution
09:06 → Large outbound transfer
```

Suddenly:

```text
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:

```text
Automation
Detection Rules
Correlation
Alerting
```

* * *

## 5\. Different Log Formats

Another major problem is that different systems represent information differently.

For example:

### Windows

```text
Event ID
Account Name
Process Name
Computer
```

### Linux

```text
Timestamp Host Process PID Message
```

### Web Server

```text
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

```text
Host-centric logs
Network-centric logs
Log-source classification
Incident correlation
```

A useful exercise is asking:

```text
Where did this event occur?
```

If it describes activity **inside the host**, I think:

```text
Host-centric
```

If it describes **network communication**, I think:

```text
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:

```text
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](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

* * *

# 1\. Centralized Log Collection

Instead of investigating every system separately:

```text
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:

```text
2026-09-07 18:22:14 user=alice src=10.0.0.5 action=login status=failed
```

A parser breaks this into fields:

```text
Time   = 18:22:14
User   = alice
Source = 10.0.0.5
Action = login
Status = failed
```

That process is called:

```text
Parsing
```

* * *

# 3\. Normalization

Different products may use different field names.

For example:

```text
src_ip
source_ip
client_ip
remote_address
```

might all represent the same concept.

A SIEM can convert them into a consistent structure.

```text
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:

```text
VPN:
Unusual login

File Server:
Sensitive document accessed

Windows:
PowerShell executed

Firewall:
Large outbound connection
```

Each event alone may not trigger concern.

Together:

```text
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](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

* * *

# 5\. Real-Time Alerting

SIEM platforms contain:

```text
Detection Rules
```

When log activity matches rule conditions:

```text
Events
   ↓
Detection Rule
   ↓
Condition Matched
   ↓
Alert Created
```

A SOC analyst then investigates the alert.

* * *

# 6\. Dashboards

SIEM dashboards summarize security information.

Examples include:

```text
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:

```text
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

```text
SIEM architecture
Parsing
Normalization
Correlation
Detection rules
Dashboards
Alerting
```

My quick revision flow:

```text
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:

```text
Windows
Linux
Web Servers
```

and then explains how those logs reach the SIEM. ([TryHackMe](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

* * *

# Windows Logs

Windows records operating-system and application events that can be viewed using:

```text
Event Viewer
```

Windows events often contain information such as:

```text
Event ID
Timestamp
Account
Computer Name
Process
Logon Information
Security Activity
```

* * *

## 🛠️ Windows Hands-On

On a Windows machine:

```text
Start Menu
   ↓
Search "Event Viewer"
```

Typical categories include:

```text
Windows Logs
├── Application
├── Security
├── Setup
└── System
```

From a cybersecurity perspective, I may look for:

```text
Login attempts
Account changes
Process-related activity
Service events
Security-policy changes
```

* * *

# Linux Logs

Linux commonly stores logs under:

```bash
/var/log/
```

The room introduces examples including authentication, kernel, cron, and web-server logs. ([TryHackMe](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

Common examples:

```text
/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:

```bash
ls -lah /var/log/
```

Read a log:

```bash
cat /var/log/auth.log
```

For long output:

```bash
less /var/log/auth.log
```

Watch new entries:

```bash
tail -f /var/log/auth.log
```

Search for a keyword:

```bash
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:

```text
192.0.2.25 - - [07/Sep/2026:18:30:00] "GET /login HTTP/1.1" 200
```

From this we might extract:

```text
Source IP
Timestamp
HTTP Method
Requested Resource
Status Code
User-Agent
```

These fields can help investigate:

```text
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](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

* * *

## 1\. Agent / Forwarder

A lightweight program is installed on the endpoint.

```text
Endpoint
   |
 Agent
   |
   v
 SIEM
```

The agent monitors relevant logs and forwards them.

Splunk commonly refers to this type of component as a:

```text
Forwarder
```

* * *

## 2\. Syslog

Syslog is widely used for centralized logging.

Conceptually:

```text
Router ─────┐
Firewall ───┤
Linux ──────┤
Server ─────┤
            ↓
          Syslog
            ↓
           SIEM
```

* * *

## 3\. Manual Upload

Sometimes analysts already have an offline log file.

A SIEM may allow:

```text
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.

```text
Endpoint
    |
    | Log Data
    v
SIEM Listening Port
```

Logs received on that port are then processed.

* * *

## 🛠️ Hands-On / Commands — Task 4

### Tools Used

```text
Windows Event Viewer
Linux /var/log
Web-server logs
Agent / Forwarder
Syslog
Manual ingestion
Port-based ingestion
```

Useful Linux commands:

```bash
ls /var/log
```

```bash
less /var/log/auth.log
```

```bash
tail -f /var/log/auth.log
```

```bash
grep -i "error" <logfile>
```

A useful investigation habit is:

```text
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](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

* * *

# Detection Rule Logic

A simplified rule might say:

```text
IF
failed_login_count >= threshold

WITHIN
short_time_window

THEN
Create Alert
```

Another example:

```text
Multiple Failed Logins
          +
Successful Login
          ↓
Possible Account Compromise
```

* * *

# Why Normalization Matters

Suppose one system records:

```text
username=alice
```

another records:

```text
user=alice
```

and another records:

```text
account_name=alice
```

Detection rules become much easier when normalization converts them into a consistent field such as:

```text
user = alice
```

Therefore:

```text
Raw Logs
   ↓
Normalization
   ↓
Consistent Fields
   ↓
Detection Rules
```

* * *

# Alert Investigation

Once an alert appears, the analyst does not immediately assume:

```text
Alert = Attack
```

Instead:

```text
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.

```text
Alert Raised
     +
Threat Exists
     =
True Positive
```

* * *

## False Positive

The SIEM raised an alert, but the activity was legitimate.

```text
Alert Raised
     +
No Real Threat
     =
False Positive
```

False positives are not useless.

They can indicate that the detection logic needs:

```text
Rule Tuning
```

TryHackMe specifically notes that false positives may require rule adjustments to avoid repeatedly alerting on expected behavior. ([TryHackMe](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

* * *

# Possible Analyst Actions

After investigation, actions might include:

```text
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

```text
Detection rules
Event correlation
Alert investigation
True positives
False positives
Rule tuning
Response actions
```

My investigation checklist became:

```text
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](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

The goal is not simply to identify an alert.

The real workflow is:

```text
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:

```text
What exactly triggered?
```

Useful fields may include:

```text
Alert name
Timestamp
Rule
Severity
Host
User
Process
```

* * *

# Step 2 — Examine the Event

Next:

```text
Alert
   ↓
Related Event
```

I inspect fields such as:

```text
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:

```text
IF process_name contains suspicious_term
THEN raise alert
```

I compare:

```text
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:

```text
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:

```text
Legitimate activity?
      ↓
False Positive
```

or:

```text
Confirmed suspicious activity?
      ↓
True Positive
```

* * *

# Step 6 — Take the Correct Action

A SIEM analyst does more than observe.

Depending on the incident:

```text
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

```text
TryHackMe SIEM simulator
Dashboard
Alert view
Event details
Detection rule
Process information
User information
Host information
Alert classification
Response action
```

My repeatable SOC workflow:

```text
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:

```text
"A dashboard containing logs"
```

Instead, I understand it as an entire security workflow:

```text
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](https://tryhackme.com/room/introtosiem?utm_source=chatgpt.com))

* * *

# 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:

```text
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:

```text
Check Host A
Check Host B
Check Firewall
Check VPN
Check Web Server
```

With SIEM:

```text
Search One Central Platform
```

That is a huge operational advantage.

* * *

## 3\. Correlation Creates Context

This was one of my biggest takeaways.

```text
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.

```text
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:

```text
Alert ≠ Incident
```

An alert means:

```text
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:

```text
False Positive
      ↓
Understand cause
      ↓
Tune rule
      ↓
Better future detection
```

Detection improves continuously.

* * *

# My Final Mental Model

```text
                    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:

```text
✅ SIEM concepts
✅ Log-analysis methodology
✅ Generic commands
✅ Alert-investigation workflow
✅ Detection concepts
✅ Defensive-security lessons
```

while intentionally excluding:

```text
❌ 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](https://tryhackme.com/room/introtosiem)
    
*   👨‍💻 **TryHackMe Profile:** [sunnysharma11200](https://tryhackme.com/p/sunnysharma11200)
    
*   💻 **GitHub Repository:** [tryhackme-writeups](https://github.com/SunnySharma04/tryhackme-writeups)
    
*   ✍️ **Hashnode Blog:** [cybersecurity-learning.hashnode.dev](https://cybersecurity-learning.hashnode.dev/)
    

* * *

# Connect with Me

*   **TryHackMe:** [sunnysharma11200](https://tryhackme.com/p/sunnysharma11200)
    
*   **GitHub:** [SunnySharma04](https://github.com/SunnySharma04/tryhackme-writeups)
    
*   **Hashnode:** [cybersecurity-learning](https://cybersecurity-learning.hashnode.dev/)
    
*   **LinkedIn:** [Sunny Sharma](https://www.linkedin.com/in/sunny-sharma-2487312a7/)
    

* * *

*Happy Learning!* 🚀