pathfinding_labs_aws

Pathfinding Labs: el “parque de atracciones” en AWS Security

Hace tiempo que no encontraba un proyecto open source tan útil para practicar seguridad cloud de forma realista. Esta semana descubrí Pathfinding Labs, un framework creado por el equipo de seguridad de Datadog que despliega entornos AWS intencionadamente vulnerables para practicar ataques, validar detecciones y entender cómo se producen realmente los movimientos laterales y las escaladas de privilegios en la nube.

Y sinceramente, me parece una de las mejores ideas que han salido últimamente para cualquiera que trabaje en cloud security, red teaming, CSPM o hardening de AWS.

¿Qué es exactamente Pathfinding Labs?

El proyecto gira alrededor de más de 100 laboratorios desplegables en AWS que recrean configuraciones inseguras reales:

  • Escaladas de privilegios IAM
  • Roles excesivamente permisivos
  • Lambdas públicas con privilegios administrativos
  • Buckets S3 expuestos
  • Chains multi-hop entre cuentas
  • Toxic combinations de servicios AWS

La idea es sencilla pero potente:

  1. Despliegas un entorno vulnerable en una cuenta sandbox.
  2. Lo explotas manualmente o con scripts automatizados.
  3. Validas si tus herramientas CSPM/SIEM detectan el problema.
  4. Destruyes todo cuando terminas.

Todo automatizado.

How Pathfinding Labs works: blue team and red team workflows from enabling labs to cleanup

Lo interesante: no es teoría, es práctica real

Lo que más me llamó la atención es que esto no es una colección de “ejemplos académicos”.

Cada laboratorio:

  • despliega recursos reales en AWS,
  • crea permisos IAM funcionales,
  • incluye scripts de explotación,
  • y valida que el ataque funciona de verdad.

Eso elimina muchísimo “falso positivo mental” que vemos a veces en artículos de seguridad cloud donde algo parece explotable… hasta que intentas hacerlo.

Aquí cada path está probado.

La filosofía detrás del proyecto me parece brillante

El proyecto nace de otro recurso muy interesante llamado pathfinding.cloud, un catálogo de técnicas de privilege escalation en AWS.

Pero los autores dieron un paso más:

“No queremos publicar paths teóricos. Queremos demostrar que funcionan.”

Así que empezaron creando laboratorios Terraform para validar cada técnica documentada.

Y acabaron construyendo un ecosistema completo de labs reutilizables.

El workflow es absurdamente cómodo

Han creado una CLI llamada plabs que abstrae Terraform completamente.

El flujo típico es algo así:

plabs init
plabs

Eso abre una TUI interactiva donde puedes activar laboratorios con el teclado.

Después:

plabs apply

Y automáticamente despliega los entornos vulnerables.

Cuando quieras probar el ataque:

plabs demo iam-002-iam-createaccesskey

Y el propio framework ejecuta la explotación paso a paso.

Finalmente:

plabs destroy

Y limpia todos los recursos.

Algunos escenarios son especialmente buenos

Hay laboratorios bastante realistas y muy útiles para equipos cloud security:

Escaladas IAM clásicas

Por ejemplo:

  • iam:CreateAccessKey
  • iam:PassRole
  • lambda:UpdateFunctionCode
  • ssm:SendCommand

Escenarios que muchísima gente subestima en auditorías AWS.

Multi-hop attacks

Aquí es donde el proyecto se pone realmente interesante.

No se limitan a:

“usuario A puede asumir rol B”.

También modelan cadenas completas:

User → RoleA → RoleB → AdminRole

O movimientos laterales entre cuentas AWS distintas.

Eso se acerca muchísimo más a cómo funcionan los ataques cloud reales.

“Attackers think in graphs”

Hay una frase de John Lambert que mencionan y que define perfectamente el problema:

“Defenders think in lists. Attackers think in graphs.”

Y es totalmente cierto en cloud.

Muchos equipos siguen viendo permisos IAM de forma aislada:

  • “este rol parece seguro”
  • “esta Lambda no tiene admin”
  • “este bucket no es público”

Pero cuando conectas relaciones:

  • AssumeRole
  • PassRole
  • Lambda invoke
  • STS chaining
  • Resource policies

…aparecen caminos completos hacia privilegios críticos.

Ese enfoque “graph-based” es probablemente la parte más valiosa de todo el proyecto.

También sirve para validar herramientas CSPM

Esto me parece especialmente potente para empresas.

Puedes usar los labs para responder preguntas reales:

  • ¿Mi CSPM detecta esta mala configuración?
  • ¿Mi SIEM genera alertas?
  • ¿Mi graph engine reconstruye el path completo?
  • ¿Mi equipo detectaría esto en producción?

En otras palabras: no solo practicas explotación.

También puedes validar controles defensivos de manera reproducible.

Todo está hecho pensando en entornos aislados

Y aquí viene la advertencia importante.

Estos labs crean cosas deliberadamente peligrosas:

  • usuarios admin,
  • buckets públicos,
  • Lambdas expuestas a Internet,
  • security groups abiertos,
  • roles excesivamente permisivos.

NO están pensados para cuentas reales.

De hecho, los propios autores insisten constantemente en:

  • usar cuentas sandbox,
  • preferiblemente organizaciones AWS separadas,
  • activar billing alerts,
  • y destruir recursos cuando termines.

Me parece una decisión acertada porque el proyecto intenta ser útil sin minimizar el riesgo.

Supported lab types: self-escalation, one-hop, multi-hop, cross-account, misconfig labs, and toxic combination labs

Instalación rápida

La instalación es bastante sencilla.

Con Go:

go install -v github.com/DataDog/pathfinding-labs/cmd/plabs@latest

Con Homebrew:

brew tap DataDog/pathfinding-labs https://github.com/DataDog/pathfinding-labs
brew install DataDog/pathfinding-labs/plabs

Después:

plabs init

Y el asistente configura perfiles AWS y Terraform automáticamente.

Lo mejor: es open source

El repositorio está aquí: https://github.com/DataDog/pathfinding-labs

Y el catálogo web aquí: https://pathfinding.cloud/labs

Mi impresión

Sinceramente, creo que este proyecto puede convertirse en una referencia para entrenamiento práctico en seguridad cloud AWS.

Especialmente porque cubre un hueco que hasta ahora estaba muy fragmentado:

  • teoría IAM,
  • privilege escalation,
  • CSPM validation,
  • graph security,
  • attack simulation.

Todo unido en un mismo framework.

Si trabajas en:

  • cloud security,
  • offensive security,
  • detección,
  • IAM hardening,
  • o arquitectura AWS,

merece muchísimo la pena dedicarle unas horas.

Porque pocas cosas enseñan tanto como explotar tú mismo una mala configuración que podrías tener mañana en producción.

De una credencial olvidada al control total: cómo se materializan los ataques en cloud

Existe una percepción errónea en muchos entornos cloud: que las brechas graves requieren técnicas avanzadas o vulnerabilidades complejas. La realidad es mucho más incómoda.

En numerosos incidentes recientes, el punto de entrada no ha sido un exploit sofisticado, sino un fallo básico de higiene de seguridad. Un ejemplo claro: una simple credencial expuesta terminó permitiendo el control completo de una cuenta en Amazon Web Services en cuestión de minutos. Este tipo de escenarios pone de manifiesto una característica clave del cloud moderno: la velocidad a la que los errores escalan.

El problema no fue el acceso inicial, sino lo que permitió

Todo comenzó con unas claves accesibles públicamente en un recurso de almacenamiento de Amazon S3.

A primera vista, el impacto parecía limitado. Sin embargo, incluso permisos aparentemente inofensivos pueden proporcionar suficiente información para iniciar un reconocimiento efectivo del entorno.

Una vez dentro, el atacante no necesitó explotar vulnerabilidades adicionales. Simplemente aprovechó lo que ya estaba disponible:

  • Capacidades existentes en funciones de AWS Lambda
  • Configuración de identidades en AWS Identity and Access Management
  • Permisos mal ajustados entre roles

El resultado fue una escalada progresiva hasta privilegios administrativos.

El verdadero riesgo: credenciales persistentes fuera de control

El uso indebido de claves de acceso sigue siendo uno de los vectores más recurrentes en incidentes cloud.

No se trata de un problema técnico complejo, sino de procesos:

  • Credenciales que se mantienen más tiempo del necesario
  • Uso de claves en automatizaciones sin controles adecuados
  • Exposición accidental en repositorios o entornos compartidos
  • Almacenamiento temporal que nunca se limpia

En paralelo, los atacantes han automatizado completamente la detección de este tipo de errores. No buscan activamente a una organización concreta: escanean de forma continua hasta encontrar algo utilizable.

Y cuando lo encuentran, el tiempo de reacción es mínimo.

De visibilidad a explotación en minutos

Uno de los aspectos más críticos en este tipo de incidentes es la rapidez con la que se encadenan los eventos.

El acceso inicial rara vez es el objetivo final. Es solo el punto de partida.

A partir de ahí, el atacante suele:

  • Identificar relaciones entre identidades
  • Detectar permisos indirectos o heredados
  • Aprovechar servicios existentes para ampliar capacidades
  • Expandirse lateralmente dentro del entorno

En plataformas como Amazon Web Services, donde todo está diseñado para ser flexible y escalable, esta progresión puede producirse sin fricción.

Cuando los límites entre identidades no están bien definidos, la infraestructura juega a favor del atacante.

Cuando la cuenta deja de ser un objetivo y se convierte en un recurso

Una vez conseguido el control administrativo, el impacto va más allá del acceso a datos.

En muchos casos, el atacante reutiliza la propia infraestructura comprometida:

  • Despliegue de recursos de computación intensiva
  • Uso de servicios avanzados como Amazon Bedrock
  • Ejecución de cargas con fines económicos

Esto refleja un cambio importante en el panorama de amenazas: el cloud ya no es solo un repositorio de información, sino un activo explotable en sí mismo.

El valor está tanto en los datos como en la capacidad de cómputo.

Por qué los errores simples ya no pasan desapercibidos

En entornos tradicionales, muchas configuraciones inseguras permanecían ocultas durante largos periodos.

Hoy, eso prácticamente no existe.

Los atacantes operan con herramientas que analizan continuamente:

  • Recursos expuestos
  • Políticas permisivas
  • Credenciales activas
  • Configuraciones inconsistentes

Esto convierte cualquier fallo en una superficie de ataque activa desde el momento en que aparece.

El problema no es solo cometer el error, sino el tiempo que permanece sin detectarse.

La seguridad cloud necesita cambiar de enfoque

Los modelos basados en revisiones periódicas o auditorías puntuales ya no son suficientes.

La defensa efectiva en cloud requiere:

  • Evaluación continua del estado de seguridad
  • Control estricto sobre identidades y permisos
  • Monitorización en tiempo real
  • Capacidad de detectar comportamientos anómalos rápidamente

Especialmente relevante es entender qué ocurre después del acceso inicial. Muchas organizaciones siguen centradas en prevenir la entrada, pero no en detectar el abuso una vez dentro.

Recomendaciones clave para reducir el riesgo

Aunque cada entorno es distinto, hay principios que se repiten en todos los incidentes de este tipo:

  • Evitar completamente el uso de credenciales en recursos públicos
  • Sustituir claves persistentes por credenciales temporales
  • Revisar continuamente los permisos efectivos de cada identidad
  • Implementar monitorización activa del uso de credenciales
  • Detectar cambios inesperados en roles y políticas
  • Tratar las identidades como el principal perímetro de seguridad

Estas prácticas no eliminan el riesgo, pero sí dificultan enormemente la escalada.

Reflexión final

Este tipo de incidentes no destacan por su sofisticación, sino por su previsibilidad.

Un pequeño descuido (una credencial olvidada, un permiso mal configurado) puede convertirse en la puerta de entrada a un compromiso total.

La diferencia entre un incidente menor y una brecha crítica no suele estar en el acceso inicial, sino en la capacidad de detectar y frenar lo que ocurre después.

En el contexto actual, donde la automatización juega tanto a favor de los equipos de seguridad como de los atacantes, el tiempo se ha convertido en el factor decisivo.

Y en cloud, ese tiempo se mide en minutos.

aws_security

8 Recomendaciones básicas para mejorar la seguridad de tu cuenta AWS

En el día a día de mi trabajo dentro del equipo de Cloud Security de Accenture Security, una de las tareas principales es la de promover e implantar la mejor solución de seguridad dentro de los entornos cloud de nuestros clientes.

Lo hacemos con Azure, con Google Cloud Platform y con (mi favorita :D) AWS. Como Security Lead dentro del grupo de trabajo AABG (Accenture & AWS Business Group), trato de estar al día de las recomendaciones de seguridad y buenas prácticas del proveedor para poder ofrecerlas a los clientes en los diferentes proyectos en los que participo.

Como podrás entender, hay muchas opciones de configuración, controles y recomendaciones que, sumados a la automatización que permiten los proveedores, hacen de la gestión de la Seguridad Cloud algo fascinante.

Sin embargo, en un nivel más «de andar por casa», tengo cantidad de amigos que tienen sus cuentas AWS para aprender, probar cosas e incluso mantener algún proyecto personal (este blog que lees está 100% sobre mi cuenta de AWS). Si eres una de esas personas que arrancan con AWS, te dejo un listado con las recomendaciones básicas y habituales que debes tener en cuenta para que la primera experiencia cloud no se te vaya de las manos.

Ten actualizada tu información de contacto

No pierdas el acceso a tu cuenta, asegúrate de usar un mail de contacto válido al que tengas acceso y que revises de forma habitual. Presta atención a las notificaciones de seguridad de los correos electrónicos de Amazon (como abuse@amazon.com).

Validar Roles IAM

Con el tiempo, puedes descubrir que los usuarios y roles de IAM ya no son necesarios, o que sus permisos se han ampliado más allá de lo que deberían. Revisa el acceso a tus recursos internos de AWS y determina dónde tienes acceso compartido fuera de tus cuentas de AWS. También recuerda no utilizar usuario root, crea con él un primer usuario administrador y usa ese para continuar a partir de ahí.

Utilizar la autenticación (MFA)

Configura siempre el MFA en tu usuario raíz y en los usuarios de AWS Identity and Access Management (IAM) para proporcionar una capa adicional de protección contra el acceso inapropiado.

Rota tus claves

Evita utilizar claves de acceso a AWS a largo plazo. En su lugar, utiliza roles IAM y la federación. Si necesitas utilizar claves de acceso en lugar de roles, rótalas regularmente. Puede utilizar AWS Security Hub para buscar usuarios de IAM con claves de acceso de larga duración.

No hay que codificar secretos

Utilice las funciones de IAM para proporcionar credenciales temporales para utilizar los servicios de AWS. Cuando necesite credenciales de larga duración, no codifique estos secretos en la aplicación ni los almacene en el código fuente. En su lugar, utilice AWS Secrets Manager para rotar, administrar y recuperar credenciales de base de datos, claves de API y otros secretos a lo largo de su ciclo de vida.

Limitar AWS grupos de seguridad

Puede utilizar los grupos de seguridad de AWS para limitar las comunicaciones entre sus recursos de AWS y con Internet. Esto puede lograrse permitiendo sólo los puertos mínimamente necesarios, y con fuentes y destinos de confianza. Puede utilizar servicios como AWS Firewall Manager y AWS Config para implementar y monitorizar las configuraciones de de seguridad de AWS.
También puede utilizar AWS Firewall Manager para proteger los recursos los recursos de cara a Internet aplicando aplicando las reglas de AWS WAF y implementando AWS Shield Advanced.

Centraliza los registros de AWS CloudTrail

Los registros y la monitorización son partes importantes de un plan de seguridad sólido. Poder investigar cambios inesperados en su entorno o iterar sobre su postura de seguridad se basa en tener acceso a los datos. Le recomendamos que escriba los registros en un cubo de Amazon Simple Storage Service (Amazon S3) en una cuenta de AWS designada para el registro. Los permisos del cubo deben impedir que se borren los registros, y estos registros deben estar encriptados en reposo.

Toma medidas sobre los resultados

AWS Security Hub, Amazon GuardDuty, Amazon Macie, Amazon Inspector y AWS IAM Access Analyzer le proporcionan hallazgos procesables en sus cuentas de AWS. Actúe sobre estos hallazgos basándose en su política de respuesta a incidentes. Y para mitigar mejor el alcance y el impacto de un evento, puede automatizar respuestas para contener más rápidamente la actividad sospechosa y notificar a los humanos para que tomen conciencia.

Si quieres saber más, no te pierdas el resto de entradas relacionadas con Cloud Security!

SecurityInside Live: CISO Day 2020

Todos sabemos la importancia del flujo de información dentro de una industria tan cambiante y retadora como la de la ciberseguridad. Si eres CISO, CIO, responsable de ciberseguridad, experto en la materia, investigador o hacker… serás bienvenido a CISO Day 2020, un evento centrado en el responsable de la ciberseguridad corporativa.

Si recuerdas, ya hemos hablado en este blog otras veces de la importancia del CISO, en este evento se profundiza en su importancia desde varios puntos de vista.

CISO DAY 2020 basa su agenda en 6 niveles fundamentales de la ciberseguridad: Estratégico (CISO), Analítico (Ciberinteligencia), Institucional (INCIBE), Innovador (CyberStartup), Security (Proveedores) y Técnico (Hacking).

En este enlace tienes toda la información que necesitas sobre la agenda y en este sobre los ponentes que van a dar las charlas.

Y no olvides que, si no puedes ir y lo quieres ver, tienes acceso al streaming. Si no lo ves es porque no quieres 😀

Leer más

SID2020

SecurityInside Live: Día de Internet Segura 2020

El Día de Internet Segura, “Safer Internet Day” (SID, por sus siglas en inglés) es un evento promovido por la red INSAFE/INHOPE con el apoyo de la Comisión Europea, que se celebra cada mes de febrero con el objetivo de promover un uso seguro y positivo de las tecnologías digitales, especialmente entre niños y jóvenes. El SID se celebra el segundo día de la segunda semana del segundo mes del año y reúne a millones de personas de todo el mundo para impulsar cambios positivos y concienciar acerca de la seguridad en Internet, organizando distintos eventos y actividades.

Leer más