Malware WordPress blockchain: el backdoor autorreparable

En pocas palabras: SC es un backdoor para WordPress, documentado por Sucuri en octubre de 2026, que se instala en ocho ubicaciones simultáneas (archivos, base de datos y memoria compartida) que se reconstruyen entre sí, y recibe órdenes de un smart contract de Ethereum a través de unos 20 gateways RPC públicos, lo que hace casi imposible eliminarlo por completo.

Un backdoor para WordPress identificado como SC vuelve a instalarse solo a los pocos segundos de borrarlo, porque vive en ocho lugares del servidor a la vez. Según el análisis de Sucuri publicado en octubre de 2026, el payload recibe órdenes vía gateways RPC públicos de Ethereum: es un caso de malware para WordPress con control remoto descentralizado.

Lo que hace a SC distinto de un backdoor cualquiera no es ningún componente individual —casi todos, por separado, ya se vieron antes en otras familias de malware para WordPress—, sino la combinación: redundancia de archivo multiplicada por redundancia fuera de disco, más un canal de control que no depende de infraestructura propia del atacante. Esa combinación es la que convierte una limpieza de rutina en un problema de varias horas, y es el motivo por el que vale la pena entender el orden de las piezas antes de tocar nada.

SC (también documentado como SC Factory X o SCFX en el análisis independiente publicado en GitHub) es una familia de malware para WordPress que combina un loader inyectado en el tema, dos drop-ins en wp-content, una copia en mu-plugins y otra en plugins, más persistencia en la base de datos y en memoria compartida. Usa un smart contract de Ethereum, leído a través de gateways RPC públicos, como canal de comando y control.

¿Por qué este backdoor de WordPress vuelve apenas se lo elimina?

Vuelve porque el payload no depende de un solo archivo. Sucuri documentó que vive en al menos ocho ubicaciones simultáneas (el disparador en .user.ini, el shim visible, el loader oculto, los dos drop-ins —db.php y advanced-cache.php—, la inyección en el tema, y las copias del plugin falso en mu-plugins y en plugins), y cada una puede reconstruir a todas las demás.

Ponele que borrás el plugin a mano. Al segundo siguiente, el drop-in db.php decodifica un blob guardado dentro de sí mismo (gzip más base64) y lo vuelve a escribir en disco. ¿Borraste también el drop-in? El tema tiene un bloque inyectado en functions.php que hace lo mismo. Es un sistema circular: no hay un punto único que al sacarlo frene todo (spoiler: ese es justamente el problema que tuvo que resolver Sucuri en esta investigación).

La trampa, para quien limpia, es que cada intento fallido parece un éxito durante unos segundos: el archivo desaparece, la carpeta queda limpia, todo bien… hasta el próximo request. Eso genera una falsa sensación de progreso y hace perder horas revisando «qué volvió a aparecer» en lugar de atacar el problema de raíz, que es el conjunto de fuentes de reconstrucción, no los archivos en sí.

¿Cuáles son los 8 componentes de la infección y cómo se regeneran entre sí?

Son ocho piezas encadenadas: un disparador en .user.ini, un shim visible, un loader oculto con tabla de strings, dos drop-ins (db.php y advanced-cache.php), una inyección en el tema y dos copias idénticas del payload (en mu-plugins y en plugins). Cada eslabón dispara al siguiente en cuanto detecta que falta algo.

El punto de entrada es .user.ini, que fija auto_prepend_file para que PHP ejecute un archivo antes de cualquier request en esa carpeta, incluso antes de que arranque WordPress. Ese archivo es un shim con nombre inocente que solo hace una cosa: si existe un archivo oculto (con punto adelante) al lado suyo, lo incluye. Si un defensor borra únicamente ese archivo oculto, el shim queda ahí sin hacer nada, silencioso, ganando tiempo hasta que otra pieza lo reconstruya. Esto se conecta con lo que analizamos en comparar herramientas para limpiar malware en WordPress.

El archivo oculto es el loader real: reconstruye el plugin falso en mu-plugins probando tres fuentes en orden (una copia existente, un stub codificado en caché, o el ZIP de respaldo), escribe con permisos 0644 y llama a opcache_invalidate para que corra de inmediato. db.php carga temprano en el bootstrap de WordPress y lleva todo el payload adentro, comprimido. advanced-cache.php es la posición más peligrosa de todas: carga antes que cualquier plugin normal cuando hay caché activa, y puede reconstruir el plugin desde cinco fuentes distintas, incluyendo una conexión directa a la base de datos usando las credenciales del propio sitio.

¿Cómo usa blockchain (Ethereum) este malware de WordPress para recibir instrucciones?

En vez de un servidor fijo, el payload lee instrucciones desde un smart contract de Ethereum usando selectores de método, y lo hace a través de aproximadamente 20 gateways RPC públicos, según detalla Sucuri. Como son gateways legítimos de terceros usados como transporte, bloquear el que aparece en los logs de tráfico no corta nada: quedan los otros diecinueve como respaldo.

Esto es lo que el reporte de GitHub firmado por el analista conocido como sonofenders llama EtherHiding: el C2 no está en un dominio que un firewall pueda bloquear con una regla, sino escondido dentro de la lógica de un contrato en la red pública de Ethereum. El loader de primera etapa que arma el plugin, en el caso que analizó este investigador, bajaba el segundo payload desde un dominio bajo TLD .sbs (de los baratos y descartables), probando wp_remote_get, luego file_get_contents y después curl_exec, con la verificación de certificado SSL desactivada a propósito en los métodos de respaldo. Ese detalle solo, la verificación SSL apagada, ya es una señal de que no es tráfico legítimo de WordPress.

Visto desde el lado defensivo, esto cambia la lógica de bloqueo que usamos hace años con C2 tradicional. Con un dominio fijo, basta una regla de firewall o un registro DNS envenenado para cortar la comunicación. Acá no: habría que bloquear el conjunto completo de gateways RPC públicos conocidos, lo cual es más parecido a bloquear «acceso a Ethereum en general» desde el servidor que a bloquear un IOC puntual. Para un sitio que no tiene ninguna razón legítima para hablar con la red Ethereum, esa regla amplia es, paradójicamente, más fácil de justificar que de implementar con precisión quirúrgica.

¿Qué hace exactamente el backdoor una vez instalado en el sitio?

Se oculta, hace fingerprint del sitio, crea un administrador invisible y mantiene un canal para recibir código nuevo. Filtra la lista de plugins, el transient de actualizaciones y las vistas de red para que su propia entrada no aparezca en el panel, y además inyecta JavaScript de administración para borrarse de la tabla como respaldo. Te puede servir nuestra cobertura de contar con backups a prueba de ransomware.

El fingerprint que envía incluye la URL del sitio, la versión de WordPress y de los plugins, hashes de rutas, el tema activo, la lista de mu-plugins y los tokens de sesión del administrador actual, todo cifrado antes de postearlo al endpoint que resuelve vía blockchain. La respuesta puede traer JavaScript para inyectar en el frontend (lo que en una tienda habilita skimming de datos de pago en el checkout), código PHP nuevo para instalar, o directamente la orden de desactivar y borrar plugins de seguridad específicos. Para el administrador oculto, el malware escribe directo en las tablas de usuarios cuando la API normal no está disponible, guarda las capacidades bajo la meta key estándar para que no aparezca en el conteo de usuarios, y forja cookies de autenticación válidas para que el atacante entre sin contraseña.

¿Dónde se esconde el malware más allá de los archivos del servidor?

Se esconde en tres lugares que no son archivos: una fila en la base de datos, un segmento de memoria compartida y tareas cron. Cualquiera de los tres puede reconstruir todo el conjunto en el próximo request, lo que explica por qué una limpieza de archivos técnicamente perfecta fracasa igual.

El payload completo vive en una fila de options con nombre aleatorio, en el mismo formato gzip más base64, y advanced-cache.php lo lee abriendo una conexión directa a la base de datos. En servidores con soporte de memoria compartida System V, hay una copia completa en RAM bajo una clave numérica fija, que sobrevive tanto al borrado de archivos como a la limpieza de la base, y en hosting compartido puede incluso pertenecer a otra cuenta. El malware también registra hooks de cron con nombres aleatorios que disparan la redeploy según programación, corridos por cron del sistema, no por tráfico de visitantes. Sucuri además observó triggers de base de datos en variantes relacionadas que recrean un administrador apenas se inserta una fila, así que borrar la cuenta no sirve de nada hasta sacar el trigger primero.

¿Cuáles son las señales de que un WordPress está infectado con SC?

Las señales más claras son archivos modificados con marcadores SC_ y tráfico saliente hacia gateways de Ethereum. Según el listado de indicadores de Sucuri, conviene revisar estos puntos:

• Bloques SC_ en db.php o advanced-cache.php: código PHP inesperado con marcadores de apertura estilo SC_ y una constante guardia.
• Bloque al final de functions.php del tema activo: fencing con marcadores de inicio y fin, a veces duplicados.
• auto_prepend_file en .user.ini, php.ini o .htaccess: apuntando a un archivo PHP oculto con punto adelante.
• Plugin falso duplicado: presente a la vez en wp-content/mu-plugins y wp-content/plugins, con contenido idéntico y una página de configuración creíble.
• ZIP con nombre hexadecimal aleatorio: en wp-content, en uploads o en una carpeta de tema.
• Fila de options con nombre aleatorio: con un blob gzip más base64 grande, y transients con prefijo tipo sc_.
• Tráfico saliente a gateways RPC públicos de Ethereum desde el servidor web.

¿Cómo limpiar correctamente un sitio infectado sin que el backdoor reaparezca?

Hay que cortar la ejecución antes de borrar nada, limpiar las copias fuera de disco antes que las de disco, y recién después eliminar todos los archivos en una sola pasada. Subís el plugin, lo borrás, vuelve a aparecer, revisás el drop-in, lo borrás, vuelve otra vez, y así en un loop que no termina hasta que se ataca el orden correcto en vez de ir pieza por pieza. Cubrimos ese tema en detalle en activar la autenticación en dos pasos en WordPress.

Sucuri remarca un detalle que mucha gente se salta: el valor de auto_prepend_file queda cacheado por PHP, así que si borrás el archivo apuntado mientras la caché sigue caliente, todos los requests PHP de la cuenta empiezan a fallar hasta que esa caché expire. Hay que neutralizar el prepend antes de tocar su destino, no al revés. Después sigue la base de datos (sacar la fila de options y revisar triggers), la memoria compartida (si el hosting la soporta) y el cron (buscar hooks con nombres raros). Recién ahí se borran los archivos: el shim, el loader oculto, los dos drop-ins, el bloque del tema y las dos copias del payload, todo en el mismo pase.

Ejemplo hipotético (ilustrativo, no es un caso real): imaginemos un sitio de ventas online, «tienda-ejemplo.com», donde el equipo técnico nota que el plugin de caché que nunca instaló reaparece cada vez que lo borra. Si ese equipo sigue el orden que describe Sucuri, la secuencia sería: primero editar .user.ini para sacar la línea auto_prepend_file y esperar a que expire la caché de PHP antes de tocar el archivo al que apuntaba; después conectarse a la base de datos para ubicar y eliminar la fila de options con el blob sospechoso, y revisar si hay triggers que recreen usuarios; luego, si el hosting lo permite, chequear memoria compartida System V por la clave numérica fija; recién en ese momento borrar en un mismo pase el shim, el loader oculto, los drop-ins, el bloque inyectado en el tema y las dos copias del plugin falso. Si el equipo invierte el orden —por ejemplo, borra primero los archivos y deja la fila de la base de datos para «después»— el próximo request de un visitante dispara advanced-cache.php, que lee esa fila y repone todo antes de que alguien note la diferencia.

¿Limpiar a mano o reinstalar todo desde cero? Criterios para decidir

No hay una respuesta única, pero a partir de lo que documentan Sucuri y el análisis de GitHub se pueden armar algunos criterios razonables para decidir entre una limpieza dirigida y una reinstalación completa (WordPress, tema y plugins desde cero, con solo el contenido restaurado):

• Si hay acceso a shell y a logs de cron del hosting: una limpieza dirigida, siguiendo el orden descrito arriba, es viable porque se puede verificar cada capa (archivos, base de datos, memoria, cron) antes de dar por cerrado el caso.
• Si el hosting es compartido, de bajo costo, sin shell ni acceso a cron del sistema: verificar memoria compartida o triggers de base de datos se vuelve casi imposible desde el panel de control estándar, así que una reinstalación completa con restauración de contenido desde un backup confiablemente anterior a la infección suele ser más rápida y más segura que perseguir cada componente a ciegas.
• Si no se puede determinar con certeza cuándo empezó el compromiso: conviene desconfiar de todos los backups recientes y priorizar la reinstalación, porque restaurar un backup que ya tenía el malware adentro repite el problema sin que nadie lo note hasta el próximo ciclo de «borro y vuelve».
• Si el sitio maneja pagos o datos de tarjetas (e-commerce): dado que el propio reporte de Sucuri menciona la capacidad de inyectar JavaScript de skimming en el checkout, el umbral para optar por reinstalación completa en lugar de limpieza parcial debería ser más bajo que en un blog o sitio institucional.

Ninguno de estos criterios reemplaza una auditoría forense completa cuando hay datos sensibles de por medio; son simplemente una forma de ordenar la decisión cuando el tiempo y el acceso técnico son limitados, que es la situación más común en la práctica.

Qué está confirmado y qué no

Está confirmado, según Sucuri y el análisis estático publicado en GitHub, que el payload usa al menos ocho ubicaciones de persistencia, que el C2 corre sobre gateways RPC de Ethereum y que existe un loader en el tema que descarga la segunda etapa desde dominios descartables de TLD .sbs.

Lo que no está confirmado: el vector de acceso inicial exacto. El propio analista de GitHub lo marca de forma explícita: encontrar el loader en functions.php no es lo mismo que saber cómo entró el atacante al servidor por primera vez, y sugiere seguir buscando una vulnerabilidad de plugin, tema o core, o una credencial comprometida (panel de hosting, SFTP o admin de WordPress), como causa raíz separada. Tampoco hay cifras públicas sobre cuántos sitios están afectados en total.

Errores comunes al tratar de limpiar este malware

• Borrar solo el archivo visible y no tocar la base de datos: el drop-in advanced-cache.php lee la fila de options directo y reinstala todo en el próximo request.
• Bloquear un solo dominio o gateway pensando que corta el C2: con cerca de 20 gateways RPC de respaldo, hay que bloquear el conjunto completo, no uno a uno.
• Restaurar un backup viejo sin verificar si ya tenía la infección adentro: si el backup se tomó después del compromiso, el malware vuelve apenas se restaura.
• Revisar solo wp-content/plugins y pasar por alto mu-plugins: la copia en mu-plugins no aparece en la pantalla de Plugins y carga de forma automática.

Preguntas Frecuentes

¿Qué es el malware SC de WordPress?

SC es una familia de malware para WordPress que instala un backdoor disfrazado de plugin de caché, con copias redundantes en mu-plugins, en plugins, en dos drop-ins y en el tema activo. Sucuri lo nombró así por los marcadores SC_ que aparecen en el código inyectado, y el analista de GitHub lo documentó por separado como SC Factory X (SCFX). Para más detalles técnicos, mirá configurar cabeceras HTTP de seguridad.

¿Por qué el malware de WordPress vuelve después de borrarlo?

Vuelve porque el payload vive en al menos ocho ubicaciones de archivos distintas (el .user.ini, el shim, el loader oculto, los dos drop-ins, el tema y las dos copias del plugin falso), y además persiste fuera de disco en la base de datos y en memoria compartida; cualquiera de esas piezas puede reconstruir a las demás en el próximo request.

¿Cómo usa blockchain (Ethereum) este backdoor para recibir órdenes?

El payload lee instrucciones desde un smart contract de Ethereum consultando cerca de 20 gateways RPC públicos con selectores de método específicos, según Sucuri. Como son gateways legítimos usados solo como transporte, bloquear uno no corta la comunicación porque quedan los demás como respaldo.

¿Cómo limpiar un sitio WordPress infectado con este malware sin que reaparezca?

Hay que cortar primero el auto_prepend_file de .user.ini, después limpiar la fila de la base de datos, la memoria compartida y las tareas cron, y recién al final borrar todos los archivos infectados en una sola pasada. Hacerlo en otro orden solo dispara una reconstrucción inmediata del componente borrado.

¿Qué archivos de WordPress hay que revisar para detectar este backdoor?

Hay que revisar wp-content/db.php, wp-content/advanced-cache.php, el functions.php del tema activo, wp-content/mu-plugins (que no aparece en el panel de Plugins) y archivos .user.ini o .htaccess con directivas auto_prepend_file. También conviene buscar archivos ZIP con nombre hexadecimal aleatorio sueltos en wp-content o uploads.

Conclusión

Lo que cambia con SC no es la cantidad de archivos que planta, sino la arquitectura: persistencia repartida entre disco, base de datos y memoria, más un canal de control que usa infraestructura pública de Ethereum en vez de un servidor propio. Eso hace que las limpiezas manuales rápidas, del tipo «borro el plugin raro y listo», fallen de manera sistemática.

Si administrás WordPress para clientes o para vos mismo, la lección práctica es simple: ante cualquier reinfección que vuelve sola, dejá de borrar archivos sueltos y empezá por la base de datos y la configuración de prepend. Y si el hosting no te da acceso a logs de cron ni a shell para verificar memoria compartida, ese también es un problema a resolver antes del próximo incidente, no un detalle menor: es, literalmente, la diferencia entre poder limpiar este backdoor o estar condenado a reinstalar desde cero cada vez que vuelva.

Fuentes

• Sucuri Blog – SC WordPress Malware: A Self-Healing Mesh of Loaders, Drop-Ins, and a Blockchain-Controlled Backdoor
• GitHub sonofenders – Análisis estático de SC Factory X (SCFX)