¿Qué riesgo asume una tienda o blog WordPress sin controles activos? Un ataque puede paralizar ventas y minar la reputación en pocas horas; muchas brechas comienzan por plugins desactualizados, credenciales débiles o configuraciones inseguras.
Protección contra malware y hackeos:
- Protege tu WordPress combinando hardening, un WAF, escaneos periódicos de malware, copias de seguridad verificadas y un playbook de respuesta. Para reducir riesgos, prioriza actualizaciones automatizadas, seguridad a nivel de hosting y monitoreo continuo
- Si no hay capacidad técnica, se recomienda contratar un servicio gestionado que ofrezca SLA claros, tiempos de respuesta documentados y procesos de restauración verificables
- Ten en cuenta que la "restauración" puede depender de la disponibilidad de backups limpios y de la identificación de persistencias, por lo que las garantías suelen estar sujetas a condiciones contractuales
Conviene valorar criticidad, hosting, capacidad técnica y presupuesto.
Factores clave para decidir la protección del sitio
La decisión se basa en cuatro variables: criticidad del sitio, tipo de hosting, capacidad técnica interna y presupuesto. Evaluar cada variable permite elegir entre una estrategia DIY o un servicio gestionado con SLA.
La criticidad determina el nivel de vigilancia requerido. Una tienda online obliga a monitorización 24/7 y backups transaccionales.
El hosting condiciona controles: en shared hosting hay menos opciones de hardening a nivel servidor. En VPS o cloud es posible aplicar reglas avanzadas y SIEM.
Hardening mínimo para WordPress
Aplicar estos pasos reduce vectores comunes en minutos. Forzar 2FA a todos los administradores, bloquear accesos innecesarios y desactivar la edición de archivos en el panel.
Comandos útiles: define('DISALLOW_FILE_EDIT', true) en wp-config.php; usar claves SSH y bloquear puertos no usados.
Verificar permisos de archivos: archivos 644 y carpetas 755. Evitar 777 en cualquier ruta.
Controles a nivel de servidor
Restringir funciones de PHP peligrosas y limitar recursos evita ejecución remota. Editar php.ini para deshabilitar exec, shell_exec, proc_open.
Configurar ModSecurity o un WAF a nivel webserver para bloquear patrones conocidos. Habilitar logs detallados de acceso y errores.
Usar fail2ban o similar para bloquear IPs con intentos repetidos de login.
Detección y respuesta automática
Combinar File Integrity Monitoring (FIM), alertas de SIEM y escaneos periódicos reduce el tiempo de detección. Establecer reglas para cambios de archivos críticos y creación de usuarios admin.
Enviar logs a un SIEM (ELK o Splunk) permite correlación de eventos y respuesta más rápida.
Definir umbrales de alerta claros: creación de admin, ejecución de PHP en uploads, o picos en wp-login.
Sitio pequeño con hosting compartido: qué hacer primero
En shared hosting el riesgo principal viene de vecinos comprometidos y permisos inseguros. Priorizar aislamiento, backups externos y WAF en DNS.
Mover el sitio a un subdominio aislado o a una cuenta separada reduce riesgo de contagio. Pedir al proveedor acceso a logs y confirmar políticas de backup.
Habilitar Cloudflare en modo proxy para bloquear tráfico malicioso antes del servidor. Forzar HTTPS y revisar certificados Let's Encrypt.
Pasos urgentes en shared hosting
Cambiar contraseñas de FTP, panel y base de datos; forzar 2FA si el proveedor lo permite. Revocar claves API y rotar tokens.
Buscar PHP en uploads: find wp-content/uploads -type f -name "*.php". Eliminar o mover archivos sospechosos a cuarentena.
Solicitar snapshot o backup al hosting antes de restaurar cualquier cosa.
Limitaciones del entorno compartido
Los proveedores a veces no permiten instalar FIM o modificar php.ini. Esa limitación obliga a usar controles externos, como WAF en DNS.
Un caso habitual: sitio en shared hosting que fue reinfectado tras restaurar un backup, porque el atacante había dejado un cron oculto. La restauración sin buscar persistencias provocó nueva incidencia.
Sitio en VPS o cloud: controles avanzados y SIEM
En VPS o cloud hay control para aplicar hardening profundo, desplegar SIEM y crear playbooks automatizados. Ese nivel reduce el TTD y mejora la contención.
Configurar syslog remoto, filebeat y un cluster ELK para almacenar y buscar eventos. Habilitar snapshots diarios para restauración rápida.
Asegurar SSH con acceso por clave, bloqueo por geolocalización y rotación de claves. Habilitar backups automáticos fuera del mismo nodo.
Reglas prácticas de SIEM
Reglas recomendadas: detección de POSTs masivos a wp-login, creación de usuarios admin, ejecución de PHP en directorios de uploads y cambios masivos de hashes de archivos.
Ejemplo de regla: alert when more than 10 failed wp-login attempts from same IP within 5 minutes. Esto permite bloquear antes de que el atacante gane acceso.
Enviar alertas críticas por correo, Slack y crear un snapshot automático del sistema al detectar brechas.
Comandos y IOCs reproducibles
Buscar patrones comunes con estos comandos de shell y WP-CLI. Guardar resultados como evidencia.
Bash
mysqldump -u usuario -p nombre_db > db_dump.sql
wp user list --role=administrator --fields=ID,user_email,user_registered
grep -R --line-number "base64_decode|gzinflate|eval(" wp-content/
find wp-content/uploads -type f -name "*.php" -ls
find . -type f -exec sha256sum {} /; | sort > hashes_antes.txt
IOCs típicos: archivos PHP en uploads, crons desconocidos, usuarios admin sin historial y conexiones externas desde PHP a dominios extraños.
Cómo limpiar e ir a producción otra vez
La secuencia es clara: contener, capturar evidencias, identificar vector, limpiar persistencias y restaurar desde backup limpio. Restaurar sin eliminar la causa raíz causa reinfecciones.
Aplicar este playbook paso a paso para evitar errores comunes y documentar cada acción en un timeline forense.
Los tiempos orientativos: contención en la primera hora, identificación y limpieza en 1–3 días, validación y monitorización intensiva durante 7–14 días.
PLAYBOOK RESPUESTA INCIDENTE (Plantilla)
1) Contención inmediata (0-1h)
- Poner sitio en modo mantenimiento o descatalogar DNS
- Cambiar credenciales admin, FTP/SFTP, DB y API
- Capturar snapshot y logs (access.log, error.log, crontab, syslog)
2) Captura de evidencia (1-6h)
- Dump DB y hashes de archivos
- Exportar lista de plugins y temas activos (wp plugin list)
- Guardar crontab y tareas programadas
3) Identificar vector (6-24h)
- Buscar plugins/temas desactualizados con CVEs
- Revisar archivos modificados en los últimos meses
- Correlacionar con logs y peticiones sospechosas
4) Limpieza (24-72h)
- Eliminar archivos sospechosos y backdoors
- Revisar y limpiar tablas de la DB con inyección
- Reinstalar core/temas/plugins desde fuentes oficiales
5) Parche y restauración (48-96h)
- Actualizar todo a versiones seguras
- Restaurar desde backup aislado y probado
- Habilitar WAF y FIM
6) Validación y cierre (7-14d)
- Escaneo externo de reputación y listas negras
- Monitorizar logs y alertas 24/7
- Documentar lecciones aprendidas y acciones legales si procede
Comprobaciones forenses concretas
Verificar crontab del usuario: crontab -l y revisar /etc/cron.*. Buscar conexiones externas en los logs con patrones de domains sospechosos.
Comprobar integridad del core: wp core verify-checksums. Si falla, reinstalar core desde WordPress.org.
Plantilla de playbook (ejemplo en texto): a continuación se muestra la estructura práctica y ejemplos de entradas que pueden guardarse como Incident_Playbook.md o Incident_Playbook.xlsx para uso inmediato. Secciones:
- Resumen del incidente (fecha/hora, vector sospechado, servicios afectados)
- Contactos clave (admin, proveedor hosting, DPO, responsable legal)
- Acciones inmediatas (registro de acciones con timestamp). Ejemplo de entrada: "2026-05-01T02:12Z. Contención: puesto sitio en modo mantenimiento; cambiadas credenciales admin; snapshot LVM creado: snapshot_id=vol-20260501-01"
- Evidencia (paths y comandos usados): /var/log/apache2/access.log (copiado), db_dump.sql (mysqldump command), hashes_antes.txt (sha256sum)
- Checklist de limpieza (lista de backdoors detectados, reinstalar core, validar wp core verify-checksums)
- Validación post-restauración (escaneo externo, comprobación en Google Safe Browsing). Incluir ejemplos de campos obligatorios por entrada (hora, actor, acción, resultado, hash de evidencia) facilita mantener cadena de custodia y acelerar notificaciones legales
Comparativa práctica de plugins y servicios de limpieza
Antes de elegir, comparar tasa de detección, tasa de falsos positivos y coste en rendimiento. No todos los plugins actúan igual y algunos generan carga alta en sites con tráfico.
| Herramienta |
Detección estimada |
FP rate |
Impacto CPU |
Coste orientativo |
| Sucuri (servicio) |
80–95% (reportes 2021–2023) |
Bajo |
Bajo (cloud WAF) |
Desde 199 €/año |
| Wordfence (plugin) |
75–90% (inteligencia propia) |
Medio |
Medio (scan en servidor) |
Desde 99 €/año |
| MalCare (plugin+servicio) |
70–88% (tests públicos) |
Medio-bajo |
Bajo (cloud scan) |
Desde 99 €/año |
Plazo orientativo: una limpieza forense completa y recuperación segura suele durar entre 3 y 7 días laborales en sitios pequeños, y entre 7 y 21 días en sitios con integraciones complejas (pasarelas, APIs, múltiples subdominios).
Metodología práctica y ejemplo de benchmark para comparar detección y coste:
- para que las cifras sean útiles debe definirse un corpus (p. ej. 1.000 ficheros que incluyan 200 webshells PHP, 200 backdoors ofuscados, 200 inyecciones en HTML/JS y 400 ficheros benignos representativos), medidas claras (detección = % de muestras maliciosas detectadas
- FP rate = % de benignos marcados erroneamente
- impacto CPU = incremento medio de carga durante el escaneo). Ejecutar escaneos en un entorno controlado (VPS con 2 vCPU, 4 GB RAM, PHP 7.4) y repetir 3 veces para estabilidad. Ejemplo de resultados de una prueba de laboratorio (solo ilustrativa): Sucuri (cloud): detección 92%, FP 0.4%, impacto en servidor local negligible
- Wordfence (scan on-host): detección 86%, FP 1.8%, impacto CPU +25% durante el escaneo
- MalCare (cloud): detección 79%, FP 0.9%, impacto +8%
Registrar versión de cada herramienta, fecha y firmas de malware usadas y publicar comandos usados para reproducibilidad (p. ej. lista de archivos de prueba y script de ejecución).
Errores frecuentes y advertencias críticas
El error más frecuente en este punto es confiar solo en un plugin de seguridad sin hacer hardening del servidor. Un plugin no repara permisos, ni gestiona usuarios a nivel sistema.
Restaurar una copia sin investigar la causa raíz provoca reinfecciones. Copias no aisladas o con backdoors mantienen acceso del atacante.
Cuidado cuando se usan escaneos intensivos en un hosting compartido; pueden generar cargas que afecten al servicio y provocar que el proveedor suspenda procesos.
Señales de infección avanzadas
Usuarios administradores inesperados, archivos PHP en uploads y crons desconocidos suelen indicar persistencia. Buscar estos indicadores antes de restaurar.
Las listas negras (Google Safe Browsing) y bloqueos de correo tras el incidente son señales de que la infección tiene impacto externo.
Caso anónimo que ilustra el riesgo
Un sitio de comercio electrónico con 15.000 pedidos mensuales fue reinfectado tras una restauración sin limpiar crons. Resultado: dos semanas de caída adicional y pérdida de facturación. La auditoría forense identificó un plugin obsoleto como vector inicial.
Integración con SIEM y reducción del TTD
La reducción del TTD permite contener antes y limitar el alcance del atacante. Integrar logs de webserver, PHP, FIM y WAF en un SIEM permite correlación y detección temprana.
Enviar logs con filebeat a ELK o SIEM comercial y crear reglas de correlación reduce falsos positivos y acelera la respuesta.
Reglas para detectar la ejecución de PHP en uploads, múltiples fallos de login y cambios de permisos en wp-content.
Ejemplo práctico de envío de logs
Configurar filebeat para enviar /var/log/apache2/* a Elasticsearch. Crear dashboard con eventos de wp-login y cambios de archivos. Definir alertas por email y webhook.
La evidencia visual ayuda: en la captura de logs se aprecia claramente un pico de peticiones a wp-login antes del compromiso.
Opinión con matiz
Una estrategia combinada de WAF en el borde y SIEM en el backend funciona bien, pero solo si se dispone de recursos para mantener reglas y analizar alertas. En ausencia de equipo, el WAF gestiona buena parte del riesgo y es la opción más coste-efectiva.
Costes y modelo: DIY frente a servicio gestionado
DIY reduce costes monetarios directos, pero implica horas técnicas y riesgos si fallan procesos. Servicios gestionados ofrecen SLA y responsabilidad por limpieza, a cambio de un coste mensual.
Rangos reales: DIY puede suponer 500–2.500 € en horas y herramientas la primera vez. Servicios gestionados cuestan entre 50 y 300 €/mes según SLA.
Evaluar coste por hora interna y coste de parada del sitio para tomar la decisión correcta.
Qué pedir a un proveedor gestionado
Pedir SLA con tiempo de respuesta, limpieza forense incluida, garantías de no reinfección y pruebas de restauración periódicas. Revisar cláusulas sobre responsabilidades y copias de seguridad.
Comprobar que el proveedor ofrece informes y soporte para notificaciones legales según RGPD.
Advertencias legales y notificación tras brechas
Si existen datos personales comprometidos, la notificación a la AEPD debe hacerse en 72 horas si hay riesgo para derechos y libertades. Documentar la evaluación y mantener evidencia del análisis.
Informar a afectados con información clara sobre qué datos se vieron comprometidos y medidas tomadas. Coordinar con DPO si existe.
Referencias útiles: RGPD, LOPDGDD y recomendaciones del CCN-CERT e INCIBE para incidentes en España.
No aplicar estas recomendaciones si el sitio no es WordPress o si el proveedor de hosting ofrece seguridad gestionada y no permite cambios a nivel servidor. En esos casos, contactar al proveedor y solicitar evidencias de controles, logs y pruebas de restauración antes de actuar.
Si el sitio es crítico y no hay equipo interno, la opción más práctica es contratar un servicio gestionado que ofrezca limpieza forense y SLA claro antes de proceder con restauraciones.
Preguntas frecuentes
¿Cómo sé si mi WordPress está infectado?
Signos claros: aparición de archivos PHP en uploads, usuarios admin desconocidos y avisos de listas negras. Detectar estos signos obliga a actuar de inmediato.
Revisar logs de acceso y errores, hacer un escaneo con Sucuri o Wordfence y buscar IOCs en el contenido de archivos. Guardar todas las evidencias para auditoría.
¿Puedo limpiar el sitio con un plugin gratuito?
Un plugin ayuda a detectar y limpiar, pero no sustituye análisis forense ni hardening a nivel servidor. Usar plugins junto con escaneos server-side.
En incidentes complejos hay que revisar crons, DB y permisos. Los plugins gratuitos suelen no eliminar backdoors sofisticados.
¿Cada cuánto debo revisar backups?
Los backups deben verificarse al menos mensualmente y tras cada cambio mayor. Probar restauraciones completas cada 3 meses.
Una copia no probada puede ser inútil; siempre aislar y comprobar antes de restaurar.
¿Qué plugins conviene evitar?
Plugins abandonados o con pocas descargas suelen ser más riesgosos. Evitar plugins sin actualizaciones desde hace más de 12 meses.
Mantener inventario de plugins y temas, y revisar CVEs conocidos antes de instalar.
¿Qué datos debo conservar tras un incidente?
Conservar logs, dump de la base de datos, hashes de archivos y capturas de crontab. Esa documentación es esencial para la notificación legal y auditoría.
Mantener cadena de custodia de las copias y registrar quién accede a cada evidencia.
¿Cómo reduce el WAF el riesgo?
Un WAF bloquea patrones maliciosos y reduce exposición a exploits conocidos antes de llegar al servidor. Es efectivo para ataques de fuerza bruta y probes automatizados.
Sin embargo, el WAF no reemplaza parches ni hardening; actúa como primera línea de defensa.
¿Qué hago si Google marca mi sitio como inseguro?
Solicitar limpieza forense y pedir revisión de seguridad a Google tras eliminar la amenaza. El tiempo hasta quitar la etiqueta varía, suele ser de 24–72 horas tras la solicitud de revisión.
Documentar los pasos de limpieza y enviar evidencia en la petición de revisión.
Qué hacer ahora
Priorizar: si hay sospecha de hack, aislar el sitio y capturar evidencias en la primera hora. Luego seguir el playbook paso a paso y decidir entre DIY o servicio gestionado según recursos.
Si la opción es externa, pedir al proveedor SLA, limpieza forense completa y pruebas de restauración antes de aceptar restauraciones.
Coste orientativo: migrar de shared hosting a VPS seguro y configurar SIEM inicial suele costar entre 800 y 3.000 euros según complejidad y proveedor.
