Quatro desafios ao monitorar a segurança do Active Directory

Com os atacantes constantemente desenvolvendo novas táticas para comprometer credenciais e dados, é cada vez mais importante monitorar sistemas críticos como Active Directory (AD) em busca de sinais de atividade maliciosa.

Muitas organizações recorrem a produtos de security information and event management (SIEM) em busca de ajuda. Mas, embora essas soluções possam ser extremamente poderosas, elas dependem em última instância dos logs de eventos do Windows — que são complicados de se trabalhar e não fornecem as informações necessárias para monitorar vários vetores de ataque chave do AD.

Este blog explora quatro dos principais desafios na segurança do Active Directory e explica a limitação do uso de logs de eventos para resolvê-los.

Desafio 1. Monitoramento de Alterações na Associação de Grupos

Grupos de segurança do Active Directory são a principal forma de os usuários obterem acesso a recursos de TI, incluindo dados, máquinas e aplicações. À medida que os atacantes se movem lateralmente pelo seu ambiente, eles frequentemente adicionam as contas que comprometeram a novos grupos de segurança para obter privilégios adicionais, por isso é vital acompanhar as alterações na associação dos grupos de segurança.

O rastreamento de alterações em grupos que fornecem acesso privilegiado é especialmente importante. Isso inclui grupos integrados como Domain Admins, Enterprise Admins e Schema Admins, bem como quaisquer grupos de segurança que sua organização tenha criado que forneçam direitos de acesso elevados.

O que o Registro de Eventos Captura — e Suas Limitações

O Active Directory registra alterações nos grupos de segurança no log de eventos. Por exemplo, se um usuário for adicionado ao grupo Domain Admins, o AD gerará um evento como o mostrado abaixo, que inclui os seguintes detalhes chave:

• O ID do usuário que realizou a alteração
• O DN e a classe do objeto que foi alterado
• O tipo de alteração (neste caso, que um membro foi adicionado)

Figura 1. Exemplo de evento mostrando que um grupo de segurança foi modificado

No entanto, o registro de eventos possui várias limitações importantes:

• · Não há registro de onde veio a alteração — Os logs de eventos não registram a origem de uma alteração na associação de grupos. Embora uma alteração no grupo Domain Admins a partir de um servidor de salto ou controlador de domínio (DC) possa ser normal, uma alteração de uma estação de trabalho não administrativa ou outra máquina voltada para a internet pode ser um sinal revelador de um ataque. Sem detalhes sobre a origem da alteração, é impossível alertar sobre mudanças de locais anormais.
• · Sem monitoramento da associação efetiva de grupos — O Active Directory apenas registra alterações na associação direta de um grupo. No entanto, grupos podem conter outros grupos como membros. Portanto, para monitorar verdadeiramente as alterações na associação de um grupo, você deve monitorar o próprio grupo e todos os grupos aninhados dentro dele.
• · Inconsistências entre eventos — Os eventos registrados serão diferentes dependendo de como um grupo foi alterado. Por exemplo, se um usuário for adicionado a um grupo usando Active Directory Service Interfaces (ADSI), o registro de eventos mostrará um evento de remoção para cada membro existente do grupo, seguido por um evento adicionando de volta cada membro do grupo, seguido por um evento adicionando o novo usuário; portanto, adicionar um usuário a um grupo com 50 membros gerará 101 entradas no registro de eventos. E se a alteração foi feita usando LDAP, o GUID do objeto pode ser listado em vez de seu nome distinto. Essas inconsistências podem causar confusão e desinformação em produtos SIEM, e tornar extremamente difícil construir regras eficazes para agir sobre os dados coletados.

Desafio 2. Monitoramento de Alterações na Group Policy

As configurações de Group Policy afetam os usuários e computadores em todo o Active Directory domain, incluindo, por exemplo, quem tem acesso administrativo aos sistemas. Uma única alteração em um objeto de Group Policy object (GPO) pode ter graves impactos na segurança ou causar interrupções na produção, portanto, é fundamental monitorar essas alterações.

O que o Registro de Eventos Captura — e Suas Limitações

Quando uma Política de Grupo é alterada, um evento como o mostrado na Figura 2 será registrado. Este evento fornece informações úteis, como quem fez a alteração e o identificador do GPO.

Figura 2. Evento registrado para uma alteração na Política de Grupo

No entanto, esses eventos carecem das seguintes informações críticas:

• · Detalhes de qual configuração foi alterada e seus valores antes e depois — GPOs suportam centenas de configurações padrão e personalizadas. Uma alteração pode modificar a página inicial do navegador padrão dos usuários ou conceder a todos os usuários controle administrativo de uma máquina crítica. No entanto, o registro de eventos não captura a configuração alterada e para o que foi mudada.
• · Origem da alteração — Assim como nas alterações dos grupos de segurança, os eventos que registram alterações na Política de Grupo não indicam a origem da mudança. A maioria das alterações de GPO deve vir de poucos locais selecionados, e ser capaz de identificar alterações que vêm de locais anormais é vital para detectar ataques rapidamente.

Desafio 3. Monitoramento de Leituras de Directory

Outra tarefa essencial na segurança do seu Active Directory é monitorar como as contas de usuário leem e enumeram objetos do AD. Atacantes que buscam se estabelecer na sua rede frequentemente enumeram contas críticas, grupos e servidores a fim de descobrir caminhos de ataque que levam a privilégios elevados e, em última instância, a dados sensíveis. Ao monitorar eventos suspeitos de leitura, você pode detectar essa atividade de reconhecimento e interromper um ataque antes que seja tarde demais.

O que o Registro de Eventos Captura — e Suas Limitações

Para ajudá-lo a ver quem está explorando o Active Directory, o log de eventos captura a atividade de leitura. O evento mostra detalhes sobre a conta de usuário, o objeto que está sendo lido e o tipo de operação que está sendo realizada, conforme ilustrado na Figura 3:

Figura 3. Um evento mostrando que uma propriedade de Domain Admins foi lida

No entanto, tentar usar esses eventos para observar atividades suspeitas tem várias desvantagens:

• Muito barulho — Registrar eventos de leitura resulta em tanto ruído no registro de eventos que é quase impossível encontrar qualquer informação valiosa. De fato, uma única instância de um usuário visualizando um grupo pode gerar dezenas ou até centenas de eventos no registro, o que torna quase impossível encontrar atividades suspeitas entre todos os eventos legítimos.
• Não há registro de onde a leitura veio — Além disso, não há como saber de onde o evento de leitura se originou. Como vimos com as alterações em grupos de segurança e GPOs, saber de qual computador um evento de leitura veio é informação crucial para determinar se é uma leitura inofensiva ou um ato malicioso de reconhecimento.
• Demasiados eventos de acesso negado — É também essencial identificar usuários que estão tentando acessar informações às quais não têm direito. Por exemplo, o Active Directory pode armazenar senhas em texto claro para contas administrativas em atributos de computador, então uma conta de usuário que tenta ler esses atributos pode estar tentando comprometer credenciais privilegiadas. Infelizmente, toda vez que qualquer conta visualiza um objeto por qualquer motivo, a ação gera eventos de falha de acesso para todos os atributos que não têm direito de ler, mesmo que não tivessem a intenção de ler esses atributos. Simplesmente não é uma estratégia viável tentar encontrar eventos de acesso falhado verdadeiramente suspeitos no meio de um oceano de eventos inocentes.
• Nenhuma maneira fácil de monitorar consultas LDAP — As consultas LDAP são comumente usadas para explorar o Active Directory a fim de descobrir usuários, grupos e computadores. Infelizmente, a Microsoft não oferece uma maneira fácil de monitorar as consultas LDAP para ver a consulta emitida e de onde ela veio. Por causa dessa questão, até mesmo ativar o monitoramento LDAP em nível de diagnóstico oferece pouco valor; de fato, não é aconselhado pela Microsoft, pois isso gerará uma quantidade enorme de ruído nos registros de eventos.

Desafio 4. Rastreamento de Eventos de Autenticação

Com o recente aumento de ataques baseados em credenciais, monitorar padrões de autenticação é crítico para identificar contas comprometidas, sinais de pass-the-hash e pass-the-ticket attacks, forged Kerberos tickets, ou outros exploits usados para obter privilégios e acesso a dados sensíveis.

O que o Registro de Eventos Captura — e Suas Limitações

O Active Directory captura eventos para monitorar a atividade de logon e autenticação de usuários em controladores de domínio, servidores membros e estações de trabalho, incluindo aqueles listados na tabela a seguir:

Embora esses eventos capturem algumas informações úteis, eles não oferecem uma maneira eficaz de identificar ataques baseados em autenticação devido às seguintes limitações:

• Excesso de ruído — Eventos são criados toda vez que um usuário faz login em qualquer computador, o que normalmente representa uma quantidade enorme de atividade. Muitos outros eventos são criados nos bastidores. Por exemplo, quando um usuário faz login em um servidor membro que está conectado a um domínio AD, o servidor inicia uma conexão com um DC que recupera informações da Política de Grupo, o que resulta no aparecimento de eventos de logon/logoff no log de eventos do DC. Não há como desativar o registro de atividades normais de login de usuário sem ignorar atividades críticas de login nos seus controladores de domínio.
• Não há registro do tipo de logon nos DCs — Os registros não acompanham o tipo de logon para eventos de logon nos DCs, contexto que é inestimável para determinar se as contas estão sendo usadas de maneira apropriada. Por exemplo, não há uma maneira fácil de diferenciar entre um usuário fazendo logon através da Área de Trabalho Remota e um logon de rede por meio de um drive de rede mapeado; é necessário coletar registros de cada servidor membro e tentar correlacioná-los com os registros dos DCs.
• Falta de detalhes específicos do protocolo — Os eventos também estão faltando outros detalhes valiosos. Por exemplo, os eventos de autenticação Kerberos não registram os carimbos de data/hora de vida e renovação do ticket, que são indicadores valiosos de tickets forjados usados no Golden Ticket exploit. Da mesma forma, os registros NTLM não especificam a versão do NTLM que foi usada, informação que é valiosa para determinar se você pode desativar versões antigas do NTLM em favor de protocolos mais seguros.

Como a Netwrix pode ajudar

Como vimos, os registros de eventos são inadequados para detectar ataques prontamente e responder de forma eficaz. Para proteção completa, considere a solução de segurança Netwrix Active Directory. Ela ajudará você a:

• Identifique proativamente lacunas de segurança por meio de uma avaliação de risco aprofundada.
• Minimize o tempo de inatividade custoso e as interrupções nos negócios.
• Detecte prontamente até mesmo ameaças avançadas a tempo e responda rapidamente.