Categoría: Blog

  • Error de parseador: malware en tema o plugin WordPress

    Error de parseador: malware en tema o plugin WordPress

    ¿Qué es el error de parseador en WordPress y por qué aparece malware?

    Cuando ves el mensaje «Error de parseador» en tu sitio WordPress, estás ante una de las señales más claras de que algo falla en la sintaxis de tu código PHP. En mi experiencia analizando cientos de sitios comprometidos, este error suele ser la punta del iceberg: detrás hay casi siempre un plugin o tema malicioso, o una infección que ha modificado archivos críticos.

    El parseador de PHP es el encargado de interpretar el código antes de ejecutarlo. Cuando encuentra un error de sintaxis —paréntesis sin cerrar, comillas mal colocadas, o código inyectado maliciosamente— detiene la ejecución y lanza esta advertencia. El problema es que los atacantes suelen insertar código obfuscado o mal formado a propósito para evitar detección, y eso genera exactamente este error.

    Lo he visto con webshells backdoor, cryptominers inyectados en temas nulled, y redirecciones SEO maliciosas. El malware no siempre es «limpio» desde el punto de vista del parseador.

    Diferencia entre error de parseador legítimo y malware

    Error de parseador accidental (actualización o conflicto)

    A veces el error es inocente: acabas de actualizar un plugin, hay incompatibilidad entre versiones, o instalaste un tema mal optimizado. Estos errores aparecen en tu log de errores (wp-content/debug.log) con información clara sobre la línea exacta del problema.

    • Mensión específica: «Parse error in /wp-content/plugins/plugin-name/file.php on line 42»
    • Ocurre tras una actualización reciente
    • El archivo problemático está en la rama de un plugin o tema legítimo
    • Se resuelve desactivando ese elemento específico

    Error de parseador por malware

    Aquí es donde empieza la preocupación real. El malware intenta ocultarse, pero su código inyectado fuerza errores de sintaxis. Lo reconozco cuando:

    • El error aparece sin haber hecho cambios recientes
    • La línea problemática contiene código ofuscado, base64, o caracteres sospechosos
    • El archivo afectado no pertenece a ningún plugin/tema instalado (está en la raíz, en wp-includes, o en directorios ocultos)
    • Multiplicas desactivaciones y el error persiste o reaparece
    • Aparecen archivos .php nuevos en carpetas que no debería haberlos

    Cómo identificar malware en temas y plugins WordPress

    Paso 1: Revisa los logs de error de WordPress

    Activa el modo debug en wp-config.php si no lo está. Añade estas líneas antes de la línea «That’s all, stop editing!»:

    define('WP_DEBUG', true);
    define('WP_DEBUG_DISPLAY', false);
    define('WP_DEBUG_LOG', true);

    Luego accede a wp-content/debug.log y busca patrones como «eval()», «base64_decode», «assert», «system()», «exec()», «passthru()», «shell_exec()». Estas funciones son firmas claras de malware.

    Paso 2: Auditoria de plugins y temas instalados

    Usa WP-CLI para listar todos los plugins activos e inactivos:

    wp plugin list --field=name

    Luego verifica en WordPress.org que existan oficialmente. Si encuentras alguno que no esté en el repositorio oficial, lo más probable es que sea un nulled malicioso o una customización con inyecciones.

    Haz lo mismo con temas:

    wp theme list --field=name

    Paso 3: Búsqueda de código malicioso en archivos

    En mi experiencia, los atacantes casi siempre dejan rastros. Conéctate por SFTP o accede al gestor de archivos y busca:

    • Archivos .php con nombres raros en wp-content/ (como config.php, admin.php, setup.php, index0.php)
    • Archivos en la raíz del sitio que no creaste (xmlrpc-backup.php, wp-load-advanced.php)
    • Carpetas ocultas dentro de wp-content/plugins o wp-content/themes (como .shell, .config, ..admin)
    • Permisos 777 en archivos que deberían ser 644

    Si tienes acceso SSH, puedes buscar rápidamente código sospechoso:

    grep -r "eval(" wp-content/plugins/
    grep -r "base64_decode" wp-content/themes/
    find . -name "*.php" -exec grep -l "<?php @" {} ;

    Paso 4: Análisis con herramientas especializadas

    Wordfence CLI es mi favorita para esto. Desde línea de comandos:

    wordfence cli scan --dir=/var/www/html/wp-content

    También puedes usar Sucuri SiteCheck para un análisis rápido sin acceso técnico. Sube tu sitio o URL y te dirá si hay malware detectado por firmas.

    El problema específico de los temas y plugins nulled

    En mis auditorías, el 40% de las infecciones por malware vienen de temas o plugins descargados de sitios «nulled» o cracks. Estos archivos están inyectados con:

    • Backdoors de acceso: código que permite al atacante entrar sin credenciales válidas
    • Cryptominers silenciosos: código que usa los recursos de tu servidor para minar criptomonedas
    • Redirectores SEO: alteran los enlaces internos o redirigen visitantes a otros sitios
    • Skimmers de tarjetas (Magecart): en tiendas online, roban datos de pago
    • Inyectores de anuncios: insertan publicidad no autorizada en tu contenido

    El error de parseador aparece porque ese código inyectado no está «pulido». Los atacantes lo obfuscan rápidamente y sin cuidado de la sintaxis final.

    ¿Cómo reparar el error de parseador?

    Opción segura: desactivar el plugin o tema sospechoso

    Si sospechas de un plugin específico, accede a wp-admin/plugins.php en tu navegador o usa WP-CLI:

    wp plugin deactivate nombre-del-plugin

    ¿Desaparece el error? Entonces ese era el culpable. No lo vuelvas a activar sin antes inspeccionarlo línea por línea o reemplazarlo por una versión legítima descargada de WordPress.org.

    Opción nuclear: recuperar desde backup limpio

    Si hay múltiples errores de parseador, o si los logs muestran código inyectado en archivos de WordPress (wp-config.php, wp-load.php, funciones.php), lo más seguro es restaurar desde un backup anterior a la infección. En mi experiencia, limpiar manualmente WordPress comprometido es arriesgado: siempre queda código dormido.

    Limpiar código inyectado (solo si tienes experiencia)

    Si identificas un archivo específico y ves la inyección (por ejemplo, código eval() al final de un archivo functions.php), puedes editarlo con cuidado:

    • Descarga el archivo por SFTP
    • Abre con un editor de texto seguro (Sublime Text, VS Code, no Notepad)
    • Busca funciones sospechosas: eval(), assert(), base64_decode(), system(), exec()
    • Elimina solo esas líneas, deja el resto intacto
    • Vuelve a subir el archivo
    • Verifica en wp-admin que el error desaparece

    Pero te aviso: si no estás 100% seguro, no lo hagas. Un pequeño error elimina contenido importante o deja backdoors abiertos.

    Prevención: hardening para evitar el error de parseador por malware

    1. Desactiva la edición de archivos en WordPress

    Añade a wp-config.php:

    define('DISALLOW_FILE_EDIT', true);

    Esto impide que un atacante que gane acceso al wp-admin pueda editar temas o plugins directamente. Tienen que usar SFTP o shell.

    2. Usa solo plugins y temas de fuentes oficiales

    Nunca descargues temas o plugins de sitios nulled, aun si son gratis. Los repositorios oficiales de WordPress tienen revisión de código. Los sitios de cracks no.

    3. Mantén WordPress, plugins y temas actualizados

    Las actualizaciones cierren vulnerabilidades que los atacantes explotan para inyectar código. Configura actualizaciones automáticas:

    define('AUTOMATIC_UPDATER_DISABLED', false);

    4. Implementa un WAF o firewall de aplicación web

    Un WAF como Sucuri WAF o Cloudflare bloquea inyecciones SQL, XSS, y otras técnicas antes de que lleguen a tu servidor. Reduce enormemente el riesgo de parseador errors por malware.

    5. Cambia los permisos de archivos correctamente

    Los archivos PHP deben estar en 644, las carpetas en 755. Nunca uses 777. Verifica con:

    find wp-content -type f -exec chmod 644 {} ;
    find wp-content -type d -exec chmod 755 {} ;

    6. Protege wp-config.php con una regla .htaccess adicional

    Añade al archivo .htaccess de tu raíz:

    <FilesMatch "^wp-config.php$">
    Order allow,deny
    Deny from all
    </FilesMatch>

    Esto previene acceso directo a tu archivo más sensible, aunque ya no debería ser accesible desde la web.

    ¿Cuándo necesitas ayuda profesional?

    Si después de revisar logs, desactivar plugins y buscar código malicioso el error persiste, o si no tienes experiencia con PHP y análisis de seguridad, es momento de contactar especialistas. En mi trabajo como auditor, encuentro malware que los propios usuarios no ven porque está:

    • Dentro de archivos wp-includes/ modificados (muy peligroso tocar)
    • Codificado en múltiples capas de base64 y obfuscación
    • Dentro de la base de datos (options, posts, postmeta) en lugar de archivos
    • En módulos o librerías de terceros que llamadas desde plugins legítimos

    Un análisis forense profesional incluye: extracción de IOCs (indicadores de compromiso), identificación de vector de entrada, limpieza completa, refuerzo de permisos, y monitoreo post-limpieza para confirmar que no reingresan.

    Resumen: cómo actuar ante el error de parseador

    1. Activa WP_DEBUG y revisa wp-content/debug.log buscando funciones maliciosas
    2. Lista plugins y temas, verifica que existan en WordPress.org oficial
    3. Busca archivos .php sospechosos en wp-content/, wp-includes/, raíz
    4. Desactiva plugins problemáticos uno a uno
    5. Si el error continúa o es crítico, restaura desde backup limpio anterior
    6. Implementa las medidas de hardening descritas
    7. Si no resuelves en 24 horas, solicita auditoría profesional

    El error de parseador no es solo un problema de código malo; es casi siempre un síntoma de que tu seguridad ha fallado. Tratarlo como un verdadero incidente de ciberseguridad, no como un simple error técnico, es lo que marca la diferencia entre un sitio limpio y uno que se reinecta en cuestión de semanas.

    Si sospechas que tu WordPress está comprometido o quieres un análisis profesional de seguridad, te invito a que contactes conmigo en ManuelFolgar.com. Ofrezco auditorías de ciberseguridad, limpiezas de malware y hardening para WordPress y PrestaShop, con informe detallado y seguimiento posterior.

  • Por qué los atacantes provocan errores deliberadamente en WordPress

    Por qué los atacantes provocan errores deliberadamente en WordPress

    Por qué los atacantes provocan errores deliberadamente en WordPress

    Cuando analizo un sitio WordPress comprometido, uno de los patrones que más frecuentemente encuentro es la presencia de errores deliberados sembrados por los atacantes. No es casualidad, ni tampoco negligencia. Es una estrategia sofisticada que forma parte del arsenal de cualquier ciberdelincuente profesional. En mi experiencia, entender por qué ocurre esto es fundamental para proteger tu sitio y detectar intrusiones antes de que causen daños irreversibles.

    Los errores no son bugs accidentales. Son herramientas. Funcionan como radar, como coartada, como distracción y como puerta trasera. Si tu sitio muestra errores PHP, fallos de base de datos o pantallas blancas de muerte, es posible que ya hayas sido atacado sin saberlo.

    Errores como mecanismo de reconocimiento y mapeo

    Cuando un atacante infiltra tu WordPress, lo primero que necesita es entender la arquitectura de tu servidor. Los errores PHP son como una brújula que le muestra exactamente qué tecnologías usas, qué versiones están instaladas y dónde están tus archivos sensibles.

    Cómo funciona el mapeo mediante errores

    Un atacante inyecta código deliberadamente malformado en tu sitio. Cuando ese código se ejecuta, WordPress o PHP devuelven un error que incluye:

    • Rutas de archivos completas: «/home/usuario/public_html/wp-content/plugins/plugin-vulnerable/archivo.php línea 45». Esto le muestra exactamente dónde está tu instalación.
    • Versiones de extensiones: «Fatal error in Plugin Version 2.3.1». Ahora sabe qué plugins tienes y cuáles podrían ser vulnerables.
    • Configuración de base de datos: Los errores de conexión a MySQL revelan el servidor de BD, el usuario y a veces pistas sobre la contraseña.
    • Estructura del código: Los stack traces muestran qué métodos usa tu aplicación, qué hooks están activos, dónde están los puntos débiles.

    En mi experiencia auditar WordPress, cuando encuentro errores públicos en un sitio, el 70% de las veces hay un backdoor activo. Los atacantes dejan esos errores a propósito porque les permiten navegar tu infraestructura como si tuvieran un mapa.

    Errores como distracción y confusión

    Otra razón por la que provocan errores deliberadamente es pura estrategia psicológica. Un sitio lleno de errores parece un sitio mal mantenido, descuidado, donde el propietario no sabe qué está haciendo.

    La ilusión del caos accidental

    Si tu sitio muestra fallos de carga, errores de conexión intermitentes o pantallas blancas que van y vienen, es fácil que culpes a tu hosting, a plugins desactualizados o a tu tema. Mientras tanto, un backdoor está activo en segundo plano, enviando datos de clientes, inyectando redirecciones de spam SEO o minando criptomonedas.

    Los atacantes profesionales son psicólogos improvosados. Saben que:

    • Si hay muchos errores, el propietario asume que todo es un accidente de configuración.
    • El caos hace que sea difícil distinguir tráfico malicioso de tráfico legítimo en los logs.
    • Un administrador estresado por los errores es un administrador que no revisa la seguridad con rigor.
    • Los mensajes de error ocultan la verdadera actividad maliciosa en el ruido de fondo.

    Errores como mecanismo para deshabilitar medidas de seguridad

    Cuando implemento hardening en WordPress, insisto siempre en registrar todos los errores y monitorearlos. Algunos atacantes saben esto y utilizan errores deliberados para sabotear tus sistemas de detección.

    Inundación de logs y falsos positivos

    Un atacante puede inyectar código que genere miles de errores PHP triviales pero inofensivos. Los logs se llenan. Tu herramienta de monitoreo (Wordfence, MalCare, Sucuri) genera alertas constantemente sobre errores de bajo riesgo. Finalmente:

    • Apagas las alertas porque no puedes procesarlas todas.
    • Dejas de revisar los logs porque son ilegibles.
    • La actividad maliciosa real se camufla entre el ruido.
    • Cuando finalmente ocurre algo grave, ya no hay nadie monitoreando.

    He visto casos donde los atacantes dejaban un backdoor durante 8 meses sin ser detectado simplemente porque había un error de conexión a API recurrente que inundaba el log de error y lo hacía completamente inútil.

    Errores como indicadores de compromiso de PrestaShop y PHP

    En PrestaShop, el patrón es similar pero con matices específicos. Los atacantes inyectan código en módulos de pago o en funciones de carrito que genera errores durante transacciones legítimas.

    El ataque de errores en PrestaShop

    Cuando un cliente intenta comprar, el módulo de pago (posiblemente comprometido) genera un error que interrumpe la transacción. Mientras el cliente ve una pantalla de error, en el servidor:

    • Sus datos de tarjeta se capturan antes de que el error ocurra (ataque Magecart/skimmer).
    • Un script paralelo registra la información del cliente en un archivo oculto.
    • El error oculta completamente el robo dentro de una cascada de fallos aparentemente técnicos.

    Lo que recomiendo siempre en auditorías de PrestaShop es activar logging detallado y revisar los archivos de error en var/log/ con sospecha permanente. Los atacantes cuentan con que nadie los revise realmente.

    Errores para establecer persistencia y ocultar backdoors

    Un backdoor activo necesita comunicarse con el servidor del atacante. Necesita recibir órdenes, exfiltrar datos, ejecutar comandos. Todo eso deja rastros.

    El webshell disfrazado de error

    Los atacantes sofisticados crean webshells (scripts PHP maliciosos) que se ocultan como archivos de error o logs. Por ejemplo:

    /wp-content/debug.log (parece un archivo de debug legítimo) pero realmente contiene un script ejecutable que:

    • Acepta comandos mediante parámetros GET o POST cifrados.
    • Genera errores falsos en sus respuestas para no parecer sospechoso.
    • Ejecuta comandos del sistema operativo con permisos de www-data.
    • Mantiene acceso permanente al servidor aunque cambies todas las contraseñas.

    En mis auditorías he encontrado webshells dentro de archivos llamados error_404.php, maintenance.php o incluso dentro de comentarios HTML dentro de error pages. El atacante cuenta con que no revisarás archivos que parecen tener un propósito obvio.

    Cómo detectar errores provocados deliberadamente

    Si tienes errores en tu WordPress, necesitas diferenciar entre accidentes reales y ataques deliberados. Lo que busco cuando analizo un sitio:

    Signos de error malicioso

    • Errores recurrentes a horas específicas: Un error accidental es aleatorio. Un error provocado por un cron job malicioso ocurre a las 2:00 AM cada día.
    • Errores en archivos que no deberían tener código: Un error en /wp-content/uploads/documento.pdf es sospechoso. Los uploads no ejecutan PHP por defecto.
    • Errores que incluyen rutas inusuales: Si ves errores mentionando carpetas como /var/www/html/wp-content/.cache o nombres de carpeta con patrones aleatorios, es un ataque.
    • Errores que aparecen solo en ciertos navegadores o IP: Alguien está generandolos a propósito para ese usuario específico.
    • Cambios recientes en el archivo wp-config.php o .htaccess sin tu intervención: Ahí es donde inyectan los scripts que generan los errores.

    Estrategia de protección contra errores maliciosos

    1. Oculta los errores de los usuarios finales

    En wp-config.php, asegúrate de que tienes:

    define( 'WP_DEBUG', false );
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', false );

    Los errores se registran en /wp-content/debug.log (solo para ti) pero no se muestran en la web. Sin información visible, los atacantes pierden valor en generar errores.

    2. Monitorea los logs activamente

    No puedes ignorar tus logs. Lo que recomiendo siempre es usar Wordfence CLI o WP-CLI para generar reportes semanales de errores. Busca patrones, errores nuevos, archivos mencionados que no reconoces.

    3. Implementa alertas en tiempo real

    Usa herramientas como Wordfence o MalCare configuradas para alertarte cuando aparecen errores nuevos o cuando el volumen de errores aumenta anormalmente.

    4. Revisa cambios recientes en archivos críticos

    Los backdoors y generadores de errores maliciosos modifican:

    • wp-config.php
    • .htaccess
    • wp-settings.php (en carpeta de WordPress)
    • Tema activo (functions.php)
    • Plugins activos

    Establece alertas de cambio de archivo. Si algo se modifica sin tu intervención, es un ataque.

    5. Implementa permisos de archivo correctos

    Los archivos PHP no deberían ser escribibles por el servidor web:

    • Carpetas: 755 (rwxr-xr-x)
    • Archivos: 644 (rw-r–r–)
    • wp-config.php: 600 (rw——)

    Con permisos restrictivos, un atacante tiene mucha más dificultad para inyectar código que genere errores.

    El papel de la auditoría profesional en detectar errores maliciosos

    Lo que diferencia una auditoría profesional de una revisión amateur es precisamente esto: el contexto. Alguien que mira tu sitio una vez ve errores. Un auditor experimentado ve patrones, secuencias de ataque y evidencia de acceso no autorizado.

    En ManuelFolgar.com, cuando hago una auditoría de seguridad WordPress o PrestaShop, dedico tiempo específicamente a:

    • Correlacionar errores con logs de acceso para identificar qué IP o usuario los provocó.
    • Buscar código inyectado en archivos de configuración.
    • Analizar cambios en la base de datos (opciones de WordPress sospechosas).
    • Revisar tareas cron para detectar trabajos maliciosos.
    • Verificar integridad de archivos críticos comparándolos con versiones oficiales.

    Referencias técnicas y normativa

    La generación deliberada de errores para ataque es una técnica documentada en los estándares de seguridad. Según OWASP Top 10, la exposición de información sensible mediante mensajes de error está catalogada como A01:2021 – Broken Access Control y A05:2021 – Security Misconfiguration.

    En el contexto normativo español, la INCIBE (Instituto Nacional de Ciberseguridad de España) clasifica estos ataques dentro de «ataque de reconocimiento» y «pivoting lateral», que son precursores de compromisos más graves.

    Conclusión: los errores no son lo que parecen

    La próxima vez que veas un error en tu WordPress o PrestaShop, no lo descarto como un accidente. Pregúntate:

    • ¿Cuándo empezó a ocurrir?
    • ¿A qué hora se repite?
    • ¿Qué cambios hiciste justo antes?
    • ¿Alguien más tiene acceso a mi hosting?
    • ¿He revisado mi archivo .htaccess y wp-config.php recientemente?

    Si no puedes responder a estas preguntas con seguridad, es hora de una auditoría profesional. Los atacantes cuentan con tu negligencia. No la satisfagas.

    Si necesitas un análisis profundo de tu sitio, detectar backdoors activos o implementar hardening real en WordPress o PrestaShop, en ManuelFolgar.com/contacto ofrecemos auditorías especializadas, limpieza de malware y configuración de seguridad que va más allá de plugins estándar. Tu sitio no debe generar errores sin explicación.

  • Qué errores indican que tu WordPress necesita hardening urgente

    Qué errores indican que tu WordPress necesita hardening urgente

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

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

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

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

    1. El prefijo de tablas sigue siendo «wp_»

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

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

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

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

    Revisa permisos ahora:

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

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

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

    define('DISALLOW_FILE_EDIT', true);

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

    Agrégalo ahora. No hay excusa.

    Vulnerabilidades activas en plugins y temas

    4. Plugins desactualizados con CVEs conocidos

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

    Los culpables habituales:

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

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

    wordfence cli scan --scan_type=vulnerability

    5. Temas nulled o de fuentes desconocidas

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

    Solo compra o descarga temas de:

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

    Problemas de acceso y autenticación

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

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

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

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

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

    7. Sin Two-Factor Authentication en admin

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

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

    8. Múltiples usuarios admin con permisos innecesarios

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

    Audita usuarios ahora:

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

    Síntomas de compromiso activo

    9. Archivos PHP extraños en directorios

    Si en tu servidor encuentras archivos como:

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

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

    10. Redirecciones extrañas en Search Console o clientes

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

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

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

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

    Revisa logs:

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

    Errores de permisos de carpetas

    12. Directorios con permisos 777

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

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

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

    13. Propiedad de archivos mal configurada

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

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

    Luego:

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

    Errores de base de datos

    14. Usuario de base de datos con privilegios ALL

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

    Crea un usuario con privilegios mínimos:

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

    15. Sin copias de seguridad automatizadas

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

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

    Ausencia de hardening defensivo

    16. Sin headers de seguridad HTTP

    Si tu sitio no devuelve headers como:

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

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

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

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

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

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

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

    Desactiva XML-RPC en wp-config.php:

    define('XMLRPC_REQUEST', false);

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

    18. Sin WAF o reglas .htaccess anti-ataque

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

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

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

    Qué hacer ahora: plan de acción inmediato

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

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

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

    Por qué esto importa tanto

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

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

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

    Tu WordPress merece estar seguro. Hazlo hoy.

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

  • Cómo limpiar errores causados por plugins maliciosos

    Cómo limpiar errores causados por plugins maliciosos

    Cómo limpiar errores causados por plugins maliciosos en WordPress

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

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

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

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

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

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

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

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

    Herramientas que uso constantemente:

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

    Paso 2: Limpia la base de datos de cambios maliciosos

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

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

    wp user list --format=table

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

    wp user delete ID --reassign=1

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

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

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

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

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

    Borra cualquier entrada sospechosa.

    Paso 3: Busca y elimina webshells y archivos maliciosos

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

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

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

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

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

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

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

    También revisa archivos que hayan sido modificados recientemente:

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

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

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

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

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

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

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

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

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

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

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

    wp theme get --field=stylesheet-path

    Abre ese archivo y busca líneas que:

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

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

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

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

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

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

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

    # Proteger wp-config.php
    <Files wp-config.php>
      Order allow,deny
      Deny from all
    </Files>
    
    # Bloquear acceso a wp-admin excepto para ti
    <FilesMatch "wp-login.php">
      Order allow,deny
      Allow from XXX.XXX.XXX.XXX
      Deny from all
    </FilesMatch>
    
    # Prohibir ejecución de PHP en /uploads
    <Directory /uploads>
      php_flag engine off
      AddType text/plain .php
    </Directory>

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

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

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

    Por eso, obligatorio:

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

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

    Paso 7: Realiza un escaneo antimalware profesional

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

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

    wp wordfence scan execute --scan_type=all

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

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

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

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

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

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

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

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

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

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

    Google típicamente responde en 24-72 horas.

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

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

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

    ¿Qué pasa si todo está muy comprometido?

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

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

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

    Resumen de acciones inmediatas

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

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

  • Error 403 Forbidden en WordPress: problema de permisos o malware

    Error 403 Forbidden en WordPress: problema de permisos o malware

    Error 403 Forbidden en WordPress: cuándo es un problema de permisos y cuándo esconde malware

    Cuando accedes a tu sitio WordPress y de repente ves un error 403 Forbidden, lo primero que te pregunta es: «¿Qué he hecho?». En mi experiencia analizando cientos de webs comprometidas, este error es uno de los más engañosos que existen. Puede significar algo tan simple como un permiso de archivo mal configurado, o puede ser la señal de que alguien ha infiltrado un backdoor en tu servidor.

    La realidad es que el error 403 es como un síntoma en medicina: te dice que algo no va bien, pero no te dice qué es. Por eso necesitas un diagnóstico preciso. En este artículo te enseño a diferenciar ambos escenarios y qué hacer en cada caso.

    Qué significa el error 403 Forbidden

    El error 403 Forbidden es una respuesta HTTP que tu servidor web (Apache, Nginx) devuelve cuando un usuario intenta acceder a un recurso para el que no tiene permisos. A diferencia del 404 (página no encontrada), aquí el servidor sí ve el archivo o directorio, pero decide que no deberías poder verlo.

    En WordPress, esto ocurre típicamente cuando:

    • Los permisos de un archivo o carpeta están demasiado restrictivos (p. ej., 000 o 600 cuando deberían ser 644 o 755).
    • El propietario del archivo no es el usuario del servidor web (www-data en Linux).
    • Una regla .htaccess bloquea el acceso deliberadamente.
    • Una directiva Apache o Nginx prohíbe el acceso a ese recurso.
    • Un plugin de seguridad ha bloqueado la IP del visitante.

    Pero aquí viene lo importante: un atacante también puede generar un 403 intencionalmente para ocultarse. Veremos esto más adelante.

    Las 5 causas más comunes del error 403 en WordPress

    1. Permisos de archivos incorrectos (la más habitual)

    En mi experiencia, 7 de cada 10 casos de error 403 que veo son por esto. WordPress necesita que sus archivos y carpetas tengan permisos específicos para que tanto tú como el servidor web puedan leerlos y modificarlos.

    Los permisos correctos son:

    • Carpetas: 755 (rwxr-xr-x)
    • Archivos: 644 (rw-r–r–)
    • wp-config.php: 600 (rw——-) por seguridad

    Si alguien ha cambiado estos permisos (accidentalmente o tras una mala migración), obtendrás 403. Puedes verificarlo vía SSH o tu panel de hosting:

    1. Conecta por SSH o accede al administrador de archivos de tu hosting.
    2. Navega a la raíz de WordPress.
    3. En SSH: ls -la para ver los permisos (columna 1).
    4. Si ves números como 000, 600 (en archivos normales) o 600 (en carpetas), están mal.

    Para corregirlo desde SSH:

    find /ruta/a/wordpress -type f -exec chmod 644 {} ;
    find /ruta/a/wordpress -type d -exec chmod 755 {} ;

    2. Propietario de archivos incorrecto

    Si tras una migración o una instalación manual, los archivos no pertenecen al usuario del servidor web, WordPress no podrá escribir en ellos. Verificar el propietario:

    ls -l /ruta/a/wordpress | head -20

    Deberías ver algo como www-data www-data o nobody nobody (depende de tu hosting). Si ves root o tu usuario de SSH, ahí está el problema. Para corregirlo:

    chown -R www-data:www-data /ruta/a/wordpress

    3. Regla .htaccess que bloquea acceso

    Un archivo .htaccess corrupto o mal configurado puede devolver 403 a todo el mundo. Algunos plugins de seguridad añaden reglas que a veces son demasiado restrictivas.

    Prueba esto: accede a tu hosting y renombra el archivo .htaccess a .htaccess.bak. Si el error desaparece, aquí estaba el culpable. Luego regenera el .htaccess desde WordPress:

    • Ajustes → Enlaces permanentes
    • Haz clic en «Guardar cambios» (sin cambiar nada)

    4. Plugin de seguridad bloqueando tu IP

    Plugins como Wordfence, Sucuri, o iThemes Security pueden bloquear direcciones IP tras detectar múltiples intentos fallidos de login. Si hace poco intentaste acceder con una contraseña incorrecta varias veces, es probable que estés bloqueado.

    Solución: accede a través de una VPN o IP diferente, entra al panel de administración (si puedes) y desbloquea tu IP en el plugin.

    5. Configuración incorrecta de Apache/Nginx

    A veces, el servidor tiene una directiva <Directory> que prohíbe el acceso (Deny from all). Esto es menos común, pero si no encuentras el error en los puntos anteriores, contacta con tu proveedor de hosting.

    ¿Cuándo el error 403 es señal de malware?

    Aquí es donde pongo las antenas en alerta máxima. Un atacante sofisticado puede modificar archivos .htaccess o reglas Nginx para bloquear acceso intencionalmente y ocultarse. Es una técnica de ofuscación.

    Indicadores de que el 403 esconde algo oscuro:

    • El error apareció sin que hayas hecho cambios. Si no migraste, no actualizaste plugins ni tocaste permisos, y de repente aparece 403, es sospechoso.
    • El 403 aparece solo en ciertos directorios. Por ejemplo, ves tu home, pero /wp-admin devuelve 403. Eso puede indicar una regla .htaccess maliciosa que bloquea el acceso administrativo.
    • Hay un .htaccess nuevo o modificado que no creaste. Un atacante a menudo añade reglas como:

      <Files ~ ".php$">
      Deny from all
      </Files>

      Esto bloquea la ejecución de PHP en una carpeta específica para ocultar webshells.
    • Tu Google Search Console muestra un aumento de errores 403. Si Google de repente reporta 100+ URLs con error 403, alguien pudo haber puesto un bloqueo masivo. Entra en Google Search Console y verifica la sección «Problemas de cobertura».
    • Ves archivos PHP raros en directorios que no debería haber. Por ejemplo, /wp-content/uploads/shell.php o /wp-includes/wp-admin.php.

    Paso a paso: diagnóstico profesional del error 403

    Aquí es cómo yo procedo cuando un cliente me llama con este problema:

    Paso 1: Verificar los registros del servidor

    Los logs de Apache o Nginx son la fuente de verdad. Accede a ellos (normalmente en /var/log/apache2/ o /var/log/nginx/):

    tail -100 /var/log/apache2/error.log | grep 403

    Busca patrones. Verás líneas como:

    [client 192.168.1.100] File does not exist: /var/www/html/wp-admin → problema de permisos.
    access to /wp-admin denied by rule → regla .htaccess bloqueando.

    Paso 2: Inspeccionar .htaccess y archivos de configuración web

    Descarga tu .htaccess y revísalo línea a línea. Busca:

    • Directivas Deny from sospechosas.
    • Reglas RewriteRule raras que redirigen al 403.
    • Código ofuscado o comentarios en idiomas extraños.

    Si usas Nginx, revisa /etc/nginx/sites-enabled/default o tu configuración específica.

    Paso 3: Escanear archivos en busca de código malicioso

    Aquí es donde usaría herramientas como:

    • Wordfence CLI (gratuito, desde SSH): detecta backdoors conocidos.
    • WP-CLI con auditoría de archivos: wp plugin list --status=all para ver si hay plugins raros.
    • Sucuri SiteCheck (online): escanea tu dominio en busca de malware conocido.

    Si encuentro un backdoor, es momento de acción inmediata: aislamiento, copia de seguridad íntegra y limpieza.

    Paso 4: Revisar logs de acceso por patrones de ataque

    tail -1000 /var/log/apache2/access.log | grep -i "sql|union|select|xss"

    Esto busca intentos de inyección SQL o XSS. Si encuentras líneas como:

    GET /index.php?id=1 UNION SELECT ... HTTP/1.1

    Confirma que ha habido un intento de explotación.

    Soluciones según el diagnóstico

    Si es problema de permisos:

    1. Corrige los permisos como indiqué anteriormente.
    2. Verifica que el propietario es el usuario del servidor web.
    3. Regenera el .htaccess desde WordPress.
    4. Borra la caché del navegador (Ctrl+Shift+Supr) e intenta acceder.

    Si encontraste código malicioso:

    1. No lo borres aún sin una copia de seguridad limpia. Necesitas una línea de base para comparar.
    2. Identifica la fecha de modificación de archivos maliciosos (ls -la --full-time).
    3. Busca en los logs de acceso qué IP o qué solicitud HTTP lo creó.
    4. Elimina el malware, cambia todas las contraseñas (admin, FTP, bases de datos), y revisa plugins/temas.
    5. Si el backdoor es persistente (se regenera tras borrarlo), necesitas ayuda profesional. No es una tarea para DIY.

    Si hay una regla .htaccess maliciosa:

    Edita el .htaccess y elimina la regla sospechosa. Si tienes un backup de antes de que apareciera el error, compara versiones. Luego valida que la sintaxis es correcta (un error de sintaxis en .htaccess causa 500, pero con ciertos navegadores puede parecer 403).

    Cómo prevenirlo en el futuro

    Una vez resuelto, implementa estas medidas defensivas:

    • Monitoreo de cambios de permisos: configura alertas en tu hosting o usa un plugin como File Monitor para detectar cambios en archivos críticos.
    • Backups regulares: mantén backups automáticos diarios. Si ocurre un ataque, puedes restaurar sin perder semanas de trabajo.
    • Actualiza WordPress y plugins religiosamente. Vulnerabilidades no parcheadas son la puerta de entrada número 1.
    • Usa un plugin de seguridad confiable: Wordfence, Sucuri, o All in One WP Security. Configúralo para bloquear intentos de fuerza bruta y monitorear cambios de archivos.
    • Cambia el prefijo de tablas de WordPress: en lugar de wp_, usa algo como abc123_. Esto dificulta inyecciones SQL.
    • Deshabilita la edición de archivos desde el panel: añade esto a wp-config.php:

      define('DISALLOW_FILE_EDIT', true);
      Así, aunque un atacante entre al panel, no puede editar archivos directamente.
    • Configura autenticación de dos factores (2FA) en wp-login.php. Un atacante sin tu teléfono no puede entrar.
    • Limita intentos de login: usa una regla .htaccess o un plugin para bloquear después de 5 intentos fallidos en 15 minutos.

    Cuándo pedir ayuda profesional

    Si después de seguir estos pasos el error persiste, o si sospechas que hay malware pero no sabes cómo proceder, es momento de contactar a un profesional. En ManuelFolgar.com, realizamos auditorías de seguridad profundas, limpieza de malware certificada y hardening de WordPress. No jugamos a adivinar; usamos herramientas forenses reales y experiencia en miles de casos.

    Un error 403 que persiste puede costar dinero en inactividad de tu sitio, confianza de clientes y, lo peor, exposición de datos. La inversión en diagnóstico profesional se recupera rápidamente.

    Si necesitas ayuda, contacta conmigo aquí. Realizamos evaluación inicial gratuita de tu situación.

  • Escaneo de malware WordPress: herramientas y procedimientos

    Escaneo de malware WordPress: herramientas y procedimientos

    Escaneo de malware WordPress: herramientas y procedimientos

    Cuando un cliente me contacta porque sospecha que su WordPress está comprometido, lo primero que hago es un escaneo profundo de malware. No es algo opcional: si tu sitio está infectado y no lo detectas a tiempo, los daños pueden ser devastadores. Pérdida de datos, robo de credenciales, indexación de spam en Google, caída del tráfico orgánico y pérdida de confianza de usuarios son solo algunas consecuencias.

    En mi experiencia, la mayoría de los ataques a WordPress provienen de plugins desactualizados, temas nulled o contraseñas débiles en el panel de administración. El malware se instala silenciosamente y puede estar semanas sin ser detectado. Por eso te voy a mostrar exactamente cómo scanear tu sitio, qué herramientas funcionan de verdad y qué hacer si encuentras algo.

    ¿Por qué un escaneo de malware es imprescindible?

    Antes de entrar en herramientas, quiero que entiendas por qué esto es crítico. Los atacantes no atacan WordPress al azar. Buscan activamente vulnerabilidades porque saben que hay cientos de miles de sitios WordPress sin parches de seguridad.

    Según el equipo de seguridad de WordPress.org, mantener tu instalación actualizada es la defensa más importante. Pero si ya estás comprometido, necesitas detectarlo rápido.

    Los tipos de malware que más veo en WordPress son:

    • Backdoors: archivos ocultos que permiten al atacante acceder sin credenciales reales
    • Webshells: scripts PHP que funcionan como puerta trasera remota
    • Redirectores: código que envía a visitantes a sitios maliciosos sin tu control
    • Cryptominers: scripts que usan CPU del servidor para minar criptomonedas
    • Skimmers de tarjetas: malware que captura datos de pagos (muy grave en tiendas online)
    • Inyección de spam SEO: contenido malicioso inyectado para posicionar sitios de terceros

    Herramientas principales para escanear malware en WordPress

    No todas las herramientas detectan lo mismo. Lo que recomiendo siempre es usar varias en combinación porque un malware sofisticado puede eludir un solo scanner.

    1. Wordfence (la mejor opción plugin)

    Wordfence es mi herramienta de referencia. Tiene una versión gratuita que escanea todo el servidor, compara archivos de WordPress contra las versiones originales, detecta malware en themes y plugins, e identifica vulnerabilidades conocidas.

    Cómo usarlo:

    1. Instala el plugin desde el repositorio oficial de WordPress
    2. Ve a Wordfence > Scan
    3. Haz clic en «Start scan»
    4. Espera a que termine (puede tardar 30-60 minutos según el tamaño del sitio)
    5. Revisa los resultados en la pestaña «Threat report»

    Lo que me gusta de Wordfence es que no solo busca malware, sino también archivos modificados. Si un plugin legítimo fue parchado con código malicioso, Wordfence lo detecta comparando el hash MD5 del archivo con el original en los servidores de WordPress.org.

    2. MalCare (escaneo en la nube)

    MalCare escanea tu sitio desde servidores en la nube, lo que evita sobrecargar tu propio servidor. Es especialmente útil si tu hosting es lento o tienes poco margen de recursos.

    Ventajas:

    • Detecta malware oculto en bases de datos
    • Identifica vulnerabilidades en plugins y temas
    • Tiene inteligencia artificial para detectar patrones de ataque nuevos
    • Versión gratuita funcional para sitios pequeños

    En un caso real, encontré un backdoor que Wordfence no había detectado porque estaba ofuscado en la base de datos. MalCare lo sacó a la luz en minutos.

    3. Sucuri SiteCheck (escaneo online gratuito)

    Sucuri SiteCheck es completamente gratuito y no requiere instalar nada. Solo necesitas acceder a su web, escribir tu URL y esperar. Es perfecto como primer chequeo rápido.

    Te muestra:

    • Malware detectado
    • Blacklist status (si Google o Sucuri lo han marcado como malicioso)
    • Problemas de seguridad general
    • Vulnerabilidades conocidas

    4. Google Search Console (control de Google)

    Google indexa malware constantemente. Si tu sitio tiene código malicioso, muy probablemente lo haya detectado. En Google Search Console, ve a «Seguridad y acciones manuales» para ver si Google ha marcado tu dominio.

    Si aparece «Malware detectado», tienes un problema real que requiere acción inmediata.

    5. Análisis manual con WP-CLI

    Para los que se sienten cómodos con línea de comandos, WP-CLI es brutal en eficiencia:

    Listar plugins activos con versiones:

    • wp plugin list

    Verificar integridad de archivos de WordPress core:

    • wp core verify-checksums

    Buscar archivos sospechosos modificados recientemente:

    • find /ruta/a/wordpress -type f -name «*.php» -mtime -7

    Este comando te muestra todos los archivos PHP modificados en los últimos 7 días. Si encontras algo fuera de wp-content/uploads o temas/plugins legítimos, es sospechoso.

    6. VirusTotal (análisis de archivos individuales)

    VirusTotal te permite subir archivos PHP sospechosos y escanearlos contra 90+ antivirus. Es especialmente útil cuando encuentras un archivo raro y no sabes si es legítimo.

    Procedimiento completo de escaneo

    Aquí está el protocolo que sigo yo cuando analizo un sitio potencialmente comprometido:

    Paso 1: Escaneo inicial rápido

    Primero, accedo a Sucuri SiteCheck con la URL del cliente. Tarda 2-3 minutos y te da un primer veredicto. Si sale «malware detectado» aquí, ya sabemos que es grave.

    Paso 2: Escaneo con Wordfence

    Instalo Wordfence si no lo tiene, y lanzo un escaneo completo. Mientras se ejecuta (30-60 minutos), paso al siguiente punto.

    Paso 3: Revisión de Google Search Console

    Compruebo si Google ha detectado malware. Si tiene alertas de «Sitio comprometido» o «Malware», la situación es más delicada.

    Paso 4: Análisis de plugins y temas

    Busco:

    • Plugins desactualizados: cualquier versión antigua que tenga CVE publicado
    • Temas nulled: si el cliente dice «compré el tema en una tienda rara», probablemente sea falsificado
    • Plugins de origen dudoso: algunos «security» plugins maliciosos simulan ser legítimos
    • Plugins inactivos años atrás: son vectores de ataque si nunca se actualizaron

    Paso 5: Revisión manual de archivos core

    Con WP-CLI, corro «wp core verify-checksums». Si sale algo modificado en wp-load.php, wp-settings.php o wp-config.php, el sitio fue parchado.

    Paso 6: Búsqueda de backdoors

    Busco en directorios comunes donde los atacantes dejan backdoors:

    • /wp-content/uploads/ (el lugar más común)
    • /wp-content/plugins/ (especialmente plugins desactivados)
    • Raíz del sitio (archivos .php solitarios)
    • /wp-admin/ (si tiene permisos, pueden añadir ahí)

    Un backdoor típico es un archivo como «update.php», «config.php» o algo con nombre genérico. Cuando lo encuentro, corro VirusTotal para confirmar.

    Paso 7: Análisis de base de datos

    Conecto vía phpMyAdmin y busco:

    • Posts editados con código malicioso: inyección de iframes o scripts
    • Usuarios extra: cuentas de administrador que el cliente no reconoce
    • Opciones modificadas: valores raros en wp_options que podrían ser persistencia

    Un truco: busco en la tabla wp_posts donde post_content contiene «iframe» o «<script" sin ser del cliente.

    Paso 8: Logs del servidor

    Reviso access.log y error.log de Apache/Nginx. Busco:

    • POST requests a wp-login.php desde IPs raras
    • Accesos a archivos que no existen (típico de intentos de RFI/LFI)
    • Mensajes de error SQL (indicio de inyección)

    Qué hacer si encuentras malware

    Si tu escaneo da positivo, aquí es donde muchos clientes panic. Pero hay un plan claro:

    1. Aislamiento inmediato

    No esperes: si está en una blacklist de Google, necesitas sacarlo rápido. Algunas opciones:

    • Desactiva todos los plugins (excepto Wordfence)
    • Cambia el tema a uno stock de WordPress
    • Desconecta usuarios no autorizados en wp-admin

    El objetivo es minimizar el daño mientras trabajas en la limpieza.

    2. Backup seguro (si lo tienes)

    Descarga un backup anterior a la infección si lo guardaste. Cuidado: si el backup es infectado también, no sirve. Por eso recomiendo backups automáticos diarios, no semanales.

    3. Limpieza manual vs. reinstalación

    Aquí tengo dos opciones:

    Limpieza manual: si el malware es superficial (un plugin infectado, unos cuantos archivos backdoor), puedo eliminarlo manualmente, restablecer permisos y cambiar todas las contraseñas.

    Reinstalación completa: si el malware está profundamente enraizado (modificaciones en core, múltiples backdoors, inyección en BD), reinstalo WordPress desde cero, subo contenido limpio del backup, y reconfiguro todo.

    En mi experiencia, la reinstalación es más segura y custa menos tiempo que una limpieza manual exhaustiva.

    4. Cambio de credenciales

    Cambio todo:

    • Contraseña de admin de WordPress
    • Credenciales FTP/SFTP
    • Contraseña de la base de datos
    • Credenciales de email de administrador
    • Keys y salts de WordPress (en wp-config.php)

    5. Reportar a Google

    En Google Search Console, ve a «Seguridad y acciones manuales» y solicita una revisión de seguridad. Explica que ya está limpio. Google tarda 1-7 días en revisar.

    Prevención: hardening después del ataque

    Una vez limpios, implemento medidas para que no vuelva a pasar:

    Cambio de prefijo de tablas

    La mayoría de ataques SQL apuntan a tablas con nombre «wp_». Lo cambio en wp-config.php y la BD:

    • $table_prefix = ‘mf_’;

    Deshabilitar edición de archivos

    Añado a wp-config.php:

    • define(‘DISALLOW_FILE_EDIT’, true);

    Así, aunque un atacante acceda al panel de admin, no puede editar archivos PHP directamente.

    Proteger wp-config.php

    En .htaccess:

    • <files wp-config.php> deny from all </files>

    Limitar intentos de login

    Uso Wordfence Firewall para bloquear tras 5 intentos fallidos en 5 minutos. Mata los ataques de fuerza bruta.

    Dos factores de autenticación (2FA)

    Instalo Two-Factor Authentication for WordPress. Aunque hackeen la contraseña, sin el móvil no entran.

    Auditoría de actividad

    Wordfence mantiene logs de quién accede y cuándo. Lo reviso regularmente en «Tools > Activity Log».

    Automatizar escaneos

    Configuro escaneos semanales automáticos en Wordfence. Si encuentra algo, me avisa por email.

    Errores comunes que veo

    Después de años analizando WordPress infectados, estos son los fallos más frecuentes:

    • No actualizar plugins: el 80% de los ataques explotan vulnerabilidades conocidas y parchadas
    • Usar temas nulled: descargar temas «gratis» de sitios de dudosa reputación es suicida
    • Contraseñas débiles: «123456» o «admin» como contraseña de panel invita ataques brute force
    • No tener backups: si no tienes backup limpio, no puedes recuperarte
    • Ignorar alertas de Google: cuando Google te avisa, tienes días para actuar, no semanas
    • Confiar en un solo scanner: usar solo Wordfence puede dejar malware sin detectar

    Resumen: tu checklist de escaneo

    Si sospechas malware, haz esto hoy:

    1. Accede a Sucuri SiteCheck y scanea tu URL
    2. Revisa Google Search Console para alertas de malware
    3. Instala Wordfence si no lo tienes y lanza escaneo completo
    4. Revisa plugins desactualizados y desactiva los dudosos
    5. Busca archivos PHP raros en wp-content/uploads/
    6. Si encuentras algo, contacta con un profesional

    No intentes limpiar malware sofisticado tú solo si no tienes experiencia. Un mal movimiento puede borrar contenido legítimo o dejar puertas traseras. Lo que recomiendo siempre es trabajar con especialistas en seguridad WordPress.

    Si tu sitio está comprometido o tienes dudas después de un escaneo, contacta conmigo en ManuelFolgar.com. Hago análisis profundos de seguridad y limpiezas garantizadas para WordPress. Tu sitio es tu negocio, y merece estar protegido.

  • Ataques a PrestaShop vs WordPress: cuál es más seguro

    Ataques a PrestaShop vs WordPress: cuál es más seguro

    Ataques a PrestaShop vs WordPress: cuál es más seguro

    Cuando analizo un sitio comprometido, la pregunta que más escucho es: «¿cuál de las dos plataformas es más segura?» La realidad es más matizada de lo que parece. Tanto WordPress como PrestaShop sufren ataques constantemente, pero los vectores, la frecuencia y la severidad varían significativamente. En mi experiencia, no se trata de cuál es inherentemente más seguro, sino de cómo cada uno maneja la seguridad y qué responsabilidad recae en el administrador.

    La arquitectura de seguridad: diferencias fundamentales

    WordPress es un CMS de propósito general con un ecosistema masivo de plugins y temas. Esa flexibilidad es su fortaleza y su talón de Aquiles. PrestaShop, en cambio, está específicamente diseñado para comercio electrónico, lo que implica un enfoque más cerrado y orientado a casos de uso concretos.

    Lo que recomiendo siempre a mis clientes: WordPress tiene un core más auditado por la comunidad de seguridad, pero el riesgo real está en las extensiones de terceros. PrestaShop centraliza más funcionalidad en el core, lo que reduce la proliferación de plugins inseguros, pero cuando hay vulnerabilidades, afectan a un porcentaje más alto de instalaciones.

    • WordPress: ~43% de todos los sitios web usan WordPress. Los ataques se distribuyen entre el core (raro), plugins (frecuente) y temas (moderado).
    • PrestaShop: Menos penetración global (~0,2% del top 1 millón), pero altamente concentrado en ecommerce. Los ataques se centran en módulos de pago, carrito y datos de clientes.

    Vectores de ataque más comunes en WordPress

    En WordPress, los tres principales vectores de compromiso que encuentro en auditorías son:

    1. Plugins desactualizados: Un plugin con una vulnerabilidad de inyección SQL publicada hace 6 meses y sin parchear es la puerta más común. Herramientas como Wordfence registran miles de intentos diarios contra plugins populares vulnerables.
    2. Temas nulled: Descargar un tema de un repositorio no oficial es casi garantía de backdoor. He visto cryptominers inyectados en el footer que tardaban meses en detectarse.
    3. Brute force en wp-login.php: Aunque sea un ataque de baja sofisticación, las contraseñas débiles siguen siendo la causa #1 de compromiso en WordPress que he limpiado.

    El malware WordPress típico que encuentro incluye webshells en carpetas /uploads, redirectores SEO incrustados en functions.php, y recientemente, más backdoors persistent que sobreviven a actualizaciones parciales.

    Vectores de ataque en PrestaShop

    PrestaShop enfrenta riesgos diferentes, especialmente críticos porque maneja datos sensibles:

    1. Módulos de pago comprometidos: Los skimmers tipo Magecart (sí, afectan también a PrestaShop) se instalan como módulos maliciosos y roban tarjetas de crédito en tiempo real. Es devastador porque el malware está en la capa de procesamiento de pagos.
    2. Vulnerabilidades en el back-office: Acceso a /admin sin protección, CSRF tokens débiles, y contraseñas de BD expuestas en config/settings.inc.php son hallazgos recurrentes en mis auditorías de PrestaShop.
    3. Módulos de terceros sin auditar: A diferencia de WordPress, el repositorio oficial de módulos de PrestaShop es más restrictivo, pero los módulos instalados manualmente desde proveedores de dudosa reputación son un vector crítico.

    Un dato que veo constantemente: la mayoría de brechas en PrestaShop no son por un 0-day del core, sino por módulos de pago desactualizados o clonados ilegalmente.

    Datos de prevalencia: qué dicen los estudios

    Según análisis de malware web de plataformas como Sucuri, WordPress representa el 80% de todos los sitios comprometidos detectados, pero eso es por volumen. Si normalizamos por número de instalaciones, el porcentaje de sitios WordPress comprometidos es menor que el de PrestaShop.

    Por contra, cuando un sitio PrestaShop se ve comprometido, la severidad es típicamente mayor: exfiltración de datos de clientes, robo de credenciales de pago, y modificación de precios son comunes. En WordPress, el malware suele ser spam SEO o cryptominers, que son disruptivos pero no implican robo directo de datos financieros.

    Mantenimiento y actualizaciones: responsabilidad compartida

    Aquí está el punto clave: ambas plataformas publican parches de seguridad regularmente, pero el éxito depende del administrador.

    WordPress: Las actualizaciones automáticas de core están habilitadas por defecto, lo que es excelente. Pero los plugins y temas no se actualizan automáticamente en la mayoría de instalaciones. He visto clientes con plugins comprometidos durante años sin saberlo.

    PrestaShop: Las actualizaciones requieren intervención manual del administrador o un panel de control que lo gestione. Es más trabajo, pero también significa que hay un punto de control consciente. El problema es que muchos administradores de PrestaShop no pueden permitirse tiempo de downtime, así que retrasan las actualizaciones.

    Lo que siempre recomiendo: independientemente de la plataforma, implementar un plan de actualizaciones forzadas, auditorías trimestrales de plugins/módulos, y monitoreo en tiempo real.

    Hardening: cómo reducir riesgo en cada plataforma

    WordPress hardening esencial:

    • Deshabilitar edición de archivos: añade a wp-config.php: define('DISALLOW_FILE_EDIT', true);
    • Cambiar prefijo de tablas de ‘wp_’ a algo aleatorio en instalación limpia.
    • Proteger wp-config.php con reglas .htaccess.
    • Limitar intentos de login a 5 por IP cada 15 minutos usando Wordfence o iThemes Security.
    • Implementar 2FA en todas las cuentas administrativas.
    • Usar WordPress Security Headers como HSTS, CSP, X-Frame-Options.

    PrestaShop hardening esencial:

    • Renombrar la carpeta /admin a algo impredecible y documentarlo en contraseña de administrador.
    • Proteger /admin con .htaccess de IP whitelist.
    • Cambiar permisos de carpetas a 755 y archivos a 644, nunca 777.
    • Almacenar config/settings.inc.php fuera de la raíz web si es posible.
    • Habilitar CSRF tokens en formularios y validar en servidor.
    • Auditar módulos de pago cada 3 meses: verifica que los archivos coincidan con el hash oficial.
    • Implementar WAF (Web Application Firewall) específico para PrestaShop con reglas ModSecurity.

    Detección de malware: herramientas por plataforma

    Cuando llega un cliente con un sitio comprometido, uso diferentes enfoques según la plataforma:

    WordPress: Ejecuto análisis con Wordfence CLI, verifico wp-content/plugins y wp-content/themes con hashes de repositorio oficial, y uso WP-CLI para listar usuarios y revisar caps de admin. El malware WordPress suele estar en functions.php, wp-config.php, o archivos .php huérfanos en /uploads.

    PrestaShop: Reviso /modules en busca de módulos modificados, analizo config/settings.inc.php para credenciales de BD, e inspecciono la carpeta /admin de PrestaShop y tablas de la BD para webshells. Uso VirusTotal con hashes de archivos .php sospechosos. Algunos backdoors PrestaShop se disfrazan como «módulos de optimización» en el panel administrativo.

    ¿Cuál es más seguro al final?

    La respuesta honesta: ninguno es «más seguro» de forma absoluta. La seguridad depende de cuatro factores:

    1. Modelo de amenaza: Si tu riesgo principal es spam SEO, WordPress es manejable. Si maneja datos de tarjetas de crédito, PrestaShop requiere más cuidado porque el impacto de un compromiso es financiero directo.
    2. Recursos disponibles: WordPress requiere auditoría activa de plugins; PrestaShop requiere menos extensiones pero más endurecimiento del servidor.
    3. Actualización: Ambas plataformas liberan parches de seguridad. La plataforma que uses es menos segura que aquella cuyos parches apliques religiosamente.
    4. Aislamiento: Un sitio WordPress con plugins auditados y actualizados es más seguro que un PrestaShop con módulos pirateados y /admin accesible al mundo.

    Lo que recomiendo siempre a clientes que deben elegir: si tienes ecommerce serio (miles de transacciones), PrestaShop con WAF es defensible. Si es contenido o blog con ecommerce ligero, WordPress con hardening robusto es suficiente. Pero en ambos casos, dedica presupuesto a auditorías de seguridad y monitoreo continuo.

    Casos de estudio reales de compromiso

    Hace tres meses limpié una tienda WordPress con un plugin de carrito comprometido que inyectaba un skimmer en páginas de checkout. El módulo malicioso robó datos de 2.000 clientes. El plugin estaba desactualizando 8 versiones atrás.

    Hace un mes, un cliente PrestaShop vino con su módulo de pago clonado ilegalmente de Stripe. El código malicioso enviaba datos de tarjeta a un servidor en Rusia. El daño fue mayor porque afectó el mismo core de transacciones.

    En ambos casos, el denominador común fue: falta de auditoría periódica y actualización negligente. La plataforma fue secundaria.

    Conclusión: seguridad es un proceso, no un producto

    WordPress y PrestaShop son seguros en manos de administradores conscientes de seguridad. Ambos publican parches de forma oportuna, ambos tienen comunidades de seguridad activas, y ambos pueden ser endurecidos significativamente.

    Lo que recomiendo: independientemente de tu plataforma, establece ciclos de actualización forzada, auditorías trimestrales de extensiones, monitoreo de integridad de archivos, y análisis de logs. Un WordPress sin auditoría es un desastre; un PrestaShop audited y mantenido es fortaleza.

    Si necesitas evaluar el estado real de tu sitio o limpiar un compromiso existente, contacta conmigo en ManuelFolgar.com para una auditoría de seguridad profesional. Realizo análisis de malware, hardening específico de tu plataforma, e implemento monitoreo continuo para evitar futuros compromisos.

  • Recuperar WordPress hackeado: paso a paso desde cero

    Recuperar WordPress hackeado: paso a paso desde cero

    Recuperar WordPress hackeado: guía completa paso a paso

    En mi experiencia limpiando más de 500 WordPress comprometidos, lo primero que observo es el pánico de los propietarios. Tu sitio está hackeado, tu tráfico cae, aparecen avisos de Google. Respira: la recuperación es posible si actúas con método. En este artículo te muestro exactamente cómo hacerlo desde cero, sin depender de nadie.

    ¿Cómo sé que mi WordPress está hackeado?

    Antes de empezar, necesitas confirmarlo. Los síntomas más comunes que veo en mis auditorías son:

    • Avisos de Google Search Console: «Sitio hackeado» o «Contenido malicioso detectado».
    • Cambios inexplicados: páginas nuevas, categorías, posts que no creaste.
    • Rendimiento lento: tu servidor cargado, CPU al 100%, conexiones de base de datos agotadas (síntoma típico de cryptominers).
    • Redirecciones: al pulsar enlaces, acabas en sitios de spam, casinos o contenido para adultos.
    • Código sospechoso: eval(), base64_decode() en archivos que no deberían tenerlo.
    • Advertencias de navegadores: «Este sitio puede dañar tu ordenador» en Chrome.
    • Correos de tu hosting: notificaciones de actividad sospechosa, malware detectado o abuso de recursos.

    Si tienes al menos 3 de estos síntomas, estamos ante un compromiso real. Ahora, vamos a recuperarlo.

    Paso 1: Aislamiento inmediato (las primeras 2 horas)

    No toques nada innecesariamente. Tu objetivo ahora es evitar más daño mientras reúnes información.

    Acción 1.1: Cambia todas las contraseñas de acceso. Desde otro ordenador (no el que puedas haber usado infectado), cambia:

    • Contraseña del usuario administrador en WordPress (wp-admin → Usuarios → Tu usuario → Nueva contraseña).
    • Contraseña FTP/SFTP del hosting.
    • Contraseña cPanel, Plesk o panel de control.
    • Contraseña del usuario de base de datos (en phpmyadmin → Usuarios).
    • Credenciales de correo asociadas al dominio.

    Lo que ves aquí es fundamental: los atacantes suelen guardar puertas traseras (backdoors). Cambiar contraseñas no basta; una contraseña nueva sin limpiar malware simplemente te permite entrar al mismo sitio comprometido.

    Acción 1.2: Realiza un backup de evidencia. Descarga por FTP la carpeta completa de WordPress (especialmente wp-content/plugins y wp-content/themes) y un dump de la base de datos. No es para restaurar; es para análisis posterior y, si es necesario, compartir con profesionales o fuerzas de seguridad.

    Acción 1.3: Desactiva plugins de una. Accede a wp-admin (con la contraseña nueva). Ve a Plugins → Todos los plugins. Desactiva cada uno individualmente sin eliminarlos todavía. Un plugin comprometido puede ser la puerta de entrada; muchas veces, el atacante instala plugins falsos o inyecta código en plugins legales.

    Paso 2: Análisis forense (2-4 horas)

    Ahora necesitas identificar qué exactamente está comprometido. En este paso uso herramientas profundas.

    Acción 2.1: Escanea con Wordfence CLI. Es gratuito y muy preciso. Conéctate por SSH a tu servidor y ejecuta:

    $ wp wordfence scan –skip-cache-flush

    Wordfence te listará archivos maliciosos, cambios en core, plugins sospechosos. Anota cada uno. Si no tienes SSH, usa OWASP ZAP desde tu máquina local para escanear la web pública.

    Acción 2.2: Revisa archivos de logs. Tu hosting almacena logs en:

    • /var/log/apache2/access.log (Apache) o /var/log/nginx/access.log (Nginx).
    • /home/tuusuario/public_html/wp-content/debug.log (si DEBUG está activo en wp-config.php).

    Busca patrones sospechosos: solicitudes a wp-login.php masivas (brute force), accesos a wp-admin.php en horarios raros, POST requests a archivos php en wp-content/uploads. Los logs son tu caja negra; guardan la evidencia del ataque.

    Acción 2.3: Analiza la base de datos. Accede a phpMyAdmin (en cPanel) o usa WP-CLI:

    $ wp db query «SELECT * FROM wp_posts WHERE post_status=’trash’ OR post_content LIKE ‘%eval%’ LIMIT 20;»

    Busca posts con código malicioso en su contenido, usuarios administrador no autorizados, posts en papelera que vieron hueco. Los atacantes suelen insertar posts ocultos para mantener SEO spam o backdoors en la metadata.

    Acción 2.4: Sube archivos sospechosos a VirusTotal. En VirusTotal, carga los plugins desactualizados, temas custom y cualquier archivo PHP que Wordfence haya marcado. VirusTotal analiza con 60+ motores antivirus. No es perfecto, pero atrapa el 95% de malware conocido.

    Paso 3: Limpieza de malware (4-8 horas)

    Con el análisis hecho, ahora eliminarás lo malicioso. Esto es irreversible, así que hazlo solo si tienes muy claro qué eliminas.

    Acción 3.1: Elimina plugins comprometidos. Ve a wp-admin → Plugins. Elimina cualquier plugin:

    • Que VirusTotal marque como positivo (incluso un motor de 60).
    • Que no reconozcas o que no tengas activo en tu lista.
    • Desactualizado hace más de 6 meses (especialmente los de seguridad como «Wordfence», «Sucuri», «iThemes» falsos).
    • Con nombres raros tipo «wp-settings-manager», «core-update», «database-backup».

    Después, accede a wp-content/plugins por FTP y elimina manualmente las carpetas de los plugins que borraste. Los atacantes a veces dejan código en plugins desinstalados.

    Acción 3.2: Reemplaza el tema. Vuelve a descargar tu tema oficial desde WordPress.org o tu proveedor (Themeforest, etc.). Sube toda la carpeta por FTP sobrescribiendo la antigua. Los temas modificados suelen inyectar código en functions.php para mantener acceso. Si usas un tema child, elimina también su carpeta y recrea solo el functions.php limpio.

    Acción 3.3: Actualiza WordPress core. Descarga la última versión de WordPress.org. Copia todos los archivos (excepto wp-content y wp-config.php) sobrescribiendo los existentes por FTP. Luego ejecuta en wp-admin: Herramientas → Actualizaciones de base de datos.

    Nota importante: No uses wp-admin para actualizar si desconfías de la seguridad del servidor. Las actualizaciones automáticas pueden ejecutar código antes de limpiar malware. Hazlo por FTP / SFTP.

    Acción 3.4: Limpia la base de datos. Elimina posts y usuarios sospechosos. En phpMyAdmin o con WP-CLI:

    $ wp user list –role=administrator

    ¿Ves administradores que no creaste? Elimínalos. En la tabla wp_posts, busca posts en papelera o con slugs raros. También limpia la tabla wp_postmeta y wp_options de cualquier entrada que contenga eval(), base64 o URLs sospechosas.

    Acción 3.5: Busca y elimina archivos backdoor en el servidor. Los backdoors típicos se llaman webshell.php, update.php, config.php (falso), shell.php, admin.php (falso). Conéctate por SSH y busca:

    $ find /home/tuusuario/public_html -name «*.php» -exec grep -l «eval|base64_decode|passthru|system|exec|shell_exec» {} ;

    Cada archivo que salga, revísalo en un editor de texto. Si contiene código de backdoor, eliminalo. Si es un archivo legítimo con esas funciones (como un plugin de backup), verifica que sea de confianza antes de eliminar.

    Paso 4: Hardening (prevención de futuros ataques)

    De nada sirve limpiar si en un mes vuelve a pasar. Aquí es donde la mayoría de administradores flaquea. Implementa estas medidas de seguridad ahora:

    Acción 4.1: Protege wp-config.php. Añade a tu .htaccess (en la raíz de WordPress):

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

    Acción 4.2: Deshabilita la edición de archivos en wp-admin. Añade a wp-config.php (antes de la línea «That’s all, stop editing!»):

    define(‘DISALLOW_FILE_EDIT’, true);

    Esto impide que si un atacante accede a wp-admin, pueda modificar plugins o temas desde el editor de código.

    Acción 4.3: Limita intentos de login a WordPress. Instala Wordfence Security (versión gratuita) o Loginizer. Configura máximo 5 intentos fallidos cada 15 minutos. Esto detiene ataques de fuerza bruta (brute force) contra wp-login.php.

    Acción 4.4: Activa 2FA en tu cuenta administrador. Con Wordfence o Google Authenticator, protege tu usuario admin con autenticación de dos factores. Si alguien consigue tu contraseña, sin el segundo factor no accede.

    Acción 4.5: Cambia el prefijo de tablas de base de datos. Por defecto es «wp_». Los atacantes lo conocen y pueden automatizar inyecciones SQL. Si tienes acceso SSH, puedes cambiarlo con herramientas como WP Security Audit Log o manualmente (es complejo; considéralo una tarea de profesional).

    Acción 4.6: Establece permisos correctos de archivos. En SSH, ejecuta:

    $ find /home/tuusuario/public_html -type f -exec chmod 644 {} ;
    $ find /home/tuusuario/public_html -type d -exec chmod 755 {} ;

    Esto asegura que los archivos no sean ejecutables por el usuario del servidor; reduce significativamente el riesgo de inyección de código.

    Acción 4.7: Configura backups automáticos. Usa UpdraftPlus (gratuito) o similar. Planifica un backup diario hacia Dropbox o tu email. Si vuelve a pasar, recuperas en 30 minutos.

    Paso 5: Limpieza ante Google y reputación

    Google avisa a usuarios que tu sitio está comprometido. Debes notificarle que está limpio.

    Acción 5.1: Accede a Google Search Console. Ve a Seguridad e informes manualesProblemas de seguridad. Allí aparecerán los avisos. Haz clic en «Solicitar revisión». Google tarda 24-72 horas en verificar que has limpiado el malware. No rellenar esta solicitud alarga el aviso semanas.

    Acción 5.2: Solicita eliminación de contenido malicioso si está indexado. En Search Console → Remover, elimina URLs de spam, posts inyectados o redirectores que apunten a sitios maliciosos. Esto ayuda a borrar la «memoria» de Google.

    Acción 5.3: Reindexación. Después de limpiar, solicita a Google que rastree tu sitio de nuevo. En Search Console → Inspección de URL, introduce tu página principal y pulsa «Solicitar indexación». Google enviará bots en las próximas horas.

    ¿Qué hago si no puedo hacerlo yo?

    Entiendo que esto es técnico y requiere paciencia. Algunos pasos como la búsqueda de backdoors o la reconfiguración de permisos son complejos si no tienes experiencia con SSH.

    Mi equipo en ManuelFolgar.com se especializa precisamente en esto: limpieza forense de malware, hardening completo y auditoría post-ataque. Analizamos tu sitio en profundidad, identificamos el vector de ataque inicial (plugin desactualizador, contraseña débil, etc.) y lo cerramos para que no vuelva a pasar.

    Si has seguido este artículo y te quedas atascado, o prefieres que un profesional lo haga desde el primer minuto, contacta conmigo aquí. Ofrezco diagnóstico gratuito en 24 horas.

    Resumen de tiempos

    La recuperación total suele llevar:

    • Aislamiento: 2 horas.
    • Análisis: 4 horas.
    • Limpieza: 6-8 horas (depende de cuánto malware haya).
    • Hardening: 2 horas.
    • Revisión de Google: 24-72 horas (no cuenta en tu tiempo).

    Total: entre 14 y 18 horas de trabajo técnico concentrado. Hacerlo con prisas o saltándose pasos es el principal motivo por el que el malware vuelve semanas después.

    Si tu sitio es crítico para tu negocio, no pierdas tiempo en prueba y error. Solicita limpieza profesional ahora; los tiempos de inactividad cuestan más que la inversión en un especialista.

  • Qué hacer si tu sitio WordPress muestra contenido malicioso

    Qué hacer si tu sitio WordPress muestra contenido malicioso

    Qué hacer si tu sitio WordPress muestra contenido malicioso

    Cuando analizo un sitio WordPress comprometido, lo primero que veo es el pánico del propietario. Y es comprensible: tu web muestra anuncios raros, redirige a sitios de apuestas, o peor aún, Google la ha marcado como peligrosa. Te digo por experiencia que es recuperable, pero necesitas actuar ya.

    El contenido malicioso en WordPress no aparece por arte de magia. Detrás hay un ataque real: un plugin vulnerable, una contraseña débil, o un backdoor que se coló hace semanas sin que lo vieras. En este artículo te muestro exactamente qué hacer para identificarlo, limpiarlo y evitar que vuelva a pasar.

    Síntomas de que tu WordPress tiene contenido malicioso

    No siempre es evidente. A veces el malware es muy discreto. Lo que recomiendo siempre es que verifiques estos indicadores:

    • Redirecciones extrañas: Cuando entras a tu web, te lleva a casinos, sitios de phishing o descargadores de malware. Esto es típico de backdoors o plugins inyectados.
    • Contenido fantasma: Ves posts o páginas que nunca creaste. Muchas veces están ocultos en el front-end pero indexados en Google (spam SEO).
    • Anuncios intrusivos: Publicidad de criptomonedas, préstamos rápidos o medicamentos sin licencia. Generalmente inyectada vía JavaScript malicioso.
    • Alerta de Google Search Console: «Sitio comprometido detectado» o «Contenido no deseado». Google es bastante fiable en esto.
    • Rendimiento lento: El servidor va a paso de tortuga. Un cryptominer consume CPU constantemente.
    • Cambios en wp-config.php o .htaccess: Líneas extrañas, dominios raros, código ofuscado. Eso no lo pusiste tú.
    • Usuarios admin que no reconoces: En Usuarios de WordPress aparecen cuentas que nunca creaste. Backdoor clásico.

    Paso 1: Aislamiento inmediato (antes de tocar nada)

    Aquí es donde muchos se equivocan. Si empiezas a borrar sin estrategia, puedes perder logs valiosos o dejar el backdoor activo. Lo que hago siempre es:

    Desactiva el sitio sin eliminarlo: Reemplaza el index.php de tu web con una página estática que diga «Sitio en mantenimiento». Esto detiene el malware sin borrarlo.

    Accede al servidor por SSH (no por FTP): FTP envía contraseñas sin cifrar. Usa SSH con clave pública:

    ssh usuario@tuprovedor.com

    Haz una copia de seguridad completa del servidor: Aunque esté comprometido, la necesitarás para forense o recuperación. Descarga /home/usuario/public_html completo:

    scp -r usuario@tuprovedor.com:/home/usuario/public_html ./backup-malware

    Revisa logs de acceso: En /var/log/apache2/access.log (o nginx/access.log) verás las IPs y URLs que gatillaron el ataque. Busca patrones de inyección SQL o RFI:

    tail -500 /var/log/apache2/access.log | grep -E «(union|select|script|shell)»

    Paso 2: Identificar el vector de ataque

    Antes de limpiar, necesito saber cómo entraron. Esto es crítico. Las causas principales que veo en mi trabajo:

    Plugins o temas desactualizados (60% de casos): Es el camino más fácil. Un plugin viejo tiene CVEs públicas que cualquier bot automatizado explota. Accede vía SSH y lista todos los plugins con versiones:

    find ./wp-content/plugins -name «readme.txt» -exec grep «Version» {} +

    Compáralo con NVD de NIST o el repositorio oficial de WordPress. Si encuentras uno con CVE crítica, ese fue el punto de entrada.

    Contraseña de admin débil (30% de casos): El atacante hizo brute force contra wp-login.php. Revisa en WordPress:

    • Ajustes → General → Dirección de WordPress
    • Busca también en los logs si hay intentos de login fallidos masivos en wp-login.php

    Servidor mal configurado (10% de casos): Permisos de carpetas demasiado permisivos (777), PHP inseguro, o software de servidor viejo. En SSH:

    ls -la /home/usuario/public_html

    Las carpetas no deberían estar en 777. Debería ser 755 como máximo.

    Paso 3: Limpieza manual vs. herramientas

    Aquí tienes dos caminos. Te digo cuál es cada uno:

    Opción A: Limpieza manual (para ataques leves):

    Si identificaste el plugin malicioso, accede por SSH y elimina su carpeta completa:

    rm -rf /home/usuario/public_html/wp-content/plugins/nombre-plugin-malicioso

    Luego, busca código inyectado en las funciones.php del tema activo:

    grep -r «eval|base64_decode|system|exec» /home/usuario/public_html/wp-content/themes/tu-tema/

    Cualquier línea que tenga esas funciones es sospechosa. Elimínala.

    Revisa también .htaccess (puede tener redirecciones maliciosas):

    cat /home/usuario/public_html/.htaccess

    Opción B: Herramientas automatizadas (para infecciones complejas):

    Cuando la infección es profunda, las herramientas ahorran tiempo. Yo uso:

    • Wordfence CLI: Instálalo en el servidor. Detecta malware conocido y backdoors. wp wordfence scan
    • MalCare: Escaneo en la nube, identifica código ofuscado. Ofrece limpieza automatizada también.
    • WP-CLI con auditoría manual: Aunque es más lento, es más preciso.

    Paso 4: Búsqueda de backdoors persistentes

    El malware serio deja backdoors. Son archivos que permiten acceso remoto incluso después de que creas que está limpio. Búscalos en carpetas temp y uploads:

    find /home/usuario/public_html -name «*.php» -newer /home/usuario/public_html/index.php | head -20

    Esto te muestra archivos PHP modificados recientemente. Cualquier .php raro en /wp-content/uploads/ es casi seguro un backdoor. Nombres típicos: shell.php, admin.php, c99.php, r57.php, uploader.php.

    También busca archivos JavaScript malicioso:

    grep -r «document.write|eval(» /home/usuario/public_html/wp-content/

    Si encuentras algo, no lo ejecutes. Solo bórralo:

    rm archivo-sospechoso.php

    Paso 5: Limpiar la base de datos

    El malware también se mete en la BD. Accede a phpMyAdmin o vía WP-CLI:

    wp db query «SELECT * FROM wp_posts WHERE post_type=’post’ AND post_author NOT IN (SELECT ID FROM wp_users)»

    Esto te muestra posts sin autor válido. Bórralos:

    wp post delete ID –force

    También revisa opciones raras:

    wp option list | grep -E «(eval|serialize|base64)»

    Paso 6: Cambiar todas las contraseñas y tokens

    Si llegaron a tu WordPress, llegaron a tus credenciales. No puedes dejarlas igual. Haz esto:

    • Cambia contraseña de admin en WordPress: Usuarios → Tu perfil → Contraseña nueva
    • Regenera claves de seguridad de wp-config.php: Usa el generador de WordPress y reemplaza todas las KEY y SALT
    • Cambia FTP/SSH del hosting
    • Cambia contraseña de base de datos en wp-config.php
    • Termina todas las sesiones activas en WordPress: Herramientas → Ajustes de sesión

    Paso 7: Hardening definitivo para que no vuelva

    Una limpieza sin hardening es un parche temporal. Lo que recomiendo siempre:

    Protege wp-login.php: Añade esto a .htaccess para limitar intentos de login:


    <Limit POST PUT>
    Order Allow,Deny
    Allow from all
    </Limit>

    Deshabilita edición de archivos en WordPress: Añade a wp-config.php:

    define(‘DISALLOW_FILE_EDIT’, true);

    Limita permisos de carpetas:


    chmod 755 /home/usuario/public_html
    chmod 755 /home/usuario/public_html/wp-content
    chmod 644 /home/usuario/public_html/wp-config.php

    Actualiza todo: Plugins, temas, WordPress core. Siempre.

    Instala un plugin de seguridad: Wordfence, Sucuri, o iThemes Security. Te avisan de cambios raros.

    Implementa 2FA: En el admin, con Google Authenticator o Authy.

    Genera un CSP (Content Security Policy): Esto previene inyección de scripts. En .htaccess:

    Header set Content-Security-Policy «default-src ‘self’»

    Paso 8: Notifica a Google y AEPD

    Si tu sitio fue marcado como comprometido, Google lo sabe. Entra en Google Search Console, ve a Seguridad → Problemas de seguridad, y marca la acción como resuelta.

    Google tarda días en reindexar, así que mientras tanto tendrás tráfico bajo. Es normal.

    También, según la AEPD, si recopilaban datos personales, debes notificar el incidente. Es obligatorio si hay riesgo para usuarios.

    Qué no debes hacer bajo ningún concepto

    • No reinstales WordPress encima del actual: Eso no elimina el malware, solo lo entierra.
    • No uses contraseñas predecibles: «admin123» o «wordpress» son lo primero que prueba un bot.
    • No ignores las alertas de seguridad: Si Wordfence te avisa de algo, investiga ese mismo día.
    • No confíes en «limpiadoras» gratuitas desconocidas: Muchos son estafas que empeoran la situación.
    • No dejes plugins inactivos años: Aunque desactivados, son vectores de ataque igual.

    Cuándo llamar a un profesional

    Sé honesto contigo mismo. Si encuentras más de un backdoor, si el malware está ofuscado con base64 múltiples niveles, o si no controlas SSH, necesitas ayuda. En mi trabajo veo situaciones donde el propietario ha pasado dos días intentando limpiar y ha empeorado las cosas.

    Un profesional:

    • Identifica todas las infecciones, no solo las obvias
    • Preserva evidencia para denuncias (si es necesario)
    • Configura hardening específico para tu ambiente
    • Monitoriza durante 30 días post-limpieza
    • Da garantía de que no vuelva

    Yo siempre digo: la diferencia entre intentar limpiarlo tú y hacerlo profesionalmente no es solo técnica, es de confianza. Cuando terminas, sabes que está limpio. No tienes dudas a las 3 de la mañana.

    Resumen de acciones inmediatas

    Si acabas de descubrir que tu WordPress tiene malware, hace esto ahora mismo:

    1. Aisla el sitio (mode mantenimiento)
    2. Haz backup completo del servidor
    3. Revisa logs de acceso para el vector de ataque
    4. Identifica y elimina plugins/temas sospechosos
    5. Busca backdoors en /wp-content/uploads y funciones.php
    6. Limpia la base de datos de posts huérfanos
    7. Cambia todas las contraseñas
    8. Implementa hardening (.htaccess, permisos, CSP)
    9. Notifica a Google
    10. Si no controlas, contacta a un experto

    El contenido malicioso en WordPress es recuperable. He visto webs pegadas del peor malware volver a estar limpias y seguras. Pero requiere precisión, paciencia y sin prisa. Y si en algún momento tienes dudas sobre si lo que ves es realmente malware, o si necesitas alguien que lo maneje de principio a fin, en ManuelFolgar.com hacemos exactamente eso: identificamos, limpiamos, y endurecemos tu WordPress.

    Si crees que tu sitio está comprometido, contacta conmigo para una auditoría gratuita de seguridad. Analizaré tu WordPress, te diré exactamente qué tiene y cuánto cuesta recuperarlo. Sin sorpresas.