Investigación de la concesión de consentimiento de la aplicación

  • Artículo

En este artículo se proporcionan instrucciones para identificar e investigar los ataques de consentimiento de la aplicación, proteger la información y minimizar los riesgos adicionales.

Este artículo contiene las siguientes secciones:

  • Requisitos previos: cubre los requisitos específicos que debe completar antes de iniciar la investigación. Por ejemplo, el registro que debe activarse, los roles y los permisos necesarios, entre otras cosas.
  • Flujo de trabajo: muestra el flujo lógico que debe seguir para realizar esta investigación.
  • Lista de comprobación: contiene una lista de tareas para cada uno de los pasos del diagrama de flujo. Esta lista de comprobación puede ser útil en entornos muy regulados para verificar los pasos dados o simplemente como puerta de calidad para usted mismo.
  • Pasos de investigación: incluye una guía detallada paso a paso para esta investigación específica.
  • Recuperación: contiene pasos generales sobre cómo recuperar o mitigar un ataque de concesión de consentimiento de la aplicación ilegal.
  • Referencias: contiene materiales de lectura y referencia adicionales.

Requisitos previos

Estas son las configuraciones generales que debe completar para realizar una investigación de las concesiones de consentimiento de la aplicación. Antes de iniciar la investigación, asegúrese de que ha leído sobre los tipos de permisos de consentimiento que se explican en Tipos de permisos de consentimiento.

Datos de clientes

Para iniciar el proceso de investigación, necesita los datos siguientes:

  • Acceso al inquilino como administrador global: una cuenta solo en la nube (que no sea parte del entorno local)
  • Detalles de los indicadores de riesgo (IoC)
  • Fecha y hora en que se descubrió el incidente
  • Intervalo de fechas
  • Número de cuentas en peligro
  • Nombre de las cuentas en peligro
  • Roles de la cuenta en peligro
  • ¿Las cuentas tienen privilegios elevados (Microsoft Exchange o SharePoint con disponibilidad general)?
  • ¿Hay alguna aplicación empresarial relacionada con el incidente?
  • ¿Algún usuario informó sobre aplicaciones que solicitaban permisos a los datos en su nombre?

Requisitos del sistema

Asegúrese de completar los siguientes requisitos de instalación y configuración:

  1. El módulo AzureAD PowerShell está instalado.
  2. Tiene derechos de administrador global en el inquilino en el que se ejecutará el script.
  3. Tiene asignado el rol de administrador local en el equipo que usará para ejecutar los scripts.

Nota:

Los módulos de PowerShell de Azure AD y MSOnline están en desuso a partir del 30 de marzo de 2024. Para obtener más información, lea la actualización de desuso. Desde esta fecha, el soporte de estos módulos se limita a la asistencia de migración al SDK de PowerShell de Microsoft Graph y a las correcciones de seguridad. Los módulos en desuso seguirán funcionando hasta el 30 de marzo de 2025.

Se recomienda migrar a PowerShell de Microsoft Graph para interactuar con Microsoft Entra ID (anteriormente Azure AD). Para preguntas comunes sobre la migración, consulte las Preguntas más frecuentes sobre migración. Nota: Las versiones 1.0.x de MSOnline podrían experimentar interrupciones después del 30 de junio de 2024.

Instalación del módulo de Azure AD

Use este comando para instalar el módulo de AzureAD.

Install-Module -Name AzureAD -Verbose

Nota:

Si se le pide que instale los módulos desde un repositorio que no es de confianza, escriba Y y presione Entrar.

Instalación del módulo de MSOnline de PowerShell

  1. Ejecute la aplicación Windows PowerShell con privilegios elevados (ejecutar como administrador).

  2. Ejecute este comando para permitir que PowerShell ejecute scripts firmados.

    Set-ExecutionPolicy RemoteSigned

  3. Instale el módulo de MSOnline con este comando.

    Install-Module -Name MSOnline -Verbose

    Nota:

    Si se le pide que instale los módulos desde un repositorio que no es de confianza, escriba Y y presione Entrar.

Descarga del script AzureADPSPermissions de GitHub

  1. Descargue el script Get-AzureADPSPermissions.ps1 de GitHub en la carpeta desde la que ejecutará el script. El archivo de salida "permissions.csv" también se escribirá en esta misma carpeta.

  2. Abra una instancia de PowerShell como administrador y abra la carpeta en la que guardó el script.

  3. Conéctese al directorio mediante el cmdlet Connect-AzureAD. Este es un ejemplo.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -AccountId "user1@contoso.onmicrosoft.com"

  4. Ejecute este comando de PowerShell.

    Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

    Desconecte la sesión de AzureAD con este comando.

    Disconnect-AzureAD

El consentimiento es el proceso por el cual se concede autorización para que una aplicación acceda a recursos protegidos en nombre de un usuario. Se puede solicitar el consentimiento a un administrador o usuario para que permita el acceso a los datos de la organización o de personas concretas.

A una aplicación se le concede acceso a los datos en función de un usuario determinado o de toda la organización. Los atacantes pueden utilizar indebidamente estos consentimientos para obtener persistencia en el entorno y acceder a datos sensibles. Este tipo de ataques se denominan "concesiones de consentimiento ilegales", que pueden producirse mediante un correo electrónico de suplantación de identidad (phishing), una cuenta de usuario en peligro debido a difusión de contraseñas o cuando un atacante registra una aplicación como un usuario legítimo. En escenarios en los que una cuenta de administrador global está en peligro, el registro y la concesión de consentimiento están en riesgo para todo el inquilino, y no solo para un usuario.

Para que una aplicación pueda acceder a los datos de su organización, primero un usuario debe conceder los permisos de aplicación. Existen diferentes permisos que permiten distintos niveles de acceso. De forma predeterminada, todos los usuarios pueden dar su consentimiento a las aplicaciones para los permisos que no requieren el consentimiento del administrador. Por ejemplo, de manera predeterminada, un usuario puede dar su consentimiento para permitir que una aplicación acceda a su buzón, pero no puede dar su consentimiento para que una aplicación acceda sin restricciones a leer y escribir en todos los archivos de la organización.

Nota:

Al permitir que los usuarios concedan permiso a las aplicaciones para acceder a los datos, los usuarios pueden adquirir fácilmente aplicaciones útiles y ser productivos. Sin embargo, en algunas situaciones esta configuración puede representar un riesgo si no se supervisa y controla con cuidado.

Para poder conceder consentimiento del administrador para todo el inquilino, debe iniciar sesión con uno de los siguientes roles:

  • Administrador global
  • Administrador de aplicaciones
  • Administrador de aplicaciones en la nube
  • Administrador: indica que el administrador concedió el consentimiento (en nombre de la organización).
  • Usuario individual: indica que el usuario concedió el consentimiento y solo se tiene acceso a la información de ese usuario.
  • Valores aceptados
    • AllPrincipals: un administrador dio el consentimiento para todo el inquilino.
    • Entidad de seguridad: un usuario individual ha dado su consentimiento solo para los datos relacionados con esa cuenta.

La experiencia real del usuario para otorgar el consentimiento difiere en función de las directivas establecidas en el inquilino del usuario, el ámbito de autoridad del usuario (o su rol) y el tipo de permisos que solicita la aplicación cliente. Esto significa que los desarrolladores de aplicaciones y los administradores de inquilinos tienen cierto control sobre la experiencia de consentimiento. Los administradores tienen la flexibilidad de configurar y desactivar las directivas en una aplicación o inquilino para controlar la experiencia de consentimiento en su inquilino. Los desarrolladores de aplicaciones pueden dictar qué tipos de permiso se solicitan y si quieren guiar a los usuarios a través del flujo de consentimiento del usuario o el flujo de consentimiento del administrador.

  • Flujo de consentimiento del usuario: cuando un desarrollador de aplicaciones dirige a los usuarios al punto de conexión de autorización con la intención de registrar el consentimiento solo para el usuario actual.

  • Flujo de consentimiento del administrador: cuando un desarrollador de aplicaciones dirige a los usuarios al punto de conexión de consentimiento del administrador con la intención de registrar el consentimiento para todo el inquilino. Para asegurarse de que el flujo de consentimiento del administrador funcione correctamente, los desarrolladores de aplicaciones deben enumerar todos los permisos en la propiedad RequiredResourceAccess del manifiesto de aplicación.

Permisos delegados frente a permisos de aplicación

Los permisos delegados los usan las aplicaciones que tienen un usuario que ha iniciado sesión y que, además, pueden recibir consentimiento del administrador o el usuario.

Los permisos de aplicación los usan las aplicaciones que se ejecutan sin necesidad de que un usuario inicie sesión. Por ejemplo, las aplicaciones que se ejecutan como servicios en segundo plano o los demonios. Los permisos de aplicación pueden ser aceptados solo por un administrador.

Para más información, vea:

Clasificación de permisos de riesgo

Hay (como mínimo) miles de permisos en el sistema y no es factible enumerarlos o analizarlos todos. La siguiente lista aborda los permisos comúnmente mal utilizados y otros que crearían un impacto catastrófico si se utilizan mal.

En términos generales, Microsoft ha observado que se usan incorrectamente los siguientes permisos delegados "raíz" (aplicación y usuario) en los ataques de suplantación de consentimiento. El nivel raíz equivale al nivel superior. Por ejemplo, Contacts. implica incluir todas las permutaciones delegadas de los permisos de contactos: Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared y Contacts.ReadWrite.Shared.

  1. Mail.* (incluye Mail.Send*, pero no Mail.ReadBasic*)
  2. Contactos. *
  3. MailboxSettings.
  4. Personas.
  5. Archivos
  6. Notes.
  7. Directory.AccessAsUser.All
  8. User_Impersonation

Los siete primeros permisos de la lista anterior son para Microsoft Graph y los equivalentes de API "heredados", como Azure Active Directory (Azure AD) Graph y REST de Outlook. El octavo permiso es para Azure Resource Manager (ARM) y también podría ser peligroso en cualquier API que exponga información confidencial con este ámbito de suplantación global.

Según las observaciones del equipo de respuesta a incidentes de Microsoft, los atacantes usan una combinación de los seis primeros permisos en el 99 % de los ataques de suplantación de consentimiento. La mayoría de las personas no piensa en la versión delegada de Mail.Read o Files.Read como un permiso de alto riesgo; sin embargo, los ataques suelen ser generalizados y estar dirigidos a usuarios finales, en lugar de tratarse de suplantaciones de identidad (phishing) contra administradores que realmente puedan dar su consentimiento a los permisos peligrosos. Se recomienda encapsular las aplicaciones con estos permisos de impacto de nivel "crítico". Incluso si las aplicaciones no son malintencionadas, si un actor malintencionado pudiera poner en peligro la identidad de la aplicación, toda la organización podría estar en riesgo.

Para conocer los permisos de mayor impacto en el riesgo, comience por:

  • Versiones de permiso de aplicación (AppOnly/AppRole) de todos los permisos anteriores, cuando proceda

Versiones delegadas y solo de aplicación de los permisos siguientes:

  • Application.ReadWrite.All
  • Directory.ReadWrite.All
  • Domain.ReadWrite.All
  • EduRoster.ReadWrite.All
  • Group.ReadWrite.All
  • Member.Read.Hidden
  • RoleManagement.ReadWrite.Directory
  • User.ReadWrite.All
  • User.ManageCreds.All
  • Todos los demás permisos de solo aplicación que permiten el acceso de escritura

Para obtener la lista de permisos de menor impacto en el riesgo, comience por:

  • User.Read
  • User.ReadBasic.All
  • Open_id
  • Email
  • Perfil
  • Offline_access (solo si está acompañado de otros permisos en esta lista de "menor riesgo")

Visualización de permisos

  1. Para ver los permisos, vaya a la pantalla Registro de la aplicación empresarial.

    ver permisos

  2. Seleccione Ver permisos de API.

    permisos de API

  3. Seleccione Agregar un permiso y se mostrará la pantalla siguiente.

    api

  4. Seleccione Microsoft Graph para ver los distintos tipos de permisos.

    tipos de permisos

  5. Seleccione el tipo de permisos que usa la aplicación registrada: Permisos delegados o Permisos de aplicación. En la imagen anterior, la opción Permisos de aplicación está seleccionada.

  6. Puede buscar uno de los permisos con impacto de alto riesgo, como EduRoster.

    permiso de ejemplo

  7. Seleccione EduRoster y expanda los permisos.

    eduroster

  8. Ahora puede asignar o revisar estos permisos.

    Para obtener más información, Permisos de Graph.

Flujo de trabajo

[Flujo de trabajo de la investigación de concesión de consentimiento de la aplicación]

También puede:

  • Descargue los flujos de trabajo del cuaderno de estrategias de concesión de consentimiento de aplicación y otros de respuesta a incidentes como un PDF.
  • Descargue los flujos de trabajo del cuaderno de estrategias de concesión de consentimiento de aplicación y otros de respuesta a incidentes como un archivo de Visio.

Lista de comprobación

Use esta lista de comprobación para realizar la validación de la concesión de consentimiento de la aplicación.

  • Requisitos

    Asegúrese de que tiene acceso al inquilino como administrador global. Esta es una cuenta solo en la nube y no forma parte del entorno local.

  • Indicadores de riesgo (IoC)

    Compruebe los siguientes indicadores de riesgo (IoC):

    • ¿Cuándo se ha dado cuenta del incidente?
    • Intervalo de fechas del incidente (¿cuán amplio es el intervalo de búsqueda?)
    • Número de cuentas en peligro
    • Nombre de las cuentas en peligro
    • Roles de las cuentas en peligro
    • ¿Las cuentas en peligro tienen privilegios elevados, un usuario estándar o una combinación de ambos?

  • Roles

    Debe tener asignados estos roles:

    • Derechos de administrador global en el inquilino para ejecutar el script
    • Rol de administrador local en el equipo desde el que se ejecutará el script

  • Configuración de PowerShell

    Configure el entorno de PowerShell con lo siguiente:

    1. Instale el módulo de Azure AD PowerShell.
    2. Ejecute la aplicación Windows PowerShell con privilegios elevados. (Ejecutar como administrador).
    3. Configure PowerShell para ejecutar scripts firmados.
    4. Descargue el script Get-AzureADPSPermissions.ps1.

  • Desencadenadores de la investigación

    • Peligro de la cuenta
    • Se modificó la configuración de consentimiento de la aplicación en el inquilino
    • Se detectó el motivo de estado del evento de alerta o auditoría "aplicación de riesgo"
    • Se detectaron aplicaciones de aspecto extraño

También puede descargar las listas de comprobación del cuaderno de estrategias de concesión de consentimiento de aplicación y otras de respuesta a incidentes como un archivo de Excel.

Pasos de investigación

Puede usar los dos métodos siguientes para investigar las concesiones de consentimiento de la aplicación:

  • Azure portal
  • Script de PowerShell

Nota:

Azure Portal solo le permitirá ver las concesiones de consentimiento del administrador durante los últimos 90 días y, en debido a esto, se recomienda usar el método de script de PowerShell solo para reducir los pasos de investigación de registros de atacantes.

Método 1: Uso de Azure Portal

Puede usar el Centro de administración de Microsoft Entra para buscar aplicaciones a las que los usuarios individuales han concedido permisos.

  1. Inicie sesión en Azure Portal como administrador.
  2. Selecciona el icono Microsoft Entra ID.
  3. Seleccione Usuarios.
  4. Seleccione el usuario que quiere revisar.
  5. Seleccione Aplicaciones.
  6. Verá la lista de aplicaciones que están asignadas al usuario y los permisos que tienen estas aplicaciones.

Método 2: Uso de PowerShell

Hay varias herramientas de PowerShell que puede usar para investigar las concesiones de consentimiento ilegales, como, por ejemplo:

PowerShell es la herramienta más sencilla y no requiere ninguna modificación en el inquilino. Basaremos nuestra investigación en la documentación pública del ataque de concesión de consentimiento ilegal.

Ejecute Get-AzureADPSPermissions.ps1 para exportar todas las concesiones de consentimiento de OAuth y las aplicaciones de OAuth para todos los usuarios de su inquilino en un archivo .csv. Consulte la sección Requisitos previos para descargar y ejecutar el script Get-AzureADPSPermissions.

  1. Abra una instancia de PowerShell como administrador y abra la carpeta en la que guardó el script.

  2. Conéctese al directorio mediante el siguiente comando Connect-AzureAD. Este es un ejemplo.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -AccountId "user1@contoso.onmicrosoft.com"

  3. Ejecute este comando de PowerShell.

    Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation

  4. Una vez completado el script, se recomienda desconectar la sesión de Microsoft Entra con este comando.

     Disconnect-AzureAD

    Nota:

    El script puede tardar algunas horas en completarse, en función del tamaño y los permisos configurados, así como de la conexión.

  5. El script crea un archivo denominado Permissions.csv.

  6. Abra el archivo, filtre o formatee los datos en una tabla y guárdelos como un archivo .xlxs (para filtrarlos).

    Los encabezados de columna de la salida se muestran en esta imagen.

    Ejemplo de encabezados de columna

  7. En la columna ConsentType(G), busque el valor AllPrinciples. El permiso AllPrincipals permite que la aplicación cliente acceda al contenido de todos los usuarios en el inquilino. Las aplicaciones de Microsoft 365 nativas necesitan este permiso para funcionar correctamente. Todas las aplicaciones que no son de Microsoft con este permiso deben revisarse detenidamente.

  8. En la columna Permission(F), revise los permisos que tiene cada aplicación delegada. Busque los permisos Read y Write o *. All y revíselos detenidamente, ya que es posible que no sean adecuados. Ejemplo de la columna Permiso F

    Nota:

    Revise los usuarios específicos a los que se ha concedido consentimiento. Si a los usuarios de alto perfil o de alto impacto se les han concedido consentimientos inadecuados, debe investigar más.

  9. En la columna ClientDisplayName(C), busque aplicaciones que parezcan sospechosas, como:

    • Aplicaciones con nombres mal escritos Ejemplo de un nombre mal escrito

    • Nombres inusuales o sosos Ejemplo de un nombre inusual

    • Nombres que suenan a hackers. Debe revisar estos nombres detenidamente. Ejemplo de un nombre de hacker

Salida de ejemplo: AllPrincipals y permisos de lectura y escritura en todo. Es posible que las aplicaciones no tengan nada sospechoso, como nombres anodinos, y estén usando MS Graph. Sin embargo, realice investigaciones y determine el propósito de las aplicaciones y los permisos reales que tienen las aplicaciones en el inquilino, como se muestra en este ejemplo.

Ejemplo de aplicaciones con ConsentType de AllPrincipals

Estas son algunas sugerencias útiles para revisar las investigaciones de la directiva de seguridad de la información (ISP):

  1. ReplyURL/RedirectURL
    • Busque URL sospechosas.
  2. ¿La dirección URL está hospedada en un dominio sospechoso?
    • ¿Está en peligro?
    • ¿El dominio se registró recientemente?
    • ¿Es un dominio temporal?
  3. ¿Hay un vínculo a los términos del servicio o acuerdo de servicio en el registro de la aplicación?
  4. ¿El contenido es único y específico de la aplicación o el editor?
  5. ¿El inquilino que registró la aplicación está recién creado o en peligro (por ejemplo, un usuario en riesgo registró la aplicación)?

Técnicas de ataque

Aunque cada ataque tiende a variar, las técnicas de ataque principales son:

  • Un atacante registra una aplicación con un proveedor de OAuth 2.0, como Microsoft Entra ID.

  • La aplicación se configura de manera que parezca legítima. Por ejemplo, los atacantes podrían usar el nombre de un producto popular que está disponible en el mismo ecosistema.

  • El atacante obtiene un vínculo directamente de los usuarios. Esto se puede obtener a través de la suplantación de identidad (phishing) basada en correo electrónico convencional, al poner en peligro un sitio web que no sea malintencionado o a través de otras técnicas.

  • El usuario selecciona el vínculo y se muestra un aviso de consentimiento auténtico que le pide que conceda a la aplicación malintencionada permisos a los datos.

  • Si un usuario selecciona "Aceptar", concederá a la aplicación permisos para acceder a datos confidenciales.

  • La aplicación obtiene un código de autorización, que canjea por un token de acceso y, potencialmente, por un token de actualización.

  • El token de acceso se usa para realizar llamadas API en nombre del usuario.

  • Si el usuario acepta, el atacante puede obtener acceso a los correos electrónicos del usuario, las reglas de reenvío, los archivos, los contactos, las notas, los perfiles y otros datos y recursos confidenciales.

    Ejemplo de solicitud de permisos

Búsqueda de señales de un ataque

  1. Abra el Centro de seguridad y cumplimiento.

  2. Vaya a Buscar y seleccione Búsqueda de registros de auditoría.

  3. Busque (todas las actividades y todos los usuarios) y escriba la fecha de inicio y la fecha final si es necesario y, a continuación, seleccione Buscar.

    Ejemplo de una búsqueda de registros de auditoría

  4. Seleccione Filtrar resultados y, en el campo Actividad, escriba Consentimiento para la aplicación.

    Ejemplo de filtrado de una búsqueda de registros de auditoría

  5. Si tiene actividad en Consentimiento para conceder, continúe como se indica a continuación.

  6. Seleccione el resultado para ver los detalles de la actividad. Seleccione Más información para obtener detalles de la actividad.

  7. Compruebe si IsAdminContent está establecido en "True".

    Nota:

    Este proceso puede tardar entre 30 minutos y hasta 24 horas para mostrar la entrada del registro de auditoría correspondiente en los resultados de la búsqueda después de que se produzca un evento.

    El período de tiempo durante el que se conserva un registro de auditoría y se puede buscar en el registro de auditoría depende de la suscripción a Microsoft 365 y, en concreto, del tipo de licencia que se haya asignado a un usuario específico. Si este valor es true, indica que quizá alguien con acceso de administrador global concedió un acceso amplio a los datos. Si esto es inesperado, realice los pasos inmediatos para confirmar un ataque.

¿Cómo confirmar un ataque?

Si tiene una o varias instancias de los indicadores de riesgo enumerados anteriormente, debe realizar una investigación más exhaustiva para confirmar de forma positiva que se produjo el ataque.

Inventario de aplicaciones con acceso en la organización

Puede inventariar las aplicaciones para sus usuarios utilizando el centro de administración de Microsoft Entra, PowerShell, o hacer que sus usuarios enumeren individualmente su acceso a las aplicaciones.

  • Use el Centro de administración de Microsoft Entra para inventariar aplicaciones y sus permisos. Este método es exhaustivo, pero solo puede comprobar un usuario a la vez, lo que puede llevar mucho tiempo si tiene que comprobar los permisos de varios usuarios.
  • Use PowerShell para inventariar aplicaciones y sus permisos. Este método es el más rápido y exhaustivo con la menor cantidad de sobrecarga.
  • Anime a los usuarios a comprobar individualmente sus aplicaciones y permisos, así como informar de los resultados a los administradores para realizar correcciones.

Inventario de aplicaciones asignadas a los usuarios

Puede usar el Centro de administración de Microsoft Entra para ver la lista de aplicaciones a las que los usuarios individuales han concedido permisos.

  1. Inicie sesión en Azure Portal con derechos administrativos.
  2. Selecciona el icono Microsoft Entra ID.
  3. Seleccione Usuarios.
  4. Seleccione el usuario que quiere revisar.
  5. Seleccione Aplicaciones.

Verá la lista de aplicaciones que están asignadas al usuario y los permisos que se han concedido a dichas aplicaciones.

Determinación del ámbito del ataque

Cuando haya terminado de inventariar el acceso a la aplicación, revise el registro de auditoría para determinar el ámbito completo de la vulneración. Busque en los usuarios afectados los períodos de tiempo en los que la aplicación ilegal tuvo acceso a su organización y los permisos que tenía la aplicación. Puede buscar el registro de auditoría en el Centro de seguridad y cumplimiento de Microsoft 365.

Importante: Si la auditoría no estaba habilitada antes del posible ataque, no podrá realizar una investigación, ya que los datos de auditoría no estarán disponibles.

¿Cómo evitar ataques y mitigar los riesgos?

Si la organización tiene la licencia correspondiente:

Después de identificar una aplicación con permisos ilícitos, deshabilite inmediatamente la aplicación siguiendo las instrucciones de Deshabilitar una aplicación. A continuación, póngase en contacto con Soporte técnico de Microsoft para notificar la aplicación malintencionada.

Una vez que una aplicación está deshabilitada en el inquilino de Microsoft Entra, no puede obtener nuevos tokens para acceder a los datos y otros usuarios no podrán iniciar sesión ni conceder consentimiento a la aplicación.

Nota:

Si sospecha que ha encontrado una aplicación malintencionada en su organización, es mejor deshabilitarla que eliminarla. Si solo elimina la aplicación, podría devolverse más adelante si otro usuario concede consentimiento. En su lugar, deshabilite la aplicación para asegurarse de que no puede volver más adelante.

Pasos para proteger su organización

Hay varios tipos de ataques de consentimiento, pero si sigue estas defensas recomendadas, se mitigarán todos los tipos de ataques, especialmente la suplantación de consentimiento, donde los atacantes engañan a los usuarios para que concedan a una aplicación malintencionada acceso a datos confidenciales u otros recursos. En lugar de intentar robar la contraseña del usuario, un atacante busca permiso para que una aplicación controlada por el atacante acceda a datos valiosos.

Para evitar que los ataques de consentimiento afecten a Microsoft Entra ID y Office 365, consulte las siguientes recomendaciones:

Establecer las directivas

  • Esta configuración tendrá implicaciones para el usuario y puede que no sea aplicable para un entorno. Si va a permitir todos los consentimientos, asegúrese de que los administradores aprueben las solicitudes.

  • Permita los consentimientos solo para aplicaciones de editores comprobados y con tipos específicos de permisos clasificados como de bajo impacto.

    Nota:

    Las recomendaciones anteriores se sugieren en función de las configuraciones más idóneas y seguras. Sin embargo, como la seguridad es un delicado equilibrio entre funcionalidades y operaciones, las configuraciones más seguras pueden provocar sobrecargas adicionales para los administradores. Esta es una decisión que se toma mejor después de consultar a los administradores.

    Configuración del consentimiento activo en función del riesgo: habilitado de manera predeterminada si el consentimiento del usuario a las concesiones está habilitado

  • El consentimiento activo en función del riesgo ayuda a reducir la exposición de los usuarios a aplicaciones malintencionadas que realizan solicitudes de consentimiento ilícitas. Si Microsoft detecta una solicitud de consentimiento de usuario final de riesgo, la solicitud requerirá un "paso activo" para el consentimiento de administrador. Esta funcionalidad está habilitada de manera predeterminada, pero solo producirá un cambio de comportamiento cuando esté habilitado el consentimiento del usuario final.

  • Cuando se detecta una solicitud de consentimiento peligrosa, la petición de consentimiento mostrará un mensaje que indica que se necesita la aprobación del administrador. Si el flujo de trabajo de solicitud de consentimiento del administrador está habilitado, el usuario puede enviar la solicitud al administrador para que la revise de nuevo desde la propia petición de consentimiento. Si se habilita, aparecerá el siguiente mensaje:

    AADSTS90094: <clientAppDisplayName> necesita permiso para acceder a recursos de su organización que solo un administrador puede conceder. Pida a un administrador que conceda permiso a esta aplicación para poder usarla. En este caso, también se registrará un evento de auditoría con la categoría "ApplicationManagement", el tipo de actividad "Consentimiento a la aplicación" y el motivo de estado "Aplicación arriesgada detectada".

Nota:

Todas tareas que requieran la aprobación del administrador tendrán sobrecarga operativa. La opción "Consentimiento y permisos, Configuración de consentimiento del usuario" se encuentra actualmente en versión preliminar. Una vez que esté lista para la disponibilidad general (GA), la característica "Permitir el consentimiento del usuario de los editores verificados, para los permisos seleccionados" debe reducir la sobrecarga de los administradores y se recomienda para la mayoría de las organizaciones.

consentimiento

Formación para los desarrolladores de aplicaciones a fin de que sigan el ecosistema de aplicaciones de confianza Para ayudar a los desarrolladores a crear integraciones seguras y de alta calidad, también presentamos la versión preliminar pública del Asistente de integración en los registros de aplicaciones de Microsoft Entra.

  • El Asistente de integración analiza el registro de la aplicación y lo compara con un conjunto de procedimientos recomendados de seguridad.
  • El Asistente de integración resalta los procedimientos recomendados que son pertinentes durante cada fase del ciclo de vida de la integración (desde el desarrollo hasta la supervisión) y garantiza que todas las fases estén configuradas correctamente.
  • Facilita el trabajo, tanto si va a integrar su primera aplicación como si es un experto que busca mejorar sus aptitudes.

Formación para su organización en tácticas de consentimiento(tácticas de suplantación de identidad [phishing], consentimientos de administrador y usuario):

  • Compruebe si hay errores de ortografía y gramática. Si un mensaje de correo electrónico o la pantalla de consentimiento de la aplicación tienen errores ortográficos y gramaticales, es probable que se trate de una aplicación sospechosa.
  • Esté atento a los nombres de aplicación y las URL de dominio. A los atacantes les gusta suplantar nombres de aplicaciones para dar la impresión de que proceden de aplicaciones o compañías legítimas, pero que lo animan a dar su consentimiento a una aplicación malintencionada.
  • Asegúrese de reconocer el nombre de la aplicación y la URL del dominio antes de dar su consentimiento a una aplicación.

Promoción y autorización del acceso a las aplicaciones de confianza

  • Promueva el uso de aplicaciones cuyo editor se ha comprobado. La comprobación del editor ayuda a los administradores y a los usuarios finales a reconocer la autenticidad de los desarrolladores de aplicaciones. Hasta ahora, se han comprobado más de 660 aplicaciones de 390 editores.
  • Configure directivas de consentimiento de aplicaciones. Para ello, permita a los usuarios dar su consentimiento solo a aplicaciones específicas de confianza, como aplicaciones desarrolladas por su organización o de editores comprobados.
  • Ofrezca formación a su organización sobre cómo funciona nuestro marco de permisos y consentimiento.
  • Comprenda los datos y permisos que una aplicación solicita y aprenda cómo funcionan los permisos y el consentimiento en nuestra plataforma.
  • Asegúrese de que los administradores saben cómo administrar y evaluar las solicitudes de consentimiento.

Audite las aplicaciones y los permisos con consentimiento de su organización para asegurarse de que las aplicaciones en uso acceden solo a los datos que necesitan y se adhieren a los principios de privilegios mínimos.

Mitigaciones

  • Ofrezca formación al cliente, así como concienciación y entrenamiento sobre la protección de las concesiones de consentimiento de la aplicación.
  • Refuerce el proceso de concesiones de consentimiento de la aplicación con controles técnicos y directivas de la organización.
  • Configure Crear programación para revisar las aplicaciones Con consentimiento.
  • Puede usar PowerShell para deshabilitar aplicaciones sospechosas o malintencionadas deshabilitando la aplicación.

Referencias

Las fuentes del contenido de este artículo son las siguientes:

Cuadernos de estrategias de respuesta ante incidentes adicionales

Examine las instrucciones para identificar e investigar estos tipos de ataques adicionales:

Recursos de respuesta a incidentes