# Kerberos Tickets

> Entenda como o Kerberos autentica usuários e serviços no Active Directory através de tickets: TGT, TGS, estrutura, fluxo completo, flags, ciclo de vida e ameaças.

## 📌 Introdução

O **Kerberos** é o protocolo de autenticação padrão no Active Directory. Diferente de sistemas que enviam senhas em texto claro, o Kerberos utiliza **tickets** – mensagens criptografadas que comprovam a identidade do usuário e autorizam o acesso a serviços. Este documento detalha a estrutura, o fluxo de funcionamento e as implicações de segurança dos tickets no contexto do AD.

## 🧩 Arquitetura de Tickets Kerberos

O Kerberos define dois tipos principais de tickets:

| **Ticket**                  | **Sigla** | **Finalidade**                                                                        |
| --------------------------- | --------- | ------------------------------------------------------------------------------------- |
| **Ticket Granting Ticket**  | TGT       | Comprova a autenticação inicial do usuário e permite solicitar tickets para serviços. |
| **Ticket Granting Service** | TGS       | Concede acesso a um serviço específico (ex.: SMB, LDAP, HTTP).                        |

Ambos são gerados pelo **KDC (Key Distribution Center)**, que no AD é o próprio Controlador de Domínio.

### Ticket Granting Ticket (TGT)

* É emitido quando o usuário faz login.
* Possui um tempo de vida típico de **10 horas** (configurável via GPO).
* É criptografado com a chave da conta **KRBTGT** (conta especial do domínio).
* Contém informações como:
  * Nome do usuário.
  * SID (Security Identifier).
  * Endereço IP (opcional).
  * Tempos de validade.

### Ticket Granting Service (TGS)

* É emitido quando o usuário solicita acesso a um serviço específico.
* É criptografado com a chave do serviço de destino (conta de computador ou conta de serviço).
* Contém os mesmos campos do TGT, mas com escopo restrito ao serviço.

## 🔐 Estrutura de um Ticket

Um ticket Kerberos (TGT ou TGS) é composto por duas partes principais:

### 1. Parte criptografada (somente o destinatário pode ler)

| **Campo**           | **Descrição**                                                          |
| ------------------- | ---------------------------------------------------------------------- |
| **Flags**           | Indicadores de políticas (renovável, inicial, etc.).                   |
| **Chave de sessão** | Chave simétrica gerada para a comunicação entre o cliente e o serviço. |
| **Nome do cliente** | Nome do usuário (ex.: `joao.silva`).                                   |
| **Tempo de vida**   | Período de validade do ticket.                                         |
| **Endereços**       | Opcional; lista de endereços IP permitidos.                            |

### 2. Parte não criptografada (cabeçalho)

| **Campo**           | **Descrição**                                                                    |
| ------------------- | -------------------------------------------------------------------------------- |
| **Nome do serviço** | SPN (Service Principal Name) do serviço alvo (ex.: `host/servidor.dominio.com`). |
| **Realm**           | Domínio Kerberos (ex.: `DOMINIO.COM.BR`).                                        |

A criptografia garante que apenas o emissor (KDC) e o destinatário (usuário ou serviço) possam ler o conteúdo. O cliente nunca consegue decifrar a parte criptografada do ticket, mas a utiliza como prova de autenticação.

## 🔄 Fluxo de Autenticação Detalhado

O Kerberos segue um processo de três etapas, representado no diagrama abaixo:

```mermaid
sequenceDiagram
    participant C as Cliente
    participant KDC as KDC (DC)
    participant S as Serviço

    Note over C,KDC: Fase 1: Obtenção do TGT
    C->>KDC: AS-REQ (username, timestamp)
    KDC-->>C: AS-REP (TGT + chave de sessão)

    Note over C,KDC: Fase 2: Obtenção do TGS
    C->>KDC: TGS-REQ (TGT + SPN do serviço)
    KDC-->>C: TGS-REP (TGS + chave de sessão para o serviço)

    Note over C,S: Fase 3: Acesso ao Serviço
    C->>S: AP-REQ (TGS + authenticator)
    S-->>C: AP-REP (opcional, confirmação)
```

{% stepper %}
{% step %}

### Fase 1: Obtenção do TGT (AS-REQ / AS-REP)

1. O cliente envia uma mensagem **AS-REQ** contendo:
   * Nome do usuário.
   * Realm (domínio).
   * Timestamp criptografado com a chave do usuário (derivada da senha).
2. O KDC valida o timestamp com a chave do usuário armazenada.
3. Se válido, o KDC gera:
   * Um **TGT** criptografado com a chave do **KRBTGT**.
   * Uma **chave de sessão** criptografada com a chave do usuário.
4. O cliente recebe o **AS-REP** e decifra a chave de sessão com sua senha, mas **não** consegue decifrar o TGT.
   {% endstep %}

{% step %}

### Fase 2: Obtenção do TGS (TGS-REQ / TGS-REP)

1. O cliente envia uma mensagem **TGS-REQ** contendo:
   * O TGT obtido na fase anterior.
   * O SPN do serviço desejado (ex.: `HTTP/webserver.dominio.com`).
   * Um **authenticator** (timestamp criptografado com a chave de sessão do TGT).
2. O KDC decifra o TGT (com a chave do KRBTGT), valida o authenticator e verifica se o cliente tem permissão para acessar o serviço.
3. Se ok, gera:
   * Um **TGS** criptografado com a chave do serviço alvo.
   * Uma **chave de sessão para o serviço** criptografada com a chave de sessão do TGT.
4. O cliente recebe o **TGS-REP** e decifra a nova chave de sessão.
   {% endstep %}

{% step %}

### Fase 3: Acesso ao Serviço (AP-REQ / AP-REP)

1. O cliente envia ao serviço uma mensagem **AP-REQ** contendo:
   * O TGS.
   * Um novo authenticator (timestamp criptografado com a chave de sessão para o serviço).
2. O serviço decifra o TGS com sua própria chave, extrai a chave de sessão e valida o authenticator.
3. Se tudo estiver correto, o serviço atende à requisição e pode opcionalmente retornar um **AP-REP** confirmando a autenticação.
   {% endstep %}
   {% endstepper %}

## 🚩 Flags de Tickets e Seus Significados

Os tickets possuem um campo de **flags** que definem comportamentos e restrições:

| **Flag**        | **Descrição**                                                               |
| --------------- | --------------------------------------------------------------------------- |
| **INITIAL**     | Indica que o ticket foi emitido via autenticação inicial (não renovado).    |
| **RENEWABLE**   | O ticket pode ser renovado antes de expirar.                                |
| **FORWARDABLE** | Permite que o ticket seja encaminhado a outros serviços (uso em delegação). |
| **PROXIABLE**   | Permite que o ticket seja usado como proxy para acessar outros serviços.    |
| **PREAUTH**     | Exigiu pré-autenticação (segurança adicional).                              |

Essas flags são definidas pelo KDC com base nas políticas de domínio e nas solicitações do cliente.

## ⏳ Ciclo de Vida do Ticket

* **Tempo de vida padrão:** 10 horas para TGT; 10 horas para TGS (configurável via GPO).
* **Renovação:** Se a flag `RENEWABLE` estiver presente, o cliente pode solicitar uma renovação antes do vencimento, obtendo um novo ticket com mesmo tempo de vida.
* **Validação de horário:** O KDC e os serviços rejeitam tickets com timestamps fora de uma janela de tolerância (normalmente 5 minutos).

## 🛡️ Segurança e Ameaças Relacionadas a Tickets

### Ameaças Comuns

| **Ataque**          | **Descrição**                                                                 | **Mitigação**                                                                         |
| ------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| **Golden Ticket**   | Atacante com o hash da conta KRBTGT forja TGTs válidos para qualquer usuário. | Proteger o hash KRBTGT (alterar periodicamente). Usar contas gerenciadas e auditoria. |
| **Silver Ticket**   | Atacante com o hash de um serviço forja TGSs para aquele serviço.             | Proteger hashes de serviços; usar contas de serviço gerenciadas (gMSA).               |
| **Pass-the-Ticket** | Atacante extrai um ticket da memória e o reutiliza em outra máquina.          | Restringir logons interativos; habilitar Credential Guard.                            |
| **Kerberoasting**   | Atacante solicita TGS de contas de serviço e quebra offline a senha.          | Usar senhas longas e complexas para contas de serviço; utilizar gMSA.                 |

### Mitigações Gerais

* **Altere a senha do KRBTGT** regularmente (duas vezes com intervalo) após qualquer suspeita de comprometimento.
* **Habilite a pré-autenticação Kerberos** para todas as contas (desabilite a opção "não exigir pré-autenticação").
* **Use contas de serviço gerenciadas (gMSA)** para que as senhas sejam rotacionadas automaticamente.
* **Monitore eventos de segurança** relacionados a tickets (IDs 4768, 4769, 4770, 4771).

## 🖥️ Comandos para Gerenciar e Visualizar Tickets

### Windows

```powershell
# Listar todos os tickets em cache
klist

# Listar tickets específicos (ex.: TGT)
klist tgt

# Remover todos os tickets
klist purge

# Ver detalhes de um ticket (se disponível)
klist tickets
```

### Linux (com Kerberos instalado)

```bash
# Listar tickets em cache
klist

# Destruir todos os tickets
kdestroy

# Definir arquivo de cache para usar um ticket específico
export KRB5CCNAME=/caminho/para/ticket.ccache
```

## 📚 Conclusão

Os tickets Kerberos são a base da autenticação segura no Active Directory. Compreender sua estrutura, ciclo de vida e as ameaças associadas é essencial para administradores e profissionais de segurança. A implementação de boas práticas – como proteção da conta KRBTGT, uso de gMSA e monitoramento contínuo – reduz drasticamente o risco de ataques baseados em tickets.

## 🔗 Referências

* [Microsoft – Kerberos Authentication Overview](https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview)
* [RFC 4120 – The Kerberos Network Authentication Service (V5)](https://tools.ietf.org/html/rfc4120)
* [MIT Kerberos Documentation](https://web.mit.edu/kerberos/)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xmorte.gitbook.io/bibliadopentestbr/conceitos/ambientes/windows/active-directory-ad/kerberos-tickets.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.