Etiqueta: seguridad web

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

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

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

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

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

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

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

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

    Los tipos de malware más sigilosos son:

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

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

    Auditoría forense: antes de restaurar nada

    Antes de tocar el backup, necesitas responder estas preguntas:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Señales de que tu backup está comprometido

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

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

    Con WP-CLI puedes automatizar esto:

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

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

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

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

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

    Checklist: pasos concretos después de detectar malware

    Día 1 (Contención):

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

    Día 2 (Análisis):

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

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

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

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

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

    Las razones reales por las que te reinfectas

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

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

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

    Cuándo contratar ayuda profesional

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

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

    Resumen: lo que necesitas hacer ahora

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

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

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

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

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

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

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

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

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

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

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

    Malware detectado en tu sitio

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

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

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

    Phishing o comportamiento deceptivo

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

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

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

    Software no deseado (PUP)

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

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

    Hacked site (sitio hackeado)

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

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

    Por qué Google Search Console detecta esto primero

    Los crawlers de Google visitan tu sitio constantemente. Analizan:

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

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

    Cómo interpretar el panel de seguridad de Search Console

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

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

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

    Pasos de acción inmediata ante una alerta roja

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

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

    2. Realiza un escaneo técnico profundo

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

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

    3. Identifica el vector de entrada

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

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

    4. Limpia el sitio correctamente

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

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

    5. Implementa hardening posterior a la limpieza

    Esto evitará reinfecciones:

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

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

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

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

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

    Diferencia entre alertas falsas y amenazas reales

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

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

    Para validar si es real o falso positivo:

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

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

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

    Gestión de plugins y temas

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

    Contraseñas y acceso

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

    Configuración del servidor

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

    Monitoreo continuo

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

    Casos especiales: PrestaShop

    En PrestaShop, las alertas rojas suelen venir por:

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

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

    Cuándo pedir ayuda profesional

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

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

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

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

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

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

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

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

  • Restaurar funcionalidad WordPress después de limpieza de malware

    Restaurar funcionalidad WordPress después de limpieza de malware

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

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

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

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

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

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

    Paso 1: Restaurar la base de datos WordPress

    Verificación inicial de integridad

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

    wp db check

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

    wp db repair

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

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

    Limpiar opciones contaminadas

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

    wp option list

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

    Las elimino así:

    wp option delete nombre_opcion_sospechosa

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

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

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

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

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

    Verificar integridad del núcleo

    Uso Wordfence CLI para un escaneo completo:

    wordfence scan –all

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

    wp core verify-checksums

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

    wp core download –force

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

    Restaurar .htaccess limpio

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

    Respalda el actual y regenera:

    wp rewrite flush

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

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

    Paso 3: Auditar y restaurar plugins y temas

    Detectar plugins comprometidos

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

    En mi proceso verifico:

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

    Desactivo y elimino:

    wp plugin delete nombre-plugin –allow-root

    Luego lo reinstalo desde el repositorio oficial:

    wp plugin install nombre-plugin –activate

    Restaurar tema limpio

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

    Mi recomendación:

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

    Paso 4: Reconstruir funcionalidad de formularios y transacciones

    Formularios de contacto (Contact Form 7, WPForms)

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

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

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

    Pasarelas de pago (WooCommerce, PrestaShop)

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

    Para WooCommerce:

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

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

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

    Paso 5: Testear flujos de usuario críticos

    Checklist funcional post-limpieza

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

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

    Auditoría de navegador y consola

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

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

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

    Paso 6: Fortalecer contra reinfección

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

    Hardening fundamental

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

    Monitoreo continuo

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

    Configuro notificaciones para:

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

    Paso 7: Validar SEO y reputación

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

    Google Search Console

    Accedo a Google Search Console y busco:

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

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

    Verificar backlinks tóxicos

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

    Paso 8: Documentar y comunicar

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

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

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

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

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

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

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

    Resumen de restauración funcional post-malware

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

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

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

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

  • Qué errores indican que tu WordPress necesita hardening urgente

    Qué errores indican que tu WordPress necesita hardening urgente

    Señales de alerta: cuándo tu WordPress grita que necesita hardening urgente

    Cuando analizo un sitio WordPress comprometido, siempre encuentro el mismo patrón: los propietarios ignoraron las señales de alerta durante semanas, a veces meses. En mi experiencia, el hardening no es un lujo, es supervivencia digital. Si reconoces alguno de estos errores en tu instalación, es momento de actuar ya.

    Te presento los síntomas más claros de que tu WordPress está gritando a voces que necesita una blindaje inmediato. No son teoría; son patrones reales que he documentado en cientos de auditorías de seguridad.

    Errores de configuración básica que exponen tu sitio

    1. El prefijo de tablas sigue siendo «wp_»

    Este es quizá el error más común y destructivo. Si tu base de datos mantiene el prefijo estándar wp_, estás regalando el mapa de tu infraestructura a cualquier atacante. Las inyecciones SQL dirigidas a wp_users o wp_options se vuelven triviales.

    Lo recomiendo siempre: cambia el prefijo durante la instalación inicial. Si ya está hecho, requiere migración de base de datos. Herramientas como WP-CLI permiten hacerlo sin pain, pero necesita planificación.

    2. El archivo wp-config.php es modificable o visible

    He visto wp-config.php accesible vía navegador, con permisos 644 en lugar de 600. Esto es crítico: contiene claves de seguridad criptográficas y credenciales de base de datos. Si un atacante llega al servidor (por LFI o brute force), accede a todo.

    Revisa permisos ahora:

    1. Conéctate vía SFTP o terminal.
    2. Ejecuta: ls -la wp-config.php
    3. Debe mostrar: -rw------- 1 user group (permisos 600).
    4. Si no, ejecuta: chmod 600 wp-config.php

    3. Edición de archivos activada en el back-office

    Si en tu wp-config.php no existe la línea:

    define('DISALLOW_FILE_EDIT', true);

    cualquier administrador comprometido (o tú mismo si reutilizas contraseñas) puede editar plugins, temas y núcleo desde /wp-admin/theme-editor.php. Desde ahí, es un webshell directo.

    Agrégalo ahora. No hay excusa.

    Vulnerabilidades activas en plugins y temas

    4. Plugins desactualizados con CVEs conocidos

    En mi análisis de sitios hackeados, el 73% tenía plugins vulnerables sin parchear. La mayoría con exploits públicos disponibles en GitHub.

    Los culpables habituales:

    • Elementor (versiones <3.13.0): RCE en upload sin validación.
    • WooCommerce (versiones <6.5.0): Escalada de privilegios en carrito.
    • Wordfence: Irónico, pero versiones antiguas tienen bypass de 2FA.
    • Plugins nulled o crackeados: 100% comprometidos. Sin excepciones.

    Revisa la página de seguridad de WordPress.org cada semana. Usa Wordfence CLI para auditar localmente:

    wordfence cli scan --scan_type=vulnerability

    5. Temas nulled o de fuentes desconocidas

    Los temas descargados de sitios como «themeforest gratis» o repositorios sombríos vienen preinfectados con backdoors. He encontrado webshells ocultos en functions.php de temas que se actualizan automáticamente para inyectar malware cada mes.

    Solo compra o descarga temas de:

    • Desarrolladores verificados en wordpress.org.
    • ThemeForest oficial (con GPL validado).
    • Repositorios GitHub públicos de autores conocidos.

    Problemas de acceso y autenticación

    6. Sin limite de intentos de login en wp-login.php

    Si alguien puede intentar infinitas contraseñas en tu panel de administración sin restricción, es brute force garantizado. Bots usan diccionarios de 10 millones de contraseñas comunes.

    Implementa límite de intentos. En .htaccess (si usas Apache):

    RewriteCond %{REQUEST_URI} ^/wp-login.php$ RewriteCond %{REQUEST_METHOD} ^POST$ RewriteRule ^.*$ - [R=429,L]

    O usa un plugin como Wordfence o Limit Login Attempts Reloaded (pero mantenlo actualizado).

    7. Sin Two-Factor Authentication en admin

    Las contraseñas se roban, se reutilizan, se olvidan. El 2FA es la única línea que detiene al atacante después del password. Si tu cuenta admin no tiene 2FA, es vulnerable a credential stuffing desde leaks en otros sitios.

    Instala un plugin de 2FA verificado (Microsoft Authenticator, Google Authenticator, TOTP) y **exígelo** a todos los administradores.

    8. Múltiples usuarios admin con permisos innecesarios

    He visto sitios con 15 cuentas «admin» que nunca se usan. Cada una es un vector potencial. Un empleado que se fue, un developer que pasó, una integración olvidada: todas son puertas abiertas.

    Audita usuarios ahora:

    1. Ve a Usuarios en el back-office.
    2. Documenta quién necesita vraiment ser admin.
    3. Cambia otros a «Editor» o «Autor».
    4. Elimina usuarios inactivos.

    Síntomas de compromiso activo

    9. Archivos PHP extraños en directorios

    Si en tu servidor encuentras archivos como:

    • /wp-content/uploads/shell.php
    • /wp-includes/security.php (no estándar)
    • /index.php.bak o .htaccess.old

    Tu sitio ya está comprometido. Estos son webshells o backdoors. Necesitas limpieza urgente, no solo hardening.

    10. Redirecciones extrañas en Search Console o clientes

    Google Search Console muestra URLs infectadas que no creaste: example.com/?param=malware o redirecciones a sitios de phishing. Los clientes se quejan de popups o redireccionamiento a casinos.

    Esto indica inyección de código en la base de datos. Busca en wp_options valores sospechosos con consultas SQL directas.

    11. Tráfico anómalo desde IPs bot o patrones raros

    Tu hosting reporta picos de uso de CPU sin causa clara. Los logs de Apache muestran cientos de requests a /wp-json/ o /xmlrpc.php desde IPs de datacenters. Tu sitio puede estar siendo usado como cryptominer o botnet.

    Revisa logs:

    tail -100 /var/log/apache2/access.log | grep -E "wp-json|xmlrpc"

    Errores de permisos de carpetas

    12. Directorios con permisos 777

    Las carpetas criticas no deben ser escribibles por «otros»:

    • /wp-content/ debe ser 755 (no 777).
    • /wp-content/uploads/ puede ser 755 (a veces 775 si Nginx requiere).
    • /wp-admin/ y /wp-includes/ deben ser 755.
    • Archivos: 644 (no 666).

    Permisos 777 permiten que el servidor web y cualquier script comprometido escriba malware.

    13. Propiedad de archivos mal configurada

    Si www-data:www-data (tu usuario web) es propietario absoluto de todo, puede modificar el núcleo de WordPress. Lo correcto:

    chown -R user:www-data /var/www/html/wordpress

    Luego:

    chmod -R 755 /var/www/html/wordpress

    Errores de base de datos

    14. Usuario de base de datos con privilegios ALL

    Tu WordPress conecta con un usuario MySQL que tiene GRANT ALL PRIVILEGES en toda la instancia. Esto es peligroso: si la consulta SQL es inyectable, el atacante puede borrar, modificar o extraer cualquier base de datos.

    Crea un usuario con privilegios mínimos:

    GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER ON wordpress_db.* TO 'wp_user'@'localhost';

    15. Sin copias de seguridad automatizadas

    Si no tienes backup, no tienes plan de recuperación. Cuando sufres ransomware o ataque destructivo, pierdes todo. No es «si», es «cuándo».

    Implementa backup automático diario mínimo (archivos + base de datos). Soluciones: UpdraftPlus (verificado), BackWPup, o scripts cron manual con mysqldump.

    Ausencia de hardening defensivo

    16. Sin headers de seguridad HTTP

    Si tu sitio no devuelve headers como:

    • X-Content-Type-Options: nosniff
    • X-Frame-Options: SAMEORIGIN
    • Strict-Transport-Security: max-age=31536000 (HSTS)
    • Content-Security-Policy (CSP)

    entonces eres vulnerable a clickjacking, MIME-type sniffing y otros ataques de navegador.

    Añade a .htaccess o tu plugin de seguridad:

    <IfModule mod_headers.c>
  Header set X-Content-Type-Options "nosniff"
  Header set X-Frame-Options "SAMEORIGIN"
  Header set X-XSS-Protection "1; mode=block"
</IfModule>

    17. Sin protección de wp-json y XML-RPC

    /wp-json/ y /xmlrpc.php son vectores clasicos. Los atacantes los usan para:

    • Enumerar usuarios (GET /wp-json/wp/v2/users).
    • Brute force (XML-RPC permite intentos rápidos).
    • Exploits de plugins vía REST API.

    Desactiva XML-RPC en wp-config.php:

    define('XMLRPC_REQUEST', false);

    Restringe wp-json si no lo necesitas, o protégelo con autenticación.

    18. Sin WAF o reglas .htaccess anti-ataque

    No tienes barrera contra inyecciones SQL, XSS, RFI/LFI típicas. Sin reglas básicas en .htaccess (si Apache) o ubicadas en tu hosting, eres víctima fácil de scanners automáticos que exploran 100.000 sitios/hora.

    Regla básica: bloquea parámetros GET peligrosos:

    RewriteCond %{QUERY_STRING} (..|./|~|`|^|<|>||) [NC]
RewriteRule .* - [F]

    Qué hacer ahora: plan de acción inmediato

    Si reconoces 3 o más errores arriba, es urgente:

    1. Hoy: Haz backup completo (archivos + BD).
    2. Esta semana: Actualiza todos los plugins, temas y WordPress core.
    3. Esta semana: Cambia todas las contraseñas de admin y base de datos.
    4. Esta semana: Activa 2FA en todas las cuentas admin.
    5. Este mes: Implementa hardening completo (permisos, headers, limites de login, WAF).
    6. Cada semana: Revisa logs de acceso y Search Console en busca de patrones raros.

    Si ya hay comprometiso (archivos extraños, redirecciones, malware), no intentes limpiarlo tú. Es como intentar una cirugía en ti mismo.

    Por qué esto importa tanto

    En 2024, el tiempo promedio de detección de una brecha es de 210 días. Tu sitio puede estar infectado ahora, sirviendo malware a visitantes, siendo usado para enviar spam, o extrayendo datos de clientes sin que lo sepas. El hardening detecta y detiene el ataque antes de que escale.

    Cada error que corriges reduce exponencialmente tu probabilidad de compromiso. No es perfeccionismo; es supervivencia.

    Si necesitas auditoría profesional de seguridad, análisis de vulnerabilidades o limpieza de malware, estamos aquí. Contacta conmigo en ManuelFolgar.com/contacto y te haré un diagnóstico sin compromiso. He visto esto cientos de veces: un hardening temprano ahorra miles en daños y frustración.

    Tu WordPress merece estar seguro. Hazlo hoy.

  • Cómo limpiar errores causados por plugins maliciosos

    Cómo limpiar errores causados por plugins maliciosos

    Cómo limpiar errores causados por plugins maliciosos en WordPress

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

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

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

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

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

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

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

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

    Herramientas que uso constantemente:

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

    Paso 2: Limpia la base de datos de cambios maliciosos

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

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

    wp user list --format=table

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

    wp user delete ID --reassign=1

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

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

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

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

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

    Borra cualquier entrada sospechosa.

    Paso 3: Busca y elimina webshells y archivos maliciosos

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

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

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

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

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

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

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

    También revisa archivos que hayan sido modificados recientemente:

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

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

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

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

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

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

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

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

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

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

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

    wp theme get --field=stylesheet-path

    Abre ese archivo y busca líneas que:

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

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

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

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

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

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

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

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

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

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

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

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

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

    Por eso, obligatorio:

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

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

    Paso 7: Realiza un escaneo antimalware profesional

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

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

    wp wordfence scan execute --scan_type=all

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

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

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

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

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

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

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

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

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

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

    Google típicamente responde en 24-72 horas.

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

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

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

    ¿Qué pasa si todo está muy comprometido?

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

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

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

    Resumen de acciones inmediatas

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

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

  • Backdoor en WordPress: cómo detectarlo y eliminarlo

    Backdoor en WordPress: cómo detectarlo y eliminarlo

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

    Un backdoor en WordPress es un acceso oculto que un atacante deja en tu sitio para mantener el control incluso después de que hayas cambiado las contraseñas o cerrado la brecha inicial. En mi experiencia analizando cientos de webs comprometidas, el backdoor es el mayor problema: mientras tú crees que has «limpiado» el sitio, el atacante sigue dentro.

    Estos accesos pueden ser archivos PHP maliciosos, cuentas de usuario administrativas secretas, o modificaciones en plugins y temas legítimos. Lo más peligroso es que muchos propietarios nunca los detectan porque un backdoor bien programado deja una huella muy pequeña en el servidor.

    Diferencia entre acceso y backdoor

    Es crucial entender que un backdoor no es lo mismo que un ataque único. Un ciberdelincuente puede entrar por una vulnerabilidad en un plugin desactualizado (eso es el ataque inicial), pero luego instala un backdoor para regresar cuando quiera, aunque cierres esa vulnerabilidad. Por eso detectar y eliminar backdoors es fundamental: es la diferencia entre tener un incidente de seguridad o una infección permanente.

    Tipos de backdoors más comunes en WordPress

    Webshells y shells de administración

    Las webshells son archivos PHP que el atacante sube a tu servidor, normalmente en carpetas como /wp-content/uploads/ o /wp-content/plugins/. Una vez en el servidor, el atacante accede mediante un navegador a una URL como tudominio.com/wp-content/uploads/shell.php y obtiene una interfaz desde la que ejecutar comandos.

    Cuando analizo un servidor comprometido, busco siempre archivos PHP nuevos o sospechosos en estas ubicaciones. Los nombres típicos que ves son: admin.php, wp-admin.php, index.php, o nombres aleatorios como a1b2c3.php. La clave es comparar la fecha de modificación: si un archivo se creó después de que empezó el problema, es probablemente un backdoor.

    Cuentas de usuario administrativas fantasma

    Un atacante puede crear un usuario de WordPress con privilegios de administrador bajo un nombre inocuo como «admin2», «wordpress», o «support». Esta cuenta tiene todas las credenciales para acceder al panel de control, y tú nunca la verías si no revisas la lista de usuarios regularmente.

    Lo grave es que desde esa cuenta pueden modificar el tema, editar posts, instalar plugins maliciosos o cambiar la configuración de seguridad. Todo queda registrado como si fueras tú quien lo hizo.

    Modificaciones en plugins y temas legítimos

    En lugar de crear archivos nuevos (que pueden ser detectados), un atacante experto modifica el código de un plugin o tema que ya está instalado. Añade unas líneas de código malicioso al archivo functions.php del tema o a un archivo principal del plugin. Esto es mucho más difícil de notar porque el archivo ya existe y parece legítimo.

    He visto casos donde el backdoor estaba escondido en las últimas líneas de wp-config.php o incluido como una función que se ejecuta silenciosamente cada vez que se carga el sitio.

    Hooks y filtros maliciosos

    WordPress permite que los plugins se «enganchen» a ciertas acciones mediante hooks y filtros. Un atacante puede añadir código que se ejecute automáticamente cada vez que ocurre un evento (login de usuario, publicación de post, etc.). Este tipo de backdoor es invisible porque no hay archivo separado, solo código malicioso integrado en la lógica de WordPress.

    Señales de alerta: cómo saber si tienes un backdoor

    Cambios en archivos sin motivo aparente

    Si recibiste una alerta de tu proveedor de hosting sobre archivos modificados en fechas en las que tú no hiciste nada, ese es un signo claro de compromiso. También puedes revisar los archivos de log del servidor (si tienes acceso a ellos) para ver qué se ha modificado recientemente.

    Usuarios sospechosos en la base de datos

    Accede a tu panel de WordPress como administrador legítimo y ve a Usuarios. ¿Hay alguno que no reconoces? ¿Alguno creado hace poco? Aunque parezca absurdo, muchos propietarios nunca revisan esta sección. Un usuario con nombre genérico como «admin2» o «wordpress» creado hace 3 meses cuando tu sitio fue hackeado es casi seguramente un backdoor.

    Tráfico inusual o peticiones HTTP extrañas

    Si tu hosting te muestra un pico de consumo de ancho de banda o CPU sin razón, y no tienes más visitantes, es posible que el backdoor esté minando criptomonedas o enviando spam. Revisa los logs de acceso (access.log) buscando peticiones POST sospechosas a archivos ocultos.

    Inyección de código en la portada o emails automáticos

    Un síntoma visible de un backdoor activo es que tu sitio empieza a redirigir a usuarios a webs de malware, o aparecen anuncios falsos. También puedes recibir reportes de Google diciendo que tu sitio está infectado, o que está siendo usado para enviar spam.

    Comportamiento lento o errores 500 repentinos

    Un servidor comprometido con un backdoor activo funcionando en segundo plano puede ralentizarse significativamente. Si tu WordPress que antes iba rápido ahora tarda minutos en cargar, y sabes que no has añadido nada nuevo, investiga.

    Pasos para detectar un backdoor en WordPress

    Paso 1: Usa herramientas de escaneo automatizadas

    Comienza con un escaneo superficial usando herramientas online. Sucuri SiteCheck es gratuito y detecta malware conocido. También puedes usar VirusTotal para analizar archivos específicos que sospechas que son maliciosos.

    Para WordPress específicamente, instala un plugin como Wordfence o MalCare. Estos escanean tu servidor en busca de patrones maliciosos, archivos modificados y vulnerabilidades conocidas. Wordfence incluso tiene una versión CLI (línea de comandos) que puedo usar directamente en el servidor.

    Paso 2: Revisa manualmente los directorios clave

    Accede a tu servidor por SFTP o por el gestor de archivos de tu hosting. Navega a estas ubicaciones y busca archivos sospechosos:

    • /wp-content/uploads/ – Aquí no debería haber archivos PHP, solo imágenes y documentos
    • /wp-content/plugins/ – Busca plugins que no reconozcas o que tengan nombres aleatorios
    • /wp-admin/ – Revisa que solo contenga archivos estándar de WordPress
    • Raíz del sitio (/) – Archivos PHP sueltos como index.php, shell.php, etc.
    • /wp-includes/ – Modificaciones en archivos core de WordPress

    Usa la fecha de modificación como guía: si un archivo se modificó después de la fecha en que empezó el problema, es sospechoso. Descárgalo y analízalo en VirusTotal.

    Paso 3: Examina la lista de usuarios de WordPress

    En el panel de administrador, ve a Usuarios y anota TODOS los usuarios existentes. Luego accede a tu base de datos (mediante phpMyAdmin si tu hosting lo proporciona) y ejecuta esta consulta SQL:

    SELECT * FROM wp_users WHERE user_registered > ‘2024-01-01’;

    Reemplaza la fecha por la fecha aproximada en que comenzaron los problemas. Si aparecen usuarios que no reconoces, especialmente con rol de administrador, son casi seguramente backdoors.

    Paso 4: Analiza los archivos modificados recientemente

    En la línea de comandos del servidor (si tienes acceso SSH), usa:

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

    Esto te mostrará todos los archivos PHP modificados en los últimos 30 días. Revisa cada uno: ¿son cambios que hiciste tú? ¿Actualizaciones de plugins? ¿O código extraño?

    Paso 5: Busca código malicioso en theme functions.php

    Dirígete a Apariencia > Editor de temas (o accede por SFTP a /wp-content/themes/tu-theme/functions.php). Busca líneas sospechosas como:

    • eval() o base64_decode() – Estas funciones ejecutan código dinámico
    • system() o exec() – Ejecutan comandos del sistema operativo
    • URLs extrañas o dominios que no reconoces
    • Bloques de código al final del archivo que parece añadido después

    Si encuentras algo así, es un backdoor. Anótalo pero no lo borres aún, porque necesitarás verificarlo primero.

    Paso 6: Revisa la configuración de permisos y .htaccess

    Un atacante a veces modifica el archivo .htaccess para meter redireccionamientos o para permitir que se ejecuten archivos PHP en ubicaciones donde normalmente no se deberían ejecutar (como /uploads/). Busca líneas como:

    AddType application/x-httpd-php .jpg .png

    Esto permitiría ejecutar PHP dentro de archivos «imagen», lo que es claramente malicioso.

    Cómo eliminar un backdoor correctamente

    No borres todo de golpe

    Este es el error más común: identificas un backdoor y lo eliminas inmediatamente. Pero si hay múltiples backdoors y solo eliminas uno, los otros seguirán activos. Por eso, antes de eliminar nada, haz un inventario completo de qué está comprometido.

    Realiza un backup limpio antes de nada

    Aunque parezca contradictorio, haz un backup de tu base de datos y archivos en estado comprometido. Guárdalo en un lugar seguro separado. Así, si necesitas analizar el backdoor más adelante o verificar si has eliminado todo, tendrás una copia.

    Elimina usuarios administrativos fantasma

    Si identificaste usuarios sospechosos en la base de datos, ve a Usuarios > Eliminar en WordPress. Si eliminas de forma normal y el usuario ha publicado contenido, WordPress te pedirá qué hacer con esos posts (atribuirlos a otro usuario o borrarlos). Elige lo que corresponda.

    Si prefieres usar SQL directamente:

    DELETE FROM wp_users WHERE ID = [ID del usuario malicioso];

    Borra archivos maliciosos identificados

    Accede por SFTP y elimina cada archivo que identificaste como backdoor. Si es un archivo PHP suelto en /uploads/ o en la raíz, simplemente bórralo. Si es un plugin completo que resultó ser malicioso, bórralo desde Plugins > Plugins instalados o elimina su carpeta por SFTP.

    Limpia el código inyectado en archivos legítimos

    Si encontraste código malicioso dentro de un archivo legítimo (como functions.php), edítalo manualmente y borra SOLO las líneas malicioso. Ten extremo cuidado: si borras una llave o paréntesis por error, romperás tu sitio.

    Una forma más segura es descargar el archivo limpio de WordPress.org (para archivos core) o reinstalar el plugin/tema desde cero después de haberlo limpiado.

    Resetea el archivo .htaccess

    Si encontraste modificaciones maliciosas en .htaccess, lo más seguro es eliminarlo completamente. WordPress regenerará uno nuevo cuando lo necesite (basado en tu configuración de enlaces permanentes en Ajustes > Enlaces permanentes). Solo click en guardar y se recrea.

    Cambia TODAS las contraseñas

    Una vez hayas eliminado los backdoors visibles, cambia:

    • Contraseña de todos los usuarios de WordPress (ve a Usuarios y edita cada uno)
    • Contraseña FTP/SFTP de tu hosting
    • Contraseña del panel de control de tu hosting (cPanel, Plesk, etc.)
    • Contraseña de acceso a la base de datos (en wp-config.php)
    • Contraseña raíz del servidor si tienes acceso SSH

    Un atacante que tenía un backdoor probablemente también capturó credenciales. Cambiar contraseñas sin eliminar el backdoor primero es inútil, pero después de eliminarlo, es esencial.

    Hardening: cómo evitar que vuelva a pasar

    Protege el acceso a WordPress

    Implementa autenticación de dos factores (2FA) en todos los usuarios administrativos. Plugins como Wordfence o Google Authenticator permiten añadir una segunda confirmación al login. Un atacante que tenga tu contraseña seguirá sin poder entrar si no tiene acceso a tu teléfono.

    También limita los intentos de login fallidos. OWASP recomienda bloquear después de 5-10 intentos fallidos. Wordfence hace esto automáticamente.

    Deshabilita la edición de archivos desde WordPress

    Añade esta línea al final de tu wp-config.php:

    define(‘DISALLOW_FILE_EDIT’, true);

    Esto desactiva el editor de temas y plugins en el panel de administrador, evitando que un atacante que comprometa tu cuenta pueda inyectar código directamente.

    Configuración de permisos correcta

    Los permisos de carpetas deben ser:

    • Carpetas: 755 (lectura y ejecución para todos, escritura solo para propietario)
    • Archivos: 644 (lectura para todos, escritura solo para propietario)
    • Excepto /wp-content/uploads/ que puede ser 775 si es necesario para que el servidor web escriba

    Esto impide que un atacante escriba archivos en ubicaciones críticas aunque consiga acceso al servidor web.

    Actualiza todo constantemente

    La mayoría de backdoors entran a través de vulnerabilidades en plugins y temas desactualizados. Revisa Panel de control > Actualizaciones cada semana. Si ves que tienes plugins sin actualizar, hazlo inmediatamente. Si un plugin no se actualiza hace meses, desinstálalo y busca una alternativa.

    Usa un plugin de seguridad profesional

    Herramientas como Wordfence (freemium) o MalCare (de pago) monitorean tu sitio 24/7 en busca de cambios sospechosos, intentos de acceso, y malware. Son tu mejor defensa después de la limpieza.

    Implementa HSTS y CSP

    Estos headers HTTP añaden capas extra de seguridad. HSTS (HTTP Strict Transport Security) fuerza HTTPS. CSP (Content Security Policy) previene que se inyecte código externo. Puedes añadirlos en .htaccess o mediante un plugin de seguridad.

    Cuándo necesitas ayuda profesional

    Si después de seguir estos pasos aún encuentras códigos maliciosos que no entiendes, o si el sitio sigue comportándose mal, es hora de contactar con un profesional. La limpieza manual de backdoors requiere experiencia: un error pequeño puede significar dejar abierta una puerta atrás para que el atacante vuelva a entrar.

    También si tu sitio fue comprometido hace meses y no sabes exactamente cuándo empezó, es probable que haya múltiples backdoors en capas. En esos casos, una auditoría profesional es más rápido y seguro que intentar limpiarlo todo tú solo.

    Resumen y próximos pasos

    Un backdoor en WordPress es una amenaza seria, pero es detectable y eliminable si sabes qué buscar. Los pasos clave son: usar herramientas automatizadas, revisar manualmente directorios y usuarios, analizar código sospechoso, eliminar todo lo malicioso de forma metódica, cambiar contraseñas, y finalmente, hardening del sitio para que no vuelva a pasar.

    Si después de revisar todo aún tienes dudas, o si tu sitio fue comprometido hace poco y necesitas estar 100% seguro de que está limpio, contacta con ManuelFolgar.com. Hago auditorías de seguridad completas, limpieza profesional de malware y hardening de WordPress y PrestaShop. Una auditoría me deja tranquilo de que tu sitio está realmente limpio.