Aprovacao de alteracao de atributo AD: valores 5136

O que é a aprovacao de alteracao de atributo AD?

Uma revisão de aprovacao de alteracao de atributo AD vincula uma modificação registrada de um objeto de diretório existente a uma decisão autorizada de forma independente. Seu resultado é um registro de evidências: GUID do objeto, atributo alterado, valores excluídos e adicionados observados, ID de correlação da operação, conta solicitante, controlador de domínio emissor, horário do evento e evidências de aprovação. Um nome de administrador conhecido ou uma baixa contagem de constatações de postura não substitui esse registro.

Use este procedimento quando uma modificação no diretório precisar de uma explicação antes de encerrar a revisão ou aprovar uma alteração corretiva. Comece com um objeto e um atributo. Preserve os eventos originais, estabeleça os limites da coleta e peça ao responsável autorizado pela decisão que confirme se a mudança de valor observada corresponde à solicitação. A revisão pode terminar com uma aprovação fundamentada, uma alteração não autorizada confirmada ou uma lacuna de evidências não resolvida; esses resultados exigem acompanhamentos diferentes.

Este artigo trata de alterações em um objeto existente. Para objetos recém-provisionados, use o registro de criação que conecta whenCreated e evidências de criação ao provisionamento aprovado. Para a comparação mais ampla entre o acesso pretendido e os direitos efetivos de grupos, ACL e replicação, use o fluxo de revisão e revalidação de desvios de acesso privilegiado. Aqui, o resultado é o registro de evidências da alteração de atributo, não outro inventário de contas privilegiadas.

Como funciona: estabelecer o que 5136 pode mostrar

A Microsoft documenta o evento 5136 para modificações em objetos de serviços de diretório. Para gerar o evento, a auditoria de sucesso de Directory Service Changes deve ser aplicada, e o objeto precisa de uma entrada SACL correspondente que audite a gravação do atributo relevante. A subcategoria de auditoria opera nos controladores de domínio. Algumas alterações de objetos ou propriedades não são auditadas devido às configurações do esquema, portanto, habilitar a política por si só não estabelece cobertura completa. Microsoft Learn: Event 5136, Audit Directory Service Changes.

Para uma substituição, a Microsoft descreve um evento típico de valor excluído seguido de um evento de valor adicionado. Trate esse padrão como um auxílio à reconstrução. Ele não garante que toda revisão tenha exatamente dois registros. Um atributo pode ter vários valores, uma operação pode afetar diversos atributos e os registros retidos podem estar incompletos. Mantenha todos os eventos de valor relevantes e explique como cada um contribui para a alteração analisada.

O campo XML OperationType distingue uma adição, %%14674, de uma exclusão, %%14675. AttributeValue contém o valor envolvido nesse evento. Preserve tanto o código bruto da operação quanto seu significado. Não interprete um valor adicionado como o conjunto completo do atributo após a alteração quando ele pode representar um elemento de um atributo multivalorado. Microsoft Learn: descrições dos campos de Event 5136.

OpCorrelationID relaciona modificações pertencentes a uma operação LDAP. Pode abranger mais do que o único atributo em análise. Combine-o com a identidade do objeto e do atributo, a proveniência e o horário; ele não é uma referência de ticket de negócio. A Microsoft descreve AppCorrelationID como não utilizado, com um hífen como valor. Nenhum dos campos fornece a decisão de aprovação da organização.

Detecção: coletar um conjunto delimitado de evidências

Os comandos abaixo usam a sintaxe documentada de comandos e parâmetros adaptada a esta revisão. Eles não foram executados em um domínio real. Leia os eventos a partir de um host Windows autorizado; use o módulo Active Directory para a leitura do objeto. Substitua o DC, o intervalo UTC e o GUID do objeto de exemplo pelas entradas reais do caso. Registre erros de permissão e logs indisponíveis como observações malsucedidas, não como pesquisas vazias bem-sucedidas. Leituras remotas com Get-WinEvent exigem acesso pelo firewall ao serviço Windows Event Log; o cmdlet não depende de PowerShell remoting. Microsoft Learn: Get-WinEvent ComputerName.

Etapa 1: registrar a cobertura de auditoria e retenção

Em cada DC relevante para o caso, examine a subcategoria atual de auditoria do sistema. O nome em inglês abaixo exige uma instalação que reconheça esse nome; a sintaxe documentada também aceita um GUID de subcategoria.

auditpol /get /subcategory:"Directory Service Changes" /r

A saída esperada é um relatório de política que identifica a subcategoria e suas configurações de sucesso e falha. Salve a identidade do DC, o horário da coleta, o comando e o relatório retornado. Uma consulta bem-sucedida estabelece o que foi lido naquele momento. Ela não comprova que a mesma configuração se aplicava quando a modificação histórica ocorreu. A sintaxe do comando e os requisitos de permissão de leitura estão documentados em Microsoft Learn: auditpol get.

Para a configuração do log, examine o log Security no mesmo DC:

Get-WinEvent -ListLog Security -ComputerName 'dc01.contoso.local' -ErrorAction Stop

O resultado descreve o log, incluindo seu modo, tamanho máximo configurado e contagem de registros. Um tamanho ou uma contagem não comprova que o intervalo de interesse ainda possa ser pesquisado. Verifique os registros locais retidos e os arquivos centrais para esse intervalo e documente a cobertura das fontes, as lacunas de encaminhamento e as evidências históricas disponíveis de política e SACL. Microsoft Learn: Get-WinEvent.

Responda explicitamente à primeira pergunta de decisão: qual SACL de gravação de atributo e quais evidências de retenção sustentam esta reconstrução? Registre o objeto auditado ou o escopo herdado, a ação de gravação relevante, o principal abrangido e a configuração de sucesso. Se apenas a configuração atual estiver disponível, marque a cobertura histórica como não comprovada. Não deduza que a ausência de um evento histórico significa que o atributo nunca foi modificado.

Etapa 2: recuperar os eventos sem um limite arbitrário de pares

Use um intervalo delimitado que inclua a alteração em análise. O exemplo a seguir seleciona eventos Security por provedor, ID e horário:

$reviewStart = [DateTimeOffset]::Parse('2026-10-04T08:00:00Z').UtcDateTime
$reviewEnd = [DateTimeOffset]::Parse('2026-10-04T09:00:00Z').UtcDateTime
$events = Get-WinEvent -ComputerName 'dc01.contoso.local' -FilterHashtable @{
    LogName = 'Security'
    ProviderName = 'Microsoft-Windows-Security-Auditing'
    Id = 5136
    StartTime = $reviewStart
    EndTime = $reviewEnd
} -ErrorAction Stop

Esses horários são ilustrativos, não uma janela de mudança medida nem uma duração prescrita para a revisão. Get-WinEvent documenta essas chaves de filtro e retorna registros de eventos, com os mais recentes primeiro por padrão. O exemplo intencionalmente não solicita apenas dois eventos nem limita o resultado com -MaxEvents. Preserve a consulta e o resultado antes de selecionar o objeto e o atributo no XML do evento. Microsoft Learn: parâmetros de filtro de Get-WinEvent.

Espere zero ou mais registros correspondentes, não uma contagem predeterminada. Se o comando informar que não há eventos correspondentes, diferencie esse resultado de erros de acesso ou conexão e depois avalie a cobertura de retenção e geração. Pesquise arquivos autorizados conforme necessário; o cmdlet também documenta -Path para arquivos de eventos salvos. Uma leitura malsucedida deve permanecer visível no registro do caso.

Retenha a exportação original dos eventos e o XML de cada evento. Uma captura de tela do valor mais recente é insuficiente para a reconstrução. Em um SIEM, verifique se a ingestão preserva os campos abaixo e mantém a identidade do evento de origem separada do horário de ingestão e de quaisquer cópias duplicadas encaminhadas.

Etapa 3: montar o registro de alteração do atributo

Use ObjectGUID para identificar o objeto e AttributeLDAPDisplayName para identificar o atributo. Registre o DN e a classe como contexto. Depois, colete todos os eventos de valor candidatos que compartilham o ID de correlação da operação para esse objeto e atributo, verificando o DC emissor, o sujeito e os horários. Se esses campos divergirem, mantenha a divergência para investigação em vez de forçar os registros a formar um par.

Esses nomes de campos de eventos vêm do XML e das descrições dos campos de 5136. Os campos de aprovação são um registro de revisão proposto, não telemetria adicional do Windows.

Para uma substituição de valor único com evidências completas, o revisor deve conseguir descrever a exclusão e a adição observadas e referenciar cada registro de origem. Para um atributo multivalorado, retenha as remoções e adições individuais como conjuntos de operações observadas. Não invente valores inalterados nem afirme que o conjunto de eventos é um retrato completo de antes e depois.

Para comparar com o estado atual do diretório, Get-ADObject aceita um GUID de objeto como -Identity, atributos extras como -Properties e um servidor específico como -Server. Este exemplo usa o GUID do evento 5136 de exemplo da Microsoft; substitua-o e o atributo de exemplo pelos identificadores analisados.

Get-ADObject -Identity '4fe80a66-5f93-4f73-b215-68678058e613' -Server 'dc01.contoso.local' -Properties userAccountControl -ErrorAction Stop

Espere o objeto localizado e a propriedade solicitada ou um erro explícito de leitura ou busca. Preserve o horário da coleta e o DC. O estado atual pode ajudar a validar a remediação, mas não pode recuperar um valor histórico ou uma aprovação ausentes. Microsoft Learn: Get-ADObject.

Verificação: tornar a decisão de aprovação independente

Peça à autoridade designada para mudanças que associe a solicitação a este objeto, atributo e alteração de valor pretendida. Registre quem está autorizado a decidir, as evidências de aprovação e seu horário e se essas evidências abrangem a operação observada. A explicação de um operador sobre uma mudança é uma evidência útil, mas não é automaticamente uma aprovação independente.

Mantenha o ator técnico e o responsável pela decisão em campos separados. Se uma conta de automação solicitou a mudança, registre esse sujeito sem adivinhar o iniciador humano. Estabeleça qualquer atribuição a um operador por meio de registros independentes. Da mesma forma, não associe uma solicitação de negócio a um evento apenas porque os horários são próximos ou ambas as descrições mencionam “manutenção do diretório”.

Classifique explicitamente os casos difíceis:

Esta tabela propõe resultados de revisão. Ela não afirma que todo evento sem correspondência é malicioso. Responda às perguntas de decisão restantes antes do encerramento: quem confirma a autorização independentemente do ator técnico, e como serão qualificadas evidências ausentes, multivaloradas ou apenas de exclusão? Atribua a cada item não resolvido um responsável e a próxima solicitação de evidências.

Remediação: resolver a decisão e validar a cobertura (Remediation)

Preserve as evidências históricas antes de fazer uma alteração corretiva no diretório. Para uma modificação aprovada e fundamentada, anexe a decisão ao registro da revisão. Para uma divergência de aprovação ou alteração não autorizada confirmada, peça aos responsáveis por identidade e serviços que avaliem a exposição e as dependências, decidam sobre contenção ou correção e registrem o estado de destino autorizado. Evite restaurar cegamente um valor excluído: alterações legítimas posteriores ou dependências multivaloradas podem tornar essa ação incorreta.

Se a cobertura de geração for inadequada, administradores autorizados devem corrigir a política de auditoria aplicável e a SACL de gravação de atributo. A Microsoft documenta a auditoria de sucesso de Directory Service Changes e a ausência de eventos Failure nesta subcategoria. Execute o comando a seguir localmente no DC selecionado. Ele usa a sintaxe documentada de auditpol /set para habilitar a auditoria de sucesso, altera a configuração e deve fazer parte de um procedimento administrativo aprovado.

auditpol /set /subcategory:"Directory Service Changes" /success:enable

Um resultado bem-sucedido do comando é seguido pela leitura com auditpol /get acima e pela SACL correspondente verificada separadamente. O comando não configura uma SACL, não comprova a persistência de uma política gerenciada centralmente nem recria eventos passados. Coordene-o com o responsável pela política e preserve as evidências da configuração resultante. Microsoft Learn: auditpol set, Audit Directory Service Changes.

Valide a cobertura futura por meio de uma modificação piloto aprovada em um objeto de teste fora de produção e em um atributo adequado. Registre a intenção autorizada para os valores antigo e novo antes do teste. Verifique se os eventos gerados e retidos contêm o objeto, o atributo e as operações de valor esperados, se o encaminhamento preserva sua identidade e se a revisão consegue vinculá-los à aprovação do teste. Nenhum teste de domínio desse tipo foi realizado para este artigo.

Após uma correção autorizada, repita a leitura delimitada do objeto e a revisão dos eventos. Preserve o estado atual, as evidências da operação corretiva e a decisão independente. Encerre apenas as partes fundamentadas do caso; mantenha as lacunas de reconstrução histórica com um encaminhamento documentado.

Como o EtcSec detecta isso

No commit do coletor bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, CHANGE_MANAGEMENT_BYPASS é uma heurística de postura de gravidade Medium. Seu Detect() lê usuários LDAP coletados. Ele conta usuários habilitados cujas entradas diretas de memberOf contêm os nomes em inglês Domain Admins ou Enterprise Admins, usando correspondência de substring sem distinção entre maiúsculas e minúsculas. Mais de 10 desses usuários gera um problema. Uma contagem separada inclui usuários com pelo menos um SPN e adminCount=1; mais de 5 gera outro problema. A segunda contagem não exclui usuários desabilitados.

Se qualquer uma das condições for atendida, a constatação retornada tem Count=1; caso contrário, tem Count=0. Um é o indicador da constatação, não o número de mudanças não aprovadas. Os detalhes incluem os dois contadores agregados. Os limiares são heurísticas do produto sem autoridade normativa, não requisitos de aprovação da Microsoft, ANSSI ou HDS.

O provedor LDAP fornece memberOf, servicePrincipalName e adminCount. Esse detector não expande associações a grupos aninhados. Nomes de grupos privilegiados renomeados ou localizados podem impedir a correspondência com os nomes em inglês; a correspondência de substring não é um teste estável de SID de grupo. A Microsoft documenta que adminCount pode permanecer definido como 1 depois de uma conta sair de um grupo protegido; portanto, esse indicador não estabelece privilégios efetivos atuais. Um SPN pode ser registrado em uma conta de usuário ou computador, de modo que sua presença por si só não estabelece a finalidade operacional atual da conta. Microsoft Learn: contas protegidas e adminCount, registro de SPN. O escopo e os limites da coleta também restringem as populações examinadas.

Essa verificação não lê eventos 5136, valores removidos/adicionados, IDs de correlação, SACLs, registros de retenção nem fluxos de aprovação. Uma constatação positiva pode motivar uma revisão de gestão de mudanças, mas não pode comprovar um desvio do processo, identificar essa modificação de atributo nem decidir a autorização. Uma contagem zero não permite dar o registro de evidências por resolvido. Conclua a reconstrução dos eventos e a decisão independente acima antes de encerrar a revisão.