UD 3 - P3.5: Solución del supuesto práctico de contención

Solución orientativa de la práctica P3.5¶

Esta propuesta de resolución está adaptada al enfoque de la teoría 3.5.1. Contención de incidentes: medidas y estrategias.

La idea principal es esta: hay señales de daño activo, por lo que la respuesta debe priorizar una contención táctica inmediata, pero sin olvidar una captura mínima viable de evidencia volátil si puede hacerse en pocos minutos.

1. Análisis previo a la contención¶

1.1. Indicios de incidente activo¶

Los indicios más importantes son:

inicio de sesión VPN desde una ubicación no habitual;
negación del acceso por parte de la usuaria legítima;
conexiones SMB desde la IP de la VPN hacia servidores internos;
ejecución anómala de powershell.exe y 7z.exe en FS-02;
tráfico HTTPS saliente desde FS-02 a un dominio sospechoso;
aumento de uso de CPU y disco en el servidor.

Todo esto apunta a un posible uso fraudulento de credenciales, intento de movimiento lateral y posible preparación de exfiltración o empaquetado de información.

uso fraudulento de credenciales: la cuenta m.soto se está usando sin que la titular legítima lo confirme, y desde una ubicación no habitual.
movimiento lateral: las conexiones SMB hacia servidores internos indican que el atacante está intentando acceder a otros recursos dentro de la red.
preparación de exfiltración: la ejecución de 7z.exe en una carpeta temporal, seguida de tráfico HTTPS hacia un dominio no categorizado, sugiere que el atacante podría estar empaquetando datos para enviarlos fuera.

1.2. Activos críticos¶

Los activos más críticos son:

la identidad asociada a m.soto, porque puede permitir reentrada;
el servidor FS-02, porque contiene documentación operativa sensible;
el segmento de servidores 10.30.20.0/24, porque podría sufrir movimiento lateral;
el repositorio de copias de seguridad, porque sigue accesible;
el controlador de dominio, aunque aún no muestre síntomas directos.

1.3. Riesgo prioritario¶

El riesgo más urgente en los primeros minutos es la combinación de:

movimiento lateral, por las conexiones SMB a servidores internos;
reentrada por identidad, porque la cuenta sigue siendo válida;
y posible exfiltración, por el tráfico HTTPS saliente y el uso de 7z.

Todavía no hay evidencia clara de cifrado en curso, así que el escenario encaja mejor con una fase de expansión interna o preparación de robo de datos.

2. Decisión inicial en los primeros 10 minutos¶

Orden razonable de actuación:

Validar que la usuaria legítima no está conectada y confirmar compromiso de identidad.
Cerrar la sesión VPN activa y deshabilitar temporalmente la cuenta m.soto.
Bloquear de inmediato el tráfico desde el pool VPN hacia el segmento de servidores críticos.
Si el equipo lo permite sin retraso relevante, capturar evidencia mínima de FS-02.
Aislar FS-02 de la red o ponerlo en cuarentena desde EDR.
Proteger las copias de seguridad para evitar que el incidente alcance el repositorio.

La primera capa a contener es identidad, seguida de red y después endpoint/servidor. La razón es que, si solo aislamos FS-02, la identidad comprometida puede reutilizarse desde otro punto.

En cuanto a la captura de evidencia, se haría justo después de cortar el acceso activo del atacante, para no retrasar la contención pero aprovechar la ventana de oportunidad para preservar datos volátiles.

3. Medidas de contención táctica¶

3.1. Identidad¶

Deshabilitar temporalmente la cuenta m.soto. Frenaría nuevos accesos con esas credenciales.
Revocar la sesión VPN activa y cualquier token o sesión asociada. Evitaría que el atacante siguiera actuando con una sesión ya abierta.

3.2. Red¶

Bloquear en firewall interno todo el tráfico del rango VPN hacia 10.30.20.0/24. Cortaría el movimiento lateral hacia servidores.
Bloquear el dominio sync-data-help[.]com y la salida HTTPS sospechosa desde FS-02. Reduciría la posible exfiltración o comunicación con infraestructura del atacante.

3.3. Endpoint y servidores¶

Aislar FS-02 con la función de cuarentena del EDR o mediante VLAN de aislamiento. Detendría nuevas conexiones desde y hacia el servidor comprometido.
Bloquear o detener procesos sospechosos relacionados con powershell.exe y 7z.exe, si la herramienta lo permite sin destruir evidencia clave. Reduciría el daño activo y evitaría que siguiera el empaquetado de datos.

3.4. Copias de seguridad¶

Desconectar o aislar lógicamente el acceso al repositorio de backup desde la red corporativa. Evitaría que el atacante alcanzara o borrara las copias necesarias para recuperación.

4. Preservación de evidencia¶

4.1. Evidencia mínima a preservar¶

La evidencia mínima razonable sería:

hora exacta de las acciones de contención;
conexiones de red activas de FS-02;
procesos en ejecución y árbol de procesos;
logs recientes de VPN, firewall, proxy y EDR;
sí es viable, volcado de memoria del servidor afectado.

4.2. Evidencia volátil¶

La evidencia más volátil en este supuesto es:

memoria RAM;
sesiones activas;
conexiones de red abiertas;
procesos temporales lanzados desde rutas transitorias;
tokens o artefactos de autenticación en sesión.

4.3. Acción que conviene evitar demasiado pronto¶

No conviene apagar bruscamente FS-02 al inicio, porque eso puede destruir datos volátiles útiles para entender qué estaba haciendo el atacante.

La teoría del tema insiste en esta idea: si podéis hacer una captura mínima viable sin retrasar la contención, merece la pena antes del aislamiento total o del apagado.

5. Contención estratégica¶

Medidas razonables para las siguientes horas o días:

rotación de credenciales y revisión de privilegios de cuentas con acceso remoto;
refuerzo de MFA y revisión de políticas de acceso VPN por geolocalización o riesgo;
segmentación más estricta entre accesos remotos y servidores internos;
hardening y monitorización reforzada en servidores críticos y repositorio de copias;
búsqueda ampliada de IoC en otros equipos del entorno;
revisión de reglas de salida a Internet y monitorización de egress.

Estas medidas ya no buscan solo parar el golpe inicial, sino sostener el control del incidente y evitar reentrada.

6. Registro operativo mínimo¶

Hora	Acción	Responsable	Justificación
08:24	Confirmación telefónica con la usuaria `m.soto`	SOC	Verificar compromiso de identidad
08:25	Cierre de sesión VPN de `m.soto`	Administrador de red	Cortar acceso activo del atacante
08:26	Deshabilitación temporal de la cuenta en directorio	Administrador de sistemas	Evitar reentrada con credenciales comprometidas
08:27	Bloqueo del tráfico VPN hacia servidores internos	Equipo de red	Frenar movimiento lateral
08:28	Bloqueo del dominio sospechoso en proxy/firewall	Equipo de red	Cortar posible exfiltración o C2
08:29	Captura de procesos, conexiones y logs de `FS-02`	Analista de incidentes	Preservar evidencia mínima viable
08:31	Aislamiento de `FS-02` mediante EDR	Equipo de seguridad	Detener actividad del servidor comprometido
08:33	Aislamiento del acceso al repositorio de backup	Sistemas	Proteger capacidad de recuperación

7. Idea final que se esperaba en la práctica¶

La respuesta más sólida no era "apagar el servidor y ya está", sino proponer una contención ordenada y justificada:

primero cortar el acceso del atacante;
después limitar su movimiento y su salida;
preservar evidencia mínima útil;
y preparar medidas estratégicas para no reabrir el incidente unas horas más tarde.