En Python Package Index (PyPI) se han descubierto tres paquetes que, además de la funcionalidad declarada, entregan de forma imperceptible el malware previamente desconocido ZiChatBot para Windows y Linux, utilizando el servicio de chat público Zulip como infraestructura de mando y control; esto deja expuestos a los desarrolladores y a cualquier sistema donde estos paquetes pudieran haberse instalado en el período del 16 al 22 de julio de 2025 y exige una auditoría inmediata de dependencias y la verificación de indicios de infección.

Detalles técnicos del ataque

Los investigadores identificaron tres paquetes en PyPI, presentados como archivos wheel habituales con funcionalidad operativa:

• uuid32-utils — contiene un loader malicioso;
• colorinal — utiliza un módulo malicioso similar al de uuid32-utils;
• termncolor — parece un paquete inofensivo, pero declara una dependencia de colorinal y, de este modo, introduce de forma transitiva el código malicioso.

Los tres paquetes se cargaron en el repositorio PyPI en una breve ventana entre el 16 y el 22 de julio de 2025, lo que es característico de una operación de supply chain dirigida y encaja bien en la técnica Supply Chain Compromise en MITRE ATT&CK.

Mecanismo de infección en Windows

En Windows, al instalar cualquiera de los dos primeros paquetes se ejecuta una lógica oculta:

• del paquete se extrae el loader DLL terminate.dll y se escribe en disco;
• al importar la biblioteca en el proyecto, la DLL se carga automáticamente;
• terminate.dll actúa como dropper de ZiChatBot, desplegando el módulo principal del malware;
• se crea una entrada de inicio automático en el registro de Windows (una clave de tipo Run);
• el código del dropper se autodestruye, borrando sus propios rastros del host.

Como resultado, en el sistema solo permanece ZiChatBot con un punto de arranque persistente y un mínimo de artefactos evidentes, lo que dificulta el análisis retrospectivo.

Mecanismo de infección en Linux

En Linux se aplica una lógica paralela utilizando un objeto compartido:

• se extrae y ejecuta terminate.so;
• ZiChatBot se coloca en la ruta /tmp/obsHub/obs-check-update;
• para mantener la persistencia se crea una entrada en el crontab, que ejecuta periódicamente el binario malicioso.

El uso del directorio /tmp y del nombre de apariencia neutra obs-check-update reduce la probabilidad de detección en una revisión superficial del sistema.

Control mediante Zulip como sustituto del C2 clásico

La característica clave de ZiChatBot es la ausencia de un servidor de mando y control dedicado. En su lugar, el malware utiliza las REST API públicas de la aplicación de chat corporativa Zulip, interactuando con ella igual que un cliente legítimo, a través de las interfaces oficialmente documentadas de Zulip API.

El comportamiento de ZiChatBot puede resumirse del siguiente modo:

• conexión a canales/streams concretos de Zulip a través de REST API;
• recepción de órdenes en forma de payload (shellcode);
• ejecución del shellcode recibido en el sistema comprometido;
• envío de un emoji de corazón al canal de Zulip como señal de ejecución satisfactoria de la orden.

Este método de control combina varias ventajas para los atacantes:

• el tráfico hacia un servicio de chat en la nube parece legítimo y a menudo no se filtra;
• no hay un dominio o IP estáticos, característicos de un C2 tradicional;
• cambiar de workspace o de cuentas en Zulip modifica por completo la «infraestructura» sin costes de hosting.

Desde el punto de vista de MITRE ATT&CK, esto se corresponde con la técnica de uso de servicios web legítimos para mando y control (Web Service C2), observada anteriormente en grupos avanzados.

Contexto y posible relación con OceanLotus

Según los investigadores, el dropper en la campaña actual muestra un 64% de similitud con otro loader atribuido anteriormente al grupo vietnamita OceanLotus (APT32). MITRE describe a este grupo bajo el identificador G0050 como un actor que ataca selectivamente a diversas organizaciones en Asia.

A finales de 2024, OceanLotus ya había sido observado en un ataque contra la comunidad china de ciberseguridad: se utilizaron proyectos falsos de Visual Studio Code, presentados como plugins de Cobalt Strike, que al compilarse lanzaban automáticamente un troyano. En aquella campaña, los atacantes emplearon el servicio de notas Notion como canal de mando y control, utilizando un servicio en la nube público de manera análoga a cómo se usa ahora Zulip, lo que se confirma mediante análisis públicos y la documentación oficial de Notion.

La actividad actual en PyPI no puede atribuirse de forma definitiva a OceanLotus, pero la presencia de un dropper similar y el patrón repetido de uso de plataformas SaaS populares (primero Notion, después Zulip) como C2 apunta a la evolución de un mismo modelo operativo:

• desplazamiento del phishing hacia ataques a través de la cadena de suministro (IDE, repositorios de paquetes);
• enmascaramiento máximo de la infraestructura C2 como tráfico corporativo normal;
• orientación a desarrolladores y especialistas en seguridad como víctimas iniciales.

Evaluación del impacto en las organizaciones

Potencialmente quedan expuestos todos los entornos donde pudieran haberse instalado los paquetes uuid32-utils, colorinal o termncolor en el período indicado. El mayor riesgo recae sobre:

• equipos de desarrollo que utilizan PyPI directamente desde Internet en estaciones de trabajo y en CI/CD;
• infraestructuras de build y testing, donde la ejecución de código arbitrario abre el camino a la compromisión de artefactos y al «infección» de productos finales;
• organizaciones donde las estaciones de desarrollo tienen privilegios ampliados o acceso a datos sensibles.

Dado que ZiChatBot ejecuta shellcode arbitrario, una infección satisfactoria equivale en la práctica a obtener control remoto con los privilegios del usuario del proceso (y, si se ejecuta con privilegios elevados, con privilegios de administrador/superusuario). Posibles consecuencias:

• robo de código fuente, secretos de configuraciones, claves de acceso a la nube;
• sustitución de artefactos de build e introducción de código malicioso en los productos de la organización;
• movimiento lateral dentro de la red a través de estaciones de desarrollo como «puente» hacia segmentos más protegidos;
• daño reputacional en caso de distribución de paquetes comprometidos a clientes finales.

La ausencia de un C2 tradicional y el uso de Zulip complican la detección a nivel de red y la recuperación del incidente: el bloqueo de uno o dos dominios o IP no resuelve el problema, y la telemetría del tráfico hacia servicios SaaS populares suele ser menos detallada.

Recomendaciones prácticas de protección

1. Comprobación inmediata del entorno

• En todos los sistemas de desarrolladores y servidores de build, verifique los paquetes instalados:
  • pip list | findstr uuid32-utils / pip list | findstr colorinal / pip list | findstr termncolor (Windows);
  • pip list | grep -E "uuid32-utils|colorinal|termncolor" (Linux).
• Si se detectan, registre las versiones y el contexto de uso y, a continuación, elimine los paquetes:
  • pip uninstall uuid32-utils colorinal termncolor.

2. Búsqueda de artefactos de ZiChatBot

• Windows:
  • búsqueda de archivos terminate.dll y de binarios sospechosos que hayan aparecido entre el 16 y el 22 de julio de 2025;
  • comprobación de claves de inicio automático (con privilegios de administrador):
    • reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
    • reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run

    y análisis de las entradas que apunten a ejecutables no estándar en el perfil del usuario o en directorios temporales.

• Linux:
  • comprobación de la existencia de la ruta /tmp/obsHub/obs-check-update y de cualquier archivo ejecutable en su interior;
  • comprobación del planificador de tareas:
    • crontab -l con cada usuario que potencialmente haya utilizado Python;
    • revisión de los archivos crontab del sistema (/etc/crontab, /etc/cron.*) para detectar referencias a obs-check-update o tareas anómalas en /tmp.

3. Detección a nivel de red

• En la telemetría de red y los logs de proxy, revise las conexiones desde las estaciones de trabajo de desarrolladores y sistemas CI/CD hacia dominios relacionados con Zulip en horarios inusuales o con volúmenes de tráfico atípicos.
• Configure detecciones basadas en actividad anómala de API hacia servicios de chat externos (creación/lectura de mensajes desde servidores en los que dichos clientes no deberían operar).

4. Refuerzo de la cadena de suministro de dependencias Python

• Pase a utilizar un mirror interno de PyPI con lista blanca de paquetes verificados; limite el acceso directo desde las estaciones de trabajo de desarrolladores al PyPI externo.
• Implemente control de integridad de paquetes (verificación de hashes, repositorios de artefactos con firma criptográfica).
• Utilice análisis estático y dinámico para nuevas dependencias, especialmente si son desconocidas o poco utilizadas.
• Aísle los entornos de build: privilegios mínimos, acceso de red restringido (permitir solo los repositorios y actualizaciones necesarios, bloquear el acceso arbitrario a servicios SaaS externos).

5. Medidas organizativas

• Actualice las políticas internas de selección de dependencias: prohibición de importar «rápidamente» paquetes aleatorios sin revisión y aprobación.
• Ofrezca una breve formación a los equipos de desarrollo sobre los riesgos de ataques a través de repositorios de paquetes y sobre los procedimientos de verificación de nuevos módulos.
• Coordine las acciones de los equipos de seguridad y DevOps para integrar la comprobación de dependencias en el pipeline (software composition analysis).

La conclusión clave del incidente con ZiChatBot en PyPI es que los entornos de desarrollo y de build deben considerarse activos prioritarios: hay que comprobar en el plazo más breve posible la presencia de los paquetes uuid32-utils, colorinal y termncolor, eliminarlos junto con los artefactos detectados (incluidos /tmp/obsHub/obs-check-update y entradas de inicio automático sospechosas) y, a continuación, consolidar el resultado con medidas técnicas: adopción de un mirror controlado de PyPI, restricciones estrictas de acceso de red para los sistemas de build e integración en el pipeline de comprobaciones automáticas de dependencias de terceros.