optiv/dentUm framework para criar bypasses baseados em COM utilizando vulnerabilidades nos sensores WDAPT da Microsoft.
Para ver a versão mais recente do Dent ou enviar um problema, consulte https://github.com/Tylous/Dent.
Dent
Se você quiser saber mais sobre as técnicas utilizadas neste framework, dê uma olhada neste artigo.
Este framework gera código para explorar vulnerabilidades nas regras de Redução de Superfície de Ataque (ASR) do Microsoft Defender Advanced Threat Protection para executar shellcode sem ser detectado ou impedido. A ASR foi projetada para ser a primeira linha de defesa, detectando eventos com base em ações que violam um conjunto de regras. Essas regras focam em indicadores de comportamento específicos no endpoint que frequentemente estão associados às Táticas, Técnicas ou Procedimentos (TTPs) de um atacante. Essas regras têm um forte foco no conjunto Microsoft Office, pois este é um vetor de ataque comum para estabelecer uma posição remota em um endpoint. Muitos dos controles baseados em regras focam em indicadores de comportamento baseados em rede ou processo que se destacam da operação normal de negócios. Essas regras focam no comprometimento inicial de um sistema ou em uma técnica que pode impactar severamente uma organização (por exemplo, divulgação de credenciais ou ransomware). Elas cobrem uma grande parte da superfície de ataque comum e focam em dificultar técnicas conhecidas usadas para comprometer ativos.
O Dent aproveita várias vulnerabilidades para contornar esses controles restritivos e executar payloads em um endpoint sem ser bloqueado ou efetivamente detectado pelos sensores do Microsoft Defender Advanced Threat Protection. O artigo acima descreve essas vulnerabilidades que AINDA estão presentes no Microsoft Defender Advanced Threat Protection mesmo após a divulgação.
O primeiro passo, como sempre, é clonar o repositório e depois compilá-lo
go build Dent.go
./Dent -h
________ __
\______ \ ____ _____/ |_
| | \_/ __ \ / \ __\
| | \ ___/| | \ |
/_______ /\___ >___| /__|
\/ \/ \/
(@Tyl0us)
"Call someone a hero long enough, and they'll believe it. They'll become it.
They have no choice. Let them call you a monster, and you become a monster."
Uso do ./Dent:
-C string
Nome do objeto COM.
-N string
Nome do payload XLL quando é escrito no disco.
-O string
Nome do arquivo de saída. (padrão "output.txt")
-P string
Caminho da DLL para seu objeto COM. (Use \\ ou '' ao redor do caminho)
-U string
URL onde o payload XLL codificado em base64 está hospedado.
-show
Exibe o script no terminal.
Este framework é destinado a explorar vulnerabilidades e deficiências no Microsoft Defender Advanced Threat Protection, por isso ele não gera payloads/implants de fato. Para gerá-los, você pode usar um grande número de ferramentas publicamente disponíveis, no entanto toda a pesquisa, desenvolvimento e teste foram feitos usando ScareCrow. O Microsoft Defender Advanced Threat Protection não depende de hooking em modo de usuário para telemetria, mas sim utiliza vários outros mecanismos, como callbacks do kernel. Pelos testes, este framework funciona extremamente bem para contornar o Microsoft Defender Advanced Threat Protection e executar shellcode.
No momento do lançamento, existem atualmente duas técnicas. Estarei constantemente adicionando diferentes que utilizam essas vulnerabilidades de maneiras diferentes periodicamente, então fique atento para mais.
Os objetos COM são frequentemente criados quando um aplicativo está sendo instalado em um sistema. Uma vez criados, qualquer aplicativo ou script pode chamá-los, no entanto esta não é a única maneira de criá-los. Ao modificar/criar chaves de registro na seção HKEY_CLASSES_ROOT do Registro do Windows, podemos criar um objeto COM que aponta para nosso shellcode no sistema. Isso significa que qualquer aplicativo ou script que possa utilizar COM pode chamá-lo, executando o shellcode.
Isso funciona devido à forma como a API CoCreateInstance funciona. CoCreateInstance é usada para criar e inicializar objetos COM com base no CLSID (um identificador globalmente único usado para identificar uma classe de objeto COM específica). Esta função obtém as informações para executar a chamada usando os valores armazenados nas chaves do registro. Esses valores CLSID podem ser encontrados no caminho HKEY_CLASSES_ROOT\CLSID\ do registro. No entanto, antes que um processo possa chamar o CLSID, ele deve saber o valor desse CLSID. Isso é feito primeiro realizando uma consulta ao registro para procurar o objeto COM em HKEY_CLASSES_ROOT\<nome do objeto COM>, e se existir, uma segunda consulta ao registro será feita para obter o valor CLSID armazenado na subpasta.
Uma inspeção mais aprofundada das subpastas do registro mostra que a permissão para os valores CLSID não é consistente. A grande maioria dos objetos COM armazenados aqui permite apenas a permissão “Controle Total” para o Trusted Installer. O Trusted Installer é uma conta de serviço que possui recursos para protegê-los, até mesmo dos Administradores. Isso foi projetado para garantir que, mesmo que um invasor obtenha privilégios administrativos, os recursos não possam ser manipulados maliciosamente. Infelizmente, muitos objetos COM permitem que qualquer pessoa no grupo Administradores tenha permissão “Controle Total”. Além disso, a chave raiz CLSID permite ao grupo Administradores permissões de “Controle Total” em vez de NT AUTHORITY\System ou Trusted Installer. Por causa disso, em um contexto elevado, podemos criar ou até mesmo modificar valores específicos de objetos COM.
Importante
A criação dessas chaves de registro só funciona se você executá-las em um contexto elevado. Clicar duas vezes nisso através de uma GUI não executará o arquivo .VBS em um contexto elevado, mesmo que você seja um administrador. É recomendado executá-lo a partir de um shell administrativo ou prompt de comando. No entanto, uma vez que as chaves são criadas, qualquer aplicativo pode chamar este objeto COM em qualquer contexto.
Para utilizar um payload do ScareCrow com este tipo de bypass, você pode executar o seguinte comando:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader dll
Depois de ter seu payload, use a flag -N para o nome do payload quando for escrito no disco, a flag -C para o nome do objeto COM, a flag -I para o local onde será escrito e, por último, a flag -O para o arquivo de saída para armazenar o conteúdo.
Esta opção gera um bloco de código para contornar várias regras ASR para baixar, escrever no disco, carregar e executar shellcode, contornando os controles preventivos da ASR. Isso é feito usando o objeto COM Excel.Application, que representa todo o Aplicativo Excel, mas de forma automatizada, e permite a interação programática com ele. Por ainda ser o Excel, ele não aciona a regra ASR. Isso porque quando chamamos Excel.Application, podemos ver que ele é gerado sob um processo Service Host (Svchost.exe) e não o processo WinWord.exe. Enquanto Svchost.exe é um processo de nível de sistema usado para hospedar vários serviços do Windows, o processo filho criado (Excel.exe) não obteve privilégios de nível de sistema.