Etiqueta: wordpress

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

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

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

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

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

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

    Las limitaciones inherentes de los modelos de lenguaje

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

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

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

    El problema de la «solución de cadena»

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

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

    Recopila información antes de cualquier acción

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

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

    Accede a logs reales: donde vive la verdad

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

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

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

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

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

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

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

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

    2. Verifica la integridad de WordPress core

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

    wp core verify-checksums

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

    wp core download --force --locale=es_ES

    3. Revisa la base de datos: inyecciones SQL sutiles

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

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

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

    4. Análisis de permisos y propietarios de ficheros

    WordPress es sensible a esto. Desde terminal:

    ls -la wp-config.php

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

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

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

    Cuándo necesitas ayuda profesional: indicadores clave

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

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

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

    Herramientas que SÍ sirven cuando la IA falla

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

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

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

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

    Documentación oficial (no tutoriales genéricos)

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

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

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

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

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

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

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

    La IA es una herramienta formidable. Úsala para:

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

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

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

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

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

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

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

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

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

    La arquitectura de PrestaShop: concentración de riesgos

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

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

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

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

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

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

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

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

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

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

    Protección de acceso: donde PrestaShop falla

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

    PrestaShop no incluye por defecto:

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

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

    Vulnerabilidades de core PrestaShop: historial de negligencia

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

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

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

    Configuración por defecto peligrosa

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

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

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

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

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

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

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

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

    Permisos de usuario débiles y mal gestionados

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

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

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

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

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

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

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

    ¿Qué puedes hacer para proteger tu PrestaShop?

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

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

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

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

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

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

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

    El factor humano: educación y vigilancia

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Malware detectado en tu sitio

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

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

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

    Phishing o comportamiento deceptivo

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

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

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

    Software no deseado (PUP)

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

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

    Hacked site (sitio hackeado)

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

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

    Por qué Google Search Console detecta esto primero

    Los crawlers de Google visitan tu sitio constantemente. Analizan:

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

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

    Cómo interpretar el panel de seguridad de Search Console

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

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

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

    Pasos de acción inmediata ante una alerta roja

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

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

    2. Realiza un escaneo técnico profundo

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

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

    3. Identifica el vector de entrada

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

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

    4. Limpia el sitio correctamente

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

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

    5. Implementa hardening posterior a la limpieza

    Esto evitará reinfecciones:

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

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

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

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

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

    Diferencia entre alertas falsas y amenazas reales

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

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

    Para validar si es real o falso positivo:

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

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

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

    Gestión de plugins y temas

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

    Contraseñas y acceso

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

    Configuración del servidor

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

    Monitoreo continuo

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

    Casos especiales: PrestaShop

    En PrestaShop, las alertas rojas suelen venir por:

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

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

    Cuándo pedir ayuda profesional

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    3. No tener copias de seguridad o tenerlas sin verificar

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

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

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

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

    4. Desconocer qué plugins y temas tienes instalados

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

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

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

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

    5. No proteger el archivo wp-config.php

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

    No cuesta casi nada protegerlo mediante .htaccess:

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

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

    6. Ignorar alertas de Google Search Console

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

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

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

    7. No implementar un WAF (Web Application Firewall)

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

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

    8. Delegar seguridad a desarrolladores sin experiencia en ciberseguridad

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

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

    9. No tener política de acceso para usuarios

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

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

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

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

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

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

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

    ¿Cuál es el costo real de esperar?

    Cuando un sitio está comprometido, los gastos incluyen:

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

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

    El primer paso: haz una auditoría ahora

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

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

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

    Referencias y recursos

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

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

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

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

    Usuarios administrador fantasma: el riesgo silencioso en tu WordPress

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

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

    ¿Por qué los atacantes crean usuarios administrador?

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

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

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

    Vectores de creación de usuarios maliciosos

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

    1. Plugins vulnerables con funciones de registro abiertas

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

    2. Inyección SQL

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

    3. Acceso directo al archivo wp-config.php

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

    4. Brute force sobre wp-login.php

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

    5. Explotación de vulnerabilidades zero-day

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

    Cómo detectar cuentas fantasma en WordPress

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

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

    Accede a Usuarios > Todos los usuarios. Busca:

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

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

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

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

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

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

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

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

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

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

    wp user get [ID] –format=json

    Opción 4: Plugins de seguridad especializados

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

    Pasos para eliminar cuentas fantasma de forma segura

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

    Paso 1: Anota toda la información

    Antes de tocar nada, toma capturas de pantalla de:

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

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

    Paso 2: Revisa qué contenido tiene asociado

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

    Paso 3: Reasigna contenido (si es necesario)

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

    Paso 4: Elimina la cuenta

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

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

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

    Paso 5: Verifica en la base de datos

    Para estar 100% seguro, consulta de nuevo phpMyAdmin:

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

    El resultado debe ser 0.

    Cómo evitar que vuelvan a crear usuarios fantasma

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

    1. Limita la creación de usuarios

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

    2. Protege wp-login.php con .htaccess

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

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

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

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

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

    4. Mantén WordPress, plugins y temas actualizados

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

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

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

    6. Monitorea logs de acceso

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

    7. Cambia el prefijo de tablas de WordPress

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

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

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

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

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

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

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

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

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

    Herramientas y recursos para la detección automatizada

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

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

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

    Preguntas frecuentes sobre usuarios fantasma

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

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

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

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

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

    Lo que recomiendo como próximo paso

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

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

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

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

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

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

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

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

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

    1. Aislamiento del sitio: desconexión controlada

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

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

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

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

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

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

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

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

    3. Búsqueda de backdoors y webshells

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

    Aquí está lo que hago:

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

    4. Análisis de logs de acceso y error

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

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

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

    5. Escaneo de la base de datos

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

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

    Usa esta consulta para encontrar posts sospechosos sin autor visible:

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

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

    6. Eliminación quirúrgica de malware

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

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

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

    7. Actualización de WordPress y dependencias

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

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

    8. Desinfección de la base de datos

    Elimina los posts, usuarios y opciones maliciosas que encontraste:

    -- Elimina posts sin autor (sospechoso)
DELETE FROM wp_posts WHERE post_author = 0 AND post_type = 'post';

-- Borra usuarios admin no reconocidos
DELETE FROM wp_users WHERE ID NOT IN (SELECT user_id FROM wp_usermeta WHERE meta_key = 'wp_user_level' AND meta_value = '10') AND user_email NOT LIKE '%@tudominio.com%';

-- Limpia opciones de plugins maliciosos (ejemplo)
DELETE FROM wp_options WHERE option_name LIKE '%malicious_setting%';

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

    Fase 4: Hardening definitivo (horas 20-24)

    9. Protección de wp-config.php

    Este archivo contiene credenciales de BD. Protégelo:

    # En .htaccess (raíz de WordPress)

    Order allow,deny
    Deny from all

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

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

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

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

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

    11. Cambio de prefijo de tablas de BD

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

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

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

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

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

    • Instala un plugin de 2FA: Wordfence incluye 2FA gratis. Google Authenticator también es sólido. Usa TOTP (Time-based One Time Password), no SMS.
    • Limita intentos de login: En `.htaccess`: 
      
    Order allow,deny
    Allow from all


# O usa un plugin como iThemes Security que lo hace automáticamente.
# Limita a 5 intentos fallidos por IP en 15 minutos.
    • Cambia la URL de login: Por defecto es `/wp-login.php`. Los bots la atacan masivamente. Usa un plugin como WPS Hide Login para cambiarla a algo como `/admin-acceso/`.

    13. Implementación de CSP y HSTS

    Estas cabeceras HTTP previenen ataques del navegador:

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

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

    14. Auditoría de permisos de carpetas

    Los permisos incorrectos son entrada abierta para atacantes. Ajusta:

    # En el servidor (vía SSH):
find /home/usuario/public_html -type d -exec chmod 755 {} ;
find /home/usuario/public_html -type f -exec chmod 644 {} ;

# Excepciones:
chmod 600 /home/usuario/public_html/wp-config.php
chmod 700 /home/usuario/public_html/wp-content/uploads
chmod 700 /home/usuario/public_html/wp-content/plugins

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

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

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

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

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

    16. Configuración de backups automatizados

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

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

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

    Fase 5: Verificación final (24h)

    17. Testeo post-hardening

    Antes de declarar victoria:

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

    18. Monitoreo continuo post-ataque

    El hardening no termina en 24h. Configura alertas:

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

    Errores que NO debes cometer

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

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

    Cuándo llamar a un profesional

    Si durante estos pasos encuentras:

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

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

    Checklist final de 24 horas

    Primeras 2h:

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

    Horas 2-12:

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

    Horas 12-20:

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

    Horas 20-24:

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

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

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

  • Qué roles de usuario crearon los hackers en tu WordPress

    Qué roles de usuario crearon los hackers en tu WordPress

    Qué roles de usuario crearon los hackers en tu WordPress: guía de detección y eliminación

    Cuando un atacante consigue acceso a tu WordPress, una de las primeras cosas que hace es crear cuentas fantasma con permisos de administrador. En mi experiencia analizando sitios comprometidos, encuentro entre 2 y 5 usuarios ocultos que los propietarios desconocen completamente. Estos roles maliciosos son la puerta trasera perfecta: permiten al hacker regresar indefinidamente, incluso después de cambiar contraseñas o actualizar plugins.

    El problema es serio porque esas cuentas fantasma actúan como salvavidas para los ciberdelincuentes. Mientras tú crees haber expulsado al intruso, él sigue accediendo tranquilamente con credenciales que creó semanas antes. Por eso te enseño a identificarlas, eliminarlas y blindar tu WordPress contra este vector específico.

    Por qué los hackers crean roles y usuarios en WordPress

    Los atacantes no son tontos. Cuando vulneran tu WordPress mediante un plugin desactualizado, una contraseña débil o un backdoor, saben que tarde o temprano vas a descubrirlo. Por eso no se conforman con acceso temporal: crean usuarios administrativos permanentes.

    Las razones son evidentes:

    • Persistencia: aunque elimines el vector de ataque original (el plugin vulnerable), ellos siguen dentro como usuario legítimo.
    • Disimulo: una cuenta de usuario se ve «normal» en la lista de WordPress, especialmente si la llaman «admin», «support» o algo que parezca oficial.
    • Control total: con rol de administrador o editor, pueden modificar contenido, instalar plugins maliciosos, redirigir tráfico o robar datos de clientes.
    • Escalada de privilegios: si primero accedieron como editor, crean una cuenta admin para mantener control incluso si les revocas permisos iniciales.
    • Venta de acceso: algunos hackers venden credenciales WordPress a terceros, así que la cuenta es un activo que comercializan.

    Lo que recomiendo siempre a mis clientes es una auditoría mensual de usuarios. No es paranoia, es protocolo estándar en ciberseguridad.

    Cómo identificar usuarios fantasma creados por atacantes

    Accede al panel de WordPress en Usuarios y revisa cuidadosamente la lista completa. Los hackers cometen errores que los delatan:

    1. Cuentas con nombres genéricos o robados: «admin2», «administrator», «support», «wordpress», «test», «temp». Si no las creaste tú, no están.
    2. Emails sospechosos: direcciones de Gmail, Outlook o dominios públicos sin relación con tu empresa. A veces usan variantes de tu propio dominio: si tu correo es info@tuempresa.es, ellos crean admin@tuempresa.es o info@tuempresa.net.
    3. Fechas de creación extrañas: si ves un usuario creado a las 3:47 de la madrugada y no recuerdas haberlo hecho, es una bandera roja.
    4. Rol de administrador sin justificación: los usuarios legítimos suelen tener roles más específicos (editor, autor). Un administrador extra es sospechoso.
    5. Último acceso reciente pero sin actividad visible: algunos plugins como Wordfence muestran cuándo fue el último login. Si un usuario se conectó ayer pero no publicó nada, algo está mal.
    6. Contraseñas que no reconoces: aunque no puedas ver la contraseña (está hasheada), si intentas cambiarla y WordPress te dice que es «muy fuerte» con caracteres aleatorios, la creó alguien más.

    Para un análisis más profundo, uso WordPress CLI. Desde terminal ejecuto:

    wp user list –field=user_login,user_email,user_registered –format=table

    Esto te muestra todos los usuarios con fecha exacta de creación. Luego verifico quién los creó investigando logs (si los tienes habilitados).

    Roles y permisos que los ciberdelincuentes asignan

    No todos los usuarios maliciosos tienen rol de administrador. Depende de su intención:

    Administrador: acceso total. Lo que la mayoría prefiere para control absoluto. Pueden instalar plugins, cambiar configuración, crear más cuentas.

    Editor: si quieren pasar desapercibidos, crean editores. Pueden modificar contenido, publicar, pero no tocar plugins ni configuración. Es más sigiloso.

    Autor: menos común. Solo permite escribir posts propios. Usado si el ataque está enfocado específicamente en spam SEO o inyección de contenido malicioso.

    Suscriptor con rol personalizado: en algunos casos avanzados, los atacantes crean roles personalizados con permisos específicos (acceso a ciertos posts, capacidad de editar solo formatos, etc.). Esto es técnicamente sofisticado y difícil de detectar.

    Lo que veo en la mayoría de casos es una cuenta administrador con nombre innocuo y una segunda cuenta editor como «backup».

    Dónde buscar más allá de la interfaz

    Los usuarios maliciosos no solo están en la tabla wp_users. Necesitas revisar también:

    Base de datos directamente: conéctate vía phpMyAdmin y ejecuta esta query:

    SELECT user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC;

    Ordena por fecha de registro descendente y busca usuarios recientes que no creaste.

    Tabla de metadatos (wp_usermeta): aquí se almacenan los roles. Un usuario puede tener rol de «suscriptor» visible pero metadatos ocultos que lo convierten en admin:

    SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE meta_key LIKE ‘%capabilities%’;

    Logs de actividad: si usas Simple History o Wordfence, revisa quién creó esos usuarios. Muchos logs falsificados o vacíos también indican manipulación.

    Archivo wp-config.php: aunque es menos frecuente, algunos backdoors inyectan código que crea usuarios automáticamente al cargar la web. Busca funciones personalizadas que generen usuarios.

    Caso práctico: cómo actúa un usuario malicioso

    Te doy un ejemplo real que he visto docenas de veces:

    Un cliente tenía WordPress con WooCommerce. Un plugin de pasarela de pago desactualizado permitía RFI (Remote File Inclusion). El atacante inyectó código, instaló un backdoor y creó dos cuentas:

    • «paypal_admin» con rol administrador, email paypal.admins@gmail.com, creada a las 02:14 AM.
    • «woo_manager» con rol editor, email whoopsie@tudominio.net, creada 48 horas después (probablemente como backup).

    Durante 3 meses, el hacker:

    • Instaló un plugin de criptominería que consumía 40% CPU del servidor.
    • Modificó el checkout de WooCommerce para capturar números de tarjeta (Magecart).
    • Inyectó redirecciones spam en posts.
    • Creó spam SEO con palabras clave de casinos y apuestas.

    Todo bajo la cuenta «paypal_admin», que parecía legítima en un vista rápida. Solo cuando el cliente revisó los logs de Wordfence vio actividad masiva a horas raras.

    Pasos para eliminar usuarios maliciosos

    Una vez identificados, actúa con rapidez pero sin prisa (necesitas evidencia para auditoría):

    1. Documenta antes de borrar: toma screenshots del usuario, su email, fecha de creación, rol, último acceso. Esto es crucial si necesitas hacer denuncia o investigación forense.
    2. Cambiar contraseña de administrador legítimo: primero cambia tu contraseña principal a algo fuerte (16+ caracteres, símbolos, sin patrones). El atacante podría haber cambiado tu contraseña también.
    3. Desactiva antes de borrar: algunos plugins maliciosos se activan al eliminar usuarios. Mejor desactiva primero: ve a cada usuario, desactívalo temporalmente (algunos plugins lo permiten), revisa que el sitio siga funcionando, luego borra.
    4. Elimina con gestión de contenido: cuando borres el usuario, WordPress te pregunta qué hacer con su contenido (atribuirlo a otro usuario, borrar). Si creó contenido malicioso, bórralo. Si el contenido es legítimo pero creado bajo cuenta falsa, atribúyelo a un usuario real.
    5. Fuerza logout global: algunos plugins como Wordfence tienen opción «revoke all sessions». Úsalo para expulsar cualquier sesión activa de ese usuario y cualquier otro.
    6. Cambia todas las contraseñas de usuarios admins: no solo la tuya. El atacante podría tener acceso a varias.

    Desde WP-CLI, el comando es:

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

    Por ejemplo: wp user delete 5 –reassign=1 elimina usuario ID 5 y asigna su contenido al usuario 1.

    Auditoría de seguridad para prevenir futuras creaciones

    Después de limpiar, necesitas blindar WordPress contra este vector:

    Limita permisos de creación de usuarios: en OWASP lo llaman «principio de menor privilegio». Solo admins deberían crear usuarios, y esto debería registrarse:

    Añade a wp-config.php:

    define(‘DISALLOW_USER_EDITING’, false); (solo si quieres permiso explícito)

    Y usa un plugin como Wordfence que registra toda creación de usuario con IP, hora y navegador.

    Activa 2FA (autenticación de dos factores): incluso si roban contraseña, no pueden acceder sin teléfono. Wordfence, Defender o Duo Security lo permiten.

    Whitelisting de IPs para admin: si gestionas WordPress solo desde tu oficina o casa, configura Wordfence para permitir login solo desde IPs específicas. Bloqueará intentos remotos.

    Monitoreo de cambios en usuarios: configura alertas para notificarte si se crea un usuario nuevo. Wordfence y MalCare lo hacen automáticamente.

    Backup regular verificado: realiza backups diarios y verifica que se pueden restaurar. Un atacante puede borrar backups antiguos, así que necesitas múltiples copias en ubicaciones distintas.

    Herramientas especializadas para detectar usuarios ocultos

    Wordfence: su «User Login» muestra todos los logins, intentos fallidos, y sesiones activas. Puedes ver quién accedió, cuándo, desde dónde. Es mi favorita.

    WP Security Audit Log: registra cada acción en WordPress, incluida creación de usuarios. Puedes revisar el historial completo.

    MalCare: detecta usuarios anómalos mediante análisis de comportamiento. Si un usuario «support» típicamente no hace nada pero de repente instala plugins, MalCare te lo marca.

    Sucuri Site Integrity Monitor: revisa cambios en archivos y base de datos. Si alguien crea usuario, Sucuri lo nota.

    Lo que recomiendo es combinar Wordfence (para firewalling y detección en tiempo real) con auditoría de logs (para análisis histórico).

    Después de la limpieza: paso a paso

    No termina en borrar usuarios. Necesitas verificar que el sitio está completamente limpio:

    1. Ejecuta escaneo de malware con Wordfence o SiteLock. Busca backdoors, webshells, código inyectado.
    2. Verifica plugins y temas: desactiva todos, luego activa uno por uno mientras monitoreas. Si el problema reaparece, ese plugin/tema es culpable.
    3. Revisa Google Search Console. ¿Ves inyecciones de spam, redirects? Google notar si limpias rápido.
    4. Usa VirusTotal para verificar archivos sospechosos: sube los archivos modificados recientemente y deja que 70+ antivirus los analice.
    5. Monitorea 30 días después. A veces hay backdoors secundarios que se activaban después de tiempo.

    Denuncia y documentación

    Si fue ataque serio (robo de datos, fraude), documenta todo para denunciar a INCIBE (Instituto Nacional de Ciberseguridad) o la AEPD si hay compromiso de datos personales.

    Incluye:

    • Screenshots de usuarios maliciosos.
    • Logs de acceso (si los tienes).
    • Fechas de compromiso estimado.
    • Datos afectados (clientes, pagos, emails).
    • Acciones tomadas para remediar.

    Conclusión: vigilancia constante

    Los usuarios fantasma son síntoma de un problema mayor: tu WordPress ha sido vulnerado. Borrar las cuentas es limpiar síntomas, pero necesitas diagnosticar qué permitió el acceso inicial.

    En mi experiencia, es casi siempre una combinación de:

    • Plugins o temas desactualizados (60% de casos).
    • Contraseñas débiles o reutilizadas (25% de casos).
    • Falta de protección de wp-login (10% de casos).
    • Hospedaje compartido inseguro (5% de casos).

    Si necesitas que un profesional revise tu WordPress para identificar vulnerabilidades, auditar usuarios y asegurar que no hay backdoors escondidos, te invito a contactar con ManuelFolgar.com. Ofrecemos análisis forense completo, limpieza de malware verificada y hardening específico para tu sitio.

    Tu WordPress es tu tienda digital. Merece la misma protección que tu hogar.

  • Cómo expulsar un backdoor persistente de tu instalación WordPress

    Cómo expulsar un backdoor persistente de tu instalación WordPress

    Cómo expulsar un backdoor persistente de tu instalación WordPress

    Un backdoor persistente en WordPress es uno de los problemas más serios que puede sufrir tu sitio. Cuando analizo una web comprometida, el backdoor es habitualmente el último recurso del atacante para mantener acceso indefinido, incluso después de cambiar contraseñas y actualizar plugins. En mi experiencia, estos accesos ocultos pueden permanecer meses sin detección si no sabes dónde buscar.

    Te voy a guiar a través del proceso completo de identificación y eliminación de backdoors persistentes, basándome en cientos de auditorías de seguridad que he realizado en WordPress.

    Qué es un backdoor persistente y por qué es tan peligroso

    Un backdoor persistente es código malicioso incrustado en tu instalación WordPress que permite al atacante acceder a tu sitio sin conocer las credenciales de usuario. Se diferencia de una simple cuenta comprometida en que permanece activo aunque cambies todas tus contraseñas.

    Los backdoors más comunes que encuentro en mis auditorías son:

    • Webshells: archivos PHP independientes (generalmente con nombres ocultos como «config.php.bak» o «upload.php») que permiten ejecutar comandos del sistema.
    • Código inyectado en wp-config.php: líneas maliciosas que crean usuarios administrativos automáticamente o abren puertas de acceso.
    • Hooks en functions.php de themes: funciones PHP que se ejecutan en cada carga de página y crean acceso remoto.
    • Opciones de base de datos modificadas: valores almacenados en wp_options que contienen código ejecutable.
    • Plugins maliciosos ocultos: plugins desactivados en el panel pero con código activo en la carpeta del servidor.
    • Modificaciones en .htaccess: reglas que redirigen solicitudes a scripts maliciosos o desactivan seguridad.

    La peligrosidad es extrema: mientras el backdoor esté activo, el atacante puede robar datos sensibles, modificar contenido, enviar spam desde tu dominio, instalar malware adicional o usarlo como pivote para atacar a tus clientes.

    Señales de alerta que delatan un backdoor

    Antes de buscar un backdoor, necesitas confirmar que realmente lo tienes. Estos son los síntomas más claros que he identificado en mis análisis:

    • Nuevo usuario administrativo que no creaste, visible en Usuarios > Administrador.
    • Cambios en archivos core de WordPress (wp-login.php, wp-admin/index.php) sin que hayas actualizado.
    • Plugins desactivados pero presentes en /wp-content/plugins/ que no reconoces.
    • Alertas de Google Search Console: «Contenido malicioso detectado» o «Sitio comprometido».
    • Redirecciones inesperadas a sitios de spam o phishing.
    • Consumo anormal de CPU/RAM sin causa aparente.
    • Logs de acceso (access.log) mostrando solicitudes extrañas a rutas inexistentes o con parámetros sospechosos.
    • Base de datos creciendo sin motivo o tablas con nombres extraños.

    Paso 1: Asegura el acceso al servidor antes de empezar

    El primer error que cometen muchos administradores es intentar limpiar el backdoor a través del panel de WordPress. Un backdoor sofisticado detectará esta actividad y puede destruir pruebas o crear accesos alternativos mientras estás trabajando.

    Lo que recomiendo siempre:

    1. Accede via SSH/SFTP directamente al servidor. Necesitas acceso de línea de comandos. Si solo tienes cPanel, usa el Terminal de cPanel o conecta por SSH con tus credenciales root.
    2. Haz una copia de seguridad completa del servidor. Copia toda la carpeta /home/usuario/public_html/ y la base de datos. Necesitarás referencia para análisis forense.
    3. Cambia todas las contraseñas de acceso: FTP/SFTP, SSH, cPanel, base de datos, cuenta de hosting. Hazlo desde otra red si es posible.
    4. Desconecta la web temporalmente. Si el backdoor está activo y lo sabes, considera tomar el sitio offline para evitar más robo de datos mientras limpias.

    Paso 2: Busca webshells ocultas en el servidor

    Las webshells son archivos PHP que el atacante sube directamente al servidor. En mis auditorías, suelen encontrarse en:

    • /wp-content/uploads/ (carpeta más grande, difícil de revisar manualmente)
    • /wp-content/plugins/nombreAleatorio/
    • Raíz del sitio con nombres como «shell.php», «admin.php», «config.php.bak»
    • Carpetas ocultas: /.well-known/, /.git/, /wp-admin/includes/

    Desde SSH, usa estos comandos para encontrarlas:

    Buscar todos los archivos PHP modificados en los últimos 30 días:

    find /home/usuario/public_html -name «*.php» -mtime -30 -ls | sort -k10

    Buscar archivos PHP en la carpeta de uploads (muy sospechoso):

    find /home/usuario/public_html/wp-content/uploads -name «*.php» -o -name «*.phtml» -o -name «*.php5»

    Buscar archivos ejecutables recientes en todo el sitio:

    find /home/usuario/public_html -type f ( -name «*.php» -o -name «*.php7» -o -name «*.phtml» ) -newer /home/usuario/public_html/wp-settings.php

    Cuando encuentres un PHP sospechoso, no lo ejecutes ni abras en el navegador. Examínalo en el servidor con:

    head -20 /ruta/archivo.php

    Un backdoor típico tendrá: eval(), system(), exec(), shell_exec(), passthru(), base64_decode(), o variables POST/GET que ejecutan código. Si ves estas funciones fuera de contexto, es malicioso. Bórralo:

    rm /ruta/archivo_malicioso.php

    Paso 3: Revisa wp-config.php y .htaccess

    El wp-config.php es un destino favorito para backdoors persistentes. Abre el archivo:

    cat /home/usuario/public_html/wp-config.php | grep -E «eval|system|exec|create_function|preg_replace.*/e»

    Busca líneas sospechosas. Un ejemplo de backdoor en wp-config.php que he visto frecuentemente:

    @eval($_POST[‘cmd’]); // Permite ejecutar código PHP vía POST

    O código ofuscado:

    @eval(base64_decode(‘c3lzdGVtKCRfUE9TVFsnd2EnXSk7’));

    Si encuentras algo así, edita el archivo (con nano o vi):

    nano /home/usuario/public_html/wp-config.php

    Elimina las líneas maliciosas. Luego revisa el .htaccess:

    cat /home/usuario/public_html/.htaccess

    Busca redirecciones sospechosas o reglas que no reconozcas. Un .htaccess limpio de WordPress contiene solo reglas de reescritura estándar. Si ves:

    • RewriteRule con dominios externos
    • Reglas que permiten acceso a archivos ejecutables en uploads
    • Redirecciones a sitios de spam

    Reemplaza el .htaccess completo con uno limpio desde wp-cli:

    wp rewrite flush –hard

    Paso 4: Analiza plugins y themes en busca de código inyectado

    Los backdoors frecuentemente se instalan modificando el archivo functions.php de un theme activo o un plugin. Necesitas revisar cada uno.

    Lista el theme activo:

    wp theme list –status=active

    Revisa el functions.php del theme activo:

    cat /home/usuario/public_html/wp-content/themes/NOMBREDELTHEME/functions.php | head -50

    Busca código sospechoso al inicio o final del archivo. Los backdoors suelen inyectarse al principio (después de <?php) o al final, antes del cierre.

    Haz lo mismo con cada plugin activo:

    wp plugin list –status=active

    cat /home/usuario/public_html/wp-content/plugins/NOMBREPLUGIN/NOMBREPLUGIN.php | head -50

    Si encuentras código sospechoso, tienes dos opciones:

    1. Si el plugin/theme es legítimo: Restaura la versión limpia desde wordpress.org. Primero desactiva y borra, luego reinstala limpio.
    2. Si no reconoces el plugin/theme: Bórralo completamente.

    Paso 5: Limpia la base de datos de opciones maliciosas

    Los atacantes sofisticados almacenan backdoors en la tabla wp_options. Estos se ejecutan mediante hooks y generan usuarios admin, redirigen contenido o crean backdoors adicionales.

    Conecta a la base de datos MySQL:

    mysql -u usuario_base_datos -p nombre_base_datos

    Busca opciones sospechosas:

    SELECT option_name, option_value FROM wp_options WHERE option_value LIKE ‘%eval%’ OR option_value LIKE ‘%base64_decode%’ OR option_value LIKE ‘%system(%’ LIMIT 20;

    Si encuentras algo, examínalo primero:

    SELECT * FROM wp_options WHERE option_id = XXX G

    Y bórralo:

    DELETE FROM wp_options WHERE option_id = XXX;

    También busca usuarios sospechosos:

    SELECT ID, user_login, user_email, user_registered FROM wp_users;

    Si hay un usuario que no creaste con rol de administrador, bórralo:

    DELETE FROM wp_users WHERE ID = XXX;

    Y elimina sus metadatos:

    DELETE FROM wp_usermeta WHERE user_id = XXX;

    Paso 6: Verifica logs de acceso en búsqueda de actividad maliciosa

    El access.log y error.log te muestran qué ha hecho el atacante. En mis auditorías, esta información es crucial para entender el alcance del compromiso.

    Busca solicitudes a archivos sospechosos:

    grep -E «.php?.*=» /home/usuario/public_html/../logs/access_log | grep -v «/wp-admin/» | tail -50

    Busca POST requests (típicas de webshells):

    grep «POST» /home/usuario/public_html/../logs/access_log | tail -50

    Documenta cualquier actividad sospechosa (IPs atacantes, fechas, archivos accedidos).

    Paso 7: Usa herramientas automáticas como verificación final

    Después de la limpieza manual, usa herramientas especializadas para confirmar que no quedan backdoors. Mi recomendación:

    WP-CLI Security Audit:

    wp plugin list –status=all

    wp theme list –status=all

    Verifica que no haya plugins/themes desactivados que no reconozcas.

    Wordfence CLI (si tienes licencia):

    wordfence scan

    Realiza un escaneo profundo de malware.

    Sucuri SiteCheck (online, gratuito): Sube tu sitio a sitecheck.sucuri.net para una segunda opinión independiente.

    Paso 8: Refuerza WordPress para evitar backdoors futuros

    Un backdoor regresa si tu seguridad es débil. Lo que implemento siempre en sitios post-compromiso:

    • Deshabilita la edición de archivos: Añade a wp-config.php: define(‘DISALLOW_FILE_EDIT’, true);
    • Cambia el prefijo de tablas de BD: De wp_ a algo como wp_a7k3_. Esto requiere un plugin especializado o acceso a la BD.
    • Protege wp-config.php: Usa .htaccess: <files wp-config.php> deny from all </files>
    • Implementa autenticación de dos factores (2FA): Usa Wordfence, Google Authenticator o similar.
    • Limita intentos de login: Máximo 5 intentos en 15 minutos. Wordfence o iThemes Security lo hacen automáticamente.
    • Actualiza WordPress, plugins y themes regularmente. Los backdoors entran por agujeros de seguridad conocidos.
    • Revisa permisos de carpetas: wp-content/uploads debe ser 755, no 777.

    Paso 9: Valida que el backdoor está completamente eliminado

    Después de 48 horas de la limpieza, realiza una verificación final:

    1. Inicia sesión en WordPress. Verifica que no hay usuarios sospechosos.
    2. Revisa Google Search Console. Elimina manualmente cualquier URL sospechosa flagged como maliciosa.
    3. Ejecuta nuevamente el escaneo de Sucuri SiteCheck. Debe estar limpio.
    4. Revisa access.log nuevamente. No debe haber solicitudes maliciosas recientes.
    5. Haz un backup limpio. Este será tu referencia para futuras comparaciones.

    Cuándo llamar a un profesional

    Si durante este proceso encuentras:

    • Múltiples backdoors entrelazados que vuelven a aparecer tras eliminarlos
    • Base de datos completamente comprometida (muchas opciones maliciosas)
    • Código ofuscado que no puedes descifrar
    • Cambios en la raíz del servidor fuera de la carpeta web
    • Tu proveedor de hosting ha detectado malware y amenaza con suspender el sitio

    Es momento de obtener ayuda profesional. En ManuelFolgar.com realizamos auditorías completas de seguridad y limpieza garantizada de backdoors, con análisis forense incluido.

    Resumen final: tu checklist de acción

    Aquí está el plan paso a paso que debes seguir:

    1. Accede al servidor via SSH, cambia contraseñas, haz backup completo.
    2. Busca webshells con find y comandos grep.
    3. Revisa wp-config.php y .htaccess línea por línea.
    4. Analiza functions.php de theme y todos los plugins.
    5. Limpia la BD de opciones y usuarios maliciosos con MySQL.
    6. Revisa logs de acceso para entender el compromiso.
    7. Ejecuta herramientas automáticas (WP-CLI, Wordfence, Sucuri).
    8. Implementa hardening de seguridad.
    9. Valida la limpieza con verificaciones finales.

    Un backdoor persistente es serio, pero eliminable si actúas rápido y metódicamente. La mayoría de propietarios de sitios comprometen su seguridad precisamente porque no saben por dónde empezar. Tú ahora sí.

    Si necesitas ayuda profesional en cualquier paso de este proceso, contacta conmigo en ManuelFolgar.com. Realizo análisis forense completo, eliminación garantizada de backdoors y hardening de WordPress para evitar que vuelvan.

  • Qué es el malware polimórfico y cómo afecta WordPress

    Qué es el malware polimórfico y cómo afecta WordPress

    Qué es el malware polimórfico y por qué es una amenaza crítica para WordPress

    En mi experiencia analizando miles de sitios WordPress comprometidos, el malware polimórfico es una de las amenazas más silenciosas y destructivas que existen. A diferencia de un backdoor convencional que mantiene siempre la misma firma de código, el malware polimórfico se regenera y cambia constantemente para evadir los sistemas de detección. Cada vez que se ejecuta, modifica su propio código manteniendo la misma funcionalidad maliciosa.

    ¿Por qué esto es tan peligroso para tu WordPress? Porque las herramientas antimalware tradicionales —incluso las más sofisticadas como Wordfence o MalCare— se basan en detectar firmas de código conocidas. Si el malware cambia su estructura cada pocas horas, las defensas se vuelven prácticamente inútiles. He visto sitios comprometidos donde los scanners reportaban «limpio» mientras el atacante robaba datos de clientes desde un webshell invisible.

    Cómo funciona el malware polimórfico: el motor de mutación

    El malware polimórfico contiene un motor de mutación —código que se reescribe a sí mismo— sin cambiar su lógica principal. Imagina un backdoor que encripta su payload de formas diferentes cada ejecución, o que cambia los nombres de sus funciones automáticamente. Así logra burlar firmas estáticas.

    Los mecanismos más comunes que veo en WordPress son:

    • Ofuscación dinámica: El código se encripta con claves que varían en cada instancia. Cuando lo analizan en un sandbox, usa una clave diferente que en el servidor real.
    • Inyección en archivos legítimos: Se integra dentro de funciones normales de WordPress (functions.php, index.php del tema) pero cambia su posición y estructura constantemente.
    • Uso de variables polifilmórficas: El código genera nombres de variables al azar en tiempo de ejecución, imposibilitando el pattern matching.
    • Envío remoto de payload: Descarga código malicioso desde servidores C2 (Command & Control) en fragmentos que se reensamblan en memoria, sin dejar rastro en disco.

    Lo más peligroso que he encontrado son variantes que se adaptan detectando el entorno: si identifican que un scanner está analizando el sitio, desactivan la funcionalidad maliciosa temporalmente. Vuelven a activarse después. Es como tener un intruso que se duerme cuando ve que lo estás buscando.

    Vectores de entrada del malware polimórfico en WordPress

    Ahora bien, ¿cómo llega este malware a tu sitio? Los vectores no son diferentes a los del malware estándar, pero los atacantes que usan polimórficos suelen ser más sofisticados:

    Plugins y temas nulled o desactualizados

    Cuando descargo un tema nulled o de fuentes no oficiales, obtengo malware gratis. Los desarrolladores maliciosos integran puertas traseras polimórficas directamente en el código. Hace poco analicé un cliente que usaba la versión «pirateada» de un tema premium: contenía un downloader polimórfico que inyectaba código diferente en cada página que visitaban los usuarios.

    Vulnerabilidades sin parchear en plugins populares

    Un plugin desactualizado con una falla de carga de archivos (LFI/RFI) es la puerta de entrada perfecta. El atacante sube un php que genera el malware polimórfico directamente en el servidor. Hace poco vimos campañas que aprovechaban CVEs en plugins de formularios y backup para inyectar webshells que se regeneraban cada 10 minutos.

    Fuerza bruta contra wp-admin y wp-login.php

    Aunque parezca anticuado, sigue siendo efectivo. Con credenciales robadas, suben temas maliciosos o modifican functions.php. He visto casos donde el malware polimórfico se activaba solo después de 48 horas de acceso, dificultando la correlación causa-efecto.

    Inyección SQL en búsquedas personalizadas o plugins obsoletos

    Algunos plugins de búsqueda avanzada o de integración con bases de datos externas tienen fallos de sanitización. Un atacante puede inyectar código SQL que escribe archivos PHP maliciosos directamente en el servidor. Estos archivos contendrán el motor polimórfico.

    Supply chain attacks: actualizaciones comprometidas

    Aunque raro, he documentado casos donde repositorios legales fueron vulnerados. El usuario descargaba una «actualización» legítima que contenía malware polimórfico. Es el escenario más difícil de detectar porque el código entra por la ruta oficial.

    Cómo detectar malware polimórfico en tu WordPress (métodos prácticos)

    La detección basada en firmas falla. Aquí es donde debo ser honesto: no existe un método 100% fiable. Pero hay indicadores comportamentales que te ayudarán:

    Análisis de rendimiento y consumo de recursos

    El malware polimórfico requiere CPU para regenerarse. Si tu sitio WordPress está lento sin razón aparente, o los logs de error muestran procesos PHP de larga ejecución a horas extrañas, investiga. He encontrado miners polimórficos que solo se activaban entre las 3 y las 5 de la mañana para evitar detección.

    Auditoría de logs y permisos de archivos

    Ejecuta un comando WP-CLI para revisar cambios recientes:

    wp shell-exec «find /var/www/html/wp-content -type f -mtime -7 -name ‘*.php’ | head -20»

    Busca archivos PHP modificados en la última semana que no sean actualizaciones esperadas. El malware polimórfico debe escribir en el servidor para persistir.

    Análisis con herramientas especializadas

    Wordfence y MalCare incluyen heurísticas comportamentales (no solo firmas). Si ambas reportan «limpio» pero tienes sospechas, usa VirusTotal para escanear archivos PHP específicos. Sube también tus logs de acceso para análisis.

    Revisión de Google Search Console

    Si Google ha detectado malware en tu sitio, recibirás alertas. El malware polimórfico a menudo deja rastros en las alertas de Search Console antes de que tú lo notes localmente, porque Google tiene mejor visibilidad de comportamientos maliciosos.

    Análisis de tráfico anómalo

    Usa Google Analytics o Matomo para detectar patrones raros: picos de tráfico a /wp-json/, accesos a archivos admin sin usuarios registrados, o requests a rutas que no existen. El malware polimórfico realiza «llamadas de hogar» (contacto con servidores C2) que se verán como tráfico extraño.

    Impacto real: qué hace el malware polimórfico en WordPress

    Ahora que entiendes cómo funciona, te muestro el daño real:

    • Robo de datos de clientes: Skimmers polimórficos (Magecart-like) capturan tarjetas de crédito. He visto tiendas online comprometidas que perdían datos de 100+ transacciones antes de detección.
    • Minería de criptomonedas: Se ejecuta en background, usando CPU de tu servidor. Tus costos de hosting se triplican, y el usuario final ve un sitio lentísimo.
    • SEO poisoning: Inyecta spam de enlaces o contenido oculto. Tu ranking en Google cae, y buscas el motivo durante meses sin éxito.
    • Distribución de malware a visitantes: El sitio se convierte en distribuidor involuntario de malware a otros usuarios.
    • Backdoors persistentes: Aunque limpies un malware polimórfico, el atacante tiene múltiples puertas traseras. Vuelve a entrar en días.
    • Pérdida de reputación: Navegadores marcan tu sitio como «peligroso». Clientes y motores de búsqueda lo evitan.

    Estrategia de hardening contra malware polimórfico

    La prevención es tu mejor defensa. Aquí están las medidas que recomiendo siempre:

    Actualización inmediata de todo

    WordPress core, plugins, temas. Sin excepciones. El 95% de los casos de malware polimórfico entran por vulnerabilidades conocidas. Usa WordPress.org para seguir advisories.

    Cambio de prefijo de tabla y deshabilitar edición de archivos

    En wp-config.php:

    define(‘DISALLOW_FILE_EDIT’, true);

    Esto impide que un atacante con acceso admin edite functions.php. Cambia el prefijo de tabla (por defecto wp_) a algo aleatorio. Limita el daño de inyecciones SQL.

    Protección de wp-config.php y .htaccess

    En tu .htaccess:

    <Files wp-config.php>
    order allow,deny
    deny from all
    </Files>

    Protege este archivo de accesos directos. El malware polimórfico busca credenciales de BD aquí.

    Limitación de intentos de login y 2FA

    Limita intentos de login a 5 por minuto por IP. Implementa autenticación de dos factores (2FA) con un plugin como Wordfence. Así bloqueas la puerta de entrada más común.

    Monitoreo en tiempo real con CSP y HSTS

    Implementa Content Security Policy (CSP) para prevenir inyecciones de scripts. En tu servidor (nginx o Apache):

    add_header Content-Security-Policy «default-src ‘self’;» always;

    HSTS obliga a conexiones HTTPS, evitando Man-in-the-Middle que inyecten malware:

    add_header Strict-Transport-Security «max-age=31536000; includeSubDomains» always;

    Auditorías de seguridad periódicas

    Realiza auditorías cada 3 meses. Revisa permisos de carpetas (wp-content debe ser 755, archivos 644), analiza logs de acceso, ejecuta scripts de integridad de archivos.

    Qué hacer si ya estás comprometido

    Si sospechas que tu WordPress tiene malware polimórfico, estos son los pasos inmediatos:

    1. No entres en pánico, pero actúa rápido: El malware polimórfico se regenara cada hora si no cortas su acceso.
    2. Aísla el sitio: Toma una copia de seguridad completa (para análisis posterior), luego desconecta el sitio del público si es posible.
    3. Cambiar todas las contraseñas: WordPress admin, FTP/SFTP, base de datos, hosting. El atacante tiene acceso.
    4. Scannea con múltiples herramientas: Wordfence, MalCare, Sucuri SiteCheck. Si uno falla, otro puede detectar patrones comportamentales.
    5. Revisa los logs: Busca archivos PHP creados recientemente, cambios en functions.php, uploads anómalos. Los webshells dejan rastro en logs de acceso (POST a archivos que no hacen GET, por ejemplo).
    6. Limpieza manual: Si identificas archivos maliciosos, elimínalos. Pero recuerda: el motor polimórfico puede haber puesto múltiples puertas traseras. Una limpieza superficial es insuficiente.
    7. Restauración segura: Restaura desde un backup anterior a la infección. Si no tienes, necesitas ayuda profesional.

    He limpiado cientos de WordPress comprometidos. En el 70% de los casos donde el cliente intenta DIY, el malware vuelve en una semana porque hay backdoors residuales que no vieron.

    Recursos adicionales y referencias técnicas

    Para profundizar en malware polimórfico y seguridad WordPress, te recomiendo consultar:

    Finalmente, recuerda que el malware polimórfico es una amenaza sofisticada que requiere un enfoque multicapa. No confíes en una única herramienta ni en una única auditoría. La vigilancia continua, las actualizaciones constantes y los backups robustos son tu mejor escudo.

    Si crees que tu WordPress está comprometido o quieres una auditoría de seguridad profesional, ponte en contacto conmigo. Ofrezco análisis forense completo, limpieza garantizada y hardening posterior para evitar reinfecciones. Accede aquí para solicitar tu auditoría de seguridad en ManuelFolgar.com.

  • Solucionar errores de upload en WordPress sin perder seguridad

    Solucionar errores de upload en WordPress sin perder seguridad

    Errores de upload en WordPress: por qué ocurren y cómo resolverlos sin comprometer seguridad

    Cuando trabajas con WordPress, los errores de upload son de los problemas más frustrantes que encontrarás. Te intentas subir una imagen, un PDF o un plugin, y de repente: «Ha ocurrido un error al subir el archivo» o «El tipo de archivo no es permitido». Lo primero que haces es buscar una solución rápida, ¿verdad? El problema es que muchas de esas soluciones que encuentras online te dejan la puerta abierta a ataques.

    En mi experiencia auditando sitios WordPress comprometidos, he visto una pauta clara: muchos administradores deshabilitaron filtros de seguridad o ampliaron permisos de forma excesiva para que los uploads funcionaran. El resultado fue que seis meses después, el servidor alojaba un webshell o un backdoor. No queremos eso para ti.

    En este artículo te muestro cómo solucionar estos errores manteniendo tu WordPress protegido. Empezaremos por entender por qué suceden, luego iremos escalando hasta las soluciones más técnicas, y siempre poniendo la seguridad en primer plano.

    Las causas más comunes de errores de upload en WordPress

    1. Límites de tamaño de archivo insuficientes

    WordPress tiene un límite de tamaño máximo para archivos subidos, heredado de la configuración PHP del servidor. Si intentas subir un archivo más grande que el límite (habitualmente 64 MB), WordPress rechazará la carga sin importar que tu servidor tenga espacio.

    Esto es especialmente común con vídeos, archivos de backup o conjuntos grandes de imágenes. La buena noticia es que aumentar este límite es seguro si lo haces de forma controlada.

    2. Permisos de carpeta incorrectos

    La carpeta /wp-content/uploads necesita permisos de escritura para que WordPress guarde los archivos. Si los permisos están mal configurados (habitualmente 755 o superior), WordPress no podrá escribir en ella. Verás un error genérico que no ayuda mucho a diagnosticar el problema real.

    3. Restricciones de tipo de archivo demasiado estrictas

    WordPress filtra qué tipos de archivo permite subir. Por defecto, acepta imágenes, documentos y otros medios comunes. Si instalas un plugin de seguridad agresivo o modificas el código, es posible que bloquee archivos legítimos.

    4. Configuración de multisite deficiente

    Si usas WordPress en modo multisite, cada subdominio o sitio tiene su propia carpeta de uploads. Los permisos y configuración de PHP-FPM pueden no aplicarse correctamente a todos ellos, dejando algunos sitios sin capacidad de upload.

    5. Problemas de propietario de archivos (ownership)

    En servidores compartidos o con configuración de PHP-FPM, los archivos deben ser propiedad del usuario PHP correcto. Si el propietario no coincide (por ejemplo, «www-data» vs. «apache»), WordPress no podrá escribir aunque los permisos parezcan correctos.

    Soluciones seguras: paso a paso

    Paso 1: Verifica los límites PHP sin tocar nada peligroso

    Primero, mira cuál es el límite actual. Accede a tu WordPress, ve a Herramientas > Estado del sitio, y busca «Límite de tamaño de subida de archivos». Anotalo.

    Si necesitas aumentarlo, hazlo de forma segura editando tu archivo wp-config.php. Añade estas líneas antes de la línea «/* Eso es todo, ¡para editar sus archivos vaya a FTP/SFTP! */»:

    define('WP_MEMORY_LIMIT', '256M');
    define('WP_MAX_MEMORY_LIMIT', '512M');

    Estos valores aumentan la memoria disponible para operaciones de upload, pero de forma controlada. No los hagas arbitrariamente grandes (por ejemplo, 2GB) porque entonces consumirás recursos innecesarios.

    Si usas un servidor Apache, puedes también crear o editar un archivo .htaccess en la raíz con:

    php_value post_max_size 256M
    php_value upload_max_filesize 256M
    php_value max_execution_time 300

    Esto es especialmente útil si tu proveedor de hosting no te deja acceder a php.ini.

    Paso 2: Asegura los permisos de carpetas correctamente

    La carpeta /wp-content/uploads debe tener permisos 755 (lectura, escritura y ejecución para propietario; lectura y ejecución para grupo y otros). Las subcarpetas también deben ser 755, y los archivos dentro deben ser 644.

    Si tienes acceso FTP o SFTP (lo que recomiendo siempre), conecta con tu cliente preferido (Filezilla, Cyberduck) y navega a /wp-content/uploads. Haz clic derecho, selecciona «Cambiar permisos» y establece 755.

    Si prefieres usar línea de comandos (SSH), conecta a tu servidor y ejecuta:

    find /ruta/a/wp-content/uploads -type d -exec chmod 755 {} ;
    find /ruta/a/wp-content/uploads -type f -exec chmod 644 {} ;

    Nota de seguridad importante: nunca hagas las carpetas 777. He visto servidores comprometidos precisamente por eso. 755 es más que suficiente.

    Paso 3: Verifica el propietario de los archivos (ownership)

    En algunos servidores, especialmente con PHP-FPM, el problema no es el permiso sino quién «posee» los archivos. Conecta por SSH y ejecuta:

    ls -la /ruta/a/wp-content/uploads

    Mira la tercera y cuarta columna. Debería decir algo como «www-data www-data» o «www www-data». Si dice «root root» o algo completamente diferente, los uploads fallarán.

    Para corregirlo (como usuario root o con sudo):

    chown -R www-data:www-data /ruta/a/wp-content/uploads

    Cambia «www-data» por el usuario PHP real en tu servidor. Si no sabes cuál es, pregunta a tu proveedor de hosting o consulta tu configuración de PHP-FPM.

    Paso 4: Revisa las restricciones de tipo de archivo

    WordPress permite ciertos tipos de archivo por defecto. Si necesitas permitir tipos adicionales, hazlo de forma controlada. Nunca permitas ejecutables (.exe, .sh, .php) en la carpeta de uploads.

    Para añadir tipos de archivo seguros, edita wp-config.php y añade (antes de la línea de «Eso es todo»):

    define('ALLOW_UNFILTERED_UPLOADS', false);

    Esto mantendrá WordPress filtrando incluso si eres administrador. Luego, si necesitas tipos específicos, usa un plugin confiable como File Manager o crea un filtro en tu tema hijo:

    add_filter('upload_mimes', function($mimes) {
    $mimes['svg'] = 'image/svg+xml';
    $mimes['webp'] = 'image/webp';
    return $mimes;
    });

    Esto es seguro porque solo añade tipos MIME específicos que WordPress puede validar correctamente.

    Paso 5: Protege la carpeta de uploads con .htaccess

    Aunque la carpeta de uploads debe permitir lectura, no debería permitir la ejecución de scripts PHP. Crea o edita el archivo .htaccess en /wp-content/uploads/ y añade:

    <FilesMatch ".(php|php3|php4|php5|php6|php7|php8|phtml)$">
    Deny from all
    </FilesMatch>

    Esto bloquea cualquier intento de ejecutar archivos PHP subidos. Incluso si un atacante logra meter un archivo PHP, no podrá ejecutarlo.

    También añade esta línea para desactivar la interpretación de scripts en esa carpeta:

    php_flag engine off

    Paso 6: Usa una herramienta de diagnóstico

    Si después de todos estos pasos aún tienes errores, usa WP-CLI para diagnosticar:

    wp core verify-checksums
    wp cap list --user=your_admin_user

    También puedes instalar el plugin Health Check & Troubleshooting (gratuito) que te mostrará exactamente qué está fallando.

    Soluciones adicionales para casos complejos

    Aumenta el tiempo de ejecución para uploads grandes

    Si subes archivos muy grandes, PHP puede «timeout» antes de terminar. En .htaccess:

    php_value max_execution_time 600

    600 segundos (10 minutos) es generoso. Ajusta según tus necesidades, pero nunca lo hagas infinito (0).

    Usa un plugin de gestión de uploads seguro

    Si necesitas control granular sobre uploads (por ejemplo, restringir por rol de usuario), usa Admin Columns o Wordfence, que incluyen logging de uploads. Esto es especialmente importante si múltiples usuarios suben archivos. Sabrás exactamente quién subió qué y cuándo.

    Configura un CDN seguro para archivos medianos y grandes

    Si regularmente necesitas subir vídeos o archivos grandes, considera un CDN como Cloudflare o BunnyCDN. Esto no solo resuelve limites de PHP, sino que distribuye la carga y protege tu servidor contra ataques volumétricos dirigidos a uploads.

    Errores comunes a evitar

    ❌ No hagas nunca las carpetas 777

    He visto esto demasiadas veces. Un «técnico» dice «establece permisos 777 en wp-content». No lo hagas. 755 funciona perfectamente y es exponencialmente más seguro.

    ❌ No instales plugins «nulled» o de fuentes desconocidas para resolver uploads

    Si Google te dirige a un plugin descargado de un sitio raro para «solucionar uploads», no lo hagas. Especialmente no lo hagas si el plugin se llama «Upload Manager Pro» o similar en una URL sospechosa. Muchos de esos plugins son Troianos que parecen legítimos.

    ❌ No desactives WordPress.org como fuente de plugins

    Tu WordPress debería instalar plugins únicamente desde WordPress.org o desde desarrolladores verificados. Desactivar esa restricción abre la puerta a malware masivamente.

    ❌ No hagas editable wp-config.php desde el navegador

    WordPress permite editar wp-config.php desde el panel si los permisos lo permiten. Deshabilítalo en tu .htaccess:

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

    Verificación de seguridad post-solución

    Una vez que hayas resuelto los errores de upload, asegúrate de que no has introducido vulnerabilidades. Ejecuta estos pasos:

    1. Escanea con Wordfence: Instala y ejecuta un escaneo completo. Busca permisos inseguros, plugins problemáticos o cambios sospechosos.
    2. Revisa los logs: Si tienes acceso a logs de Apache o Nginx, busca intentos fallidos de acceso a archivos .php en /uploads/.
    3. Valida con VirusTotal: Sube el archivo wp-config.php a VirusTotal para asegurarte de que no contiene código malicioso (aunque debería, porque lo acabas de editar tú).
    4. Comprueba en Google Search Console: Mira si Google ha detectado malware o problemas de seguridad en tu sitio. A veces, uploads comprometidos triggean alertas automáticas.

    Recomendaciones finales y buenas prácticas

    Los errores de upload no son un problema de seguridad en sí. El problema de seguridad es cómo resuelves esos errores. Por eso:

    • Mantén WordPress, plugins y temas actualizados. Las vulnerabilidades de upload a menudo se explotan a través de plugins desactualizados.
    • Usa 2FA en tu cuenta de administrador. Incluso si alguien consigue tu contraseña, no podrá acceder al panel sin el segundo factor.
    • Implementa Content Security Policy (CSP). Añade a tu .htaccess: Header set Content-Security-Policy "script-src 'self'; object-src 'none';". Esto previene que scripts inyectados se ejecuten.
    • Haz backups regulares. Si algo sale mal, podrás restaurar desde un punto limpio. Usa un plugin como UpdraftPlus o BackWPup que se integre bien con tu hosting.
    • Monitoriza uploads por correo. Configura logs que te notifiquen cuando alguien sube un archivo. Esto te ayudará a detectar comportamiento sospechoso rápidamente.

    Cuándo pedir ayuda profesional

    Si después de seguir estos pasos aún tienes errores de upload, o si sospechas que tu servidor ya está comprometido, es hora de llamar a un profesional. En mi experiencia, los problemas de upload a veces están relacionados con configuración más profunda del servidor, entornos PHP-FPM mal configurados, o incluso infecciones previas que interfieren con el funcionamiento normal.

    Un audit profesional no solo resuelve los errores de upload, sino que te da una visión completa de la seguridad de tu WordPress, detecta backdoors ocultos, y te proporciona un plan de hardening personalizado.

    Contacta conmigo en ManuelFolgar.com si necesitas una auditoría de seguridad profesional o si tus errores de upload persisten después de estas soluciones. Evaluaremos tu sitio de forma integral y resolveremos no solo los síntomas, sino la causa raíz del problema.