AWS - Información Básica

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Jerarquía de Organización

Cuentas

En AWS, hay una cuenta raíz, que es el contenedor principal para todas las cuentas de tu organización. Sin embargo, no necesitas usar esa cuenta para desplegar recursos, puedes crear otras cuentas para separar diferentes infraestructuras de AWS entre ellas.

Esto es muy interesante desde el punto de vista de la seguridad, ya que una cuenta no podrá acceder a los recursos de otra cuenta (excepto si se crean puentes específicamente), de esta manera puedes crear límites entre los despliegues.

Por lo tanto, hay dos tipos de cuentas en una organización (estamos hablando de cuentas de AWS y no de cuentas de usuario): una única cuenta que se designa como la cuenta de gestión, y una o más cuentas miembro.

  • La cuenta de gestión (la cuenta raíz) es la cuenta que usas para crear la organización. Desde la cuenta de gestión de la organización, puedes hacer lo siguiente:

  • Crear cuentas en la organización

  • Invitar a otras cuentas existentes a la organización

  • Eliminar cuentas de la organización

  • Gestionar invitaciones

  • Aplicar políticas a entidades (raíces, OUs o cuentas) dentro de la organización

  • Habilitar la integración con servicios de AWS compatibles para proporcionar funcionalidad de servicio en todas las cuentas de la organización.

  • Es posible iniciar sesión como el usuario raíz utilizando el correo electrónico y la contraseña utilizados para crear esta cuenta raíz/organización.

La cuenta de gestión tiene las responsabilidades de una cuenta pagadora y es responsable de pagar todos los cargos que son acumulados por las cuentas miembro. No puedes cambiar la cuenta de gestión de una organización.

  • Las cuentas miembro constituyen el resto de las cuentas en una organización. Una cuenta puede ser miembro de solo una organización a la vez. Puedes adjuntar una política a una cuenta para aplicar controles solo a esa cuenta.
  • Las cuentas miembro deben usar una dirección de correo electrónico válida y pueden tener un nombre, en general no podrán gestionar la facturación (pero podrían recibir acceso a ella).
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Unidades de Organización

Las cuentas se pueden agrupar en Unidades de Organización (OU). De esta manera, puedes crear políticas para la Unidad de Organización que se van a aplicar a todas las cuentas hijas. Ten en cuenta que una OU puede tener otras OUs como hijas.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Service Control Policy (SCP)

Una service control policy (SCP) es una política que especifica los servicios y acciones que los usuarios y roles pueden usar en las cuentas que la SCP afecta. Las SCP son similares a las políticas de permisos de IAM excepto que no otorgan ningún permiso. En cambio, las SCP especifican los permisos máximos para una organización, unidad organizativa (OU) o cuenta. Cuando adjuntas una SCP a la raíz de tu organización o a una OU, la SCP limita los permisos para las entidades en las cuentas miembros.

Esta es la ÚNICA forma en que incluso el usuario raíz puede ser detenido de hacer algo. Por ejemplo, podría usarse para evitar que los usuarios desactiven CloudTrail o eliminen copias de seguridad.
La única forma de eludir esto es comprometer también la cuenta maestra que configura las SCP (la cuenta maestra no puede ser bloqueada).

Warning

Ten en cuenta que las SCP solo restringen a los principales en la cuenta, por lo que otras cuentas no se ven afectadas. Esto significa que tener una SCP que niegue s3:GetObject no detendrá a las personas de acceder a un bucket S3 público en tu cuenta.

Ejemplos de SCP:

  • Negar completamente la cuenta raíz
  • Solo permitir regiones específicas
  • Solo permitir servicios en la lista blanca
  • Negar que GuardDuty, CloudTrail y S3 Public Block Access sean desactivados
  • Negar que roles de seguridad/respuesta a incidentes sean eliminados o modificados.
  • Negar que las copias de seguridad sean eliminadas.
  • Negar la creación de usuarios IAM y claves de acceso

Encuentra ejemplos JSON en https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

Resource Control Policy (RCP)

Una resource control policy (RCP) es una política que define los permisos máximos para los recursos dentro de tu organización AWS. Las RCP son similares a las políticas de IAM en sintaxis pero no otorgan permisos—solo limitan los permisos que pueden aplicarse a los recursos por otras políticas. Cuando adjuntas una RCP a la raíz de tu organización, a una unidad organizativa (OU) o a una cuenta, la RCP limita los permisos de recursos en todos los recursos dentro del alcance afectado.

Esta es la ÚNICA forma de asegurar que los recursos no pueden exceder los niveles de acceso predefinidos—incluso si una política basada en identidad o en recursos es demasiado permisiva. La única forma de eludir estos límites es también modificar la RCP configurada por la cuenta de gestión de tu organización.

Warning

Las RCP solo restringen los permisos que los recursos pueden tener. No controlan directamente lo que los principales pueden hacer. Por ejemplo, si una RCP niega el acceso externo a un bucket S3, asegura que los permisos del bucket nunca permitan acciones más allá del límite establecido—incluso si una política basada en recursos está mal configurada.

Ejemplos de RCP:

  • Restringir los buckets S3 para que solo puedan ser accedidos por principales dentro de tu organización
  • Limitar el uso de claves KMS para permitir solo operaciones de cuentas organizativas de confianza
  • Limitar permisos en colas SQS para prevenir modificaciones no autorizadas
  • Hacer cumplir límites de acceso en secretos de Secrets Manager para proteger datos sensibles

Encuentra ejemplos en AWS Organizations Resource Control Policies documentation

ARN

Amazon Resource Name es el nombre único que tiene cada recurso dentro de AWS, se compone así:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Note que hay 4 particiones en AWS pero solo 3 formas de llamarlas:

  • AWS Standard: aws
  • AWS China: aws-cn
  • AWS US public Internet (GovCloud): aws-us-gov
  • AWS Secret (US Classified): aws

IAM - Identity and Access Management

IAM es el servicio que te permitirá gestionar Autenticación, Autorización y Control de Acceso dentro de tu cuenta de AWS.

  • Autenticación - Proceso de definir una identidad y la verificación de esa identidad. Este proceso se puede subdividir en: Identificación y verificación.
  • Autorización - Determina a qué puede acceder una identidad dentro de un sistema una vez que ha sido autenticada.
  • Control de Acceso - El método y proceso de cómo se concede acceso a un recurso seguro.

IAM se puede definir por su capacidad para gestionar, controlar y gobernar los mecanismos de autenticación, autorización y control de acceso de identidades a tus recursos dentro de tu cuenta de AWS.

AWS account root user

Cuando creas por primera vez una cuenta de Amazon Web Services (AWS), comienzas con una única identidad de inicio de sesión que tiene acceso completo a todos los servicios y recursos de AWS en la cuenta. Este es el usuario raíz de la cuenta de AWS y se accede iniciando sesión con la dirección de correo electrónico y la contraseña que utilizaste para crear la cuenta.

Ten en cuenta que un nuevo usuario administrador tendrá menos permisos que el usuario raíz.

Desde el punto de vista de la seguridad, se recomienda crear otros usuarios y evitar usar este.

IAM users

Un usuario de IAM es una entidad que creas en AWS para representar a la persona o aplicación que lo utiliza para interactuar con AWS. Un usuario en AWS consiste en un nombre y credenciales (contraseña y hasta dos claves de acceso).

Cuando creas un usuario de IAM, le otorgas permisos haciéndolo miembro de un grupo de usuarios que tiene políticas de permisos apropiadas adjuntas (recomendado), o adjuntando políticas directamente al usuario.

Los usuarios pueden tener MFA habilitado para iniciar sesión a través de la consola. Los tokens API de los usuarios con MFA habilitado no están protegidos por MFA. Si deseas restringir el acceso de las claves API de un usuario usando MFA, necesitas indicar en la política que para realizar ciertas acciones se necesita que MFA esté presente (ejemplo aquí).

CLI

  • Access Key ID: 20 caracteres alfanuméricos aleatorios en mayúsculas como AKHDNAPO86BSHKDIRYT
  • Secret access key ID: 40 caracteres aleatorios en mayúsculas y minúsculas: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (No es posible recuperar los IDs de claves de acceso secretas perdidas).

Siempre que necesites cambiar la Clave de Acceso, este es el proceso que debes seguir:
Crear una nueva clave de acceso -> Aplicar la nueva clave al sistema/aplicación -> marcar la original como inactiva -> Probar y verificar que la nueva clave de acceso funciona -> Eliminar la antigua clave de acceso

MFA - Multi Factor Authentication

Se utiliza para crear un factor adicional para la autenticación además de tus métodos existentes, como la contraseña, creando así un nivel de autenticación multifactor.
Puedes usar una aplicación virtual gratuita o un dispositivo físico. Puedes usar aplicaciones como Google Authenticator de forma gratuita para activar un MFA en AWS.

Las políticas con condiciones de MFA se pueden adjuntar a lo siguiente:

  • Un usuario o grupo de IAM
  • Un recurso como un bucket de Amazon S3, una cola de Amazon SQS o un tema de Amazon SNS
  • La política de confianza de un rol de IAM que puede ser asumido por un usuario

Si deseas acceder a través de CLI a un recurso que verifica MFA, necesitas llamar a GetSessionToken. Eso te dará un token con información sobre MFA.
Ten en cuenta que las credenciales de AssumeRole no contienen esta información.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Como se indica aquí, hay muchos casos diferentes en los que MFA no se puede usar.

Grupos de usuarios de IAM

Un grupo de usuarios de IAM es una forma de adjuntar políticas a múltiples usuarios a la vez, lo que puede facilitar la gestión de los permisos para esos usuarios. Los roles y grupos no pueden ser parte de un grupo.

Puedes adjuntar una política basada en identidad a un grupo de usuarios para que todos los usuarios en el grupo de usuarios reciban los permisos de la política. No puedes identificar un grupo de usuarios como un Principal en una política (como una política basada en recursos) porque los grupos se relacionan con permisos, no con autenticación, y los principales son entidades IAM autenticadas.

Aquí hay algunas características importantes de los grupos de usuarios:

  • Un grupo de usuarios puede contener muchos usuarios, y un usuario puede pertenecer a múltiples grupos.
  • Los grupos de usuarios no pueden estar anidados; solo pueden contener usuarios, no otros grupos de usuarios.
  • No hay un grupo de usuarios predeterminado que incluya automáticamente a todos los usuarios en la cuenta de AWS. Si deseas tener un grupo de usuarios así, debes crearlo y asignar a cada nuevo usuario a él.
  • El número y tamaño de los recursos de IAM en una cuenta de AWS, como el número de grupos y el número de grupos de los que un usuario puede ser miembro, son limitados. Para más información, consulta cuotas de IAM y AWS STS.

Roles de IAM

Un rol de IAM es muy similar a un usuario, en el sentido de que es una identidad con políticas de permisos que determinan qué puede y no puede hacer en AWS. Sin embargo, un rol no tiene ninguna credencial (contraseña o claves de acceso) asociada. En lugar de estar asociado de manera única a una persona, un rol está destinado a ser asumido por cualquier persona que lo necesite (y tenga suficientes permisos). Un usuario de IAM puede asumir un rol para temporalmente adquirir diferentes permisos para una tarea específica. Un rol puede ser asignado a un usuario federado que inicia sesión utilizando un proveedor de identidad externo en lugar de IAM.

Un rol de IAM consta de dos tipos de políticas: una política de confianza, que no puede estar vacía, que define quién puede asumir el rol, y una política de permisos, que no puede estar vacía, que define a qué puede acceder.

Servicio de Token de Seguridad de AWS (STS)

El Servicio de Token de Seguridad de AWS (STS) es un servicio web que facilita la emisión de credenciales temporales de privilegios limitados. Está específicamente diseñado para:

Credenciales temporales en IAM

Las credenciales temporales se utilizan principalmente con roles de IAM, pero también hay otros usos. Puedes solicitar credenciales temporales que tengan un conjunto de permisos más restringido que tu usuario de IAM estándar. Esto previene que realices accidentalmente tareas que no están permitidas por las credenciales más restringidas. Un beneficio de las credenciales temporales es que expiran automáticamente después de un período de tiempo establecido. Tienes control sobre la duración durante la cual las credenciales son válidas.

Políticas

Permisos de Políticas

Se utilizan para asignar permisos. Hay 2 tipos:

  • Políticas administradas por AWS (preconfiguradas por AWS)
  • Políticas administradas por el cliente: configuradas por ti. Puedes crear políticas basadas en políticas administradas por AWS (modificando una de ellas y creando la tuya propia), utilizando el generador de políticas (una vista GUI que te ayuda a otorgar y denegar permisos) o escribiendo la tuya propia.

Por defecto, el acceso es denegado, el acceso se otorgará si se ha especificado un rol explícito.
Si existe un “Deny” único, anulará el “Allow”, excepto para las solicitudes que utilizan las credenciales de seguridad raíz de la cuenta de AWS (que están permitidas por defecto).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

Los campos globales que se pueden usar para condiciones en cualquier servicio están documentados aquí.
Los campos específicos que se pueden usar para condiciones por servicio están documentados aquí.

Políticas en línea

Este tipo de políticas son asignadas directamente a un usuario, grupo o rol. Entonces, no aparecen en la lista de Políticas ya que cualquier otro puede usarlas.
Las políticas en línea son útiles si deseas mantener una relación estricta uno a uno entre una política y la identidad a la que se aplica. Por ejemplo, quieres asegurarte de que los permisos en una política no se asignen inadvertidamente a una identidad diferente de la que están destinados. Cuando usas una política en línea, los permisos en la política no pueden ser adjuntados inadvertidamente a la identidad incorrecta. Además, cuando usas la Consola de Administración de AWS para eliminar esa identidad, las políticas incrustadas en la identidad también se eliminan. Eso es porque son parte de la entidad principal.

Políticas de Bucket de Recursos

Estas son políticas que se pueden definir en recursos. No todos los recursos de AWS las soportan.

Si un principal no tiene una denegación explícita sobre ellos, y una política de recurso les otorga acceso, entonces se les permite.

Límites de IAM

Los límites de IAM se pueden usar para limitar los permisos a los que un usuario o rol debería tener acceso. De esta manera, incluso si se otorgan un conjunto diferente de permisos al usuario por una política diferente, la operación fallará si intenta usarlos.

Un límite es solo una política adjunta a un usuario que indica el nivel máximo de permisos que el usuario o rol puede tener. Así que, incluso si el usuario tiene acceso de Administrador, si el límite indica que solo puede leer buckets S·, ese es el máximo que puede hacer.

Esto, SCPs y seguir el principio de menor privilegio son las formas de controlar que los usuarios no tengan más permisos de los que necesitan.

Políticas de Sesión

Una política de sesión es una política establecida cuando se asume un rol de alguna manera. Esto será como un límite de IAM para esa sesión: Esto significa que la política de sesión no otorga permisos, sino que los restringe a los indicados en la política (siendo los permisos máximos los que tiene el rol).

Esto es útil para medidas de seguridad: Cuando un administrador va a asumir un rol muy privilegiado, podría restringir el permiso solo a los indicados en la política de sesión en caso de que la sesión se vea comprometida.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Nota que por defecto AWS puede agregar políticas de sesión a las sesiones que se van a generar por razones de terceros. Por ejemplo, en roles asumidos de cognito no autenticados por defecto (usando autenticación mejorada), AWS generará credenciales de sesión con una política de sesión que limita los servicios a los que la sesión puede acceder a la siguiente lista.

Por lo tanto, si en algún momento te enfrentas al error “… porque ninguna política de sesión permite el …”, y el rol tiene acceso para realizar la acción, es porque hay una política de sesión que lo impide.

Federación de Identidad

La federación de identidad permite a los usuarios de proveedores de identidad que son externos a AWS acceder a los recursos de AWS de manera segura sin tener que proporcionar credenciales de usuario de AWS de una cuenta IAM válida.
Un ejemplo de un proveedor de identidad puede ser tu propio Microsoft Active Directory corporativo (a través de SAML) o servicios de OpenID (como Google). El acceso federado permitirá a los usuarios dentro de él acceder a AWS.

Para configurar esta confianza, se genera un Proveedor de Identidad IAM (SAML u OAuth) que confiará en la otra plataforma. Luego, al menos un rol IAM es asignado (confiando) al Proveedor de Identidad. Si un usuario de la plataforma de confianza accede a AWS, lo hará como el rol mencionado.

Sin embargo, generalmente querrás dar un rol diferente dependiendo del grupo del usuario en la plataforma de terceros. Entonces, varios roles IAM pueden confiar en el Proveedor de Identidad de terceros y la plataforma de terceros será la que permitirá a los usuarios asumir un rol u otro.

Centro de Identidad IAM

AWS IAM Identity Center (sucesor de AWS Single Sign-On) amplía las capacidades de AWS Identity and Access Management (IAM) para proporcionar un lugar central que reúne la administración de usuarios y su acceso a cuentas de AWS y aplicaciones en la nube.

El dominio de inicio de sesión será algo como <user_input>.awsapps.com.

Para iniciar sesión a los usuarios, hay 3 fuentes de identidad que se pueden usar:

  • Directorio del Centro de Identidad: Usuarios regulares de AWS
  • Active Directory: Soporta diferentes conectores
  • Proveedor de Identidad Externo: Todos los usuarios y grupos provienen de un Proveedor de Identidad externo (IdP)

En el caso más simple del directorio del Centro de Identidad, el Centro de Identidad tendrá una lista de usuarios y grupos y podrá asignar políticas a ellos para cualquiera de las cuentas de la organización.

Para dar acceso a un usuario/grupo del Centro de Identidad a una cuenta, se creará un Proveedor de Identidad SAML que confíe en el Centro de Identidad, y se creará un rol que confíe en el Proveedor de Identidad con las políticas indicadas en la cuenta de destino.

AwsSSOInlinePolicy

Es posible dar permisos a través de políticas en línea a roles creados a través del Centro de Identidad IAM. Los roles creados en las cuentas que se les dan políticas en línea en AWS Identity Center tendrán estos permisos en una política en línea llamada AwsSSOInlinePolicy.

Por lo tanto, incluso si ves 2 roles con una política en línea llamada AwsSSOInlinePolicy, no significa que tenga los mismos permisos.

Confianzas y Roles entre Cuentas

Un usuario (confiando) puede crear un Rol entre Cuentas con algunas políticas y luego, permitir a otro usuario (confiado) acceder a su cuenta pero solo teniendo el acceso indicado en las nuevas políticas del rol. Para crear esto, solo crea un nuevo Rol y selecciona Rol entre Cuentas. Los roles para Acceso entre Cuentas ofrecen dos opciones. Proporcionar acceso entre cuentas de AWS que posees, y proporcionar acceso entre una cuenta que posees y una cuenta de AWS de terceros.
Se recomienda especificar el usuario que es confiado y no poner algo genérico porque si no, otros usuarios autenticados como usuarios federados también podrán abusar de esta confianza.

AWS Simple AD

No soportado:

  • Relaciones de Confianza
  • Centro de Administración de AD
  • Soporte completo de API de PS
  • Papelera de reciclaje de AD
  • Cuentas de Servicio Administradas por Grupo
  • Extensiones de Esquema
  • Sin acceso directo a OS o Instancias

Federación Web o Autenticación OpenID

La aplicación utiliza AssumeRoleWithWebIdentity para crear credenciales temporales. Sin embargo, esto no otorga acceso a la consola de AWS, solo acceso a recursos dentro de AWS.

Otras opciones de IAM

  • Puedes establecer una configuración de política de contraseñas con opciones como longitud mínima y requisitos de contraseña.
  • Puedes descargar “Informe de Credenciales” con información sobre las credenciales actuales (como el tiempo de creación del usuario, si la contraseña está habilitada…). Puedes generar un informe de credenciales tan a menudo como una vez cada cuatro horas.

AWS Identity and Access Management (IAM) proporciona control de acceso granular en toda AWS. Con IAM, puedes especificar quién puede acceder a qué servicios y recursos, y bajo qué condiciones. Con las políticas de IAM, gestionas los permisos de tu fuerza laboral y sistemas para asegurar permisos de menor privilegio.

Prefijos de ID de IAM

En esta página puedes encontrar los prefijos de ID de IAM de las claves dependiendo de su naturaleza:

Código de IdentificadorDescripción
ABIAToken portador del servicio AWS STS

| ACCA | Credencial específica del contexto | | AGPA | Grupo de usuarios | | AIDA | Usuario IAM | | AIPA | Perfil de instancia de Amazon EC2 | | AKIA | Clave de acceso | | ANPA | Política administrada | | ANVA | Versión en una política administrada | | APKA | Clave pública | | AROA | Rol | | ASCA | Certificado | | ASIA | IDs de claves de acceso temporales (AWS STS) utilizan este prefijo, pero son únicos solo en combinación con la clave de acceso secreta y el token de sesión. |

Permisos recomendados para auditar cuentas

Los siguientes privilegios otorgan varios accesos de lectura de metadatos:

  • arn:aws:iam::aws:policy/SecurityAudit
  • arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
  • codebuild:ListProjects
  • config:Describe*
  • cloudformation:ListStacks
  • logs:DescribeMetricFilters
  • directconnect:DescribeConnections
  • dynamodb:ListTables

Varios

Autenticación CLI

Para que un usuario regular se autentique en AWS a través de CLI, necesitas tener credenciales locales. Por defecto, puedes configurarlas manualmente en ~/.aws/credentials o ejecutando aws configure.
En ese archivo puedes tener más de un perfil, si no se especifica un perfil usando el aws cli, se utilizará el llamado [default] en ese archivo.
Ejemplo de archivo de credenciales con más de 1 perfil:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Si necesitas acceder a diferentes cuentas de AWS y tu perfil tiene acceso para asumir un rol dentro de esas cuentas, no necesitas llamar manualmente a STS cada vez (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) y configurar las credenciales.

Puedes usar el archivo ~/.aws/config para indicar qué roles asumir, y luego usar el parámetro --profile como de costumbre (el assume-role se realizará de manera transparente para el usuario).
Un ejemplo de archivo de configuración:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Con este archivo de configuración, puedes usar aws cli así:

aws --profile acc2 ...

Si estás buscando algo similar a esto pero para el navegador, puedes revisar la extensión AWS Extend Switch Roles.

Automatizando credenciales temporales

Si estás explotando una aplicación que genera credenciales temporales, puede ser tedioso actualizarlas en tu terminal cada pocos minutos cuando expiran. Esto se puede solucionar utilizando una directiva credential_process en el archivo de configuración. Por ejemplo, si tienes alguna aplicación web vulnerable, podrías hacer:

[victim]
credential_process = curl -d 'PAYLOAD' https://some-site.com

Tenga en cuenta que las credenciales deben ser devueltas a STDOUT en el siguiente formato:

{
"Version": 1,
"AccessKeyId": "an AWS access key",
"SecretAccessKey": "your AWS secret access key",
"SessionToken": "the AWS session token for temporary credentials",
"Expiration": "ISO8601 timestamp when the credentials expire"
}

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks