Responder manualmente a las amenazas basadas en la identidad hace perder tiempo y puede aumentar tu exposición al riesgo. Es posible que estés filtrando datos sensibles y poniendo en peligro a tu organización. Una forma de reforzar la protección es integrar el Acceso condicional (CA) de Microsoft con activadores de la Graph API y automatización con PowerShell, lo que da como resultado una respuesta automatizada a amenazas.
Así, los MSP (proveedores de servicios gestionados) pueden contener y mitigar amenazas sin depender de plataformas SIEM (gestión de eventos e información de seguridad), que resultan costosas.
Automatizar la respuesta a amenazas con Acceso condicional, Microsoft Graph y PowerShell
Hay varias formas de automatizar la respuesta a amenazas. Puedes configurar políticas de Acceso condicional, usar Microsoft Graph, crear un script de PowerShell, registrar los eventos de respuesta en el Registro y aplicar un comportamiento de cuarentena mediante GPO.
📌 Requisitos previos:
- Azure AD Premium P2 para Identity Protection y Acceso condicional
- Microsoft Defender for Endpoint o una fuente equivalente de señales basadas en riesgo
- Permisos de la API de Microsoft Graph
- PowerShell 7+ con el módulo Microsoft.Graph instalado
📌 Estrategias de implementación recomendadas:
Haz clic para elegir un método | 💻 Ideal para usuarios individuales | 💻💻💻 Ideal para empresas |
| Método 1: configurar políticas de Acceso condicional para la respuesta a amenazas | ✓ | |
| Método 2: usar Microsoft Graph para activar acciones de política en tiempo real | ✓ | |
| Método 3: automatizar la corrección con PowerShell | ✓ | |
| Método 4: registrar los eventos de respuesta a amenazas en el Registro | ✓ | |
| Método 5: usar GPO para aplicar la cuarentena en dispositivos de riesgo | ✓ |
Método 1: configurar políticas de Acceso condicional para la respuesta a amenazas
El primer paso es configurar las políticas de Acceso condicional.
📌 Caso de uso: administradores de TI que crean reglas de Acceso condicional para bloquear o verificar automáticamente los inicios de sesión de riesgo
Crea políticas de Acceso condicional en Entra ID a partir de señales de amenaza:
- Respuesta basada en el riesgo del usuario:
- Señal: UserRiskLevel = High
- Acción: bloquear el acceso o exigir el restablecimiento de la contraseña
- Respuesta basada en el riesgo del dispositivo:
- Señal: DeviceRiskLevel = High (desde Defender)
- Acción: exigir un dispositivo conforme o bloquear el acceso
Ejemplo de expresión de filtro de política:
(device.deviceOwnership -eq «Company») and (device.riskLevel -eq «High»)
Asigna las políticas a los roles más expuestos, como administradores y directivos.
⚠️ Advertencia: las reglas restrictivas pueden dejar fuera a administradores y a otros usuarios legítimos. (Más información en: Aspectos a tener en cuenta)
Método 2: usar Microsoft Graph para activar acciones de política en tiempo real
Puedes recurrir a Microsoft Graph para activar acciones de política en tiempo real.
📌 Caso de uso: administradores de TI que crean un script para consultar los usuarios de riesgo y deshabilitar sus cuentas en tiempo real
- Pulsa Win, escribe PowerShell y haz clic en Ejecutar como administrador.
- Copia y pega los siguientes scripts en la consola y pulsa Intro:
Connect-MgGraph -Scopes "User.ReadWrite.All", «IdentityRiskEvent.Read.All»
foreach ($user in $riskyUsers) { Update-MgUser -UserId $user.Id -AccountEnabled:$false Write-Output «Disabled account: $($user.UserPrincipalName)» } |
💡 Consejo: registra la acción y, si quieres, avisa a un administrador o abre un ticket de PSA para dar visibilidad a los equipos de seguridad.
Método 3: automatizar la corrección con PowerShell
Con PowerShell puedes convertir las detecciones de riesgo en acciones repetibles y auditables.
📌 Caso de uso: administradores de TI que automatizan la recuperación de cuentas forzando el restablecimiento de contraseñas, invalidando tokens y poniendo dispositivos en cuarentena tras detecciones de alto riesgo
Por ejemplo, puedes restablecer la MFA (autenticación multifactor) y forzar un cambio de contraseña con PowerShell.
- Pulsa Win, escribe PowerShell y haz clic en Ejecutar como administrador.
- Copia y pega los siguientes scripts en la consola y pulsa Intro:
Connect-MgGraph -Scopes "User.ReadWrite.All", «IdentityRiskyUser.ReadWrite.All», «Device.ReadWrite.All»
foreach ($user in $riskyUsers) { try { # Invalidate all active sessions Invoke-MgInvalidateUserRefreshToken -UserId $user.Id # Force password reset on next sign-in (requires a temporary password)
Update-MgUser -UserId $user.Id -PasswordProfile @{ Password = $tempPassword ForceChangePasswordNextSignIn = $true } # Quarantine associated device(s) if extension attribute exists $devices = Get-MgUserRegisteredDevice -UserId $user.Id foreach ($device in $devices) { try { Update-MgDevice -DeviceId $device.Id -AdditionalProperties @{ «extensionAttribute1» = «Quarantined» } } catch { Write-Warning «Failed to update device $($device.Id)» } } Write-Output «Remediated: $($user.UserPrincipalName)» } catch { Write-Warning «Failed to remediate user $($user.UserPrincipalName)» } } |
- Poner un dispositivo en cuarentena por etiqueta o filtro de política:
| Update-MgDevice -DeviceId $device.Id -AdditionalProperties @{ «extensionAttribute1» = «Quarantined» } |
💡 Consejo: puedes combinar estos scripts con tareas de RMM o lanzarlos mediante alertas por correo electrónico y Logic Apps.
⚠️ Advertencia: antes de aplicar el cambio de configuración en varios endpoints, conviene probarlo primero en un equipo local. (Más información en: Aspectos a tener en cuenta)
Método 4: registrar los eventos de respuesta a amenazas en el Registro
Este método guarda en el registro los eventos de respuesta locales de los dispositivos que no están cubiertos por Microsoft Defender ni Intune.
📌 Caso de uso: administradores de TI que registran la actividad de respuesta a amenazas en el registro de Windows para mantener un rastro de auditoría local
- Pulsa Win, escribe PowerShell y haz clic en Ejecutar como administrador.
- Copia y pega los siguientes scripts en la consola y pulsa Intro:
New-Item -Path "HKLM:\SOFTWARE\Org\ThreatResponse" -Force
|
También puedes comprobar el contenido de la clave del registro copiando y pegando el siguiente comando:
| reg query HKLM\SOFTWARE\Org\ThreatResponse |
⚠️ Advertencia: editar el registro puede tener consecuencias imprevistas. Hazlo con precaución y crea una copia de seguridad del registro antes de realizar cambios. (Más información en: Aspectos a tener en cuenta)
Método 5: usar GPO para aplicar la cuarentena en dispositivos de riesgo
Puedes usar GPO para aplicar restricciones cuando las claves locales del registro indiquen cuarentena.
📌 Caso de uso: administradores de TI que aplican la cuarentena del endpoint deshabilitando el acceso a internet y las aplicaciones cuando el registro indica un estado de cuarentena
📌 Requisito previo: acceso a GPO para las políticas de cuarentena local
- Pulsa Win + R, escribe gpmc.msc y pulsa Intro.
- Ve a la siguiente ruta:
- Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas de restricción de software
En este ejemplo, puedes restringir el acceso a unidades de red asignadas o bloquear los navegadores de internet.
También puedes comprobar un indicador de cuarentena en el registro y actuar sobre el endpoint. Para ello, ejecuta el siguiente script en PowerShell:
| Script logic (triggered by key):
} |
⚠️ Aspectos a tener en cuenta
| Riesgos | Posibles consecuencias | Cómo revertirlo |
| Las reglas restrictivas pueden bloquear a usuarios legítimos | Los administradores pueden quedarse sin acceso. | Deshabilita o elimina la política en Entra ID. |
| No probar en un equipo local | Implementar un script sin probar puede provocar fallos en los dispositivos por problemas como la incompatibilidad de claves del registro. | Aplica los cambios que quieras en un equipo local y comprueba si la configuración da el resultado previsto. |
| Editar el Registro sin copia de seguridad | Editar el registro de forma incorrecta puede corromperlo, así que conviene crear una copia de seguridad antes. | Exporta la clave del registro antes de los cambios en Archivo > Exportar. |
Otras consideraciones
Para crear protecciones de identidad resistentes, las organizaciones deben centrarse en una segmentación precisa, rutas de escalado claras, visibilidad multicliente y una validación cuidadosa de las señales de amenaza.
Filtros de alcance
Evita aplicar políticas de CA a usuarios que no estén en riesgo, ya que pueden causar interrupciones. Por ejemplo, podrías dejar sin acceso por error a administradores o cuentas de servicio si impones una política de bloqueo estricta. Para evitarlo, puedes usar grupos, atributos o unidades administrativas y dirigir las políticas de CA solo a los grupos de alto riesgo.
Rutas de escalado
Sin un proceso de escalado, algunas señales pueden pasar desapercibidas, o las alertas críticas pueden bloquear a los usuarios sin que haya corrección. Puedes implementar una integración con la gestión de tickets para el seguimiento y la investigación. Esto consiste en derivar los inicios de sesión de alto riesgo y los intentos de acceso bloqueados, o incorporar directamente las detecciones de riesgo de Identity Protection a un sistema de gestión de tickets.
Alertas entre tenants
La falta de visibilidad entre entornos complica a los MSP la gestión de varios tenants. Valora usar bucles de la Graph API o Logic Apps para mejorar la monitorización entre tenants:
- Bucles de la Graph API: consulta Microsoft Graph en cada tenant gestionado para recopilar datos de alertas e inicios de sesión.
- Logic Apps: automatiza la recopilación y el reenvío de alertas a un SIEM centralizado.
Validación de las señales de amenaza
CA puede aplicar políticas a partir de señales de Microsoft Defender, Entra ID e Identity Protection. Aun así, siguen produciéndose falsos positivos, y actuar solo con esas señales puede provocar bloqueos innecesarios. Una forma de evitarlos es exigir más de una señal de riesgo antes de activar un bloqueo.
Solución de problemas habituales
Estos son los problemas más habituales al automatizar la respuesta a amenazas y cómo resolverlos.
Errores de Graph
Si te aparecen errores de Graph, lo ideal es confirmar los permisos de los tokens delegados y de aplicación. Descodifica ambos tokens y busca patrones. Los códigos 401 apuntan a problemas con el token, mientras que los 403 indican permisos insuficientes.
Retrasos en la aplicación de políticas
Las actualizaciones hechas mediante Graph pueden tardar unos minutos en aplicarse, así que conviene confirmarlo con los registros de inicio de sesión. También es recomendable auditar los registros y verificar que el cambio en Graph se ha completado.
La GPO no se activa
Si la GPO no se activa, revisa la frecuencia de actualización de la política y el contexto en el que se ejecuta el script. También puedes forzar una actualización ejecutando gpupdate /force.
Servicios de NinjaOne que facilitan la respuesta automatizada a amenazas
Con NinjaOne, los MSP pueden escalar sus flujos de respuesta en entornos híbridos y no nativos de Microsoft. Los servicios de NinjaOne facilitan la respuesta automatizada a amenazas al:
- Implementar scripts para aislar o etiquetar dispositivos comprometidos
- Monitorizar claves del registro e indicadores de riesgo para activar la corrección
- Etiquetar endpoints para la asignación de políticas
- Activar alertas y automatización de flujos de trabajo según los resultados de los scripts
- Generar informes multicliente sobre eventos de respuesta a amenazas, acciones ejecutadas y endpoints afectados
Reduce el tiempo de permanencia del atacante automatizando la respuesta a amenazas
Automatizar la respuesta a amenazas con el Acceso condicional de Microsoft, la Graph API y PowerShell ayuda a los MSP a contener los riesgos sin herramientas SIEM costosas. También puedes usar herramientas como NinjaOne para reforzar la automatización: implementa scripts, monitoriza endpoints y simplifica la visibilidad y los informes entre tenants.
Temas relacionados:
