Responder manualmente a ameaças baseadas em identidade consome tempo e pode aumentar a exposição a riscos. Dados sensíveis podem estar vazando e colocando a organização em risco. Uma forma de ampliar a proteção é integrar o Microsoft Conditional Access (CA) a gatilhos da Graph API e à automação com PowerShell, o que resulta em resposta automatizada a ameaças.
Assim, os MSPs (provedores de serviços gerenciados) conseguem conter e mitigar ameaças sem depender de plataformas SIEM (Security Information and Event Management) caras.
Como automatizar respostas a ameaças com Conditional Access, Microsoft Graph e PowerShell
Existem várias formas de automatizar respostas a ameaças: configurar políticas de Conditional Access, usar o Microsoft Graph, criar um script de PowerShell, registrar eventos de resposta a ameaças no Registro e usar GPO para aplicar o comportamento de quarentena.
📌 Pré-requisitos:
- Azure AD Premium P2 para Identity Protection e Conditional Access
- Microsoft Defender for Endpoint ou outra fonte equivalente de sinais baseados em risco
- Permissões da Microsoft Graph API
- PowerShell 7+ com o módulo Microsoft.Graph instalado
📌 Estratégias de implantação recomendadas:
Clique para escolher um método | 💻 Melhor para usuários individuais | 💻💻💻 Melhor para empresas |
| Método 1: configurar políticas de Conditional Access para resposta a ameaças | ✓ | |
| Método 2: usar o Microsoft Graph para acionar ações de política em tempo real | ✓ | |
| Método 3: automatizar a remediação com PowerShell | ✓ | |
| Método 4: registrar eventos de resposta a ameaças no Registro | ✓ | |
| Método 5: usar GPO para aplicar o comportamento de quarentena em dispositivos de risco | ✓ |
Método 1: configurar políticas de Conditional Access para resposta a ameaças
O primeiro passo é configurar as políticas de Conditional Access.
📌 Caso de uso: administradores de TI que criam regras de Conditional Access para bloquear ou desafiar automaticamente logins de risco
Crie políticas de Conditional Access no Entra ID para sinais de ameaça:
- Resposta com base no risco do usuário:
- Sinal: UserRiskLevel = High
- Ação: bloquear o acesso ou exigir a redefinição da senha
- Resposta com base no risco do dispositivo:
- Sinal: DeviceRiskLevel = High (do Defender)
- Ação: exigir um dispositivo em conformidade ou bloquear o acesso
Exemplo de expressão de filtro de política:
(device.deviceOwnership -eq "Company") and (device.riskLevel -eq "High")
Atribua as políticas a funções mais expostas a risco, como administradores e executivos.
⚠️ Aviso: regras restritivas podem bloquear administradores e outros usuários legítimos. (Para mais informações, consulte: Pontos de atenção)
Método 2: usar o Microsoft Graph para acionar ações de política em tempo real
O Microsoft Graph permite acionar ações de política em tempo real.
📌 Caso de uso: administradores de TI que criam um script para consultar usuários de risco e desativar as contas deles em tempo real
- Pressione Win, digite PowerShell e clique em Executar como administrador.
- Copie e cole os scripts a seguir no prompt e pressione Enter:
Connect-MgGraph -Scopes "User.ReadWrite.All", "IdentityRiskEvent.Read.All"
foreach ($user in $riskyUsers) { Update-MgUser -UserId $user.Id -AccountEnabled:$false
} |
💡 Dica: registre a ação e, se quiser, notifique um administrador ou abra um ticket no PSA para dar visibilidade às equipes de segurança.
Método 3: automatizar a remediação com PowerShell
Com o PowerShell, dá para transformar detecções de risco em ações repetíveis e auditáveis.
📌 Caso de uso: administradores de TI que automatizam a recuperação de contas forçando a redefinição de senhas, invalidando tokens e colocando dispositivos em quarentena após detecções de alto risco
Por exemplo, é possível redefinir a autenticação multifator (Multi-Factor Authentication) e forçar a redefinição de senha com PowerShell.
- Pressione Win, digite PowerShell e clique em Executar como administrador.
- Copie e cole os scripts a seguir no prompt e pressione Enter:
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 @{
} } catch {
} }
} catch {
} } |
- Colocar o dispositivo em quarentena por tag ou filtro de política:
Update-MgDevice -DeviceId $device.Id -AdditionalProperties @{ "extensionAttribute1" = "Quarantined" } |
💡 Dica: esses scripts podem ser combinados com tarefas do RMM ou acionados por alertas de e-mail e Logic Apps.
⚠️ Aviso: antes de aplicar a mudança de configuração em vários endpoints, teste primeiro em uma máquina local. (Para mais informações, consulte: Pontos de atenção)
Método 4: registrar eventos de resposta a ameaças no Registro
Este método grava eventos de resposta locais no registro para dispositivos que não são cobertos pelo Microsoft Defender nem pelo Intune.
📌 Caso de uso: administradores de TI que registram a atividade de resposta a ameaças no registro do Windows para manter trilhas de auditoria locais
- Pressione Win, digite PowerShell e clique em Executar como administrador.
- Copie e cole os scripts a seguir no prompt e pressione Enter:
New-Item -Path "HKLM:\SOFTWARE\Org\ThreatResponse" -Force
|
Também é possível verificar o conteúdo da chave do registro copiando e colando o seguinte prompt:
| reg query HKLM\SOFTWARE\Org\ThreatResponse |
⚠️ Aviso: editar o registro pode ter consequências não intencionais. Tenha cautela e faça backup do registro antes de qualquer alteração. (Para mais informações, consulte: Pontos de atenção)
Método 5: usar GPO para aplicar o comportamento de quarentena em dispositivos de risco
Com GPO, dá para aplicar restrições quando as chaves do registro local indicam quarentena.
📌 Caso de uso: administradores de TI que impõem a quarentena de endpoints desativando o acesso à internet e os aplicativos quando o registro indica estado de quarentena
📌 Pré-requisito: acesso a GPO para políticas de quarentena local
- Pressione Win + R, digite gpmc.msc e pressione Enter.
- Navegue até o seguinte caminho:
- Configuração do Computador > Configurações do Windows > Configurações de Segurança > Diretivas de Restrição de Software
Neste exemplo, dá para restringir o acesso a unidades mapeadas ou bloquear navegadores de internet.
Também é possível verificar um sinalizador de quarentena no registro e agir sobre o endpoint. Para isso, execute o script a seguir no PowerShell:
| Script logic (triggered by key):
} |
⚠️ Pontos de atenção
| Riscos | Possíveis consequências | Como reverter |
| Regras restritivas podem bloquear usuários legítimos | Administradores podem perder o acesso. | Desative ou exclua a política no Entra ID. |
| Não testar em uma máquina local | Implantar um script sem teste pode fazer os dispositivos travarem por problemas como incompatibilidade de chaves do registro. | Aplique as alterações desejadas em uma máquina local e confirme se a configuração produz o resultado esperado. |
| Editar o Registro sem backup | Editar o registro de forma incorreta pode corrompê-lo, por isso é melhor fazer um backup antes. | Exporte a chave do registro antes das alterações em Arquivo > Exportar. |
Considerações adicionais
Para construir proteções de identidade resilientes, vale focar em segmentação precisa, caminhos de escalonamento claros, visibilidade multi-tenant e validação cuidadosa dos sinais de ameaça.
Filtros de escopo
Evite aplicar políticas de CA que afetem usuários sem risco, já que isso causa transtornos. Por exemplo, uma política de bloqueio rígida pode trancar administradores ou contas de serviço por acidente. Para evitar isso, use grupos, atributos ou unidades administrativas e direcione as políticas de CA apenas aos grupos de alto risco.
Caminhos de escalonamento
Sem um processo de escalonamento, alguns sinais podem passar despercebidos, ou alertas críticos podem bloquear usuários sem qualquer remediação. Integre um sistema de tickets para acompanhamento e investigação. Isso significa encaminhar logins de alto risco, tentativas de acesso bloqueadas ou as próprias detecções de risco do Identity Protection diretamente para um sistema de tickets.
Alertas entre tenants
A falta de visibilidade entre ambientes dificulta o gerenciamento de vários tenants pelos MSPs. Considere loops da Graph API ou Logic Apps para monitorar melhor vários tenants:
- Loops da Graph API: consulte o Microsoft Graph em cada tenant gerenciado para coletar dados de alertas e de login.
- Logic Apps: automatize a coleta e o encaminhamento de alertas para um SIEM central.
Validação dos sinais de ameaça
O CA aplica políticas com base nos sinais do Microsoft Defender, do Entra ID e do Identity Protection. Ainda assim, falsos positivos acontecem, e agir apenas com base nesses sinais pode gerar bloqueios desnecessários. Uma forma de evitar isso é exigir mais de um sinal de risco antes de acionar um bloqueio.
Solução de problemas comuns
Veja a seguir os problemas mais comuns ao automatizar respostas a ameaças e como resolvê-los.
Erros do Graph
Se aparecerem erros do Graph, o ideal é confirmar as permissões dos tokens delegados e de aplicativo. Decodifique os dois tipos de token e procure padrões: o código 401 indica problemas de token, enquanto o 403 aponta permissão insuficiente.
Atrasos na política
Atualizações feitas via Graph podem levar alguns minutos para entrar em vigor, então confirme pelos logs de login. Também vale auditar os logs e verificar se a alteração no Graph foi concluída.
GPO não é acionada
Se a GPO não estiver sendo acionada, verifique a frequência de atualização da política e o contexto de execução do script. Também é possível forçar uma atualização executando gpupdate /force.
Serviços NinjaOne que apoiam a resposta automatizada a ameaças
Com NinjaOne, os MSPs escalam fluxos de resposta em ambientes híbridos e não nativos da Microsoft. Os serviços NinjaOne apoiam a resposta automatizada a ameaças ao:
- implantar scripts para isolar ou marcar dispositivos comprometidos;
- monitorar chaves do registro e indicadores de risco para acionar a remediação;
- marcar endpoints para atribuição de políticas;
- disparar alertas e automação de fluxos de trabalho com base nos resultados dos scripts;
- gerar relatórios entre tenants sobre eventos de resposta a ameaças, ações tomadas e endpoints afetados.
Reduza o tempo de permanência do invasor com a resposta automatizada a ameaças
Automatizar a resposta a ameaças com o Microsoft Conditional Access, a Graph API e o PowerShell ajuda os MSPs a conter riscos sem ferramentas SIEM caras. Ferramentas como NinjaOne também ampliam essa automação: implantam scripts, monitoram endpoints e simplificam a visibilidade e os relatórios entre tenants.
Tópicos relacionados:
