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

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 comprobar lo que ha hecho o simplemente como una estación de calidad para el usuario.
  • 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 del cliente

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. Los módulos de AzureAD y MSOnline de PowerShell están instalados.
  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.

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. Sin embargo, los atacantes pueden usar incorrectamente este consentimiento para lograr persistencia en el entorno y acceder a datos confidenciales. 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 variará 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 obtener más información, consulte:

Clasificación de permisos de riesgo

Hay (como mínimo) miles de permisos en el sistema y no es factible enumerarlos o analizarlos todos. En la lista siguiente se abordarán los permisos que se usan incorrectamente con mayor frecuencia y otros que tendrían un impacto catastrófico si se usan incorrectamente.

En términos generales, hemos 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. Contacts. *
  3. MailboxSettings.*
  4. People.*
  5. Files.*
  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 nuestras observaciones, los atacantes han usado 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 que hemos visto suelen ser generalizados y estar dirigidos a usuarios finales, en lugar de tratarse de suplantación de identidad (phishing) contra administradores que realmente pueden 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
  • Correo electrónico
  • 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, consulte Permisos de Graph.

Flujo de trabajo

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

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:

    • Instale el módulo de PowerShell de Azure AD.
    • Ejecute la aplicación Windows PowerShell con privilegios elevados. (Ejecutar como administrador).
    • Configure PowerShell para ejecutar scripts firmados.
    • 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

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 portal de Azure Active Directory para buscar aplicaciones a las que cualquier usuario individual ha concedido permisos.

  1. Inicie sesión en Azure Portal como administrador.
  2. Seleccione el icono Azure Active Directory.
  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:

  • Herramienta HAWK
  • Módulo de respuesta ante incidentes de AzureAD
  • El script Get-AzureADPSPermissions.ps1 de GitHub.

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 Azure AD 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 escritos incorrectamente Ejemplo de un nombre escrito incorrectamente

    • Nombres inusuales o anodinos 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 Azure AD.

  • 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, tome medidas inmediatas 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 de los usuarios mediante el portal de Azure Active Directory, PowerShell, o hacer que los usuarios enumeren individualmente su acceso de aplicación.

  • Use el portal de Azure Active Directory 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 portal de Azure Active Directory para ver la lista de aplicaciones a las que cualquier usuario individual ha concedido permisos.

  1. Inicie sesión en Azure Portal con derechos administrativos.
  2. Seleccione el icono Azure Active Directory.
  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:

  • Use otras características de auditoría de la aplicación de OAuth en Microsoft Cloud App Security.
  • Use libros de Azure Monitor para supervisar la actividad relacionada con los permisos y el consentimiento. El libro Consent Insights proporciona una vista de las aplicaciones por número de solicitudes de consentimiento con error. Esta información puede resultar útil para clasificar las aplicaciones por orden de prioridad y que los administradores las revisen y decidan si se les concede el consentimiento del administrador.

Después de identificar una aplicación con permisos ilegales, hay varias maneras de quitar ese acceso.

Puede revocar el permiso de la aplicación en el portal de Azure Active Directory.

  1. Vaya al usuario afectado en la pestaña Usuario de Azure Active Directory.

  2. Seleccione Aplicaciones.

    applications

  3. Seleccione la aplicación ilegal.

  4. Seleccione Quitar.

    quitar aplicación

Puede usar PowerShell para revocar la concesión de consentimiento de OAuth mediante los pasos descritos en Remove-AzureADOAuth2PermissionGrant .

En primer lugar, ejecute este comando para recopilar información que tenga en Azure AD para los permisos de concesión de consentimiento.

Get-ADOAuth2PermissionGrantoAuth

Este es un ejemplo de la salida.

Ejemplo de la salida del comando Get-ADOAuth2PermissionGrantoAuth

Puede usar PowerShell para revocar la asignación de roles de la aplicación de servicio mediante los pasos descritos en Remove-AzureADServiceAppRoleAssignment .

Este es un ejemplo.

Remove-AzureADOAuth2PermissionGrant -ObjectId "GbrSwpsCB0ar6c7N7PRvD1bNACUj4C9IspcKu5YkdoE"

Este es un ejemplo de la salida.

Ejemplo de la salida del comando Remove-AzureADOAuth2PermissionGrant

También puede desactivar por completo el inicio de sesión para la cuenta afectada, lo que a su vez desactivará el acceso de la aplicación a los datos de esa cuenta. Esta opción no es ideal para la productividad del usuario final, pero puede ser una corrección viable a corto plazo.

desactivar usuario

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 Azure AD 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 no está habilitado, se muestra el mensaje siguiente:

    AADSTS90094: <clientAppDisplayName> necesita permiso para acceder a los recursos de la organización que solo un administrador puede conceder. Pida a un administrador que conceda permiso a esta aplicación antes de poder usarla. En este caso, también se registrará un evento de auditoría con una categoría de "ApplicationManagement" , un tipo de actividad "Consentimiento a la aplicación" y el motivo de estado de "Aplicación de riesgo 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 Azure AD.

  • 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.
  • Está diseñado para facilitar 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 revocar la concesión de consentimiento de OAuth mediante los pasos descritos en Remove-AzureADOAuth2PermissionGrant.
  • Puede usar PowerShell para revocar la asignación de roles de la aplicación de servicio mediante los pasos descritos en Remove-AzureADServiceAppRoleAssignment.
  • También puede desactivar por completo el inicio de sesión para la cuenta afectada, lo que a su vez desactivará el acceso de la aplicación a los datos de esa cuenta.
  • Puede desactivar las aplicaciones integradas para su inquilino. Se trata de una medida drástica que impide que los usuarios finales concedan consentimiento a las aplicaciones de terceros en todo el inquilino. No obstante, esta opción no se recomienda.

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: