Direitos de Usuário Perigosos no Active Directory via GPO (SeDebug, SeTcb): Escalonamento de Privilégio SeLoadDriver para SYSTEM

O que é uma atribuição de direitos de usuário perigosa no Active Directory

A Política de Grupo não serve apenas para distribuir software ou mapear unidades de rede — o contêiner Security Settings de uma GPO também pode conceder direitos de usuário locais ("privilégios" no modelo de token de acesso do Windows, distintos das permissões de objeto) a qualquer principal de segurança, incluindo Authenticated Users, Domain Users ou um grupo personalizado. Quando a seção [Privilege Rights] de uma GPO atribui um privilégio de alto impacto como SeDebugPrivilege, SeLoadDriverPrivilege ou SeTcbPrivilege a contas que não são administradores locais, todo computador ao qual a GPO se aplica herda um caminho direto, sem necessidade de exploit, de "qualquer conta de domínio" para SYSTEM. Equipes de segurança e auditores têm sinalizado cada vez mais esse padrão — direitos de usuário perigosos concedidos por GPO — como um achado distinto do Active Directory, separado da má configuração mais conhecida de "GPO adiciona um usuário aos Administradores locais".

Isso não é uma vulnerabilidade do Windows — é um erro na criação da Política de Grupo, geralmente introduzido para desbloquear um agente de monitoramento, um produto de backup ou uma ferramenta de helpdesk que legitimamente precisa de direitos elevados, e depois deixado em vigor (ou copiado para GPOs sem relação alguma) muito depois de a justificativa original ter deixado de existir. Más configurações de GPO são uma das formas mais comuns pelas quais a Política de Grupo se torna um vetor de ataque, justamente porque são silenciosas: nada quebra, nenhum alerta dispara, e a GPO continua sendo aplicada a cada ciclo de atualização de política.

O raio de impacto escala com o vínculo da GPO, não com a forma como a atribuição foi justificada. Uma GPO criada para corrigir o agente de monitoramento de um único servidor, depois vinculada a uma OU ou à raiz do domínio por conveniência, silenciosamente concede o mesmo direito a todo computador sob esse vínculo — transformando uma exceção estreita e defensável em um caminho de escalonamento em todo o domínio que ninguém aprovou, e mais uma variante dos caminhos ocultos do aninhamento perigoso de grupos até o Domain Admin.

Por que o Active Directory trata esses direitos de usuário concedidos por GPO como perigosos

O Windows aplica cerca de três dezenas de direitos de usuário por meio do token de acesso. A maioria é inofensiva em mãos erradas — "Alterar o fuso horário" não é um caminho para SYSTEM. Três deles são a exceção.

SeDebugPrivilege ("Depurar programas")

SeDebugPrivilege permite que seu detentor abra um handle para qualquer processo ou thread na máquina, contornando a verificação de acesso que de outra forma impediria um não proprietário de tocar no processo de outro usuário — incluindo processos pertencentes a NT AUTHORITY\SYSTEM. Como o LSASS é executado como SYSTEM e mantém material de credenciais em cache na memória, uma conta com SeDebugPrivilege pode abrir um handle para o LSASS e extrair credenciais utilizáveis dele — a mesma primitiva em que ferramentas como o módulo sekurlsa do Mimikatz se baseiam, e a mesma primitiva por trás de técnicas living-off-the-land como o dump do LSASS via exportação MiniDump da comsvcs.dll. Por padrão, apenas Administradores possuem esse direito.

SeLoadDriverPrivilege ("Carregar e descarregar drivers de dispositivo")

SeLoadDriverPrivilege permite que o detentor carregue um driver em modo kernel via API NtLoadDriver(). Drivers de kernel são executados sem nenhuma fronteira de segurança em relação ao restante do SO, então uma conta com esse direito pode registrar e carregar um driver assinado conhecido por ser vulnerável (o driver Capcom.sys é um exemplo bem documentado) e usá-lo como primitiva para ler/escrever memória do kernel ou executar código arbitrário como SYSTEM — uma técnica comumente chamada de BYOVD (Bring Your Own Vulnerable Driver). Esse caminho importa mesmo contra hosts com EDR moderno, já que um driver assinado vulnerável é confiável pelas verificações de integridade de código que bloqueiam código não assinado.

SeTcbPrivilege ("Atuar como parte do sistema operacional")

SeTcbPrivilege é o mais direto dos três: permite que o detentor chame as APIs de autenticação normalmente reservadas à Trusted Computing Base do Windows, o que inclui personificar qualquer conta no sistema, incluindo SYSTEM. Um atacante com esse direito não precisa extrair uma credencial nem carregar um driver — pode criar um serviço que chama diretamente as APIs de logon confiáveis e personificar SYSTEM diretamente. Em um sistema devidamente configurado, nenhuma conta que não seja administrador deveria jamais possuir SeTcbPrivilege.

🚨 Perigo: os três direitos são tratados como críticos porque nenhum deles exige um exploit de execução de código. Se a GPO concede o direito, a escalada é um uso documentado e suportado de uma API do Windows — não um bug.

A cadeia de ataque: da má configuração de GPO até SYSTEM

Passo 1 — Descobrir a atribuição

Um atacante que já possui algum ponto de apoio no domínio (um usuário vítima de phishing, uma conta de serviço de baixo privilégio) enumera as GPOs aplicadas a OUs interessantes — controladores de domínio, servidores tier-0, jump hosts — e lê a seção [Privilege Rights] do GptTmpl.inf de cada GPO no SYSVOL, que qualquer usuário autenticado pode ler por padrão:

# Enumera a seção User Rights Assignment de cada GPO para os três direitos críticos
Get-GPO -All | ForEach-Object {
    $report = [xml](Get-GPOReport -Guid $_.Id -ReportType Xml)
    $report.GPO.Computer.ExtensionData.Extension.UserRightsAssignment |
        Where-Object { $_.Name -match 'SeDebugPrivilege|SeLoadDriverPrivilege|SeTcbPrivilege' } |
        Select-Object @{n='GPO';e={$report.GPO.Name}}, Name, Member
}

Passo 2 — Confirmar se a conta está no escopo

O atacante verifica se sua conta atual — ou um grupo que ele controla, incluindo um grupo amplo como Authenticated Users se a GPO tiver esse escopo tão abrangente — está listada como membro da atribuição, e a quais computadores a GPO está vinculada. Uma GPO vinculada à raiz do domínio ou a uma OU que contém controladores de domínio transforma isso de "interessante" em "fim de jogo para o domínio".

Passo 3 — Weaponizar o direito

• Com SeDebugPrivilege: abrir um handle em lsass.exe e extrair material de credenciais para cracking offline ou replay.
• Com SeLoadDriverPrivilege: registrar e carregar um driver assinado vulnerável, depois explorá-lo para obter um shell SYSTEM.
• Com SeTcbPrivilege: chamar as APIs de logon confiáveis para personificar SYSTEM diretamente, sem necessidade de driver ou dump de credenciais.

Qualquer um dos três converte "usuário de domínio nessa OU" em "SYSTEM local em toda máquina tocada pela GPO" — o que, se a OU incluir ativos tier-0, é funcionalmente equivalente a um caminho de ataque direto até Domain Admin. A partir de SYSTEM local em um controlador de domínio, o atacante está a um passo dos direitos de DCSync e de todo o conjunto de credenciais do domínio.

Detecção

Active Directory Monitoring cobre o conjunto mais amplo de IDs de evento que vale a pena alertar, caso você esteja expandindo sua detecção além desses três privilégios. O repositório público de regras de detecção da Elastic também traz a regra "Group Policy Abuse for Privilege Addition", que observa o evento de alteração do serviço de diretório do AD (Evento ID 5136) disparado quando o GUID da Security Client-Side Extension de uma GPO é tocado — o sinal de que o conteúdo do seu GptTmpl.inf, incluindo [Privilege Rights], foi alterado — sinalizando exatamente essa classe de direito de alto impacto (SeDebugPrivilege, SeTakeOwnershipPrivilege, SeEnableDelegationPrivilege, SeImpersonatePrivilege) — uma referência útil mesmo fora do Elastic Security. Seja qual for a fonte usada para alertar, trate qualquer ocorrência como de alta severidade: não há motivo legítimo para que esses três direitos alcancem uma conta não administradora por meio de desvio rotineiro de política.

Correção

1. Inventarie toda GPO que toca em [Privilege Rights]. Exporte todas as GPOs com Get-GPOReport -All -ReportType Xml e procure por nós UserRightsAssignment; não assuma que apenas GPOs de "linha de base de segurança" tocam essa seção.
2. Restrinja os três direitos críticos a Administradores. Os benchmarks CIS para Windows Server e Windows 11 definem "Depurar programas" (SeDebugPrivilege) apenas para Administradores como recomendação de linha de base; aplique o mesmo padrão a SeLoadDriverPrivilege e SeTcbPrivilege, a menos que exista uma exceção específica, documentada e com prazo definido.
3. Rastreie qualquer exceção até sua origem. Se um agente de monitoramento ou produto de backup realmente precisa de um desses direitos, delimite a GPO ao menor grupo de segurança possível em vez de uma OU ampla ou Authenticated Users, e documente a exceção com um responsável e uma data de revisão.
4. Teste em uma OU isolada antes do lançamento. Implante uma linha de base restrita de User Rights Assignment primeiro em uma OU piloto — alguns agentes legados falham de forma visível (e óbvia) se um direito do qual dependem é removido, o que é uma descoberta muito mais barata do que descobrir isso em produção.
5. Controle de versão para mudanças de GPO. Trate alterações no GptTmpl.inf como mudanças de código — um processo de diff/revisão de GPO transforma uma concessão silenciosa de privilégio em uma mudança revisável em vez de uma surpresa.
6. Reexecute a varredura periodicamente, não apenas uma vez. GPOs são copiadas, herdadas e revinculadas ao longo do tempo, e uma linha de base limpa hoje não garante uma linha de base limpa no próximo trimestre. O desvio de acesso privilegiado segue exatamente esse padrão: os direitos voltam a se infiltrar depois que a auditoria original é encerrada.

Como a EtcSec detecta isso

A auditoria de Active Directory da EtcSec verifica a seção [Privilege Rights] de cada GPO vinculada contra as três atribuições críticas cobertas aqui — PRIVILEGE_SEDEBUG_ABUSE, PRIVILEGE_SELOADDRIVER_ABUSE e PRIVILEGE_SETCB_ABUSE — e sinaliza qualquer SID não padrão à qual uma delas tenha sido concedida fora do grupo interno de Administradores, com o nome da GPO e a OU vinculada, para que o achado seja acionável sem uma varredura manual com Get-GPOReport.