Kryptominer auf dem Server – Forensik und Bereinigung in 37 Minuten

Linux Server gehackt – so sieht echte Forensik aus: Ein kompromittierter Ubuntu-Server, 18 Monate unentdeckte Malware und eine vollständige Bereinigung in 37 Minuten.

Meldung vom Provider um 10:48, Auftrag um 13:04 in meiner Inbox: ausgehendes Portscanning von einem Server. Mehrfach, regelmäßig, in kurzen Abständen – zwischen 10:13 und 10:46 Uhr, jeweils auf wechselnde Adressen im Netz 198.51.100.0/24.

Hinweis: Alle Zeiten sind hier in UTC angegeben.

Erster Login: Was läuft hier?

Kommando:

root@webhost-03:~# ss -tnp

Ausgabe (Auszug):

SYN-SENT  0  1  203.0.113.42:43720  78.47.75.71:22222  users:(("kthreadadd64",pid=214999,fd=422))
# ↑ hunderte solcher Zeilen – ein einzelner Prozess baut massenhaft SSH-Verbindungen auf
ESTAB     0  0  203.0.113.42:48188  192.0.2.83:80  users:(("kswapd00",pid=206626,fd=13))
# ↑ etablierte Verbindung nach draußen – das ist die C2-Kommunikation des Miners¹

Zwei Prozesse, zwei Rollen. Der eine scannt, der andere kommuniziert nach draußen.

Kommando:

root@webhost-03:~# ps auxf

Ausgabe (Auszug):

ftptest  206626  92.9  30.3  307476 271168  07:50  463:45  ./kswapd00
# ↑ 92% CPU, läuft seit 07:50 Uhr – tarnt sich als Kernel-Thread, ist ein Kryptominer
ftptest  206644   0.0   0.1    2584   1756  07:50    0:00  /bin/sh ./go
# ↑ Orchestrierungsskript, startet den Scanner in 4-Stunden-Blöcken
ftptest  214999   4.9   2.7  101068  24168  16:04    0:15  /usr/sbin/httpd rsync/c/kthreadadd64 ...
# ↑ tarnt sich als httpd – ist der SSH-Scanner

Alle Prozesse laufen unter dem Benutzer ftptest.

Schlussfolgerung: Der Server ist aktiv kompromittiert. kswapd00 ist ein Kryptominer mit C2-Verbindung nach 192.0.2.83:80. kthreadadd64 ist ein SSH-Scanner – die direkte Ursache der Provider-Meldung. Das Skript go orchestriert beide.

Prozesse stoppen und Dateien sichern

Kommandos:

root@webhost-03:~# kill -9 206626 206644 214994 214995 214999
root@webhost-03:~# pkill -u ftptest

Kommando:

root@webhost-03:~# find /home/ftptest /tmp /var/tmp /dev/shm -type f -ls 2>/dev/null

Ausgabe (Auszug):

3289  2164  -rwxrwxrwx  1 ftptest ftptest  2213128 Mai 13 07:50  /home/ftptest/.configrc7/a/kswapd00
# ↑ Miner-Binary, 2,1 MB, heute Morgen kopiert
3292     4  -rwxrwxrwx  1 ftptest ftptest     1543 Mai 13 07:50  /home/ftptest/.configrc7/a/delsshd
# ↑ entfernt konkurrierende SSH-Backdoors anderer Angreifer
11813 1120  -rwxrwxrwx  1 ftptest ftptest  1145176 Mai 12 15:45  /tmp/.X26-unix/.rsync/c/kthreadadd64
# ↑ SSH-Scanner, 1,1 MB
3278  4400  -rw-r--r--  1 ftptest ftptest  4504609 Mai 13 07:49  /tmp/.X26-unix/dota3.tar.gz
# ↑ ursprüngliches Dropper-Archiv, 4,3 MB
5399  2164  -rwxr-xr-x  1 ftptest ftptest  2215212 Apr 21 08:51  /var/tmp/.kswapd00
# ↑ Backup-Kopie des Miners in /var/tmp

Zwei Malware-Nester:

/home/ftptest/.configrc7/ – Hauptinstallation mit Miner-Binary, Startskripten, Updater, TLS-Zertifikaten für die C2-Kommunikation und Persistenz-Konfiguration.

/tmp/.X26-unix/.rsync/ – operative Dateien: Scanner für 64- und 32-Bit, Orchestrierungsskript, gefälschtes aptitude-Skript, IP-Listen mit Scan-Zielen (je 724 KB), Dropper-Archiv.

Schlussfolgerung: Die Malware-Kampagne ist unter dem Fingerprint mdrfckr bekannt. Das Paket ist vollständig – Miner, Scanner, Updater, Persistenz, Konkurrenzkampf gegen andere Angreifer auf demselben System.²

Einstiegspunkt: Wie kam der Angreifer rein?

Kommando:

root@webhost-03:~# last ftptest

Ausgabe (Auszug):

ftptest  ftpd81754  dyn-kunde-49283.carrier-example.de  Thu Nov 21 09:28 - 09:29  (00:00)
ftptest  ftpd81550  dyn-kunde-49283.carrier-example.de  Thu Nov 21 09:26 - 09:26  (00:00)
# ↑ 17 Sessions in 25 Minuten vom selben Anschluss – das ist der Einbruch
ftptest  ftpd80308  dyn-kunde-49283.carrier-example.de  Thu Nov 21 09:04 - 09:07  (00:02)
wtmp begins Wed Nov 20 16:29:12 2024
# ↑ der Server existiert seit dem 20. November – der Einbruch kam am nächsten Tag

Der FTP-Dienst ProFTPD lief auf dem Server. Das Konto ftptest war mit einem einfachen Passwort versehen – angelegt für einen Test, nie entfernt. Der Einbruch liegt zu diesem Zeitpunkt knapp 18 Monate zurück.

Wie sich die Kampagne entwickelte

Die Timestamps der gefundenen Dateien erzählen eine Geschichte:

20. Novemer 2024 – wtmp beginns, hier wurde der Server vermutlich aufgebaut.
21. November 2024 – Ersteinbruch via FTP, Erstinstallation der Malware. Nur einen Tag später!
Dezember 2024 – erste Lock- und State-Dateien in /var/tmp
21. April 2026 – aktualisierte Miner-Binary in /var/tmp/.kswapd00
5./11. April 2026 – Updates der Startskripte
12. Mai 2026 – kthreadadd64 neu kompiliert, go-Skript aktualisiert
13. Mai 2026, 07:49 (UTC) – dota3.tar.gz abgelegt, Neuinstallation der gesamten Kampagne
13. Mai 2026, 07:50 (UTC) – alle Prozesse neu gestartet
13. Mai 2026, ab 10:13 (UTC) – Provider registriert Portscanning
13. Mai 2026, 10:48 (UTC) – Meldung des Providers beim Kunden
13. Mai 2026, 13:04 (UTC) – Auftrag bei Terruhn.IT
13. Mai 2026, 16:05 (UTC) – Erster Login, Forensik beginnt
13. Mai 2026, 16:42 (UTC) – Reboot, sauberer Zustand bestätigt
13. Mai 2026, 17:29 (UTC) – Fertig-Meldung für den Provider und detailierter Bericht an den Kunden versendet

Das ist kein Schlafmodus. Der Updater hat funktioniert, die Kampagne wurde über 18 Monate regelmäßig gepflegt – auf einem Server, den niemand im Blick hatte.

Persistenz-Mechanismus

Kommando:

root@webhost-03:~# cat /home/ftptest/.configrc7/cron.d

Ausgabe:

5 6 */2 * 0   /home/ftptest/.configrc7/a/upd>/dev/null 2>&1
# ↑ Miner-Update alle zwei Tage
@reboot        /home/ftptest/.configrc7/a/upd>/dev/null 2>&1
# ↑ und bei jedem Reboot
5 8 * * 0     /home/ftptest/.configrc7/b/sync>/dev/null 2>&1
@reboot        /home/ftptest/.configrc7/b/sync>/dev/null 2>&1
0 0 */3 * *   /tmp/.X26-unix/.rsync/c/aptitude>/dev/null 2>&1
# ↑ kein Paketmanager – ein Wrapper, der die Malware alle drei Tage neu startet

SSH-Backdoor

Kommando:

root@webhost-03:~# cat /home/ftptest/.ssh/authorized_keys

Ausgabe:

ssh-rsa AAAAB3Nz... mdrfckr
# ↑ "mdrfckr" ist der bekannte Fingerprint dieser Kampagne

Mit diesem Schlüssel hätte der Angreifer jederzeit wieder Zugang gehabt – unabhängig vom Passwort.

Kommando:

root@webhost-03:~# > /home/ftptest/.ssh/authorized_keys

Bereinigung

Kommandos:

root@webhost-03:~# rm -rf /home/ftptest/.configrc7
root@webhost-03:~# rm -rf /tmp/.X26-unix
root@webhost-03:~# rm -f /var/tmp/.kswapd00 /var/tmp/.systemcache436621
root@webhost-03:~# rm -f /var/tmp/sdfIESll923 /var/tmp/.sdfkLEucmtT /var/tmp/.SKEKKSPROSUTX
root@webhost-03:~# rm -f /dev/shm/.out
root@webhost-03:~# passwd -l ftptest
root@webhost-03:~# usermod -s /bin/false ftptest
root@webhost-03:~# systemctl stop proftpd
root@webhost-03:~# systemctl disable proftpd

Firewall härten

UFW war aktiv, aber ausgehender Traffic war unkontrolliert erlaubt.

Kommandos:

root@webhost-03:~# ufw default deny outgoing
root@webhost-03:~# ufw allow out 53/udp
root@webhost-03:~# ufw allow out 80/tcp
root@webhost-03:~# ufw allow out 443/tcp
root@webhost-03:~# ufw allow out 123/udp
root@webhost-03:~# ufw allow out 22/tcp
# ↑ SSH nach außen – ohne diese Zeile sperrt man sich selbst aus
root@webhost-03:~# ufw reload

Ausgabe:

Default outgoing policy changed to 'deny'
Rule added
Rule added (v6)
...
Firewall reloaded

Die Console-Episode

Beim ersten Entwurf der Firewall-Regeln fehlte ufw allow out 22/tcp. Nach dem Reboot:

ssh: connect to host 203.0.113.42 port 22: Connection refused
# ↑ selbst ausgesperrt

Der Ausweg: Konsolen-Zugang über den Provider, manuelles Eintippen eines 24 Zeichen langen Passworts aus dem Passwort-Manager – blind, ohne Korrekturmöglichkeit, auf einem US-Keyboard-Layout an einem deutschen Mac. Vier Versuche. Und für den Login beim Provider war ein Code aus einer Kunden-E-Mail nötig – also erst Telefonat, Erklärung, dann weiter.

Lesson learned: Vor jedem Reboot prüfen, ob der eigene SSH-Kanal in den Firewall-Regeln enthalten ist.

Reboot und Kontrolle

Kommando:

root@webhost-03:~# reboot

Nach dem Neustart:

Kommandos:

root@webhost-03:~# ps auxf | grep ftptest
root@webhost-03:~# ss -tnp | grep -v sshd
root@webhost-03:~# find /tmp /var/tmp /dev/shm -type f -ls 2>/dev/null

Ausgabe:

root  3405  0.0  0.2  3884  1836  pts/0  S+  grep ftptest
# ↑ nur der grep selbst – keine ftptest-Prozesse
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
# ↑ keine verdächtigen Verbindungen

Der Server ist sauber.

Wer hat hier eigentlich gearbeitet?

Ehrlichkeit gehört dazu: Diese Analyse hat nicht ein Mensch alleine durchgeführt. Der größte Teil der Kommandos, die Interpretation der Ausgaben, die Struktur der Bereinigung – das kam von Claude, meinem aktuellen KI-Assistenten von Anthropic.

Mein Teil war ein anderer. Ich habe validiert, ob die vorgeschlagenen Kommandos sinnvoll sind. Ich habe geprüft, ob etwas fehlt oder eine Gefahr darstellt. Ich habe beurteilt, ob das Gesamtbild plausibel ist.

Und genau dabei ist der Fehler passiert, der zur Console-Episode geführt hat. Als Claude die UFW-Regeln vorschlug, war mein erster Gedanke: da fehlt noch etwas. Ich hatte explizit gesagt, dass ich per SSH auf dem Server bin. Der Hinweis hat nicht gereicht – Claude hat ihn nicht in die Firewall-Konfiguration übersetzt. Und ich habe die Regeln trotzdem durchgewunken.

Das ist kein Vorwurf an die KI. Es ist eine Beschreibung davon, wie Mensch-KI-Zusammenarbeit in der Praxis funktioniert – und wo die Verantwortung liegt. Sie liegt beim Menschen. Noch.

Was folgte, war eine unfreiwillig komische Situation: Konsolen-Zugang über den Provider, ein Code aus einer Kunden-E-Mail, ein Telefonat, in dem ich erklären durfte, was ich da gerade gebaut hatte. Eine Gelegenheit, die Hosen runterzulassen. Und eine gute Übung in Gelassenheit.

Und das Ganze hat auch einen anderen Aspekt, der mich beschäftigt. Technisch kann eine KI solche Aufgaben vollständig autonom übernehmen – ohne dass ein Mensch jeden Schritt validiert. Und wenn ich diesen Gedanken weiterspinne: eine KI, die Zugriff auf Server hat, auf denen sie selbst läuft, die sie selbst verwaltet – das ist eine Entwicklung, über die es sich lohnt, ernsthaft nachzudenken. Nicht aus Angst, sondern weil die Fragen, die dabei entstehen, real sind.

Heute war der Mensch noch dabei. Und das war gut so.

Was bleibt

Von erstem Login bis sauberem Reboot: 37 Minuten. Inklusive Console-Episode und Kundentelefonat.

Ein vergessener FTP-Account, ein schwaches Passwort, ein Server, den niemand im Blick hatte. 18 Monate.

Abrechnung

Zur Transparenz: Dieser Einsatz wird minutengenau abgerechnet. Alle Zeiten in Europe/Berlin.

Die aktive Forensik-Zeit von 18:05 bis 18:42 Uhr – 37 Minuten Forensik, vollständige Bereinigung, Härtung – zum Notfall-Stundensatz von derzeit 324€ netto ergibt 199,80€. Die anschließende Dokumentation und der Bericht für den Provider, fertiggestellt um 19:29 Uhr – 47 Minuten – zum regulären Durchschnitts-Stundensatz von derzeit 95€ netto ergibt 74,42€.

Gesamtrechnung: 274,22 € netto. Finde ich fair, oder?

Und es hat eine Menge Spass gemacht:-)

Legende

Alle im Text verwendeten IP-Adressen und Hostnamen sind anonymisiert. Die technischen Abläufe sind authentisch dokumentiert. Alle Zeiten in UTC, sofern nicht anders angegeben.

Platzhalter	Bedeutung
`203.0.113.42`	IP-Adresse des betroffenen Servers
`198.51.100.0/24`	Vom Provider gemeldetes Scan-Ziel
`192.0.2.83`	C2-Server des Angreifers
`dyn-kunde-49283.carrier-example.de`	Hostname des Angreifers (dynamischer Residential-Anschluss)
`webhost-03`	Hostname des betroffenen Servers

Die IP-Bereiche 203.0.113.0/24, 198.51.100.0/24 und 192.0.2.0/24 sind gemäß RFC 5737 offiziell für Dokumentationszwecke reserviert und im Internet nicht geroutet.

C2: Command-and-Control-Kommunikation. Der infizierte Server meldet sich dabei regelmäßig bei einem Server des Angreifers, empfängt Befehle und schickt Status zurück – zum Beispiel wie viel Kryptowährung bereits geschürft wurde. ↩︎
https://securelist.com/outlaw-botnet/116444/ (abgefragt am 14. Mai 2026) ↩︎

Zuletzt aktualisiert am 14. Mai 2026.