Entfernung eines Rootkits aus einem kompromittierten Linux-System
1. Ausgangslage: Auffällige Systemlast
Die Problematik begann mit einer ungewöhnlich hohen CPU-Auslastung, sichtbar in htop. Auffällig waren unzählige Prozesse namens -bash, welche nahezu 100% CPU verbrauchten. Ein klares Indiz für Schadsoftware.
2. Erste Analyse und Identifikation
Ich prüfte zunächst die Cron-Jobs und Systemdienste und fand ungewöhnliche Einträge:
/etc/cron.daily/jdsqhjkbwp
/etc/cron.hourly/jdsqhjkbwp
/etc/cron.weekly/jdsqhjkbwp
/etc/cron.monthly/jdsqhjkbwp
/etc/cron.d/jdsqhjkbwp
Zusätzlich tauchte ein verdächtiger Dienst mit zufälligem Namen auf:
okwbeyqxkq.service - jdsqhjkbwp
Eine nähere Untersuchung zeigte, dass diese Dateien unveränderlich waren (immutable gesetzt durch chattr +i).
3. Herausforderung: Selbstschutz der Malware
Versuche, die Dateien direkt als root zu entfernen, schlugen fehl:
rm: cannot remove '/etc/systemd/system/okwbeyqxkq.service': Operation not permitted
Dies deutete auf aktive Schutzmaßnahmen des Rootkits hin, entweder durch Kernel-Hooks oder modifizierte Systembibliotheken.
4. Lösung: Erstellung eines isolierten Chroot-Environments
Um das Rootkit zu umgehen, baute ich eine temporäre RAM-basierte Umgebung (Chroot). Dazu erstellte ich ein minimales Linux-System im RAM:
mkdir -p /tmp/killbox
mount -t tmpfs -o size=10M tmpfs /tmp/killbox
cp /bin/bash /tmp/killbox/sh
ldd /bin/bash # Analyse der benötigten Abhängigkeiten
# Kopieren der nötigen Bibliotheken nach /tmp/killbox
chroot /tmp/killbox /sh
Innerhalb dieser isolierten Umgebung waren die Rootkit-Hooks inaktiv.
5. Tiefere Prozessanalyse
Mittels gezielter Prozessanalysen konnte ich einen versteckten Prozess namens sgfs identifizieren, der sich selbständig erneut startete und Dateien wiederherstellte:
ps -eo pid,ppid,cmd --sort=start_time
kill -9 <PID>
Das gezielte Abschalten dieser Prozesse eliminierte die automatische Selbstreparatur des Rootkits.
6. Nachhaltige Entfernung und Prävention
Nach erfolgreicher Abschaltung des Rootkits entfernte ich sämtliche persistente Dateien:
chattr -i /etc/systemd/system/okwbeyqxkq.service
rm -f /etc/systemd/system/okwbeyqxkq.service
Um zukünftige Angriffe dieser Art zu verhindern, wurden Platzhalter-Dateien erstellt und vor Änderungen geschützt:
touch /etc/systemd/system/okwbeyqxkq.service
chmod 000 /etc/systemd/system/okwbeyqxkq.service
chattr +i /etc/systemd/system/okwbeyqxkq.service
7. Abschließende Validierung
Zur endgültigen Überprüfung erfolgte eine Validierung der Maßnahmen:
systemctl daemon-reexec
systemctl daemon-reload
systemctl reset-failed
Dabei stellte ich sicher, dass keinerlei schädliche Dienste oder Prozesse mehr aktiv waren.
Fazit und Empfehlungen
Meine Empfehlungen zur Absicherung:
Proaktives Monitoring mittels Audit- und Intrusion-Detection-Systemen
Regelmäßige Systemupdates und Sicherheits-Patches
Einsatz zusätzlicher Sicherheitsmaßnahmen wie SELinux, AppArmor oder Integritätsprüfungen mit Tripwire
Bei weiteren Fragen oder Sicherheitsvorfällen stehe ich gerne unterstützend zur Verfügung!