Tim Beasley Consultor Sénior de Resposta a Incidentes

Bem-vindos de volta à nossa análise dos grupos do Active Directory que, apesar de não «parecerem» perigosos, representam um risco. Tal como expliquei na nossa primeira parte, os atacantes não precisam de ser administradores de domínio para causar danos graves e nem sempre procuram grupos com esse tipo de privilégios elevados e óbvios.

«Operadores de Conta» é um grupo do AD que muitas pessoas subestimam porque não contém a palavra «admins». É precisamente por isso que é tantas vezes ignorado.

Um equívoco comum é pensar que o grupo «Operadores de Conta» não representa um risco grave, uma vez que os membros não devem alterar grupos protegidos, como o dos «Administradores de Domínio».

Essa suposição é, na melhor das hipóteses, incompleta — e, na pior das hipóteses, perigosa.
É também falsa em determinadas circunstâncias.

A questão principal não é o facto de o grupo «Operadores de Conta» ser um grupo administrativo diretamente de «nível superior» (embora o tratemos como tal). O verdadeiro problema é que este grupo confere um controlo alargado sobre as identidades em todo o domínio — e, no Active Directory, as identidades equivalem a privilégios.


O que é que os operadores de conta podem realmente fazer?

Por predefinição, os membros do grupo «Operadores de Conta» podem criar, alterar e eliminar objetos de utilizador, grupo e computador em grande parte do domínio. Em muitos ambientes, isso inclui a capacidade de:

  • Redefinir palavras-passe
  • Ativar ou desativar contas
  • Editar nomes de entidades de serviço (SPNs)
  • Gerir a adesão a grupos não protegidos
  • Criar novas contas de utilizador

Os operadores de conta estão intencionalmente impedidos de modificar diretamente grupos e contas protegidos controlados pelo AdminSDHolder, incluindo os «Domain Admins», «Enterprise Admins», «Schema Admins» e o grupo «Administrators» integrado nos controladores de domínio.

No entanto, essas restrições não eliminam as vias de ataque que um agente malicioso experiente pode utilizar após ter comprometido um membro dos Operadores de Conta.

Esse é o ponto fundamental que os defensores têm de interiorizar: o «Account Operators» não é uma função de administrador delegada inofensiva.
Trata-se de um amplificador de privilégios situado diretamente no plano de identidade.


Por que é que o grupo dos Operadores de Contas se torna perigoso tão rapidamente?

Se um atacante comprometer as credenciais de um Operador de Conta, não precisa de se adicionar ao grupo de Administradores do Domínio para começar a ter sucesso.

Já os vi criar utilizadores controlados por atacantes, redefinir palavras-passe de contas privilegiadas não protegidas, manipular indiretamente a pertença a grupos, adicionar SPNs para a configuração de «kerberoasting» e abusar da criação de objetos de computador para ataques de delegação, tais como a delegação restrita baseada em recursos.

Isto é importante porque muitos dos percursos de ataque mais realistas a empresas não exigem aceder primeiro aos grupos óbvios que constituem as «joias da coroa». Basta-lhes ter as identidades certas, os grupos delegados certos e os percursos de autenticação certos durante o tempo suficiente para fazerem a transição.

Por outras palavras, os «Account Operators» conferem a um atacante acesso de escrita distribuído em toda a estrutura de identidades. Isso é, muitas vezes, mais do que suficiente para passar de «sem grandes privilégios» para «tenho-te na mão».


Cenários realistas de abuso após a violação de contas por parte de operadores de contas

Uma via óbvia é a criação de contas por via de backdoor. Um atacante pode criar um novo utilizador e, em seguida, colocá-lo em grupos privilegiados ou semiprivilegiados que possa controlar, incluindo grupos com vias de escalonamento ocultas que são frequentemente monitorizadas de forma muito menos rigorosa do que os «Domain Admins». Além disso, esta abordagem dá-lhe a capacidade de identificar o aninhamento de grupos dentro de grupos privilegiados, permitindo uma maior escalonamento e persistência.

Outra forma comum é a atividade de redefinição de palavras-passe direcionada ou em massa. Os operadores de contas podem redefinir as palavras-passe da maioria dos utilizadores do domínio, incluindo contas de serviço, identidades de aplicações e utilizadores administrativos não protegidos. Nas mãos de um agente malicioso, isso traduz-se em acesso operacional imediato e numa potencial perturbação das atividades da empresa.

Uma terceira via é o abuso de SPN e o «kerberoasting». Se um atacante conseguir editar os atributos de uma conta e adicionar SPNs, poderá criar novos alvos suscetíveis a «kerberoasting» ou tornar as contas existentes vulneráveis a explorações, sem que o «ataque» pareça óbvio.

Uma quarta forma consiste em explorar contas não protegidas, mas que continuam a ser valiosas. Muitas organizações ainda têm administradores delegados, contas de serviço antigas e grupos aninhados que não estão protegidos pelo AdminSDHolder. Reiniciar palavras-passe ou alterar atributos nesses objetos pode ser suficiente para obter privilégios superiores.

E depois há uso indevido de contas informáticas. Uma vez que os operadores de conta podem, muitas vezes, criar objetos informáticos e controlar o que criam, podem possibilitar ataques que envolvam MachineAccountQuota e a delegação limitada com base em recursos. Isso abre caminho para a suplantação de identidade e a escalada de privilégios sem nunca tocar diretamente no grupo «Domain Admins».

Já nos estamos a divertir?


A nuance do AdminSDHolder que os defensores não devem ignorar

É aqui que a conversa se torna ainda mais desconfortável.

Em teoria, os Operadores de Conta não deveriam poder modificar grupos protegidos, como os «Domain Admins» ou os «Enterprise Admins».

Na prática, essa proteção não é aplicada de forma contínua. É aplicada pelo processo «Security Descriptor Propagator», vulgarmente denominado SDProp, que aplica a ACL «AdminSDHolder» aos objetos protegidos num ciclo periódico. Por predefinição, esse ciclo ocorre aproximadamente a cada 60 minutos.

O intervalo padrão de 60 minutos do SDProp é importante. Entre as execuções do processo, os «objetos protegidos» podem desviar-se temporariamente do descritor de segurança pretendido. Se as permissões se tiverem alterado, se os direitos herdados ou delegados ainda não tiverem sido totalmente corrigidos, ou se um objeto recém-criado ou recém-modificado não tiver sido re-marcado, um invasor pode ter uma oportunidade de curta duração para abusar dessa lacuna antes de o SDProp voltar a aplicar a ACL protegida.

Isso significa que um atacante pode não precisar de uma adesão persistente a um grupo protegido. Pode bastar-lhe tempo suficiente dentro desse intervalo padrão de 60 minutos para adicionar um principal controlado, iniciar uma sessão privilegiada, extrair segredos, criar contas de porta traseira ou estabelecer persistência noutro local antes que o SDProp remova as provas evidentes ao nível da ACL ou da adesão. Pode até ter tempo para redefinir uma conta de administrador recém-criada.

60 minutos é muito tempo para um cibercriminoso experiente.

Isso constitui um grave problema de deteção para os responsáveis pela segurança, pois cria a possibilidade de uma condição de utilizador privilegiado de duração muito curta, seguida de atividades privilegiadas realizadas a partir de uma conta que poderá já não parecer privilegiada quando os investigadores a analisarem posteriormente.

A principal conclusão é que a proteção do AdminSDHolder é consistentemente eventual, não em tempo real, e que a programação padrão do SDProp, de 60 minutos, constitui a lacuna que um atacante tenta explorar.


O que devem os responsáveis pela segurança monitorizar para detetar abusos por parte de operadores de contas?

Se pretender detetar abusos por parte dos Operadores de Contas, comece por analisar a atividade relacionada com o ciclo de vida das identidades. A criação de novas contas, a ativação de contas, a redefinição de palavras-passe e as alterações às contas são, todas elas, sinais fundamentais quando realizadas por um membro deste grupo. Os eventos relevantes incluem os códigos 4720, 4722, 4723, 4724 e 4738.

Em seguida, acompanhe de perto as alterações na composição dos grupos, especialmente as adições a grupos delegados invulgares, grupos aninhados ou grupos com privilégios raramente utilizados. Eventos como o 4728, o 4732 e o 4756 são relevantes neste contexto e, no cenário de janela curta, também é necessário correlacionar padrões rápidos de adição e remoção com os eventos 4729, 4733 e 4757.

Deve também estar atento a alterações no SPN e a outras modificações nos atributos do diretório. Evento 5136 é importante para situações inesperadas servicePrincipalName alterações, alterações de atributos relacionadas com a delegação, tais como msDS-AllowedToActOnBehalfOfOtherIdentity, e outras alterações suspeitas em objetos recém-criados ou recém-modificados.

Por fim, estabeleça uma linha de base comportamental.

  • Quantos utilizadores cria normalmente um membro da equipa de Operadores de Contas num dia?
  • Quantas redefinições de palavra-passe costumam fazer?
  • Quais são os alvos habituais?

É quando se verifica um desvio em relação a essa linha de base que começam as deteções de elevada fiabilidade.


O que fazer a esse respeito

A resposta preferida é simples: esvaziar o grupo.

Se não houver qualquer motivo operacional válido para utilizar os Operadores de Conta (o que é quase SEMPRE o caso), remova a adesão e mantenha-a vazia. Se ainda precisar de administração delegada, recorra à delegação personalizada nas UOs e nos objetos específicos que realmente necessitem de gestão.

Se não for possível eliminar imediatamente a filiação ao grupo, trate-a como algo muito mais sensível do que a maioria das organizações faz atualmente.

  • Aplicar a classificação administrativa
  • Impedir o início de sessão interativo em controladores de domínio e servidores críticos
  • Recusar o início de sessão local sempre que possível

Deve também reduzir as possibilidades de utilização indevida de objetos informáticos, reforçando MachineAccountQuota (de preferência a zero), sempre que apropriado, e restringindo quem pode criar novas contas de utilizador.

Além disso, monitorize explicitamente as áreas que podem permitir uma escalação de privilégios em curto prazo ou indireta: alterações nos grupos privilegiados, alterações na delegação, modificações no SPN e alterações na ACL no AdminSDHolder e nos grupos protegidos.


Repensar os riscos associados aos operadores de contas

O grupo «Operadores de Conta» é perigoso porque confere um controlo alargado sobre os objetos que definem o acesso, a confiança e a autenticação em todo o Active Directory.

A identidade de um Operador de Conta comprometida permite criar novos entidades, redefinir palavras-passe, manipular grupos, configurar o «Kerberoasting», abusar da delegação, estabelecer persistência e, nas condições certas, explorar o atraso incorporado na proteção do AdminSDHolder.

É por isso que os defensores experientes devem deixar de considerar os Operadores de Conta como uma função de suporte obsoleta e começar a tratá-la pelo que realmente é: acesso pré-privilegiado com múltiplas vias de escalonamento… também conhecido como Nível 0.

A identidade é o perímetro… protejam-na.

Até à próxima…Acompanhe a conversa sobre Operadores de Conta no LinkedIn.

E se pretender ajuda especializada para identificar e colmatar as falhas de segurança do seu Active Directory, contacte-nos para uma Avaliação de Segurança do Active Directory. Estamos aqui para o ajudar.


Ler mais