SOC L2 Alert Triage

Overview — A room on the SOC Level 2 path centred on the core L2 responsibility: picking up an alert that L1 has already triaged and escalated, then performing the deeper log analysis, verdict-making, and advanced response actions that L1 cannot do alone. The idea running through the whole room is that L1 optimises for triage speed while L2 optimises for triage quality and depth. It closes with a hands-on challenge around a fake Claude Desktop installer that actually delivers an infostealer.

L1 versus L2

Before diving into the tasks it helps to pin down the role difference the room repeats throughout:

Resumen — Room de la ruta SOC Level 2 centrado en la responsabilidad central de un analista L2: recoger una alerta que L1 ya ha triado y escalado, y realizar el análisis de logs profundo, la emisión de veredicto y las acciones de respuesta avanzadas que L1 no puede ejecutar por sí solo. La idea clave que atraviesa todo el room es que L1 optimiza la velocidad del triaje mientras L2 optimiza la calidad y la profundidad. Cierra con un reto práctico sobre un falso instalador de Claude Desktop que en realidad entrega un infostealer.

L1 frente a L2

Antes de entrar en las tareas conviene fijar la diferencia de roles que el room repite una y otra vez:

Task 1 — Introduction

No graded question.

This task sets the stage: an escalated alert may represent exfiltration, ransomware, or wiper activity. The room's objective is to teach the L2 workflow, SOC best practices, and the senior-analyst mindset.

Prerequisites:

• Senior Security Analyst Intro room
• SOC Team Internals module

Task 2 — SOC L2 Workflow

Q: What is the most common trigger for L2 to start the triage?
A: Escalated alert

Explanation

Unlike L1, whose workflow always begins with a fresh alert firing in the SIEM, an L2 analyst's day-to-day work begins when L1 has already reviewed an alert and pushed it upward because it needs deeper investigation, coordination with other teams, or an advanced response action. Occasionally an L2 may also be triggered by a direct urgent request from management or an MSSP customer, but escalation from L1 remains the dominant trigger.

Task 3 — Log Analysis as L2

Q: Should you understand the rule purpose before triaging the alert? (Yea/Nay)
A: Yea

Q: What term is used for a chronological list of events (related to the attack)?
A: Timeline

Explanation

Before touching any logs, the analyst must know exactly what technique the triggered detection rule is designed to catch — otherwise the investigation starts blind and risks missing the actual attack pattern.

Once the rule's purpose is understood, the L2 workflow follows two stages:

1. See what happened — quick SIEM queries to build a high-level «story» (why the rule fired, what happened next, what caused the initial trigger).
2. Build a detailed timeline — a full chronological reconstruction of process, file, and network activity across every involved host, used to surface hidden indicators such as dropped DLLs, C2 domains, or malicious IPs.

When the story alone cannot answer every open question, L2 analysis becomes a threat-hunting loop:

Form a hypothesis → build a timeline to close the gaps → evaluate whether the story is complete → repeat if it isn't.

Task 4 — Threat Response

Q: What is the term for a temporary response that stops the threat from spreading?
A: Containment

Q: You see clearly malicious activity on a corporate device. You also know about an ongoing pentest, but the red teamers do not respond. Would you isolate the device before receiving confirmation? (Yea/Nay)
A: Yea

Explanation

Response in the L2 workflow follows a strict logic gate:

Verify the activity -> Determine true/false positive -> Respond accordingly -> Resolve the case -> Capture lessons learned

Verifying the activity means confirming legitimacy directly with the affected party before jumping to conclusions: asking the user whether a login was theirs, confirming a new admin account with IT, or checking a suspicious API call with DevOps. If there is no response and the risk is high, the account or host gets disabled/isolated by default rather than left exposed.

Response to true positives scales with blast radius. A single infected laptop might only need an EDR quarantine, while a large-scale intrusion could require RDP/SSH access to hosts, disabling identities in Entra ID, subnet isolation, and emergency patching.

Response to major incidents follows the classic three-phase IR model:

This is why isolating a device with clearly malicious activity is the correct call even when a pentest is technically in progress — without confirmation from the red team you cannot assume the activity is sanctioned, and the cost of a false containment is far lower than the cost of an active real intrusion left unchecked.

Response to false positives still requires action, just at lower urgency — three common outcomes:

• False Positive Tuning — fixing a flawed detection query.
• Security Hardening — fixing an exposed risk the FP incidentally revealed (e.g. open RDP).
• Team Improvement — correcting an L1 analysis mistake through mentorship.

Resolving the case always includes three non-negotiable steps:

1. Log evidence of every action taken in a centralised ticketing system.
2. Inform the wider SOC team (especially about anything novel).
3. Keep external parties such as MSSP customers updated with a summary.

Task 5 — Learning Lessons & Practical Challenge

This task combines a reflection principle with a hands-on simulation around a fake Claude Desktop installer that actually delivers an infostealer.

Challenge Phase 1 — Analysis (drag-and-drop into buckets)

See what happened (first 5 minutes)

• Quickly review what the malware is doing now and how urgent the situation is.
• Check the past activity: who launched Claude and where it was downloaded from.

Build a timeline (detailed investigation)

• Trace and note the malware's full process, file, and network activity up to the present time.
• Reconstruct the complete attack timeline and collect indicators of compromise (IOCs).

Make your verdict (summarise what you've learned)

• Reach a True Positive verdict and proceed to the Response stage with the collected IOCs.
• Determine the root cause of Claude running malware: supply-chain compromise, prompt injection, or an imposter binary.

Challenge Phase 2 — Response Actions (ordered sequence)

The scenario reveals that the «Claude Desktop» installer was actually an infostealer downloaded from a fake claude.top website. The correctly ordered response sequence:

1. Isolate the infected LPT-1601 from the network (Containment).
2. Eradicate the infostealer and its files from the host (Eradication).
3. Rotate all stolen passwords, keys, and tokens (Eradication).
4. Lift host isolation and inform the user and your team (Recovery).
5. Monitor — ask your team to keep an eye on the user/host (Recovery / monitoring).

This directly mirrors the NIST Containment → Eradication → Recovery model taught in Task 4: isolate first to stop spread, clean the host and rotate compromised credentials, then only lift isolation once the threat is fully removed, followed by continued monitoring for reinfection.

Challenge Phase 3 — Lessons Learned (select the 4 best options)

The four correct reflection actions for this incident:

1. Search for attack indicators on the other workstations.
2. Communicate with your L1 on how to improve escalation comments.
3. Build an early-stage detection rule that covers malicious downloads.
4. Suggest enabling a web filter to block fake websites.

Incorrect distractors: replacing the EDR vendor outright and disciplining the affected user. Both go against the senior mindset this room teaches: a single miss doesn't justify a vendor swap, and blaming the end user contradicts the «learn, don't punish» culture senior analysts are expected to build within their SOC team.

Flag

The challenge flag is generated dynamically per session inside the embedded static site once all three phases are completed correctly, so it will be unique to your run and appear directly on the results screen after phase 3 is checked.

Task 6 — Conclusion

No graded question.

This task confirms room completion and points toward the next room, Report Writing for SOC L2, which builds on this incident by teaching how to document it in a professional report for stakeholders and MSSP customers.

Key takeaways

• L2 triage begins with escalation, not raw alerts — always understand the detection rule's purpose first.
• Investigation follows «see what happened» → «build a timeline», looping as a threat hunt when the story is incomplete.
• Response follows a strict logic gate: verify → classify → respond → resolve → reflect.
• Major incidents follow the Containment → Eradication → Recovery model, with containment applied immediately even before investigation completes.
• Case resolution always requires logging, internal communication, and external updates.
• Lessons learned should focus on systemic improvement (detection rules, escalation quality, hardening) — not vendor blame or user punishment.

Task 1 — Introduction

Sin pregunta puntuada.

Esta tarea sitúa el escenario: una alerta escalada puede representar exfiltración, ransomware o actividad de tipo wiper. El objetivo del room es enseñar el flujo de trabajo de un L2, las buenas prácticas del SOC y la mentalidad del analista senior.

Prerrequisitos:

• Room Senior Security Analyst Intro
• Módulo SOC Team Internals

Task 2 — SOC L2 Workflow

Q: ¿Cuál es el disparador más habitual para que L2 empiece el triaje?
A: Escalated alert

Explicación

A diferencia de L1, cuyo flujo siempre arranca con una alerta nueva disparándose en el SIEM, el día a día de un L2 empieza cuando L1 ya ha revisado una alerta y la ha empujado hacia arriba porque necesita una investigación más profunda, coordinación con otros equipos o una acción de respuesta avanzada. En ocasiones un L2 también puede activarse por una petición urgente directa de dirección o de un cliente MSSP, pero la escalada desde L1 sigue siendo el disparador dominante.

Task 3 — Log Analysis as L2

Q: ¿Debes entender el propósito de la regla antes de triar la alerta? (Yea/Nay)
A: Yea

Q: ¿Qué término se usa para una lista cronológica de eventos (relacionados con el ataque)?
A: Timeline

Explicación

Antes de tocar un solo log, el analista debe saber exactamente qué técnica está diseñada para detectar la regla que se ha disparado; de lo contrario la investigación empieza a ciegas y se arriesga a pasar por alto el patrón de ataque real.

Una vez entendido el propósito de la regla, el flujo L2 sigue dos etapas:

1. Ver qué ha pasado — consultas rápidas al SIEM para construir una «historia» de alto nivel (por qué se disparó la regla, qué ocurrió después, qué provocó el disparo inicial).
2. Construir una timeline detallada — una reconstrucción cronológica completa de la actividad de procesos, ficheros y red en cada host implicado, usada para sacar a la luz indicadores ocultos como DLLs soltadas, dominios de C2 o IPs maliciosas.

Cuando la historia por sí sola no puede responder a todas las preguntas abiertas, el análisis L2 se convierte en un bucle de threat hunting:

Formular una hipótesis → construir una timeline para cerrar los huecos → evaluar si la historia está completa → repetir si no lo está.

Task 4 — Threat Response

Q: ¿Cómo se llama la respuesta temporal que detiene la propagación de la amenaza?
A: Containment

Q: Ves actividad claramente maliciosa en un dispositivo corporativo. También sabes que hay un pentest en curso, pero el red team no responde. ¿Aislarías el dispositivo antes de recibir confirmación? (Yea/Nay)
A: Yea

Explicación

La respuesta en el flujo L2 sigue una puerta lógica estricta:

Verificar la actividad -> Determinar verdadero/falso positivo -> Responder en consecuencia -> Resolver el caso -> Capturar lecciones aprendidas

Verificar la actividad significa confirmar la legitimidad directamente con la parte afectada antes de sacar conclusiones: preguntar al usuario si un login fue suyo, confirmar una cuenta de administrador nueva con IT o comprobar una llamada API sospechosa con DevOps. Si no hay respuesta y el riesgo es alto, la cuenta o el host se deshabilita/aisla por defecto en lugar de dejarlo expuesto.

Respuesta a verdaderos positivos escala con el radio de impacto. Un único portátil infectado quizá solo necesite una cuarentena por EDR, mientras que una intrusión a gran escala podría requerir acceso RDP/SSH a los hosts, deshabilitar identidades en Entra ID, aislar subredes y parcheo de emergencia.

Respuesta a incidentes mayores sigue el clásico modelo de IR de tres fases:

Por eso aislar un dispositivo con actividad claramente maliciosa es la decisión correcta aunque técnicamente haya un pentest en curso: sin confirmación del red team no puedes asumir que la actividad esté autorizada, y el coste de una contención en falso es mucho menor que el de una intrusión real activa dejada sin control.

Respuesta a falsos positivos también exige acción, solo que con menor urgencia; tres resultados habituales:

• False Positive Tuning — corregir una consulta de detección defectuosa.
• Security Hardening — corregir un riesgo expuesto que el FP reveló de forma incidental (p. ej. un RDP abierto).
• Team Improvement — corregir un error de análisis de L1 mediante mentoría.

Resolver el caso incluye siempre tres pasos innegociables:

1. Registrar evidencia de cada acción tomada en un sistema de tickets centralizado.
2. Informar al conjunto del equipo SOC (sobre todo de cualquier cosa novedosa).
3. Mantener informadas a las partes externas, como clientes MSSP, con un resumen.

Task 5 — Learning Lessons & Practical Challenge

Esta tarea combina un principio de reflexión con una simulación práctica en torno a un falso instalador de Claude Desktop que en realidad entrega un infostealer.

Fase 1 del reto — Análisis (arrastrar y soltar en cubos)

Ver qué ha pasado (primeros 5 minutos)

• Revisar rápidamente qué está haciendo el malware ahora y cuán urgente es la situación.
• Comprobar la actividad pasada: quién lanzó Claude y desde dónde se descargó.

Construir una timeline (investigación detallada)

• Rastrear y anotar toda la actividad de procesos, ficheros y red del malware hasta el momento actual.
• Reconstruir la timeline completa del ataque y recopilar los indicadores de compromiso (IOCs).

Emitir tu veredicto (resumir lo aprendido)

• Alcanzar un veredicto de True Positive y pasar a la fase de respuesta con los IOCs recopilados.
• Determinar la causa raíz de que Claude ejecutase malware: compromiso de la cadena de suministro, prompt injection o un binario impostor.

Fase 2 del reto — Acciones de respuesta (secuencia ordenada)

El escenario revela que el instalador de «Claude Desktop» era en realidad un infostealer descargado desde una web falsa, claude.top. La secuencia de respuesta correctamente ordenada:

1. Aislar el equipo infectado LPT-1601 de la red (Containment).
2. Erradicar el infostealer y sus ficheros del host (Eradication).
3. Rotar todas las contraseñas, claves y tokens robados (Eradication).
4. Levantar el aislamiento del host e informar al usuario y a tu equipo (Recovery).
5. Monitorizar — pedir a tu equipo que vigile al usuario/host (Recovery / monitoring).

Esto refleja directamente el modelo NIST Containment → Eradication → Recovery enseñado en la Task 4: aislar primero para frenar la propagación, limpiar el host y rotar las credenciales comprometidas, y solo entonces levantar el aislamiento una vez la amenaza esté totalmente eliminada, seguido de monitorización continua por si hay reinfección.

Fase 3 del reto — Lecciones aprendidas (elegir las 4 mejores opciones)

Las cuatro acciones de reflexión correctas para este incidente:

1. Buscar indicadores del ataque en el resto de estaciones de trabajo.
2. Hablar con tu L1 sobre cómo mejorar los comentarios de escalada.
3. Construir una regla de detección temprana que cubra descargas maliciosas.
4. Proponer habilitar un filtro web que bloquee webs falsas.

Distractores incorrectos: sustituir por completo al proveedor de EDR y sancionar al usuario afectado. Ambos van en contra de la mentalidad senior que enseña este room: un único fallo no justifica un cambio de proveedor, y culpar al usuario final contradice la cultura de «aprender, no castigar» que se espera que construya un analista senior dentro de su equipo SOC.

Flag

La flag del reto se genera dinámicamente por sesión dentro del sitio estático embebido una vez completadas correctamente las tres fases, así que será única para tu ejecución y aparecerá directamente en la pantalla de resultados tras validar la fase 3.

Task 6 — Conclusion

Sin pregunta puntuada.

Esta tarea confirma la finalización del room y apunta al siguiente, Report Writing for SOC L2, que parte de este incidente para enseñar a documentarlo en un informe profesional dirigido a stakeholders y clientes MSSP.

Puntos clave

• El triaje L2 empieza con una escalada, no con alertas en crudo; entiende siempre primero el propósito de la regla de detección.
• La investigación sigue «ver qué ha pasado» → «construir una timeline», en bucle como un threat hunt cuando la historia está incompleta.
• La respuesta sigue una puerta lógica estricta: verificar → clasificar → responder → resolver → reflexionar.
• Los incidentes mayores siguen el modelo Containment → Eradication → Recovery, con la contención aplicada de inmediato incluso antes de completar la investigación.
• La resolución del caso exige siempre registrar, comunicar internamente y actualizar a las partes externas.
• Las lecciones aprendidas deben centrarse en la mejora sistémica (reglas de detección, calidad de la escalada, hardening), no en culpar al proveedor ni castigar al usuario.