Respuesta a incidentes en AWS: cuenta comprometida
¿Cuenta de AWS comprometida? Qué hacer primero, qué registros asegurar, cómo delimitar el ataque en CloudTrail y cómo contenerlo sin destruir evidencias.
En resumen. Trate «nuestra cuenta de AWS está comprometida» como dos tareas en paralelo: detener la hemorragia (desactivar las credenciales que tiene el atacante y eliminar lo que ha lanzado) y conservar y leer los registros (primero CloudTrail, después los eventos de datos o los registros de acceso de S3, los VPC Flow Logs, los hallazgos de GuardDuty y el informe de credenciales de IAM). Delimite el alcance antes de limpiar: debe encontrar cada usuario de IAM, clave, relación de confianza de rol e instancia que haya creado el atacante; de lo contrario, cerrará el punto de entrada y dejará abierta la puerta trasera. El resto de esta serie profundiza en cada paso.
La mayoría de los incidentes de AWS que veo no empiezan con un zero-day. Empiezan con una credencial: una clave de acceso subida a un repositorio, una clave olvidada en los registros de CI, una contraseña de consola sin MFA o un rol que confía demasiado. Lo que viene después es notablemente constante: comprobar que la clave funciona, enumerar, crear una vía de regreso, cegar a los defensores y, por último, llevarse datos o quemar capacidad de cómputo. Esa constancia es una buena noticia para quien responde, porque cada paso deja una llamada a la API concreta en CloudTrail.
Minuto cero: señales de que una cuenta de AWS está comprometida
El detonante suele ser uno de estos:
| Señal | Dónde aparece | Qué suele significar |
|---|---|---|
| Factura inesperada o alerta de anomalía de costes | Facturación / Cost Explorer | Instancias GPU o de gran tamaño lanzadas para minería de criptomonedas |
| Correo de AWS sobre una clave expuesta | Buzón de la cuenta raíz, caso de soporte | Clave encontrada en un lugar público; AWS puede asociar una política de cuarentena |
Hallazgo de GuardDuty como PenTest:IAMUser/KaliLinux o UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS | Consola de GuardDuty o hallazgos exportados | Credenciales usadas desde la máquina de un atacante |
| Usuarios, claves o roles de IAM que nadie reconoce | Consola de IAM, informe de credenciales | La persistencia ya está implantada |
| Trail de CloudTrail detenido, detector de GuardDuty desaparecido | Estado de CloudTrail / GuardDuty | Evasión de defensas: el atacante ya ha superado la fase de reconocimiento |
AWS documenta los tipos de hallazgos de IAM de GuardDuty y publica una política administrada, AWSCompromisedKeyQuarantineV3, que puede asociar a un usuario de IAM cuya clave considera expuesta. Si encuentra esa política asociada a un usuario, tiene una filtración confirmada: no la quite y siga el caso de soporte.
Primera hora: contener sin destruir evidencias
La contención y la conservación de evidencias solo tiran en direcciones opuestas si se actúa con descuido. El orden que funciona:
- Asegure los registros de los que depende. Descargue los objetos de CloudTrail del periodo desde el bucket del trail, exporte los hallazgos de GuardDuty y genere el informe de credenciales de IAM. Si el atacante tiene permisos de administrador, puede eliminar trails y detectores; el historial de eventos solo conserva 90 días de eventos de administración por región. La guía de exportación de registros recoge los comandos exactos.
- Desactive las credenciales que sabe que están comprometidas. Para la clave de un usuario de IAM:
aws iam update-access-key --status Inactive. Para la sesión de un rol, use la opción «Revoke active sessions» de la consola de IAM, que añade una denegación para los tokens emitidos antes de ese momento (documentación de AWS). - No elimine lo que no haya examinado. Al eliminar un usuario creado por el atacante también se eliminan sus políticas insertadas y sus claves, que le interesa conservar en el expediente. Desasocie, desactive y elimine solo después de delimitar el alcance.
- Frene la sangría de costes. Cree instantáneas y detenga o termine las instancias no autorizadas, en todas las regiones.
- Abra un caso de soporte con AWS. Tanto las indicaciones de re:Post sobre actividad no autorizada como el playbook de credenciales comprometidas de aws-samples recomiendan avisar a AWS cuanto antes.
Delimitar el alcance: leer el ataque en CloudTrail
Delimitar el alcance consiste en responder a cuatro preguntas, cada una con un pivote en CloudTrail:
- ¿Qué credencial entró primero? Pivote sobre
userIdentity.accessKeyIdysourceIPAddress. Una clave de acceso de larga duración (prefijoAKIA) usada de repente desde una dirección ajena a su historial es el patrón clásico de clave filtrada. Empiece por la investigación de una clave de acceso filtrada. - ¿Qué averiguó? Una llamada a
GetCallerIdentityseguida de decenas de llamadasList*,Describe*yGet*en pocos minutos, a menudo con erroresAccessDenied, es enumeración. - ¿Qué creó?
CreateUser,CreateAccessKey,CreateLoginProfile,AttachUserPolicy,UpdateAssumeRolePolicy, nuevos proveedores SAML/OIDC, pares de claves, funciones Lambda. El artículo sobre persistencia en IAM analiza cada uno. - ¿Qué tocó? Lecturas de objetos de S3 (solo visibles con eventos de datos o registros de acceso al servidor), instantáneas compartidas con otras cuentas, secretos leídos, instancias lanzadas.
El artículo sobre los eventos de CloudTrail que todo analista de respuesta debe conocer ofrece la lista completa con su correspondencia en MITRE ATT&CK. El objetivo en esta fase es una cronología: cada acción del atacante, en orden, con el principal, la clave, la IP y el recurso implicados.
Los pivotes que importan
| Pivote | Campo de CloudTrail | Por qué |
|---|---|---|
| Clave de acceso | userIdentity.accessKeyId | Sigue una misma credencial a través de servicios y regiones |
| Principal | userIdentity.arn | Detecta la actividad de los usuarios creados por el atacante |
| IP de origen | sourceIPAddress | Encuentra todas las credenciales usadas desde el equipo del atacante |
| Agente de usuario | userAgent | Kali, Pacu o versiones de SDK inusuales llaman la atención |
| Región | awsRegion | A los atacantes les gustan las regiones que nadie vigila |
| Errores | errorCode | El sondeo deja rastros de AccessDenied |
Siga pivotando hasta que los pivotes dejen de producir entidades nuevas. La IP del atacante le llevará a una segunda clave; la segunda clave, a un usuario; el usuario, a un rol que asumió.
Delimitar el alcance más allá de CloudTrail
Los eventos de administración de CloudTrail le dicen qué se configuró. No le dicen qué objetos se leyeron ni cuántos bytes salieron de una VPC. Para eso necesita las evidencias de datos de S3 y el análisis de VPC Flow Logs. Si esas fuentes nunca se habilitaron, indíquelo en el informe en lugar de concluir que no se llevaron nada: antes de redactar cualquier conclusión, conviene leer sobre los límites de una investigación basada solo en registros.
Si la vía de entrada no fue una credencial de AWS sino una identidad federada, las evidencias empiezan en el proveedor de identidad: un inicio de sesión a través de Okta se investiga mejor con oktaforensics.com, y una clave filtrada desde un repositorio, con githubforensics.com. En el caso de cargas de trabajo de EKS comprometidas, el registro de auditoría de Kubernetes importa tanto como CloudTrail (kubernetesforensics.com).
Erradicación: eliminar todos los puntos de apoyo
Cuando la cronología sea estable, limpie en este orden:
- Desactive y después elimine todas las claves de acceso creadas durante el incidente.
- Elimine los usuarios de IAM creados por el atacante (después de guardar sus políticas), los perfiles de inicio de sesión y los dispositivos MFA.
- Desasocie las políticas de administrador concedidas durante el incidente y revise quién más las tiene.
- Revierta los cambios en las políticas de confianza de los roles y elimine los proveedores de identidad desconocidos.
- Elimine los permisos públicos de Lambda, las URL de función sin autenticación, los pares de claves de EC2 y los datos de usuario modificados.
- Vuelva a habilitar CloudTrail, GuardDuty, Config y cualquier servicio de seguridad que el atacante haya desactivado, en todas las regiones.
- Rote todos los secretos que el atacante haya podido leer.
Si utiliza AWS Organizations, plantéese una política de control de servicios que deniegue las regiones que no usa: elimina el escondite favorito del atacante.
Qué papel desempeña la herramienta
AWS Forensics ejecuta esta fase de delimitación en su navegador. Suelte los archivos de CloudTrail exportados (y, si los tiene, los flow logs, los registros de acceso de S3, los hallazgos de GuardDuty y el informe de credenciales) y obtendrá un veredicto —«Ningún indicio de compromiso en estos registros», «Actividad sospechosa: requiere revisión» o «Indicios de compromiso»— con los hallazgos, las filas de evidencia en las que se basa cada uno, una cronología y una lista de remediación ordenada empezando por la contención. No se sube nada. La guía de análisis paso a paso muestra el flujo de trabajo, y el recorrido por un incidente ficticio lo aplica de principio a fin sobre los datos de ejemplo.
El veredicto es una ayuda para el triaje, no una conclusión. Solo es tan fiable como los registros que le proporcione, y cada hallazgo muestra sus evidencias para que pueda confirmarlo o descartarlo.
Preguntas frecuentes
¿Cómo sé si mi cuenta de AWS se ha visto comprometida?
Busque en CloudTrail llamadas a la API que no pueda atribuir: una clave de acceso de larga duración usada desde una dirección IP desconocida, usuarios o claves de IAM que nadie ha creado, GuardDuty o CloudTrail desactivados, instancias en regiones que nunca utiliza o descargas masivas de S3. Un pico en la factura o un hallazgo de GuardDuty suelen ser la primera señal visible.
¿Debo eliminar de inmediato la clave de acceso comprometida?
Desactívela primero en lugar de eliminarla. Una clave inactiva ya no puede firmar solicitudes, pero sigue existiendo, lo que simplifica la investigación. Elimínela cuando haya delimitado lo que hizo y la haya sustituido en todos los lugares donde se usaba legítimamente.
¿Tengo que ponerme en contacto con AWS?
AWS pide a sus clientes que abran un caso de soporte cuando sospechen que hay credenciales comprometidas, y es la vía para plantear dudas sobre cargos no autorizados. El caso de soporte no sustituye a su propia investigación de CloudTrail.
Lecturas recomendadas
- AWS Security Incident Response Guide: el proceso de respuesta a incidentes de la propia AWS.
- Remediating potentially compromised AWS credentials: documentación de GuardDuty.
- Incident response guide for AWS CloudTrail investigations: AWS Security Blog.
- Matriz IaaS de MITRE ATT&CK: las técnicas a las que se hace referencia a lo largo de esta serie.