Assinatura SMB desativada: risco NTLM relay e correção

O Que É a Assinatura SMB Desativada?

Assinatura SMB desativada geralmente significa que os clientes Windows, os servidores Windows, ou ambos, não exigem tráfego SMB assinado. Nos sistemas Windows modernos, o controle exato é a configuração RequireSecuritySignature no cliente SMB e no servidor SMB.

A documentação da Microsoft sobre a assinatura SMB é explícita quanto ao que o recurso faz. A assinatura SMB adiciona uma assinatura a cada mensagem SMB usando a chave de sessão e o conjunto de cifras (cipher suite) negociado. Se um invasor adulterar a mensagem em trânsito, a assinatura deixa de corresponder. A Microsoft também declara que a assinatura SMB ajuda a proteger contra ataques de relay e de spoofing.

É por isso que o problema de segurança não se resume a "compartilhamento de arquivos não assinado". Quando a assinatura SMB não é exigida em caminhos onde deveria ser, o ambiente fica mais exposto à interceptação por adversário-no-meio (adversary-in-the-middle) e a oportunidades de NTLM relay.

Para este artigo, o escopo é o Windows SMB 2.x e 3.x em ambientes Active Directory, com ênfase na exposição a relay, na verificação e no hardening prático. O objetivo não é afirmar que a assinatura SMB, sozinha, resolve todos os caminhos de relay possíveis. O ponto é que desativá-la, ou não exigi-la, remove uma das proteções em nível de protocolo que a Microsoft construiu especificamente para impedir a adulteração e o relay no tráfego SMB.

Como Funciona a Assinatura SMB

A Microsoft descreve a assinatura SMB como um recurso de segurança que usa a chave de sessão e o conjunto de cifras para adicionar uma assinatura a uma mensagem que trafega pela conexão SMB. A assinatura contém um hash da mensagem completa presente no cabeçalho SMB. Se alguém alterar a mensagem em trânsito, a verificação da assinatura falha.

Para o SMB 2.x e 3.x, a assinatura é controlada pelo fato de ela ser exigida ou não, e não pela antiga lógica EnableSecuritySignature da era do SMB1. A Microsoft afirma que, para o SMB 2.02 e versões posteriores, o EnableSecuritySignature é ignorado e a assinatura é controlada exclusivamente pelo fato de ela ser exigida.

Essa distinção importa porque as equipes costumam pensar que a assinatura SMB está habilitada apenas porque uma configuração legada existe em algum lugar da política, mesmo quando a exigência efetiva ainda está desativada.

Quando a assinatura SMB é realmente usada

A Microsoft resume o comportamento de forma clara:

a assinatura é usada quando o cliente SMB a exige
a assinatura é usada quando o servidor SMB a exige
a assinatura só deixa de ser usada quando tanto o cliente SMB quanto o servidor SMB não a exigem

Isso significa que o estado vulnerável é mais amplo do que apenas um servidor de arquivos mal configurado. Se nenhum dos dois lados exigir a assinatura, a sessão pode prosseguir sem assinatura.

Por que a assinatura SMB importa em ambientes AD

O SMB não é apenas um protocolo de compartilhamento de arquivos. Os ambientes Active Directory dependem dele para fluxos de trabalho comuns, como o acesso ao SYSVOL e ao NETLOGON, compartilhamentos administrativos e o acesso operacional a arquivos entre endpoints e servidores.

A Microsoft observa explicitamente que os controladores de domínio exigem a assinatura SMB por padrão para as conexões estabelecidas com eles, especialmente em torno do SYSVOL e do NETLOGON. Esse padrão existe por um motivo: o tráfego SMB não assinado na infraestrutura de identidade é muito mais fácil de adulterar ou de usar em um relay.

Assinatura SMB Desativada vs. Assinatura SMB Não Exigida

Na prática, as equipes costumam usar esses dois rótulos como sinônimos, mas a nuance técnica importa.

Desativada geralmente significa que o administrador definiu explicitamente RequireSecuritySignature como False no cliente, no servidor, ou em ambos.
Não exigida significa que o endpoint ainda pode assinar se o outro lado exigir, mas também aceitará uma sessão não assinada quando nenhum dos lados exigir a assinatura.

Do ponto de vista de risco, ambos os estados podem criar o mesmo problema operacional: sessões SMB que têm permissão para prosseguir sem assinatura.

É por isso que muitas auditorias agrupam os dois em um único achado. A pergunta real não é se uma caixa de seleção diz "habilitado". A pergunta real é se o cliente ou o servidor vão recusar o SMB não assinado.

Por Que a Assinatura SMB Desativada Ainda Importa

Esse controle ainda importa porque a Microsoft continua descrevendo a assinatura SMB como uma defesa contra a adulteração de mensagens, o spoofing e o relay, e porque muitos caminhos de relay ainda dependem de conseguir que um servidor aceite tráfego sem essa proteção.

O SMB não assinado dá aos adversários um caminho de protocolo mais fraco

Se um cliente e um servidor conseguem negociar uma sessão não assinada, um invasor presente na rede tem mais espaço para interferir no tráfego ou para retransmitir (relay) material de autenticação para outro host.

O NTLM ainda existe em ambientes reais

Mesmo em organizações que estão migrando para o Kerberos e para protocolos mais fortes, a Microsoft continua documentando o bloqueio de NTLM no SMB como uma etapa de hardening separada para o Windows 11 24H2 e o Windows Server 2025. Esse é um forte sinal de que o problema de downgrade de protocolo e de autenticação legada ainda é operacionalmente relevante.

Dispositivos de terceiros e o acesso do tipo convidado frequentemente enfraquecem o caminho

A orientação da Microsoft sobre a assinatura SMB é direta nesse ponto: se um servidor SMB de terceiros não suporta a assinatura, algumas equipes desativam a assinatura no Windows apenas para restaurar a compatibilidade. A Microsoft alerta explicitamente contra o uso dessa prática como solução alternativa, porque isso significa confiar em um acesso do tipo convidado, ou não assinado, a um compartilhamento remoto.

Pré-Condições para uma Exposição Real de Assinatura SMB

Um achado SMB_SIGNING_DISABLED se torna materialmente importante quando as seguintes condições se sobrepõem.

1. Nenhum dos lados exige a assinatura em um caminho relevante

A exposição central é que tanto o cliente SMB quanto o servidor SMB podem prosseguir sem exigir assinaturas.

2. O NTLM ainda está disponível no caminho

A orientação da Microsoft sobre SMB recomenda repetidamente o uso do Kerberos em vez do NTLMv2 e desaconselha o uso de endereços IP ou de registros CNAME, porque esses padrões tendem a afastar a autenticação do Kerberos e a aproximá-la do NTLM. Isso importa porque a combinação de SMB não assinado com caminhos de acesso orientados a NTLM é uma combinação clássica que viabiliza o relay.

3. O invasor consegue se posicionar no caminho ou influenciá-lo

Os ataques de relay e de interceptação não são mágica remota. O invasor precisa ser capaz de coagir ou posicionar o tráfego através de um sistema que ele controla, ou então abusar de algum outro caminho no qual consiga retransmitir credenciais.

4. Compartilhamentos administrativos ou de alto valor estão acessíveis

Um relay contra um compartilhamento inofensivo é um problema. Um relay contra um servidor de gerenciamento, um compartilhamento administrativo ou um serviço de arquivos sensível é um problema diferente. Se esses sistemas também estiverem acessíveis por causa de uma higiene operacional fraca, o raio de impacto (blast radius) aumenta. Esse é um dos motivos para revisar Contas Obsoletas e Superprivilegiadas no AD junto com as configurações de rede voltadas para o relay.

5. O ambiente ainda contém clientes legados, dispositivos ou fluxos de convidado

A pressão operacional para dar suporte a dispositivos NAS antigos, appliances, scanners ou padrões de acesso do tipo convidado é um dos principais motivos pelos quais a assinatura acaba não sendo exigida, para começar.

A Cadeia de Ataque

Um caminho de ataque prático envolvendo a assinatura SMB desativada geralmente se parece com isto.

Etapa 1 - Encontrar um caminho SMB não assinado

O invasor identifica um par servidor/cliente no qual nenhum dos dois lados exige a assinatura SMB.

Etapa 2 - Coagir ou interceptar a autenticação

O invasor faz com que um sistema ou usuário-alvo se autentique via SMB em um caminho que ele consegue observar ou influenciar.

Etapa 3 - Retransmitir a tentativa de autenticação

Se as condições mais amplas permitirem, o invasor retransmite (relay) a tentativa de autenticação para outro serviço SMB ou para outro endpoint de protocolo que aceite a identidade retransmitida.

Etapa 4 - Usar imediatamente o acesso resultante

O relay é útil porque o invasor não precisa quebrar a senha primeiro. Se o relay for bem-sucedido, ele pode agir com o acesso da vítima em tempo real.

É por isso que esse achado pertence ao lado de Ataques de NTLM Relay: Sequestrando a Autenticação no AD. A assinatura SMB desativada não é toda a história do relay, mas é uma das formas mais claras de tornar o relay SMB mais fácil do que deveria ser.

Detecção

A detecção desse problema tem duas partes: a detecção de configuração e a detecção operacional.

Detecção de configuração

O método de validação mais direto é verificar se o cliente SMB ou o servidor SMB realmente exigem a assinatura.

A Microsoft documenta as verificações exatas em PowerShell:

Get-SmbClientConfiguration | FL RequireSecuritySignature
Get-SmbServerConfiguration | FL RequireSecuritySignature

Se o valor for False, a assinatura não é exigida naquele lado.

Na Política de Grupo (Group Policy), a Microsoft coloca as configurações relevantes em:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Microsoft network client: Digitally sign communications (always)
Microsoft network server: Digitally sign communications (always)

Essa é a maneira mais rápida de transformar uma afirmação vaga de auditoria em um sim ou não concreto.

Compatibilidade de auditoria antes de impor a exigência

Uma melhoria prática nas versões mais recentes do Windows é a auditoria de assinatura e criptografia SMB. A Microsoft documenta os seguintes controles de auditoria:

Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

Os eventos relacionados são registrados em:

Microsoft-Windows-SMBClient/Audit, com os IDs de evento 31998 e 31999
Microsoft-Windows-SMBServer/Audit, com os IDs de evento 3021 e 3022

Esses eventos são especialmente úteis quando você quer tornar a assinatura obrigatória, mas primeiro precisa descobrir quais sistemas de terceiros vão parar de funcionar.

Detecção operacional

Se você suspeitar de abuso real, e não apenas de uma configuração fraca, correlacione:

hosts onde a assinatura não é exigida
padrões de tráfego SMB fortemente baseados em NTLM
atividade do tipo relay descoberta em Monitoramento de Segurança AD: Eventos que Importam
acesso inesperado a compartilhamentos administrativos ou a serviços de arquivos sensíveis
sistemas usando acesso SMB baseado em IP ou padrões de nomenclatura que não usam Kerberos

Não existe um único evento do Windows que diga "o NTLM relay teve sucesso porque a assinatura SMB estava desativada". O modelo mais eficaz é identificar primeiro o caminho não assinado e, depois, correlacionar a atividade de autenticação e de acesso ao redor dele.

Remediação

A remediação primária é direta: exigir a assinatura SMB onde ela deveria ser exigida e, em seguida, reduzir os comportamentos de protocolo adjacentes que mantêm o relay viável.

1. Exija a assinatura SMB em ambos os lados sempre que possível

A Microsoft documenta os comandos exatos em PowerShell:

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true

No nível de política, as configurações relevantes são:

Microsoft network client: Digitally sign communications (always)
Microsoft network server: Digitally sign communications (always)

Se você controla tanto os clientes Windows quanto os servidores de arquivos Windows, essa é a linha de base (baseline) mais limpa.

2. Não trate a incompatibilidade de terceiros como um motivo para normalizar um SMB fraco

A Microsoft alerta explicitamente contra desativar a assinatura SMB como uma solução alternativa para servidores de terceiros e contra tentar usar a assinatura com contas de convidado. Se um appliance de terceiros não suportar a assinatura corretamente, documente-o como dívida técnica ou isole-o. Não reduza silenciosamente a linha de base do Windows para todo o resto.

3. Prefira o Kerberos e evite padrões que empurram você para o NTLM

A Microsoft recomenda:

usar o Kerberos em vez do NTLMv2
não se conectar a compartilhamentos por endereço IP
não usar registros CNAME para acesso SMB nos casos em que eles forçam o comportamento NTLM

Esses não são detalhes cosméticos. Eles reduzem diretamente a chance de que um caminho não assinado ou fracamente protegido se torne um caminho prático de NTLM relay. A higiene de senhas e a higiene de protocolo ainda importam na mesma superfície de ataque, e é por isso que Segurança de Senhas no Active Directory: Configurações que os Atacantes Adoram faz parte da mesma revisão.

4. Use os recursos de hardening SMB mais recentes onde sua plataforma der suporte

A Microsoft agora entrega padrões mais fortes e proteções adjacentes nas versões atuais:

o Windows 11 24H2 Enterprise, Pro e Education exigem a assinatura SMB tanto de entrada (inbound) quanto de saída (outbound)
o Windows Server 2025 exige a assinatura SMB de saída (outbound) por padrão
o Windows 11 24H2 e o Windows Server 2025 adicionam controles de auditoria de assinatura SMB
o Windows 11 24H2 e o Windows Server 2025 adicionam o bloqueio de NTLM no SMB do lado do cliente

Isso significa que a remediação não se resume a alternar uma única política antiga. Nas plataformas mais recentes, você pode usar a auditoria e a redução do NTLM para tornar o ambiente mais seguro sem precisar adivinhar qual dependência vai quebrar.

5. Revise separadamente o acesso de convidado e as dependências de NAS legados

A Microsoft afirma que exigir a assinatura SMB também desativa o acesso de convidado aos compartilhamentos. Se o seu negócio ainda depende de um acesso SMB do tipo convidado, isso é uma exceção de design que deve ser isolada e revisada, e não silenciosamente incorporada ao ambiente normal.

6. Revise a proliferação de administradores locais nos mesmos sistemas

O SMB não assinado em estações de trabalho e servidores membros é mais perigoso quando esses mesmos hosts também compartilham problemas de credenciais de administrador local. Se você está fazendo o hardening do ambiente, revise Windows LAPS Não Implantado: Por que Senhas de Administrador Local Compartilhadas Ainda Importam no mesmo conjunto de sistemas.

7. Combine a assinatura com revisões focadas em relay

Se a assinatura SMB estiver desativada, revise também os achados adjacentes que tornam o relay mais fácil:

Se você está decidindo como operacionalizar essas verificações em todo o ambiente, Comparação de Ferramentas de Auditoria AD também é relevante.

O controle é mais forte quando você o trata como parte de um programa de redução de relay, e não como um valor isolado de registro.

Validação Após o Hardening

Depois de alterar a política, valide o resultado diretamente.

execute Get-SmbClientConfiguration e Get-SmbServerConfiguration para confirmar que RequireSecuritySignature está como True
confirme se as configurações efetivas de Política de Grupo correspondem à linha de base pretendida
habilite primeiro os eventos de auditoria de assinatura se você espera problemas de compatibilidade com terceiros
identifique dispositivos ou softwares que não suportam a assinatura antes de forçar a exigência de forma ampla
teste se ainda existem fluxos de trabalho antigos de convidado ou não assinados, e se eles devem ser desativados em vez de preservados
revise se o acesso a compartilhamentos baseado em IP, o uso de CNAME ou os caminhos SMB fortemente baseados em NTLM ainda estão presentes
inclua o controle na revisão mais ampla descrita em Como Auditar a Segurança do Active Directory: Checklist Prática para Equipes Internas

A verdadeira condição de sucesso não é uma captura de tela da política. É o fato de que os clientes e servidores deixam de aceitar SMB não assinado nos pontos em que a exposição a relay importa.

Como a EtcSec Detecta Exposições Relacionadas

A EtcSec consegue modelar esse problema diretamente porque o SMB_SIGNING_DISABLED é um achado concreto de hardening de rede, e não apenas uma recomendação genérica de boas práticas.

Na prática, os vínculos de catálogo relacionados mais úteis são:

achados diretos de SMB_SIGNING_DISABLED em sistemas que ainda permitem SMB não assinado
achados de NTLM_RELAY_OPPORTUNITY nos quais os pré-requisitos de relay permanecem em vigor
verificações adjacentes de monitoramento e hardening do AD que explicam se o problema é isolado ou faz parte de um ambiente mais amplo, favorável ao relay

É por isso que esse tópico se encaixa junto com Ataques de NTLM Relay: Sequestrando a Autenticação no AD e Como Auditar a Segurança do Active Directory: Checklist Prática para Equipes Internas, e não apenas com orientações genéricas de servidor de arquivos.

Controles Relacionados

Se você está revisando a assinatura SMB desativada, revise também Ataques de NTLM Relay: Sequestrando a Autenticação no AD, Monitoramento de Segurança AD: Eventos que Importam, Como Auditar a Segurança do Active Directory: Checklist Prática para Equipes Internas, Segurança de Senhas no Active Directory: Configurações que os Atacantes Adoram, Windows LAPS Não Implantado: Por que Senhas de Administrador Local Compartilhadas Ainda Importam, Contas Obsoletas e Superprivilegiadas no AD e Comparação de Ferramentas de Auditoria AD. Esses artigos cobrem os caminhos adjacentes de coerção, relay e monitoramento que determinam se o SMB não assinado é apenas uma configuração fraca ou um caminho de ataque prático.

Assinatura SMB desativada: por que ainda permite NTLM relay