Objetivo
Medir impacto después de obtener acceso
Enfoque
Evidencia mínima, límites y limpieza
Resultado
Documentar alcance real sin dejar riesgos abiertos
20.1 Introducción
La post-explotación comienza cuando ya se obtuvo algún tipo de acceso: una sesión, una cuenta válida, un token, una shell limitada, un rol dentro de una aplicación o control sobre un servicio. En ese momento, la pregunta principal cambia: ¿qué impacto tiene este acceso?
Esta fase puede incluir recolección de información, validación de privilegios, identificación de datos accesibles, análisis de rutas de movimiento lateral, revisión de persistencia autorizada y limpieza de artefactos.
El enfoque debe ser controlado. Tener acceso no significa tener permiso para explorar sin límites. La post-explotación debe respetar alcance, reglas de compromiso y mínima intrusión.
20.2 Objetivos de la post-explotación
La post-explotación tiene objetivos defensivos y de medición de riesgo. No se trata de mantener acceso por mantenerlo.
- Confirmar identidad, privilegios y contexto del acceso obtenido.
- Determinar qué datos o funciones quedan expuestos.
- Evaluar si el acceso permite escalar privilegios.
- Analizar si existe posibilidad de movimiento lateral autorizado.
- Medir impacto real sobre confidencialidad, integridad y disponibilidad.
- Recolectar evidencia mínima y protegida.
- Limpiar artefactos generados durante la prueba.
La post-explotación debe convertir acceso técnico en comprensión de impacto, no en una exploración indiscriminada.
20.3 Límites y autorización
La post-explotación suele acercarse a datos sensibles y sistemas críticos. Por eso, sus límites deben estar claros antes de ejecutarla.
| Actividad |
Requiere |
Cuidado principal |
| Enumerar privilegios locales |
Acceso autorizado al sistema |
No modificar configuración |
| Consultar archivos sensibles |
Justificación y evidencia mínima |
No copiar contenido completo |
| Movimiento lateral |
Autorización explícita |
No tocar sistemas fuera de alcance |
| Persistencia |
Aprobación específica |
No dejar accesos ocultos o indefinidos |
| Limpieza |
Plan y trazabilidad |
No borrar logs defensivos sin acuerdo |
20.4 Confirmar contexto de acceso
Lo primero es saber desde dónde se está operando y con qué permisos. Esto evita acciones incorrectas y ayuda a medir impacto.
- Usuario actual y grupos.
- Host, sistema operativo y rol del equipo.
- Privilegios locales o de dominio.
- Proceso o servicio desde el cual se ejecuta la sesión.
- Redes alcanzables desde el sistema.
- Restricciones de seguridad activas.
- Relación del sistema con datos o servicios críticos.
20.5 Recolección mínima de información
La recolección debe estar orientada a responder preguntas de impacto. No se debe copiar todo lo accesible.
- Metadatos de archivos sensibles, no contenido completo.
- Listados parciales cuando basta para demostrar exposición.
- Fragmentos enmascarados de secretos o configuraciones.
- Identificadores de bases de datos o sistemas, no dumps completos.
- Capturas que muestren permisos, no datos personales completos.
- Rutas y propietarios de archivos críticos.
- Evidencia de acceso a funciones, no ejecución masiva de acciones.
La pregunta correcta es: ¿cuál es la evidencia mínima que demuestra este impacto?
20.6 Clasificación de información encontrada
La información recolectada debe clasificarse para priorizar riesgo y proteger evidencias.
| Tipo |
Ejemplos |
Manejo recomendado |
| Credenciales |
Contraseñas, claves API, tokens |
Enmascarar, proteger y recomendar rotación |
| Datos personales |
Documentos, correos, teléfonos |
Captura mínima y anonimizada |
| Datos de negocio |
Contratos, reportes, operaciones |
Evitar copia completa |
| Configuración |
Archivos .env, connection strings |
Mostrar ruta y fragmento no sensible |
| Infraestructura |
Hosts, redes, topologías |
Usar para impacto y alcance, no para ampliar sin permiso |
20.7 Validar impacto sobre confidencialidad
El impacto sobre confidencialidad aparece cuando el acceso permite leer información que no debería estar disponible para ese usuario o contexto.
- Archivos de configuración con secretos.
- Datos personales o de clientes.
- Documentos internos.
- Backups o dumps.
- Tokens y claves de servicio.
- Logs con información sensible.
La validación debe limitarse a demostrar acceso, no a extraer información masiva.
20.8 Validar impacto sobre integridad
El impacto sobre integridad aparece cuando el acceso permite modificar datos, configuraciones, archivos o estados de negocio. Debe probarse con extrema cautela.
- Modificar un recurso de laboratorio.
- Crear un archivo de prueba en una ruta autorizada.
- Actualizar un registro controlado.
- Demostrar permisos de escritura sin usarlos si basta con evidencia de ACL.
- No alterar datos reales ni configuraciones productivas.
- Revertir cambios inmediatamente.
20.9 Validar impacto sobre disponibilidad
La disponibilidad es especialmente sensible. No se debe provocar caída para demostrar riesgo salvo autorización explícita y ventana controlada.
- Validar DoS por versión, configuración y advisory.
- Evitar pruebas de carga no autorizadas.
- No detener servicios productivos.
- No llenar discos, logs o colas.
- No ejecutar payloads que consuman CPU o memoria.
- Documentar riesgos de disponibilidad con evidencia indirecta cuando sea suficiente.
20.10 Persistencia controlada
La persistencia consiste en mantener acceso después de la explotación inicial. En pentesting estándar, no debe implementarse salvo que esté explícitamente autorizada y tenga objetivo claro.
Cuando se autoriza, debe ser:
- Temporal.
- Documentada.
- Visible para el cliente si así se acordó.
- Reversible.
- Limitada al alcance.
- Eliminada al finalizar.
- Registrada en el reporte.
Persistencia no autorizada rompe el marco ético del pentest. Si no está aprobada por escrito, no se implementa.
20.11 Ejemplos de persistencia y riesgos
| Mecanismo |
Riesgo |
Uso responsable |
| Cuenta temporal |
Acceso olvidado |
Crear solo si está aprobado y eliminar al cierre |
| Clave SSH autorizada |
Acceso persistente no controlado |
Registrar huella, usuario y fecha de retiro |
| Tarea programada |
Ejecución repetida no deseada |
Evitar salvo ejercicio específico |
| Servicio temporal |
Impacto operativo o detección defensiva |
Usar alternativa menos invasiva |
| Token o sesión extendida |
Uso posterior no trazado |
Revocar al finalizar |
20.12 Movimiento lateral y límites
La post-explotación puede revelar acceso a otros sistemas. Probar movimiento lateral requiere autorización explícita, porque cambia el objetivo y puede afectar más activos.
- No usar credenciales encontradas contra otros sistemas sin permiso.
- No escanear redes internas fuera del alcance.
- Validar rutas con evidencia indirecta si alcanza.
- Solicitar ampliación formal de alcance si aparece una ruta crítica.
- Documentar sistemas alcanzables como riesgo potencial.
- Evitar propagar herramientas o payloads sin autorización.
20.13 Recolección de credenciales
Las credenciales son evidencia altamente sensible. Encontrarlas puede cambiar por completo la severidad, pero su manejo debe ser estricto.
- No copiar credenciales completas si no es necesario.
- Enmascarar valores en capturas.
- Registrar ubicación, tipo y alcance probable.
- No probarlas contra otros sistemas sin autorización.
- Recomendar rotación inmediata si están expuestas.
- Proteger evidencias con controles de acceso.
Una credencial encontrada es un hallazgo; usarla para ampliar acceso es otra actividad que requiere permiso.
20.14 Trazabilidad de acciones
Durante post-explotación, registrar acciones es esencial para transparencia y limpieza.
- Hora aproximada de cada acción relevante.
- Sistema y usuario utilizados.
- Comando, petición o herramienta usada.
- Archivo, cuenta o artefacto creado.
- Datos consultados o evidencia recolectada.
- Acciones de limpieza realizadas.
- Eventos inesperados o errores.
20.15 Limpieza de artefactos
La limpieza debe planificarse desde antes de la explotación. Todo artefacto creado durante la prueba debe eliminarse o entregarse al cliente según lo acordado.
| Artefacto |
Acción |
Evidencia de limpieza |
| Archivo de prueba |
Eliminarlo |
Captura o registro de eliminación |
| Cuenta temporal |
Deshabilitar o eliminar |
Confirmación del estado final |
| Token generado |
Revocar |
Prueba de invalidez posterior |
| Sesión abierta |
Cerrar |
Registro de cierre |
| Configuración temporal |
Revertir |
Comparación antes/después |
20.16 Qué no debe limpiarse sin acuerdo
Limpiar no significa borrar rastros defensivos. En un pentest estándar, borrar logs puede ser inapropiado y generar problemas de auditoría.
- No borrar logs de seguridad salvo ejercicio específico.
- No eliminar alertas de EDR o SIEM.
- No modificar historiales para ocultar actividad.
- No retirar evidencias que el cliente necesita investigar.
- No deshabilitar controles defensivos sin autorización.
Si se generaron logs o alertas, lo correcto es documentarlo y coordinar con el cliente.
20.17 Comunicación durante post-explotación
La comunicación debe ser más activa cuando la prueba llega a datos sensibles, privilegios altos o posibles rutas críticas.
- Avisar hallazgos críticos de inmediato.
- Solicitar aprobación antes de ampliar alcance.
- Informar si se accedió accidentalmente a datos sensibles.
- Coordinar persistencia autorizada si aplica.
- Reportar artefactos que no pudieron limpiarse.
- Confirmar con el cliente antes de validar acciones de alto impacto.
20.18 Métricas de impacto
Para reportar post-explotación, conviene transformar acceso técnico en métricas comprensibles.
- Tipo de acceso obtenido.
- Privilegios alcanzados.
- Datos potencialmente expuestos.
- Sistemas alcanzables desde la posición comprometida.
- Controles que limitaron o no limitaron avance.
- Tiempo estimado hasta impacto.
- Acciones necesarias para remediar.
20.19 Evidencia de post-explotación
La evidencia debe mostrar alcance e impacto sin exponer más de lo necesario.
| Impacto |
Evidencia adecuada |
Evitar |
| Privilegio local |
Usuario, grupos y contexto |
Modificar el sistema para demostrar control |
| Acceso a datos |
Ruta y fragmento enmascarado |
Copiar datasets completos |
| Credencial expuesta |
Tipo, ubicación y valor truncado |
Guardar secreto completo sin protección |
| Movimiento lateral posible |
Ruta potencial y condición |
Conectarse sin autorización |
| Persistencia autorizada |
Artefacto, duración y limpieza |
Dejar acceso activo al cierre |
20.20 Remediación después de post-explotación
Las recomendaciones deben cortar la ruta completa de ataque, no solo el primer punto de entrada.
- Corregir vulnerabilidad inicial.
- Rotar credenciales expuestas.
- Reducir privilegios excesivos.
- Proteger secretos con gestores adecuados.
- Segmentar sistemas para limitar movimiento lateral.
- Mejorar monitoreo y alertas.
- Revisar logs para detectar abuso previo.
- Validar limpieza de artefactos del pentest.
20.21 Errores frecuentes
- Explorar sin objetivo después de obtener acceso.
- Copiar demasiados datos como evidencia.
- Usar credenciales encontradas fuera del alcance.
- Implementar persistencia sin autorización explícita.
- No documentar artefactos creados.
- Olvidar limpiar archivos, tokens o cuentas temporales.
- Borrar logs defensivos sin acuerdo.
- No comunicar hallazgos críticos hasta el reporte final.
20.22 Flujo práctico de post-explotación
Un flujo responsable puede ser:
- Confirmar que el acceso obtenido está dentro del alcance.
- Identificar usuario, privilegios, sistema y contexto.
- Definir qué impacto se quiere medir.
- Recolectar evidencia mínima sobre datos, permisos o rutas.
- Evaluar credenciales o secretos sin usarlos fuera de permiso.
- Solicitar autorización antes de movimiento lateral o persistencia.
- Registrar todas las acciones relevantes.
- Comunicar hallazgos críticos.
- Limpiar artefactos creados.
- Documentar impacto, limitaciones y remediación.
20.23 Qué debes recordar de este tema
- La post-explotación mide impacto, no justifica exploración ilimitada.
- La recolección debe ser mínima, protegida y orientada a evidencia.
- Persistencia y movimiento lateral requieren autorización explícita.
- Las credenciales encontradas deben tratarse como evidencia sensible.
- La limpieza debe planificarse y documentarse.
- No se deben borrar logs defensivos sin acuerdo específico.
20.24 Conclusión
La post-explotación es donde se entiende el impacto real del acceso obtenido. Bien ejecutada, permite explicar qué habría podido lograr un atacante y qué controles limitaron o permitieron el avance.
En el próximo tema veremos pivoting, tunneling, proxychains y movimiento lateral autorizado, profundizando en cómo analizar rutas entre sistemas sin exceder el alcance definido.