Como descobrimos uma campanha Horabot e como você pode detectar esse malware

Introdução

Nesta edição de nossa série Arquivos SOC, apresentaremos uma campanha direcionada que nossa equipe de MDR identificou e perseguiu há alguns meses. Envolve uma ameaça conhecida como horabotum pacote que consiste em um infame Trojan bancário, um espalhador de e-mail e uma cadeia de ataque notavelmente complexa.

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

O ponto de partida

Como sempre, nossa história começa com um alerta que apareceu no ambiente de um dos nossos clientes. A regra que o desencadeou é genérica, mas eficaz na detecção de atividades suspeitas de mshta. O caso progrediu a partir desse alerta inicial, mas felizmente terminou com uma nota positiva. O Kaspersky Endpoint Security interveio e encerrou o processo malicioso (por meio de um módulo de defesa proativo (PDM)) e removeu os arquivos relacionados antes que a ameaça pudesse progredir ainda mais.

O incidente foi então trazido à discussão em uma de nossas reuniões semanais. Isso foi suficiente para despertar a curiosidade de um dos nossos analistas, que se aprofundou na arte por trás desta campanha.

A cadeia de ataque

Depois de alguma pesquisa e muita investigação na infraestrutura do adversário, nossa equipe conseguiu mapear a cadeia de destruição de ponta a ponta. Nesta seção, detalharemos cada etapa e explicaremos como a operação se desenrola.

Etapa 1: isca inicial

Seguindo a trilha observada no incidente relatado, a atividade parece começar com uma página CAPTCHA falsa padrão. No incidente mencionado acima, esta página estava localizada na URL https://evs.grupotuis(.)buzz/0capcha17/ (detalhes sobre seu conteúdo podem ser encontrados aqui).

Semelhante aos casos 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. Uma vez enganada, a vítima cola um comando semelhante ao abaixo:

Este comando recuperou e executou um arquivo HTA que continha o seguinte:

É essencialmente um pequeno carregador. Quando executado, ele abre uma janela em branco e imediatamente extrai e executa uma carga JavaScript externa hospedada no domínio do invasor. O corpo contém um grande bloco de texto aleatório e sem sentido que serve apenas como preenchimento.

Estágio 2: Uma pitada de polimorfismo do lado do servidor

A carga carregada pelo arquivo HTA cria dinamicamente um novo element, sets its source to an external VBScript hosted on another attacker-controlled domain, and injects it into the section of a page hardcoded in the HTA. You can see the full content of the page in the box below. Once appended, the external VBScript is immediately fetched and executed, advancing the attack to its next stage.

The next-stage VBS content resembles the example shown below. During our analysis, we observed the use of server-side polymorphism because each access to the same resource returned a slightly different version of the code while preserving the same functionality.

The script is obfuscated and employs a custom string encoding routine. Below is a more readable version with its strings decoded and replaced using a small Python script that replicates the decode_str() routine.

The script performs pretty much the same function as the initial HTA file. It reaches a JavaScript loader that injects and executes another polymorphic VBScript.

Unlike the first script, this one is significantly more complex, with more than 400 lines of code. It acts as the heavy lifter of the operation. Below is a brief summary of its key characteristics:

• Heavy obfuscation: the script uses multiple layers of obfuscation to obscure its behavior.
• Custom string decoder: employs the same decoding routine found in the first VBScript to reconstruct strings at runtime.
• Anti-VM and “anti-Avast”: performs basic environment checks and terminates if a specific Avast folder or VM artifacts are detected.
• Information gathering and exfiltration: collects the host IP, hostname, username, and OS version, then sends this data to a C2 server.
• Download of additional components: retrieves an AutoIt executable, its compiler (Aut2Exe), a script (au3), and a blob file, placing them under the hardcoded path C:UsersPublicLAPTOP-0QF0NEUP4.
• PowerShell command execution: executes PowerShell commands that reach out to two different URLs (one unavailable and the other leading to the first stager of the spreader, which we describe later in this article).
• Persistence setup: creates a LNK file and drops it into the Startup folder to maintain persistence.
• Cleanup routines: removes temporary files and terminates selected processes.

During our analysis of the heavy lifter, specifically within the exfiltration routine, we identified where the collected data was being sent. After probing the associated URL and removing the “salvar.php” portion, we uncovered an exposed webpage where the adversary listed all their victims.

As you may have noticed, the table is in Brazilian Portuguese and lists victims dating back to May 2025 (this screenshot was taken in September 2025). In the “Localização” (location) column, the adversary even included the victims’ geographic coordinates, which are redacted in the screenshot. A quick breakdown shows that, of the 5384 victims, 5030 were located in Mexico, representing roughly 93% of the total.

Stage 3: The evil combination of AutoIT and a banking Trojan

It is now time to focus on the files downloaded by our heavy lifter. As previously mentioned, three AutoIT components were dropped on disk: the executable (AutoIT3), the compiler (Aut2Exe), and the script (au3), along with an encrypted blob file. Since we have access to the AutoIt script code, we can analyze its routines. However, it contains over 750 lines of heavily obfuscated code, so let’s focus only on what really matters.

The most important routine is responsible for decrypting the blob file (it uses AES-192 with a key derived from the seed value 99521487), loading it directly into memory, and then calling the exported function B080723_N. The decrypted blob is a DLL.

We also managed to replicate the decryption logic with a Python script and manually extract the DLL (0x6272EF6AC1DE8FB4BDD4A760BE7BA5ED). After initial triage and basic sandbox execution, we observed the following:

• The sample is a well-known Delphi banking Trojan detected by several engines under different names, such as Casbaneiro, Ponteiro, Metamorfo, and Zusy.

• It embeds two old OpenSSL libraries (libeay32.dll and ssleay32.dll) from the Indy Project, an open-source client/server communications library used to establish client/server HTTPS C2 communication.

• It includes SQL commands used to harvest credentials from browsers.

Once loaded into memory, the Trojan sends several HTTP requests to different URLs:

Since this malware family has been extensively documented in previous studies, we won’t reiterate its well-known functionality. Instead, we’ll focus on lesser-documented and newly observed features, including the malware’s encryption and protocol handling logic.

The sample implements a stateful XOR-subtraction cipher in the sub_00A86B64 subroutine, which is used to protect strings and decrypt HTTP data received from the C2. Unlike simple XOR, each byte of output here depends on both the key and the previous byte. In our sample, the key is the string "0xFF0wx8066h".

Key construction (left) and decryption logic (right)

We can easily reimplement the logic of the routine in Python and integrate the following snippet into our workflow to automate string decryption:

Python implementation of the decryption routine

The encrypted strings are retrieved in three different ways: through indexed lookups using a global encrypted Delphi string list (also observed by our colleagues at ESET); via direct references to encrypted hex strings in the data section; through indirect references using pointer variables, adding an overhead when automating decryption with scripts.

Direct pointer (left), indirect pointer (right)

Indexed strings via TStringList lookups

The malware fetches its configuration by performing an HTTPS GET request to the hardcoded, encrypted C2 server. The server responds with a configuration, which is a raw HTTP response, consisting of several values, each individually encrypted with the aforementioned algorithm. The sample extracts specific parameters based on their position in the list.

Decrypted configuration values (root password redacted)

To improve readability, the above screenshot has been edited to include the decrypted parameters, which are separated by double newlines.

Configuration retrieval and parsing are initiated in the sub_00AD2C70 subroutine where the first configuration value, the C2 socket connection setting (host;port), is extracted.

C2 socket address extraction

If parsing fails, the malware falls back to a hardcoded secondary C2 socket address. The socket connection is then established.

Fallback to hardcoded socket address (lifenews(.)pro:49569)

Additional configuration values are parsed in sub_00AD2918 and its subroutines. For example, in the decrypted C2 configuration shown above, parameter 5 contains the “UPON” string that triggers execution, and parameter 6 contains the PowerShell commands that are run when this string is used. Below is the portion of the routine that takes care of parsing this command:

Extracting value 5 and 6 from the configuration

In addition to HTTP communication, the malware supports raw socket communication using a custom protocol that encapsulates commands into tags such as <|SIMPLE_TAG|> or <|TAG|>Arg1<|>Arg2<<|>.

The client initiates the C2 connection in sub_00AD331C, where it establishes a TCP socket to the operator’s server and sends the "PRINCIPAL" command to request a control channel. After receiving an OK response, it follows up with an "Info" message containing system details. Once validated, the server replies with a "SocketMain" message containing a session ID, completing the handshake. All subsequent command handling occurs in sub_00AD373C, a central orchestrator routine that parses incoming messages and dispatches the malicious actions.

The sample, and therefore the protocol itself, is inherited, from the open-source Delphi Remote Access PC project, as our colleagues at ESET have noted in the past. Below is a visual comparison:

Comparison of “PING” and “Close” commands (sample disassembly on the left, Delphi Remote Access source code on the right)

Some features from the open-source project, including the chat and file manipulation commands, have been removed, while some mouse-related commands have been renamed with playful prefixes like “LULUZ” (e.g., LULUZLD, LULUZPos). This could be an inside joke, anti-analysis obfuscation, or a way to mark custom variants. Beyond the standard functionality, the protocol now includes a range of additional custom commands, such as LULUZSD for mouse wheel scrolling down, ENTERMANDA to simulate pressing the Enter key, and COLADIFKEYBOARD to inject arbitrary text as keystrokes.

The full command set is considerably larger, and while not all commands are implemented in the analyzed sample, evidence of their presence (e.g., in the form of strings) suggests ongoing development.

After getting a sense of the protocol, let’s focus on the cipher used. In this sample, traffic exchanged via the C2 socket channel is encrypted using another stateful XOR algorithm with embedded decryption keys. Its logic is implemented in the routines sub_00A9F2D0 (encryption) and sub_00A9F5C0 (decryption):

Encryption routine sub_00A9F2D0

The encryption routine generates three random four-digit integer keys. The first key acts as the initial cipher state, while the other two serve as the multiplier and increment that are applied at every encryption stage to both the state and the data. For each character in the input string, it takes the high byte of the current state, XORs it with the character to encrypt, and then updates the cipher state for the next character. The output is created by prepending the three keys to the ciphertext, encapsulating everything within the “##” markers. The final output looks like this:

Here’s a Python snippet to decode such traffic:

Although this encryption layer was likely intended to evade network inspection, it ironically makes detection easier due to its highly regular and repetitive structure. This pattern, including the external markers “##”, is uncommon in legitimate traffic and can be used as a reliable network signature for IDS/IPS systems. Below is a Suricata rule that matches the described structure:

As documented by our colleagues at Fortinet, the malware contains functionality to display fake pop-ups prompting victims to enter their banking credentials. The images for these pop-ups are stored as encrypted resources. Unlike strings, resources are decrypted using the standard RC4 cipher, and the key pega-avisao3234029284 is retrieved from the previous TStringList structure at offset 3FEh.

Fake token overlay used for credential theft (right), with disassembly (left)

The wordplay around “pega a visão”, Brazilian slang meaning “get the picture” figuratively, reveals an intentional cultural reference, supporting the already well-known Brazilian ties of the operators who have a native understanding of the language.

Below is a collage of pictures where the targeted bank overlays are visible.

Excerpt of decrypted fake overlays

Stage 4: The spreader

In our tests, we noticed that both the VBScript (the heavy lifter) and the Delphi DLL have overlapping functionality for downloading the next stage via PowerShell. Although they rely on different domains, they follow the same URL pattern.

We tried accessing URLs meant for downloading the spreader. One returned nothing, while the other displayed a sequence of two PowerShell stagers before reaching the actual spreader.

In the second stager, we found several Base64-encoded URLs, but only one of them was active during our analysis. Based on comments found in the spreader code, we suspect that in previous versions or campaigns the spreader was assembled piece by piece from these other URLs. In our case, however, a single URL contained all the necessary code.

Yes, we also wondered how PowerShell could possibly accept ASCII chaos as variable/function names, but it does. After cleaning up the messy naming convention and reviewing the well-commented routines (thanks, threat actor), we were able to identify its main duties:

• Harvest emails via the MAPI namespace;
• Exfiltrate unique email addresses to the C2;
• Clean up the outbox;
• Filter the exfiltrated email addresses against a blocklist of keywords;
• Prepare a phishing email containing a malicious PDF;
• Mass-distribute the email to the filtered addresses.

One interesting point is that the spreader’s code and comments allow us to extract some useful intel:

• All comments are written in Brazilian Portuguese, which gives a strong indication of the threat actor’s origin.
• It is fairly easy to distinguish comments written by a human from those most likely generated by an AI/LLM; the latter are too formal and remarkably well-formatted. One of the human comments actually inspired the title of this article.
• One of the comments in the code reads “limpa a caixa de saida antes de sapecar”. Sapecar has a very specific meaning that only Brazilian Portuguese speakers would naturally understand. The closest equivalent to this comment in English would be: “Clear the outbox before you blast it off or let it rip.”

Our team tracked Horabot activity for a few months and compiled a collection of malicious attachment examples used in this campaign. They are all written in Spanish and urge the user to click a large button in the document to access a “confidential file” or an “invoice”. Clicking the button triggers the same infection chain described in this article.

Detection engineering and threat hunting opportunities

After navigating this long, layered attack chain, we bet some of the tech folks reading this have already started imagining potential detection opportunities.
With that in mind, this section provides some rules and queries that you can use to detect and hunt this threat in your own environment.

YARA rules

The YARA rules focus on two core components of the operation: the AutoIt script that functions as the loader, and the Delphi DLL that serves as the banking Trojan.

Hunting queries

You may notice that some patterns in this section do not appear in the URLs described earlier in the article. These additional patterns were included because we observed small variations introduced by the threat actor over time, such as the use of QR codes in the lure pages.

IoCs