Melhorar a postura de segurança do Active Directory: AdminSDHolder para o resgate

Este documento realça a importância das permissões de leitura predefinidas na segurança do Active Directory (AD), que é frequentemente negligenciada. A floresta do AD não é apenas um limite de segurança, mas também deve ser considerada como o alcance do acesso de um intruso e a avaliação da segurança dos objectos do AD após a entrada na rede de uma organização. A remoção de permissões de leitura predefinidas específicas é uma medida de baixo risco que aumenta a dificuldade de os intrusos efectuarem o reconhecimento e planearem os passos seguintes. Compreender a lógica incorporada do mecanismo de proteção da Microsoft para as contas mais privilegiadas no diretório é crucial para compreender as vantagens e desvantagens deste mecanismo.

Este documento explica como ajustar o mecanismo de proteção removendo as permissões de leitura por defeito arriscadas para melhorar a segurança do AD. Além disso, o documento aborda a questão do débito de configuração incorrecta na maioria das infra-estruturas do AD e como corrigir as permissões em objectos que já fizeram parte de um grupo privilegiado, mas que já não fazem. Em última análise, proteger o AD restringindo a visibilidade dos objectos e as permissões gerais de leitura é fundamental para reduzir a superfície de ataque do AD e melhorar a sua postura de segurança.

Restrição do reconhecimento e dos movimentos laterais

O bloqueio adequado tem um impacto direto na dificuldade - ou facilidade - com que os intrusos utilizam o Active Directory (AD) contra si durante a fase de reconhecimento de um ataque.

Tal como se mostra na Figura 1, esta fase ocorre depois de um utilizador malicioso estabelecer uma base de apoio na sua rede empresarial, normalmente enganando os seus empregados através de e-mails de phishing ou de sítios Web maliciosos especiais. Nesta fase, o intruso normalmente assumiu o controlo da conta AD apenas de um utilizador autenticado normal (ou seja, qualquer conta de funcionário sem privilégios que não administre o AD da sua empresa). Poderá pensar que um utilizador sem privilégios não constitui uma ameaça para a segurança da sua empresa, mas durante quanto tempo é que um intruso permanecerá sem privilégios? Inicialmente, os intrusos utilizam vulnerabilidades conhecidas do sistema operativo (SO) ou controladores em terminais insuficientemente corrigidos para elevar os seus privilégios locais e, assim, obter rapidamente acesso administrativo ao cliente comprometido. Isto permite-lhes desativar outras protecções que possam existir no cliente, descarregar mais malware e estabelecer um sistema de comando e controlo que normalmente permite o acesso remoto direto a outros membros do grupo. O próximo objetivo seria mover-se lateralmente para outros clientes, realizando um reconhecimento adequado com o objetivo de comprometer uma conta de administrador do domínio para eventualmente ganhar o domínio do domínio.

No entanto, o verdadeiro objetivo do intruso é claro: alcançar e extrair os seus dados comerciais sensíveis para o colocar sob pressão. Melhor ainda, aumentar essa pressão encriptando o maior número possível de sistemas no seu ambiente, incluindo todos os servidores, as suas cópias de segurança e as cópias de segurança dessas cópias de segurança. Estas acções são seguidas por uma nota de resgate amigável, solicitando um pagamento em Bitcoin dentro de algumas horas ou dias, e prometendo que, após o pagamento, receberá uma chave de desencriptação e que os seus dados sensíveis não serão definitivamente libertados para o maior licitador na Dark Web. Pagaria? Idealmente, não precisará de responder a essa pergunta. Em vez disso, terá colocado o seu esforço em impedir que os intrusos atinjam o seu objetivo, assumam o controlo do seu AD e destruam a sua empresa. O primeiro passo é dificultar a qualquer intruso a localização dos seus utilizadores privilegiados e a leitura de dados sensíveis do seu AD.

Bloquear o AD pode fazer a diferença

Um "bloqueio" do AD refere-se normalmente a alterações de permissões no diretório (ou seja, à alteração de algumas das permissões predefinidas). Infelizmente, estas permissões são demasiado abertas, dando demasiadas informações armazenadas no seu AD aos maus da fita. Os utilizadores típicos e as aplicações empresariais raramente necessitam destas informações, pelo que a remoção de algumas permissões no AD aproxima-o muito mais da melhor prática geral de segurança de TI: o modelo de privilégios mínimos, no qual concede aos utilizadores apenas as permissões necessárias para desempenharem as suas funções. No entanto, para quaisquer alterações de permissões no AD, é sempre necessário ponderar os prós e os contras da forma como essas alterações podem afetar as suas aplicações empresariais. Afinal de contas, um AD perfeitamente seguro que não suporta as suas aplicações empresariais não o ajuda em nada. Idealmente, tem um ambiente de teste sólido que contém não só uma floresta AD de teste (configurada tal como o AD de produção), mas também uma cópia das aplicações empresariais mais importantes que utiliza. Este ambiente permite-lhe testar o impacto de quaisquer alterações de permissões no AD antes de as implementar na produção.

Em qualquer caso, as alterações de permissões devem ser planeadas cuidadosamente (ver Figura 2). A boa notícia é que reverter para as permissões originais é bastante fácil (por exemplo, se os seus testes ignoraram alguns artefactos). A documentação das permissões que estão a ser alteradas no AD é fundamental para que possa desfazer essas alterações. Uma ferramenta de auditoria do AD adequada pode fazer isso por si, mantendo-o num local seguro.

Os seus objectos privilegiados são um alvo importante para os intrusos

Se tiver de escolher uma área específica para iniciar um confinamento do seu AD, a primeira escolha deve ser claramente as suas contas e grupos privilegiados. Trata-se dos grupos de administradores da empresa e do domínio e respectivos membros, mas também de outros grupos especiais, como operadores de conta, operadores de servidor, etc., e respectivos membros. Num AD corretamente configurado, nenhuma das suas aplicações empresariais utilizará esses grupos e contas privilegiados. Essas aplicações também não precisam de efetuar uma pesquisa LDAP (Lightweight Directory Access Protocol) como, por exemplo, "quem é membro do grupo de administradores do domínio" para funcionarem. Por conseguinte, este bloqueio do AD é normalmente uma tarefa de baixo risco. O AD utiliza o atributo 'adminCount' nos objectos para assinalar aqueles que considera serem 'privilegiados'; os objectos correspondentes têm este atributo definido como 1. Para compreender quais os grupos que o AD considera privilegiados, pode executar uma consulta LDAP simples com o seguinte filtro^:1

(&(groupType:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))

Esta consulta procura apenas grupos de segurança, especificamente os que estão assinalados com um '1' no seu atributo adminCount. Utilize o seu método de consulta LDAP preferido; por exemplo, DSQUERY:

dsquery * domainroot “(&(groupType: 1.2.840.113556.1.4.803:=2147483648) (admincount=1))”

ou PowerShell:

Get-ADObject -LDAPfilter “(&(groupType: 1.2.840.113556.1.4.803:=2147483648) (admincount=1))”

ou o filtro LDAP diretamente na Consola de Gestão Microsoft (MMC) AD Users & Computers, com a opção de pesquisa personalizada/avançada (ver Figura 3). Os resultados no seu domínio podem ser diferentes, especialmente se tiver aninhado outros grupos nesses grupos privilegiados predefinidos, mesmo que temporariamente. Os resultados também dependem da versão do sistema operativo dos controladores de domínio do AD e da forma como foi efectuada a atualização entre versões. Mas, idealmente, a sua lista não se desvia muito desta predefinição. Se isso acontecer, poderá ter algum trabalho de limpeza (discutido abaixo) pela frente. Em primeiro lugar, é importante compreender o significado do atributo adminCount e a sua origem, bem como algumas noções básicas de comportamento e conceção do AD.

A delegação de permissões bem definida foi a pedra angular do sucesso do AD

Quando a Microsoft concebeu o AD, há mais de 23 anos, adicionou poderosas capacidades de delegação de permissões, até cada atributo dos objectos no diretório. A base desta capacidade era armazenar permissões separadas, denominadas descritor de segurança ou lista de controlo de acesso (ACL), para cada objeto no AD como parte do próprio objeto (armazenado no atributo nTSecurityDescriptor ). O modelo de segurança do AD suportava a herança de permissões ao longo de toda uma árvore de unidades organizacionais (OUs) para configurar eficientemente as permissões sem as definir separadamente em todos os objectos. Mas o modelo também permitia que as permissões explícitas fossem definidas diretamente num objeto (por exemplo, outra UO, utilizador ou grupo) (ver Figura 4). As permissões explícitas desse objeto podiam ser misturadas com as permissões herdadas ou podiam impedir que as permissões fossem herdadas do objeto principal.

Esta flexibilidade permitiu que até as maiores empresas utilizassem um diretório de TI central e global que podia delegar tarefas de suporte importantes noutras equipas. Na altura em que o AD foi concebido, era prática comum ter equipas de assistência separadas em cada país em que uma empresa operava. Essas equipas executavam tarefas de suporte clássicas, como redefinir a palavra-passe de uma conta de utilizador na sua região, adicionar objectos informáticos ou mesmo adicionar utilizadores a grupos, conforme necessário para gerir a empresa. Através da delegação de permissões ao nível da UO adequada (por exemplo, UO=PHX, UO=US, DC=mycompany, DC=com) e da herança de permissões ao longo de todo o ramo da UO para os objectos relevantes (por exemplo, utilizador, computador, grupo), os membros de um grupo AD de helpdesk correspondente podiam executar todas as tarefas de suporte necessárias para os utilizadores, computadores e grupos em qualquer uma das sub-unidades. Esta capacidade não exigia que os membros do grupo tivessem permissão para administrar o próprio serviço AD. Por outras palavras, o pessoal do serviço de assistência não era membro do grupo de administradores de domínios e não podia alterar a configuração do AD, promover novos controladores de domínios (DCs) ou iniciar sessão nos controladores de domínios do AD.

Estes utilizadores de helpdesk com permissões delegadas específicas no AD são designados por administradores de dados do AD, enquanto as contas verdadeiramente privilegiadas, como os administradores de domínio, são conhecidas por administradores de serviços do AD. Mas o que acontece se uma conta de administrador de domínio "real" estiver numa sub-OU à qual o pessoal do serviço de assistência tem o direito de repor as palavras-passe dos utilizadores? Ou pior, e se alguém não conceder permissões ao serviço de assistência ao nível correto da sub-OU, mas o fizer na raiz do domínio? Sem um mecanismo de proteção adicional no AD que impeça um administrador de dados, como uma conta de helpdesk, de efetuar quaisquer alterações (como redefinir a palavra-passe) num administrador de serviços, como uma conta de administrador de domínio ou qualquer outra conta ou grupo privilegiado, a segurança geral de qualquer implementação do AD ficaria num estado terrível. Qualquer equipa de helpdesk delegada poderia facilmente comprometer todo o AD.

SDPROP: A funcionalidade de proteção AD incorporada

A proteção desses objectos AD privilegiados é exatamente a tarefa do processo de Propagação do Descritor de Segurança (SDPROP). Este processo é executado periodicamente (a cada 60 minutos por predefinição, ou conforme configurado) em cada emulador de controlador de domínio primário (PDCE) de cada domínio numa floresta do AD e procura todos os objectos privilegiados no respetivo domínio do AD. O SDPROP não verifica apenas os membros dos grupos predefinidos (como administradores de domínio), mas continua a seguir quaisquer grupos que estejam aninhados nesses grupos privilegiados e marca-os e aos seus membros como "privilegiados". Como pode adicionar utilizadores, grupos e até objectos de computador a esses grupos privilegiados, todos esses objectos são considerados durante a verificação. Advertência importante: os objectos têm de ser locais no mesmo domínio que o grupo privilegiado para serem considerados pelo SDPROP, por isso não espere a mesma proteção para utilizadores adicionados a partir de outro domínio.

Para cada objeto privilegiado que o SDPROP encontra, o processo compara o nTSecurityDescriptor do objeto com um modelo de permissão especial que é reservado apenas com o objetivo de proteger esses objectos privilegiados. Este modelo concede uma variedade de permissões, mas o mais importante é garantir que apenas os administradores, administradores de domínio e administradores da empresa podem alterar a palavra-passe de contas privilegiadas. Se o processo SDPROP encontrar um desvio entre as permissões dos objectos que encontra e as do modelo, substitui o nTSecurityDescriptor do objeto relevante pelo do modelo e, em seguida, actualiza o atributo adminCount do objeto com um '1'.

Nos bastidores: AdminSDHolder

O modelo de permissão especial que o SDPROP copia para os seus objectos privilegiados é configurável. É o nTSecurityDescriptor(permissions) do objeto AdminSDHolder do seu domínio. Este nome deve ser familiar: é literalmente o objeto 'admin security descriptor holder', um objeto contentor localizado no contentor do sistema de cada domínio(CN=AdminSDHolder,CN=System,DC=myco mpany,DC=com). As permissões predefinidas em AdminSDHolder são comparativamente restritivas no que diz respeito a alterações nos objectos. É o que se espera de permissões que vão ser impostas a todos os grupos e utilizadores privilegiados do AD. O exemplo de lista de permissões na Figura 5 é de uma implantação recente de um laboratório de teste no Windows Server 2019 que não contém servidores Exchange. Se tiver o Exchange no seu ambiente, encontrará mais permissões adicionadas a este modelo. Afinal de contas, os programadores do Exchange consideraram "possuir" o AD para a sua aplicação. Por agora, tenha em mente que as seguintes permissões são impostas a todos os seus objectos privilegiados no respetivo domínio AD. Mais importante ainda, pode ver que esta lista de controlo de acesso (ACL) não tem a herança activada. Por outras palavras, a ACL bloqueia a herança das permissões definidas num objeto pai (OU), incluindo as permissões de reposição da palavra-passe do serviço de assistência discutidas anteriormente. Desta forma, a combinação de SDPROP e AdminSDHolder protege as suas contas mais privilegiadas de permissões mal configuradas no seu AD.

Tecnicamente, é possível remover alguns grupos de administradores predefinidos no AD de serem considerados privilegiados pelo processo SDPROP, especificamente os grupos de operadores de conta, operadores de servidor, operadores de impressão e operadores de cópia de segurança. Os membros não seriam então substituídos pelas permissões do objeto AdminSDHolder. No entanto, como cada grupo tem seu próprio risco em relação à elevação de privilégios no AD, essa configuração não é recomendada. Vale a pena proteger estes grupos ou, melhor ainda, não os utilizar. Para saber mais sobre como excluir (ou reincluir) estes grupos do processo SDPROP, consulte o artigo "Segurança do Active Directory: Compreender o objeto AdminSDHolder'^.2

A função do atributo AdminCount

O atributo adminCount em si não tem qualquer relevância real em termos de segurança. É uma funcionalidade de suporte simples que permite utilizar mais facilmente uma consulta LDAP para determinar quais as permissões dos objectos que foram substituídas pelas permissões definidas nesse modelo especial, como mostrado anteriormente. Note que uma vez removido um utilizador, grupo ou computador de um grupo privilegiado, este deixará de ser privilegiado. O processo SDPROP escreve o ID de evento 4780 no registo de eventos de segurança do controlador de domínio primário (PDC) ao carimbar as permissões AdminSDHolder em objectos privilegiados e ao atualizar esses objectos com o atributo adminCount (definido como 1). No entanto, não reverte essas alterações quando um objeto deixa de ter privilégios, nem escreve qualquer evento no registo de eventos informando-o de que já não os considera privilegiados. Por exemplo, quando adiciona temporariamente alguém ao grupo de administradores do domínio e o processo SDPROP é executado antes de remover o utilizador, esse utilizador continuará a ter a definição nTSecurityDescriptor bloqueada e será marcado com adminCount=1. O mesmo se aplica a qualquer objeto. Idealmente, então, não deve adicionar temporariamente qualquer utilizador a um grupo privilegiado. Se o tiver feito, deve limpar as permissões e o atributo adminCount para que o utilizador seja configurado de volta ao seu estado original. Este processo de limpeza é descrito mais adiante neste documento.

Um olhar mais atento às permissões do AdminSDHolder

Com uma compreensão destes conceitos, está satisfeito com as permissões que são concedidas através do objeto AdminSDHolder e SDPROP a todas as suas contas privilegiadas? Se olhar mais de perto para essas permissões, mesmo sem o Exchange na mistura, notará algumas permissões questionáveis, conforme destacado na Figura 6, retirado da página de definições de segurança avançadas do objeto AdminSDHolder, ao qual acede através de utilizadores e computadores AD ou edição ADSI. Que acesso é que essas outras entradas marcadas como "especiais" concedem à respectiva entidade de segurança nessa ACL? Infelizmente, o editor de segurança padrão do AD não faz o melhor trabalho ao converter corretamente a cadeia SDDL armazenada no atributo nTSecurityDescriptor . Mesmo quando abre a respectiva entrada de controlo de acesso (ACE), essas permissões especiais muitas vezes não são apresentadas. Assim, tem de as encontrar diretamente através do PowerShell, através de algo como (Get-Acl'AD:CN=AdminSDHolder,CN=System,D C=mydom,DC=local').access, ou utilizando DSACLS.exe, ambos com um resultado difícil de decifrar. Uma ferramenta comparativamente fácil, poderosa e frequentemente ignorada para o gerenciamento de ACLs é o LDP.exe, que faz um trabalho perfeito exibindo todos os ACEs com as informações relevantes. Siga estas etapas para exibir completamente as permissões adequadas do seu objeto AdminSDHolder: Inicie o LDP.exe;

1. Escolha Ligação > Ligar (ou Ctrl + B) e Ligar como o utilizador atualmente ligado;
2. Seleccione Ver > Árvore (ou Ctrl + T) e seleccione o seu domínio como BaseDN;
3. Na árvore de domínios à esquerda, navegue para Sistema > AdminSDHolder;
4. Clique com o botão direito do rato no objeto AdminSDHolder e seleccione Avançado > Descritor de segurança;
5. Clique em OK para visualizar o descritor de segurança;

A janela resultante deve ser semelhante à da Figura 7. Quando compara esta janela com a Figura 6 do editor de segurança padrão, pode ver que até os ACEs estão ordenados pela mesma ordem. Se nunca actualizou as permissões AdminSDHolder com o editor de segurança predefinido (tal como utilizado nos utilizadores e computadores do AD e no ADSIedit), o editor de segurança LDP.exe mostra até os ACEs de acesso originais compatíveis com o Windows 2000, divididos por muitos tipos de objectos. O editor de segurança predefinido não consegue sequer processar corretamente esses ACEs e substitui-os simplesmente por uma permissão de leitura genérica em qualquer outra atualização da ACL; uma vez actualizados com a interface de utilizador (IU) do editor de segurança predefinido, esses outros ACEs para este grupo são automaticamente removidos. Isto não acontece se a permissão AdminSDHolder (ou qualquer outra) for actualizada com o editor de segurança LDP.exe, pelo que, em geral, o LDP.exe é a opção mais segura para trabalhar ao atualizar ACLs críticas no AD.

Agora pode confirmar facilmente que as permissões "Todos" e "Auto-permissões" não são motivo de preocupação. A permissão de alteração da palavra-passe pode parecer perigosa, mas não indica nada mais do que o direito de alterar a palavra-passe de um utilizador quando se conhece a palavra-passe antiga desse mesmo utilizador (ao contrário da redefinição da palavra-passe, que permite a um administrador substituir qualquer palavra-passe existente). Dito isso, qual é o problema com os ACEs destacados? A conta MSOL_5c0317387a29 (ou seja, 'MSOL_' mais uma string aleatória), destacada em laranja na Figura 7, é encontrada na maioria dos ambientes. Esta conta é uma conta predefinida que é criada automaticamente durante a configuração da ferramenta Azure AD Connect, que utiliza a conta para sincronizar objectos entre o AD no local e o Azure AD. As versões mais antigas do Azure AD Connect, ao utilizar a opção de instalação expressa, adicionavam automaticamente a conta à ACL AdminSDHolder para permitir o controlo sobre os grupos e utilizadores privilegiados. Se tiver configurado a sua conta do Azure AD Connect manualmente ou se utilizar uma versão mais recente da ferramenta, poderá não encontrar esta entrada.

Não deve replicar quaisquer contas ou grupos privilegiados do AD para o Azure AD, uma vez que isso pode levar a caminhos de ataque adicionais entre os dois directórios. Se seguir esta regra, não há qualquer requisito para manter a conta de sincronização com permissões desta forma, pelo que pode também remover a entrada de AdminSDHolder. A conta de sincronização em si, no entanto, deve ser vista como altamente privilegiada e sensível, portanto, remover a ACL aqui não fornece muita redução adicional na superfície de ataque do AD. O mesmo não acontece com as duas entradas destacadas a vermelho: os grupos de utilizadores autenticados e de ^acesso3 compatíveis com o pré-Windows 2000. A ambos são concedidas permissões totais de leitura em qualquer objeto privilegiado no AD. Isto não é certamente o ideal; qualquer utilizador (ou computador) na sua floresta AD pode enumerar o conteúdo de qualquer grupo privilegiado (por exemplo, Admins. do Domínio) e listar os vários membros do grupo de qualquer utilizador privilegiado. É exatamente assim que os intrusos gostam: fácil de determinar quem no seu AD deve ser perseguido e qual a conta a capturar e utilizar para efetuar um ataque pass-the-hash ou outro ataque para obter o domínio do domínio e da floresta. É muito provável que os seus utilizadores e aplicações empresariais nunca precisem de consultar estas informações, por isso, porquê concedê-las?

A resposta é simples: não deve. Remova estas duas permissões (incluindo todas as outras ACEs que possam ser atribuídas ao grupo de acesso compatível com o pré-Windows 2000). Substitua-as simplesmente por uma permissão para outro grupo; por exemplo, SVC-ADconfig- AdminSDHolder-READ. Torne esse grupo num grupo Local de domínio para que possa controlar a sua participação quando necessitar de uma conta de serviço ou objeto de computador que execute software que tenha o direito legítimo de ler dados dos seus objectos privilegiados. A utilização do tipo de grupo local de domínio permite-lhe adicionar quaisquer utilizadores, grupos globais ou universais ou computadores de qualquer domínio na sua floresta AD. Poderá necessitar desta capacidade para software ou sistemas que utilize para monitorizar ou administrar o AD. Por exemplo, se executar o Semperis Directory Services Protector (DSP), quererá adicionar a conta de computador DSP a esse grupo. Mas todos os outros utilizadores e computadores estão impedidos de ler qualquer coisa sobre os seus objectos privilegiados, o que é uma forma eficaz de reduzir a superfície de ataque do AD. Os intrusos são simplesmente impedidos de enumerar os objectos adequados. Tenha em atenção que esta ação tem de ser repetida para cada domínio da sua floresta AD.

Um modelo AdminSDHolder atualizado no domínio raiz teria então o aspeto da Figura 8. Para determinar o efeito que essas alterações terão na postura de segurança do AD, deve utilizar os direitos que um intruso teria disponíveis através de um utilizador de domínio normal, antes e depois de alterar a permissão no objeto AdminSDHolder no seu ambiente de produção. Por uma questão de simplicidade, este exemplo verifica a segurança do domínio raiz numa floresta AD, ignorando o domínio filho. Na realidade, é melhor verificar a segurança de todos os domínios da floresta.

Utilização de poderosos scanners de vulnerabilidade do AD

Pode efetuar facilmente estas verificações simples utilizando ferramentas gratuitas: a ferramenta de análise de vulnerabilidades Purple Knight AD^{,4 BloodHound5} e SharpHound (a ferramenta de recolha de dados do BloodHound). Os intrusos utilizam frequentemente uma combinação de SharpHound na rede da vítima e BloodHound numa máquina externa para encontrar o caminho de ataque mais curto para o grupo de administradores de domínio. Ambas as análises de vulnerabilidades podem ser facilmente repetidas num ambiente AD, sem qualquer configuração especial, embora o funcionamento do BloodHound e das suas dependências (ou seja, base de dados NEOj4, Java JDK) possa exigir um esforço substancial. Purple Knight não requer qualquer instalação para além de descarregar e descompactar o ficheiro .zip correspondente.

Antes de ajustar o AdminSDHolder

Este exemplo executa ambas as verificações como um utilizador simples, JustArootUser. Este utilizador não tem direitos especiais de administrador no AD, mas é um utilizador autenticado na floresta do AD. Este cenário imita as acções de um intruso no seu ambiente AD. A primeira análise, utilizando Purple Knight, mostra 29 indicadores de exposição (IOEs) - vulnerabilidades que um intruso poderia utilizar para atacar o AD (consulte a Figura 9). A análise BloodHound/SharpHound lista todas as contas de administrador de domínio (ver Figura 10) a que o utilizador simples pode aceder e o caminho mais curto para esse utilizador aceder ao grupo de administradores de domínio (ver Figura 11).

Depois de ajustar AdminSDHolder

Depois de remover o ACE para os utilizadores autenticados e grupos de acesso compatíveis com o pré-Windows 2000 do AdminSDHolder no domínio raiz e adicionar o ACE para o grupo SVC-ADconfig- AdminSDHolder-READ, tem de aguardar que o processo SDPROP seja executado e atualizar os objectos privilegiados para que os atributos nTSecurityDescriptor sejam actualizados com os do modelo AdminSDHolder. Este processo demora cerca de uma hora, mas pode ativar manualmente a atualização, como descrito mais à frente neste documento. Após estas acções, uma análise Purple Knight encontra apenas 18 IOEs - menos 11 vulnerabilidades do que antes (ver Figura 12). Agora que o utilizador simples já não pode enumerar o grupo de administradores do domínio nem os seus membros, uma análise BloodHound/SharpHound mostra que um intruso seria incapaz de ver os membros do grupo ou localizar caminhos de ataque para eles (ver Figuras 13 e 14).

A AD já é segura?

Note-se que as vulnerabilidades contra contas privilegiadas não desaparecem totalmente; simplesmente não são facilmente visíveis para os atacantes. Mas encontrar os pontos fracos adequados para atacar o seu AD tornou-se muito mais difícil. Por exemplo, os intrusos já não conseguem ver quais os utilizadores privilegiados que estão devidamente protegidos pelo grupo de utilizadores protegidos - um grupo do qual pretende que os administradores de domínio e outros utilizadores privilegiados sejam membros, uma vez que o grupo faz o que o seu nome indica: protege as contas de vários vectores de ataque, como ataques pass-the-hash. Com o confinamento, os intrusos já não podem planear um caminho de ataque detalhado às suas contas mais privilegiadas e têm de encontrar outras formas de comprometer o seu AD. Essas formas são muitas vezes mais complexas. Se tiver uma monitorização adequada do AD e dos pontos finais, esses ataques podem acionar um alarme mais cedo para a sua equipa do centro de operações de segurança (SOC). Uma combinação de ferramentas como o Microsoft Defender for Identity, o Semperis Directory Services Protector e o SentinalOne XDR vai levá-lo bastante longe neste espaço.

No entanto, este confinamento de permissões não significa que possa desistir de outras práticas recomendadas de segurança. Deve continuar a levar a sério a classificação da sua infraestrutura AD por níveis. No mínimo, isto significa que as suas contas com privilégios mais elevados nunca iniciam sessão em qualquer sistema que não sejam os controladores de domínio (ou outros sistemas de nível 0 altamente fiáveis). Ocultar o acesso às suas contas privilegiadas é apenas um aspeto deste tipo de classificação administrativa e aborda especificamente as técnicas de reconhecimento utilizadas pelos atacantes, conforme descrito na estrutura MITRE ATT&CK^.6

Tenha também em atenção que a análise Purple Knight ainda detectou outras potenciais vulnerabilidades, mesmo após o bloqueio do AdminSDHolder. IOEs como 'Non-default principals with DC Sync rights on the domain' ou 'Domain trust to a third-party domain without quarantine', ainda foram encontrados através das permissões padrão para utilizadores autenticados noutros objectos no domínio - e ainda podem ser usados por intrusos para planeamento de ataques.

Ainda não acabaste ...

Agora que criou o grupo SVC- ADconfig-AdminSDHolder-READ, tem ainda de adicionar as contas adequadas ao grupo, que pretende reativar para ler objectos privilegiados. Estas contas incluem contas de serviço com privilégios reduzidos para ferramentas de segurança e gestão e, numa floresta com vários domínios, os administradores de domínio de outros domínios. Por exemplo, a Figura 15 mostra a vista de administrador de domínio de um domínio filho dos objectos de raiz da floresta. Esta conta, que dependia das permissões de utilizadores autenticados em AdminSDHolder, já não tem direitos de leitura dos grupos privilegiados do domínio raiz.

Este problema é facilmente resolvido adicionando o grupo de administradores de domínio do domínio filho (global) ao grupo local SVC-ADconfig- AdminSDHolder-READ no domínio raiz. Depois de bloquear o domínio filho, terá de repetir esta tarefa para adicionar o grupo de administradores de domínio do domínio raiz ao grupo do domínio filho - ou pode tornar o grupo especial AdminSDHolder num grupo universal no seu domínio raiz, utilizá-lo em todos os modelos AdminSDHolder nessa floresta e adicionar-lhe todos os grupos de administradores de domínio. A escolha é sua. Escusado será dizer: não active a herança no próprio modelo AdminSDHolder. Se o fizer, invalidará toda a funcionalidade. Tenha também em atenção que, tal como pode utilizar o AdminSDHolder para bloquear o seu AD removendo as permissões, os intrusos também podem utilizar o objeto para ganhar persistência num AD comprometido. Para o fazer, um intruso começa por criar um utilizador discreto e esconde-o algures na estrutura da sua UO. Em seguida, atribui a este utilizador a permissão para repor as palavras-passe dos utilizadores no modelo AdminSDHolder. O SDPROP faz o resto, permitindo que o intruso mantenha o controlo. É evidente que vai querer monitorizar continuamente este modelo para detetar alterações. Por fim, como mencionado anteriormente, é necessário limpar os administradores e grupos de administradores restantes que possam ter sido gerados ao longo dos anos.

Limpeza de objectos privilegiados: Encontrar objectos mal configurados

Os passos seguintes permitem-lhe localizar e limpar objectos que foram anteriormente considerados privilegiados pelo AD (e portanto 'carimbados' através do SDPROP actualizando a ACL e definindo o atributo adminCount para '1') mas que já não são membros de quaisquer grupos privilegiados:

1. Mark all existing groups with admincount=1 via the telephoneNumber attribute (or some other unused attribute) so that you can more easily locate these groups again in a later stage of the clean-up: Get-ADObject-LDAPfilter “(&(groupType:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))”| Set-ADObject -Replace @ {telephoneNumber=“adminCount- Check-20220730”};
2. Limpa a definição atual do atributo adminCount para todos os grupos anteriormente encontrados: Get- ADObject -LDAPfilter "(&(group Type:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))" | Set- ADObject -Clear "adminCount";
3. Assegure-se de que o processo SDPROP irá reimprimir todos os objectos relevantes: O SDPROP executará uma atualização apenas nos objectos relevantes quando ocorrer uma alteração na ACL no destino ou no AdminSDHolder. A forma mais fácil de garantir que o SDPROP fará a sua magia é adicionar manualmente um ACE falso (por exemplo, Permitir 'Operadores de Backup' a 'Listar Objeto') em AdminSDHolder e, em seguida, remover o ACE após a verificação;
4. Forçar a execução de SDPROP.

Pode esperar até 60 minutos para que o processo SDPROP seja executado (ou seja, esperar que o agendamento predefinido accione a operação). Ou pode forçar o DC com a função PDCE FSMO a iniciar o processo SDPROP sob o seu comando, enviando o comando RunProtectAdminGroupsTask para o RootDSE do seu domínio. O método mais fácil é utilizar o LDP.exe como um utilizador com privilégios de administrador do domínio: escolhendo a opção "executar como administrador" ao iniciá-lo e, em seguida:

• Inicie o LDP.exe, escolhendo a opção Executar como administrador ;
• Seleccione Ligação > Ligar e introduza o DC com a função de emulador PDC no seu domínio;
• Prima Ctrl + B ou seleccione Ligação > Ligar para Ligar como o utilizador atualmente com sessão iniciada;
• Prima Ctrl + M ou seleccione Procurar > Modificar para iniciar uma operação de modificação;
• Deixe DN: em branco e introduza RunProtectAdminGroupsTask como Attribute e 1 como Value;
• Seleccione Operação ADD e, em seguida, clique em Enter ou prima Alt + E;
• Quando vir a entrada [Adicionar] RunProtectAdminGroupsTask:1 na lista de entradas da janela Modificar (ver Figura 16), clique no botão Executar para executar a operação e executar o processo SDPROP.

5. Aguarde que o processo SDPROP termine o processamento. Pode verificar se
   o atributo adminCount=1 retorna aos objectos conhecidos que espera (por exemplo, os membros directos do seu grupo de administradores de domínio) ou verificar o registo de eventos de segurança no PDCE e validar se não são gerados mais eventos com o ID 4780 (categoria de tarefa: gestão de contas de utilizador). Esses eventos mostram-lhe quais os objectos que foram reiniciados através do processo SDPROP.
6. Verifique quais os grupos que não foram actualizados utilizando o sinalizador anterior e adicionando um filtro para esses grupos, em que adminCount não está definido para '1': Get- ADObject-LDAPfilter “(&(groupType: 1.2.840.113556.1.4.803:=2147483648)(telephoneNumber=adminCount-Check-20220730)(!(adminCount=1)))”;
7. O resultado do último filtro são os objectos que vai querer concentrar-se em limpar em breve. Estes ainda contêm a ACL da definição AdminSDHolder na altura em que eram um grupo privilegiado, o que também significa que não herdam quaisquer permissões que possa ter definido ao nível da UO;
8. Repita o mesmo procedimento com o computador e as contas de utilizador. É provável que não queira utilizar o atributo telephoneNumber como o seu AdminSDHolder-check-flag temporário nos objectos de utilizador; talvez o facsimileTelephoneNumber já não esteja a ser utilizado. O filtro LDAP adequado para encontrar os utilizadores privilegiados seria: (&(objectClass=user) (objectCategory=person) (admincount=1));
9. Remova o ACE falso do objeto AdminSDHolder depois de determinar os seus objectos de limpeza.

Limpeza de objectos privilegiados: Redefinindo as ACLs em objetos mal configurados

Utilizar o PowerShell para restaurar ACLs nos objectos relevantes é um pouco mais complicado. Não existe um equivalente simples do PowerShell para a opção "restaurar predefinições" que está disponível na interface de utilizador das definições de segurança avançadas em objectos do AD. Essas predefinições são armazenadas no esquema do AD, especificamente no atributo defaultSecurityDescriptor da classe de objeto relevante. Quando clica na opção restaurar predefinições na interface de segurança, as permissões de classe adequadas são lidas a partir do esquema e, em seguida, aplicadas novamente ao objeto. Se tiver apenas alguns objectos mal configurados, este método pode ser a forma mais fácil de os corrigir. Mas e se tiver muitos desses objectos em várias localizações?

Uma opção é utilizar a ferramenta DSACLS com a opção /resetDefaultDACL , que restaura a segurança do objeto para a sua predefinição, conforme definido no esquema; no entanto, misturar ferramentas PowerShell e CLI pode ser complicado. E embora a Microsoft não tenha criado um equivalente do PowerShell para processar uma reposição direta da ACL para a sua predefinição, pode utilizar o cmdlet Get-ACL para obter a ACL de outro objeto da mesma classe e, em seguida, carimbar essa ACL em objectos mal configurados através do cmdlet Set-ACL. Basicamente, pode copiar e colar ACLs de um objeto para outro através dos comandos Get-ACL e Set-ACL do PowerShell. Como o defaultSecurityDescriptor do esquema também é lido e utilizado na criação de qualquer novo objeto de uma classe específica, pode simplesmente criar um objeto fictício para copiar a ACL. O objeto pode até ser um objeto desativado, uma vez que o seu estado não faz parte da ACL.

Infelizmente, não pode simplesmente canalizar a saída do cmdlet Get-ADObject para o cmdlet Set-ACL, uma vez que este último tem de receber o caminho do objeto num formato específico: o nome distinto (DN) do objeto precedido de 'AD:'. Por conseguinte, é necessário percorrer a lista de objectos devolvidos por Get-ADObject, formar o caminho adequado para utilização com Set-ACL e, em seguida, executar o respetivo comando no ciclo. O seguinte script do PowerShell redefinirá as ACLs dos objectos de classe de utilizador para as de uma conta fictícia recém-criada denominada DefaultUserACL. (O atributo facsimileTelephoneNumber foi anteriormente assinalado para ajudar a localizar as contas mal configuradas).

#Set path for ACLing to AD
Set-Location AD:

#Grab ACL objects from a sample user- account (e.g. newly created account) 
$DefaultAcl = (Get-Acl “AD:CN= DefaultUserACL,OU=MyOU,DC=mydo m,DC=local”)

#query for the old AdminCount objects that must get their permissions reset $OldAdminCountObjects =

Get-ADObject -LDAPfilter 
“(&(objectClass=user)
(objectCategory=person)(facsimile TelephoneNumber=adminCount- Check-20220730)(!(adminCount=1)))”

#work through every object, grab the DN, create the proper ACL-DN-Path and set sample ACL on object
ForEach ($Object in $$OldAdminCountObjects)

{
$ACLpath = “AD:” + $Object. distinguishedName
write-host “Resetting permissions on”, 
$ACLpath
Set-Acl -Path $ACLpath -AclObject 
$DefaultAcl

#update flag of object
Set-ADObject -Identity $Object. 
distinguishedName -Replace 
@{facsimileTelephoneNumber=“ACL was reset 20220730”}
}

Ao adaptar o script para grupos ou computadores, certifique-se de que muda para o filtro LDAP adequado com o atributo que escolheu para o ajudar a localizar esses objectos. Se preferir, pode ignorar a criação desses objectos fictícios e utilizar a mesma lógica de ciclo para executar as ferramentas DSACLS, utilizando o nome distinto do objeto e a opção /resetDefaultDACL . Qualquer um dos métodos o ajudará a limpar corretamente objetos antigos e privilegiados no seu AD.

A segurança do AD requer uma atenção permanente

Este documento destina-se a ajudá-lo a compreender as vantagens da funcionalidade de segurança integrada AdminSDHolder e SDPROP do AD, que protege os objectos com mais privilégios no AD, e como pode bloquear ainda mais esses objectos para uma melhor proteção, com a intenção de combater a fase de reconhecimento de um ataque. Quanto mais difícil for para os intrusos chegarem aos seus objectos mais privilegiados, melhor. Conforme descrito, este método de endurecimento deve ser acompanhado por uma classificação adequada das contas administrativas e pela monitorização ativa do AD e dos pontos finais. Proteger o AD sempre foi importante, e o aumento contínuo dos ataques de ransomware realça esta necessidade.

Recursos

1. Mueller, R. e Geelen, P. (setembro de 2020 [novembro de 2011]), "Active Directory: LDAP Syntax Filters", Microsoft, disponível em https://social.technet. microsoft.com/wiki/contents/articles/5392.active- directory-ldap-syntax-filters.aspx (acedido em 25 de setembro de 2022).

2. Smith, R. (janeiro de 2018), "Segurança do Active Directory: Understanding the AdminSDHolder Object", Petri, disponível em https://petri.com/ active-directory-security-understanding- AdminSDHolder-object (acedido em 25 de setembro de 2022).

3. Grillenmeier, G. (novembro de 2021), 'Understanding the Risks of Pre-Windows 2000 Compatibility Settings in Windows 2022', Semperis, disponível em https://www.semperis.com/blog/security-risks- pre-windows-2000-compatibility-windows-2022/ (acedido em 25 de setembro de 2022).

4. Purple Knight , 'Uncover Active Directory vulnerabilidades before attackers do', disponível em https://www.semperis.com/purple-knight (acessado em 25 de setembro de 2022).

5. GitHub, 'BloodHound 4.2.0 - Azure Refactor', disponível em https://github.com/BloodHoundAD (acedido em 25 de setembro de 2022).

6. MITRE ATT&CK, 'Reconnaissance', disponível em https://attack.mitre.org/tactics/TA0043 (acedido em 25 de setembro de 2022).