Etiqueta: ciberseguridad web

  • Diagnóstico profesional: herramientas que revelan lo que esconden los atacantes

    Diagnóstico profesional: herramientas que revelan lo que esconden los atacantes

    Diagnóstico profesional: herramientas que revelan lo que esconden los atacantes

    Cuando analizo un sitio web comprometido, lo primero que hago es dejar a un lado las suposiciones. En mi experiencia, la diferencia entre identificar una amenaza real o pasar por alto un backdoor silencioso depende casi enteramente de las herramientas que uses y de cómo las domines. En este artículo te muestro el arsenal técnico que yo utilizo diariamente para exponer lo que los atacantes intentan ocultarte.

    Por qué necesitas herramientas de diagnóstico específicas

    Un malware moderno no deja señales obvias. No es un archivo rojo titilante en tu panel de WordPress. Es código inyectado en funciones.php, es una tabla de base de datos con registros de backdoor, es un certificado SSL comprometido que sigue siendo válido, es un usuario fantasma creado hace seis meses que nadie recuerda. Sin las herramientas adecuadas, navegas a ciegas.

    Lo que recomiendo siempre es un enfoque en capas: escaneo superficial, análisis de código, inspección de base de datos, auditoría de logs, y búsqueda de indicadores de compromiso (IoC). Cada herramienta te revela una perspectiva distinta del ataque.

    Herramientas de escaneo web: tu primera línea de defensa

    Empiezo con Sucuri SiteCheck. No es una herramienta cara ni requiere instalación. Metes la URL y en segundos ves si Google ha marcado el dominio como malicioso, si hay inyección de código malicioso detectada, si los certificados SSL están comprometidos. He descubierto cryptominers que llevaban dos meses inyectados solo porque SiteCheck los detectó en la lista negra de proveedores.

    Sucuri SiteCheck es gratuito. Es tu aliado. Úsalo antes de hacer nada más.

    Para análisis más profundo, recomiendo MalCare Security. Es un plugin de WordPress que ejecuta un escaneo de malware comparando tu código contra una base de datos de más de 100 millones de firmas de malware conocidas. Lo que MalCare hace bien es detectar backdoors incrustados en temas y plugins legitimados. He visto casos donde un plugin de contacto aparentemente limpio contenía una webshell escondida bajo el nombre de una clase falsa.

    Wordfence Security es otra herramienta que uso constantemente. Su escáner es agresivo (a veces demasiado), pero su función de detección de cambios en archivos es imprescindible. Cuando alguien modifica tu wp-config.php o inyecta código en index.php, Wordfence lo sabe. Su CLI te permite automatizar auditorías sin depender del navegador.

    Inspección de línea de comandos: donde viven los ataques reales

    Las herramientas gráficas son tranquilizantes. La realidad está en la terminal.

    WP-CLI es mi arma más valiosa. Con un comando puedo listar todos los usuarios de WordPress, incluidos los fantasmas creados por backdoors. Con otro, puedo inspeccionar el contenido de funciones.php sin que el navegador intente renderizarlo (evitando que el código malicioso se ejecute mientras lo examino). Ejemplo básico:

    wp user list –allow-root

    Me muestra cada usuario, cada dirección de correo, cada fecha de creación. He encontrado usuarios llamados «temp», «admin2», «backup» creados en horarios extraños, siempre un indicador de compromiso.

    Para inspeccionar archivos sospechosos sin ejecutarlos, uso strings y grep. Si veo que un archivo .js tiene un tamaño inusual (200 KB cuando debería tener 20 KB), ejecuto:

    strings archivo.js | grep -i «eval|base64|setTimeout»

    Los atacantes casi siempre usan eval(), ofuscación base64 o setTimeout para ocultar código. Si lo encuentro, lo sé.

    Análisis de base de datos: donde los atacantes guardan los secretos

    La base de datos es el corazón del sitio. Un atacante que coloque una puerta trasera bien hecha siempre guarda credenciales, configuración maliciosa o registros en la BD.

    Accedo vía SSH y conecto directamente a MySQL:

    mysql -u usuario -p basedatos

    Luego ejecuto:

    SELECT * FROM wp_users WHERE user_registered > DATE_SUB(NOW(), INTERVAL 30 DAY);

    Esto me muestra cada usuario creado en los últimos 30 días. Frecuentemente encuentro usuarios que no reconoce nadie.

    También inspecciono tablas personalizadas que no deberían existir. Los atacantes a menudo crean tablas como wp_cache_malware o wp_tmp_data para almacenar datos exfiltrados. Un comando simple:

    SHOW TABLES;

    Te revela si hay tablas inusuales. Una vez encontré una tabla llamada «crypto_data» con direcciones de wallet de Bitcoin.

    Análisis de logs: la cronología del ataque

    Los logs nunca mienten. Un atacante puede borrar muchas cosas, pero si los logs de servidor están intactos, puedes reconstruir el ataque completo.

    Apache/Nginx logs en /var/log/apache2/access.log o /var/log/nginx/access.log contienen cada solicitud HTTP. Busco patrones sospechosos:

    grep «wp-admin|wp-login.php» /var/log/apache2/access.log | cut -d’ ‘ -f1 | sort | uniq -c | sort -rn

    Este comando me muestra qué IPs intentaron acceder a wp-login.php más veces. Ataques de fuerza bruta son obvios: cientos de peticiones desde la misma IP en minutos.

    Wordfence genera sus propios logs (en /wp-content/plugins/wordfence/) que son aún más útiles porque ya filtran intentos de ataque identificados.

    Herramientas de detección de inyección de código

    VirusTotal no es específicamente para WordPress, pero es poderosa. Subo archivos sospechosos (o incluso URLs completas) y dejo que 70+ antivirus los analicen simultáneamente. He detectado webshells que MalCare pasó por alto simplemente porque VirusTotal lo flagueó como Trojan.PHP.Shell.

    Para análisis local, grep recursivo es tu aliado. Busco patrones característicos de inyección:

    grep -r «eval(» . –include=»*.php» | head -20

    grep -r «base64_decode» . –include=»*.php»

    grep -r «assert(» . –include=»*.php»

    El 90% de los backdoors contienen al menos una de estas funciones. Es raro encontrar código legítimo que las use.

    Auditoría de permisos de archivos y propietarios

    Un ataque exitoso casi siempre requiere cambiar permisos de archivos. Un archivo .php que debería ser 644 pero es 777 es una bandera roja. Ejecuto:

    find . -type f -perm 777 -o -type f -perm 666

    Cualquier archivo con permisos de escritura global es sospechoso.

    También verifico propietarios:

    find . -not -user usuario_www -type f

    Si hay archivos propiedad de «root» o un usuario extraño en una carpeta que el servidor debería controlar, algo ocurrió.

    Inspección de certificados SSL y conexiones externas

    Atacantes modernos a menudo redirigen tráfico hacia servidores C2 (command and control). Inspecciono:

    openssl s_client -connect dominio.com:443

    Verifico que el certificado es legítimo y que no hay MITM (man-in-the-middle). También busco configuraciones de DNS sospechosas o modificaciones en .htaccess que redirijan tráfico.

    Monitoreo continuo vs. diagnóstico puntual

    El diagnóstico profesional no es un evento único. Después de detectar y limpiar un ataque, configuro monitoreo permanente. Wordfence en modo «monitoring» revisa cambios de archivos diariamente. Sucuri proporciona alertas de malware. Google Search Console notifica si hay malware detectado nuevamente.

    Lo que aprendí después de limpiar cientos de webs es que el 40% de los sites reinfectados lo fueron porque no se configuró vigilancia post-limpieza.

    Herramientas específicas para PrestaShop

    Si tu problema es PrestaShop, el enfoque es ligeramente distinto. Busco modificaciones en /classes/, inyecciones en /modules/, y especialmente en módulos de pago comprometidos. La herramienta más útil es una auditoría manual de hashes de archivos comparándola con la versión oficial de PrestaShop descargada directamente desde su web.

    El diagnóstico que no puedes hacer solo

    Estas herramientas te dan visibilidad. Pero cuando encuentras un backdoor bien ofuscado, o cuando necesitas reconstruir un ataque APT (Advanced Persistent Threat) para entender cómo los atacantes mantuvieron acceso durante meses, necesitas análisis forense profesional. Yo combino estas herramientas con análisis manual de código, ingeniería inversa de malware, y reconstrucción de cadenas de ataque.

    Si tu sitio ha sido comprometido o sospechas que lo está, estas herramientas te dan un diagnóstico inicial. Pero si necesitas garantía de que está completamente limpio, si necesitas investigación forense de un ataque sofisticado, o si el malware está bien oculto, contacta conmigo para un diagnóstico profesional completo. Ejecuto análisis manual, verifico cada línea de código sospechosa, audito permisos, inspecciono logs históricos, y te doy un reporte detallado de qué pasó, cómo entró, y cómo garantizar que no vuelva.

    El coste de no diagnosticar correctamente es mucho mayor que el de hacerlo bien desde el principio.

  • Blindaje post-ataque: medidas de hardening que realmente funcionan en 48 horas

    Blindaje post-ataque: medidas de hardening que realmente funcionan en 48 horas

    Blindaje post-ataque: medidas de hardening que realmente funcionan en 48 horas

    Cuando descubres que tu sitio web ha sido comprometido, el pánico es justificado. Pero lo que haces en las primeras 48 horas marca la diferencia entre una recuperación rápida y semanas de lucha contra el malware. En mi experiencia analizando cientos de webs infectadas, los sitios que aplican un blindaje estructurado post-ataque logran eliminar vectores de riesgo críticos y evitar reinfecciones en menos de dos días.

    Te mostraré exactamente qué hacer, con qué herramientas y en qué orden, para levantar defensas reales mientras limpias los restos del compromiso.

    Hora 0-2: Aislamiento y diagnóstico de urgencia

    Lo primero es contener el daño. No se trata de limpieza profunda todavía, sino de detener el sangrado mientras recopilamos inteligencia.

    Desconecta la base de datos de bases de datos remotas. Muchos backdoors usan túneles SFTP o conexiones SSH comprometidas para exfiltrar datos de clientes. Si tu hosting permite, cierra el acceso SFTP/SSH durante 48 horas o cambia las credenciales por unas generadas aleatoriamente que solo tú conoces.

    Extrae el wp-config.php (WordPress) o config/settings.php (PrestaShop) a un directorio protegido. Usa WP-CLI para WordPress:

    wp config get DB_USER

    Anota todas las contraseñas activas. Luego las cambiaremos, pero primero necesitas saber cuáles están comprometidas. En PrestaShop, accede vía phpMyAdmin y ejecuta un volcado de las tablas de usuarios antes de modificar nada.

    Genera un reporte rápido con Wordfence CLI. Si tienes acceso SSH, descarga Wordfence CLI y ejecuta:

    wordfence scan --output=detailed

    Esto te da un mapa de archivos sospechosos en 5-10 minutos. Alternativa si no tienes SSH: usa Sucuri SiteCheck en modo online desde https://sitecheck.sucuri.net. No es tan profundo, pero identifica backdoors obvios y patrones de inyección.

    Documenta el incidente en tu log local. Crea un archivo timeline.txt con fecha, hora, qué detectaste y quién tiene acceso. Esto será tu defensa legal y técnica si necesitas reportarlo a AEPD o a tus usuarios.

    Hora 2-6: Cambio masivo de credenciales

    Aquí es donde la mayoría de sitios falla. Cambiar solo la contraseña de admin de WordPress NO es suficiente. Los atacantes suelen crear cuentas fantasma o modificar usuarios existentes a nivel de base de datos.

    WordPress:

    1. Accede a wp-admin (si aún funciona). Si está bloqueado, usa WP-CLI:
      wp user update admin --user_pass="nueva_password_aleatoria_32_caracteres"
    2. Elimina todos los usuarios excepto los necesarios. En wp-admin, ve a Usuarios y borra cuentas sospechosas. Si usas CLI:
      wp user delete [usuario_sospechoso] --reassign=admin
    3. Cambia el email de recuperación de cada usuario admin a uno que controles:
      wp user update admin --user_email="nuevo@dominio.es"
    4. Genera credenciales nuevas para SFTP, SSH y MySQL. Avisa a tu hosting que necesitas resetear todas (esto puede tardar 30 min).

    PrestaShop:

    1. Accede al back-office. Ve a Administración > Empleados y revisa todas las cuentas. Elimina cualquier que no reconozcas.
    2. Cambia la contraseña de cada empleado activo desde el mismo panel.
    3. Ve a Configuración > Tiendas y resetea la contraseña del usuario «Admin» (el usuario root del sistema).
    4. Comprueba que el archivo config/settings.inc.php solo está accesible por lectura:
      chmod 444 config/settings.inc.php

    Correos y 2FA (autenticación de dos factores): Si tu proveedor de hosting ofrece 2FA en el panel de control, actívalo ahora. Para WordPress, instala Google Authenticator o Authy en tu teléfono y configura 2FA en wp-admin usando un plugin de confianza como Two Factor (desarrollado por WordPress Security Team).

    Hora 6-12: Eliminación de puertas traseras y ficheros sospechosos

    Este es el momento técnico más delicado. Los backdoors modernos no siempre se ven. Pueden estar comprimidos en base64, ofuscados en PHP, o incrustados en ficheros legítimos.

    Busca archivos recién modificados. Accede por SFTP o línea de comandos y ordena por fecha de modificación:

    find /var/www/html -type f -mtime -2 -name "*.php" | head -20

    Esto te muestra todos los PHP modificados en los últimos 2 días. Descárgalos y abre cada uno en un editor de texto. Los backdoors suelen tener características reconocibles: funciones eval(), system(), shell_exec(), $_REQUEST o $_POST sin validar, o código en base64.

    Elimina plugins y temas desactualizados (WordPress). La mayoría de infecciones entran por aquí. Ve a Plugins > Plugins instalados y desactiva todo lo que no uses. Luego:

    wp plugin delete [nombre] --allow-root

    Para temas, si no es Twenty Twenty-Three o superior (temas oficiales de WordPress), considera eliminarlo también:

    wp theme delete [nombre] --allow-root

    Deshabilita la edición de archivos en WordPress. Añade esto al final de wp-config.php:

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

    Esto impide que un atacante (incluso con acceso a wp-admin comprometido) pueda editar funciones.php o plugin files.

    En PrestaShop, elimina módulos no verificados. Ve a Módulos y desinstala cualquier módulo de fuente desconocida, especialmente relacionados con pagos o email. Los skimmers Magecart se disfrazan de módulos legales.

    Hora 12-24: Fortalecimiento de permisos y acceso

    Ahora que el sitio está más limpio, blindamos los puntos de entrada.

    Corrige permisos de directorios. Los permisos incorrectos son una rampa de acceso directa para atacantes. Para WordPress:

    find /var/www/html -type d -exec chmod 755 {} ;
    find /var/www/html -type f -exec chmod 644 {} ;
    chmod 600 /var/www/html/wp-config.php
    chmod 700 /var/www/html/wp-content/uploads

    Para PrestaShop:

    chmod 755 app/config/
    chmod 644 app/config/parameters.php
    chmod 700 var/
    chmod 755 modules/

    Protege wp-login.php (WordPress). Añade a tu .htaccess una regla que limite intentos de fuerza bruta:

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} wp-login.php
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteRule ^.*$ - [F,L]
    </IfModule>

    O usa una solución más robusta: redirige wp-login.php a una URL privada. En wp-config.php:

    define('WP_HOME', 'https://tudominio.es');
    define('WP_SITEURL', 'https://tudominio.es');
    define('ADMIN_COOKIE_DOMAIN', 'tudominio.es');

    Luego instala Hide My WP o un plugin equivalente que cambie la ruta de acceso al panel.

    Establece límite de intentos de login. En el .htaccess, añade:

    <IfModule mod_limit.c>
    <Limit GET POST>
    order allow,deny
    allow from all
    </Limit>
    </IfModule>

    O usa el plugin Wordfence (versión gratuita) que incluye rate limiting nativo.

    Hora 24-36: Refuerzo de configuración HTTP y CSP

    Las cabeceras HTTP son tu escudo contra ataques cliente y exfiltración de datos. Muchos sitios las ignoran.

    Implementa Content Security Policy (CSP). Añade a tu .htaccess o a wp-config.php (via plugin):

    Header set Content-Security-Policy "default-src 'self'; script-src 'self' cdn.ejemplo.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none';"

    CSP previene inyecciones de código malicioso (XSS) y exfiltración de datos vía CORS.

    Añade HSTS (HTTP Strict Transport Security).

    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    Esto obliga a HTTPS permanente y previene downgrade attacks.

    Protege contra clickjacking y MIME sniffing:

    Header set X-Frame-Options "SAMEORIGIN"
    Header set X-Content-Type-Options "nosniff"
    Header set X-XSS-Protection "1; mode=block"

    Desactiva la indexación de directorios. Si hay una carpeta sin index.php o index.html, los atacantes pueden explorar archivos:

    <IfModule mod_autoindex.c>
    Options -Indexes
    </IfModule>

    En PrestaShop, asegúrate de que admin/index.php esté protegido con IP whitelist en el .htaccess del directorio admin/:

    <Files "index.php">
    order deny,allow
    deny from all
    allow from 192.168.1.1
    </Files>

    (Sustituye la IP por la tuya o la de tu oficina.)

    Hora 36-48: Monitoreo y verificación

    Las últimas 12 horas son para verificar que todo funciona y configurar alertas.

    Ejecuta un escaneo completo post-limpieza. Usa MalCare o Sucuri SiteCheck nuevamente. Debe salir completamente limpio. Si detecta malware residual, vuelve al paso de búsqueda de backdoors.

    Configura logging y alertas. En WordPress, instala WP Security Audit Log o similar. Configura alertas por email para:

    • Nuevos usuarios creados
    • Cambios en plugins o temas
    • Acceso a wp-admin desde IPs nuevas
    • Errores 404 o 403 frecuentes (intentos de acceso a archivos protegidos)

    Monitorea la base de datos. En phpMyAdmin, ejecuta una consulta para buscar inyecciones SQL residuales:

    SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%' OR post_content LIKE '%eval%' OR post_content LIKE '%base64%';

    Si encuentras algo, edita o elimina ese post.

    Notifica a Google Search Console. Reporta que el sitio fue hackeado. Ve a Seguridad > Problemas de seguridad. Google puede tomar días en limpiar el index, pero es obligatorio informar.

    Cumple con normativa AEPD si manejabas datos personales. Si almacenabas datos de clientes (emails, teléfonos, direcciones), debes reportar la brecha a la Autoridad de Protección de Datos. El plazo es máximo 72 horas desde que descubriste el incidente.

    Checklist de 48 horas (para imprimir)

    • ☐ Cambio de todas las credenciales (MySQL, SFTP, SSH, wp-admin, panel hosting)
    • ☐ Búsqueda y eliminación de backdoors (archivos recientes, code review)
    • ☐ Eliminación de plugins/temas desactualizados o sospechosos
    • ☐ DISALLOW_FILE_EDIT y DISALLOW_FILE_MODS en wp-config.php
    • ☐ Permisos corregidos (644 archivos, 755 directorios, 600 wp-config.php)
    • ☐ Protección de wp-login.php y admin con rate limiting
    • ☐ CSP, HSTS y cabeceras de seguridad en .htaccess
    • ☐ 2FA activado en hosting y wp-admin
    • ☐ Escaneo post-limpieza con Sucuri o MalCare
    • ☐ Reporte a Google Search Console y AEPD (si corresponde)

    ¿Y después de 48 horas?

    El blindaje inicial está hecho, pero esto no es permanente. Los atacantes evolucionan, y tu defensa debe también. Después de estos dos días, necesitas:

    • Actualizaciones automáticas: Activa actualizaciones de seguridad automáticas en WordPress para core, plugins y temas.
    • Backups diarios: Configura backups automáticos con UpdraftPlus o Backwpup que se almacenen fuera del servidor (AWS S3, Dropbox, Google Drive).
    • Monitoreo 24/7: Usa Wordfence, MalCare o Sucuri (versión premium) para alertas en tiempo real.
    • Auditoría trimestral: Cada tres meses, pide un análisis profesional. Mi equipo en ManuelFolgar.com lo hacemos rutinariamente a clientes recuperados.

    Errores que NO debes cometer

    No reinstales WordPress o PrestaShop sobre el sitio comprometido. Es tentador hacer table rasa, pero si un backdoor está en tu hosting o en credenciales compartidas, volverá a infectar.

    No confíes en plugins «de limpieza automática». Algunos como WP Hacked Help prometen limpiar automáticamente. En mi experiencia, son lentos y dejan restos. Es mejor un análisis manual rápido que una falsa seguridad.

    No publiques en redes que fuiste hackeado sin estar seguro de que está limpio. Los atacantes monitorean búsquedas sobre sus víctimas y pueden reinfectar si ven que están limpios pero vulnerables.

    No olvides cambiar contraseñas de email asociadas. Si tu dominio está registrado con un email [email protected] y fue comprometido, un atacante puede resetear el dominio o certificados SSL. Cambia también esa contraseña.

    En ManuelFolgar.com hemos visto sitios que, sin ayuda profesional, tardan 2-3 semanas en estar seguros. Con este plan de 48 horas, aceleramos significativamente. Pero si en algún momento sientes que el malware se resiste, que tu acceso está bloqueado o que no sabes identificar código malicioso, contáctame para una auditoría completa y limpieza profesional. Garantizo que en 48-72 horas tu sitio estará limpio, blindado y monitoreado.

    El tiempo es tu aliado en un ciberataque. Actúa rápido, sigue este orden, y recuerda: la mejor defensa es que no te haqueen. Pero si ya pasó, que al menos sea una lección aprendida.

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

  • Error de parseador: malware en tema o plugin WordPress

    Error de parseador: malware en tema o plugin WordPress

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

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

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

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

    Diferencia entre error de parseador legítimo y malware

    Error de parseador accidental (actualización o conflicto)

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

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

    Error de parseador por malware

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

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

    Cómo identificar malware en temas y plugins WordPress

    Paso 1: Revisa los logs de error de WordPress

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

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

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

    Paso 2: Auditoria de plugins y temas instalados

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

    wp plugin list --field=name

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

    Haz lo mismo con temas:

    wp theme list --field=name

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

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

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

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

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

    Paso 4: Análisis con herramientas especializadas

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

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

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

    El problema específico de los temas y plugins nulled

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

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

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

    ¿Cómo reparar el error de parseador?

    Opción segura: desactivar el plugin o tema sospechoso

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

    wp plugin deactivate nombre-del-plugin

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

    Opción nuclear: recuperar desde backup limpio

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

    Limpiar código inyectado (solo si tienes experiencia)

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

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

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

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

    1. Desactiva la edición de archivos en WordPress

    Añade a wp-config.php:

    define('DISALLOW_FILE_EDIT', true);

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

    2. Usa solo plugins y temas de fuentes oficiales

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

    3. Mantén WordPress, plugins y temas actualizados

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

    define('AUTOMATIC_UPDATER_DISABLED', false);

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

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

    5. Cambia los permisos de archivos correctamente

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

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

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

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

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

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

    ¿Cuándo necesitas ayuda profesional?

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

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

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

    Resumen: cómo actuar ante el error de parseador

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

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

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

  • Recuperar WordPress hackeado: paso a paso desde cero

    Recuperar WordPress hackeado: paso a paso desde cero

    Recuperar WordPress hackeado: guía completa paso a paso

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

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

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

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

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

    Paso 1: Aislamiento inmediato (las primeras 2 horas)

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

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

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

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

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

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

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

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

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

    $ wp wordfence scan –skip-cache-flush

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    $ wp user list –role=administrator

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

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

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

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

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

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

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

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

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

    define(‘DISALLOW_FILE_EDIT’, true);

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

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

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

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

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

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

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

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

    Paso 5: Limpieza ante Google y reputación

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

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

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

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

    ¿Qué hago si no puedo hacerlo yo?

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

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

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

    Resumen de tiempos

    La recuperación total suele llevar:

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

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

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