Qué hacer si tu WordPress fue hackeado: guía de emergencia paso a paso | Drokio Blog | Drokio
GuíasemergencialimpiezaWordPress
🚨Qué hacer si tu WordPress fue hackeado: guía de emergencia paso a paso
Si acabás de descubrir que tu WordPress está hackeado, parás. Respirás. Y seguís esta guía. Orden exacto de acciones en las primeras 24 horas para contener el daño y restaurar sin reinfectar.
Drokio··11 min de lectura
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.
Las primeras 4 cosas que debés hacer en los primeros 15 minutos (y qué NO hacer).
Cómo identificar el vector de entrada antes de limpiar (sino el atacante vuelve).
Limpieza completa: core, themes, plugins, uploads, base de datos, usuarios.
Verificación post-limpieza: cómo saber si el malware se fue de verdad.
Prevención: cómo cerrar la puerta para que no vuelvan.
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.
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.
Listá los plugins instalados (anotá versiones).
Desactivá todos desde wp-admin (o moviendo /wp-content/plugins/ a /wp-content/plugins-backup/).
Borrá los archivos de plugins.
Reinstalá uno por uno desde el repositorio oficial o desde el vendor.
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.
Prevení la próxima vez con Drako
Después de limpiar, instalá Drako para que este incidente no se repita. Hardening + monitoreo continuo + IA + alertas en español.
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.
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.
Hardening completo: si no tenías plugin de seguridad, instalá uno. Drako cubre las 7 capas básicas automáticamente.
Backups diarios con verificación mensual: restaurá backup en staging una vez al mes para comprobar que funciona.
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).
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.
Preguntas frecuentes
¿Cuánto tiempo toma limpiar un WordPress hackeado?
Depende del alcance. Un webshell aislado: 2-4 horas si sabés qué hacer. Infección profunda con múltiples backdoors, usuarios admin ocultos y malware persistente: 1-3 días con trabajo concentrado. Si no tenés experiencia, contratá ayuda — un especialista en WordPress forense hace en 4 horas lo que a vos te lleva 3 días, y con menor riesgo de reinfección.
¿Puedo restaurar desde backup y listo?
Si tu backup es viejo y confiable (pre-infección), sí — pero verificado. El problema es que muchos sitios están infectados semanas antes de darse cuenta, lo que significa que los backups de los últimos días también tienen el malware. Hay que identificar el momento de la infección y restaurar desde antes de eso. Si no tenés backups de esa fecha, restaurar solo es parte de la solución — hay que limpiar archivos restaurados también.
¿Necesito reportar el hackeo a alguien?
Si tu sitio procesaba tarjetas de crédito, sí — notificá a tu payment processor (Stripe, Wompi, MercadoPago) lo antes posible. Tienen protocolos específicos. Si se filtró información personal de clientes, aplican leyes de notificación (Ley 1581 en Colombia, GDPR si hay clientes UE). Si hubo daños grandes, considerá denuncia penal y reporte al CSIRT local (CERT-CO, UNAM-CERT, etc.).
¿Vale la pena pagar un servicio de limpieza profesional?
Si tu tienda genera revenue significativo (>$5K USD/mes) y vos o tu equipo no tienen experiencia en forense WordPress, sí. Sucuri, Wordfence, y servicios LATAM cobran $100-$300 por limpieza completa. Es seguro y rápido. Si tu tienda es chica y podés dedicar 2-3 días, podés hacerlo vos siguiendo esta guía. El riesgo del DIY es la reinfección por limpieza incompleta.
¿Cómo evito que vuelva a pasar?
Identificá el vector original (¿plugin vulnerable? ¿contraseña débil? ¿webshell en uploads?) y cerrá esa puerta específicamente. Instalá hardening completo (Drako cubre las 7 capas básicas). Activá 2FA. Rotá todas las contraseñas. Hacé scan mensual con múltiples herramientas (el atacante puede haber dejado backdoors redundantes). Monitoreá alertas de Drako durante las primeras 4 semanas — es el período de reinfección más probable.
¿Google va a penalizar mi sitio?
Sí, si detecta malware. Tu sitio aparece con banner rojo "engañoso" en resultados de búsqueda, y Chrome/Firefox bloquean el acceso. Para levantar la penalización: limpiá completamente, verificá en Google Search Console, solicitá revisión. Puede tardar 24-72 horas en revisar y otro par de días en reflejarse en búsquedas. Mientras tanto, el tráfico orgánico cae a cero.
Producto mencionado
🐕
Drako
El cachorro guardián
4 módulos base del ecosistema Drokio: Hardening, Integrity, Alerts y Admin. Un solo plugin, 1 sitio WordPress, $9/mes.
Wordfence vs Drokio: por qué la IA cambia las reglas del juego en seguridad WordPress
Comparación honesta entre Wordfence y Drokio. Qué hace cada uno, dónde brilla cada uno, cuándo conviene uno y cuándo el otro. Sin marketing, con trade-offs reales.
