Uso de Azure Automation para detectar e informar eventos de auditoría de Microsoft 365

Detección y notificación de eventos de auditoría importantes

Ha sido una época de mucha actividad para quienes se preocupan por la seguridad de Exchange. En el frente local, dos nuevas vulnerabilidades de día cero aparecieron como otro desagradable recordatorio de los peligros que acechan en Internet cuando los atacantes descubren nuevas formas de penetrar incluso en servidores bien administrados. Los servidores locales que no están tan bien administrados son blancos fáciles para los malos, y todavía existen demasiados de ese tipo de servidores.

Debido a las barreras levantadas para proteger Microsoft 365, Exchange Online suele estar a salvo de este tipo de exploits. Sin embargo, como cubrimos antes, una cuenta de administrador de Azure AD comprometida puede llevar a que los atacantes secuestren Exchange Online en un inquilino. Las palabras del vicepresidente de seguridad de Microsoft, Alex Weinert, sobre la importancia de proteger todas las cuentas de Azure AD con MFA deben haber tenido un significado especial para los propietarios del inquilino comprometido.

Todo lo cual me lleva a un artículo del equipo de ciberseguridad de Microsoft (DART) donde revisan importantes fuentes de información forense para investigaciones. A DART le gusta buscar en el registro de auditoría de Azure AD, los inicios de sesión de Azure AD y el registro de auditoría de Office 365 (también conocido como registro de auditoría unificado) para encontrar rastros de actividad de los malos. Esto generó la idea de escribir sobre cómo utilizar el nuevo soporte para identidades administradas en el módulo de administración de Exchange Online (V3) para verificar eventos de auditoría que podrían revelar problemas. Así que allá vamos.

Exchange Online, Azure Automation e identidades administradas

Anteriormente, cubrí cómo usar Exchange Online PowerShell con Azure Automation. Antes de la V3, se podían usar credenciales como un nombre de usuario y una contraseña (almacenadas de forma segura en Azure Key Vault) para iniciar sesión en una cuenta de administrador y ejecutar cmdlets de Exchange. Con V3, puede usar una identidad administrada, tal como puede hacerlo con el SDK de Microsoft Graph PowerShell y los módulos Teams.

La gran ventaja de utilizar una identidad administrada es que Azure se encarga de la seguridad y no hay necesidad de complicarse con contraseñas o certificados. En su lugar, Azure usa los permisos asignados a la cuenta de automatización utilizada con la identidad administrada para permitir o denegar el acceso a los recursos. Es posible que los atacantes intenten comprometer una identidad administrada, pero la probabilidad es baja en comparación con la posibilidad de comprometer una combinación de nombre de usuario y contraseña.

Gestión de riesgos de ciberseguridad para Active Directory

Descubra cómo prevenir y recuperarse de ataques AD a través de estas soluciones de gestión de riesgos de ciberseguridad.

Asignar los permisos correctos

Mi idea es escribir un script de PowerShell que se ejecute como un runbook utilizando una programación propiedad de una identidad administrada por Azure. El guión hace lo siguiente:

Define los eventos de auditoría de alta prioridad a monitorear. El reciente compromiso de un inquilino de Microsoft 365 permitió a los atacantes crear un nuevo conector de entrada y 12 nuevas reglas de transporte. Los atacantes podrían utilizar el inquilino para enviar mucho spam. Mi script busca estos eventos.
Inicia sesión en Exchange Online utilizando una identidad administrada. A la entidad de servicio de la identidad administrada se le debe asignar el permiso Administrar Exchange como aplicación. Para saber cómo asignar el permiso (solo es posible usando PowerShell), lea este artículo.
Busca en el registro de auditoría de Office 365 mediante el cmdlet Search-UnifiedAuditLog. La búsqueda cubre los últimos 30 días. Para los inquilinos de Office 365 E3, podría retroceder 90 días; para inquilinos E5, 365 días. Creo que 30 es razonable dado que deberías comprobar los eventos recientes de forma regular.
Si la búsqueda encuentra algunos registros de auditoría, analice la carga útil de datos de auditoría en cada registro para extraer información importante como el nombre de una regla de transporte o conector, los parámetros utilizados, etc. La carga útil varía de un evento a otro, por lo que si agrega otros eventos a la búsqueda, debe actualizar el script para extraer información de esos eventos.
Ejecute el cmdlet Get-ExoMailbox para obtener el nombre para mostrar de la cuenta que realizó la acción que provocó que se activara el evento de auditoría.
Cree un informe HTML de los datos de auditoría.
Envíe el informe por correo electrónico a una dirección SMTP diseñada. Esto podría ser para una lista de distribución, un grupo de Microsoft 365, un canal de equipo habilitado para correo o un individuo. La idea es que el mensaje sea un llamado a la acción para solicitar a los administradores que verifiquen si las acciones asociadas con los eventos de auditoría de alto perfil son válidas. El script utiliza cmdlets del SDK de Microsoft Graph PowerShell para crear y enviar el mensaje, por lo que la entidad de servicio de la identidad administrada debe tener los permisos de aplicación Graph Mail.ReadWrite y Mail.Send. Estos permisos son muy poderosos (entre los tipos apreciados por los atacantes), por lo que es importante implementarlos junto con una política de acceso a las aplicaciones (que se explica a continuación).

La mayor parte de esto es sencillo y Azure Automation envía debidamente el correo electrónico para solicitar a los administradores que revisen los eventos de auditoría de alta prioridad (Figura 1). Adjuntar el runbook a una programación de Azure Automation garantizará que los administradores de inquilinos reciban notificaciones de forma regular.

Asignación de permisos de gráficos a una identidad administrada

Dos cuestiones merecen una atención adicional. En primer lugar, asignar un permiso Graph como Mail.ReadWrite a la cuenta de automatización utilizada con la identidad administrada es otra operación que solo es posible en PowerShell. Aquí está el código que utilicé:

$ManagedIdentity = Get-MgServicePrincipal -ServicePrincipalId d5469aa1-070f-4008-863b-e69b6646203a
$GraphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'" # Microsoft Graph
$Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq 'Mail.ReadWrite'}

$AppRoleAssignment = @{
     "PrincipalId" = $ManagedIdentity.Id
     "ResourceId" = $GraphApp.Id
     "AppRoleId" = $Role.Id }
# Assign the Graph permission
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id -BodyParameter $AppRoleAssignment

Los pasos del código son:

Obtenga la entidad de servicio para la cuenta de automatización para la identidad administrada mediante el identificador de entidad de servicio. Puede obtener esto seleccionando la identidad administrada en la sección de aplicaciones empresariales del centro de administración de Azure AD y viendo sus propiedades.
Defina el identificador de la aplicación empresarial Microsoft Graph. Este valor es siempre '00000003-0000-0000-c000-000000000000.
Recuperar la función de la aplicación para el permiso que quiero otorgar. El filtro extrae el rol para el rol Mail.ReadWrite.
Utilice la información obtenida para crear los parámetros para la nueva asignación.
Ejecute el cmdlet New-MgServicePrincipalAppRoleAssignment para asignar la función a la entidad de servicio de la cuenta de automatización. La asignación del rol consiente el uso del permiso solicitado.

Proteger buzones de correo contra aplicaciones

En segundo lugar, la cuenta de automatización ahora tiene los permisos de aplicación Mail.ReadWrite y Mail.Send. Microsoft Graph permitirá que el código ejecutado por la cuenta de automatización acceda a cualquier buzón del inquilino y envíe correo electrónico en nombre de cualquier buzón. Establecer una instalación omnipotente para enviar correo electrónico facilita la tarea a los desarrolladores, pero puede ser una pesadilla para la seguridad. Y ahí es donde entran las políticas de acceso a aplicaciones.

Una política de acceso a aplicaciones controla el acceso a los buzones por parte de una aplicación. En nuestro escenario, probablemente solo queramos que el código ejecutado por la cuenta de automatización pueda acceder a una cantidad limitada de buzones de correo, tal vez incluso solo uno. Para que el conjunto de buzones sea fácil de mantener, puede crear una lista de distribución para definir el conjunto de buzones accesibles.

Por ejemplo, este código crea una lista de distribución con seguridad habilitada (no se puede utilizar una lista de distribución normal) y agrega un único buzón a la lista.

New-DistributionGroup -Alias ManagedMailbox.Restrict -PrimarySmtpAddress ManagedMailbox.Restrict@office365itpros.com -Description "Restrict Access for Managed Mailboxes - used with Application Policy" -DisplayName "Restrict Access to Managed Mailbox" -IgnoreNamingPolicy -Name ManagedMailbox.Restrict -Type Security

Set-DistributionGroup -Identity ManagedMailbox.Restrict -ManagedBy Tony.Redmond -HiddenFromAddressListsEnabled $True

Add-DistributionGroupMember -Identity ManagedMailbox.Restrict -Member "Azure.Management.Account@office365itpros.com"

Ahora puedo crear una política de acceso a la aplicación para limitar la cuenta de automatización al conjunto de buzones definidos en la lista de distribución. Inmediatamente después de que la política esté activa, Exchange Online limita la cuenta de automatización, incluidos los runbooks que utilizan la identidad administrada, a los buzones asignados.

New-ApplicationAccessPolicy -AccessRight RestrictAccess -AppId "b977a222-3534-4625-980d-e2f864d3a2d5" -Description "Restrict Mailbox Access to Managed Identity" -PolicyScopeGroupId ManagedMailbox.Restrict

ScopeName        : Restrict Access to Managaed Mailbox
ScopeIdentity    : ManagedMailbox.Restrict
Identity         : a662313f-14fc-43a2-9a7a-d2e27f4f3478\b977a222-3534-4625-980d-e2f864d3a2d5:S-1-5-21-458367025-2064581115-2950179075-49778371;e33e4a0e-149d-4949-8c51-0c849df7b9ea
AppId            : b977a222-3534-4625-980d-e2f864d3a2d5
ScopeIdentityRaw : S-1-5-21-458367025-2064581115-2950179075-49778371;e33e4a0e-149d-4949-8c51-0c849df7b9ea
Description      : Restrict Mailbox Access to Managed Identity
AccessRight      : RestrictAccess
ShardType        : All
IsValid          : True
ObjectState      : Unchanged

El alcance de la política lo establece la lista de distribución creada anteriormente. El valor AppId utilizado en el código es el identificador de la aplicación para la cuenta de automatización, que puede encontrar en el centro de administración de Azure AD examinando las propiedades de la cuenta (Figura 2).

Puede descargar el código del runbook desde GitHub.

La automatización programada es una buena automatización

Proteger a un inquilino requiere trabajo duro y un esfuerzo continuo y persistente. Usar Azure Automation para ejecutar runbooks programados para detectar anomalías es una excelente manera de asegurarse de que nadie se olvide de verificar las cosas. Ahora que el módulo de administración de Exchange Online admite identidades administradas, está disponible un nuevo conjunto de posibilidades. ¡A por ello!