Cómo investigar una clave de acceso de AWS filtrada
Clave de acceso de AWS filtrada: desactívela y use CloudTrail para ver dónde se usó, qué enumeró, qué creó y a qué datos pudo acceder el atacante con ella.
En resumen. 1) Desactive la clave (aws iam update-access-key --status Inactive); no la elimine todavía. 2) Extraiga todos los eventos de CloudTrail en los que userIdentity.accessKeyId sea la clave, desde bastante antes de la filtración hasta ahora. 3) Localice el primer uso desde una IP nueva: es la entrada del atacante. 4) A partir de ahí, enumere lo que la clave exploró, lo que creó (usuarios, claves, contraseñas, políticas, instancias) y a qué datos pudo acceder. 5) Pivote sobre la IP del atacante para detectar otras credenciales. Remedie todo lo que la clave creó, no solo la clave.
Las claves de acceso de larga duración, cuyo ID empieza por AKIA (referencia de identificadores de IAM), no caducan. Cuando una acaba en un repositorio público, en un registro de CI, en una capa de una imagen de Docker o pegada en un ticket de soporte, quien la encuentre dispone de los permisos de su usuario hasta que alguien se dé cuenta. La investigación consiste en responder a la pregunta «¿qué hicieron con ella?» con la precisión suficiente para deshacerlo todo.
Paso 0: desactivar, no eliminar
aws iam update-access-key --user-name <user> --access-key-id AKIA... --status Inactive
Una clave inactiva ya no puede autenticarse. Conservarla (inactiva) en lugar de eliminarla hace que su ID siga visible en IAM y en el informe de credenciales mientras investiga. Antes de desactivarla, averigüe qué la usa legítimamente: un proceso de producción que falla a las 3 de la madrugada es un coste que conviene conocer de antemano, no un motivo para esperar.
Compruebe si AWS ya ha reaccionado: si el usuario tiene asociada la política AWSCompromisedKeyQuarantineV3, AWS detectó la exposición y abrió un caso de soporte. La política deniega una lista de acciones de alto riesgo (iam:CreateUser, iam:CreateAccessKey, ec2:RunInstances y otras); un atacante que actuara antes de que se asociara puede haber tenido éxito de todos modos.
Si la clave se filtró desde un repositorio de GitHub, el registro de auditoría del propio repositorio (quién la subió, cuándo, si el repositorio era público) es una investigación aparte; githubforensics.com cubre esa parte.
Paso 1: obtener el historial completo de la clave
Si tiene un trail, filtre los archivos exportados por la clave. Con jq sobre una carpeta de archivos descomprimidos:
zcat cloudtrail/**/*.json.gz | jq -c '.Records[]
| select(.userIdentity.accessKeyId == "AKIA...")
| [.eventTime, .sourceIPAddress, .eventSource, .eventName, (.errorCode // "")]'
Sin trail, el historial de eventos permite buscar por clave (por región):
aws cloudtrail lookup-events --region us-east-1 \
--lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA...
Las columnas access_key_1_last_used_date, _region y _service del informe de credenciales sirven como comprobación rápida, pero solo registran el primer uso de cada intervalo de 15 minutos (documentación de IAM). La fuente de referencia es CloudTrail.
Paso 2: encontrar el primer uso malicioso
Agrupe los eventos de la clave por sourceIPAddress y userAgent. El uso legítimo se concentra en unos pocos valores: la salida a internet de la oficina, el rango de un runner de CI, la versión de la CLI del desarrollador. El atacante aparece como:
- una dirección nueva (a menudo un VPS o un proveedor de alojamiento),
- un agente de usuario distinto: otro sistema operativo, un SDK más antiguo y, a veces, una pista evidente, como la cadena de compilación de Kali,
- una llamada a
GetCallerIdentitycomo primerísima solicitud. No requiere permisos (referencia de la API de STS), así que es la comprobación universal de «¿funciona esta clave y de quién es?».
La detección «Clave de acceso de larga duración usada desde una IP nueva» del analizador lo automatiza: aprende las direcciones de la clave durante su primer día en los registros y señala el uso posterior desde una dirección pública ajena a ese conjunto. Su valor depende de la línea base, así que cargue unos cuantos días anteriores a la supuesta filtración.
Paso 3: ¿qué enumeró?
Los atacantes cartografían los permisos muy deprisa. En CloudTrail esto se ve como una ráfaga de decenas de llamadas List*, Describe* y Get* distintas sobre IAM, S3, EC2, Lambda, Secrets Manager y otros servicios en cuestión de minutos, a menudo mezcladas con errores AccessDenied allí donde la clave no tiene permisos. GetAccountAuthorizationDetails es un objetivo muy valioso: devuelve todos los usuarios, roles, grupos y políticas en una sola llamada.
| Patrón | Evidencia | ATT&CK |
|---|---|---|
| Comprobación de validez de la clave | sts:GetCallerIdentity desde una IP nueva | T1087.004 |
| Enumeración de servicios | Más de 30 List/Describe/Get distintos en 10 min | T1580, T1526 |
| Sondeo de permisos | Ráfaga de AccessDenied / UnauthorizedOperation | T1069.003 |
| Herramientas ofensivas | userAgent que contiene Kali, Pacu, CloudFox… | T1078.004 |
Las llamadas fallidas importan: muestran lo que el atacante quería, y eso le indica qué debe proteger a continuación.
Paso 4: ¿qué creó?
Aquí es donde más a menudo fracasan las investigaciones. Busque todas las escrituras que tuvieron éxito:
CreateUser,CreateLoginProfile,CreateAccessKey(sobre todo para otro usuario),AttachUserPolicy/PutUserPolicycon permisos de administrador;UpdateAssumeRolePolicy,CreateSAMLProvider,CreateOpenIDConnectProvider;RunInstances,CreateKeyPair,ImportKeyPair,AuthorizeSecurityGroupIngress;CreateFunction,AddPermission,CreateFunctionUrlConfig.
Los responseElements de CreateAccessKey contienen el ID de la nueva clave: su siguiente pivote. El artículo sobre persistencia en IAM y escalada de privilegios describe cada técnica.
Paso 5: ¿a qué datos pudo acceder?
Los eventos de administración muestran ListBuckets y GetBucketPolicy, no las lecturas de objetos. Para saber si se descargaron objetos necesita los eventos de datos de S3 o los registros de acceso al servidor; consulte las evidencias de exfiltración de datos de S3. Revise también GetSecretValue, GetParametersByPath, ModifySnapshotAttribute (compartir una instantánea con otra cuenta) y GetPasswordData.
Paso 6: pivotar sobre la IP del atacante
Pivote sobre cada dirección del atacante en todos los principales. A menudo encontrará la nueva clave del usuario de puerta trasera, un inicio de sesión en la consola de un usuario creado o una sesión de rol asumido: actividad que ya no lleva el ID de la clave filtrada.
Lista de remediación para una clave filtrada
- Clave filtrada: inactiva ya, eliminada tras delimitar el alcance; retírela del código, de las variables de CI, de las imágenes y del historial.
- Todas las claves creadas durante el incidente: desactívelas y después elimínelas.
- Usuarios, perfiles de inicio de sesión, pertenencias a grupos y políticas creados o asociados por el atacante: guárdelos y después elimínelos.
- Políticas de confianza de roles y proveedores de identidad modificados: reviértalos.
- Instancias, pares de claves, reglas de grupos de seguridad y funciones Lambda en todas las regiones: cree instantáneas si es necesario y después elimínelos.
- Secretos que el atacante haya leído: rótelos.
- Servicios de registro y detección desactivados: vuelva a habilitarlos (artículo sobre evasión de defensas).
Suelte el historial de CloudTrail de la clave en el analizador para obtener esta lista ya rellenada con los ID de clave, los usuarios y las regiones reales de sus registros. Para tener la visión de toda la cuenta, vuelva a la visión general de la respuesta a incidentes en AWS.
Preguntas frecuentes
¿Puedo ver qué direcciones IP usaron una clave de acceso de AWS filtrada?
Sí. Cada evento de CloudTrail firmado con la clave la incluye en userIdentity.accessKeyId, y la dirección de quien hizo la llamada, en sourceIPAddress. Filtre por la clave y enumere las direcciones distintas; si no tiene trail, el historial de eventos cubre los últimos 90 días de eventos de administración.
¿Una llamada a GetCallerIdentity demuestra que se robó una clave?
No. La AWS CLI y los SDK la invocan de forma rutinaria y no requiere ningún permiso. Adquiere relevancia cuando es la primera llamada desde una dirección que la clave nunca ha usado, sobre todo si le sigue una enumeración en cuestión de minutos.
¿Desactivar la clave detiene al atacante?
Detiene esa clave. No detiene las credenciales que el atacante creó con ella: otras claves de acceso, contraseñas de consola, usuarios, cambios en la confianza de los roles. Esas se encuentran delimitando la actividad de la clave en CloudTrail.