En 05-01 escalamos privilegios y ya somos root/SYSTEM en uno o varios hosts de TechNova. Un atacante real, llegado a este punto, querría no perder ese acceso: si la máquina se reinicia, si se cambia la contraseña que explotó o si se parchea el fallo de entrada, quiere poder volver sin reexplotar. A eso se le llama persistencia o mantenimiento del acceso. En un pentest autorizado, la persistencia tiene un sentido muy distinto al del atacante: sirve para demostrar el impacto —"con este foothold, un adversario habría podido reengancharse aquí"— y para probar si TechNova lo detecta. No es un fin en sí mismo, y desde luego no es dejar puertas abiertas.

Esta lección exige el encuadre más estricto del módulo, y no lo relajamos. La regla de oro se convierte aquí en el eje central: el pentester documenta cada mecanismo de persistencia que crea —cuenta, tarea, servicio, clave, webshell— y lo REVIERTE al terminar, entregando al cliente la lista completa de todo lo introducido. Nada de accesos ocultos que se quedan. De hecho, los pentesters profesionales no ocultan esta actividad: dejan rastro auditable precisamente para que el cliente pueda verificar la limpieza. Y por eso enseñamos cada mecanismo desde la perspectiva defensiva: qué haría el atacante, por qué, y —en primer plano— cómo lo detecta y lo previene el equipo azul. No hay recetas de rootkits ni de ocultación profunda; esos solo se nombran para explicar qué debe cazar el defensor.

1. Qué significa "persistencia" en un engagement autorizado
2. La regla de oro: crear, documentar, revertir
3. Mecanismos de persistencia y su detección
4. Un ejemplo controlado: clave SSH autorizada
5. La perspectiva defensiva en primer plano
6. Rootkits y ocultación: solo lo que el defensor debe cazar
7. Errores comunes y consejos (incluidos los éticos)
8. Ejercicios
9. Conclusión

Para el atacante, persistir es sobrevivir a reinicios, parches y cambios de credenciales. Para el pentester de TechNova, la persistencia responde a dos preguntas del informe:

• Impacto: ¿un adversario que llegara hasta aquí podría reengancharse de forma estable? Demostrarlo eleva la gravedad de un hallazgo de "acceso puntual" a "compromiso sostenible".
• Detección: ¿el SOC de TechNova se entera cuando alguien crea una cuenta nueva, una tarea programada o un servicio? Ese es, muchas veces, el hallazgo más valioso —una brecha en la capacidad de detección.

La persistencia nunca es el objetivo final del engagement autorizado. El objetivo es el informe; la persistencia es una evidencia más que se captura y, acto seguido, se retira.

Todo artefacto de persistencia sigue un ciclo cerrado y auditable:

Esto se sostiene con una bitácora de artefactos: una tabla que el pentester mantiene en tiempo real.

Esta tabla es parte del entregable. Si algo no se puede revertir en la ventana, se marca y se comunica explícitamente al contacto técnico para que lo elimine. Un pentester no se marcha dejando dudas sobre lo que introdujo.

Los mecanismos que un atacante usaría —y que, por tanto, el defensor debe conocer y cazar. La columna protagonista es cómo se detecta y previene:

El patrón se repite: casi toda persistencia crea o modifica algo que un sistema con baseline, integridad de ficheros y alertas de eventos puede detectar. Esa es la lección para TechNova.

Ilustramos un solo mecanismo, de bajo impacto y fácilmente reversible, para ver el ciclo completo. Añadir nuestra clave pública a authorized_keys de una cuenta da acceso por SSH sin contraseña. Lo hacemos con marca identificable para poder revertirlo y auditarlo.

El comentario pentest-technova es deliberado: hace la entrada trazable y garantiza que revertimos exactamente lo que pusimos, sin tocar claves legítimas. Contrapartida defensiva (protagonista): proteger authorized_keys con monitorización de integridad de ficheros (que alerte ante cualquier cambio), restringir sus permisos, y preferir gestión centralizada de claves; un cambio en ese fichero fuera de un proceso aprobado debe generar una alerta en el SIEM.

Si esta lección deja un solo mensaje para TechNova, es cómo detectar y prevenir la persistencia —porque es exactamente lo que un atacante real intentaría y lo que el SOC debe cazar:

• Baselines: conocer el estado normal —qué cuentas, servicios, tareas y claves existen— para que cualquier añadido destaque. Sin baseline no hay detección.
• Integridad de ficheros (FIM): vigilar ficheros sensibles (authorized_keys, /etc/passwd, webroot, puntos de arranque) y alertar ante cambios.
• Alertas de eventos en el SIEM: creación de cuentas (4720), de tareas (4698), de servicios (7045), cambios en cron. Reenviados de forma centralizada (enlaza con 05-04).
• EDR: detecta los patrones de comportamiento típicos de la persistencia (procesos que se registran para autoarranque, shells lanzadas por servicios web).
• Mínimo privilegio y revisión de cuentas: menos cuentas privilegiadas y revisiones periódicas reducen tanto la superficie como el sitio donde esconderse.
• Higiene de credenciales: rotar claves tras un incidente y no fiarse solo del cambio de contraseña —una clave SSH o una tarea persistente lo ignoran.

Un atacante avanzado intentaría ocultar su persistencia con rootkits (que esconden procesos, ficheros o conexiones) o técnicas de ocultación profunda. Aquí no las enseñamos como receta, y el pentester profesional de TechNova no las usa para esconderse del cliente: al contrario, deja todo trazable. Las nombramos solo para que el defensor sepa qué existe y qué buscar:

• Qué son: software que manipula el sistema operativo para que sus artefactos no aparezcan en las herramientas normales (ps, ls, listado de servicios).
• Por qué importan al defensor: por eso la detección no puede fiarse solo del propio host comprometido —un rootkit miente al sistema en el que corre.
• Cómo se cazan (lo relevante): verificación de integridad desde fuera del host (arranque limpio, comparación de imágenes), telemetría centralizada que el host no puede alterar (logs ya reenviados al SIEM), detección de anomalías de red, y herramientas de comprobación de rootkits. La defensa robusta asume que el host comprometido no es fuente fiable y se apoya en evidencia externa.

Este es el enfoque correcto: conocer la amenaza para defenderse, no para ejecutarla contra el cliente.

• [Ético] Dejar un artefacto sin revertir. Es el error más grave del módulo: una cuenta, tarea o webshell olvidada es una puerta trasera real que puede acabar en manos de un atacante de verdad. Revierte todo y entrega la lista completa. La bitácora existe para que no se te escape ninguno.
• [Ético] Persistir sin que el RoE lo contemple. Probar persistencia puede requerir acuerdo explícito; instalarla "porque sí" excede el mandato. Confirma el alcance antes.
• [Ético] Ocultar tu actividad al cliente. El pentester profesional deja rastro auditable; no evade al SOC para "ganar", sino para medir su detección si así se pactó. Esconderte del cliente traiciona el encargo.
• Usar artefactos sin marca identificable. Sin un comentario o nombre reconocible (pentest-technova), no puedes garantizar que revertiste exactamente lo tuyo. Marca siempre lo que creas.
• Reportar la persistencia sin la contrapartida. Cada mecanismo va con su detección/prevención (baseline, FIM, alertas). El valor para TechNova está en aprender a cazarla.
• Confundir persistencia con movimiento lateral. Mantener el acceso en este host es 05-02; usarlo para saltar a otros hosts es 05-03. No los mezcles.
• Consejo: trata cada artefacto como un préstamo, no como una posesión. Lo creas, lo enseñas, lo documentas y lo devuelves. Si dudas de si podrás revertir algo, no lo crees.

Ejercicio 1. Vas a demostrar persistencia en un host Linux de TechNova (10.10.10.15) añadiendo una clave SSH autorizada, dentro de un RoE que lo contempla. Escribe el ciclo completo —crear, documentar, capturar evidencia, revertir— con especial cuidado en cómo garantizas que revertiste exactamente tu artefacto. Añade la contrapartida defensiva que TechNova debería implementar.

Ejercicio 2. El SOC de TechNova pregunta qué eventos debería vigilar para detectar los tres mecanismos de persistencia más comunes en Windows (cuenta nueva, tarea programada, servicio nuevo). Enuméralos y explica qué papel juega tener un baseline para que estas alertas sean útiles.

Ejercicio 3. Un compañero junior propone instalar un rootkit para "que la persistencia no la detecte el SOC y así el ejercicio sea más realista". Explica por qué esto es un error ético y metodológico en un pentest autorizado, y reformula el objetivo de manera correcta.

Solución 1. Ciclo completo: (1) Crear con marca identificable: echo "ssh-ed25519 AAAA... pentest-technova" >> ~/.ssh/authorized_keys. (2) Documentar en la bitácora: host 10.10.10.15, cuenta, fichero ~/.ssh/authorized_keys, comentario pentest-technova, fecha y hora. (3) Capturar evidencia: demostrar el re-acceso por SSH una sola vez (captura con hora) y parar. (4) Revertir exactamente lo añadido usando el comentario como ancla: sed -i '/pentest-technova/d' ~/.ssh/authorized_keys y verificar con grep -c pentest-technova ~/.ssh/authorized_keys que devuelve 0. La marca garantiza que se elimina solo la clave del pentester, sin tocar claves legítimas. Contrapartida: monitorización de integridad de ficheros sobre authorized_keys con alerta ante cualquier cambio, permisos restrictivos, y gestión centralizada de claves; el cambio se habría reflejado como alerta en el SIEM.

Solución 2. Eventos de Windows: 4720 (creación de una cuenta de usuario), 4698 (creación de una tarea programada) y 7045 (instalación de un servicio nuevo). Reenviados a un SIEM central para que el host comprometido no pueda ocultarlos (enlaza con 05-04). El baseline es imprescindible porque estas alertas por sí solas generan mucho ruido en un entorno grande: solo sabiendo qué cuentas, tareas y servicios son normales y esperados puede el SOC distinguir un añadido malicioso de la actividad legítima de administración. Sin baseline, la alerta 4720 se pierde entre las creaciones rutinarias; con baseline, una cuenta nueva no prevista salta de inmediato.

Solución 3. Es un error ético porque el pentester profesional no oculta su actividad al cliente: mantiene un rastro auditable de todo lo que hace, y un rootkit va justo en contra de eso, además de introducir software difícil de revertir por completo (riesgo de dejar un artefacto persistente real). Es un error metodológico porque el objetivo del engagement no es "ganarle al SOC escondiéndose", sino medir y mejorar la detección de TechNova. Reformulación correcta: si el RoE contempla probar la capacidad de detección, se crean artefactos de persistencia trazables y documentados (con marca identificable), se observa si el SOC los detecta, y el hallazgo —lo detecte o no— se lleva al informe con su contrapartida; al terminar, todo se revierte y se entrega la lista al cliente. La amenaza del rootkit se documenta como algo que el defensor debe poder cazar (telemetría externa, integridad desde fuera del host), no como algo que el pentester ejecuta.

Hemos tratado el mantenimiento del acceso como lo que debe ser en un pentest profesional: una demostración de impacto y una prueba de la capacidad de detección de TechNova, no un fin ni una puerta trasera. Vimos los mecanismos que un atacante usaría —cuentas, tareas/cron, servicios, claves SSH, webshells— siempre con su contrapartida defensiva en primer plano (baselines, integridad de ficheros, alertas de eventos en el SIEM, EDR), e ilustramos el ciclo completo con una clave SSH marcada y revertida. Los rootkits y la ocultación aparecieron solo como amenaza que el defensor debe conocer y cazar con telemetría externa, nunca como receta.

Por encima de la técnica, queda la regla de oro: todo artefacto se crea con acuerdo, se documenta en la bitácora, se captura como evidencia y se revierte, entregando al cliente la lista completa. El pentester no deja accesos ocultos ni esconde su actividad. Con el acceso escalado (05-01) y su persistencia entendida y controlada (05-02), el compromiso en este host está medido. La siguiente pregunta es hasta dónde alcanza en la red: cómo usar este host como trampolín hacia segmentos internos que no eran accesibles directamente. Eso es 05-03 Pivoting y Movimiento Lateral.