WordPress comprometido: admin falso y posts en ruso

En pocas palabras: Si encontrás un admin desconocido, posts en ruso y plugins que no instalaste en tu WordPress, tu sitio fue comprometido por backdoor — el vector más común en hackeos WordPress desde 2022. La recuperación exige cuatro pasos: limpiar la base de datos, verificar integridad, resetear credenciales y activar 2FA.

Si encontraste un WordPress site comprometido con admin desconocido en tu panel, publicaciones en ruso que nunca escribiste y plugins que nunca instalaste, tu sitio fue hackeado. La buena noticia: con el procedimiento correcto podés recuperarlo. La mala: cada hora que pasa, Google indexa más spam y la reputación del dominio cae más.

¿Qué es un sitio WordPress comprometido y qué implica en la práctica?

Un sitio WordPress comprometido es una instalación que un atacante externo controló de forma no autorizada, generalmente para inyectar spam, robar datos de visitantes, redirigir tráfico o usar el servidor como plataforma de ataque hacia otros sitios. Los vectores más comunes son plugins con vulnerabilidades sin parchear, fuerza bruta sobre credenciales débiles y ataques de supply chain donde el propio código del plugin viene con backdoor desde el repositorio donde lo descargaste.

WordPress corre aproximadamente el 43% de los sitios web del planeta (según W3Techs, jul 2026). Eso lo convierte en el blanco más atacado de la web. El problema casi nunca es WordPress por diseño: son plugins desactualizados, contraseñas de 8 caracteres o cuentas de hosting sin ningún segundo factor de autenticación.

Señales de alerta: cómo detectar que tu WordPress fue comprometido

La detección temprana es lo que separa una limpieza de dos horas de una crisis de dos semanas. Estas son las señales concretas que tenés que buscar:

• Usuarios administradores que no reconocés. Ir a wp-admin > Usuarios > Todos los usuarios y revisar cada cuenta con rol «Administrador». Si hay un usuario con nombre raro (números aleatorios, guiones bajos como prefijo, nombres genéricos como «support_admin») que no creaste vos, es una bandera roja.
• Posts o páginas en idiomas que no usás. Publicaciones en ruso, chino o árabe con links a casinos online o farmacéuticos. En general están configuradas como privadas o en categorías ocultas para que no las veas vos, pero sí las rastrea Googlebot.
• Plugins instalados que no instalaste vos. En wp-admin > Plugins, compará la lista contra lo que vos pusiste. Un plugin con nombre genérico tipo «WP System Manager» o «Site Performance Helper» que apareció solo merece atención inmediata.
• Google Search Console marcando el sitio como malicioso. Si GSC te manda un mensaje de «Contenido hackeado detectado» (spoiler: cuando llega ese aviso, Google ya indexó el spam hace días), el compromiso ya es público.
• Tu proveedor de hosting avisando de spam masivo. Si el hosting te notificó uso anómalo de recursos o envío de emails en volumen, el servidor está siendo usado como relay de spam hacia terceros.

¿Cómo diferenciás spam manual de inyección en base de datos? El manual lo ves en el listado de posts y podés borrarlo desde el editor. La inyección directa en wp_posts a veces no aparece en el panel o aparece con slugs sin sentido: tenés que ir a la base de datos con phpMyAdmin para verlos. Sobre eso hablamos en una herramienta de monitoreo como Sucuri.

Admin malicioso y plugins infectados: cómo los atacantes logran acceso permanente

Acá viene lo importante, y es la parte que más confunde: los atacantes no se conforman con entrar una vez. El objetivo es la persistencia.

La cadena típica funciona así: explotan una vulnerabilidad en un plugin desactualizado, una inyección de formulario o fuerza bruta sobre el login de wp-admin, entran, inyectan código PHP en la tabla wp_options para crear un usuario administrador con un nombre discreto como «_siteadmin» o un string de 8 caracteres aleatorios, instalan un plugin malicioso que en cada carga de página verifica si ese usuario existe y lo recrea si lo borraste, y se van sabiendo que aunque vos notes el usuario falso y lo elimines, el backdoor sigue activo y lo regenera antes de que termines de respirar (sí, así de frustrante).

Ese mecanismo de auto-restauración es el que confunde a la mayoría. Según la investigación de Sucuri sobre backdoors con admin oculto, este patrón de plugins que regeneran usuarios es uno de los más frecuentes en sitios comprometidos que llegan a limpieza profesional.

También existen ataques de supply chain: el plugin viene comprometido desde el repositorio donde lo descargaste. En esos casos, incluso instalar algo recién bajado puede darte un backdoor sin que lo sepas. WordPress.org no audita el código de cada plugin del repositorio de forma continua: la revisión inicial es limitada y el código puede modificarse días después de ser aprobado.

Posts en ruso y spam SEO: por qué los atacantes eligen idiomas extraños

Ponele que entrás a tu sitio y encontrás 40 publicaciones en ruso que nunca escribiste, con links a casinos online y farmacias dudosas. La razón de esos idiomas no es aleatoria.

El spam SEO en ruso tiene una lógica de negocio concreta: el mercado de backlinks para casinos y farmacéuticos no regulados en ese idioma es muy rentable. Un backlink en un dominio con autoridad puede valer varios dólares al mes en esquemas de link building negro. Multiplicá eso por miles de sitios comprometidos y tenés un negocio oscuro pero con números que cierran. El dueño de un sitio argentino probablemente notes posts en ruso tarde (si los nota). Y muchos de esos posts están configurados para ser invisibles al dueño del sitio: muestran el contenido legítimo cuando el usuario está logueado, pero el spam cuando lo rastrea Googlebot. Técnica clásica de cloaking. Más contexto en autenticación de dos factores en WordPress.

La inyección se hace directamente en la tabla wp_posts de la base de datos, con post_status configurado como ‘publish’ pero en categorías y slugs que no aparecen en la navegación normal. Para encontrarlos, tenés que ir a phpMyAdmin y ejecutar algo como SELECT * FROM wp_posts WHERE post_content LIKE '%casino%' o la keyword que corresponda.

Pasos 1 y 2: verificar usuarios y eliminar admins desconocidos desde la base de datos

Antes de tocar cualquier cosa, hacé un backup completo. Sin backup, no tenés red de seguridad si algo sale mal en la limpieza. No es negociable.

• Verificar wp_users en phpMyAdmin. Entrá a phpMyAdmin > tu base de datos > tabla wp_users. Revisá cada usuario. Los sospechosos tienen user_login con caracteres extraños, user_registered muy reciente, o user_email con dominios que no conocés.
• Confirmar que son admins maliciosos. Revisá la tabla wp_usermeta y buscá el campo wp_capabilities para el usuario sospechoso. Si dice ‘administrator’ y ese usuario no lo creaste vos, está.
• No uses el panel de WordPress si el sitio está comprometido. Si hay un backdoor activo, el panel puede regenerar el usuario antes de que termines. Hacé la limpieza por phpMyAdmin o wp-cli directo.
• Query SQL para borrar el admin sospechoso: primero confirmá el ID (SELECT ID, user_login FROM wp_users), después borrá el usuario (DELETE FROM wp_users WHERE ID = [número]) y sus metadatos (DELETE FROM wp_usermeta WHERE user_id = [número]).

¿Y si el admin vuelve a aparecer después de borrarlo? Exacto: hay un backdoor activo en archivos o en la base de datos. Pasá al paso siguiente antes de volver a verificar usuarios.

Pasos 3 y 4: limpiar plugins maliciosos y verificar integridad de archivos

Desactivar y eliminar plugins sospechosos desde wp-admin es el primer movimiento, pero no alcanza. Tenés que verificar que no haya código malicioso inyectado en plugins legítimos o en archivos del core.

• WP-CLI para verificar integridad. El comando wp plugin verify-checksums --all compara cada archivo de plugin contra los hashes oficiales de WordPress.org. Si un archivo fue modificado, lo reporta. Lo mismo con wp core verify-checksums para el núcleo.
• Buscar webshells en /wp-content/uploads. Los atacantes esconden archivos .php en la carpeta de uploads, que solo debería tener imágenes y documentos. Un find /wp-content/uploads -name "*.php" desde SSH te muestra si hay algo raro.
• Revisar .htaccess y wp-config.php. El .htaccess puede tener redirecciones maliciosas (RewriteRule que manda a otros sitios) y wp-config.php puede tener código PHP ejecutable inyectado al principio. Compará contra una copia limpia de tu versión de WordPress.
• Revisar cron jobs maliciosos. Los backdoors a veces registran cron jobs que descargan código malicioso periódicamente. Desde wp-cli: wp cron event list y buscá eventos con nombres genéricos que no correspondan a ningún plugin legítimo instalado.

Herramientas que aceleran este proceso: el escáner de Patchstack, Wordfence con su File Integrity Monitor activado, y MalCare para limpieza automatizada. Ninguna reemplaza la revisión manual, pero identifican los archivos comprometidos mucho más rápido.

Paso 5: resetear contraseñas y activar 2FA en todas las cuentas

Limpiar el sitio sin cambiar las credenciales es como poner llave nueva a una puerta con vidrios rotos. Después de la limpieza, cambiá todo en este orden: Tema relacionado: configurar 2FA para proteger accesos.

• Password del admin de WordPress. Mínimo 16 caracteres, con mayúsculas, números y símbolos. El generador de WordPress en la pantalla de edición de usuario crea uno seguro por defecto.
• Credenciales del hosting. Si el sitio fue comprometido, el atacante puede haber tenido acceso SFTP o SSH. Cambiá las credenciales del hosting también — en donweb.com podés hacerlo desde el panel de control sin necesitar soporte.
• Password de la base de datos. En wp-config.php está el usuario y password de la base. Cambiá ese password en el panel de hosting y actualizá wp-config.php con el nuevo valor.
• Email principal de recuperación. Si el atacante tiene acceso al email vinculado a la cuenta de WordPress, puede resetear la contraseña cuando quiera. Verificá que ese email tampoco esté comprometido.

Después del reseteo: activá 2FA. El plugin Two Factor (del propio equipo de WordPress) o cualquier autenticador TOTP compatible hace que un password robado no alcance para entrar. Es el cambio que más reduce el riesgo de reinfección a futuro.

Cómo prevenir ataques de supply chain: auditar plugins antes de instalar

El vector más peligroso no es el brute force: es instalar un plugin que parece legítimo pero tiene backdoor desde el repositorio donde lo conseguiste. La «seguridad» del ecosistema de plugins de WordPress tiene límites claros que mucha gente desconoce.

• Actualizaciones automáticas activadas. Para WordPress core, plugins y temas. La mayoría de los compromisos explotan vulnerabilidades que ya tienen parche. Si no actualizás, la puerta sigue abierta.
• Auditar plugins antes de instalar. Revisá la cantidad de instalaciones activas, la frecuencia de actualizaciones, los reviews y si el desarrollador tiene historial verificable. Un plugin con 200 instalaciones y sin actualizaciones en dos años es riesgo alto.
• Remover plugins que no usás. Un plugin desactivado pero instalado sigue siendo superficie de ataque. Si no lo usás, borralo.
• Monitoreo de CVE en tiempo real. Herramientas como Patchstack o WPScan te avisan cuando un plugin instalado tiene una vulnerabilidad reportada, antes de que salga el parche o lo exploten masivamente.

Herramientas para detectar y limpiar malware: qué hace cada una

¿Qué está confirmado y qué todavía no sobre estos ataques?

• Confirmado: los atacantes crean usuarios admin ocultos usando código PHP inyectado en wp_options, patrón documentado por Sucuri y Wordfence en múltiples campañas de limpieza.
• Confirmado: los plugins maliciosos pueden regenerar automáticamente usuarios borrados si el código en la base de datos permanece activo.
• Confirmado: el spam SEO con posts en idiomas extranjeros se inyecta directo en wp_posts, a veces con cloaking para que Googlebot vea el spam y el dueño no.
• Pendiente de verificación caso por caso: el alcance de cada campaña de supply chain varía según el repositorio o marketplace. No todos tienen el mismo nivel de afectación ni el mismo tiempo de exposición antes de ser detectados.
• No confirmado para todos los casos: que la limpieza desde el panel de WordPress sea suficiente sin revisión manual de base de datos y filesystem. Casi nunca lo es.

Errores comunes al intentar recuperar un WordPress comprometido

• Borrar el admin malicioso sin limpiar el backdoor. El error más frecuente. Borrás el usuario, el backdoor lo recrea en horas. Primero limpiás el código malicioso, después borrás el usuario.
• Cambiar solo la contraseña de WordPress y no la del hosting. Si el atacante tenía acceso SFTP, puede subir archivos maliciosos de nuevo. Las credenciales del hosting son igual de críticas.
• Confiar en que el scanner de seguridad «limpió todo». Los scanners detectan malware conocido. Las variantes nuevas o el código obfuscado avanzado a veces pasan sin ser detectados. El escaneo automatizado es un primer filtro, no la solución completa (que no es poco como punto de partida, igual).
• Reinstalar WordPress Core sin limpiar la base de datos. El malware puede estar en wp_posts, wp_options y wp_users además de los archivos. Reinstalar el core deja la base de datos intacta.

Preguntas Frecuentes

¿Cómo sé si mi WordPress fue hackeado?

Las señales más claras son: usuarios administradores que no creaste en wp-admin > Usuarios, publicaciones en idiomas extranjeros con links a casinos o farmacéuticas, plugins instalados que no reconocés, y avisos de Google Search Console sobre contenido malicioso. Si ves cualquiera de estas señales, tratá el sitio como comprometido y empezá la revisión de inmediato.

¿Qué hago si aparece un admin desconocido en mi WordPress?

No lo borres solo desde el panel de WordPress todavía. Si hay un backdoor activo, el usuario se va a recrear. El orden correcto es: hacé un backup completo, verificá los archivos con WP-CLI (wp core verify-checksums y wp plugin verify-checksums --all), limpiá el código malicioso en archivos y en la tabla wp_options, y recién entonces borrá el usuario administrador falso desde phpMyAdmin con una query SQL directa.

¿Por qué hay posts en ruso en mi sitio WordPress?

Son spam SEO inyectado directamente en la base de datos para monetizar tu dominio con backlinks hacia sitios de casinos o farmacias en mercados de habla rusa. Los atacantes los configuran para que Googlebot los vea pero vos no (cloaking). Para encontrarlos tenés que ir a phpMyAdmin y buscar directamente en la tabla wp_posts, porque a veces no aparecen en el listado normal del panel de WordPress. Para más detalles técnicos, mirá medidas de seguridad contra hackers.

¿Puedo recuperar mi WordPress comprometido sin ayuda profesional?

Sí, en la mayoría de los casos, si tenés acceso a phpMyAdmin y conocimiento básico de SSH o WP-CLI. El proceso requiere backup, verificación de integridad de archivos, limpieza de la base de datos, eliminación de plugins y usuarios maliciosos, reset de credenciales y activación de 2FA. Si el malware está obfuscado o el ataque fue profundo en múltiples capas, conviene un servicio de limpieza como Sucuri o MalCare que garantizan la eliminación completa.

¿Cómo eliminar plugins maliciosos de WordPress definitivamente?

Desactivalos y eliminalos desde wp-admin > Plugins. Después verificá que no hayan dejado archivos en el filesystem (especialmente en /wp-content/plugins/ y /wp-content/uploads/) y revisá la tabla wp_options en la base de datos por opciones residuales del plugin. Usá wp plugin verify-checksums --all para confirmar que los plugins que quedan no fueron modificados. Si un plugin no está en WordPress.org, ese comando no puede compararlo, así que hay que revisarlo manualmente archivo por archivo.

Conclusión

Encontrar un WordPress site comprometido con admin desconocido y posts en ruso es estresante, pero tiene solución con el procedimiento correcto. El problema más común no es la complejidad del ataque: es que se borra el síntoma (el usuario admin falso) sin eliminar la causa (el backdoor que lo regenera).

El orden importa y no es opcional: backup primero, limpieza de archivos y base de datos segundo, reset de credenciales tercero, medidas preventivas cuarto. Saltarte cualquier paso garantiza la reinfección.

Para el futuro: la auditoría de plugins antes de instalar y el monitoreo continuo de vulnerabilidades son lo que separa a los sitios que se hackean una sola vez de los que entran en ciclos de reinfección permanente. Actualizaciones automáticas activadas y 2FA en todas las cuentas de admin no son opcionales en 2026.

Fuentes

• Sucuri Blog — Malicious WordPress Plugin Creates Hidden Admin User Backdoor
• Patchstack — WordPress Malware Removal Guide
• MalCare — WordPress Hacked: What to Do
• WordPress.org Support — Help: hacker posting strange foreign posts
• Session Studio — Me hackearon el WordPress: qué hacer y cómo recuperarlo (guía 2026)