Detectar persistencia: una guia de caza para blue team

Una intrusion rara vez es un solo momento. Despues de que un adversario logra un punto de apoyo, su primera prioridad es asegurarse de poder regresar aunque la maquina se reinicie, la contrasena cambie o el punto de entrada original se cierre. Esa capacidad se llama persistencia, y cazarla es una de las actividades de mayor valor que realiza un blue team. Esta guia adopta una postura defensiva: describimos las categorias de persistencia para que reconozcas sus rastros, nos centramos en la telemetria, los Event IDs y los flujos de caza que las revelan, y cerramos con fortalecimiento. El objetivo es ensenar deteccion y erradicacion, no dar a nadie una receta para permanecer oculto. Si puedes encontrar la persistencia de forma fiable, conviertes un compromiso persistente en un incidente contenido.

Que es la persistencia y por que importa#

La persistencia es cualquier mecanismo que permite a un adversario mantener el acceso a un sistema a traves de interrupciones como reinicios, cierres de sesion o restablecimientos de credenciales. En el marco MITRE ATT&CK es la tactica TA0003, y esta en el corazon de por que las intrusiones se vuelven longevas. La verdad incomoda para los defensores es que la erradicacion falla cuando se pasa por alto la persistencia: puedes eliminar el malware, rotar una contrasena y reconstruir un servicio, pero si el atacante dejo una tarea programada, una cuenta ilicita o una entrada de arranque modificada, simplemente vuelve a entrar. Por eso la respuesta a incidentes siempre incluye una caza deliberada de persistencia antes de declarar limpio un sistema. Encontrar la carga inicial no es la meta; encontrar cada punto de apoyo lo es.

La mentalidad de persistencia para defensores#

La caza eficaz parte de una premisa simple: un atacante que quiere sobrevivir a un reinicio debe dejar algo que el sistema operativo ejecute automaticamente. Esa restriccion es tu ventaja, porque el conjunto de lugares donde el SO busca cosas para ejecutar es finito y esta bien documentado. En vez de perseguir posibilidades infinitas, enumeras las ubicaciones de autoarranque conocidas y preguntas, por cada una, si lo que vive alli es lo esperado. La disciplina es el baselining: saber como se ve lo normal para que las anomalias resalten. Una tarea programada creada a las tres de la manana por un usuario que nunca hace scripts, un servicio que apunta a un binario en una carpeta temporal, o una nueva cuenta de administrador local no son sutiles una vez que tienes una linea base con la que comparar.

Donde se esconde la persistencia en Windows#

En Windows, los defensores deben revisar de forma rutinaria un conjunto conocido de puntos de extensibilidad de autoarranque. Estos incluyen las claves de registro Run y RunOnce, las tareas programadas, los servicios de Windows, las carpetas de inicio, las suscripciones a eventos WMI y el abuso de mecanismos legitimos como el orden de busqueda de DLL o las funciones de accesibilidad. La persistencia basada en cuentas importa igual: cuentas locales o de dominio recien creadas, usuarios anadidos a grupos privilegiados y scripts de inicio de sesion modificados. Herramientas como Sysinternals Autoruns estan construidas precisamente para enumerar estas ubicaciones, y combinarlo con telemetria de Sysmon te da visibilidad de creacion de procesos, modificacion de registro y carga de imagenes. El objetivo al revisar cada ubicacion no es memorizar cada tecnica sino detectar la entrada que no pertenece, y luego pivotar a quien la creo y cuando.

Donde se esconde la persistencia en Linux#

En sistemas Linux y Unix la superficie de autoarranque es distinta pero igual de enumerable. Los trabajos cron y los timers y unidades de systemd son puntos de apoyo comunes, al igual que los archivos de inicio de shell modificados como los scripts profile y rc, las claves SSH autorizadas anadidas y las definiciones de servicio nuevas o alteradas. Los atacantes tambien abusan de tareas programadas que corren como root y de archivos de configuracion cargados al arranque. Defensivamente revisas estas ubicaciones contra una linea base conocida, vigilas archivos con tiempos de modificacion recientes que ningun ticket de cambio explica y monitoreas la adicion de claves SSH a cuentas. Auditd y la telemetria de endpoint ayudan al registrar la ejecucion de procesos y los cambios de archivos, de modo que una entrada cron que aparece fuera de tu pipeline de despliegue se vuelve una senal en vez de una sorpresa que hallas semanas despues.

Persistencia en la nube y de identidad#

La persistencia moderna es cada vez mas basada en identidad y vive por encima de cualquier host individual. En entornos de nube y SaaS, los atacantes buscan acceso duradero a traves de nuevas credenciales en vez de archivos: una access key fresca en un principal de servicio, una relacion de federacion o confianza anadida, una aplicacion OAuth con amplios permisos delegados, o una regla oculta de reenvio de correo. Como estos mecanismos son funciones administrativas legitimas, se mezclan a menos que estes vigilando el log de auditoria. Caza claves y registros de aplicaciones recien creados, cambios en la confianza de roles y la federacion, y concesiones de consentimiento a aplicaciones desconocidas. El principio defensivo refleja el mundo del host: enumera el pequeno conjunto de lugares donde se puede plantar acceso duradero, establece una linea base de lo esperado y trata cualquier adicion inexplicada a la identidad como un posible punto de apoyo.

Senales de deteccion y telemetria#

La caza de persistencia es tan buena como la telemetria que la sostiene. En Windows, los Event IDs relevantes para la seguridad son invaluables: 4698 registra la creacion de tareas programadas, 7045 marca la instalacion de un nuevo servicio, 4720 muestra la creacion de cuentas y 4732 registra un miembro anadido a un grupo con seguridad habilitada. Sysmon anade eventos granulares de creacion de procesos, registro y carga de imagenes que capturan tecnicas que la politica de auditoria por defecto pasa por alto. En Linux, auditd y el historial de shell dan visibilidad equivalente, y las plataformas EDR unen ambos mundos con deteccion basada en comportamiento. La senal mas potente, sin embargo, es la comparacion contra una linea base: alerta sobre la aparicion vista por primera vez de una entrada de autoarranque, un servicio que apunta a una ruta inusual o una creacion de cuenta fuera de tu proceso de aprovisionamiento. La anomalia vence a la firma cuando los adversarios viven de la tierra.

Un flujo de caza practico#

Convierte los conceptos en una rutina repetible. Empieza enumerando las ubicaciones de autoarranque en tu flota con herramientas que reporten claves run del registro, tareas programadas, servicios y elementos de inicio, o sus equivalentes en Linux y la nube. Luego establece la linea base: compara el estado actual con un snapshot conocido como bueno o con la mayoria de hosts similares, porque los valores atipicos son donde miras primero. Despues enriquece cada candidato preguntando quien lo creo, cuando, desde que cuenta y si existe un registro de cambio correspondiente. Correlaciona con logs de procesos y de autenticacion para construir una linea temporal, y finalmente valida si la entrada es benigna o maliciosa antes de actuar. Documenta lo que encuentres para que la proxima caza parta de una mejor linea base, y realimenta los patrones confirmados en detecciones automatizadas.

Mitigacion y fortalecimiento#

La deteccion y la prevencion se refuerzan mutuamente. Reduce la superficie de persistencia aplicando minimo privilegio para que pocas cuentas puedan crear servicios, tareas programadas o nuevos usuarios en primer lugar. Exige autenticacion multifactor y monitorea la pertenencia a grupos privilegiados para que los puntos de apoyo basados en cuentas sean dificiles de plantar y rapidos de notar. Centraliza y protege los logs en un lugar que el atacante no pueda editar, y habilita las politicas de auditoria y la configuracion de Sysmon o auditd que hacen visible la persistencia. El allowlisting de aplicaciones limita lo que puede ejecutarse desde el autoarranque en absoluto. En la nube, restringe quien puede acunar credenciales y otorgar consentimiento, y alerta sobre cambios de confianza y federacion. Cada control que estrecha donde se puede plantar acceso duradero tambien encoge el espacio que debes cazar.

Errores comunes#

Varios errores dejan sobrevivir la persistencia. Los respondedores erradican la carga obvia y cantan victoria sin enumerar las ubicaciones de autoarranque, asi que una tarea programada restablece la intrusion en silencio. Los equipos cazan en el host pero olvidan la persistencia de identidad en la nube, dejando una access key que sobrevive a la reconstruccion. Faltan lineas base, asi que un servicio malicioso es indistinguible de uno legitimo a simple vista. La telemetria no esta configurada, asi que los mismos Event IDs que revelarian una nueva tarea o cuenta nunca se registraron. Y los investigadores encuentran un punto de apoyo y se detienen, sin darse cuenta de que los atacantes suelen plantar varios por redundancia. La cura es una caza sistematica que cubra hosts e identidades, respaldada por lineas base y telemetria completa, y una regla de nunca declarar limpio tras encontrar solo uno.

Lista de verificacion de persistencia para blue team#

Usa esto como secuencia de caza. 1. Confirma que la politica de auditoria, Sysmon o auditd y la centralizacion de logs esten en su lugar antes de necesitarlos. 2. Enumera los puntos de autoarranque de Windows: claves run, tareas programadas, servicios, carpetas de inicio, suscripciones WMI. 3. Enumera los equivalentes de Linux: cron, systemd, archivos rc de shell, claves SSH. 4. Enumera la persistencia de identidad: nuevas claves, registros de aplicaciones, cambios de confianza y consentimiento. 5. Establece linea base de cada uno contra hosts conocidos como buenos o pares y marca los atipicos. 6. Enriquece con correlacion de creador, marca de tiempo y registro de cambio. 7. Construye una linea temporal con los Event IDs 4698, 7045, 4720, 4732 y los logs de procesos. 8. Asume redundancia: sigue cazando tras el primer hallazgo. 9. Remedia, luego vuelve a verificar. 10. Realimenta los patrones confirmados en detecciones automatizadas.

FAQ: encontrar un mecanismo de persistencia basta para declarar limpio un host?#

No, y suponerlo es uno de los errores mas costosos en respuesta a incidentes. Los adversarios plantan de forma rutinaria multiples mecanismos de persistencia precisamente para que eliminar uno no los deje fuera. Si encuentras una tarea programada maliciosa, tratala como una senal para cazar mas fuerte, no como el fin de la investigacion, y enumera cada otra ubicacion de autoarranque en el host asi como la persistencia basada en identidad en cualquier nube conectada. Construye una linea temporal completa de lo que hizo el atacante y cuando, porque la persistencia que encuentras a menudo apunta a la cuenta y la ventana de tiempo en que se crearon otros puntos de apoyo. Declara limpio un sistema solo tras una enumeracion completa, no tras el primer acierto.

FAQ: que telemetria debo priorizar si tengo recursos limitados?#

Si debes empezar en pequeno, prioriza las senales que revelan los puntos de apoyo mas comunes. En Windows, habilita la auditoria para la creacion de tareas programadas, la instalacion de servicios y los cambios de cuentas y grupos, que corresponden a los Event IDs 4698, 7045, 4720 y 4732, y despliega Sysmon para visibilidad de procesos y registro. En Linux, habilita auditd para la ejecucion de procesos y monitorea cron, systemd y las claves SSH autorizadas. En la nube, captura el log de auditoria de identidad y alerta sobre nuevas credenciales y cambios de confianza. Centraliza todo esto en un lugar que el atacante no pueda alterar. Con eso cubres una gran fraccion de la persistencia del mundo real, y puedes ampliar la cobertura segun lo permitan los recursos.

Conclusion#

La persistencia es lo que convierte una intrusion breve en una larga, y cazarla es lo que convierte una larga de nuevo en un incidente contenido. La ventaja del defensor es estructural: el sistema operativo y las plataformas de nube buscan elementos de autoarranque y credenciales duraderas en un conjunto finito y documentado de lugares, asi que una caza disciplinada puede cubrirlos todos. Habilita primero la telemetria, establece la linea base de lo normal, enumera los puntos de apoyo de host e identidad, correlaciona los eventos de creacion en una linea temporal y nunca declares limpio tras un solo hallazgo. Combina la deteccion con minimo privilegio y allowlisting para que haya menos lugares donde plantar un punto de apoyo desde el principio. Hecha de forma consistente, la caza de persistencia es el paso que hace real la erradicacion.