Erradicacion, Recuperacion y Hardening Post-Incidente

De la contencion a la erradicacion

TL;DR: La fase post-incidente se define por la eliminación total del atacante y la restauración de sistemas mediante un proceso estructurado de erradicación y endurecimiento. A diferencia de la contención básica, este ciclo requiere un análisis forense exhaustivo de los vectores de persistencia para evitar que el atacante recupere el acceso. Se recomienda no restaurar servicios operativos hasta haber corregido todas las debilidades críticas identificadas durante la investigación.

Una vez que el incidente esta contenido, el siguiente paso es eliminar completamente la presencia del atacante y restaurar los sistemas a un estado seguro. Esta transicion es critica: una erradicacion incompleta permite al atacante recuperar el acceso, y una recuperacion precipitada puede reintroducir la vulnerabilidad original.

La erradicacion, la recuperacion y el hardening forman un ciclo que no termina hasta que el equipo tiene confianza razonable de que el atacante ha sido expulsado, los sistemas son seguros y las debilidades que permitieron el incidente han sido corregidas.

Erradicacion: eliminar la causa raiz

Identificar todos los componentes del ataque

La erradicacion requiere haber completado la investigación forense lo suficiente como para conocer todos los componentes del ataque:

Vector de acceso inicial: la vulnerabilidad, la cuenta comprometida, el phishing exitoso.

Mecanismos de persistencia: servicios, tareas programadas, claves de registro, cronjobs, claves SSH, cuentas creadas por el atacante.

Herramientas del atacante: Cobalt Strike beacons, webshells, herramientas de movimiento lateral, scripts de reconocimiento.

Cuentas comprometidas: cuentas de usuario, cuentas de servicio, tokens de API.

Modificaciones a la configuración: reglas de firewall anadidas, politicas de grupo modificadas, configuraciones de proxy alteradas.

Si la investigación no ha identificado todos estos componentes, la erradicacion será incompleta. Es preferible extender la fase de investigación antes que ejecutar una erradicacion parcial.

Eliminación del malware y herramientas

Para cada sistema afectado, elimina todo el software malicioso identificado:

Ejecutables y scripts del atacante: eliminar los ficheros, pero primero calcular su hash y preservar una copia para análisis (en un contenedor seguro, no en un sistema de producción).

Webshells: en servidores web, revisar todos los ficheros en los directorios web accesibles buscando webshells. Comparar los ficheros con una versión limpia conocida del sitio web.

Herramientas de acceso remoto no autorizadas: AnyDesk, TeamViewer, ngrok y similares que no forman parte del software autorizado de la organización.

Eliminar mecanismos de persistencia

Revisa sistematicamente todos los mecanismos de persistencia conocidos:

En Windows: servicios (HKLM\SYSTEM\CurrentControlSet\Services), tareas programadas (schtasks /query), claves Run/RunOnce (HKLM y HKCU\Software\Microsoft\Windows\CurrentVersion\Run), WMI subscriptions (Get-WMIObject -Namespace root\Subscription -Class __EventFilter), startup folders, y DLLs de inicio cargadas por servicios legitimos (DLL side-loading).

En Linux: crontabs (de todos los usuarios y del sistema), servicios systemd, scripts en /etc/init.d/, modificaciones a .bashrc/.profile, claves en authorized_keys, y librerias en /etc/ld.so.preload.

En cloud: roles IAM creados, policies modificadas, Lambda/Functions desplegadas, reglas de firewall anadidas.

Parchear la vulnerabilidad de entrada

Si el acceso inicial fue a traves de una vulnerabilidad de software, aplica el parche correspondiente antes de restaurar el servicio. Si no hay parche disponible, implementa una mitigación temporal (desactivar el servicio vulnerable, restringir el acceso a el, aplicar una regla WAF).

Si el acceso fue por credenciales comprometidas, el reseteo de credenciales (cubierto más adelante) es la accion equivalente a "parchear".

Reseteo de credenciales

El reseteo de credenciales es una de las acciones más criticas y de mayor impacto operativo en la erradicacion. Si el atacante tiene credenciales validas, puede recuperar el acceso independientemente de cuantos mecanismos de persistencia hayas eliminado.

Alcance del reseteo

El alcance del reseteo depende del nivel de acceso que tuvo el atacante:

Si el atacante comprometio cuentas de usuario estandar: resetear esas cuentas especificas y cualquier otra cuenta que usara las mismas credenciales.

Si el atacante comprometio cuentas de Domain Admin: resetear TODAS las cuentas privilegiadas, la cuenta krbtgt (dos veces con intervalo de 12 horas), y las contrasenas de administrador local de todos los sistemas (usar LAPS si esta implementado).

Si el atacante tuvo acceso a un controlador de dominio: considerar la reconstruccion completa del dominio de Active Directory. Este es el peor escenario y el más costoso, pero es la única forma de garantizar la integridad del directorio.

Reseteo de krbtgt

La cuenta krbtgt es la clave maestra de Kerberos en Active Directory. Todo ticket Kerberos esta firmado con el hash de esta cuenta. Si el atacante extrajo el hash de krbtgt (con DCSync o acceso al NTDS.dit), puede crear Golden Tickets que le dan acceso persistente como cualquier usuario del dominio.

El reseteo de krbtgt invalida todos los tickets Kerberos existentes, lo que tiene impacto operativo (todos los usuarios deben reautenticarse). El reseteo debe hacerse dos veces porque Active Directory retiene el hash anterior para compatibilidad:

Primer reseteo: invalida los tickets firmados con el hash actual. Los tickets firmados con el hash N-1 siguen siendo validos.

Segundo reseteo (12 horas despues): invalida los tickets firmados con el hash N-1. Ahora ninguno de los hashes que tenia el atacante es valido.

Otras credenciales a resetear

Claves SSH: regenerar los pares de claves de todos los sistemas afectados y los usuarios comprometidos. Eliminar las claves publicas no autorizadas de authorized_keys.

Tokens de API: revocar y regenerar todos los tokens de API que estaban almacenados en los sistemas comprometidos. Esto incluye tokens de cloud providers, APIs de terceros y service accounts.

Certificados TLS: si las claves privadas de los certificados TLS estaban en sistemas comprometidos, revocar los certificados y emitir nuevos.

Contrasenas de bases de datos: cambiar las contrasenas de todas las cuentas de base de datos que estaban configuradas en los sistemas comprometidos.

Recuperacion de sistemas

Reconstruccion vs. limpieza

Hay dos enfoques para restaurar un sistema comprometido:

Reconstruccion (reimage): reinstalar el sistema operativo desde cero usando una imagen limpia conocida, reinstalar las aplicaciones y restaurar los datos desde backup. Es la opcion más segura porque elimina cualquier artefacto malicioso, incluyendo los que no fueron identificados durante la investigación.

Limpieza: eliminar el malware y las modificaciones del atacante manteniendo la instalación existente. Es más rápida pero conlleva el riesgo de que queden componentes maliciosos no detectados (rootkits, backdoors en ubicaciones no revisadas, modificaciones a binarios del sistema).

La recomendacion general para servidores criticos es siempre reconstruir. Para estaciones de trabajo, la limpieza puede ser aceptable si la investigación es completa y el nivel de sofisticacion del atacante es bajo.

Orden de restauracion

La restauracion de servicios debe seguir un orden basado en dependencias y criticidad:

Primero, infraestructura de identidad: Active Directory, DNS, DHCP. Sin estos servicios, nada más funciona.

Segundo, infraestructura de seguridad: firewalls, EDR, SIEM, servidores de log. La monitorización debe estar activa antes de restaurar servicios de producción.

Tercero, servicios criticos de negocio: bases de datos, servidores de aplicaciones, servidores de correo.

Cuarto, servicios de soporte: impresoras, ficheros compartidos, herramientas internas.

Quinto, estaciones de trabajo: restaurar por grupos, empezando por los departamentos más criticos.

Verificación post-restauracion

Cada sistema restaurado debe verificarse antes de declararlo limpio:

Ejecutar escaneos con las reglas YARA del malware identificado en el incidente.

Verificar la integridad de los ficheros del sistema comparando hashes con una fuente conocida.

Monitorizar el tráfico de red del sistema durante las primeras 24-48 horas buscando comunicaciones C2 o actividad anomala.

Verificar que los mecanismos de persistencia eliminados no han reaparecido.

Confirmar que los servicios de seguridad (EDR, antivirus, logging) están activos y reportando correctamente.

Hardening post-incidente

La recuperacion no esta completa hasta que las debilidades que permitieron el incidente han sido corregidas. El hardening post-incidente se basa directamente en los hallazgos de la investigación forense.

Hardening basado en el vector de entrada

Si el vector fue RDP expuesto: eliminar el acceso RDP directo a Internet, implementar VPN con MFA, restringir RDP a IPs especificas, habilitar Network Level Authentication.

Si el vector fue phishing: reforzar el filtrado de correo (bloqueo de macros en adjuntos, sandboxing de adjuntos), implementar DMARC con politica reject, formación de concienciacion para usuarios.

Si el vector fue una vulnerabilidad web: implementar WAF, establecer un programa de gestión de vulnerabilidades con SLAs de parcheado, realizar pruebas de penetracion periodicas.

Si el vector fue credenciales comprometidas: implementar MFA en todas las cuentas privilegiadas y en los accesos remotos, implementar LAPS para contrasenas de administrador local, activar la monitorización de credenciales filtradas.

Hardening de Active Directory

Active Directory es el objetivo principal de los atacantes en entornos corporativos. El hardening post-incidente debe incluir:

Implementar el modelo de administracion por tiers (Tier 0: controladores de dominio, Tier 1: servidores, Tier 2: estaciones de trabajo). Las cuentas de Tier 0 nunca deben usarse en sistemas de Tier 1 o 2.

Habilitar la protección de credenciales: Credential Guard, Remote Credential Guard, Protected Users group para cuentas privilegiadas.

Implementar Just-In-Time (JIT) access para cuentas privilegiadas. Las cuentas de Domain Admin deben estar deshabilitadas por defecto y habilitarse solo cuando se necesitan, con duracion limitada.

Habilitar el logging detallado de Active Directory: todos los Event IDs relevantes para detección de ataques (4624, 4625, 4648, 4672, 4768, 4769, 4776, 7045, 4698).

Hardening de red

Implementar segmentación de red que límite el movimiento lateral. Los servidores criticos deben estar en segmentos separados con acceso controlado.

Revisar y restringir las reglas de firewall. Eliminar reglas permisivas (any-any), implementar reglas basadas en el principio de mínimo privilegio.

Implementar detección de anomalias en el tráfico de red. Herramientas como Zeek o Suricata proporcionan visibilidad sobre el tráfico interno.

Mejora de la capacidad de detección

El incidente revela gaps en la capacidad de detección. Las mejoras tipicas incluyen:

Crear reglas de detección especificas para las TTPs observadas en el incidente. Si el atacante uso PowerShell para post-explotación, asegurar que Script Block Logging esta habilitado y que el SIEM tiene reglas para detectar comandos sospechosos.

Implementar o mejorar el EDR. Si no habia EDR durante el incidente, este es el argumento para su implementación. Si habia EDR pero no detecto el ataque, revisar la configuración y las reglas de detección.

Aumentar la retencion de logs. Si la investigación se vio limitada por la falta de logs historicos, aumentar la retencion a un mínimo de 90 dias (180 dias o 1 año para entornos regulados).

Implementar deception technology. Honeypots, honeyfiles y honeytokens que detectan actividad de reconocimiento y movimiento lateral.

Verificación de la erradicacion completa

Antes de cerrar la fase de erradicacion, verifica:

Todos los IOCs del incidente (hashes, IPs, dominios, cuentas) han sido buscados en todos los sistemas de la organización, no solo en los sistemas comprometidos conocidos.

Las reglas de detección para las TTPs del incidente están activas en el SIEM/EDR.

La monitorización reforzada no muestra signos de actividad residual del atacante despues de 2 a 4 semanas.

Los backups restaurados no contienen artefactos del compromiso (verificar que los backups usados son anteriores al inicio del incidente).

Conclusion

La erradicacion, la recuperacion y el hardening son las fases que transforman un incidente de una crisis en una mejora de seguridad. La tentacion es restaurar operaciones lo antes posible, pero una erradicacion precipitada o un hardening superficial dejan la puerta abierta a la reinfeccion.

El principio rector es: no restaurar sobre cimientos comprometidos. Reconstruir cuando hay duda, resetear credenciales de forma amplia, parchear la vulnerabilidad de entrada, y implementar las mejoras que el incidente revelo como necesarias. Cada incidente bien gestionado deja a la organización más segura que antes.