Auditoria whenCreated de objetos AD: controlo

O que é uma revisão da criação de objetos AD?

Uma Auditoria whenCreated de objetos AD relaciona os objetos de diretório criados recentemente com o provisionamento aprovado. O resultado útil é um registo datado que mostra quais os utilizadores, computadores e grupos examinados, quem é responsável por eles, que pedido justificou a sua criação e que evidências continuam por esclarecer. O total de objetos recentes é um ponto de partida para esse trabalho; não demonstra que as criações tenham sido maliciosas ou aprovadas.

A Microsoft descreve whenCreated como uma marca temporal de criação definida pelo sistema, replicada e disponível no catálogo global. Fornece uma data, mas não a identidade de quem fez o pedido nem uma justificação de negócio. Mantenha estes tipos de evidência separados ao longo da revisão. Microsoft Learn: When-Created attribute.

A questão prática é saber se cada criação observada pertence a um processo de provisionamento documentado. Um computador novo pode ser uma implementação esperada, um grupo pode apoiar uma aplicação aprovada e um utilizador pode ser uma entrada legítima na organização. Estas possibilidades exigem registos e um responsável identificável. Nomes, descrições e uma OU conhecida podem orientar a investigação, mas não devem substituir um registo de aprovação.

Como funciona: construir um registo datado de objetos

Comece por registar o domínio, a base de pesquisa, o controlador de domínio consultado, o momento da recolha e o intervalo da revisão. Guarde as definições de recolha e quaisquer erros juntamente com as linhas dos objetos. Isto permite distinguir uma observação do diretório de uma suposição sobre a cobertura da recolha.

Mantenha uma linha de revisão por identificador estável de objeto, usando o nome distinto atual como referência de localização legível. Preserve separadamente a pertença às populações: um objeto devolvido tanto na população de utilizadores como na de computadores deve manter ambas as etiquetas, contando apenas uma vez no registo de objetos únicos. Isto é relevante para contas de serviço geridas de grupo, que os filtros LDAP do coletor podem incluir em ambas as populações.

Campo do registo	O que o revisor regista	Decisão que apoia
Identidade do objeto	GUID do objeto, DN, classe e SID disponível	Associar evidências ao mesmo objeto e eliminar observações duplicadas
Momento da criação	`whenCreated` normalizado para UTC; ausência de data registada explicitamente	Situar o objeto no intervalo de revisão escolhido
Proveniência da recolha	Domínio, DC, base de pesquisa, momento da consulta e resultado	Explicar o âmbito da observação
Pertença às populações	Utilizador, computador, grupo ou populações sobrepostas	Reconciliar os totais das populações com os objetos únicos
Evidências de provisionamento	Referência do pedido, finalidade solicitada e evidência de aprovação	Estabelecer o motivo documentado da criação
Responsável identificado	Responsável de serviço ou de negócio nomeado e resposta à revisão	Atribuir ações de seguimento em vez de deixar linhas sem explicação
Evidências de eventos	Evento de criação correspondente ou limitação de cobertura documentada	Preservar o que se sabe sobre quem fez o pedido
Classificação final	Aprovado, investigação necessária ou por esclarecer	Manter a incerteza visível até ao encerramento

Use conjuntos distintos para objetos dentro do intervalo, objetos fora dele, objetos sem data disponível e populações ou localizações que não puderam ser lidas. Uma consulta falhada é uma observação falhada. Não pode produzir um resultado vazio fiável. Da mesma forma, um objeto excluído por um filtro de data não foi classificado como aprovado.

A revisão semanal de criações recentes no fluxo de auditoria recorrente de AD fornece a cadência operacional. Este registo fornece as evidências dos objetos e do provisionamento para essa revisão. Preserve explicitamente o intervalo de revisão em vez de tratar a janela retrospetiva de dez dias de um produto como uma política da organização.

Deteção: ler whenCreated com um âmbito explícito

Use um sistema com o módulo PowerShell do Active Directory e uma conta autorizada a ler o diretório. Os exemplos seguintes são consultas de revisão baseadas na documentação, não comandos executados num diretório de cliente. Substitua o domínio e o DC de exemplo antes de os usar.

Get-ADObject documenta -Filter, -Properties adicionais, -SearchBase, -SearchScope e -Server. Os exemplos definem -SearchScope Subtree para incluir a base de pesquisa e os seus descendentes. Os filtros abaixo combinam esses parâmetros com as três definições de população do coletor e um limite inferior para whenCreated. Microsoft Learn: Get-ADObject.

$reviewEnd = [DateTime]::UtcNow
$reviewStart = $reviewEnd.AddDays(-10)
$base = 'DC=contoso,DC=local'
$dc = 'dc01.contoso.local'
$properties = 'whenCreated','objectGUID','objectSid','objectClass'

$users = Get-ADObject -Filter {objectClass -eq 'user' -and (objectCategory -eq 'person' -or objectClass -eq 'msDS-GroupManagedServiceAccount') -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop
$computers = Get-ADObject -Filter {objectClass -eq 'computer' -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop
$groups = Get-ADObject -Filter {objectClass -eq 'group' -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop

As consultas com limite inferior omitem as datas mais antigas e as indisponíveis. Para uma observação separada com âmbito definido, leia sem uma condição de data:

$scopeObjects = Get-ADObject -Filter * -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop

Esta leitura mais abrangente não equivale às três consultas de população. Classifique os seus objetos antes da comparação. Por predefinição, o cmdlet exclui os objetos eliminados; nenhuma das leituras reconstrói um diretório histórico completo.

Passo 1: preservar a observação

Guarde as definições das consultas e os seus resultados, bem-sucedidos ou falhados, antes de interpretar as linhas. Se uma consulta parar com um erro, registe o erro e o âmbito afetado e investigue a falha de recolha. Não substitua o resultado por um array vazio para continuar como se a população tivesse sido revista.

Para as datas devolvidas, mantenha o valor original e normalize a apresentação no registo para UTC. Avalie o limite inferior de forma consistente: o coletor usa uma comparação estrita com o seu momento de referência menos dez dias. Uma marca temporal exatamente nesse limite é excluída. O seu código não tem um limite superior no momento de referência, pelo que deve assinalar separadamente qualquer data devolvida posterior ao fim de revisão registado, em vez de a incluir silenciosamente no intervalo normal.

Passo 2: reconciliar objetos únicos

Combine as observações pelo GUID do objeto, mantenha todas as etiquetas de população e compare o registo resultante com as contagens de população do coletor. Explique as diferenças pelo âmbito, limites, tratamento das datas e classes sobrepostas antes de as tratar como criações sem explicação. Uma contagem sem duplicados pode legitimamente diferir da soma das observações de utilizadores, computadores e grupos.

Mantenha as contas desativadas na revisão. O estado desativado não explica por que motivo um objeto foi criado nem se o seu pedido de provisionamento foi aprovado. O próprio detetor de objetos recentes não exclui utilizadores ou computadores desativados.

Passo 3: relacionar cada linha com o provisionamento

Peça ao responsável identificado que forneça o pedido e as evidências de aprovação para o objeto específico. Faça corresponder os identificadores, a classe prevista, a localização e a finalidade, em vez de aceitar um ticket genérico de implementação que possa referir-se a vários objetos sem relação entre si. Registe a divergência entre o pedido e o objeto observado como um ponto de seguimento.

Uma resposta do responsável sem evidências de suporte continua a ser uma afirmação a avaliar. Inversamente, uma resposta em falta significa proveniência por esclarecer, não prova de atividade de um atacante. Mantenha estes resultados distintos para que a remediação trate a lacuna real nas evidências.

Deteção: correlacionar o Event ID 5137 apenas com cobertura comprovada

O Event ID 5137 regista a criação de objetos de diretório num controlador de domínio com auditoria de sucessos ativada em Audit Directory Service Changes. A Microsoft especifica que a SACL do objeto pai deve auditar a ação Create relevante para a classe do objeto. Ambos os controlos devem ter estado em vigor antes da criação; os registos locais ou centrais conservados devem cobrir esse momento. Microsoft Learn: Event 5137.

Faça corresponder ObjectGUID, apoiado por ObjectDN e ObjectClass, ao registo. Preserve a hora UTC do evento, o DC emissor e o identificador do registo de evento. SubjectUserSid, SubjectUserName e SubjectDomainName identificam a conta que fez o pedido. SubjectLogonId pode apoiar a correlação de sessões; não identifica a pessoa por detrás da automação nem prova aprovação.

Evidência	Utilização na revisão	Limite
5137 correspondente	Identificar quem fez o pedido para este objeto	A identidade de quem fez o pedido não é autorização
Política histórica e SACL do objeto pai	Estabelecer a cobertura da geração de eventos	A configuração atual não pode provar a cobertura passada
Logs e arquivos legíveis	Estabelecer o período pesquisável	Registos em falta deixam a proveniência por esclarecer

O guia de configuração da política de auditoria explica por que os eventos têm primeiro de ser gerados. Para o 5137, acrescente evidências da SACL Create do objeto pai e da retenção; o contador de criações não comprova nenhum destes elementos.

Remediação: resolver criações não aprovadas e lacunas nas evidências (Remediation)

A remediação começa pela classificação de cada objeto, não pela redução da contagem de criações recentes. O provisionamento aprovado deve continuar documentado mesmo enquanto o objeto permanece dentro da janela retrospetiva. Uma criação por esclarecer precisa de um responsável e de um caminho de investigação.

Completar o registo de provisionamento. Anexe o identificador do objeto, o pedido, a aprovação e a resposta do responsável à linha de revisão. Confirme que a finalidade e a localização observadas correspondem ao pedido aprovado. Registe qualquer exceção justificada e a pessoa responsável pela sua resolução.
Escalar criações sem explicação ou inconsistentes. Preserve as observações do diretório e os registos de eventos disponíveis. Peça aos responsáveis pela identidade e pelo serviço que avaliem a utilização prevista do objeto e a sua exposição atual. Encaminhe objetos comprovadamente não autorizados pelos processos de incidentes e de alterações da organização, com uma decisão explícita de contenção.
Corrigir lacunas de recolha. Reveja as bases de pesquisa, os limites de população configurados e as falhas de consulta. Repita as leituras com âmbito definido depois de a causa ter sido resolvida e mantenha o novo momento de observação. Conserve as observações anteriores falhadas no registo para que o registo final não sugira uma cobertura ininterrupta.
Corrigir a cobertura futura de eventos. Peça a administradores autorizados que verifiquem a auditoria efetiva de sucessos de Directory Service Changes e as SACLs Create relevantes dos objetos pais. Verifique se os arquivos conservados podem efetivamente ser pesquisados. Valide a geração e recolha futuras através de uma criação de teste aprovada e preserve as evidências resultantes.
Verificar o encerramento com base no registo. Reconcilie o registo atualizado de objetos únicos com o provisionamento aprovado e as exceções documentadas. Encerre apenas as decisões apoiadas por evidências; mantenha a proveniência desconhecida e o âmbito incompleto como pontos em aberto.

Evite a eliminação ou desativação automática baseada apenas na idade, num nome desconhecido ou num evento de criação em falta. Esses sinais justificam investigação, enquanto a decisão de remediação exige evidências sobre o objeto e as suas dependências. Os exemplos deste artigo efetuam leituras do diretório; não autorizam uma alteração no diretório.

Como o EtcSec deteta esta situação

No commit do coletor 9f698083354a1cb7f625df5cb490a515823c3257, RECENT_OBJECTS_CREATED é uma constatação Info. O seu Detect() soma as entradas de utilizadores, computadores e grupos cujo valor Created é diferente de zero e estritamente posterior a DetectorData.Now - 10 × 24 hours. Dez dias é uma heurística do produto. A comparação não tem limite superior em Now, e o detetor não exclui contas desativadas.

A constatação fornece um total e os contadores agregados newUsers, newComputers e newGroups. Não fornece uma lista AffectedEntities por objeto nem determina quem fez o pedido, a intenção ou a autorização. Os parsers LDAP obtêm Created a partir de whenCreated; valores ausentes ou formatos não compreendidos por parseADTime tornam-se zero e são excluídos deste cálculo.

A recolha depende de BaseDN e de MaxUsers, MaxGroups e MaxComputers. Um erro ao obter qualquer uma das três populações interrompe a recolha. As populações podem sobrepor-se: o filtro de utilizadores inclui gMSAs e o filtro de computadores pode devolver os mesmos objetos. Consequentemente, a contagem somada não é um inventário único de todos os objetos AD.

Use esta constatação para iniciar o registo independente e a revisão do provisionamento descritos acima. Uma contagem menor numa auditoria posterior pode simplesmente refletir objetos que ficaram fora da janela retrospetiva com o passar do tempo, uma alteração de âmbito ou uma diferença de recolha. Verifique diretamente as decisões da revisão e as evidências antes de encerrar o trabalho.