El proyecto europeo que debía alumbrar el avión de combate del futuro ha terminado estrellándose antes de abandonar la mesa de diseño. Francia y Alemania han decidido abandonar el desarrollo conjunto del caza de sexta generación que constituía la pieza central del Future Combat Air System (FCAS), un ambicioso programa en el que también participaba España.

No se ha perdido únicamente un avión. El fracaso del FCAS pone de manifiesto las enormes dificultades que sigue encontrando Europa cuando intenta coordinar sus intereses políticos, militares, industriales y tecnológicos.

Mientras Estados Unidos y China avanzan en sus propios sistemas aéreos de nueva generación, los países europeos vuelven a separarse por disputas relacionadas con el liderazgo industrial, la propiedad intelectual y el reparto del trabajo.

FCAS no era solamente un avión

Aunque habitualmente se hablaba del FCAS como “el futuro caza europeo”, el proyecto era mucho más amplio.

Su núcleo era el New Generation Fighter (NGF), un avión de combate de sexta generación destinado a sustituir, a partir de la década de 2040, al Rafale francés y a los Eurofighter utilizados por Alemania y España.

Pero alrededor de ese avión debía construirse un auténtico sistema de sistemas compuesto por:

• Un avión de combate tripulado de nueva generación.
• Drones y vehículos no tripulados conocidos como remote carriers.
• Sensores avanzados.
• Sistemas de guerra electrónica.
• Nuevos motores aeronáuticos.
• Comunicaciones seguras.
• Inteligencia artificial para apoyar la toma de decisiones.
• Una nube de combate para intercambiar información en tiempo real.
• Integración con aviones, satélites, radares y plataformas terrestres o navales.

La idea consistía en crear una red de combate conectada en la que el avión pilotado fuese solamente uno de sus elementos.

El programa comenzó a tomar forma en 2017 mediante un acuerdo entre Francia y Alemania. España se incorporó oficialmente en 2019, con Indra como coordinador industrial nacional y con la participación de Airbus España, ITP Aero, GMV, Sener y otras empresas tecnológicas.

En diciembre de 2022 se adjudicó una fase de demostración valorada en aproximadamente 3.200 millones de euros, destinada a desarrollar prototipos y tecnologías durante unos tres años y medio.

El coste completo del programa se estimaba en torno a los 100.000 millones de euros a lo largo de varias décadas.

En uno de nuestros servidores Linux administrados, comenzamos a observar un comportamiento bastante extraño: el firewall funcionaba correctamente, pero, sin motivo aparente, todas sus reglas desaparecían.

Al ejecutar:

iptables -L -n

encontrábamos las cadenas vacías y las políticas predeterminadas en ACCEPT. Es decir, el servidor continuaba funcionando, pero había perdido todas las reglas de bloqueo que debían protegerlo.

Lo más desconcertante era que, después de restaurar el firewall, las reglas volvían a desaparecer pocos minutos después.

En este artículo explicamos la investigación que realizamos, las pistas que encontramos y cómo descubrimos que APF estaba ejecutando periódicamente un flush de todas las reglas de iptables.

Un script de vigilancia detectó la caída

El servidor contaba con un script propio que se ejecutaba periódicamente desde cron. Su función era comprobar el estado de diferentes servicios esenciales:

cat /root/bin/Comprueba.sh

Su contenido era similar al siguiente:

#!/bin/bash
#
# Comprueba que una serie de servicios
#

echo "Comprobando 1 de 10"
/root/bin/compruebasshd.sh

echo "Comprobando 2 de 10"
/root/bin/compruebafirewall.sh

echo "Comprobando 3 de 10"
/root/bin/compruebanamed.sh

echo "Comprobando 4 de 10"
/root/bin/compruebanamed-old.sh

echo "Comprobando 5 de 10"
/root/bin/compruebapostfix.sh

echo "Comprobando 6 de 10"
/root/bin/compruebadovecot.sh

echo "Comprobando 7 de 10"
/root/bin/compruebaccesosfallidos.sh

if [ ! -f /root/cargatrabajo.tmp ]; then
    echo "Comprobando 8 de 10"
    /root/bin/compruebahttpd.sh

    echo "Comprobando 9 de 10"
    /root/bin/compruebanginx.sh

    echo "Comprobando 10 de 10"
    /root/bin/compruebamysqld.sh
fi

if [ -f /root/cargatrabajo.tmp ]; then
    source /root/cargatrabajo.tmp

    quedan=$(echo "$quedan - 1" | bc)

    echo "Quedan: $quedan - $(date) -> $A" >> "$REGISTROSLOGS"
    echo "quedan=$quedan" > /root/cargatrabajo.tmp

    if [ "$quedan" -le 0 ]; then
        rm -f /root/cargatrabajo.tmp
        /root/bin/cargatrabajo.sh
    else
        exit 0
    fi
fi

Entre esas comprobaciones se encontraba:

/root/bin/compruebafirewall.sh

Durante muchos años ha circulado una idea que, aunque contiene parte de verdad, puede llevar a una peligrosa sensación de seguridad:

"En Linux no existen los virus."

La realidad es bastante diferente.

Los equipos Linux de escritorio siguen siendo un objetivo poco atractivo para la mayoría del malware tradicional, pero los servidores Linux que alojan sitios web son uno de los principales objetivos de los ciberdelincuentes.

WordPress, Joomla, PrestaShop, Drupal, Moodle, Dolibarr o cualquier otra aplicación web expuesta a Internet puede verse comprometida si aparece una vulnerabilidad, una contraseña es robada o un complemento desactualizado permite la ejecución de código.

Cuando eso ocurre, el atacante rara vez instala un "virus" clásico.

Lo habitual es encontrar:

• Webshells PHP.
• Puertas traseras (backdoors).
• Scripts para enviar spam.
• Mineros de criptomonedas.
• Redirecciones ocultas.
• Código JavaScript inyectado.
• Archivos modificados para mantener el acceso al servidor.

Aquí es donde entra en juego Linux Malware Detect (LMD), una de las herramientas más conocidas y utilizadas para detectar malware específico en servidores Linux.

¿Qué es Linux Malware Detect?

Linux Malware Detect, conocido habitualmente como LMD o Maldet, es un escáner antimalware desarrollado por R-fx Networks especialmente pensado para servidores Linux que alojan aplicaciones web.

A diferencia de un antivirus tradicional orientado al escritorio, LMD está especializado en detectar amenazas habituales en entornos de hosting:

• Malware PHP.
• Webshells.
• Código ofuscado.
• Backdoors.
• Scripts utilizados por botnets.
• Malware dirigido a CMS.

Su base de firmas se alimenta continuamente de muestras reales obtenidas en servidores comprometidos, lo que convierte a LMD en una herramienta especialmente eficaz para administradores de sistemas.

Auditor Web es un script Bash de auditoría de seguridad pensado para servidores Linux que alojan páginas desarrolladas en PHP. Permite buscar archivos sospechosos, código ofuscado, funciones peligrosas, modificaciones recientes, permisos inseguros y otros indicios habituales de una intrusión.

El script reconoce instalaciones de Joomla y WordPress, aunque también puede trabajar con cualquier sitio PHP en modo genérico. Está especialmente indicado para servidores administrados mediante Plesk, servidores de hosting compartido, VPS y máquinas dedicadas.

Una de sus características más útiles es que no se limita a generar un informe: después de cada análisis crea automáticamente un segundo script, específico para esa auditoría, con el que se pueden abrir uno por uno los archivos sospechosos utilizando bat, batcat o less.

De este modo resulta mucho más sencillo revisar el código encontrado, identificar una posible puerta trasera y distinguirla de una coincidencia legítima.

Importante: Auditor Web es una herramienta de detección y revisión. Una coincidencia no demuestra por sí sola que un archivo contenga malware.

¿Qué analiza Auditor Web?

El script realiza, entre otras, las siguientes comprobaciones:

• Archivos PHP modificados recientemente.
• Extensiones dobles y nombres frecuentemente utilizados por webshells.
• Ficheros PHP dentro de images, media, uploads, tmp, cache o directorios similares.
• Funciones capaces de ejecutar comandos del sistema.
• Código ofuscado mediante Base64, eval(), gzinflate() y técnicas parecidas.
• Líneas de código anormalmente largas.
• JavaScript inyectado u ofuscado.
• Descargas remotas, sockets y escritura de archivos.
• Archivos y directorios con permisos 777.
• Elementos escribibles por cualquier usuario.
• Enlaces simbólicos que salen de la raíz auditada.
• Reglas sospechosas en .htaccess, .user.ini y php.ini.
• Peticiones relacionadas con webshells en los registros de Apache o Nginx.
• Tareas programadas que utilizan curl, wget, PHP, Python o directorios temporales.
• Versiones locales de Joomla, WordPress, plugins, plantillas y extensiones.
• Usuarios administradores y determinados contenidos sospechosos almacenados en la base de datos.

El análisis del sistema de archivos se realiza en modo de solo lectura. El script no elimina ni pone en cuarentena ningún archivo automáticamente.

#!/usr/bin/env bash
#
# auditor-web-malware.sh
# Auditor de solo lectura para buscar indicios de compromiso en sitios PHP.
# Detecta Joomla, WordPress o funciona en modo generico.
# Inspirado en la guia de LinuxParty sobre Helix Ultimate y SP Page Builder.
#
# No elimina, mueve ni modifica archivos o registros de la base de datos.

set -uo pipefail
export LC_ALL=C

VERSION="1.3.1"
DAYS=30
SINCE=""
ROOT=""
LOG_DIR=""
TOKEN=""
OUTPUT=""
MAX_RESULTS=200
SKIP_DB=0
QUIET=0
COLOR_MODE="auto"
WEB_USERS="apache,www-data,nginx"
CMS_MODE="auto"
CMS="generic"
ALERT_HITS=0
REVIEW_HITS=0
ERRORS=0
MYSQL_CNF=""
SUSPECTS_OUTPUT=""
REVIEW_SCRIPT=""
RUN_STAMP=$(date '+%Y%m%d-%H%M%S')

usage() {
    cat <<'EOF'
Uso:
  sudo ./auditor-web-malware.sh --root /ruta/al/sitio [opciones]

Opciones:
  -r, --root DIR       Directorio raiz del sitio web (obligatorio).
  -d, --days N         PHP modificados en los ultimos N dias (30).
      --since FECHA    Buscar ficheros posteriores a FECHA; ej. 2026-07-15.
  -l, --logs DIR       Directorio de logs Apache/Nginx. Se intenta detectar.
  -t, --token TEXTO    Token, nombre de webshell o texto literal para los logs.
  -o, --output FILE    Informe de salida. Por defecto, en el directorio actual.
  -m, --max N          Maximo de lineas mostradas por prueba (200).
      --web-users LIST Usuarios web separados por coma (apache,www-data,nginx).
      --cms TIPO       auto, joomla, wordpress o generic (auto).
      --skip-db        No analizar la base de datos del CMS.
  -q, --quiet          No mostrar progreso; escribir solamente el informe.
      --color MODO     Colores: auto, always o never (auto).
      --no-color       Equivale a --color never.
  -h, --help           Mostrar esta ayuda.
      --version        Mostrar la version.

Codigos de salida:
  0  Auditoria terminada sin indicios de alta prioridad.
  1  Se encontraron indicios de alta prioridad que deben revisarse.
  2  Error de uso o no se pudo completar una parte esencial.

Ejemplos:
  sudo ./auditor-web-malware.sh -r /var/www/vhosts/dominio/httpdocs
  sudo ./auditor-web-malware.sh -r /var/www/vhosts/dominio/httpdocs \
       --since 2026-07-15 --logs /var/www/vhosts/system/dominio/logs
  sudo CMS_DB_PASSWORD='clave' ./auditor-web-malware.sh -r /srv/wordpress

La variable CMS_DB_PASSWORD, si existe, sustituye la clave leida de
configuration.php o wp-config.php. La clave nunca se imprime en el informe.

El auditor genera junto al informe:
  - Una lista terminada en .sospechosos.txt.
  - Un script autonomo revisar-SITIO-FECHA.sh para examinar con bat o less
    los ficheros sospechosos de esa ejecucion concreta.
EOF
}

La Comisión Europea continúa impulsando nuevas medidas para reforzar la protección de los menores en Internet. Entre ellas se encuentra la implantación de sistemas de verificación de edad que permitan impedir el acceso de menores a determinados contenidos y redes sociales.

Sobre el papel, el objetivo parece difícil de cuestionar. Todos coincidimos en que los menores deben estar protegidos frente a contenidos inapropiados, estafas, manipulación o plataformas diseñadas para captar su atención durante horas.

Sin embargo, cuando la protección de los menores se convierte en la puerta de entrada a sistemas de verificación de identidad obligatorios, conviene preguntarse hasta dónde estamos dispuestos a ceder privacidad a cambio de seguridad.

La historia se repite

No es la primera vez que una medida nace con una finalidad legítima.

Las cámaras de vigilancia se instalaron para prevenir delitos.

La conservación de determinados datos de comunicaciones se justificó por la lucha contra el terrorismo.

Los sistemas biométricos comenzaron utilizándose para mejorar la seguridad en aeropuertos y fronteras.

En todos los casos existía un objetivo razonable.

La cuestión no suele ser el propósito inicial, sino hasta dónde puede extenderse una vez que la infraestructura ya existe.

Porque una vez creado un sistema capaz de verificar la identidad de millones de ciudadanos, la tentación de utilizarlo para nuevos fines siempre estará presente.

Hoy puede servir para impedir que un menor acceda a una red social.

¿Y mañana?

La privacidad es un derecho, no un obstáculo

Desde hace años, la Unión Europea ha sido uno de los mayores defensores de la privacidad digital. El Reglamento General de Protección de Datos (RGPD) marcó un antes y un después en la protección de la información personal.

Precisamente por eso resulta paradójico que ahora el debate se centre en cómo identificar cada vez a más ciudadanos para acceder a determinados servicios digitales.

Aunque las instituciones europeas aseguran que estos sistemas incorporarán garantías técnicas y minimizarán la cantidad de datos compartidos, sigue habiendo preguntas importantes que merecen respuesta.

¿Quién custodiará esa información?

¿Durante cuánto tiempo?

¿Qué organismos podrán acceder a ella?

¿Qué ocurrirá si en el futuro cambian las normas o las prioridades políticas?

Cuando hablamos de identidad digital, las preguntas son tan importantes como las respuestas.

"Qué se puede hacer hoy con n8n e IA, y qué todavía está en fase experimental."

Durante las tres primeras entregas de esta serie hemos aprendido qué es n8n, cómo instalarlo y cómo construir automatizaciones útiles para administrar servidores Linux. Pero el ecosistema tecnológico está cambiando rápidamente. La irrupción de los grandes modelos de lenguaje (LLM) y de los llamados agentes inteligentes está transformando la forma en que interactuamos con las aplicaciones. ¿Qué ocurre cuando unimos n8n con la Inteligencia Artificial? La respuesta abre un escenario completamente nuevo para administradores de sistemas, desarrolladores y empresas.

La automatización entra en una nueva etapa

Hasta hace muy poco, automatizar significaba ejecutar una serie de pasos predefinidos.

Si ocurría A...

Entonces ejecutar B.

Después C.

Y finalmente D.

Ese modelo sigue siendo válido.

Pero la Inteligencia Artificial añade una capacidad completamente nueva: tomar decisiones basadas en el contenido de la información, no únicamente en reglas fijas.

Ya no se trata solo de mover datos entre aplicaciones.

Ahora podemos analizarlos, resumirlos, clasificarlos e incluso generar respuestas automáticamente.

¿Qué aporta realmente un LLM?

Un modelo de lenguaje como GPT, Llama, Mistral o Gemma no sustituye a n8n.

Lo complementa.

n8n sigue siendo quien orquesta el proceso.

La IA simplemente actúa como un nodo más dentro del Workflow.

Por ejemplo:

Correo recibido
        │
        ▼
Extraer contenido
        │
        ▼
Modelo de IA
        │
        ▼
Clasificar incidencia
        │
        ▼
Crear ticket
        │
        ▼
Enviar respuesta

Sin escribir reglas para cada caso.

Es el propio modelo quien interpreta el contenido.

Después de la publicación de nuestra guía sobre la vulnerabilidad crítica de Helix Ultimate y SP Page Builder, muchos administradores nos han preguntado lo mismo:

"He actualizado el sitio... ¿pero cómo sé si el atacante ya había entrado?"

La respuesta es sencilla: actualizar elimina la vulnerabilidad, pero no elimina las modificaciones que un atacante haya realizado previamente.

No deje de ver éste artículo:

Instalar Linux Malware Detect (LMD) en RHEL, AlmaLinux, Rocky Linux y Fedora: protege tu servidor frente a malware y webshells

Si el sitio fue comprometido antes de instalar la actualización, es posible que el atacante haya dejado puertas traseras (webshells), usuarios administradores ocultos o modificaciones en la base de datos que seguirán funcionando incluso después de instalar la versión corregida.

1. Buscar usuarios administradores sospechosos

Lo primero es revisar la tabla de usuarios de Joomla.

Tal vez sobre decirlo, pero cambia TuPrefijo por el prefijo de tu base de datos.

SELECT id, name, username, email, registerDate
FROM TuPrefijo_users
ORDER BY id DESC;

Presta especial atención a:

• usuarios creados recientemente;
• direcciones de correo extrañas;
• cuentas con nombres aparentemente legítimos pero desconocidas;
• administradores que no recuerdes haber creado.

Después verifica que esos usuarios pertenecen realmente al grupo Super Users.

SELECT *
FROM TuPrefijo_user_usergroup_map
WHERE group_id = 8;

2. Revisar los parámetros del menú

Uno de los vectores más utilizados consiste en inyectar JavaScript malicioso dentro del campo

params

de la tabla

TuPrefijo_menu

.

SELECT id,title,params
FROM TuPrefijo_menu
WHERE params <> '{}'
AND params <> '';

Busca especialmente:

• etiquetas <script>;
• funciones eval(), atob(), fromCharCode() o document.write();
• URLs hacia dominios desconocidos;
• cadenas extremadamente largas codificadas en Base64;
• código JavaScript ofuscado.

Puedes localizar rápidamente registros sospechosos buscando directamente:

SELECT id,title
FROM TuPrefijo_menu
WHERE params LIKE '%<script%'
   OR params LIKE '%eval(%'
   OR params LIKE '%atob(%'
   OR params LIKE '%http://%'
   OR params LIKE '%https://%';

También resulta muy útil localizar los registros con mayor tamaño, ya que muchos ataques almacenan cientos o miles de caracteres de JavaScript:

SELECT id,title,LENGTH(params) AS longitud
FROM TuPrefijo_menu
ORDER BY longitud DESC;

Durante los últimos días se ha confirmado una campaña de ataques contra sitios Joomla 3 que utilizan Helix Ultimate, Helix 3 y SP Page Builder. Los atacantes están aprovechando varias vulnerabilidades ya corregidas para modificar la configuración del sitio, inyectar código JavaScript y, en algunos casos, crear nuevos usuarios con privilegios de Super Administrador. (JoomShaper)

En ExtreHost hemos podido analizar un caso real en producción donde el código malicioso había sido almacenado dentro del campo

params

de un elemento del menú principal.

A continuación explicamos cómo comprobar si tu instalación ha sido afectada y qué pasos recomendamos seguir para eliminar la infección.

¿Qué vulnerabilidades corrigen las actualizaciones?

JoomShaper ha publicado actualizaciones de seguridad para Joomla 3 que corrigen, entre otros problemas:

• Vulnerabilidades XSS (Cross Site Scripting) en Mega Menu, galerías y Media Manager.
• Falta de validación CSRF en llamadas AJAX.
• Comprobaciones insuficientes de permisos.
• Validación incorrecta de rutas.
• Subidas inseguras de archivos.
• Redirecciones abiertas (Open Redirect).

Estas vulnerabilidades permiten que un atacante modifique configuraciones del sitio o inserte código JavaScript que posteriormente se ejecutará cuando un administrador acceda al panel de Joomla. (JoomShaper)

Lo primero: actualizar inmediatamente

Antes de limpiar el sitio es imprescindible instalar las versiones corregidas.

Descargas oficiales:

• Helix Ultimate Security Update
• Artículo oficial de JoomShaper sobre las vulnerabilidades

Si utilizas:

• Helix Ultimate
• Helix3
• SP Page Builder

deben actualizarse todos.

Actualizar únicamente SP Page Builder no elimina una posible explotación realizada mediante Helix Ultimate.