Estrategias de Contencion: Red y Host en Respuesta a Incidentes

La contencion como momento critico

La contencion es el punto de inflexion en un incidente de seguridad. Antes de la contencion, el atacante tiene libertad de movimiento. Despues, su acceso esta restringido o eliminado. La calidad de la contencion determina si el incidente se resuelve limpiamente o si el atacante mantiene acceso residual que permite una reinfeccion.

Pero la contencion tiene una tension inherente: cada accion que tomas para detener al atacante puede destruir evidencia forense. Desconectar un cable de red mata las conexiones activas. Apagar un sistema borra la memoria RAM. Deshabilitar una cuenta puede alertar al atacante de que ha sido detectado, provocando que acelere sus acciones destructivas.

Este articulo cubre las estrategias de contencion a nivel de red y de host, los criterios para elegir entre ellas, y las tecnicas para preservar evidencia durante el proceso.

Contencion a nivel de red

Aislamiento por VLAN

La tecnica mas limpia de aislamiento de red es mover el sistema comprometido a una VLAN de cuarentena. Esta VLAN esta configurada para permitir unicamente la comunicacion con la estacion de analisis forense y, opcionalmente, con los servidores de logs y la consola del EDR.

Antes:  [Host comprometido] --- VLAN Produccion --- [Red corporativa]
Despues: [Host comprometido] --- VLAN Cuarentena --- [Estacion forense]

Ventajas: el sistema sigue encendido y accesible para el analista. Los procesos en ejecucion, las conexiones de red (ahora fallidas) y la memoria RAM se preservan. El atacante pierde la comunicacion C2 y la capacidad de movimiento lateral.

Para implementar el aislamiento por VLAN, necesitas acceso al switch de acceso (o al controlador SDN) y una VLAN de cuarentena preconfigurada. Esta es una de las preparaciones que debe hacerse antes del incidente.

Bloqueo en firewall

Si no puedes mover el host a una VLAN de cuarentena, puedes bloquear su trafico en el firewall perimetral o en el firewall de host:

Bloquear las IPs y dominios de C2 conocidos. Esto corta la comunicacion del atacante con su infraestructura sin afectar el resto del trafico del host.

Bloquear todo el trafico saliente del host excepto el necesario para el analisis. Mas agresivo, pero garantiza que el atacante no puede comunicarse con ningun destino externo.

Bloquear el trafico entre el host comprometido y los segmentos de red criticos. Previene el movimiento lateral hacia servidores sensibles.

# Ejemplo: bloquear trafico de un host comprometido en iptables
# En el firewall perimetral
iptables -I FORWARD -s 192.168.1.50 -j DROP
iptables -I FORWARD -d 192.168.1.50 -j DROP

# Permitir solo la comunicacion con la estacion forense
iptables -I FORWARD -s 192.168.1.50 -d 10.0.0.100 -j ACCEPT
iptables -I FORWARD -s 10.0.0.100 -d 192.168.1.50 -j ACCEPT

Bloqueo DNS

Si el malware se comunica con el C2 a traves de dominios (no IPs hardcodeadas), puedes bloquear la resolucion DNS de esos dominios. Esto es efectivo contra malware que usa DGA (Domain Generation Algorithm) si conoces los dominios generados.

Configura el servidor DNS interno para resolver los dominios de C2 a una IP de sinkhole (una IP controlada que registra las conexiones intentadas). Esto no solo bloquea la comunicacion, sino que proporciona evidencia de que sistemas intentan contactar al C2.

Aislamiento por EDR

Las soluciones EDR modernas (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, entre otras) permiten aislar un endpoint remotamente. El agente EDR bloquea todo el trafico de red del host excepto la comunicacion con la consola del EDR, manteniendo la capacidad de investigacion remota.

Esta es la opcion mas rapida y menos invasiva cuando la organizacion tiene EDR desplegado en el endpoint comprometido. No requiere acceso fisico ni cambios en la configuracion de red.

Contencion de red en cloud

En entornos cloud, la contencion de red se implementa a traves de los controles nativos del proveedor:

AWS: cambiar el Security Group de la instancia comprometida a uno que bloquee todo el trafico excepto el del analista. Alternativamente, aplicar una Network ACL restrictiva a la subred.

Azure: modificar el Network Security Group (NSG) de la interfaz de red de la VM comprometida.

GCP: aplicar reglas de firewall con prioridad alta que bloqueen el trafico de la instancia.

# AWS: crear y asignar un security group de cuarentena
aws ec2 create-security-group \
  --group-name "Cuarentena-IR" \
  --description "Aislamiento forense - solo analista" \
  --vpc-id vpc-0123456789

# Permitir solo SSH desde la IP del analista
aws ec2 authorize-security-group-ingress \
  --group-id sg-cuarentena \
  --protocol tcp --port 22 --cidr 10.0.0.100/32

# Asignar el security group a la instancia
aws ec2 modify-instance-attribute \
  --instance-id i-comprometida \
  --groups sg-cuarentena

Contencion a nivel de host

Contencion de procesos

Si el malware es un proceso identificado, puedes suspenderlo en lugar de matarlo. Suspender un proceso preserva su estado en memoria para analisis posterior.

# Linux: suspender un proceso (SIGSTOP)
kill -STOP PID_DEL_MALWARE

# Windows PowerShell: suspender un proceso
# (requiere herramientas como PsSuspend de Sysinternals)
pssuspend.exe PID_DEL_MALWARE

Matar un proceso (kill -9 o taskkill /F) es mas agresivo: el proceso desaparece y su estado se pierde. Usa esta opcion solo si el proceso esta causando dano activo (cifrando ficheros, exfiltrando datos) y no puedes suspenderlo.

Contencion de cuentas

Deshabilitar o resetear las cuentas comprometidas es una accion de contencion critica, especialmente en incidentes que involucran credenciales robadas:

Deshabilitar la cuenta comprometida en Active Directory o en el proveedor de identidad.

Resetear la contrasena de la cuenta.

Revocar todos los tokens de sesion activos. En entornos con SSO (SAML, OAuth), la revocacion de la sesion no es inmediata y puede requerir acciones adicionales en cada aplicacion.

Si el atacante tiene credenciales de Domain Admin, el reseteo debe incluir la cuenta krbtgt (dos veces, con intervalo) para invalidar todos los tickets Kerberos existentes. Este es un procedimiento con impacto operativo significativo que debe planificarse cuidadosamente.

Bloqueo de mecanismos de persistencia

Una vez identificados los mecanismos de persistencia del atacante, desactivalos sin eliminarlos (preservar como evidencia):

Servicios maliciosos: cambiar el tipo de inicio a "Disabled" en lugar de eliminar el servicio.

Tareas programadas: deshabilitar la tarea en lugar de eliminarla.

Claves de registro Run: renombrar la clave (anadir un prefijo como "DISABLED_") en lugar de borrarla.

Cronjobs: comentar la linea en lugar de eliminarla.

Esta tecnica preserva la evidencia del mecanismo de persistencia mientras previene que se ejecute.

Criterios de decision

Cuando aislar vs. cuando apagar

Aislar (mantener encendido, cortar red) es preferible cuando:

Necesitas preservar la memoria RAM (claves de cifrado, procesos maliciosos, conexiones activas).

El atacante no tiene acceso fisico ni out-of-band al sistema.

El sistema no esta causando dano activo que no pueda detenerse de otra forma.

Apagar es necesario cuando:

El sistema esta cifrando activamente ficheros de red a los que tiene acceso.

No puedes aislar la red de forma efectiva y el riesgo de propagacion es alto.

El sistema es un punto de pivote activo para un ataque en curso que no puede contenerse a nivel de red.

Cuando contener silenciosamente vs. contener agresivamente

La contencion silenciosa (bloquear C2, monitorizar sin alertar al atacante) es preferible cuando:

Necesitas tiempo para identificar todos los sistemas comprometidos antes de actuar.

El atacante tiene multiples puntos de acceso y contener uno prematuramente puede provocar que active los demas.

La exfiltracion de datos ya ha ocurrido y no hay urgencia de cortar comunicaciones.

La contencion agresiva (aislar sistemas, deshabilitar cuentas, bloquear todo) es necesaria cuando:

Hay destruccion activa de datos o cifrado en curso.

Hay exfiltracion activa de datos sensibles.

Solo hay un punto de acceso conocido y cortarlo neutraliza al atacante.

Preservacion de evidencia durante la contencion

Cada accion de contencion debe documentarse con:

Timestamp (UTC) de la accion.

Que accion se tomo y por que.

Quien la ejecuto.

Que estado tenia el sistema antes de la accion.

Antes de aplicar cualquier accion de contencion, si el tiempo lo permite:

Captura la memoria RAM del sistema con herramientas como DumpIt, WinPMem o LiME.

Captura el estado de las conexiones de red (netstat/ss, arp, routing table).

Captura la lista de procesos en ejecucion (ps aux, tasklist /v).

Crea un snapshot del disco si es un entorno virtualizado o cloud.

Estas capturas preservan el estado volatil que se perdera cuando la contencion altere el entorno del sistema.

Contencion coordinada

En incidentes que afectan a multiples sistemas, la contencion debe coordinarse para evitar alertar al atacante prematuramente:

Identifica todos los sistemas comprometidos antes de actuar. Si aislas un sistema pero el atacante tiene acceso a otros cinco, puede acelerar sus acciones destructivas al detectar que ha sido descubierto.

Planifica la contencion simultanea. Prepara las acciones de contencion para todos los sistemas y ejecutalas todas al mismo tiempo. En entornos grandes, esto requiere coordinacion entre multiples administradores de sistemas y un Incident Manager que de la orden de ejecutar.

Comunica por canales seguros. No uses el correo corporativo ni los canales de mensajeria internos para coordinar la contencion si existe la posibilidad de que el atacante este monitorizando esas comunicaciones.

Ten en cuenta las dependencias de servicio. Aislar un servidor de base de datos afecta a todas las aplicaciones que dependen de el. La contencion debe planificarse con conocimiento de la arquitectura de servicios para minimizar el impacto colateral en el negocio.

Errores comunes en la contencion

Apagar sistemas precipitadamente perdiendo evidencia volatil. La memoria RAM contiene procesos maliciosos en ejecucion, claves de cifrado, credenciales en cache y conexiones de red activas que se pierden irrecuperablemente.

Contener parcialmente. Aislar un sistema pero dejar otros comprometidos sin contener. El atacante migra a los sistemas no contenidos y la accion es inutil.

No documentar las acciones de contencion. Meses despues, en una revision legal o regulatoria, nadie recuerda que se hizo exactamente, cuando ni por que.

Alertar al atacante sin estar preparado para la contencion completa. Si el atacante detecta que ha sido descubierto (por ejemplo, porque deshabilitaste una de sus cuentas pero no las demas), puede activar sus acciones destructivas (ransomware, borrado de datos, eliminacion de logs).

No verificar que la contencion es efectiva. Despues de implementar las medidas de contencion, verifica activamente que el atacante ya no tiene comunicacion C2 y no puede moverse lateralmente. Monitoriza el trafico de red y los logs del sistema para confirmar.

Conclusion

La contencion es la fase mas operativa y de mayor presion en la respuesta a incidentes. Las decisiones se toman con informacion incompleta, bajo presion temporal, y con consecuencias tanto si actuas como si no actuas.

La preparacion previa (VLANs de cuarentena preconfiguradas, EDR con capacidad de aislamiento, procedimientos documentados, equipo entrenado) es lo que permite ejecutar la contencion de forma rapida, coordinada y con preservacion de evidencia.

La regla de oro: cada accion de contencion debe equilibrar tres objetivos: detener el ataque, preservar la evidencia y minimizar el impacto en el negocio. Cuando estos tres objetivos entran en conflicto, la prioridad depende del contexto: un ransomware cifrando activamente prioriza detener el ataque; un APT silencioso prioriza preservar evidencia para identificar el alcance completo.