De ‘Nezha’ a ‘Ghost RAT’: así funciona la nueva cadena de ataque contra webs que empieza en phpMyAdmin y termina con control total del servidor

Por /
Compartir en Pinterest Compartir en WhatsApp

Una investigación de Huntress, corroborada por Hispasec, ha documentado por primera vez el uso de Nezha —una herramienta open-source de monitorización— como pieza central de una intrusión a servidores web. La campaña, activa desde agosto de 2025, arranca con log poisoning (inyección de comandos en registros) a través de phpMyAdmin/MariaDB, deja un web shell estilo China Chopper, se gestiona con AntSword, despliega un agente Nezha para operar la máquina y culmina instalando Ghost RAT con persistencia. El grupo, con nexo probable con China, habría comprometido más de 100 sistemas, principalmente en Taiwán, Japón, Corea del Sur y Hong Kong, con casos en Europa y América.

La cadena de ataque, paso a paso

  1. Acceso inicial por phpMyAdmin expuesto
    • Panel accesible sin autenticación por una mala configuración/DNS.
    • Actor cambia el idioma a zh-CN, indicador cultural/lengua de trabajo.
  2. Log poisoning en MariaDB
    • Activación de general query log y redirección del fichero a la ruta web con extensión .php (traversal + falta de restricción de extensión).
    • Inserción del web shell (una one-liner PHP con eval($_REQUEST[1])) oculto entre entradas de log.
    • Petición GET/POST de control para validar y usar el backdoor.
  3. Operación con AntSword
    • El servidor web (Apache httpd.exe) lanza procesos hijo con comandos calcados a la terminal virtual de AntSword (indicadores stag/etag).
    • Cambio de directorio a C:\Windows\Cursors\ (ruta “discreta” pero legítima).
  4. Despliegue de Nezha (RMM/monitorización)
    • Descarga de live.exe (agente Nezha) y config.yml desde Cloudflare Pages rism.pages[.]dev.
    • El agente llama al servidor de mando c.mid[.]al (HostPapa, Dublín).
    • La consola Nezha (vista sin autenticación al dashboard de salud) mostraba >100 agentes conectados; locale en ruso.
  5. Desactivación de defensas y payload final
    • Apertura de PowerShell elevado; exclusiones de Defender con Add-MpPreference -ExclusionPath 'C:\WINDOWS'.
    • Ejecución de x.exe en C:\Windows\Cursors\ → Ghost RAT (familia Gh0st), persistente como servicio “SQLlite” (sic) en System32\SQLlite.exe y DLL 32138546.dll.
    • C2: gd[.]bj2[.]xyz → 45.207.220[.]12 (mismo IP que operaba AntSword).

Huntress aisló y erradicó el incidente eliminando web shell, agente Nezha y Ghost RAT antes de objetivos adicionales.

Qué tiene de nuevo y por qué preocupa

  • Nezha como “operador” post-explotación: herramienta legítima, liviana y lista para automatizar tareas, barata de adoptar y con plausible deniability frente a malware a medida.
  • Log poisoning “de libro”: funciona en stacks tipo XAMPP donde Apache y MariaDB corren con el mismo usuario y SUPER en la BD, práctica frecuente en entornos de prueba mal promovidos a producción.
  • Infra cambiante y “comoditizada”: dominios y servicios en Cloudflare Pages, VPS europeos, ASN nuevos y proveedores poco transparentes (MoeDove LLC).
  • Victimología alineada con intereses geopolíticos en Asia oriental, más casos dispersos globales.

Indicadores de compromiso (IoCs)

Archivos y hashes

Ruta / RecursoDescripciónSHA256
C:\xamp\htdocs\123.phpWeb shell (PHP)f3570b...d16
C:\Windows\Cursors\live.exeAgente Nezha9f3309...7de6
C:\Windows\Cursors\x.exeGhost RAT (loader)7b2599...c958
C:\Windows\System32\SQLlite.exePersistencia (renombrado rundll32)82611e...799
C:\Windows\System32\32138546.dllDLL maliciosa35e0b2...10f3

Infraestructura / dominios / IP

TipoValorNota
IP inicial acceso54.46.50[.]255AWS HK (ASN 16509)
Operación web shell / C245.207.220[.]12ASN 53808 (MoeDove)
Loader Nezharism.pages[.]dev/microsoft.exeCloudflare Pages
C2 Nezhac.mid[.]al → 172.245.52[.]169HostPapa (Dublín)
C2 RATgd[.]bj2[.]xyz → 45.207.220[.]12DGA/XYZ pattern

Artefactos / marcas

ClaveValor
Servicio persistenteSQLlite
Mutexgd.bj2[.]xyz:53762:SQLlite
Ruta stagingC:\Windows\Cursors\

Bloquee/monitoree esos dominios/IPs y busque servicio “SQLlite”, ejecutables en C:\Windows\Cursors\ y tareas/servicios creados tras conexiones de httpd.exe (Apache).

Mapeo MITRE ATT&CK (alto nivel)

  • Initial Access: T1190 (Exploited Web App) / T1133 (External Remote Services, si hay WinRM/RPC).
  • Execution: T1059.001 (PowerShell), T1106 (API Nativa), T1059.008 (SQL).
  • Persistence: T1543.003 (Create/Modify Service), T1053.005 (Scheduled Task).
  • Privilege Escalation/Defense Evasion: T1112 (Modify Registry), T1562.001 (Disable AV), T1036 (Masquerading: SQLlite.exe).
  • C2: T1071.001 (Web), T1573 (Encrypted Channel).
  • Discovery: T1082 (System info), T1033 (Account Discovery).
  • Collection/Exfil: dependiente de módulos RAT.

Reglas prácticas de defensa

1) Aplicaciones web / WordPress / phpMyAdmin

  • Nunca exponga phpMyAdmin a Internet; si es imprescindible, VPN, IP allowlist y auth fuerte.
  • XAMPP/WAMP solo para desarrollo local; si migra a producción, separe cuentas de servicio (Apache ≠ MariaDB, sin SUPER) y suba versiones no EoL.
  • En MariaDB: deshabilite general_log por defecto; AppArmor/SELinux para impedir escritura en htdocs.
  • WAF/CDN con reglas para file-write sospechoso y log poisoning; CSP + subresource integrity.

2) Detección en servidores

  • EDR: alertas cuando httpd.exe (o php-cgi) engendra procesos (PowerShell/cmd/curl).
  • SIGMA sugerida – Conhost-spawned PowerShell: title: Conhost-Spawns-PowerShell logsource: { category: process_creation, product: windows } detection: sel: ParentImage|endswith: '\conhost.exe' Image|endswith: '\powershell.exe' condition: sel level: high
  • Buscar ejecutables/DLL en System32 con nombres mal deletreados (p. ej., SQLlite.exe) y servicios recientemente instalados.

3) Respuesta y erradicación

  • Aislar el host; copias forenses de htdocs, my.cnf, logs Apache/MariaDB.
  • Eliminar web shell, revocar credenciales, limpiar servicios/tareas y restaurar binarios de sistema.
  • Reinstalar la pila web/DB en versiones soportadas; rotar secretos y revisar allow-list en firewall.
  • Hunting en el entorno por conexiones a IoCs y por beacons de Nezha/RAT.

4) Concienciación y hardening

  • Playbooks de web-shell hunting (hashes, greps por eval, assert, base64_decode).
  • Revisiones periódicas de paneles/entornos de prueba expuestos por DNS o shadow IT.
  • Least privilege real en servicios (cuentas dedicadas sin SUPER, sin escritura en rutas web).

Por qué este caso importa a toda la industria

  • Abuso de open-source: Nezha es legítimo y útil; su abuso baja el coste de operación y dificulta la atribución.
  • Commoditización de la intrusión: web shell + AntSword + RMM + RAT es una fábrica repetible y difícil de ver con controles de perímetro clásicos.
  • Superficie realista: paneles phpMyAdmin/XAMPP y servidores WordPress mal protegidos siguen siendo la puerta en muchas pymes.

Checklist “en 60 minutos”

  • Quitar de Internet phpMyAdmin / poner tras VPN.
  • Ver si Apache ha lanzado PowerShell/cmd/curl.
  • Buscar C:\Windows\Cursors\ y System32\SQLlite.exe / servicio SQLlite.
  • Bloquear rism.pages[.]dev, c.mid[.]al, gd.bj2[.]xyz, 45.207.220[.]12, 54.46.50[.]255.
  • Revisar functions.php y logs MariaDB (general log) por one-liners con eval.
  • Actualizar Apache/PHP/MariaDB y separar cuentas de servicio.

Mensaje final: si su aplicación web está en Internet, alguien la probará. El salto de “panel mal expuesto” a “RAT persistente” puede ocurrir en minutos. La diferencia entre incidente y anécdota es hardening, visibilidad y respuesta entrenada.

vía: huntress y unaaldia.hispasec

Compartir en Pinterest Compartir en WhatsApp

Entradas relacionadas

Scroll al inicio