Termos sensiveis nas descricoes do AD: rever DA e admin

Termos sensiveis nas descricoes do AD podem revelar quais identidades merecem atenção adicional, mesmo quando o texto não contém uma senha. Este guia separa uma revisão manual abrangente de rótulos como DA, admin e privileged dos cinco padrões implementados pelo etc-collector e mostra como inventariar, limpar e verificar novamente descrições individuais.

O que os termos sensíveis nas descrições do AD revelam

Uma descrição como domain admin — backup operator é uma declaração sobre a finalidade de uma conta. A inferência de segurança é que um leitor poderia usar essa declaração para selecionar possíveis alvos. Ela não demonstra que a conta realmente possui direitos administrativos. O exemplo é fictício; não é uma observação de produção nem um ataque confirmado.

A mesma distinção aplica-se a DA, notas sobre acesso de emergência e rótulos de serviços. Um revisor pode interpretá-los como pistas sobre o papel de uma identidade, mas a terminologia local importa. admin pode referir-se a trabalho administrativo fora da TI. service client pode descrever um departamento comercial. Uma descrição antiga pode sobreviver a uma mudança de funções. Pergunte ao responsável o que o texto significa antes de o tratar como evidência de privilégios atuais.

Este artigo trata da identificação de alvos sem um segredo. Para senhas exatas, valores temporários ou pistas sobre credenciais, siga o procedimento de exposição de senhas, rotação e investigação nos campos de descrição do AD. Eliminar um rótulo de função e responder à exposição de uma credencial são tarefas diferentes; descobrir um segredo altera a resposta necessária.

Use um registo de revisão que distinga o texto observado, a sua interpretação e as evidências ainda necessárias. Por exemplo, registe «a descrição contém privileged» separadamente de «o responsável confirmou que esta é uma identidade administrativa». Mantenha um caso por resolver aberto quando o responsável for desconhecido. Não transforme uma correspondência lexical numa declaração de que a conta está comprometida, contorna a MFA ou pertence a Domain Admins.

Como funciona o acesso de leitura às descrições

O guia da Microsoft sobre contas e grupos privilegiados explica que as ACL normalmente concedem a Authenticated Users acesso a informações gerais dos objetos. A secção sobre permissões inclui explicitamente as propriedades gerais dos utilizadores. Isto fundamenta a revisão da exposição das descrições com uma identidade autenticada comum, em vez de assumir que o campo é visível apenas para administradores. Autenticado não significa anónimo, e a permissão de leitura não implica permissão de edição.

A documentação histórica sobre atributos confidenciais também descreve o acesso de leitura predefinido aos atributos e o papel de READ_PROPERTY. O acesso real depende das permissões efetivas do objeto. Uma alteração local de permissões pode mudar o que um leitor recebe; verifique a implementação em vez de assumir que todos os objetos seguem o comportamento predefinido.

A referência do esquema de description identifica o atributo LDAP como description, com searchFlags=0x00000000 e systemFlags=0x00000010. As suas observações distinguem descrições de valor único para classes geridas pelo SAM, incluindo principais de segurança, de possíveis valores múltiplos noutras classes. Uma revisão alargada de objetos deve preservar esses valores, em vez de assumir que toda a descrição é uma única cadeia de uma conta de utilizador.

Para uma comparação útil da exposição, escolha um objeto que se sabe estar preenchido e execute a mesma leitura delimitada com um leitor comum e um revisor autorizado. Registe a identidade utilizada, o controlador de domínio, a base de pesquisa, a hora e quaisquer erros. Este é um procedimento de medição recomendado, não uma afirmação de que estes testes foram realizados aqui. Guarde o material de revisão num local com controlo de acesso; um exercício de limpeza não deve tornar-se uma nova lista de identidades sensíveis amplamente partilhada.

Deteção

Passo 1 — Inventariar descrições de utilizadores preenchidas

Os comandos abaixo são adaptados do Microsoft Learn, usando os parâmetros documentados de Get-ADUser e Get-ADObject. Não foram executados num diretório para este artigo. Substitua o DN e o servidor de exemplo, use o módulo ActiveDirectory e selecione o leitor cujo acesso pretende medir. Cada bloco é uma medição separada.

Comece pelas descrições de utilizadores preenchidas:

Get-ADUser -LDAPFilter '(description=*)' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Pedir -Properties description solicita o atributo; não concede acesso. Trate uma resposta vazia como algo a investigar. Verifique o âmbito, as permissões e se um objeto que se sabe estar preenchido é devolvido antes de declarar que o diretório não contém descrições sensíveis.

Passo 2 — Separar contas ativadas e desativadas

O exemplo 5 de Get-ADUser da Microsoft usa o teste LDAP bit a bit para o bit 2 de userAccountControl para excluir contas desativadas. O inventário abaixo acrescenta a condição da descrição e usa a forma NOT entre parênteses documentada na sintaxe de filtros de pesquisa LDAP da Microsoft:

Get-ADUser -LDAPFilter '(&(description=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Para a revisão complementar, mantenha o teste de bit sem negação:

Get-ADUser -LDAPFilter '(&(description=*)(userAccountControl:1.2.840.113556.1.4.803:=2))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Isto separa o estado da conta, não o privilégio real. Mantenha os objetos desativados na fila de limpeza e reveja as suas descrições antes de qualquer reativação planeada. Não interprete o sinalizador de desativação como prova de que ninguém pode ler o objeto ou de que todas as sessões históricas foram invalidadas.

Passo 3 — Rever correspondências lexicais e outros rótulos locais

Uma lista reduzida por subcadeias pode tornar a primeira análise mais manejável:

Get-ADUser -LDAPFilter '(|(description=*admin*)(description=*privileged*))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Esta seleção LDAP não é equivalente às regex do coletor. Reveja o inventário original de descrições preenchidas à procura de DA, break-glass, service, abreviaturas locais e termos noutras línguas. Caso contrário, uma consulta restrita pode ocultar precisamente os rótulos que o exercício manual pretende avaliar.

Os padrões exatos do coletor estão definidos em accounts/privileged/domain-admin-description.go:35–41, relativamente a public/internal/audit/detectors/ad/:

(?i)domain\s*admin
(?i)enterprise\s*admin
(?i)administrator
(?i)admin\s*account
(?i)privileged

Os cinco ignoram maiúsculas e minúsculas. Não têm limites de palavra nem âncoras de início ou fim, e \s* permite zero caracteres de espaço em branco. Consequentemente, domainadmin corresponde ao primeiro padrão e unprivileged ao último. Este último pode descrever o oposto do que um revisor espera; examine o valor completo em vez de tratar a subcadeia correspondente como um veredito.

Estes resultados decorrem dos padrões do código-fonte; não são resultados comunicados de uma auditoria em ambiente real. Mantenha três conclusões separadas: texto correspondente, finalidade confirmada pelo responsável e acesso verificado de forma independente. Esta separação permite explicar um falso positivo sem fingir que o inventário mais amplo está completo.

Passo 4 — Alargar os objetos e monitorizar alterações

Se as descrições de outras classes de objetos estiverem no âmbito, use um inventário separado:

Get-ADObject -LDAPFilter '(description=*)' -Properties description -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Isto inclui qualquer classe de objeto devolvida com uma descrição preenchida. É uma extensão manual para além dos dois detetores de utilizadores, não uma evidência de que a sua cobertura automática inclui esses objetos. Preserve vários valores de descrição quando o esquema o permitir.

Para monitorizar a reintrodução, a referência da Microsoft para Event ID 5136 documenta modificações no diretório. Configure Audit Directory Service Changes e uma SACL Write adequada para os objetos e atributos monitorizados. Selecione eventos em que AttributeLDAPDisplayName=description; examine o autor, o objeto e o valor. Quando os eventos Value Deleted e Value Added estiverem ambos disponíveis, correlacione-os usando OpCorrelationID e o mesmo objeto e atributo.

A ausência de um evento 5136 não prova que ninguém leu o texto anterior. Estes eventos de alteração e o inventário de postura respondem a perguntas diferentes: o que está escrito agora e que modificação auditada ocorreu.

Correção (Remediation)

Passo 1 — Acordar a informação de substituição

Para uma divulgação apenas da função, o fluxo recomendado é transferir o contexto sensível para um inventário ou manual operacional com controlos de acesso adequados. Peça ao responsável que aprove o que deve permanecer no AD. Uma referência opaca como Managed record INV-01234 pode preservar um apontador operacional sem nomear o privilégio ou o procedimento de emergência. O sistema referenciado também tem de controlar o acesso; ocultar apenas o nome de um registo não é autorização.

Defina exemplos de formulações aceitáveis e inaceitáveis com a equipa que provisiona contas. Inclua rótulos locais que as verificações automáticas não detetam. Reveja modelos do apoio técnico, instruções de passagem de responsabilidade e quem pode editar descrições, para que a mesma nota não seja reposta na próxima tarefa de manutenção. Tome uma decisão por objeto, em vez de limpar indiscriminadamente todas as descrições preenchidas.

Passo 2 — Pré-visualizar e confirmar a alteração de um campo

Estes exemplos adaptam os parâmetros Clear, Description, WhatIf e Confirm documentados de Set-ADUser. O exemplo 4 limpa especificamente description. Escolha a remoção ou a substituição para a conta selecionada.

Pré-visualize a remoção:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -WhatIf

Após a aprovação do responsável, solicite confirmação para a remoção efetiva:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -Confirm

Em alternativa, pré-visualize uma substituição neutra:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -WhatIf

Depois confirme essa substituição separadamente:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -Confirm

-WhatIf não aplica a alteração nem prova a compatibilidade das aplicações. Preserve a identidade do objeto selecionado e a ação aprovada no registo da alteração e depois verifique o valor escrito. Estes comandos são exemplos documentados, não um script de correção global nem um relatório de limpeza concluída.

Passo 3 — Evitar atalhos de confidencialidade não suportados

Se forem consideradas restrições locais de leitura, solicite primeiro uma revisão das permissões efetivas e das dependências. As páginas da Microsoft sobre permissões e atributos confidenciais explicam ACE, herança e verificações de leitura; não validam uma receita universal de ACL para esta implementação. Acrescentar um leitor dedicado não remove uma concessão abrangente já existente. Não remova globalmente o acesso de leitura de Authenticated Users sem auditar os consumidores e a delegação.

Prefira guardar informação operacional confidencial num sistema de referência protegido. Uma extensão do esquema ou um modelo de permissões redesenhado exige um projeto próprio testado. Limpar descrições reduz uma pista; não substitui a redução de privilégios nem oculta todas as outras propriedades do diretório.

Validação após a limpeza

Use a leitura Identity documentada de Get-ADObject para examinar o objeto selecionado após a escrita autorizada:

Get-ADObject -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Properties description -Server 'dc01.corp.example'

O registo de aceitação recomendado deve indicar se o valor pretendido está presente, se o responsável consegue usar a referência protegida e se as ferramentas legítimas continuam a funcionar. Verifique novamente o inventário com o mesmo leitor e âmbito utilizados inicialmente. Tenha em conta a replicação entre controladores de domínio ao comparar servidores de diretório e preserve a identidade do DC, para que leituras diferentes possam ser investigadas em vez de descartadas.

Valide os rótulos mais amplos, além das correspondências de regex. Um resultado automático limpo após substituir domain admin por DA deixaria a pista de seleção de alvos intacta. Inversamente, uma frase aprovada que contenha unprivileged pode continuar a ser uma correspondência lexical com contexto benigno. Registe explicitamente essa decisão; não afirme que todas as correspondências restantes representam acesso perigoso ou que todos os resultados negativos provam uma formulação segura.

Os direitos reais exigem uma revisão separada. A validação de desvios no acesso privilegiado examina a pertença efetiva a grupos, caminhos de ACL delegadas e direitos de replicação em relação a uma referência. Use esse fluxo quando uma descrição sugerir acesso administrativo. Alterar a descrição em si não é evidência de que os direitos da conta foram reduzidos.

Por fim, valide a configuração de monitorização de alterações com uma alteração de teste aprovada e verifique se os dados 5136 esperados chegam ao processo de revisão. Reveja qualquer nova formulação sensível com o responsável. Se descobrir um segredo durante a validação, encaminhe-o para o fluxo de exposição de credenciais, em vez de encerrar o caso após editar o campo. Defina o responsável pela próxima revisão, para que as descrições de identidades desativadas também sejam verificadas antes da reativação.

Como o EtcSec deteta este problema

As duas implementações do etc-collector revistas para este artigo operam sobre data.Users e a cadeia Description recolhida. Ambas ignoram descrições vazias e param após o primeiro padrão reconhecido para um utilizador. Usam as mesmas cinco regex, mas selecionam populações opostas quanto ao estado das contas.

O predicado para contas ativadas encontra-se nas linhas 47–61 do primeiro ficheiro; o predicado para contas desativadas nas linhas 43–57 do segundo. Os seus resultados contam utilizadores afetados. As entidades de detalhe só são anexadas quando IncludeDetails é true e existe pelo menos um utilizador afetado, nas linhas 72–74 e 68–70, respetivamente.

Nenhum dos métodos Detect() lê memberOf, verifica direitos reais, procura senhas ou analisa eventos do diretório. O identificador DOMAIN_ADMIN_IN_DESCRIPTION descreve, portanto, uma verificação de exposição lexical, não uma prova de que um utilizador afetado pertence a Domain Admins. Os valores Alta/Baixa são classificações da política do coletor, não resultados de ataques medidos nem classificações de gravidade da Microsoft.

Trate estes resultados como elementos para revisão: examine o texto, confirme a finalidade com o responsável, limpe o campo aprovado e execute novamente a verificação delimitada. Um resultado lexical negativo não demonstra a ausência de rótulos sensíveis, e remover um rótulo não demonstra a remoção de privilégios.