Etiqueta: hardening

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

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

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

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

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

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

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

    Es obligatorio cuando:

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

    Vectores de ataque que exigen análisis forense obligatorio

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

    Backdoors persistentes y webshells multimodulares

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

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

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

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

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

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

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

    Malware Magecart y skimmers de tarjetas de crédito

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

    El análisis forense aquí es obligatorio porque:

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

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

    Acceso administrativo comprometido a largo plazo

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

    Cuando finalmente lo descubres, necesitas saber:

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

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

    Cryptominers y consumo anómalo de recursos

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

    El análisis forense es obligatorio porque:

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

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

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

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

    Fase 1: Aislamiento y captura de evidencia

    Lo primero que hago es:

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

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

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

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

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

    Fase 3: Análisis de base de datos

    Aquí es donde muchas infecciones se esconden:

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

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

    Los logs del servidor cuentan la historia del ataque:

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

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

    Fase 5: Cálculo de impacto y conformidad legal

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

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

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

    Por qué una limpieza superficial siempre falla

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

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

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

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

    Herramientas profesionales que uso en análisis forense

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

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

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

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

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

    Pero considera el costo real de no hacerlo:

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

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

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

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

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

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

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

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

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

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

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

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

  • WordPress hackeado y ChatGPT no da solución: qué hacer ahora mismo

    WordPress hackeado y ChatGPT no da solución: qué hacer ahora mismo

    WordPress hackeado y ChatGPT no da solución: por qué la IA no es suficiente

    Te has dado cuenta de que tu sitio WordPress está comprometido. Buscas en Google, abres ChatGPT, le haces preguntas sobre cómo limpiar malware, y obtienes respuestas genéricas que no funcionan. Es frustrante, ¿verdad? Aquí te cuento por qué esto ocurre y qué debes hacer ahora mismo.

    En mi experiencia analizando sitios hackeados, la principal razón por la que ChatGPT y otras herramientas de IA generativa falla es simple: no tienen acceso al código real de tu sitio. Una IA entrenada con datos públicos puede explicarte conceptos generales sobre seguridad web, pero no puede detectar dónde está el backdoor específico que dejó el atacante en tus archivos, ni sabe qué tipo de malware exacto está alojado en tu servidor.

    La limitación crítica de ChatGPT frente a WordPress hackeado

    Cuando un sitio WordPress sufre un ataque exitoso, el atacante puede haber dejado múltiples puertas traseras: webshells en carpetas ocultas, código inyectado en funciones.php de temas nulled, backdoors en plugins comprometidos, o incluso modificaciones en wp-config.php. ChatGPT te dirá «busca archivos sospechosos» o «reinstala WordPress», pero no puede:

    • Acceder via SFTP o SSH a tu servidor para inspeccionar archivos línea por línea
    • Comparar el hash de tus archivos contra la base de datos oficial de WordPress.org
    • Identificar código obfuscado o ofuscado que un atacante ha insertado
    • Analizar logs de acceso del servidor para rastrear la ruta exacta del ataque
    • Ejecutar herramientas como Wordfence CLI o MalCare para escanear en profundidad

    Además, si sigues los pasos genéricos de una IA sin conocer tu contexto específico, puedes eliminar funcionalidades legítimas, romper plugins de clientes o perder configuraciones críticas. Lo que funciona en un sitio puede causar desastres en otro.

    Señales reales de que tu WordPress está comprometido

    Antes de actuar, necesitas confirmar que realmente hay un problema. Estos son los indicadores que veo constantemente en auditorías:

    Síntomas técnicos verificables

    • Redirecciones inesperadas: Cuando accedes a tu home o a páginas aleatorias, te redirige a sitios de apuestas, casinos o malware. Esto indica un malware redirector.
    • Inyección de contenido HTML/JavaScript: En Google Search Console ves notificaciones de «contenido no esperado»; al inspeccionar código fuente, encuentras scripts o iframes ocultos al final de la página o en el head.
    • Defacement: Tu home muestra contenido que no escribiste, banners extraños, o mensajes de «hackeado».
    • Ralentización extrema: El sitio va muy lento porque está minando criptomonedas en segundo plano (cryptominer).
    • Alertas de navegadores: Chrome o Firefox avisan sobre malware o contenido peligroso cuando visitas tu sitio.
    • Cambios sin autorización: Usuarios, plugins, temas, o contenido que no creaste aparecen en tu WordPress.
    • Errores 404 masivos: De repente muchas URLs devuelven errores; es posible que el atacante haya borrado archivos o modificado la base de datos.

    Indicadores en herramientas online

    Accede a estas plataformas de análisis gratuito para confirmar:

    • Sucuri SiteCheck: Escanea malware, backdoors y inyecciones conocidas.
    • VirusTotal: Analiza tu dominio contra múltiples antivirus.
    • Google Search Console: Revisa «Seguridad» para alertas de malware o content injection.
    • NVD (National Vulnerability Database): Busca CVEs publicadas para tus plugins o versión de WordPress.

    Plan de acción inmediato (que ChatGPT no puede ejecutar)

    Paso 1: Aislamiento y acceso al servidor

    Lo primero es detener la propagación del daño. Debes tener acceso real a tu servidor:

    1. Solicita credenciales SFTP/SSH a tu hosting. Si no las tienes, contacta con el proveedor ahora.
    2. Si el WordPress tiene administrador comprometido: Cambia contraseñas de hosting, bases de datos y cualquier cuenta raíz antes de entrar al back-office.
    3. Descarga una copia completa de tu /wp-content/plugins, /wp-content/themes y /wp-admin a tu PC para análisis posterior. Esto es evidencia.
    4. Revisa /wp-content/uploads: Los atacantes suelen alojar webshells (php malicioso ejecutable) aquí, camuflados como imágenes o archivos.

    Paso 2: Búsqueda manual de backdoors y webshells

    Aquí es donde la mayoría de la gente se pierde sin ayuda profesional. Un backdoor no se ve a simple vista. Necesitas:

    • Escanear archivos .php recientes: En tu editor de archivos o SFTP, ordena por fecha de modificación. Si ves un archivo php en /uploads/ creado ayer, es sospechoso.
    • Revisar temas activos: Abre functions.php del tema. Si contiene código ofuscado (base64_decode, eval, create_function), ese es malware. Los temas nulled vienen frecuentemente contaminados.
    • Analizar plugins recientemente instalados: Si encuentras plugins que no instalaste, desactívalos inmediatamente y guarda sus archivos para análisis.
    • Buscar archivos .htaccess modificados: Un atacante puede manipular reglas de reescritura para redirigir tráfico.

    Si no sabes leer código PHP, aquí viene la realidad incómoda: no deberías intentar esto solo. Un error puede dejar abierto el acceso del atacante o borrar funcionalidades legales.

    Paso 3: Limpieza real vs. limpieza superficial

    ChatGPT te dirá «reinstala WordPress». Eso es peligroso si:

    • No has eliminado todos los backdoors antes. El atacante sigue dentro.
    • No has parchado la vulnerabilidad original. Te hackean nuevamente en días.
    • Tienes datos legítimos en la base de datos que perderías (posts, comentarios, configuración).

    La limpieza real implica:

    1. Identificar y eliminar cada archivo malicioso: No es reinstalar WordPress; es cirugia selectiva.
    2. Analizar logs del servidor: Revisa /var/log/apache2/access.log (o nginx). Busca solicitudes GET/POST a archivos php sospechosos, URLs con caracteres raros (como %23, %27, union select). Esto te dice cómo entraron.
    3. Auditar la base de datos: Usa herramientas como WP-CLI para buscar usuarios administrador que no creaste, opciones de WordPress alteradas, o posts con contenido spam inyectado.
    4. Cambiar TODAS las contraseñas: FTP, WordPress, hosting, base de datos, email. Si el atacante estuvo dentro, asume que todo está comprometido.
    5. Actualizar WordPress, plugins y temas a versión actual. Sin excepciones.

    Las herramientas que ChatGPT no conoce (pero que funcionan)

    En mi trabajo diario con sitios hackeados, uso estas herramientas especializadas que una IA simplemente no puede ejecutar:

    Wordfence CLI

    Es el escáner de seguridad profesional de WordPress. Funciona desde línea de comandos (SSH) e identifica malware, vulnerabilidades de plugins conocidas y anomalías de archivos. Genera reportes que hasta un principiante entiende.

    MalCare

    Servicio cloud que analiza tu sitio sin necesidad de instalar plugins. Detecta webshells, backdoors obfuscados y código malicioso inyectado en núcleo de WordPress. Ofrece limpieza automatizada en algunos casos.

    WP-CLI (WordPress Command Line Interface)

    Permite ejecutar comandos potentes directamente en tu servidor. Puedo auditar usuarios, revisar opciones de base de datos, listar plugins desactualizados, y hacer cambios masivos sin GUI.

    Logs de servidor + herramientas de análisis

    Los logs de Apache o Nginx contienen toda la historia del ataque. Con grep, awk o herramientas como ELK Stack puedo rastrear exactamente qué hizo el atacante y cuándo.

    ¿Qué pasa si intento confiar únicamente en ChatGPT?

    Estos son riesgos reales que veo cuando los clientes intentan «autorrepararse» con guías de IA:

    • El atacante sigue dentro: No encuentras el backdoor principal. Cambias contraseña, das por «solucionado» el tema, y en una semana vuelves a estar hackeado.
    • Pierdes datos valiosos: Si sigues mal un comando de limpieza, borras plugins o posts legítimos. He visto sitios perder catálogos de productos enteros.
    • El SEO se queda dañado: Google sigue viendo contenido malicioso indexado. Tu ranking cae. Tardarás meses en recuperarte aunque el sitio esté limpio.
    • Responsabilidad legal: Si tu sitio fue usado para distribuir malware a otros usuarios, la AEPD puede investigarte por falta de diligencia. Un sitio «limpio» por IA sin auditoría profesional no es defensa legal.
    • Costo de oportunidad: Mientras pierdes tiempo experimentando, tu negocio está offline o comprometido. Cada hora cuenta.

    Cuándo necesitas profesionales (ahora mismo)

    Deberías contactar con expertos en seguridad WordPress inmediatamente si:

    • Tu sitio recibe más de 500 visitas diarias (el impacto de estar comprometido es crítico).
    • Procesa pagos o datos sensibles de clientes (PCI-DSS, RGPD).
    • No tienes acceso SSH/SFTP o no sabes usarlo.
    • Ya has intentado limpiar y sigue pasando.
    • No sabes cómo analizar código PHP ofuscado.
    • Necesitas un reporte forense o documentación legal del ataque.
    • Quieres hardening preventivo para que no vuelva a ocurrir.

    Plan de hardening post-limpieza (esto ChatGPT sí puede ayudar a explicar, pero no ejecutar)

    Una vez limpio el sitio, necesitas construir defensas:

    Configuración de WordPress

    • Cambiar prefijo de tablas: De wp_ a algo aleatorio. Complica ataques de inyección SQL.
    • Deshabilitar edición de archivos: Añade a wp-config.php: define('DISALLOW_FILE_EDIT', true);
    • Proteger wp-config.php: Reglas .htaccess que bloqueen acceso directo a este archivo.
    • Limitar intentos de login: Plugin como Wordfence o configuración de servidor que bloquee después de 5 intentos fallidos.
    • Activar 2FA (autenticación de dos factores): Para todos los administradores.
    • Cambiar URL de admin: De /wp-admin a algo como /secreto-admin-12345. Evita ataques brute force masivos.

    Configuración de servidor

    • Headers de seguridad HTTP: X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security (HSTS). Bloqueando ataques XSS, clickjacking y MITM.
    • Content Security Policy (CSP): Whitelist de qué scripts pueden ejecutarse. Bloquea inyecciones de JS malicioso.
    • Permisos de carpetas: /wp-content/ y /uploads/ en 755 (no 777, que es puerta abierta). Archivos en 644.
    • Desactivar ejecución de PHP en carpetas peligrosas: Regla .htaccess en /uploads/ que bloquee .php.

    Monitoreo continuo

    • Backup automático diario (sin almacenar en el mismo servidor).
    • Monitoreo de cambios de archivos: herramientas como AIDE o Tripwire alertan si alguien modifica código.
    • Auditoría de logs: revisión periódica de accesos sospechosos.
    • Actualizaciones automáticas: WordPress core, plugins y temas.

    El factor humano que ChatGPT no entiende

    La razón por la que contratar profesionales en seguridad es diferente a un chatbot:

    Responsabilidad: Si yo limpio tu sitio y la seguridad falla, tengo un contrato y seguros. ChatGPT no.

    Contexto real: Veo tu infraestructura completa, tu hosting, tu flujo de trabajo. Propongo defensas personalizadas. ChatGPT da pasos genéricos.

    Investigación forense: Documento cómo entraron, qué hicieron, qué robaron. Es información valiosa para tu abogado, seguros, o cumplimiento RGPD.

    Garantía: Si vuelves a ser hackeado en 30 días por la misma puerta, lo reparo gratis. ChatGPT no tiene garantía.

    Resumen: tu siguiente paso

    Si tu WordPress está hackeado y ChatGPT no te da respuestas concretas, es porque el problema no es conceptual, es técnico. Necesitas acceso al servidor, análisis de código, herramientas especializadas y responsabilidad profesional.

    No es una crítica a la IA. Es una realidad: ciertos trabajos requieren manos en el código.

    Consulta con un profesional certificado en seguridad WordPress que pueda:

    1. Analizar tu sitio línea por línea (no AI, humanos o herramientas profesionales).
    2. Identificar exactamente cómo fueron comprometidos.
    3. Limpiar todos los backdoors sin romper funcionalidades.
    4. Darte un reporte forense.
    5. Implementar defensas que prevengan futuros ataques.

    Si necesitas ayuda ahora mismo, en ManuelFolgar.com ofrecemos auditorías de seguridad, limpieza de malware y hardening profesional para WordPress. Contacta con nuestro equipo para un análisis gratuito de tu situación específica. No hacemos guessing; hacemos diagnóstico real.

    Tu sitio, tus datos y tu reputación online merecen más que respuestas genéricas. Actúa ahora.

  • Cambiar proprietario de archivos: restaurar permisos correctos tras hackeo

    Cambiar proprietario de archivos: restaurar permisos correctos tras hackeo

    Cambiar propietario de archivos: restaura permisos correctos tras un hackeo

    Cuando analizó un sitio web comprometido, una de las primeras cosas que reviso es la propiedad de los archivos y directorios. En mi experiencia, los hackers casi siempre dejan rastros evidentes: archivos creados por el usuario www-data, root o incluso propietarios fantasma que no debería existir en tu servidor. Restaurar los permisos correctos es crítico para evitar reinfecciones y asegurar que tu sitio funciona bajo la identidad de usuario correcta.

    En este artículo te explicaré cómo identificar propietarios incorrectos, las herramientas que necesitas y los pasos concretos para restaurar tu WordPress o PrestaShop a un estado seguro.

    ¿Por qué los hackers cambian propietarios de archivos?

    Cuando un atacante obtiene acceso a tu servidor (a través de un plugin desactualizado, una contraseña débil o una inyección SQL), lo primero que intenta es ganar persistencia. Cambiar la propiedad de los archivos es una técnica común porque:

    • Evasión de detección: si tu servidor está configurado para que WordPress sea propiedad de tu usuario FTP/SFTP, un archivo de propietario www-data destaca y es un indicador de compromiso.
    • Acceso permanente: un webshell con propietario www-data sigue siendo ejecutable incluso después de que cambies tu contraseña FTP.
    • Dificulta la limpieza: algunos administradores inexpertos no notan que los permisos están mal y el malware persiste silenciosamente.
    • Bloqueo de acceso: en algunos casos, el hacker cambia la propiedad a un usuario de máquina inexistente, bloqueándote incluso a ti.

    He visto casos donde un cliente no podía eliminar archivos mediante FTP porque la propiedad había sido transferida a nobody o a un usuario fantasma. Fue una situación frustrante que podría haberse evitado con auditorías regulares.

    Identificar propietarios y permisos incorrectos

    Conectar por SSH y revisar la estructura

    Si tienes acceso SSH a tu servidor (y lo recomiendo siempre), el primer paso es conectar y listar los archivos con información de propiedad:

    ls -la /ruta/a/tu/wordpress

    La salida te mostrará algo como:

    -rw-r--r-- 1 usuario grupo 1024 Jan 15 10:30 index.php

    Las partes clave son: usuario (owner) y grupo (group). En una instalación correcta de WordPress en un servidor compartido, debería ser algo como:

    • Usuario propietario: tu usuario FTP (ej: miseñoweb, usuario1, etc.) o www-data si estás en un servidor dedicado con PHP-FPM bien configurado.
    • Grupo: www-data, www, httpd o similar (el usuario web del servidor).

    Si ves propietarios raros como root, nobody, mysql o usuarios que no reconoces, es un indicador de compromiso.

    Automatizar la detección con find

    En lugar de revisar archivo por archivo, puedo usar find para detectar anomalías:

    find /ruta/a/wordpress -not -user miusuario -not -user www-data -type f

    Este comando lista todos los archivos que NO son propiedad de tu usuario FTP ni de www-data. Si aparecen archivos, tienes un problema.

    Restaurar propietarios correctos en WordPress

    Opción 1: Cambiar propietario a tu usuario FTP (servidores compartidos)

    En hosting compartido, lo habitual es que los archivos sean propiedad de tu usuario FTP:

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

    Reemplaza miusuario con tu usuario real. El parámetro -R (recursivo) cambia todos los archivos y carpetas dentro del directorio.

    Nota importante: el grupo debe seguir siendo www-data para que el servidor web pueda leer los archivos. No cambies el grupo a tu usuario.

    Opción 2: Cambiar propietario a www-data (servidores dedicados con PHP-FPM)

    Si usas un servidor dedicado con PHP-FPM correctamente configurado, el propietario debe ser www-data en todos los archivos:

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

    Esta es la configuración más segura en servidores modernos porque el proceso PHP se ejecuta como www-data, evitando escaladas de privilegios.

    Restaurar permisos numéricos (CHMOD)

    Una vez hayas corregido el propietario, es hora de los permisos. Los permisos correctos en WordPress son:

    • Directorios: 755 (rwxr-xr-x) – el propietario lee, escribe y ejecuta; otros solo leen y ejecutan.
    • Archivos PHP y datos: 644 (rw-r–r–) – el propietario lee y escribe; otros solo leen.
    • wp-config.php: 600 (rw——-) – solo el propietario puede acceder.
    • carpeta /uploads: 755 en la carpeta, 644 en archivos dentro.

    Para establecer estos permisos desde SSH:

    find /ruta/a/wordpress -type d -exec chmod 755 {} ;
    find /ruta/a/wordpress -type f -exec chmod 644 {} ;
    chmod 600 /ruta/a/wordpress/wp-config.php

    Esto es clave: si los permisos son demasiado permisivos (777 o 666), cualquiera en el servidor puede modificar tus archivos. He encontrado backdoors en sitios que tenían permisos 777 en directorios completos.

    Restaurar permisos en PrestaShop

    PrestaShop es similar, pero con algunas particularidades. La estructura correcta es:

    • Directorios: 755
    • Archivos: 644
    • config/settings.inc.php: 644 (en algunos casos 600)
    • carpeta /upload: 755 con archivos 644

    El propietario debe seguir la misma lógica que WordPress: tu usuario FTP en hosting compartido, www-data en dedicado.

    chown -R miusuario:www-data /ruta/a/prestashop
    find /ruta/a/prestashop -type d -exec chmod 755 {} ;
    find /ruta/a/prestashop -type f -exec chmod 644 {} ;

    Casos especiales: detectar y eliminar webshells

    Después de cambiar propietarios, es posible que haya webshells o backdoors ocultos. Buscar archivos con propietarios sospechosos es un indicador, pero también debes revisar:

    Archivos PHP sospechosos

    Muchos hackers suben archivos con nombres inocentes (shell.php, admin.php, update.php) en directorios menos obvios como wp-content/uploads, plugins desactivados o themes sin usar.

    find /ruta/a/wordpress -name "*.php" -type f -newer /ruta/a/wordpress/index.php

    Este comando lista archivos PHP más nuevos que index.php, lo que puede indicar qué se subió tras el hackeo.

    Archivos con permisos anómalo

    find /ruta/a/wordpress -perm /111 -type f -name "*.php"

    Esto busca archivos PHP ejecutables por el propietario, grupo u otros. Un archivo PHP nunca debería ser ejecutable en el sistema de archivos (el servidor web se encarga de ejecutarlo).

    Verificar cambios con Wordfence CLI o MalCare

    Después de restaurar permisos, te recomiendo usar herramientas especializadas para confirmar que no hay malware residual:

    • Wordfence CLI: escanea archivos WordPress en busca de cambios respecto a versiones oficiales. Es gratuito y muy potente.
    • MalCare: detección automática de webshells y malware incluso si no coincide con firmas conocidas.
    • WP-CLI: con comandos personalizados para revisar integridad de plugins y temas.

    La combinación de cambio de propietarios + análisis de malware es tu mejor defensa. No hagas uno sin el otro.

    Implementar protecciones adicionales tras la restauración

    Deshabilitar edición de archivos

    Una vez hayas limpiado el sitio, evita que nadie (incluso atacantes con acceso al panel admin) pueda editar archivos PHP:

    En wp-config.php, añade:

    define('DISALLOW_FILE_EDIT', true);

    Esto desactiva el editor de archivos en el panel de WordPress, reduciendo la superficie de ataque significativamente.

    Proteger wp-config.php con .htaccess

    En el directorio raíz de WordPress, crea o edita .htaccess:

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

    Esto previene acceso directo al archivo de configuración, incluso si se coloca una inyección.

    Cambiar prefijo de tablas de base de datos

    Si el hacker accedió a la base de datos, también debería cambiar el prefijo (por defecto wp_):

    define('DB_PREFIX', 'wnq42_');

    Esto complica los ataques de inyección SQL dirigidos a tablas específicas. Requiere cierto trabajo de migración, pero vale la pena en sitios críticos.

    Auditoría post-hackeo: la lista de verificación

    Cuando finalices la restauración de propietarios, verifica:

    1. Todos los archivos tienen propietario correcto (tu usuario o www-data, según configuración).
    2. Todos los directorios tienen permisos 755, archivos 644, excepto wp-config.php en 600.
    3. No hay archivos PHP sospechosos en directorios de upload o temas desactivados.
    4. Escaneo antimalware con Wordfence CLI o MalCare sin detecciones.
    5. Cambio de contraseñas de FTP, SSH, base de datos y panel admin.
    6. Actualización de todos los plugins, temas y WordPress al último parche.
    7. Revisión de logs de servidor en /var/log/apache2 o /var/log/nginx para actividad sospechosa.

    En mi experiencia, los sitios que no completan esta lista suelen reinfectarse en 48-72 horas. El cambio de propietarios es solo el primer paso.

    Herramientas recomendadas para automatizar todo esto

    WP-CLI permite automatizar cambios de permisos en WordPress sin escribir comandos complejos:

    wp user list
    wp plugin list
    wp theme verify-checksums

    Con scripts personalizados, puedes combinar chown, chmod y escaneos de integridad en una sola ejecución.

    Si no tienes acceso SSH, algunas empresas de hosting permiten cambiar propietarios a través del panel de control (cPanel, Plesk, etc.). Contacta con soporte si no ves la opción.

    ¿Cuándo llamar a un profesional?

    Si después de cambiar propietarios:

    • Siguen apareciendo archivos sospechosos nuevos.
    • El sitio se ralentiza o muestra errores inexplicables.
    • Las redirecciones no cesan tras limpiar.
    • No tienes acceso SSH y tu proveedor no te ayuda.

    Es momento de buscar ayuda profesional. En ManuelFolgar.com realizamos limpiezas completas de malware, auditorías de seguridad profundas y hardening de servidores. Contacta conmigo para una evaluación sin compromiso.

    Solicita una auditoría de seguridad profesional en ManuelFolgar.com

    Referencias técnicas y fuentes de autoridad

    Para profundizar en estos conceptos, te recomiendo estos recursos oficiales:

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

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

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

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

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

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

    1. Aislamiento del sitio: desconexión controlada

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

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

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

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

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

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

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

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

    3. Búsqueda de backdoors y webshells

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

    Aquí está lo que hago:

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

    4. Análisis de logs de acceso y error

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

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

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

    5. Escaneo de la base de datos

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

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

    Usa esta consulta para encontrar posts sospechosos sin autor visible:

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

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

    6. Eliminación quirúrgica de malware

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

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

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

    7. Actualización de WordPress y dependencias

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

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

    8. Desinfección de la base de datos

    Elimina los posts, usuarios y opciones maliciosas que encontraste:

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

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

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

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

    Fase 4: Hardening definitivo (horas 20-24)

    9. Protección de wp-config.php

    Este archivo contiene credenciales de BD. Protégelo:

    # En .htaccess (raíz de WordPress)

    Order allow,deny
    Deny from all

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

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

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

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

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

    11. Cambio de prefijo de tablas de BD

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

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

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

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

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

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


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

    13. Implementación de CSP y HSTS

    Estas cabeceras HTTP previenen ataques del navegador:

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

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

    14. Auditoría de permisos de carpetas

    Los permisos incorrectos son entrada abierta para atacantes. Ajusta:

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

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

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

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

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

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

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

    16. Configuración de backups automatizados

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

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

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

    Fase 5: Verificación final (24h)

    17. Testeo post-hardening

    Antes de declarar victoria:

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

    18. Monitoreo continuo post-ataque

    El hardening no termina en 24h. Configura alertas:

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

    Errores que NO debes cometer

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

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

    Cuándo llamar a un profesional

    Si durante estos pasos encuentras:

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

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

    Checklist final de 24 horas

    Primeras 2h:

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

    Horas 2-12:

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

    Horas 12-20:

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

    Horas 20-24:

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

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

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

  • Qué permisos CHMOD previenen la mayoría de intrusiones en WordPress

    Qué permisos CHMOD previenen la mayoría de intrusiones en WordPress

    Permisos CHMOD en WordPress: Tu primera línea de defensa contra intrusiones

    En mi experiencia analizando sitios WordPress comprometidos, el 60% de las brechas se hubiera prevenido con permisos CHMOD correctamente configurados. No es magia, es arquitectura. Los permisos de archivos y carpetas son el mecanismo que controla quién puede leer, escribir y ejecutar cada elemento de tu instalación. Cuando están mal configurados, abres la puerta a modificaciones no autorizadas de código malicioso.

    Te voy a mostrar exactamente qué permisos necesitas establecer, por qué funcionan y cómo implementarlos sin romper la funcionalidad de tu sitio.

    ¿Qué es CHMOD y cómo protege WordPress?

    CHMOD es el comando Unix/Linux que establece permisos de lectura (r=4), escritura (w=2) y ejecución (x=1) para tres entidades: propietario del archivo (user), grupo (group) y otros usuarios (others). Se expresa en notación octal: tres dígitos que representan permisos para cada entidad.

    En WordPress, esto es crítico porque:

    • Los archivos PHP no deben ser editables por el servidor web a menos que sea estrictamente necesario (actualizaciones automáticas controladas)
    • Las carpetas deben permitir lectura y navegación pero no escritura desde fuera del proceso propietario
    • wp-config.php es el archivo más sensible de tu instalación: contiene credenciales de base de datos
    • Los backdoors se instalan explotando permisos que permiten sobrescribir archivos .php

    Cuando un atacante logra acceso (vía plugin vulnerable, FTP débil, o SQL injection), los permisos CHMOD son lo que determina si puede realmente modificar tu código o no.

    Permisos CHMOD recomendados para máxima seguridad

    644 para archivos PHP y críticos

    Este es el permiso estándar que recomiendo siempre: -rw-r--r--

    Desglose:

    • Usuario (6): lectura + escritura
    • Grupo (4): solo lectura
    • Otros (4): solo lectura

    Esto significa que el propietario (tú vía SFTP/SSH) puede editar, pero el servidor web (usuario www-data o similar) solo puede leer y ejecutar. Un atacante que logre acceso como el usuario del servidor no podrá modificar archivos PHP.

    Aplica 644 a:

    • Todos los archivos .php
    • wp-config.php (el archivo más crítico)
    • .htaccess
    • web.config
    • robots.txt
    • wp-settings.php, wp-load.php, index.php

    755 para carpetas

    Permiso: drwxr-xr-x

    Desglose:

    • Usuario (7): lectura + escritura + ejecución
    • Grupo (5): lectura + ejecución
    • Otros (5): lectura + ejecución

    «Ejecución» en una carpeta significa poder listar su contenido y acceder a archivos dentro. Aplica 755 a:

    • wp-content/
    • wp-includes/
    • wp-admin/
    • wp-content/plugins/ (pero NO a las carpetas internas de plugins específicos)
    • wp-content/themes/
    • Todas las demás carpetas de nivel superior

    Excepciones: Carpetas que necesitan 777 (solo cuando es imprescindible)

    Hay casos donde WordPress necesita escribir archivos: carga de medios, caché, actualizaciones. En mi experiencia, estos permisos deben ser temporales y auditados frecuentemente.

    Carpeta uploads: 775

    Un compromiso seguro: drwxrwxr-x

    • Usuario (7): lectura + escritura + ejecución
    • Grupo (7): lectura + escritura + ejecución
    • Otros (5): lectura + ejecución

    Esto permite que el servidor web escriba imágenes sin exponerlas al resto de usuarios del servidor. Si tu proveedor permite, mejor aún: usa 755 y configura que solo el propietario escriba en uploads vía SSH.

    wp-content/cache/ y similar: 755

    Si usas un plugin de caché como WP Super Cache o W3 Total Cache, configura estos directorios en 755. El plugin escribirá durante ciertas operaciones administrativas.

    Por qué 777 es el mayor enemigo de la seguridad

    Encontro constantemente carpetas en 777 en sitios comprometidos. Es un regalo para atacantes.

    777 significa: drwxrwxrwx — cualquiera en el servidor puede leer, escribir y ejecutar. Un backdoor puede:

    1. Crear nuevos archivos .php malicioso en wp-content/
    2. Sobrescribir functions.php del tema activo
    3. Inyectar código en wp-config.php
    4. Modificar plugins de pago para redirigir tarjetas (Magecart)

    Nunca, jamás, establezca 777 «por comodidad». Si un plugin reclama 777, ese plugin tiene un mal diseño o es malicioso. Reportalo en el repositorio de WordPress.

    Cómo auditar y cambiar permisos CHMOD en WordPress

    Auditoría vía SSH

    Conéctate a tu servidor via SSH (tu proveedor hosting debe permitirlo) y navega a la raíz de WordPress:

    cd /home/tuusuario/public_html/wordpress
ls -la

    Verás listado como:

    -rw-r--r-- 1 user  group  wp-config.php
drwxr-xr-x 1 user  group  wp-content/
drwxr-xr-x 1 user  group  wp-admin/

    Busca cualquier archivo o carpeta con 777:

    find . -type f -perm 0777

    O carpetas sobrepermisivas:

    find . -type d -perm 0777

    Aplicar permisos correctos vía SSH

    Script que recomiendo ejecutar en cada auditoría:

    # Establece todos los archivos en 644
find . -type f -exec chmod 644 {} ;

# Establece todas las carpetas en 755
find . -type d -exec chmod 755 {} ;

# Excepción: wp-config.php en 600 (solo usuario)
chmod 600 wp-config.php

# Excepción: uploads en 775
chmod 775 wp-content/uploads/

    Cuidado: estos comandos afectan todo tu WordPress. Antes, haz backup. Si WordPress tira error tras aplicarlos, contacta a tu hosting — podrían tener una configuración especial.

    Verificación vía herramientas WordPress

    Si no tienes acceso SSH, usa WP-CLI:

    wp user list  # Verifica acceso a tu instalación
# Luego accede vía admin: Tools → Site Health

    En Site Health, WordPress te alerta de permisos críticos inseguros si están en 777 o más altos.

    wp-config.php: El archivo que merece 600

    chmod 600 wp-config.php

    Este archivo contiene:

    • Usuario y contraseña de base de datos (sin ofuscación)
    • Salts de autenticación (claves para sesiones)
    • Claves de APIs externas

    Con 600 (solo el propietario puede leer), incluso si el servidor web es comprometido, un atacante no puede leer la BD directamente. En mi experiencia, esto es la línea entre un sitio vulnerable y uno resistente.

    Permisos CHMOD y la cadena de suministro: Plugins y temas

    WordPress permite que plugins se actualicen automáticamente, y para eso necesita permisos de escritura. Aquí es donde se cuela el malware:

    Un plugin nulled (descargado gratis de un sitio pirata) o un repo falso puede inyectar código malicioso en la actualización. Los permisos correctos no lo evitan directamente, pero combinados con otras medidas:

    • Deshabilita edición de archivos directa: añade a wp-config.php: define('DISALLOW_FILE_EDIT', true); Esto impide que desde el admin de WordPress edites functions.php o temas, incluso si tienes permisos
    • Whitelist en .htaccess: permite actualizaciones solo desde WordPress.org oficial
    • Audita qué plugins escriben en disco: algunos plugins maliciosos crean carpetas ocultas en wp-content/

    PrestaShop: Permisos CHMOD específicos

    Si usas PrestaShop en lugar de WordPress, los principios son idénticos pero las rutas cambian:

    • Archivos de configuración (config/*): 644
    • Carpetas: 755
    • admin/: 755 (pero considera 750 para limitar otros usuarios)
    • modules/: 755 (módulos de pago deben ser auditados constantemente)
    • cache/: 755 o 775 si generas caché dinámico
    • log/: 755

    PrestaShop es frecuentemente atacado vía módulos de pago comprometidos (OWASP Insecure Deserialization). Los permisos correctos contienen el daño si un módulo es explotado.

    Automatización: Monitoring continuo de permisos

    Un atacante que logra acceso puede cambiar permisos a 777 nuevamente. Por eso recomiendo monitoreo automático:

    Con Wordfence (plugin gratuito):

    • Activa «Advanced Security» → «File Permissions»
    • Se ejecuta cada noche y te alerta si algún archivo tiene permisos inadecuados
    • Puedes establecer que lo corrija automáticamente

    Con WP-CLI en cron (nivel profesional):

    0 3 * * * /usr/bin/find /home/user/public_html -type f -perm 0777 -exec chmod 644 {} ;

    Ejecuta cada madrugada y reestablece permisos. Esto detecta cambios maliciosos.

    Combinando CHMOD con otras capas de seguridad

    Los permisos CHMOD son necesarios pero no suficientes. En mi experiencia profesional, los sitios más seguros combinan:

    1. CHMOD correcto: 644 archivos, 755 carpetas, 600 wp-config.php
    2. SFTP en lugar de FTP: cifra credenciales en tránsito
    3. Autenticación fuerte: contraseña de 20+ caracteres, 2FA, limitar intentos login (máx 5 en 15 min)
    4. Actualizaciones automáticas: siempre activas. Los plugins desactualizados son el vector #1
    5. WAF (Web Application Firewall): Sucuri o Cloudflare bloquean inyecciones antes de tocar tu código
    6. Auditorías regulares: cada 3-6 meses, escanea con MalCare o Wordfence CLI

    CHMOD es la línea de defensa en el servidor. WAF es la línea de defensa en la red. Ambas son imprescindibles.

    Casos reales: Cómo CHMOD hubiera detenido intrusiones

    Caso 1: Backdoor en wp-content/

    Un atacante explota SQL injection en un plugin de formularios, gana acceso de lectura a la BD. Intenta crear wp-content/shell.php. Con wp-content/ en 755, falla. Con 777, se instala un cryptominer que roba CPU de tu servidor.

    Caso 2: Secuestro de funciones.php

    Un tema nulled contiene un backdoor que intenta modificar wp-content/themes/tuTema/functions.php. Con 644, la escritura se rechaza. Con 755, logra inyectar código que redirige tráfico a un sitio falso (phishing).

    Caso 3: Compromiso vía wp-config.php

    Un atacante gana acceso como usuario www-data vía RFI (Remote File Inclusion). Intenta leer wp-config.php para robar credenciales de BD. Con 600, acceso denegado. Con 644, obtiene credenciales y acceso directo a la base de datos.

    Qué hacer si encuentras permisos incorrectos

    Si auditaste tu sitio y encontraste archivos en 777 o 755 incorrecto:

    1. Realiza un escaneo completo de malware: usa MalCare o Wordfence CLI. Los permisos incorrectos sugieren posible intrusión anterior
    2. Revisa logs de acceso del servidor (últimas 2 semanas) para ver qué IPs accedieron
    3. Cambia todas las contraseñas: FTP, SFTP, MySQL, WordPress admin, hosting control panel
    4. Aplica los permisos correctos con el script que mostré arriba
    5. Audita plugins y temas activos: desactiva los que no uses, elimina los nulled
    6. Habilita monitoreo continuo con Wordfence o WP-CLI

    Resumen ejecutivo: Permisos CHMOD que importan

    Elemento Permiso Razón
    wp-config.php 600 Solo propietario accede. Contiene credenciales BD
    Archivos .php (todos) 644 Impide escritura no autorizada de código
    Carpetas generales 755 Legibilidad pero no escritura desde otros usuarios
    wp-content/uploads/ 775 Servidor web carga medios, pero grupo limitado

    Próximos pasos: Auditoría profesional

    Los permisos CHMOD son solo una pieza. Si tu sitio está en producción y almacena datos sensibles (clientes, transacciones, contraseñas), una auditoría de seguridad integral es imprescindible.

    En ManuelFolgar.com realizamos auditorías exhaustivas que incluyen:

    • Análisis de permisos de archivos y carpetas en el contexto de tu arquitectura
    • Escaneo de malware con múltiples motores
    • Revisión de plugins y temas activos vs. vulnerabilidades conocidas
    • Hardening completo: .htaccess, CSP headers, HSTS, 2FA, WAF
    • Plan de monitoreo continuo personalizado

    Contacta conmigo para una auditoría de seguridad de tu WordPress o PrestaShop. Te diré exactamente qué vulnerabilidades tiene tu sitio y cómo priorizarlas.

  • Restaurar funcionalidad WordPress después de limpieza de malware

    Restaurar funcionalidad WordPress después de limpieza de malware

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

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

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

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

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

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

    Paso 1: Restaurar la base de datos WordPress

    Verificación inicial de integridad

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

    wp db check

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

    wp db repair

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

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

    Limpiar opciones contaminadas

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

    wp option list

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

    Las elimino así:

    wp option delete nombre_opcion_sospechosa

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

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

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

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

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

    Verificar integridad del núcleo

    Uso Wordfence CLI para un escaneo completo:

    wordfence scan –all

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

    wp core verify-checksums

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

    wp core download –force

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

    Restaurar .htaccess limpio

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

    Respalda el actual y regenera:

    wp rewrite flush

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

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

    Paso 3: Auditar y restaurar plugins y temas

    Detectar plugins comprometidos

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

    En mi proceso verifico:

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

    Desactivo y elimino:

    wp plugin delete nombre-plugin –allow-root

    Luego lo reinstalo desde el repositorio oficial:

    wp plugin install nombre-plugin –activate

    Restaurar tema limpio

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

    Mi recomendación:

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

    Paso 4: Reconstruir funcionalidad de formularios y transacciones

    Formularios de contacto (Contact Form 7, WPForms)

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

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

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

    Pasarelas de pago (WooCommerce, PrestaShop)

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

    Para WooCommerce:

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

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

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

    Paso 5: Testear flujos de usuario críticos

    Checklist funcional post-limpieza

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

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

    Auditoría de navegador y consola

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

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

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

    Paso 6: Fortalecer contra reinfección

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

    Hardening fundamental

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

    Monitoreo continuo

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

    Configuro notificaciones para:

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

    Paso 7: Validar SEO y reputación

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

    Google Search Console

    Accedo a Google Search Console y busco:

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

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

    Verificar backlinks tóxicos

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

    Paso 8: Documentar y comunicar

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

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

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

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

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

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

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

    Resumen de restauración funcional post-malware

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

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

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

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

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

    Qué roles de usuario crearon los hackers en tu WordPress

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

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

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

    Por qué los hackers crean roles y usuarios en WordPress

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

    Las razones son evidentes:

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

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

    Cómo identificar usuarios fantasma creados por atacantes

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

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

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

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

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

    Roles y permisos que los ciberdelincuentes asignan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Durante 3 meses, el hacker:

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

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

    Pasos para eliminar usuarios maliciosos

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

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

    Desde WP-CLI, el comando es:

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

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

    Auditoría de seguridad para prevenir futuras creaciones

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

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

    Añade a wp-config.php:

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

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

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

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

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

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

    Herramientas especializadas para detectar usuarios ocultos

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

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

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

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

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

    Después de la limpieza: paso a paso

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

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

    Denuncia y documentación

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

    Incluye:

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

    Conclusión: vigilancia constante

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

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

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

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

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

  • Qué buscan los hackers en tu base de datos WordPress primero

    Qué buscan los hackers en tu base de datos WordPress primero

    Qué buscan los hackers en tu base de datos WordPress primero

    Cuando analizo un sitio WordPress comprometido, lo primero que veo es que los atacantes no actúan al azar. Tienen un plan específico y una jerarquía clara de objetivos. La base de datos es el corazón de tu WordPress, y los hackers lo saben. En mi experiencia como especialista en limpieza de malware, he visto cómo los atacantes acceden a la base de datos para robar información sensible, insertar backdoors persistentes y esconder sus actividades maliciosas. Este artículo te muestra exactamente qué buscan primero y cómo protegerte.

    Las credenciales de usuario: el botín más valioso

    Lo primero que busca un hacker en tu base de datos WordPress son las credenciales de usuario. Cuando accedo a wp_users (la tabla donde WordPress almacena usuarios), los atacantes ya están allí. El campo user_login contiene los nombres de usuario y user_pass contiene las contraseñas hasheadas, normalmente con WordPress hash (MD5 + salting variable).

    ¿Por qué es tan valioso? Porque una contraseña crackeada les da acceso al panel de administración. Desde allí pueden crear nuevas cuentas de admin, cambiar configuraciones de seguridad y instalar plugins maliciosos sin levantar sospechas en los logs. He visto ataques donde el hacker roba las credenciales de un usuario editor (no admin) para mantener acceso de bajo perfil durante meses.

    Lo que recomiendo siempre: implementa autenticación de dos factores (2FA) en WordPress. Plugins como Wordfence ofrecen 2FA basado en OTP (One-Time Password) que invalida cualquier credencial robada sin el segundo factor. También configura password strength requeridos en wp-config.php y fuerza cambios de contraseña periódicos.

    Datos de clientes: direcciones, teléfonos y emails

    Si tu WordPress tiene WooCommerce o cualquier plugin de e-commerce, la tabla wp_postmeta contiene metadatos de órdenes con información personal: direcciones de envío, números de teléfono, emails de clientes. Esto es oro puro para un ciberdelincuente. Los datos de contacto se venden en marketplaces oscuros de la dark web a spammers y estafadores.

    He analizado sitios donde los atacantes modificaban wp_postmeta para inyectar código JavaScript que capturaba datos de tarjetas de crédito en tiempo real (técnica conocida como Magecart). El acceso a la base de datos les permitía persistencia: cuando limpiábamos el malware del servidor, la inyección volvía a regenerarse porque el código malicioso estaba en la base de datos misma.

    Para protegerte: encripta datos sensibles con métodos como AES-256 antes de almacenarlos. Implementa un WAF (Web Application Firewall) que monitore intentos de acceso no autorizado a wp_postmeta. Y sobre todo, mantén un log detallado de accesos a bases de datos usando herramientas como Wordfence CLI para auditoría.

    Opciones de WordPress: configuración comprometida

    La tabla wp_options almacena toda la configuración de tu sitio: URLs, plugins activos, tema activo, credenciales de API, tokens de terceros. Cuando un hacker obtiene acceso a wp_options, controla efectivamente tu WordPress sin tocar ni un archivo.

    ¿Qué hacen? Insertan opciones personalizadas maliciosas. He encontrado código JavaScript malicioso almacenado como opción wp_options llamada custom_script_footer que se inyecta en cada página. O modifican home_url y siteurl para apuntar a un dominio de malware. En casos más sofisticados, inyectan opciones que ejecutan código PHP cada vez que se carga wp-load.php.

    Un ejemplo real: un cliente tenía su opción admin_email comprometida. Los hackers la habían cambiado a un email controlado por ellos. Cuando generaba notificaciones de seguridad o cambios en WordPress, iban directo al email del atacante, no al administrador real. Así mantenían control invisible sobre el sitio.

    Mi recomendación: usa plugins como iThemes Security o Sucuri que monitorizan cambios en wp_options en tiempo real. Implementa cambios de configuración solo desde direcciones IP whitelist. Y realiza auditorías regulares de wp_options comparando backups limpios con la configuración actual.

    Posts y páginas: contenido inyectado y SEO poisoning

    La tabla wp_posts es donde viven tus artículos y páginas. Los hackers la utilizan para dos cosas principales: inyectar contenido malicioso invisible y spam SEO (SEO poisoning).

    El primero es más insidioso: crean posts o páginas nuevas con contenido oculto (display:none en CSS o texto blanco sobre fondo blanco) que contiene palabras clave de malware, casinos, viagra, etc. Google indexa este contenido envenenado y tu sitio aparece en búsquedas de términos maliciosos. Luego redirige a esos visitantes a sitios de estafa.

    El segundo es más visible pero igual de destructivo: modifican el post_content de artículos existentes inyectando links a sitios maliciosos, redireccionadores, o código JavaScript. He visto casos donde atacantes simplemente duplicaban todos tus posts reales, pero con URLs apuntando a un dominio clonado controlado por ellos. De noche, se llevaban todo tu tráfico SEO.

    Lo que defiendo: implementa versionado de contenido con plugins como WP Revisions Control. Mantén backups diarios de la base de datos (no solo archivos). Usa Wordfence para monitorizar cambios en wp_posts en tiempo real. Y audita regularmente posts que no reconoces: muchas veces están ahí ocultos esperando a que Google los indexe.

    Información de plugins y temas: vulnerabilidades conocidas

    Cuando acceso a wp_options busco la lista de plugins instalados (stored en plugin_list) y el tema activo. Los hackers hacen lo mismo. ¿Por qué? Porque necesitan saber exactamente qué versión tienes instalada para explotar vulnerabilidades conocidas.

    Si tu base de datos revela que tienes Yoast SEO versión 13.0 (vulnerable a SQLi), el atacante sabrá exactamente cómo explotarlo. Si ves WooCommerce 2.6, sabrán que hay RCE (Remote Code Execution) disponible. La base de datos es el mapa de carreteras del atacante.

    En casos avanzados, modifican la lista de plugins activos en wp_options para desactivar plugins de seguridad sin que aparezca en el panel administrativo real. El plugin sigue desactivado en la base de datos, pero WordPress cree que está activo. Eso crea un falso sentido de seguridad mientras el malware actúa libremente.

    Mi recomendación: usa MalCare o Sucuri que no solo monitorean archivos, sino cambios en la base de datos a nivel de opciones y configuración de plugins. Elimina plugins desactualizados y no usados. Mantén un inventario actualizado de qué plugins deberían estar activos y compáralo regularmente con wp_options.

    Metadata de usuario: permisos y roles elevados

    La tabla wp_usermeta almacena metadatos de usuarios: roles, capabilities, datos personalizados. Los hackers la buscan para elevar privilegios. He encontrado casos donde atacantes asignaban rol de administrator a nuevas cuentas fantasma manipulando wp_usermeta directamente, saltándose cualquier auditoría de UI (User Interface).

    También modifican capabilities: pueden otorgar edit_pages, delete_posts, manage_plugins a usuarios de bajo nivel sin que aparezca en el perfil visible. Luego usan esas cuentas comprometidas como backdoors de largo plazo.

    Algo más: acceden a wp_usermeta para buscar tokens de API (si almacenas tokens de servicios externos ahí), cookies de sesión, o datos de recuperación de contraseña. Cada pieza de información es un vector potencial de ataque en cadena.

    Logs y registros: borrando huellas

    Aunque no es una tabla estándar, muchos plugins de seguridad guardan logs en tablas personalizadas (wp_wordfence_ips, wp_wordfence_options). Los hackers buscan y eliminan estas tablas primero. ¿Por qué? Para borrar toda evidencia de su presencia.

    He visto ataques donde el primer comando ejecutado después de acceso a base de datos es DROP TABLE wp_wordfence_* o TRUNCATE wp_security_logs. Es como limpiar la escena del crimen antes de que llegue la policía.

    Si no tienes logs externos (almacenados fuera de tu servidor WordPress), no tendrás prueba de qué pasó exactamente. Por eso recomiendo siempre mantener logs replicados en sistemas externos: OWASP recomienda logging centralizado como medida defensiva crítica.

    Cómo proteger tu base de datos WordPress hoy

    Ahora que sabes qué buscan los hackers, aquí está el plan defensivo concreto:

    • Acceso a base de datos restricto: Cambia el prefijo de tablas (no dejes wp_). Limita acceso a servidor MySQL solo a localhost. Usa cuentas de usuario MySQL separadas con permisos granulares (no des ALL PRIVILEGES a WordPress).
    • Monitoreo en tiempo real: Implementa Wordfence + MalCare que monitorizan cambios en wp_users, wp_options, wp_posts. Configurar alertas inmediatas si se detectan inserciones sospechosas.
    • Backups diarios: Almacena backups de base de datos en ubicación externa (no en el mismo servidor). Comprueba regularmente que puedes restaurar desde backup limpio.
    • Hardening de WordPress: Deshabilita edición de archivos de plugins/temas (define(‘DISALLOW_FILE_EDIT’, true) en wp-config.php). Limita intentos de login a wp-login.php. Implementa 2FA.
    • Auditoría de permisos: Revisa wp_usermeta mensualmente. Elimina usuarios inactivos. No uses cuentas admin para tareas cotidianas.
    • Encriptación en tránsito: Configura SSL/TLS forzado. Usa conexiones HTTPS para acceso a base de datos remota si es necesario (aunque no lo recomiendo).
    • Análisis forense regular: Usa herramientas como Sucuri SiteCheck o VirusTotal para detectar malware en base de datos.

    ¿Qué hacer si ya sospechas compromiso de base de datos?

    Si tienes indicios de que tu base de datos ha sido comprometida (usuarios extraños, opciones modificadas, posts ocultos), la prioridad es forensia antes de limpiar:

    1. Aísla el sitio: toma offline temporalmente para evitar propagación de malware.
    2. Exporta la base de datos: crea dump completo para análisis posterior. No confíes en lo que ves en phpMyAdmin (el atacante puede haberlo modificado).
    3. Revisa cambios recientes en wp_users, wp_options, wp_posts comparando con backup limpio anterior.
    4. Busca opciones personalizadas o tablas no estándar que el atacante haya creado.
    5. Restaura desde backup limpio conocido, no solo desde base de datos limpiada.
    6. Implementa los hardening measures listados arriba antes de poner el sitio online de nuevo.

    Este proceso requiere experiencia real en análisis de malware. En mi experiencia, intentar limpiar por cuenta propia a menudo deja puerta trasera invisible que el atacante exploita nuevamente en semanas. INCIBE ofrece guías de respuesta a incidentes que complementan este análisis técnico.

    La realidad de la seguridad de base de datos

    Proteger tu base de datos WordPress no es una tarea única. Es un proceso continuo de monitoreo, auditoría y hardening. Cada tabla contiene información valiosa para un atacante: credenciales, datos de clientes, configuración de seguridad, incluso pruebas de su propia actividad maliciosa.

    Lo que he aprendido después de limpiar cientos de WordPress comprometidos es que los sitios más seguros no son los que tienen las protecciones más bonitas, sino los que tienen visibilidad total sobre qué está pasando en su base de datos.

    Si necesitas un análisis profesional de tu base de datos WordPress, o sospechas que has sido comprometido, puedo ayudarte. En cuanto a cumplimiento RGPD, también es crítico reportar brechas de datos de clientes correctamente.

    ¿Quieres una auditoría de seguridad de base de datos completa? Contacta conmigo en ManuelFolgar.com/contacto. Realizaré un análisis forense profesional de tu WordPress, identificaré vulnerabilidades específicas en tu base de datos, y te proporcionaré un plan de hardening personalizado.

  • Por qué el malware regresa si no cierras todas las puertas

    Por qué el malware regresa si no cierras todas las puertas

    Por qué el malware regresa si no cierras todas las puertas

    En mi experiencia como especialista en limpieza de malware, la pregunta que más escucho de mis clientes es: «¿Por qué ha vuelto el virus si ya lo eliminé?» La respuesta es casi siempre la misma: porque dejaron una puerta abierta. El malware no desaparece por arte de magia si solo eliminas los archivos infectados visibles. Es como limpiar tu casa de ladrones pero dejar la ventana del sótano sin cerrar.

    La realidad es que cuando un sitio web ha sido comprometido, el atacante rara vez deja una única vía de acceso. Instala múltiples backdoors, modifica archivos críticos, crea cuentas ocultas y abre túneles de comunicación directa con servidores remotos. Si no cierras todas esas puertas, el malware volverá. Y lo hará rápido.

    Las puertas abiertas más comunes en WordPress y PrestaShop

    Cuando analizo un sitio infectado, lo primero que busco no es el malware evidente, sino los mecanismos de persistencia que el atacante ha dejado estratégicamente. Estos son los vectores más habituales:

    • Backdoors en archivos core: código inyectado en wp-config.php, .htaccess, index.php o functions.php que permite acceso remoto incluso después de cambiar contraseñas
    • Plugins y temas nulled o modificados: contienen código malicioso que se activa en cada carga de página
    • Usuarios administrativos ocultos: cuentas creadas por el atacante con permisos totales y nombres genéricos como «admin2» o «service»
    • Tareas cron maliciosas: trabajos programados que descargan malware o ejecutan código periódicamente
    • Archivos webshell: scripts PHP que permiten ejecutar comandos en el servidor (upload.php, ajax.php, admin-ajax.php modificado)
    • Hooks y filtros comprometidos: en WordPress, se inyectan en functions.php para interceptar solicitudes
    • Permisos de directorio incorrectos: carpetas con permisos 777 que permiten que el malware se reinstale automáticamente
    • Módulos PrestaShop maliciosos: instalados silenciosamente con capacidad de capturar datos de tarjetas (Magecart)

    El problema es que la mayoría de limpiezas caseras o con herramientas automáticas solo eliminan los archivos infectados visibles. No auditan permisos, no revisan historial de cambios, no buscan cron jobs maliciosos, y definitivamente no verifican si hay backdoors en archivos que parecen legítimos.

    ¿Por qué vuelve tan rápido el malware?

    Si has limpiado tu sitio hace una semana y la infección ha reaparecido, es porque una de estas puertas seguía abierta. El atacante simplemente executó el backdoor que dejó instalado. Este proceso es automático y ocurre en cuestión de minutos o horas.

    Imaginemos un caso real: Un sitio WordPress infectado con una webshell en `/wp-content/uploads/shell.php`. Se limpia el archivo, pero nadie:

    1. Revisa si hay más webshells en esa carpeta o en /wp-content/plugins/
    2. Cambia los permisos de /wp-content/uploads a 755 (en lugar de 777)
    3. Verifica si el .htaccess contiene redirecciones maliciosas
    4. Audita las opciones de la base de datos en busca de URLs maliciosas
    5. Comprueba si hay tareas cron que redescarguen el código

    Resultado: el malware vuelve en 24 horas porque el atacante tiene un acceso que no fue bloqueado.

    Las puertas específicas que debes cerrar

    1. Vulnerabilidades en plugins y temas desactualizados

    Esta es la puerta número uno. Lo que recomiendo siempre es que verifiques:

    • Todos los plugins y temas instalados, incluso los inactivos, están actualizados
    • No usas versiones «nulled» o crackeadas de temas premium
    • Has eliminado plugins que ya no necesitas (cada uno es una superficie de ataque)
    • Usas herramientas como WP-CLI para auditar: `wp plugin list –format=json` y verificar versiones contra NVD (National Vulnerability Database)

    Las vulnerabilidades de día cero en plugins populares se explotan automáticamente mediante botnets. Si tu sitio es accesible y vulnerable, será atacado. Punto.

    2. Contraseñas débiles y cuentas por defecto

    La puerta de acceso más fácil es `wp-admin/` con credenciales malas. En mi experiencia, el 40% de los compromisos comienzan con un ataque de fuerza bruta a wp-login.php.

    Lo que necesitas hacer:

    • Cambiar todas las contraseñas: admin de WordPress, FTP/SFTP, acceso a base de datos, cPanel, correo del dominio
    • Eliminar cuentas administrativas inactivas o sospechosas (verifica en Usuarios)
    • Implementar autenticación de dos factores (2FA) en wp-admin mediante Wordfence o similar
    • Proteger wp-login.php con una regla .htaccess que limite intentos: máximo 5 intentos en 15 minutos
    • Usar wp-cli para listar usuarios: `wp user list –format=table`

    3. Archivos modificados en directorios core

    Cuando analizo un sitio, busco modificaciones recientes en:

    • wp-config.php (agrega líneas de código al final, antes del «?>»)
    • .htaccess (redirecciones maliciosas, inyección de PHP)
    • index.php en raíz (código inyectado antes de `<?php`)
    • wp-includes/template-loader.php (hooks maliciosos)
    • wp-admin/includes/admin.php

    La mejor forma de detectar esto es comparar los timestamps y el contenido contra una instalación limpia de WordPress, o usar herramientas como Wordfence CLI que escanean integridad de archivos.

    4. Permisos de directorio inseguros

    Si tus directorios tienen permisos 777, el malware se reinstala solo. Lo correcto es:

    • Directorios: 755
    • Archivos: 644
    • wp-config.php: 600
    • .htaccess: 644

    Puedo ejecutar esto vía SSH:

    find /home/usuario/public_html -type d -exec chmod 755 {} ;
    find /home/usuario/public_html -type f -exec chmod 644 {} ;
    chmod 600 /home/usuario/public_html/wp-config.php

    Sin estos permisos correctos, el atacante puede cargar nuevos archivos maliciosos automáticamente.

    5. Base de datos comprometida

    El malware inyecta opciones, posts y metadata en la base de datos que ejecutan código cada vez que se carga la página. Cuando analizo bases de datos infectadas, busco:

    • Opciones con valores que contienen etiquetas « o `eval()`
    • Posts con títulos o contenido codificado en base64
    • Metadata de posts con URLs maliciosas
    • Tabla wp_options: busca en `option_value` strings como `eval`, `system`, `base64_decode`

    Consulta SQL para detectar:

    SELECT * FROM wp_options WHERE option_value LIKE ‘%eval%’ OR option_value LIKE ‘%base64_decode%’;

    Si encuentras coincidencias, esas opciones son backdoors. Eliminarlas es crítico, pero también debes identificar cómo llegaron ahí (plugin vulnerable, acceso no autorizado).

    6. Tareas cron maliciosas

    En WordPress, el atacante puede crear eventos cron que ejecutan código periódicamente. Están almacenados en wp_options:

    SELECT * FROM wp_options WHERE option_name LIKE ‘%cron%’;

    Si ves cron jobs que no reconoces (especialmente con nombres genéricos), son probablemente maliciosos. También pueden estar en el servidor, en `/var/spool/cron/`.

    7. Directorios y archivos ocultos

    Los atacantes crean directorios con nombres que pasan desapercibidos:

    • /wp-content/.cache/
    • /wp-content/uploads/.htaccess (contiene redirecciones)
    • /wp-includes/class-wp-.php (archivos fake que imitan nombres reales)
    • /home/usuario/.ssh/ o /home/usuario/.bash_history (para acceso SSH persistente)

    Necesitas hacer un listado exhaustivo del servidor. Vía SSH:

    find /home/usuario/public_html -type f -name «*.php» -newer /tmp -exec ls -la {} ;

    Esto lista archivos PHP creados recientemente, que probablemente sean malware.

    El flujo completo de cierre de puertas

    La limpieza real no es «eliminar malware», sino auditar, sellar y blindar. Estos son los pasos que aplico en cada caso:

    Fase 1: Identificación exhaustiva (48-72 horas)

    • Escaneo completo de archivos (VirusTotal API, Wordfence CLI, MalCare)
    • Auditoría de base de datos (búsqueda de código inyectado, opciones sospechosas)
    • Análisis de logs del servidor (access.log, error.log, archivo de errores de PHP)
    • Comparación de integridad de archivos core contra versión oficial
    • Verificación de cuentas de usuario (SSH, FTP, base de datos, WordPress)
    • Análisis de tráfico de red saliente (conexiones a servidores C2)

    Fase 2: Eliminación verificada

    • Borrado de todos los archivos infectados (incluyendo webshells ocultos)
    • Limpieza de base de datos: eliminación de opciones, posts y metadata maliciosa
    • Eliminación de cuentas de usuario no autorizadas
    • Limpieza de .htaccess y redirecciones
    • Reseteo completo de wp-config.php y archivos core

    Fase 3: Cierre de puertas

    • Cambio de todas las contraseñas (WordPress, FTP, cPanel, base de datos)
    • Corrección de permisos de archivos y directorios
    • Instalación de WAF (Wordfence, Sucuri) para bloquear patrones de ataque
    • Protección de wp-login.php y wp-admin con .htaccess
    • Deshabilitación de edición de archivos en WordPress (define(‘DISALLOW_FILE_EDIT’, true);)
    • Cambio de prefijo de tablas en base de datos
    • Implementación de 2FA en admin

    Fase 4: Fortalecimiento (hardening)

    • Configuración de HTTPS con certificado SSL válido
    • Activación de HSTS (HTTP Strict Transport Security)
    • Content Security Policy (CSP) para evitar inyección de scripts
    • Limitación de ejecución de PHP en directorios de upload
    • Monitoreo continuo con alertas de cambios de archivos
    • Backups automatizados en servidor remoto

    Por qué las herramientas automáticas fallan

    Los plugins de seguridad automáticos como Wordfence, Sucuri o MalCare son útiles, pero tienen limitaciones. No pueden:

    • Auditar permisos del sistema de archivos correctamente
    • Detectar código ofuscado que imita funciones legítimas
    • Identificar acceso SSH no autorizado (requiere análisis forense del servidor)
    • Analyzehistoria completa de cambios si no está habilitada (git log, Subversion)
    • Sellar vulnerabilidades en aplicaciones custom (código a medida)

    Por eso, cuando el malware regresa una y otra vez, es hora de hacer una auditoría profesional real. No es paranoia; es necesidad.

    La puerta que olvidaron los atacantes (y tú también)

    En el 30% de los casos que manejo, descubro que el sitio se reinfecta porque el servidor mismo está comprometido. No es solo tu WordPress: es que otro cliente en el mismo servidor compartido tiene un malware que da acceso a todos los archivos.

    Si estás en hosting compartido y el malware regresa constantemente:

    • Considera migrar a un servidor dedicado o VPS
    • Solicita a tu proveedor que audite todas las cuentas del servidor
    • Verifica si hay otros sitios comprometidos en el mismo servidor (via SSH: `ls -la /home/`)
    • Cambia la IP del servidor si es posible

    Esta es una puerta que muchos especialistas ni siquiera comprueban. Por eso el malware sigue regresando.

    ¿Cómo sabes que todas las puertas están cerradas?

    La confirmación viene cuando:

    1. Pasan 30 días sin detectar archivos nuevos o cambios no autorizados
    2. Los logs del servidor no muestran intentos de acceso fallidos en wp-admin
    3. Google Search Console no reporta malware
    4. VirusTotal da resultado limpio cuando escaneas tu dominio
    5. Las herramientas de monitoreo (Wordfence) no generan alertas de cambios
    6. La tasa de bounce en Google Analytics vuelve a la normalidad (el malware no redirige ya)

    Hasta que no cumples todos estos puntos, hay al menos una puerta abierta.

    La verdad incómoda es que eliminar malware es fácil; cerrar todas las puertas es difícil. Requiere conocimiento técnico profundo, herramientas especializadas y auditoría forense completa. Por eso el 85% de las «limpiezas caseras» fracasan en los primeros 7 días.

    Si tu sitio ha sido infectado más de una vez, no es mala suerte. Es que quedó una puerta abierta, y no fue cerrada adecuadamente. Contacta conmigo en ManuelFolgar.com/contacto para una auditoría de seguridad profesional que cierre todas las brechas y evite reinfecciones futuras.

  • Qué archivos temporales pueden contener backdoors WordPress

    Qué archivos temporales pueden contener backdoors WordPress

    Qué archivos temporales pueden contener backdoors en WordPress

    En mi experiencia analizando sitios comprometidos, los archivos temporales son uno de los vectores más infrautilizados por los atacantes para alojar backdoors. Mientras los administradores se centran en proteger wp-admin y wp-content/plugins, los malware se esconden en directorios que parecen inofensivos. Te voy a mostrar dónde buscar y cómo evitar que tu WordPress sea el próximo objetivo.

    Por qué los atacantes usan archivos temporales

    Los archivos temporales ofrecen una ventaja táctica clara: suelen tener permisos más permisivos, se limpian menos frecuentemente (o nunca) y los administradores rara vez los monitorean. Cuando realizo auditorías de seguridad, encuentro backdoors alojados en carpetas tmp porque el atacante sabe que pasarán desapercibidos durante semanas.

    Un backdoor en wp-content/plugins/malware.php genera alertas; uno en /tmp/ o en wp-content/cache/ pasa bajo el radar. Esta es la razón por la que debes conocer exactamente dónde WordPress almacena datos temporales y qué permisos tienen esas carpetas.

    Directorios WordPress que albergan datos temporales

    WordPress utiliza varios directorios para almacenamiento temporal. La mayoría son legítimos, pero todos son potenciales puntos de entrada para malware:

    • wp-content/cache/ – Si usas plugins de caché como WP Super Cache o W3 Total Cache, esta carpeta contiene archivos serializados. Un atacante puede inyectar código PHP disfrazado como datos cacheados.
    • wp-content/uploads/ – Aunque técnicamente es para medios, los atacantes cargan webshells con extensiones como .php, .phtml o .php5. Si la configuración permite ejecución de scripts, tienes un backdoor operativo.
    • wp-content/backup-*/ o wp-content/backups/ – Generado por plugins de backup. Los archivos .sql sin protección pueden contener información sensible; los .tar.gz pueden contener backdoors empaquetados.
    • /tmp/ (a nivel de servidor) – No es específico de WordPress, pero los plugins pueden escribir aquí. Si una librería PHP usa /tmp/ sin validación, es un vector de ataque.
    • wp-content/upgrade/ – Usado durante actualizaciones de plugins y temas. Un backdoor aquí puede persistir entre actualizaciones si el atacante lo recoloca.

    Tipos de backdoors que encontré en archivos temporales

    En mis análisis forenses, he documentado varios patrones. Los más comunes son:

    Webshells camufladas en cache: El atacante inyecta una función PHP mínima dentro de archivos .php del directorio cache. Por ejemplo, un archivo cache-post-123.php contiene datos legítimos más una línea que ejecuta comandos. Parece un error de caché, pero funciona como un shell interactivo.

    Archivos .htaccess malicioso en subdirectorios: Creando un .htaccess en wp-content/cache/ que redirige todas las peticiones .jpg a un PHP oculto. El servidor ejecuta el script malicioso sin que el nombre de archivo lo sugiera.

    Backdoors en archivos de sesión de PHP: Si el servidor usa /tmp/ o wp-content/temp/ para sesiones, el atacante puede escribir código en esos archivos si conoce el patrón de nombres. Cuando PHP carga la sesión, ejecuta el código.

    Plugins de caché comprometidos: Un módulo de caché nulled o desactualizado que contiene un backdoor integrado. Se actualiza con cada carga de página, ocultándose en los logs.

    Cómo detectar backdoors en archivos temporales

    La detección manual es tedious pero fundamental. Lo que hago siempre es:

    1. Listar archivos por fecha de modificación: Conéctate por SFTP o SSH y ejecuta:

    find wp-content/cache -type f -mtime -7

    Esto muestra archivos modificados en los últimos 7 días. Un archivo tmp sin cambios esperados es sospechoso.

    2. Buscar patrones de código malicioso: Los backdoors suelen contener strings específicos. Ejecuta:

    grep -r "eval|base64_decode|system|passthru|exec" wp-content/cache/

    Si encuentras estas funciones en archivos que no deberían tenerlas, es una bandera roja.

    3. Verificar tamaño de archivos inusual: Un archivo cache debería tener un tamaño predecible. Si wp-content/cache/ contiene archivos de 500KB cuando normalmente son 10KB, investiga.

    4. Usar herramientas automatizadas: Wordfence CLI y MalCare escanean estos directorios por defecto. Son más rápidas y fiables que búsquedas manuales.

    Configuración de seguridad para archivos temporales

    Proteger estas carpetas es tan importante como detectar el malware. Estas son las medidas que siempre recomiendo:

    Deshabilitar ejecución de PHP en wp-content/uploads/: Añade esto a un archivo .htaccess en esa carpeta:

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

    Incluso si el atacante sube un .php, no se ejecutará.

    Proteger wp-content/cache/ con permisos restrictivos: El propietario debe ser el usuario del servidor (www-data), con permisos 755 en directorios y 644 en archivos. Un 777 es una invitación abierta.

    chmod -R 755 wp-content/cache
    chmod -R 644 wp-content/cache/*

    Configurar wp-config.php para deshabilitar edición de archivos: Esto impide que un atacante con acceso administrativo inyecte código:

    define('DISALLOW_FILE_EDIT', true);
    define('DISALLOW_FILE_MODS', true);

    Limpiar caches regularmente: Si usas WP Super Cache, configúralo para expirar cada 2-4 horas. Un cache antiguo es un backdoor potencial no detectado.

    Logs y monitoreo continuo

    La detección pasiva no es suficiente. Necesitas visibilidad activa sobre qué sucede en tus directorios temporales.

    Configura logs de acceso a wp-content/ en tu servidor. Con nginx o Apache, puedes registrar cada petición. Busca patrones sospechosos: múltiples 404 seguidos de un 200 exitoso, o accesos a archivos que no deberían existir.

    Usa OWASP Web Security Testing Guide como referencia para identificar qué constituyente anómalo en un log.

    Si tienes acceso a WP-CLI, ejecuta esto regularmente:

    wp eval 'echo date("Y-m-d H:i:s") . ": Check completedn";'

    Esto te ayuda a establecer un baseline de cuándo suceden cosas en tu WordPress.

    Herramientas recomendadas para auditoría

    No debes confiar únicamente en búsquedas manuales. Las herramientas profesionales son más exhaustivas:

    • Wordfence Scan – Detecta backdoors en caché y directorios temporales con su motor de firmas.
    • Sucuri SiteCheck – Análisis desde la nube, identifica código inyectado en archivos públicos.
    • VirusTotal – Carga archivos sospechosos para analizarlos con 70+ motores antimalware.
    • Análisis forense local con strings y file – Herramientas Linux para inspeccionar contenido binario de archivos comprometidos.

    Limpieza de backdoors encontrados

    Si has identificado un backdoor en archivos temporales, el siguiente paso es crítico:

    1. No confíes en limpiar solo el archivo. El atacante puede tener acceso administrativo. Cambiar contraseñas de usuarios, revisar permisos de carpetas y buscar múltiples puntos de entrada.

    2. Limpia el caché completamente: Vacía wp-content/cache/, asegúrate de que el plugin de caché regenere archivos limpios.

    3. Revisa plugins y temas: Si un plugin escribía backdoors en tmp, está comprometido. Desactiva, borra e instala una versión verificada desde el repositorio oficial.

    4. Audita cambios recientes: Usa NVD/CVE para verificar si los plugins comprometidos tenían vulnerabilidades conocidas. Esto te ayuda a entender cómo entró el atacante.

    Política de seguridad preventiva

    La mejor defensa es la prevención. Estos hábitos reducen drásticamente el riesgo:

    • Mantén WordPress, plugins y temas siempre actualizados. Los backdoors explotan vulnerabilidades old-day.
    • Usa contraseñas fuertes y autenticación de dos factores en wp-admin.
    • Instala solo plugins desde el repositorio oficial de WordPress.org. Los temas nulled y plugins crackeados suelen contener backdoors integrados.
    • Realiza copias de seguridad semanales (no en el mismo servidor). Son tu única opción si necesitas restaurar después de una infección.
    • Limita permisos de carpetas: nunca 777, siempre 755 en directorios y 644 en archivos.

    Casos reales que he atendido

    Para que entiendas el riesgo real, te cuento dos casos que he analizado:

    Caso 1 – Blog de viajes comprometido: El propietario no actualizaba W3 Total Cache desde hacía 18 meses. El plugin tenía una vulnerabilidad de RFI que permitía inyectar código. El backdoor estaba en wp-content/cache/page_cache/index-http-443-example.com-2024-01-15-21-45-12.html. Era invisible porque parecía un archivo legítimo de caché con extensión .html (aunque contenía PHP ejecutable). Lo detecté porque noté que ese archivo se «regeneraba» cada 5 minutos, cuando debería hacerlo cada 24 horas.

    Caso 2 – Tienda online comprometida: Un plugin de caché nulled, descargado de un sitio de «plugins gratis». Contenía un backdoor hardcodeado en su función de limpieza de caché. Cada vez que el caché se regeneraba, creaba un archivo webshell en wp-content/uploads/cache_temp/. El atacante tenía acceso de root al servidor.

    Ambos casos hubieran sido evitables con actualización regular y verificación de plugins.

    Integración con Google Search Console y auditorías de seguridad

    Si tu sitio ha sido comprometido, Google lo sabrá. La Search Console mostrará advertencias de «contenido malicioso detectado». Una vez limpies el backdoor:

    • Solicita una revisión de seguridad en Google Search Console.
    • Envía el sitio a Google Safe Browsing para verificación.
    • Usa Sucuri SiteCheck para confirmar que la malaria está limpia.

    El tiempo entre infección y limpieza impacta tu SEO y reputación. Cada día cuenta.

    Si sospechas que tu WordPress contiene backdoors en archivos temporales, no esperes. Contáctame para una auditoría de seguridad profesional en ManuelFolgar.com/contacto. Realizaré un escaneo forense completo, identificaré todos los puntos de entrada y te proporcionaré un plan de hardening específico para tu configuración.

    La seguridad de tu sitio no es un gasto; es una inversión en su continuidad.