Erradicacion, Recuperacion y Hardening Post-Incidente

De la contencion a la erradicacion

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 investigacion 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 configuracion: reglas de firewall anadidas, politicas de grupo modificadas, configuraciones de proxy alteradas.

Si la investigacion no ha identificado todos estos componentes, la erradicacion sera incompleta. Es preferible extender la fase de investigacion antes que ejecutar una erradicacion parcial.

Eliminacion 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 analisis (en un contenedor seguro, no en un sistema de produccion).

Webshells: en servidores web, revisar todos los ficheros en los directorios web accesibles buscando webshells. Comparar los ficheros con una version 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 organizacion.

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 mitigacion 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 mas adelante) es la accion equivalente a "parchear".

Reseteo de credenciales

El reseteo de credenciales es una de las acciones mas 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 mas costoso, pero es la unica 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 mas segura porque elimina cualquier artefacto malicioso, incluyendo los que no fueron identificados durante la investigacion.

Limpieza: eliminar el malware y las modificaciones del atacante manteniendo la instalacion existente. Es mas rapida 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 investigacion 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 mas funciona.

Segundo, infraestructura de seguridad: firewalls, EDR, SIEM, servidores de log. La monitorizacion debe estar activa antes de restaurar servicios de produccion.

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 mas criticos.

Verificacion 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 trafico 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) estan 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 investigacion 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, formacion de concienciacion para usuarios.

Si el vector fue una vulnerabilidad web: implementar WAF, establecer un programa de gestion 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 monitorizacion 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 proteccion 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 deteccion de ataques (4624, 4625, 4648, 4672, 4768, 4769, 4776, 7045, 4698).

Hardening de red

Implementar segmentacion de red que limite 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 minimo privilegio.

Implementar deteccion de anomalias en el trafico de red. Herramientas como Zeek o Suricata proporcionan visibilidad sobre el trafico interno.

Mejora de la capacidad de deteccion

El incidente revela gaps en la capacidad de deteccion. Las mejoras tipicas incluyen:

Crear reglas de deteccion especificas para las TTPs observadas en el incidente. Si el atacante uso PowerShell para post-explotacion, 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 implementacion. Si habia EDR pero no detecto el ataque, revisar la configuracion y las reglas de deteccion.

Aumentar la retencion de logs. Si la investigacion se vio limitada por la falta de logs historicos, aumentar la retencion a un minimo de 90 dias (180 dias o 1 ano para entornos regulados).

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

Verificacion 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 organizacion, no solo en los sistemas comprometidos conocidos.

Las reglas de deteccion para las TTPs del incidente estan activas en el SIEM/EDR.

La monitorizacion 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 organizacion mas segura que antes.