Qué buscan los hackers en tu base de datos WordPress primero
Cuando analizo un sitio WordPress comprometido, lo primero que veo es que los atacantes no actúan al azar. Tienen un plan específico y una jerarquía clara de objetivos. La base de datos es el corazón de tu WordPress, y los hackers lo saben. En mi experiencia como especialista en limpieza de malware, he visto cómo los atacantes acceden a la base de datos para robar información sensible, insertar backdoors persistentes y esconder sus actividades maliciosas. Este artículo te muestra exactamente qué buscan primero y cómo protegerte.
Las credenciales de usuario: el botín más valioso
Lo primero que busca un hacker en tu base de datos WordPress son las credenciales de usuario. Cuando accedo a wp_users (la tabla donde WordPress almacena usuarios), los atacantes ya están allí. El campo user_login contiene los nombres de usuario y user_pass contiene las contraseñas hasheadas, normalmente con WordPress hash (MD5 + salting variable).
¿Por qué es tan valioso? Porque una contraseña crackeada les da acceso al panel de administración. Desde allí pueden crear nuevas cuentas de admin, cambiar configuraciones de seguridad y instalar plugins maliciosos sin levantar sospechas en los logs. He visto ataques donde el hacker roba las credenciales de un usuario editor (no admin) para mantener acceso de bajo perfil durante meses.
Lo que recomiendo siempre: implementa autenticación de dos factores (2FA) en WordPress. Plugins como Wordfence ofrecen 2FA basado en OTP (One-Time Password) que invalida cualquier credencial robada sin el segundo factor. También configura password strength requeridos en wp-config.php y fuerza cambios de contraseña periódicos.
Datos de clientes: direcciones, teléfonos y emails
Si tu WordPress tiene WooCommerce o cualquier plugin de e-commerce, la tabla wp_postmeta contiene metadatos de órdenes con información personal: direcciones de envío, números de teléfono, emails de clientes. Esto es oro puro para un ciberdelincuente. Los datos de contacto se venden en marketplaces oscuros de la dark web a spammers y estafadores.
He analizado sitios donde los atacantes modificaban wp_postmeta para inyectar código JavaScript que capturaba datos de tarjetas de crédito en tiempo real (técnica conocida como Magecart). El acceso a la base de datos les permitía persistencia: cuando limpiábamos el malware del servidor, la inyección volvía a regenerarse porque el código malicioso estaba en la base de datos misma.
Para protegerte: encripta datos sensibles con métodos como AES-256 antes de almacenarlos. Implementa un WAF (Web Application Firewall) que monitore intentos de acceso no autorizado a wp_postmeta. Y sobre todo, mantén un log detallado de accesos a bases de datos usando herramientas como Wordfence CLI para auditoría.
Opciones de WordPress: configuración comprometida
La tabla wp_options almacena toda la configuración de tu sitio: URLs, plugins activos, tema activo, credenciales de API, tokens de terceros. Cuando un hacker obtiene acceso a wp_options, controla efectivamente tu WordPress sin tocar ni un archivo.
¿Qué hacen? Insertan opciones personalizadas maliciosas. He encontrado código JavaScript malicioso almacenado como opción wp_options llamada custom_script_footer que se inyecta en cada página. O modifican home_url y siteurl para apuntar a un dominio de malware. En casos más sofisticados, inyectan opciones que ejecutan código PHP cada vez que se carga wp-load.php.
Un ejemplo real: un cliente tenía su opción admin_email comprometida. Los hackers la habían cambiado a un email controlado por ellos. Cuando generaba notificaciones de seguridad o cambios en WordPress, iban directo al email del atacante, no al administrador real. Así mantenían control invisible sobre el sitio.
Mi recomendación: usa plugins como iThemes Security o Sucuri que monitorizan cambios en wp_options en tiempo real. Implementa cambios de configuración solo desde direcciones IP whitelist. Y realiza auditorías regulares de wp_options comparando backups limpios con la configuración actual.
Posts y páginas: contenido inyectado y SEO poisoning
La tabla wp_posts es donde viven tus artículos y páginas. Los hackers la utilizan para dos cosas principales: inyectar contenido malicioso invisible y spam SEO (SEO poisoning).
El primero es más insidioso: crean posts o páginas nuevas con contenido oculto (display:none en CSS o texto blanco sobre fondo blanco) que contiene palabras clave de malware, casinos, viagra, etc. Google indexa este contenido envenenado y tu sitio aparece en búsquedas de términos maliciosos. Luego redirige a esos visitantes a sitios de estafa.
El segundo es más visible pero igual de destructivo: modifican el post_content de artículos existentes inyectando links a sitios maliciosos, redireccionadores, o código JavaScript. He visto casos donde atacantes simplemente duplicaban todos tus posts reales, pero con URLs apuntando a un dominio clonado controlado por ellos. De noche, se llevaban todo tu tráfico SEO.
Lo que defiendo: implementa versionado de contenido con plugins como WP Revisions Control. Mantén backups diarios de la base de datos (no solo archivos). Usa Wordfence para monitorizar cambios en wp_posts en tiempo real. Y audita regularmente posts que no reconoces: muchas veces están ahí ocultos esperando a que Google los indexe.
Información de plugins y temas: vulnerabilidades conocidas
Cuando acceso a wp_options busco la lista de plugins instalados (stored en plugin_list) y el tema activo. Los hackers hacen lo mismo. ¿Por qué? Porque necesitan saber exactamente qué versión tienes instalada para explotar vulnerabilidades conocidas.
Si tu base de datos revela que tienes Yoast SEO versión 13.0 (vulnerable a SQLi), el atacante sabrá exactamente cómo explotarlo. Si ves WooCommerce 2.6, sabrán que hay RCE (Remote Code Execution) disponible. La base de datos es el mapa de carreteras del atacante.
En casos avanzados, modifican la lista de plugins activos en wp_options para desactivar plugins de seguridad sin que aparezca en el panel administrativo real. El plugin sigue desactivado en la base de datos, pero WordPress cree que está activo. Eso crea un falso sentido de seguridad mientras el malware actúa libremente.
Mi recomendación: usa MalCare o Sucuri que no solo monitorean archivos, sino cambios en la base de datos a nivel de opciones y configuración de plugins. Elimina plugins desactualizados y no usados. Mantén un inventario actualizado de qué plugins deberían estar activos y compáralo regularmente con wp_options.
Metadata de usuario: permisos y roles elevados
La tabla wp_usermeta almacena metadatos de usuarios: roles, capabilities, datos personalizados. Los hackers la buscan para elevar privilegios. He encontrado casos donde atacantes asignaban rol de administrator a nuevas cuentas fantasma manipulando wp_usermeta directamente, saltándose cualquier auditoría de UI (User Interface).
También modifican capabilities: pueden otorgar edit_pages, delete_posts, manage_plugins a usuarios de bajo nivel sin que aparezca en el perfil visible. Luego usan esas cuentas comprometidas como backdoors de largo plazo.
Algo más: acceden a wp_usermeta para buscar tokens de API (si almacenas tokens de servicios externos ahí), cookies de sesión, o datos de recuperación de contraseña. Cada pieza de información es un vector potencial de ataque en cadena.
Logs y registros: borrando huellas
Aunque no es una tabla estándar, muchos plugins de seguridad guardan logs en tablas personalizadas (wp_wordfence_ips, wp_wordfence_options). Los hackers buscan y eliminan estas tablas primero. ¿Por qué? Para borrar toda evidencia de su presencia.
He visto ataques donde el primer comando ejecutado después de acceso a base de datos es DROP TABLE wp_wordfence_* o TRUNCATE wp_security_logs. Es como limpiar la escena del crimen antes de que llegue la policía.
Si no tienes logs externos (almacenados fuera de tu servidor WordPress), no tendrás prueba de qué pasó exactamente. Por eso recomiendo siempre mantener logs replicados en sistemas externos: OWASP recomienda logging centralizado como medida defensiva crítica.
Cómo proteger tu base de datos WordPress hoy
Ahora que sabes qué buscan los hackers, aquí está el plan defensivo concreto:
- Acceso a base de datos restricto: Cambia el prefijo de tablas (no dejes wp_). Limita acceso a servidor MySQL solo a localhost. Usa cuentas de usuario MySQL separadas con permisos granulares (no des ALL PRIVILEGES a WordPress).
- Monitoreo en tiempo real: Implementa Wordfence + MalCare que monitorizan cambios en wp_users, wp_options, wp_posts. Configurar alertas inmediatas si se detectan inserciones sospechosas.
- Backups diarios: Almacena backups de base de datos en ubicación externa (no en el mismo servidor). Comprueba regularmente que puedes restaurar desde backup limpio.
- Hardening de WordPress: Deshabilita edición de archivos de plugins/temas (define(‘DISALLOW_FILE_EDIT’, true) en wp-config.php). Limita intentos de login a wp-login.php. Implementa 2FA.
- Auditoría de permisos: Revisa wp_usermeta mensualmente. Elimina usuarios inactivos. No uses cuentas admin para tareas cotidianas.
- Encriptación en tránsito: Configura SSL/TLS forzado. Usa conexiones HTTPS para acceso a base de datos remota si es necesario (aunque no lo recomiendo).
- Análisis forense regular: Usa herramientas como Sucuri SiteCheck o VirusTotal para detectar malware en base de datos.
¿Qué hacer si ya sospechas compromiso de base de datos?
Si tienes indicios de que tu base de datos ha sido comprometida (usuarios extraños, opciones modificadas, posts ocultos), la prioridad es forensia antes de limpiar:
- Aísla el sitio: toma offline temporalmente para evitar propagación de malware.
- Exporta la base de datos: crea dump completo para análisis posterior. No confíes en lo que ves en phpMyAdmin (el atacante puede haberlo modificado).
- Revisa cambios recientes en wp_users, wp_options, wp_posts comparando con backup limpio anterior.
- Busca opciones personalizadas o tablas no estándar que el atacante haya creado.
- Restaura desde backup limpio conocido, no solo desde base de datos limpiada.
- Implementa los hardening measures listados arriba antes de poner el sitio online de nuevo.
Este proceso requiere experiencia real en análisis de malware. En mi experiencia, intentar limpiar por cuenta propia a menudo deja puerta trasera invisible que el atacante exploita nuevamente en semanas. INCIBE ofrece guías de respuesta a incidentes que complementan este análisis técnico.
La realidad de la seguridad de base de datos
Proteger tu base de datos WordPress no es una tarea única. Es un proceso continuo de monitoreo, auditoría y hardening. Cada tabla contiene información valiosa para un atacante: credenciales, datos de clientes, configuración de seguridad, incluso pruebas de su propia actividad maliciosa.
Lo que he aprendido después de limpiar cientos de WordPress comprometidos es que los sitios más seguros no son los que tienen las protecciones más bonitas, sino los que tienen visibilidad total sobre qué está pasando en su base de datos.
Si necesitas un análisis profesional de tu base de datos WordPress, o sospechas que has sido comprometido, puedo ayudarte. En cuanto a cumplimiento RGPD, también es crítico reportar brechas de datos de clientes correctamente.
¿Quieres una auditoría de seguridad de base de datos completa? Contacta conmigo en ManuelFolgar.com/contacto. Realizaré un análisis forense profesional de tu WordPress, identificaré vulnerabilidades específicas en tu base de datos, y te proporcionaré un plan de hardening personalizado.