SOC L1 Alert Triage: TryHackMe

Learn more about SOC alerts and build a systematic approach to efficiently triaging them.

Task 1: Introduction

An alert is a core concept for any SOC team, and knowing how to handle it properly ultimately decides whether a security breach is detected and prevented, or missed and devastating. This is an entry level but essential room for SOC L1 analysts to understand the concept and lifecycle of alerts, from event generation to correct resolution.

Familiarise with the concept of SOC alert
Explore alert fields, statuses, and classification
Learn how to perform alert triage as an L1 analyst
Practice with real alerts and SOC workflows
Prepare for SOC Simulator and SAL1 certification

Understand common attacks on networks, Windows, and Linux
Know SOC roles and duties, especially of L1 analysts

You were granted access to the SOC dashboard in the TryHackMe SIEM, and you will need it to complete most of the tasks. Open the attached website in a separate window, familiarise yourself with it, and move on to the next task!

No answer is needed.

Task 2: Events and Alerts

Imagine yourself as a SOC intern, looking at the monitor of your mentor, a SOC L1 or L2 analyst, and seeing hundreds of alerts appear, moving between statuses and eventually disappearing from some dashboard or console. You notice lots of alerts named “Email Marked as Phishing”, a few “Unusual Gmail Login Location”, and one scary “Unapproved Mimikatz Usage” inside a red column. What are these alerts, how are they formed, and what should we do with them? Let’s find out!

First, an event must occur, like user login, process launch, or file download. Then, the system, like your OS, a firewall, or a cloud provider must log the event. After that, all system logs must be shipped to a security solution like SIEM or EDR. The SOC team can receive millions of logs per day from thousands of different systems, where most of the events are expected, but some require attention. Alert, a notification generated by a security solution when a specific event or sequence of events occurs, is what saves SOC analysts from manual log review by highlighting only suspicious, anomalous events. With alerts, analysts triage just dozens of alerts per day instead of millions of raw logs.

SOC L1 analysts are the first line of defence, and they are the ones who work with alerts the most. Depending on various factors, L1 analysts may receive zero to a hundred alerts a day, every one of which can reveal a cyberattack. Still, everyone in the SOC team is somehow involved in the alert triage:

SOC L1 analysts: Review the alerts, distinguish bad from good, and notify L2 analysts in case of a real threatSOC L2 analysts: Receive the alerts escalated by L1 analysts and perform deeper analysis and remediation
SOC engineers: Ensure the alerts contain enough information required for efficient alert triage
SOC manager: Track speed and quality of alert triage to ensure that real attacks won't be missed

Answer the questions below
What is the number of alerts you see in the SOC dashboard?

What is the name of the most recent alert you see?

  Double-Extension File Creation

Task 3: Alert Properties

Now that you know how alerts are generated, it’s time to review their content. While the details differ for every SIEM or security solution, the alerts generally have a few main properties you must understand before taking them. Don’t worry if you find some confusing, as you will hear more about some in the upcoming tasks.

Answer the questions below
What was the verdict for the “Unusual VPN Login Location” alert?

What user was mentioned in the “Unusual VPN Login Location” alert?

Task 4: Alert Prioritisation

Okay, you can now read and understand the alert. What’s next? Recall the second task, where you see hundreds of alerts but have to choose which to pick up first. The process of deciding which to take is called Alert Prioritisation, and it is crucial to ensure timely detection of a threat, especially with many alerts in the queue.

Every SOC team decides on its own prioritisation rules and usually automates them by setting the appropriate alert sorting logic in SIEM or EDR. Below, you may see the generic, simplest, and most commonly used approach:

Filter the alerts
Make sure you don’t take the alert that other analysts have already reviewed, or that is already being investigated by one of your teammates. You should only take new, yet unseen and unresolved alerts.
Sort by severity
Start with critical alerts, then high, medium, and finally low. This is because detection engineers design rules so that critical alerts are much more likely to be real, major threats and cause much more impact than medium or low ones.
Sort by time
Start with the oldest alerts and end with the newest ones. The idea is that if both alerts are about two breaches, the hacker from the older breach is likely already dumping your data, while the “newcomer” has just started the discovery.

Answer the questions below
Should you first prioritise medium over low severity alerts? (Yea/Nay)

Yea

Should you first take the newest alerts and then the older ones? (Yea/Nay)

Nay

Assign yourself to the first-priority alert and change its status to In Progress.
The name of your selected alert will be the answer to the question.

Potential Data Exfiltration

Task 5: Alert Prioritisation

Finally, you are ready to review the chosen alert! The process is quite operationally heavy, but you will soon see why every step is important. Also, note that the alert review by SOC analysts can also be called alert triage, alert handling, alert processing, alert investigation, or alert analysis. During this module, we will stick to the Alert Triage option.

The initial steps are designed to ensure that you take ownership of the assigned alert and avoid interfering with alerts being handled by other analysts, and confirm that you are fully prepared to proceed with the detailed investigation. You achieve it by first assigning the alert to yourself, moving it to In Progress, and then familiarising yourself with the alert details, like its name, description, and key indicators.

This is the most complex step, requiring you to apply your technical knowledge and experience to understand the activity and properly analyse its legitimacy in SIEM or EDR logs. To support L1 analysts with this step, some teams develop Workbooks (also known as playbooks or runbooks) — instructions on how to investigate the specific category of alerts. If workbooks are not available, below are some key recommendations:

Understand who is under threat, like the affected user, hostname, cloud, network, or website
Note the action described in the alert, like whether it was a suspicious login, malware, or phishing
Review surrounding events, looking for suspicious actions shortly after or before the alert
Use threat intelligence platforms or other available resources to verify your thoughts

Your decisions here determine whether you found or missed the potential cyberattack. Some actions, like Escalation or Commenting, will be explained in the following rooms, so don’t worry if they sound complex right now. First, decide if the alert you investigated is malicious (True Positive) or not (False Positive). Then, prepare your detailed comment explaining your analysis steps and verdict reasoning, return to the dashboard and move it to the Closed status.

SOC Dashboard Notes

If you didn’t receive a flag after your triage, it means that the values you set are wrong.
You can reset the SOC dashboard by clicking Restart on the top right in the TryHackMe SIEM.

Answer the questions below
Which flag did you receive after you correctly triaged the first-priority alert?


🔍 Alert Summary
Field Value
Date/Time Mar 21st, 2025 at 13:30
Alert Type Potential Data Exfiltration
Severity Critical
Status Awaiting Action
Source IP 192.168.45.66
Source Network UK04/MEETINGROOM
Destination *.zoom.us
Sent Data 5.8 GB
Received Data 5.2 GB

This alert is triggered because over 5GB of data was transferred from a meeting room device to *.zoom.us, which is a legitimate domain used for video conferencing.

Considering:

The network location isUK04/MEETINGROOMlikely a conference room setup.
The domain zoom.us is widely recognized and commonly used for video meetings (screen sharing, large file sharing, etc.).
The data transfer direction matches expectations during a Zoom call (uploads for video/audio/screenshare, downloads for incoming streams).

📝 Closing Statement (for ticket or tool)
False Positive – Expected Behavior.
Alert triggered due to 5.8 GB of outbound data from UK04/MEETINGROOM to *.zoom.us on March 21, 2025. Verified that Zoom is a legitimate video conferencing platform. Based on context and destination domain, this is consistent with normal business activity (e.g., screen sharing, video calls). No signs of malicious behavior.
Action Taken: Reviewed traffic, confirmed business use.
Resolution: No further action needed.

THM{looks_like_lots_of_zoom_meetings}

Which flag did you receive after you correctly triaged the second-priority alert?

🔍 Alert Summary

Field Value
Date/Time Mar 21st, 2025 at 13:58
Alert Type Double-Extension File Creation
Severity High
Host LPT-HR-009 (HR department laptop)
Process chrome.exe (browser)
User S.Conway
File Created C:\Users\S.Conway\Downloads\cats2025.mp4.exe
Source URL https://freecatvideoshd.monster/cats2025.mp4.exe
File MD5 14d8486f3f63875ef93cfd240c5dc10b

The file name uses a double extension (.mp4.exe) — classic phishing/malware tactic to disguise executables as media files.
The URL (freecatvideoshd.monster) is highly suspicious and not a known legitimate site.

51 antivirus engines flagged this file as malware — that’s well beyond the safe threshold.
File likely downloaded via Chrome by the user S.Conway, maybe thinking it was a cat video.
Filename on VT: h0t.exe — often used by malicious payloads.

Analyst Comment 
True Positive – Malicious File Detected.
Detected creation of suspicious file cats2025.mp4.exe on host LPT-HR-009 via Chrome (user: S.Conway). 
File was downloaded from https://freecatvideoshd.monster, a known malicious domain. 
File hash 14d8486f3f63875ef93cfd240c5dc10b flagged by 51/73 AV engines on VirusTotal.
Actions Taken: Isolated affected host, escalated to IR, scanning for lateral spread.
Next Steps: Awaiting further analysis from IR team.

THM{how_could_this_user_fall_for_it?}

Which flag did you receive after you correctly triaged the third-priority alert?

🔍 Alert Summary

Field Value
Date/Time Mar 21st, 2025 at 13:02
Alert Type Download from GitHub Repository
Severity Low
Host LPT-IT-063
User G.Chandler
Network VPN/DEVELOPERS
URL Accessed https://github.com/facebook/react

The GitHub repo accessed is facebook/react, which is a legitimate open-source JavaScript library developed by Facebook (now Meta).
The user (G.Chandler) is part of the IT/developer team and was working over VPN — fits the context of a developer using a common, trusted library.
No signs of suspicious behavior or malicious download here.

Analyst Comment

False Positive – Developer Activity.
Alert triggered due to GitHub access from user G.Chandler on host LPT-IT-063 via VPN. 
User accessed the official React repository (https://github.com/facebook/react), 
which is a widely used and trusted JavaScript library.
Action Taken: Reviewed access, confirmed as legitimate.
Resolution: No further action required.

THM{should_we_allow_github_for_devs?}

Task 6: Conclusion

Congratulations on successfully triaging the alerts! Of course, closing the alert as True Positive won’t prevent the attack, but it is a great start. Next, you will learn about proper alert commenting and case reporting, correct escalation procedures, and actions made by L2 analysts after the escalation. We hope you enjoyed the room!

Answer the questions below

I am ready to move on!

No answer needed

Sort by time
Start with the oldest alerts and end with the newest ones. The idea is that if both alerts are about two breaches, the hacker from the older breach is likely already dumping your data, while the “newcomer” has just started the discovery.