[Nota do editor: Este blogue foi escrito em co-autoria com Andrew Schwartz da TrustedSec.] Um dia, enquanto navegávamos no YouTube, deparámo-nos com uma apresentação Black Hat 2015 de Tal Be'ery e Michael Cherny. Em sua palestra e resumo subsequente, Watching the Watchdog: Protecting Kerberos Authentication with Network Monitoring, Be'ery e Cherny descreveram algo de que nunca tínhamos ouvido falar... o ataque Diamond Privilege Attribute Certificate (PAC). Ambos estivemos interessados em falsificar tickets no ano passado, então essa técnica imediatamente chamou nossa atenção e nos iniciou em uma jornada de exame e armamento de PoC. O resultado? O Bilhete Diamante.
Leitura relacionada
Golden Ticket vs Diamond Ticket
Tanto os ataques Golden como os ataques Diamond Ticket requerem acesso à chave KRBTGT. No entanto, os ataques Diamond Ticket quase certamente também exigem acesso à chave AES256. Enquanto os ataques Golden Ticket tiram partido da capacidade de forjar um bilhete de concessão de bilhete (TGT) a partir do zero, os ataques Diamond Ticket tiram partido da capacidade de desencriptar e reencriptar TGTs genuínos solicitados a um controlador de domínio (DC).
PAC Diamante vs Bilhete Diamante
O ataque original do Diamond PAC:
- Solicita um TGT sem PAC
- Garante que a conta de serviço para o serviço a ser acedido não tem o NA definido no seu atributo UserAccountControl (UAC)
- Forja um PAC e assina-o com a chave KRBTGT
- Injecta o PAC no bilhete de serviço resultante, incluindo o PAC no parâmetro enc_authorization_data da secção TGS-REQ
O bit NA no atributo UAC tem o valor 33554432 (ver Figura 1).
Depois de definir o bit bit NA no atributo UAC de uma conta de serviço, os pedidos de bilhetes de serviço para essa conta de serviço não têm PAC (ver Figura 2).
Sempre que os dados de autorização são incluídos no enc_authorization_data de um TGS-REQ (ver Figura 3), são copiados para a secção authorization_data da parte cifrada do bilhete de serviço resultante.
O Diamond PAC aproveitou-se deste comportamento para injectar um PAC no bilhete de serviço resultante quando a conta de serviço alvo não tinha o bit NA definido (ver Figura 4).
Repare na diferença de tamanho da saída do bilhete entre a Figura 2 e a Figura 4.
Como mostra a Figura 5, o bilhete pertence a Loki, mas o PAC tem informações de utilizador diferentes (ou seja, Thor).
Graças aospatches Kerberos/AD de Novembro de 2021 , a utilização de um TGT sem um PAC já não é possível em DCs totalmente actualizados. Portanto, soubemos imediatamente que essa versão do ataque não funcionaria mais. Mas, depois de ler sobre ele, perguntámo-nos porque é que o ataque tinha de ser tão complexo. No processo de simplificação do ataque, removemos a maioria dos seus requisitos, tornando-o possível em DCs totalmente actualizados.
A chave KRBTGT era um requisito, e o ataque utilizava qualquer outra conta válida para solicitar uma TGT. Porque não desencriptar esse TGT, modificá-lo como quiséssemos, recalcular as assinaturas PAC e voltar a encriptá-lo? Chamámos a esta abordagem um ataque Diamond Ticket.
Armação de Rubeus
Implementámos o nosso bilhete diamante no Rubeus com um novo comando - diamante
-dentro deste PR. Na demonstração seguinte, utilizamos este novo comando para criar e utilizar um bilhete Diamante.
Começamos o ataque tentando aceder ao ficheiro C$ (CIFS) em um DC, usando nosso usuário com pouco privilégio(Loki). Como mostra a Figura 6, recebemos uma resposta Access is denied (Acesso negado ).
Assumindo que já comprometemos a chave KRBTGT, podemos usar o novo comando diamante
no Rubeus para criar um Bilhete Diamante. Este comando começa por pedir um TGT normal para o utilizador pouco privilegiado Loki (ver figura 7). De seguida, o comando desencripta o TGT, modifica as partes relevantes, recalcula as assinaturas e volta a encriptar o TGT (ver Figura 8).
O tíquete resultante pode então ser usado como qualquer outro TGT, mas agora com modificações. Como mostra a Figura 9, solicitamos um tíquete de serviço para o serviço CIFS em nosso DC de destino(Earth-DC).
Por fim, no mesmo terminal, podemos agora aceder ao ficheiro C$ no DC, autenticando como um utilizador diferente da conta que pediu o TGT (ver Figura 10).
Vantagens OPSEC
Existem muitas formas potenciais de detectar a utilização do Golden Ticket ou as acções necessárias para obter acesso à chave KRBTGT (como o DCSync). Uma técnica: Monitorar as solicitações de tíquete de serviço (TGS-REQs) que não têm solicitação de TGT correspondente (AS-REQ). No entanto, tenha em atenção que a técnica Diamond Ticket tem mais probabilidades de contornar este tipo de detecção, solicitando um TGT válido antes de utilizar o bilhete resultante. Além disso, como o bilhete é criado pela primeira vez por um DC, é mais provável que alguns valores (por exemplo, os tempos do bilhete) estejam correctos por predefinição, em vez de exigir o cálculo dos tempos adequados para a criação do Bilhete Dourado OPSEC.
Orientação para a detecção
A investigação Diamond PAC original indicava o seguinte como orientação para a detecção baseada na rede:
- Um AS-REQ com um PA-PAC-REQUEST definido como falso
- A adição de dados de autorização numa mensagem TGS subsequente
- O serviço de destino bit NA definido como falso, exigindo PAC para autorização
Dada a nossa técnica melhorada, esta orientação não se aplica. O ataque Diamond Ticket não requer o pedido de um TGT sem um PAC, o envio de um PAC forjado dentro de um enc_authorization_data de um TGS-REQ, ou definir o bit NA bit em qualquer conta de serviço.
No entanto, alguma lógica de detecção do ataque Golden Tickets (por exemplo, as acções necessárias para obter acesso à chave KRBTGT ) pode também aplicar-se à detecção de um ataque Diamond Ticket. Muitas outras técnicas que podem ser usadas para detectar qualquer tipo de bilhete falsificado (Dourado, Prata ou Diamante) dependem em grande parte do nível de cuidado tomado durante a criação do bilhete - por exemplo, definir horários de bilhetes diferentes do que deveriam ser.
Nenhum destes métodos é uma bala de prata garantida para detectar este ataque, tal como não há balas de prata para detectar Bilhetes Dourados.
Uma nova visão dos bilhetes
Este post procurou demonstrar um mínimo de armamento PoC de bilhetes de diamante, embora uma implementação no estilo Mimikatz. Esta pesquisa pode ser facilmente estendida para fornecer controlo total e manipulação de quaisquer bilhetes, dadas as chaves certas.
Ao concluir nossa pesquisa e criar um PoC de armamento, Elad Shamir nos enviou a palestra DerbyCon 2014 de Tim Medin, Atacando o Microsoft Kerberos Chutando o Cão de Guarda do Hades. Nesta palestra, Tim discute a mesma técnica no contexto de tickets de serviço.
Embora a nossa técnica seja uma abordagem ligeiramente diferente dos bilhetes dourados e prateados, pode constituir uma alternativa útil e preferida em determinados ambientes.
