¿Cómo limpiar un sitio WordPress infectado con malware paso a paso?

Una guía profesional para diagnosticar, contener, limpiar y reforzar un WordPress comprometido sin perder la cabeza, el posicionamiento ni la confianza de tus usuarios.

Un sitio WordPress infectado rara vez llega con música dramática. A veces aparece como una redirección absurda a una tienda de zapatillas, otras como un aviso rojo de Google, un pico extraño de consumo del servidor o un archivo llamado class-wp-cache.php que, por supuesto, no cachea nada salvo la desgracia. La ironía es fina: construimos una web para que nos encuentren, y el malware la convierte en un faro para bots, spam y buscadores ofendidos.

WordPress es el gestor de contenidos más usado del mundo; según mediciones públicas como W3Techs, impulsa alrededor del 40% de los sitios web. Esa popularidad es virtud y condena: comunidad inmensa, ecosistema brillante, miles de plugins útiles; y, al mismo tiempo, una superficie de ataque enorme. No porque WordPress sea “inseguro” por naturaleza, sino porque muchos sitios viven con plugins abandonados, contraseñas recicladas, temas pirata y copias de seguridad que existen solo en la imaginación. El castillo es sólido; la puerta, a veces, queda con la llave puesta.

Mapa rápido de la guía 🧭

1. Señales de infección en WordPress
2. Contener el incidente antes de limpiar
3. Crear una copia forense del sitio infectado
4. Diagnosticar el alcance del malware
5. Limpiar archivos del núcleo, plugins, temas y uploads
6. Limpiar la base de datos de WordPress
7. Revisar usuarios, contraseñas y accesos
8. Corregir permisos, cron jobs y configuraciones ocultas
9. Verificar que el sitio quedó limpio
10. Recuperar reputación, SEO y avisos de seguridad
11. Endurecer WordPress para evitar reinfecciones

1. Señales de que tu WordPress tiene malware 🔍

El malware en WordPress no siempre se ve como una página destruida. A menudo trabaja como humedad detrás de una pared: silencioso, persistente, dejando manchas cuando ya lleva tiempo ahí. Estas son señales habituales:

🚨 Avisos visibles

• Google muestra “Este sitio puede haber sido hackeado”.
• El navegador alerta sobre phishing o software malicioso.
• Redirecciones a casinos, sorteos, farmacias o sitios para adultos.
• Pop-ups extraños que no estaban en tu diseño.

⚙️ Síntomas técnicos

• Archivos PHP dentro de wp-content/uploads.
• Consumo anormal de CPU, RAM o procesos PHP.
• Errores 500, lentitud repentina o caídas intermitentes.
• Tareas cron desconocidas o archivos modificados recientemente.

📉 Daño comercial

• Caída brusca del tráfico orgánico.
• Emails del dominio marcados como spam.
• Pedidos o formularios sospechosos.
• Clientes preguntando por enlaces raros. Qué elegante, justo un lunes.

Importante: no empieces borrando archivos “raros” como quien arranca malas hierbas con los ojos cerrados. Puedes eliminar evidencia útil, romper el sitio o dejar intacta la puerta trasera. Primero contiene, copia y analiza.

2. Contener el incidente: parar la hemorragia antes de operar 🧯

Limpiar WordPress infectado no es solo “pasar un plugin de seguridad”. Es una respuesta a incidente, aunque sea en miniatura. Hay un antes y un después: antes, el sitio sirve contenido; después, quizá sirve malware. La diferencia entre ambos mundos puede ser una línea en .htaccess, tan pequeña como una astilla y tan dañina como una viga podrida.

2.1 Restringe temporalmente el acceso

Si el sitio está enviando malware, redirigiendo usuarios o mostrando phishing, ponlo en mantenimiento o limita el acceso por IP. Si tienes una tienda online, entiende el golpe comercial, sí; pero dejar un ecommerce infectado funcionando es como vender pan desde una panadería con humo saliendo del horno.

Opciones razonables:

• Activar modo mantenimiento desde el hosting o un archivo temporal.
• Bloquear acceso público mediante reglas del servidor, permitiendo solo tu IP.
• Pausar campañas de anuncios para no enviar tráfico a una página comprometida.
• Desactivar temporalmente tareas automatizadas sospechosas si están generando spam.

2.2 Contacta al proveedor de hosting

Un buen hosting puede revisar logs, detectar procesos sospechosos, restaurar archivos de sistema, confirmar si hay otros sitios infectados en la misma cuenta y decirte si el problema viene de permisos, FTP, vulnerabilidades conocidas o abuso de recursos. Un mal hosting responderá con un “instale un plugin”, esa poesía administrativa tan nuestra. Insiste en obtener datos: hora de modificación, IPs, rutas afectadas, procesos y alertas del antivirus del servidor.

2.3 No confíes en un único escáner

Herramientas como Wordfence, Sucuri SiteCheck, Patchstack, MalCare, ImunifyAV, ClamAV o el escáner del hosting pueden ayudar. Pero ningún escáner ve todo. Algunos detectan firmas conocidas; otros identifican comportamiento; otros solo miran desde fuera. El malware nuevo, ofuscado o escondido en base de datos puede pasar como pez bajo agua turbia.

3. Haz una copia del sitio infectado antes de tocar nada 💾

Puede parecer absurdo respaldar algo contaminado. Pero esa copia es tu fotografía de la escena. Sirve para comparar, auditar, recuperar contenido legítimo y entender cómo entró el atacante. La memoria técnica, como la memoria humana, se deforma cuando la urgencia aprieta.

Guarda:

• Todos los archivos del sitio: public_html, www o el directorio correspondiente.
• La base de datos completa en formato SQL.
• Logs de acceso y error del servidor, si están disponibles.
• Lista de usuarios administradores, plugins y temas instalados.
• Capturas de avisos de Google, Search Console, navegador o antivirus.

Si tienes SSH, puedes comprimir archivos y exportar la base de datos. Ajusta rutas, usuario y nombre de base de datos a tu caso:

tar -czf respaldo-sitio-infectado.tar.gz /ruta/del/sitio

mysqldump -u usuario_bd -p nombre_bd > respaldo-base-datos-infectada.sql

Con WP-CLI, si está disponible:

wp db export respaldo-base-datos-infectada.sql

Consejo práctico: descarga esa copia fuera del servidor. Si el atacante conserva acceso, un respaldo guardado en la misma cuenta puede ser modificado o borrado. El backup local es como una linterna en un apagón: humilde, pero cuando hace falta, vale oro.

4. Diagnosticar el alcance de la infección 🧪

Antes de limpiar, hay que saber qué se limpió y qué falta. Una infección puede estar en archivos, base de datos, usuarios, tareas programadas, reglas de servidor o incluso en credenciales externas. El error clásico es eliminar el archivo visible y celebrar. Dos días después, el malware vuelve. No era resurrección; era una puerta trasera haciendo su trabajo con paciencia de jardinero.

4.1 Revisa versiones y vulnerabilidades conocidas

Consulta la versión de WordPress, plugins y temas. Las vulnerabilidades más frecuentes en el ecosistema WordPress suelen concentrarse en plugins y temas de terceros. Informes públicos de empresas como Patchstack y Wordfence muestran año tras año que la mayoría de vulnerabilidades reportadas no están en el núcleo de WordPress, sino en extensiones. Esto no demoniza los plugins; demoniza abandonarlos.

wp core version
wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version,update

Busca:

• Plugins sin actualizar desde hace años.
• Temas “nulled” o descargados fuera de fuentes confiables.
• Plugins desactivados pero presentes en el servidor.
• Extensiones con vulnerabilidades recientes publicadas en bases como Patchstack, WPScan Vulnerability Database o NVD.

4.2 Verifica integridad del núcleo de WordPress

WP-CLI permite comparar archivos del núcleo con los checksums oficiales. Es una de las comprobaciones más limpias para detectar modificaciones indebidas en wp-admin, wp-includes y archivos raíz de WordPress.

wp core verify-checksums

Si aparecen archivos alterados en el núcleo, lo normal es reinstalar WordPress desde una fuente oficial. No “arregles” manualmente cada archivo del core salvo que sepas muy bien por qué. El núcleo debe ser aburridamente idéntico al original; ahí la creatividad es sospechosa.

4.3 Encuentra archivos modificados recientemente

Este comando muestra archivos editados en los últimos 14 días:

find . -type f -mtime -14 -ls

Para buscar PHP donde no debería haberlo, especialmente en uploads:

find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" -o -name "*.php5" \) -print

En la mayoría de sitios, wp-content/uploads debería contener imágenes, PDFs, documentos y medios, no scripts PHP. Hay excepciones raras, pero pocas. Si encuentras image.php, about.php, autoload_classmap.php o nombres “inocentes” dentro de uploads, levanta la ceja.

4.4 Busca patrones sospechosos, sin caer en paranoia

Algunas funciones son comunes en malware, aunque también pueden aparecer en código legítimo. Úsalas como pista, no como sentencia:

grep -RIn --include="*.php" "eval\|base64_decode\|gzinflate\|str_rot13\|shell_exec\|passthru\|assert" wp-content

Un archivo con base64_decode no siempre es malware; un archivo con cinco capas de ofuscación, nombres aleatorios y llamadas remotas a dominios extraños ya huele diferente. Como pescado olvidado en agosto.

4.5 Revisa archivos especialmente sensibles

• .htaccess: redirecciones, reglas extrañas, condicionales por user-agent o referer.
• wp-config.php: código añadido antes o después de la configuración legítima.
• index.php: inyecciones al inicio o al final del archivo.
• wp-content/mu-plugins: plugins obligatorios que cargan siempre.
• wp-content/advanced-cache.php y object-cache.php: drop-ins legítimos o escondites perfectos.
• .user.ini y php.ini: directivas como auto_prepend_file que cargan malware en cada petición.

5. Limpiar archivos infectados de WordPress 🧹

Aquí empieza la cirugía. No buscamos embellecer el paciente; buscamos extirpar lo comprometido y reconstruir con fuentes confiables. Antiguo contra nuevo, limpio contra contaminado, certeza contra sospecha.

5.1 Reinstala el núcleo desde wordpress.org

La forma más segura es reemplazar wp-admin, wp-includes y los archivos raíz de WordPress con una copia limpia. Conserva wp-config.php y wp-content, pero revísalos con lupa.

Con WP-CLI:

wp core update --force

Después, vuelve a verificar:

wp core verify-checksums

No borres wp-content completo si no tienes copia verificada. Ahí están medios, temas, plugins y archivos propios. Pero tampoco lo trates como territorio sagrado: es uno de los lugares favoritos del malware.

5.2 Elimina plugins y temas no confiables

Los plugins “nulled” prometen funciones premium gratis. Qué generosidad tan conmovedora: a menudo traen backdoors, spam SEO o inyecciones preparadas. Si un tema o plugin no viene del repositorio oficial, del desarrollador legítimo o de un marketplace fiable, elimínalo.

Buenas prácticas:

• Desinstala plugins inactivos. Inactivo no significa inocuo si sus archivos siguen ahí.
• Reinstala plugins desde fuentes oficiales, no sobreescribiendo versiones sospechosas sin revisar.
• Reemplaza temas abandonados. Mantén solo el tema activo y un tema oficial de respaldo si lo necesitas.
• Comprueba si el plugin vulnerable tiene parche. Si no, busca alternativa.

wp plugin update --all
wp theme update --all

Si quieres verificar checksums de plugins disponibles en wordpress.org, puedes probar:

wp plugin verify-checksums --all

Este comando solo es útil para plugins del repositorio oficial con checksums disponibles. Plugins comerciales o personalizados requieren comparación con una copia limpia del proveedor o del repositorio de desarrollo.

5.3 Limpia la carpeta uploads

wp-content/uploads es un lugar cómodo para ocultar puertas traseras porque suele tener permisos de escritura. Busca archivos ejecutables:

find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" -o -name "*.cgi" -o -name "*.pl" \) -print

Si confirmas que no pertenecen a una función legítima, elimínalos. Luego impide ejecución PHP en uploads. En servidores Apache, puedes crear o ajustar un .htaccess dentro de wp-content/uploads:

<FilesMatch "\.(php|phtml|php5|phar)$">
  Require all denied
</FilesMatch>

En Nginx, la restricción debe hacerse en la configuración del servidor, por ejemplo denegando ejecución PHP dentro de /wp-content/uploads/. Si no administras Nginx, pide al hosting que lo aplique.

5.4 Revisa .htaccess

Un .htaccess limpio de WordPress suele ser breve. El bloque estándar se parece a esto:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Desconfía de reglas que:

• Redirigen a dominios que no reconoces.
• Actúan solo sobre visitantes móviles.
• Filtran por googlebot, bingbot, referer o país.
• Contienen cadenas largas y ofuscadas.

5.5 Revisa wp-config.php

El archivo wp-config.php debe contener credenciales de base de datos, claves de seguridad, prefijo de tablas y constantes legítimas. Busca código antes de <?php, después del final, inclusiones extrañas o llamadas remotas.

Señales sospechosas:

• include o require hacia archivos ocultos.
• Variables con nombres aleatorios.
• Código codificado en base64.
• Conexiones a dominios externos.
• Modificaciones no documentadas de WP_HOME o WP_SITEURL.

Después de limpiar, regenera las salts de WordPress. Con WP-CLI:

wp config shuffle-salts

Esto cerrará sesiones activas. Incómodo, sí. Necesario, también.

6. Limpiar la base de datos de WordPress 🗄️

Muchos ataques no se conforman con archivos. Insertan JavaScript en entradas, widgets, opciones del tema o registros aparentemente anodinos. La base de datos se vuelve entonces un ático lleno de cajas: casi todo parece familiar hasta que abres una y encuentras una serpiente.

Antes de tocar la base de datos: crea una copia SQL. Una consulta mal escrita puede borrar contenido legítimo. Trabaja en staging si es posible y valida antes de ejecutar cambios masivos.

6.1 Revisa URLs principales

Asegúrate de que siteurl y home no fueron alteradas:

wp option get siteurl
wp option get home

O mediante SQL, ajustando el prefijo si no usas wp_:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

6.2 Busca scripts y iframes maliciosos

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%'
   OR post_content LIKE '%iframe%'
   OR post_content LIKE '%document.write%'
   OR post_content LIKE '%atob(%';

También revisa opciones:

SELECT option_id, option_name
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%base64%'
   OR option_value LIKE '%eval(%'
   OR option_value LIKE '%iframe%';

Estas búsquedas pueden encontrar código legítimo, especialmente en plugins de analítica, chat, consentimientos de cookies o constructores visuales. La diferencia suele estar en el dominio, la ofuscación y el contexto. Un script de Google Tag Manager reconocible no es lo mismo que una cadena ilegible apuntando a un dominio recién nacido.

6.3 Revisa widgets, menús y opciones del tema

Los atacantes adoran las zonas que cargan en todas las páginas: widgets HTML, cabecera del tema, footer, opciones de constructores, snippets personalizados. Busca en:

• wp_options: opciones de tema, plugins de cabecera/footer, constructores.
• wp_posts: entradas, páginas, revisiones, plantillas de builders.
• wp_postmeta: metadatos donde muchos builders guardan contenido.
• wp_terms y wp_termmeta: menos frecuente, pero posible.

6.4 Identifica páginas spam creadas por el atacante

Lista publicaciones recientes o modificadas:

SELECT ID, post_title, post_type, post_status, post_date, post_modified
FROM wp_posts
ORDER BY post_modified DESC
LIMIT 50;

Busca títulos en otros idiomas, slugs extraños, contenido farmacéutico, casinos, cupones o páginas que no pertenecen al sitio. En algunos hackeos SEO, las páginas se muestran solo a Google y no al visitante normal; el teatro es barato, pero efectivo.

6.5 Limpieza cuidadosa

No hagas un reemplazo global de cualquier <script>. Puedes destruir integraciones legítimas. Procede así:

1. Exporta la tabla afectada.
2. Identifica el patrón exacto de malware.
3. Prueba la limpieza en una copia.
4. Verifica páginas clave.
5. Aplica en producción cuando estés seguro.

7. Revisar usuarios, contraseñas y accesos 👤

Si solo limpias archivos y dejas una cuenta administradora creada por el atacante, has cambiado las sábanas mientras el ladrón sigue en la casa. Revisa usuarios con privilegios altos:

wp user list --role=administrator

Consulta usuarios recientes:

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

Acciones recomendadas:

• Elimina administradores desconocidos.
• Cambia contraseñas de todos los administradores, editores y cuentas FTP/SFTP/SSH.
• Cambia la contraseña de la base de datos y actualiza wp-config.php.
• Revoca sesiones activas regenerando salts.
• Activa autenticación de dos factores para administradores.
• Revisa emails de recuperación. Un correo comprometido puede reabrir la puerta.
• Cambia claves API de servicios conectados: pasarelas de pago, SMTP, CDN, analítica, repositorios, automatizaciones.

Pequeña digresión: una vez vi un sitio reinfectarse tres veces. No era un plugin, ni el tema, ni una conspiración del servidor. Era una cuenta FTP guardada en un portátil con malware. El WordPress era la víctima visible; el verdadero incendio estaba en otra habitación.

8. Corregir permisos, tareas cron y configuraciones ocultas 🔐

Los permisos no son glamorosos. Nadie presume en una reunión: “mi 755 está impecable”. Y, sin embargo, unos permisos mal puestos pueden convertir el servidor en una plaza pública con micrófono abierto.

8.1 Permisos recomendados

Como regla general en servidores Linux:

• Directorios: 755
• Archivos: 644
• wp-config.php: 600 o 640, según configuración del hosting

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

Algunos hostings administrados usan permisos distintos por su arquitectura. Si el sitio deja de funcionar tras cambiar permisos, consulta documentación del proveedor.

8.2 Desactiva el editor de archivos desde el panel

Agrega en wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Esto evita editar temas y plugins desde el administrador. No detiene un ataque por sí solo, pero reduce daño si una cuenta admin cae.

8.3 Revisa WP-Cron y cron del servidor

Lista eventos programados:

wp cron event list

Busca hooks con nombres extraños, llamadas a archivos eliminados o tareas que ejecutan acciones desconocidas. También revisa cron jobs del hosting o del usuario Linux:

crontab -l

El malware puede programarse para reconstruirse cada cierto tiempo. Como esas plantas que cortas mal y vuelven más verdes, más insolentes.

8.4 Revisa configuraciones del servidor

• .user.ini: busca auto_prepend_file o auto_append_file.
• php.ini: revisa directivas inesperadas.
• Archivos ocultos: usa ls -la.
• Subdominios o carpetas antiguas dentro del mismo hosting.
• Otros WordPress en la cuenta. Un sitio abandonado puede infectar al sitio principal.

9. Verificar que el malware fue eliminado ✅

La limpieza no termina cuando la home carga bien. Termina cuando has comprobado varias capas: archivos, base de datos, accesos, comportamiento externo y registros. Un sitio infectado puede mostrar una cara limpia al administrador y una máscara venenosa al visitante que llega desde Google.

9.1 Limpia cachés

Antes de verificar, purga:

• Caché del plugin de WordPress.
• Caché del servidor.
• CDN, por ejemplo Cloudflare, Fastly o similar.
• Caché del navegador al probar.
• Object cache si usas Redis o Memcached.

9.2 Prueba como distintos visitantes

Abre el sitio:

• En incógnito.
• Desde móvil.
• Con user-agent de Googlebot, si sabes hacerlo con seguridad.
• Desde resultados de búsqueda.
• Con parámetros habituales: ?utm_source=google, páginas internas y checkout.

9.3 Escanea desde dentro y desde fuera

Usa más de una herramienta. Un escáner externo puede detectar redirecciones, blocklists y scripts visibles. Un escáner interno puede ver archivos PHP, permisos y modificaciones. Ninguno reemplaza una revisión manual seria, pero juntos reducen la niebla.

9.4 Revisa logs después de limpiar

Durante 24 a 72 horas, observa:

• Intentos de acceso a archivos eliminados.
• Peticiones POST a rutas inusuales.
• IPs repetitivas intentando explotar plugins antiguos.
• Errores PHP nuevos.
• Creación de archivos inesperados.

Un intento de acceso a una backdoor ya borrada puede revelar por dónde entraban. El atacante vuelve a tocar la puerta; esta vez, al menos, tienes cámara.

10. Recuperar reputación, SEO y avisos de seguridad 📈

Cuando Google, Bing, navegadores o antivirus marcan un sitio como peligroso, la limpieza técnica no basta. Debes demostrar que el sitio ya no amenaza a los usuarios. La confianza digital se pierde como cristal y se reconstruye como catedral: piedra a piedra.

10.1 Google Search Console

Entra en Search Console y revisa:

• Problemas de seguridad: malware, contenido engañoso, descargas dañinas.
• Acciones manuales: spam puro, enlaces artificiales o contenido pirateado.
• Indexación: páginas desconocidas añadidas al índice.
• Sitemaps: archivos sitemap falsos o generados por el atacante.

Cuando hayas limpiado y verificado, solicita revisión. Explica de forma breve qué hiciste: actualizaciones, eliminación de malware, cambio de contraseñas, revisión de usuarios, endurecimiento. No escribas una novela judicial; Google necesita señales claras, no lágrimas.

10.2 Revisa resultados indexados

Busca en Google:

site:tudominio.com

Si aparecen páginas spam, elimínalas del sitio, asegúrate de que devuelvan 404 o 410 si no deben existir, actualiza sitemap y solicita retirada temporal si el daño reputacional es urgente.

10.3 Email y dominio

Si el sitio envió spam, revisa si el dominio o IP están en listas negras. Comprueba también SPF, DKIM y DMARC. Muchos dueños de sitios separan mentalmente “web” y “correo”, pero para la reputación del dominio viven en la misma casa.

11. Endurecer WordPress para evitar reinfecciones 🧱

Limpiar sin endurecer es barrer arena durante una tormenta. El objetivo no es volver al estado anterior; el objetivo es volver mejor. Más sobrio. Menos confiado. La seguridad perfecta no existe, pero la negligencia perfecta sí, y se reconoce enseguida.

11.1 Mantén todo actualizado

• Activa actualizaciones automáticas para parches menores.
• Revisa actualizaciones de plugins y temas al menos semanalmente.
• Elimina lo que no uses.
• Sustituye plugins abandonados por alternativas mantenidas.

11.2 Usa copias de seguridad reales

Una buena estrategia de backups debe cumplir la regla 3-2-1:

• 3 copias de los datos.
• 2 medios o ubicaciones distintas.
• 1 copia fuera del servidor principal.

Y añade una condición que muchos olvidan: prueba la restauración. Un backup no probado es una promesa, no una garantía.

11.3 Aplica mínimo privilegio

• No todos necesitan ser administradores.
• Usa cuentas individuales, no usuarios compartidos.
• Revoca accesos de exempleados, agencias anteriores o proveedores temporales.
• Limita acceso SFTP/SSH a quienes realmente lo necesitan.

11.4 Activa WAF y protección de login

Un Web Application Firewall ayuda a bloquear explotación de vulnerabilidades conocidas, bots agresivos y patrones maliciosos. Puede estar en plugin, hosting o CDN. Además:

• Activa 2FA para administradores.
• Limita intentos de login.
• Protege wp-login.php y xmlrpc.php si no necesitas XML-RPC.
• Usa contraseñas largas y únicas con gestor de contraseñas.

11.5 Cabeceras y configuración adicional

Según el sitio, considera:

• Content-Security-Policy para reducir impacto de scripts inyectados, implementada con cuidado.
• X-Frame-Options o frame-ancestors para mitigar clickjacking.
• X-Content-Type-Options: nosniff.
• HTTPS obligatorio con HSTS si estás seguro de tu configuración.
• Deshabilitar ejecución PHP en directorios de subida.

11.6 Monitoreo continuo

Después de una infección, instala vigilancia razonable:

• Alertas de cambios de archivos.
• Registro de actividad de usuarios.
• Escaneos programados.
• Monitoreo de uptime.
• Alertas de Search Console.

No conviertas el sitio en un búnker inmanejable. La seguridad útil es la que se mantiene. La otra, la que exige rituales imposibles, se abandona en dos semanas.

12. Checklist profesional para limpiar WordPress infectado 🧾

13. Errores frecuentes al eliminar malware en WordPress ❌

Algunos errores se repiten tanto que casi merecen estatua, aunque sería una estatua fea.

• Restaurar un backup sin saber si ya estaba infectado. Si el malware entró hace semanas, el respaldo de ayer solo devuelve el problema con puntualidad británica.
• Cambiar solo la contraseña del administrador. También hay FTP, base de datos, hosting, correo, SSH, API keys y sesiones activas.
• Dejar plugins inactivos. Si el archivo vulnerable sigue en el servidor, puede seguir siendo explotable.
• No limpiar caché. Puedes creer que el malware continúa cuando solo estás viendo una copia cacheada; o peor, creer que se fue mientras la CDN aún lo sirve.
• Ignorar otros sitios en la misma cuenta. Un WordPress viejo en una subcarpeta puede reinfectar al principal.
• Confiar en temas pirata. Lo barato sale caro; lo gratis robado sale carísimo.
• No revisar base de datos. El malware no vive solo en archivos.
• No investigar el vector de entrada. Si no sabes cómo entró, no sabes si cerraste la puerta.

14. ¿Cuándo conviene llamar a un profesional? 🧑‍💻

Hay limpiezas que un administrador cuidadoso puede resolver. Otras requieren experiencia forense, acceso al servidor y criterio para separar código legítimo de veneno elegante. Busca ayuda profesional si:

• El sitio procesa pagos, datos personales sensibles o información médica/legal.
• Hay phishing o robo de credenciales.
• La infección vuelve después de limpiar.
• No tienes backups confiables.
• El hosting amenaza con suspender la cuenta.
• Hay varios sitios afectados en el mismo servidor.
• No sabes interpretar logs, permisos o consultas SQL.

Además, si manejas datos personales, revisa tus obligaciones legales. Dependiendo del país y del tipo de datos, podrías tener deberes de notificación ante usuarios o autoridades. La seguridad web no vive aislada en el sótano técnico; toca reputación, contratos, privacidad y confianza.

15. Guía rápida de comandos útiles ⚙️

Estos comandos no sustituyen una auditoría, pero ayudan a orientarse. Ejecútalos solo si tienes permisos y sabes revertir cambios.

# Ver versión de WordPress
wp core version

# Verificar integridad del núcleo
wp core verify-checksums

# Reinstalar core limpio
wp core update --force

# Listar plugins con versión y actualización disponible
wp plugin list --fields=name,status,version,update

# Listar temas
wp theme list --fields=name,status,version,update

# Listar administradores
wp user list --role=administrator

# Exportar base de datos
wp db export respaldo.sql

# Revisar cron de WordPress
wp cron event list

# Regenerar salts y cerrar sesiones
wp config shuffle-salts

# Buscar archivos modificados recientemente
find . -type f -mtime -14 -ls

# Buscar PHP dentro de uploads
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -print

16. Un plan de recuperación en 24 horas ⏱️

Si necesitas actuar con rapidez, este orden suele funcionar bien:

17. Después de la limpieza: documenta lo ocurrido 📚

Documentar no es burocracia; es memoria operativa. Anota:

• Fecha aproximada de inicio de la infección.
• Archivos y tablas afectadas.
• Vulnerabilidad o vector probable.
• Credenciales cambiadas.
• Plugins eliminados o reemplazados.
• Medidas de endurecimiento aplicadas.
• Escáneres usados y resultados.

Dentro de seis meses, cuando alguien pregunte “¿por qué dejamos de usar aquel plugin tan cómodo?”, agradecerás tener una respuesta distinta a “me suena que pasó algo”.

Resumen práctico para propietarios de sitios WordPress 🧠

Para limpiar un sitio WordPress infectado con malware, primero debes contener el incidente, crear una copia de seguridad del estado infectado, analizar archivos y base de datos, reinstalar el núcleo desde fuentes oficiales, eliminar plugins y temas vulnerables o pirata, revisar usuarios administradores, cambiar todas las credenciales, corregir permisos, bloquear ejecución PHP en uploads, limpiar cachés, escanear nuevamente y solicitar revisión en Google Search Console si el dominio fue marcado. La clave no es solo eliminar el malware visible, sino cerrar el vector de entrada para evitar reinfecciones.

Un cierre necesario: limpiar es recuperar confianza 🌱

Un WordPress hackeado duele porque rompe una ilusión básica: la de que nuestro sitio, ese pequeño territorio de marca, ventas, ideas o comunidad, estaba bajo control. Pero una infección también puede ser una auditoría brutal y útil. Muestra contraseñas débiles, plugins olvidados, backups teatrales, permisos excesivos y dependencias que nadie revisaba.

La web moderna vive en esa tensión: apertura y riesgo, velocidad y fragilidad, abundancia de herramientas y exceso de descuido. WordPress puede ser una casa luminosa o un pasillo lleno de puertas sin llave. La diferencia no está en un plugin milagroso, sino en método, mantenimiento y vigilancia.

Limpiar malware es apagar un incendio; endurecer el sitio es revisar la instalación eléctrica. Lo primero salva el día. Lo segundo salva el futuro.

🛡️ Mantén WordPress actualizado, reduce extensiones innecesarias, usa copias externas, activa 2FA y revisa tus logs. La seguridad no es un producto que se instala: es una costumbre que se practica.