Respuesta a incidentes en la nube AWS: donde mirar primero

Cuando salta una alerta en una cuenta de AWS, la diferencia entre una investigacion de dos horas y una de dos semanas es saber donde mirar primero. La respuesta a incidentes en la nube no es igual a investigar un portatil o un servidor local: no hay un disco que copiar en el sentido tradicional, el plano de control es una API y la evidencia mas importante suele ser una entrada de log que caduca si no activaste el registro con antelacion. Esta guia esta escrita para defensores. El objetivo es entender la superficie de ataque para detectar el abuso y recuperarse con seguridad, no ensenar a nadie a entrar. Recorreremos la telemetria de AWS que importa, las senales que separan el ruido de una intrusion real y como contener el dano sin destruir la evidencia que necesitas.

Por que la respuesta a incidentes en la nube es diferente#

En un entorno tradicional respondes a un host: lo aislas, capturas la memoria y copias el disco. En AWS el objeto primario de investigacion es la cuenta y sus identidades. Un atacante que obtiene una credencial valida puede actuar desde cualquier lugar del mundo a traves de la misma API que usas, y sus acciones parecen sintacticamente identicas a la administracion legitima. En una intrusion del plano de control no hay malware que encontrar, solo una secuencia de llamadas a la API. Esto desplaza el centro de gravedad de la investigacion desde los binarios y los archivos hacia la identidad, los permisos y los logs de auditoria. Tambien significa que la preparacion es decisiva: la evidencia que puedes recopilar despues es exactamente la que configuraste antes del incidente. Si el registro a nivel de organizacion estaba apagado, la reconstruccion posible queda fundamentalmente limitada.

Preparate antes del incidente: una disposicion que rinde#

La disposicion es el control mas barato que jamas compraras. Antes de que ocurra nada, confirma que hay un trail de CloudTrail multi-region y a nivel de organizacion habilitado y entregando a una cuenta de logging dedicada, de solo escritura, que los respondedores puedan leer pero las cuentas de servicio no puedan borrar. Habilita GuardDuty en todas las regiones y cuentas, activa Config para registrar el estado de los recursos en el tiempo y asegurate de que VPC Flow Logs y los logs de servicio relevantes (registro de acceso a S3, logs de balanceadores, registro de consultas DNS via Route 53 Resolver) se capturen de forma centralizada. Establece roles de emergencia con MFA fuerte y documenta quien puede asumirlos. Un runbook breve y ensayado que nombre las ubicaciones de los logs, los pasos de aislamiento y los contactos de escalado ahorrara mas tiempo en un evento real que cualquier herramienta.

Las fuentes de logs clave de AWS en las que te apoyaras#

Cuatro fuentes sostienen la mayoria de las investigaciones en la nube. CloudTrail es el log de auditoria del plano de control: cada llamada a la API, quien la hizo, desde que IP e identidad y si tuvo exito. GuardDuty es un detector gestionado que correlaciona datos de CloudTrail, DNS y flujo en hallazgos como exfiltracion de credenciales o uso anomalo de la API. VPC Flow Logs registran las conversaciones de red a nivel de ENI, donde reconstruyes el movimiento lateral y la salida de datos. Config te da una linea temporal de como se veia un recurso en cada momento, invaluable para probar cuando se abrio un grupo de seguridad o se cambio una politica. Alrededor de estas hay logs especificos de servicio (S3, RDS, Lambda, CloudFront, WAF) que anaden contexto sobre las cargas de trabajo implicadas.

Donde mirar primero: CloudTrail#

CloudTrail es casi siempre la primera parada. Empieza pivotando sobre la identidad de la alerta y hazte tres preguntas: que hizo este principal, desde donde y cuando cambio el comportamiento. Filtra por valores de eventName que indiquen reconocimiento o intentos de escalada y presta atencion especial a los eventos del plano de gestion. Los eventos de alta senal para un compromiso incluyen cambios de identidad y confianza, como CreateUser, CreateAccessKey, AttachUserPolicy, PutUserPolicy, UpdateAssumeRolePolicy y CreateLoginProfile. Vigila los registros de ConsoleLogin sin MFA, un GetCallerIdentity seguido de inmediato por llamadas de listado amplio y los picos de resultados AccessDenied que revelan a un actor tanteando permisos. Correlaciona la IP de origen, el user agent y si las llamadas vinieron por credenciales de rol temporales, lo que indica si se abuso de una access key o de un rol asumido.

Senales de identidad y acceso#

Como la identidad es el campo de batalla, invierte en la vista de permisos. Enumera los usuarios, roles y access keys de IAM creados o modificados recientemente y comparalos con tus registros de cambios. Una access key recien creada en una cuenta de servicio, una politica de confianza de rol que de pronto permite una cuenta externa o una politica en linea que otorga iam:* son indicadores fuertes de un atacante estableciendo acceso duradero. Los hallazgos de GuardDuty de las familias UnauthorizedAccess, CredentialAccess y Persistence merecen triaje inmediato. IAM Access Analyzer ayuda a detectar recursos que quedaron accesibles desde fuera de la cuenta. En todo momento recuerda que la automatizacion legitima tambien crea keys y roles, asi que la senal es la desviacion respecto a la linea base, no la accion aislada.

Telemetria de red y del plano de datos#

Una vez que entiendes lo que hizo la identidad, sigue los datos. Los VPC Flow Logs te permiten ver que instancias hablaron con que endpoints y cuantos bytes se movieron, para distinguir el trafico rutinario de una salida masiva hacia un destino desconocido. Los logs de consultas DNS revelan con frecuencia dominios de mando y control o de preparacion que los datos de flujo por IP ocultan tras CDNs. En el lado del almacenamiento, los logs de acceso al servidor de S3 y los data events de CloudTrail para S3 muestran lecturas a nivel de objeto: una serie repentina de llamadas GetObject en un bucket entero, o un ListBuckets seguido de descargas dirigidas, es la forma clasica de la exfiltracion. Para bases de datos, revisa los logs de RDS y cualquier auditoria de consultas que habilitaras. La pregunta que respondes es simple y de peso: salieron datos y, de ser asi, cuales y cuantos.

Convertir senales en detecciones#

Cazar con eficacia significa escribir las preguntas como consultas repetibles. Usando CloudTrail en Athena o tu SIEM, construye detecciones para inicios de sesion de consola desde nuevos paises o ASNs, para llamadas a la API cuyo user agent no coincide con tu tooling conocido, para cualquier uso de la cuenta root y para la desactivacion de servicios de seguridad como StopLogging, DeleteTrail, DeleteFlowLogs o DisableSecurityHub. Alerta sobre emparejamientos vistos por primera vez de principal y region, porque los atacantes a menudo operan en regiones que tus equipos nunca usan. Ordena los hallazgos por radio de impacto: un cambio en una identidad que puede asumir otros roles importa mas que una unica llamada denegada. Ajusta con agresividad para que las alertas que despiertan a una persona sean las que de verdad lo justifican.

Contencion sin destruir evidencia#

La contencion en la nube es rapida, lo que es un regalo y un riesgo. Puedes revocar una sesion, desactivar una access key o desasociar una politica en segundos, pero si borras el rol comprometido o terminas la instancia puedes borrar evidencia que aun no recopilaste. La secuencia que preserva la evidencia es primero hacer snapshot y preservar: toma snapshots EBS de los volumenes afectados, captura los metadatos de la instancia y exporta los rangos de log relevantes a tu almacen del caso. Luego restringe la identidad adjuntando un deny explicito o revocando sesiones en vez de borrar el principal, y aisla el computo moviendolo a un grupo de seguridad de cuarentena sin salida. Rota las credenciales expuestas e invalida los tokens temporales. Solo tras la preservacion y la contencion pasas a la erradicacion y reconstruyes desde infraestructura como codigo conocida y buena.

Errores comunes#

Se repiten varios errores. Los equipos descubren durante el incidente que CloudTrail era de una sola region o nunca entregaba a una cuenta aislada, asi que las acciones del atacante en otra region son invisibles. Los respondedores terminan instancias por rapidez y pierden artefactos de memoria y disco. Los investigadores confian en las marcas de tiempo de un solo log sin correlacionar relojes entre fuentes. La gente persigue una llamada maliciosa a la API y pasa por alto la persistencia que el atacante planto tres pasos antes, como una access key olvidada o una confianza de rol modificada. Y un error evitable frecuente es arreglar el sintoma y luego no rotar cada credencial que el actor pudo tocar, lo que invita al reingreso inmediato. Escribe estas lecciones en el runbook para que el siguiente respondedor no las reaprenda bajo presion.

Lista de verificacion del blue team#

Usa esto como secuencia inicial. 1. Confirma el alcance: que cuentas, regiones e identidades estan implicadas. 2. Preserva primero: exporta rangos de CloudTrail, haz snapshot de volumenes, captura metadatos de instancia. 3. Reconstruye la linea temporal de la identidad desde CloudTrail, centrandote en cambios de IAM y confianza. 4. Extrae los hallazgos de GuardDuty y correlaciona con logs de flujo y DNS. 5. Determina el impacto en los datos con los data events de S3 y el volumen de salida. 6. Contiene con politicas de deny, revocacion de sesiones y grupos de seguridad de cuarentena, no con borrado. 7. Rota cada credencial potencialmente expuesta e invalida los tokens temporales. 8. Erradica y reconstruye desde infraestructura como codigo. 9. Documenta la linea temporal y realimenta las detecciones en tu monitorizacion.

FAQ: cuanto tiempo se conservan los logs de AWS por defecto?#

Depende del servicio y de tu configuracion. El historial de eventos de la consola de CloudTrail se conserva 90 dias, pero eso no sustituye a un trail duradero que entregue a S3, que controlas y deberias conservar segun tu politica. Los hallazgos de GuardDuty, los VPC Flow Logs y los logs de servicio tienen cada uno su propia retencion que tu fijas. Por eso importa la disposicion: si dependes del historial de consola por defecto, una investigacion que empieza tarde puede hallar la evidencia mas temprana ya desaparecida. Configura una entrega de logs duradera y resistente a manipulacion antes de necesitarla.

FAQ: necesito copiar una instancia EC2, o eso quedo obsoleto en la nube?#

Los artefactos volatiles y de disco siguen importando cuando una carga de trabajo esta comprometida, asi que el imaging no quedo obsoleto para intrusiones a nivel de host. El enfoque que preserva la evidencia es tomar un snapshot EBS del volumen afectado y, cuando sea factible, capturar la memoria antes de detener la instancia, y luego adjuntar el snapshot a una estacion forense para analisis fuera de linea. Lo que cambia en la nube es que para un compromiso puro del plano de control puede no haber ningun host que copiar; la investigacion vive por completo en CloudTrail y los registros de identidad. Ajusta la recoleccion a la naturaleza del incidente en vez de aplicar un habito en todas partes.

Conclusion#

La respuesta a incidentes en la nube premia la preparacion y la disciplina. Las cuentas que se recuperan rapido son las que habilitaron registro a nivel de organizacion y resistente a manipulacion antes de un incidente, las que saben que CloudTrail, GuardDuty, VPC Flow Logs y Config son los cuatro pilares y las que contienen amenazas sin incinerar evidencia. Trata la identidad como el campo de batalla principal, sigue los datos para responder si algo salio y preserva siempre antes de actuar. Integra estos pasos en un runbook ensayado, mide con que rapidez reconstruyes una linea temporal de identidad y sigue realimentando lo aprendido en las detecciones. Bien hecha, la respuesta en la nube convierte una alerta aterradora en un procedimiento metodico y repetible.