10 Métodos para Identificar e Proteger Usuários Privilegiados do AD

Comprometer contas privilegiadas é o penúltimo objetivo da maioria dos ciberataques — uma vez que os atacantes obtêm acesso privilegiado, eles podem então realizar seu objetivo final, seja para roubar ou criptografar ativos de informação ou interromper as operações comerciais. Tipicamente, os cibercriminosos obtêm um ponto de apoio em uma rede comprometendo uma conta de baixo nível em uma máquina local. Usando uma variedade de técnicas, eles então tentam assumir o controle das contas mais privilegiadas de que precisam para acessar os dados sensíveis e sistemas da organização. Em ambientes de Active Directory (AD), o grande prêmio é uma conta de Administrador de Domínio, mas qualquer conta privilegiada geralmente é suficiente.

Elementos-chave do Privileged Access Management

Um atacante com acesso privilegiado pode se mover livremente pelo seu AD domain e acessar seus recursos de TI mais valiosos. Portanto, para manter a segurança e a conformidade, é imperativo estabelecer uma governança de identidade forte e gerenciamento de acesso sobre todas as contas privilegiadas no seu ambiente AD.

Especificamente, garantir a segurança dos seus sistemas e dados envolve dois componentes chave:

• Identificando quais usuários têm quais privilégios para quais ativos de TI
• Detectando quando uma conta obtém Privileged Access pela primeira vez

É vital entender que Privileged Access Management não é um esforço único. À medida que os usuários são integrados e mudam de funções e o ambiente de TI evolui, os direitos e as associações de grupos mudam, e as equipes de segurança precisam identificar quaisquer alterações que possam ser maliciosas ou de outra forma impróprias.

Abaixo estão os 10 principais métodos que você pode usar para proteger suas contas de usuário privilegiadas de comprometimento. Eles fazem parte de uma estratégia de segurança abrangente para impedir que usuários não autorizados obtenham acesso privilegiado ao AD.

1.Gerencie de perto grupos privilegiados integrados como Domain Admins.

Os grupos privilegiados integrados do AD, como Administradores, Admins de Domínio, Admins de Empresa e Admins de Esquema, são um ponto de partida óbvio. Em seguida, está o grupo de Administradores Locais em cada um dos seus endpoints Windows, que fornecem acesso privilegiado a esses sistemas.

Identificar os membros de cada um desses grupos é tão fácil quanto visualizar a aba de Propriedade de Membros do grupo no Active Directory Users & Computers (ADUC). Outra maneira é usar o cmdlet do PowerShell Get-ADGroupMember, conforme mostrado na captura de tela abaixo. Este é o método preferido quando você precisa analisar vários grupos de maneira rápida.

Tenha em mente que revisões periódicas dos membros do grupo fornecem uma visão do estado do grupo naquele momento apenas. Ainda assim, é um bom ponto de partida.

2. Verifique a existência de grupos aninhados dentro de grupos privilegiados.

É vital verificar se os grupos privilegiados têm outros grupos como membros, pois esses grupos aninhados concedem a seus membros todos os direitos de acesso do grupo privilegiado. Por exemplo, na captura de tela abaixo, você pode ver que um dos membros do grupo Domain Admins é um grupo chamado LabPowerUsers — o que significa que qualquer membro do grupo LabPowerUsers tem privilégios administrativos em todo o domínio.

Sempre que possível, deve-se evitar o aninhamento de grupos, especialmente dentro de grupos privilegiados, pois isso fornece aos atacantes uma maneira de obter acesso a recursos críticos e dados com menor risco de acionar alarmes — eles adicionam uma conta que controlam a um grupo aninhado, em vez de diretamente ao grupo privilegiado pai, que pode ser mais rigorosamente monitorado.

Como mostrado anteriormente, o cmdlet Get-ADGroupMember revela apenas os membros imediatos do grupo consultado, então ele listará quaisquer grupos aninhados, mas não seus membros. Uma maneira de também mostrar os membros de quaisquer grupos aninhados é usar o filtro LDAP mostrado em vermelho abaixo:

      param([string]$groupDn )
$s = new-object system.directoryservices.directorysearcher
$s.searchroot = new-object system.directoryservices.directoryentry
$s.filter = “(&(memberOf:1.2.840.113556.1.4.1941:=$groupDn))”
$s.propertiestoload.add(“name”)
$s.propertiestoload.add(“objectclass”)
$r = $s.FindAll()
foreach ($e in $r)
{Write-Host
$e.Properties.objectclass[$e.Properties.objectclass.Count-1]:
$e.properties.name
      

Se este código for salvo como um script (.GetNestedMembers.ps1), ele pode ser executado da seguinte forma, especificando o Nome Distinto do grupo desejado:

      .GetNestedMembers.ps1 -groupDn “CN=Administrators,CN=Builtin,DC=lab,DC=local”
      

A saída mostra o nome do grupo e lista seus membros:

      group : Domain Admins
user : bosshogg
user : azuresync
user : Barry Vista
user : Randy Smith
user : AdminService
      

Para obter uma visibilidade rápida em privilégios elevados sem todo o incômodo e despesa de scripts, muitas organizações optam por investir em uma ferramenta de terceiros para Privileged Access Management (PAM) como a Netwrix PAM solution.

3. Preste atenção às permissões da unidade organizacional (OU).

Além de obter privilégios por meio da associação a grupos, os usuários podem receber controle delegado no nível da unidade organizacional. A captura de tela abaixo mostra um grupo recebendo privilégios delegados para a OU de Vendas; cada membro desse grupo poderá realizar as tarefas selecionadas, incluindo modificar a associação de qualquer grupo na OU de Vendas.

Manter o controle das permissões de OU é complicado devido à herança. Assim como na segurança NTFS, as permissões das OUs pais propagam-se para as OUs filhas e objetos folha. Isso pode resultar em muitos usuários com privilégios elevados que são difíceis de descobrir, como ilustrado na captura de tela a seguir que mostra todas as OUs filhas e objetos folha da OU de Vendas:

Embora você possa interromper a herança de uma OU pai, fazer isso pode causar problemas, como gerentes que não conseguem gerenciar objetos pelos quais são responsáveis.

Para gerar eventos de auditoria sempre que um objeto do diretório for acessado, você pode usar a Política de Grupo do AD. Vá em Configuração do Computador > Configurações do Windows > Configurações de Segurança > Configuração Avançada de Política de Auditoria > Políticas de Auditoria > Acesso ao DS e configure Auditoria de Alterações do Serviço de Diretório conforme mostrado abaixo.

Tenha em mente que ativar essa auditoria irá gerar um grande volume de entradas de log, portanto, revisar manualmente os logs de auditoria leva bastante tempo. Além disso, as entradas de log não especificam quais permissões estão sendo atribuídas; elas simplesmente revelam que as permissões para uma determinada OU precisam ser revisadas.

4. Procure por direitos equivalentes a administrador em controladores de domínio (DCs).

Controladores de domínio são máquinas especiais que executam o sistema operacional Windows Server e fornecem serviços vitais de autenticação e autorização. Portanto, é importante procurar por contas com privilégios de nível de administrador nos seus DCs. Por exemplo, uma conta de serviço pode ser concedida o direito de fazer backup ou restaurar arquivos nos DCs. Ataques podem comprometer essas contas usando ferramentas de código aberto como Mimikatz para descobrir seus hashes de senha e, em seguida, quebrar suas senhas em texto claro.

Você pode identificar quais contas possuem esses direitos com base em:

• Revisando a política de Controladores de Domínio Padrão
• Usando um script PowerShell
• Usando ferramentas de Privileged Access Management (PAM) como Netwrix PAM solutions

5. Descubra usuários com autoridade de redefinição de senha sobre outras contas.

A capacidade de redefinir a senha de uma conta de usuário é altamente visada por atores de ameaças, porque redefinir a senha de uma conta permite que eles assumam o controle da conta. Esse direito está incluído na permissão de Controle Total. Você também pode delegar a permissão específica para redefinir senhas de outros usuários usando o assistente de Delegação de Controle, conforme mostrado abaixo:

No exemplo abaixo, membros do grupo de Suporte de PC têm permissão para redefinir as senhas dos administradores de domínio. Portanto, ao comprometer a conta de qualquer membro do grupo de suporte de PC, um atacante pode facilmente obter privilégios elevados em todo o domínio.

Procurar manualmente cada UO e objeto de usuário para ver quem tem esse privilégio é demorado e propenso a erros, e tentar auditar manualmente toda a atividade de redefinição de senha é igualmente impraticável. Netwrix AD security facilita a visualização de quais contas têm direitos de redefinição de senha. A captura de tela abaixo mostra um ambiente no qual 1.000 usuários no domínio prod.net podem ter suas senhas redefinidas por 15 indivíduos diferentes:

6. Monitore o uso de contas de serviço privilegiadas.

Uma dica anterior mencionou a necessidade de monitorar contas de serviço que possuem direitos de acesso em um DC equivalentes aos dos administradores. Mas os riscos associados a contas de serviço não se limitam a DCs. Cargas de trabalho como Exchange, SQL Server, soluções de backup e outras aplicações empresariais funcionam sob contas de serviço que frequentemente têm privilégios administrativos, e qualquer pessoa que conheça as credenciais de tal conta pode usá-la para fins maliciosos.

As senhas das contas de serviço muitas vezes não são alteradas regularmente, ou até mesmo nunca, então frequentemente não está claro exatamente quem as conhece. Mesmo que as senhas das contas de serviço sejam rotacionadas regularmente, a atividade de logon dessas contas deve ser auditada para garantir que sejam usadas apenas para os serviços designados e não para atividades ilícitas, como logon interativo em um controlador de domínio.

Usar o log de Segurança em um DC para determinar se uma conta de serviço está sendo usada de forma inadequada requer a montagem de várias peças de um quebra-cabeça. Por exemplo, o Evento 4768 mostra que um ticket de autenticação Kerberos foi solicitado e o 4672 indica que privilégios especiais foram atribuídos a um novo logon, mas eles precisam ser correlacionados com o Evento 4624 (uma conta foi logada com sucesso).

7. Descubra usuários com acesso de escrita a GPOs que são aplicados a DCs ou servidores que executam aplicações com Privileged Access Management.

A Política de Grupo é uma ferramenta poderosa para gerenciar tanto usuários quanto máquinas como DCs, servidores de aplicativos e endpoints Windows. É por isso que os atacantes tentam ganhar controle sobre ela e por que é imperativo para você monitorar quem tem acesso de escrita a qualquer objeto de Política de Grupo (GPO).

Um bom ponto de partida é revisar as permissões em todas as GPOs que estão vinculadas à raiz do Domínio ou à OU dos Controladores de Domínio. Isso pode ser feito facilmente ao revisar a aba Delegação da política de Controladores de Domínio Padrão, conforme mostrado abaixo:

8. Identifique todas as contas de usuário com acesso a qualquer solução de AD management.

Muitas organizações utilizam soluções de terceiros para simplificar tarefas de gerenciamento do AD. Essas soluções podem, às vezes, habilitar dois métodos de ataque para atores de ameaças que procuram obter acesso privilegiado.

• O primeiro envolve o uso de uma conta de serviço ou proxy que recebe acesso privilegiado a todo ou a um subconjunto do AD para permitir as funções de gerenciamento da solução.
• O segundo método utiliza qualquer conta com permissões atribuídas dentro da solução de gestão. Aqui, um usuário de baixo nível pode receber a capacidade de realizar tarefas privilegiadas (por exemplo, redefinir a senha de outro usuário) em um subconjunto de contas AD. Dependendo do nível de delegação, obter controle sobre uma conta como esta pode ser tão eficaz quanto ser um Administrador de Domínio.

Para obter visibilidade desses riscos, você deve fazer um inventário de todas as aplicações de gerenciamento em uso. Observe que elas frequentemente não estão em um controlador de domínio. Então você precisa identificar todas as contas de serviço e proxy que têm acesso privilegiado e monitorar o que essas contas estão fazendo. A maioria das soluções de gerenciamento oferece algum meio de estabelecer um rastro de auditoria para monitorar comportamentos inadequados. Quaisquer alertas gerados por essas aplicações também podem ser encaminhados para uma solução SIEM se uma estiver disponível.

Alternativamente, Netwrix Auditor pode enviar resumos diários de atividades detalhando todas as alterações em hardware e software, tarefas agendadas, aplicações, configurações de rede e mais nos seus servidores Windows. Abaixo está uma captura de tela mostrando todas as aplicações instaladas:

9. Não se esqueça dos administradores de infraestrutura de virtualização.

Para proteger seu ambiente virtual AD, você deve saber quais contas têm acesso privilegiado à sua infraestrutura virtual. Lembre-se de que qualquer pessoa que gerencie o ambiente virtual que hospeda DCs ou servidores membros tem o equivalente a acesso administrativo a uma máquina física.

Por exemplo, se você estiver executando Hyper-V, os membros do grupo local Hyper-V Administrators têm acesso de nível de administrador no sistema operacional convidado. Da mesma forma, em ambientes VMware, o usuário root em um sistema ESXi possui o mesmo nível de acesso. E embora servidores membros possam não hospedar AD, quaisquer aplicações de gerenciamento ou contas de serviço com privilégios AD apresentam o mesmo risco.

10. Impedir que administradores deixem vestígios de credenciais.

Quando um usuário faz login em um sistema, pedaços de informações de credenciais muitas vezes permanecem após o usuário se desconectar. Essas informações podem incluir senhas em texto claro, hashes de senhas, hashes NTLM e tickets Kerberos. Utilizando ferramentas como Mimikatz, atacantes podem explorar facilmente esses artefatos deixados na memória de servidores e estações de trabalho para se autenticarem como contas privilegiadas. Por exemplo, senhas em texto claro podem simplesmente ser reutilizadas, e hashes podem ser passados como parte de uma solicitação de autenticação, usando ferramentas adicionais de hacking para obter acesso a outros sistemas.

Infelizmente, identificar quais máquinas possuem artefatos de credenciais privilegiadas é quase impossível. Portanto, seu foco precisa estar em determinar onde os usuários privilegiados estão fazendo login.

Como mencionado anteriormente, você pode monitorar o ID de evento 4627 (Privilégios especiais atribuídos a novo logon) em qualquer sistema Windows atual para grupos que são conhecidos por serem privilegiados. E você pode monitorar o ID de evento 4769 (Um ticket de serviço Kerberos foi solicitado) nos seus DCs para identificar logons privilegiados.

Depois de ter uma ideia de como as contas privilegiadas estão sendo usadas, certifique-se de que as configurações do WDigest impeçam que senhas em texto claro sejam armazenadas na memória. Você também deve proibir que contas privilegiadas sejam usadas em estações de trabalho de usuários para manter suas credenciais seguras e usar uma conta com privilégios de Administrador Local para resolver problemas de usuários finais.

Mantendo um Controle Rigoroso sobre as Contas Privilegiadas

Contas de usuário privilegiadas — desde contas com direitos de Admin local em uma máquina até aquelas com privilégios completos de Admin de Domínio — são regularmente alvo de adversários. Para prevenir violações e inatividade, você precisa saber quem são seus usuários privilegiados e monitorar por mudanças que possam afetar o acesso privilegiado. No entanto, se você depende de ferramentas nativas, a avaliação e o monitoramento são processos demorados e sujeitos a erros. Para o monitoramento confiável 24/7 que você precisa para proteger suas contas privilegiadas de comprometimento e uso indevido, você precisa de ferramentas automatizadas de terceiros. A Netwrix suite of solutions oferece a visibilidade que você precisa para detectar e impedir tentativas de privilege escalation e abuso de privilégios.