NetSessionEnum, Remoto SAM Endurecimento, BloodHound Reconhecimento, Active Directory: Cegando o Grafo de Ataque

O Que São NetSessionEnum, Endurecimento do SAM Remoto, Reconhecimento do BloodHound e a Exposição do Grafo de Ataque do Active Directory?

NetSessionEnum, endurecimento do SAM remoto, reconhecimento do BloodHound, grafos de ataque no Active Directory: esses quatro temas se reduzem às mesmas três configurações, e nenhuma delas carrega um número de CVE — motivo exato pelo qual quase ninguém as endurece.

Os dois tipos de aresta mais valiosos do BloodHound, HasSession e AdminTo, não são construídos a partir de um exploit. Eles vêm de duas chamadas RPC comuns do Windows: NetSessionEnum (quem está conectado aqui agora?) e uma consulta SAMR contra o banco de dados SAM local (quem é administrador local aqui?). Se uma conta de domínio com baixo privilégio pode fazer essas chamadas é decidido inteiramente por dois padrões que mudaram em momentos diferentes — e que ainda hoje deixam uma grande brecha aberta. NetSessionEnum esteve aberto para Authenticated Users até o Windows 10 1703 e o Windows Server 2016, e o SAM remoto era irrestrito antes do Windows 10 1607 e do Windows Server 2016; nas builds atuais, ambos são restritos em servidores membros e estações de trabalho, mas o SAM remoto continua aberto para Todos em cada controlador de domínio, por design documentado. Um atacante com um único ponto de apoio de baixo privilégio percorre o ambiente fazendo as duas perguntas em todo lugar onde ainda são respondidas, e o SharpHound transforma as respostas em um grafo que aponta diretamente para o Domain Admin.

As três configurações abaixo são as alavancas que removem essas duas perguntas do grafo: o descritor de segurança SrvsvcSessionInfo que controla o NetSessionEnum, a política RestrictRemoteSam que controla a consulta SAM/SAMR, e se o SMBv1 — o protocolo cuja era precede ambos os padrões de endurecimento — ainda está instalado em algum lugar do ambiente.

Como Funciona

A enumeração de sessões e de administradores locais são duas de várias fraquezas de identidade de máquina que alimentam o grafo de ataque do BloodHound — veja também a superfície de ataque mais ampla dos objetos de computador no Active Directory para o lado de delegação e DCSync do mesmo problema.

NetSessionEnum e a aresta HasSession

NetSessionEnum é uma API legada do serviço Server (\\host\srvsvc através do compartilhamento administrativo IPC$) que lista as sessões de rede atualmente conectadas a uma máquina — efetivamente "quais contas estão conectadas ou têm uma unidade mapeada para mim agora". O SharpHound a chama durante o método de coleta padrão Session, resolve os IPs/hostnames retornados de volta para objetos de computador e desenha uma aresta HasSession desse computador para cada conta encontrada. Uma aresta HasSession é uma promessa de oportunidade, não uma garantia: se o atacante puder alcançar aquele computador com direitos de administrador (ou outro caminho até ele), as credenciais ou o token de um usuário real, atualmente conectado, podem estar na memória prontos para serem roubados.

Quem tem permissão para chamar NetSessionEnum é controlado por um descritor de segurança armazenado no valor de registro SrvsvcSessionInfo, sob HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\DefaultSecurity. A Compass Security testou essa ACL específica build a build e publicou a matriz: Windows 10 1607 (14393) e 1703 (15063) e Windows Server 2016 (14393) concedem à Authenticated Users o direito de chamá-la, enquanto Windows 10 1709 (16299) e posteriores, Windows Server 2019 (17763) e Windows Server 2022 (20348) não concedem. Nessas builds mais recentes, o descritor concede acesso remoto a Administradores, Operadores de Servidor e Power Users, além das sessões de logon Interativa, de Serviço e em Lote localmente — o que é, quase exatamente, a ACL que o script de endurecimento NetCease foi escrito para aplicar. A Compass também observa que as atualizações cumulativas não alteraram o comportamento dentro de um determinado release, e que não há documentação pública clara da Microsoft sobre a mudança — então a única forma de saber qual comportamento um determinado host tem é ler o valor, não inferi-lo pela versão do SO na lista de ativos.

Acesso remoto ao SAM e a aresta AdminTo

O método de coleta LocalAdmin do SharpHound (também usado pelos métodos RDP, DCOM e PSRemote) enumera os grupos locais de um computador através do pipe nomeado SAMR (\\host\samr, também via IPC$) para descobrir quem é membro dos Administradores locais — a origem da aresta AdminTo. O protocolo SAMRPC permite que um chamador com baixo privilégio enumere usuários, grupos e associações de grupo a partir do SAM local e do Active Directory — exatamente o passo de reconhecimento que atacantes usavam bem antes do BloodHound existir para descobrir onde uma conta privilegiada tem direitos permanentes de administrador local.

Isso é controlado pela política Acesso à rede: Restringir clientes com permissão para fazer chamadas remotas ao SAM (valor de registro RestrictRemoteSam, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\RestrictRemoteSam, REG_SZ). A própria documentação da Microsoft é explícita sobre o padrão aqui, e o padrão é desigual por design:

Essa linha do meio é a nuance que importa: a história de "seguro por padrão desde 2016" só se aplica a servidores membros e estações de trabalho. Controladores de domínio — as máquinas cujos dados de administrador local um atacante mais deseja — vêm com leituras SAMR abertas para Todos, em toda versão do Windows Server suportada, por motivos de compatibilidade que a Microsoft declara explicitamente, e não como um descuido.

Onde o SMBv1 se encaixa

O SMBv1 não é o transporte que carrega as chamadas NetSessionEnum ou SAMR — esses RPCs trafegam por pipes nomeados no IPC$ independentemente do dialeto SMB. O que o SMBv1 revela é história. A Microsoft não instala o SMBv1 por padrão desde o Windows 10 e o Windows Server, versão 1709, e o Windows Server 2019 e posteriores são entregues sem ele após uma instalação limpa. Um host que ainda responde ao SMBv1 se enquadra, portanto, em uma de três categorias, e a terceira é a que a maioria dos ambientes esquece: ele é anterior ao corte, alguém o reinstalou deliberadamente, ou ele foi atualizado in-place. A Microsoft é explícita ao afirmar que upgrades in-place não removem automaticamente o SMBv1, e que no Windows 10 Enterprise, Education e Pro for Workstations "um administrador deve decidir desinstalar o SMBv1 nesses ambientes gerenciados" — nenhuma remoção automática de 15 dias se aplica ali. Portanto, o SMBv1 não prova que o host é antigo; prova que o host nunca foi rebaselinado. Essa é a mesma condição sob a qual um descritor SrvsvcSessionInfo anterior a 1709 sobrevive, o que faz dele um atalho de inventário útil — "vá ler manualmente as ACLs de sessão e SAM deste host" — em vez de um primitivo de ataque separado.

Essa superfície de reconhecimento de sessão/administrador local está ao lado de outros caminhos de reconhecimento já cobertos neste blog: assinatura SMB desativada, que permite NTLM relay, cadeias de ataque NTLM relay contra o Active Directory de forma mais ampla, e acesso LDAP anônimo via um valor dsHeuristics permissivo, que cobre a enumeração do lado do diretório. Este artigo não repete nada disso — ele trata especificamente da superfície de enumeração de sessão e de administrador local que alimenta HasSession e AdminTo.

A Cadeia de Ataque

Etapa 1 — Qualquer ponto de apoio no domínio

O atacante não precisa de mais do que uma única credencial de domínio válida (ou um token de sessão sem supervisão) — nenhum exploit, e nenhum direito de administrador local nos controladores de domínio que está prestes a enumerar.

Etapa 2 — Coleta padrão do SharpHound

# -c All executa todos os métodos de coleta, incluindo Session e LocalAdmin
.\SharpHound.exe -c All -d corp.local

Para cada host ativo, o SharpHound chama NetSessionEnum via \\host\srvsvc para sessões e uma consulta de grupo local SAMR via \\host\samr para administradores locais. As duas chamadas não falham nem têm sucesso juntas. A consulta SAMR tem sucesso contra todo controlador de domínio, independentemente da versão do Windows, por causa do padrão em branco mencionado acima; a chamada de sessão tem sucesso em qualquer host cujo descritor SrvsvcSessionInfo ainda seja o anterior a 1709, ou tenha sido relaxado depois. Uma única conta de baixo privilégio é suficiente para ambas.

Etapa 3 — O BloodHound constrói o caminho

O BloodHound Community Edition correlaciona as arestas HasSession e AdminTo retornadas com as associações de grupo existentes para calcular um caminho mais curto, como: conta de baixo privilégio comprometida → tem uma sessão no Host-X → uma conta de Domain Admin também está conectada no Host-X → o atacante assume o Host-X → despeja o LSASS ou rouba o token do Domain Admin.

Etapa 4 — Roubo de credenciais no host alvo

Se o atacante também tiver (ou puder obter) direitos de administrador local no host que carrega a sessão — frequentemente verdadeiro, já que a enumeração AdminTo do mesmo levantamento de baixo privilégio já revela quais hosts têm associação de administrador local permissiva —, a sessão se torna uma oportunidade de roubo de credenciais via acesso ao LSASS ou representação de token.

Detecção

Nem o NetSessionEnum nem uma leitura SAMR produzem, por padrão, um evento dedicado do Windows do tipo "alguém me enumerou", e ambos dependem da mesma configuração avançada de política de auditoria que a maioria dos domínios deixa em seu estado incompleto de fábrica. Os eventos a seguir oferecem a melhor cobertura disponível:

Não construa detecção baseada em volume apenas sobre o 16965. A Microsoft o limita: por padrão, o evento é registrado apenas na primeira vez que o acesso é negado após a inicialização, e cada negação posterior dentro de uma janela de 15 minutos é apenas contada e reportada em massa pelo evento 16969 ("N chamadas remotas ao banco de dados SAM foram negadas na janela de limitação dos últimos X segundos"). A janela é definida por RestrictRemoteSamEventThrottlingWindow (REG_DWORD, segundos, sob HKLM\System\CurrentControlSet\Control\Lsa); defina-a como 0 para desativar a limitação e registrar cada negação. O modo somente auditoria não é limitado, o que é mais um motivo para executá-lo primeiro.

Uma caça prática: filtre o ID de Evento 5145 por Share Name = \\*\IPC$ e Relative Target Name em srvsvc, samr, lsarpc, e então sinalize qualquer conta de origem que não seja controlador de domínio que toque mais do que um punhado de hosts de destino distintos em uma janela curta — uma única conta de estação de trabalho chamando srvsvc/samr contra dezenas de hosts em minutos é o comportamento padrão de coleta do SharpHound, não atividade normal de usuário. O evento 5145 vem da subcategoria Auditar Compartilhamento de Arquivo Detalhado, que é desativada por padrão e de alto volume, então delimite-a deliberadamente.

Remediation

1. Faça o inventário antes de restringir. Ative o RestrictRemoteSamAuditOnlyMode (REG_DWORD, valor 1, sob HKLM\SYSTEM\CurrentControlSet\Control\Lsa) e analise o evento 16968 por alguns dias para identificar chamadores legítimos de SAM remoto antes de configurar a política em produção.
2. Configure explicitamente o RestrictRemoteSam nos controladores de domínio. O padrão ali é "Todos" por compatibilidade — isso não se torna seguro só porque a máquina roda o Windows Server mais recente. Defina uma SDDL que permita apenas as contas e grupos que realmente precisam de leituras SAM remotas (o SAMRi10, dos mesmos pesquisadores da Microsoft que criaram o NetCease, cria um grupo dedicado "Remote SAM Users" e escreve a SDDL para você, em vez de editar a string manualmente). Reinicializações não são necessárias: a Microsoft afirma que a configuração entra em vigor assim que é salva localmente ou aplicada por Diretiva de Grupo.
3. Endureça o NetSessionEnum com uma mudança de ACL no SrvsvcSessionInfo — nas builds que ainda precisam disso. O script NetCease remove Authenticated Users do descritor de segurança SrvsvcSessionInfo e adiciona os SIDs de logon Interativo, de Serviço e em Lote, mantendo Administradores, Power Users e Operadores de Servidor. A própria documentação é explícita ao afirmar que você "precisa reiniciar o serviço 'Server' para que as mudanças tenham efeito" (Restart-Service -Name LanmanServer -Force). Note o que isso significa em um ambiente moderno: Windows 10 1709+ e Windows Server 2019+ já entregam essa ACL por padrão, então o NetCease é praticamente um no-op ali — seu valor está nos hosts anteriores a 1709 e no Server 2016, e em qualquer host cujo descritor tenha sido relaxado posteriormente. Teste primeiro em um grupo de auditoria/homologação — as mesmas ferramentas administrativas que quebram sob RestrictRemoteSam também podem quebrar aqui.
4. Não assuma que a versão do SO revela o estado atual. Consulte SrvsvcSessionInfo e RestrictRemoteSam diretamente, em vez de confiar em "estamos no Server 2019/2022, então estamos bem":

   Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name RestrictRemoteSam -ErrorAction SilentlyContinue
   

5. Confirme que o SMBv1 realmente se foi, não apenas presuma que sim.

   # Requer elevação; desativar aciona uma reinicialização a menos que -NoRestart seja usado
   Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
   # Se o State for Enabled:
   Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
   
   # Alternativa não elevada da Microsoft, mais adequada para varrer um ambiente inteiro:
   Get-SmbServerConfiguration | Format-List EnableSMB1Protocol
   

   Trate qualquer host que ainda responda ao SMBv1 como um sinal para verificar manualmente seu estado de SrvsvcSessionInfo e RestrictRemoteSam — não porque o SMBv1 prova que o host é antigo, mas porque prova que o host nunca foi rebaselinado, a mesma condição que preserva um descritor de sessão ou SAM desatualizado. Isso complementa a lista mais ampla de prioridades de endurecimento do Active Directory, que mostra onde isso se encaixa em relação a outras correções.
6. Execute o SharpHound novamente após o endurecimento e compare a contagem de arestas. Uma queda nas arestas HasSession e AdminTo contra o mesmo domínio, com os mesmos métodos de coleta, é a única prova de que a mudança realmente reduziu o grafo de ataque, e não apenas o checklist de conformidade.

Como a EtcSec Detecta Isso

O audit de Active Directory da EtcSec cobre as três configurações no nível em que são governadas centralmente: Diretiva de Grupo. NET_SESSION_HARDENING_MISSING dispara quando nenhuma política configura o endurecimento de sessão do SrvsvcSessionInfo — a configuração equivalente ao NetCease simplesmente está ausente do conjunto de políticas do domínio. SAM_REMOTE_ACCESS_OPEN dispara quando o RestrictRemoteSam não está definido ou carrega uma SDDL sem DACL, o estado que deixa o padrão do controlador de domínio em vigor. SMB_V1_ENABLED dispara quando a política deixa o SMBv1 habilitado.

Leia essas três descobertas pelo que são: elas dizem se o domínio tem uma política que fecha essas brechas, não se cada máquina individual está em conformidade com ela. Essa distinção é o ponto central deste artigo. Uma baseline de GPO limpa ainda deixa para você o trabalho por host descrito acima — ler SrvsvcSessionInfo e RestrictRemoteSam nos próprios hosts, e executar o SharpHound novamente para comparar a contagem de arestas — porque um upgrade in-place, uma gravação de política local ou um script de endurecimento de terceiros pode divergir da política sem alterá-la.