🚨Qué hacer si tu WordPress fue hackeado: guía de emergencia paso a paso

Son las 11 de la noche de un viernes. Revisás Analytics antes de cerrar y ves algo raro: picos de tráfico a URLs que no existen, tasa de conversión despanzurrada, alerta de Google Search Console avisando "engañoso o malicioso". Abrís tu sitio y por fuera parece normal, pero cuando entrás al admin de WordPress hay un usuario admin_backup que no recordás haber creado, y la carpeta wp-content/uploads/2026/04/ tiene archivos .php raros.

Tu WordPress está hackeado. Y cada hora que pase sin acción, el daño crece.

Esta guía es lo que hacemos en Drokio cuando un cliente nos llama con una emergencia así. Orden exacto, acciones específicas, errores comunes que debés evitar. No es reemplazo de contratar un profesional si el caso es grave — es el plan si decidís manejarlo vos mismo o mientras llega ayuda.

Primeros 15 minutos: contener sin destruir evidencia

La tentación es borrar todo y restaurar desde backup. Resistilo. Hay cosas que tenés que hacer ANTES de tocar archivos.

No borres todavía

Los archivos maliciosos son evidencia forense. Te dicen cómo entró el atacante (necesario para cerrar el vector) y qué hizo (necesario para saber qué limpiar). Borrarlos en pánico te deja ciego.

Qué hacer: no tocar archivos ni base de datos hasta terminar el diagnóstico (siguientes pasos). Si la urgencia de sacar el sitio es extrema (por ejemplo, está sirviendo malware a clientes), pasá al paso "aislar" en lugar de borrar.

Aislar el sitio (opcional pero recomendado)

Si el sitio está causando daño activo (sirviendo malware, redirigiendo clientes, robando tarjetas en checkout), sacalo de producción temporalmente.

Opciones:

• Activar modo mantenimiento desde el panel del hosting.
• Agregar un .htaccess que bloquee todo excepto tu IP: Deny from all + Allow from [tu IP].
• Apuntar el dominio a una página estática temporal.

El sitio queda inaccesible para clientes mientras investigás. Perdés ventas esas horas, pero evitás comprometer a más clientes.

Cambiar contraseñas críticas

Desde un dispositivo que NO sea el que usás para el sitio (idealmente otro navegador en otra máquina): cambiá contraseñas de:

• Panel del hosting (cPanel, Plesk, hPanel).
• SFTP / SSH al servidor.
• Admin de WordPress (los que reconozcas — a los desconocidos los borrás después).
• Base de datos MySQL.
• Email asociado al dominio.
• Cualquier servicio third-party con acceso al sitio (Stripe, MailChimp, analytics).

Si alguna contraseña estaba guardada en el navegador de la máquina infectada, considerala comprometida.

Backup del estado actual (comprometido)

Sí, aunque esté infectado. Te sirve para análisis forense y rollback de emergencia si tu limpieza rompe algo.

Hacé snapshot desde el hosting (Backup ahora) o via SFTP copiá wp-content/, wp-config.php, y un dump de la base de datos (wp db export via wp-cli o phpMyAdmin). Guardalo en un directorio etiquetado pre-limpieza-[fecha].

Diagnóstico: identificar el vector de entrada

Limpiar sin encontrar cómo entraron es garantía de reinfección. Pasás días limpiando, el atacante vuelve a entrar por la misma puerta, y volvés a empezar. La prioridad ahora es entender por dónde entró.

Revisar logs de acceso

Tu hosting guarda logs de acceso HTTP (Apache/Nginx). Miralos.

Desde cPanel/hPanel buscás Raw Access Logs o similar. Bajás los últimos 7-30 días de logs y los abrís con un editor que maneje archivos grandes.

Busca:

• Requests a archivos .php en uploads/ → webshell upload.
• POSTs a /wp-login.php de IPs diferentes a las tuyas → brute force exitoso.
• Requests a /xmlrpc.php con patrones de amplificación → brute force via XML-RPC.
• Accesos a archivos con nombres raros en wp-content/plugins/ o wp-content/themes/ → exploit de plugin vulnerable.
• Requests a /wp-admin/admin-ajax.php con params sospechosos → exploit de plugin via AJAX.

El timestamp del primer request sospechoso es aproximadamente cuándo entraron.

Revisar archivos modificados recientemente

En SSH:

find /var/www/html -type f -mtime -30 -name "*.php"

(cambiá /var/www/html por tu ruta real y -30 por los días a revisar).

Listará archivos PHP modificados en los últimos 30 días. Revisá cada uno que no reconozcas: functions.php del theme, wp-config.php, archivos en uploads/.

Revisar usuarios de WordPress

Desde la base de datos directamente (no confíes en wp-admin — puede estar manipulado):

SELECT user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC;

Usuarios registrados recientemente que no reconocés = sospechosos. Ver también wp_usermeta buscando wp_capabilities con administrator para ver todos los admins.

Revisar tareas programadas de WordPress

Malware persistente suele agendar tareas vía wp_cron.

SELECT option_value FROM wp_options WHERE option_name = 'cron';

Devuelve el array serializado de cron events. Buscá hooks con nombres raros (no estándar de WordPress ni de tus plugins conocidos).

Limpieza completa

Con el diagnóstico hecho, empezás a limpiar. Orden recomendado: core → plugins → themes → uploads → base de datos → usuarios.

Core de WordPress

Reemplazá TODO el core con una copia oficial limpia.

Descargá WordPress de wordpress.org (misma versión que tenés, o actualizá a la última si es compatible). Via SFTP, reemplazá:

• Todo en la raíz excepto wp-config.php y .htaccess (los revisás manualmente después).
• La carpeta /wp-admin/ completa.
• La carpeta /wp-includes/ completa.

NO reemplaces /wp-content/ (ahí viven tus plugins, themes, uploads — lo tratamos aparte).

Plugins

Opción segura: reinstalar todos los plugins desde cero.

1. Listá los plugins instalados (anotá versiones).
2. Desactivá todos desde wp-admin (o moviendo /wp-content/plugins/ a /wp-content/plugins-backup/).
3. Borrá los archivos de plugins.
4. Reinstalá uno por uno desde el repositorio oficial o desde el vendor.
5. Verificá hashes SHA-256 si tenés desconfianza.

Themes

Mismo tratamiento que plugins. Reinstalá el theme activo desde fuente oficial. Borrá themes inactivos (son superficie de ataque).

Uploads (el más delicado)

wp-content/uploads/ es donde viven las imágenes, PDFs y archivos que subieron vía WordPress. No debería haber archivos .php ahí. Cualquier .php en uploads es sospechoso.

find wp-content/uploads -name "*.php" -type f

Revisá cada uno. Si ninguno es legítimo (plugins mal diseñados a veces ponen archivos PHP ahí — verificá con el vendor), borralos.

Para archivos con extensiones normales (jpg, png, pdf), la técnica pro es comparar hashes con backup pre-incidente. Si no tenés backup pre-incidente, tenés que confiar en que el atacante no escondió payload en imágenes (posible pero raro).

Base de datos

Las infecciones profundas inyectan en la base de datos también. Buscá:

• Posts con código JavaScript/PHP embebido:

  SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%eval%' OR post_content LIKE '%base64_decode%';
  

• Options con valores sospechosos:

  SELECT option_name FROM wp_options WHERE option_value LIKE '%eval%' OR option_value LIKE '%base64%';
  

• Usermeta sospechoso:

  SELECT * FROM wp_usermeta WHERE meta_value LIKE '%eval%';
  

Cualquier registro sospechoso: copialo aparte, analizalo, borralo si es malicioso.

Usuarios

Borrá todos los usuarios administradores que no reconozcas (los que identificaste en diagnóstico). Antes de borrar, reasigná sus posts a un admin legítimo.

Para los admins legítimos restantes: rotá sus contraseñas y activá 2FA obligatorio.

Verificación: ¿quedó limpio?

Limpiar sin verificar es peor que no limpiar. Dos horas de trabajo para quedarte con malware persistente es doble derrota.

Scanner múltiple

Corré MÚLTIPLES herramientas (los atacantes evaden la herramienta que más conocen):

• Wordfence scan (gratis).
• Sucuri SiteCheck (online, gratis).
• Drako initial scan (después de instalar).
• Comando manual: find / -name "*.php" -newer /tmp/reference_file para encontrar cualquier php reciente en todo el filesystem.

Si todas dan clean, probablemente estás bien.

Revisar integridad del core

WP-CLI tiene comando para verificar core:

wp core verify-checksums

Alerta si algún archivo del core tiene hash distinto al oficial. Si hay discrepancias, volvé a reemplazar esos archivos con copia limpia.

Monitorear 4 semanas

Las primeras 4 semanas después de la limpieza son las críticas. Si quedó un backdoor que no detectaste, suele reactivarse en ese período (el atacante intenta re-entrar).

Drako te ayuda acá: monitorea 20+ archivos críticos cada 6 horas y envía alerta inmediata ante cualquier cambio. Si durante las 4 semanas post-limpieza hay alerta, actuá rápido — probablemente es el atacante intentando volver.

Prevención: cerrar la puerta

La limpieza es reactiva. Sin prevención, el ciclo se repite.

1. Identificá el vector original y cerralo específicamente:

   • ¿Plugin vulnerable? Actualizado o reemplazado.
   • ¿Contraseña débil? Cambiada + 2FA.
   • ¿Webshell en uploads? Regla .htaccess que bloquea ejecución PHP ahí (Drako lo hace).
   • ¿Brute force via XML-RPC? XML-RPC desactivado.

2. Hardening completo: si no tenías plugin de seguridad, instalá uno. Drako cubre las 7 capas básicas automáticamente.

3. Backups diarios con verificación mensual: restaurá backup en staging una vez al mes para comprobar que funciona.

4. Logs fuera del servidor: si te hackean de nuevo, los logs en el servidor comprometido no son confiables. Mandá logs a un servicio externo (Papertrail, Loggly free tier, o similar).

5. Monitoreo activo: alerta inmediata ante cambios no autorizados. Sin esto, el próximo hackeo va a durar semanas antes de que te enterés.

Notificaciones legales

Según el caso:

• Payment processor: si procesabas tarjetas, notificá a Stripe/Wompi/MercadoPago. Tienen protocolos específicos y pueden requerir forensia.
• Clientes afectados: si hubo filtración de datos personales, aplican leyes de notificación. En Colombia, Ley 1581; en México, LFPDPPP; en Europa, GDPR. Generalmente 72 horas para notificar.
• Autoridades: CSIRT nacional (CERT-CO en Colombia, UNAM-CERT en México) puede ayudar con inteligencia. Denuncia penal si hubo daño cuantificable — la policía cibernética tiene divisiones especializadas.

Cierre

Un hackeo de WordPress es estresante. Pero con plan claro y disciplina, la mayoría se resuelven en horas o días sin daño permanente. Lo que NO hay que hacer: ignorarlo, minimizarlo, o "ver qué pasa mañana". La ventana de oportunidad para contener es las primeras 24 horas; después, la reparación se vuelve exponencialmente más cara.

Y la mejor guía de emergencia es la que nunca tenés que usar. Prevención sólida vale más que limpieza heroica.