Auditoria Sensitive Privilege Use AD: Failure plus Success

O que é a auditoria Sensitive Privilege Use AD?

A auditoria Sensitive Privilege Use AD é uma verificação da visibilidade no nível do host: o Windows registra solicitações de privilégios sensíveis em cada controlador de domínio, servidor membro ou estação de trabalho no escopo? Uma exportação da GPO de domínio pode sugerir uma resposta, mas as evidências necessárias para concluir a revisão são a política de auditoria informada pelo host de destino e os eventos que chegam à plataforma de monitoramento.

Este guia foi verificado em 4 de outubro de 2026, com base no Microsoft Learn e no commit de código-fonte do etc-collector 20268a321609c193b79c5da6764f3f56950449cb. Seu ponto de partida é uma limitação específica: o controle EtcSec AUDIT_PRIVILEGE_USE_DISABLED aceita apenas Failure. Portanto, um resultado sem achado contabilizado não demonstra que Success e Failure estão ambos habilitados.

A Microsoft recomenda os dois resultados para essa subcategoria em controladores de domínio, servidores membros e estações de trabalho. Success registra tentativas bem-sucedidas; Failure registra tentativas malsucedidas. Consulte a recomendação da Microsoft para Sensitive Privilege Use. Revise sua linha de base aprovada e documente as exceções, em vez de tratar o limiar do produto como o requisito completo da política.

Como funciona a verificação

Comece pelas máquinas que pretende cobrir. Liste os controladores de domínio, servidores membros relevantes e estações de trabalho privilegiadas, juntamente com o responsável pela política de cada grupo. Uma consulta bem-sucedida em um DC não demonstra o estado de outro DC ou de um servidor membro. Registre a identidade do host e o horário da observação junto de cada resultado.

A distinção entre configuração e estado do host é explicada no nosso guia para comparar a configuração de auditoria da GPO com as configurações efetivas do host. Esse artigo aborda Account Logon, Account Management e Policy Change. Aqui, a decisão diz respeito ao bit Success de Sensitive Privilege Use e à telemetria que dele decorre.

A verificação tem três etapas de validação. Primeiro, identifique a linha de base esperada e as exceções aprovadas. Depois, consulte a política de auditoria do sistema no host real. Por fim, compare os eventos locais relevantes com suas cópias centrais e verifique os campos necessários ao analista. Conclua cada etapa com suas próprias evidências: a aprovação de uma exceção não substitui uma verificação de coleta malsucedida, e um log de eventos preenchido não substitui a consulta da política.

Quando as evidências divergirem, preserve a divergência. Por exemplo, uma GPO coletada pode conter apenas Failure enquanto um host informa os dois resultados. O próximo passo útil é identificar como esse host é gerenciado e se o estado é duradouro. Alterar uma GPO apenas para fazer uma exportação parecer consistente pode remover uma configuração local legítima ou deixar o verdadeiro problema de configuração sem solução.

Detecção: leia a política em cada host

Execute a seguinte consulta somente de leitura em cada destino, usando uma conta autorizada a ler sua política de auditoria. Esses comandos aplicam a sintaxe por nome ou GUID documentada na referência da Microsoft para auditpol get; foram verificados com base nessa referência, mas não executados em um ambiente AD para este artigo.

auditpol /get /subcategory:"Sensitive Privilege Use"

Em hosts com outro idioma de exibição, consulte pelo GUID de Sensitive Privilege Use documentado pela Microsoft, também usado pelo coletor:

auditpol /get /subcategory:"{0cce9228-69ae-11d9-bed3-505054503030}" /r

Sem /user, o auditpol consulta a política do sistema. Preserve a saída, o host, o carimbo de data e hora, o comando e qualquer erro. Um erro de permissão representa um resultado desconhecido que exige acesso autorizado; não representa uma política desabilitada. Investigue separadamente a política por usuário quando ela for relevante para uma conta específica ou para um resultado de evento inesperado.

Mantenha o resultado da política separado da amostra de eventos. Eventos antigos podem permanecer após uma alteração de política; portanto, um evento observado antes da consulta não comprova a configuração atual. Por outro lado, uma janela de observação sem atividade pode não conter nenhuma operação relevante. Registre a janela e a atividade esperada antes de decidir se a ausência de eventos indica um problema de geração ou de coleta.

Detecção: valide 4673/4674 ao longo do pipeline de coleta

A Microsoft documenta 4673 como uma chamada de serviço privilegiado e 4674 como uma tentativa de operação em um objeto privilegiado. Ambos também podem pertencer a Non Sensitive Privilege Use. Examine o contexto do privilégio e da operação; o número do evento, isoladamente, não identifica a subcategoria sensível.

Use esta consulta local ao log Security para examinar o XML. Ela aplica as opções de consulta, ordem inversa e formato de saída da referência da Microsoft para wevtutil:

wevtutil qe Security /q:"*[System[(EventID=4673 or EventID=4674)]]" /rd:true /f:xml

Escolha uma janela de observação delimitada e adequada à revisão ao pesquisar centralmente. Compare os registros locais com as cópias recebidas usando a identidade do host, o horário, o ID do evento e o ID do registro, quando preservado. Verifique a normalização do resultado da auditoria e dos nomes de privilégios pelo conector com base no XML original, especialmente quando a visualização central mescla campos ou remove valores vazios.

O guia complementar sobre coleta central de eventos e validação do parser apoia esse trabalho de transporte e mapeamento de campos. Preserve um exemplo de cada tipo de evento relevante efetivamente observado. Se um exemplo necessário não estiver disponível, documente o caso não testado, em vez de afirmar que a cobertura está completa.

Essa distinção é explícita na documentação da Microsoft para 4672. Use 4672 para seu contexto de logon, mantendo separadas as verificações de geração e encaminhamento de 4673/4674. Avalie contas, privilégios e processos inesperados em relação às atividades administrativas aprovadas antes de escalar um evento como possível abuso.

Correção: verifique Failure plus Success após a implantação (Remediation)

1. Corrija a subcategoria gerenciada

Quando a linha de base aprovada exigir os dois resultados, configure Audit Sensitive Privilege Use em Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Privilege Use. Selecione Success plus Failure na GPO ou no sistema de configuração que realmente gerencia o grupo de destino.

Documente o responsável pela alteração, os hosts de destino, a lista de exceções, a configuração anterior e a decisão de reversão. Teste a alteração em máquinas representativas antes de estendê-la ao restante do escopo. A implantação deve seguir o grupo de hosts e os limites de gerenciamento identificados, em vez de presumir que todos os computadores relevantes são controlados pela mesma política padrão.

2. Verifique a precedência sobre a política legada e releia o estado do host

Revise Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. A Microsoft recomenda mantê-la habilitada e documenta SCENoApplyLegacyAuditPolicy como um mecanismo que impede a aplicação da política no nível da categoria. Consulte a referência da Microsoft sobre precedência em relação à política legada ao conciliar configurações de auditoria básicas e avançadas.

Depois que a alteração gerenciada chegar a cada host, repita a consulta auditpol baseada em GUID apresentada acima. Compare as saídas antes e depois. Se um host ainda apresentar diferenças, investigue a fonte de gerenciamento aplicável e o processamento da política; não declare a correção concluída apenas com base no editor da GPO.

3. Mantenha Backup/Restore como uma decisão separada

A auditoria do uso dos privilégios Backup e Restore depende também de Audit: Audit the use of Backup and Restore privilege. A Microsoft desaconselha habilitar essa configuração separada porque ela pode produzir um volume considerável de eventos. Não a habilite em todos os lugares como um atalho para concluir esta revisão. Registre a visibilidade necessária, a carga de trabalho, a capacidade operacional e a decisão do responsável para qualquer exceção a essa recomendação.

4. Confirme a entrega antes de concluir a revisão

Verifique novamente a geração local e a interpretação central após a implantação, usando atividades aprovadas e controladas que sejam relevantes para o privilégio pretendido. Combine o evento esperado com o responsável pelo monitoramento antes do teste. Uma ação administrativa genérica não garante que ambos os IDs de evento ou ambos os resultados aparecerão.

Se houver eventos locais, mas faltarem as cópias centrais, investigue a assinatura de encaminhamento, os filtros do agente, os erros de ingestão e a configuração do parser. Se faltarem eventos locais, verifique primeiro a operação, a configuração da auditoria e a janela de observação. São falhas diferentes com responsáveis diferentes. Defina uma data de acompanhamento para os casos não resolvidos e verifique novamente após a reconstrução de hosts ou alterações na política que os gerencia.

Como o EtcSec detecta esse problema

No commit de código-fonte analisado aqui, AUDIT_PRIVILEGE_USE_DISABLED lê advancedAuditLevel. Essa função auxiliar usa um mapa selecionado de GPO de auditoria avançada ou recorre aos dados legados de EventAudit. Quando há um valor conhecido abaixo de 2, o detector emite um achado Medium com Count 1. O valor 2 significa apenas Failure, e o valor 3 significa Success plus Failure: ambos passam pelo seu limiar. Esse detector não exige Success.

Quando nenhuma das fontes selecionadas fornece a configuração, ok=false retorna Count 0, mantém a severidade Medium inicializada e inclui detalhes explicando que ela não está configurada via GPO. A política efetiva do host continua desconhecida; isso não é evidência de conformidade nem de auditoria desabilitada.

A seleção da fonte tem outras limitações:

• A seleção de auditoria avançada prioriza Default Domain Controllers Policy, depois Default Domain Policy e, por fim, a primeira entrada disponível no mapa. A seleção de EventAudit legado prioriza Default Domain Policy, depois Default Domain Controllers Policy e, por fim, a primeira entrada disponível. Essas precedências são diferentes.
• A ausência da subcategoria no mapa avançado selecionado não provoca uma busca em outros mapas avançados. A função auxiliar pode recorrer à categoria legada selecionada.
• O provedor SMB ignora falhas de leitura de GptTmpl.inf e audit.csv durante a coleta da política. Uma seção EventAudit que contenha outro campo pode deixar o campo Privilege Use ausente com seu valor zero.
• O parser de audit.csv extrai pares GUID/valor; ele não atesta que uma política foi aplicada a um host nem preserva um registro completo da proveniência dessa aplicação.

Esse fluxo não calcula Windows Resultant Set of Policy nem considera integralmente SCENoApplyLegacyAuditPolicy. Também não comprova a geração, o encaminhamento ou a interpretação dos eventos. Use o achado para priorizar a investigação e conclua a revisão com a saída de auditpol de cada host e as evidências de coleta.

Registro da revisão

Preserve a decisão sobre a linha de base, o inventário de hosts no escopo, a saída da política por host, as exceções aprovadas, a comparação antes/depois e as amostras de eventos locais comparadas às cópias centrais. Atribua um responsável a cada resultado desconhecido. A revisão está concluída quando cada host no escopo tem um resultado documentado e a telemetria necessária foi verificada, com qualquer exceção restante explicitamente aceita pelo seu responsável.