Recuperar-se do comprometimento de identidades sistêmico
Este artigo descreve os recursos e as recomendações da Microsoft para a recuperação de um ataque de comprometimento de identidades sistêmico contra a sua organização.
O conteúdo deste artigo é baseado na orientação fornecida pela DART (Equipe de Detecção e Resposta da Microsoft), que trabalha para responder a comprometimentos e ajudar os clientes a se tornarem resilientes cibernéticos. Para obter mais orientação da equipe DART, consulte as Séries de blogs de segurança da Microsoft.
Muitas organizações têm feito a transição para uma abordagem baseada em nuvem para maior segurança no gerenciamento de identidade e acesso. No entanto, sua organização também pode ter sistemas locais em uso e usar métodos variados de arquitetura híbrida. Este artigo reconhece que ataques de identidade sistêmicos afetam os sistemas em nuvem, locais e híbridos e fornece as recomendações e referências para todos esses ambientes.
Importante
Essas informações são fornecidas no estado em que estão e constituem diretrizes generalizada; a determinação final sobre como aplicar esta orientação ao seu ambiente de TI e locatário(s) deve considerar o ambiente e as necessidades exclusivas, que cada cliente está na melhor posição para determinar.
Sobre o comprometimento de identidades sistêmico
Um ataque de comprometimento de identidades sistêmico em uma organização ocorre quando um invasor obtém uma base na administração da infraestrutura de identidade de uma organização.
Se isso acontecer com a sua organização, você estará em uma corrida contra o invasor para proteger seu ambiente antes que mais danos possam ser causados.
Os invasores com controle administrativo da infraestrutura de identidade de um ambiente podem usar esse controle para criar, modificar ou excluir as identidades e as permissões de identidade nesse ambiente.
Em um comprometimento local, se os certificados de assinatura de tokens SAML confiáveis não forem armazenados em um HSM, o ataque incluirá o acesso a esse certificado de assinatura de token SAML confiável.
Os invasores podem usar o certificado para forjar tokens SAML para representar qualquer um dos usuários e contas existentes da organização sem a necessidade de acesso às credenciais da conta e sem deixar rastreamentos.
O acesso de conta altamente privilegiado também pode ser usado para adicionar credenciais controladas pelo invasor a aplicativos existentes, permitindo que os invasores acessem seu sistema sem ser detectado, como para chamar APIs, usando essas permissões.
Responder ao ataque
A resposta a comprometimentos de identidades sistêmicos deve incluir as etapas mostradas na seguinte imagem e tabela:
| Etapa | Descrição |
|---|---|
| Estabelecer comunicações seguras | Uma organização que passou por um comprometimento sistêmico da identidade deve presumir que toda a comunicação foi afetada. Antes de realizar qualquer ação de recuperação, será necessário garantir que os membros de sua equipe que são essenciais para seu esforço de investigação e resposta possam se comunicar com segurança. Proteger as comunicações deve ser sua primeira etapa para que você possa continuar sem o conhecimento do invasor. |
| Investigar seu ambiente | Após proteger as comunicações em sua equipe de investigação principal, você poderá começar a procurar os pontos de acesso iniciais e as técnicas de persistência. Identifique suas indicações de comprometimentoe, em seguida, procure os pontos de acesso iniciais e a persistência. Ao mesmo tempo, comece a estabelecer as operações de monitoramento contínuo durante os esforços de recuperação. |
| Aperfeiçoar a postura de segurança | Habilite os recursos e as capacidades de segurança seguindo as recomendações de melhores práticas para melhorar a segurança do sistema no futuro. Certifique-se de continuar seus esforços de monitoramento contínuo conforme o tempo passa e o cenário de segurança muda. |
| Recuperar/reter controle | É necessário recuperar o controle administrativo do ambiente do invasor. Após controlar novamente e atualizar a postura de segurança do sistema, corrija ou bloqueie todas as técnicas de persistência possíveis e as novas explorações de acesso inicial. |
Estabelecer comunicações seguras
Antes de começar a responder, tenha certeza de que é possível comunicar-se com segurança sem a intercepção do invasor. Isole todas as comunicações relacionadas ao incidente para que o invasor não seja informado de sua investigação e seja pego de surpresa com suas ações de resposta.
Por exemplo:
Para comunicações iniciais individuais e em grupo, é possível usar chamadas PSTN, pontes de conferência que não estejam conectadas à infraestrutura corporativa e soluções de mensagens criptografadas de ponta a ponta.
As comunicações fora dessas estruturas devem ser tratadas como comprometidas e não confiáveis, exceto se verificadas por meio de um canal seguro.
Após essas conversas iniciais, crie um locatário do Microsoft 365 totalmente novo, isolado do locatário de produção da organização. Crie contas somente para o pessoal-chave que precisa fazer parte da resposta.
Se você criar um novo locatário do Microsoft 365, siga todas as melhores práticas para o locatário e, especialmente, para contas e direitos administrativos. Limite os direitos administrativos, sem nenhuma relação de confiança para aplicativos ou fornecedores externos.
Importante
Não comunique sobre o novo locatário em suas contas de email existentes e potencialmente comprometidas.
Para obter mais informações, consulte Melhores práticas para usar o Microsoft 365 com segurança.
Identifique as indicações de comprometimento
É recomendável que os clientes sigam as atualizações dos fornecedores de sistema, incluindo da Microsoft e de quaisquer parceiros, implementem todas as novas detecções e proteções fornecidas e identifiquem os IOCs (incidentes de comprometimento) publicados.
Verifique se há atualizações nos seguintes produtos de segurança da Microsoft e implemente todas as alterações recomendadas:
- Microsoft Sentinel
- Soluções e serviços de segurança do Microsoft 365
- Segurança do Windows 10 Enterprise
- Microsoft Defender para aplicativos de nuvem
- Microsoft Defender para IoT
Implementar novas atualizações ajudará a identificar campanhas anteriores e impedir campanhas futuras em seu sistema. Tenha em mente que as listas de IOCs podem não ser exaustivas e podem ser expandidas conforme as investigações continuam.
Portanto, é recomendável também realizar as seguintes ações:
Certifique-se de que você aplicou o parâmetro de comparação de segurança da nuvem da Microsoft e de que está monitorando a conformidade por meio do Microsoft Defender para Nuvem.
Incorpore feeds de inteligência contra ameaças no SIEM, como configurando os conectores de dados do Microsoft Purview no Microsoft Sentinel.
Verifique se todas as ferramentas de detecção e resposta estendidas, como Microsoft Defender para IoT, estão usando os dados de inteligência contra ameaças mais recentes.
Para obter mais informações, consulte a documentação de segurança da Microsoft:
Investigar seu ambiente
Assim que os respondentes pelo incidente e o pessoal-chave tiverem um local seguro para colaborar, será possível iniciar a investigação do ambiente comprometido.
Você precisará equilibrar o acesso à parte inferior de cada comportamento anômalo e tomar uma ação rápida para interromper qualquer atividade posterior do invasor. As correções bem-sucedidas requerem uma compreensão do método inicial de entrada e métodos de persistência que o invasor usou, o mais completo possível no momento. Todos os métodos de persistência perdidos durante a investigação podem resultar em acesso contínuo do invasor e um possível novo comprometimento.
Neste ponto, você pode realizar uma análise de risco para priorizar suas ações. Para obter mais informações, consulte:
- Avaliação de risco, vulnerabilidade e ameaça contra datacenter
- Acompanhar e responder a ameaças emergentes com a análise de ameaças
- Gerenciamento de ameaças e vulnerabilidades
Os serviços de segurança da Microsoft fornecem recursos abrangentes para investigações detalhadas. As seções a seguir descrevem as principais ações recomendadas.
Observação
Se você achar que uma ou mais fontes de registros em log listadas não são parte de seu programa de segurança, é recomendável configurá-las o mais rapidamente possível para permitir as detecções e as revisões de logs futuras.
Configure a retenção de log para dar suporte às metas de investigação da sua organização no futuro. Retenha as evidências, conforme necessário, para fins legais, regulatórios ou de seguro.
Investigar e revisar os registros do ambiente de nuvem
Investigue e analise os logs do ambiente de nuvem em busca de ações suspeitas e indicações de comprometimento do invasor. Por exemplo, verifique os seguintes logs:
- UAL (Logs de Auditoria Unificados)
- Logs do Microsoft Entra
- Logs locais do Microsoft Exchange
- Logs de VPN, como do Gateway de VPN
- Logs do sistema de engenharia
- Logs de detecção de antivírus e ponto de extremidade
Examinar os logs de auditoria do ponto de extremidade
Examine os logs de auditoria do ponto de extremidade em busca de alterações locais, como os seguintes tipos de ações:
- Alterações de membros do grupo
- Criação de nova conta de usuário
- Delegações no Active Directory
Considere especialmente qualquer uma dessas alterações que ocorrem com outros sinais típicos de comprometimento ou atividade.
Examine os direitos administrativos em seus ambientes
Examine os direitos administrativos em seus ambientes de nuvem e locais. Por exemplo:
| Ambiente | Descrição |
|---|---|
| Todos os ambientes de nuvem | – Examinar todos os direitos de acesso privilegiado na nuvem e remover as permissões desnecessárias – Implementar o PIM (Privileged Identity Management) – Configurar as políticas de Acesso Condicional para limitar o acesso administrativo durante a proteção |
| Todos os ambientes locais | – Examinar o acesso privilegiado local e remover as permissões desnecessárias – Reduzir a associação de grupos internos – Verificar as delegações do Active Directory – Proteger o ambiente da Camada 0 e limitar quem tem acesso aos ativos da Camada 0 |
| Todos os aplicativos Empresariais | Examinar as permissões delegadas e as concessões de consentimento que permitem qualquer uma das seguintes ações: – Modificar usuários e funções com privilégios – Ler ou acessar todas as caixas de correio – Enviar ou encaminhar email em nome de outros usuários – Acessar todo o conteúdo do site OneDrive ou SharePoint – Adicionar entidades de serviço que podem ler ou gravar no diretório |
| Ambientes do Microsoft 365 | Examinar as definições de acesso e configuração do ambiente Microsoft 365, incluindo: – Compartilhamento online do SharePoint – Microsoft Teams – Power Apps – Microsoft OneDrive for Business |
| Examinar as contas de usuário em seus ambientes | – Examinar e remover as contas de usuários convidados que não são mais necessárias. – Examinar as configurações de email para delegados, permissões de pasta de caixa de correio, registros de dispositivos móveis do ActiveSync, regras de caixa de entrada e opções do Outlook na Web. – Examinar os direitos de ApplicationImpersonation e reduzir qualquer uso da autenticação herdada o máximo possível. – Validar se o MFA é aplicado e se as informações de contato de SSPR (redefinição de senha self-service) de todos os usuários estão corretas. |
Estabelecer monitoramento contínuo
Detectar o comportamento do invasor inclui vários métodos e depende das ferramentas de segurança que sua organização tem disponível para responder ao ataque.
Por exemplo, os serviços de segurança da Microsoft podem ter recursos específicos e diretrizes relevantes para o ataque, conforme descrito nas seções a seguir.
Importante
Se a sua investigação encontrar evidências de permissões administrativas adquiridas por meio do comprometimento em seu sistema, que forneceram acesso à conta de administrador global de sua organização e/ou certificado de assinatura de token SAML confiável, recomendamos executar ações para corrigir e reter o controle administrativo.
Monitoramento com o Microsoft Azure Sentinel
O Microsoft Azure Sentinel tem muitos recursos integrados para ajudar na investigação, como guias de trabalho de busca e regras de análise que podem ajudar a detectar ataques em áreas relevantes do ambiente.
Use o hub de conteúdo do Microsoft Sentinel para instalar soluções de segurança estendidas e conectores de dados que transmitem conteúdo de outros serviços em seu ambiente. Para obter mais informações, consulte:
- Visualizar e analisar o ambiente
- Detectar ameaças prontas para uso
- Descubra e implante as soluções prontas para uso
Monitoramento com o Microsoft Defender para IoT
Se seu ambiente também incluir recursos de OT (Tecnologia Operacional), você poderá ter dispositivos que usam protocolos especializados, que priorizam desafios operacionais em relação à segurança.
Implante Microsoft Defender para IoT para monitorar e proteger esses dispositivos, especialmente aqueles que não são protegidos por sistemas tradicionais de monitoramento de segurança. Instale os sensores de rede do Defender para IoT em pontos específicos de interesse em seu ambiente para detectar ameaças em atividades de rede contínuas usando monitoramento sem agente e inteligência dinâmica contra ameaças.
Para obter mais informações, consulte Introdução ao monitoramento de segurança de rede OT.
Monitoramento com o Microsoft Defender XDR
Recomendamos que você verifique o Microsoft Defender XDR para Ponto de Extremidade e o Microsoft Defender Antivírus para obter orientações específicas relevantes para o seu ataque.
Verifique outros exemplos de detecções, consultas de busca e relatórios de análise de ameaças na central de segurança da Microsoft, como no Microsoft Defender XDR, Microsoft Defender XDR para Identidade e Microsoft Defender para Aplicativos de Nuvem. Para garantir a cobertura, instale o agente do Microsoft Defender para Identidade em servidores ADFS, além de todos os controladores de domínio.
Para obter mais informações, consulte:
- Acompanhar e responder a ameaças emergentes com a análise de ameaças
- Entender o relatório de analistas na análise de ameaças
Monitoramento com Microsoft Entra ID
Os logs de entrada do Microsoft Entra podem mostrar se a autenticação multifator está sendo usada corretamente. Acesse os logs de entrada diretamente da área do Microsoft Entra no portal do Azure, use o cmdlet Get-MgBetaAuditLogSignIn ou visualize-os na área Logs do Microsoft Sentinel.
Por exemplo, pesquise ou filtre os resultados para quando o campo de resultados de MFA tiver um valor de requisito de MFA atendido pela declaração no token. Se a sua organização usa ADFS e as declarações registradas não estão incluídas na configuração do ADFS, essas declarações podem indicar atividade do invasor.
Pesquise ou filtre ainda mais seus resultados para excluir ruídos extras. Por exemplo, talvez você queira incluir resultados somente de domínios federados. Se você encontrar entradas suspeitas, aprofunde-se ainda mais com base em endereços IP, contas de usuário e assim por diante.
A tabela a seguir descreve mais métodos para usar os logs do Microsoft Entra em sua investigação:
| Método | Descrição |
|---|---|
| Analise eventos de entrada suspeita | O Microsoft Entra ID e sua plataforma de Proteção de Identidade podem gerar eventos de risco associados ao uso de tokens SAML gerados pelo invasor. Esses eventos podem ser rotulados como propriedades desconhecidas, endereço IP anônimo, viagem impossível, e assim por diante. É recomendável analisar minuciosamente todos os eventos de risco associados às contas que tenham privilégios administrativos, incluindo aqueles que podem ter sido automaticamente descartados ou corrigidos. Por exemplo, um evento de risco ou um endereço IP anônimo pode ser corrigido automaticamente porque o usuário foi aprovado pela MFA. Certifique de usar o ADFS Connect Health para que todos os eventos de autenticação estejam visíveis no Microsoft Entra ID. |
| Detectar as propriedades de autenticação de domínio | Qualquer tentativa do invasor de manipular as políticas de autenticação de domínio será registrada nos logs de auditoria do Microsoft Entra e refletida no Log de auditoria unificada. Por exemplo, examine todos os eventos associados ao Conjunto de autenticação de domínio no Log de auditoria unificado, nos logs de auditoria do Microsoft Entra e/ou em seu ambiente SIEM para verificar se todas as atividades listadas eram esperadas e planejadas. |
| Detectar credenciais para aplicativos OAuth | Os invasores que ganharam o controle de uma conta com privilégios poderão pesquisar um aplicativo com a capacidade de acessar os emails de qualquer usuário na organização e, em seguida, adicionar credenciais controladas pelo invasor a esse aplicativo. Por exemplo, é possível pesquisar qualquer uma das seguintes atividades, o que seria consistente com o comportamento do invasor: – Adicionar ou atualizar as credenciais de entidades de serviço – Atualizar os certificados e segredos de aplicativos – Adicionar uma concessão de atribuição de função de aplicativo a um usuário – Adicionar o Oauth2PermissionGrant |
| Detectar o acesso ao email por aplicativos | Pesquise por acesso ao email por aplicativos em seu ambiente. Por exemplo, use os recursos de Auditoria (Premium) do Microsoft Purview para investigar contas comprometidas. |
| Detectar entradas não interativas para entidades de serviço | Os relatórios de entrada do Microsoft Entra fornecem os detalhes de todas as entradas não interativas que usaram credenciais de entidades de serviço. Por exemplo, você pode usar os relatórios de entrada para encontrar dados valiosos para sua investigação, como um endereço IP usado pelo invasor para acessar aplicativos de email. |
Aperfeiçoar a postura de segurança
Se um evento de segurança ocorreu em seus sistemas, é recomendável que você reflita sobre sua estratégia e suas prioridades de segurança atuais.
Os respondentes de incidentes são frequentemente solicitados a fornecer recomendações sobre quais investimentos a organização deve priorizar, agora que enfrentou novas ameaças.
Além das recomendações documentadas neste artigo, é preciso considerar priorizar as áreas de foco que são responsivas às técnicas de pós-recuperação usadas por esse invasor e as lacunas de postura de segurança comuns que as habilitam.
As seções a seguir listam recomendações para aperfeiçoar a postura de segurança geral e de identidade.
Aperfeiçoar a postura geral de segurança
Recomendamos as seguintes ações para garantir a postura geral de segurança:
Examine o Microsoft Secure Score para obter as recomendações básicas de segurança personalizadas para os produtos e serviços da Microsoft que você consome.
Verifique se sua organização tem soluções XDR (detecção e resposta estendidas) e SIEM (gerenciamento de eventos e informações de segurança) em vigor, como Microsoft Defender XDR para Ponto de Extremidade, Microsoft Sentinel e Microsoft Defender para IoT.
Examinar o modelo de acesso Enterprise da Microsoft
Aperfeiçoar a postura de segurança de identidade
Recomendamos as seguintes ações para garantir a postura de segurança relacionada à identidade:
Examine as Cinco etapas da Microsoft para proteger sua infraestrutura de identidade e priorize as etapas conforme apropriado à sua arquitetura de identidade.
Considere migrar os Padrões de Segurança do Microsoft Entra para sua política de autenticação.
Elimine o uso de autenticação herdada da organização, se os sistemas ou os aplicativos ainda exigirem. Para obter mais informações, consulte Bloqueio de autenticação herdada para o Microsoft Entra ID com o Acesso Condicional.
Trate a infraestrutura do ADFS e a infraestrutura do AD Connect como um ativo da Camada 0.
Restrinja o acesso administrativo local ao sistema, incluindo a conta usada para executar o serviço ADFS.
O privilégio mínimo necessário para a conta que executa o ADFS é a Atribuição de Direitos de Usuário Fazer logon como um Serviço.
Restrinja o acesso administrativo a usuários limitados e a intervalos de endereços IP limitados, usando as políticas de Firewall do Windows para Área de Trabalho Remota.
É recomendável configurar uma caixa de salto da Camada 0 ou um sistema equivalente.
Bloqueie todo o acesso de entrada de SMB em sistemas de qualquer lugar do ambiente. Para obter mais informações, consulte Além da borda: como proteger o tráfego de SMB no Windows. É recomendável também transmitir os logs do Firewall do Windows para um SIEM para monitoramento histórico e proativo.
Se você estiver usando uma Conta de Serviço e seu ambiente for compatível com ela, migre de uma Conta de Serviço para uma gMSA (Conta de Serviço Gerenciado de Grupo) . Se não for possível mover para uma gMSA, gire a senha na Conta de Serviço para uma senha complexa.
Verifique se o log detalhado está habilitado em seus sistemas ADFS.
Corrigir e reter o controle administrativo
Se sua investigação identificou que o invasor tem controle administrativo na nuvem da organização ou no ambiente local, você deverá recuperar o controle para garantir que o invasor não persista.
Esta seção fornece os métodos e as etapas possíveis a serem considerados quando você compilar o plano de recuperação de controle administrativo.
Importante
As etapas exatas necessárias para a organização dependerão da persistência que você descobriu na investigação e qual o nível de confiança você tem de que a investigação foi concluída e todos os métodos de entrada e persistência possíveis foram descobertos.
Verifique se todas as ações executadas são realizadas de um dispositivo confiável, criado com base em uma fonte limpa. Por exemplo, use uma nova estação de trabalho com acesso privilegiado.
As seções a seguir incluem os seguintes tipos de recomendações para corrigir e reter o controle administrativo:
- Remover a confiança dos servidores atuais
- Alternar o certificado de assinatura de token SAML ou substituir os servidores ADFS, se necessário
- Especificar as atividades de correção para ambientes de nuvem ou locais
Remover a confiança dos servidores atuais
Se a organização perdeu o controle dos certificados de autenticação de tokens ou da confiança federada, a abordagem mais segura é remover a confiança e alternar para a identidade controlada pela nuvem durante a correção local.
Remover a confiança e alternar para a identidade mestre em nuvem requer um planejamento cuidadoso e uma compreensão profunda dos efeitos de operação de negócios do isolamento da identidade. Para obter mais informações, consulte Proteger o Microsoft 365 de ataques locais.
Alternar o certificado de autenticação de tokens SAML
Se a organização decidir nãoremover a confiança durante a recuperação do controle administrativo local, será necessário alternar o certificado de autenticação de tokens SAML após recuperar o controle administrativo local e bloquear a capacidade dos invasores de acessar o certificado de autenticação novamente.
Alternar o certificado de autenticação de tokens uma única vez ainda permitirá que o certificado de autenticação de tokens anterior funcione. Continuar permitindo que os certificados anteriores funcionem é uma funcionalidade integrada para rotações normais de certificados, o que permitirá um período de carência para que as organizações atualizem todas as relações de confiança de terceiros antes que o certificado expire.
Se houve um ataque, você não quer que o invasor retenha o acesso. Certifique-se de que o invasor não consiga forjar tokens para seu domínio.
Para saber mais, veja:
Substituir os servidores ADFS
Se, em vez de girar o certificado de autenticação de tokens SAML, você decidir substituir os servidores ADFS por sistemas limpos, será necessário remover o ADFS existente do ambiente e, em seguida, criar um novo.
Para obter mais informações, consulte Remover uma configuração.
Atividades de correção de nuvem
Além das recomendações listadas anteriormente neste artigo, também recomendamos as seguintes atividades para os ambientes de nuvem:
| Atividade | Descrição |
|---|---|
| Redefinir senhas | Redefinir as senhas em contas de emergência e reduzir o número de contas de emergência ao mínimo necessário. |
| Restringir contas de acesso privilegiado | Certifique que as contas de serviço e de usuário com acesso privilegiado sejam contas somente de nuvem e não use contas locais sincronizadas ou federadas com o Microsoft Entra ID. |
| Impor a MFA | Impor a MFA (Autenticação Multifator) em todos os usuários elevados no locatário. É recomendável impor a MFA em todos os usuários no locatário. |
| Limitar o acesso administrativo | Implementar PIM(Privileged Identity Management) e acesso condicional para limitar o acesso administrativo. Para usuários do Microsoft 365, implementar PAM (Privileged Access Management) para limitar o acesso a recursos confidenciais como Descoberta Eletrônica, Administrador Global, Administração de Conta e muito mais. |
| Revisar/reduzir permissões delegadas e concessões de consentimento | Revisar e reduzir todas as permissões delegadas de aplicativos corporativos ou concessões de consentimento que permitem qualquer uma das seguintes funcionalidades: – Modificar usuários e funções com privilégios – Ler, enviar email ou acessar todas as caixas de correio – Acessar o conteúdo do OneDrive, Teams ou SharePoint – Adicionar Entidades de Serviço que podem ler ou gravar no diretório – Permissões de aplicativo versus acesso delegado |
Atividades de correção local
Além das recomendações listadas anteriormente neste artigo, também recomendamos as seguintes atividades para os ambientes locais:
| Atividade | Descrição |
|---|---|
| Recompilar os sistemas afetados | Recompilar os sistemas que foram identificados como comprometidos pelo invasor durante a investigação. |
| Remover usuários administradores desnecessários | Remover membros desnecessários dos grupos de Administradores de Domínio, Operadores de Backup e Admin Corporativo. Para obter mais informações, consulte Protegendo o Acesso Privilegiado. |
| Redefinir senhas para contas privilegiadas | Redefina senhas de todas as contas privilegiadas no ambiente. Observação: as contas privilegiadas não estão limitadas a grupos integrados, mas também podem ser grupos que têm acesso delegado à administração do servidor, à administração da estação de trabalho ou a outras áreas do seu ambiente. |
| Redefinir a conta krbtgt | Redefinira conta krbtgt duas vezes usando o script New-KrbtgtKeys. Observação: se você estiver usando Controladores de Domínio Somente Leitura, será necessário executar o script separadamente para os Controladores de Domínio de Leitura/Gravação e para os Controladores de Domínio Somente Leitura. |
| Agendar uma reinicialização do sistema | Após validar que nenhum mecanismo de persistência criado pelo invasor existe ou permanece no sistema, agendar uma reinicialização do sistema para ajudar na remoção do malware residente na memória. |
| Redefinir a senha DSRM | Redefinir a senha de DSRM (Modo de Restauração dos Serviços de Diretório) de cada controlador de domínio para algo exclusivo e complexo. |
Corrigir ou bloquear a persistência descoberta durante a investigação
A investigação é um processo iterativo e você precisará equilibrar o desejo organizacional de correção à medida que identificar anomalias e a chance de que a correção alerte o invasor para sua detecção e dê a ele tempo para reagir.
Por exemplo, um invasor ciente da detecção pode alterar as técnicas ou criar mais persistência.
Corrija as técnicas de persistência que você identificou nos estágios anteriores da investigação.
Corrigir o acesso do usuário e da conta de serviço
Além das ações recomendadas listadas acima, recomendamos que você considere as seguintes etapas para corrigir e restaurar as contas de usuário:
Impor o acesso condicional com base em dispositivos confiáveis. Se possível, é recomendável impor o acesso condicional com base na localização para atender aos seus requisitos organizacionais.
Redefinir as senhas após remover as contas de usuário que possam ter sido comprometidas. Implemente também um plano de médio prazo para redefinir as credenciais de todas as contas no seu diretório.
Revogar tokens de atualização imediatamente após girar suas credenciais.
Para saber mais, veja:
Próximas etapas
Obtenha ajuda nos produtos da Microsoft, incluindo o portal do Microsoft Defender, o portal de conformidade do Microsoft Purview e o Centro de Conformidade e Segurança do Office 365, selecionando o botão Ajuda (?) na barra de navegação superior.
Para obter assistência de implantação, fale conosco pelo FastTrack
Se você tiver necessidades relacionadas ao suporte do produto, registre um caso de suporte da Microsoft.
Importante
Se você acredita que foi comprometido e precisa de assistência por meio de uma resposta a incidentes, abra um caso de suporte da Microsoft Sev A.