Kerberos Armoring (FAST): Active Directory Flexible Authentication Secure Tunneling Desativado por Padrão

Kerberos Armoring, FAST, Active Directory Flexible Authentication Secure Tunneling

Kerberos Armoring, FAST, Active Directory Flexible Authentication Secure Tunneling — a Microsoft empilha todos esses nomes em um único recurso, e em um domínio padrão esse recurso está desativado. As duas configurações de Política de Grupo que o ativam vêm como Not Configured (não configurado), então a troca de autenticação que carrega material derivado de senha atravessa a rede sem nenhum canal protegido ao redor, mesmo que toda versão suportada do Windows Server consiga blindá-la (armor) desde o Windows Server 2012.

O FAST é definido na RFC 6113, A Generalized Framework for Kerberos Pre-Authentication. A IANA registra seu tipo de dado de pré-autenticação PA-FX-FAST como padata type 136, ao lado de PA-FX-COOKIE (133), PA-FX-ERROR (137) e PA-ENCRYPTED-CHALLENGE (138). A própria descrição da Microsoft sobre a implementação no Windows é curta e precisa: "Flexible Authentication Secure Tunneling (FAST) fornece um canal protegido entre o cliente Kerberos e o KDC. O FAST é implementado como Kerberos armoring no Windows Server 2012 e está disponível apenas para trocas do Authentication Service (AS) e do Ticket-Granting Service (TGS)."

A Microsoft lista três benefícios para sistemas ingressados no domínio, e o primeiro é o motivo pelo qual este artigo existe:

• Proteção contra ataques de dicionário offline. "O Kerberos armoring protege os dados de pré-autenticação do usuário, que são vulneráveis a ataques de dicionário offline quando gerados a partir de uma senha."
• Erros Kerberos autenticados. O armoring "protege as autenticações Kerberos do usuário contra spoofing de erros Kerberos do KDC, que pode causar downgrade para NTLM ou criptografia mais fraca."
• Compound authentication, a extensão de identidade de dispositivo usada pelo Dynamic Access Control.

Fonte: What's New in Kerberos Authentication, Microsoft Learn.

Como funciona o Kerberos Armoring

O FAST envolve a requisição real dentro de uma troca externa criptografada sob uma armor key. A RFC 6113 afirma claramente, nas definições ASN.1 tanto da requisição blindada quanto da resposta blindada, que "a chave de criptografia é a armor key." Um observador na rede vê o envelope blindado, não os dados de pré-autenticação dentro dele.

Quais trocas são de fato blindadas

De onde vem a armor key é o ponto que confunde as pessoas. Microsoft: "O Kerberos armoring usa um ticket-granting ticket (TGT) do dispositivo para proteger as trocas do Authentication Service com o KDC, portanto a troca de Authentication Service do computador não é blindada. O TGT do usuário é usado para proteger suas trocas TGS com o KDC."

Leia isso duas vezes, porque define o limite desse controle:

A autenticação inicial da própria máquina não pode ser blindada, porque a armor key é justamente o que ela está tentando obter. Todo logon de usuário nessa máquina depois disso pode ser.

A RFC 6113 é explícita sobre o ataque que isso elimina: "O padata de pré-autenticação Kerberos FAST definido nesta seção fornece uma ferramenta para reduzir significativamente a vulnerabilidade a ataques de dicionário offline. Combinado com o encrypted challenge, o FAST exige que um atacante realize com sucesso um ataque man-in-the-middle para observar o texto cifrado."

Por que a pré-autenticação não blindada é coletável

Sem o FAST, o fluxo padrão de pré-autenticação do Windows é PA-ENC-TIMESTAMP — tipo de pré-autenticação 2, que a Microsoft documenta como "um tipo normal para autenticação padrão por senha." O cliente prova o conhecimento da senha criptografando um timestamp com uma chave derivada dessa senha, e o KDC retorna uma AS-REP cuja parte criptografada é protegida pela mesma chave derivada da senha.

As duas metades são texto cifrado derivado de senha, e a RFC 6113 descreve a consequência diretamente: "Um atacante pode solicitar uma AS-REP e tentar várias senhas para ver se consegue descriptografar o ticket resultante."

A análise da Trimarc Security sobre o Kerberos armoring (publicada em julho de 2024) faz o mesmo ponto sobre a economia do ataque: "O processo de tentar quebrar uma senha usando um desses métodos é totalmente offline, o que significa que um atacante pode levar todo o tempo que precisar."

É aqui que a recomendação de remediação usual para antes da hora. As correções padrão para AS-REP roasting e Kerberoasting — senhas mais longas, group managed service accounts, remover o fallback para RC4 — tornam a quebra mais difícil. Nenhuma delas impede que o material seja coletado. O FAST ataca a etapa de coleta, colocando a troca dentro de um canal que o coletor não consegue ler.

O que o armoring muda estruturalmente é a posição do coletor não autenticado. Quando o KDC está configurado para rejeitar mensagens Kerberos não blindadas, uma AS-REQ produzida por uma ferramenta que não possui um TGT de dispositivo não pode ser blindada e, por isso, é recusada antes que qualquer AS-REP seja retornada. Esse comportamento decorre diretamente da opção documentada "Fail unarmored authentication requests", descrita abaixo.

As configurações de Política de Grupo que ficam desativadas por padrão

Três configurações regem isso, distribuídas em dois nós de Administrative Templates. As três vêm Not Configured de fábrica.

Os caminhos de registro, os nomes amigáveis e as descrições citadas vêm das referências ADMX_kdc e Kerberos do Policy CSP.

As quatro opções do KDC

A configuração do KDC tem quatro opções, e as diferenças não são cosméticas:

Duas consequências merecem um lembrete antes de qualquer pessoa mexer na OU Domain Controllers:

🚨 Perigo: aviso da própria Microsoft sobre a política do KDC — "Quando 'Fail unarmored authentication requests' está definida, os computadores cliente que não suportam Kerberos armoring falharão ao se autenticar no controlador de domínio." Qualquer cliente Kerberos que não consiga blindar — appliances, hosts não Windows, sistemas embarcados, qualquer coisa mais antiga que Windows 8 / Windows Server 2012 — para de se autenticar. Faça o inventário antes de aplicar, não depois.

A segunda: as duas opções estritas simplesmente não fazem nada abaixo do nível funcional de domínio do Windows Server 2012. A Microsoft afirma que ambas as opções "causam falhas intermitentes de autenticação ou de controle de acesso se houver qualquer controlador de domínio que não esteja rodando Windows Server 2012 no domínio. Portanto, nenhuma dessas opções entrará em vigor até que o domínio esteja no nível funcional do Windows Server 2012. Até lá, os controladores de domínio rodando Windows Server 2012 se comportarão como se a opção Supported estivesse configurada." Um domínio que ainda está no nível funcional 2008 R2 pode configurar "Fail unarmored" e obter o comportamento de Supported em vez disso: armoring oferecido aos clientes que o solicitam, nada é imposto.

Detecção

O status do armoring pode ser medido a partir de três ângulos independentes: configuração, telemetria de autenticação ao vivo e eventos de saúde do KDC.

Indicadores que revelam o estado do armoring

A tabela de tipos de pré-autenticação e as orientações de monitoramento vêm da referência da Microsoft para 4768(S, F) A Kerberos authentication ticket (TGT) was requested, que recomenda alertar quando o "valor não for 138 enquanto o Kerberos Armoring estiver habilitado para todas as comunicações Kerberos da organização." Os eventos 33 e 34 e os contadores de desempenho do FAST estão documentados em What's New in Kerberos Authentication.

Verificar se as políticas estão configuradas

Comece pelo estado de configuração. Execute em um controlador de domínio:

# As opções de enforcement exigem nível funcional de domínio Windows Server 2012 ou superior
Get-ADDomain | Select-Object DNSRoot, DomainMode

# Lado do KDC: nenhum retorno significa que a política está Not Configured
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\KDC\Parameters' `
                 -Name EnableCbacAndArmor -ErrorAction SilentlyContinue

Depois o lado do cliente, em uma workstation ou servidor membro:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' `
                 -Name EnableCbacAndArmor, RequireFast -ErrorAction SilentlyContinue

Medir quantos logons estão de fato blindados

A configuração só revela a intenção. Para medir o que realmente acontece, agrupe as requisições de TGT capturadas ao vivo por tipo de pré-autenticação em um controlador de domínio:

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4768 } -MaxEvents 5000 |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        [pscustomobject]@{
            PreAuthType = ($x.Event.EventData.Data |
                Where-Object { $_.GetAttribute('Name') -eq 'PreAuthType' }).'#text'
        }
    } |
    Group-Object PreAuthType |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Selecionar o campo pelo atributo Name em vez de pelo índice posicional importa: a Microsoft lançou uma versão atualizada do Event 4768 com campos adicionais na cumulative update de janeiro de 2025 para Windows Server 2016 e versões posteriores, então as posições dos campos diferem entre as versões do evento.

Para extrair apenas as requisições não blindadas diretamente:

Get-WinEvent -LogName Security -MaxEvents 50 -FilterXPath @"
*[System[EventID=4768] and EventData[Data[@Name='PreAuthType'] != '138']]
"@

Alimente o mesmo fluxo de eventos 4768 no que você já usa para o monitoramento de eventos do Active Directory. A proporção entre o tipo 138 e todo o resto é o único número que mostra o quanto um rollout realmente avançou.

Remediation

O rollout em etapas

Implemente nesta ordem. A orientação da Trimarc sobre a sequência é inequívoca: "Garanta que o Kerberos Armoring seja habilitado primeiro para os clientes… Essa mudança precisa ser aplicada a todos os clientes antes de ser configurada nos controladores de domínio."

1. Confirme o nível funcional do domínio. Get-ADDomain | Select-Object DomainMode precisa reportar Windows Server 2012 ou superior antes que as opções de enforcement façam qualquer coisa. Se ainda estiver abaixo disso, isso vira primeiro um projeto de upgrade do nível funcional.

2. Habilite a política de cliente em todos os clientes. Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring → Enabled. Vincule-a às OUs de workstations e servidores membros, não apenas a um grupo piloto. Verifique se a política de fato foi aplicada — uma GPO mal configurada ou com escopo incorreto é o motivo mais comum para um rollout travar silenciosamente:

gpupdate /force
gpresult /h C:\Temp\kerberos-armoring.html

3. Defina a política do KDC como Supported na OU Domain Controllers. Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring → Enabled, opção Supported. Se um controlador de domínio registrar o evento de sistema 33 depois disso, a resolução documentada pela Microsoft é executar gpupdate /force em um controlador de domínio.

4. Meça antes de impor. Observe os contadores de desempenho KDC AS Requests with FAST e KDC armored TGS Requests, além da distribuição dos tipos de pré-autenticação no 4768. Todo principal que ainda mostra o tipo 2 é um cliente que vai quebrar sob enforcement.

5. Faça o inventário dos clientes que não conseguem blindar. O suporte a armoring começa em clientes Windows 8 e Windows Server 2012. Appliances, hosts Linux e UNIX, dispositivos de rede e stacks Kerberos legados precisam cada um de uma decisão explícita: atualizar, isentar por escopo de OU, ou aceitar que o enforcement vai bloqueá-los.

6. Só então imponha. No lado do KDC, mude para Fail unarmored authentication requests. No lado do cliente, habilite Fail authentication requests when Kerberos armoring is not available. Faça isso um de cada vez, com um plano de rollback, e nunca os dois na mesma janela de mudança.

Capacidade e custo antes de impor

Implante controladores de domínio capazes de armoring em número suficiente para suportar a carga antes de impor. A referência ADMX_kdc avisa que um "número insuficiente de controladores de domínio que suportam essa política resulta em falhas de autenticação sempre que o Dynamic Access Control ou o Kerberos armoring forem exigidos."

Por fim, planeje o custo. A Microsoft é direta na mesma referência ao dizer que "o Kerberos armoring criptografa totalmente as mensagens Kerberos e assina os erros Kerberos, o que aumenta o tempo de processamento, mas não altera o tamanho do ticket de serviço." O inchaço do ticket não é o problema aqui; a CPU do DC é.

Como a EtcSec detecta isso

O catálogo de vulnerabilidades da EtcSec trata esse controle como duas verificações separadas, porque a metade do cliente e a metade do KDC falham de forma independente, e um domínio pode facilmente ter uma sem a outra:

• KERBEROS_ARMORING_DC_DISABLED — Kerberos Armoring (FAST) Not Enforced on DCs
• KERBEROS_ARMORING_CLIENT_DISABLED — Kerberos Armoring (FAST) Not Required on Clients
• ANSSI_R27_KERBEROS_PREAUTH_NOT_FAST — a leitura orientada a compliance do mesmo controle

Essas verificações são correlacionadas com as entradas de superfície de ataque que elas de fato mitigam — ASREP_ROASTING_RISK, KERBEROASTING_RISK e KERBEROS_RC4_FALLBACK —, de modo que um relatório mostra tanto as contas expostas à quebra offline quanto se o controle em nível de protocolo que limita a coleta está ligado. Esse pareamento é o ponto central: uma auditoria que reporta contas vulneráveis a roasting sem reportar o estado do armoring está descrevendo apenas metade do problema. Se você está conduzindo uma revisão mais ampla, esse controle se encaixa naturalmente ao lado do restante de uma auditoria de segurança do Active Directory.