Lacunas de Monitoramento do Active Directory: Display Specifiers, RODC, Adulteração da Default Domain Policy e PAM Shadow Principals

Lacunas de Monitoramento do Active Directory: Display Specifiers, RODC e Mais Duas

Lacunas de monitoramento do Active Directory – display specifiers, RODC credential caching, adulteração da Default Domain Policy e PAM shadow principals – raramente aparecem em uma revisão de segurança padrão, mesmo sendo os quatro mecanismos documentados pela Microsoft que podem dar a um invasor persistência ou acesso privilegiado enquanto os dashboards habituais (associação a Domain Admins, direitos de DCSync, alterações de ACL em objetos Tier 0) permanecem verdes. São pontos cegos porque ninguém aponta uma SACL ou uma consulta para eles, não porque estejam escondidos.

Este texto aborda cada um deles: o que o objeto ou mecanismo realmente é, como é abusado ou sofre desvio, o que observar para detectá-lo e como corrigi-lo.

Display Specifiers: Um Ponto de Extensão de UI Transformado em Backdoor de Persistência

O Mecanismo

Display specifiers são objetos da classe displaySpecifier, armazenados em containers específicos de idioma sob CN=DisplaySpecifiers,CN=Configuration,DC=<forest-root> — por exemplo, CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration. Como residem no naming context de Configuration, eles replicam para todos os controladores de domínio da floresta. Seu propósito documentado, segundo a referência de programação Win32 AD da Microsoft, é totalmente legítimo: armazenam os dados por trás de páginas de propriedades, menus de contexto, ícones e assistentes de criação em ferramentas baseadas em MMC como o Active Directory Users and Computers (ADUC).

Os atributos que tornam isso interessante do ponto de vista de segurança são adminContextMenu e adminPropertyPages (snap-ins administrativos) e seus equivalentes não administrativos contextMenu/shellContextMenu — todos documentados na especificação de protocolo [MS-ADTS] da Microsoft e na referência da classe de schema Display-Specifier. Cada um pode registrar um objeto COM ou uma aplicação para ser executada quando um administrador interage com um objeto pelo ADUC. Pesquisadores de segurança da Semperis e da SDM Software documentaram diretamente o caso de abuso: um invasor com acesso de escrita a um display specifier pode adicionar uma entrada de menu de contexto falsa — uma que parece uma ação normal (por exemplo, uma opção de redefinição de senha) — que na verdade executa um script quando um administrador do helpdesk clica com o botão direito em um objeto de usuário.

Detecção

Alterações em objetos de diretório geram o evento de segurança do Windows com ID 5136 ("A directory service object was modified"), mas apenas se duas condições forem atendidas: a subcategoria de auditoria avançada "Audit Directory Service Changes" está habilitada no DC, e o objeto de destino possui uma SACL para os atributos relevantes. Nenhuma das duas vem habilitada por padrão para o container DisplaySpecifiers — e é exatamente por isso que essa lacuna existe. Uma vez configurada a auditoria, observe eventos 5136 em que a classe do objeto é displaySpecifier e o atributo alterado é adminContextMenu, adminPropertyPages, contextMenu ou shellContextMenu. Veja Monitoramento do Active Directory: Os IDs de Evento de Segurança que Importam para a linha de base de política de auditoria da qual essas verificações partem.

# Listar todos os objetos display specifier e seus atributos de menu/página de propriedades
Get-ADObject -SearchBase "CN=DisplaySpecifiers,CN=Configuration,$((Get-ADRootDSE).configurationNamingContext)" `
  -Filter "objectClass -eq 'displaySpecifier'" `
  -Properties adminContextMenu, adminPropertyPages, contextMenu, shellContextMenu |
  Where-Object { $_.adminContextMenu -or $_.adminPropertyPages -or $_.contextMenu -or $_.shellContextMenu } |
  Select-Object Name, adminContextMenu, adminPropertyPages, contextMenu, shellContextMenu

Uma linha de base limpa para essa consulta é um resultado vazio na maioria dos domínios — qualquer ocorrência merece revisão manual do CLSID COM ou caminho de aplicação referenciado.

Adulteração da Default Domain Policy: Alterações Silenciosas na Linha de Base de Segurança do Domínio

O Mecanismo

A Default Domain Policy carrega um GUID conhecido e independente de floresta — {31B2F340-016D-11D2-945F-00C04FB984F9} — e aplica a linha de base de conta, senha, Kerberos e bloqueio em todo o domínio, a menos que seja sobreposta por um GPO mais específico. Como esse GUID é fixo e previsível, e como o GPO é antigo o suficiente para que a maioria das equipes tenha parado de revisá-lo após o hardening inicial, alterações nele tendem a passar despercebidas. O MITRE ATT&CK rastreia a adulteração de GPO como a sub-técnica T1484.001 (Domain or Tenant Policy Modification: Group Policy Modification) — adversários alteram GPOs para enfraquecer limites de bloqueio de conta, desativar a complexidade de senha ou distribuir uma tarefa agendada/script de logon para todo computador que aplica a política.

Detecção

Dois IDs de evento distintos cobrem camadas diferentes de uma alteração de GPO, e confundi-los é um erro comum:

• Event ID 5136 ("A directory service object was modified") dispara no próprio objeto AD groupPolicyContainer quando a subcategoria "Audit Directory Service Changes" e uma SACL do objeto estão ambas em vigor. Conteúdo de segurança da pesquisa de detecção do Splunk e a própria orientação de detecção do MITRE apontam especificamente para observar os atributos gPCFileSysPath, gPCMachineExtensionNames e versionNumber — um incremento de versão sem uma solicitação de alteração no SYSVOL correspondente já é, por si só, um sinal que merece atenção.
• Event ID 4739 ("Domain Policy was changed") dispara quando a política de conta efetiva — limite de bloqueio, política de senha, política Kerberos — de fato muda, seja essa mudança feita via Group Policy ou via Local Security Policy. É o evento de maior sinal para responder "a linha de base de segurança em si se moveu" — mas não indica qual GPO ou administrador fez a alteração; combine-o com o 5136 para atribuição.

# Esboço de detecção estilo Splunk: modificação do objeto Default Domain Policy
index=wineventlog EventCode=5136 ObjectDN="*CN=Policies,CN=System,DC=*"
| search ObjectDN="*{31B2F340-016D-11D2-945F-00C04FB984F9}*"
| table _time, SubjectUserName, AttributeLDAPDisplayName, AttributeValue, OperationType

PAM Shadow Principals: Acesso Administrativo Temporário Que Consultas Padrão Não Veem

O Mecanismo

O recurso Privileged Access Management (PAM) do Windows Server, construído sobre o Microsoft Identity Manager, concede acesso privilegiado limitado no tempo sem jamais adicionar uma conta a um grupo permanente como Domain Admins. A própria documentação de PAM da Microsoft descreve o mecanismo: um shadow principal — um objeto da classe msDS-ShadowPrincipal, criado apenas dentro do container padrão CN=Shadow Principal Configuration sob CN=Services no NC de Configuration de uma floresta bastion — carrega um atributo msDS-ShadowPrincipalSid que o mapeia para o SID de um grupo privilegiado na floresta de produção (por exemplo, Domain Admins). A associação a esse shadow principal é concedida com um tempo de vida (TTL) usando o recurso de AD Expiring Links (Windows Server 2016+): o KDC limita qualquer ticket Kerberos emitido ao TTL restante do link, de modo que o acesso realmente expira, em vez de depender de alguém se lembrar de removê-lo.

A lacuna: vínculos de grupo com expiração são armazenados como valores comuns do atributo member com uma flag de TTL, mas esse TTL só é visível para uma consulta que passa explicitamente o controle estendido LDAP_SERVER_LINK_TTL (OID 1.2.840.113556.1.4.2309), conforme documentado pela pesquisa da DSInternals sobre como os Expiring Links realmente funcionam. Uma consulta de rotina do tipo "quem é membro deste grupo", que não passa esse controle, vê uma associação de aparência normal — sem expiração, sem flag de tempo limitado óbvia —, o que significa que um administrador que examina grupos de shadow principal com ferramentas genéricas de auditoria de AD pode não perceber que o acesso é temporário por design, ou perder completamente adições de associação de curta duração se o intervalo de varredura for maior que o TTL.

Detecção

Grupos de shadow principal continuam sendo objetos da classe grupo de segurança, então adições de membro geram os mesmos eventos padrão de associação a grupo do AD que qualquer outro grupo, conforme o escopo do grupo: 4728 (membro adicionado a um grupo de segurança global), 4732 (domain local), 4756 (universal). Filtre esses eventos especificamente para objetos dentro de CN=Shadow Principal Configuration,CN=Services,CN=<config-NC> para isolar ativações de PAM da administração rotineira de grupos.

# Listar shadow principals atuais e o SID mapeado na floresta de produção
Get-ADObject -SearchBase "CN=Shadow Principal Configuration,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" `
  -Filter "objectClass -eq 'msDS-ShadowPrincipal'" `
  -Properties 'msDS-ShadowPrincipalSid', member |
  Select-Object Name, 'msDS-ShadowPrincipalSid', @{N='MemberCount';E={$_.member.Count}}

RODC Credential Caching, Resumidamente

Read-Only Domain Controllers (RODCs) são implantados especificamente para sites de baixa confiança — filiais, locais fisicamente expostos — sob a premissa de que, se um deles for comprometido, o raio de impacto fica limitado às senhas de conta que ele tinha permissão para armazenar em cache. Esse limite é imposto por duas associações de grupo: o Allowed RODC Password Replication Group (vazio por padrão — um RODC não armazena nada em cache até que seja explicitamente permitido) e o Denied RODC Password Replication Group, correspondentes aos atributos msDS-RevealOnDemandGroup e msDS-NeverRevealGroup documentados pela Microsoft. O que foi de fato armazenado em cache é visível em msDS-RevealedList; quem se autenticou pelo RODC está em msDS-AuthenticatedToAccountlist.

Esta é a única lacuna deste texto em que a correção é uma questão de política, não uma lacuna de monitoramento da qual a maioria das equipes nunca ouviu falar — a EtcSec já cobriu o caminho completo de detecção e correção para o cache privilegiado de RODC, incluindo as configurações incorretas exatas da Password Replication Policy que permitem que uma credencial Tier 0 seja replicada para onde nunca deveria estar. Veja RODC Privileged Credential Caching: Read-Only Domain Controller Holds Domain Admin Hashes para a análise completa; o resumo aqui é deliberadamente breve para não duplicá-la.

Detecção: O Que Observar de Fato

Nenhum desses pontos exige um novo pipeline de logging — eles exigem SACLs em objetos que são entregues sem elas, e alguém consultando atributos que scripts padrão de health-check de AD não tocam.

Remediação

Passo a Passo

1. Display specifiers. Coloque uma SACL de "Write all properties" (ou, de forma mais restrita, os atributos específicos de menu/página de propriedades) em CN=DisplaySpecifiers,CN=Configuration,DC=<forest-root> e seus filhos. Estabeleça agora uma linha de base dos valores atuais de adminContextMenu/adminPropertyPages, já que um backdoor comprometido pode já estar presente.
2. Default Domain Policy. Aplique uma SACL ao objeto groupPolicyContainer da Default Domain Policy e à sua pasta no SYSVOL (\\<domain>\SYSVOL\<domain>\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}). Alerte para qualquer par 5136/4739 que não corresponda a um chamado de alteração rastreado.
3. PAM shadow principals. Se PAM/MIM não estiver implantado intencionalmente, confirme que o container CN=Shadow Principal Configuration está vazio e permanece assim. Se estiver implantado, revise a associação de shadow principal em uma cadência que leve em conta TTLs menores que seu intervalo de revisão — um vínculo que expira entre duas varreduras semanais nunca aparece em nenhuma das duas, a menos que você compare eventos 4728/4732/4756 em vez de apenas snapshots pontuais de associação.
4. RODC credential caching. Confirme que o Allowed RODC Password Replication Group não contém principais Tier 0, seja diretamente ou por associação de grupo aninhada — veja o artigo dedicado linkado acima para o passo a passo completo de correção, incluindo as verificações específicas de política de replicação.
5. Alimente os cinco IDs de evento acima (5136, 4739, 4728, 4732, 4756) no SIEM que já processa sua linha de base de política de auditoria do Active Directory — isso é uma extensão da auditoria existente de Account Management e Policy Change, não uma nova categoria de log, e se encaixa naturalmente com processos existentes de monitoramento de GPO e revisão de acesso privilegiado.

Como a EtcSec Detecta Isso

Os detectores Advanced e Computers da EtcSec sinalizam automaticamente essas quatro lacunas em cada auditoria de AD: DISPLAY_SPECIFIER_CHANGES captura modificações recentes em objetos display specifier, DEFAULT_DOMAIN_POLICY_CHANGED sinaliza edições na política de segurança de linha de base do domínio, EPHEMERAL_ADMINS_PAM revela atividade de shadow principal do PAM (incluindo associações de curto TTL que um snapshot manual perderia), e RODC_PRIVILEGED_CACHING — classificado como Crítico — captura credenciais Tier 0 replicadas para um RODC.