Técnicas de Phishing XLL
Com o recente anúncio da Microsoft sobre o bloqueio de macros em documentos originados da internet (e-mail E download da web), os atacantes começaram a explorar agressivamente outras opções para obter acesso orientado pelo usuário (UDA). Existem várias considerações a serem ponderadas e equilibradas ao buscar um método viável de phishing para acesso:
Estas são as principais questões, mas certamente há mais. As coisas se tornam mais complexas à medida que você percebe que esses fatores se agravam mutuamente; por exemplo, se um cliente possui um proxy web que proíbe o download de executáveis ou DLLs, você pode precisar colocar seu payload dentro de um contêiner (ZIP, ISO, etc.). Fazer isso pode apresentar mais problemas no futuro quando se trata de detecção. Defesas mais robustas exigem combinações mais complexas de técnicas para serem derrotadas.
Este artigo será escrito tendo em mente uma organização alvo fictícia; esta organização empregou várias medidas defensivas, incluindo regras de filtragem de e-mail, bloqueio de certos tipos de arquivo de serem baixados, lista de permissões de aplicativos em endpoints e Microsoft Defender for Endpoint como solução EDR.
Organizações reais podem não empregar nenhuma dessas, algumas, ou até mais defesas, o que pode simplificar ou complicar as técnicas descritas nesta pesquisa. Como sempre, conheça seu alvo.
XLLs são DLLs, especificamente criadas para o Microsoft Excel. Para olhos não treinados, elas se parecem muito com documentos normais do Excel.
XLLs fornecem uma opção muito atraente para UDA, já que são executadas pelo Microsoft Excel, um software muito comum em redes de clientes; como bônus adicional, como são executadas pelo Excel, nosso payload quase certamente contornará as regras de lista de permissões de aplicativos porque um aplicativo confiável (Excel) o está executando. XLLs podem ser escritas em C, C++ ou C#, o que proporciona muito mais flexibilidade e poder (e sanidade) do que macros VBA, o que as torna ainda mais desejáveis.
A desvantagem, é claro, é que existem muito poucos usos legítimos para XLLs, então DEVERIA ser uma caixa muito fácil de marcar para as organizações bloquearem o download dessa extensão de arquivo tanto por e-mail quanto por download da web. Infelizmente, muitas organizações estão anos atrasadas e, como resultado, as XLLs continuam sendo um método viável de phishing por algum tempo.
Há uma série de eventos diferentes que podem ser usados para executar código dentro de uma XLL, o mais notável dos quais é xlAutoOpen. A lista completa pode ser vista aqui:
Ao clicar duas vezes em uma XLL, o usuário é recebido por esta tela:
Esta única caixa de diálogo é tudo o que separa o usuário da execução de código; com engenharia social bastante sutil, a execução de código é praticamente garantida.
Algo que deve ser lembrado é que as XLLs, sendo executáveis, são específicas da arquitetura. Isso significa que você deve conhecer seu alvo; a versão do Microsoft Office/Excel que a organização alvo utiliza (geralmente) ditará para qual arquitetura você precisa construir seu payload.
Há uma divisão bastante clara nas versões do Office que pode ser usada como regra prática:
Office 2016 ou anterior: x86
Office 2019 ou posterior: x64
Deve-se notar que é possível instalar a outra arquitetura para cada produto, no entanto essas são as arquiteturas padrão instaladas e, na maioria dos casos, essa deve ser uma maneira confiável de decidir para qual arquitetura preparar sua XLL. É claro que, dependendo do método de entrega e do pretexto usado na campanha de phishing, é possível fornecer ambas as versões e contar com a vítima para selecionar a versão apropriada para seu sistema.
O payload XLL que foi construído durante esta pesquisa foi baseado neste projeto de edparcell. O repositório dele tem boas instruções sobre como começar com XLLs no Visual Studio, e usei o código dele como ponto de partida para desenvolver um arquivo XLL malicioso.
Um desvio notável do repositório dele é que, caso você queira criar seu próprio projeto XLL, precisará baixar o SDK mais recente do Excel e depois seguir as instruções do repositório vinculado usando esta versão, em vez da versão 2010 do SDK mencionada no README.
A entrega do payload é uma consideração séria no contexto de UDA. Existem dois métodos principais nos quais vamos focar:
Seja anexando um arquivo ou incluindo um link para um site onde um arquivo pode ser baixado, o e-mail é uma parte crítica do processo de UDA. Ao longo dos anos, muitas organizações (e provedores de e-mail) amadureceram e impuseram regras para proteger usuários e organizações contra anexos maliciosos. O resultado varia, mas as organizações agora têm a capacidade de:
Fuzzer as regras de e-mail de uma organização pode ser uma parte importante de um engajamento, no entanto, deve-se sempre ter cuidado para não revelar que uma operação de Red Team está em andamento e que informações estão sendo ativamente coletadas.
Para os fins deste artigo, será assumido que a organização alvo possui regras robustas de anexos de e-mail que impedem a entrega de um payload XLL. Vamos mudar e analisar a entrega pela web.
O e-mail ainda será usado neste vetor de ataque, no entanto, em vez de enviar um anexo, ele será usado para enviar um link para um site. As regras de proxy web e mitigações de rede que controlam os tipos de arquivo permitidos para download podem diferir daquelas aplicadas em relação a anexos de e-mail. Para os fins deste artigo, assume-se que a organização impede o download de arquivos executáveis (cabeçalhos MZ) da web. Sendo este o caso, vale a pena explorar empacotadores/contêineres.
A premissa é que podemos colocar nosso executável dentro de outro tipo de arquivo e contrabandeá-lo pelas políticas da organização. Uma consideração importante aqui é o suporte nativo ao tipo de arquivo; arquivos 7Z, por exemplo, não podem ser abertos pelo Windows sem instalar software de terceiros, então não são uma boa escolha. Formatos como ZIP, ISO e IMG são escolhas atraentes porque são suportados nativamente pelo Windows e, como bônus adicional, adicionam muito poucos passos extras para a vítima.
A organização, infelizmente, bloqueia o download de ISOs e IMGs da web; além disso, como empregam Prevenção contra Perda de Dados (DLP), os usuários não podem montar dispositivos de armazenamento externo, que é como ISOs e IMGs são considerados.
Felizmente para nós, embora a organização impeça o download de arquivos com cabeçalho MZ, ela permite o download de arquivos zip contendo executáveis. Esses arquivos zip são ativamente escaneados em busca de malware, incluindo solicitar ao usuário a senha para arquivos zip protegidos por senha; no entanto, como o executável está zipado, ele não é bloqueado pela negação geral de arquivos MZ.
Arquivos zip foram escolhidos como contêiner para nosso payload XLL porque:
Convenientemente, clicar duas vezes em um arquivo ZIP no Windows abrirá esse arquivo zip no Explorador de Arquivos:
Menos convenientemente, clicar duas vezes no arquivo XLL do local zipado aciona o Windows Defender; mesmo usando o projeto padrão de edparcell que não contém nenhum tipo de código malicioso.
Olhando para o alerta do Windows Defender, vemos que é apenas um alerta genérico "Wacatac":
No entanto, há algo estranho; o arquivo que ele identificou como malicioso estava em c:\users\user\Appdata\Local\Temp\Temp1_ZippedXLL.zip, não em C:\users\user\Downloads\ZippedXLL\ onde clicamos duas vezes. Observando a instância do Excel no ProcessExplorer, mostra que o Excel está realmente executando a XLL de appdata\local\temp, não do arquivo ZIP de onde veio:
Isso parece ser uma complicação associada a arquivos ZIP, não a XLLs. Abrir um arquivo TXT de dentro de um zip usando o bloco de notas também resulta na cópia do arquivo TXT para appdata\local\temp e abertura a partir de lá. Embora abrir um arquivo de texto deste local seja aceitável, o Defender parece identificar qualquer tipo de execução de código real neste local como maliciosa.
Se um usuário extraísse a XLL do arquivo ZIP e depois a executasse, ela seria executada sem problemas; no entanto, não há como garantir que o usuário faça isso, e realmente não podemos arriscar acionar o AV/EDR caso ele não a extraia. Além disso, clicar duas vezes no ZIP e depois clicar duas vezes na XLL é muito mais simples e a vítima é muito mais propensa a concluir essas ações simples do que se dar ao trabalho de extrair o ZIP.
Esse problema me fez começar a considerar um tipo de payload diferente de XLL; comecei a explorar VSTOs, que são Modelos do Visual Studio para Office. Recomendo fortemente que você confira esse artigo.
VSTOs, em última análise, chamam uma DLL que pode estar localizada localmente com o .XLSX que inicia tudo, ou hospedada remotamente e baixada pelo .XLSX via http/https. A opção local não oferece vantagens reais (e, na verdade, várias desvantagens, pois há vários arquivos associados a um ataque VSTO), e a opção remota, infelizmente, requer um certificado de assinatura de código ou que o local remoto seja uma rede confiável. Não tendo um certificado de assinatura de código válido, VSTOs não mitigam nenhum dos problemas neste cenário que nosso payload XLL está enfrentando.
Realmente parece que estamos encurralados. Executar a XLL em si é aceitável, no entanto a XLL não pode ser entregue sozinha à vítima, seja por anexo de e-mail ou download da web, devido à política da organização. A XLL precisa ser empacotada dentro de um contêiner, mas devido a formatos DLP como ISO, IMG e VHD não serem viáveis. A vítima precisa ser capaz de abrir o contêiner nativamente sem nenhum software de terceiros, o que realmente deixa ZIP como a opção; no entanto, como discutido, executar a XLL de uma pasta zipada resulta em sua cópia e execução a partir de appdata\local\temp, o que aciona o AV.
Passei muitas horas debatendo e testando coisas, descendo na toca do coelho VSTO, explorando todas as opções concebíveis até que finalmente decidi tentar algo tão estúpido que poderia funcionar.
Desta vez, criei uma pasta, coloquei a XLL dentro dela e depois zipei a pasta:
Clicando na pasta, revela o arquivo XLL:
Clicar duas vezes na XLL mostra o prompt de Add-In do Excel. Observe que a XLL ainda é copiada para appdata\local\temp, no entanto há uma camada adicional devido à pasta extra que criamos:
Clicar em Habilitar executa nosso código sem acionar o Defender:
Legal! Execução de código. E agora?
O pretexto envolvido em conseguir que uma vítima baixe e execute a XLL variará enormemente com base na organização e no método de entrega; temas podem incluir dados salariais de funcionários, calculadoras de remuneração baseada em habilidades, informações sobre um projeto, uma lista de presença para um evento, etc. Seja qual for a isca, nosso ataque será muito mais eficaz se realmente fornecermos à vítima o que foi prometido. Sem acompanhamento, as vítimas podem ficar desconfiadas e denunciar o documento às suas equipes de segurança, o que pode rapidamente entregar o atacante e limitar o acesso ao sistema alvo.
A XLL por si só deixará apenas uma janela em branco do Excel após a execução do nosso código; seria muito melhor para nós fornecer a Planilha Excel que a vítima está procurando.
Podemos incorporar nosso XLSX como um array de bytes dentro da XLL; quando a XLL for executada, ela irá soltar o XLSX no disco ao lado da XLL, após o que será aberto. Nomearemos o XLSX com o mesmo nome da XLL, a única diferença sendo a extensão.
Dado que nossa XLL é escrita em C, podemos trazer algumas das capacidades de um artigo anterior que escrevi sobre Payload Capabilities in C, nomeadamente a Autodeleção. Combinar essas duas técnicas resulta na XLL sendo deletada do disco, e o XLSX de mesmo nome sendo colocado em seu lugar. Para o olho não treinado, parecerá que o XLSX esteve lá o tempo todo.
Infelizmente, o local onde a XLL é deletada e o XLSX é solto é a pasta appdata\temp\local, não o ZIP original; para resolver isso, podemos criar um segundo ZIP contendo apenas o XLSX e também lê-lo em um array de bytes dentro da XLL. Na execução, além das ações mencionadas, a XLL poderia tentar localizar o arquivo ZIP original em c:\users\victim\Downloads\ e deletá-lo antes de soltar o segundo ZIP contendo apenas o XLSX em seu lugar. Isso pode, é claro, falhar se o usuário salvou o ZIP original em um local diferente ou com um nome diferente, no entanto, na maioria dos casos, ele deve cair automaticamente na pasta de downloads do usuário.
Esta captura de tela mostra no painel inferior a pasta temp criada em appdata\local\temp contendo a XLL e o XLSX solto, enquanto o painel superior mostra a janela original do Explorador de Arquivos de onde a XLL foi aberta. Observe no painel inferior que a XLL tem tamanho 0. Isso ocorre porque ela se deletou durante a execução, no entanto, até que o painel superior seja fechado, o arquivo XLL não desaparecerá completamente do local appdata\local\temp. Mesmo que a vítima clique na XLL novamente, ela agora está inerte e não existe realmente.
Da mesma forma, assim que a vítima sair do ZIP aberto no Explorador de Arquivos (fechando-o ou navegando para uma pasta diferente), se ela clicar em spreadsheet.zip novamente, agora descobrirá que a pasta test contém importantdoc.xlsx; portanto, a XLL foi removida e substituída pelo XLSX inofensivo em ambos os locais onde existia no disco.
Este GIF demonstra o download e execução da XLL em uma VM de teste do MDE. Observe que, por algum motivo, o Excel abre duas instâncias aqui; no meu computador doméstico, abriu apenas uma, então não sei ao certo por que difere.
Como sempre, perguntaremos "O que o MDE vê?"
Uma rápida captura de tela para provar que executei isso no alvo e capturei um beacon de volta no TestMachine11:
Primeiramente, zero alertas:
O que a linha do tempo/log de eventos captura?
Caramba. Para ser sincero, não tenho ideia de onde vêm os alertas de keylogging, criptografia e descriptografia de credenciais, já que meu código não faz nada disso. Nossas ações certamente parecem suspeitas quando apresentadas assim, mas comentarei novamente sobre a quantidade de dados que o MDE coleta em um único endpoint, quanto mais em centenas, milhares ou centenas de milhares que uma organização pode ter conectados ao EDR. Contanto que não estejamos gerando nenhum alerta real, provavelmente estamos bem.
O momento que a maioria provavelmente estava esperando, estou fornecendo um exemplo de código do meu runner XLL desenvolvido, limitado apenas às partes discutidas aqui na seção de Tradecraft. Caberá ao leitor realmente colocar o código em uma XLL e implementá-lo em conjunto com o restante do seu runner. Como sempre, não cause danos, tenha permissão para pescar (phishing) uma organização, etc.
Incluí o código-fonte de um programa que irá ingerir um arquivo e produzir hexadecimal que pode ser copiado para os arrays de bytes definidos no snippet. Use isso no XLSX que você deseja apresentar ao usuário, bem como no arquivo ZIP que contém a pasta que contém esse mesmo XLSX e armazene-os em seus respectivos arrays de bytes. Compile este código usando:``` gcc -o ingestfile ingestfile.c
Tive alguns problemas para compilar meus XLL's usando MingW em uma máquina Kali, então pensei em postar os comandos aqui:
**x64**```
x86_64-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/x64/XLCALL32.LIB -o importantdoc.xll -s -Os -DUNICODE -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
x86``` i686-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/XLCALL32.LIB -o HelloWorldXll.xll -s -DUNICODE -Os -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
Depois de compilar, você vai querer criar uma nova pasta e copiar o XLL para essa pasta. Em seguida, compacte-o usando:```
zip -r <myzipname>.zip <foldername>/
Note que para que as técnicas descritas neste artigo funcionem, você precisará combinar algumas variáveis no trecho de código com o que você nomeia o XLL e o arquivo zip.
Com o domínio das macros do Office chegando ao fim, os XLL's apresentam uma opção atraente para campanhas de phishing. Com alguma criatividade, eles podem ser usados em conjunto com outras técnicas para contornar muitas camadas de defesas implementadas por organizações e equipes de segurança. Obrigado por ler e espero que tenha aprendido algo útil!