WordPress secuestrado: cómo recuperarlo sin pagar

Si tu WordPress fue secuestrado por hackers y alguien te está pidiendo plata para «limpiar» tu base de datos, no pagués. Es ransomware clásico: los atacantes toman control de tu DDBB o archivos, los cifran o modifican, y te exigen un rescate a cambio de restaurar el acceso. No hay garantía de recuperación una vez que pagás.

WooCommerce es un plugin de WordPress desarrollado por Automattic que convierte un sitio WordPress en una tienda de comercio electrónico, permitiendo vender productos y servicios en línea.

¿Qué es el secuestro de bases de datos en WordPress?

Un secuestro de base de datos WordPress es un ataque donde un tercero obtiene acceso no autorizado a tu instalación y, en lugar de robar datos silenciosamente, te lo hace saber: modifica tablas críticas, borra o cifra contenido, o instala un backdoor que bloquea tu acceso al admin. Después llegan con la propuesta: «nosotros sabemos lo que pasó, te limpiamos el sitio por X dólares o bitcoins».

Grupos como G2K operan exactamente así. No son necesariamente los mismos que te atacaron: en algunos casos son oportunistas que detectan sitios comprometidos, los atacan ellos mismos, y se ofrecen como «servicios de limpieza». En otros, el mismo actor que inyectó el malware intenta monetizarlo directamente. El patrón es idéntico al ransomware de escritorio, pero aplicado a sitios web.

La diferencia técnica con un ataque silencioso es intencional. Un hacker que quiere usar tu sitio para spam SEO no quiere que te enteres. Uno que quiere cobrarte, sí.

Señales claras de que tu WordPress o DDBB fue secuestrada

No siempre te mandan un mensaje diciendo «te hackeamos». A veces lo descubrís por los síntomas.

• Contenido que no creaste: páginas con texto en otro idioma, links a farmacias online, o artículos de spam SEO que aparecen en Google Search Console pero no en tu admin.
• Redirecciones inesperadas: usuarios que entran a tu home y terminan en otro sitio. Vos no lo ves porque el redirect suele excluir IPs conocidas o sesiones de admin.
• Error 403 o pantalla en blanco al entrar al panel: el atacante puede haber modificado wp-config.php, las credenciales de la DDBB, o directamente las tablas de usuarios.
• Usuarios fantasma en wp_users: cuentas con rol «administrator» que no reconocés, creadas en horarios inusuales.
• Valores extraños en wp_options: URLs de sitios externos en siteurl u home, o scripts obfuscados en active_plugins o widget data.
• Logs de acceso con IPs desconocidas: accesos a wp-login.php o xmlrpc.php desde rangos de IP inusuales, especialmente de noche.

Si ves dos o más de estas señales juntas, asumí que el sitio está comprometido y actuá como si lo estuviera, aunque no estés seguro.

WordPress secuestrado por hackers: cómo sucede el ataque

Ponele que tenés WooCommerce con el plugin Brands instalado y hace tres meses que no lo actualizás. CVE-2025-68519, publicado en diciembre de 2025, es una SQL injection en exactamente ese plugin. Un atacante que la explota puede leer toda tu DDBB sin autenticarse. Desde ahí, crear un usuario administrador es trivial.

No es el único vector. CVE-2025-48122 afecta Spreadsheet Price Changer for WooCommerce, y CVE-2025-11735 explota un blind SQL injection en Husky Products Filter. Los tres son de 2025 y siguen siendo relevantes en 2026 para sitios que no aplicaron parches.

Los vectores más frecuentes según el historial de ataques documentados:

• SQL injection en plugins desactualizados, especialmente ecosistema WooCommerce donde hay decenas de plugins de terceros con poco mantenimiento.
• Plugins o temas crackeados: la campaña WP-VCD, operando desde hace más de 5 años, distribuye malware embebido en temas y plugins pirata. Si descargaste algo de un sitio que no es el repositorio oficial de WordPress o el desarrollador original, podés tener una puerta trasera activa desde el día uno.
• Credenciales débiles o reutilizadas: contraseñas filtradas en breaches anteriores que siguen funcionando porque nadie las cambió.
• FTP/SSH sin restricción de IP: acceso al servidor desde cualquier IP del mundo con credenciales que quizás viajan en texto plano.

¿Y qué hacen una vez adentro? Exacto: lo que quieran. Modificar la DDBB, plantar backdoors en wp-includes o en plugins legítimos, agregar usuarios admin, insertar scripts maliciosos en el tema activo.

¿Debo pagar el rescate? Razones concretas para no hacerlo

La respuesta corta es no. La respuesta larga también es no, pero con contexto.

Primero, el técnico: no hay ningún mecanismo que obligue al atacante a cumplir. Pagás, y podés recibir una clave de descifrado que no funciona, ninguna respuesta, o la restauración de tus datos con un backdoor que queda activo para el próximo ataque. En casos documentados de ransomware web, incluso cuando se paga, el sitio vuelve a ser comprometido semanas después porque el vector de entrada original nunca fue cerrado.

Segundo, el legal: financiar un ataque informático puede tener implicancias legales dependiendo del país. En Argentina, la Ley 26.388 tipifica accesos ilegítimos a sistemas. Pagar el rescate no te convierte en cómplice, pero tampoco te protege si hay datos de terceros comprometidos (clientes de una tienda WooCommerce, por ejemplo).

Tercero: si el atacante tiene una copia de tu DDBB, el pago no borra esa copia. Tus datos de clientes, contraseñas hasheadas, información de pedidos: ya salieron. El «rescate» solo te devuelve el acceso al servidor, no controla lo que el atacante ya tiene.

Pasos inmediatos de recuperación (primeras 2-4 horas)

Si llegaste acá porque te acaban de avisar que tu sitio fue comprometido, esto es lo que hacés ahora, en orden:

• Cambiá todas las contraseñas: WP admin, FTP, SSH, usuario de DDBB (en wp-config.php), panel de hosting. Todas, aunque creas que no fueron comprometidas.
• Activá modo mantenimiento: para que los visitantes no vean contenido malicioso mientras limpiás. Un plugin o un archivo .maintenance en la raíz alcanza.
• Hacé un backup del estado actual: suena contraintuitivo, pero necesitás el estado comprometido para análisis forense. Comprimí los archivos y exportá la DDBB antes de tocar nada.
• Revisá wp_users: buscá cuentas con rol administrator que no reconocés. Eliminalas. Revisá también los timestamps de last_login si tenés algún plugin que los registre.
• Revisá wp_options: específicamente los campos siteurl, home, active_plugins, widget_text. Un valor que no reconocés o un script obfuscado ahí es señal de persistencia.
• Notificá al hosting: si usás donweb.com u otro proveedor con soporte técnico, avisales. Muchos tienen herramientas de detección de malware a nivel servidor que vos no tenés acceso desde el panel WP.

Limpiar la DDBB comprometida: técnicas paso a paso

La opción más segura y menos estresante: restaurar desde un backup limpio anterior a la fecha del ataque. Si tenés backups automáticos externos (no en el mismo servidor), esto debería resolver el problema en menos de una hora.

Si no tenés backup limpio, la limpieza manual es posible pero tediosa. Tabla por tabla:

• wp_posts y wp_postmeta: buscá posts con post_status = «publish» que no aparecen en tu admin normal, o postmeta con claves inusuales que contengan código PHP o JavaScript obfuscado.
• wp_options: usá una query para listar todas las opciones y revisá manualmente las que no reconocés. Prestá especial atención a cualquier valor que contenga eval(, base64_decode( o URLs externas.
• wp_comments: inyecciones de spam SEO en comentarios aprobados. Buscá comentarios con links a dominios externos que no deberían estar ahí.
• wp_users y wp_usermeta: eliminá cuentas no autorizadas y revisá los usermeta de las cuentas legítimas por capabilities modificadas.

Wordfence y Sucuri pueden ayudar a detectar archivos PHP maliciosos, pero tienen limitaciones. No confíes solo en ellos: una limpieza manual de las tablas críticas siempre es necesaria si el ataque fue a la DDBB.

Auditoría post-ataque: verificar que no quedó malware

Restaurar o limpiar no alcanza si el vector de entrada sigue abierto. Antes de poner el sitio online de nuevo, revisá:

• Permisos de archivos: wp-config.php debería tener 440 o 400. Directorios: 755. Archivos: 644. Cualquier archivo con 777 es una alerta.
• Timestamps de archivos PHP modificados recientemente: si wp-login.php o cualquier archivo en wp-includes tiene fecha de modificación reciente y vos no hiciste updates, lo revisás.
• .htaccess: compará con el contenido estándar de WordPress. Reglas extras que redirijan tráfico son señal clara de manipulación.
• wp-config.php: revisá que no haya código PHP inusual al inicio o al final del archivo.
• Crontabs del servidor: si tenés acceso SSH, listá los cron jobs activos. Backdoors persistentes suelen usar cron para reinstalarse si los borrás.

Tabla: métodos de recuperación y su efectividad

Método	Tiempo estimado	Efectividad	Requiere
Restaurar backup externo	30-60 min	Alta (si el backup es anterior al ataque)	Backup externo automático
Limpieza manual de DDBB	4-12 horas	Media-alta (si encontrás todo)	Acceso phpMyAdmin o SSH
Reinstalar WordPress limpio + restaurar contenido	2-4 horas	Alta (si la DDBB era la única afectada)	Backup de contenido exportado
Pagar rescate	Variable	Baja-ninguna	Dinero y confianza ciega en el atacante
Plugin de seguridad (escaneo automático)	15-30 min	Baja por sí solo (complemento, no solución)	Wordfence, Sucuri u otro

Protecciones futuras: cómo evitar que esto se repita

Backups automáticos externos, fuera del servidor principal. Si los backups están en la misma cuenta de hosting que el sitio, un atacante con acceso al servidor puede borrarlos. Usá un servicio externo o al menos un bucket S3 separado.

Actualizaciones automáticas habilitadas para WordPress core, plugins y temas. La mayoría de los ataques explotan vulnerabilidades con parche disponible hace semanas o meses. CVE-2025-68519 en WooCommerce Brands tuvo parche el mismo día que se publicó la vulnerabilidad. Los sitios que lo aplicaron no fueron afectados.

Otras medidas concretas:

• 2FA en todas las cuentas de WordPress, especialmente administradores. Un plugin como WP 2FA o el módulo de Wordfence alcanza.
• Limitar intentos de login: por defecto WordPress no tiene límite. Con Wordfence o Limit Login Attempts Reloaded, bloqueás fuerza bruta en minutos.
• Deshabilitar XML-RPC si no lo usás. Es un vector clásico para ataques de credential stuffing.
• WAF activo: un firewall de aplicación web bloquea SQL injection antes de que llegue al plugin vulnerable. Wordfence tiene uno integrado; también hay opciones a nivel DNS.
• Eliminar plugins y temas inactivos: cada plugin desactivado pero instalado es superficie de ataque. Si no lo usás, borralo.
• Restricción de acceso SSH/FTP por IP: si solo vas a administrar el servidor desde tu oficina o casa, limitá el acceso a esas IPs. Un cambio de 2 minutos en el hosting que cierra un vector enorme.

Errores comunes al responder a un secuestro WordPress

Error 1: Limpiar antes de hacer backup forense. El estado comprometido tiene evidencia. Timestamps, IPs en logs, archivos modificados. Si restaurás sin guardar eso primero, perdés la posibilidad de entender cómo entraron y cerrar el vector.

Error 2: Cambiar solo la contraseña de WordPress y asumir que alcanza. Si el atacante entró por FTP, todavía tiene acceso. Si entró por un plugin con SQL injection, ese plugin sigue siendo vulnerable. Cambiar la contraseña del admin no cierra ninguna de esas puertas.

Error 3: Confiar en que el plugin de seguridad encontró todo. Los escaneos de Wordfence y similares son buenos para detectar archivos PHP conocidos como maliciosos, pero no garantizan que encontraron todos los backdoors, especialmente si el atacante usó ofuscación personalizada o inyectó código en la DDBB en vez de en archivos.

Preguntas Frecuentes

¿Qué es G2K y por qué aparece asociado al secuestro de WordPress?

G2K es el nombre con el que se identifica un grupo o individuo que contacta propietarios de sitios WordPress comprometidos ofreciendo «servicios de limpieza» a cambio de un pago. El patrón documentado indica que en algunos casos son los propios atacantes los que primero comprometen el sitio y luego se ofrecen como solución. No existe documentación oficial que los clasifique como un grupo organizado con estructura formal, por lo que tratá cualquier contacto no solicitado de «servicios de limpieza» con el mismo escepticismo.

¿Cómo restaurar mi DDBB después del secuestro?

El método más confiable es restaurar desde un backup externo tomado antes de la fecha del ataque. Si no tenés backup limpio, necesitás limpiar manualmente las tablas wp_posts, wp_options, wp_users y wp_comments buscando contenido inusual, scripts ofuscados y usuarios no autorizados. Después del ataque, cerrar el vector de entrada (plugin vulnerable, credenciales comprometidas) es obligatorio antes de volver a poner el sitio online.

¿Debo pagar el rescate si piden dinero por limpiar mi web?

No. El pago no garantiza la recuperación, no asegura que el atacante elimine copias de tus datos, y no cierra el vector de entrada original. En casos documentados, sitios que pagaron rescate fueron comprometidos nuevamente semanas después porque el backdoor seguía activo. La recuperación desde backup o mediante limpieza manual es siempre preferible.

¿Cuáles son las señales de que mi WordPress fue secuestrado?

Las más claras son: usuarios administradores desconocidos en wp_users, redirecciones a sitios externos que solo ven los visitantes (no vos logueado), contenido de spam SEO que aparece en Google pero no en tu editor, y valores extraños en wp_options especialmente en siteurl o active_plugins. Si encontrás cualquiera de estas señales, asumí compromiso total y actuá en consecuencia.

¿Cómo proteger mi sitio WordPress después del ataque?

Las prioridades post-ataque son: backups automáticos externos (fuera del servidor), 2FA en todas las cuentas admin, actualización inmediata de todos los plugins y temas, eliminación de plugins crackeados o de fuentes no oficiales, y un WAF activo para bloquear SQL injection. Con estas medidas básicas en orden, los ataques de tipo ransomware web se vuelven significativamente más difíciles de ejecutar.

Conclusión

Si te llegó un mensaje de G2K u otro grupo diciendo que tienen acceso a tu WordPress y quieren cobrarte por limpiarlo, estás frente a un ataque de ransomware web. El vector de entrada más frecuente en 2026 son plugins WooCommerce con vulnerabilidades de SQL injection sin parchear, y la respuesta correcta nunca es pagar.

Lo que sí funciona: restaurar desde un backup externo limpio, limpiar manualmente la DDBB si no tenés backup, cerrar el vector de entrada (actualizar el plugin vulnerable, cambiar todas las credenciales), y después implementar las protecciones que deberían haber estado antes: backups externos automáticos, 2FA, WAF, y actualizaciones automáticas habilitadas.

El costo de recuperarse de un ataque sin backup es de horas o días de trabajo. El costo de un backup externo automático es prácticamente cero. Sacá tus propias conclusiones.

Fuentes

• CriptoNoticias – Ransomware secuestra portales WordPress y pide rescate en bitcoins
• WP Firewall – CVE-2025-68519: SQL injection en WooCommerce Brands
• Ameeba – CVE-2025-48122: SQL injection en Spreadsheet Price Changer for WooCommerce
• ZeroPath – CVE-2025-11735: Blind SQL injection en Husky WooCommerce
• Session Studio – Me hackearon el WordPress: guía de recuperación 2026