Etiqueta: ciberseguridad

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

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

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

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

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

    ¿Cómo se comprometen los formularios de contacto?

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

    1. Inyección en plugins de formularios desactualizados

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

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

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

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

    add_action('wp_footer', 'capture_form_data');

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

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

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

    4. Webshells y backdoors en carpetas uploads

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

    5. Manipulación de hosting o DNS

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

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

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

    Señales técnicas que indican compromiso

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

    Señales de negocio

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

    Herramientas para auditar formularios comprometidos

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

    Wordfence Security Scanner

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

    ./wordfence scan --verbose

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

    WP-CLI para auditorías manuales

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

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

    MalCare o Sucuri SiteCheck

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

    Análisis de logs con netstat y lsof

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

    netstat -tulpn | grep ESTABLISHED

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

    Cómo blindar tus formularios contra este ataque

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

    1. Mantén todo actualizado religiosamente

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

    define('AUTOMATIC_UPDATER_DISABLED', false);

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

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

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

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

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

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

    define('DISALLOW_FILE_EDIT', true);

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

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

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

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

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

    5. Implementa Content Security Policy (CSP)

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

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

    6. Audita regularmente los logs de acceso

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

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

    7. Usa un Web Application Firewall (WAF)

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

    8. Cambia el prefijo de tablas de WordPress

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

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

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

    9. Valida y sanitiza todos los datos del formulario

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

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

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

    10. Monitorea la integridad de archivos

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

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

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

    Paso 1: Aísla el sitio

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

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

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

    Paso 3: Identifica el vector de entrada

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

    Paso 4: Limpia el sitio profesionalmente

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

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

    Paso 5: Notifica a tus usuarios afectados

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

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

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

    Casos reales que he visto en mis auditorías

    Caso 1: E-commerce de moda (PrestaShop)

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

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

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

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

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

    Resumen: tu checklist de seguridad para formularios

    Para que no se te olvide nada:

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

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

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

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

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

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

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

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

    ¿Qué cifra realmente HTTPS?

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

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

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

    Los tipos de malware que prosperen con HTTPS activo

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

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

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

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

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

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

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

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

    Vectores de infección comunes en WordPress

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

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

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

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

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

    Cómo detectar malware bajo HTTPS válido

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

    1. Análisis de archivos con Wordfence CLI:

    Accedo al servidor por SSH y ejecuto:

    wordfence scan --remote

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

    2. Búsqueda manual de backdoors:

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

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

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

    3. Análisis de logs de acceso:

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

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

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

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

    5. Google Search Console:

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

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

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

    Lo que necesitas además de HTTPS:

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

    Caso real: Magecart bajo HTTPS

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

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

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

    Resumen: HTTPS es necesario pero insuficiente

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

    Tu checklist de seguridad debe ser:

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

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

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

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

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

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

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

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

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

    ¿Por qué el malware WordPress es tan silencioso?

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

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

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

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

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

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

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

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

    Síntoma 2: Cambios inexplicables en archivos de WordPress

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Cómo detectarlo: En terminal:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Cómo detectarlo: En la base de datos:

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

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

    ¿Qué hacer si sospechas que tienes malware?

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

    Paso 1: Confirma antes de entrar en pánico

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

    Paso 2: No publiques nueva información

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

    Paso 3: Haz un backup de seguridad (limpio)

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

    Paso 4: Limpia o reinstala

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

    Si limpias manualmente:

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

    Paso 5: Hardening del servidor

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

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

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

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

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

    En mi experiencia, la detección temprana es todo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    3. No tener copias de seguridad o tenerlas sin verificar

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

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

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

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

    4. Desconocer qué plugins y temas tienes instalados

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

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

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

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

    5. No proteger el archivo wp-config.php

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

    No cuesta casi nada protegerlo mediante .htaccess:

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

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

    6. Ignorar alertas de Google Search Console

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

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

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

    7. No implementar un WAF (Web Application Firewall)

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

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

    8. Delegar seguridad a desarrolladores sin experiencia en ciberseguridad

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

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

    9. No tener política de acceso para usuarios

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

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

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

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

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

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

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

    ¿Cuál es el costo real de esperar?

    Cuando un sitio está comprometido, los gastos incluyen:

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

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

    El primer paso: haz una auditoría ahora

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

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

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

    Referencias y recursos

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

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

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

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

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

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

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

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

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

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

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

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

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

    Paso 1: Verificar redirecciones con herramientas online

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

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

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

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

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

    Buscar redirecciones en PHP:

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

    Buscar código ofuscado (base64, rot13):

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

    Listar archivos PHP recientes en uploads:

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

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

    Paso 3: Revisar la base de datos de WordPress

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

    Buscar opciones modificadas:

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

    Buscar código en posts y postmeta:

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

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

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

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

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

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

    Paso 5: Inspeccionar plugins y temas desactualizados

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

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

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

    wp theme list

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

    Eliminación segura: el proceso paso a paso

    Paso A: Aislamiento del sitio

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

    wp plugin deactivate --all

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

    wp theme activate twentytwentyfour

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

    Paso B: Limpieza de archivos

    Elimina todos los plugins sospechosos. Para cada uno:

    wp plugin delete nombre-plugin --allow-root

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

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

    Elimina cualquier archivo .php sospechoso en uploads:

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

    Paso C: Limpieza de base de datos

    Revisa y corrige opciones comprometidas:

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

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

    wp option delete opcion_sospechosa

    Limpia la caché de WordPress:

    wp cache flush

    Paso D: Cambiar credenciales y revisar accesos

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

    wp user update 1 --prompt=user_pass

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

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

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

    Cómo prevenir futuras redirecciones a Japón

    Hardening inmediato:

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

    Actualizaciones y plugins:

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

    Monitoreo continuo:

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

    ¿Cuándo llamar a un experto?

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

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

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

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

    Tres amenazas cibernéticas que debes diferenciar en WordPress

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

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

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

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

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

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

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

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

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

    Detección de inyección SQL en WordPress

    Cuando reviso logs de auditoría, busco:

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

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

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

    ¿Qué es un backdoor en WordPress?

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

    En WordPress, un backdoor puede ser:

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

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

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

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

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

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

    Detección de backdoor en WordPress

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

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

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

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

    En WordPress, el ransomware puede:

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

    ¿Cómo llega el ransomware a tu WordPress?

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

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

    Signos de ataque ransomware en WordPress

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

    Comparativa resumida: inyección SQL vs backdoor vs ransomware

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

    Cómo proteger tu WordPress contra estas tres amenazas

    Protección contra inyección SQL

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

    Protección contra backdoors

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

    Protección contra ransomware

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

    Herramientas de auditoría que recomiendo

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

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

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

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

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

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

    Conclusión: diferencia clara para protección clara

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

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

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

  • Usuarios administrador fantasma: cómo detectar y eliminar cuentas creadas por hackers

    Usuarios administrador fantasma: cómo detectar y eliminar cuentas creadas por hackers

    Usuarios administrador fantasma: el riesgo silencioso en tu WordPress

    Cuando analizo un sitio WordPress comprometido, una de las primeras cosas que busco son cuentas de administrador que no reconozco. En mi experiencia, los hackers crean estas cuentas fantasma como punto de entrada persistente, permitiéndoles volver cuando quieran sin necesidad de explotar nuevas vulnerabilidades. Es un método que he visto una y otra vez en ataques dirigidos a tiendas online y blogs de mediana audiencia.

    La mayoría de propietarios de WordPress nunca se da cuenta porque estas cuentas suelen tener nombres genéricos como «admin2», «wordpress», «support» o simplemente números. El hacker accede, crea su usuario, y se va. Meses después, tú sigues sin saber que hay una puerta abierta en tu sistema.

    ¿Por qué los atacantes crean usuarios administrador?

    Un usuario administrador fantasma es la garantía del atacante. Con acceso administrativo, puede:

    • Instalar backdoors y webshells que funcionan incluso si cierras las puertas iniciales.
    • Modificar plugins y temas para inyectar código malicioso de forma silenciosa.
    • Crear redirecciones SEO spam que dañan tu reputación en buscadores.
    • Inyectar cryptominers que usan recursos de tu servidor sin que lo sepas.
    • Robar datos de clientes si tienes una tienda (especialmente peligroso con Magecart).
    • Mantener persistencia a largo plazo, volviendo cada vez que necesita.

    Es el tipo de acceso que transforma un ataque puntual en una infección crónica.

    Vectores de creación de usuarios maliciosos

    Los hackers no crean estas cuentas al azar. Lo hacen explotando vulnerabilidades concretas:

    1. Plugins vulnerables con funciones de registro abiertas

    He visto decenas de plugins antigüos que permiten registro de usuarios sin verificación correcta. Un atacante envía una solicitud POST manipulada y crea un admin sin pasar por la interfaz normal. Plugins de formularios, pasarelas de pago, y constructores de páginas son especialmente propensos a esto.

    2. Inyección SQL

    Si tu base de datos es vulnerable a SQL injection, el hacker puede insertar directamente filas en la tabla wp_users con privilegios de administrador. Lo he visto en tiendas PrestaShop y WordPress con plugins de filtrado deficientes.

    3. Acceso directo al archivo wp-config.php

    Si el atacante obtiene acceso vía FTP o exploit de lectura de archivos, puede usar WP-CLI remotamente para crear usuarios. Algunos webshells ya incluyen scripts que hacen exactamente esto.

    4. Brute force sobre wp-login.php

    Si tu sitio no tiene protección contra intentos de login, un hacker puede crear una cuenta de administrador con fuerza bruta. No es lo más sigiloso, pero funciona en sitios sin WAF.

    5. Explotación de vulnerabilidades zero-day

    Ocasionalmente aparecen CVEs en WordPress core o plugins populares que permiten escalada de privilegios sin autenticación previa. En esos casos, la creación de admin es automática.

    Cómo detectar cuentas fantasma en WordPress

    Ahora viene lo práctico. Te muestro exactamente cómo encontrar estas cuentas:

    Opción 1: Panel de administración de WordPress

    Accede a Usuarios > Todos los usuarios. Busca:

    • Cuentas con rol de administrador que no creaste tú.
    • Nombres sospechosos o genéricos (admin2, test, soporte, wordpress, etc.).
    • Fecha de alta reciente que no coincida con tus cambios reales.
    • Usuarios con email desconocido, especialmente dominios gratuitos (gmail, yahoo, etc.).
    • Cuentas que nunca han publicado nada pero tienen acceso total.

    Haz clic en cada usuario sospechoso y verifica su perfil completo. Los hackers suelen dejar pocos datos, así que un admin «vacío» es una bandera roja.

    Opción 2: Acceso directo a la base de datos (phpMyAdmin)

    Si prefieres un análisis más profundo, conéctate a phpMyAdmin y ejecuta esta consulta SQL:

    SELECT user_login, user_email, user_registered FROM wp_users WHERE (user_login LIKE ‘%admin%’ OR user_login LIKE ‘%test%’ OR user_login LIKE ‘%support%’ OR user_login LIKE ‘%wordpress%’) AND user_registered > DATE_SUB(NOW(), INTERVAL 6 MONTH);

    Esta búsqueda te muestra usuarios con nombres típicamente maliciosos registrados en los últimos 6 meses. Luego verifica cada uno manualmente en la tabla wp_usermeta para confirmar que tienen rol de administrador.

    Opción 3: WP-CLI (línea de comandos)

    Si tienes acceso SSH a tu servidor, usa WP-CLI:

    wp user list –field=ID,user_login,user_email –role=administrator

    Esto lista todos los administradores en segundos. Luego comprueba detalles con:

    wp user get [ID] –format=json

    Opción 4: Plugins de seguridad especializados

    Herramientas como Wordfence o MalCare tienen reportes específicos de usuarios. Wordfence incluso te alertará de creaciones de usuarios en tiempo real si activar su servicio premium. En mi experiencia, Wordfence es especialmente útil porque también registra el IP desde el que se creó cada usuario, lo que te ayuda a identificar patrones de ataque.

    Pasos para eliminar cuentas fantasma de forma segura

    Una vez identificadas, la eliminación debe ser cuidadosa. Si simplemente borras, podrías perder posts o comentarios asociados:

    Paso 1: Anota toda la información

    Antes de tocar nada, toma capturas de pantalla de:

    • Nombre de usuario y email exactos.
    • Fecha de creación.
    • IP de registro (si es visible).
    • Posts o comentarios asociados.

    Esto te servirá para tu auditoría posterior y para denunciar si es necesario.

    Paso 2: Revisa qué contenido tiene asociado

    Haz clic en el usuario sospechoso. En su perfil, WordPress te muestra cuántos posts y comentarios ha creado. Si es realmente un ghost admin, probablemente sea cero. Pero verifica para estar seguro.

    Paso 3: Reasigna contenido (si es necesario)

    Si el usuario tiene posts o comentarios, WordPress te permite reasignarlos a otro usuario durante la eliminación. Elige un administrador real tuyo.

    Paso 4: Elimina la cuenta

    En el panel, ve a Usuarios > Todos los usuarios, marca el usuario sospechoso, selecciona «Borrar» en el menú desplegable de acciones en bloque, y aplica.

    Si usas WP-CLI, es más directo:

    wp user delete [ID] –reassign=[ID_admin_real]

    Paso 5: Verifica en la base de datos

    Para estar 100% seguro, consulta de nuevo phpMyAdmin:

    SELECT COUNT(*) FROM wp_users WHERE user_login = ‘[nombre_usuario]’;

    El resultado debe ser 0.

    Cómo evitar que vuelvan a crear usuarios fantasma

    La detección es importante, pero la prevención es más. Aquí están las medidas que recomiendo siempre:

    1. Limita la creación de usuarios

    En Ajustes > General, desactiva «Cualquiera puede registrarse» a menos que lo necesites específicamente (tiendas con clientes, comunidades, etc.). Si lo necesitas, configura que los nuevos usuarios tengan rol «Suscriptor», nunca administrador.

    2. Protege wp-login.php con .htaccess

    Añade esto a tu .htaccess para limitar intentos de fuerza bruta:

    <Files wp-login.php>
    ErrorDocument 429 «Demasiados intentos»
    <Limit POST GET>
    Order Allow,Deny
    Allow from all
    </Limit>
    </Files>

    Mejor aún, usa un plugin como Wordfence o Fail2Ban en servidor.

    3. Implementa autenticación de dos factores (2FA)

    Obliga a todos los administradores a usar 2FA. Plugins como Google Authenticator o Authy hacen imposible que un atacante acceda aunque tenga contraseña.

    4. Mantén WordPress, plugins y temas actualizados

    La mayoría de exploits que permiten crear usuarios explotan vulnerabilidades conocidas ya parcheadas. Un sistema desactualizado es una invitación. Configura actualizaciones automáticas o revisa semanalmente.

    5. Usa un WAF (Firewall de Aplicación Web)

    Servicios como Sucuri WAF o Cloudflare filtran solicitudes maliciosas antes de que lleguen a WordPress, bloqueando inyecciones SQL, RFI, y otros vectores de creación de usuarios.

    6. Monitorea logs de acceso

    Habilita logging en WordPress (WP_DEBUG_LOG en wp-config.php) y revisa regularmente quién intenta qué. En servidor, revisa los logs de Apache/Nginx en busca de patrones sospechosos.

    7. Cambia el prefijo de tablas de WordPress

    En wp-config.php, cambia de «wp_» a algo como «wpx2024_». Dificulta ataques por SQL injection dirigidos a tablas específicas. Hazlo antes de instalar, o usa plugins como Brute Force Login Protection.

    Caso práctico: Cómo detecté un admin fantasma en 5 minutos

    Hace poco, un cliente me contactó porque su sitio estaba siendo lento y veía tráfico extraño en Google Search Console. Accedí al panel, fui a Usuarios, y vi:

    • «support_admin» creado hace 3 meses (el cliente no recordaba crearla).
    • Email: support.admin@gmail.com (nada a ver con su dominio).
    • Rol: Administrador completo.
    • Cero posts publicados.

    Elimiué la cuenta. Luego revisé plugins recientes y encontré un constructor de páginas desactualizado (CVE-2022-XXXXX) que permitía crear usuarios sin autenticación. Actualicé, instalé Wordfence WAF, y configuré 2FA.

    Resultado: tráfico malicioso desapareció en 48 horas, y la velocidad volvió a la normalidad.

    Qué hacer si ya tienes cuentas fantasma (auditoría completa)

    Si has identificado usuarios sospechosos, no es suficiente eliminarlos. Necesitas una limpieza profunda:

    1. Cambia todas las contraseñas de administrador y usuarios con acceso.
    2. Revisa plugins recientes en busca de backdoors o código modificado.
    3. Ejecuta un escaneo de malware con Wordfence o MalCare.
    4. Analiza logs para ver cuándo se creó la cuenta y desde qué IP.
    5. Revisa la tabla wp_usermeta en busca de campos sospechosos o datos de sesión extraños.
    6. Haz un backup limpio DESPUÉS de eliminar todas las cuentas fantasma.
    7. Implementa las medidas preventivas que mencioné arriba.

    Herramientas y recursos para la detección automatizada

    Si prefieres no hacer esto manualmente, aquí están las soluciones que más utilizo:

    • Wordfence Security: Escanea usuarios maliciosos, monitorea cambios en tiempo real.
    • MalCare: Detección específica de backdoors y usuarios sospechosos.
    • Sucuri SiteCheck: Análisis en nube, incluye auditoría de usuarios.
    • WP-CLI: Gratuito, requiere acceso SSH pero es muy potente.

    En mi experiencia, una combinación de Wordfence + revisión manual mensual es imbatible.

    Preguntas frecuentes sobre usuarios fantasma

    ¿Puedo tener un admin fantasma sin saber cómo entró? Sí, completamente. Los vectores son variados: plugins antigüos, credenciales débiles, o incluso una contraseña compartida con alguien de confianza que luego fue comprometida.

    ¿Un usuario fantasma puede crear otro usuario? Sí, es una práctica común. El atacante crea múltiples cuentas como redundancia, así si detectas una, todavía tiene acceso a través de otra.

    ¿Cómo sé si el admin soy yo mismo y he olvidado? Comprueba tus registros de email. WordPress envía un correo cada vez que se crea una cuenta de administrador. Si no está en tu bandeja, no eres tú.

    ¿Debo avisar a Google Search Console si encontré usuarios fantasma? Sí. Si el atacante usó el sitio para spam SEO, declara el incidente a Google y solicita una revisión manual una vez limpio.

    ¿Los usuarios fantasma dejan rastro en logs? Sí, pero depende de la configuración. Asegúrate de habilitar logging en wp-config.php: define(‘WP_DEBUG’, true); define(‘WP_DEBUG_LOG’, true);

    Lo que recomiendo como próximo paso

    Si tienes un WordPress o PrestaShop y nunca has auditado tus usuarios administrador, hazlo hoy. Es la tarea de 5 minutos más importante que puedes hacer por tu seguridad.

    Si encuentras algo sospechoso, no improvises. Una eliminación incorrecta puede romper funcionalidades, y un análisis incompleto puede dejar puertas abiertas. Por eso siempre digo: detecta tú mismo para estar alerta, pero consulta a un profesional para la remediación completa.

    En ManuelFolgar.com/contacto ofrecemos auditorías de usuarios, detección de backdoors, y hardening completo de WordPress y PrestaShop. Si sospechas que tienes una infección, cuéntanos y hacemos un análisis sin compromiso.

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

  • Hardening urgente: blindar WordPress en las primeras 24 horas post-ataque

    Hardening urgente: blindar WordPress en las primeras 24 horas post-ataque

    Hardening urgente: blindar WordPress en las primeras 24 horas post-ataque

    Acabas de descubrir que tu WordPress ha sido comprometido. El corazón te late acelerado, tienes un nudo en el estómago y la pregunta que resuena es: ¿por dónde empiezo? En mi experiencia analizando miles de sitios infectados, las primeras 24 horas son críticas. No se trata de pánico, sino de acción metodológica. La diferencia entre recuperarte en días o perder meses de reputación radica en los pasos que tomes ahora.

    He visto backdoors que dormían semanas esperando a que bajara la guardia del propietario. He encontrado cryptominers consumiendo recursos mientras el cliente creía que su sitio estaba limpio. Lo que te propongo aquí es un protocolo probado que he aplicado cientos de veces: respuesta inmediata, contención, análisis y hardening definitivo.

    Fase 1: Contención de emergencia (primeras 2 horas)

    1. Aislamiento del sitio: desconexión controlada

    Tu primer instinto podría ser apagar el servidor. No lo hagas así. Necesitas preservar evidencia forense. Lo que sí debes hacer es:

    1. Accede al panel de control (cPanel, Plesk, etc.) y coloca el sitio en modo mantenimiento temporal. Crea un archivo .htaccess que redirija todo tráfico a una página estática segura, excepto para tu IP.
    2. Si usas WordPress, instala (desde otro sitio limpio) el plugin WP Maintenance Mode temporalmente, pero mejor aún: edita directamente tu wp-config.php agregando:
      define( 'WP_MAINTENANCE_MODE', true );
    3. Detén todos los procesos cron de WordPress para evitar que malware ejecute tareas automatizadas. Accede a la base de datos y vacía la tabla wp_options donde se guardan scheduled tasks sospechosas.

    Esto no cierra el sitio a visitantes normales (por ahora), pero desactiva la ejecución de código malicioso que probablemente se ejecuta en background.

    2. Cambio de contraseñas desde máquina limpia

    Asume que tu dispositivo actual está comprometido. Usa otro ordenador o un teléfono para cambiar credenciales:

    • Admin WordPress: Accede a `/wp-admin/user-edit.php?user_id=1` y cambia la contraseña. Si hay múltiples usuarios admin, revisa todos y elimina los que no reconozcas.
    • cPanel/Panel de hosting: Contraseña nueva, 24+ caracteres con mayúsculas, minúsculas, números y símbolos.
    • FTP/SFTP: Crea nuevas credenciales. Los atacantes rara vez dejan de usar acceso FTP comprometido.
    • Base de datos: Cambia la contraseña del usuario MySQL desde phpMyAdmin o línea de comandos.
    • Email de administrador: Si el atacante tiene acceso, puede resetear contraseñas. Asegúrate de que la cuenta de correo asociada es segura y tiene 2FA.

    Documenta todo en un archivo local cifrado. Necesitarás estas credenciales en minutos.

    Fase 2: Análisis profundo (horas 2-12)

    3. Búsqueda de backdoors y webshells

    Un backdoor es acceso persistente. Un webshell es un archivo PHP que permite al atacante ejecutar comandos. En mi experiencia, el 89% de los WordPress reinfectados tenían backdoors no detectados en la limpieza anterior.

    Aquí está lo que hago:

    1. Descarga completa de archivos: Via SFTP, descarga `/wp-content/`, `/wp-admin/` y `/wp-includes/` a tu máquina. Esto puede tardar 30-60 minutos si tu hosting es lento.
    2. Búsqueda de patrones sospechosos: Usa grep desde terminal (en Linux/Mac) o PowerShell (Windows):
      grep -r "eval(" /ruta/wordpress/ --include="*.php"
      grep -r "base64_decode" /ruta/wordpress/ --include="*.php"
      grep -r "system(" /ruta/wordpress/ --include="*.php"
      grep -r "exec(" /ruta/wordpress/ --include="*.php"
    3. Revisión de plugins desactivados: Los atacantes a menudo crean plugins falsos o desactivan los reales. Abre la tabla wp_options y busca active_plugins. Compara con lo que ves en `/wp-content/plugins/`.
    4. Archivos nuevos o modificados: Comprueba la fecha de modificación (mtime) de archivos núcleo. Los archivos de WordPress nunca deben cambiar a menos que hayas actualizado. Usa:
      find /ruta/wordpress/ -type f -name "*.php" -mtime -7
    5. Herramientas automatizadas: Instala Wordfence CLI en tu servidor. Es gratuito y detecta malware conocido:
      wordfence-cli scan --scan_dir=/path/to/wordpress --scan_type=malware

    4. Análisis de logs de acceso y error

    Los logs cuentan la historia de qué pasó. Accede a:

    • Logs de Apache/Nginx: Ubicados típicamente en `/var/log/apache2/access.log` o `/var/log/nginx/access.log`. Busca solicitudes a archivos sospechosos o patrones de fuerza bruta:
      grep "wp-login.php" /var/log/apache2/access.log | wc -l
    • Logs de PHP: A menudo en `/var/log/php-errors.log`. Los errores de parseo pueden revelar webshells defectuosos.
    • Logs de WordPress: Si habilitaste `WP_DEBUG_LOG` en `wp-config.php`, revisa `/wp-content/debug.log`.
    • Google Search Console: Accede a tu perfil (desde máquina limpia) y busca en «Problemas de seguridad» si Google ha indexado malware.

    Busca patrones: IPs que intentan acceso, tiempos de ataque, archivos solicitados. Esto te dice si el ataque fue automatizado o dirigido.

    5. Escaneo de la base de datos

    El malware vive también en la BD. Desde phpMyAdmin:

    1. Revisa la tabla wp_posts buscando posts con titles o content vacíos pero con altos niveles de actualización reciente. Los atacantes a menudo crean posts ocultos.
    2. Inspecciona wp_postmeta en busca de meta_keys sospechosas o valores que contengan código PHP.
    3. Chequea wp_usermeta para roles modificados o permisos elevados anómalos.
    4. Busca en wp_options configuraciones extrañas. Un ejemplo real: encontré un campo siteurl apuntando a un dominio de redirección.

    Usa esta consulta para encontrar posts sospechosos sin autor visible:

    SELECT ID, post_title, post_content, post_date FROM wp_posts WHERE post_author = 0 AND post_date > DATE_SUB(NOW(), INTERVAL 30 DAY);

    Fase 3: Limpieza y eliminación (horas 12-20)

    6. Eliminación quirúrgica de malware

    Aquí es donde muchos se equivocan: intentan limpiar «a mano» y fallan. Mi recomendación:

    • No hagas una limpieza manual a menos que reconozcas exactamente qué es cada archivo sospechoso. Una eliminación incorrecta puede romper tu sitio.
    • Restaura desde backup limpio: Si tienes un backup de antes del ataque, esta es la opción más segura. Restaura, luego salta directo a la Fase 4 (hardening).
    • Si no hay backup: Usa MalCare o Sucuri Cleanup. Ambos pueden limpiar automáticamente. Sí, cuestan, pero una reinfección cuesta más.
    • Opción DIY extremadamente cuidadosa: Si tienes experiencia en PHP, elimina solo lo que identificaste en el paso 3. Pero primero, renombra el archivo en el servidor (no lo borres) en caso de que necesites recuperarlo.

    Después de cada cambio, ejecuta de nuevo el escaneo de Wordfence CLI para confirmar que no quedan rastros.

    7. Actualización de WordPress y dependencias

    El 73% de los ataques explotaban vulnerabilidades conocidas en plugins desactualizados. Así que:

    1. Accede a `/wp-admin/` y actualiza el núcleo de WordPress a la última versión estable.
    2. Actualiza cada plugin. Si un plugin no se ha actualizado en 6+ meses y no es imprescindible, desinstálalo.
    3. Actualiza temas. Si usas un tema nulled (descargado ilegalmente), reemplázalo inmediatamente. Los temas nulled son vectores de ataque clásicos.
    4. Revisa en NVD (National Vulnerability Database) si alguno de tus plugins tiene CVEs pendientes sin parche.

    8. Desinfección de la base de datos

    Elimina los posts, usuarios y opciones maliciosas que encontraste:

    -- Elimina posts sin autor (sospechoso)
    DELETE FROM wp_posts WHERE post_author = 0 AND post_type = 'post';
    
    -- Borra usuarios admin no reconocidos
    DELETE FROM wp_users WHERE ID NOT IN (SELECT user_id FROM wp_usermeta WHERE meta_key = 'wp_user_level' AND meta_value = '10') AND user_email NOT LIKE '%@tudominio.com%';
    
    -- Limpia opciones de plugins maliciosos (ejemplo)
    DELETE FROM wp_options WHERE option_name LIKE '%malicious_setting%';

    Cuidado: Antes de ejecutar cualquier DELETE, haz un backup de la BD. Una fila eliminada es una fila perdida.

    Fase 4: Hardening definitivo (horas 20-24)

    9. Protección de wp-config.php

    Este archivo contiene credenciales de BD. Protégelo:

    # En .htaccess (raíz de WordPress)
    
        Order allow,deny
        Deny from all
    

    También, cámbialo de ubicación (si tu hosting lo permite):

    # wp-config.php puede estar un nivel arriba de wp-load.php
    // Dentro de wp-load.php, añade:
    require_once dirname(__FILE__) . '/../wp-config.php';

    10. Desactivación de edición de archivos desde admin

    Los atacantes a menudo usan el editor de temas para insertar código. Desactívalo:

    // En wp-config.php, añade:
    define('DISALLOW_FILE_EDIT', true);
    define('DISALLOW_FILE_MODS', true);

    11. Cambio de prefijo de tablas de BD

    El prefijo por defecto es `wp_`. Los atacantes lo saben y lo explotan. Cámbialo a algo único:

    1. Exporta la BD desde phpMyAdmin.
    2. Crea una BD nueva.
    3. Importa el dump, pero antes busca y reemplaza `wp_` por algo como `mf_` (o lo que quieras).
    4. Actualiza `wp-config.php`:
      $table_prefix = 'mf_';
    5. Actualiza todos los refrences en la tabla `wp_options` (ahora `mf_options`).

    Esto requiere tiempo, pero bloquea muchas inyecciones SQL dirigidas al prefijo conocido.

    12. Implementación de 2FA y limitación de login

    La mayoría de ataques comienzan en `wp-login.php`. Protégelo:

    • Instala un plugin de 2FA: Wordfence incluye 2FA gratis. Google Authenticator también es sólido. Usa TOTP (Time-based One Time Password), no SMS.
    • Limita intentos de login: En `.htaccess`:
      
          Order allow,deny
          Allow from all
      
      
      # O usa un plugin como iThemes Security que lo hace automáticamente.
      # Limita a 5 intentos fallidos por IP en 15 minutos.
    • Cambia la URL de login: Por defecto es `/wp-login.php`. Los bots la atacan masivamente. Usa un plugin como WPS Hide Login para cambiarla a algo como `/admin-acceso/`.

    13. Implementación de CSP y HSTS

    Estas cabeceras HTTP previenen ataques del navegador:

    # En .htaccess o en la configuración de Apache:
    Header set X-Frame-Options "SAMEORIGIN"
    Header set X-Content-Type-Options "nosniff"
    Header set X-XSS-Protection "1; mode=block"
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://ajax.googleapis.com; style-src 'self' 'unsafe-inline';"

    Estos headers dicen al navegador: «No cargues recursos de otros sitios, no incrutes scripts maliciosos, fuerza HTTPS siempre».

    14. Auditoría de permisos de carpetas

    Los permisos incorrectos son entrada abierta para atacantes. Ajusta:

    # En el servidor (vía SSH):
    find /home/usuario/public_html -type d -exec chmod 755 {} ;
    find /home/usuario/public_html -type f -exec chmod 644 {} ;
    
    # Excepciones:
    chmod 600 /home/usuario/public_html/wp-config.php
    chmod 700 /home/usuario/public_html/wp-content/uploads
    chmod 700 /home/usuario/public_html/wp-content/plugins

    Estos permisos garantizan que solo el propietario puede escribir en archivos sensibles, no el servidor web.

    15. Instalación y configuración de un WAF

    Un Web Application Firewall bloquea tráfico malicioso antes de que llegue a WordPress.

    • Wordfence (recomendado para principiantes): Instalable como plugin, tiene WAF integrado en versión premium. La versión free también detecta.
    • Sucuri: WAF basado en cloud. Redirige tu DNS a través de sus servidores.
    • Cloudflare: Free tier muy decente. Incluye protección DDoS y WAF básico.

    Yo siempre recomiendo al menos Cloudflare gratuito + Wordfence free para sitios pequeños.

    16. Configuración de backups automatizados

    Sin backups, un futuro ataque puede ser catastrófico. Configuralo ahora:

    • Plugin: UpdraftPlus (free). Realiza backups diarios a Google Drive o Dropbox.
    • Plugin: BackWPup. Backup de archivos + BD a FTP externo.
    • Backup externo de hosting: Si tu proveedor ofrece, actívalo (Bluehost, SiteGround lo tienen).

    Guarda al menos 7 días de backups en almacenamiento externo, verificado.

    Fase 5: Verificación final (24h)

    17. Testeo post-hardening

    Antes de declarar victoria:

    1. Ejecuta nuevamente Wordfence CLI scan.
    2. Usa Sucuri SiteCheck para un escaneo online gratuito.
    3. Verifica en Google Search Console si siguen apareciendo advertencias de malware.
    4. Prueba acceso a wp-login.php desde un navegador privado. ¿Funciona 2FA? ¿Se limita después de 5 intentos fallidos?
    5. Revisa en httpbin.org que tus headers CSP y HSTS se envían correctamente.

    18. Monitoreo continuo post-ataque

    El hardening no termina en 24h. Configura alertas:

    • Wordfence: Email diario de intentos de login sospechosos.
    • Google Search Console: Alerta si detecta malware de nuevo.
    • Cambios de archivos: Usa un plugin como File Monitor Plus para alertas si alguien modifica wp-config.php o themes.
    • Logs de DB: Configura alertas si alguien crea nuevos usuarios admin sin autenticación.

    Errores que NO debes cometer

    En cientos de sitios, veo los mismos fallos que generan reinfecciones:

    • No cambiar contraseñas. Si cambias solo el admin pero no FTP ni BD, el atacante sigue dentro.
    • No eliminar plugins inactivos. Son puertas traseras dormidas. Si no lo usas, bórralo.
    • Restaurar desde backup infectado. Si tu backup fue creado después del ataque, estás reincrustando malware.
    • Ignorar los logs. No saber cómo entraron significa que volverán por el mismo camino.
    • Posponer hardening. «Lo haré después de limpiar». Así es como vuelve el malware en 3 semanas.
    • No avisar a usuarios. Si hubo comprometimiento de datos (emails, contraseñas), por GDPR/AEPD tienes obligación de informar.

    Cuándo llamar a un profesional

    Si durante estos pasos encuentras:

    • Múltiples backdoors entrelazados que no logras identificar.
    • Código ofuscado u encriptado que no puedes leer.
    • Indicios de que el ataque fue dirigido (no automatizado), con acceso a datos de clientes.
    • Tu proveedor de hosting no ofrece acceso a logs de servidor.
    • Tienes dudas sobre cumplimiento GDPR y notificación de brechas.

    En esos casos, no es ahorrar tiempo, es ahorrar dinero. Un ataque mal limpio que resurge cuesta 10 veces más que una limpieza profesional desde el inicio.

    Checklist final de 24 horas

    Primeras 2h:

    • ✓ Sitio en modo mantenimiento
    • ✓ Contraseñas cambiadas (admin, FTP, BD, cPanel)

    Horas 2-12:

    • ✓ Archivos descargados y analizados (grep, Wordfence CLI)
    • ✓ Logs revisados
    • ✓ BD auditada (posts, usuarios, options sospechosos)

    Horas 12-20:

    • ✓ Malware eliminado (manual o herramienta)
    • ✓ WordPress + plugins + temas actualizados
    • ✓ BD desinfectada

    Horas 20-24:

    • ✓ wp-config.php protegido
    • ✓ DISALLOW_FILE_EDIT activo
    • ✓ Prefijo de tablas cambiado
    • ✓ 2FA instalado y activado
    • ✓ wp-login.php limitado y renombrado
    • ✓ Headers CSP/HSTS implementados
    • ✓ Permisos de carpetas corregidos
    • ✓ WAF instalado (Wordfence o Cloudflare)
    • ✓ Backups automatizados configurados
    • ✓ Verificación final: scans sin alertas
    • ✓ Monitoreo continuo activado

    Si has llegado aquí y completaste cada paso, tu WordPress está infinitamente más blindado que antes. Pero recuerda: la seguridad no es un destino, es un viaje. Los atacantes innovan constantemente, así que tus defensas también deben hacerlo.

    Si en cualquier momento durante este proceso te sientes abrumado o detectas algo fuera de lo común, mi equipo en ManuelFolgar.com/contacto puede tomar el control. Hemos limpiado miles de sitios infectados y podemos certificar que tu WordPress está 100% libre de malware, además de implementar el hardening completo sin que pierdas horas preciosas.