Herramientas falsas de ciberseguridad en GitHub distribuyen backdoors e infostealers: más de 2.000 equipos Windows comprometidos
Detectan repositorios maliciosos en GitHub que distribuyen backdoors, AsyncRAT e infostealers. Más de 2.000 equipos Windows comprometidos. Conoce los riesgos y cómo protegerte.
GitHub se convierte en un nuevo vector de distribución de malware dirigido a profesionales de ciberseguridad
Una nueva campaña de distribución de malware está utilizando repositorios aparentemente legítimos de GitHub para comprometer equipos Windows mediante backdoors, herramientas de robo de información (infostealers) y malware diseñado para evadir soluciones de seguridad.
La investigación, publicada por la compañía de ciberseguridad Dr. Web, revela que los atacantes han modificado su estrategia para dirigirse específicamente a usuarios interesados en herramientas de administración de sistemas, automatización de análisis de redes, pruebas de seguridad y procesamiento de registros.
Según los investigadores, más de 2.000 equipos Windows han resultado comprometidos durante esta campaña.
Lo especialmente preocupante es que los atacantes no están utilizando únicamente aplicaciones fraudulentas convencionales. También están ocultando código malicioso dentro de proyectos de Visual Studio, scripts de Python y código fuente desarrollado en Go, aprovechándose de la confianza que los profesionales depositan en las herramientas de código abierto.
1. Una campaña que evoluciona: de usuarios de criptomonedas a profesionales de seguridad
La actividad maliciosa comenzó aproximadamente dos años antes de la publicación de la investigación.
En sus primeras etapas, los atacantes distribuían herramientas dirigidas principalmente a usuarios del ecosistema blockchain y videojuegos, incluyendo:
- Juegos relacionados con criptomonedas.
- Bots automatizados.
- Herramientas para videojuegos.
- Utilidades fraudulentas vinculadas a activos digitales.
Sin embargo, la campaña ha evolucionado.
Los investigadores de Dr. Web identificaron repositorios que se presentan como herramientas legítimas para automatizar tareas de ciberseguridad y administración de redes.
Uno de los ejemplos detectados es un supuesto script ligero para procesar, limpiar y dar formato a los resultados generados por Fscan, una herramienta utilizada para el escaneo de redes.
Este cambio de enfoque resulta especialmente relevante porque los usuarios de estas herramientas pueden tener acceso a información sensible, credenciales, servidores corporativos y redes internas.
En otras palabras, comprometer el equipo de un profesional de seguridad puede proporcionar a los atacantes una vía de entrada hacia entornos empresariales de mayor valor.
2. Cómo ocultan el malware dentro de proyectos aparentemente legítimos
Uno de los elementos más interesantes de esta campaña es la técnica utilizada para esconder el código malicioso.
Dr. Web encontró código incrustado en:
- Proyectos de Visual Studio.
- Scripts de Python.
- Archivos fuente de Go.
Los atacantes recurren a una técnica relativamente antigua, pero todavía efectiva: ocultar instrucciones maliciosas detrás de grandes bloques de espacios en blanco.
Esto dificulta que una revisión superficial del código permita identificar las instrucciones sospechosas.
Ejecución automática antes de compilar
En determinados proyectos de Visual Studio, el código malicioso se introduce mediante eventos de precompilación (pre-build events).
Estos eventos permiten ejecutar comandos antes de que comience el proceso de compilación.
Por tanto, un desarrollador puede abrir un proyecto aparentemente legítimo y desencadenar la ejecución de instrucciones maliciosas antes incluso de generar el ejecutable final.
Este comportamiento representa un riesgo importante en entornos de desarrollo, especialmente cuando se descargan proyectos de repositorios públicos sin verificar su procedencia.
Recomendación: nunca debe asumirse que un proyecto es seguro únicamente porque está publicado en GitHub, dispone de documentación o presenta una estructura de código aparentemente profesional.
3. Cadena de infección: PowerShell, loader y ejecución del malware
La infección comienza cuando el usuario descarga y ejecuta el proyecto malicioso.
A partir de ese momento, se inicia una cadena de ejecución que utiliza PowerShell para recuperar un enlace de descarga cifrado.
Ese enlace permite descargar un cargador modular basado en Electron, identificado por los investigadores como Microsoft.exe.
El uso de un nombre que imita software legítimo de Microsoft busca reducir las sospechas del usuario y facilitar que el archivo pase inadvertido.
Fases principales del ataque
- Distribución: el atacante publica herramientas fraudulentas en repositorios de GitHub.
- Ejecución inicial: el usuario abre o ejecuta el proyecto descargado.
- PowerShell: se recupera una dirección de descarga cifrada.
- Descarga del loader: se obtiene el archivo malicioso
Microsoft.exe. - Persistencia: el malware establece mecanismos para mantenerse activo en el sistema.
- Elevación de privilegios: intenta obtener mayores permisos.
- Evasión: modifica componentes de Windows y dificulta la detección.
- Inyección: introduce cargas maliciosas en procesos legítimos.
- Compromiso final: despliega herramientas de acceso remoto y robo de información.
Esta arquitectura modular permite separar el mecanismo inicial de infección de las cargas finales, facilitando la actualización y modificación de las capacidades del malware.
4. Seis técnicas de evasión utilizadas para evitar la detección
Uno de los aspectos más preocupantes del loader es su modo de funcionamiento denominado Mode3, que Dr. Web identifica como su configuración operativa predeterminada.
Este modo incorpora seis técnicas de evasión:
4.1. Manipulación de la relación entre procesos
El malware intenta hacer que explorer.exe aparezca como proceso padre, dificultando la identificación de la cadena real de ejecución.
Esta técnica puede complicar las investigaciones forenses y la detección basada en relaciones anómalas entre procesos.
4.2. Desactivación de Smart App Control
Modifica un valor del Registro de Windows para desactivar Smart App Control.
El objetivo es reducir las restricciones que podrían impedir la ejecución de aplicaciones no confiables.
4.3. Restauración de ntdll.dll
El loader restaura el código original de ntdll.dll desde el disco para eliminar determinados hooks introducidos por herramientas de seguridad.
Esto puede interferir con mecanismos de monitorización que dependen de la instrumentación de funciones del sistema.
4.4. Uso de llamadas directas al sistema
El malware utiliza llamadas directas a funciones del sistema operativo para dificultar la interceptación de sus operaciones.
Estas técnicas pueden reducir la visibilidad de determinadas soluciones de seguridad que dependen de APIs convencionales de Windows.
4.5. Manipulación de ETW
Modifica en memoria la función EtwEventWrite para suprimir determinados eventos de seguimiento y telemetría.
ETW (Event Tracing for Windows) es un mecanismo fundamental para recopilar información sobre la actividad del sistema operativo.
Su manipulación puede afectar a la visibilidad de las herramientas de monitorización.
4.6. Evasión de AMSI
El loader modifica en memoria AmsiScanBuffer, interfiriendo con el análisis de contenido realizado por AMSI (Antimalware Scan Interface).
Esto puede dificultar la detección de scripts y contenido malicioso, especialmente en escenarios que utilizan PowerShell.
5. Modo alternativo: Mode2 y manipulación de Microsoft Defender
Cuando Mode3 no consigue ejecutarse correctamente, el loader puede recurrir a un segundo mecanismo denominado Mode2.
Este modo introduce otras técnicas para facilitar la ejecución de las cargas maliciosas:
- Añade exclusiones a Microsoft Defender.
- Utiliza scripts de PowerShell.
- Descifra cargas maliciosas.
- Inyecta componentes en el proceso legítimo
RegAsm.exe.
La utilización de procesos legítimos y exclusiones de seguridad puede dificultar la identificación del comportamiento malicioso si la organización no dispone de una monitorización adecuada.
Es importante señalar que la presencia de RegAsm.exe o PowerShell no constituye por sí sola una prueba de infección. Lo relevante es analizar su comportamiento, los argumentos de ejecución, los procesos relacionados y las conexiones de red.
6. ¿Qué malware se instala en los equipos comprometidos?
La campaña distribuye tres tipos principales de cargas maliciosas.
AsyncRAT: acceso remoto al equipo infectado
AsyncRAT es un troyano de acceso remoto que permite a los atacantes controlar sistemas comprometidos.
Entre sus posibles capacidades se encuentran:
- Acceso remoto al equipo.
- Ejecución de comandos.
- Manipulación de archivos.
- Supervisión de la actividad del sistema.
- Descarga y ejecución de nuevas cargas.
Su presencia puede convertir un equipo inicialmente comprometido en una plataforma para realizar nuevas operaciones maliciosas.
Clipper: manipulación de direcciones de criptomonedas
El componente Clipper supervisa el portapapeles y sustituye determinadas direcciones de monederos de criptomonedas por direcciones controladas por los atacantes.
Por ejemplo, un usuario copia una dirección legítima para realizar una transferencia, pero el malware la sustituye antes de que se complete la operación.
Si el usuario no verifica la dirección de destino, puede enviar sus activos directamente al atacante.
Infostealer: robo de información sensible
El componente de robo de información recopila datos almacenados en el sistema.
Entre la información que busca se encuentran:
- Datos de navegación de los navegadores.
- Configuraciones de VPN.
- Archivos de configuración de clientes FTP.
- Información de cuentas de videojuegos.
- Tokens de autenticación de Discord.
Los datos robados se exfiltran mediante un bot de Telegram.
Este mecanismo permite al atacante recibir información sustraída sin depender necesariamente de una infraestructura de comando y control tradicional.
7. Eliminación de antivirus y sabotaje de las copias de seguridad
La investigación también revela que el malware intenta eliminar determinadas soluciones antivirus del sistema.
Entre los productos afectados se mencionan:
- ESET.
- McAfee.
- Malwarebytes.
Además, intenta desconectarlos de sus servidores de actualización e interfiere con los mecanismos de copia de seguridad de Windows.
Este comportamiento es especialmente peligroso porque no se limita a robar información: también busca reducir la capacidad de detección, respuesta y recuperación de la víctima.
Los investigadores identificaron asimismo un componente aparentemente inacabado que podría permitir mantener activo el loader y volver a descargarlo si es eliminado del disco.
Esto apunta a una posible evolución de la campaña hacia mecanismos de persistencia y recuperación más sofisticados.
8. Medidas de protección y remediación para empresas
La campaña demuestra que la cadena de suministro de software también puede convertirse en un vector de entrada para ataques dirigidos a profesionales de tecnología.
Las organizaciones deben considerar los repositorios públicos como fuentes externas que requieren controles de seguridad, independientemente de su popularidad o apariencia.
8.1. Controles de seguridad en GitHub
Se recomienda:
- Verificar la identidad y reputación de los autores.
- Revisar el historial de modificaciones del repositorio.
- Comprobar las dependencias utilizadas.
- Analizar los scripts de instalación y compilación.
- Evitar ejecutar proyectos descargados directamente en equipos corporativos.
- Utilizar análisis estático de código (SAST).
- Implementar análisis de dependencias y detección de secretos.
- Revisar las modificaciones introducidas en archivos de configuración de compilación.
En proyectos de Visual Studio, deben inspeccionarse especialmente los eventos de precompilación y postcompilación.
8.2. Microsoft Defender: recomendaciones de configuración
Las empresas que utilizan Microsoft Defender deben prestar especial atención a los cambios inesperados en sus políticas de seguridad.
Se recomienda:
- Mantener habilitada la protección en tiempo real.
- Activar la protección proporcionada por la nube.
- Habilitar la protección contra manipulaciones (Tamper Protection).
- Auditar las exclusiones de antivirus.
- Monitorizar cambios en las políticas de seguridad.
- Investigar modificaciones inesperadas del Registro.
- Revisar alertas relacionadas con PowerShell y ejecución de procesos.
No se recomienda añadir exclusiones indiscriminadamente para solucionar falsos positivos, especialmente en equipos de desarrollo.
8.3. AWS WAF: ¿puede proteger frente a esta amenaza?
Es importante distinguir entre protección perimetral y protección del endpoint.
AWS WAF no es una solución de protección contra malware ejecutado localmente en Windows.
No puede impedir directamente que un usuario descargue y ejecute un proyecto malicioso de GitHub ni bloquear la inyección de código dentro de procesos del sistema operativo.
Sin embargo, sí puede contribuir a proteger las aplicaciones web y los servicios publicados en AWS frente a determinados ataques relacionados con la infraestructura expuesta.
Se recomienda:
- Utilizar AWS WAF administrado con reglas de protección comunes.
- Implementar reglas de limitación de solicitudes.
- Aplicar controles específicos para las APIs públicas.
- Monitorizar las solicitudes sospechosas.
- Enviar los registros de AWS WAF a un sistema centralizado de análisis.
- Complementar la protección con AWS GuardDuty y AWS Security Hub.
Para detectar y contener malware en equipos Windows, la protección debe implementarse en el endpoint mediante EDR, antivirus y monitorización del sistema.
8.4. Monitorización mediante EDR y SIEM
La detección de esta campaña requiere correlacionar diferentes eventos.
Algunas señales que deben investigarse son:
| Indicador de comportamiento | Riesgo |
|---|---|
| PowerShell descarga archivos desde URLs desconocidas | Descarga de payload |
Ejecución inesperada de Microsoft.exe | Loader malicioso |
| Modificaciones de exclusiones de Defender | Evasión de seguridad |
| Cambios en Smart App Control | Reducción de protección |
| Manipulación de AMSI | Evasión antimalware |
| Alteraciones de ETW | Supresión de telemetría |
Inyección en RegAsm.exe | Ejecución encubierta |
| Modificaciones de procesos y persistencia | Compromiso del endpoint |
En entornos empresariales, es recomendable utilizar Microsoft Defender for Endpoint, Sysmon y un SIEM para correlacionar eventos.
8.5. Reglas YARA y análisis de indicadores
Los equipos de respuesta a incidentes deben incorporar los indicadores publicados por Dr. Web a sus procesos de investigación.
La investigación original incluye una recopilación de indicadores de compromiso (IOC) de esta campaña.
Se puede consultar aquí:
https://github.com/DoctorWebLtd/malware-iocs/blob/master/Trojan.Loader.3261/README.adoc
Estos indicadores deben integrarse en los sistemas de detección y actualizarse conforme aparezcan nuevas muestras.
9. ¿Qué hacer si has ejecutado una herramienta sospechosa de GitHub?
Si un usuario o administrador ha ejecutado un proyecto potencialmente malicioso, debe tratarse como un posible incidente de seguridad.
Las actuaciones recomendadas son:
- Aislar el equipo: desconectarlo de la red corporativa para limitar la propagación y la exfiltración.
- No borrar evidencias: conservar registros, archivos sospechosos y datos de actividad para facilitar el análisis forense.
- Investigar la ejecución: revisar PowerShell, procesos, tareas programadas, servicios y claves de inicio automático.
- Comprobar Defender: verificar exclusiones, estado de protección y modificaciones de configuración.
- Analizar credenciales: determinar qué contraseñas, tokens, cookies y configuraciones pudieron quedar expuestos.
- Revocar sesiones: invalidar tokens y sesiones de los servicios potencialmente afectados.
- Cambiar credenciales: hacerlo desde un dispositivo limpio y priorizar las cuentas privilegiadas.
- Analizar el alcance: revisar otros equipos que hayan descargado o utilizado el mismo repositorio.
- Recuperar el sistema: reinstalar o reconstruir los equipos cuando no pueda garantizarse su integridad.
Si se confirma el robo de credenciales corporativas, también deben investigarse los accesos a VPN, servicios cloud, repositorios de código y sistemas de administración.
10. El riesgo de confiar ciegamente en el software de código abierto
Esta campaña pone de manifiesto una realidad importante: el hecho de que una herramienta esté publicada en GitHub no significa que sea segura.
Los repositorios públicos son fundamentales para el desarrollo de software, la investigación de vulnerabilidades y las operaciones de ciberseguridad. Sin embargo, también pueden ser utilizados para distribuir código malicioso aprovechando la confianza de los usuarios.
El problema es especialmente relevante para los profesionales de seguridad informática, que habitualmente descargan herramientas de escaneo, scripts de automatización, utilidades de administración y proyectos de terceros.
Una herramienta que aparentemente facilita una tarea técnica puede convertirse en el primer eslabón de una intrusión mucho más compleja.
La combinación de PowerShell, manipulación de componentes de Windows, evasión de AMSI y ETW, inyección de procesos y robo de información demuestra que los atacantes están desarrollando campañas cada vez más adaptadas a los entornos técnicos.
La seguridad también empieza antes de ejecutar el código
La campaña identificada por Dr. Web demuestra que los atacantes están aprovechando la confianza depositada en las plataformas de desarrollo para distribuir malware de forma dirigida.
Los más de 2.000 equipos comprometidos reflejan el impacto potencial de esta estrategia.
Las organizaciones deben reforzar los controles sobre el software de terceros, revisar los procesos de compilación, monitorizar la ejecución de PowerShell y proteger los endpoints mediante soluciones EDR.
La principal lección es clara: ningún repositorio, herramienta o proyecto debe considerarse confiable únicamente por estar disponible en una plataforma de código abierto.
La revisión del código, la verificación de procedencia y el análisis de comportamiento deben formar parte del proceso habitual de seguridad.
Fuentes y referencias
- BleepingComputer: Fake security tools on GitHub push backdoors and infostealers
- Dr. Web: Investigación original sobre la campaña
- Dr. Web: Indicadores de compromiso – Trojan.Loader.3261
