Campaña de malware en GitHub: repos SEO-pointed empujan el infostealer Rapuncel

Por qué este descubrimiento importa

El 18 de septiembre de 2026, LastPass y Delphos Labs publicaron un informe conjunto que documenta una campaña activa de malware sin un perfil técnico público detallado hasta ahora. Bautizaron al ladrón como Rapuncel, y el vector de distribución es lo más preocupante: repositorios falsos en GitHub, optimizados para SEO, que aparecen en los primeros resultados cuando un sysadmin busca software legítimo como LastPass Authenticator, KeePass, Notion, 1Password, Slack, Trezor o cualquier otra herramienta popular. En total, la campaña suplanta al menos 40 marcas de software conocidas.

Lo que hace a esta campaña diferente de los ClickFix y los repos basura del año pasado no es el payload: es la combinación de un infostealer nuevo, un EDR killer firmado por Microsoft, y una cadena de distribución que evade sandboxes inflando archivos hasta 148 MB. Si diriges un homelab Linux o un clúster pequeño y usas Windows como host de gestión, este caso te toca de cerca. Aunque el malware es Windows-only, el vector — búsqueda en Google → repo falso → descarga — es idéntico a cómo muchos sysadmins localizan binarios nuevos.

Qué se anunció exactamente: la anatomía de Rapuncel

El informe de LastPass y Delphos Labs describe tres componentes en la cadena de ataque:

Componente	Nombre técnico	Qué hace
Instalador legítimo renombrado	vsdbg.exe (Microsoft Visual Studio CoreCLR Debugger)	Punto de entrada. El binario es auténtico pero se usa para hacer sideload de la DLL maliciosa vsdbg.dll
EDR killer firmado	Alinubx.sys (disfrazado como nvfsflt64.sys / servicio NvFsFilter)	Driver en modo kernel que mata 145 procesos de antivirus y EDR con ObOpenObjectByPointer en KernelMode, bypasseando PPL
Infostealer	Rapuncel	Roba credenciales de 25 navegadores, 30 wallets de cripto, Discord/Steam/Telegram, Windows Credential Manager, archivos con nombres password/seed/wallet/recovery, screenshots y datos del sistema

La atribución publicada en el informe, con grado de confianza moderado, es que Rapuncel es una variante de BoryptGrab, y que el loader se compiló con el crypter Cruciferra PUROSANGUE. Esa dupla (crypter comercial + stealer con marcas renombradas) se ha vuelto habitual en el bajo mundo desde 2024; lo nuevo aquí es la combinación con un driver firmado por Microsoft, lo que vuelve a la cadena muchísimo más silenciosa de lo que sería sin el certificado válido. Defender y la mayoría de EDR actuales suelen generar telemetría rica sobre drivers cargados en el sistema, pero confían en la blocklist de HVCI para bloquear los conocidos — y este no está en ella todavía.

Lo que también conviene tener presente: si te toca responder a un incidente similar, la telemetría que más rápido acota el blast radius es la del driver, no la del infostealer. El driver se carga en el primer reinicio posterior a la infección, registra un servicio (en este caso NvFsFilter), y deja rastro en el event log del sistema mucho antes de que el ladrón haya exfiltrado cualquier cosa. Esa ventana es la que aprovecha un equipo con buena monitorización para contener el incidente antes de que se pierdan credenciales de producción.

Cómo funciona el driver que mata antivirus

El detalle técnico más interesante — y el que más debe preocuparte si haces respuesta a incidentes — está en Alinubx.sys. Los investigadores explican exactamente por qué los productos protegidos con Protected Process Light (PPL) caen igual:

// Fragmento conceptual del driver (pseudocódigo basado en el informe)
// El driver pide al kernel abrir el handle directamente en modo kernel,
// evitando el path normal user-mode SeAccessCheck.
status = ObOpenObjectByPointer(
    &EProcess,
    0,                     // user-mode flags ignorados
    NULL,
    KernelMode,            // AccessMode=KernelMode (clave del bypass)
    *PsProcessType,
    KernelMode,
    &handle);
if (NT_SUCCESS(status)) {
    ZwTerminateProcess(handle, 0);   // mata el AV/EDR
}

Una vez que entiendes este patrón, lo que queda en evidencia es que cualquier driver en modo kernel, firmado por un certificador de la cadena de Microsoft, tiene esta capacidad. Por eso la defensa correcta no es “bloquear drivers desconocidos” sino auditar constantemente qué drivers están cargados en tu endpoint. Una verificación manual rápida desde PowerShell corre en menos de cinco segundos:

# Listar drivers cargados que no estén firmados por vendors esperados.
# Exporta a CSV para revisar después en una hoja de cálculo.
Get-WmiObject Win32_PnPSignedDriver |
  Select-Object DeviceName, DriverProviderName, Manufacturer, IsSigned, Signer |
  Where-Object { $_.IsSigned -eq $true -and
                 $_.Manufacturer -notmatch 'Microsoft|NVIDIA|Intel|Realtek|AMD|Broadcom|Qualcomm' } |
  Export-Csv -NoTypeInformation C:tempdrivers-sospechosos-$(hostname).csv
# Cualquier fila con Manufacturer='Unknown' o sin signer conocido es candidata
# a investigación. NvFsFilter no aparecería en una lista limpia de un Dell/Lenovo
# con Windows estándar.

¿Por qué importa este detalle? Porque PPL es el mecanismo que usan Symantec, CrowdStrike, SentinelOne, Defender y casi todos los EDR comerciales para protegerse incluso de un administrator con SYSTEM. El driver bypassea ese control pidiendo al kernel que abra el proceso como código de kernel — un nivel de privilegio que un driver legítimo solo obtiene si está firmado por un certificador confiable. Y aquí está la trampa: este driver sí está firmado, a través de la cadena Windows Hardware Compatibility Publisher de Microsoft. No aparece en la lista de drivers vulnerables de Microsoft, lo que significa que los EDR con política de driver blocklist no lo van a parar por default.

Por qué GitHub: el truco del SEO y los ZIP inflados

La distribución no es un exploit de día cero: es ingeniería social de búsqueda. Los operadores hicieron lo mismo que hacen los afiliados a programas de afiliados deshonestos con blogs de cupones — produjeron decenas de repos públicos con descripciones y nombres optimizados para las consultas más rentables, y los subieron a GitHub para aprovechar su peso SEO. Cuando un sysadmin busca “LastPass Authenticator download” en Google, los primeros tres o cuatro resultados incluyen repos falsos que replican el README, muestran badges de “verified” o “official” falsos (los repos de GitHub los dibujan los atacantes en el HTML), y un botón “Download” prominente.

Lo que ocurre al hacer clic es una cadena de redirecciones — el detalle técnico, no la cantidad — que lleva a un servidor de entrega del payload. Lo que se descarga es un ZIP con un tamaño artificialmente inflado hasta 148 MB:

# Inspección rápida del archivo (después del unzip)
$ unzip -l Authenticator_Setup.zip
   0  09-15-2026 10:23   Authenticator_Setup/
   0  09-15-2026 10:23   Authenticator_Setup/data/
148M  09-15-2026 10:23   Authenticator_Setup/data/payload.bin   # relleno inerte
 56K  09-15-2026 10:23   Authenticator_Setup/setup.exe           # vsdbg.exe renombrado
 12K  09-15-2026 10:23   Authenticator_Setup/setup.dll           # vsdbg.dll maliciosa
# Fíjate: el tamaño del binario "relleno" es el truco para evadir escaneo.
# Muchas soluciones suben a sandbox archivos pequeños. 148 MB cruza el umbral
# de "demasiado grande para emular" en configuraciones por defecto.

Si tu endpoint ejecuta el binario, vsdbg.exe es el debugger legítimo de Microsoft, así que ni Windows Defender ni muchos EDR van a levantar alerta de “binario desconocido”. El sideload de vsdbg.dll — la DLL maliciosa que vive al lado — es lo que carga Rapuncel y Alinubx.sys en orden: primero el driver desactiva las defensas, después el stealer empieza a robar.

Qué roba exactamente Rapuncel

El informe lista los blancos del infostealer con una cobertura que da cuenta de por qué LastPass (gestor de credenciales) tomó el caso como prioridad:

Categoría	Alcance / método
Navegadores web	25 navegadores soportados (Chrome, Edge, Brave, Opera, Vivaldi, etc.). La app-bound encryption de Chrome/Edge se rompe inyectando una DLL helper y usando el Elevation Service interno del navegador
Wallets de cripto	30 wallets (extensiones de Chrome y apps locales). Busca archivos wallet.dat, *.key, bases de LevelDB/RocksDB específicas
Aplicaciones de mensajería	Discord, Steam y Telegram — extrae tokens de sesión persistentes que permiten relogin sin contraseña
Windows Credential Manager	Volcado completo del vault vía CredEnumerate
Archivos sueltos	Búsqueda recursiva de archivos cuyo nombre contenga password, seed, wallet o recovery
Capturas	Screenshot de cada monitor conectado (no solo el primario)
Datos del sistema	Hostname, IP pública (vía API externa), versión de OS, listas de software instalado

El exfiltrado se hace con un request HTTP formateado sobre TCP crudo, no HTTPS ni DNS tunneling — sale directo al endpoint 2.26.126[.]50. Eso es una decisión operacional de los atacantes: el tráfico sin TLS es trivial de dumpear con un sniffer local si estás en el segmento correcto, pero viaja sin levantar alertas de TLS-intercept en productos que solo inspeccionan certs válidos. En la práctica, este patrón requiere que cualquier defensa en profundidad esté observando el flujo IP-puerto, no solo el flujo TLS. La consecuencia operativa es directa: si tu IDS/IPS está en modo “sólo SSL/TLS”, esta exfiltración pasa por debajo del radar. Sumado a que el puerto destino puede ser cualquiera (no hay negociación TLS que fuerce 443 o 8443), el outbound es indistinguible de una llamada HTTP legítima como la de un script interno que use cURL en modo debug.

Cómo proteger tu entorno hoy

Lo que el informe y la realidad práctica recomiendan se resume en cinco controles:

1. Solo descargar software desde el sitio oficial, no desde resultados de Google (incluso si el repo de GitHub parece “oficial”). El atajo sofwareoficial.com/download reduce casi todo el riesgo de esta clase de campañas, porque los repos SEO-poisoning viven en posiciones orgánicas altas, no en la URL canónica del vendor.
2. Bloquear los ZIP >100 MB de fuentes externas en el mail gateway o en el filtro del endpoint. El umbral de 148 MB no es aleatorio — muchos sandboxes sub-files a partir de cierto tamaño sin ejecutar, o aplican timeouts agresivos. Una regla simple en el EDR (“alertar sobre cualquier ZIP entrante >50 MB desde correo o descarga web”) habría parado esta campaña antes del primer clic. Si quieres reforzar con un script PowerShell que aplica la regla en endpoints sueltos, esta es la base mínima:

# FSRM rule a nivel Windows Server: rechazar archivos ZIP >50MB
# que lleguen desde Downloads o email temporal. Ajustar umbrales según política.
Import-Module FileServerResourceManager
New-FsrmQuota -Path "C:Users*Downloads" -Description "Cuota ZIP entrante" -Size 50MB
New-FsrmFileScreen -Path "C:Users*Downloads" `
  -Description "Limita ZIPs sospechosos" `
  -IncludeGroup "Zip Files" `
  -FileScreenFlags Active | Out-Null
# Si el entorno es mixto (la laptop de gestión es Linux), en el host Linux usa:
# auditd + inotifywait, y descarta cualquier descomprensión que produzca >50MB
# en /tmp o en ~/Downloads sin ticket abierto en el helpdesk.

3. Forzar firma de driver con la lista HVCI de Microsoft y vigilar los servicios con nombres similares a drivers legítimos. Alinubx.sys se disfrazó como nvfsflt64.sys y se registró como servicio NvFsFilter. Una regla básica: alertar sobre cualquier servicio nuevo cuyo binario está en %SystemRoot%System32drivers pero no está firmado por NVIDIA, Microsoft, Intel o tu vendor de EDR. El Centro de Seguridad de Windows y Microsoft Defender for Endpoint tienen directivas de HVCI que se pueden endurecer.
4. Activar WDAC (Windows Defender Application Control) con una política que solo permita binarios firmados por vendors conocidos. WDAC en modo “allow Microsoft + signed by trusted signers” habría bloqueado el sideload de vsdbg.dll aunque vsdbg.exe sea legítimo — porque vsdbg.dll no tiene firma válida.
5. Monitorizar el vault de Windows Credential Manager. Cualquier modificación masiva al vault desde un proceso que no sea explorer.exe, runas.exe o tu gestor corporativo, debe alertar. El truco del Windows Credential Manager es que muchos sysadmins ni lo miran — confían en los navegadores, pero ahí se guardan los RDP, las credenciales de sistemas internos, los tokens de servicios antiguos.

Por qué Linux no es invulnerable (el ángulo para sysadmins)

Rapuncel es Windows-only, así que el titular fácil sería “Linux está a salvo”. Esa lectura es peligrosa por dos razones. La primera: la infraestructura de búsqueda delata a cualquiera que busca herramientas multiplataforma en Google. Si tu laptop personal es Linux pero tu máquina de trabajo es Windows, el mismo clic equivocado te expone. La segunda: la técnica del SEO poisoning se replica trivialmente a tutoriales de Linux — ya hemos visto campañas similares con falsos instaladores de Docker Desktop, falsos builds de Portainer, falsos scripts de Netdata, y supuestos paquetes de Helm listos para producción.

Para un sysadmin que vive en Linux, lo accionable hoy es empezar a recolectar indicadores de compromiso (IOCs) en una capa central y no esperar al primer incidente. Aunque Rapuncel no toca tus servidores Linux, los IOCs publicados sirven para escribir reglas que detectan familiar de malware en cualquier endpoint Linux o Windows de la flota. Aquí va un ejemplo mínimo ejecutable en el propio host, sin dependencias externas:

# Reglas rápidas (no son YARA; son un grep simple) para el C2 conocido.
# Útil para triage manual cuando un endpoint empieza a llamar a IPs raras.
# IOCs publicados en el informe LastPass/Delphos:
C2_IP="2.26.126.50"
SERVICE_NAME="NvFsFilter"
DRIVER_HASHES=()  # los hashes SHA-256 vendrán en el IOC oficial
# 1. Buscar conexiones activas al C2 desde la red interna.
ss -ntp 2>/dev/null | grep -E "${C2_IP//./.}:" || 
  echo "Sin conexiones activas al C2 detectado."
# 2. Buscar driver disfrazado en cualquier Windows de la red (vía rpcclient).
#    Si en tu flota todo es Linux, sustituí este paso por wmi con Packer/Ansible.
for host in $(cat /etc/soylinux-fleet.txt); do
  rpcclient -U "$DOMAIN_USER%$DOMAIN_PASS" "$host" -c 
    "enumdrivers" 2>/dev/null | grep -i nvfsflt && 
    echo "⚠️  $host tiene un driver NvFsFilter cargado. Investigar."
done
# 3. Si tienes logs centralizados (Graylog/Loki/ELK), cargá los IOCs al SOAR.
#    La regla de detección es trivial: cualquiera conexión outbound al IP
#    sospechoso con duración >3s y volumen >1KB.

Si operas un clúster pequeño y te alcanza con un edge gateway, puedes sumar la capa de reputación en el borde de la red también:

# Bloqueo en el firewall perimetral (iptables o nftables, da igual el sabor).
# El principio es el mismo: si tu servidor de salida no tiene nada legítimo
# que hablar con 2.26.126.50, el default es DROP.
iptables -I FORWARD -d 2.26.126.50 -j DROP       # Linux bridge/gateway
iptables -I OUTPUT   -d 2.26.126.50 -j REJECT     # host individual con curl
# Una vez bloqueado, este IP te queda como negative cache en cualquier SIEM.
# mira los logs de las últimas 24h para detectar intentos previos.
grep "2.26.126.50" /var/log/syslog /var/log/kern.log 2>/dev/null | head -20

La defensa correcta es tratar cualquier binario de fuentes no oficiales como hostil por default, validar el SHA-256 contra la página del vendor (no contra la que te devolvió Google), y mantener el hábito de descargar desde github.com/<vendor>/<repo>/releases, no desde resultados promovidos por SEO. Si tu flujo de trabajo es Linux puro, conviene recordar que las campañas de SEO poisoning se adaptan — la próxima oleada podría perfectamente apuntar a administradores de Debian/Ubuntu buscando PPA, scripts de instalación de Helm, o charts de Kubernetes.

Veredicto: vale la pena tomar este en serio, ya

El motivo por el que este caso aparece en soylinux no es el payload en sí — es la confirmación empírica de que la cadena de firma de drivers de Microsoft sigue siendo un vector activo para EDR killers. El informe señala directamente que Alinubx.sys “no está en la blocklist de drivers vulnerables de Microsoft”. Eso significa que si tu política de seguridad depende de esa blocklist (directamente o vía herramientas que la consumen), tienes un agujero que un atacante activo ya está explotando.

Para un sysadmin de homelab, lo accionable es simple: deja de instalar software de Windows desde “el primer resultado de Google” que parezca oficial, audita los servicios de driver que cargan en tus máquinas críticas, y revisa tu lista de fuentes confiables en el EDR. Para un equipo pequeño, endurecer WDAC + bloquear ZIP grandes + monitorizar Windows Credential Manager cubre el 90% del riesgo con cero costo en licencias. El 10% restante es la disciplina del threat hunting: revisiones semanales del event log, suscripción a IOCs oficiales, y simulacros periódicos del runbook de respuesta. Una hora por semana por endpoint no es caro si se lo mide contra el costo de un leak de credenciales de producción.

Rapuncel es solo el nombre que dimos a este ladrón. El próximo será distinto. La cadena técnica se queda: SEO poisoning → repo falso → binario legítimo renombrado → driver firmado por Microsoft → EDR muerto → robo de credenciales. Esa secuencia no se va a ir, solo va a mutar.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux