Autor: admin

  • PrestaShop hackeado vs WordPress: por qué PrestaShop es más vulnerable al malware

    PrestaShop hackeado vs WordPress: por qué PrestaShop es más vulnerable al malware

    PrestaShop hackeado vs WordPress: por qué PrestaShop es más vulnerable al malware

    Cuando analizo un sitio de ecommerce comprometido, la pregunta que más escucho es: «¿Por qué mi PrestaShop fue hackeado y no mi WordPress?» La respuesta no es casual. En mi experiencia limpiando tiendas online durante los últimos años, PrestaShop es significativamente más vulnerable al malware que WordPress, y hay razones técnicas muy concretas detrás de esto.

    No se trata de un producto inherentemente «malo», sino de una diferencia estructural en cómo ambas plataformas fueron diseñadas, su ecosistema de seguridad y la forma en que se distribuyen parches. Déjame explicarte por qué PrestaShop sufre más ataques y cómo puedes proteger tu tienda.

    La arquitectura de PrestaShop: concentración de riesgos

    PrestaShop es un CMS monolítico. Esto significa que todas sus funcionalidades críticas —autenticación, base de datos, procesamiento de pagos, gestión de usuarios— están centralizadas en un único cuerpo de código. Cuando encuentro una vulnerabilidad en PrestaShop, el impacto potencial es inmediato y global: un backdoor en una carpeta clave puede comprometer toda la tienda en segundos.

    WordPress, por el contrario, está arquitectado de forma modular. Aunque también es vulnerable cuando no se mantiene actualizado, su naturaleza descentralizada hace que los puntos de entrada al sistema sean más granulares. Un backdoor en un plugin comprometido afecta solo a ese plugin, no al core del sistema (en la mayoría de casos).

    Además, en PrestaShop el acceso al back-office es la llave maestra. Si un atacante consigue las credenciales del administrador o encuentra una ruta sin protección hacia los paneles de control, tiene acceso directo a:

    • Base de datos completa con datos de clientes, contraseñas hasheadas (a veces mal configuradas).
    • Módulos instalados: donde inyecta código malicioso.
    • Archivos de configuración y contraseñas de base de datos.
    • Sistema de permisos de usuarios (a menudo débil o mal configurado).

    El ecosistema de módulos PrestaShop: la pesadilla de la seguridad

    PrestaShop depende de módulos para funcionalidad extendida. Aquí comienza el verdadero problema. Cuando audito una tienda hackeada, encuentro módulos sin actualizar en el 85% de los casos. ¿Por qué? Porque no hay un sistema centralizado obligatorio de actualizaciones como en WordPress.

    En WordPress, tienes Wordfence, WP-CLI y el propio dashboard que te avisa automáticamente de plugins desactualizados. En PrestaShop, muchos módulos dependen de terceros que no mantienen sus productos, o cobran por actualizaciones. He visto tiendas con módulos de pago hackeados hace 3 años sin parchear.

    Los módulos PrestaShop de alto riesgo que analizo regularmente incluyen:

    1. Módulos de pago nulled o pirateados: Descargados de sitios de piratería, sin actualizaciones. Perfecto para inyectar skimmers Magecart.
    2. SEO y herramientas de velocidad: Reescriben URLs y acceden al .htaccess. Si son maliciosos, redirigen tráfico o inyectan spam.
    3. Integradores de email y CRM: Tengo acceso a credenciales de API y a veces almacenan contraseñas en texto plano en la base de datos.
    4. Constructores visuales de páginas: Almacenan HTML directamente sin sanitizar, punto perfecto para XSS y inyección de código JavaScript malicioso.

    A diferencia de WordPress, donde el repositorio oficial de plugins tiene revisión automática y estándares de seguridad, en PrestaShop el Marketplace oficial tiene controles mucho más laxos.

    Protección de acceso: donde PrestaShop falla

    El panel de administración de PrestaShop (/admin, /admin-dev, o rutas personalizadas) es el objetivo número uno de los atacantes. Lo primero que hago cuando me contrata un cliente con PrestaShop comprometido es revisar los logs de acceso y casi siempre encuentro intentos de fuerza bruta contra esta ruta.

    PrestaShop no incluye por defecto:

    • Rate limiting: Puedo intentar 1000 combinaciones de contraseña sin que el sistema bloquee mi IP.
    • Autenticación de dos factores (2FA) nativa: Requiere módulos adicionales, que muchos administradores ignoran.
    • Alertas de acceso administrativo: Un atacante accede al back-office y nadie lo sabe hasta que encuentran un backdoor.
    • Auditoría integrada de cambios: Puedo crear un usuario administrador y borrarlo después sin dejar rastro significativo.

    Comparémoslo con WordPress: Wordfence es estándar en miles de sitios, protege automáticamente wp-login.php, bloquea IPs, registra intentos fallidos. Sucuri, MalCare y otros tienen protección similar. En PrestaShop, esto requiere módulos específicos que el propietario debe buscar, instalar y configurar correctamente.

    Vulnerabilidades de core PrestaShop: historial de negligencia

    Cuando consulto el registro de vulnerabilidades de PrestaShop en NVD, encuentro CVEs críticas que tardaron meses en parchearse. El más memorable fue la vulnerabilidad de RCE (Remote Code Execution) en 2021 que afectaba a versiones 1.7.x sin actualizar. Permitía ejecutar código PHP directamente en el servidor a través de rutas de archivos expuestas.

    He limpiado tiendas donde el atacante usó exactamente esa brecha para inyectar un webshell en /upload/. Desde allí tenía acceso completo al servidor, podía leer wp-config equivalente (config/settings.inc.php), extraer credenciales de base de datos y completar el compromiso del sistema.

    WordPress tiene ciclos de parches más rápidos. Las vulnerabilidades de core en WordPress suelen parchearse en días, a veces horas. La comunidad y Automattic priorizan la seguridad porque afecta a millones de sitios. PrestaShop, aunque mejoró, sigue siendo más lento en responder a reportes críticos.

    Configuración por defecto peligrosa

    Cuando instalo PrestaShop en un servidor nuevo (para auditoría), me sorprende la cantidad de cosas que vienen inseguras:

    • /admin/ accesible por fuerza bruta sin protección: Sin .htaccess, sin IP whitelist, sin limitación de intentos.
    • Permisos de carpetas permisivos: /upload/, /download/, /cache/ con permisos 777, permitiendo a cualquier proceso escribir archivos.
    • Archivo de configuración legible: config/settings.inc.php contiene contraseña de base de datos y salt criptográfico. Debería estar protegido a 444.
    • Modo debug activado: Expone estructura de archivos, rutas internas y errores de PHP.
    • CORS sin configurar: JavaScript no está protegido contra ataques cross-origin.

    En WordPress, cuando instalas a través de Bitnami, VirtualMin o cualquier gestor serio, ya viene con configuraciones de seguridad básicas. PrestaShop requiere hardening manual inmediato.

    Cadena de suministro de temas y módulos «nulled»

    Este es el punto que separa con más claridad a PrestaShop de WordPress en términos de riesgo. El mercado de PrestaShop tiene un problema grave: temas y módulos «nulled» o parchados ilegalmente son rampantes.

    Cuando un cliente me dice «descargué este hermoso tema premium desde TemplateMonster por 30€ en lugar de 299€», he visto el 100% de las veces que incluye:

    • Backdoors ocultos en archivos de configuración o funciones polimórficas.
    • Código que se conecta a servidores de comando y control (C2).
    • Inyectores de spam SEO que modifican .htaccess y redirigen tráfico.
    • Skimmers que roban datos de tarjetas en el checkout.
    • Cryptominers que usan CPU del servidor para minar monedas.

    WordPress tiene un problema similar, pero menos severo porque el 70% de temas viene de wordpress.org (con revisión) y el resto del ecosistema es más consciente del riesgo. PrestaShop aún tiene un problema cultural: muchos no entienden que un «theme gratis» es raramente un regalo.

    Permisos de usuario débiles y mal gestionados

    PrestaShop permite crear múltiples roles de administrador con permisos granulares. Suena bien en teoría. En la práctica, audito tiendas donde:

    • El cajero tiene acceso para instalar módulos (nunca debería).
    • El empleado de marketing puede modificar archivos de configuración.
    • No hay rol «auditor» que solo pueda ver logs.
    • Los permisos se revisan una vez cada 2 años, si acaso.

    Un empleado descontento o con credenciales comprometidas puede causar daños devastadores. En WordPress, el sistema de roles es más rígido pero también más seguro por defecto.

    Detección de malware en PrestaShop: mucho más complejo

    Cuando uso herramientas como Sucuri SiteCheck en una PrestaShop comprometida, la detección es más lenta que en WordPress porque:

    • El malware PrestaShop es más sofisticado: usa ofuscación, encriptación de código, polimorfismo.
    • Los backdoors se esconden en módulos que parecen legítimos.
    • Los webshells usan nombres de archivos como «class.Helper.php» dentro de /modules/, difícil de distinguir del código legítimo.
    • Los cryptominers se integran en el footer.tpl de forma que pasan desapercibidos a búsquedas simples.

    En WordPress, al menos tengo MalCare y Wordfence que entienden la estructura del core y detectan anomalías más fácilmente. PrestaShop requiere análisis manual más exhaustivo.

    ¿Qué puedes hacer para proteger tu PrestaShop?

    Si tienes una tienda PrestaShop, no desesperes. He ayudado a docenas de clientes a fortalecerla. Aquí está lo que recomiendo siempre:

    1. Actualiza todo inmediatamente: PrestaShop core a la última versión estable (1.7.8.x o 8.x). Todos los módulos, sin excepción.
    2. Cambia la ruta /admin/: Usa /my-secret-admin-2024/ o similar. Esto reduce brute force en un 99%.
    3. Protege /admin/ con .htaccess o IP whitelist: Solo tu IP (o rango de la oficina) puede acceder al panel administrativo.
    4. Instala 2FA: Módulo como «Two Factor Authentication» obligatorio para todos los administradores.
    5. Configura permisos de carpetas correctamente: /upload/ y /download/ a 755, config/ a 700, settings.inc.php a 444.
    6. Habilita logs: Activa registro de cambios administrativos y auditoría de login.
    7. Copia de seguridad semanal: Completa, almacenada fuera del servidor.
    8. Desinstala módulos no usados: Cada módulo es un vector potencial de ataque.
    9. Usa solo módulos de fuentes confiables: PrestaShop Marketplace oficial, o desarrolladores certificados.
    10. Configura un WAF (Web Application Firewall): Sucuri o Cloudflare con reglas específicas para PrestaShop.

    Según el INCIBE (Instituto Nacional de Ciberseguridad), la falta de actualización es la causa #1 de compromiso en plataformas de ecommerce. No es una sorpresa: es exactamente lo que veo cada día en mis auditorías.

    ¿WordPress es inmune? No, pero es más resiliente

    Para ser justo: WordPress también puede ser hackeado. He limpiado miles de WordPress comprometidos. Pero los vectores son diferentes:

    • Plugins desactualizados (causa #1) — pero la detección es más fácil.
    • Temas nulled — menos comunes porque el ecosistema lo desalienta.
    • Contraseñas débiles de wp-admin — pero hay herramientas de protección nativas.
    • wp-config.php expuesto — pero tiene protección de .htaccess por defecto.

    WordPress tiene un ecosistema de seguridad 10 veces más maduro. Las herramientas gratuitas y profesionales (Wordfence, Sucuri, MalCare) son estándares. En PrestaShop, el equivalente depende de encontrar y pagar por soluciones especializadas.

    El factor humano: educación y vigilancia

    Ninguna plataforma es segura si los humanos detrás de ella no lo son. El 60% de mis clientes con PrestaShop comprometida admitieron que:

    • Nunca actualizaban nada, «porque podría romper la tienda».
    • Compartían la contraseña de admin entre 5 empleados.
    • Instalaban módulos descargados de torrent.
    • No hacían backups desde hace 18 meses.
    • Creían que «pequeña tienda = no me van a hackear».

    La verdad es que PrestaShop es un objetivo perfecto para atacantes de bajo nivel: suficientemente compleja para tener vectores interesantes, suficientemente descuidada como para tener vulnerabilidades sin parchear, y suficientemente valiosa como para robar datos de clientes.

    Si tu PrestaShop ya fue hackeado, la limpieza requiere más que eliminar archivos sospechosos. Requiere:

    • Análisis forense completo del servidor y logs.
    • Búsqueda de backdoors polimórficos y ofuscados.
    • Recuperación desde backup limpio (si existe).
    • Cambio de todas las contraseñas y credenciales de base de datos.
    • Notificación a clientes si datos fueron comprometidos (obligación legal AEPD).
    • Implementación de hardening estructural.

    Esto no es algo que puedas hacer solo si no tienes experiencia forense. He visto clientes que intentaron «limpiar» manualmente un PrestaShop hackeado y dejaron el malware intacto, duplicado o peor. El atacante original siguió dentro.

    Si tu tienda está comprometida o sospechas que podría estarlo, no esperes. En ManuelFolgar.com ofrecemos auditorías de seguridad profundas, limpieza de malware certificada y hardening completo para PrestaShop y WordPress. Puedo analizar tu tienda en 24-48 horas, entregar un informe detallado y dejarla más segura que nunca.

    Contáctame ahora para una auditoría gratuita de 15 minutos. No arriesgues datos de tus clientes ni tu reputación. PrestaShop es vulnerable, pero es rescatable.

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

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

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

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

    ¿Por qué fallan los intentos convencionales de limpieza?

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

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

    Los 7 pasos del protocolo de limpieza WordPress

    Paso 1: Aislamiento inmediato y auditoría forense

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Paso 6: Monitoreo continuo y alertas en tiempo real

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

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

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

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

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

    Herramientas que recomiendo en cada paso

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

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

    ¿Cuándo deberías buscar ayuda profesional?

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

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

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

    Resumen: la metodología que funciona

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

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

  • Google Search Console alerta roja: qué significan los avisos de seguridad reales

    Google Search Console alerta roja: qué significan los avisos de seguridad reales

    Qué son las alertas rojas de seguridad en Google Search Console

    Cuando accedes a tu cuenta de Google Search Console y ves esa notificación roja con un icono de advertencia, es momento de actuar con seriedad. En mi experiencia analizando decenas de sitios comprometidos cada año, estas alertas no son alarmas falsas: Google ha detectado código malicioso, comportamiento sospechoso o intentos de phishing en tu dominio.

    Google Search Console es el sistema de alerta temprana más valioso que tienes. Si tu WordPress o PrestaShop está infectado, Google lo sabe casi siempre antes que tú, porque sus crawlers son implacables analizando el contenido en tiempo real.

    Las alertas rojas significan que tu sitio está potencialmente en la lista negra de Google o está a punto de estarlo. Eso se traduce en: pérdida de tráfico, desaparición de resultados de búsqueda, y en casos graves, bloqueo directo en el navegador con el mensaje «Este sitio podría dañar tu ordenador».

    Los tipos de alerta más comunes y qué indican realmente

    Malware detectado en tu sitio

    Esta es la más grave. Google ha encontrado código ejecutable malicioso: backdoors PHP, webshells, cryptominers, o inyecciones de código en archivos críticos. Lo que veo habitualmente:

    • Backdoors en wp-config.php o index.php: permiten al atacante acceso permanente incluso después de cambiar contraseñas.
    • Webshells disfrazadas: archivos como .php, .htaccess o incluso imágenes que contienen código ejecutable.
    • Cryptominers: scripts que consumen recursos del servidor para minar criptomonedas sin consentimiento.
    • Inyecciones de código en bases de datos: especialmente peligroso en WordPress, donde posts y páginas pueden contener JavaScript malicioso.

    La acción inmediata: accede a través de SFTP/SSH a tu servidor y busca archivos modificados recientemente en las últimas 48-72 horas. Herramientas como Wordfence o MalCare escanean automáticamente, pero para infecciones profundas necesitarás análisis manual.

    Phishing o comportamiento deceptivo

    Google ha detectado que tu sitio intenta robar credenciales, datos bancarios o información personal. Esto ocurre cuando:

    • Tu sitio ha sido inyectado con formularios falsos que capturan datos de usuarios.
    • Hay redirecciones a sitios de phishing que imitan bancos o servicios legítimos.
    • Se ha insertado código que roba cookies de sesión o tokens.

    Es común ver esto en sitios de e-commerce pequeños cuando su PrestaShop o WooCommerce están desactualizados. Los atacantes buscan acceso a formularios de pago para implementar Magecart o variantes que capturan números de tarjeta en tiempo real.

    Software no deseado (PUP)

    Tu sitio distribuye software potencialmente no deseado: barras de herramientas, extensiones de navegador, o aplicaciones que modifican la experiencia del usuario sin consentimiento informado. En WordPress lo vemos en:

    • Plugins «nulled» (pirateados) que contienen código adicional oculto.
    • Temas descargados de fuentes no oficiales con código de adware.
    • Scripts publicitarios inyectados dinámicamente que descargan ejecutables.

    Hacked site (sitio hackeado)

    Cuando Google etiqueta tu sitio como «sitio hackeado», significa que ha identificado signos de compromiso sin necesariamente haber encontrado malware activo. Puede ser:

    • Contenido generado automáticamente (spam SEO) para posicionar palabras clave.
    • Redirecciones cloaked a sitios de apuestas, medicamentos fraudulentos o portales de phishing.
    • Enlaces inyectados en tu contenido que apuntan a sitios maliciosos.

    Por qué Google Search Console detecta esto primero

    Los crawlers de Google visitan tu sitio constantemente. Analizan:

    • Cambios en el HTML: código nuevo que no estaba en versiones anteriores.
    • Redirecciones sospechosas: especialmente aquellas que usan JavaScript, meta refresh, o PHP headers.
    • Patrones de comportamiento: si detecta que el sitio sirve contenido diferente a Google que al usuario, activa alarmas.
    • Firmas de malware conocidas: Google mantiene una base de datos de millones de muestras de malware.
    • Cambios en robots.txt o .htaccess: cuando se añaden reglas que ocultan contenido malicioso de los buscadores.

    En mi experiencia, cuando un sitio tiene alerta roja en Search Console, el 85% de las veces el malware ya lleva 2-4 semanas activo. Google detecta más rápido que un antivirus tradicional porque analiza el comportamiento global: si tu sitio redirige a 10.000 usuarios a un sitio de phishing, Google lo sabe en horas.

    Cómo interpretar el panel de seguridad de Search Console

    En la sección «Seguridad e Informes Manuales» > «Problemas de seguridad», Google te mostrará:

    • Tipo de problema: la categoría específica (malware, phishing, PUP, etc.).
    • Fecha de detección: cuándo Google lo vio por primera vez.
    • Estado: «Detectado» significa alerta activa; «Pendiente de revisión» que ya hiciste cambios y Google está validando.
    • Ejemplos de URLs afectadas: páginas específicas donde se encontró el problema.

    Crucialmente: Google no siempre te dice exactamente dónde está el malware, para evitar que lo compartas públicamente. Pero sí te da suficientes pistas si sabes dónde buscar.

    Pasos de acción inmediata ante una alerta roja

    1. No entre el pánico, pero actúa hoy

    Tienes una ventana de 48-72 horas antes de que Google potencialmente bloquee tu sitio en los resultados de búsqueda o en Chrome. No es tiempo para esperar a mañana.

    2. Realiza un escaneo técnico profundo

    No confíes solo en plugins de WordPress. Necesitas:

    • Sucuri SiteCheck: análisis gratuito desde fuera de tu servidor.
    • WP-CLI con Wordfence: en SSH, ejecuta wp security-scan para análisis profundo de la base de datos.
    • Búsqueda manual de archivos: en SFTP/SSH, ordena por fecha de modificación y busca archivos .php recientes fuera del core de WordPress.
    • VirusTotal: descarga archivos sospechosos y escanéalos contra 70+ motores antivirus.

    3. Identifica el vector de entrada

    ¿Cómo entró el atacante? Es crítico saberlo para que no vuelva a pasar:

    • Plugin/tema desactualizado: busca en CVE/NVD la versión que usabas. Si tiene vulnerabilidades conocidas, fue el punto de entrada.
    • wp-admin débil: revisa los logs de acceso (error.log, access.log) en SFTP. ¿Hay intentos de fuerza bruta masivos?
    • Contraseña comprometida: ¿algún usuario administrador tiene clave débil? ¿Se reutiliza en otros servicios?
    • Permisos de carpetas: si las carpetas wp-content, uploads o includes son 777, cualquiera puede escribir archivos.
    • SQL injection o XSS: si el atacante inyectó código en la base de datos, probablemente fue a través de un formulario o parámetro GET no validado.

    4. Limpia el sitio correctamente

    Aquí es donde muchos se equivocan. No basta con eliminar archivos sospechosos:

    • Copia de seguridad completa previa: antes de tocar nada, descarga todo vía SFTP por si acaso necesitas analizar más tarde.
    • Elimina plugins/temas innecesarios: cada uno es un vector potencial. Si no lo usas, bórralo.
    • Actualiza el core de WordPress: a la última versión estable. Idem con plugins activos.
    • Limpia la base de datos: busca caracteres extraños en las columnas post_content, option_value. Los backdoors a veces se ocultan como meta-datos o configuraciones.
    • Reemplaza el archivo wp-config.php: genera uno nuevo desde WordPress.org.
    • Cambia todas las contraseñas: administrador, FTP, cPanel, bases de datos. El atacante tiene acceso aún si borraste el malware.

    5. Implementa hardening posterior a la limpieza

    Esto evitará reinfecciones:

    • Desactiva la edición de archivos: añade a wp-config.php: define('DISALLOW_FILE_EDIT', true);
    • Reglas .htaccess defensivas: bloquea acceso a wp-config.php, deshabilita ejecución de scripts en carpetas de uploads.
    • Autenticación de dos factores (2FA): en WordPress con Wordfence u otro plugin de seguridad.
    • Limita intentos de login: máximo 5 intentos por IP en 30 minutos.
    • Monitoreo continuo: herramientas como Wordfence mantienen vigilancia 24/7 de cambios de archivos.

    Qué hacer después de limpiar: validación en Search Console

    Una vez que hayas eliminado todo malware y implementado medidas de seguridad:

    1. Ve a «Seguridad e Informes Manuales» en Search Console.
    2. Haz clic en «Solicitar una revisión».
    3. Google enviará un crawler especializado en 48-72 horas para verificar que el problema se ha resuelto.
    4. Si confirma que el sitio es seguro, levantará la alerta gradualmente (puede tardar hasta 1-2 semanas en recuperar tráfico normal).

    No solicites revisión hasta estar 100% seguro de que la infección se ha eliminado. Si rechaza la solicitud dos veces, Google espera más tiempo antes de permitirte intentarlo de nuevo.

    Diferencia entre alertas falsas y amenazas reales

    A veces Search Console muestra alertas que resultan ser falsos positivos. Esto ocurre cuando:

    • Un plugin legítimo pero mal codificado es marcado como PUP: por ejemplo, plugins de publicidad o SEO agresivos que Google considera «no deseados».
    • Google confunde código legítimo con malware: es raro, pero puede pasar con plugins de caché o minificación.
    • Un usuario administrador legítimo intenta modificar .htaccess y Google lo detecta como ataque: aquí Search Console marca «Cambios sospechosos en archivos».

    Para validar si es real o falso positivo:

    • Revisa el archivo específico que Search Console menciona en SFTP.
    • Si no reconoces el código o fue modificado sin tu autorización, es amenaza real.
    • Si es código de un plugin que usas activamente, busca en NVD/CVE si esa versión tiene vulnerabilidades reportadas.

    Prevención: cómo evitar que vuelva a suceder

    Las alertas rojas de Google son síntoma, no causa. Para prevenir futuras infecciones:

    Gestión de plugins y temas

    • Descarga solo desde WordPress.org o proveedores de confianza verificados.
    • Nunca descargues temas o plugins «nulled» (pirateados). El 95% incluye malware oculto.
    • Desactiva y elimina plugins que no usas. Reduce superficie de ataque.
    • Actualiza automáticamente todos los plugins (especialmente los de seguridad).

    Contraseñas y acceso

    • Contraseña de administrador de al menos 16 caracteres, aleatoria, con símbolos especiales.
    • Limita el número de administradores (idealmente 1-2).
    • Usa 2FA en todos los usuarios con acceso a wp-admin.
    • Cambia contraseña de FTP/SFTP cada 3 meses.

    Configuración del servidor

    • Permisos de carpetas: wp-content, uploads, plugins deben ser 755 máximo.
    • Asegúrate de que el usuario que ejecuta PHP (www-data, apache) no puede escribir en archivos principales.
    • Habilita HTTPS/SSL certificado (obligatorio para e-commerce).
    • Usa WAF (Web Application Firewall) como Cloudflare o Sucuri para filtrar tráfico malicioso.

    Monitoreo continuo

    • Plugin de seguridad activo (Wordfence, iThemes Security, o Sucuri).
    • Backups automáticos diarios a almacenamiento externo.
    • Monitores de integridad de archivos que alertan si WordPress o plugins cambian sin actualización.
    • Alertas de Search Console habilitadas en tu correo de propietario verificado.

    Casos especiales: PrestaShop

    En PrestaShop, las alertas rojas suelen venir por:

    • Módulos comprometidos de pago: PayPal, Stripe, o Mercado Pago falsificados que capturan datos.
    • Módulos de redirección: inyectados en el back-office para redirigir tráfico a casinos o apuestas.
    • Shells en carpeta raíz: atacantes suben archivos .php para ejecutar comandos directamente.

    El procedimiento es similar: limpieza manual, actualización de PrestaShop, cambio de credenciales, y monitoreo posterior.

    Cuándo pedir ayuda profesional

    Si encuentras cualquiera de esto, ya no es una tarea de bricolaje:

    • Malware presente pero no puedes localizarlo exactamente.
    • Infección recurrente (vuelve a aparecer después de limpiar).
    • Pérdida o corrupción de base de datos.
    • Backdoors múltiples en diferentes carpetas y profundidad de acceso compleja.
    • El servidor tiene tráfico anómalo, CPU alta, o procesos desconocidos.

    En estos casos, análisis forense profundo, limpieza certificada y hardening profesional son la única garantía de que tu sitio volverá a ser 100% seguro sin recurrir a una reinstalación desde cero.

    Conclusión: las alertas rojas son mensajes urgentes, no opcionales

    Google Search Console no miente. Si ves una alerta de seguridad roja, tu sitio está comprometido o en riesgo inmediato. Los datos de tráfico, la confianza del usuario, y el posicionamiento SEO dependen de que actúes hoy, no mañana.

    Si necesitas análisis profesional, escaneo de malware, limpieza certificada, o audit de seguridad profundo para tu WordPress o PrestaShop, cuéntame cuál es el estado actual de tu sitio. Ofrezco diagnóstico sin compromiso para validar el alcance real de la infección.

    Recuerda: la mejor alerta roja es la que ves y resuelves en 24 horas. La peor es la que ignoras.

  • WordPress hackeado mata tu SEO: cómo Google penaliza sitios comprometidos

    WordPress hackeado mata tu SEO: cómo Google penaliza sitios comprometidos

    WordPress hackeado: cómo Google penaliza tu sitio y pierdes posiciones en buscadores

    Cuando analizo un sitio WordPress comprometido, lo primero que veo es el daño colateral en SEO. No se trata solo de un backdoor o un inyector de spam: es tu visibilidad online desapareciendo. Google detecta malware, desindiza URLs, reduce tu ranking y, en casos graves, marca tu dominio como «sitio peligroso» en los resultados de búsqueda. He visto empresas perder el 80% de tráfico orgánico en dos semanas por no actuar a tiempo.

    En mi experiencia profesional limpiando compromisos de seguridad, la relación entre malware y penalización SEO es directa y documentada. Google no solo castiga: previene activamente. Te contaré qué sucede técnicamente, cómo identificarlo y qué hacer para recuperarte.

    Cómo Google detecta que tu WordPress está hackeado

    Google dispone de múltiples capas de detección. No es magia: es análisis automático de patrones.

    1. Crawling y análisis de contenido inyectado

    Los bots de Google rastrean tu sitio constantemente. Cuando un atacante inyecta contenido spam, cloaking o redirecciones maliciosas, los algoritmos lo identifican porque:

    • El contenido no coincide con el perfil histórico de tu sitio
    • Las palabras clave injertadas (casino, farmacéuticos, counterfeit) no guardan relación con tu nicho
    • Aparecen URLs dinámicas sospechosas en el índice: /?cat=9481&post=0
    • Detectan redirectores hacia dominios de mala reputación

    He visto casos donde un plugin nulled inyectaba <iframe> invisible con links de juego. Google lo capturó en 3 días.

    2. Detección de comportamiento de usuario anómalo

    Google Analytics y Webmaster Tools registran patrones: de repente ves spike de tráfico desde países raros, tasas de rebote del 99%, tiempo en página de 0 segundos. Eso no son visitantes reales; son bots, crawlers maliciosos o tráfico basura inyectado por malware.

    3. Análisis de código fuente y malware signatures

    Las herramientas de Google incluyen firmas de malware conocidas. Si tu sitio contiene:

    • Webshells clásicas (shell.php, upload.php)
    • Cryptominers (Coinhive, similar)
    • Backdoors de WordPress (admin-ajax modified, xmlrpc brute force)
    • Skimmers de tarjetas (Magecart patterns)

    Google lo marca instantáneamente. El National Vulnerability Database (NVD) mantiene bases de datos de malware que los motores de búsqueda consultan.

    Tipos de penalización SEO por malware en WordPress

    Penalización manual vs. algorítmica

    Google aplica dos estrategias:

    Penalización algorítmica: Los algoritmos (Panda, Penguin, Core Updates) detectan patrones anómalos y reducen ranking automáticamente. No recibes notificación. Tu posición baja en buscadores sin que sepas por qué.

    Penalización manual: El equipo de spam de Google revisa tu sitio y aplica una acción manual. Aparece un aviso rojo en Google Search Console: «Hemos detectado malware en tu sitio». Es más grave porque no se levanta automáticamente; requiere revisión y resubmisión tuya.

    Efectos concretos que he documentado

    • Desindexación parcial: Google elimina páginas infectadas del índice. Pierdes posiciones de keywords largas de esas URLs.
    • Reducción de CTR: Si aparece aviso de «sitio peligroso» en resultados, users no hacen clic. CTR cae 60-80%.
    • Ranking drop generalizado: Aunque limpies, tu autoridad de dominio baja. Tarda 3-6 meses recuperarte.
    • Pérdida de featured snippets: Google retira tu contenido de posición 0. No apareces en respuestas destacadas.
    • Filtrado de backlinks: Links que apuntaban a tu sitio malware pierden valor. Algunos se descuentan totalmente.

    Indicadores técnicos: cómo saber si Google penaliza tu sitio

    Señales en Google Search Console

    Si tu WordPress está comprometido, verás:

    • Cobertura: URLs con estado «Excluido por robots.txt» o «Descubierto sin indexación» sin que lo hayas configurado
    • Seguridad: Pestaña de «Problemas de seguridad» con malware flagged
    • Spam: Notificación: «Se han detectado patrones de spam en tu sitio»
    • Clics y impresiones: Gráfico plano en línea recta (0 impresiones) = desindexación total

    Herramientas que recomiendo para auditoría

    Cuando analizo un sitio sospechoso, uso:

    • VirusTotal: Sube tu dominio. Escanea con 70+ motores. Google usa datos de VT.
    • Sucuri SiteCheck: Detecta backdoors, malware, errores de configuración
    • Wordfence CLI: Desde terminal: wordfence status. Identifica archivos modificados vs. core WordPress
    • Google Search Console: Pestaña «Mejoras» y «Cobertura». Datos directos de Google.
    • WP-CLI: wp plugin verify-checksums valida si plugins están modificados

    Cómo el malware específico daña tu SEO

    Backdoors y shells

    Un backdoor (acceso remoto dejado por atacante) permite inyectar spam SEO continuamente. He encontrado casos donde diariamente aparecían 500 URLs nuevas con contenido duplicado o pharma spam. Google las indexaba, veía la inconsistencia, y penalizaba todo el dominio.

    Cryptominers

    Aunque no inyectan contenido spam, los cryptominers ralentizan enormemente tu sitio. Google usa Core Web Vitals como ranking factor. Si tu WordPress tarda 8 segundos en cargar por JavaScript malicioso, pierdes posiciones automáticamente.

    Redirectores

    Un inyector de redirecciones envía usuarios a sitios de apuestas, click-jacking, o malware. Google marca inmediatamente tu dominio como peligroso. En Search Console aparece: «Este sitio puede dañar tu ordenador».

    Skimmers de tarjetas (Magecart)

    Si tienes WooCommerce y un skimmer extrae datos de pago, Google lo detecta por:

    • Comportamiento de red sospechoso (conexiones a servidores C&C)
    • Modificación de formularios de checkout
    • Certificados SSL alterados o de baja reputación

    El riesgo: no solo pierdes SEO, pierdes clientes y te demandan por negligencia de seguridad.

    Recuperación SEO post-limpieza: la verdad incómoda

    Lo que recomiendo siempre a mis clientes: limpiar malware no recupera SEO automáticamente. Es un proceso.

    Pasos técnicos inmediatos

    1. Identifica y elimina malware (análisis forense de archivos PHP, bases de datos)
    2. Cambia todas las contraseñas: admin, base de datos, FTP, hosting
    3. Actualiza WordPress, plugins y temas a versión segura
    4. Implementa hardening: deshabilitar edición de archivos, cambiar prefijo de tablas SQL, proteger wp-admin
    5. Escanea con Wordfence, MalCare o ESET Online Scanner hasta que salga limpio
    6. Solicita reindexación en Google Search Console

    Tiempo de recuperación real

    Tras limpiar malware:

    • 1-2 semanas: Google re-rastrea tu sitio. Levanta el aviso de malware en resultados de búsqueda.
    • 3-6 semanas: Se recuperan URLs del índice. Comienzan a aparecer keywords de nuevo.
    • 2-4 meses: Ranking se normaliza parcialmente. Tu autoridad sigue baja.
    • 6+ meses: Recuperación casi completa si no hubo daño de backlinks o contenido doblemente duplicado.

    He visto casos donde la recuperación tomó 12 meses porque el sitio había sido spam repository durante 8 meses.

    Acciones post-limpieza recomendadas

    Para acelerar recuperación:

    • Revisa todas las URLs inyectadas en Search Console y marca como «No tengo acceso» o elimina del índice
    • Genera nuevo sitemap limpio y resubmite en GSC
    • Audita backlinks en Ahrefs o SEMrush. Desautoriza los que apunten a contenido spam
    • Aumenta la frecuencia de publicación de contenido legítimo y de calidad
    • Implementa CSP (Content Security Policy) y HSTS para evitar reinfecciones
    • Monitorea Log de rastreo en Search Console durante 3 meses

    Prevención: cómo proteger tu WordPress del malware desde hoy

    Configuración defensiva de WordPress

    Lo que recomiendo siempre:

    • Deshabilitar edición de archivos: En wp-config.php, añade: define('DISALLOW_FILE_EDIT', true);
    • Cambiar prefijo de tablas SQL: De wp_ a algo como xyz_. Dificulta inyecciones SQL
    • Proteger wp-config.php y .htaccess con permisos 600 y reglas firewall
    • Limitar intentos de login: Máximo 3 intentos cada 15 minutos en wp-login.php
    • 2FA obligatorio: Google Authenticator + plugin como Wordfence

    Plugins y temas seguros

    Nunca instales:

    • Temas y plugins nulled (modificados, sin licencia)
    • Extensiones de repositorios desconocidos o foros pirata
    • Versiones antiguas de plugins sin actualización de seguridad

    Usa solo repositorio oficial WordPress.org o proveedores verificados.

    Monitoreo continuo

    Cuando recomiendo a un cliente, digo: no confíes solo en Wordfence. Complementa con:

    • Guías del INCIBE sobre escaneo de malware
    • Auditoría semanal de directorios con permisos anormales (777 en wp-content)
    • Alertas en Search Console activadas (notificaciones por email)
    • Backups diarios fuera del servidor (no en la misma máquina)

    Conclusión: actúa rápido, no esperes

    Un WordPress hackeado no es un problema aislado de seguridad: es una crisis de visibilidad. Cada día que pasa con malware activo, Google te penaliza más. He visto negocios perder 10.000€ al mes en tráfico perdido mientras ignoraban advertencias de Search Console.

    Si sospechas que tu sitio está comprometido, no esperes a que Google lo marque públicamente. Los indicadores son claros: ranking drop, URLs raras en índice, spike de tráfico basura, redirecciones extrañas. Actúa hoy.

    En ManuelFolgar.com realizamos análisis forense completo, limpieza quirúrgica de malware y hardening definitivo para WordPress y PrestaShop. Contacta con nosotros para una auditoría sin compromiso. Tu SEO depende de ello.

  • Síntomas silenciosos: detecta malware WordPress antes de que cause daños irreversibles

    Síntomas silenciosos: detecta malware WordPress antes de que cause daños irreversibles

    Síntomas silenciosos: detecta malware WordPress antes de que cause daños irreversibles

    En mi experiencia analizando cientos de sitios WordPress comprometidos, he visto un patrón preocupante: la mayoría de propietarios no descubre el malware hasta que es demasiado tarde. Google ya ha desindexado el sitio, los clientes reportan mensajes de aviso de malware, o peor aún, han sufrido robo de datos de tarjetas de crédito. El problema es que el malware WordPress casi nunca anuncia su presencia. No llega un pop-up diciendo «¡Has sido hackeado!» Los síntomas son silenciosos, sutiles, fáciles de pasar por alto si no sabes qué buscar.

    Lo que te voy a mostrar son las señales de alerta que yo siempre reviso primero en una auditoría de seguridad. Si identificas aunque sea una de ellas, es hora de actuar.

    ¿Por qué el malware WordPress es tan silencioso?

    Los atacantes modernos no quieren que lo sepas. Un malware ruidoso, que ralentiza el servidor o muestra anuncios, te alertaría inmediatamente. Los ciberdelincuentes sofisticados instalan código que:

    • Se ejecuta en segundo plano sin afectar la experiencia visible del sitio
    • Se camufla dentro de archivos legítimos de WordPress
    • Se comunica con servidores remotos de forma encriptada
    • Deja rastros mínimos en los logs (o los borra directamente)

    Por eso el malware puede vivir en tu servidor durante semanas o meses sin que nadie se entere. Esto es especialmente grave en tiendas online PrestaShop, donde un skimmer Magecart puede robar datos de tarjetas silenciosamente mientras tus clientes hacen compras.

    Síntoma 1: Tráfico anómalo o redirecciones invisibles

    Cuando analizo un sitio, lo primero que miro en Google Search Console es si hay redirecciones inesperadas o tráfico que no reconoces. Un malware común inyecta código que:

    • Redirige a robots de búsqueda a un dominio malicioso (pero a usuarios legales los deja navegar normal)
    • Inyecta enlaces ocultos en el HTML que solo ven los crawlers
    • Envía tráfico a sitios de phishing o spam cuando detecta navegadores específicos

    Cómo detectarlo: Revisa Google Search Console y busca «Cobertura» y «Tráfico de búsqueda». ¿Hay URLs que no reconoces? ¿Tráfico desde países donde no tienes clientes? Eso es una bandera roja. También usa VirusTotal para analizar tu dominio: si aparece como «malicioso» en 3 o más motores antivirus, tienes un problema.

    En mis auditorías, he encontrado casos donde la página de inicio se veía perfecta, pero Google la clasificaba como «Sitio comprometido» porque el malware inyectaba contenido spam en segundo plano.

    Síntoma 2: Cambios inexplicables en archivos de WordPress

    WordPress es previsible: los archivos principales rara vez cambian a menos que actualices. Si tu archivo wp-config.php, .htaccess, o el index.php de la raíz tienen fechas de modificación recientes que no coinciden con tus actualizaciones, alguien ha estado dentro.

    Cómo detectarlo: Usa WP-CLI para verificar integridad. Desde terminal:

    1. Ejecuta: wp core verify-checksums
    2. WordPress compara tus archivos con los hashes oficiales
    3. Cualquier archivo modificado te lo dirá inmediatamente

    También revisa los permisos: ls -la wp-config.php debe mostrar -rw-r--r-- (644). Si ves permisos más abiertos como 777, tu servidor está vulnerable a modificaciones.

    He visto backdoors disfrazados de actualizaciones legales. El atacante modifica wp-load.php con dos líneas que parecen inocentes pero crean una puerta trasera. Ese archivo pasa desapercibido porque es legítimo, excepto que no es el original.

    Síntoma 3: Plugins inactivos o temas deshabilitados sin razón aparente

    Encontré algo interesante en mis auditorías: muchos sitios comprometidos tienen plugins de seguridad instalados pero desactivados. Algunos incluso tienen el login de administrador «protegido» por un plugin que está inactivo.

    ¿Coincidencia? No. El malware a veces desactiva tus defensas después de tomar control. Es como neutralizar la alarma de una casa antes de robar.

    Cómo detectarlo: Revisa tu carpeta /wp-content/plugins/ vía SFTP o terminal:

    • ¿Hay plugins que no reconoces?
    • ¿Plugins que están inactivos desde hace meses?
    • ¿Plugins instalados pero nunca activados?

    Un patrón que veo mucho: el atacante instala un plugin con nombre como «wp-security» o «backup-manager» que es en realidad un troyan. Parece legítimo, pero si lo activas, otorga acceso remoto al servidor.

    Síntoma 4: Base de datos más grande de lo que debería

    Tu base de datos WordPress crece cuando añades posts, comentarios, productos (en WooCommerce), etc. Pero si de repente ves que la BD ha crecido 50 MB en una semana sin que hayas hecho nada, algo huele mal.

    El malware a veces almacena datos robados directamente en la BD. Skimmers de tarjetas guardan información de clientes en una tabla oculta. Backdoors almacenan cachés de datos para exfiltración lenta.

    Cómo detectarlo: Conéctate a tu base de datos (vía phpMyAdmin o CLI):

    1. Ejecuta: SELECT table_name, ROUND(((data_length + index_length) / 1024 / 1024), 2) AS size_mb FROM information_schema.tables WHERE table_schema = 'tu_basedatos' ORDER BY size_mb DESC;
    2. Busca tablas que no reconoces
    3. Las tablas legales de WordPress empiezan con tu prefijo (por defecto wp_)
    4. Si ves wp_xyzabc_temp o backup_stolen_data, eso es malware

    También revisa los usuarios de BD. Algunos backdoors crean un usuario con nombre ofuscado como wp_usr_234 con permisos totales. Solo deberías tener uno o dos usuarios legales.

    Síntoma 5: Procesos del servidor sospechosos y uso anómalo de CPU

    Aunque esto requiere acceso root, si tienes VPS o servidor dedicado, puedes verlo. Los cryptominers (malware que usa tu servidor para minar criptomonedas) consumen CPU masivamente.

    Cómo detectarlo: En terminal:

    • top o htop para ver procesos activos
    • Busca procesos raros con nombres ofuscados: .hidden, system, update
    • ps aux | grep -v grep | grep -E "(curl|wget|perl|python)" muestra si hay descargas sospechosas activas
    • netstat -ano | grep ESTABLISHED lista todas las conexiones de red activas

    He encontrado backdoors que ejecutan scripts Python que se conectan a botnets. El servidor se vuelve lento para usuarios legales pero mantiene conexiones persistentes hacia servidores de mando y control.

    Si tu servidor está alojado, pide a tu host que revise los logs de sistema. Muchos no lo hacen a menos que lo solicites explícitamente.

    Síntoma 6: Modificación de archivo de salida (output_handler) o constantes en wp-config.php

    Este es técnico, pero importante. Algunos backdoors instalan funciones que interceptan todo lo que WordPress genera antes de enviarlo al navegador. Se inyectan mediante:

    • Modificar php.ini (si tienes acceso)
    • Agregar código en wp-config.php que carga un archivo remoto
    • Inyectar en el .htaccess con directivas como auto_prepend_file o auto_append_file

    Cómo detectarlo: Abre wp-config.php y busca:

    • Líneas que cargan include, require, o eval() después de las constantes legales
    • URLs extrañas en define() que no reconoces
    • Base64 decodificado que parece código PHP ofuscado

    Revisa también tu .htaccess. El malware a menudo agrega:

    php_value auto_prepend_file /var/www/html/wp-content/plugins/evil.php

    Eso cargará el malware en cada request, sin que ningún plugin lo vea.

    Síntoma 7: Logs de acceso y errores borrados o ausentes

    Los atacantes profesionales borran logs. Si tu servidor de repente no tiene registros de acceso en ciertos días, o los logs de errores PHP están vacíos cuando deberían tener contenido, alguien ha estado limpiando rastros.

    Cómo detectarlo: Accede vía FTP o SFTP a:

    • /var/log/apache2/access.log (Apache)
    • /var/log/nginx/access.log (Nginx)
    • /var/log/php-fpm.log (PHP-FPM)

    Busca brechas de tiempo donde no hay registros. También revisa en tu panel de control (cPanel, Plesk) si hay logs de errores de WordPress. Si están vacíos o solo muestran una semana cuando deberían mostrar meses, eso es sospechoso.

    Un malware sofisticado se conecta vía SSH, ejecuta comandos sin dejar rastro en los logs normales, y luego borra todo. Afortunadamente, algunos hosts guardan logs de sistemas más profundos que no son tan fáciles de eliminar.

    Síntoma 8: Contraseñas de usuario cambio sin consentimiento

    Si alguien reporta que no puede acceder al admin, o tú intentas entrar y tu contraseña no funciona, es probable que el malware haya creado o modificado usuarios. Los backdoors suelen crear una cuenta admin oculta para mantener acceso incluso si limpias los archivos.

    Cómo detectarlo: En la base de datos:

    1. Abre phpMyAdmin y ve a wp_users
    2. Busca usuarios que no reconoces
    3. Usuarios con email extraño (spam@attacker.com)
    4. Accounts creadas en fechas que no coinciden con tus acciones

    También revisa wp_usermeta para permisos. Un usuario «regular» podría tener el rol «administrator» modificado silenciosamente.

    ¿Qué hacer si sospechas que tienes malware?

    Si identificaste uno o más síntomas, aquí está mi protocolo:

    Paso 1: Confirma antes de entrar en pánico

    Ejecuta un escaneo gratuito con Sucuri SiteCheck o Wordfence Scan. Ambos son confiables y te dirán si hay malware conocido. No es 100% preciso (el malware personalizado es difícil de detectar), pero es un buen primer paso.

    Paso 2: No publiques nueva información

    Si tienes una tienda online, considera desactivarla temporalmente. Un skimmer activo sigue robando datos mientras analyzes. Es mejor perder un día de ventas que comprometer a tus clientes.

    Paso 3: Haz un backup de seguridad (limpio)

    Antes de limpiar nada, haz un backup de los archivos comprometidos para análisis posterior. Guarda la BD actual. Esto es vital si necesitas investigación forense o reportar a autoridades como la AEPD (en caso de robo de datos).

    Paso 4: Limpia o reinstala

    Tienes dos opciones: limpiar manualmente (requiere experiencia) o reinstalar WordPress desde cero. Reinstalar es más seguro porque garantiza que todo malware se va, pero pierdes personalizaciones si no estaban en un tema hijo.

    Si limpias manualmente:

    • Borra todos los plugins y temas excepto los que usas
    • Reemplaza los archivos core de WordPress (mantén tu carpeta wp-content)
    • Cambia todas las contraseñas: DB, FTP, admin de WordPress
    • Actualiza todos los plugins a la última versión
    • Revisa cada backup de archivo reciente para asegurar que está limpio

    Paso 5: Hardening del servidor

    Después de limpiar, refuerza. Esto es crítico:

    • Cambia el prefijo de tablas: Por defecto es wp_. Muchos ataques lo asumen. Cámbialo a algo como mf_.
    • Protege wp-admin: Restringe acceso solo desde tu IP usando .htaccess o firewall.
    • Deshabilita edición de archivos: Agrega en wp-config.php: define('DISALLOW_FILE_EDIT', true);
    • Limita intentos de login: Usa Wordfence o similar para 2FA y rate limiting.
    • Revisa permisos de carpetas: wp-content debe ser 755, wp-config.php debe ser 644.

    Prevención: cómo evitar que vuelva a suceder

    Una vez limpies, la prevención es más fácil que la limpieza:

    • Mantén WordPress actualizado: Cron automático es tu amigo. La mayoría de las brechas explotan vulnerabilidades conocidas hace años.
    • Audita plugins: Desinstala cualquier plugin que no uses. Los plugins desactualizados son el #1 vector de ataque.
    • Monitoreo continuo: Herramientas como Sucuri Site Monitoring te alertan si detectan cambios o malware nuevo.
    • Backups automáticos: Al menos diarios. Si todo falla, recuperas tu sitio limpio.
    • WAF (Web Application Firewall): Cloudflare, Sucuri, o Wordfence ofrecen WAF que bloquean ataques comunes antes de que lleguen a tu servidor.

    En mi experiencia, la detección temprana es todo

    He visto propietarios que detectaron malware en 48 horas (porque revisaban logs regularmente) y lo eliminaron antes de que causar daño. También he visto casos donde el malware vivió 6 meses silenciosamente, robando datos de clientes y destruyendo el SEO del sitio.

    La diferencia: vigilancia. Si implementas aunque sea uno de los puntos que mencioné (revisar Search Console, hacer escaneos mensuales, actualizar religiosamente), tu riesgo baja enormemente.

    Si necesitas ayuda profesional para limpiar, analizar logs, o hardening completo de tu WordPress o PrestaShop, contáctame en ManuelFolgar.com. Realizo análisis profundos con herramientas de nivel enterprise, limpieza garantizada, y plan de hardening personalizado. Tu seguridad es mi prioridad.

  • El error más caro: qué hacen mal los propietarios antes de contratar profesionales

    El error más caro: qué hacen mal los propietarios antes de contratar profesionales

    El error más caro: qué hacen mal los propietarios antes de contratar profesionales

    En mi experiencia auditando más de 500 sitios comprometidos, he visto un patrón que se repite constantemente: cuando llamas a un profesional de ciberseguridad web, ya es demasiado tarde. No porque no podamos resolver el problema —lo hacemos—, sino porque el coste económico y reputacional habría sido infinitamente menor si hubieras actuado antes. Hoy quiero mostrarte qué errores cometen la mayoría de propietarios de WordPress y PrestaShop que después se arrepienten.

    1. Ignorar las actualizaciones: el lujo que no puedes permitirte

    Este es probablemente el error número uno. Cuando reviso un sitio infectado, la primera pregunta que hago es: «¿cuándo fue la última actualización de WordPress, plugins y temas?» La respuesta más frecuente: «No sé, lleva meses sin tocar».

    Las vulnerabilidades conocidas en plugins desactualizados son la puerta de entrada preferida de los atacantes. Toma el caso de Elementor, WooCommerce o Yoast SEO: cada parche de seguridad cierra un agujero que los malwares ya están explotando en miles de sitios que no actualizan. En PrestaShop ocurre lo mismo con módulos de pago o gestión de inventario.

    Lo que recomiendo siempre es establecer un cronograma automático de actualizaciones en desarrollo o testing primero, y luego en producción. No es complicado: una hora mensual puede ahorrarte 3.000 euros en limpieza de malware.

    Costo real: Una inyección SQL en un plugin desactualizado de WooCommerce puede robar datos de clientes. Notificación a afectados + auditoría forense + pérdida de reputación = mínimo 5.000 euros.

    2. Contraseñas débiles en el back-office

    Todavía encuentro sitios con credenciales como «admin123» o «wordpress2024». Cuando realizo un ataque de fuerza bruta contra wp-login.php sin protección, accedo en cuestión de minutos.

    El error no es solo la contraseña débil. Es que los propietarios:

    • No restablecen contraseñas cuando despiden a un trabajador que tenía acceso.
    • Usan la misma contraseña en múltiples sitios.
    • No activan autenticación de dos factores (2FA).
    • No limitan intentos de login fallidos.

    Un atacante que accede al back-office puede instalar un backdoor en 30 segundos. Desde entonces, aunque cambies la contraseña, ellos siguen dentro.

    Acción preventiva: Usa un gestor de contraseñas, implementa 2FA con plugins como Wordfence, y configura límites de intentos de login fallidos en tu archivo .htaccess o a través de tu WAF.

    3. No tener copias de seguridad o tenerlas sin verificar

    Cuando descubrimos que tu sitio está comprometido, la única forma de volver a estado limpio sin dudas es restaurar desde una copia de seguridad previa a la infección. Pero muchos propietarios:

    • No hacen copias de seguridad en absoluto.
    • Las hacen, pero nunca las prueban restaurándolas.
    • Las almacenan en el mismo servidor (si se hackea, se pierden todas).
    • No tienen automatización, por lo que «olvidan» hacer backups durante meses.

    Una copia de seguridad corrupta o infectada es peor que no tener ninguna, porque te hace creer que estás protegido cuando no lo estás.

    Mi recomendación: Automatiza backups diarios con plugins como UpdraftPlus o Backwpup, almacénalos en AWS S3 o Google Drive (fuera del servidor), y prueba una restauración al menos trimestralmente.

    4. Desconocer qué plugins y temas tienes instalados

    Cuando analizo un sitio, genero un inventario completo de todo lo que corre. Frecuentemente encuentro:

    • Plugins nulled (pirateados) descargados de fuentes dudosas.
    • Temas premium «crackeados» que vienen con backdoors.
    • Plugins desactualizados de hace 3 años que no se usan.
    • Complementos que nunca fueron instalados conscientemente (¿cómo llegaron ahí?).

    Cada plugin es una línea de código potencialmente vulnerable. Cada tema es una oportunidad de ataque. Si no sabes qué tienes, no puedes protegerte.

    Acción preventiva: Ejecuta en terminal WP-CLI con wp plugin list y wp theme list para saber exactamente qué tienes. Elimina todo lo que no uses. Compra solo desde fuentes oficiales: WordPress.org, distribuidores autorizados.

    5. No proteger el archivo wp-config.php

    Este archivo contiene las credenciales de acceso a tu base de datos. Si un atacante lo obtiene, tiene acceso completo a toda tu información. Sin embargo, muchos servidores lo sirven sin protección.

    No cuesta casi nada protegerlo mediante .htaccess:

    • Denegar acceso directo a wp-config.php.
    • Desactivar edición de archivos desde el back-office (constante DISALLOW_FILE_EDIT).
    • Cambiar los permisos de archivo a 600.

    Si tu proveedor de hosting no te permite esto, es hora de cambiar de proveedor.

    6. Ignorar alertas de Google Search Console

    Google te avisa cuando detecta malware o contenido inyectado en tu sitio. He visto propietarios con 50+ alertas sin abrir. Eso es equivalente a ignorar una alarma de incendio porque no quieres mirar.

    Las advertencias de seguridad en los resultados de búsqueda también te cuestan visibilidad y confianza de clientes. Una detección de malware puede reducir tráfico orgánico hasta un 90%.

    Acción: Revisa Search Console semanalmente. Si hay alertas, invéstigalas inmediatamente o contacta a un profesional.

    7. No implementar un WAF (Web Application Firewall)

    Un WAF es como un guardaespaldas para tu sitio web. Detecta patrones de ataque (inyección SQL, XSS, brute force) y los bloquea antes de llegar a tu servidor.

    Soluciones económicas como Wordfence, Sucuri o Cloudflare ofrecen WAF con planes asequibles. Si no tienes nada, estás navegando sin casco de seguridad.

    8. Delegar seguridad a desarrolladores sin experiencia en ciberseguridad

    Desarrollar una tienda online no es lo mismo que asegurarla. Un buen developer crea funcionalidades. Un profesional de seguridad piensa como un atacante: «¿por dónde entraría?»

    Muchos propietarios creen que porque tienen un developer interno, ya están cubiertos. Luego descubren una vulnerabilidad de inyección SQL que habría sido detectada en una auditoría profesional.

    9. No tener política de acceso para usuarios

    ¿Cuántas personas tienen credenciales de admin en tu WordPress? ¿Las restableciste cuando alguien se fue? ¿Tienes registros de quién accedió cuándo?

    En PrestaShop ocurre lo mismo: empleados con acceso al back-office que ya no trabajan contigo. Un acceso comprometido o malintencionado puede ser indistinguible de un ataque externo.

    Mejor práctica: Crea roles y permisos específicos. Admin solo para ti. Editors para contenidos. WooCommerce Manager para responsables de tienda. Usa auditoría de logs para rastrear cambios.

    10. Esperar a que «algo ocurra» antes de actuar

    Este es el peor error. Esperar a tener un problema para contratar a un profesional es como esperar a tener un infarto para ir al cardiólogo.

    La seguridad proactiva es exponencialmente más barata que la reactiva. Una auditoría anual (200-500 euros) previene un ataque de 5.000+ euros. Un escaneo trimestral detecta malware temprano. Un hardening inicial ahorra migraciones de emergencia.

    Los sitios web no «se protegen solos». Requieren vigilancia constante, actualizaciones regulares y una mentalidad defensiva.

    ¿Cuál es el costo real de esperar?

    Cuando un sitio está comprometido, los gastos incluyen:

    • Análisis forense: 400-800 euros (saber cómo entraron).
    • Limpieza completa: 600-2.000 euros (eliminar cada rastro de malware).
    • Restauración de datos: 300-1.500 euros si hay corrupción.
    • Auditoría post-limpieza: 300-500 euros (asegurar que está limpio).
    • Hardening: 500-1.500 euros (prevenir futuros ataques).
    • Pérdida de reputación y ventas: Incalculable.
    • Notificación a usuarios afectados: Obligatorio por RGPD, costoso en tiempo.

    Total realista: 2.500-6.000 euros en una emergencia. Compare con 300-500 euros anuales en mantenimiento preventivo.

    El primer paso: haz una auditoría ahora

    No esperes a tener un problema. En ManuelFolgar.com realizo auditorías de seguridad completas que incluyen:

    • Escaneo de malware y vulnerabilidades conocidas.
    • Análisis de configuración y permisos.
    • Inventario de plugins, temas y dependencias.
    • Recomendaciones de hardening personalizadas.
    • Plan de acción con prioridades.

    El primer paso no cuesta tanto como el último. Contáctame para una auditoría sin compromiso. Te mostraré exactamente dónde están tus brechas de seguridad antes de que alguien más las encuentre.

    Referencias y recursos

    Para profundizar en ciberseguridad web, consulta estas fuentes de autoridad:

    La ciberseguridad web no es un gasto. Es una inversión en continuidad de negocio. Actúa ahora, antes de que sea demasiado tarde.

  • Redirecciones a páginas japonesas: rastrea el origen del phishing en tu WordPress

    Redirecciones a páginas japonesas: rastrea el origen del phishing en tu WordPress

    Redirecciones a páginas japonesas en WordPress: cómo identificar y eliminar este ataque de phishing

    En mi experiencia analizando sitios WordPress comprometidos, las redirecciones a páginas japonesas son uno de los indicadores más claros de infección por malware. Lo que encuentro constantemente es que los propietarios no se dan cuenta hasta que Google ha penalizado su sitio o los usuarios reportan comportamientos extraños. Hoy te enseño cómo detectar este ataque, rastrear su origen y eliminarlo de raíz.

    ¿Qué son las redirecciones a páginas japonesas y por qué ocurren?

    Las redirecciones a dominios japoneses (típicamente .jp, pero también subdominios comprometidos con características tipográficamente similares) son un vector de ataque especializado en phishing y distribución de malware. El atacante inyecta código en tu WordPress que redirige a visitantes específicos —generalmente por geolocalización o user-agent— hacia páginas fraudulentas.

    ¿Por qué Japón? Porque ese mercado tiene alto valor para estafadores de tarjetas de crédito y bots que compran dominios baratos en .jp para alojar malware. Cuando analizo un sitio con este problema, encuentro que el 80% de las veces la redirección está condicionada: solo afecta a ciertos países, navegadores o dispositivos móviles, lo que explica por qué el propietario no la ve al revisar su propio sitio.

    Cómo rastrear el origen: los lugares donde se esconde este malware

    Lo primero que hago es ejecutar comandos en WP-CLI para buscar patrones de redirección. El malware típicamente se inyecta en estos lugares:

    • wp-config.php modificado: Código malicioso antes de la línea «require_once» o en constantes defectuosas
    • Funciones.php del tema activo: Lógica de redirección condicional que los editores visuales no siempre muestran
    • Plugins comprometidos o nulled: Temas y plugins descargados de fuentes no oficiales suelen incluir backdoors
    • Archivos .htaccess manipulados: Reglas de reescritura que redirigen según geolocalización
    • Webshells en carpeta /uploads: Archivos PHP ocultos con nombres que parecen imágenes
    • Inyecciones en la base de datos: Opciones de WordPress modificadas (siteurl, home, etc.)
    • Headers manipulados en wp-load.php: Redirecciones JavaScript insertadas antes de cualquier output

    Cuando ejecuto búsquedas recursivas con grep, busco patrones como «location.href», «wp_redirect», «header(«, combinados con dominios japoneses o variables que revelen lógica condicional por geolocalización.

    Paso 1: Verificar redirecciones con herramientas online

    Antes de entrar en terminal, prueba esto de forma segura desde tu navegador:

    • Abre Sucuri SiteCheck e introduce tu dominio. Detectará redirecciones conocidas y alertas de malware
    • Usa Google Search Console y revisa «Seguridad» → «Problemas de seguridad». Google es muy preciso identificando este tipo de ataques
    • Comprueba con VirusTotal: sube tu URL y obtén análisis de 70+ antivirus simultáneamente

    Estos análisis externos son cruciales porque el atacante frecuentemente deshabilita redirecciones si detecta que eres administrador (verificando cookies de admin, IP, user-agent).

    Paso 2: Acceso SSH y búsqueda manual en archivos críticos

    Si tienes acceso SSH (que recomiendo siempre para WordPress en producción), ejecuta estos comandos:

    Buscar redirecciones en PHP:

    grep -r "location.href|wp_redirect|header(.*jp|japan" /home/tudominio/public_html/ --include="*.php" 2>/dev/null

    Buscar código ofuscado (base64, rot13):

    grep -r "base64_decode|eval|preg_replace|assert" /home/tudominio/public_html/wp-content/ --include="*.php" | head -20

    Listar archivos PHP recientes en uploads:

    find /home/tudominio/public_html/wp-content/uploads/ -name "*.php" -o -name "*.jpg.php" -mtime -30

    Cualquier archivo .php en la carpeta uploads es sospechoso por defecto. Los atacantes lo saben, así que lo disfrazan como imagen (.jpg.php, .png.php).

    Paso 3: Revisar la base de datos de WordPress

    Conéctate vía phpMyAdmin o línea de comandos MySQL y ejecuta:

    Buscar opciones modificadas:

    SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%jp%' OR option_value LIKE '%redirect%';

    Buscar código en posts y postmeta:

    SELECT ID, post_content FROM wp_posts WHERE post_content LIKE '%location.href%' OR post_content LIKE '%eval%';

    Las opciones de WordPress que encontramos comprometidas suelen ser «home», «siteurl» o custom options creadas por plugins maliciosos. Allí se inyecta lógica condicional de redirección.

    Paso 4: Analizar el tráfico y logs de acceso

    Los logs del servidor web revelan el patrón de ataque. En Apache:

    tail -500 /var/log/apache2/access_log | grep -i ".jp|japan|redirect" | cut -d' ' -f1,7,9 | sort | uniq -c

    Busca peticiones GET a archivos PHP sospechosos, especialmente con User-Agents genéricos (curl, wget) que indican bots de ataque. Las redirecciones exitosas generan códigos 301 o 302; anótalos.

    Paso 5: Inspeccionar plugins y temas desactualizados

    Lo que recomiendo siempre es ejecutar un listado de versiones de plugins:

    wp plugin list --field=name,version,status

    Cualquier plugin inactivo pero presente es un riesgo. Los atacantes frecuentemente dejan plugins desactivados para mantener acceso si eliminas el activo. Revisa también los temas:

    wp theme list

    Temas descargados de sitios «nulled» (ilegales) como ThemeForest alternativas incluyen malware integrado. He encontrado inyecciones de redirección en functions.php de temas que el propietario no recuerda haber modificado nunca.

    Eliminación segura: el proceso paso a paso

    Paso A: Aislamiento del sitio

    Antes de limpiar, toma una copia de seguridad completa (base de datos + archivos). Luego, deshabilita todos los plugins excepto uno de seguridad como Wordfence:

    wp plugin deactivate --all

    Desactiva también el tema actual y activa uno seguro de WordPress.org:

    wp theme activate twentytwentyfour

    Esto aísla la infección. Si las redirecciones persisten, el malware está en núcleo o base de datos.

    Paso B: Limpieza de archivos

    Elimina todos los plugins sospechosos. Para cada uno:

    wp plugin delete nombre-plugin --allow-root

    Descarga la última versión limpia de WordPress.org, y reemplaza solo los archivos del núcleo (wp-admin/, wp-includes/, index.php, etc.), preservando wp-content/:

    rsync -avz --exclude='wp-content' --delete wordpress/ /ruta/publica/

    Elimina cualquier archivo .php sospechoso en uploads:

    find /ruta/publica/wp-content/uploads -name "*.php" -delete

    Paso C: Limpieza de base de datos

    Revisa y corrige opciones comprometidas:

    wp option update home 'https://tudominio.es'
    wp option update siteurl 'https://tudominio.es'

    Busca y elimina custom options maliciosas (creadas por plugins de ataque):

    wp option delete opcion_sospechosa

    Limpia la caché de WordPress:

    wp cache flush

    Paso D: Cambiar credenciales y revisar accesos

    Modifica contraseña del admin, de FTP/SSH y de base de datos:

    wp user update 1 --prompt=user_pass

    Revisa los usuarios de WordPress para detectar cuentas backdoor creadas por el atacante:

    wp user list --field=ID,user_login,user_email

    Elimina usuarios sospechosos (especialmente «admin» si no es el tuyo, o cuentas genéricas).

    Cómo prevenir futuras redirecciones a Japón

    Hardening inmediato:

    • Deshabilita la edición de archivos en el panel: añade a wp-config.php: define('DISALLOW_FILE_EDIT', true);
    • Protege wp-config.php con regla .htaccess: <Files wp-config.php> deny from all </Files>
    • Cambia el prefijo de tablas (si es aún wp_): requiere migración pero aumenta seguridad
    • Limita intentos de login de /wp-login.php a 5 por IP/hora usando Wordfence o ModSecurity

    Actualizaciones y plugins:

    • Activa actualizaciones automáticas en wp-config.php: define('AUTOMATIC_UPDATER_DISABLED', false);
    • Solo descarga temas y plugins de WordPress.org o de distribuidores licenciados
    • Elimina cualquier plugin inactivo que no uses
    • Actualiza PHP a versión soportada (mínimo 7.4, recomiendo 8.2+)

    Monitoreo continuo:

    • Instala Wordfence y activa alertas de logins, cambios de archivos y malware
    • Revisa Google Search Console cada semana buscando «Problemas de seguridad»
    • Ejecuta scans de seguridad mensuales con MalCare o Sucuri
    • Mantén logs de acceso (mínimo 90 días) para auditorías

    ¿Cuándo llamar a un experto?

    Si después de estos pasos las redirecciones persisten, el malware está enraizado en el servidor o la base de datos está masivamente comprometida. En mi experiencia, esto requiere herramientas forenses avanzadas y análisis binario que solo un profesional en ciberseguridad puede realizar. La limpieza incorrecta deja backdoors que vuelven a infectar en 48 horas.

    Si necesitas ayuda profesional en eliminar redirecciones a Japón, auditar tu WordPress completamente o implementar hardening real, contacta con nuestro equipo de especialistas en ciberseguridad web. Realizamos análisis forense, limpiezas garantizadas y protección permanente para WordPress y PrestaShop.

  • Blindaje post-ataque: medidas de hardening que realmente funcionan en 48 horas

    Blindaje post-ataque: medidas de hardening que realmente funcionan en 48 horas

    Blindaje post-ataque: medidas de hardening que realmente funcionan en 48 horas

    Cuando descubres que tu sitio web ha sido comprometido, el pánico es justificado. Pero lo que haces en las primeras 48 horas marca la diferencia entre una recuperación rápida y semanas de lucha contra el malware. En mi experiencia analizando cientos de webs infectadas, los sitios que aplican un blindaje estructurado post-ataque logran eliminar vectores de riesgo críticos y evitar reinfecciones en menos de dos días.

    Te mostraré exactamente qué hacer, con qué herramientas y en qué orden, para levantar defensas reales mientras limpias los restos del compromiso.

    Hora 0-2: Aislamiento y diagnóstico de urgencia

    Lo primero es contener el daño. No se trata de limpieza profunda todavía, sino de detener el sangrado mientras recopilamos inteligencia.

    Desconecta la base de datos de bases de datos remotas. Muchos backdoors usan túneles SFTP o conexiones SSH comprometidas para exfiltrar datos de clientes. Si tu hosting permite, cierra el acceso SFTP/SSH durante 48 horas o cambia las credenciales por unas generadas aleatoriamente que solo tú conoces.

    Extrae el wp-config.php (WordPress) o config/settings.php (PrestaShop) a un directorio protegido. Usa WP-CLI para WordPress:

    wp config get DB_USER

    Anota todas las contraseñas activas. Luego las cambiaremos, pero primero necesitas saber cuáles están comprometidas. En PrestaShop, accede vía phpMyAdmin y ejecuta un volcado de las tablas de usuarios antes de modificar nada.

    Genera un reporte rápido con Wordfence CLI. Si tienes acceso SSH, descarga Wordfence CLI y ejecuta:

    wordfence scan --output=detailed

    Esto te da un mapa de archivos sospechosos en 5-10 minutos. Alternativa si no tienes SSH: usa Sucuri SiteCheck en modo online desde https://sitecheck.sucuri.net. No es tan profundo, pero identifica backdoors obvios y patrones de inyección.

    Documenta el incidente en tu log local. Crea un archivo timeline.txt con fecha, hora, qué detectaste y quién tiene acceso. Esto será tu defensa legal y técnica si necesitas reportarlo a AEPD o a tus usuarios.

    Hora 2-6: Cambio masivo de credenciales

    Aquí es donde la mayoría de sitios falla. Cambiar solo la contraseña de admin de WordPress NO es suficiente. Los atacantes suelen crear cuentas fantasma o modificar usuarios existentes a nivel de base de datos.

    WordPress:

    1. Accede a wp-admin (si aún funciona). Si está bloqueado, usa WP-CLI: 
      wp user update admin --user_pass="nueva_password_aleatoria_32_caracteres"
    2. Elimina todos los usuarios excepto los necesarios. En wp-admin, ve a Usuarios y borra cuentas sospechosas. Si usas CLI: 
      wp user delete [usuario_sospechoso] --reassign=admin
    3. Cambia el email de recuperación de cada usuario admin a uno que controles: 
      wp user update admin --user_email="nuevo@dominio.es"
    4. Genera credenciales nuevas para SFTP, SSH y MySQL. Avisa a tu hosting que necesitas resetear todas (esto puede tardar 30 min).

    PrestaShop:

    1. Accede al back-office. Ve a Administración > Empleados y revisa todas las cuentas. Elimina cualquier que no reconozcas.
    2. Cambia la contraseña de cada empleado activo desde el mismo panel.
    3. Ve a Configuración > Tiendas y resetea la contraseña del usuario «Admin» (el usuario root del sistema).
    4. Comprueba que el archivo config/settings.inc.php solo está accesible por lectura: 
      chmod 444 config/settings.inc.php

    Correos y 2FA (autenticación de dos factores): Si tu proveedor de hosting ofrece 2FA en el panel de control, actívalo ahora. Para WordPress, instala Google Authenticator o Authy en tu teléfono y configura 2FA en wp-admin usando un plugin de confianza como Two Factor (desarrollado por WordPress Security Team).

    Hora 6-12: Eliminación de puertas traseras y ficheros sospechosos

    Este es el momento técnico más delicado. Los backdoors modernos no siempre se ven. Pueden estar comprimidos en base64, ofuscados en PHP, o incrustados en ficheros legítimos.

    Busca archivos recién modificados. Accede por SFTP o línea de comandos y ordena por fecha de modificación:

    find /var/www/html -type f -mtime -2 -name "*.php" | head -20

    Esto te muestra todos los PHP modificados en los últimos 2 días. Descárgalos y abre cada uno en un editor de texto. Los backdoors suelen tener características reconocibles: funciones eval(), system(), shell_exec(), $_REQUEST o $_POST sin validar, o código en base64.

    Elimina plugins y temas desactualizados (WordPress). La mayoría de infecciones entran por aquí. Ve a Plugins > Plugins instalados y desactiva todo lo que no uses. Luego:

    wp plugin delete [nombre] --allow-root

    Para temas, si no es Twenty Twenty-Three o superior (temas oficiales de WordPress), considera eliminarlo también:

    wp theme delete [nombre] --allow-root

    Deshabilita la edición de archivos en WordPress. Añade esto al final de wp-config.php:

    define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);

    Esto impide que un atacante (incluso con acceso a wp-admin comprometido) pueda editar funciones.php o plugin files.

    En PrestaShop, elimina módulos no verificados. Ve a Módulos y desinstala cualquier módulo de fuente desconocida, especialmente relacionados con pagos o email. Los skimmers Magecart se disfrazan de módulos legales.

    Hora 12-24: Fortalecimiento de permisos y acceso

    Ahora que el sitio está más limpio, blindamos los puntos de entrada.

    Corrige permisos de directorios. Los permisos incorrectos son una rampa de acceso directa para atacantes. Para WordPress:

    find /var/www/html -type d -exec chmod 755 {} ;
find /var/www/html -type f -exec chmod 644 {} ;
chmod 600 /var/www/html/wp-config.php
chmod 700 /var/www/html/wp-content/uploads

    Para PrestaShop:

    chmod 755 app/config/
chmod 644 app/config/parameters.php
chmod 700 var/
chmod 755 modules/

    Protege wp-login.php (WordPress). Añade a tu .htaccess una regla que limite intentos de fuerza bruta:

    <IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} wp-login.php
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.*$ - [F,L]
</IfModule>

    O usa una solución más robusta: redirige wp-login.php a una URL privada. En wp-config.php:

    define('WP_HOME', 'https://tudominio.es');
define('WP_SITEURL', 'https://tudominio.es');
define('ADMIN_COOKIE_DOMAIN', 'tudominio.es');

    Luego instala Hide My WP o un plugin equivalente que cambie la ruta de acceso al panel.

    Establece límite de intentos de login. En el .htaccess, añade:

    <IfModule mod_limit.c>
<Limit GET POST>
order allow,deny
allow from all
</Limit>
</IfModule>

    O usa el plugin Wordfence (versión gratuita) que incluye rate limiting nativo.

    Hora 24-36: Refuerzo de configuración HTTP y CSP

    Las cabeceras HTTP son tu escudo contra ataques cliente y exfiltración de datos. Muchos sitios las ignoran.

    Implementa Content Security Policy (CSP). Añade a tu .htaccess o a wp-config.php (via plugin):

    Header set Content-Security-Policy "default-src 'self'; script-src 'self' cdn.ejemplo.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none';"

    CSP previene inyecciones de código malicioso (XSS) y exfiltración de datos vía CORS.

    Añade HSTS (HTTP Strict Transport Security).

    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    Esto obliga a HTTPS permanente y previene downgrade attacks.

    Protege contra clickjacking y MIME sniffing:

    Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"

    Desactiva la indexación de directorios. Si hay una carpeta sin index.php o index.html, los atacantes pueden explorar archivos:

    <IfModule mod_autoindex.c>
Options -Indexes
</IfModule>

    En PrestaShop, asegúrate de que admin/index.php esté protegido con IP whitelist en el .htaccess del directorio admin/:

    <Files "index.php">
order deny,allow
deny from all
allow from 192.168.1.1
</Files>

    (Sustituye la IP por la tuya o la de tu oficina.)

    Hora 36-48: Monitoreo y verificación

    Las últimas 12 horas son para verificar que todo funciona y configurar alertas.

    Ejecuta un escaneo completo post-limpieza. Usa MalCare o Sucuri SiteCheck nuevamente. Debe salir completamente limpio. Si detecta malware residual, vuelve al paso de búsqueda de backdoors.

    Configura logging y alertas. En WordPress, instala WP Security Audit Log o similar. Configura alertas por email para:

    • Nuevos usuarios creados
    • Cambios en plugins o temas
    • Acceso a wp-admin desde IPs nuevas
    • Errores 404 o 403 frecuentes (intentos de acceso a archivos protegidos)

    Monitorea la base de datos. En phpMyAdmin, ejecuta una consulta para buscar inyecciones SQL residuales:

    SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%' OR post_content LIKE '%eval%' OR post_content LIKE '%base64%';

    Si encuentras algo, edita o elimina ese post.

    Notifica a Google Search Console. Reporta que el sitio fue hackeado. Ve a Seguridad > Problemas de seguridad. Google puede tomar días en limpiar el index, pero es obligatorio informar.

    Cumple con normativa AEPD si manejabas datos personales. Si almacenabas datos de clientes (emails, teléfonos, direcciones), debes reportar la brecha a la Autoridad de Protección de Datos. El plazo es máximo 72 horas desde que descubriste el incidente.

    Checklist de 48 horas (para imprimir)

    • ☐ Cambio de todas las credenciales (MySQL, SFTP, SSH, wp-admin, panel hosting)
    • ☐ Búsqueda y eliminación de backdoors (archivos recientes, code review)
    • ☐ Eliminación de plugins/temas desactualizados o sospechosos
    • ☐ DISALLOW_FILE_EDIT y DISALLOW_FILE_MODS en wp-config.php
    • ☐ Permisos corregidos (644 archivos, 755 directorios, 600 wp-config.php)
    • ☐ Protección de wp-login.php y admin con rate limiting
    • ☐ CSP, HSTS y cabeceras de seguridad en .htaccess
    • ☐ 2FA activado en hosting y wp-admin
    • ☐ Escaneo post-limpieza con Sucuri o MalCare
    • ☐ Reporte a Google Search Console y AEPD (si corresponde)

    ¿Y después de 48 horas?

    El blindaje inicial está hecho, pero esto no es permanente. Los atacantes evolucionan, y tu defensa debe también. Después de estos dos días, necesitas:

    • Actualizaciones automáticas: Activa actualizaciones de seguridad automáticas en WordPress para core, plugins y temas.
    • Backups diarios: Configura backups automáticos con UpdraftPlus o Backwpup que se almacenen fuera del servidor (AWS S3, Dropbox, Google Drive).
    • Monitoreo 24/7: Usa Wordfence, MalCare o Sucuri (versión premium) para alertas en tiempo real.
    • Auditoría trimestral: Cada tres meses, pide un análisis profesional. Mi equipo en ManuelFolgar.com lo hacemos rutinariamente a clientes recuperados.

    Errores que NO debes cometer

    No reinstales WordPress o PrestaShop sobre el sitio comprometido. Es tentador hacer table rasa, pero si un backdoor está en tu hosting o en credenciales compartidas, volverá a infectar.

    No confíes en plugins «de limpieza automática». Algunos como WP Hacked Help prometen limpiar automáticamente. En mi experiencia, son lentos y dejan restos. Es mejor un análisis manual rápido que una falsa seguridad.

    No publiques en redes que fuiste hackeado sin estar seguro de que está limpio. Los atacantes monitorean búsquedas sobre sus víctimas y pueden reinfectar si ven que están limpios pero vulnerables.

    No olvides cambiar contraseñas de email asociadas. Si tu dominio está registrado con un email [email protected] y fue comprometido, un atacante puede resetear el dominio o certificados SSL. Cambia también esa contraseña.

    En ManuelFolgar.com hemos visto sitios que, sin ayuda profesional, tardan 2-3 semanas en estar seguros. Con este plan de 48 horas, aceleramos significativamente. Pero si en algún momento sientes que el malware se resiste, que tu acceso está bloqueado o que no sabes identificar código malicioso, contáctame para una auditoría completa y limpieza profesional. Garantizo que en 48-72 horas tu sitio estará limpio, blindado y monitoreado.

    El tiempo es tu aliado en un ciberataque. Actúa rápido, sigue este orden, y recuerda: la mejor defensa es que no te haqueen. Pero si ya pasó, que al menos sea una lección aprendida.

  • Diferencia entre ransomware, backdoor y inyección SQL en WordPress

    Diferencia entre ransomware, backdoor y inyección SQL en WordPress

    Tres amenazas cibernéticas que debes diferenciar en WordPress

    Cuando analizo un sitio WordPress comprometido, lo primero que hago es identificar qué tipo de malware o técnica de ataque lo ha afectado. En mi experiencia, muchos administradores confunden términos como ransomware, backdoor e inyección SQL, creyendo que son variantes del mismo problema. La realidad es muy diferente: cada uno representa un vector de ataque distinto, con intenciones, métodos y consecuencias completamente diferentes.

    Entender estas diferencias es esencial para proteger tu sitio web. No es lo mismo un ataque de inyección SQL que instala un backdoor, que un ransomware que cifra tus archivos, ni que un atacante que simplemente intenta extraer datos de tus bases de datos. En este artículo te explico qué es cada uno, cómo funcionan, qué daño causan y, lo más importante, cómo detectarlos y prevenirlos.

    ¿Qué es una inyección SQL y cómo afecta a WordPress?

    La inyección SQL es una técnica de ataque que explota formularios, campos de búsqueda o parámetros de URL mal validados para ejecutar comandos SQL arbitrarios en tu base de datos. En WordPress, esto ocurre cuando un plugin, tema o código personalizado no sanitiza correctamente las entradas del usuario.

    Cuando hago auditorías de seguridad, veo que la mayoría de inyecciones SQL en WordPress ocurren a través de:

    • Formularios de contacto defectuosos: un atacante introduce código SQL en lugar de un nombre o correo.
    • Parámetros de búsqueda en URLs: ejemplo.com/?s=’; DROP TABLE wp_users; —
    • Plugins vulnerables sin actualizar: búsquedas de productos, filtros, campos personalizados.
    • Campos personalizados o metadatos: si aceptan entrada de usuario sin validación.

    ¿Qué consigue el atacante con una inyección SQL? Acceso a la base de datos completa. Puede:

    1. Leer datos sensibles: usuario admin, contraseñas hasheadas, email de clientes.
    2. Modificar el contenido del sitio: cambiar posts, insertar links maliciosos, redirigir a páginas de phishing.
    3. Crear nuevos usuarios administradores para mantener acceso persistente.
    4. Robar información de WooCommerce: datos de pedidos, direcciones, números de teléfono.
    5. Extraer contraseñas de formularios guardados, si existen sin encriptación.

    La diferencia clave: la inyección SQL es un método para acceder a datos o modificarlos en tiempo real. No cifra, no deja un programa permanente en el servidor (aunque puede ser el primer paso para instalar un backdoor). Es más un «robo de datos» que una «infección».

    Detección de inyección SQL en WordPress

    Cuando reviso logs de auditoría, busco:

    • Errores de MySQL en error.log: «You have an error in your SQL syntax»
    • Consultas anómalas en Access.log: ?s=1′ AND ‘1’=’1, ?id=1 UNION SELECT …
    • Cambios no autorizados en wp_users o wp_posts sin registro de edición.
    • Nuevas tablas en la base de datos que no reconoces.

    Con WP-CLI puedo hacer un dump de la base de datos y analizarla:

    • wp db export --porcelain para extraer un backup rápido y revisar integridad.
    • Comparar con una copia limpia anterior, si la tienes.

    ¿Qué es un backdoor en WordPress?

    Un backdoor (puerta trasera) es un componente malicioso dejado deliberadamente en tu servidor para mantener acceso persistente y remoto. A diferencia de la inyección SQL, que es temporal, el backdoor es permanente hasta que lo elimines.

    En WordPress, un backdoor puede ser:

    • Un archivo PHP oculto en /wp-content/uploads/: backdoor.php, shell.php, admin.php, con código que acepta comandos remotos.
    • Un plugin o tema malicioso: código que se activa automáticamente y crea un usuario admin fantasma.
    • Una función dentro de functions.php: que permite ejecutar comandos sin pasar por el dashboard.
    • Un archivo .htaccess modificado: que redirige peticiones o ejecuta código malicioso.
    • Un webshell: un script simple como <?php system($_GET[‘cmd’]); ?> que ejecuta órdenes del sistema operativo.

    ¿Cómo accede el atacante a tu servidor para dejar el backdoor? Los métodos más comunes son:

    1. Explotación de plugin o tema desactualizado: el más frecuente. Una vulnerabilidad de day-zero o conocida permite subir un archivo.
    2. Inyección SQL que crea un usuario y modifica la base de datos: combina inyección SQL con backdoor.
    3. FTP o SSH comprometidos: si el hosting está con credenciales débiles o reutilizadas.
    4. Acceso por fuerza bruta a wp-login: si las contraseñas son débiles, el atacante entra al dashboard y sube un plugin malicioso.
    5. Vulnerabilidad del hosting o servidor: misconfiguración de permisos, servicios vulnerables.

    La diferencia clave: el backdoor es un acceso persistente. El atacante puede volver cuando quiera, sin necesidad de explotar la vulnerabilidad original de nuevo. Es como cambiar la cerradura de tu puerta para tener su propia llave.

    ¿Qué hace un atacante una vez instalado el backdoor?

    • Inyecta SEO spam: cientos de links a sitios de casinos, farmacéuticos, drop shippings.
    • Instala cryptominers: consume CPU para minar criptomonedas.
    • Roba datos: credenciales de pago, emails, información personal.
    • Distribuye malware: convierte tu sitio en servidor de descarga de virus para terceros.
    • Realiza ataques DDoS desde tu servidor: lo convierte en botnet.
    • Busca otros servidores en la red local para propagarse (movimiento lateral).

    Detección de backdoor en WordPress

    Cuando audito un sitio con backdoor, estos son mis pasos:

    • Busco archivos recientes anómalos: find /var/www/html -type f -mtime -7 -name "*.php" para ver archivos modificados en los últimos 7 días.
    • Reviso plugins y temas activos: wp plugin list --status=active para identificar instalaciones no autorizadas.
    • Examino la carpeta /uploads: la mayoría de webshells se ocultan aquí porque suele tener permisos de escritura.
    • Analizo functions.php del tema activo: muchos backdoors se inyectan al final del archivo.
    • Reviso .htaccess: búsqueda de redirecciones o código PHP incrustado.
    • Escaneo con Wordfence CLI: wordfence scan detecta la mayoría de webshells conocidos.
    • Cargo el sitio en VirusTotal: si hay comportamiento malicioso evidente.

    ¿Qué es ransomware y cómo ataca WordPress?

    El ransomware es software malicioso que cifra tus archivos y bases de datos, haciéndolos inaccesibles. El atacante exige un pago (rescate, «ransom» en inglés) para proporcionarte la contraseña de descifrado. Si no pagas, pierdes todos tus datos, o son publicados en darknet.

    En WordPress, el ransomware puede:

    • Cifrar todas tus imágenes, PDFs y documentos descargables: la mayoría de usuarios no pueden acceder a ellos.
    • Cifrar la base de datos: WordPress no puede conectar, el sitio cae completamente.
    • Cifrar archivos de configuración: wp-config.php, .htaccess, dejando el sitio inutilizable.
    • Exfiltrar datos sensibles antes de cifrar: el atacante obtiene información de clientes, luego te chantajea.

    ¿Cómo llega el ransomware a tu WordPress?

    1. A través de un backdoor ya instalado: el atacante descarga y ejecuta el ransomware una vez tiene acceso remoto.
    2. Por una vulnerabilidad RFI (Remote File Inclusion): en un plugin, permite ejecutar código malicioso desde un servidor remoto.
    3. Por un exploit de día cero no parcheado: vulnerabilidad muy nueva, aún sin actualización disponible.
    4. Por descarga accidental por parte de un empleado: phishing dirigido, adjunto malicioso ejecutado dentro de la red del servidor.

    La diferencia clave: el ransomware es destructivo y urgente. No busca acceso silencioso o robo gradual. Busca paralizar tu negocio y cobrarte lo antes posible. Es el ataque más visible y costoso economicamente.

    Signos de ataque ransomware en WordPress

    • El sitio deja de cargar de repente: «Error establiscing database connection».
    • Aparece un archivo de texto o página HTML con mensaje de rescate.
    • Archivos en /uploads tienen extensión inusual: .encrypted, .locked, .cryptolocker.
    • La base de datos no responde o tarda minutos en abrir.
    • CPU al 100% por proceso desconocido ejecutando algoritmo de cifrado.
    • Nota de rescate en el servidor root o en cada directorio.

    Comparativa resumida: inyección SQL vs backdoor vs ransomware

    Aspecto Inyección SQL Backdoor Ransomware
    Tipo de ataque Explotación de formularios Instalación de acceso remoto Cifrado de archivos
    Objetivo Leer/modificar datos Mantener acceso persistente Extorsionar dinero
    Persistencia Temporal (mientras exista la vulnerabilidad) Permanente hasta su eliminación Destructivo, no es permanente
    Visibilidad Muy difícil de detectar Difícil de detectar, requiere auditoría Inmediatamente visible
    Impacto inicial Medio: robo de datos Alto: acceso completo al servidor Crítico: pérdida total de datos
    Cómo prevenirlo Validar y sanitizar inputs Mantener plugins/temas actualizados Backups regulares, monitoreo activo

    Cómo proteger tu WordPress contra estas tres amenazas

    Protección contra inyección SQL

    • Valida y sanitiza todas las entradas de usuario: utiliza funciones como sanitize_text_field(), absint(), esc_attr() en WordPress.
    • Usa consultas preparadas (prepared statements): $wpdb->prepare() en lugar de concatenar variables directamente en SQL.
    • Mantén plugins y temas actualizados: los parches de seguridad suelen corregir inyecciones SQL.
    • Audita plugins personalizados: si desarrollas código custom, hazlo revisar por experto en seguridad.
    • Usa un WAF (Web Application Firewall): servicios como Wordfence Premium o Sucuri bloquean patrones de inyección SQL.

    Protección contra backdoors

    • Mantén WordPress, plugins y temas al día: es la medida #1. Los backdoors usan vulnerabilidades conocidas.
    • Usa contraseñas fuertes y autenticación 2FA: wp-cli admin-user set-password admin contraseña_aleatoria_de_32_caracteres.
    • Protege wp-login.php: limita intentos de conexión con reglas .htaccess o plugins.
    • Cambia el prefijo de tablas de la base de datos: de wp_ a algo aleatorio como xyz12_ en wp-config.php.
    • Deshabilita la edición de archivos en el dashboard: añade a wp-config.php: define( 'DISALLOW_FILE_EDIT', true );
    • Monitorea cambios de archivos: Wordfence CLI detecta webshells, VirusTotal.com escanea archivos sospechosos.
    • Revisa carpeta /uploads regularmente: busca archivos .php que no reconozcas.

    Protección contra ransomware

    • Haz backups automáticos diarios: fuera del servidor, en almacenamiento externo (AWS S3, Google Cloud, servicio profesional de backup).
    • Prueba tus backups regularmente: un backup que no puedes restaurar no sirve de nada.
    • Segmmenta la red: si tienes múltiples servidores, aíslalos. Si uno se infecta, no propagues el ransomware a otros.
    • Implementa permisos de archivo restrictivos: /uploads con permisos 755 (no 777), wp-config.php con 600.
    • Deshabilita ejecución de PHP en carpetas susceptibles: en .htaccess de /uploads, añade: <FilesMatch ".php$"> Deny from all </FilesMatch>.
    • Usa HSTS y CSP (Content Security Policy): reduce el riesgo de distribución de malware desde tu sitio.
    • Monitorea actividad inusual del servidor: CPU alta, ancho de banda inusual, procesos desconocidos.

    Herramientas de auditoría que recomiendo

    Cuando realizo auditorías profesionales, uso esta combinación de herramientas:

    • Wordfence Security: detecta backdoors, webshells, vulnerabilidades conocidas. Su malware scan es muy completo.
    • Sucuri SiteCheck: escaneo rápido de malware visible desde fuera, verifica si está listado en Google Safe Browsing.
    • VirusTotal: sube archivos sospechosos, analiza con 70+ motores de antivirus simultáneamente.
    • WP-CLI: acceso directo a base de datos y archivos del sistema, muy potente para análisis profundo.
    • MalCare: monitoreo automático, limpieza de malware asistida, alertas en tiempo real.

    ¿Qué hacer si tu WordPress ya está comprometido?

    Si sospechas que tu sitio tiene inyección SQL, backdoor o ransomware, estos son mis pasos inmediatos:

    1. Mantén la calma y no desconectes el servidor sin antes hacer un análisis forense. Los logs son tu evidencia.
    2. Aísla el servidor de internet (si es posible): desconéctalo temporalmente para evitar propagación de malware.
    3. Haz una copia de seguridad COMPLETA del servidor (incluyendo malware): necesitarás para análisis posterior.
    4. Si hay ransomware, NO pagues el rescate: no hay garantía de que recibas la contraseña, y financias a delincuentes.
    5. Restaura desde un backup limpio anterior a la infección, si tienes disponible.
    6. Si no tienes backup, necesitas limpiar manualmente: elimina backdoors, parches vulnerabilidades, actualiza todo.
    7. Cambia todas las contraseñas: FTP, base de datos, usuarios WordPress, hosting.
    8. Audita logs de acceso para entender cómo entró el atacante.
    9. Reporta al proveedor de hosting y a Google Search Console: si tu sitio está distribuiendo malware, Google lo listará como peligroso.

    En mi experiencia, cuando un sitio ya está comprometido, la limpieza manual es arriesgada y consume mucho tiempo. Siempre recomiendo una auditoría profesional para asegurar que el malware se elimina completamente y no deja puertas traseras.

    Conclusión: diferencia clara para protección clara

    La inyección SQL es una explotación de formularios que busca robar datos. El backdoor es una puerta trasera que instala acceso persistente. El ransomware cifra archivos para extorsionar dinero. Tres amenazas completamente distintas, con vectores de ataque diferentes, objetivos diferentes, y defensas diferentes.

    Si quieres proteger realmente tu WordPress, no basta con un solo parche de seguridad. Necesitas una estrategia en capas: validación de inputs, actualizaciones regulares, backups automáticos, monitoreo activo, y auditorías periódicas.

    Si ya tienes dudas sobre la seguridad de tu sitio, si has detectado actividad sospechosa, o si simplemente quieres asegurarte de que tu WordPress está blindado contra estas amenazas, te recomiendo que contactes para una auditoría profesional. En ManuelFolgar.com realizamos escaneos de malware profundos, análisis forense, y hardening completo de WordPress y PrestaShop. Solicita tu auditoría de seguridad aquí.

  • Configuración del servidor cPanel/Plesk: errores que abren puertas al malware

    Configuración del servidor cPanel/Plesk: errores que abren puertas al malware

    Configuración del servidor cPanel/Plesk: errores que abren puertas al malware

    Cuando analizo servidores comprometidos en mi trabajo diario, descubro que la mayoría de los ataques no llegan porque el malware sea sofisticado, sino porque la configuración de cPanel o Plesk tiene fallos elementales. Estos paneles de control son el corazón de tu infraestructura web, y un error en su setup puede convertir tu servidor en puerta abierta para ciberdelincuentes.

    En esta guía te muestro los errores de configuración más peligrosos que veo en la práctica, cómo detectarlos y, lo más importante, cómo blindar tu servidor antes de que sea demasiado tarde.

    Por qué cPanel y Plesk son objetivos prioritarios del malware

    cPanel y Plesk no son solo herramientas administrativas: son la llave maestra de tu servidor. Alojando decenas o cientos de sitios web, una sola vulnerabilidad o mala configuración puede comprometer toda tu infraestructura. Los atacantes lo saben, y por eso invierten recursos en escanear y explotar brechas en estos paneles.

    He visto backdoors instalados en servidores cPanel mediante accesos débiles al WHM (Web Host Manager), cryptominers corriendo con permisos de root, y bases de datos de clientes completas exfiltradas porque nadie había deshabilitado el acceso remoto a MySQL.

    Error 1: Contraseña débil o default en WHM/cPanel

    Parece obvio, pero es el error número uno. Muchos proveedores de hosting entregan servidores con contraseñas generadas automáticamente que nunca se cambian, o peor, con patrones predecibles.

    Lo que ocurre: Los atacantes ejecutan diccionarios contra puertos SSH (22), FTP (21) y WHM (2087/2096). Si tu contraseña es débil o default, el acceso es cuestión de minutos. Una vez dentro, instalan backdoors, webshells o malware de red.

    Cómo detectarlo:

    • Revisa los logs de acceso SSH: cat /var/log/auth.log | grep «Failed password». Si ves intentos fallidos masivos, alguien ya te está buscando.
    • Comprueba los usuarios SSH en tu servidor: awk -F: ‘{print $1}’ /etc/passwd. ¿Hay usuarios que no reconoces?
    • En WHM, accede a Security Center y verifica quién ha accedido recientemente.

    Cómo remediarlo:

    1. Cambia la contraseña root a una de 20+ caracteres: mayúsculas, minúsculas, números y símbolos especiales.
    2. Usa passwd en terminal o genera una contraseña con openssl rand -base64 20.
    3. En WHM, ve a Security Center → Password & Security → Change Root Password.
    4. Documenta la nueva contraseña en un gestor de contraseñas seguro (Bitwarden, 1Password).

    Error 2: SSH abierto a todo el mundo (sin restricción de IP)

    SSH (puerto 22) es la puerta de entrada a tu servidor. Si está abierto a internet sin restricciones, recibirás miles de intentos de acceso cada día desde bots de todo el mundo.

    Lo que ocurre: Incluso con contraseña fuerte, un atacante persistente puede probar millones de combinaciones. Además, pueden explotar vulnerabilidades zero-day en OpenSSH o en herramientas como Exim para ganar acceso.

    Cómo detectarlo:

    • Ejecuta netstat -tlnp | grep ssh o ss -tlnp | grep ssh. ¿SSH escucha en 0.0.0.0:22? Está abierto a todo el mundo.
    • Comprueba el archivo /var/log/auth.log para ataques brute force: grep «sshd» /var/log/auth.log | wc -l.

    Cómo remediarlo:

    1. Cambia el puerto SSH a uno no estándar (ej: 2222): Edita /etc/ssh/sshd_config y cambia Port 22 a Port 2222.
    2. Restringe SSH por IP: Si tienes una IP fija, añade en cPanel/WHM:
      • Ve a Security Center → IP Whitelist Manager
      • Whitelist tu IP corporativa y las de tu proveedor de hosting.
    3. Usa firewalls de host: Instala CSF/LFD (ConfigServer Firewall) para limitar intentos de SSH y bloquear IPs maliciosas automáticamente.
    4. Reinicia SSH: systemctl restart sshd

    Error 3: Acceso remoto a MySQL/bases de datos habilitado

    MySQL, PostgreSQL y otros servicios de base de datos están habilitados por defecto para conexiones locales. El problema: si habilitas acceso remoto (bind-address 0.0.0.0) sin firewall, cualquiera puede intentar conectarse desde internet.

    Lo que ocurre: Los atacantes lanzan exploits contra MySQL (versiones antiguas tienen CVEs críticas). Si entran, acceden a todas las bases de datos: contraseñas WordPress hasheadas, datos de clientes, información de pagos.

    Cómo detectarlo:

    • Conecta por SSH y ejecuta: netstat -tlnp | grep mysql o ss -tlnp | grep mysql
    • Si ves 0.0.0.0:3306, tu MySQL está abierto a internet.
    • Intenta conectar desde fuera del servidor: mysql -h [TU_IP] -u root -p. Si funciona, estás en riesgo.

    Cómo remediarlo:

    1. Edita /etc/mysql/my.cnf o /etc/mysql/mysql.conf.d/mysqld.cnf
    2. Busca bind-address y cambia a bind-address = 127.0.0.1 (solo localhost)
    3. Guarda y reinicia: systemctl restart mysql
    4. En cPanel/Plesk, desactiva Remote MySQL:
      • cPanel: WHM → Security Center → MySQL Remote Access → Disabled
      • Plesk: Tools & Settings → Server Management → MySQL → Remote Access Off
    5. Si necesitas acceso remoto, usa SSH tunneling: ssh -L 3306:localhost:3306 root@tu_servidor

    Error 4: FTP sin cifrar en lugar de SFTP

    FTP transmite credenciales en texto plano. Cualquiera sniffeando la red ve tu usuario y contraseña. SFTP cifra todo el tráfico, pero muchos servidores aún usan FTP o lo tienen habilitado por defecto.

    Lo que ocurre: Un atacante captura tus credenciales FTP, accede a todos los sitios web alojados, inyecta malware, crea backdoors, roba datos.

    Cómo detectarlo:

    • En cPanel/Plesk, comprueba qué servicios están activos: netstat -tlnp | grep -E «ftp|ssh»
    • Si ves puerto 21 (FTP) abierto, estás usando FTP tradicional.

    Cómo remediarlo:

    1. Deshabilita FTP completamente:
      • cPanel: WHM → Service Manager → FTP → Stop & Disable
      • Plesk: Tools & Settings → Server Components → Deselecciona FTP
    2. Usa SFTP (incluido con SSH):
      • Configurado por defecto en cPanel/Plesk. Solo necesitas conectar por SSH con credenciales.
      • Herramientas como FileZilla permiten SFTP fácilmente.
    3. Reinicia: systemctl restart vsftpd (si es necesario)

    Error 5: No actualizar cPanel/Plesk y sus componentes

    cPanel y Plesk lanzan parches de seguridad regularmente. No actualizar es como dejar puertas abiertas con un cartel que dice «aquí hay vulnerabilidades conocidas».

    Lo que ocurre: Atacantes aprovechan CVEs públicos en cPanel, Apache, PHP o Exim. Lanzan exploits masivos contra miles de servidores, sabiendo que muchos no se han parcheado.

    Cómo detectarlo:

    • En WHM, ve a Update Manager o Software Updates. ¿Hay actualizaciones pendientes?
    • Ejecuta uname -a para ver tu versión de kernel. Compara con nvd.nist.gov o cisa.gov para CVEs conocidas.

    Cómo remediarlo:

    1. cPanel: WHM → Update Manager → Update. Elige «Auto Updates» para que se actualice automáticamente.
    2. Plesk: Tools & Settings → Updates → Check for updates → Install.
    3. Actualiza el kernel y servicios del sistema:
      • CentOS/RHEL: yum update -y
      • Debian/Ubuntu: apt update && apt upgrade -y
    4. Reinicia después de actualizaciones del kernel: reboot
    5. Establece un calendario de actualizaciones: la primera semana de cada mes.

    Error 6: Permisos de archivo incorrectos en directorios públicos

    Los permisos UNIX mal configurados permiten que procesos web escriban donde no deberían. Si tu directorio public_html tiene permisos 777, cualquier proceso comprometido puede crear archivos maliciosos.

    Lo que ocurre: Un plugin WordPress vulnerabilizado, una aplicación con RFI/LFI, o un script comprometido escriben webshells, backdoors, malware de minería en tu servidor.

    Cómo detectarlo:

    • Busca directorios con permisos 777 o 666: find /home -type d -perm /700 -user nobody 2>/dev/null | head -20
    • Comprueba permisos de public_html: ls -la /home/usuario/public_html | head. Debería ser 755 para directorios, 644 para archivos.

    Cómo remediarlo:

    1. En cPanel, configura permisos automáticos:
      • WHM → Security Center → Permissions → Set Default File/Directory Permissions
      • Files: 644, Directories: 755
    2. Corrige permisos manuales (si es necesario):
      • find /home/usuario/public_html -type f -exec chmod 644 {} ;
      • find /home/usuario/public_html -type d -exec chmod 755 {} ;
    3. Para WordPress específicamente:
      • wp-config.php: 600 (solo lectura para propietario)
      • .htaccess: 644
      • /wp-content/uploads: 755

    Error 7: No monitorizar logs de seguridad

    Los logs son tu línea de defensa. Si no los revisas regularmente, no sabes que estás siendo atacado hasta que es demasiado tarde.

    Logs críticos que debes monitorizar:

    • /var/log/auth.log – Intentos de login SSH/FTP
    • /var/log/apache2/access.log o /var/log/httpd/access_log – Peticiones HTTP (inyecciones SQL, XSS, exploits web)
    • /var/log/exim_mainlog – Email (spam, phishing)
    • /var/log/cron – Tareas programadas (malware que intenta persistencia)
    • Logs de cPanel/Plesk en /var/log/

    Cómo detectarlo:

    • ¿Últimamente revisaste manualmente tus logs? Si hace más de un mes, estás a ciegas.
    • Busca patrones sospechosos: grep «SQL injection» /var/log/apache2/access.log | wc -l

    Cómo remediarlo:

    1. Instala un monitor de logs automático: CSF/LFD (ConfigServer Firewall) incluye alertas de seguridad.
      • Instala: cd /usr/src && wget https://download.configserver.com/csf.tgz && tar -xzf csf.tgz && cd csf && sh install.sh
      • Configura alertas en /etc/csf/csf.conf
    2. Usa herramientas de SIEM: Fail2Ban, Logwatch, o servicios como Sumologic, Splunk.
    3. Revisa logs semanalmente: Automatiza con script cron que envíe resumen a tu email.
    4. En cPanel/Plesk: Activa alertas por email en Security Center.

    Error 8: Módulos/extensiones de PHP inseguros

    Módulos PHP como suhosin, exec(), system(), o extensiones desactualizadas pueden ser exploitadas para ejecutar comandos arbitrarios en el servidor.

    Lo que ocurre: Un atacante inyecta PHP malicioso (vía plugin vulnerable o upload de archivo), y php.ini permite que se ejecuten comandos del sistema. El atacante crea backdoors, roba archivos, instala malware.

    Cómo detectarlo:

    • Crea un archivo test.php con <?php phpinfo(); ?> y cárgalo en public_html.
    • Busca en la salida:
      • ¿disable_functions está vacío? Problema: todas las funciones están habilitadas.
      • ¿allow_url_fopen está «On»? Riesgo de RFI.
      • ¿magic_quotes_gpc está «Off»? (En PHP 7.x, no existe; en PHP 5.x, debería estar «On»)
    • Lista módulos cargados: php -m o desde WHM/Plesk.

    Cómo remediarlo:

    1. Edita /etc/php.ini (o el archivo de configuración de tu versión de PHP):
      • disable_functions = exec,system,passthru,shell_exec,proc_open,proc_nice,popen,pcntl_exec,eval
      • allow_url_fopen = Off
      • open_basedir = /home/usuario/public_html:/tmp (aísla el acceso a directorios)
    2. En cPanel/Plesk, deshabilita módulos innecesarios desde MultiPHP Manager.
    3. Actualiza PHP a la última versión compatible con tus aplicaciones. No uses versiones EOL (End of Life).
    4. Reinicia Apache/Nginx: systemctl restart apache2 o systemctl restart nginx

    Error 9: Firewall desactivado o mal configurado

    El firewall del servidor (iptables/nftables en Linux, o CSF/LFD en cPanel) es tu barrera contra ataques de red. Muchos administradores lo desactivan «temporalmente» y nunca lo vuelven a activar.

    Lo que ocurre: Cualquier puerto está abierto a internet. Atacantes escanean tu servidor, descubren servicios vulnerables, y explotan.

    Cómo detectarlo:

    • Comprueba si el firewall está activo: systemctl status firewalld o systemctl status ufw o csf -l (para CSF)
    • Lista puertos abiertos: netstat -tlnp o ss -tlnp. ¿Ves servicios innecesarios?

    Cómo remediarlo:

    1. Activa el firewall:
      • systemctl enable firewalld && systemctl start firewalld (Firewalld)
      • systemctl enable ufw && ufw enable (UFW)
      • csf -e (ConfigServer Firewall)
    2. Configura reglas estrictas:
      • Abre solo puertos necesarios: 22 (SSH), 80 (HTTP), 443 (HTTPS), 25/587 (SMTP si es servidor de correo).
      • En cPanel: WHM → Security Center → Firewall Configuration → Add Firewall Whitelist Rules
    3. CSF/LFD es recomendable: Incluye protección contra ataques brute force, DDoS, y tiene listas negras actualizadas.

    Error 10: No realizar auditorías de seguridad periódicas

    Una auditoría de seguridad no es un lujo: es mantenimiento preventivo. Cada 3-6 meses, deberías escanear tu servidor buscando malware, configuraciones débiles y vulnerabilidades.

    Lo que ocurre: Los problemas se acumulan silenciosamente. Un plugin desactualizado aquí, una contraseña débil allá, permisos incorrectos en algún otro lado. De repente, descubres que tu servidor está comprometido desde hace meses.

    Cómo detectarlo:

    • ¿Cuándo fue la última vez que ejecutaste un scan de malware en tu servidor?
    • ¿Tienes un registro de cambios en tu configuración de seguridad?
    • ¿Revisaste recientemente qué usuarios tienen acceso root/SSH?

    Cómo remediarlo:

    1. Herramientas de escaneo automático:
      • Maldet (Linux Malware Detect): maldet -a /home para escanear archivos
      • ClamAV: Antivirus de código abierto. freshclam actualiza firmas, clamscan -r /home escanea.
      • Rootkit Hunter (rkhunter): Busca backdoors y rootkits. rkhunter –check
    2. Auditoría manual:
      • Revisa usuarios con acceso root: grep «:0:0:» /etc/passwd
      • Busca cambios recientes en archivos del sistema: find /etc -mtime -7 (últimos 7 días)
      • Revisa tareas cron sospechosas: cat /var/spool/cron/crontabs/*
    3. Cada mes: Ejecuta al menos un escaneo de malware.
    4. Cada trimestre: Auditoría de permisos de archivos, usuarios, y configuración de servicios.

    Plan de acción rápido: Checklist de seguridad cPanel/Plesk

    Si acabas de leer esto y tienes miedo de tu servidor, aquí está la lista de acciones inmediatas (prioritarias):

    1. HOY: Cambia contraseña root a una fuerte (20+ caracteres).
    2. HOY: Comprueba logs SSH (/var/log/auth.log) buscando accesos desconocidos.
    3. HOY: Deshabilita FTP, habilita solo SFTP.
    4. ESTA SEMANA: Cambia puerto SSH a uno no estándar y restringe por IP.
    5. ESTA SEMANA: Desactiva acceso remoto a MySQL. Bind-address a 127.0.0.1.
    6. ESTA SEMANA: Activa firewall (CSF/LFD es ideal en cPanel).
    7. ESTE MES: Actualiza cPanel/Plesk y todos sus componentes.
    8. ESTE MES: Escanea servidor con Maldet, ClamAV, y rkhunter.
    9. ESTE MES: Configura monitorización de logs automática (CSF/LFD o Fail2Ban).
    10. CADA TRIMESTRE: Auditoría de seguridad completa.

    Cuándo llamar a un experto: señales de alerta

    Si detectas cualquiera de esto, tu servidor probablemente esté comprometido:

    • Cientos de intentos fallidos de login en los logs.
    • Procesos desconocidos ejecutándose (ej: minero, bot de spam).
    • Archivos nuevos que no creaste en public_html o /tmp.
    • Tu servidor enviando spam o malware a otros sitios (ISP te avisa).
    • Rendimiento muy bajo sin razón aparente (CPU/RAM al máximo).
    • Cambios en archivos de sistema que no autorizaste.
    • Google Search Console reporta malware en tu sitio.

    En estos casos, no intentes «limpiar» tú solo. Un error puede empeorar las cosas o dejar puertas traseras abiertas. Lo recomendable es contactar con un especialista en ciberseguridad que pueda:

    • Analizar logs forenses para determinar cómo entró el atacante.
    • Identificar y eliminar todo el malware sin dejar rastros.
    • Cerrar la vulnerabilidad explotada.
    • Recuperar tus datos si han sido robados.
    • Aplicar hardening completo para evitar que vuelva a ocurrir.

    En ManuelFolgar.com, nos especializamos en limpieza de malware, auditorías de seguridad y hardening de servidores cPanel/Plesk. Si tu servidor ha sido comprometido o quieres blindarlo antes de que lo sea, contacta con nosotros para una auditoría de seguridad profesional. Analizo tu infraestructura completa, identifico riesgos y aplico soluciones probadas.

    La seguridad del servidor no es una tarea de una vez: es un proceso continuo. Pero si empiezas con estos diez errores evitados, habrás cerrado la mayoría de puertas por las que entra el malware. Tu servidor, y los datos de tus clientes, te lo agradecerán.