Active Directory (AD) é um produto da Microsoft projetado para auxiliar administradores de rede no gerenciamento de permissões de usuários dentro de uma organização. Ele é instalado em um Windows Server, transformando-o em um Controlador de Domínio responsável por gerenciar ambientes corporativos e executar ações como armazenar todos os contas de usuário, suas senhas e permissões e gerenciamento da autenticação do usuário.
Com o tempo, o mundo está se movendo cada vez mais em direção à adoção da nuvem, e a Microsoft também tem pressionado as organizações a mudarem para ambientes baseados em nuvem para ambientes mais simplificados e modernos. gerenciamento de identidade. A solução da Microsoft para ambiente de domínio baseado em nuvem é Entra ID. Ele estende os recursos do AD local para a nuvem, fornecendo uma solução robusta para gerenciar identidades e acesso para aplicativos baseados em nuvem. Para permitir uma integração perfeita com sistemas legados de suporte, a Microsoft introduziu Entra ID Conectar. Esta ferramenta permite que as organizações vinculem seus locais Active Directory (AD) ambiente com Entra ID, criando um “ambiente híbrido unido”.
Através da Entra ID Connect, as organizações podem sincronizar usuários e dados de diretório de seus ADs locais para a nuvem. Isso permite que os usuários acessem serviços de nuvem enquanto usam as mesmas credenciais de seus sistemas locais. Um recurso interessante Entra ID O Connect oferece suporte a writeback de senha, onde as alterações de senha feitas na nuvem são sincronizadas de volta para o AD local, garantindo um gerenciamento de identidade consistente em ambos os ambientes. Esse modelo híbrido garante que as organizações possam manter um sistema de identidade unificado enquanto operam em infraestruturas na nuvem e no local.
As diferenças no gerenciamento de permissões entre legados Active Directory e Entra ID pode levar a lacunas de segurança no processo de sincronização entre os dois produtos.
Mergulho profundo no gerenciamento de permissões
Gerenciamento de permissões em Active Directory opera de tal forma que em cada ambiente, há vários grupos de segurança privilegiados padrão com permissões elevadas para fazer alterações. Quando queremos conceder essas permissões a um usuário específico, simplesmente o adicionamos ao grupo. Por exemplo, o grupo “Administrador de Domínio” concede privilégios a todos os usuários dentro dele. Outro método para definir permissões para usuários ou grupos é por meio da ACL (Lista de Controle de Acesso). Essa lista existe para cada objeto no AD e especifica as permissões para cada entidade. Esse mecanismo permite a atribuição de permissões a um usuário regular para fazer modificações, mesmo em objetos pertencentes a usuários com privilégios de alto nível, como Administradores de Domínio.
No entanto, em Entra ID (anteriormente Azure AD), não há grupos de segurança por padrão. Em vez disso, ele usa um mecanismo RBAC (Role-Based Access Control). Isso significa que há muitos tipos de funções, cada uma definindo diferentes permissões de usuário. Você também pode atribuir uma função a um grupo, e todos os membros desse grupo herdarão as mesmas permissões. Mas essa opção não inclui grupos definidos por padrão, como Active Directory.
Então, qual é a diferença entre os dois mecanismos? No Entra, uma proteção de modificação é fornecida quando um usuário recebe permissões privilegiadas por atribuição de função ou grupo. No AD legado, descobrimos que nem todos os grupos sensíveis são protegidos contra modificações. Na verdade, certos grupos sensíveis são tratados como fracos quando se trata de Entra ID Conecte a sincronização.
No Entra, sempre que um usuário recebe uma função privilegiada, ele recebe automaticamente proteção de modificação. Apenas um usuário com privilégios de nível mais alto ou nível de função equivalente pode executar alterações, impedindo que qualquer outro usuário com nível de função mais baixo o faça. Isso significa que o usuário não precisa ser membro de um grupo de segurança para ser protegido — simplesmente atribuir a ele uma função privilegiada é o suficiente para fornecer a ele algum nível de proteção, diferente do AD.
Por exemplo, na hierarquia de funções de administrador dentro Entra ID, Administrador de senhas A função concede aos usuários a capacidade de redefinir senhas. No entanto, apesar de ser categorizada como administrador, essa função é considerada uma das mais baixas na hierarquia de administração. Como resultado, os administradores de senhas só podem redefinir senhas para usuários regulares ou usuários que possuem a mesma função de administrador. Eles não têm autoridade para redefinir senhas para usuários em níveis mais altos funções de administrador, como administradores globais ou outros contas privilegiadas, mantendo um limite de segurança claro entre diferentes funções de administrador. Essa estrutura hierárquica garante que funções mais sensíveis sejam protegidas de alterações de senha não autorizadas.
Como ocorre a sincronização?
O processo de sincronização entre o AD local e Entra ID pode ser dividido em duas partes principais:
- Sincronizando identidades do local para Entra ID
- Writeback de senha de Entra ID para o local
Parte 1: Sincronização do local para Entra ID
Entra ID Conectar cria um conta de serviço usuário chamado MSOL seguindo os primeiros 8 bytes do identificador de instalação. Este usuário tem recursos poderosos que podem ser equivalentes a um Controlador de Domínio. A permissão “Replicating Directory Changes All” permite que o usuário execute a sincronização DC e extraia todos os atributos do objeto, incluindo as credenciais do cliente – em outras palavras, seu NT Hash. Devido às extensas permissões concedidas a este usuário no diretório, ele pode acessar e ler informações sobre usuários em grupos protegidos. Isso ocorre porque as permissões fornecidas permitem que o usuário opere com privilégios semelhantes aos do Controlador de Domínio. Consequentemente, mesmo que o usuário não esteja explicitamente listado na ACL de um grupo, ele ainda retém a capacidade de recuperar o NT Hash dos membros do grupo. Esta permissão permite o lado local do processo de sincronização e é gerenciada usando o Directory Replication Service Remote Protocol, que opera sobre o transporte RPC. O mesmo protocolo é usado para executar o ataque DCSync. O agente de sincronização local envia todas as informações e atributos do usuário para Entra ID pela porta 443. Depois que o Entra recebe esses dados, ele processa e preenche os detalhes necessários em seu ambiente, concluindo o processo de sincronização inicial.
Parte 2: Writeback de senha de Entra ID para o local
A segunda parte do processo de sincronização ocorre quando o Password Writeback está habilitado no Entra AD Connect. Esse recurso permite a sincronização de senhas da nuvem para o ambiente local, então quando um usuário altera sua senha na nuvem, a alteração também é refletida no local. Isso garante a sincronização precisa entre os dois ambientes, que é um dos principais motivos para conectá-los: permitir que os usuários façam login com a mesma senha em todos os aplicativos e ambientes da organização.
Quando uma ação de redefinição de senha é iniciada para um usuário em Entra ID, o sistema primeiro procura o nome de usuário para verificar se ele existe em Entra ID. Se o usuário for descoberto, uma verificação de permissões será realizada para ver se a pessoa que está tentando redefinir a senha tem uma função que lhe permita executar essa ação. Se o usuário tiver as permissões necessárias, Entra ID envia o nome de usuário e a nova senha para o Entra Service Bus.
O agente de sincronização em execução no local recupera essas informações. Como o usuário MSOL criado pelo Entra Connect tem permissões de sincronização do DS, mas apenas para leitura, ele não usa o protocolo RPC para redefinir a senha. Em vez disso, ele executa uma solicitação LDAP para localizar o usuário correspondente em Active Directory e tenta atualizar a senha com a solicitação usando a operação “IADsUser.ChangePassword”.
Nesta fase, é realizada uma verificação de segurança crucial: quando a solicitação LDAP é recebida pelo controlador de domínio (DC), o Active Directory O sistema de permissões verifica se o usuário que está tentando alterar a senha tem as permissões necessárias para redefinir a senha do usuário de destino. Isso é feito examinando a ACL do usuário de destino. Se o usuário MSOL não tiver a permissão “Redefinir senha” sobre a entidade, um erro será enviado de volta para Entra ID, indicando que a atualização da senha falhou devido a permissões insuficientes. Se a permissão “Reset Password” estiver presente, a alteração da senha foi concluída com sucesso.
A lacuna de segurança
Durante o processo de sincronização, notei que não há cobertura completa de quais usuários pertencem a grupos privilegiados ou têm permissões mais altas. Consequentemente, no ambiente Entra, esses usuários não recebem automaticamente o mesmo status privilegiado que recebem no local. Por padrão, os usuários híbridos não recebem a mesma proteção que as funções privilegiadas no Entra durante a sincronização inicial, a menos que o administrador da rede atribua manualmente esses privilégios e proteções dentro Entra ID.
Compreendendo os recursos de sincronização entre os dois ambientes e a capacidade de sincronizar credenciais do Entra para o local, surge a pergunta: quais são os riscos potenciais envolvidos?
O principal risco é obter permissões elevadas no AD local por meio de uma função de administrador fraca no Entra. Enquanto estiver no AD, um usuário pode receber permissões privilegiadas, mas não necessariamente pertencer a um grupo protegido, o que o deixa exposto a ataques. O mesmo risco existe neste fluxo de ataque aqui:
Uma vez que um invasor obtém o controle sobre um Entra ID usuário com a função Password Administrator atribuída, eles podem aproveitar sua permissão de redefinição de senha para elevar suas permissões, mesmo que o usuário não tenha um usuário local. Ao redefinir a senha de um usuário com permissões elevadas do AD, como um usuário do grupo DNS Admins, eles podem obter controle sobre a conta e potencialmente escalar privilégios dentro do domínio local.
Tudo o que o invasor precisa fazer é efetuar login com a conta de usuário correta, que tenha pelo menos a função de Administrador de Senhas para Entra ID. Não importa se eles usam a interface em https://entra.microsoft.com or https://portal.azure.com. Uma vez logados, eles selecionam o usuário local alvo e simplesmente redefinem sua senha. Isso permite que o invasor faça login no ambiente local com a conta cuja senha ele alterou.
É importante observar que, se o usuário visado fizer parte de um grupo protegido no ambiente local, o ataque falhará.
Isso ocorre porque o gerenciamento de permissões para usuários protegidos no local bloqueia alterações feitas por um Entra ID Conecte a conta aos usuários nesses grupos protegidos. Em um ambiente local, os grupos protegidos podem ser identificados examinando o Contagem de administradores atributo do grupo. Se o Contagem de administradores atributo é definido como “1”, indica que o grupo é considerado protegido. Esses grupos protegidos seguem um modelo de permissões fixas que é periodicamente aplicado. A cada hora, um mecanismo de proteção em Active Directory executa um processo que verifica se as permissões do grupo no ACL corresponder às permissões definidas no template. Se houver uma discrepância, o processo redefine as permissões para alinhar com o template.
Este processo é gerido por um mecanismo denominado SDProp (Security Descriptor Propagator), e o modelo de permissões é conhecido como AdministradorSDHolder.
Cenários de ataque que exploram essa fraqueza
Administradores de sombra
Administradores de sombra são usuários que podem redefinir a senha para um administrador, mas não pertencem a nenhum grupo de administradores. Como ambos no local Active Directory e Entra ID tratar esses Shadow Admins como usuários regulares (sem proteção especial por grupos de usuários privilegiados), um invasor pode explorar sua capacidade de redefinir a senha de um usuário privilegiado no Entra. Isso significa que o invasor também pode redefinir a senha desse usuário no ambiente local.
Esse cenário fornece aos invasores um caminho claro para aumentar privilégios e expandir seu controle pela rede, aproveitando as permissões elevadas do usuário comprometido.
Grupo de administração DNS
Outro exemplo é o grupo DNS Admin. Os DNS Admins gerenciam componentes críticos de infraestrutura de rede, especificamente servidores DNS. Como o grupo DNS Admin é configurado como um grupo privilegiado sem proteção adicional no local, um invasor pode facilmente redefinir a senha de um membro do grupo DNS Admin via Entra. Isso daria a eles controle total sobre essa conta no ambiente local.
Com o controle de uma conta de administrador DNS, o invasor pode interromper significativamente as operações de rede. Eles podem modificar os registros DNS para redirecionar o tráfego de rede interna, executar Homem-no-meio (MITM) ataques redirecionando o tráfego através de servidores que eles controlam ou alterando as configurações de DNS para enviar usuários para sites maliciosos.
Proprietários do Criador de Política de Grupo
Proprietários do Criador de Política de Grupo é outro exemplo de um grupo que pode ser um grupo privilegiado sem proteção adicional. Os membros deste grupo podem modificar Objetos de Política de Grupo (GPOs) que eles criaram. Se um invasor obtiver acesso a uma conta neste grupo, ele poderá explorar suas permissões para modificar GPOs impostos existentes que podem incluir scripts ou configurações prejudiciais, como scripts que podem roubar credenciais ou instalar malware.
Grupo de editores certificados
Editores de certificados grupo é outro exemplo de um grupo privilegiado que pode nem sempre receber a atenção necessária em relação à segurança. Os membros deste grupo têm a capacidade de publicar certificados para Active Directory, que desempenha um papel fundamental na organização Infraestrutura de chave pública (PKI). Se um invasor obtiver acesso a uma conta que faz parte do Editores de certificados grupo, eles podem emitir ou manipular certificados, levando a sérios riscos de segurança.
Por exemplo, o invasor pode publicar um certificado malicioso ou desonesto para personificar usuários ou serviços confiáveis, permitindo-lhes realizar ataques MITM, descriptografar comunicações seguras ou ignorar autenticação controles. O invasor também pode escalar privilégios emitindo certificados para contas com altos privilégios, como administradores de domínio, levando ao comprometimento total do domínio.
Mitigação de ataque
1. Ao usar uma configuração de identidade híbrida unida, sempre compare as permissões entre seu ambiente local e o Entra. Além disso, certifique-se de que usuários privilegiados que existem apenas no Entra e não têm contas correspondentes no local não recebam permissões de redefinição de senha. Isso ajuda a evitar acesso externo não autorizado e controle sobre seu ambiente.
2. Ao configurar a sincronização entre o local Active Directory (AD) e Entra ID, é essencial sempre verificar as permissões atribuídas a grupos privilegiados em seu ambiente local. Especificamente, você deve garantir que esses grupos não tenham permissões de alteração de senha desnecessárias.
Se você perceber que membros de grupos privilegiados podem alterar senhas, você tem duas opções para resolver isso:
- Remover manualmente as permissões: você pode ajustar manualmente as permissões para cada grupo privilegiado para remover a capacidade de alterar senhas.
- Aproveite o modelo AdminSDHolder: Como alternativa, você pode modificar o Contagem de administradores atributo dos grupos privilegiados ser igual a “1”, protegendo-os assim.
O AdminSDHolder é um modelo de segurança em Active Directory que define e aplica permissões de segurança para membros de grupos protegidos. Ao adicionar os grupos privilegiados a este modelo, você pode remover automaticamente suas permissões de alteração de senha.
