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.
Porque criamos um objeto COM que era um aplicativo completo, o processo Excel foi criado sob Svchost.exe para que pudesse ser tratado adequadamente para evitar instabilidades no processo WinWord.exe. Embora este processo esteja sob Svchost.exe, há outro desafio a enfrentar: executar shellcode. Como a execução binária ou o uso de WinAPI dentro de uma macro acionará outras regras ASR, isso limita o que podemos fazer sem acionar uma regra ASR ou ser pego pelo componente EDR do WDAPT. É aqui que as DLLs brilham. Se um payload baseado em DLL for compilado com as funções de exportação corretas, ele pode ser usado como um plugin do Office que, quando carregado, executará automaticamente o shellcode. Para fazer isso, podemos utilizar a função RegisterXLL do Excel. A função RegisterXLL carrega um plugin XLL na memória, registrando-o e executando-o automaticamente. Arquivos XLL são essencialmente DLLs baseadas em Excel.
Para obter o conteúdo no sistema, podemos usar outro objeto COM (Microsoft.XMLHTTP), ganhando a capacidade de executar uma requisição HTTP, neste caso, uma requisição HTTP GET para uma URL. O segundo objeto COM (ADODB.stream) fornece a capacidade de ler/escrever bytes de um fluxo de dados. Ao combinar os dois objetos COM, um atacante pode solicitar um recurso remoto através de uma requisição HTTP GET e escrever a resposta (neste caso, o próprio arquivo) no disco. Isso é feito usando o objeto COM (ADODB.stream) novamente para lidar com a leitura/escrita de bytes do fluxo de dados. O segundo objeto COM (Microsoft.XMLDOM) permite a leitura de dados armazenados em um arquivo. O objeto XMLDCOM permite definir o tipo de dados (neste caso, base64) e uma vez aberto e armazenado em uma string com o tipo de dados apropriado, o objeto ADODB.stream pode escrever a string de código no disco usando um tipo de dados diferente (neste caso, BinaryStreamType), convertendo a string base64 de volta para uma forma binária.
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 excel -O <Output filename>
Uma vez gerado, copie as linhas 13 e 14 do arquivo de saída e junte-as, certificando-se de remover:
var <nome da variável>; no final de cada linha
Depois de ter seu payload codificado, use a flag -N para o nome do payload quando for escrito no disco, a flag -U para a URL onde o payload codificado será hospedado (por exemplo, https:///), e a flag -F para o nome do arquivo que está sendo hospedado pelo site. O código gerado foi projetado para funcionar em um documento de macro .
Através de investigação adicional, observou-se que não é uma lacuna nos sensores do WDATP, mas sim que o WDATP tem visibilidade sobre essa atividade, mas ela é ignorada. Através da linha do tempo de eventos do endpoint do WDATP procurando por qualquer referência a Appwiz.xll, observamos que o WDAPT registrou um evento de “arquivo criado” quando o Word criou o arquivo AppWiz.xll. É importante notar que arquivos .XLL são executáveis.
20/11/2020 - Desenvolvimento da pesquisa e artigo escrito.
14/03/2021 - Fornecido à Microsoft um documento de divulgação preliminar descrevendo as questões identificadas.
31/03/2021 - A Microsoft reconheceu e admitiu que as vulnerabilidades relacionadas à criação de um processo filho do Office e à gravação de arquivos no disco eram vulnerabilidades reais e começou a trabalhar na correção. No entanto, as inconsistências de permissões no registro foram consideradas não uma vulnerabilidade devido à exigência de privilégios elevados.
21/04/2021 - A Microsoft informou ao autor que a compilação de assinatura 1.333.1055.0 lançada em 22/03/2021 e a 1.335.1321.0 lançada em 21/04/2021 continham a detecção para as vulnerabilidades baseadas em aplicativos do Office e encerrou o caso.
22/04/2021 - O autor retestou as mesmas técnicas, identificando que as vulnerabilidades ainda estavam presentes.