Tentar realizar um ataque Golden Ticket, conhecido, mas muito difícil de executar, passou a fazer parte, nos últimos anos, das avaliações de segurança e cenários de ataques ao vivo das operadoras.
Atores mal-intencionados realizam essa tarefa ignorando o centro de distribuição de chaves Kerberos (KDC) e representando uma conta de controlador de domínio (KRBTGT) para fabricar novos tíquetes de concessão de tíquetes (TGTs) para o Active Directory offline.
Mais tarde, o TGT representado é apresentado ao centro de distribuição de chaves (KDC) para obter um tíquete de serviço com altos privilégios forjados. Embora o patch CVE-2021-42287 tente resolver os ataques Golden Ticket, os invasores ainda podem passar por um usuário se usarem seu SID correspondente. Os privilégios de usuário representados não são relevantes e sua associação ao grupo pode ser forjada.
Atualizações de autenticação – o patch KB5008380 foi apresentado para resolver essa vulnerabilidade. As atualizações, que foram disponibilizadas em novembro de 2021 e serão aplicadas a partir de outubro de 2022, pretendem fornecer proteções adicionais no certificado de atributo privilegiado (PAC) Kerberos com informações adicionais sobre a conta que solicitou o TGT.
Nest post, falaremos detalhadamente sobre o que é PAC, o PAC atualizado e como ele foi projetado para melhorar o processo de autenticação, por que não é uma solução perfeita e como a aplicação influenciará a representação do tíquete e sua detecção.
Os dados do PAC são responsáveis pela autorização do usuário. Ele contém permissões para acessar diferentes serviços. Os dados do PAC são copiados de um tíquete para outro por meio do fluxo de autenticação e autorização Kerberos
Quando um usuário se autentica pela primeira vez com sucesso no centro de distribuição de chaves (AS_REQ), o usuário recebe em resposta (AS_REP) um TGT contendo dados de PAC criptografados do usuário (etapas um e dois no diagrama abaixo). O PAC no TGT contém os dados de autorização – uma lista de associações de usuários.
Posteriormente, quando o usuário solicita ao TGS para acessar serviços específicos (TGS_REQ), o PAC é copiado como está do TGT para o TGS (etapas três e quatro abaixo). Quanto o TGS é usado para acesso (AP_REQ), o serviço verifica o PAC para validar as permissões de acesso do usuário (etapa cinco).
Figura 1: Dados PAC no fluxo Kerberos
Os dados de autorização do PAC residem na estrutura "KERB_VALIDATION_INFO”, na propriedade “Grouplds". Os dados são copiados ao longo do fluxo do TGT para o tíquete TGS para serem usados para acessar o serviço desejado.
A atualização apresenta uma nova estrutura de dados no PAC contendo o identificador de segurança do usuário (SID). O SID é validado pelo KDC (etapa três no diagrama acima). O nome de usuário (“cname”) do tíquete é resolvido para SID e comparado com o novo valor PAC_REQUESTOR
A atualização do PAC é dividida em três fases: implantação inicial, segunda implantação e aplicação.
De acordo com a documentação da Microsoft, o estado do ambiente do Active Directrory pode ser controlado com a chave de registro PACRequestorEnforcement para modificar o comportamento da validação de PAC desejado. Os administradores de sistema preocupados com a segurança agora podem habilitar isso, permitindo que eles planejem melhor o lançamento.
| Valor da chave de registro | Validação de PAC | Novembro 2021: 1ª Implantação |
Julho 2022: 2ª implantação |
Outubro 2022: |
| 0 - desativado | A validação está desabilitada. O PAC antigo pode ser usado |
V | NA | NA |
| 1 - implantação | Tanto o PAC antigo quanto o novo podem ser usados. Se a nova estrutura do PAC for usada, o solicitante será validado | V | Default | NA |
| 2 - execução | A autenticação com PAC antigo é negada. O valor do solicitante do usuário é validade |
V | NA | NA |
Dividir a atualização em três fases significa que as organizações terão tempo suficiente para entender as implicações das mudanças feitas. Depois que o novo PAC for aplicado, todas as contas da organização precisarão se autenticar novamente, tornando os antigos tíquetes Kerberos inúteis, o que pode causar interrupções nos ambientes de produção.
Junto com as atualizações de validação do PAC, novos eventos do sistema também estão disponíveis. Os eventos encontrados como indicativos de ataques baseados em tíquetes são eventos relacionados ao novo campo PAC Requestor.
| EventID | Nome | Descrição |
| 37 | Tíquete sem solicitante | O KDC encontrou o tíquete sem PAC_REQUESTOR ao solicitar tíquete de serviço |
| 38 | Incompatibilidade de solicitante | O PAC_REQUESTOR_SID não corresponde ao que foi resolvido do nome de usuário |
Após esta atualização de segurança, as ferramentas ofensivas também foram atualizadas para oferecer suporte a estruturas de PAC novas e antigas e tiquetes forjados.
No entando, forjar o TGT como o novo PAC, mais o SID do usuário padrão, ou usar o PAC antigo no ambiente atualizado, acionará os novos eventos correspondentes assim que o TGT forjado for usado.
A nova estrutura PAC_REQUESTOR está incluída no novo TGT PAC, e seu valor é validade no KDC na solicitação do TGS. O que isso significa para os atraques do Golden Ticket e o que pode ser detectado pelos novos eventos?
Em um ambiente de implementação, esse evento pode ser um indicador de ataque golden ticket bem-sucedido porque a nova estrutura de PAC não é obrigatória. Depois que o usuário é autenticado pelo controlador de domínio no modo de implantação pela primeira vez, um TGT é concedido usando o novo PAC atualizado que contém a estrutura do solicitante. Portanto, eventos de “tiquete sem solicitante” devem ser identificados como uma primeira indicação de um TGT possivelmente forjado. O evento contém o usuário representado, mas infelizmente não o host do cliente de origem:
Em um ambiente de imposição, o evento indica uma tentativa fracassaa de usar um TGT com um PAC antigo, após o qual o TGT será revogado. Um adversário pode então tentar criar um TGR usando o /newPAC e realizar o ataque Golden Ticket com sucesso. Portanto, é altamente recomendável monitorar outras atividades do usuário e eventos TGS (5769).
A nova estrutura de dados PAC_REQUESTOR contém o SID do usuário. Quanto o TGT é apresentado ao KDC na solicitação TGS (KRB_TGS_REQ), o KDC realiza a validação onde o SID do usuário no PAC_REQUESTOR deve corresponder ao cname na solicitação TGS. Se eles diferirem, o evento do sistema 38 “incompatibilidade do solicitante” é sinalizado.
Tanto em ambientes de implantação quanto de imposição, quando um TGT com um novo PAC é usado para emitir um TGS, o ID do usuário será validado. Tradicionalmente, forjar um TGT sem mencionar explicitamente o ID do usuário resulta em um padrão “500” (uma conta de usuário para o administrador do sistema).
O uso desse tíquete causa um evento de “incompatibilidade de solicitante” e o TGT é revogado. Usar o ID de usuário correspondente correto, com associação forjada de Grouplds de alto privilégio, leva a um ataque de Golden Ticket bem-sucedido. Embora o usuário representado possa não ser membro dos grupos mencionados, essas informações não são validadas.
Na comparação a seguir, podemos ver o PAC original dos usuários comparado ao PAC com incompatibilidade de SID e PAC com SID correspondente:
Figura 10: Usando tíquetes TGT forjados
Um ataque Golden Ticket usando um usuário desconhecido não é mais possível em ambientes de implantação/aplicação com nomes de usuários que não existem no domínio. Em ambientes de implantação e aplicação, o uso de PAC novo ou antigo resultará em um TGT revogado assim que o TGS for solicitado. Nem os eventos de “tíquete sem solicitante” nem de “incompatibilidade de solicitante” são acionados nesse caso.
Avançar para a fiscalização também impedirá o uso bem-sucedido de TGT forjado sem as novas estruturas do PAC.
Para resumir, embora a atualização de segurança do PAC Kerberos não possa impedir totalmente um ataque Golden Ticket, os novos eventos deixam indicadores significativos de comprometimento para os clientes da Varonis a identificar a tentativa de ataque.