Revisão de computadores AD desativados whenChanged: origem

O que é uma revisão de computadores AD desativados whenChanged?

Uma revisão de computadores AD desativados whenChanged começa com uma conta de computador atualmente desativada e um carimbo de data e hora antigo de alteração no diretório. Procura determinar se a conta deve permanecer no Active Directory, quem é responsável por essa decisão e que evidências sustentam a sua retirada de serviço. O carimbo ajuda a priorizar a investigação; não estabelece quando a conta foi desativada.

Esta distinção importa quando uma lista de limpeza se transforma numa fila de eliminações. Uma conta desativada pode pertencer a uma estação de trabalho retirada de serviço, a uma máquina temporariamente isolada, a uma identidade de serviço ou a infraestrutura que aguarda um procedimento separado de desativação operacional. Uma constatação de auditoria não fornece nenhuma dessas decisões de negócio. Mantenha o estado atual da conta, as evidências da origem da desativação e a aprovação da retirada de serviço como evidências separadas.

A revisão aqui descrita segue a constatação COMPUTER_DISABLED_NOT_DELETED do etc-collector. Não introduz um calendário universal de eliminação nem estabelece a existência de um ataque a partir de um carimbo antigo. O resultado é uma decisão documentada para um objeto identificado: mantê-lo com uma justificação sob responsabilidade de alguém, investigar evidências em falta ou retirá-lo de serviço através de um procedimento aprovado depois de resolver as suas dependências.

Como funciona: a última alteração não comprova a origem da desativação

A referência do atributo whenChanged da Microsoft define o valor como a data da última alteração do objeto. O sistema atualiza-o sempre que o objeto muda. O valor não é replicado; por isso, registe que controlador de domínio forneceu a observação e quando o leu.

Definir o estado desativado altera o objeto, mas o valor atual de whenChanged não identifica essa operação. Uma alteração posterior pode substituir o carimbo anterior mesmo que a conta continue desativada. Ler um valor recente não estabelece, portanto, uma desativação recente; ler um valor antigo não fornece o seu autor, motivo ou aprovação. Trate o atributo como uma observação de alteração proveniente do DC escolhido, em vez de um campo específico para a data de desativação.

Mantenha estas distinções no registo da revisão:

O nosso guia de higiene de objetos de computador do Active Directory fornece o contexto mais amplo do ciclo de vida, incluindo controladores de domínio, LAPS e objetos de computador obsoletos. As suas cadências ilustrativas de limpeza não comprovam uma data de desativação e não são adotadas como limiares para esta revisão. Uma observação da última autenticação ou da palavra-passe da máquina responderia a outra pergunta; nenhuma substitui aqui a evidência de desativação da conta.

Deteção: estabelecer o estado atual e investigar a transição

Passo 1: ler o objeto exato num DC identificado

Utilize o módulo ActiveDirectory numa estação de administração autorizada. A referência de Get-ADComputer da Microsoft documenta -Identity, -Properties e -Server. Solicite explicitamente os atributos LDAP e identifique um servidor de diretório em vez de depender de uma seleção implícita:

$computer = Get-ADComputer -Identity 'PC01' -Server 'dc01.contoso.com' -Properties whenChanged,userAccountControl,objectClass -ErrorAction Stop
$computer | Select-Object DistinguishedName,ObjectGUID,SID,Enabled,whenChanged,userAccountControl,objectClass

A seleção de campos utiliza a sintaxe de Select-Object documentada pela Microsoft. Conserve a identidade do computador, o DC escolhido, o momento da leitura e o resultado da recolha juntamente com os campos apresentados. Uma consulta que falhou é evidência incompleta. Um atributo indisponível não é um resultado negativo fiável só porque o processo de recolha devolveu um objeto.

O parser LDAP analisado deriva Disabled do bit ACCOUNTDISABLE, 0x0002, no userAccountControl do diretório. A propriedade Enabled apresentada e o atributo bruto fornecem observações do estado atual que devem ser conciliadas. Não registam há quanto tempo a conta está desativada. Se a leitura atual entrar em conflito com a auditoria, investigue o momento da recolha, a identidade do alvo e as observações dos DCs antes de agir com base na constatação mais antiga.

Passo 2: utilizar o evento 4742 apenas quando as suas evidências se aplicam

A Microsoft documenta o evento 4742, uma conta de computador foi alterada, na subcategoria Audit Computer Account Management. É gerado nos controladores de domínio. Reveja os registos Security dos DCs relevantes ou as suas cópias recolhidas, com configuração de auditoria e retenção suficientes para cobrir a transição suspeita.

Num SIEM, limite a investigação ao evento 4742 e ao TargetSid da conta alterada. Inspecione o evento bruto, não apenas um resumo normalizado. Conserve a hora do evento, o DC emissor, o identificador do registo, a identidade do alvo, a identidade do sujeito, OldUacValue, NewUacValue e as informações de controlo de conta alteradas. Compare qualquer alegada transição para o estado desativado com o registo aprovado de alteração ou incidente e com a leitura atual do diretório. Um nome de conta coincidente, por si só, fornece um contexto mais fraco do que o SID do alvo verificado.

A documentação do evento afirma explicitamente que algumas alterações não geram o evento 4742. Outros eventos podem conter traços em todos os atributos alterados apresentados, deixando por identificar o atributo que mudou. Uma entrada 4742 para o objeto não é, portanto, prova automática da sua desativação. Pode documentar outra alteração da conta, e uma pesquisa nos registos pode não cobrir o DC ou o período relevante.

Os campos UAC antigo e novo do evento 4742 utilizam a implementação SAM dos sinalizadores de conta, cujas definições diferem de userAccountControl no LDAP. Não aplique a máscara LDAP 0x0002 a esses campos do evento para alegar uma transição de desativação. Interprete a transição registada utilizando as definições de sinalizadores de conta documentadas para o evento e conserve os valores brutos para revisão.

Passo 3: correlacionar as evidências com a responsabilidade

Pergunte ao responsável se a máquina ainda é necessária, está temporariamente isolada, foi substituída ou foi formalmente retirada de serviço. Associe a resposta à identidade exata do diretório. Conserve separadamente o motivo da desativação, as evidências disponíveis da transição e a decisão de retirada de serviço. Quando faltarem evidências históricas, descreva diretamente essa lacuna em vez de construir uma data a partir da última alteração do objeto.

Uma alteração sem explicação que afete uma identidade crítica exige investigação antes da limpeza do ciclo de vida. Por outro lado, uma decisão aprovada de manutenção pode ser legítima mesmo que o detetor continue a sinalizar o objeto. Registe quem voltará a analisar essa decisão e que condição justificaria a retirada de serviço. Eliminar a constatação não é, por si só, um requisito de negócio para eliminar a conta.

Remediação: validar dependências antes da remoção aprovada (Remediation)

Passo 1: classificar o objeto e resolver as incógnitas

Confirme a classe do objeto e a sua função operacional antes de escolher um procedimento de retirada de serviço. O detetor não exclui explicitamente controladores de domínio nem group managed service accounts. Um controlador de domínio precisa do seu processo adequado de retirada de serviço; uma identidade de serviço precisa de uma verificação das suas dependências de serviço. Um exemplo genérico de remoção de uma estação de trabalho não autoriza aplicar a mesma ação a todos os objetos devolvidos pelo collector.

Concilie o estado atual da conta, a resposta do responsável e os registos de retirada de serviço. Mantenha os casos por resolver em espera, com responsabilidade atribuída para a próxima ação. Este processo não define um novo período genérico de envelhecimento: o tempo decorrido não pode estabelecer que terminaram as necessidades de serviços, registos ou recuperação.

Passo 2: inventariar objetos subordinados e dependências de recuperação

Leia os objetos imediatamente subordinados ao objeto de computador verificado utilizando os parâmetros de pesquisa de Get-ADObject documentados pela Microsoft. Este exemplo utiliza o $computer devolvido acima e solicita identificadores e classes de objetos, em vez de segredos de recuperação:

Get-ADObject -LDAPFilter '(objectClass=*)' -SearchBase $computer.DistinguishedName -SearchScope OneLevel -Server 'dc01.contoso.com' -ErrorAction Stop |
    Select-Object DistinguishedName,ObjectGUID,ObjectClass

OneLevel pesquisa apenas objetos imediatamente subordinados. Se um objeto subordinado tiver os seus próprios descendentes ou se o inventário estiver incompleto, investigue essa estrutura e o seu propósito antes de prosseguir. Um resultado vazio com visibilidade não verificada não prova que não existem objetos dependentes. Registe falhas de acesso e âmbito incerto como itens de inventário por resolver.

Inclua as informações de recuperação BitLocker na revisão das dependências. O nosso guia de verificação da recuperação BitLocker no AD: fazer corresponder o registo do diretório ao protetor de recuperação atual do volume explica por que motivo um objeto de recuperação tem de corresponder ao protetor de recuperação realmente presente no volume. A sua presença, por si só, não estabelece uma recuperação utilizável, e a sua data não estabelece quando a conta de computador foi desativada.

Antes da remoção do computador, acorde como as informações de recuperação necessárias e outros dados dos objetos subordinados continuarão disponíveis ao abrigo do processo de recuperação e retenção aprovado pela organização. Mantenha os segredos fora dos tickets de limpeza e dos registos SIEM. Registe a decisão sobre as dependências e o responsável, em vez de copiar palavras-passe de recuperação para as evidências. Esta é uma verificação de dependências da retirada de serviço; o guia ligado fornece o procedimento separado de verificação do volume e do protetor.

Passo 3: simular e executar apenas a remoção aprovada de um único objeto

Depois de concluídas as verificações de responsabilidade, retirada de serviço, dependências e recuperação, utilize a sintaxe de Remove-ADComputer da Microsoft para o objeto verificado. A documentação suporta uma identidade GUID, um servidor explícito e -WhatIf. A simulação seguinte não executa a remoção:

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -WhatIf

Reveja o alvo e a simulação face ao registo aprovado de retirada de serviço. Uma simulação não verifica que a máquina está sem uso, que os dados de recuperação estão preservados ou que a ação foi aprovada. Volte a ler o objeto atual antes da operação autorizada se as evidências puderem ter mudado.

Só depois dessa validação, o comando para um único objeto mantém um pedido explícito de confirmação:

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -Confirm

Se objetos subordinados, proteção ou outro erro impedirem a remoção, pare e resolva a causa específica através do procedimento aprovado. Não transforme uma falha numa eliminação recursiva do computador e dos seus descendentes. Conserve o resultado real do comando; uma operação tentada não prova que a conta foi removida.

Passo 4: encerrar a revisão com evidências

Registe a decisão final, quem a aprovou, as decisões sobre dependências e o resultado da operação. Verifique o resultado no diretório através de uma leitura autorizada da identidade exata no DC registado, conservando qualquer erro e o seu significado. Confirme que as informações de recuperação necessárias continuam disponíveis através do processo acordado. Para um objeto mantido, documente o motivo da manutenção e a investigação restante em vez de apresentar a remediação como concluída.

Como a EtcSec deteta esta situação

No commit do collector analisado, 20268a321609c193b79c5da6764f3f56950449cb, COMPUTER_DISABLED_NOT_DELETED é uma constatação de gravidade Low. O seu Detect() examina os computadores recolhidos e inclui um objeto apenas quando Disabled é verdadeiro, WhenChanged é diferente de zero e WhenChanged.Before(Now.AddDate(0, 0, -30)) é verdadeiro. A comparação é estrita: um carimbo igual ao limite é excluído.

O limite subtrai 30 dias de calendário ao Now da auditoria. É uma referência de higiene operacional do etc-collector, não um prazo de eliminação exigido pela Microsoft ou por outra norma identificada. Uma alteração posterior do objeto faz avançar whenChanged e pode adiar este sinal enquanto a conta continua desativada.

No fornecedor LDAP analisado, um whenChanged ausente ou inválido torna-se um instante zero, que este detetor ignora. Um userAccountControl ausente ou sintaticamente inválido torna-se zero, pelo que o parser não marca esse objeto como desativado. O filtro predefinido de computadores é (objectClass=computer). Embora o parser consiga identificar uma classe gMSA, este Detect() não tem uma exclusão explícita de controladores de domínio ou gMSAs.

O detetor não estabelece a data de desativação, o responsável, a aprovação da retirada de serviço, os objetos subordinados, as dependências de recuperação ou um histórico de eventos que as sustente. Uma constatação positiva abre a revisão de evidências descrita acima. Uma contagem de zero não pode encerrar essas perguntas independentes, sobretudo quando a recolha ou a disponibilidade de atributos é incerta.