Durante una respuesta a incidentes encuentras un vacío sospechoso en los registros de autenticación. ¿Qué concluyes y qué haces?
Respuesta breve
Un vacío en los registros locales durante un incidente puede significar registros borrados o manipulados, un paso antiforense común, así que no trates la ausencia de registros como ausencia de actividad. Coteja con registros centralizados/reenviados, EDR y datos de red que el atacante probablemente no pudo alterar, y documenta el vacío de integridad como un hallazgo. Suponer que el servidor estaba inactivo confía en pruebas que el atacante puede controlar, tratar el vacío como prueba de que no pasó nada es justo la conclusión que él quiere, y borrar más registros destruye lo que queda. Corrobora en su lugar con telemetría independiente.
Un vacío limpio e inexplicado en los registros de autenticación durante un incidente activo es en sí mismo una prueba — y el error más peligroso es leerlo como «no pasó nada». Borrar o editar selectivamente registros es una técnica antiforense documentada (MITRE ATT&CK T1070, eliminación de indicadores). Los atacantes lo hacen precisamente para que un respondedor menos experimentado concluya que la ventana estuvo tranquila.
La conclusión y acción correctas
Trata el vacío como un posible evento de integridad, no como un hecho sobre la actividad. Luego:
- Corrobora con fuentes que el atacante probablemente no pudo alcanzar. Los registros centralizados/reenviados (ya fuera del host), la telemetría EDR, los datos de flujo de red y los registros de dispositivos aguas arriba (cortafuegos, VPN, proveedor de identidad) con frecuencia siguen mostrando lo que los registros locales ya no muestran.
- Caza artefactos de manipulación. En Linux, las anomalías de rotación del journal, los vacíos que coinciden con la actividad del atacante en otros sitios, o las inconsistencias de inode/marca de tiempo pueden delatar un borrado incluso cuando las entradas han desaparecido.
- Documenta el vacío de integridad como un hallazgo explícito, con la ventana temporal y qué pruebas corroborantes lo llenan o no. Esto importa tanto para la delimitación del alcance como para la admisibilidad.
Por qué fallan los distractores
- «El servidor estaba inactivo» asume que el registro ausente refleja fielmente la realidad — pero el atacante puede controlar justamente esa fuente. La ausencia de prueba no es prueba de ausencia.
- «Confiar en el vacío como prueba de que no pasó nada» es la conclusión que el atacante está orquestando; es la trampa, no la respuesta.
- «Borrar el resto de los registros para ordenar» destruye las pruebas restantes y podría constituir destrucción de pruebas — catastrófico para una investigación y cualquier acción legal.
Qué está evaluando el entrevistador
Si desconfías instintivamente de los vacíos convenientes, recurres a telemetría independiente y a prueba de manipulación, y preservas en lugar de destruir pruebas — el criterio senior que distingue «los registros dicen que no pasó nada» de «se hizo que los registros dijeran que no pasó nada».
Posibles preguntas de seguimiento
- ¿Qué artefactos en Linux revelan que los registros fueron borrados incluso cuando las entradas en sí han desaparecido?
- ¿Cómo cambia el reenvío centralizado de registros la capacidad de un atacante para ocultarse, y cuáles son sus límites?
- ¿Cómo documentarías un vacío de integridad de la prueba para que resista el escrutinio legal?