CISA alerta para hardening do Intune. O que isso significa para seus terceiros


Em 11 de março de 2026, um grupo ligado ao Ministério de Inteligência e Segurança do Irã acessou o ambiente Microsoft da Stryker Corporation, obteve privilégios de administrador do Intune e executou um comando de remote wipe nos dispositivos gerenciados pela empresa. Nenhum malware foi implantado. Nenhum ransomware foi utilizado. Os atacantes usaram uma ferramenta legítima de gestão corporativa para apagar dados de dezenas de milhares de endpoints, incluindo servidores, estações de trabalho, laptops e dispositivos pessoais de funcionários registrados por meio do portal da empresa.
A Stryker é uma empresa Fortune 500 de tecnologia médica. 56.000 funcionários. Operações em mais de 60 países. Contratos com o exército dos EUA para equipamentos médicos usados em hospitais militares. O ataque interrompeu pedidos, manufatura e envios. Cirurgias foram adiadas. Funcionários em múltiplos países perderam acesso aos seus dispositivos da noite para o dia.
Os invasores, operando sob a persona Handala, comprometeram uma conta de administrador e criaram uma nova conta Global Administrator. A partir desse único ponto de controle, dispararam comandos de wipe em toda a empresa por meio das funcionalidades nativas do Intune. A investigação, conduzida pela Microsoft DART e pela Palo Alto Unit 42, não encontrou evidências de malware tradicional. Este foi um ataque living-off-the-land, executado inteiramente por meio do plano de gerenciamento.
Sete dias depois, em 18 de março, a CISA emitiu um alerta incentivando todas as organizações dos EUA a reforçar seus sistemas de gerenciamento de endpoints.
O que CISA e Microsoft recomendam
A Microsoft publicou um guia de hardening para o Intune em 14 de março. A CISA endossou esse guia quatro dias depois e ampliou o escopo para cobrir sistemas de gerenciamento de endpoints de forma geral. As recomendações se concentram em três áreas.
Primeiro, least privilege por meio de role-based access control (RBAC). As organizações devem limitar quem possui funções de Global Administrator e Intune Administrator. Essas são funções privilegiadas com permissões amplas que nunca devem ser usadas para tarefas administrativas do dia a dia. O RBAC do Intune permite segmentar permissões por função, região e unidade de negócio. A recomendação inclui adotar elevação de privilégios com tempo limitado por meio do Microsoft Entra Privileged Identity Management, de modo que o acesso administrativo seja temporário, aprovado e auditável.
Segundo, autenticação resistente a phishing e higiene de acesso privilegiado. Toda ação privilegiada no Intune deve exigir autenticação forte e verificada por políticas. A CISA recomenda políticas dedicadas de Conditional Access para funções administrativas, MFA resistente a phishing (tokens de hardware, sem fallback para SMS), exigência de dispositivos em conformidade e restrição de acesso por localização ou rede confiável. Acesso permanente deve ser eliminado.
Terceiro, Multi Admin Approval. Ações de alto impacto, como device wipes, deploy de scripts e alterações em RBAC, devem exigir aprovação de um segundo administrador antes da execução. Esse controle existe especificamente para evitar que uma única conta comprometida provoque destruição em larga escala, exatamente o que ocorreu no caso da Stryker.
O ângulo que a maioria das análises está ignorando
Toda equipe de segurança que lê essa cobertura está fazendo o mesmo exercício interno neste momento: temos essas mesmas lacunas? Esse é o instinto correto. Mas é apenas metade da análise.
A Stryker é um fornecedor. Milhares de sistemas de saúde, hospitais, centros cirúrgicos e instalações médicas governamentais dependem dos produtos e da cadeia de suprimentos da Stryker. Quando o comando de wipe foi executado, ele derrubou sistemas de pedidos. A manufatura parou. Envios foram interrompidos. Cirurgias foram adiadas semanas após o ataque.
Se a Stryker está no seu portfólio de fornecedores, a má configuração do Intune dela se torna sua interrupção operacional. A falha nos controles administrativos dela se torna suas cirurgias atrasadas, seus pedidos não atendidos, seu incidente em nível de conselho. E você não tinha nenhuma visibilidade sobre isso.
A Palo Alto Unit 42 documentou a estratégia desse ator de ameaça de buscar pontos de entrada na cadeia de suprimentos por meio de provedores de TI e serviços para atingir vítimas downstream. O padrão é claro: comprometer o fornecedor, e o impacto se propaga. A pergunta para quem gerencia risco de terceiros é objetiva: você saberia que o ambiente Intune do seu fornecedor tinha contas com privilégios excessivos, MFA fraco ou ausência de aprovação para ações destrutivas?
Se a Stryker está no seu portfólio, esse risco também é seu
A Palo Alto Unit 42 documentou essa estratégia de ataque via cadeia de suprimentos. O caso da Stryker segue esse padrão. A pergunta para qualquer organização que gerencia risco de terceiros é direta: você teria identificado que o ambiente Intune do seu fornecedor tinha contas com privilégios excessivos, MFA fraco ou ausência de controles de aprovação?
Uma ferramenta de security rating outside-in não mostraria isso. Varreduras externas enxergam domínios, certificados, portas abertas, talvez problemas de DNS. Não conseguem ver como o fornecedor configura RBAC dentro do Intune. Não conseguem verificar se contas Global Administrator exigem MFA resistente a phishing. Não conseguem checar se um único administrador pode apagar todos os dispositivos da organização sem revisão.
Esse é o gap de visibilidade que transforma uma má configuração interna do fornecedor em uma interrupção operacional para você.
O que o monitoramento inside-out captura
Quando um terceiro autoriza inside-out scanning do seu ambiente Microsoft, a plataforma de monitoramento pode avaliar o estado real das configurações em múltiplas camadas. Isso importa porque o ataque à Stryker foi uma cadeia, não um evento isolado.
A cadeia começou com roubo de credenciais. Pesquisadores associaram o grupo Handala a campanhas de phishing e malware infostealer direcionadas a organizações dos EUA nos dias anteriores ao ataque. Se o endpoint do administrador comprometido tivesse proteção configurada corretamente, o roubo de credenciais seria mais difícil de executar.
O Zanshin monitora Microsoft Defender for Endpoint junto com Microsoft Intune, ambos como alvos de análise na categoria de Security Tools. Para o Defender, isso significa validar se as configurações de proteção de endpoint estão ativas: políticas anti-malware, detecção comportamental habilitada e cobertura em toda a frota de dispositivos. Também verifica se alertas relacionados a comprometimentos estão sendo tratados de forma adequada. Um ambiente onde o Defender está mal configurado, implantado de forma inconsistente ou não monitorado cria condições para que malware de roubo de credenciais opere sem ser detectado.
Para o Intune, a plataforma verifica se funções de Global Administrator estão atribuídas a um número excessivo de contas ou concentradas em uma única conta sem separação de funções. Também valida se contas privilegiadas possuem MFA habilitado e se utilizam métodos fracos, como SMS, vulneráveis a interceptação.
Essas duas camadas de verificação se conectam diretamente com a cadeia do ataque à Stryker. A camada de proteção de endpoint trata da origem do comprometimento. A camada de configuração do Intune trata da escalada e do impacto.
Essas verificações rodam diariamente. Configurações mudam. Políticas são flexibilizadas durante migrações e não são restauradas. Um questionário preenchido há seis meses não reflete o estado atual do ambiente.
Como o Zanshin aplica isso
O Zanshin inclui o Microsoft Intune como um dos alvos de análise suportados, junto com outras ferramentas como CrowdStrike Falcon Endpoint Security, Microsoft Defender for Endpoint, SentinelOne Singularity Endpoint Security, Bitdefender GravityZone Business Security Enterprise, Trend Vision One Endpoint Security e Sophos Endpoint.
O mecanismo da plataforma executa verificações diárias nos alvos autorizados, avaliando configurações com base em um conjunto de regras que identifica condições inseguras e gera alertas com classificação de severidade e rastreamento completo do ciclo de vida.
O fornecedor recebe o alerta com contexto de remediação. A organização cliente vê o sinal de risco, a severidade e se houve ação. Esse é o modelo cooperativo: visibilidade gera conversa, e a conversa gera correção antes que um atacante explore a mesma falha.
O que isso significa para o seu programa de risco de terceiros
O incidente da Stryker será estudado por anos como um caso em que o plano de gerenciamento se tornou a arma. Sem malware. Sem exploit. Sem zero-day. Apenas uma conta administrativa com acesso excessivo, em um ambiente onde uma única pessoa podia apagar todos os dispositivos da organização.
Se você gerencia risco de terceiros em um sistema de saúde, banco, seguradora ou qualquer organização em um setor regulado, a lição é direta. Seus fornecedores usam Intune ou ferramentas semelhantes para gerenciar endpoints. A segurança dessas configurações impacta diretamente sua continuidade operacional. Um questionário anual perguntando “você usa MFA?” não fornece a resposta necessária. Validação automatizada, recorrente e inside-out fornece.
O alerta da CISA se aplica a todas as organizações. A implicação para risco de terceiros é clara: cada fornecedor do seu portfólio deveria atender a esse mesmo padrão.
Quantos dos seus fornecedores críticos você conseguiria verificar agora, hoje, se estão seguindo essas três recomendações da CISA?
Mais importante, isso não se limita ao Intune. Outras soluções de endpoint, rede, gestão de configuração e segurança também podem ser usadas de forma abusiva com impacto semelhante. É necessário identificar todas e aplicar os mesmos controles para ações críticas.
Se a resposta leva mais do que alguns segundos, esse é o gap que o Zanshin resolve. Solicite uma demonstração para ver como funciona a visibilidade inside-out no seu portfólio de fornecedores.


