Tickets Kerberos em contas desativadas: validade e contenção

Tickets Kerberos em contas desativadas: por que as sessões persistem

A validade dos tickets Kerberos em contas desativadas é importante porque alterar o estado de uma conta não cancela automaticamente os tickets já emitidos para ela. A Microsoft documenta que tickets de serviço válidos, emitidos antes da desativação, ainda podem permitir acesso. Quem responde ao incidente precisa, portanto, de evidências sobre a conta, os tickets e os recursos que os aceitam, em vez de tratar a desativação como prova de contenção concluída. Microsoft Learn: user ticket lifetime

Há um segundo limite: uma conexão autenticada pode durar mais do que o ticket usado para estabelecê-la. A Microsoft explica que os tickets de serviço autenticam novas conexões; a expiração não interrompe operações em andamento numa conexão já autenticada. Esperar pelo horário de término do ticket é, portanto, uma evidência insuficiente de que o acesso cessou. Microsoft Learn: service ticket lifetime

Considere uma investigação com três perguntas separadas. A identidade pode obter outro ticket? Um ticket já existente pode autenticar outra conexão? Uma conexão autenticada anteriormente ainda está em operação? Essas são perguntas investigativas derivadas dos limites documentados, e não três etapas pelas quais todo incidente passa. Mantenha-as separadas no registro do incidente para que evidências sobre uma não encerrem acidentalmente as outras.

Este guia aborda tickets legítimos já emitidos, incluindo o problema de contenção quando esse material foi roubado. Para a ameaça distinta de TGTs falsificados a partir de um segredo krbtgt comprometido, consulte o ataque Golden Ticket e seu pré-requisito de krbtgt. Para as diferenças entre falsificar um ticket de serviço e reutilizar um ticket roubado, veja a comparação de Silver Ticket com Pass-the-Ticket e a comparação de Pass-the-Hash, Overpass-the-Hash e Pass-the-Ticket. Os procedimentos de ataque desses artigos são separados das decisões sobre validade e contenção apresentadas aqui.

Os três relógios: TGT, ticket de serviço e conexão estabelecida

O ticket-granting ticket, ou TGT, é usado para obter outros tickets Kerberos. O ticket de serviço é apresentado a um serviço específico. A conexão estabelecida passa então a ter sua própria duração, que a política de tickets de serviço não define. Mantenha separados os dois relógios dos tickets e o relógio da conexão; a janela de renovação é um limite adicional para TGTs renováveis. Microsoft Learn: service ticket lifetime, RFC 4120 §2.3

Os valores abaixo são os padrões documentados pela Microsoft, e não medições do seu domínio. As chaves e unidades são especificadas em MS-GPSB §2.2.2, Kerberos Policy.

Converta horas e minutos antes de comparar os valores. O MS-GPSB identifica MaxTicketAge como o limite superior correspondente de MaxServiceAge; a página do Learn sobre tickets de serviço contém um erro de digitação que compara o valor consigo mesmo e não deve virar uma regra operacional. A configuração de cinco minutos de desvio é uma tolerância, e não um atraso de contenção garantido. MS-GPSB, Microsoft Learn: clock synchronization tolerance

Sete dias de renovação não significam que cada TGT permaneça continuamente válido durante sete dias. Um ticket renovável tem uma expiração individual e um limite final de renovação. Reduzir essa janela também afeta a disponibilidade para usuários que não conseguem acessar frequentemente um controlador de domínio. Microsoft Learn: user ticket renewal, RFC 4120 §2.3

As verificações de conta limitam novos tickets sem cancelar automaticamente os já emitidos

O Windows realiza verificações de conta durante as solicitações de tickets. MS-KILE §5.1.3 exige que os KDCs do domínio da conta verifiquem a conta quando o TGT apresentado tiver mais de 20 minutos. MS-KILE §3.3.5.7.1 fornece as condições: a validação da política de conta deve estar habilitada, e o KDC deve pertencer ao domínio da conta do usuário. Um KDC de outro domínio não pode realizar essa verificação. Uma conta desativada é rejeitada com KDC_ERR_CLIENT_REVOKED nessas condições.

Trata-se do processamento de uma solicitação, e não de um temporizador que desconecta todas as sessões no minuto 20. Isso limita a emissão posterior de TGS e não revoga um ticket de serviço já obtido. As solicitações de TGT também têm verificações documentadas de política de conta, incluindo a rejeição de contas desativadas quando a opção de validação está habilitada. MS-KILE §3.3.5.6.3

O protocolo também descreve um mecanismo de revogação. A RFC 4120 §3.3.3.1 especifica uma hot-list verificada no ticket-granting service, impedindo que tickets cancelados obtenham tickets adicionais. Ela distingue esse caso dos tickets normais já obtidos, que permanecem válidos até sua expiração habitual. Essa especificação não estabelece um comando universal de administração do Windows para revogar globalmente os tickets de um usuário. RFC 4120 §3.3.3.1

Alterar a senha do usuário não substitui automaticamente as chaves de sessão e os tickets já existentes. Essa é uma inferência criptográfica a partir da troca TGS: o TGT é processado com a chave do ticket-granting service, e a resposta usa uma chave de sessão em vez do segredo de longo prazo do cliente. Isso não é uma promessa de que toda autenticação futura terá sucesso após uma redefinição. RFC 4120 §§3.3.2–3.3.3

A remoção de grupos tem outro limite. Os SIDs dos grupos globais e universais entram no PAC durante a emissão inicial do TGT e são copiados para os TGTs renovados. A renovação, por si só, não garante que a associação a grupos seja atualizada. Os grupos locais do domínio do recurso são adicionados durante a emissão do ticket de serviço; não generalize que todos os grupos ficam fixados no primeiro TGT. MS-PAC §4.1.2.1, MS-KILE §3.3.5.7.3

Detecção

1. Construir uma linha do tempo entre os logs da conta, do KDC e do destino

Use os eventos documentados do Windows abaixo como fontes de evidência. A estratégia de correlação é uma recomendação analítica baseada nos campos desses eventos e nos limites do protocolo apresentados acima; não se afirma nenhum resultado de laboratório ou de detecção em produção.

O evento 4768 não cobre todas as falhas de TGT: a Microsoft documenta que os códigos de resultado 0x10 e 0x18 geram o evento 4771 em seu lugar. Inclua essas falhas de pré-autenticação ao revisar solicitações malsucedidas. Microsoft Learn: 4768 coverage

Use como referência do incidente o alvo do evento 4725, e não o administrador que o desativou. Mapeie essa identidade para nomes normalizados nos eventos Kerberos: o 4769 não fornece o mesmo campo de SID do usuário-alvo que o 4725. Preserve o evento bruto e a decisão de mapeamento. Use o host de destino com seu identificador de logon ao relacionar 4624 e 4634; a Microsoft documenta que os IDs de logon são únicos apenas entre reinicializações no mesmo computador. 4725 field definitions, 4769 field definitions, 4634 correlation limits

Priorize solicitações de tickets bem-sucedidas ou novos logons no destino após a desativação, hosts de origem inesperados e atividade contínua em conexões conhecidas. Revise o KDC do domínio da conta, a configuração de validação, a idade do TGT e a cronologia do incidente antes de interpretar uma solicitação posterior de TGS bem-sucedida. Essas são pistas de investigação derivadas do KILE, e não provas automáticas de roubo de tickets. Eventos ausentes deixam uma lacuna de visibilidade; não demonstram que uma conexão terminou. Confirme a linha do tempo com o inventário atual de conexões do responsável pelo recurso e com a trilha de auditoria da aplicação.

2. Medir a política nos controladores de domínio relevantes

Os exemplos abaixo foram adaptados da documentação e não são comandos executados num ambiente AD. Use um contexto autorizado, as ferramentas/módulos necessários e um diretório de relatórios existente com permissão de escrita. O exemplo local de gpresult tem como alvo o DC no qual é executado. Leia as configurações de Kerberos Policy no relatório juntamente com o contexto das GPOs aplicadas. Microsoft Learn: gpresult

gpresult /scope computer /h C:\Temp\Kerberos-RSoP.html

Examine as configurações da Default Domain Policy com o relatório abaixo. Seu GUID conhecido também é a chave de busca da função auxiliar do coletor em helpers/gpo_policy.go:11. Um relatório de uma única GPO não demonstra, por si só, a política efetiva em todos os DCs. Microsoft Learn: Get-GPOReport

Get-GPOReport -Guid 31B2F340-016D-11D2-945F-00C04FB984F9 -ReportType XML

Examine outras GPOs, incluindo seus vínculos e filtros, com um relatório separado. Se o contexto atual não for adequado, selecione o domínio e o servidor reais usando os parâmetros documentados. Get-GPOReport

Get-GPOReport -All -ReportType XML

Get-ADDefaultDomainPasswordPolicy não lê a política Kerberos. Sua saída é o objeto da política de senhas padrão do domínio; não a use para afirmar que MaxTicketAge ou MaxRenewAge foram verificados. Microsoft Learn: Get-ADDefaultDomainPasswordPolicy

3. Examinar os tickets realmente presentes nos hosts do escopo

Os exemplos separados abaixo vêm de Microsoft Learn: klist. Leia o cache da sessão atual:

klist

Examine seu TGT, incluindo o horário de término e o limite de renovação:

klist tgt

Enumere as sessões de logon locais antes de presumir que o cache do usuário atual cobre o host:

klist sessions

Selecione uma sessão de logon com -li, que especifica a parte baixa de seu LUID; use também -lh se a parte alta for diferente de zero. 0x3e7 é o exemplo documentado pela Microsoft:

klist -li 0x3e7

Registre o host, a sessão, o horário da coleta e os horários dos tickets. Essas observações cobrem o cache selecionado, e não cópias de tickets em outro sistema. Preserve esse perímetro no registro da resposta.

Medidas de correção (Remediation)

1. Reduzir durações excessivas antes de um incidente

A orientação da Microsoft para tickets de usuário propõe 4–10 horas, com solicitações mais frequentes aumentando a carga do KDC. Teste o valor escolhido nos fluxos de trabalho legítimos. Configure os parâmetros Kerberos do domínio em Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy. Microsoft Learn: user ticket lifetime

Para uma preparação direcionada a contas privilegiadas, revise as políticas de autenticação e silos para TGTs de Tier 0 mais curtos e restrições de dispositivos. Mantenha essa decisão de implantação separada da limpeza emergencial de caches.

Reduzir uma duração numa GPO não é uma limpeza retroativa de tickets. Essa é uma inferência a partir dos horários de validade contidos nos próprios tickets e das operações de cache local documentadas acima. Aplique a alteração e verifique os tickets recém-emitidos; preserve separadamente as evidências sobre tickets existentes. RFC 4120, klist

2. Conter a identidade e os recursos durante o incidente

Desative e redefina a identidade afetada conforme necessário para autenticações futuras; em seguida, isole os hosts comprometidos e inventarie as conexões que envolvem essa identidade. O isolamento e o encerramento no lado do recurso são recomendações operacionais inferidas da sobrevivência documentada de conexões autenticadas, e não um procedimento universal de recuperação da Microsoft. Atribua um responsável a cada host e serviço afetado e registre qual caminho de acesso cada ação cobre. MS-KILE TGT account checks, Microsoft Learn: service ticket lifetime

Num host sob seu controle, remova os tickets da sessão atual com este comando documentado:

klist purge

Para uma sessão selecionada, o exemplo da Microsoft é uma operação separada:

klist purge -li 0x3e7

Sem um seletor de LUID, a limpeza se aplica à sessão atualmente conectada. Ela não alcança outros caches nem tickets copiados para outros locais. Feche as conexões relevantes e organize a reautenticação como parte da resposta. A limpeza, por si só, não prova que todas as conexões das aplicações terminaram. klist, service-ticket connection boundary

O operador responsável pode optar por reiniciar um host ou serviço para encerrar contextos locais quando não for possível controlar sessões individuais. Trate isso como uma decisão operacional local, e não como revogação em todo o domínio ou prova de erradicação. Nenhum comando universal de reinicialização é prescrito aqui.

3. Reservar a recuperação de krbtgt para o comprometimento desse segredo

A desativação comum de um usuário não é motivo para rotacionar krbtgt duas vezes. Se esse segredo estiver comprometido, siga o planejamento de recuperação do domínio. O procedimento de recuperação de floresta da Microsoft exige duas redefinições porque o histórico de senhas mantém duas senhas. Aguarde 10 horas entre as redefinições com os valores padrão; se as durações máximas tiverem sido alteradas, a espera mínima deve ser maior do que a duração configurada. Verifique a replicação e o escopo dos DCs antes de agendar a segunda operação. O procedimento citado se aplica a DCs graváveis, e não a contas krbtgt_number de RODCs. Microsoft Learn: reset the krbtgt password

Não deduza que essas redefinições destroem todos os tickets de serviço emitidos ou todas as conexões existentes. Suas chaves de serviço e seus contextos estabelecidos são limites separados. Valide independentemente novas tentativas de acesso, caches locais e conexões abertas anteriormente; registre os resultados reais quando a equipe de resposta realizar essas verificações. RFC 4120 §3.3, Microsoft Learn: service ticket lifetime

Como o EtcSec detecta isso

O etc-collector do EtcSec identifica durações configuradas excessivas por meio de três IDs reais de detectores. As afirmações abaixo vêm da inspeção estática de suas implementações Detect(), e não de uma execução de auditoria no domínio de um cliente. Os caminhos abaixo são relativos a public/internal/audit/detectors/ad/ no código-fonte do coletor.

As comparações são estritas: 10 horas e 7 dias não acionam esses achados. A verificação agregada se sobrepõe às duas verificações especializadas; são duas verificações de duração e uma agregada, e não três capacidades independentes de contenção. Elas não detectam roubo de tickets, não encerram sessões e não implementam a revogação de tickets de usuário.

As entradas principais são configurações Kerberos extraídas do GptTmpl.inf do SYSVOL em public/internal/providers/smb/gptmpl_parser.go:221–227. A função auxiliar public/internal/audit/helpers/gpo_policy.go:42–54 prefere a Default Domain Policy e, depois, outra GPO disponível com configurações Kerberos. Ela não calcula a precedência completa do RSoP. Compare o achado com a política efetiva do DC relevante e com os tickets observados antes de declarar a correção concluída.

Os detectores especializados selecionam valores positivos e contêm mecanismos de fallback para DomainInfo. MaxTicketAge=0, apesar do significado de ausência de expiração documentado pela Microsoft, não é sinalizado pela comparação de duração. Entradas ausentes ou iguais a zero também podem deixar Count=0. A verificação agregada retorna imediatamente Count=0 quando DomainInfo é nil, mesmo que existam dados de política do SYSVOL (weak-kerberos-policy.go:25–33). Seus detalhes dependem de IncludeDetails. Nenhuma dessas três comparações verifica a validade de tickets de serviço, o desvio de horário ou a flag de validação de conta.

O registro final da resposta deve relacionar as durações configuradas com evidências dos caches de tickets, resultados das solicitações ao KDC e verificações de conexões no lado dos recursos. Essas são as evidências necessárias para distinguir uma política corrigida de um acesso que realmente terminou.