El cloud credential harvesting (recolección de credenciales en la nube) es el proceso por el que un atacante consigue, a escala, usuarios/contraseñas, tokens de sesión y claves de API para convertir un incidente “de identidad” en acceso real a entornos cloud. En empresa, el problema rara vez es una sola credencial filtrada: suele ser una cadena que mezcla endpoints corporativos, integraciones CI/CD, permisos IAM amplios y falta de detección temprana.
La consecuencia operativa es clara: si el atacante obtiene un token o una clave con permisos suficientes, puede actuar como un usuario legítimo, con trazas confusas y con capacidad de automatizar acciones (enumeración, descubrimiento de secretos, escalada y exfiltración). Lo que sigue es una guía orientada a operación y respuesta, con foco exclusivo en harvesting de credenciales cloud.
Superficie de ataque real: dónde se cosechan credenciales en la nube
En entornos corporativos modernos, el harvesting no se limita al clásico phishing de contraseña. Lo que más se ve en incidentes es la recolección de material de autenticación reutilizable: tokens de sesión, refresh tokens, claves API en repositorios, variables de entorno en pipelines, ficheros de configuración en estaciones de trabajo y credenciales embebidas en imágenes o artefactos.
Un patrón frecuente: un desarrollador configura una herramienta de línea de comandos en su portátil para operar en cloud, la máquina se compromete (malware, infostealer o acceso remoto), y el atacante extrae el directorio de credenciales o el cache de sesiones. No necesita “romper” IAM; le basta con usar credenciales válidas. El resultado típico en empresa es acceso a buckets, colas, registros o funciones serverless desde una IP “nueva”, pero con identidad “conocida”.
Otro punto de cosecha corporativo son los sistemas de automatización: runners de CI/CD con secretos mal segregados, logs que imprimen variables sensibles, o jobs que asumen roles demasiado amplios para “evitar fricción”. Cuando el atacante obtiene el secreto del pipeline, se salta el endpoint humano y entra directo a la cuenta cloud.
Escenarios de abuso tras el harvesting: de una clave a control operativo
La diferencia entre un incidente “molesto” y uno crítico suele ser el perímetro de permisos de la credencial cosechada. Con una clave de API de un usuario con privilegios, el atacante puede crear nuevas identidades, generar nuevas claves y establecer persistencia. Con un token de sesión de un rol operativo, puede enumerar recursos, extraer datos o modificar configuraciones sin necesidad de elevar privilegios.
En empresa, el impacto suele aterrizar en tres frentes: interrupción de servicio por cambios de configuración, fuga de datos por acceso a almacenamiento/analytics, y costes por abuso de recursos (minería, despliegues masivos, transferencia). Lo peligroso es que muchas acciones “parecen” operaciones normales, sobre todo si no se tiene trazabilidad fuerte de identidad y contexto.
- Persistencia vía nuevas credenciales
Si el principal comprometido tiene permisos para gestionar IAM, es habitual ver creación de nuevos usuarios/roles, generación de access keys o cambios en políticas. La empresa suele detectar tarde porque el acceso inicial puede ser breve: se roba, se entra, se deja una puerta y se sale.
- Exfiltración silenciosa usando servicios legítimos
Con permisos de lectura, el atacante no necesita herramientas “raras”: listados, descargas y exportaciones a través de APIs oficiales. En la práctica, los equipos se sorprenden al ver que el incidente no activó alertas porque el tráfico era “válido” y la identidad era “correcta”.
Señales tempranas y telemetría: lo que sí cambia cuando el atacante usa credenciales válidas
Cuando el acceso se hace con credenciales reales, el reto es detectar cambios de patrón, no “fallos de login”. Hay indicadores que, bien instrumentados, suelen aparecer pronto: primeras llamadas de API desde ASN/país no habitual, creación de access keys fuera de horario, picos de enumeración (List/Describe) y fallos de autorización repetidos mientras el atacante mapea permisos.
Una señal especialmente útil es la secuencia: GetCallerIdentity (o equivalente) seguida de múltiples llamadas “Describe/List” y luego acciones de escritura o IAM. En incidentes reales, esa fase de reconocimiento ocurre en minutos. Si el SOC o el equipo cloud no tiene alertas sobre esa transición, el atacante avanza sin fricción.
- Anomalías de origen y contexto
No se trata solo de geolocalización. En entornos corporativos, es más accionable correlacionar con: IPs de salida corporativas conocidas, egress de VPN, rangos de runners, y dispositivos gestionados. Ver una credencial de pipeline usada desde una red residencial es casi siempre una mala señal.
- Eventos de IAM de alto riesgo
Creación/rotación de claves, cambios en políticas y adjuntos de permisos deben elevarse como eventos críticos, incluso si los hace un administrador. En harvesting, el atacante busca convertir un acceso temporal en persistencia; si no se vigila IAM con lupa, se normaliza lo anómalo.
Cómo hacerlo en la práctica: hardening y validación operativa para reducir el harvesting
La defensa efectiva combina reducción de exposición (menos secretos largos, menos superficies donde puedan filtrarse), limitación de blast radius (permisos mínimos, segmentación por roles/entornos) y controles de sesión (duración, condiciones, dispositivos, red). La clave es que estas medidas se puedan verificar, no solo documentar.
Acciones concretas que suelen dar resultados rápidos en empresas: forzar MFA en identidades humanas, migrar automatizaciones a credenciales efímeras (roles con asunción y sesiones cortas), y eliminar claves de larga duración donde sea viable. En paralelo, endurecer políticas para que una credencial cosechada no pueda por sí sola crear nuevas credenciales o cambiar IAM.
- Configurar políticas IAM con condiciones de origen
Cuando el caso de uso lo permite, condicionar por red de origen (rangos corporativos, NAT de VPC, egress de CI) reduce el valor de una credencial robada. Si la clave aparece fuera de esos rangos, la llamada falla aunque el secreto sea válido.
Ejemplo (AWS IAM policy) para limitar acciones a un rango corporativo:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowFromCorpEgressOnly",
"Effect": "Allow",
"Action": ["s3:ListBucket","s3:GetObject"],
"Resource": ["arn:aws:s3:::mi-bucket","arn:aws:s3:::mi-bucket/*"],
"Condition": {
"IpAddress": {"aws:SourceIp": ["203.0.113.0/24"]}
}
}
]
}
Validación: revisar en CloudTrail que las llamadas denegadas por IP quedan registradas (eventName, errorCode) y que no existen rutas “alternativas” (por ejemplo, endpoints públicos usados desde fuera) que permitan el acceso. Además, comprobar que los rangos permitidos reflejan la realidad (egress de oficinas/VPN/CI) para no forzar bypasses operativos.
- Bloquear persistencia: negar gestión de credenciales salvo roles controlados
Un error corporativo común es dar permisos amplios “por si acaso” a usuarios técnicos. Si una credencial se cosecha, el atacante intenta crear nuevas access keys o adjuntar políticas. Reducir quién puede ejecutar iam:CreateAccessKey, iam:AttachUserPolicy o iam:PutUserPolicy recorta la escalada más habitual.
Ejemplo (AWS IAM) de denegación explícita de acciones de IAM sensibles:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyIamCredentialManagement",
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey",
"iam:UpdateAccessKey",
"iam:DeleteAccessKey",
"iam:AttachUserPolicy",
"iam:PutUserPolicy",
"iam:CreateUser",
"iam:CreateLoginProfile"
],
"Resource": "*"
}
]
}
Validación: usar IAM Access Analyzer y pruebas controladas (por ejemplo, con un rol de laboratorio) para confirmar que las operaciones quedan bloqueadas y que los roles “break-glass” están segregados y auditados. Revisar también eventos de CloudTrail para detectar intentos fallidos repetidos: suelen ser la fase de reconocimiento del atacante tras el harvesting.
Recomendaciones para entornos corporativos
El cloud credential harvesting funciona porque convierte secretos reutilizables (contraseñas, tokens, claves) en operaciones legítimas dentro de la nube. En empresa, el impacto real aparece cuando esa credencial tiene permisos amplios o cuando puede usarse desde cualquier lugar sin restricciones de contexto.
Operativamente, lo que más reduce riesgo es: acortar vida y alcance de credenciales (priorizar sesiones efímeras), cerrar la puerta a la persistencia (limitar gestión de IAM y creación de nuevas credenciales) y mejorar la detección basada en patrón (origen, secuencia de APIs, eventos IAM de alto riesgo). Si estas medidas se validan con telemetría (CloudTrail/IAM Access Analyzer y pruebas controladas), el harvesting deja de ser una autopista y pasa a ser un intento ruidoso y de bajo rendimiento para el atacante.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.