Saltar al contenido

Caso práctico independiente · Analista de SOC

La cuenta de servicio que creó un administrador a las 04:03

Cinco extractos de registros ficticios, un ticket de cambio y una copia de seguridad: decide si cierras, vigilas o escalas, y justifica cada paso con evidencia.

  • Logística Brumario Ejemplo, S. L. (ficticia)
  • 5 entregables
  • 5 criterios, niveles 0 a 3
  • Datos 100 % ficticios

Tiempo estimado. Entre 90 y 150 minutos. Es una estimación nuestra, todavía sin medir con personas.

Qué podrás demostrar

  • Reconstruir una línea temporal en UTC a partir de varias fuentes y separar lo relevante del ruido.
  • Decidir con evidencia (cerrar, vigilar o escalar) y reconocer lo que no se puede verificar.
  • Relacionar lo observado con técnicas de ATT&CK citando la línea de datos que las respalda.
  • Proponer una contención ordenada que preserve la evidencia, y decir qué no harías.
  • Escribir una detección con un caso positivo, uno negativo y un hueco anotado.

El escenario

Eres analista de SOC de primer nivel en Logística Brumario Ejemplo, S. L., una empresa ficticia de transporte y almacenaje. Entras a trabajar el martes 16 de junio de 2026 y el turno de noche te deja una alerta sin resolver: durante la madrugada se ha creado una cuenta con privilegios en el controlador de dominio DC01, y coincide con una ventana de mantenimiento aprobada para esa misma máquina.

Tienes cinco fuentes exportadas entre las 15:00 UTC del lunes 15 y las 02:30 UTC del martes 16: la pasarela de correo, el EDR del equipo de contabilidad, el cortafuegos, el registro de Seguridad de DC01 y los tickets de cambio y de copia. También tienes el inventario de activos con su criticidad.

Tu trabajo es decidir si se cierra, se vigila o se escala; reconstruir qué pasó sin inventarte lo que los datos no dicen; proponer una contención que no destruya evidencia; y dejar una detección que atrape este comportamiento la próxima vez. Todo lo que no esté en los ficheros, no lo sabes.

Reglas del caso

  • Las columnas de hora de los ficheros están en UTC. Los tickets están en hora de Madrid (en junio, UTC+2).
  • Todo es ficticio: empresa, equipos, cuentas y direcciones (rangos de documentación 192.0.2.0/24, 198.51.100.0/24 y 203.0.113.0/24, dominios .example).
  • No ejecutes nada de lo que aparece en los ficheros. Son texto para leer.

Qué cursos conviene tener hechos

Se apoya en logs de Windows (3), triage (5), detección y correo (6), respuesta a incidentes (9) y ATT&CK y reglas Sigma (12). Puedes intentarlo sin haberlos hecho, pero espera niveles bajos en los criterios que dependan de ellos.

Necesarios

Recomendados

Los cursos se abren desde su ficha, donde puedes crear una cuenta gratuita si aún no la tienes.

Materiales (ficheros ficticios)

Todo el paquete en un .zip, o los ficheros uno a uno. Descomprímelo en una carpeta vacía y lee primero LEEME.md. No contienen datos reales ni código que ejecutar.

Descargar el paquete (.zip)

Qué tienes que entregar

Escribe tus entregables fuera de esta página (en un documento tuyo). Aquí solo marcas cuáles has terminado; la plantilla ya trae la estructura.

  1. Mínimo 10 entradas, cada una con su fuente, distinguiendo lo que forma parte del incidente de lo que no.

    Formato: Tabla en Markdown o CSV

    Qué debe contener
    • Hora UTC
    • Fuente (fichero y línea)
    • Qué ocurre
    • ¿Forma parte del incidente? Sí / No / No lo sé, y por qué

  2. Decisión en dos o tres frases, activos y cuentas implicados, qué descartas y por qué, y qué no has podido verificar.

    Formato: Texto breve, máx. una página

    Qué debe contener
    • Decisión: cerrar, vigilar o escalar
    • Activos y cuentas implicados
    • Qué descartas y por qué
    • Qué no has podido verificar
    • Prioridad y motivo

  3. Una técnica por fase con su ID (y subtécnica si existe), la línea de datos que la respalda y la versión de ATT&CK que has consultado.

    Formato: Tabla

    Qué debe contener
    • Fase observada
    • ID y nombre de la técnica
    • Evidencia (fichero y línea)
    • Versión de ATT&CK y fecha de consulta

  4. Pasos en orden (máximo 8) y tres acciones que NO harías, con su motivo.

    Formato: Lista numerada

    Qué debe contener
    • Pasos en orden (máx. 8) con responsable
    • Qué evidencia preservas y cómo
    • Tres acciones que no harías y por qué

  5. Para el comportamiento «una cuenta de servicio crea una cuenta con privilegios»: regla en lenguaje natural o en Sigma, con un caso positivo, uno negativo y un hueco anotado.

    Formato: Texto o YAML de Sigma

    Qué debe contener
    • Regla (texto o Sigma)
    • Caso positivo sacado de los datos
    • Caso negativo (qué no debe saltar)
    • Un hueco: qué escaparía a la regla

0 de 5 entregables marcados como terminados

Rúbrica y autoevaluación

Por cada criterio, marca el nivel más alto que puedas demostrar señalando en tu entrega la frase, la fila o el fichero que lo cumple. Si dudas entre dos niveles, marca el más bajo. Es una autoevaluación: nadie corrige tu trabajo.

1.Línea temporal

Orden, zona horaria, fuentes citadas y capacidad de separar ruido de incidente.

2.Decisión de triage

Que la decisión esté sostenida por evidencias enlazadas y por lo que no se sabe.

3.Mapa ATT&CK con evidencia

IDs reales y comprobados, respaldados por una línea de datos, con su versión.

4.Contención y evidencia

Orden de las acciones, preservación de evidencia y criterio sobre lo que no se hace.

5.Detección propuesta

Una regla con casos de prueba y un hueco reconocido.

Tu puntuación orientativa

Has valorado 0 de 5 criterios. Marca el resto para ver la valoración global.

Criterio de este caso: «sólido» desde 12 de 15 puntos y ningún criterio por debajo de 2; «en camino» desde 8 y sin ningún 0; los criterios eliminatorios deben estar al menos en 2. Es una orientación nuestra, no una nota: no hay corrección ni certificado asociado.

Tus marcas se guardan solo en este navegador (almacenamiento local). No se envían a ningún servidor.

Puntos de control para después de tu intento

No son la solución: son hechos objetivos que puedes comprobar en tu entrega. Ábrelos cuando hayas terminado; si los lees antes, pierdes parte del ejercicio.

Ya he hecho mi intento: mostrar los puntos de control
  • Las horas de Madrid en junio son UTC+2. La ventana del ticket de cambio (03:30 a 04:30, hora de Madrid) equivale a 01:30-02:30 UTC. Comprueba qué eventos de DC01 caen dentro de ella y si el alcance escrito del ticket cubre lo que pasó.
  • Hay una transferencia grande hacia un destino externo desde otro equipo. Antes de contarla como fuga de datos, cruza el equipo origen con activos.csv y la hora con el ticket de copia.
  • Mide el intervalo entre las conexiones del puesto de contabilidad hacia una misma dirección externa (por ejemplo con awk, como en el curso 2). Un intervalo casi constante es una pista; un solo valor suelto, no.
  • La cadena que sigue a -enc es Base64 de texto en UTF-16LE. Descodifícala en un entorno de pruebas (en tu equipo, nunca ejecutándola) y escribe qué dice.
  • Los datos no incluyen VPN, MFA ni el registro del puesto de contabilidad entre las dos fases. Tu entrega debería decir que no puede saber cómo se obtuvo la contraseña de la cuenta de servicio.
  • Los ID de ATT&CK y su versión cambian con el tiempo: comprueba cada uno en attack.mitre.org el día que hagas el caso. No damos una lista, y la tuya debe llevar tu fecha de consulta.

Cuándo necesitas supervisión

Este caso es un ejercicio con datos ficticios. Lo que aprendas aquí no te habilita para actuar sin revisión en un entorno real. Estos son los límites:

  • Este caso es un ejercicio con datos ficticios. En un incidente real, la contención (aislar equipos, deshabilitar o eliminar cuentas, rotar credenciales) la aprueba quien tenga autoridad sobre el activo y se hace con un procedimiento de respuesta aprobado, no por iniciativa propia.
  • Descodificar o ejecutar cargas de una muestra real solo se hace en un entorno aislado y con quien lidere la respuesta. En este caso no hay ninguna muestra real.
  • Notificar a clientes, a una autoridad o a una aseguradora no es decisión de quien hace el triage: se escala.
  • Una detección nueva no se pasa a producción sin pruebas y sin que la revise alguien con experiencia: puede generar ruido o cegar otra regla.

Apoyo para después de tu intento

El Taller de SOC resuelve otro escenario (montar un laboratorio de detección con tres detecciones, triage y proyecto final). Ábrelo cuando hayas entregado tu intento: te sirve para comparar enfoques y para practicar lo que te haya salido flojo, no para copiar respuestas de este caso, que no tiene solución publicada.

Curso 14 · Taller de SOC: tu laboratorio de detección

Cuando termines: vuelve a la ruta, o repasa los cursos que te marquen los criterios más bajos.