Permalink 5 min read Modified: 2020-10-12 (UPDATED)

malware forensic #Rootkit #Cryptominer #Monero #LKM #Kernel #Reptile #XMRig #Debian

Analyse eines Servers der mit Rootkit und Cryptominer infiziert wurde

Vor ein paar Tagen sollte ein älterer, bis dato ungenutzter, Server in Betrieb genommen werden, hierbei machten wir eine unerwartete Entdeckung: Ein unbekannter Prozess lastete alle verbauten CPUs bis zum Anschlag aus.

Da der Server noch nicht in das Produktionsnetzwerk überführt und somit auch nicht an das Monitoringsystem angeschlossen wurde, konnte das Problem über längere Zeit unerkannt bleiben.

Stellt sich natürlich die Frage, warum der Server in Betrieb war, obwohl er noch nicht seiner Bestimmung zugeführt wurde.

Eine schnelle, oberflächliche Analyse des veralteten Debian Systems ließ schnell auf unerlaubten Fremdzugriff schließen:

Die Bash-History des root Users wurde gelöscht
Ebenso die systemd-journal Datenbank
In der authorized_keys Datei von root befanden sich mehrere unbekannte öffentliche SSH Schlüssel
Der SSH Daemon erlaubte root Zugriff via Publickey (Debian Standardeinstellung)

Jedenfalls lief besagter, verdächtiger Prozess bereits seit ca. einer Woche mit root-Rechten und hatte 207 Stunden CPU-Zeit auf dem Buckel.

$ ps -efaux | grep fda61738f49879faa0ae7814

root  12298  23.1  8.4  ... /tmp/biscuit/fda61738f49879faa0ae7814 -B -a cryptonight -o xmr.omine.org:3000 -u 43nBNRzaaqn5nzdKaiDFFXTuW65AcE2ZXLjGajfg2P7pbVEYz1X3MajdigEEKss4JAMzzYcipf3EjUWp4mu9cXtyPLygb1W#fda61738f49879faa0ae7814 -v 0 -k --donate-level=1 --asm=auto -t 23

Interessant war die Tatsache, dass es den Ordner /tmp/biscuit, bzw. die ausgeführte Datei fda61738f49879faa0ae7814 nicht zu geben schien. Weder ls noch find konnten etwas anzeigen. Mit einem kurzen Blick in das proc Dateisystem, prüfte ich, ob es sich um eine Binärdatei oder ein Shellscript handelte das ausgeführt wurde:

$ sudo ls -l /proc/12298/exe

lrwxrwxrwx 1 root root 0 06.02.2019-01:18 /proc/12298/exe -> '/tmp/biscuit/fda61738f49879faa0ae7814'

Wäre es ein Script gewesen, hätte man hier einen Symlink zur ausführenden Shell gesehen. Es handelte sich also um eine native elf64-Binärdatei. Auch kann man sehen, dass die Datei nach Ausführung nicht gelöscht wurde, um im RAM zu verbleiben, ansonsten hätte der Kernel (deleted) angefügt.

Zur Sicherheit und zur späteren Analyse, versuchte ich schnell eine Kopie der Binärdatei zu erstellen, denn bei einem Reboot wäre alles in /tmp gelöscht worden. Zum Glück war dies, ebenso wie file ausgeführt auf den Dateipfad, problemlos möglich.

Blieb der Umstand, dass ls nicht korrekt funktionierte. Um zu überprüfen, ob Systemprogramme manipuliert wurden, verglich ich die relevanten MD5-Summen mit denen einer anderen Debian Installation. So zeigte sich, dass offenbar nichts an den Programmen verändert wurde.

Allerdings lassen die Tatsache, dass der Ordner in /tmp und die Binärdatei dennoch weitestgehend unsichtbar waren, darauf schließen, dass hier ein Rootkit installiert wurde, zweifelsfrei um die verdächtigen Dateien vor Entdeckung zu schützen.

Kleiner Spoiler an dieser Stelle: Das Rootkit war nicht korrekt konfiguriert. Es hat zwar fleissig den Ordner, bzw. Datei vor dem System versteckt, aber nicht den eigentlichen Prozess.

Analyse des Cryptominers

Eine weitere Analyse der Binärdatei ergab, dass Virustotal diese als Trojan.Linux.XMR-Miner!1.A988 (CLASSIC) erkennt und strings liefert die Bestätigung, dass es sich mit XMRig um einen Monero Cryptominer handelt - An für sich ein reguläres Programm zum Schürfen von XMR, solang es außerhalb des Kontextes betrachtet wird.

$ strings /tmp/exe | grep -i xmr

  XMRig 0.6.0

Eine Google-Suche nach der XMRig Version ergab folgende Quelle: https://github.com/xmrig/xmrig/releases?after=v0.6.0.

Schnell war die - zu diesem Zeitpunkt bereits deutlich veraltete Miner-Version - heruntergeladen und die MD5-Summen verglichen:

$ md5sum /tmp/exe ~/downloads/xmrig-0.6.0/xmrig

  ec26682235acca13fcc655851a91d4dd  /tmp/exe
  ec26682235acca13fcc655851a91d4dd  /home/ff0x/downloads/xmrig-0.6.0/xmrig

Unsere Schadsoftware war gefunden!

Blieb die Analyse der Parameter, mit denen der Miner gestartet wurde, doch zuerst beendete ich den Prozess auf dem gekapertem Server mit SIGKILL.

Verwendeter Parameter	Bedeutung
-B	Run the miner in the background
-a cryptonight	Mining algorithm
-o xmr.omine.org:3000	URL of mining server
-u 43…XtyPLygb1W#fda61738f4…	Wallet address (and parameter)
	for the mining pool
-v 0	Algorithm variation, 0 auto select
-k	Send keepalive packet for prevent timeout
–donate-level=1	Donate level, default 1%
–asm=auto	ASM optimizations
-t 23	Number of CPU threads

Eine Monero Wallet-Adresse besteht aus einem String mit 95 Hexadezimal-Zeichen. Da diese dem Mining-Pool (xmr.omine.org) übermittelt werden musste, dürfte sie also im Parameter für den Benutzernamen zu finden sein. Allerdings entsprach der Wert nicht direkt einer Monero-Wallet-Adresse. Ich nahm an, alles hinter der Raute markiert weitere Mining-Pool-spezifische Optionen:

$ echo -n '43nBNRzaaqn5nzdKaiDFFXTuW65AcE2ZXLjGajfg2P7pbVEYz1X3MajdigEEKss4JAMzzYcipf3EjUWp4mu9cXtyPLygb1W#fda61738f49879faa0ae7814' | cut -c 1-95

  43nBNRzaaqn5nzdKaiDFFXTuW65AcE2ZXLjGajfg2P7pbVEYz1X3MajdigEEKss4JAMzzYcipf3EjUWp4mu9cXtyPLygb1W

Mit Hilfe von xmr.llcoins.net validierte ich die Gültigkeit der Wallet-Adresse.

Kurz dachte ich, man könnte sich doch einfach die getätigten Transaktionen, Wallet-Guthaben oder anderweitige relevante Informationen zur Adresse anzeigen lassen, aber - wie sich herausstellte - ist dies mit Monero nicht möglich und meine Suche endete hier.

Warum gerade Monero/XMR?

XMR ist eine der wenigen Crypto-Währungen, die konzeptuell eher von starken CPUs als von GPUs profitiert und somit eher dafür prädestiniert ist das Mining auf gekaperten, unbeobachteten Servern zu betreiben.

Hier findet man aktuelle Benchmarks zu diesem Thema.

Analyse des Rootkits

Und so wandte ich mich dem installierten Rootkit zu. Ein Scan mit rkhunter ergab folgendes:

 [09:11:03] Warning: IntoXonia-NG Rootkit                     [ Warning ]
 [09:11:03]          Kernel symbol 'hide_module' found
 [09:11:03]

Das betagte Programm rkhunter funktioniert primär auf Basis von statischen Signaturen, hat aber auch eine sehr rudimentäre heuristische Suche integriert, die hier tatsächlich einen Treffer landete.

Jetzt wissen wir zwar, dass irgendein Kernelmodul das Symbol mit dem ominösem Namen hide_module verwendet, aber noch nicht welches genau.

Weitere Informationen zu Linux Kernelmodulen und zu -symbolen lassen sich unter ouah.org/LKM_HACKING im Kapitel 3. What is the Kernel-Symbol-Table finden.

Man kann recht leicht herausfinden welches Kernelmodul die Variable oder Funktion hide_module verwendet, indem man auf das /proc Dateisystem zurückgreift und wild in den geladenen Kernel Symbolen greppt:

$ sudo grep 'hide_module' /proc/kallsyms

  ffffffffc0886850 b hide_module [reptile]

Ist das Modul reptile geladen?

$ lsmod | grep reptile

   reptile                24576  0

Weitere Informationen über das Kernelmodul anzeigen:

$ modinfo reptile

  filename:       /lib/modules/4.9.0-8-amd64/kernel/drivers/PulseAudio/reptile/reptile.ko
  intree:         Y
  license:        GPL
  depends:
  retpoline:      Y
  vermagic:       4.9.0-8-amd64 SMP mod_unload modversions

Das Rootkit Modul lag also im regulären LKM-Verzeichnis des aktuellen Kernels allerdings “getarnt” als PulseAudio Treiber.

Weitere Informationen über die Modul-Datei lieferte uns file:

$ file /lib/modules/4.9.0-8-amd64/kernel/drivers/PulseAudio/reptile/reptile.ko

  /lib/modules/4.9.0-8-amd64/kernel/drivers/PulseAudio/reptile/reptile.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=39b6aa117909e6536ca50e956738ff6dc0775f07, not stripped

Mit strings ließen sich wieder ein paar interessante Details in der Binärdatei finden:

$ strings /lib/modules/4.9.0-8-amd64/kernel/drivers/PulseAudio/reptile/reptile.ko | grep -i reptile

  /tmp/Reptile/parasite_loader
  /tmp/Reptile/parasite_loader/encrypt
  /tmp/Reptile/parasite_loader
  /tmp/Reptile/parasite_loader/kmatryoshka.c
  /tmp/Reptile/parasite_loader/parasite_loader.mod.c

Zuletzt fand ich über eine Internetsuche nach den Stichwörtern “lkm rootkit reptile parasite loader” das Quellcodeverzeichnis des verwendeten Linux LKM Rootkit: github.com/f0rb1dd3n/Reptile. Es stellte sich heraus, dass es sich um ein bekanntes Rootkitframework handelt.

Fazit

Final halte ich fest, dass der Rootkitbausatz stümperhaft konfiguriert wurde und die verwendete Mining-Software völlig veraltet war.

Je nachdem wie über das weitere Vorgehen entschieden wird, darf ich ggf. analysieren wie die Schadsoftware auf den Server gekommen ist. Mehrere Möglichkeiten kommen hierfür bereits in Betracht.