# SOC Alert Triaging - Tinsel Triage (TryHackMe) 🎉🧑‍🎄

This write-up came a little later than expected. The initial version of the Microsoft Sentinel environment was quite difficult to access, and it slowed down a lot of the hands-on progress. Thankfully, TryHackMe updated the Azure access, making everything far smoother — and I’m genuinely grateful, because it finally allowed me to fully explore and complete the Microsoft Sentinel challenge.

In this task, we dive into Microsoft Sentinel, a cloud-native SIEM designed for real-time threat detection and investigation. Working inside Sentinel brings back the core fundamentals of search-driven analysis using Kusto Query Language (KQL), and serves as a reminder of how powerful logs become when properly queried, filtered, and correlated.

This write-up walks through the experience of reviewing alerts, performing triage, and analysing system activity across multiple hosts during the festive-themed investigation. With Sentinel’s visibility, we’re able to reconstruct attacker behaviour, validate detections, and understand the true sequence of events unfolding inside the environment.

## Introduction

**The Story**

![Task banner for day DAY 10](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1761798411436.svg align="left")

The Best Festival Company's Security Operations Center was in chaos. Screens flickered, lights flashed, and the sound of alerts echoed through the room like a digital thunderstorm. The elves rushed between consoles, their faces lit by the glow of red and orange warnings. It was raining alerts, and no one knew where the storm had begun.

Whispers spread through the SOC as tension filled the air. Something strange was happening across the cloud environment, and the timing couldn't be worse. As the blizzard of alerts grew heavier, one name surfaced among the worried elves: the evil Easter Bunnies. But why now? And what were they after this time?

## **Learning Objectives**

* Understand the importance of alert triage and prioritisation
    
* Explore Microsoft Sentinel to review and analyse alerts
    
* Correlate logs to identify real activities and determine alert verdicts
    

## Alert Triaging Primer

## **It's Raining Alerts**

McSkidy was notified that it's raining alerts; something unusual is happening within the Azure tenant. The dashboards are lighting up with suspicious activities, and early signs indicate a possible attack from the Evil Bunnies. The Best Festival Company must act fast to survive this onslaught before it affects the entire season's operations.

![Depiction of raining alerts, affecting the festivities of the Best Festival Company.](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1763630654527.png align="left")

Before investigating these alerts in Microsoft Sentinel, McSkidy must step back and understand what's happening. When alerts start flooding in, jumping straight into each one isn't efficient since not all alerts are equal. Some are noise, others are false positives, and a few may indicate real threats in progress.

This is where alert triaging becomes critical. Triaging helps security teams identify which alerts deserve immediate attention, which can be deprioritised, and which can be safely ignored for a moment. The process separates chaos from clarity, allowing analysts like McSkidy's SOC team to focus their time and resources where it truly matters.

## **Alert Triaging**

Now, let's continue the discussion about alert triaging. In the previous section, we introduced triaging and why it is essential. This time, we'll focus on how to approach it, what to prioritise, what to look for, and what to do right after an alert.

When multiple alerts appear, analysts should have a consistent method to assess and prioritise them quickly. There are many factors you can consider when triaging, but these are the fundamental ones that should always be part of your process of identifying and evaluating alerts:

| **Key Factors** | **Description** | **Why It Matters?** |
| --- | --- | --- |
| Severity Level | Review the alert's severity rating, ranging from Informational to Critical. | Indicates the urgency of response and potential business risk. |
| Timestamp and Frequency | Identify when the alert was triggered and check for related activity before and after that time. | Helps identify ongoing attacks or patterns of repeated behaviour. |
| Attack Stage | Determine which stage of the attack lifecycle this alert indicates (reconnaissance, persistence, or data exfiltration). | It gives insight into how far the attacker may have progressed and their objective. |
| Affected Asset | Identify the system, user, or resource involved and assess its importance to operations. | Prioritises response based on the asset's importance and the potential impact of compromise. |

In short, these four represent the essential dimensions of triage:

* **Severity:** How bad?
    
* **Time:** When?
    
* **Context:** Where in the attack lifecycle?
    
* **Impact:** Who or what is affected?
    

They form a balanced foundation that's simple enough for analysts to apply quickly but comprehensive enough for informed decisions.

After reviewing these factors, decide on your next step: escalate to the incident response team, perform a deeper investigation, or close the alert if it's confirmed to be a false positive. A structured triage process like this helps ensure that time and resources are focused on what truly matters.

## **Diving Deeper into an Alert**

After identifying which alerts deserve further attention, it's time to dig into the details. Follow these steps to investigate and correlate effectively:

* **Investigate the alert in detail.**  
    Open the alert and review the entities, event data, and detection logic. Confirm whether the activity represents real malicious behaviour.
    
* **Check the related logs.**  
    Examine the relevant log sources. Look for patterns or unusual actions that align with the alert.
    
* **Correlate multiple alerts.**  
    Identify other alerts involving the same user, IP address, or device. Correlation often reveals a broader attack sequence or coordinated activity.
    
* **Build context and a timeline.**  
    Combine timestamps, user actions, and affected assets to reconstruct the sequence of events. This helps determine if the attack is ongoing or has already been contained.
    
* **Decide on the following action.**  
    If there are indicators of compromise, escalate to the incident response team. Investigate further if more evidence or correlation is needed. Close or suppress if the alert is a confirmed false positive, and update detection rules accordingly.
    
* \*\*Document findings and lessons learned.  
    \*\*Keep a clear record of the analysis, decisions, and remediation steps. Proper documentation strengthens SOC processes and supports continuous improvement.
    

With the triage complete and the investigation in motion, McSkidy begins piecing together the puzzle. Every alert, log entry, and timestamp brings her closer to uncovering what the Evil Bunnies are up to inside the Azure tenant. It's time to connect the dots and reveal the bigger picture behind the noise.

## **Environment Review**

Before proceeding with alert triaging, let’s first review the lab environment.

To get started, head over to the Azure Portal and search for Microsoft Sentinel.

![Accessing Microsoft Sentinel from the Azure Portal.](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1761801801838.png align="left")

Then, click the Sentinel instance, go to the **Logs** tab and select the custom log table named **Syslog\_CL**.

![Reviewing Sentinel Logs Syslog_CL table.](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1765381600047.png align="left")

After running the query, the logs for this lab environment should be rendered.

![](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1765381600008.png align="left")

Now that we have reviewed the environment, let's proceed with the discussion of alert triaging in the next task.

## Investigation Proper

## **McSkidy Goes Triaging**

Now that we have learned about triaging, let's move to the fun part, working inside the actual SOC environment of the Best Festival Company hosted in Azure. This is where McSkidy will put her triage skills to the test using Microsoft Sentinel, a cloud-native SIEM and SOAR platform. Sentinel collects data from various Azure services, applications, and connected sources to detect, investigate, and respond to threats in real time.

Through Sentinel, McSkidy can view and manage alerts, analyse incidents, and correlate activities across multiple logs. It provides visibility into what's happening within the Azure tenant and efficiently allows analysts to pivot from one alert to another. In this next part, we'll explore how McSkidy reviews alerts, drills into the evidence, and uses Sentinel's investigation tools to uncover the truth behind the Evil Bunnies' attack.

## **Microsoft Sentinel in Action**

To start the activity, navigate to [Microsoft Sentinel](https://portal.azure.com/#browse/microsoft.securityinsightsarg%2Fsentinel) and select your dedicated Sentinel instance. Then, under the **Threat management** dropdown, select the **Incidents** tab to view the incidents triggered during the current timeframe. You may also press the `<<` button to expand the view as shown in the image below.

![Microsoft Sentinel Incidents page.](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1761812013900.png align="left")

**Note:** In case the alerts do not appear, refresh your browser page (see image below)

![](https://tryhackme-images.s3.amazonaws.com/user-uploads/5e9c5d0148cf664325c8a075/room-content/5e9c5d0148cf664325c8a075-1765496772588.png align="left")

From the task images, there are eight open incidents, four of high severity and four of medium severity. Note that these numbers might differ in your lab environment.

Since we focus on addressing the most critical threats first, we’ll begin with the high-severity alerts. These represent potential compromise points or privilege-escalation activities that could lead to complete host control if left unchecked.

To begin the triage, we’ll examine one high-severity incident in detail: the **Linux PrivEsc—Kernel Module Insertion** alert. By clicking the alert, additional details appear on the right-hand side.

![Sentinel Incident: Kernel Module Insertion](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1761813693949.png align="left")

Upon checking the alert, as seen in the above image, the following details can be initially inferred:

1. There are three events related to the alert.
    
2. The alert was recently created (note that this varies based on your lab instance).
    
3. There are three entities involved in the alert.
    
4. The alert is classified as a Privilege Escalation tactic.
    

We can get further details from here by clicking the **View full details** button.

![View full details button](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1762540605044.png align="left")

In the new view, we can see that in addition to the details shown in the summary, we can also view the possible **Incident Timeline** and **Similar Incidents**.

![Similar incidents and incident timeline.](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1762540510566.png align="left")

### **Understanding Related Alerts**

From the view above, you may notice that several alerts point to the same affected entities. This helps us understand the relationship and the possible sequence of events that impact the same host or user.

When multiple alerts are linked to a single entity, such as the same **machine**, **user**, or **IP address**, it typically indicates that these detections are not isolated incidents, but somewhat different stages of the same intrusion.

By analysing which alerts share the same entities, we can start to trace the attack path, from the initial access to privilege escalation and persistence.

For example, if the same VM triggered the following alerts:

| **Alert** | **What does it suggest?** |
| --- | --- |
| Root SSH Login from External IP | The attacker gained remote access (via SSH) to the system (Initial Access) |
| SUID Discovery | The attacker looked for ways to escalate privileges. |
| Kernel Module Insertion | The attacker installed a malicious kernel module for persistence. |

At this stage, McSkidy has reviewed the high-severity alerts, identified the affected entities, and noticed that several detections are linked together. This initial triage allows her to prioritise which incidents need immediate attention and recognise when multiple alerts are actually part of a larger compromise.

With this foundational understanding, McSkidy is ready to move beyond surface-level triage and dive deeper into the underlying logs, which will be discussed in the next task.

### Answer the questions below

1. How many entities are affected by the **Linux PrivEsc - Polkit Exploit Attempt** alert?
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765573268477/27edfb06-43fd-4856-8c45-209ad28bbd7a.png align="center")
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765573302489/87fb9344-901f-41a0-b6af-11a556dd09b8.png align="center")
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765573325439/9a535b5c-4b37-4f2b-b075-997c4252c69f.png align="center")
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765573338677/61406b8b-6e8e-455b-95e9-4a1331a875ba.png align="center")
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765573406487/23f59e73-0f2f-40e1-83f8-eca2c8dffd3f.jpeg align="center")
    
2. What is the severity of the **Linux PrivEsc - Sudo Shadow Access** alert?
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765573838663/b5886b00-b141-41e0-a690-8d5bce972c47.jpeg align="center")
    
3. How many accounts were added to the sudoers group in the **Linux PrivEsc - User Added to Sudo Group** alert?
    
    You have to visit the page like the one below, then count the number of names with the type `account`
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765573590054/4eaf99e6-91f7-498d-95de-fc22d5bfe665.jpeg align="center")
    

## Diving Deeper Into Logs

## **In-Depth Log Analysis with Sentinel**

With the initial triage complete, McSkidy now examines the raw evidence behind these alerts. The next task involves diving into the underlying log data within Microsoft Sentinel to validate the alerts and uncover the exact attacker actions that triggered them. By analysing authentication attempts, command executions, and system changes, McSkidy can begin piecing together the full story of how the attack unfolded.

If we go back to the alert's full details view, we can try clicking the **Events** from the **Evidence** section.

![Event Evidences from a single alert.](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1761814527567.png align="left")

From this view, we can definitely see the actual name of the kernel module installed in each machine and the time it was installed.

Diving deeper into this, we can try checking the raw events from a single host through a custom query. To do this, let's change the view into an editable KQL query and find all the events triggered from **app-02**.

1. Press the **Simple mode** dropdown from the upper-right corner and select KQL mode.
    
2. Modify the query with the following KQL query below.
    
    `set query_now = datetime(2025-10-30T05:09:25.9886229Z);`  
    `Syslog_CL`  
    `| where host_s == 'app-02'`  
    `| project _timestamp_t, host_s, Message`
    
3. Press the **Run** button and wait for the results.
    

![KQL query mode.](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1761814527687.png align="left")

After executing the query, it can be seen that multiple potentially suspicious events occurred around the installation of the kernel module.

1. Execution of the `cp` (copy) command to create a shadow file backup.
    
2. Addition of the user account Alice to the sudoers group.
    
3. Modification of the backupuser account by root.
    
4. Insertion of the malicious\_mod.ko module.
    
5. Successful SSH authentication by the root user.
    

![System logs from the app-02 machine.](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1761815790577.png align="left")

Based on the surrounding events, including the execution of the `cp` command to create a shadow file backup, the addition of the user account Alice to the sudoers group, the modification of the backupuser account by root, and the successful SSH authentication by the root user, this activity appears highly unusual. The sequence suggests potential privilege escalation and persistence behaviour, indicating that the event may not be part of normal system operations and warrants further investigation.

Now that we have discussed the methodology for determining and reviewing alerts, let’s help McSkidy complete the assessment by examining the remaining alerts and answering the questions below.

![Investigating alerts with McSkidy.](https://tryhackme-images.s3.amazonaws.com/user-uploads/5dbea226085ab6182a2ee0f7/room-content/5dbea226085ab6182a2ee0f7-1763630714346.png align="left")

### Answer the questions below

1. What is the name of the kernel module installed in websrv-01?
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765573885771/c882123b-11a7-4fe1-82ac-15f53fb75faf.png align="center")
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765573996049/ee84c935-8502-407b-ae9e-2e48a782da19.jpeg align="center")
    
    To answer the next set of questions, you need to add a new query next to ***New Query 1\*,*** *then switch from* ***Simple mode*** *to* ***KQL mode***
    
2. What is the unusual command executed within websrv-01 by the ops user?
    
    ```bash
    Syslog_CL
    | where host_s == "websrv-01"
    | where Message contains "ops" or Message contains "sudo" or Message contains "COMMAND"
    | project _timestamp_t, host_s, Message
    | order by _timestamp_t asc
    ```
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765574564082/534e4584-7f0d-4fba-a0b3-63f3ab240f52.jpeg align="center")
    
3. What is the source IP address of the first successful SSH login to storage-01?
    
    ```bash
    Syslog_CL
    | where host_s == "websrv-01"
    | where Message contains "ops" or Message contains "sudo" or Message contains "COMMAND"
    | project _timestamp_t, host_s, Message
    | order by _timestamp_t asc
    ```
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765574485366/c75839f9-9271-4281-9ddd-ba53524add27.jpeg align="center")
    
4. What is the external source IP that successfully logged in as root to app-01?
    
    ```bash
    Syslog_CL
    | where host_s == "app-01"
    | where Message contains "Accepted password for root"
    | project _timestamp_t, host_s, Message
    | order by _timestamp_t asc
    ```
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765574678709/7857a639-44ca-444c-9eea-681801a563ba.jpeg align="center")
    
5. Aside from the backup user, what is the name of the user added to the sudoers group inside app-01?
    
    ```bash
    Syslog_CL
    | where host_s == "app-01"
    | where Message contains "sudo"
    or Message contains "sudoers"
    or Message contains "add"
    or Message contains "group"
    | project _timestamp_t, host_s, Message
    | order by _timestamp_t asc
    ```
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1765574769998/f879c958-3109-4ed9-93c2-df1e601cda84.jpeg align="center")
    

Completing this challenge was a great refresher on real-world security operations and the essential role a SIEM like Microsoft Sentinel plays in threat detection. The updated Azure access made the investigation seamless and allowed the entire analysis to flow naturally through triage, log review, and entity correlation. It also served as a reminder of how powerful KQL is — turning raw logs into clear evidence when used effectively.

This exercise reinforces the importance of structured alert triage, contextual analysis, and building timelines from event data. While the scenario was festive, the techniques and thought process mirror what analysts use daily in live environments. Overall, it was a meaningful and enjoyable hands-on experience, and I’m glad I was finally able to get through it and document the findings properly.