Ataque Silver Ticket no AD: detecção e remediação

O que é um ataque Silver Ticket?

Um ataque Silver Ticket consiste em forjar um ticket de serviço Kerberos (TGS) usando o segredo da conta de serviço alvo. A MITRE registra a técnica como T1558.002, Silver Ticket.

O escopo é mais estreito que um Golden Ticket, mas o mecanismo é importante. Um atacante que conhece o hash de senha ou a chave Kerberos de uma conta de serviço pode forjar um ticket para esse serviço e apresentá-lo diretamente ao host que executa o serviço. A MITRE deixa três pontos claros:

o atacante precisa do hash de senha da conta de serviço alvo
o ticket forjado é um ticket de serviço, não um TGT
o ticket pode ser criado sem interagir com o KDC

Esse último ponto explica por que os Silver Ticket continuam valiosos. O atacante não pede ao controlador de domínio que emita o ticket de serviço em tempo real. Ele forja o ticket de serviço offline e depois o apresenta ao serviço alvo.

O escopo deste artigo são ambientes Kerberos do Windows Active Directory. O foco é a cadeia real de pré-requisitos, o comportamento de protocolo que diferencia o ataque de Golden Ticket, e as etapas de hardening de contas de serviço que realmente eliminam a oportunidade.

Como o ataque Silver Ticket funciona

O Kerberos normalmente depende do Key Distribution Center para emitir tickets de serviço depois que um cliente apresenta um TGT válido. Silver Ticket quebra esse fluxo esperado forjando o ticket de serviço diretamente.

A página da MITRE sobre a técnica Silver Ticket afirma que adversários com o hash de senha de uma conta de serviço alvo podem forjar Kerberos ticket granting service tickets, ou seja, tickets de serviço. Diferente de Golden Tickets, esses tickets são limitados a um recurso específico e ao sistema que hospeda esse recurso. Mas diferente de um Golden Ticket, o atacante pode criar o ticket sem interagir com o KDC.

Essa diferença de design traz duas consequências diretas:

o ticket forjado fica limitado a um service principal específico, em vez de todo o domínio
a detecção costuma ser mais difícil porque o caminho normal de emissão pelo controlador de domínio está ausente

Por que o segredo da conta de serviço importa

Silver Ticket funciona porque o atacante conhece a chave usada pela conta de serviço alvo. Esse segredo pode vir de:

credential dumping direto após uma comprometimento
extração do hash de senha de uma conta de serviço em um servidor onde o serviço roda
Kerberoasting Explicado — Deteccao & Prevencao, que a MITRE cita explicitamente como um caminho para obter o hash alvo

Se o atacante não conseguir obter o segredo do serviço alvo, não consegue forjar um Silver Ticket útil para esse serviço.

Por que alguns tickets forjados ainda alcançam o caminho do serviço

A documentação Microsoft sobre Kerberos mostra que o tratamento da PAC depende do modelo de aplicação e das premissas de confiança. Em particular, a Microsoft observa que a validação PAC pode ser opcional para uma aplicação autocontida.

Essa nuance importa, mas não deve ser exagerada. O pré-requisito central de Silver Ticket continua sendo a posse do segredo da conta de serviço alvo e um caminho de serviço alvo disposto a aceitar o ticket apresentado. O comportamento da PAC é uma parte do modelo de processamento do lado do serviço, não uma explicação completa para todo caso bem-sucedido de ticket forjado.

Silver Ticket vs. Golden Ticket, Kerberoasting e Pass-the-Ticket

Esses termos são frequentemente misturados. Não deveriam ser.

Silver Ticket: ticket de serviço forjado para um serviço específico após obter o segredo da conta de serviço
Golden Ticket: TGT forjado a partir do segredo krbtgt, com um impacto muito mais amplo em todo o domínio. Veja Ataque Golden Ticket — Deteccao & Remediacao
Kerberoasting: solicitar tickets de serviço legítimos ao KDC e quebrá-los offline para recuperar segredos de contas de serviço. Veja Kerberoasting Explicado — Deteccao & Prevencao
Pass-the-Ticket: reproduzir ou reutilizar um ticket Kerberos real que foi roubado em vez de forjado

Silver Ticket geralmente aparece depois de outro ataque pré-requisito. Kerberoasting ou credential dumping obtém o segredo da conta de serviço. Silver Ticket transforma esse segredo em acesso não autorizado ao serviço.

Por que Silver Ticket ainda importa

Silver Ticket é menos famoso que Golden Ticket, mas continua importante porque atinge uma fraqueza comum nas empresas: segredos de contas de serviço mal gerenciados.

Contas de serviço costumam ser mais amplas e mais antigas do que as equipes imaginam

Contas de serviço tendem a sobreviver por anos, sustentar múltiplas aplicações e acumular SPNs, direitos locais e exceções operacionais. Isso cria exatamente o tipo de segredo de longa duração que um atacante procura.

O ataque é mais silencioso que um fluxo de serviço normal emitido pelo KDC

A MITRE destaca diretamente o problema de detecção mais importante: Silver Tickets forjados podem ser criados sem interação com o KDC. Isso significa que parte da visibilidade normal do controlador de domínio, na qual os defensores confiam, está ausente desde o momento em que o ticket é forjado.

A higiene fraca de contas de serviço ainda existe

A orientação da Microsoft sobre contas de serviço gerenciadas existe porque a gestão manual de senhas de serviço é propensa a erros. Uma conta de usuário comum usada para executar um serviço continua sendo um dos lugares mais fáceis para acumular chaves antigas, rotação fraca e configurações de criptografia inconsistentes.

A criptografia Kerberos legacy continua aumentando o risco

A Microsoft já foi além de simplesmente eliminar gradualmente o RC4. No âmbito do rollout da CVE-2026-20833, atualizações a partir de 13 de janeiro de 2026 adicionaram eventos de auditoria, atualizações a partir de 14 de abril de 2026 alteraram o padrão do KDC para DefaultDomainSupportedEncTypes para AES-SHA1 apenas (0x18), e atualizações lançadas a partir de julho de 2026 removeram a subchave de registro RC4DefaultDisablementPhase que permitia reversão. Um controlador de domínio sem configuração explícita agora assume apenas AES. Isso é relevante porque contas de serviço com postura de criptografia antiga costumam ser as mesmas contas que permanecem mal geridas operacionalmente, e são elas que quebram ou mantêm silenciosamente uma chave RC4 assim que o padrão muda.

Pré-requisitos para um ataque Silver Ticket bem-sucedido

Silver Ticket não é um truque Kerberos de um clique só. Várias condições precisam se alinhar.

1. O atacante precisa obter o segredo da conta de serviço alvo

Esse é o pré-requisito não negociável. A MITRE afirma explicitamente que é necessário o hash de senha da conta de serviço alvo. Os caminhos comuns de aquisição são credential dumping e Kerberoasting.

2. O serviço alvo precisa depender desse service principal

O ticket forjado precisa corresponder a uma identidade de serviço real aceita pelo host. Por isso o escopo é menor que o de Golden Ticket.

3. O ticket forjado precisa ser aceito pelo caminho de serviço visado

A documentação Microsoft sobre PAC explica por que o processamento do lado do serviço pode variar conforme o design da aplicação. Essa nuance é útil para entender o protocolo, mas não elimina a necessidade de o atacante mirar o service principal correto com o segredo correto.

4. A conta de serviço precisa ter valor suficiente para importar

Um ticket forjado para um serviço de baixo valor ainda é um problema, mas a preocupação real é uma conta de serviço ligada a uma aplicação sensível, um workflow administrativo ou um host privilegiado.

5. O ambiente ainda apresenta higiene fraca de contas de serviço

Contas de serviço baseadas em usuário e de longa duração, ausência de adoção de gMSA, rotação fraca, contas de serviço superprivilegiadas ou chaves antigas dependentes apenas de RC4 tornam os pré-requisitos de Silver Ticket mais realistas do que deveriam ser.

A cadeia de ataque

Uma cadeia prática de intrusão Silver Ticket geralmente se parece com isto.

Etapa 1 - Identificar uma conta de serviço que valha a pena atacar

O atacante mapeia SPNs, serviços e sistemas para encontrar um service principal que daria acesso útil se comprometido.

Etapa 2 - Obter o hash ou a chave da conta de serviço

O atacante obtém o segredo por dumping, quebra offline após Kerberoasting ou outro caminho de acesso a credenciais.

Etapa 3 - Forjar o ticket de serviço offline

Usando o segredo do serviço, o atacante cria um ticket de serviço Kerberos para o service principal escolhido.

Etapa 4 - Apresentar o ticket forjado diretamente ao serviço

É aqui que Silver Ticket diverge do caminho Kerberos normal. A MITRE indica que o ticket forjado pode ser usado sem interação com o KDC.

Etapa 5 - Usar o acesso resultante dentro do escopo do serviço

O acesso é mais estreito que o de Golden Ticket, mas ainda pode ser sério operacionalmente se o serviço roda em um host sensível, expõe funções administrativas ou permite movimento lateral.

Por isso Silver Ticket pertence à mesma revisão de Caminhos de Ataque AD: Ma Configuracoes em Cadeia. Mesmo um ticket de serviço limitado pode se tornar parte de uma cadeia muito maior.

Detecção

Detectar Silver Ticket é difícil por um motivo simples: o atacante pode nunca pedir ao KDC o ticket de serviço que usa.

O modelo correto é, portanto, detecção de anomalias mais detecção de pré-requisitos, não um único Event ID que prove o caso magicamente.

Procurar uso de ticket de serviço que não bate com a atividade esperada do KDC

A estratégia de detecção da MITRE para Silver Ticket (DET0241) descreve uma das melhores abordagens de alto nível: procurar atividade anômala de tickets de serviço Kerberos, incluindo campos malformados em eventos de logon e solicitações TGS sem interação com o KDC.

Operacionalmente, isso significa investigar casos em que:

uma conta de serviço é usada em um host ou recurso fora do seu escopo normal
o serviço alvo vê atividade autenticada por Kerberos que não bate de forma limpa com os padrões esperados de emissão de tickets de serviço pelo KDC
campos malformados ou incomuns aparecem em dados de logon ou de processamento de tickets

Essa não é uma regra trivial de implementar. Depende de ter uma baseline de quais hosts e recursos cada conta de serviço deveria de fato tocar.

Monitorar os ataques pré-requisito, não apenas o ticket forjado em si

A estratégia de detecção da MITRE também aponta diretamente acesso suspeito ao LSASS e credential dumping como fontes de dados úteis. Isso é relevante porque o segredo da conta de serviço geralmente precisa ser roubado antes de o Silver Ticket existir.

Se você já monitora:

acesso suspeito ao LSASS
comportamento de credential dumping
Kerberoasting Explicado — Deteccao & Prevencao
padrões incomuns de autenticação de contas de serviço

então você está muito mais perto de detectar a cadeia de ataque real do que se procurasse apenas um único indicador final de ticket forjado.

Usar o contexto de eventos Kerberos com cautela

A orientação Microsoft sobre Kerberos e o evento 4769 continua útil porque documenta que uma solicitação normal de ticket de serviço é visível no KDC como um evento de ticket de serviço. Isso torna 4769 um contexto valioso para atividade Kerberos normal.

Para investigações de Silver Ticket, o ponto não é alertar de forma abstrata quando 4769 está ausente. O ponto é entender que um ticket de serviço forjado pode não seguir o mesmo caminho de emissão do KDC que um ticket de serviço legítimo. Qualquer detecção baseada nessa ideia precisa de contexto de baseline, não de uma regra simplista de evento único.

Observar contas de serviço fora do seu raio de ação esperado

A estratégia de detecção da MITRE para Silver Ticket cita especificamente tentativas de acesso usando contas de serviço fora de hosts ou recursos esperados. Essa é uma das detecções mais úteis operacionalmente porque é compreensível para os defensores e está ligada ao escopo real da conta de serviço.

Correlacionar com atividade privilegiada posterior

Se o ticket forjado alcança um serviço com impacto administrativo, os próximos sinais podem aparecer como:

acesso incomum a funções administrativas da aplicação alvo
logons no host do serviço vindos de identidades que não deveriam estar presentes ali
ações privilegiadas downstream após o ticket ser aceito
anomalias ao redor já cobertas em Monitoramento de Seguranca AD: Os Eventos que Importam

Remediação

A mitigação de Silver Ticket é principalmente higiene de contas de serviço. Se o atacante não consegue obter um segredo de conta de serviço reutilizável, não consegue forjar o ticket.

1. Migrar serviços elegíveis para gMSAs

A orientação da Microsoft sobre group Managed Service Accounts é a mitigação de fonte primária mais clara aqui.

A Microsoft documenta que os gMSAs:

deixam o Windows cuidar do gerenciamento de senhas para contas de serviço
alteram periodicamente as chaves usadas pela conta
permitem que hosts membros obtenham os valores de senha atual e anterior a partir do controlador de domínio
reduzem a necessidade de administradores gerenciarem a sincronização de senhas manualmente

Isso ataca diretamente um dos maiores pré-requisitos de Silver Ticket: segredos de contas de serviço estáticos ou mal gerenciados.

2. Configurar suporte a AES para contas de serviço gerenciadas

A documentação Microsoft sobre gMSA é explícita: contas de serviço gerenciadas dependem dos tipos de criptografia Kerberos suportados, e você deve sempre configurar AES para MSAs. O controlador de domínio lê o atributo msDS-SupportedEncryptionTypes da conta para decidir o que o servidor suporta, e quando esse atributo não está definido, ele trata a conta como se não suportasse os tipos mais fortes. Então, se você endureceu o host para recusar RC4 enquanto o atributo continua indefinido, a autenticação sempre falha. É exatamente por isso que a postura de criptografia precisa ser explícita, e não presumida.

3. Redefinir senhas antigas de contas de serviço para gerar chaves AES

A orientação da Microsoft sobre remediação de RC4 no Kerberos explica que contas criadas antes do suporte a AES podem estar sem chaves AES se suas senhas nunca foram redefinidas após a adição do suporte a AES. A Microsoft é explícita ao afirmar que alterar a senha da conta gera essas chaves.

Isso importa porque muitas contas de serviço legacy são antigas o suficiente para carregar exatamente esse problema.

4. Eliminar a dependência restante de RC4

Isso não é mais opcional do lado da Microsoft: desde as atualizações de julho de 2026, o KDC assume apenas AES-SHA1 quando nenhum tipo de criptografia explícito está configurado, e a subchave de registro de reversão temporária deixou de existir. A orientação da Microsoft sobre RC4 fornece as etapas de auditoria e remediação para encontrar contas que ainda o utilizam, incluindo os scripts List-AccountKeys.ps1 e Get-KerbEncryptionUsage.ps1 e os eventos 4768 e 4769. Isso não torna o Silver Ticket impossível por si só, mas remove mais uma fraqueza legacy do tratamento Kerberos das contas de serviço e melhora a baseline geral do Kerberos. Também complementa diretamente AS-REP Roasting: Coletando Hashes Sem Credenciais e outros trabalhos de hardening Kerberos.

5. Minimizar privilégio e escopo das contas de serviço

Um ticket forjado só é tão útil quanto a conta de serviço por trás dele. Mesmo que a conta de serviço precise existir, ela não deveria carregar também direitos de administrador local desnecessários, participação em grupos privilegiados ou acesso amplo a sistemas não relacionados.

6. Inventariar SPNs e a propriedade das contas de serviço

Você não pode defender segredos de contas de serviço que não entende. Um programa de hardening de verdade deveria saber:

quais SPNs correspondem a quais contas
quais hosts devem usar essas contas
quem é responsável operacionalmente por cada conta de serviço
se a conta pode migrar para gMSA
se a conta ainda depende de RC4 ou de configurações legacy

Por isso Auditar a segurança do Active Directory: checklist prática pertence ao lado deste tema. Se você está escalando essa revisão por todo o parque, Comparação de ferramentas de auditoria AD também é relevante.

7. Tratar credential dumping e Kerberoasting como precursores diretos de Silver Ticket

Se um atacante consegue dumpar ou quebrar offline o segredo de uma conta de serviço, o caminho Silver Ticket está aberto. Por isso este artigo deve ser lido junto com Kerberoasting Explicado — Deteccao & Prevencao, Ataques Delegacao Kerberos: Nao Restrita a RBCD e Ataque Golden Ticket — Deteccao & Remediacao.

Validação após o hardening

Não encerre o risco de Silver Ticket só porque você trocou uma senha uma vez. Valide o modelo de contas de serviço diretamente.

confirmar quais service principals ainda usam contas de usuário tradicionais em vez de gMSAs
verificar se cada conta de serviço tem chaves AES e se RC4 ainda está em uso
verificar msDS-SupportedEncryptionTypes onde for relevante e comparar com o uso Kerberos real observado nos controladores de domínio
revisar os dados do evento 4769 nos KDCs para entender quais contas de serviço ainda solicitam tickets de serviço e com quais tipos de criptografia
verificar que serviços sensíveis não dependem de identidades de serviço obsoletas, compartilhadas ou não documentadas
confirmar que as contas de serviço não recebem privilégios mais amplos do que o serviço realmente precisa

O verdadeiro critério de sucesso não é apenas uma política Kerberos melhor. É que comprometer uma conta de serviço não entregue mais um segredo estável e reutilizável com amplo valor operacional.

Como a EtcSec detecta exposição relacionada

Não existe um vulnerability type exato para Silver Ticket no catálogo atual, então os achados mais úteis são os pré-requisitos e as fraquezas Kerberos ao redor que tornam a técnica prática.

Os achados mais relevantes são:

KERBEROASTING_RISK, porque a recuperação offline de um segredo de conta de serviço é um dos precursores mais claros de Silver Ticket
KERBEROS_RC4_FALLBACK, porque a postura de criptografia Kerberos legacy frequentemente se sobrepõe à mesma população de contas de serviço mal gerenciadas
contas de serviço privilegiadas ou com escopo excessivo, que tornam um ticket de serviço forjado muito mais danoso
condições de attack path ao redor já capturadas em Caminhos de Ataque AD: Ma Configuracoes em Cadeia

Esse é o modelo mental correto: Silver Ticket é uma técnica de ticket forjado, mas a superfície real de correção é a higiene de contas de serviço.

Controles relacionados

Se você está revisando o risco de Silver Ticket, revise também Ataque Golden Ticket — Deteccao & Remediacao, Kerberoasting Explicado — Deteccao & Prevencao, AS-REP Roasting: Coletando Hashes Sem Credenciais, Ataques Delegacao Kerberos: Nao Restrita a RBCD, Monitoramento de Seguranca AD: Os Eventos que Importam, Caminhos de Ataque AD: Ma Configuracoes em Cadeia, Auditar a segurança do Active Directory: checklist prática e Comparação de ferramentas de auditoria AD.