Como mitigar ataques Golden Ticket com PAC (Privileged Attribute Certificate)

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. 

Insira as proteções do PAC contra o Golden Ticket

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. 

O que é um certificado de atributo privilegiado (PAC)

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. 

Figura 2: Estrutura KERB_VALIDATION_INFO descriptografada do PAC de um usuário de domínio. 

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 

Figura 3: PAC_REQUESTOR descriptografado do PAC de um usuário de domínio 

PACRequestorEnforcement: fases de lançamento e eventos

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.

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. 

/newPAC ou /oldPAC?

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. 

Figura 4: Mimikatz – Solicitação pull, suportando a nova estrutura PAC por padrão. 

Figura 5: Rubeus – bandeira que suporta a estrutura atualizada do PAC 

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. 

PAC_REQUESTOR na prática

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? 

“Tiquete sem solicitante” -  um TGT sem a nova estrutura PAC_REQUESTOR usada.

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: 

Figura 6: Evento do sistema 37 “tiquete sem solicitante” 

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). 

“Incompatibilidade do solicitante” – O SID do usuário não corresponde ao nome de usuário no TGT.

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. 

Figura 7: Evento do sistema 38 “incompatigilidade do solicitante” 

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). 

Figura 8: Mimikatz – valor padrão do ID do usuário 

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 9: Comparação entre o PAC original do usuário do domínio com versões forjadas do PAC do usuário no TGT 

Todos os cenários possíveis   

Figura 10: Usando tíquetes TGT forjados

Figura 10: Usando tíquetes TGT forjados As boas notícias

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.