Red Team

A área de Red Team preza principalmente por uma invasão precisa, sem deixar rastros e indo direto ao ponto, tudo isso ao mesmo tempo.

E por ser dessa forma, envolve vários cuidados e técnicas que acabam sendo muito interessantes, nesse artigo vamos falar sobre uma delas. Antes de falar sobre a técnica, vamos falar um pouco sobre o cenário em que se aplica, existe uma validação de assinatura de driver no windows, essa validação, basicamente, faz uma busca por assinaturas da microsoft em um driver quando ele está para ser carregado, e essa validação, em um red team mitiga completamente a ideia de carregar um driver do atacante, já que assim que esse driver for carregado, vai ser feito um alert sysadmin dizendo que foi carregado um driver não assinado. Aqui, entra a técnica chamada de BYOD ou Bring Your Own Driver.

Cenário possível

Vamos montar o seguinte cenário, o atacante precisa fazer um dump das hashes do LSASS do windows, para isso ele vai precisar do mimikatz. Porém, ele só pode usar o mimikatz sem nt authority\system, se o driver mimidrv.sys for carregado, o que é (ou deveria ser) inviável, pois o sysadmin seria alertado.

Bring Your Own Driver

Vamos resolver o dilema do atacante. Sabemos que tudo que precisa para que a validação ocorra sem alarde, é que o driver seja assinado, agora pense o seguinte, se existisse um driver assinado pela microsoft que permita você carregar outros drivers, esse driver seria validado? A resposta para essa pergunta é: não. Mas você deve estar pensando “A microsoft não tem um driver desses, portanto é um cenário impossível”, e claro, a microsoft não tem um driver desses, mas o que impede um hacker de explorar uma vulnerabilidade em algum desses drivers para dar load/unload no driver que ele desejar, no nosso cenário, o driver de desejo é o mimidrv.sys. Recaptulando, basta o atacante carregar um driver assinado, porém vulnerável, explorá-lo e dar load no driver de desejo.

gdrv.sys

O gdrv.sys, é um driver assinado pela microsoft, que possui algumas poc’s para load/unload de driver, o que é perfeito para um bring your own driver. Tudo que precisamos fazer é usar alguma dessas poc’s, para explorar o driver em questão e por fim, dar load no driver de desejo (no caso do cenário, o mimidrv.sys).