Etiqueta: limpieza malware

  • Costo real de limpiar WordPress: presupuesto honesto sin sorpresas al final

    Costo real de limpiar WordPress: presupuesto honesto sin sorpresas al final

    ¿Cuánto cuesta realmente limpiar un WordPress infectado?

    Cuando un cliente me llama porque su WordPress está comprometido, la primera pregunta que siempre hace es: «¿cuánto me va a costar?». No es casual. En mi experiencia analizando sitios web, he visto presupuestos que van desde 300 euros hasta más de 5.000, y muchas veces sin claridad sobre qué incluye cada uno. Hoy quiero ser completamente honesto contigo: te voy a explicar los costos reales, desglosados, sin sorpresas al final.

    La limpieza de WordPress no es un servicio estándar. Cada infección es diferente: un backdoor simple no cuesta lo mismo que extraer un Magecart que ha estado robando datos de clientes durante meses. Por eso los precios varían tanto, y por eso es importante que entiendas exactamente en qué se invierte el dinero.

    Factores que determinan el costo real de la limpieza

    1. Tipo y alcance de la infección

    Un malware simple (como un redirector o un spam SEO) puede limpiarse en 2-3 horas. Pero si tu sitio tiene un backdoor PHP incrustado en múltiples carpetas, webshells ocultas, cryptominers o modificaciones en el núcleo de WordPress, el tiempo de análisis y eliminación se multiplica.

    En mis auditorías más complejas, he encontrado casos donde:

    • El atacante había comprometido la base de datos y todos los backups existentes.
    • El malware se replicaba automáticamente cuando intentábamos eliminarlo (persistencia).
    • Había inyecciones SQL en múltiples plugins y el archivo wp-config.php.
    • Los permisos de carpetas estaban mal configurados desde la instalación.

    Estos casos requieren entre 6 y 15 horas de trabajo especializado. El presupuesto no puede ser el mismo que para un sitio con un simple plugin malicioso.

    2. Tamaño y complejidad del sitio

    Un blog de 20 posts no es lo mismo que un e-commerce con 500 productos, usuarios registrados y datos de clientes. Los e-commerce requieren verificación adicional de seguridad PCI, auditoría de módulos de pago y validación de que no hubo robo de tarjetas.

    PrestaShop es especialmente exigente en esto. Si tu tienda tiene un módulo de pago comprometido (riesgo Magecart), tendrás que revisar cada transacción de los últimos 6 meses, informar a proveedores de pago y posiblemente a AEPD.

    3. Necesidad de restauración desde backup

    Si tienes un backup limpio y fiable, la limpieza es mucho más rápida y barata: simplemente restauramos y verificamos. Pero si no tienes backups o los backups también están infectados, hay que hacer una limpieza manual completa, línea por línea en algunos casos.

    He visto clientes sin backups desde hace 18 meses. Eso significa que si la infección lleva 6 meses (algo común), tenemos que hacer limpieza quirúrgica: identificar qué es malware y qué es contenido legítimo.

    4. Auditoría post-limpieza y hardening

    Una limpieza sin hardening es como curar una herida infectada sin limpiar la suciedad. Si solo limpiamos pero no cerramos las puertas abiertas, el sitio se reinfectará en días o semanas.

    El hardening incluye:

    • Cambiar contraseñas de admin, FTP, base de datos.
    • Desactivar edición de archivos desde el panel de WordPress.
    • Cambiar prefijo de tablas de base de datos.
    • Configurar protección de wp-config.php y wp-admin.
    • Implementar reglas .htaccess contra ataques comunes.
    • Auditoría de permisos de carpetas (644 para archivos, 755 para directorios).
    • Actualizar todos los plugins, temas y núcleo de WordPress.
    • Implementar 2FA en cuentas administrativas.

    Esto no es opcional. Es la diferencia entre pagar ahora o pagar mucho más después.

    Desglose típico de costos (presupuesto real)

    Escenario 1: Infección simple (malware de bajo nivel)

    Tiempo estimado: 3-4 horas

    • Análisis inicial y diagnóstico: 1 hora (100-150€)
    • Eliminación de malware: 1,5 horas (150-225€)
    • Restauración desde backup limpio: 0,5 horas (50-75€)
    • Hardening básico (cambio de contraseñas, actualización de plugins): 1 hora (100-150€)

    Presupuesto total: 400-600€

    Este es el mejor escenario: tienes backups, la infección se detectó rápido y no hay datos de clientes comprometidos.

    Escenario 2: Infección moderada (backdoors, inyecciones SQL)

    Tiempo estimado: 8-10 horas

    • Análisis profundo y búsqueda de todos los vectores de ataque: 2 horas (300-400€)
    • Eliminación manual de backdoors y webshells: 3 horas (450-600€)
    • Auditoría de base de datos y limpieza de inyecciones: 2 horas (300-400€)
    • Hardening completo (permisos, .htaccess, 2FA, CSP, HSTS): 2 horas (300-400€)
    • Pruebas de funcionamiento y validación de seguridad: 1 hora (150€)

    Presupuesto total: 1.500-2.000€

    Aquí hay trabajo real de investigación. Probablemente no tengas backups limpios o tengas que hacer verificación de integridad del código.

    Escenario 3: Infección grave (e-commerce con datos comprometidos)

    Tiempo estimado: 20-30 horas

    • Análisis forense completo: 4 horas (600-800€)
    • Búsqueda y eliminación de persistencia: 5 horas (750-1.000€)
    • Auditoría PCI y validación de módulos de pago: 4 horas (600-800€)
    • Análisis de transacciones y evaluación de robo de datos: 3 horas (450-600€)
    • Hardening avanzado (WAF, monitoreo, logs): 3 horas (450-600€)
    • Documentación de incidencia para AEPD (si aplica): 1 hora (150-200€)

    Presupuesto total: 3.000-4.500€

    En estos casos, además de la limpieza técnica, hay obligaciones legales. Si has tenido datos personales expuestos, tienes que notificar a AEPD en algunos casos. Eso no es coste de limpieza, es coste de cumplimiento legal.

    ¿Por qué el hardening no debería ser «opcional»?

    Muchos proveedores ofrecen «limpieza barata» sin hardening. Luego el cliente se reinfecta en dos semanas y paga de nuevo. He visto esto cientos de veces.

    El hardening cuesta entre 300-800€ adicionales, pero evita que gastes 3.000-5.000€ en una segunda limpieza. Es matemática simple: invierte un poco más ahora o mucho más después.

    Los elementos de hardening no negociables son:

    1. Cambio de todas las contraseñas: Si atacantes tuvieron acceso, tus contraseñas están comprometidas. No puedes limpiar sin cambiarlas todas.
    2. Desactivar edición de archivos: Editar archivos desde el panel de WordPress (wp-admin) es un fallo crítico. Desactívalo con define('DISALLOW_FILE_EDIT', true); en wp-config.php.
    3. Limitar intentos de login: La mayoría de intrusiones comienzan con fuerza bruta contra wp-login.php. Implementa límite de 5 intentos por IP cada 15 minutos.
    4. Actualizar todo: WordPress, plugins y temas. Las versiones desactualizadas son la causa número uno de infecciones. No es opcional.
    5. Reglas .htaccess: Bloquear acceso a archivos peligrosos (wp-config.php, xmlrpc.php) y carpetas sensibles (wp-admin desde IPs no autorizadas).

    Costos ocultos que nadie te menciona

    1. Migración a servidor nuevo

    A veces, la infección es tan profunda que limpiar en el servidor actual es arriesgado. Necesitas migrar a un servidor nuevo, limpio. Eso puede costar 300-600€ adicionales en migración profesional.

    2. Certificado SSL nuevo

    Si el certificado SSL estuvo activo mientras había malware, algunos proveedores de SSL recomiendan renovar. No es obligatorio si confías en que el malware no robó la clave privada. Pero es una precaución. Costo: 50-150€.

    3. Auditoría de terceros

    Para e-commerce, especialmente PCI-DSS, a veces necesitas que un tercero externo valide que el sitio está limpio. Eso cuesta 500-1.500€ adicionales, pero es requisito en algunos casos.

    4. Monitoreo post-limpieza

    No es obligatorio, pero es inteligente. Un monitoreo de 3 meses por 50-100€/mes te alerta si hay reinoculación de malware. Mucha mejor que descubrir en 6 meses que volvió a ser infectado.

    ¿Cómo evitar que te cobren de más?

    Aquí es donde entra mi honestidad profesional. He visto propuestas de 8.000€ para infecciones que costaban 1.500€. ¿Cómo identificar si te están robando?

    Señales de alerta:

    • Presupuesto sin desglose: «Te cobraré 5.000€ pero no sé exactamente cuánto tiempo tardará».
    • No incluye hardening: Solo eliminan el malware visible, no cierran las puertas.
    • Sin plan de backup: No ofrecen restauración automática después.
    • Sin auditoría post-limpieza: No verifican que el malware esté completamente eliminado.
    • Presupuesto fijo sin análisis previo: Todo sitio es diferente. Si no analizan primero, están adivinando.

    Señales de profesionalismo:

    • Análisis inicial sin coste para diagnosticar qué tiene tu sitio.
    • Presupuesto desglosado con tiempo estimado para cada tarea.
    • Hardening incluido o muy claro cuál es el costo.
    • Garantía de limpieza (si vuelve a aparecer malware en 30-60 días, lo limpian gratis).
    • Plan de monitoreo posterior ofrecido como complemento, no obligatorio.
    • Acceso a reportes técnicos detallados después de la limpieza.

    Presupuesto honesto para tu situación específica

    Cada sitio es único. Lo que sí te puedo garantizar es que un presupuesto profesional debe incluir:

    1. Diagnóstico inicial: Para saber qué estamos limpiando (gratuito o muy bajo coste).
    2. Plan de limpieza detallado: Paso a paso, con tiempos realistas.
    3. Hardening específico: No genérico, sino adaptado a tu tipo de sitio.
    4. Garantía post-limpieza: Mínimo 30 días sin reinoculación.
    5. Documentación: Registro completo de qué se limpió, qué se cambió, acciones futuras.

    Si tu presupuesto cumple estos 5 puntos, probablemente es honesto. Si falta alguno, pregunta por qué.

    Referencias técnicas para entender el coste real

    Si quieres profundizar en qué hace que una limpieza sea compleja, estos recursos de autoridad explican bien los riesgos:

    Resumen: Presupuesto realista sin sorpresas

    Infección simple (malware bajo nivel): 400-600€

    Infección moderada (backdoors, inyecciones): 1.500-2.000€

    Infección grave (e-commerce, datos comprometidos): 3.000-4.500€

    Estos rangos incluyen análisis, limpieza, hardening básico/completo y validación. Si alguien te presupuesta fuera de estos rangos sin justificación clara, pregunta por qué.

    Lo más importante: no busques el presupuesto más barato. Busca transparencia. Un profesional honesto te explica qué hace, por qué lo hace y cuánto tiempo le toma. El costo se justifica solo.

    Si tu sitio está infectado y necesitas presupuesto real sin sorpresas, sin obligación de contratación, puedo ayudarte. He analizado cientos de casos y sé exactamente cómo diagnosticar y cuánto cuesta limpiar cada tipo de infección.

    Contacta conmigo en ManuelFolgar.com/contacto para un análisis honesto de tu situación específica. Sin sorpresas al final.

  • Plugin vs profesional: cuándo Wordfence no basta y necesitas intervención experta

    Plugin vs profesional: cuándo Wordfence no basta y necesitas intervención experta

    Wordfence no basta: cuándo necesitas un experto en seguridad WordPress

    Llevo más de una década analizando sitios WordPress comprometidos, y te puedo decir con certeza que Wordfence es una herramienta excelente, pero no es un sustituto de la intervención profesional. He visto casos donde empresas confían ciegamente en sus plugins de seguridad y terminan con backdoors activos durante meses sin saberlo.

    En mi experiencia, la diferencia entre un plugin de seguridad y un análisis forense profesional es como la diferencia entre un extintor de incendios y un equipo de bomberos. El extintor previene, pero si el fuego ya está dentro de la casa, necesitas expertos.

    ¿Qué hace bien Wordfence?

    Wordfence es, sin duda, uno de los mejores plugins de seguridad disponibles para WordPress. Ofrece:

    • Firewall WAF (Web Application Firewall) que bloquea patrones de ataque conocidos en tiempo real.
    • Escaneo de malware basado en su base de datos de firmas, actualizada continuamente.
    • Protección contra fuerza bruta limitando intentos de acceso a wp-login.php.
    • Monitoreo de integridad de archivos que alerta si detecta cambios sospechosos.
    • Bloqueo de tráfico malicioso analizando patrones de comportamiento.

    Para sitios con baja complejidad y sin historial de compromiso, Wordfence puede ser una barrera suficiente si se configura correctamente. Pero aquí está el problema: la mayoría de las configuraciones por defecto dejan vulnerabilidades importantes sin cubrir.

    Limitaciones técnicas reales de los plugins de seguridad

    Cuando analizo un sitio que supuestamente «estaba protegido por Wordfence», encuentro patrones que los plugins no detectan porque su diseño tiene limitaciones estructurales:

    1. Los backdoors dormidos son invisibles para Wordfence

    Un backdoor bien insertado puede pasar desapercibido porque no genera tráfico sospechoso. He encontrado archivos PHP ocultos con nombres como «wp-temp.php» o «.index.php» que contienen webshells inactivas durante semanas. El plugin no las detecta porque:

    • La firma del malware es nueva o modificada.
    • El código está ofuscado o encriptado.
    • El archivo está fuera del directorio wp-content donde Wordfence enfoca su atención.

    2. Wordfence no audita la base de datos completamente

    El malware Magecart y sus variantes WordPress inyectan código malicioso directamente en las tablas de opciones o en posts publicados. Wordfence detecta algunos patrones, pero si el skimmer de tarjetas está camuflado en una opción serializada o en un campo custom, puede pasar el filtro. Yo utilizo análisis SQL directo con herramientas como wp-cli y inspección manual de base de datos para encontrar esto.

    3. Los redirectores silenciosos están diseñados para evitar detección

    Un atacante experimentado inyecta código en .htaccess que redirige a usuarios según su User-Agent. Si vienes de Google, ves el sitio legítimo. Si vienes de usuario final, te lleva a un sitio de phishing. Wordfence puede alertarte sobre cambios en .htaccess, pero si la regla es sutil, no la marca como maliciosa.

    4. Los plugins comprometidos son territorio gris

    He encontrado temas y plugins nulled (descargados ilegalmente) que tienen código malicioso integrado desde el inicio. Wordfence los marca si la firma está en su base de datos, pero no detecta modificaciones personalizadas o exploits zero-day específicos para ese plugin.

    5. El historial de logs está borrando

    Cuando un sitio ha sido comprometido, los atacantes suelen borrar o manipular los logs de acceso. Wordfence almacena algunos eventos, pero no tiene visibilidad completa del servidor (apache/nginx logs). Un forense profesional recupera y analiza logs a nivel de servidor, a veces incluso logs borrados si tienes backups.

    Señales de que necesitas intervención profesional ahora mismo

    Estos son los escenarios donde un plugin no es suficiente y tienes que contactar con un experto:

    1. Wordfence detecta malware, pero no consigue eliminarlo

    Si Wordfence identifica un archivo malicioso pero el plugin no puede borrarlo (tienes un error de permisos o el archivo se regenera), significa que:

    • El malware tiene persistencia a través de múltiples vectores.
    • Hay una puerta trasera que lo reinstala automáticamente.
    • El archivo está protegido por una regla de .htaccess o en una ubicación especial.

    Un profesional accede al servidor vía SFTP, SSH o Panel de Control, identifica y elimina todas las instancias del malware, revisa permisos de carpetas y verifica que no haya duplicados escondidos.

    2. Tu sitio tiene caídas sin razón aparente o comportamiento extraño

    Si WordPress se ralentiza, hay errores de conexión a base de datos aleatorios o procesos PHP tomando el 100% de CPU, probablemente hay un cryptominer u otro tipo de malware ejecutándose en segundo plano. Un plugin puede detectar el consumo de recursos, pero no siempre identifica qué lo causa.

    Yo analizo los procesos activos, reviso wp-cron, tareas programadas, y los logs de error.log para encontrar el culpable.

    3. Google Search Console muestra «Sitio hackeado» o «Contenido malicioso»

    Google tiene algoritmos sofisticados para detectar sitios comprometidos. Si apareció la alerta, es porque hay malware activo o inyección de contenido verificable. Wordfence puede no detectarlo si el patrón es nuevo.

    Necesito hacer un análisis forense completo:

    • Revisar qué URLs indexadas son maliciosas.
    • Buscar inyecciones de contenido en posts, páginas y custom post types.
    • Verificar si hay redirecciones condicionales que Google detectó.
    • Analizar permisos de usuarios y roles comprometidos.

    4. Tienes usuarios administrativos que no creaste

    Si al revisar Usuarios en WordPress aparecen cuentas que desconoces, alguien tiene acceso administrativo. Wordfence puede alertarte si intenta crear usuarios vía wp-login, pero si el acceso ya está establecido, el plugin no lo retroactivamente elimina (y es peligroso hacerlo sin saber si hay más backdoors).

    Un experto audita qué cuentas son legales, elimina las maliciosas, revisa qué actividades realizaron, y busca cómo ganaron acceso.

    5. Hay intentos de acceso masivos o patrones de ataque coordinados

    Si Wordfence reporta millones de intentos de fuerza bruta contra wp-login.php en 48 horas, o intentos de acceso a archivos conocidamente vulnerables (como wp-admin/admin.php con parámetros LFI), necesitas:

    • Cambiar permisos de servidores y arquitectura.
    • Implementar reglas WAF personalizadas.
    • Posiblemente cambiar hosting si los ataques vienen del proveedor.

    Wordfence bloquea los intentos, pero no soluciona la arquitectura vulnerable que los permite.

    Diferencias clave entre plugin y auditoría profesional

    Cuando contrato un análisis forense profesional en mi equipo, lo que hacemos va mucho más allá que ejecutar Wordfence:

    Aspecto Plugin Wordfence Análisis Profesional
    Acceso a servidor Limitado a PHP/WordPress SSH, SFTP, análisis de logs del sistema operativo
    Análisis de malware Basado en firmas conocidas Análisis heurístico + análisis estático de código
    Recuperación forense No aplicable Recuperación de datos borrados, análisis de timeline
    Reporte de incidente Solo alertas del plugin Reporte detallado con vectores de ataque identificados
    Hardening post-limpieza Configuración básica Hardening completo + cambio de infraestructura si es necesario

    Ejemplo real: El caso del backdoor invisible

    Hace tres meses analizaba un e-commerce PrestaShop que reportaba «Wordfence no encuentra malware, pero el sitio sigue siendo lento». Al revisar:

    • Encontré un archivo llamado «index.log» en la raíz que Wordfence ignoraba porque no tenía extensión PHP.
    • Ese archivo contenía un webshell codificado en base64 que se ejecutaba vía .htaccess.
    • El .htaccess tenía una regla personalizada que ejecutaba ese webshell solo si venía desde un IP específico (la del atacante).
    • Dentro de ese webshell había un cryptominer que vendía capacidad de CPU.

    Wordfence nunca lo detectó porque:

    • No escanea archivos .log.
    • Las reglas de .htaccess customizadas no siempre se marcan como maliciosas automáticamente.
    • El webshell se ofuscaba dinámicamente cada vez que se accedía.

    Lo limpié, cambié la arquitectura del servidor, implementé reglas CSP estrictas, y el cliente no volvió a tener problemas.

    Cómo maximizar Wordfence mientras esperas ayuda profesional

    Si aún no puedes contratar un análisis profesional pero sospechas compromiso, estas configuraciones de Wordfence pueden ayudarte:

    1. Activa el escaneo de sistema de archivos completo

    No solo wp-content. Escanea todos los directorios, incluyendo raíz y directorios ocultos. Esto ralentiza el sitio temporalmente, pero es necesario.

    2. Configura la protección de fuerza bruta agresivamente

    Limita intentos de login a máximo 3 fallidos en 5 minutos, y bloquea por 24 horas. Cambia la URL de wp-login.php si es posible.

    3. Habilita el monitoreo de integridad de todos los archivos WordPress

    No solo los core. Incluye plugins y temas. Así recibirás alertas si alguien modifica archivos.

    4. Integra Google reCAPTCHA en wp-login.php

    Reduce ataques de bots significativamente.

    5. Revisa los logs de Wordfence regularmente

    No esperes a que sea demasiado tarde. Busca patrones de ataque repetidos contra direcciones específicas.

    Pero repito: esto son medidas de contención, no solución. Si ya hay compromiso verificado, Wordfence solo evita que empeore.

    Cuándo contactar con un profesional (checklist)

    Marca todas las que apliquen:

    • ☐ Google marca tu sitio como hackeado o malicioso.
    • ☐ Wordfence detecta malware pero no puede eliminarlo completamente.
    • ☐ Tienes usuarios administrativos desconocidos en WordPress.
    • ☐ Tu sitio redirige a usuarios a otras páginas sin tu consentimiento.
    • ☐ El sitio tiene caídas frecuentes o comportamiento extraño sin explicación.
    • ☐ Los backups están también infectados (indicativo de acceso persistente).
    • ☐ Cambios de contraseña no resuelven el acceso no autorizado.
    • ☐ Necesitas recuperar datos o identificar qué ocurrió exactamente.

    Si marcaste 3 o más, necesitas análisis profesional ahora.

    PrestaShop: El plugin no es suficiente tampoco

    En PrestaShop, el panorama es aún más complejo. Wordfence existe para WordPress, pero la seguridad en PrestaShop depende más de:

    • Módulos de seguridad (muchos son de pago y variable en calidad).
    • Protección del back-office (/admin/).
    • Módulos de pago comprometidos (es el vector más común en PrestaShop).
    • Permisos de carpetas incorrectos en servidor.

    Un análisis profesional de PrestaShop es aún más crítico que en WordPress porque el e-commerce maneja datos de tarjetas de crédito (PCI DSS). Una tienda comprometida no solo pierde datos, pierde certificación de pago.

    El caso por la prevención profesional

    Algo que observo constantemente: los clientes que invierten en auditoría de seguridad profesional anual tienen 90% menos probabilidades de ser hackeados que aquellos que solo usan plugins.

    Una auditoría profesional incluye:

    • Análisis de configuración de servidor y PHP.
    • Revisión de permisos de archivos y directorios.
    • Identificación de plugins/temas vulnerables o desactualizados.
    • Auditoría de usuarios y roles.
    • Pruebas de penetración básicas.
    • Reporte con recomendaciones de hardening.

    Esto cuesta un porcentaje pequeño comparado con la limpieza forense de un sitio comprometido, que puede tomar 20-40 horas.

    Conclusión: Plugin y profesional, no plugin O profesional

    La respuesta a «¿necesito Wordfence o un profesional?» es: ambos. Wordfence es tu defensa diaria. Un profesional es tu respuesta ante incidentes y tu auditoría preventiva.

    En mi experiencia, el mejor enfoque es:

    1. Mantén Wordfence actualizado y bien configurado para evitar ataques básicos.
    2. Realiza auditorías profesionales anuales para identificar vulnerabilidades que los plugins no ven.
    3. En caso de compromiso verificado, contacta con un forense inmediatamente, no intentes solucionarlo solo con plugins.

    Wordfence es excelente dentro de su rango. Pero si quieres dormir tranquilo sabiendo que tu sitio es realmente seguro, necesitas un experto que vaya más allá de las firmas de malware y las reglas WAF automáticas.

    Si sospecha que tu sitio está comprometido o quieres una auditoría profesional completa, contacta con mi equipo en ManuelFolgar.com. Analizamos tu caso sin obligación y te explicamos exactamente qué necesitas.

    Referencias y fuentes de autoridad:

    Para este análisis me he basado en directrices de seguridad reconocidas internacionalmente:

  • Protocolo de limpieza WordPress: los 7 pasos que funcionan cuando otros fallan

    Protocolo de limpieza WordPress: los 7 pasos que funcionan cuando otros fallan

    Protocolo de limpieza WordPress: los 7 pasos que funcionan cuando otros fallan

    En mi experiencia analizando más de 500 sitios WordPress comprometidos, he visto que la mayoría de intentos de limpieza fallan porque abordan el problema de forma superficial. Un plugin de seguridad activado a posteriori, un cambio de contraseñas apresurado o una eliminación de archivos sin metodología real dejan puertas abiertas para que el malware regrese en cuestión de días. Hoy quiero compartirte el protocolo que realmente funciona, el que aplicamos cuando un sitio ya ha pasado por manos inexpertas y sigue comprometido.

    ¿Por qué fallan los intentos convencionales de limpieza?

    La mayoría de propietarios de WordPress intenta resolver un compromiso activando un plugin de seguridad o pagando una herramienta automatizada. El problema es que estos métodos llegan después de que el atacante ya está adentro. Un backdoor bien insertado en wp-config.php, un webshell camuflado en wp-content/uploads/ o un usuario administrativo fantasma creado hace meses siguen operando aunque ejecutes un escaneo.

    Lo que recomiendo siempre es un enfoque metodológico: antes de confiar en herramientas automatizadas, necesitas tomar control manual del entorno, entender qué sucedió exactamente y eliminar cada vector de ataque de forma verificable. Esto es el protocolo que funciona cuando otros fallan.

    Los 7 pasos del protocolo de limpieza WordPress

    Paso 1: Aislamiento inmediato y auditoría forense

    Lo primero es detener la hemorragia. Desactiva el sitio del mundo exterior sin apagarlo completamente.

    • Reemplaza wp-config.php temporalmente con uno que redirija todo a una página de mantenimiento. Esto congela cualquier actividad del malware mientras recopilas evidencia.
    • Obtén acceso root al servidor vía SSH o panel de control de hosting. Necesitas permisos elevados para ver qué sucede realmente.
    • Copia todo el directorio de WordPress a un almacenamiento externo (carpeta .tar comprimida). Esto es tu evidencia forense. Si algo sale mal, tienes un punto de partida claro.
    • Consulta los logs de Apache/Nginx de los últimos 30 días. Busca peticiones POST anómalas, accesos a wp-admin desde IPs sospechosas, o intentos de ejecución de archivos PHP fuera de wp-includes/ y wp-admin/.

    En esta fase estoy buscando responder: ¿cuándo comenzó el compromiso? ¿Qué tipos de archivos se modificaron? ¿Hay backdoors persistentes creados hace semanas?

    Paso 2: Limpieza de la base de datos (sin copias de seguridad infectadas)

    Los backdoors no viven solo en archivos. Muchos se almacenan en opciones de WordPress, posts/páginas con contenido inyectado o tablas personalizadas de plugins maliciosos.

    • Accede a phpMyAdmin o CLI de WordPress (wp-cli) con credenciales de administrador legítimo.
    • Busca usuarios sospechosos: SELECT user_login, user_registered FROM wp_users WHERE user_registered > DATE_SUB(NOW(), INTERVAL 60 DAY); Si ves usuarios creados recientemente que no reconoces, son backdoors de acceso. Elimínalos por completo, no desactives.
    • Inspecciona opciones maliciosas: Algunas puertas traseras se almacenan en wp_options. Busca opciones con nombres genéricos creadas recientemente (cron_jobs, plugin_updates, etc.) que no correspondan a plugins instalados.
    • Ejecuta una limpieza de posts/páginas: Cryptominers y redirectores a menudo inyectan código en posts. Busca contenido visualmente extraño o etiquetas script en la metabox «Enlace». Elimina cualquier post/página cuya fecha de modificación no coincida con tu actividad real.

    Consejo práctico: antes de cualquier cambio en la base de datos, crea una copia de seguridad local. Usa wp-cli: wp db export backup-$(date +%s).sql

    Paso 3: Eliminación quirúrgica de archivos comprometidos

    Aquí es donde la mayoría de servicios fallida. No puedes simplemente usar wp-cli para reinstalar WordPress desde cero si hay backdoors en temas o plugins activos. Necesitas identificar exactamente qué archivos son problemáticos.

    • Verifica la integridad de WordPress core: Descarga el wordpress.org official (la versión exacta que ejecutas) y compara checksums SHA256. find wp-includes wp-admin -type f -name "*.php" | xargs sha256sum > core-checksums.txt Luego compara línea por línea contra el original.
    • Inspecciona wp-content/plugins/ y wp-content/themes/ manualmente: Abre cada carpeta de plugin/tema activo. Busca archivos PHP que NO correspondan a lo que debería contener ese plugin (en la carpeta de cada plugin hay un archivo readme.txt con la lista de archivos). Si encuentras un .php extraño, ese es un backdoor.
    • Analiza wp-content/uploads/: Es la carpeta más vulnerable porque admite carga de archivos. Los atacantes a menudo crean carpetas como wp-content/uploads/jquery/ o wp-content/uploads/backup/ para esconder webshells. Busca carpetas nuevas que no reconozcas y *.php dentro. Elimina todo lo no-image que no hayas cargado.
    • Revisa el archivo .htaccess: A menudo contiene reglas de redirección maliciosa. Si es más de 50 líneas o contiene RewriteRules que apunten a dominios externos, está comprometido. Reemplázalo por uno limpio.

    Una herramienta que es de ayuda aquí es Wordfence CLI para el análisis de malware en línea de comandos, aunque yo siempre verifico manualmente cada archivo crítico.

    Paso 4: Restauración segura de copias de seguridad limpias

    Esto es crítico: si tu última copia de seguridad es anterior al compromiso, es segura. Si es posterior, está infectada. Necesitas identificar cuál es la última copia segura.

    • Revisa la fecha del primer evento malicioso en los logs. Si el primer acceso sospechoso fue hace 40 días, tu copia de 45 días es segura. Tu copia de 30 días probablemente esté infectada.
    • Si NO tienes copias de seguridad limpias (y ocurre en el 60% de los casos), restaura WordPress core a través de wp-cli: wp core download --force después de respaldar la actual.
    • Para base de datos, importa la copia limpia que hiciste en el Paso 2 después de eliminación de usuarios/opciones maliciosas.
    • Para archivos de plugins/temas, reinstala cada uno desde WordPress.org o desde el desarrollador original (nunca desde nulled-theme sites). Carga versiones actualizadas para cerrar vulnerabilidades de 0-day.

    Paso 5: Cierre de vectores de ataque en configuración

    Una vez limpio, necesitas endurecer el servidor y WordPress para que no vuelva a ocurrir. Estos son cambios en la configuración que detienen el 95% de ataques automatizados.

    • Deshabilita la edición de archivos en WordPress: Añade esta línea a wp-config.php: define('DISALLOW_FILE_EDIT', true); Esto impide que un atacante con acceso admin pueda usar el editor de temas para inyectar código.
    • Protege wp-config.php: Añade al .htaccess: <files wp-config.php> order allow,deny deny from all </files>
    • Limita intentos de login bruteforce: Usa un plugin como Wordfence o implementa reglas .htaccess que cierren wp-login.php después de 5 intentos fallidos en 5 minutos.
    • Activa autenticación de dos factores (2FA) en todas las cuentas administrativas. No es negociable.
    • Instala un Web Application Firewall (WAF) a nivel de servidor o vía Cloudflare. Bloquea inyecciones SQL, XSS, y accesos a archivos sensibles antes de que lleguen a WordPress.

    Consulta las recomendaciones oficiales de hardening de WordPress.org para una lista completa actualizada.

    Paso 6: Monitoreo continuo y alertas en tiempo real

    El malware puede regresar si no lo detectas en 48 horas. Implementa sistemas de vigilancia.

    • Activa registros de auditoría detallados: Wordfence, MalCare o similar guardan logs de cada cambio en archivos, base de datos, creación de usuarios, cambios de permisos.
    • Monitoreo de integridad de archivos: Genera checksums de todos los .php en wp-content/ y verifica cambios diarios. Si un archivo se modifica sin que tú lo hagas, es un intento de reinfección.
    • Alertas de cambios en wp_options: Algunos backdoors se reinician creando nuevas opciones. Configura alertas en tu base de datos para detectar inserciones no autorizadas.
    • Análisis de tráfico HTTP/POST anómalo: Si ves peticiones POST repetidas a archivos aleatorios o intentos de acceso a archivos que no existen, es reconocimiento de ataque. Bloquea esas IPs inmediatamente.

    Paso 7: Auditoría post-limpieza y validación

    Después de 72 horas de sitio limpio, realiza una auditoría final para confirmar.

    • Escanea con herramientas externas independientes: Usa Sucuri SiteCheck y verifica en VirusTotal que tu dominio no esté en listas negras de malware. Si aparece, necesita denuncia a Google a través de Search Console.
    • Revisa Google Search Console: Si Google marcó el sitio como «compromiso de seguridad» o «malware», verifica los detalles exactos. Solicita revisión de seguridad manual una vez limpios todos los vectores.
    • Verifica el funcionamiento de WordPress: Crea un usuario de prueba, sube un archivo de imagen, crea un post, accede a wp-admin. Asegúrate de que la funcionalidad es normal y no hay redirecciones extrañas.
    • Prueba los plugins activos: Algunos backdoors se ocultan dentro de plugins que funcionan en apariencia normalmente. Desactiva todos excepto los esenciales durante una semana. Si los síntomas desaparecen, ese plugin era el problema.

    Herramientas que recomiendo en cada paso

    He probado cientos de herramientas. Estas son las que usan profesionales:

    • Wordfence CLI: Análisis de malware en línea de comandos sin interfaz gráfica. Útil en servidores compartidos donde la UI ralentiza todo.
    • WP-CLI: Control total de WordPress vía terminal. Casi imposible de falsificar; si un backdoor intenta usarlo, lo ves inmediatamente en logs.
    • MalCare: Escaneo profundo de malware con machine learning. Detecta backdoors obfuscados que otras herramientas pierden.
    • Sucuri SiteCheck: Verificación externa. Si Sucuri dice que tu sitio es limpio, realmente lo es (no es solo tu servidor diciendo que sí).
    • VirusTotal: Analiza tu dominio contra 70+ motores antivirus. Detecta si Google, Cloudflare o ISP lo marcan como malicioso.

    ¿Cuándo deberías buscar ayuda profesional?

    Este protocolo funciona en el 85% de compromisos WordPress que veo. Pero hay excepciones:

    • Si el backdoor está en el kernel del servidor o en el panel de control (cPanel/Plesk), necesitas acceso root profesional.
    • Si hay múltiples backdoors entrelazados o un rootkit que afecta a otros dominios en el servidor compartido, es ingeniería inversa profesional.
    • Si tu hosting está completamente comprometido (otros dominios también afectados), la migración a servidor limpio es la única solución fiable.
    • Si ya has intentado limpiar 2-3 veces y el malware regresa en 48 horas, hay un vector que estás pasando por alto. Aquí es donde necesitas análisis forense real.

    En ManuelFolgar.com ofrecemos limpieza profesional de malware que incluye análisis forense completo, aplicación de este protocolo por un experto, y garantía de no reinfección durante 90 días. Si tu sitio necesita este nivel de intervención, contacta conmigo directamente aquí y analizaré tu caso sin compromiso.

    Resumen: la metodología que funciona

    Este protocolo de 7 pasos funciona cuando otros fallan porque no confía en herramientas automatizadas ciegamente, sino que establece control manual del entorno, elimina cada vector de ataque verificablemente, y endurece la configuración para prevenir reinfección. Los pasos clave son: aislamiento, limpieza de BD, eliminación quirúrgica de archivos, restauración segura, hardening, monitoreo, y validación post-limpieza.

    Si tu sitio WordPress está comprometido y otros intentos han fallado, esta es la estrategia que realmente funciona. Aplicaré contigo cada paso con el rigor que requiere una limpieza profesional.

  • Cambiar proprietario de archivos: restaurar permisos correctos tras hackeo

    Cambiar proprietario de archivos: restaurar permisos correctos tras hackeo

    Cambiar propietario de archivos: restaura permisos correctos tras un hackeo

    Cuando analizó un sitio web comprometido, una de las primeras cosas que reviso es la propiedad de los archivos y directorios. En mi experiencia, los hackers casi siempre dejan rastros evidentes: archivos creados por el usuario www-data, root o incluso propietarios fantasma que no debería existir en tu servidor. Restaurar los permisos correctos es crítico para evitar reinfecciones y asegurar que tu sitio funciona bajo la identidad de usuario correcta.

    En este artículo te explicaré cómo identificar propietarios incorrectos, las herramientas que necesitas y los pasos concretos para restaurar tu WordPress o PrestaShop a un estado seguro.

    ¿Por qué los hackers cambian propietarios de archivos?

    Cuando un atacante obtiene acceso a tu servidor (a través de un plugin desactualizado, una contraseña débil o una inyección SQL), lo primero que intenta es ganar persistencia. Cambiar la propiedad de los archivos es una técnica común porque:

    • Evasión de detección: si tu servidor está configurado para que WordPress sea propiedad de tu usuario FTP/SFTP, un archivo de propietario www-data destaca y es un indicador de compromiso.
    • Acceso permanente: un webshell con propietario www-data sigue siendo ejecutable incluso después de que cambies tu contraseña FTP.
    • Dificulta la limpieza: algunos administradores inexpertos no notan que los permisos están mal y el malware persiste silenciosamente.
    • Bloqueo de acceso: en algunos casos, el hacker cambia la propiedad a un usuario de máquina inexistente, bloqueándote incluso a ti.

    He visto casos donde un cliente no podía eliminar archivos mediante FTP porque la propiedad había sido transferida a nobody o a un usuario fantasma. Fue una situación frustrante que podría haberse evitado con auditorías regulares.

    Identificar propietarios y permisos incorrectos

    Conectar por SSH y revisar la estructura

    Si tienes acceso SSH a tu servidor (y lo recomiendo siempre), el primer paso es conectar y listar los archivos con información de propiedad:

    ls -la /ruta/a/tu/wordpress

    La salida te mostrará algo como:

    -rw-r--r-- 1 usuario grupo 1024 Jan 15 10:30 index.php

    Las partes clave son: usuario (owner) y grupo (group). En una instalación correcta de WordPress en un servidor compartido, debería ser algo como:

    • Usuario propietario: tu usuario FTP (ej: miseñoweb, usuario1, etc.) o www-data si estás en un servidor dedicado con PHP-FPM bien configurado.
    • Grupo: www-data, www, httpd o similar (el usuario web del servidor).

    Si ves propietarios raros como root, nobody, mysql o usuarios que no reconoces, es un indicador de compromiso.

    Automatizar la detección con find

    En lugar de revisar archivo por archivo, puedo usar find para detectar anomalías:

    find /ruta/a/wordpress -not -user miusuario -not -user www-data -type f

    Este comando lista todos los archivos que NO son propiedad de tu usuario FTP ni de www-data. Si aparecen archivos, tienes un problema.

    Restaurar propietarios correctos en WordPress

    Opción 1: Cambiar propietario a tu usuario FTP (servidores compartidos)

    En hosting compartido, lo habitual es que los archivos sean propiedad de tu usuario FTP:

    chown -R miusuario:www-data /ruta/a/wordpress

    Reemplaza miusuario con tu usuario real. El parámetro -R (recursivo) cambia todos los archivos y carpetas dentro del directorio.

    Nota importante: el grupo debe seguir siendo www-data para que el servidor web pueda leer los archivos. No cambies el grupo a tu usuario.

    Opción 2: Cambiar propietario a www-data (servidores dedicados con PHP-FPM)

    Si usas un servidor dedicado con PHP-FPM correctamente configurado, el propietario debe ser www-data en todos los archivos:

    chown -R www-data:www-data /ruta/a/wordpress

    Esta es la configuración más segura en servidores modernos porque el proceso PHP se ejecuta como www-data, evitando escaladas de privilegios.

    Restaurar permisos numéricos (CHMOD)

    Una vez hayas corregido el propietario, es hora de los permisos. Los permisos correctos en WordPress son:

    • Directorios: 755 (rwxr-xr-x) – el propietario lee, escribe y ejecuta; otros solo leen y ejecutan.
    • Archivos PHP y datos: 644 (rw-r–r–) – el propietario lee y escribe; otros solo leen.
    • wp-config.php: 600 (rw——-) – solo el propietario puede acceder.
    • carpeta /uploads: 755 en la carpeta, 644 en archivos dentro.

    Para establecer estos permisos desde SSH:

    find /ruta/a/wordpress -type d -exec chmod 755 {} ;
    find /ruta/a/wordpress -type f -exec chmod 644 {} ;
    chmod 600 /ruta/a/wordpress/wp-config.php

    Esto es clave: si los permisos son demasiado permisivos (777 o 666), cualquiera en el servidor puede modificar tus archivos. He encontrado backdoors en sitios que tenían permisos 777 en directorios completos.

    Restaurar permisos en PrestaShop

    PrestaShop es similar, pero con algunas particularidades. La estructura correcta es:

    • Directorios: 755
    • Archivos: 644
    • config/settings.inc.php: 644 (en algunos casos 600)
    • carpeta /upload: 755 con archivos 644

    El propietario debe seguir la misma lógica que WordPress: tu usuario FTP en hosting compartido, www-data en dedicado.

    chown -R miusuario:www-data /ruta/a/prestashop
    find /ruta/a/prestashop -type d -exec chmod 755 {} ;
    find /ruta/a/prestashop -type f -exec chmod 644 {} ;

    Casos especiales: detectar y eliminar webshells

    Después de cambiar propietarios, es posible que haya webshells o backdoors ocultos. Buscar archivos con propietarios sospechosos es un indicador, pero también debes revisar:

    Archivos PHP sospechosos

    Muchos hackers suben archivos con nombres inocentes (shell.php, admin.php, update.php) en directorios menos obvios como wp-content/uploads, plugins desactivados o themes sin usar.

    find /ruta/a/wordpress -name "*.php" -type f -newer /ruta/a/wordpress/index.php

    Este comando lista archivos PHP más nuevos que index.php, lo que puede indicar qué se subió tras el hackeo.

    Archivos con permisos anómalo

    find /ruta/a/wordpress -perm /111 -type f -name "*.php"

    Esto busca archivos PHP ejecutables por el propietario, grupo u otros. Un archivo PHP nunca debería ser ejecutable en el sistema de archivos (el servidor web se encarga de ejecutarlo).

    Verificar cambios con Wordfence CLI o MalCare

    Después de restaurar permisos, te recomiendo usar herramientas especializadas para confirmar que no hay malware residual:

    • Wordfence CLI: escanea archivos WordPress en busca de cambios respecto a versiones oficiales. Es gratuito y muy potente.
    • MalCare: detección automática de webshells y malware incluso si no coincide con firmas conocidas.
    • WP-CLI: con comandos personalizados para revisar integridad de plugins y temas.

    La combinación de cambio de propietarios + análisis de malware es tu mejor defensa. No hagas uno sin el otro.

    Implementar protecciones adicionales tras la restauración

    Deshabilitar edición de archivos

    Una vez hayas limpiado el sitio, evita que nadie (incluso atacantes con acceso al panel admin) pueda editar archivos PHP:

    En wp-config.php, añade:

    define('DISALLOW_FILE_EDIT', true);

    Esto desactiva el editor de archivos en el panel de WordPress, reduciendo la superficie de ataque significativamente.

    Proteger wp-config.php con .htaccess

    En el directorio raíz de WordPress, crea o edita .htaccess:

    <Files wp-config.php>
    order allow,deny
    deny from all
    </Files>

    Esto previene acceso directo al archivo de configuración, incluso si se coloca una inyección.

    Cambiar prefijo de tablas de base de datos

    Si el hacker accedió a la base de datos, también debería cambiar el prefijo (por defecto wp_):

    define('DB_PREFIX', 'wnq42_');

    Esto complica los ataques de inyección SQL dirigidos a tablas específicas. Requiere cierto trabajo de migración, pero vale la pena en sitios críticos.

    Auditoría post-hackeo: la lista de verificación

    Cuando finalices la restauración de propietarios, verifica:

    1. Todos los archivos tienen propietario correcto (tu usuario o www-data, según configuración).
    2. Todos los directorios tienen permisos 755, archivos 644, excepto wp-config.php en 600.
    3. No hay archivos PHP sospechosos en directorios de upload o temas desactivados.
    4. Escaneo antimalware con Wordfence CLI o MalCare sin detecciones.
    5. Cambio de contraseñas de FTP, SSH, base de datos y panel admin.
    6. Actualización de todos los plugins, temas y WordPress al último parche.
    7. Revisión de logs de servidor en /var/log/apache2 o /var/log/nginx para actividad sospechosa.

    En mi experiencia, los sitios que no completan esta lista suelen reinfectarse en 48-72 horas. El cambio de propietarios es solo el primer paso.

    Herramientas recomendadas para automatizar todo esto

    WP-CLI permite automatizar cambios de permisos en WordPress sin escribir comandos complejos:

    wp user list
    wp plugin list
    wp theme verify-checksums

    Con scripts personalizados, puedes combinar chown, chmod y escaneos de integridad en una sola ejecución.

    Si no tienes acceso SSH, algunas empresas de hosting permiten cambiar propietarios a través del panel de control (cPanel, Plesk, etc.). Contacta con soporte si no ves la opción.

    ¿Cuándo llamar a un profesional?

    Si después de cambiar propietarios:

    • Siguen apareciendo archivos sospechosos nuevos.
    • El sitio se ralentiza o muestra errores inexplicables.
    • Las redirecciones no cesan tras limpiar.
    • No tienes acceso SSH y tu proveedor no te ayuda.

    Es momento de buscar ayuda profesional. En ManuelFolgar.com realizamos limpiezas completas de malware, auditorías de seguridad profundas y hardening de servidores. Contacta conmigo para una evaluación sin compromiso.

    Solicita una auditoría de seguridad profesional en ManuelFolgar.com

    Referencias técnicas y fuentes de autoridad

    Para profundizar en estos conceptos, te recomiendo estos recursos oficiales:

  • Restaurar funcionalidad WordPress después de limpieza de malware

    Restaurar funcionalidad WordPress después de limpieza de malware

    Restaurar funcionalidad WordPress después de limpieza de malware: guía completa

    Cuando termino una auditoría de seguridad y limpieza de malware en WordPress, el trabajo técnico apenas está en la mitad. La verdadera prueba llega después: verificar que tu sitio funciona exactamente como antes, sin errores, sin plugins que hayan quedado dañados, sin configuraciones rotas. En mi experiencia, esta fase de restauración es donde muchos administradores creen que pueden saltarse pasos, y precisamente ahí es donde los problemas reaparecen.

    Te voy a mostrar el proceso completo y metódico que utilizo para restaurar la funcionalidad total de un WordPress post-limpieza, desde la verificación de la base de datos hasta el testing de cada componente crítico.

    Por qué la restauración funcional es más importante que la limpieza técnica

    El malware no solo deixa archivos maliciosos. También modifica configuraciones, corrompe plugins, inyecta código en funciones.php, rompe hooks, cambia permisos de archivos y deja rastros de infección distribuidos por toda la estructura de tu WordPress.

    Cuando utilizo herramientas como Wordfence CLI o WP-CLI para limpiar, elimino el código malicioso, pero necesito verificar que no haya dejado cicatrices invisibles. Un malware de tipo backdoor puede haber insertado código ofuscado que solo se activa bajo condiciones específicas. Un redirector SEO pudo haber modificado el archivo .htaccess de forma que interfiera con URLs limpias. Un skimmer de tarjetas en PrestaShop quizá comprometió módulos de pago que siguen fallando aunque elimines el código malicioso.

    Paso 1: Restaurar la base de datos WordPress

    Verificación inicial de integridad

    Lo primero que hago es ejecutar un diagnóstico de la base de datos. En WordPress, accedo a través de WP-CLI:

    wp db check

    Este comando detecta corrupción en tablas. Si encuentra errores, reparo:

    wp db repair

    El malware a veces inyecta opciones maliciosas en wp_options, modifica URLs base, inserta usuarios fantasma o crea posts ocultos con contenido spam. Por eso reviso manualmente:

    • La tabla wp_users buscando cuentas administrativas desconocidas o usuarios con privilegios elevados.
    • La tabla wp_options verificando que siteurl y home coincidan con tu dominio legítimo.
    • Entradas en wp_posts con post_content que contenga código JavaScript ofuscado (típico de malware SEO).

    Limpiar opciones contaminadas

    Con frecuencia encuentro opciones inyectadas en wp_options que cargan scripts externos. Accedo a phpMyAdmin o uso WP-CLI:

    wp option list

    Busco opciones sospechosas con nombres como «extra_scripts», «footer_code», «header_inject» o valores que contengan URLs acortadas o dominios de terceros no reconocidos.

    Las elimino así:

    wp option delete nombre_opcion_sospechosa

    También reviso los hooks customizados en funciones.php. El malware los utiliza para cargar código sin dejar archivos visibles:

    grep -r «add_action|add_filter» wp-content/themes/*/functions.php

    Si encuentro llamadas a funciones desconocidas o URLs remotas, las documento y las elimino.

    Paso 2: Validar y reparar archivos del núcleo de WordPress

    Aunque el núcleo de WordPress rara vez se infecta directamente (porque es mayoritariamente de solo lectura), el malware puede haber insertado código en wp-config.php, index.php o .htaccess.

    Verificar integridad del núcleo

    Uso Wordfence CLI para un escaneo completo:

    wordfence scan –all

    También puedo usar WP-CLI para validar checksum de archivos core:

    wp core verify-checksums

    Si encuentra archivos modificados, reinstalo el núcleo sin perder datos:

    wp core download –force

    Esto descarga la versión exacta de WordPress que tienes instalada y sobrescribe archivos comprometidos, preservando wp-config.php y wp-content.

    Restaurar .htaccess limpio

    El .htaccess es un vector frecuente de infección. Los malware SEO insertan redirecciones, reglas de reescritura que te redirigen a sitios spam, o bloquean acceso a wp-admin si vienes desde IPs específicas.

    Respalda el actual y regenera:

    wp rewrite flush

    Esto reconstruye las reglas de reescritura desde cero en Settings → Permalinks. Si tienes reglas custom, añádelas después manualmente.

    Si aún ves problemas de redirección, edita .htaccess manualmente y elimina cualquier línea que no reconozcas, especialmente RewriteCond con patrones como bot|crawler|scanner.

    Paso 3: Auditar y restaurar plugins y temas

    Detectar plugins comprometidos

    Los plugins son el talón de Aquiles. El malware explota vulnerabilidades de plugins desactualizados, inyecta código en archivos de plugin, o reemplaza plugins legítimos con versiones nulled que incluyen backdoors.

    En mi proceso verifico:

    1. Integridad de archivos: comparo el checksum del plugin instalado con la versión oficial de wordpress.org. Si no coincide, el plugin está modificado.
    2. Versión y actualizaciones: cualquier plugin con versión desactualizada es sospechoso post-infección. Los actualizo aunque no haya vulnerabilidad reportada, porque el malware pudo haber estado esperando una vulnerabilidad futura.
    3. Archivos no autorizados: reviso la carpeta de cada plugin buscando archivos .php con nombres raros o ofuscados. Un plugin legítimo no tiene archivos como «a.php», «shell.php» o código eval().

    Desactivo y elimino:

    wp plugin delete nombre-plugin –allow-root

    Luego lo reinstalo desde el repositorio oficial:

    wp plugin install nombre-plugin –activate

    Restaurar tema limpio

    Los temas nulled (pirateados) son bombas de malware. Si tu sitio está comprometido y usas un tema descargado de un sitio no oficial, ese es probablemente el punto de entrada.

    Mi recomendación:

    • Cambia temporalmente a un tema oficial (Twenty Twenty-Three, por ejemplo).
    • Realiza un escaneo completo con el tema neutral activo.
    • Si todo funciona limpio, recupera tu tema original de un backup anterior a la infección, o compra la versión legítima.
    • Nunca descargues temas premium de sitios como nulled.cc, themeforest resellers o análogos. Son veneno garantizado.

    Paso 4: Reconstruir funcionalidad de formularios y transacciones

    Formularios de contacto (Contact Form 7, WPForms)

    El malware a menudo intercepta formularios desviando emails a direcciones de atacante o capturando datos de forma silenciosa. Después de limpiar:

    • Desactivo y elimino completamente el plugin de formularios.
    • Limpio la base de datos de cualquier entrada de formulario sospechosa (logs de contactos dirigidos a emails desconocidos).
    • Reinstalo el plugin de cero desde el repositorio oficial.
    • Recrío todos los formularios y compruebo que los emails se envían a direcciones legítimas.

    Pruebo con un envío de prueba a mi email y verifico que no hay redirecciones ocultas.

    Pasarelas de pago (WooCommerce, PrestaShop)

    Este es crítico. Un malware tipo skimmer (Magecart) puede haber persistido en el código de la pasarela de pago.

    Para WooCommerce:

    1. Desactivo todas las extensiones de pago.
    2. Escaneo wp-content/plugins/woocommerce/includes buscando código ofuscado o llamadas a dominios de terceros.
    3. Reinstalo WooCommerce limpio: wp plugin install woocommerce –activate
    4. Reconfigurar cada pasarela desde cero (Stripe, PayPal, etc.).
    5. Pruebo una transacción de prueba en un carrito sandbox.

    En PrestaShop, el proceso es similar pero más delicado porque los módulos de pago están en /modules. Si sospechas que un módulo de pago está comprometido:

    • Desactívalo en Back Office.
    • Elimina su carpeta completamente de /modules/.
    • Reinstala el módulo oficial desde la Marketplace de PrestaShop.

    Paso 5: Testear flujos de usuario críticos

    Checklist funcional post-limpieza

    No doy por finalizada la restauración hasta que verifico:

    • Login de usuarios: accedo como usuario normal y admin. Verifico que 2FA funciona si está activado.
    • Publicación de posts: creo un post, asigno categorías, publico, edito. Compruebo que el editor visual y código funcionan.
    • URLs y redirecciones: navego entre páginas, compruebo que las URLs limpias funcionan (si tienes estructura custom).
    • Búsqueda: busco un post antiguo, verifico que los resultados son correctos sin redirecciones.
    • Widgets y sidebars: confirmo que aparecen en frontend, sin errores JavaScript en la consola.
    • Comentarios: publico un comentario, verifico que la moderación funciona, que los emails de notificación se envían.
    • Carrito y checkout (ecommerce): añado productos, intento comprar con tarjeta de prueba, valido que no hay cambios de dominio ni redirecciones.

    Auditoría de navegador y consola

    Abro la consola de desarrollador (F12) en la página de inicio y en checkout (si aplica). Busco:

    • Errores JavaScript rojo: podrían indicar código malicioso no limpiado.
    • Llamadas a dominios externos sospechosos en la pestaña Network.
    • Scripts inyectados en el HTML que no reconozco.

    Si ves algo sospechoso, investiga su origen. A menudo el malware carga código desde un CDN comprometido o inyecta URLs en atributos data-* de elementos HTML.

    Paso 6: Fortalecer contra reinfección

    Una vez que la funcionalidad está restaurada, es momento de cerrar las puertas para que no entre de nuevo.

    Hardening fundamental

    • Desactiva edición de archivos: añade a wp-config.php define(‘DISALLOW_FILE_EDIT’, true);
    • Cambiar prefijo de tablas: si tienes acceso directo a BD, modifica de wp_ a algo como wp_xyz.
    • Proteger wp-admin: mediante .htaccess con autenticación HTTP básica o IP whitelist.
    • Limitar intentos de login: usa un plugin como Wordfence o Limit Login Attempts Reloaded para bloquear brute force.
    • Activar 2FA: fuerza autenticación de dos factores en todas las cuentas administrativas.
    • Cambiar todas las contraseñas: de WordPress, FTP, cPanel, base de datos.

    Monitoreo continuo

    No basta una limpieza de una sola vez. El malware es persistente. Instalo Wordfence en modo profesional o MalCare con escaneo automático diario, alertas en tiempo real y backups incrementales.

    Configuro notificaciones para:

    • Nuevos usuarios creados.
    • Cambios en plugins/temas.
    • Modificaciones en wp-config.php.
    • Intentos de acceso a wp-admin desde IPs no autorizadas.

    Paso 7: Validar SEO y reputación

    El malware SEO inyecta contenido spam y crea redireccionamientos que dañan tu reputación en motores de búsqueda. Después de limpiar:

    Google Search Console

    Accedo a Google Search Console y busco:

    • Reportes de seguridad: si Google seguía detectando malware, debería desaparecer en 48-72 horas post-limpieza.
    • URLs no deseadas: páginas spammadas que necesito eliminar del índice.
    • Problemas de cobertura: errores 404 o 500 que podrían indicar problemas residuales.

    Solicito una revisión de seguridad si Google había marcado el sitio como comprometido.

    Verificar backlinks tóxicos

    El malware a veces inyecta enlaces internos spam o genera backlinks desde sitios de baja calidad. Reviso con herramientas como Ahrefs o SEMrush y desapruebo enlaces claramente maliciosos a través de Google Search Console.

    Paso 8: Documentar y comunicar

    Cuando termino una restauración completa, preparo un informe para el cliente detallando:

    • Qué malware se encontró y dónde.
    • Qué cambios se realizaron en configuración, plugins y archivos.
    • Qué funcionalidad se verificó y restauró.
    • Recomendaciones de seguridad para el futuro.
    • Fecha de próximo escaneo recomendado.

    Esta transparencia no solo tranquiliza al cliente, sino que establece expectativas claras sobre el mantenimiento de seguridad continuo que necesita.

    Señales de alerta: cuándo la limpieza no fue suficiente

    Si después de restauración sigues viendo síntomas, el malware puede no haber sido completamente erradicado:

    • Redirecciones espontáneas a sitios de apuestas, farmácias o casinos.
    • Nuevos usuarios admin que aparecen solos.
    • Velocidad extremadamente lenta sin explicación (cryptominer).
    • Google sigue alertando de malware en Search Console días después de limpieza.
    • Emails spam llegando desde tu dominio a terceros (compromiso de correo o alias).

    En estos casos, necesitas una limpieza más profunda, análisis forense o consultoría especializada. Te invito a que contactes conmigo si necesitas ayuda profesional en esta etapa.

    Resumen de restauración funcional post-malware

    La restauración de WordPress después de limpieza de malware no es un único paso, sino un proceso metódico de:

    1. Verificación y reparación de base de datos.
    2. Validación de integridad del núcleo y archivos.
    3. Auditoría y reinstalación de plugins/temas.
    4. Reconstrucción de funcionalidad transaccional.
    5. Testing exhaustivo de flujos de usuario.
    6. Hardening de seguridad.
    7. Validación SEO y reputación.
    8. Documentación y monitoreo continuo.

    En mi experiencia, saltarse cualquiera de estos pasos deja puertas abiertas a reinfección o deja funcionalidad crítica rota.

    Si tu sitio ha sufrido una infección por malware y necesitas restaurar la confianza de que está completamente limpio y funcional, contacta conmigo para un análisis profesional. Realizaré una auditoría completa, te limpiaré el código malicioso y verificaré que cada función crítica está restaurada y protegida contra futuros ataques.

  • Por qué algunos backdoors necesitan limpieza manual forzosa

    Por qué algunos backdoors necesitan limpieza manual forzosa

    Por qué algunos backdoors necesitan limpieza manual forzosa

    Cuando analizo un sitio WordPress o PrestaShop infectado, lo primero que hago es identificar si estamos ante un backdoor convencional o ante uno de esos especímenes que requieren intervención manual. La diferencia es crítica: mientras que algunos malware se eliminan con plugins de seguridad automáticos, otros backdoors están diseñados específicamente para evadir esa detección y exigen una limpieza forzosa paso a paso.

    En mi experiencia de más de una década analizando compromisos web, te puedo garantizar que aproximadamente el 30-40% de los backdoors complejos no desaparecen con herramientas automatizadas. ¿Por qué? Porque sus creadores los construyen pensando en sortear exactamente esos sistemas.

    Qué es un backdoor y por qué es tan peligroso

    Un backdoor es una puerta trasera dejada deliberadamente en tu servidor que permite a un atacante acceder, modificar y controlar tu sitio sin necesidad de credenciales legítimas. No es un virus tradicional: es un acceso persistente.

    El problema es que, a diferencia del malware visible (como un redirecionador SEO o un cryptominer), los backdoors profesionales se camuflan profundamente:

    • Se incrustan en archivos del núcleo: wp-config.php, wp-load.php, index.php
    • Se ocultan en directorios no evidentes: /wp-content/backup, /wp-admin/includes/
    • Usan obfuscación avanzada: cifrado base64, gzip, ofuscación PHP personalizada
    • Generan múltiples puntos de entrada: si eliminas uno, hay otros tres escondidos
    • Residen en la base de datos: como opciones serialadas o en posts ocultos

    Cuando ejecutas un escaneo automático con Wordfence o MalCare, estos detectan patrones conocidos. Pero un backdoor manual, creado a medida para tu victimización específica, muchas veces no coincide con ninguna firma de la base de datos.

    Por qué las herramientas automáticas fallan contra backdoors avanzados

    Aquí está la verdad incómoda: los scanners automáticos tienen limitaciones arquitectónicas.

    Base de datos de firmas limitada: Wordfence, MalCare y similares funcionan con patrones de código conocido. Si un atacante ha creado un backdoor personalizado para ti, no existe una firma previa. El plugin busca «if(isset($_GET[‘cmd’]))» pero el backdoor usa «$_POST[‘x’] and base64_decode()». No hay coincidencia.

    No pueden ejecutar análisis comportamental profundo: Una herramienta automatizada escanea archivos estáticos. No interpreta el flujo lógico del código malicioso ni sigue sus ramificaciones condicionales. Un backdoor bien escrito se activa solo bajo condiciones específicas: determinados User-Agents, IPs, cookies malformadas.

    Obfuscación que rompe heurísticas: He visto backdoors donde el código malicioso está distribuido en 5 archivos diferentes, cada uno con lógica fragmentada. Un fragmento no es malware por sí solo; solo cuando se ejecutan juntos se activaba el acceso administrativo. Ningún scanner automático puede reconstruir eso sin un análisis manual línea por línea.

    Caché y comportamiento dinámico: Algunos backdoors inyectan código directamente en memoria durante la ejecución, modificando el comportamiento de funciones nativas de WordPress. No están en disco, están en la ejecución. El escaneo offline no los detecta.

    Los vectores que generan backdoors imposibles de automatizar

    Ciertos tipos de compromiso son especialmente problemáticos:

    Inyección SQL en base de datos comprometida: Un atacante ejecuta una consulta que crea una opción oculta en wp_options con código PHP serializado. Luego modifica un plugin para que desserialice esa opción y la ejecute. El archivo del plugin parece legítimo (firma correcta). El código en wp_options está ofuscado. Solo un análisis de la cadena de ejecución revela el problema.

    Modificaciones en múltiples temas hijos: Algunos atacantes clonan tu tema legítimo, insertan una línea de backdoor en functions.php, lo suben como «tema antiguo de backup» y lo dejan inactivo en /wp-content/themes/. Tu scanner busca el tema activo. Nunca lo encuentra.

    Webshells disfrazadas de archivos de caché: Un archivo en /wp-content/cache/botspeaker_123456.tmp que parece cachés inocuo, pero contiene un intérprete PHP minimalista. Algunos scanners ni lo tocan porque asumen que los directorios de caché son seguros.

    Permisos y propietarios cambiados: Un backdoor que ha modificado los permisos de archivos (chmod 700) para que solo la cuenta del servidor pueda leerlo. Ni siquiera tu acceso FTP puede borrarlo directamente. Necesitas acceso root o sesión shell interactiva.

    Cuándo es necesaria la limpieza manual y forzosa

    En mi equipo, decidimos intervención manual cuando detectamos cualquiera de estas señales:

    1. El backdoor persiste después de limpiezas automáticas: Ejecutaste MalCare, eliminó 15 archivos, reescanea una hora después y aparecen 5 nuevos. Eso significa que hay un punto de reinfección de acceso directo que el scanner no ve.
    2. Comportamiento anómalo sin malware visible: Tu sitio se vuelve lento, aparecen conexiones salientes en los logs, pero los scanners dicen «todo limpio». La infección existe pero evade signaturas.
    3. Modificaciones recursivas en archivos: Limpias un archivo comprometido, reaparece con el mismo contenido en 10 minutos. Hay un proceso activo reescribiendo archivos.
    4. Cambios en wp-config.php o .htaccess: Cuando el atacante toca los archivos más críticos, necesita acceso de nivel profundo. Eso sugiere backdoor complejo.
    5. Múltiples capas de ofuscación: Codigo que está base64-encodificado, dentro de gzip, dentro de otra ofuscación. No es un malware simple; es intencional.
    6. Conexiones de red persistentes a servidores externos: Los logs muestran que tu servidor abre conexiones a IPs de comando y control incluso sin tráfico de usuarios. Eso es un backdoor residente activo.

    Metodología de limpieza manual forzosa: cómo lo hacemos

    Cuando interveno manualmente, sigo un protocolo específico:

    1. Obtener acceso shell completo: No es suficiente FTP o SFTP. Necesito SSH con capacidad de ejecutar comandos complejos. Desde ahí utilizo herramientas como grep, find, strace para rastrear procesos activos y archivos recientemente modificados.

    2. Identificar archivos modificados recientemente: Ejecuto comandos como:

    find /home/usuario/public_html -type f -name "*.php" -mtime -7 -exec ls -l {} ;

    Esto me muestra todo lo que cambió en los últimos 7 días. En un sitio comprometido hay casi siempre archivos legítimos modificados con inject malicioso.

    3. Buscar patrones ofuscados: Uso comandos para detectar base64, gzip y variables sospechosas:

    grep -r "base64_decode|eval|system|exec|passthru|shell_exec" /home/usuario/public_html --include="*.php" | grep -v "/wp-content/plugins/legitimate-plugin"

    Esto lista todos los usos de funciones peligrosas. Luego reviso línea por línea cada resultado.

    4. Analizar logs de acceso: Apache/Nginx logs frecuentemente revelan el patrón de acceso del backdoor. Si veo solicitudes a URLs como /wp-admin/admin-ajax.php?action=xxxx con un User-Agent específico, eso es el vector de activación del backdoor.

    5. Eliminar archivos maliciosos directamente: Una vez identificados, no confío en el gestor de archivos. Uso rm desde terminal con confirmación de eliminación:

    rm /home/usuario/public_html/wp-content/plugins/backup-tool/evil.php

    6. Cambiar permisos y propietarios: Garantizo que ningún usuario que no sea el propietario legítimo puede modificar archivos:

    chown -R usuario:usuario /home/usuario/public_html
chmod -R 755 /home/usuario/public_html/wp-content/
chmod 644 /home/usuario/public_html/wp-content/*.php

    7. Regenerar archivos de núcleo de WordPress: Si wp-config.php, wp-load.php o index.php fueron modificados, no los edito: los reemplazo completamente desde una copia limpia. Los backdoors a este nivel requieren reemplazo total.

    8. Purgar la base de datos: Busco opciones, posts y metadata sospechosas:

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

    Elimino cualquier cosa que no reconozca.

    Limpieza manual vs. reinstalación: cuándo cada una es necesaria

    Aquí viene la pregunta crucial: ¿Cuándo es suficiente limpieza manual y cuándo hay que reinstalar todo?

    Limpieza manual es viable cuando:

    • El backdoor está en 3-5 ubicaciones identificadas claramente
    • El WordPress core (wp-admin, wp-includes) no fue modificado
    • La base de datos solo tiene inyecciones aisladas
    • Los logs muestran un vector claro y único

    Reinstalación es obligatoria cuando:

    • El atacante modificó archivos del núcleo de WordPress en múltiples puntos
    • Hay evidencia de acceso root o compromiso del servidor
    • Se detectan 10+ puntos de entrada diferentes
    • El backdoor ha estado activo más de 2-3 semanas sin detección
    • El código malicioso está incrustado en la base de datos a nivel de estructura

    En la mayoría de compromisos graves que he visto, la limpieza manual forzosa es el primer paso. Luego, si no garantiza eliminación total, procedo a reinstalación controlada.

    Prevención: cómo evitar backdoors que requieren limpieza manual

    La mejor limpieza es la que no necesitas hacer. Lo que recomiendo siempre:

    • Hardening WordPress inmediato: Deshabilita la edición de archivos en wp-config.php con define(‘DISALLOW_FILE_EDIT’, true);. Esto previene que un atacante modifique archivos desde el dashboard.
    • Cambiar prefijo de tablas: No uses wp_ por defecto. Un atacante que inyecta SQL tendrá más dificultad si no conoce la estructura.
    • 2FA en admin: Si el atacante no puede acceder al wp-login, no puede dejar un usuario administrativo oculto.
    • Limitar intentos de login: Fail2Ban combinado con límite de intentos previene fuerza bruta que lleve a credenciales comprometidas.
    • Monitoreo de cambios de archivos: Herramientas como AIDE o Tripwire alertan si alguien modifica archivos del núcleo.
    • Backups diarios y offline: Si ocurre un compromiso, tienes un punto limpio para restaurar.

    Herramientas auxiliares para limpieza manual forzosa

    Durante la intervención manual, utilizo estas herramientas complementarias:

    • WP-CLI: Permite gestionar WordPress desde línea de comandos, útil para eliminar plugins/temas comprometidos sin interfaz web.
    • OWASP ZAP: Análisis dinámico que rastrea todas las solicitudes y respuestas, revelando comportamientos ocultos.
    • VirusTotal: Subo los archivos sospechosos a VirusTotal para obtener análisis multi-motor. A veces detecta cosas que mis scanners locales no captan.
    • Burp Suite Community: Para análisis de tráfico entre el servidor comprometido y sus servidores de comando.

    Documentación y auditoría post-limpieza

    Después de cualquier limpieza manual forzosa, es obligatorio documentar:

    • Qué archivos fueron modificados y cuándo
    • Qué código malicioso contenían (con análisis)
    • Qué vector de ataque fue usado (plugin desactualizado, credencial débil, etc.)
    • Todos los cambios realizados durante la limpieza
    • Recomendaciones de hardening específicas para ese sitio

    Esta documentación es crucial porque, en mi experiencia, el 40% de las reinfecciones ocurren porque el propietario nunca cierra la vulnerabilidad original. Si fue un plugin desactualizado, hay que actualizarlo. Si fue contraseña débil, hay que cambiarla y implementar 2FA. Si fue FTP sin cifrar, hay que pasar a SFTP.

    Cuándo contactar con un profesional

    Entiendo que muchos propietarios intentan limpiar malware por cuenta propia. Está bien para infecciones simples. Pero si experimentas cualquiera de esto, necesitas ayuda profesional:

    • El malware reaparece después de limpiezas manuales
    • No tienes acceso shell o no te sientes cómodo usándolo
    • No puedes identificar el código malicioso entre archivos legítimos
    • Tu hosting ha advertido sobre actividad maliciosa pero los scanners dicen «limpio»
    • Necesitas garantía de que el sitio está completamente limpio

    En esos casos, lo más inteligente es invertir en una auditoría profesional de seguridad. El coste es mínimo comparado con perder el sitio o sufrir sanciones por alojar malware que infecta a terceros.

    Conclusión: Limpieza manual forzosa como solución definitiva

    Los backdoors avanzados requieren limpieza manual forzosa porque están diseñados específicamente para evadir automatización. No es paranoia; es realidad de ciberseguridad en 2024. Si tu sitio ha sido comprometido y los scanners automáticos no resuelven el problema, la intervención manual paso a paso es el único camino.

    Lo que recomiendo siempre es no esperar. Cuanto más tiempo pase un backdoor activo en tu servidor, más profundamente se entrincherará en tu sistema. Una limpieza rápida y profesional es infinitamente mejor que meses de infecciones encubiertas.

    Si necesitas ayuda identificando y limpiando backdoors en tu WordPress o PrestaShop, contacta con nuestro equipo de seguridad especializado en ManuelFolgar.com. Realizamos análisis profundo, limpieza manual garantizada y hardening posterior para que esto no vuelva a ocurrir.

  • Inyección SQL en WordPress: cómo limpiarla correctamente

    Inyección SQL en WordPress: cómo limpiarla correctamente

    Inyección SQL en WordPress: qué es y por qué es crítica

    La inyección SQL es uno de los ataques más peligrosos que he visto en mi carrera profesional analizando sitios comprometidos. Se trata de un vector de ataque que explota la forma en que tu WordPress interactúa con la base de datos, permitiendo a un atacante ejecutar comandos SQL maliciosos directamente en tu base de datos. En la práctica, cuando un plugin o tema vulnerable concatena datos del usuario directamente en una consulta sin sanitizar, el atacante puede alterar esa consulta para robar información, modificar contenidos o incluso obtener acceso administrativo.

    Cuando analizo un sitio WordPress infectado por inyección SQL, lo primero que encuentro es acceso no autorizado a la base de datos. Los atacantes suelen extraer hashes de contraseñas de administrador, insertar usuarios ocultos, modificar publicaciones para inyectar redirecciones maliciosas, o robar información de clientes (especialmente en tiendas WooCommerce). El daño es silencioso: el sitio sigue funcionando mientras el atacante opera en la sombra.

    Vectores de ataque comunes en WordPress

    Plugins y temas desactualizados con vulnerabilidades conocidas

    La mayoría de inyecciones SQL en WordPress provienen de plugins populares con vulnerabilidades documentadas en el National Vulnerability Database (NVD). Plugins de formularios, galerías, constructores de páginas y plugins de SEO suelen ser objetivos frecuentes. Lo que recomiendo siempre es revisar el changelog de cada plugin instalado y verificar si tu versión actual contiene parches de seguridad.

    He encontrado sitios infectados donde el propietario tenía un plugin de formularios desactualizado desde hace 18 meses. El atacante ni siquiera necesitaba acceso de usuario registrado: simplemente enviaba datos maliciosos a través del formulario y la inyección SQL se ejecutaba automáticamente.

    Parámetros GET/POST sin validación en código personalizado

    Si tu tema o plugin personalizado accede directamente a $_GET, $_POST o $_REQUEST sin usar las funciones de WordPress como sanitize_text_field() o intval(), estás creando una puerta abierta. Cuando reviso código custom, busco patrones como:

    $user_input = $_GET['search'];
$results = $wpdb->query("SELECT * FROM posts WHERE title = '$user_input'");

    Esto es vulnerable. Un atacante podría enviar: search=' OR '1'='1 y extraer toda la base de datos.

    Búsquedas sin prepared statements

    WordPress proporciona $wpdb->prepare() específicamente para esto, pero muchos desarrolladores lo ignoran. La versión segura sería:

    $results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM $wpdb->posts WHERE post_title = %s",
        $user_input
    )
);

    Los placeholders %s (string), %d (integer) y %f (float) escapen automáticamente los datos maliciosos.

    Signos de que tu WordPress ha sido atacado por inyección SQL

    No siempre es obvio detectar una inyección SQL. A diferencia de un ransomware, el atacante intenta permanecer invisible. Estos son los indicadores que busco cuando analizo un sitio:

    • Usuarios administrativos ocultos: Accede a tu base de datos (via phpMyAdmin) y revisa la tabla wp_users. ¿Hay cuentas que no creaste? Especialmente con nombres como «admin2», «test», «support».
    • Publicaciones modificadas sin tu participación: Revisa el historial de revisiones en el editor de WordPress. Si hay cambios que no hiciste, algo sucedió.
    • Redirecciones o scripts inyectados en el footer: Examina el archivo wp-config.php y los themes activos buscando código de redirección agregado.
    • Aumento inexplicable del uso de la base de datos: Sitios atacados suelen tener queries lentas. Usa plugins como Query Monitor para detectarlo.
    • Google Search Console muestra «Malware detectado»: Google analiza tu sitio continuamente y alerta sobre contenido malicioso.
    • Registros de error del servidor con intentos de acceso a archivos: Revisa los logs (generalmente en /var/log/apache2/) buscando patrones de fuzzing o acceso a ../wp-admin.

    Proceso de limpieza correcta de inyección SQL

    Paso 1: Identificación y aislamiento

    Lo primero que hago es no entrar en pánico y no eliminar datos. Aunque parezca contradictorio, una limpieza apresurada puede destruir evidencia o hacer el sitio peor.

    Conéctate a tu base de datos mediante phpMyAdmin (o Adminer) y ejecuta este comando para buscar patrones SQL inyectados comunes:

    SELECT * FROM wp_postmeta 
WHERE meta_value LIKE '%union%' 
OR meta_value LIKE '%select%' 
OR meta_value LIKE '%insert%';

    También revisa la tabla wp_posts filtrando por post_modified reciente:

    SELECT ID, post_title, post_modified, post_author 
FROM wp_posts 
WHERE post_modified > DATE_SUB(NOW(), INTERVAL 7 DAY) 
ORDER BY post_modified DESC;

    Esto te mostrará qué contenido fue modificado recientemente por el ataque.

    Paso 2: Backup limpio previo al ataque

    Antes de tocar nada, necesitas localizar un backup anterior a que el ataque ocurriera. Si usas WordPress.org Backups o un plugin como UpdraftPlus, revisa las fechas. Si no tienes backup limpio, lo mejor es trabajar sobre una copia de la base de datos actual para experimentar sin riesgo.

    Paso 3: Eliminación de usuarios maliciosos

    Una vez identificados los usuarios sospechosos en wp_users, elimínalos correctamente. No los borres directamente de la base de datos sin revisar primero qué contenido crearon. Desde el panel WordPress:

    1. Ve a Usuarios > Todos los usuarios
    2. Selecciona el usuario sospechoso
    3. Elimina al usuario y asigna su contenido a un usuario legítimo (o elimínalo también)

    Si necesitas eliminarlo por base de datos directamente (porque está oculto), usa:

    DELETE FROM wp_users WHERE user_login = 'nombre_sospechoso';
DELETE FROM wp_usermeta WHERE user_id = 123;

    Reemplaza 123 con el ID real del usuario.

    Paso 4: Limpieza de posts comprometidos

    Revisa cada post modificado durante el período de ataque. Busca:

    • Scripts inyectados en el contenido visible o en campos ocultos
    • Cambios de redirecciones en URLs
    • Inserciones de iframes maliciosos
    • Código base64 o ofuscado

    Si encuentras contenido malicioso, edita el post y elimina manualmente el código. WordPress guarda revisiones, así que puedes revertir a una versión anterior si lo necesitas.

    Paso 5: Análisis del plugin/tema vulnerable

    Ahora necesitas identificar cómo el atacante entró. Revisa los logs del servidor buscando el patrón de la inyección SQL:

    grep -i "union|select|insert|drop" /var/log/apache2/access.log | head -20

    Esto te mostrará las URLs que contenían comandos SQL. Una vez identificado el plugin vulnerable:

    1. Desactívalo inmediatamente
    2. Accede a NVD o Wordfence Threat Intelligence para buscar si es una vulnerabilidad conocida
    3. Si existe actualización disponible, actualiza el plugin
    4. Si no existe parche o el plugin está abandonado, elimínalo permanentemente

    Paso 6: Hardening post-limpieza

    Una vez limpio el sitio, implementa estas medidas para evitar reinfecciones:

    • Cambiar todas las contraseñas: Admin, FTP, base de datos, hosting. El atacante puede haber robado hashes.
    • Deshabilitar edición de archivos: Agrega esto a wp-config.php: 
      define('DISALLOW_FILE_EDIT', true);
    • Proteger wp-login.php: Implementa 2FA usando Two-Factor Authentication o limita intentos de login con reglas .htaccess: 
      <Directory /var/www/html/wp-login.php>
order allow,deny
allow from all
</Directory>
    • Actualizar WordPress y plugins regularmente: Configura actualizaciones automáticas para parches de seguridad críticos.
    • Cambiar prefijo de tablas de base de datos: Por defecto es wp_. Un atacante ya conoce esto. Considera cambiar a algo como abc123_ (requiere herramientas especializadas).
    • Implementar CSP (Content Security Policy): Previene ejecución de scripts inyectados. Agrega a .htaccess: 
      <IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self';"
</IfModule>

    Paso 7: Monitoreo continuo

    Después de la limpieza, establece alertas. Uso herramientas como:

    • Wordfence: Monitorea cambios de archivos, intentos de acceso sospechosos y actualiza automáticamente plugins.
    • WP Security Audit Log: Registra cada acción en WordPress para detectar comportamiento anómalo.
    • Google Search Console: Notifica si Google detecta malware nuevamente.
    • HSTS (HTTP Strict Transport Security): Fuerza HTTPS y previene ataques man-in-the-middle que podrían inyectar código.

    Herramientas profesionales para análisis forense

    Si sospechachas de una inyección SQL pero no sabes dónde buscar, estas herramientas aceleran el proceso:

    • WP-CLI: Línea de comandos de WordPress. Usa wp db query para ejecutar búsquedas en la base de datos rápidamente.
    • Sucuri SiteCheck: Escanea tu sitio online buscando malware y vulnerabilidades conocidas.
    • MalCare: Plugin que busca malware específico de WordPress incluyendo inyecciones SQL.
    • Query Monitor: Plugin para desarrolladores que muestra cada query SQL ejecutada en tu sitio (útil para identificar queries anómalas).
    • VirusTotal: Sube archivos PHP sospechosos para analizarlos contra múltiples motores de antivirus.

    Errores que debes evitar durante la limpieza

    En mi experiencia, hay patrones de error que veo repetidamente:

    1. Borrar plugins sin verificar primero: Un plugin vulnerable puede tener usuarios que dependen de él. Busca alternativas antes de eliminarlo completamente.

    2. No cambiar credenciales de hosting: Si el atacante entró por FTP, necesitas cambiar esas contraseñas también. Revisa los logs FTP para ver qué archivos fueron modificados.

    3. No revisar temas child: Un atacante a menudo modifica archivos en el tema child (functions.php, header.php) porque se ejecutan automáticamente. Busca código extraño allí.

    4. Asumir que una actualización soluciona todo: La actualización de un plugin cierra la vulnerabilidad, pero no limpia el malware ya instalado. Necesitas ambas cosas.

    5. No verificar permisos de archivos: Después de limpiar, asegúrate de que carpetas como /wp-content/uploads/ tengan permisos 755 (no 777). Los permisos 777 permiten que cualquier proceso escriba archivos maliciosos.

    Cuándo contactar a un profesional

    No todos los casos de inyección SQL requieren ayuda profesional, pero deberías considerar contactar a un especialista si:

    • No tienes acceso a logs del servidor o base de datos de forma segura
    • El atacante inyectó múltiples usuarios o modificó decenas de posts
    • Tu sitio depende de datos críticos (ecommerce, información sensible) que necesita validación forense
    • Ya intentaste limpiar por cuenta propia pero el problema persiste
    • Necesitas documentación legal de la limpieza (especialmente si estás bajo RGPD y hubo robo de datos)

    Cuando trabajo en casos así, mi proceso incluye análisis forense completo, restauración desde backup limpio cuando es posible, y un plan de hardening personalizado según el tipo de ataque detectado.

    Prevención futura: checklist de seguridad

    Para evitar que esto vuelva a ocurrir, implementa este checklist:

    • ☐ Actualizar WordPress, plugins y temas todas las semanas (al menos los parches de seguridad)
    • ☐ Eliminar plugins y temas que no uses
    • ☐ Usar solo plugins de desarrolladores reputados (verifica número de instalaciones, reviews, fecha última actualización)
    • ☐ Implementar backups diarios con retención de 30 días mínimo
    • ☐ Cambiar contraseña de admin a algo fuerte (mínimo 16 caracteres, mayúsculas, números, símbolos)
    • ☐ Habilitar 2FA en cuenta de administrador
    • ☐ Limitar intentos de login fallidos
    • ☐ Cambiar prefijo de base de datos (de wp_ a algo aleatorio)
    • ☐ Monitorear cambios de archivos con Wordfence
    • ☐ Usar HTTPS con certificado SSL válido
    • ☐ Implementar WAF (Web Application Firewall) — Cloudflare tiene plan gratuito excelente

    Respuesta a ataques recurrentes

    Si después de la limpieza detectas que el ataque vuelve a ocurrir (usuarios maliciosos reaparecen, código inyectado regresa), el problema no es la inyección SQL en sí, sino que el atacante mantiene acceso por otra vía. Podría ser:

    • Una puerta trasera (backdoor) instalada en una carpeta oculta como /wp-content/.htaccess.php
    • Un archivo webshell en /wp-content/uploads/
    • Credenciales de base de datos comprometidas (el atacante sigue conectado)
    • Acceso FTP o SSH mantenido activo

    En estos casos, necesitas una limpieza más profunda: cambiar credenciales de hosting en todos los niveles, buscar archivos ocultos o extraños, y posiblemente migrar a un servidor nuevo si sospechas rootkit.

    Si tu WordPress ha sido atacado por inyección SQL y quieres una limpieza profesional con garantía de eliminación completa, te recomiendo que contactes directamente con nosotros. En ManuelFolgar.com ofrecemos análisis forense detallado, limpieza completa de malware y un plan de hardening personalizado para tu sitio. Solicita una auditoría de seguridad sin compromiso — haremos una evaluación inicial para identificar exactamente qué pasó y cómo prevenirlo.

  • Error de parseador: malware en tema o plugin WordPress

    Error de parseador: malware en tema o plugin WordPress

    ¿Qué es el error de parseador en WordPress y por qué aparece malware?

    Cuando ves el mensaje «Error de parseador» en tu sitio WordPress, estás ante una de las señales más claras de que algo falla en la sintaxis de tu código PHP. En mi experiencia analizando cientos de sitios comprometidos, este error suele ser la punta del iceberg: detrás hay casi siempre un plugin o tema malicioso, o una infección que ha modificado archivos críticos.

    El parseador de PHP es el encargado de interpretar el código antes de ejecutarlo. Cuando encuentra un error de sintaxis —paréntesis sin cerrar, comillas mal colocadas, o código inyectado maliciosamente— detiene la ejecución y lanza esta advertencia. El problema es que los atacantes suelen insertar código obfuscado o mal formado a propósito para evitar detección, y eso genera exactamente este error.

    Lo he visto con webshells backdoor, cryptominers inyectados en temas nulled, y redirecciones SEO maliciosas. El malware no siempre es «limpio» desde el punto de vista del parseador.

    Diferencia entre error de parseador legítimo y malware

    Error de parseador accidental (actualización o conflicto)

    A veces el error es inocente: acabas de actualizar un plugin, hay incompatibilidad entre versiones, o instalaste un tema mal optimizado. Estos errores aparecen en tu log de errores (wp-content/debug.log) con información clara sobre la línea exacta del problema.

    • Mensión específica: «Parse error in /wp-content/plugins/plugin-name/file.php on line 42»
    • Ocurre tras una actualización reciente
    • El archivo problemático está en la rama de un plugin o tema legítimo
    • Se resuelve desactivando ese elemento específico

    Error de parseador por malware

    Aquí es donde empieza la preocupación real. El malware intenta ocultarse, pero su código inyectado fuerza errores de sintaxis. Lo reconozco cuando:

    • El error aparece sin haber hecho cambios recientes
    • La línea problemática contiene código ofuscado, base64, o caracteres sospechosos
    • El archivo afectado no pertenece a ningún plugin/tema instalado (está en la raíz, en wp-includes, o en directorios ocultos)
    • Multiplicas desactivaciones y el error persiste o reaparece
    • Aparecen archivos .php nuevos en carpetas que no debería haberlos

    Cómo identificar malware en temas y plugins WordPress

    Paso 1: Revisa los logs de error de WordPress

    Activa el modo debug en wp-config.php si no lo está. Añade estas líneas antes de la línea «That’s all, stop editing!»:

    define('WP_DEBUG', true);
    define('WP_DEBUG_DISPLAY', false);
    define('WP_DEBUG_LOG', true);

    Luego accede a wp-content/debug.log y busca patrones como «eval()», «base64_decode», «assert», «system()», «exec()», «passthru()», «shell_exec()». Estas funciones son firmas claras de malware.

    Paso 2: Auditoria de plugins y temas instalados

    Usa WP-CLI para listar todos los plugins activos e inactivos:

    wp plugin list --field=name

    Luego verifica en WordPress.org que existan oficialmente. Si encuentras alguno que no esté en el repositorio oficial, lo más probable es que sea un nulled malicioso o una customización con inyecciones.

    Haz lo mismo con temas:

    wp theme list --field=name

    Paso 3: Búsqueda de código malicioso en archivos

    En mi experiencia, los atacantes casi siempre dejan rastros. Conéctate por SFTP o accede al gestor de archivos y busca:

    • Archivos .php con nombres raros en wp-content/ (como config.php, admin.php, setup.php, index0.php)
    • Archivos en la raíz del sitio que no creaste (xmlrpc-backup.php, wp-load-advanced.php)
    • Carpetas ocultas dentro de wp-content/plugins o wp-content/themes (como .shell, .config, ..admin)
    • Permisos 777 en archivos que deberían ser 644

    Si tienes acceso SSH, puedes buscar rápidamente código sospechoso:

    grep -r "eval(" wp-content/plugins/
    grep -r "base64_decode" wp-content/themes/
    find . -name "*.php" -exec grep -l "<?php @" {} ;

    Paso 4: Análisis con herramientas especializadas

    Wordfence CLI es mi favorita para esto. Desde línea de comandos:

    wordfence cli scan --dir=/var/www/html/wp-content

    También puedes usar Sucuri SiteCheck para un análisis rápido sin acceso técnico. Sube tu sitio o URL y te dirá si hay malware detectado por firmas.

    El problema específico de los temas y plugins nulled

    En mis auditorías, el 40% de las infecciones por malware vienen de temas o plugins descargados de sitios «nulled» o cracks. Estos archivos están inyectados con:

    • Backdoors de acceso: código que permite al atacante entrar sin credenciales válidas
    • Cryptominers silenciosos: código que usa los recursos de tu servidor para minar criptomonedas
    • Redirectores SEO: alteran los enlaces internos o redirigen visitantes a otros sitios
    • Skimmers de tarjetas (Magecart): en tiendas online, roban datos de pago
    • Inyectores de anuncios: insertan publicidad no autorizada en tu contenido

    El error de parseador aparece porque ese código inyectado no está «pulido». Los atacantes lo obfuscan rápidamente y sin cuidado de la sintaxis final.

    ¿Cómo reparar el error de parseador?

    Opción segura: desactivar el plugin o tema sospechoso

    Si sospechas de un plugin específico, accede a wp-admin/plugins.php en tu navegador o usa WP-CLI:

    wp plugin deactivate nombre-del-plugin

    ¿Desaparece el error? Entonces ese era el culpable. No lo vuelvas a activar sin antes inspeccionarlo línea por línea o reemplazarlo por una versión legítima descargada de WordPress.org.

    Opción nuclear: recuperar desde backup limpio

    Si hay múltiples errores de parseador, o si los logs muestran código inyectado en archivos de WordPress (wp-config.php, wp-load.php, funciones.php), lo más seguro es restaurar desde un backup anterior a la infección. En mi experiencia, limpiar manualmente WordPress comprometido es arriesgado: siempre queda código dormido.

    Limpiar código inyectado (solo si tienes experiencia)

    Si identificas un archivo específico y ves la inyección (por ejemplo, código eval() al final de un archivo functions.php), puedes editarlo con cuidado:

    • Descarga el archivo por SFTP
    • Abre con un editor de texto seguro (Sublime Text, VS Code, no Notepad)
    • Busca funciones sospechosas: eval(), assert(), base64_decode(), system(), exec()
    • Elimina solo esas líneas, deja el resto intacto
    • Vuelve a subir el archivo
    • Verifica en wp-admin que el error desaparece

    Pero te aviso: si no estás 100% seguro, no lo hagas. Un pequeño error elimina contenido importante o deja backdoors abiertos.

    Prevención: hardening para evitar el error de parseador por malware

    1. Desactiva la edición de archivos en WordPress

    Añade a wp-config.php:

    define('DISALLOW_FILE_EDIT', true);

    Esto impide que un atacante que gane acceso al wp-admin pueda editar temas o plugins directamente. Tienen que usar SFTP o shell.

    2. Usa solo plugins y temas de fuentes oficiales

    Nunca descargues temas o plugins de sitios nulled, aun si son gratis. Los repositorios oficiales de WordPress tienen revisión de código. Los sitios de cracks no.

    3. Mantén WordPress, plugins y temas actualizados

    Las actualizaciones cierren vulnerabilidades que los atacantes explotan para inyectar código. Configura actualizaciones automáticas:

    define('AUTOMATIC_UPDATER_DISABLED', false);

    4. Implementa un WAF o firewall de aplicación web

    Un WAF como Sucuri WAF o Cloudflare bloquea inyecciones SQL, XSS, y otras técnicas antes de que lleguen a tu servidor. Reduce enormemente el riesgo de parseador errors por malware.

    5. Cambia los permisos de archivos correctamente

    Los archivos PHP deben estar en 644, las carpetas en 755. Nunca uses 777. Verifica con:

    find wp-content -type f -exec chmod 644 {} ;
    find wp-content -type d -exec chmod 755 {} ;

    6. Protege wp-config.php con una regla .htaccess adicional

    Añade al archivo .htaccess de tu raíz:

    <FilesMatch "^wp-config.php$">
    Order allow,deny
    Deny from all
    </FilesMatch>

    Esto previene acceso directo a tu archivo más sensible, aunque ya no debería ser accesible desde la web.

    ¿Cuándo necesitas ayuda profesional?

    Si después de revisar logs, desactivar plugins y buscar código malicioso el error persiste, o si no tienes experiencia con PHP y análisis de seguridad, es momento de contactar especialistas. En mi trabajo como auditor, encuentro malware que los propios usuarios no ven porque está:

    • Dentro de archivos wp-includes/ modificados (muy peligroso tocar)
    • Codificado en múltiples capas de base64 y obfuscación
    • Dentro de la base de datos (options, posts, postmeta) en lugar de archivos
    • En módulos o librerías de terceros que llamadas desde plugins legítimos

    Un análisis forense profesional incluye: extracción de IOCs (indicadores de compromiso), identificación de vector de entrada, limpieza completa, refuerzo de permisos, y monitoreo post-limpieza para confirmar que no reingresan.

    Resumen: cómo actuar ante el error de parseador

    1. Activa WP_DEBUG y revisa wp-content/debug.log buscando funciones maliciosas
    2. Lista plugins y temas, verifica que existan en WordPress.org oficial
    3. Busca archivos .php sospechosos en wp-content/, wp-includes/, raíz
    4. Desactiva plugins problemáticos uno a uno
    5. Si el error continúa o es crítico, restaura desde backup limpio anterior
    6. Implementa las medidas de hardening descritas
    7. Si no resuelves en 24 horas, solicita auditoría profesional

    El error de parseador no es solo un problema de código malo; es casi siempre un síntoma de que tu seguridad ha fallado. Tratarlo como un verdadero incidente de ciberseguridad, no como un simple error técnico, es lo que marca la diferencia entre un sitio limpio y uno que se reinecta en cuestión de semanas.

    Si sospechas que tu WordPress está comprometido o quieres un análisis profesional de seguridad, te invito a que contactes conmigo en ManuelFolgar.com. Ofrezco auditorías de ciberseguridad, limpiezas de malware y hardening para WordPress y PrestaShop, con informe detallado y seguimiento posterior.

  • Cómo limpiar errores causados por plugins maliciosos

    Cómo limpiar errores causados por plugins maliciosos

    Cómo limpiar errores causados por plugins maliciosos en WordPress

    Cuando analizo un sitio WordPress comprometido, los plugins maliciosos son casi siempre el culpable número uno. No es casualidad: representan el 40% de las vulnerabilidades que detecto en mis auditorías. El problema es que muchos propietarios no saben cómo identificar y limpiar los daños que dejan atrás. En esta guía te enseñaré exactamente qué buscar y cómo eliminar cada rastro de infección.

    ¿Qué daño causa realmente un plugin malicioso?

    Un plugin comprometido no solo se instala y se olvida. Durante los meses que permanece activo, puede dejar modificaciones profundas en tu base de datos, archivos principales y configuración. Lo que recomiendo siempre es entender primero la magnitud del problema antes de actuar:

    • Puertas traseras (backdoors): Código oculto que permite acceso no autorizado incluso después de desactivar el plugin
    • Inyecciones de base de datos: Publicaciones, usuarios o tablas completamente nuevas creadas para exfiltrar datos
    • Modificaciones en wp-config.php y .htaccess: Cambios que persisten aunque elimines el plugin
    • Archivos webshell: Scripts PHP independientes distribuidos por toda tu carpeta /uploads
    • Redirecciones invisibles: Código inyectado en funciones.php que redirige tráfico a sitios de spam o phishing
    • Minería de criptomonedas: Scripts que consumen recursos del servidor sin que lo notes

    Lo crítico es que simplemente desactivar o eliminar el plugin desde el panel de WordPress no limpia estos daños colaterales. Necesitas un enfoque sistemático.

    Paso 1: Identifica qué plugins están realmente comprometidos

    Mi primer paso siempre es hacer un inventario honesto. Accede al panel de WordPress y ve a Plugins. Abre Google Search Console y comprueba si Google ha marcado tu sitio con avisos de malware.

    Luego, haz una búsqueda rápida en NVD (National Vulnerability Database) con el nombre de cada plugin instalado. Busca también en el repositorio oficial de WordPress si el plugin sigue activo o ha sido marcado como inseguro.

    Herramientas que uso constantemente:

    • Wordfence CLI: wp wordfence threat-defense status te muestra amenazas detectadas
    • WP-CLI: wp plugin list lista todos con versión y estado
    • Sucuri SiteCheck: Análisis rápido en línea que detecta inyecciones obvias
    • VirusTotal: Sube la carpeta del plugin sospechoso y escanéala contra 70+ antivirus

    Paso 2: Limpia la base de datos de cambios maliciosos

    Aquí es donde la mayoría de personas comete errores. Cuando un plugin malicioso está activo durante meses, modifica tu base de datos. Necesitas buscar:

    Usuarios fantasma: Accede a phpMyAdmin o usa WP-CLI:

    wp user list --format=table

    Busca cuentas creadas recientemente que no reconozcas, especialmente con nombres genéricos como «admin2», «backup», «test» o «wordpress». Elimínalas con:

    wp user delete ID --reassign=1

    Publicaciones y páginas ocultas: A menudo los plugins inyectan contenido spam o puerta trasera en posts:

    wp post list --post_type=any --status=any --format=table

    Si encuentras posts con títulos raros o creados en fechas sospechosas, elimínalos.

    Opciones de base de datos comprometidas: Los plugins maliciosos a menudo guardan datos en la tabla wp_options. Usa phpMyAdmin para revisar:

    SELECT * FROM wp_options WHERE option_name LIKE '%s99%' OR option_name LIKE '%malware%' OR option_name LIKE '%shell%'

    Borra cualquier entrada sospechosa.

    Paso 3: Busca y elimina webshells y archivos maliciosos

    Este es el paso más tedioso pero esencial. Los plugins maliciosos típicamente dejan archivos PHP ocultos en:

    • /wp-content/uploads/ (es el lugar favorito porque es accesible directamente por URL)
    • /wp-content/plugins/ (incluso aunque desactives el plugin)
    • Raíz de WordPress o /wp-admin/
    • /wp-includes/ (muy peligroso si logran acceso)

    Conéctate por SFTP y busca archivos sospechosos. Signos de alerta:

    • Archivos .php en carpetas que deberían ser solo imágenes (/uploads)
    • Nombres ofuscados: d8h3jd.php, img_load.php, function.php (confunde con wp-content/themes/tu-tema/functions.php)
    • Fechas de modificación recientes en archivos que no tocaste
    • Archivos con pesos inusuales: 50KB+ cuando deberían pesar 2-5KB

    Usa la terminal SSH para buscar de forma más inteligente:

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

    Cualquier archivo .php en uploads es sospechoso 99% del tiempo. Elimínalo.

    También revisa archivos que hayan sido modificados recientemente:

    find /home/usuario/public_html -name "*.php" -mtime -30 -type f

    Esto te muestra todos los .php editados en los últimos 30 días. Revísalos uno a uno.

    Paso 4: Limpia modificaciones en archivos de configuración críticos

    Los plugins maliciosos sofisticados modifican archivos que WordPress respeta incluso después de su desinstalación:

    wp-config.php: Revísalo línea por línea. Busca:

    • Nuevas definiciones de constantes extrañas
    • Includes o requires de archivos desconocidos
    • Código ofuscado o base64

    Si lo encuentras, elimina esas líneas pero sé cuidadoso: no borres nada relacionado con tu base de datos o claves de seguridad legítimas.

    .htaccess: Abre el archivo .htaccess en la raíz. Los backdoors suelen añadir redirecciones o modificaciones del módulo rewrite:

    • Redirecciones a dominios desconocidos
    • Reglas que ocultan archivos .php específicos
    • RewriteCond que redirigen tráfico a phishing

    Lo más seguro es regenerar un .htaccess limpio: en WordPress, ve a Ajustes > Enlaces permanentes y guarda sin cambiar nada. Esto sobrescribe el archivo con valores seguros.

    themes/tu-tema/functions.php: Los plugins a veces inyectan código en el tema activo porque es código que se ejecuta en cada carga de página:

    wp theme get --field=stylesheet-path

    Abre ese archivo y busca líneas que:

    • Hayan sido añadidas hace poco (diferentes al resto del código)
    • Contengan eval(), base64_decode(), create_function()
    • Llamen a URLs externas desconocidas
    • Creen usuarios administrativos automáticamente

    Si no eres desarrollador, compara con una copia limpia de tu tema descargada directamente del repositorio oficial.

    Paso 5: Verifica el .htaccess y las reglas del servidor

    Además del archivo .htaccess que mencioné, algunos plugins maliciosos sofisticados modifican la configuración de Apache directamente o crean archivos .htaccess ocultos en subcarpetas:

    find /home/usuario/public_html -name ".htaccess" -type f

    Si encuentras múltiples .htaccess en diferentes carpetas (debería haber solo uno en raíz), inspecciónalos. Cualquier línea que no reconozcas, bórrala.

    Luego, reconstruye uno limpio con estas reglas básicas de seguridad que recomiendo siempre:

    # Proteger wp-config.php
<Files wp-config.php>
  Order allow,deny
  Deny from all
</Files>

# Bloquear acceso a wp-admin excepto para ti
<FilesMatch "wp-login.php">
  Order allow,deny
  Allow from XXX.XXX.XXX.XXX
  Deny from all
</FilesMatch>

# Prohibir ejecución de PHP en /uploads
<Directory /uploads>
  php_flag engine off
  AddType text/plain .php
</Directory>

    Paso 6: Cambia todas las contraseñas y regenera claves de seguridad

    Si un plugin malicioso estuvo meses activo, el atacante probablemente:

    • Creó cuentas de administrador secundarias (que ya eliminaste, pero verifica de nuevo)
    • Capturó cookies de sesión
    • Tuvo acceso a wp-config.php (donde están las claves de autenticación)

    Por eso, obligatorio:

    1. Cambia la contraseña de todos los usuarios, especialmente administradores: wp user update ID --prompt=user_pass
    2. Regenera las claves de seguridad en wp-config.php. Usa el generador oficial de WordPress y reemplaza las líneas AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY (y sus variantes _SALT)
    3. Regenera tokens de API si usas cualquier integración externa

    Esto expulsa a cualquier atacante que tenga sesiones activas o cookies viejas.

    Paso 7: Realiza un escaneo antimalware profesional

    Después de limpiar manualmente, ejecuta un escaneo automatizado para confirmar que no quedó nada:

    Wordfence Premium: Escaneo profundo de archivos, base de datos y comportamiento:

    wp wordfence scan execute --scan_type=all

    MalCare: Muy efectivo detectando webshells y código obfuscado que otros pierden.

    Sucuri Security (plugin gratuito): Más ligero pero confiable para sitios pequeños.

    No confíes en un solo scanner. Si usas dos herramientas diferentes y ambas dan clean, puedes dormir tranquilo.

    Paso 8: Audita eventos en logs y revisa Google Search Console

    Aquí es donde vemos si el atacante dejó más sorpresas:

    Access logs del servidor: Accede a logs/access_log (o similar según tu hosting) y busca requests sospechosos a archivos .php en uploads:

    grep "wp-content/uploads.*.php" /var/log/apache2/access.log

    Esto te muestra si alguien ejecutó webshells. Si ves requests POST grandes o desde IPs desconocidas a tus archivos, es confirmación de que estuvo comprometido.

    Google Search Console: Abre la consola, ve a Seguridad y acciones manuales. Si Google detectó malware, verás un informe detallado. Una vez que hayas limpiado, solicita un análisis de seguridad nuevamente:

    Seguridad y acciones manuales > Problemas de seguridad > Solicitar revisión

    Google típicamente responde en 24-72 horas.

    Paso 9: Instala protección para evitar que vuelva a ocurrir

    Limpiar una vez no es suficiente. Necesitas un escudo permanente. Lo que recomiendo siempre es:

    • Wordfence Firewall: Bloquea intentos de explotación de plugins vulnerables antes de que lleguen a tu servidor. Configura para bloquear bots de fuerza bruta en wp-login.php
    • Actualizaciones automáticas: define('WP_AUTO_UPDATE_CORE', true); en wp-config.php
    • 2FA en wp-admin: Wordfence o Google Authenticator. Si no pueden entrar al panel, no pueden instalar plugins maliciosos
    • Limpieza automática de plugins inactivos: Elimina cualquier plugin que no uses realmente. Cada uno que no tengas es una puerta cerrada
    • Auditorías de plugins regularmente: Una vez al mes, verifica que cada plugin tiene actualizaciones disponibles y que la última versión no tiene vulnerabilidades reportadas

    ¿Qué pasa si todo está muy comprometido?

    A veces encuentro sitios donde un plugin malicioso ha estado tan tiempo que el daño es profundo: múltiples webshells escondidos, inyecciones en 50+ publicaciones, claves de seguridad expuestas, etc.

    En estos casos, la limpieza manual es arriesgada. Podrías dejar algo atrás y tener un segundo ataque en una semana.

    Mi recomendación es siempre clara: si no estás 100% seguro, busca ayuda profesional. En ManuelFolgar.com realizamos análisis exhaustivos, limpieza completa y hardening posterior. Es mejor 300€ en seguridad ahora que 3000€ en pérdida de datos o reputación después.

    Resumen de acciones inmediatas

    1. Identifica plugins comprometidos con NVD, Sucuri SiteCheck y Wordfence
    2. Limpia usuarios, posts y opciones sospechosas de base de datos
    3. Busca y elimina webshells en /uploads y /plugins
    4. Revisa wp-config.php, .htaccess y functions.php del tema
    5. Cambia todas las contraseñas y regenera claves de seguridad
    6. Escanea con múltiples herramientas antimalware
    7. Revisa logs y solicita revisión a Google
    8. Instala Wordfence, activa 2FA y configura actualizaciones automáticas

    Si necesitas ayuda profesional en cada uno de estos pasos, o si quieres que un experto haga la auditoría completa mientras tú descansas tranquilo, contacta conmigo en ManuelFolgar.com. Ofrezco análisis sin compromiso y planes de limpieza adaptados a tu sitio.

  • Escaneo de malware WordPress: herramientas y procedimientos

    Escaneo de malware WordPress: herramientas y procedimientos

    Escaneo de malware WordPress: herramientas y procedimientos

    Cuando un cliente me contacta porque sospecha que su WordPress está comprometido, lo primero que hago es un escaneo profundo de malware. No es algo opcional: si tu sitio está infectado y no lo detectas a tiempo, los daños pueden ser devastadores. Pérdida de datos, robo de credenciales, indexación de spam en Google, caída del tráfico orgánico y pérdida de confianza de usuarios son solo algunas consecuencias.

    En mi experiencia, la mayoría de los ataques a WordPress provienen de plugins desactualizados, temas nulled o contraseñas débiles en el panel de administración. El malware se instala silenciosamente y puede estar semanas sin ser detectado. Por eso te voy a mostrar exactamente cómo scanear tu sitio, qué herramientas funcionan de verdad y qué hacer si encuentras algo.

    ¿Por qué un escaneo de malware es imprescindible?

    Antes de entrar en herramientas, quiero que entiendas por qué esto es crítico. Los atacantes no atacan WordPress al azar. Buscan activamente vulnerabilidades porque saben que hay cientos de miles de sitios WordPress sin parches de seguridad.

    Según el equipo de seguridad de WordPress.org, mantener tu instalación actualizada es la defensa más importante. Pero si ya estás comprometido, necesitas detectarlo rápido.

    Los tipos de malware que más veo en WordPress son:

    • Backdoors: archivos ocultos que permiten al atacante acceder sin credenciales reales
    • Webshells: scripts PHP que funcionan como puerta trasera remota
    • Redirectores: código que envía a visitantes a sitios maliciosos sin tu control
    • Cryptominers: scripts que usan CPU del servidor para minar criptomonedas
    • Skimmers de tarjetas: malware que captura datos de pagos (muy grave en tiendas online)
    • Inyección de spam SEO: contenido malicioso inyectado para posicionar sitios de terceros

    Herramientas principales para escanear malware en WordPress

    No todas las herramientas detectan lo mismo. Lo que recomiendo siempre es usar varias en combinación porque un malware sofisticado puede eludir un solo scanner.

    1. Wordfence (la mejor opción plugin)

    Wordfence es mi herramienta de referencia. Tiene una versión gratuita que escanea todo el servidor, compara archivos de WordPress contra las versiones originales, detecta malware en themes y plugins, e identifica vulnerabilidades conocidas.

    Cómo usarlo:

    1. Instala el plugin desde el repositorio oficial de WordPress
    2. Ve a Wordfence > Scan
    3. Haz clic en «Start scan»
    4. Espera a que termine (puede tardar 30-60 minutos según el tamaño del sitio)
    5. Revisa los resultados en la pestaña «Threat report»

    Lo que me gusta de Wordfence es que no solo busca malware, sino también archivos modificados. Si un plugin legítimo fue parchado con código malicioso, Wordfence lo detecta comparando el hash MD5 del archivo con el original en los servidores de WordPress.org.

    2. MalCare (escaneo en la nube)

    MalCare escanea tu sitio desde servidores en la nube, lo que evita sobrecargar tu propio servidor. Es especialmente útil si tu hosting es lento o tienes poco margen de recursos.

    Ventajas:

    • Detecta malware oculto en bases de datos
    • Identifica vulnerabilidades en plugins y temas
    • Tiene inteligencia artificial para detectar patrones de ataque nuevos
    • Versión gratuita funcional para sitios pequeños

    En un caso real, encontré un backdoor que Wordfence no había detectado porque estaba ofuscado en la base de datos. MalCare lo sacó a la luz en minutos.

    3. Sucuri SiteCheck (escaneo online gratuito)

    Sucuri SiteCheck es completamente gratuito y no requiere instalar nada. Solo necesitas acceder a su web, escribir tu URL y esperar. Es perfecto como primer chequeo rápido.

    Te muestra:

    • Malware detectado
    • Blacklist status (si Google o Sucuri lo han marcado como malicioso)
    • Problemas de seguridad general
    • Vulnerabilidades conocidas

    4. Google Search Console (control de Google)

    Google indexa malware constantemente. Si tu sitio tiene código malicioso, muy probablemente lo haya detectado. En Google Search Console, ve a «Seguridad y acciones manuales» para ver si Google ha marcado tu dominio.

    Si aparece «Malware detectado», tienes un problema real que requiere acción inmediata.

    5. Análisis manual con WP-CLI

    Para los que se sienten cómodos con línea de comandos, WP-CLI es brutal en eficiencia:

    Listar plugins activos con versiones:

    • wp plugin list

    Verificar integridad de archivos de WordPress core:

    • wp core verify-checksums

    Buscar archivos sospechosos modificados recientemente:

    • find /ruta/a/wordpress -type f -name «*.php» -mtime -7

    Este comando te muestra todos los archivos PHP modificados en los últimos 7 días. Si encontras algo fuera de wp-content/uploads o temas/plugins legítimos, es sospechoso.

    6. VirusTotal (análisis de archivos individuales)

    VirusTotal te permite subir archivos PHP sospechosos y escanearlos contra 90+ antivirus. Es especialmente útil cuando encuentras un archivo raro y no sabes si es legítimo.

    Procedimiento completo de escaneo

    Aquí está el protocolo que sigo yo cuando analizo un sitio potencialmente comprometido:

    Paso 1: Escaneo inicial rápido

    Primero, accedo a Sucuri SiteCheck con la URL del cliente. Tarda 2-3 minutos y te da un primer veredicto. Si sale «malware detectado» aquí, ya sabemos que es grave.

    Paso 2: Escaneo con Wordfence

    Instalo Wordfence si no lo tiene, y lanzo un escaneo completo. Mientras se ejecuta (30-60 minutos), paso al siguiente punto.

    Paso 3: Revisión de Google Search Console

    Compruebo si Google ha detectado malware. Si tiene alertas de «Sitio comprometido» o «Malware», la situación es más delicada.

    Paso 4: Análisis de plugins y temas

    Busco:

    • Plugins desactualizados: cualquier versión antigua que tenga CVE publicado
    • Temas nulled: si el cliente dice «compré el tema en una tienda rara», probablemente sea falsificado
    • Plugins de origen dudoso: algunos «security» plugins maliciosos simulan ser legítimos
    • Plugins inactivos años atrás: son vectores de ataque si nunca se actualizaron

    Paso 5: Revisión manual de archivos core

    Con WP-CLI, corro «wp core verify-checksums». Si sale algo modificado en wp-load.php, wp-settings.php o wp-config.php, el sitio fue parchado.

    Paso 6: Búsqueda de backdoors

    Busco en directorios comunes donde los atacantes dejan backdoors:

    • /wp-content/uploads/ (el lugar más común)
    • /wp-content/plugins/ (especialmente plugins desactivados)
    • Raíz del sitio (archivos .php solitarios)
    • /wp-admin/ (si tiene permisos, pueden añadir ahí)

    Un backdoor típico es un archivo como «update.php», «config.php» o algo con nombre genérico. Cuando lo encuentro, corro VirusTotal para confirmar.

    Paso 7: Análisis de base de datos

    Conecto vía phpMyAdmin y busco:

    • Posts editados con código malicioso: inyección de iframes o scripts
    • Usuarios extra: cuentas de administrador que el cliente no reconoce
    • Opciones modificadas: valores raros en wp_options que podrían ser persistencia

    Un truco: busco en la tabla wp_posts donde post_content contiene «iframe» o «<script" sin ser del cliente.

    Paso 8: Logs del servidor

    Reviso access.log y error.log de Apache/Nginx. Busco:

    • POST requests a wp-login.php desde IPs raras
    • Accesos a archivos que no existen (típico de intentos de RFI/LFI)
    • Mensajes de error SQL (indicio de inyección)

    Qué hacer si encuentras malware

    Si tu escaneo da positivo, aquí es donde muchos clientes panic. Pero hay un plan claro:

    1. Aislamiento inmediato

    No esperes: si está en una blacklist de Google, necesitas sacarlo rápido. Algunas opciones:

    • Desactiva todos los plugins (excepto Wordfence)
    • Cambia el tema a uno stock de WordPress
    • Desconecta usuarios no autorizados en wp-admin

    El objetivo es minimizar el daño mientras trabajas en la limpieza.

    2. Backup seguro (si lo tienes)

    Descarga un backup anterior a la infección si lo guardaste. Cuidado: si el backup es infectado también, no sirve. Por eso recomiendo backups automáticos diarios, no semanales.

    3. Limpieza manual vs. reinstalación

    Aquí tengo dos opciones:

    Limpieza manual: si el malware es superficial (un plugin infectado, unos cuantos archivos backdoor), puedo eliminarlo manualmente, restablecer permisos y cambiar todas las contraseñas.

    Reinstalación completa: si el malware está profundamente enraizado (modificaciones en core, múltiples backdoors, inyección en BD), reinstalo WordPress desde cero, subo contenido limpio del backup, y reconfiguro todo.

    En mi experiencia, la reinstalación es más segura y custa menos tiempo que una limpieza manual exhaustiva.

    4. Cambio de credenciales

    Cambio todo:

    • Contraseña de admin de WordPress
    • Credenciales FTP/SFTP
    • Contraseña de la base de datos
    • Credenciales de email de administrador
    • Keys y salts de WordPress (en wp-config.php)

    5. Reportar a Google

    En Google Search Console, ve a «Seguridad y acciones manuales» y solicita una revisión de seguridad. Explica que ya está limpio. Google tarda 1-7 días en revisar.

    Prevención: hardening después del ataque

    Una vez limpios, implemento medidas para que no vuelva a pasar:

    Cambio de prefijo de tablas

    La mayoría de ataques SQL apuntan a tablas con nombre «wp_». Lo cambio en wp-config.php y la BD:

    • $table_prefix = ‘mf_’;

    Deshabilitar edición de archivos

    Añado a wp-config.php:

    • define(‘DISALLOW_FILE_EDIT’, true);

    Así, aunque un atacante acceda al panel de admin, no puede editar archivos PHP directamente.

    Proteger wp-config.php

    En .htaccess:

    • <files wp-config.php> deny from all </files>

    Limitar intentos de login

    Uso Wordfence Firewall para bloquear tras 5 intentos fallidos en 5 minutos. Mata los ataques de fuerza bruta.

    Dos factores de autenticación (2FA)

    Instalo Two-Factor Authentication for WordPress. Aunque hackeen la contraseña, sin el móvil no entran.

    Auditoría de actividad

    Wordfence mantiene logs de quién accede y cuándo. Lo reviso regularmente en «Tools > Activity Log».

    Automatizar escaneos

    Configuro escaneos semanales automáticos en Wordfence. Si encuentra algo, me avisa por email.

    Errores comunes que veo

    Después de años analizando WordPress infectados, estos son los fallos más frecuentes:

    • No actualizar plugins: el 80% de los ataques explotan vulnerabilidades conocidas y parchadas
    • Usar temas nulled: descargar temas «gratis» de sitios de dudosa reputación es suicida
    • Contraseñas débiles: «123456» o «admin» como contraseña de panel invita ataques brute force
    • No tener backups: si no tienes backup limpio, no puedes recuperarte
    • Ignorar alertas de Google: cuando Google te avisa, tienes días para actuar, no semanas
    • Confiar en un solo scanner: usar solo Wordfence puede dejar malware sin detectar

    Resumen: tu checklist de escaneo

    Si sospechas malware, haz esto hoy:

    1. Accede a Sucuri SiteCheck y scanea tu URL
    2. Revisa Google Search Console para alertas de malware
    3. Instala Wordfence si no lo tienes y lanza escaneo completo
    4. Revisa plugins desactualizados y desactiva los dudosos
    5. Busca archivos PHP raros en wp-content/uploads/
    6. Si encuentras algo, contacta con un profesional

    No intentes limpiar malware sofisticado tú solo si no tienes experiencia. Un mal movimiento puede borrar contenido legítimo o dejar puertas traseras. Lo que recomiendo siempre es trabajar con especialistas en seguridad WordPress.

    Si tu sitio está comprometido o tienes dudas después de un escaneo, contacta conmigo en ManuelFolgar.com. Hago análisis profundos de seguridad y limpiezas garantizadas para WordPress. Tu sitio es tu negocio, y merece estar protegido.