Cómo limpiar un WordPress hackeado paso a paso

El día que descubrí mi primer WordPress hackeado

Recuerdo perfecto la primera vez que abrí un sitio cliente y vi en lugar de la página de inicio una pantalla negra con texto en árabe pidiendo donaciones para no sé qué causa. Fue hace doce años, era viernes a las once de la noche, y el cliente recién había contratado pauta para el lunes. Esa noche aprendí muchas cosas a la mala. Una de ellas fue que tener un WordPress hackeado no es cuestión de si va a pasar, sino de cuándo.

Desde entonces limpié sitios por decenas. Algunos eran ataques juveniles de defacement. Otros eran operaciones serias de redirección con miles de dólares en juego. Y aprendí un protocolo que funciona casi siempre. Lo voy a compartir aquí, paso a paso, sin atajos que después te muerdan.

Si tu sitio está hackeado ahora mismo, respira. Cierra esta página un segundo, ponte un café y vuelve. La prisa es mala consejera cuando estás reparando algo crítico. Empezamos.

Cómo confirmar que de verdad tienes un WordPress hackeado

Antes de armar el operativo de limpieza, confirma el diagnóstico. A veces lo que parece un hackeo es solo un plugin mal configurado o una caché que se rompió. Hay señales claras que sí indican compromiso real.

Los redireccionamientos no autorizados son la señal más común. Cuando alguien entra a tu sitio desde Google y termina en una página de apuestas o farmacia rusa, hay malware metido en algún lado. Otra señal típica es la aparición de nuevos usuarios con rol de administrador que tú no creaste. Revisa la tabla wp_users desde phpMyAdmin si hace falta.

Los archivos modificados recientemente también son delatores. Si tu wp-config.php tiene fecha de modificación de ayer y tú no lo tocaste, algo huele mal. Lo mismo con archivos extraños en wp-content como nombres aleatorios tipo j47x8.php o carpetas con nombres tipo wp-cache que no deberían existir.

Google Search Console te avisa si detectó software malicioso o ingeniería social. Esa advertencia es seria. Significa que tu sitio ya está en listas negras y vas a perder tráfico hasta que limpies y reportes la corrección.

Herramientas para escanear y confirmar

Antes de tocar archivos, escanea. Wordfence en modo escaneo profundo te muestra archivos del núcleo modificados, archivos sospechosos en wp-content y comparaciones contra el repositorio oficial. Sucuri SiteCheck es un escáner online gratuito que analiza la versión pública del sitio y detecta inyecciones visibles. MalCare es otra opción potente, especialmente para tiendas grandes.

Aislar el sitio antes de cualquier limpieza

Aislar significa cortar el oxígeno al atacante y proteger a los visitantes. Lo primero que hago es activar el modo mantenimiento. Plugins como WP Maintenance Mode bloquean el frontend mostrando una página neutra mientras tú trabajas atrás. Si el sitio ya está totalmente comprometido y no puedes ni entrar al panel, edita el .htaccess para devolver un 503 con un mensaje breve.

Después cambio todas las contraseñas asociadas. Y cuando digo todas, son todas. Hosting, panel de control cPanel o Plesk, base de datos, FTP, SFTP, SSH, usuarios de WordPress con permisos elevados, correos vinculados a recuperación, y cualquier API key configurada. Si tu atacante todavía tiene credenciales válidas, limpiar es inútil porque vuelve a entrar.

Hago una copia completa del sitio comprometido antes de tocar nada. Tanto archivos como base de datos. Esta copia sirve como evidencia forense y como red de seguridad por si algo sale peor durante la limpieza. La guardo en un disco externo, nunca en el mismo servidor.

Documenta todo lo que vas haciendo. Yo abro un bloc de notas con horas y acciones. Cuando llevas seis horas reparando un sitio a las tres de la mañana, el cerebro se nubla y olvidas qué probaste y qué no.

Limpieza de archivos del sitio

Aquí viene la parte que más miedo da pero es la más sistemática. Mi enfoque es reemplazar todo lo que se pueda reemplazar con originales limpios y revisar manualmente solo lo que es único de tu sitio.

Empiezo descargando la versión exacta de WordPress que tienes instalada desde wordpress.org. La descomprimo y sobreescribo en tu servidor todas las carpetas wp-admin y wp-includes, además de los archivos sueltos del directorio raíz. Excepto wp-config.php y .htaccess que reviso manualmente. Este paso elimina cualquier modificación maliciosa en archivos del núcleo.

Después voy a wp-content. Aquí necesito quirúrgica. Los plugins los reinstalo todos descargándolos otra vez del repositorio oficial. Si tienes plugins premium, descárgalos de la cuenta del desarrollador, nunca de versiones nulled. Lo mismo con el tema activo: si es de un marketplace serio, vuelve a bajarlo. Si es un tema custom, ahí toca revisar archivo por archivo.

La carpeta uploads requiere atención especial. Aquí los atacantes esconden shells PHP con nombres de imagen. Busca cualquier archivo .php dentro de wp-content/uploads y elimínalo sin compasión. No debería haber código ejecutable en uploads, nunca.

Revisar archivos sospechosos comunes

Hay patrones típicos que reviso siempre. Archivos llamados wp-cron.php en ubicaciones raras, archivos con extensión .ico que en realidad son PHP, código ofuscado con base64 o eval dentro de plugins, comentarios extraños al inicio de functions.php. Una búsqueda con grep por eval(base64 o gzinflate suele encontrar varios sospechosos en minutos.

Limpieza de la base de datos

La base de datos es el segundo escondite favorito de los atacantes. Aunque limpies los archivos al cien por ciento, si dejaste código malicioso en wp_options o wp_posts, el sitio se reinfecta solo en cuestión de horas.

Reviso primero la tabla wp_users. Cualquier usuario con rol administrator que no reconozcas, lo elimino. También reviso wp_usermeta buscando capabilities sospechosas asignadas a usuarios de bajo rango. He visto subscribers que tenían permisos de admin gracias a un meta inyectado.

En wp_options busco entradas anómalas. Cualquier opción con scripts JavaScript inyectados en valores que deberían ser texto plano. Revisa siteurl y home asegurándote que apuntan a tu dominio correcto, no a un dominio extraño. Y revisa las opciones autoload que cargan en cada petición porque ahí esconden persistencia.

Las tablas wp_posts y wp_postmeta requieren búsquedas por patrones sospechosos. Iframes ocultos, scripts externos, enlaces a dominios desconocidos, codificaciones extrañas en el contenido. Un script SQL bien hecho puede limpiar miles de posts en minutos, pero hazlo después de tener un respaldo a buen recaudo.

Cambio de claves y credenciales tras la limpieza

Después de la limpieza viene otro round de cambios. Genera nuevas claves de seguridad en wp-config.php usando el generador oficial de WordPress. Esto invalida todas las cookies y sesiones activas, expulsando a cualquier sesión que el atacante haya dejado abierta.

Cambia la contraseña del usuario de base de datos. Tienes que actualizar también la línea DB_PASSWORD en wp-config.php. Si no haces este paso, el sitio deja de funcionar. Lo mismo con la contraseña FTP y de panel de hosting.

Reinstala los certificados SSL si tienes razones para pensar que las claves privadas se vieron comprometidas. Es paranoico, lo sé. Pero cuando manejas tiendas con pagos, la paranoia es virtud.

Por último, fuerza el reseteo de contraseña a todos los usuarios del sitio. Sí, todos. Aunque parezca exagerado. El atacante pudo haber obtenido hashes de la base de datos antes de que tú limpiaras, y con tiempo y poder de cómputo esos hashes ceden.

Verificación final y reapertura

Antes de reabrir el sitio al público, ejecuto un escaneo completo de nuevo. Wordfence en profundidad, Sucuri externo y una revisión manual a la carpeta uploads. Pruebo el sitio desde el navegador en modo incógnito, simulo búsquedas desde Google, reviso los logs de Apache o Nginx para detectar peticiones raras.

Si todo se ve limpio, desactivo el modo mantenimiento. Pero el trabajo no termina ahí. Reporto el sitio como limpio en Google Search Console solicitando revisión. Suelen tardar entre veinticuatro y setenta y dos horas en quitar la advertencia. Mientras tanto, monitoreo logs cada hora para detectar cualquier intento de reentrada.

Avisa a tus clientes si manejas datos personales. Es desagradable, pero la transparencia construye confianza. Y en muchos casos es obligación legal según la naturaleza del incidente.

Prevención para que no vuelva a pasar

Limpiar un WordPress hackeado sin cambiar lo que falló es prepararse para el siguiente hackeo. La causa raíz casi siempre es una de estas: plugin desactualizado, contraseña débil, tema nulled o falta de copias para detectar el problema temprano.

Implemento autenticación de dos factores obligatoria para todos los administradores. Instalo un plugin de seguridad serio con escaneo diario. Configuro copias automáticas a destino externo. Reviso plugins instalados y desinstalo todo lo que no se usa activamente. Documento qué versión de PHP corre el servidor y la actualizo a 8.3 si está atrasada.

Programo un mantenimiento mensual donde aplico actualizaciones, reviso logs y verifico que las copias se puedan restaurar. Veinte minutos al mes pueden ahorrar veinte horas de reparación cuando algo sale mal.

Preguntas frecuentes sobre WordPress hackeado

¿Cuánto tiempo toma limpiar un WordPress hackeado?

Depende de la profundidad del compromiso. Un hackeo superficial con redirecciones puede limpiarse en dos a cuatro horas. Un compromiso serio con shells múltiples y persistencia en base de datos puede llevar entre uno y tres días. Si es ecommerce con miles de productos, súmale revisión de pedidos uno por uno.

¿Es mejor restaurar una copia antigua o limpiar el actual?

Si tienes una copia limpia anterior al hackeo y no perdiste contenido importante, restaurar es más rápido y seguro. Si el hackeo lleva semanas activo y no sabes desde cuándo, limpiar el actual es la única opción viable porque cualquier copia disponible ya estaría comprometida.

¿Puedo limpiar yo mismo o necesito un especialista?

Para sitios pequeños con conocimiento técnico básico, sí puedes con paciencia y siguiendo un protocolo. Para tiendas, sitios con tráfico alto o casos donde hay datos sensibles, contrata a alguien con experiencia. El costo de hacerlo mal supera por mucho el costo del especialista.

¿Cuánto cuesta contratar a alguien para limpiar un sitio?

En Perú los rangos van desde trescientos soles para sitios pequeños hasta tres mil o más para tiendas grandes. Servicios internacionales como Sucuri o Wordfence Response cobran entre doscientos y mil dólares según el caso. Pide referencias y exige garantía de reentrada gratuita por treinta días.

¿El hackeo afecta mi posicionamiento SEO?

Sí, y bastante. Google penaliza sitios con malware y reduce su visibilidad hasta que se limpie y se solicite revisión. Si el ataque incluyó inyección de enlaces SEO negativo, la recuperación puede llevar meses. Cuanto antes limpies y reportes a Search Console, mejor.

¿Debo avisar a mis clientes que el sitio fue hackeado?

Si hubo posible exposición de datos personales, contraseñas o información de pago, sí. Es obligación ética y muchas veces legal. Para hackeos cosméticos sin exposición de datos, no es obligatorio, pero la transparencia siempre suma confianza a largo plazo.

¿Cómo evito que el mismo hackeo se repita?

Identifica el vector de entrada y ciérralo. Actualiza todo, cambia todas las contraseñas, implementa autenticación de dos factores, elimina plugins innecesarios, instala un firewall serio y configura copias externas automáticas. Sin esos cambios, la limpieza es solo un paréntesis.

¿Mi hosting es responsable del hackeo?

Generalmente no. Los hackeos casi siempre vienen por vulnerabilidades en WordPress, temas o plugins, no por fallas del hosting. Solo en casos de hostings muy malos con servidores compartidos sin aislamiento se puede atribuir responsabilidad al proveedor. Pídeles que revisen logs del servidor para descartar.

¿Sirve restaurar desde la copia automática del hosting?

Sí, si la copia es anterior al hackeo. El problema es que muchas veces el hackeo lleva semanas y las copias del hosting son de los últimos siete o catorce días. Por eso insisto siempre en copias externas con histórico extendido de al menos treinta días.