Advanced Threat Analytics guia de atividades suspeitas

Aplica-se a: Advanced Threat Analytics versão 1.9

Após a investigação adequada, qualquer atividade suspeita pode ser classificada como:

• Verdadeiro positivo: uma ação maliciosa detectada pelo ATA.

• Positivo verdadeiro benigno: uma ação detectada pelo ATA que é real, mas não mal-intencionada, como um teste de penetração.

• Falso positivo: um alarme falso, o que significa que a atividade não aconteceu.

Para obter mais informações sobre como trabalhar com alertas do ATA, consulte Trabalhando com atividades suspeitas.

Para perguntas ou comentários, entre em contato com a equipe do ATA em ATAEval@microsoft.com.

Modificação anormal de grupos confidenciais

Description

Os atacantes adicionam utilizadores a grupos altamente privilegiados. Eles fazem isso para obter acesso a mais recursos e obter persistência. As detecções dependem do perfilamento das atividades de modificação do grupo de usuários e do alerta quando se observa uma adição anormal a um grupo sensível. A criação de perfil é executada continuamente pelo ATA. O período mínimo antes que um alerta possa ser disparado é um mês por controlador de domínio.

Para obter uma definição de grupos confidenciais no ATA, consulte Como trabalhar com o console do ATA.

A detecção depende de eventos auditados em controladores de domínio. Para garantir que os controladores de domínio auditem os eventos necessários, use te ferramenta.

Investigação

1. A modificação de grupo é legítima?
   Modificações legítimas de grupo que raramente ocorrem e que não são consideradas "normais" podem causar um alerta, que seria considerado um verdadeiro positivo benigno.

2. Se o objeto adicionado for uma conta de usuário, verifique quais ações a conta de usuário tomou após ser adicionada ao grupo de administradores. Vá para a página do usuário no ATA para obter mais contexto. Havia outras atividades suspeitas associadas à conta antes ou depois da adição ter ocorrido? Baixe o relatório de modificação de grupo confidencial para ver quais outras modificações foram feitas e por quem durante o mesmo período de tempo.

Remediação

Minimize o número de usuários autorizados a modificar grupos confidenciais.

Configurar Gerenciamento de Acesso Privilegiado para o Active Directory caso aplicável.

Confiança interrompida entre computadores e domínio

Description

Confiança interrompida significa que os requisitos de segurança do Active Directory podem não estar em vigor para esses computadores. Isso é considerado uma falha de segurança e conformidade de base e um alvo vulnerável para invasores. Nessa detecção, um alerta será disparado se mais de cinco falhas de autenticação Kerberos forem vistas de uma conta de computador dentro de 24 horas.

Investigação

O computador que está sendo investigado permite que usuários de domínio façam login?

• Se sim, você poderá ignorar este computador nas etapas de correção.

Remediação

Reingresse a máquina no domínio, se necessário, ou redefina a senha da máquina.

Ataque de força bruta usando vinculação simples LDAP

Description

Em um ataque de força bruta, um invasor tenta autenticar com muitas senhas diferentes para contas diferentes até que uma senha correta seja encontrada para pelo menos uma conta. Uma vez encontrado, um invasor pode entrar usando essa conta.

Nessa detecção, um alerta é disparado quando o ATA detecta um grande número de autenticações de associação simples. Isso pode ser horizontalmente com um pequeno conjunto de senhas em muitos usuários; ou verticalmente" com um grande conjunto de senhas em apenas alguns usuários; ou qualquer combinação dessas duas opções.

Investigação

1. Se houver muitas contas envolvidas, selecione Baixar detalhes para visualizar a lista em uma planilha do Excel.

2. Selecione o alerta para ir para sua página dedicada. Verifique se as tentativas de logon terminaram com uma autenticação bem-sucedida. As tentativas apareceriam como contas estimadas no lado direito do infográfico. Se sim, alguma das contas presumidas é normalmente usada no computador de origem? Se sim, suprime a atividade suspeita.

3. Se não houver nenhuma conta adivinhada, alguma das contas atacadas normalmente será usada no computador de origem? Se sim, suprime a atividade suspeita.

Remediação

Senhas complexas e longas fornecem o primeiro nível necessário de segurança contra ataques de força bruta.

Atividade de redução de criptografia

Description

O downgrade de criptografia é um método de enfraquecer Kerberos, rebaixando o nível de criptografia de diferentes campos do protocolo que normalmente são criptografados usando o nível mais alto de criptografia. Um campo encriptado enfraquecido pode ser um alvo mais fácil para tentativas de força bruta offline. Vários métodos de ataque utilizam cifras de encriptação Kerberos fracas. Nessa detecção, o ATA aprende os tipos de criptografia Kerberos usados por computadores e usuários e alerta quando uma criptografia mais fraca é usada que: (1) é incomum para o computador de origem e/ou usuário; e (2) corresponde a técnicas de ataque conhecidas.

Há três tipos de detecção:

1. Skeleton Key – é um malware que é executado em controladores de domínio e permite a autenticação para o domínio com qualquer conta sem saber sua senha. Este software maligno utiliza frequentemente algoritmos de encriptação mais fracos para hashar as palavras-passe do utilizador no controlador de domínio. Nessa detecção, o método de criptografia da mensagem KRB_ERR do controlador de domínio para a conta que solicita o tíquete foi reduzido em comparação com o comportamento aprendido anteriormente.

2. Golden Ticket – Em um alerta Golden Ticket, o método de criptografia do campo TGT da mensagem TGS_REQ (solicitação de serviço) do computador de origem foi rebaixado em comparação com o comportamento aprendido anteriormente. Isto não se baseia numa anomalia de tempo (como na outra deteção de Permissão Dourada). Além disso, não houve nenhuma solicitação de autenticação Kerberos associada à solicitação de serviço anterior detectada pelo ATA.

3. Overpass-the-Hash – Um invasor pode usar um hash roubado fraco para criar um tíquete forte, com uma solicitação AS Kerberos. Nessa detecção, o tipo de criptografia de mensagem AS_REQ do computador de origem foi rebaixado em comparação com o comportamento aprendido anteriormente (ou seja, o computador estava usando a AES).

Investigação

Primeiro, verifique a descrição do alerta para ver com qual dos três tipos de detecção acima você está lidando. Para obter mais informações, baixe a planilha Excel.

1. Skeleton Key – Verifique se a Skeleton Key afetou seus controladores de domínio.
2. Golden Ticket – Na planilha Excel, vá para o diretório Atividade de rede. Você verá que o campo relevante com downgrade é Request Ticket Encryption Type, e Source Computer Supported Encryption Types lista métodos de criptografia mais fortes. 1.Verifique o computador de origem e a conta ou se há vários computadores de origem e contas verificam se eles têm algo em comum (por exemplo, toda a equipe de marketing usa um aplicativo específico que pode estar fazendo com que o alerta seja disparado). Há casos em que um aplicativo personalizado que raramente é usado é autenticado usando uma criptografia inferior. Verifique se há aplicativos personalizados no computador de origem. Se assim for, provavelmente é um verdadeiro positivo benigno e você pode suprimi-lo. 2. Verifique o recurso acessado por esses tíquetes. Se houver um recurso que todos eles estão acessando, valide-o e verifique se é um recurso válido que eles devem acessar. Além disso, verifique se o recurso de destino dá suporte a métodos de criptografia fortes. Você pode verificar isso em Active Directory verificando o atributo msDS-SupportedEncryptionTypes, da conta de serviço de recurso.
3. Overpass-the-Hash – Na planilha Excel, vá para a guia Atividade da rede. Você verá que o campo relevante com downgrade é o Encrypted Timestamp Encryption Type e Source Computer Supported Encryption Types abrange métodos de criptografia mais robustos. 1.Há casos em que esse alerta pode ser disparado quando os usuários entrarem usando cartões inteligentes se a configuração do cartão inteligente tiver sido alterada recentemente. Verifique se houve alterações como esta para as contas envolvidas. Se assim for, este é provavelmente um verdadeiro positivo benigno e você pode suprimi-lo . 1.Verifique o recurso acessado por esses tíquetes. Se houver um recurso que todos eles estão acessando, valide-o e verifique se é um recurso válido que eles devem acessar. Além disso, verifique se o recurso de destino dá suporte a métodos de criptografia fortes. Você pode verificar isso em Active Directory verificando o atributo msDS-SupportedEncryptionTypes, da conta de serviço de recurso.

Remediação

1. Skeleton Key – Remover o malware. Para obter mais informações, consulte Skeleton Key Malware Analysis.

2. Golden Ticket – Siga as instruções das atividades suspeitas do Golden Ticket . Além disso, como a criação de um Golden Ticket requer direitos de administrador de domínio, implemente as recomendações de Pass the Hash.

3. Overpass-the-Hash – se a conta envolvida não for confidencial, redefina a senha dessa conta. Isso impede que o invasor crie novos tíquetes Kerberos a partir do hash de senha, embora os tíquetes existentes ainda possam ser usados até expirarem. Se for uma conta confidencial, considere redefinir a conta KRBTGT duas vezes, como é feito em casos de atividade suspeita do Golden Ticket. A redefinição do KRBTGT invalida duas vezes todos os tíquetes Kerberos nesse domínio, portanto, planeje antes de fazer isso. Consulte as orientações no artigo da conta KRBTGT. Como essa é uma técnica de movimento lateral, siga as práticas recomendadas de Pass the hash.

Atividade honeytoken

Description

As contas Honeytoken são contas de engodo configuradas para identificar e controlar atividades maliciosas que envolvem estas contas. As contas honeytoken devem ser deixadas sem uso, enquanto têm um nome atraente para atrair invasores (por exemplo, SQL-Admin). Qualquer atividade deles pode indicar comportamento mal-intencionado.

Para obter mais informações sobre contas de token honey, consulte Instalar o ATA – Etapa 7.

Investigação

1. Verifique se o proprietário do computador de origem usou a conta Honeytoken para autenticar, usando o método descrito na página de atividade suspeita (por exemplo, Kerberos, LDAP, NTLM).

2. Navegue até as páginas de perfil do computador de origem e verifique quais outras contas foram autenticadas nelas. Verifique com os proprietários dessas contas se eles usaram a conta Honeytoken.

3. Isso pode ser um logon não interativo, portanto, verifique se há aplicativos ou scripts em execução no computador de origem.

Se depois de executar as etapas 1 a 3, se não houver nenhuma evidência de uso benigno, suponha que isso seja mal-intencionado.

Remediação

Verifique se as contas Honeytoken são usadas apenas para a finalidade pretendida, caso contrário, podem gerar muitos alertas.

Roubo de identidade usando o ataque Pass-the-Hash

Description

Pass-the-Hash é uma técnica de movimento lateral na qual os atacantes roubam o hash NTLM de um utilizador de um computador e o utilizam para obter acesso a outro computador.

Investigação

O hash foi usado de um computador que pertence ou é usado regularmente pelo usuário alvo? Se sim, o alerta é um falso positivo, se não, provavelmente é um verdadeiro positivo.

Remediação

1. Se a conta envolvida não for confidencial, redefina a senha dessa conta. Redefinir a senha impede que o invasor crie novos tíquetes Kerberos a partir do hash de senha. Os tíquetes existentes ainda podem ser utilizáveis até expirarem.

2. Se a conta envolvida for sensível, considere redefinir a conta KRBTGT duas vezes, como ocorre na atividade suspeita do Golden Ticket. Reinicializar o KRBTGT duas vezes invalida todos os tíquetes Kerberos de domínio, portanto, planeje com antecedência devido ao impacto antes de executar esta ação. Consulte as orientações no artigo da conta KRBTGT. Como essa é normalmente uma técnica de movimento lateral, siga as práticas recomendadas de Pass the hash recommendations.

Roubo de identidade através do ataque Pass-the-Ticket

Description

Pass-the-Ticket é uma técnica de movimentação lateral na qual os atacantes roubam um ticket Kerberos de um computador e o utilizam para obter acesso a outro computador reutilizando o ticket roubado. Nesta detecção, um ticket Kerberos é utilizado em dois (ou mais) computadores.

Investigação

1. Selecione o botão Baixar detalhes para exibir a lista completa de endereços IP envolvidos. O endereço IP de um ou ambos os computadores faz parte de uma sub-rede alocada a partir de um pool DHCP subdimensionado, como VPN ou WiFi? O endereço IP é compartilhado? Por exemplo, por um dispositivo NAT? Se a resposta a qualquer uma dessas perguntas for sim, o alerta será um falso positivo.

2. Há um aplicativo personalizado que encaminha tíquetes em nome dos usuários? Se sim, é um verdadeiro positivo benigno.

Remediação

1. Se a conta envolvida não for confidencial, redefina a senha dessa conta. A redefinição de senha impede que o invasor crie novos tíquetes Kerberos a partir do hash de senha. Todos os tíquetes existentes permanecem utilizáveis até expirarem.

2. Se for uma conta confidencial, considere redefinir a conta KRBTGT duas vezes, como é feito em casos de atividade suspeita do Golden Ticket. A redefinição do KRBTGT invalida duas vezes todos os tíquetes Kerberos nesse domínio, portanto, planeje antes de fazer isso. Consulte as orientações no artigo da conta KRBTGT. Como essa é uma técnica de movimento lateral, siga as práticas recomendadas nas recomendações para Pass the Hash.

Atividade do Kerberos Golden Ticket

Description

Invasores com direitos de administrador de domínio podem comprometer sua conta KRBTGT. Os invasores podem usar a conta KRBTGT para criar um TGT (tíquete de concessão de tíquete Kerberos) fornecendo autorização para qualquer recurso. A expiração do tíquete pode ser definida como qualquer hora arbitrária. Esse TGT falso é chamado de "Golden Ticket" e permite que os invasores alcancem e mantenham a persistência em sua rede.

Nessa detecção, um alerta é disparado quando um TGT (tíquete de concessão de tíquete Kerberos) é utilizado por um período superior ao permitido, conforme especificado na política de segurança tempo máximo de vida para tíquete de usuário.

Investigação

1. Houve alguma alteração recente (nas últimas horas) feita na configuração tempo de vida máximo do tíquete de usuário na política de grupo? Se sim, feche o alerta (era um falso positivo).

2. O Gateway do ATA envolvido neste alerta é uma máquina virtual? Caso positivo, foi retomado recentemente de um estado salvo? Em caso afirmativo, feche este alerta.

3. Se a resposta para as perguntas acima for não, suponha que seja mal-intencionado.

Remediação

Altere a senha do Tíquete de Concessão de Tíquete Kerberos (KRBTGT) duas vezes de acordo com as diretrizes no artigo da conta KRBTGT. A redefinição do KRBTGT invalida duas vezes todos os tíquetes Kerberos nesse domínio, portanto, planeje antes de fazer isso. Além disso, como a criação de um Golden Ticket requer direitos de administrador de domínio, implemente as recomendações de Pass the Hash.

Solicitação maliciosa de proteção de informações privadas de dados

Description

A API de Proteção de Dados (DPAPI) é utilizada pelo Windows para proteger de forma segura palavras-passe guardadas por browsers, ficheiros encriptados e outros dados confidenciais. Os controladores de domínio contêm uma chave mestra de backup que pode ser utilizada para descriptografar todos os segredos criptografados com DPAPI em máquinas Windows associadas a um domínio. Os invasores podem usar essa chave mestra para descriptografar qualquer segredo protegido pelo DPAPI em todas as máquinas ingressadas no domínio. Nessa detecção, um alerta é disparado quando o DPAPI é usado para recuperar a chave mestra de backup.

Investigação

1. O computador de origem está executando um scanner de segurança avançado aprovado pela organização contra Active Directory?

2. Caso a resposta seja sim e deve sempre fazer isso, feche e exclua a atividade suspeita.

3. Se sim e não deve fazer isso, feche a atividade suspeita.

Remediação

Para usar o DPAPI, um invasor precisa de direitos de administrador de domínio. Implemente as recomendações de Pass the Hash.

Replicação maliciosa dos Serviços de Diretório

Description

A replicação do Active Directory é o processo através do qual as alterações efetuadas num controlador de domínio são sincronizadas com todos os outros controladores de domínio. Com as permissões necessárias, os atacantes podem iniciar um pedido de replicação, permitindo-lhes obter os dados armazenados no Active Directory, incluindo hashes de palavras-passe.

Nesta deteção, é acionado um alerta quando um pedido de replicação é iniciado a partir de um computador que não é um controlador de domínio.

Investigação

1. O computador em questão é um controlador de domínio? Por exemplo, um controlador de domínio recém-promovido que tinha problemas de replicação. Se sim, feche a atividade suspeita.
2. O computador em questão deveria estar replicando dados de Active Directory? Por exemplo, Microsoft Entra Connect. Se sim, feche e exclua a atividade suspeita.
3. Selecione o computador de origem ou a conta para acessar sua página de perfil. Verifique o que aconteceu na hora da replicação, procurando atividades incomuns, como: quem foi conectado, quais recursos foram acessados.

Remediação

Valide as seguintes permissões:

• Replicar alterações de diretório

• Replicar todas as alterações de diretório

Para obter mais informações, consulte as permissões Grant Active Directory Domain Services para sincronização de perfil no Servidor do SharePoint 2013. Você pode aproveitar AD ACL Scanner ou criar um script do PowerShell Windows para determinar quem no domínio tem essas permissões.

Exclusão maciça de objeto

Description

Em alguns cenários, os invasores executam ataques de DoS (negação de serviço) em vez de apenas roubar informações. Excluir um grande número de contas é um método de tentativa de ataque do DoS.

Nessa detecção, um alerta é disparado sempre que mais de 5% de todas as contas são excluídas. A detecção requer acesso de leitura ao contêiner de objeto excluído. Para obter informações sobre como configurar permissões somente leitura no contêiner de objeto excluído, consulte Alterando permissões em um contêiner de objeto excluído em Exibir ou Definir Permissões em um Objeto de Diretório.

Investigação

Examine a lista de contas excluídas e determine se há um padrão ou um motivo comercial que justifique uma exclusão em larga escala.

Remediação

Remova permissões para usuários que podem excluir contas no Active Directory. Para obter mais informações, consulte Exibir ou definir permissões em um objeto de diretório.

Escalonamento de privilégios usando dados de autorização forjados

Description

Vulnerabilidades conhecidas em versões mais antigas do Windows Server permitem que os invasores manipulem o PAC (Certificado de Atributo Privilegiado). PAC é um campo no tíquete Kerberos que tem dados de autorização do usuário (em Active Directory isso é associação de grupo) e concede aos invasores privilégios adicionais.

Investigação

1. Selecione o alerta para acessar a página de detalhes.

2. O computador de destino (na coluna ACCESSED) está atualizado com MS14-068 (controlador de domínio) ou MS11-013 (servidor)? Se sim, feche a atividade suspeita (é um falso positivo).

3. Se o computador de destino não for corrigido, o computador de origem executará (na coluna FROM ) um sistema operacional/aplicativo conhecido por modificar o PAC? Se sim, suprime a atividade suspeita (é um verdadeiro positivo benigno).

4. Se a resposta para as duas perguntas anteriores foi não, suponha que essa atividade seja mal-intencionada.

Remediação

Verifique se todos os controladores de domínio com sistemas operacionais até Windows Server 2012 R2 estão instalados com KB3011780 e todos os servidores membros e controladores de domínio até 2012 R2 estão atualizados com KB2496930. Para obter mais informações, consulte o PAC Silver e o PAC Forjado.

Reconhecimento usando enumeração de conta

Description

No processo de reconhecimento de enumeração de contas, um invasor utiliza um dicionário contendo milhares de nomes de usuário, ou ferramentas como o KrbGuess, para tentar adivinhar nomes de usuário no seu domínio. O invasor faz solicitações Kerberos usando esses nomes para tentar encontrar um nome de usuário válido em seu domínio. Se uma tentativa de adivinhação determinar com sucesso um nome de usuário, o invasor receberá o erro de Pré-autenticação exigida em vez de Principal de segurança desconhecido.

Nessa detecção, o ATA pode detectar de onde o ataque veio, o número total de tentativas de adivinhação e quantas foram correspondidas. Se houver muitos usuários desconhecidos, o ATA o detectará como uma atividade suspeita.

Investigação

1. Selecione o alerta para acessar a página de detalhes.

   1. Esse computador host deve consultar o controlador de domínio se as contas existem (por exemplo, servidores Exchange)?

2. Há um script ou aplicativo em execução no host que pode gerar esse comportamento?

   Se a resposta a qualquer uma dessas perguntas for sim, feche a atividade suspeita (é um verdadeiro positivo benigno) e exclua esse host da atividade suspeita.

3. Baixe os detalhes do alerta em uma planilha Excel para ver convenientemente a lista de tentativas de conta, dividida em contas existentes e não existentes. Se você examinar a planilha de contas não existentes e as contas parecerem familiares, elas podem ser contas desativadas ou de funcionários que saíram da empresa. Nesse caso, é improvável que a tentativa venha de um dicionário. Provavelmente, é um aplicativo ou script que está verificando quais contas ainda existem em Active Directory, o que significa que é um verdadeiro positivo benigno.

4. Se os nomes forem em grande parte desconhecidos, alguma das tentativas de adivinhação corresponde aos nomes de conta existentes no Active Directory? Se não houver correspondências, a tentativa foi inútil, mas você deve prestar atenção ao alerta para ver se ele é atualizado ao longo do tempo.

5. Se qualquer uma das tentativas de adivinhação corresponder aos nomes de conta existentes, o invasor saberá da existência de contas em seu ambiente e poderá tentar usar a força bruta para acessar seu domínio usando os nomes de usuário descobertos. Verifique os nomes da conta adivinhada para atividades suspeitas adicionais. Verifique se alguma das contas correspondentes são contas confidenciais.

Remediação

Senhas complexas e longas fornecem o primeiro nível necessário de segurança contra ataques de força bruta.

Reconhecimento usando consultas dos Serviços de Diretório

Description

O reconhecimento de serviços de diretório é usado por invasores para mapear a estrutura do diretório e direcionar contas com privilégios para etapas posteriores em um ataque. O protocolo Remoto do Gerenciador de Contas de Segurança (SAM-R) é um dos métodos usados para consultar o diretório para executar esse mapeamento.

Nessa detecção, nenhum alerta seria disparado no primeiro mês após a implantação do ATA. Durante o período de aprendizado, os perfis do ATA registram quais consultas SAM-R são feitas a partir de quais computadores, tanto para enumeração quanto para consultas individuais de contas confidenciais.

Investigação

1. Selecione o alerta para acessar a página de detalhes. Verifique quais consultas foram feitas (por exemplo, administradores corporativos ou administradores) e se foram bem-sucedidas ou não.

2. Essas consultas devem ser feitas do computador de origem em questão?

3. Se sim e o alerta for atualizado, suprime a atividade suspeita.

4. Se sim e não deve mais fazer isso, feche a atividade suspeita.

5. Se houver informações sobre a conta envolvida: essas consultas devem ser feitas por essa conta ou essa conta normalmente entra no computador de origem?

   • Se sim e o alerta for atualizado, suprime a atividade suspeita.

   • Se sim e não deve mais fazer isso, feche a atividade suspeita.

   • Se a resposta foi não para todos os acima, suponha que isso seja mal-intencionado.

6. Se não houver informações sobre a conta envolvida, você pode acessar o terminal e verificar qual conta estava conectada no momento do alerta.

Remediação

1. O computador está executando uma ferramenta de verificação de vulnerabilidades?
2. Investigue se os usuários e grupos específicos consultados no ataque são contas privilegiadas ou de alto valor (ou seja, CEO, CFO, gerenciamento de TI e assim por diante). Nesse caso, examine outras atividades no endpoint e monitore os computadores nos quais as contas consultadas estão logadas, pois são provavelmente alvos de movimentação lateral.

Reconhecimento usando DNS

Description

O servidor DNS contém um mapa de todos os computadores, endereços IP e serviços na sua rede. Estas informações são utilizadas pelos atacantes para mapear a sua estrutura de rede e direcionar computadores interessantes para passos posteriores no ataque.

Existem vários tipos de consulta no protocolo DNS. O ATA detecta a solicitação AXFR (Transferência) proveniente de servidores não DNS.

Investigação

1. O computador de origem (originário de...) é um servidor DNS? Se sim, então isso é provavelmente um falso positivo. Para validar, selecione o alerta para acessar a página de detalhes. Na tabela, em Consulta, verifique quais domínios foram consultados. Esses domínios são existentes? Se sim , feche a atividade suspeita (é um falso positivo). Além disso, verifique se a porta UDP 53 está aberta entre o Gateway do ATA e o computador de origem para evitar falsos positivos futuros.
2. O computador de origem está executando um verificador de segurança? Se sim, exclua as entidades no ATA, diretamente com Fechar e excluir ou por meio da página Exclusão (em Configuração – disponível para administradores do ATA).
3. Se a resposta para todas as perguntas anteriores for não, continue a investigação focando no computador de origem. Selecione o computador de origem para acessar sua página de perfil. Verifique o que aconteceu na hora da solicitação, procurando atividades incomuns, como: quem foi conectado, quais recursos foram acessados.

Remediação

Proteger um servidor DNS interno para impedir que o reconhecimento usando DNS ocorra pode ser feito desabilitando ou restringindo transferências de zona apenas para endereços IP especificados. Para obter mais informações sobre como restringir transferências de zona, consulte Restringir Transferências de Zona. Modificar transferências de zona é uma tarefa entre uma lista de verificação que deve ser tratada para proteger seus servidores DNS de ataques internos e externos.

Reconhecimento usando enumeração de sessão SMB

Description

A enumeração SMB (Server Message Block) permite que os invasores obtenham informações sobre onde os usuários fizeram logon recentemente. Assim que os atacantes tiverem estas informações, podem mover-se lateralmente na rede para aceder a uma conta confidencial específica.

Nesta deteção, é acionado um alerta quando uma enumeração de sessão SMB é efetuada num controlador de domínio.

Investigação

1. Selecione o alerta para acessar a página de detalhes. Verifique as contas que executaram a operação e quais contas foram expostas, se houver.

   • Há algum tipo de verificador de segurança em execução no computador de origem? Se sim, feche e exclua a atividade suspeita.

2. Verifique quais usuários/s envolvidos executaram a operação. Eles normalmente fazem logon no computador de origem ou são administradores que devem executar essas ações?

3. Se sim e o alerta for atualizado, suprime a atividade suspeita.

4. Se a resposta for sim e não deva ser atualizado, feche a atividade suspeita.

5. Se a resposta a todos os acima for não, suponha que a atividade seja mal-intencionada.

Remediação

1. Contenha o computador de origem.
2. Localize e remova a ferramenta que executou o ataque.

Tentativa de execução remota detectada

Description

Invasores que comprometem credenciais administrativas ou utilizam um exploit de dia zero podem executar comandos remotamente no controlador de domínio. Isso pode ser usado para obter persistência, coletar informações, ataques de DOS (negação de serviço) ou qualquer outro motivo. O ATA detecta conexões PSexec e WMI remotas.

Investigação

1. Isso é comum para estações de trabalho administrativas, bem como para membros da equipe de TI e contas de serviço que executam tarefas administrativas em controladores de domínio. Se esse for o caso e o alerta for atualizado porque o mesmo administrador ou computador está executando a tarefa, suprime o alerta.
2. O computador em questão tem permissão para executar essa execução remota no controlador de domínio?
   • A conta em questão tem permissão para executar essa execução remota no controlador de domínio?
   • Se a resposta para ambas as perguntas for sim, feche o alerta.
3. Se a resposta para qualquer uma das perguntas for não, essa atividade deverá ser considerada um verdadeiro positivo. Tente encontrar a origem da tentativa verificando perfis de computador e conta. Selecione o computador de origem ou a conta para acessar sua página de perfil. Verifique o que aconteceu na hora dessas tentativas, procurando atividades incomuns, como: quem foi conectado, quais recursos foram acessados.

Remediação

1. Restrinja o acesso remoto a controladores de domínio de computadores que não são da Camada 0.

2. Implemente o acesso privilegiado para permitir que apenas computadores protegidos se conectem a controladores de domínio para administradores.

Credenciais de conta sensíveis expostas & serviços expondo credenciais de conta

Description

Alguns serviços enviam credenciais de conta em texto sem formatação. Isto pode até acontecer em contas confidenciais. Os atacantes que monitorizam o tráfego de rede podem capturar e, em seguida, reutilizar estas credenciais para fins maliciosos. Qualquer senha de texto clara para uma conta confidencial dispara o alerta, enquanto para contas não confidenciais o alerta é disparado se cinco ou mais contas diferentes enviam senhas de texto claras do mesmo computador de origem.

Investigação

Selecione o alerta para acessar a página de detalhes. Veja quais contas foram expostas. Se houver muitas dessas contas, selecione Download de detalhes para exibir a lista em uma planilha Excel.

Normalmente, há um script ou aplicativo herdado nos computadores de origem que usa a associação simples LDAP.

Remediação

Verifique a configuração nos computadores de origem e certifique-se de não usar a associação simples LDAP. Em vez de usar associações simples LDAP, você pode usar LDAP SASL ou LDAPS.

Falhas suspeitas de autenticação

Description

Em um ataque de força bruta, um invasor tenta autenticar com muitas senhas diferentes para contas diferentes até que uma senha correta seja encontrada para pelo menos uma conta. Uma vez encontrado, um invasor pode entrar usando essa conta.

Nessa detecção, um alerta é disparado quando ocorreram muitas falhas de autenticação usando Kerberos ou NTLM, isso pode ser horizontalmente com um pequeno conjunto de senhas em muitos usuários; ou verticalmente com um grande conjunto de senhas em apenas alguns usuários; ou qualquer combinação dessas duas opções. O período mínimo antes de um alerta poder ser acionado é de uma semana.

Investigação

1. Selecione Detalhes de Download para ver as informações completas em uma planilha Excel. Você pode obter as seguintes informações:
   • Lista das contas atacadas
   • Lista de contas adivinhadas em que as tentativas de logon terminaram com autenticação bem-sucedida
   • Se as tentativas de autenticação foram executadas usando o NTLM, você verá atividades de evento relevantes
   • Se as tentativas de autenticação foram executadas usando Kerberos, você verá atividades de rede relevantes
2. Selecione o computador de origem para acessar sua página de perfil. Verifique o que aconteceu na hora dessas tentativas, procurando atividades incomuns, como: quem foi conectado, quais recursos foram acessados.
3. Se a autenticação foi executada usando NTLM e você vê que o alerta ocorre muitas vezes e não há informações suficientes disponíveis sobre o servidor que o computador de origem tentou acessar, você deve habilitar a auditoria NTLM nos controladores de domínio envolvidos. Para fazer isso, ative o evento 8004. Esse é o evento de autenticação NTLM que inclui informações sobre o computador de origem, a conta de usuário e o servidor que o computador de origem tentou acessar. Depois de saber qual servidor enviou a validação de autenticação, você deve investigar o servidor verificando seus eventos, como 4624, para entender melhor o processo de autenticação.

Remediação

Senhas complexas e longas fornecem o primeiro nível necessário de segurança contra ataques de força bruta.

Criação de serviço suspeito

Description

Os invasores tentam executar serviços suspeitos em sua rede. O ATA gera um alerta quando um novo serviço que parece suspeito foi criado em um controlador de domínio. Esse alerta se baseia no evento 7045 e é detectado em cada controlador de domínio coberto por um Gateway do ATA ou Gateway Lightweight.

Investigação

1. Se o computador em questão for uma estação de trabalho administrativa ou um computador no qual os membros da equipe de TI e as contas de serviço executam tarefas administrativas, isso pode ser um falso positivo e talvez seja necessário suprimir o alerta e adicioná-lo à lista de Exclusões, se necessário.

2. O serviço é algo que você reconhece neste computador?

   • A conta em questão tem permissão para instalar esse serviço?

   • Se a resposta para ambas as perguntas for sim, feche o alerta ou adicione-o à lista exclusões.

3. Se a resposta para qualquer uma das perguntas for não, isso deverá ser considerado um verdadeiro positivo.

Remediação

• Implemente acesso menos privilegiado em computadores de domínio para permitir que apenas usuários específicos tenham o direito de criar novos serviços.

Suspeita de roubo de identidade com base em comportamento anormal

Description

O ATA aprende o comportamento da entidade para usuários, computadores e recursos durante um período deslizante de três semanas. O modelo de comportamento baseia-se nas seguintes atividades: os computadores aos qual as entidades fizeram logon, os recursos aos que a entidade solicitou acesso e a hora em que essas operações ocorreram. O ATA envia um alerta quando há um desvio do comportamento da entidade com base em algoritmos de aprendizado de máquina.

Investigação

1. O usuário em questão deveria estar executando essas operações?

2. Considere os seguintes casos como possíveis falsos positivos: um usuário que retornou de férias, funcionários de TI que executam o excesso de acesso como parte de seu dever (por exemplo, um pico no suporte técnico em um determinado dia ou semana), aplicativos de área de trabalho remota.+ Se você fechar e excluir o alerta, o usuário não fará mais parte da detecção

Remediação

Ações diferentes devem ser tomadas dependendo do que causou esse comportamento anormal. Por exemplo, se a rede tiver sido escaneada, o computador de origem deveria ser bloqueado na rede (a menos que seja aprovado).

Implementação de protocolo incomum

Description

Os atacantes utilizam ferramentas que implementam vários protocolos (SMB, Kerberos, NTLM) de formas não padrão. Embora esse tipo de tráfego de rede seja aceito por Windows sem avisos, o ATA é capaz de reconhecer possíveis intenções mal-intencionadas. O comportamento é um indicativo de técnicas como Over-Pass-the-Hash, bem como exploits usados por ransomware de nível avançado, como o WannaCry.

Investigação

Identifique o protocolo que é incomum – na linha de tempo de atividade suspeita, selecione a atividade suspeita para acessar a página de detalhes; o protocolo aparece acima da seta: Kerberos ou NTLM.

• Kerberos: Muitas vezes disparado se uma ferramenta como Mimikatz tenha sido potencialmente usada em um ataque Overpass-the-Hash. Verifique se o computador de origem está executando um aplicativo que implementa uma pilha Kerberos própria, não estando em conformidade com o RFC do Kerberos. Nesse caso, é um verdadeiro positivo benigno e o alerta pode ser Fechado. Se o alerta continuar sendo disparado e ainda for o caso, você poderá suprimir o alerta.

• NTLM: pode ser WannaCry ou ferramentas como Metasploit, Medusa e Hydra.

Para determinar se a atividade é um ataque do WannaCry, execute as seguintes etapas:

1. Verifique se o computador de origem está executando uma ferramenta de ataque, como Metasploit, Medusa ou Hydra.

2. Se nenhuma ferramenta de ataque for encontrada, verifique se o computador de origem está executando um aplicativo que implementa sua própria pilha NTLM ou SMB.

3. Caso contrário, verifique se foi causado pelo WannaCry executando um script de scanner do WannaCry, por exemplo, esse scanner no computador de origem envolvido na atividade suspeita. Se o verificador descobrir que o computador está infectado ou vulnerável, trabalhe na aplicação de patch do computador e na remoção do malware e no bloqueio da rede.

4. Se o script não descobrir que o computador está infectado ou vulnerável, ele ainda pode estar infectado, mas o SMBv1 pode ter sido desabilitado ou o computador foi corrigido, o que afetaria a ferramenta de verificação.

Remediação

Aplique os patches mais recentes a todos os seus computadores e verifique se todas as atualizações de segurança são aplicadas.

1. Desabilitar o SMBv1

2. Remover WannaCry

3. Os dados sob controle de algum software de ransomware às vezes podem ser descriptografados. A descriptografia só será possível se o usuário não tiver reiniciado ou desativado o computador. Para obter mais informações, consulte o worm de ransomware WannaCrypt que ataca sistemas desatualizados

Consulte também

• Manual de procedimentos de atividade suspeita do ATA
• Veja o fórum do ATA!
• Trabalhando com atividades suspeitas