Proteção contra Reconhecimento Interno usando NetCease e SAMRi10

O que é Reconhecimento Interno?

A reconhecimento interno é um dos primeiros passos que um atacante tomará assim que comprometer uma conta de usuário ou computador na sua rede. Utilizando várias ferramentas ou scripts, eles enumeram e coletam informações que os ajudarão a identificar quais ativos devem tentar comprometer a seguir para obter o que desejam. Por exemplo, BloodHound mapeará caminhos de ataque que podem permitir a um adversário escalar seus privilégios de usuário comum para administrador.

Quase todos os métodos comuns de enumeração podem ser executados por um usuário sem privilégios, o que os torna extremamente difíceis de detectar e bloquear. Neste post, explicarei como usar para se defender contra dois tipos de reconhecimento interno:

• Enumeração de sessões por usuários não privilegiados
• Consultas ao protocolo MS-SAMR

Tipos de Reconhecimento

Para encontrar informações sobre a rede que penetraram, os atacantes frequentemente enumeram os seguintes tipos de dados:

• Sessões — Para descobrir quem está logado onde
• Usuários — Para entender todos os usuários no domínio, idealmente com a sua associação a grupos
• Grupos — Para ver todos os grupos no domínio, idealmente com a sua composição
• Listas de controle de acesso (ACLs) do Active Directory — Para entender quais principais de segurança (como usuários e grupos) podem acessar quais recursos
• Membros do grupo local — Para ver quem tem direitos de acesso na máquina (especialmente quem possui direitos administrativos)

Bloqueando a enumeração de sessões com NetCease

Este post do blog se concentra na enumeração de sessões, que permite a um adversário determinar onde contas de usuário e serviço estão logadas. Essa informação ajuda a priorizar quais hosts tentar comprometer primeiro — como hosts que têm um administrador logado.

Nota: As permissões padrão no Windows 10 foram alteradas para impedir que atacantes realizem enumeração de sessão; no entanto, ainda vale a pena verificar.

NetCease é um pequeno script PowerShell que ajuda a prevenir a enumeração de sessões ao alterar a chave do Registro que controla as permissões do método NetSessionEnum. (A razão pela qual isso é feito usando um script em vez de manualmente é porque a chave, SrvsvcSessionInfo, só é editável em um valor binário do reg.) Aqui está o caminho para a chave SrvsvcSessionInfo:

Caminho: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/LanmanServer/DefaultSecurity

O valor padrão da chave de registro SrvsvcSessionInfo é a ACL que permite o uso do método NetSessionEnum. Isso é atribuído aos seguintes:

• Membro dos Administradores
• Membro dos Operadores de Servidor
• Membro dos Power Users
• Usuários Autenticados

A permissão de Usuários Autenticados permite que atacantes realizem reconhecimento de sessão usando qualquer conta de usuário comprometida.

O que o script NetCease faz é criar um backup do valor atual do registro e, em seguida, alterar as permissões, de modo que as seguintes ACEs estejam na ACL:

• InteractiveSid
• ServiceSid
• BatchSid
• Administradores
• Operadores de Servidor
• PowerUsers

Verificando a ACL

Se você deseja visualizar o descritor de segurança, pode usar o seguinte trecho de PowerShell, que mostrará a ACL:

      #Registry Key Information
$key = "HKLM:SYSTEMCurrentControlSetServicesLanmanServerDefaultSecurity"
$name = "SrvsvcSessionInfo"

#Get the Registry Key and Value
$Reg_Key = Get-Item -Path $key
$BtyeValue = $reg_Key.GetValue($name, $null)

#Create a CommonSecurityDescriptor Object using the Byte Value
$Security_Descriptor = New-Object -TypeName System.Security.AccessControl.CommonSecurityDescriptor -ArgumentList $true, $false, $ByteValue, 0

#Output of the ACL to make it simple to see for document. Use only $Security_Descriptor.DiscretionaryAcl if you want to see the full ACL!
$Security_Descriptor.DiscretionaryAcl | Select-Object SecurityIdentifier, ACEType | Format-Table -AutoSize
      

Saída antes de executar o NetCease:

Saída após executar o NetCease:

Nota: Informações sobre SIDs conhecidos podem ser encontradas aqui.

Teste de Enumeração de Sessão

Uma maneira fácil de testar se você bloqueou a enumeração de sessões por contas de usuário comuns é usar a ferramenta NetSess do Joeware.net, mas existem muitas outras opções, incluindo SharpHound. Ao fazer isso, certifique-se de que está usando uma conta de usuário que não seja membro dos Administradores, Operadores de Servidor ou Usuários Avançados.

Saída antes de usar NetCease

      Netsess.exe [Computer]
      

Saída após o uso de NetCease com uma conta sem privilégios

      Netsess.exe [Computer]
      

Saída após o uso de NetCease com uma conta de usuário privilegiado

      Netsess.exe [Computer]
      

Bloqueando Reconhecimento usando Remote SAM (SAMR)

Attackers can perform reconnaissance using the SAMR protocol, which can remotely query devices but can also query Active Directory. Using SAMR, an attacker without any administrative privileges can find highly privileged groups and users, as well as local users and groups for every system on the network. Tools such as BloodHound can then automatically map this information into attack paths to compromise Active Directory.

A Microsoft introduziu proteções para consultas SAMR com o Windows 10 e, em 2017, adicionou atualizações para sistemas operacionais anteriores até o Windows 7 e Server 2008 R2 usando a chave de registro RestrictRemoteSAM. Esta chave é uma string (REG_SZ) que conterá o SDDL do descritor de segurança que protege chamadas Remote SAM.

Na edição de aniversário do Windows 10 (1607) e do Windows Server 2016 e posteriores, o SDDL padrão foi alterado para permitir apenas que administradores locais consultem o Remote SAM.

Abaixo está uma tabela que detalha os requisitos, comportamentos padrão e opções de proteção para todos os sistemas operacionais:

Existem três maneiras de configurar a chave de registro RestrictRemoteSAM:

• Registro
• Política de Grupo
• SAMRi10 (Samaritano)

Vamos revisar cada um deles.

Opção de Registro

A chave de registro RestrictRemoteSAM está disponível para que os administradores atualizem como desejarem:

Caminho: HKLM/System/CurrentControlSet/Control/Lsa

Nome: RestrictRemoteSAM

Valor padrão (SDDL) no Windows 10: O:SYG:SYD:(A;;RC;;;BA)

Componentes do SDDL

Como você pode ver, o valor padrão que o Windows 10 define é SYSTEM para Proprietário e Grupo Primário e Controle de Leitura para Administradores Integrados.

Verificando o SDDL antes de aplicá-lo

Para verificar se o SDDL está correto antes de aplicar a alteração, você pode usar o comando ConvertFrom-SDDLString no PowerShell para convertê-lo em um descritor de segurança mais fácil de ler.

Opção de Política de Grupo ou Política de Segurança Local

As configurações de Política de Grupo e Security Policy permitem que os administradores configurem essa chave facilmente. Isso pode funcionar bem para administradores que desejam definir o mesmo valor em todos os sistemas ou vários grupos de sistemas (por exemplo, permitindo conexões Remote SAM para todos os servidores em uma OU específica ou um determinado conjunto de servidores de aplicativos).

Os detalhes sobre a configuração são os seguintes:

Opção SAMRi10 (Samaritano)

SAMRi10 é um script PowerShell que oferece uma vantagem chave em relação às opções anteriores: Ele cria um novo grupo local e delega acesso para o grupo poder realizar chamadas SAM remotas. Isso permite que os administradores controlem totalmente essa funcionalidade nas Preferências de Política de Grupo ou concedam manualmente a contas quando necessário.

O script SAMRi10 faz o seguinte:

1. Cria um grupo local chamado “Remote SAM Users”
2. Altera a SDDL para incluir o grupo recém-criado:
   • Se não houver um SDDL padrão, então conceda acesso aos Administradores Internos.
   • Se um SDDL existir, então modifique-o para incluir a nova ACE para o grupo de Usuários SAM Remotos.

Benefícios de usar SAMRi10

• Fácil de conceder acesso granular para acesso Remote SAM
• Ajuda organizações que desejam impor acesso com o menor privilégio
• Pode ser usado em conjunto com uma associação de local group membership Group Policy para conceder acesso centralizado aos usuários usando o direcionamento de item
• Pode ser utilizado por um sistema de Privileged Access Management (PAM) para conceder facilmente acesso dinâmico (just-in-time) se uma conta ou processo requerer essa permissão específica

Defendendo contra Reconhecimento com Soluções Netwrix

Netwrix StealthAUDIT inclui um analisador de caminho de ataque que fornece aos administradores informações sobre suas ACLs do Active Directory para que possam corrigir quaisquer falhas antes que os adversários as explorem. Netwrix StealthINTERCEPT pode monitorar consultas LDAP e depois encaminhá-las para Netwrix StealthDEFEND, que pode detectar vários cenários de reconhecimento e consultas prontas para uso, incluindo BloodHound, consultas para todos os SPNs e consultas para todas as contas com password never expires.

FAQ

O que é reconhecimento interno e por que você deve se importar?

A reconhecimento interno ocorre quando atacantes que já obtiveram acesso inicial à sua rede começam a mapear o ambiente para encontrar alvos valiosos. Eles não estão mais invadindo – já estão logados e procurando ao redor. É aqui que a maioria das estratégias de segurança falha, concentrando-se em defesas perimetrais enquanto os atacantes se movem livremente por dentro usando credenciais legítimas.

A realidade é clara: você não pode proteger o que não consegue ver, e não pode controlar o que não entende. A reconhecimento interno é a fase crítica onde os atacantes coletam inteligência sobre a estrutura do seu Active Directory, identificam contas de alto valor e mapeiam caminhos para os seus dados mais sensíveis. Data Security That Starts with Identity começa com a identidade, e isso significa impedir que os atacantes enumerem sua infraestrutura de identidade em primeiro lugar.

Como você implementa NetCease para proteção contra enumeração de sessão?

NetCease bloqueia ataques de enumeração de sessão impedindo que usuários não autorizados listem sessões ativas em seus controladores de domínio e servidores. A implementação é direta, mas requer planejamento. Primeiro, baixe o NetCease do repositório oficial e verifique se você está executando-o em um sistema com o PowerShell 5.1 ou posterior.

Pré-requisitos:

• Privilégios administrativos
• PowerShell 5.1 ou posterior
• Sistema associado a um domínio ou Windows Server

A ferramenta funciona modificando as configurações do registro que controlam como o serviço Windows Server responde às solicitações de enumeração de sessão. Execute o NetCease com privilégios administrativos em cada servidor que deseja proteger, começando por sistemas não críticos para testes. As alterações entram em vigor imediatamente sem a necessidade de reinicialização, mas você deve validar se as ferramentas administrativas legítimas e soluções de monitoramento ainda funcionam corretamente.

A melhor prática é implementar o NetCease gradualmente em seu ambiente em vez de implantá-lo em todos os lugares de uma só vez. Comece com servidores que não hospedam aplicações críticas para o negócio, monitore por quaisquer interrupções, depois expanda para controladores de domínio e outros alvos de alto valor. Lembre-se de que prevenir reconhecimento não é sobre tornar sua rede invisível – é sobre fazer os atacantes trabalharem mais e dar mais tempo para seus sistemas de detecção identificarem atividades maliciosas.

Qual é a diferença entre SAMRi10 e as restrições de Group Policy SAM?

SAMRi10 e Group Policy restringem ambos o acesso ao banco de dados Security Account Manager (SAM), mas operam em níveis diferentes e atendem a casos de uso distintos. SAMRi10 é um script PowerShell que modifica diretamente as configurações do registro em máquinas individuais, oferecendo controle granular sobre as restrições de acesso ao SAM em sistemas específicos.

As restrições de Group Policy SAM funcionam no nível do domínio, permitindo que você aplique políticas consistentes em vários sistemas simultaneamente. A abordagem de Group Policy é melhor para implantações em larga escala onde é necessária proteção uniforme em muitas máquinas. SAMRi10 é ideal para servidores específicos, ambientes de teste ou situações onde você precisa de configurações personalizadas que não se enquadram nos modelos padrão de Group Policy.

A implementação técnica também difere. O SAMRi10 modifica diretamente a chave de registro RestrictRemoteSAM, enquanto a Política de Grupo utiliza o sistema de modelo administrativo para alcançar o mesmo resultado. Ambos os métodos são eficazes, mas o SAMRi10 oferece mais flexibilidade para solução de problemas e configurações personalizadas. Para a maioria das organizações, uma abordagem híbrida funciona melhor: use a Política de Grupo para restrições SAM de base em todo o domínio e, em seguida, use o SAMRi10 para sistemas específicos que necessitam de reforço adicional.

Como você verifica se as medidas de proteção contra reconhecimento estão funcionando?

Testar a sua proteção contra reconhecimento requer uma abordagem metódica que simula técnicas reais de atacantes sem interromper as operações. Comece com testes básicos de enumeração de sessão utilizando ferramentas como NetSess ou comandos Get-WmiObject do PowerShell a partir de uma conta não administrativa. Se o NetCease estiver funcionando corretamente, essas tentativas devem falhar ou retornar informações limitadas.

Para restrições do SAM, teste o acesso remoto ao banco de dados do Security Account Manager utilizando ferramentas como enum4linux ou rpcclient de um sistema Linux, ou comandos net use do Windows. Restrições de SAM adequadamente configuradas devem bloquear tentativas de enumeração não autorizadas enquanto ainda permitem acesso administrativo legítimo.

A chave é testar a partir da perspectiva do atacante. Crie contas de teste com privilégios de usuário padrão e tente técnicas comuns de reconhecimento, como enumeração de domínio, descoberta de compartilhamento e listagem de contas de usuário. Documente o que funciona e o que não funciona, e então ajuste suas medidas de proteção de acordo. Lembre-se de que a segurança eficaz não é sobre bloquear tudo – é sobre controlar quais informações estão disponíveis para quem, enquanto garante que as funções legítimas do negócio continuem a operar adequadamente.

Quando você deve reverter as alterações do NetCease e SAMRi10?

Cenários de reversão geralmente envolvem problemas de compatibilidade com ferramentas administrativas legítimas, falhas inesperadas de aplicativos ou interrupções de processos de negócios que não foram identificadas durante os testes. NetCease e SAMRi10 ambos oferecem opções de reversão, mas o processo é diferente para cada ferramenta.

Para NetCease, o processo de reversão envolve reverter as modificações do registro que controlam a enumeração de sessão. A ferramenta inclui parâmetros para restaurar as configurações originais, mas você deve sempre documentar a baseline configuration antes de fazer alterações. Teste o processo de reversão primeiro em um ambiente de laboratório para garantir que você entenda os passos e o tempo envolvido.

O rollback do SAMRi10 é mais complexo porque envolve múltiplas chaves de registro e potenciais interações com a Política de Grupo. Se você implementou restrições do SAM por meio da Política de Grupo, utilize as ferramentas de gerenciamento de políticas para reverter as alterações. Para modificações diretas no registro, o SAMRi10 inclui funções de restauração, mas a verificação manual é essencial para garantir um rollback completo.

A melhor abordagem é proativa: implemente mudanças durante janelas de manutenção, tenha procedimentos de reversão documentados e testados, e monitore os sistemas afetados de perto por pelo menos 24-48 horas após a implementação. A maioria dos problemas de compatibilidade aparece rapidamente, mas alguns podem se tornar aparentes apenas durante processos de negócios específicos ou operações do sistema.