My Path to SOC Analyst with TryHackMe

Introduction

This post kicks off my new blog series: My Path to SOC Analyst with TryHackMe. Each post, I’ll be sharing updates as I progress through different courses that build the technical and analytical skills I need to become a Security Analyst. The idea is to not only learn, but document how each step contributes to my bigger career goal.

The series will cover a range of courses that gradually build my SOC analyst skill set. All being related to a day in the life of a SOC analyst.

• Intro to SIEM — learning the foundations of log collection, correlation, and analysis.
• Junior Security Analyst Intro — stepping into the Tier 1 SOC analyst role to practice triaging alerts and escalating incidents.
• Splunk101 & Splunk201 — gaining hands-on experience with Splunk, one of the most widely used SIEM platforms in enterprise SOCs.
• Benign — identifying and analyzing seemingly harmless but suspicious activity, sharpening my eye for detail.
• Investigating with Splunk — applying Splunk queries and dashboards to dig deeper into real-world security incidents.
• Investigating with ELK — practicing with the open-source ELK stack (Elasticsearch, Logstash, Kibana) for SIEM-style investigations.
• ItsyBitsy — investigating and analyzing small-scale attack scenarios to apply everything I’ve learned in a practical context.
• I nay throw some others in the mix along the way ;)

Each of these courses is designed to build on the last, creating a layered progression from basic concepts to advanced investigations. Intro to SIEM sets the foundation by introducing core monitoring tools, while Junior Security Analyst Intro puts me into the role of an entry-level SOC analyst to understand responsibilities and workflows. The Splunk101 and Splunk201 labs give me the chance to grow more comfortable with an enterprise-grade SIEM platform, focusing on both fundamental queries and advanced analysis. Benign sharpens my analytical judgment by presenting edge cases where activity may look harmless at first but requires closer examination. Investigating with Splunk and Investigating with ELK expand my technical range by teaching me to work across both commercial and open-source SIEM tools. Finally, ItsyBitsy brings everything together in a compact, scenario-based investigation that tests my ability to apply skills holistically.

Enjoy the read as I take you on my journey to become a Security Analyst!

Intro to SIEM

What I Learned

In Intro to SIEM, I learned how SIEM tools act as a centralized hub for log data coming from servers, endpoints, firewalls, and other devices. I practiced identifying different types of logs, like authentication attempts, system events, and firewall traffic Seeing how this data is normalized and presented in a SIEM platform. This really highlighted how important log data is for spotting unusual activity that could point to a security incident.

The course also walked me through the workflow of a SOC analyst. From triaging alerts to digging deeper into suspicious activity, I got a clear picture of how SIEM supports the investigative process. This was my first hands-on experience thinking like an analyst — moving beyond just running commands to actually interpreting the meaning behind the data.

Why It Matters

As someone preparing for a SOC analyst role, I know that learning SIEM isn’t optional — it’s essential. The course gave me a practical introduction to how analysts use log data to detect and investigate threats. It also showed me the importance of repeatable processes, disciplined workflows in handling security events, and gave me a leg up for the courses/labs to come.

For me, this wasn’t just about learning a tool. It was about shifting my mindset. I’m starting to think in terms of patterns, anomalies, and investigations — the same way I’ll need to think when I’m working in a real SOC environment.

Junior Security Analyst Intro

What I Learned

In this course, I stepped into the role of a Tier 1 SOC analyst — often called a Junior Security Analyst. I learned that this position is primarily focused on triaging alerts and monitoring log data in a 24/7 SOC environment. The responsibilities covered included investigating suspicious events, configuring and managing security tools, and even helping create basic intrusion detection signatures.

The course also introduced me to the SOC three-tier model and how analysts at each level work together to monitor, prevent, and respond to cyber threats. I practiced looking at alerts, analyzing them for severity, and escalating appropriately — just like I would in a real SOC. One of the most hands-on parts was simulating a day in the life of a Junior Analyst by reviewing tickets, identifying suspicious network activity, blocking a malicious IP address, and even finding a message left by the attacker.

Why It Matters

This course showed me that being a Junior SOC Analyst isn’t just about tools, but about process and mindset. Triaging alerts requires attention to detail, critical thinking, and the ability to quickly separate false positives from real threats. It also reinforced how important communication and escalation are — knowing when to handle something on my own versus when to pass it along to Tier 2 or Tier 3 analysts.

For my journey, this course helped me picture what the day-to-day responsibilities of an entry-level SOC role look like. It tied together the concepts I learned in Intro to SIEM by showing me how that log data gets used in real investigations. This step is essential for building both confidence and competence as I move forward in my path to becoming a Security Analyst.

Splunk101

What I Learned

In the Splunk101 lab, I was introduced to the fundamentals of searching and analyzing data inside Splunk — one of the most widely used SIEM platforms in enterprise environments. I learned how Splunk organizes data into indexes, and how every search begins with specifying which index to query. From there, I practiced building searches using different commands. For example, I used:

• stats count by username to quickly see activity grouped by users.
• sourceip=<ip address> to identify specific events tied to a given IP.
• source=<country> to narrow down activity by geographic location.

These exercises gave me a hands-on understanding of how flexible Splunk searches can be. By combining fields and commands, I was able to drill down into very specific sets of data, which is exactly what a SOC analyst does when investigating alerts.

Why It Matters

This lab was important because it moved me from learning about SIEM concepts in theory to applying them in a tool that SOC analysts actually use on the job. Knowing how to construct searches in Splunk is a core skill — without it, an analyst would struggle to filter through the overwhelming amount of log data a SIEM collects.

For my journey, Splunk101 gave me confidence in using Splunk’s search language to extract meaningful insights. It reinforced the idea that being a good SOC analyst isn’t about memorizing commands, but about understanding the data you’re working with and asking the right questions through your searches. Mastering this skill will make me more effective in spotting malicious activity, investigating incidents, and contributing to a SOC team from day one.

Splunk201

What I Learned

Splunk201 was a deep dive — far more extensive and hands-on than the introductory lab. The course pushed me to build targeted searches, pivot between sourcetypes, and dissect multi-stage attack activity inside a SIEM. Instead of one-off queries, I learned how to chain commands, extract and normalize fields, enrich events with threat intel, and construct investigations that follow an incident from reconnaissance through cleanup.

Some concrete Splunk SPL examples and techniques I practiced:

• Filtering by index & sourcetype
  index=main sourcetype=wineventlog — always start by narrowing the data source so searches run faster and return relevant events.
• Quick user activity summary
  index=main sourcetype=wineventlog EventCode=4624 | stats count by Account_Name
  (group successful logons by user to spot unusual volumes or unexpected service accounts).
• Find suspicious IP activity
  index=network sourcetype=bro_conn dest_ip=1.2.3.4 | stats count, sum(bytes) by src_ip dest_ip
  (identify hosts communicating with known bad destinations and examine bytes transferred).
• Pivoting on fields with stats and top
index=* sourcetype=apache_access | top clientip limit=20
  (fast surface of most active clients hitting a web service).
• Field extraction with rex and shaping results
  index=auth sourcetype=linux_secure | rex "Failed password for (?<user>\w+)" | stats count by user
  (extract usernames from free-text logs to summarize brute force attempts).
• Session and timeline assembly
  index=main sourcetype=* (src_ip=10.0.0.* OR dest_ip=10.0.0.*) | transaction src_ip startswith="StartEvent" endswith="EndEvent" maxspan=30m
  (group related events into a single transaction to see the sequence of actions for a host or user).
• Using eval for risk scoring and conditional fields
  ... | eval risk=if(match(Account_Name,"(?i)admin|root"),"high","normal") | stats count by risk
  (quickly tag events for downstream filtering or alerting).
• Threat intel enrichment with lookup
... | lookup malicious_ips ip as src_ip OUTPUT is_malicious | where is_malicious="true"
  (join external blocklists to highlight IOCs in event streams).
• Time series analysis for spotting anomalies
  index=main sourcetype=netflow | timechart span=1h count by src_ip
  (visualize host behavior over time to detect sudden spikes).

These are only sample queries — the course emphasized the why behind each pattern: pick the smallest, most-relevant dataset first (index + sourcetype), extract/normalize fields so you can pivot, and always build queries that can be reused in dashboards or alerts.

Phases I Dissected (and how Splunk helped)

In Splunk201 I practiced breaking an incident into investigative phases and applied different SPL techniques to each phase:

• Reconnaissance — I used top, stats count by src_ip and quick timecharts to show scanning behavior and identify noisy IPs hitting many endpoints. Visualizing activity density helped me prioritize which hosts to investigate.
• Initial Access — I filtered authentication logs for unusual logon patterns (e.g., logons at odd hours, new service accounts, or a surge in failed logons). Searches that combine success/failure and process/command context made it easier to separate legitimate admin activity from suspicious access attempts.
• Persistence — I searched for creation of scheduled tasks, new services, or modifications to autorun locations across sourcetypes. Field extraction and transaction helped me link these persistence events back to the originating host and user.
• Lateral Movement — By pivoting on source/destination IPs and network share access events, I could map lateral hops. Combining network sourcetypes with host event logs (joined by IP or hostname) revealed patterns like remote command execution followed by file copy activity.
• Data Collection & Exfiltration — I looked for abnormal volumes and unusual destinations using stats sum(bytes) by dest_ip and time-based anomaly detection. Large, sustained outbound transfers or use of uncommon protocols were clear red flags.
• Cleanup / Covering Tracks — Finally, I searched for deletions, log tampering, and unusual log rotation activity. Correlating audit-type events with the timeline of the attack allowed me to identify attempts to remove evidence.

Why It Matters

Splunk201 transformed my approach from running isolated queries to constructing investigations: start with a hypothesis, narrow the data by index/sourcetype, extract fields, enrich where possible, and iterate until the timeline of the incident is clear. The course showed me practical ways to make searches efficient and repeatable — skills that map directly to Tier 1 and Tier 2 SOC responsibilities (triage, hunt, and escalate with context).

Most importantly, the lab reinforced that being a strong SOC analyst isn’t about memorizing commands — it’s about thinking in queries. Each SPL example I learned is a small investigative step that, when combined, forms a robust process for detecting, dissecting, and responding to threats. That ability to move quickly from noisy alerts to an evidence-backed story is exactly what employers look for in entry-level and junior SOC roles.

Benign

What I Learned

The Benign lab was a competitive, score-based challenge that put my analytical and investigative skills to the test. Unlike traditional guided labs, this one simulated a real-world scenario where I had to identify and investigate a compromised host without step-by-step hints. Using the knowledge I gained from my previous labs. It was designed to test both speed and accuracy — my performance was scored and ranked against other TryHackMe users.

In this room, I analyzed system logs and artifacts from a potentially infected host to determine the root cause and the attacker’s actions. I followed the the hackers trail through event logs, network activity, and process data to uncover suspicious behavior that might initially appear harmless or “benign.”

The challenge forced me to think like both an attacker and a defender — to question every log entry and to validate each lead through data correlation and cross-referencing. It wasn’t about running a single command; it was about building a clear, evidence-based story of what happened on the host.

Why It Matters

Benign was one of the most realistic simulations I’ve completed so far. Working under competitive scoring conditions added pressure that mirrored a real SOC environment, where time and precision both matter. This experience helped sharpen my ability to triage quickly while maintaining accuracy, a critical skill for incident response.

The exercise also reinforced the importance of intuition and pattern recognition — not every attack looks obvious at first. Learning to spot “quiet” compromises and methodically piece together small indicators is a vital part of being an effective Security Analyst.

Investigating with Splunk

What I Learned

The Investigating with Splunk lab built directly on the foundation from Splunk201 and similar to the Benign lab. Taking me from advanced searching to full-scale threat investigation. This lab simulated a real-world scenario where I had to analyze suspicious network behavior and uncover indicators of compromise using Splunk’s powerful data analysis tools. Correlating multiple data sources, building timelines, and uncovering how an attack unfolded.

In this lab, I used Splunk’s Search Processing Language (SPL) to investigate anomalies within a compromised environment. Commands like stats, table, top, and eval helped me summarize and visualize large datasets, while filters such as index=security sourcetype=sysmon narrowed down relevant events. I ran queries similar to the ones used in Splunk 201.

By following event chains across sourcetypes, I was able to trace the attacker’s actions from initial compromise to data exfiltration. Each stage of the investigation emphasized how to think critically — verifying patterns, linking events, and ensuring that every assumption was backed by data.

Why It Matters

This lab took my analytical process to the next level. Instead of running single searches, I learned to conduct multi-phase investigations — filtering, correlating, validating, and finally reporting findings with evidence. That workflow is exactly what SOC analysts use during real incidents, and mastering it bridges the gap between lab work and real-world operations.

It also highlighted the importance of data interpretation and communication. In a SOC, finding malicious activity is only part of the job — explaining it clearly, with supporting data and context, is just as critical. The Investigating with Splunk course reinforced my ability to turn technical logs into a readable, defensible narrative of what happened and why it mattered.

This room was another step in my continuous journey to strengthen my incident detection and response skills — skills that are essential to succeeding as a future Security Analyst.

Investigating with ELK 101

What I Learned

After spending time investigating with Splunk, I wanted to broaden my experience with another major SIEM stack — ELK (Elasticsearch, Logstash, and Kibana). The Investigating with ELK 101 lab introduced me to how open-source SIEMs operate and how analysts use Kibana’s interface to visualize and search through security data.

In this lab, I investigated VPN log activity through ELK, applying similar investigative principles I’ve used in Splunk but through the lens of the Kibana Query Language (KQL). I explored the Discover tab to search and filter through logs, practiced writing KQL queries to isolate malicious IPs, and created visualizations to highlight patterns and potential indicators of compromise. By the end, I had built a dashboard that displayed authentication attempts, login success rates, and geolocation data — all vital for detecting suspicious remote access.

Why It Matters

Working with ELK showed me how flexible and powerful open-source SIEM solutions can be. As an aspiring SOC analyst, I want to be tool-agnostic — able to adapt whether a team uses Splunk, ELK, or another platform. This lab helped me understand that while interfaces and query languages differ, the underlying investigative mindset remains the same: find anomalies, validate context, and connect events into a story.

This experience also reminded me that good analysts don’t rely solely on prebuilt alerts or dashboards. They use the data creatively — crafting custom queries and visualizations to uncover what others might miss. Investigating with ELK 101 pushed me to think visually, turning raw data into actionable intelligence and making it easier to communicate findings to other SOC team members.

Each lab like this brings me closer to my goal of becoming a Security Analyst who’s confident across different SIEM ecosystems and ready to handle investigations from any angle.

ItsyBitsy

What I Learned

The ItsyBitsy lab was the perfect way to close out my TryHackMe SOC journey. This challenge pulled together everything I’ve learned — from investigating SIEM alerts and dissecting attack phases to correlating evidence and reporting findings. The scenario placed me in the role of a SOC analyst investigating a potential command-and-control (C2) communication alert.

Using ELK, I reviewed network traffic, log entries, and suspicious connections to determine if the alert was legitimate or a false positive. I applied all the techniques I’ve developed through previous labs: structured searches, data correlation, timeline building, and validating every assumption with evidence. It felt like a real shift from “student” to “analyst.”

This lab wasn’t just a recap — it was a full simulation of what a day in a SOC feels like. I started with an alert, developed hypotheses, collected data, and built an investigation timeline that clearly showed the attacker’s activity. The exercise reminded me that cybersecurity is a blend of technology, analysis, and intuition — the ability to turn raw data into a story that explains what happened, how, and why.

Why It Matters

ItsyBitsy tied everything together and proved how far I’ve come. I could see my progression — from learning what a SIEM is, to navigating Splunk and ELK confidently, to finally handling a complete incident investigation on my own. It validated all the hours I’ve spent studying and reinforced that I’m capable of thinking and working like a SOC analyst.

This experience gave me a deeper appreciation for the analyst’s role in defending organizations. Each log, alert, and query is a puzzle piece, and it’s our job to put them together before damage is done. That mindset — proactive, curious, and relentless — is what I’ve been building throughout this journey.

Closing Reflections

I’m genuinely proud of myself for staying consistent and completing this series. The Path to SOC Analyst journey has been challenging, exciting, and incredibly rewarding. It reminded me of being back in college during my senior year — but this time, every lesson genuinely excited me because it directly connects to a career I’m passionate about.

I’m not a paid ambassador for TryHackMe, but I can’t speak highly enough about the platform. It delivers hands-on, gamified learning that makes complex cybersecurity concepts approachable and practical. Each lab gave me real-world experience I can confidently take into a professional SOC environment. This post doubles as formal documentation of what I've learned and queries I've ran for the future.

As I wrap up this series, I’m grateful for the knowledge I’ve gained and the momentum I’ve built. This isn’t the end — it’s the foundation. I’ll continue sharpening my skills, pursuing certifications, and preparing for the day I officially step into a SOC role.

Thank you for following along — and here’s to the next chapter in my cybersecurity journey. 🛡️