Ataques de Delegacao Kerberos: de Nao Restrita ao Abuso RBCD

O Que Sao os Ataques de Delegacao Kerberos?

Os ataques de delegacao Kerberos exploram recursos legitimos de delegacao do Active Directory que permitem que um servico acesse outro servico em nome de um usuario. A delegacao existe para fluxos reais de aplicacao, como uma camada web que se conecta a uma camada de banco de dados com a identidade do usuario. O problema de seguranca comeca quando o escopo da delegacao e mais amplo do que a aplicacao realmente precisa, ou quando um atacante consegue modificar a relacao de delegacao.

Os tres modelos de delegacao que os defensores normalmente precisam revisar sao:

• Delegacao nao restrita, em que um servico confiavel pode receber material Kerberos delegavel e usa-lo alem de um unico servico backend.
• Delegacao restrita, em que o servico frontend fica limitado a nomes de principal de servico especificos listados no Active Directory.
• Delegacao restrita baseada em recursos (RBCD), em que o recurso de destino controla quais principals podem agir em nome de usuarios perante esse recurso.

Esses modelos nao devem ser tratados como risco equivalente. A delegacao nao restrita costuma ser a prioridade mais alta, porque o comprometimento do host delegado pode expor credenciais delegadas reutilizaveis. A delegacao restrita e o RBCD tambem podem ser perigosos, especialmente quando os servicos permitidos sao amplos demais ou quando permissoes de escrita permitem que um atacante altere os atributos de delegacao.

Como Funciona a Delegacao Kerberos

A delegacao Kerberos estende a autenticacao de servico Kerberos normal. Em um fluxo Kerberos padrao, um usuario obtem um ticket-granting ticket do Key Distribution Center (KDC) e depois solicita tickets de servico para servicos especificos. A delegacao adiciona a capacidade de um servico obter ou usar tickets em nome do usuario para outro servico.

Com a delegacao nao restrita, a conta ou o computador e marcado como confiavel para delegacao. Se um usuario se autentica nesse servico com a delegacao habilitada, o servico pode receber material Kerberos delegavel. Se o host for comprometido, o atacante pode conseguir reutilizar esse acesso delegado. Por isso o Microsoft Defender for Identity trata a delegacao Kerberos nao restrita como um item de avaliacao de seguranca: a configuracao pode expor credenciais privilegiadas quando usuarios sensiveis se autenticam em servicos delegados.

A delegacao restrita reduz o escopo. Em vez de permitir delegacao para qualquer servico, a conta so pode delegar para servicos configurados, representados por valores como msDS-AllowedToDelegateTo. O protocol transition muda o risco novamente, porque o servico pode obter um ticket delegado para um usuario sem que este tenha se autenticado antes via Kerberos nesse servico frontend, quando configurado para usar qualquer protocolo de autenticacao.

O RBCD inverte parte do modelo administrativo. O proprio recurso armazena a lista de principals autorizados a agir em nome de usuarios perante esse recurso em msDS-AllowedToActOnBehalfOfOtherIdentity. Isso torna o RBCD util para alguns cenarios de aplicacao, mas tambem significa que o controle de escrita sobre um objeto de computador pode se tornar um caminho de delegacao.

Pre-Condicoes Que Permitem o Abuso de Delegacao

As configuracoes de delegacao nao sao automaticamente exploraveis por si so. Os casos perigosos costumam combinar varias condicoes:

• um servidor ou conta de servico esta configurado para delegacao nao restrita e e mais facil de comprometer do que os usuarios que se autenticam nele
• usuarios privilegiados ou Domain Controllers se autenticam em sistemas que podem receber credenciais delegadas
• objetos de computador tem ACLs fracas que permitem que principals nao administrativos modifiquem atributos relacionados a delegacao
• contas de servico tem alvos de delegacao restrita amplos demais que ja nao correspondem a necessidade real da aplicacao
• existem entradas RBCD sem owner documentado, dependencia de aplicacao ou processo de expiracao
• Domain Controllers expoem caminhos de coercao que fazem a autenticacao de contas de maquina chegar a sistemas onde o material delegado pode ser capturado ou reutilizado

A conclusao defensiva e pratica: uma revisao de delegacao nao e apenas uma lista de atributos. Ela precisa incluir hardening de hosts, caminhos de logon de contas privilegiadas, ACLs de objetos e ownership de aplicacao.

A Cadeia de Ataque

Um ataque de delegacao normalmente segue uma sequencia, e nao um evento unico.

1. O atacante identifica computadores ou contas de servico configurados para delegacao.
2. O atacante compromete um host delegado, uma conta de servico ou uma identidade com acesso de escrita sobre um objeto de computador.
3. O atacante espera ou induz a autenticacao de uma conta valiosa, ou modifica o RBCD para que um principal controlado pelo atacante possa se passar por usuarios perante um recurso de destino.
4. O atacante reutiliza o acesso delegado resultante para alcancar um servico mais sensivel.
5. Se o caminho alcancar direitos de replicacao de Domain Controller, sistemas Tier-0 ou servicos administrativos privilegiados, o ataque pode se tornar um comprometimento total do dominio.

Para a delegacao nao restrita, os casos mais graves envolvem contas privilegiadas ou contas de maquina de Domain Controller se autenticando em um servidor delegado comprometido. Para o RBCD, a pergunta-chave e outra: quem pode escrever o atributo de delegacao do objeto de computador de destino, e a relacao de confianca resultante corresponde a uma dependencia de aplicacao legitima?

Deteccao

Nenhum evento unico do Windows prova sozinho um ataque de delegacao Kerberos. A deteccao vem da correlacao entre inventario de delegacao, mudancas de objetos, atividade de tickets de servico Kerberos, eventos de logon e telemetria de host.

Sinais do Inventario de Delegacao

Comece pelos dados de configuracao:

• contas ou computadores com delegacao nao restrita habilitada
• contas com TrustedToAuthForDelegation habilitado
• valores msDS-AllowedToDelegateTo preenchidos
• valores msDS-AllowedToActOnBehalfOfOtherIdentity preenchidos
• contas privilegiadas nao marcadas como sensiveis e por isso ainda elegiveis para caminhos de delegacao
• ACLs fracas em objetos de computador que permitem que principals inesperados escrevam atributos relacionados a delegacao

O inventario sozinho nao basta, mas da as deteccoes o contexto de que precisam. Um evento 4769 de ticket de servico e mais significativo quando se sabe que a conta de servico esta configurada para delegacao arriscada.

Eventos do Windows para Correlacionar

O evento 5136 exige a politica de auditoria e a cobertura SACL corretas. A Microsoft documenta que ele e gerado quando um objeto do Active Directory e modificado, mas uma deteccao util depende de manter os detalhes de objeto, atributo e operacao.

Padroes de Deteccao de Alto Sinal

Priorize estas deteccoes antes de escrever regras de anomalia amplas:

• um valor msDS-AllowedToActOnBehalfOfOtherIdentity novo ou alterado em um objeto de computador
• delegacao nao restrita habilitada em um sistema que nao e DC
• uma conta privilegiada se autenticando em um sistema configurado para delegacao nao restrita
• atividade de logon de contas de maquina de Domain Controller para servidores membros inesperados
• mudancas de atributos relacionados a delegacao feitas por contas que nao sao donas da aplicacao
• entradas RBCD em que o principal atuante foi criado recentemente, e raramente usado ou nao esta relacionado ao servico de destino

O alerta deve incluir os dois lados da relacao: a conta ou computador autorizado a delegar, e o servico ou recurso para o qual a delegacao aponta.

Remediacao

Trate a delegacao nao restrita em sistemas que nao sao DC como um achado de alta prioridade. Se uma aplicacao ainda precisa de delegacao, migre para um modelo mais restrito e comprove que a lista de destinos esta correta.

1. Remover a Delegacao Nao Restrita Onde Possivel

Identifique computadores e contas confiaveis para delegacao nao restrita, confirme o ownership da aplicacao e remova a configuracao de sistemas sem uma necessidade de negocio vigente.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
  Select-Object Name, DistinguishedName, TrustedForDelegation

Nao desabilite a delegacao as cegas em servidores de aplicacao de producao sem testar. Algumas aplicacoes legadas podem depender da delegacao para autenticacao de usuario ate o backend. O caminho de remediacao seguro e: inventario, confirmacao do proprietario, staging, mudanca e validacao.

2. Restringir a Delegacao Restrita

Para servicos que ainda precisam de delegacao, restrinja os servicos de destino permitidos ao menor conjunto viavel. Revise os valores de msDS-AllowedToDelegateTo e remova SPNs obsoletos. Se o protocol transition estiver habilitado, verifique se a aplicacao realmente precisa dele e se a conta de servico esta protegida como uma identidade privilegiada.

3. Revisar e Limpar o RBCD

Para o RBCD, revise cada valor msDS-AllowedToActOnBehalfOfOtherIdentity preenchido. Cada entrada deve corresponder a uma dependencia de aplicacao documentada. Se a entrada existe apenas porque uma solucao de problemas a exigiu meses atras, remova-a. Revise tambem quem pode escrever no objeto de computador de destino, porque o controle de escrita costuma ser a vulnerabilidade real.

4. Proteger Contas Privilegiadas da Exposicao por Delegacao

Usuarios privilegiados nao deveriam se autenticar de forma interativa em servidores de confianca menor. Use administracao em camadas, estacoes de trabalho de administracao dedicadas e restricoes de logon para que credenciais Tier 0 nao acabem em hosts delegados. Para contas sensiveis, revise as configuracoes da conta e o modelo operacional que previne exposicao por delegacao.

5. Reduzir a Exposicao a Coercao nos Domain Controllers

Se o servico Print Spooler nao for necessario nos Domain Controllers, desabilita-lo remove um caminho conhecido de autenticacao por conta de maquina usado em cadeias de abuso de delegacao. Trate isso como uma camada de protecao, nao como a unica solucao. O problema raiz continua sendo a delegacao insegura e a exposicao de credenciais.

Validacao Apos a Remediacao

A remediacao de delegacao so esta completa quando voce valida tanto a seguranca quanto o comportamento da aplicacao:

• confirme que sistemas que nao sao DC nao tem mais delegacao nao restrita, a menos que explicitamente aprovada
• confirme que os SPNs de destino restantes da delegacao restrita correspondem ao design da aplicacao
• confirme que as entradas RBCD tem owners documentados e nenhum principal atuante inesperado
• teste o fluxo de aplicacao que antes exigia delegacao
• monitore o evento 5136 para novas escritas de atributos de delegacao apos a limpeza
• monitore logons privilegiados em hosts delegados por pelo menos uma janela de mudanca apos a remediacao
• revise as ACLs de objetos de computador para garantir que atacantes nao possam reconstruir o caminho de delegacao

A pergunta final de validacao e simples: se um atacante comprometer o mesmo servidor de aplicacao amanha, ele ainda conseguiria coletar ou criar acesso delegado para um recurso de maior confianca?

Como o EtcSec Detecta Isso

O EtcSec audita configuracoes de delegacao em computadores e contas de servico a cada scan de AD.

UNCONSTRAINED_DELEGATION identifica sistemas e contas configurados para delegacao nao restrita.

CONSTRAINED_DELEGATION destaca configuracoes de delegacao restrita arriscadas ou amplas demais.

RBCD_ABUSE revela relacoes de delegacao restrita baseada em recursos que merecem revisao porque podem oferecer um caminho de impersonificacao inesperado.

Controles Relacionados

A revisao de delegacao deve ser feita junto com Deteccao prevencao kerberoasting: como identificar e proteger contas de servico expostas a cracking offline, Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin, Monitoramento de Seguranca AD: Os Eventos que Importam, Ma Configuracoes de GPO: Quando a Group Policy Se Torna um Vetor de Ataque e Ataque Golden Ticket — Deteccao & Remediacao. Em ambientes reais, esses caminhos costumam ser encadeados em vez de explorados isoladamente.

Fontes Primarias

• Microsoft Defender for Identity: avaliacao da postura de seguranca de contas (delegacao Kerberos insegura)
• 5136: um objeto do servico de diretorio foi modificado
• 4738: uma conta de usuario foi alterada
• Configurar a auditoria de eventos do Windows para o Microsoft Defender for Identity
• Delegacao restrita Kerberos com o Microsoft Entra ID (application proxy)