XMRIG - Mining Malware / Trojaner

[MementoX]

Hi zusammen,
hoffe ihr könnt mir helfen. Wäre wichtig und dringend.
Webserver - Debian 11.8

Konnte gestern Abend eine höhere CPU Auslastung feststellen.
Das ganze ging von einem User-Account aus. Offenbar lagen dort kompromittierte PHP Dateien.
CHMOD 000 die Lese/Schreibzugriffe entzogen.

ClamAV nochmal drüber laufen lassen.

Code: Alles auswählen

------------ INFECTIONS ------------
/tmp/.tmp/xmrig-6.20.0-linux-static-x64.tar.gz: Unix.Trojan.Generic-9919438-0 FOUND
/tmp/.tmp/xmrig-6.20.0/xmrig: Unix.Trojan.Generic-9919438-0 FOUND

Nach meiner Recherche ist XMRIG eine Krypto-Mining Geschichte - also will ein Hacker wohl den Server als Mining missbrauchen.

Habe in den /tmp/ im Useraccount und im allgemeinen /tmp/ am Server eine exploit1 Datei gefunden wo die gepackte xmrig und entpackte Dateien waren.
Alles mal entfernt, was nicht ClamAV schon in Quarantäne geworfen hat.

Den User auch mal komplett gesperrt übers Webpanel.
Hatte den Prozess etliche male beendet - es startete der Prozess aber immer wieder nach einer Zeit.

Es war unter /var/spool/ ein Cronjob für den User angelegt und dort war das hinterlegt, dass sich das Script immer wieder runterlädt.
War dann stets unter /tmp/.tmp entpackt u. startet den Prozess.

Habe den Cron gelöscht und gestern war dann nichts mehr.

Heute musste ich feststellen, dass der XMRIG Prozess wieder am laufen war (ausgehend von diesem User als Besitzer)
Finde aber nichts mehr.. auch kein Cronjob ob unter /var/spool/ oder /etc/cron.d usw.

Code: Alles auswählen

./xmrig -o drsql.ooguy.com:443 --user shell --cpu-max-threads-hint 20

Der User hat kein Shell Zugriff - aktuell überhaupt kein Zugriff mehr. Gibt auch sonst kein Fremdzugriff.
Irgendwo im System muss sich das noch rein geschrieben haben !?
Verstehe also nicht, wie der Prozess von dem User ausgehen kann.

Wo und wie kann ich das finden noch finden ?

rkhunter findet nichts außer 2 Warnungen, sagt aber am Ende 1 mögliche Rootkit - die für mich eher nach false-positiv aussehen.
Oder hat sich das in den RAM geschrieben ?

Code: Alles auswählen

Checking for suspicious (large) shared memory segments [ Warnung ]
Überprüfung ob Zugang des Root-Kontos mittels SSH erlaubt ist [ Warnung ]

chrootkit findet gar nichts


Brauche dringend Unterstützung.

[MSfree]

Zusätzlich zum cron könnte sich das Ding auch als Service- oder Timer-Unit in systemd eingetragen haben.

[MementoX]

Ich bin kein Linux Experte, kannst mir ein wenig helfen wie ich das am besten dort ausfindig mache ?
Oder hat sich das in den RAM geschrieben, wenn das die Warnung beim rkhunter bedeutet ?

Hab da gestern was wg. systemd gefunden u. xmrig service etc. damit stoppen wollen, aber sagt es existiert gar nicht.
Aber da kenne ich mich zuwenig aus.

auf FB sagte jemand, man sollte auch /proc durchsuchen ob da was läuft... wie check ich das am besten?


Blöderweise habe ich den Cron auch zackig gelöscht, statt eine kopie behalten mit dem Inhalt - hätte vl. etwas geholfen.


Momentan ist auch seit 1 Std. ruhe als ich den Prozess heute das erste mal wieder beendet habe.
Lasse gerade ClamAV nochmal laufen.

[rodney]

Eine unpopulaere Antwort: Setz die Kiste neu auf - spart Zeit und bringt Gewissheit dass die Kiste wieder sauber ist. Alles andere ist IMHO russisches Roulette

[MementoX]

Das ist nicht ohne weiteres möglich und nicht die Lösung.

Also zurück zur sinnvollen Solutions.


Hab mal systemctl status angesehen, da sehe ich nichts, falls das gemeint war.

Aber aktuell läuft ja auch kein Dienst mehr.
Will es nicht verschreien, aber vl. war es auch ein Überbleibsel von gestern - seit beenden des Prozess heute hat es sich nicht nochmal gestartet.

Datei gesucht unter /proc/
Verzeichnis wird nicht mehr gefunden, aber schlug wohl auf "xmrig" oder "exploitl" an.
Also war das wohl auch dort, und soweit ich weiß ist das der RAM oder Schnittstelle zu Kernel/Hardware ?

Wie sollte/kann ich das System weiter durchsuchen ?


[update]
Die rkhunter warnungen sind wie vermutet wohl eher zu vernachlässigen bzw. false-positiv
selbes kommt bei anderen server.

[update2 - 21:00uhr]

so... sieht weiterhin gut aus u. war wohl noch im Ram vermute ich.

[uname]

Vielleicht war das alles ja gar kein Schadcode. XMRIG scheint eher eine Windows-Software zu sein. Mich würde interessieren, was der Webbenutzer überhaupt durfte bzw. an Webanwendungen installiert hat. Vielleicht hat er ja die Dateien hochgeladen und sie lagen noch im /tmp-Ordner rum. Gehörten die Dateien wirklich dem Benutzer oder dem Webserver-Benutzer. Oder verwaltest du unterschiedliche Webserver-Benutzer?

[MSfree]

Vielleicht war das alles ja gar kein Schadcode. XMRIG scheint eher eine Windows-Software zu sein.

xmrig ist ein ganz offizieller Miner, den es für alle Betriebssysteme gibt. Schadcode ist das also zunächst nicht.

Problematisch ist nur, daß ein Unbefugter sich Zugang zu dem Server verschafft hat und den Rechner zum Mnen in seinem Namen mißbraucht, ohne die Serverkosten und/oder den Energisverbraauch dafür zu bezahlen.

[uname]

@MSfree
Naja ich bringe XMRIG und PHP noch nicht wirklich zusammen. Es gibt zwar ein XMRig-Frontend. Aber Mining mit PHP? Dann müsste man wohl aus PHP ausbrechen und z. B. Shellbefehle ausführen können, damit es sich alleine von der Performance lohnt sofern es überhaupt möglich ist.

@MementoX
Wie geschrieben wäre die Konfiguration und die Webanwendungen interessant. Vielleicht solltest du den Anwender einfach mal fragen was er gemacht hat.

[MSfree]

Naja ich bringe XMRIG und PHP noch nicht wirklich zusammen.

Vermutlich wurde eine angreifbare PHP-Version genutzt, um sich Benutzerrechte auf einer Shell zu beschaffen. xmrig selbst ist jedenfalls nicht in PHP geschrieben.

[uname]

Ok ich habe noch mal geschaut. Scheinbar wurde die Version von hier genutzt. Der Unterordner .tmp innerhalb von /tmp könnte ein Zeichen sein, dass jemand was verstecken wollte. Somit stimme ich allen Tipps von oben zu: plattmachen.

Code: Alles auswählen

/tmp/.tmp/xmrig-6.20.0-linux-static-x64.tar.gz: Unix.Trojan.Generic-9919438-0 FOUND
/tmp/.tmp/xmrig-6.20.0/xmrig: Unix.Trojan.Generic-9919438-0 FOUND

Der genutzte Anwender kann aber auch ein Ablenkungsmanöver sein. Vielleicht hat der Angreifer das System ganz anders gehackt und die Rechte auf den Benutzer angepasst. Die Software läuft wohl mit beliebigen Benutzern.

[TRex]

Das ist nicht ohne weiteres möglich und nicht die Lösung.

Also zurück zur sinnvollen Solutions.

Unpopuläre Antwort #2: du kennst dich nicht besonders gut mit dem System aus und kannst es dir nicht leisten, das System neu aufzusetzen? Zusammen mit dem Risiko, dass derjenige, der dir das untergejubelt hat, sich besser als du auskennen wird, könnte er auch besser Verstecken spielen. rodney hat nicht unrecht. Dein Risiko - wenn das System wichtig ist...

[reox]

Wenn man das forensisch sauber aufklären wollen würde, hätte man, direkt nachdem man den Einbruch entdeckt hat die Kiste runtergefahren und ein Diskimage gezogen (Ok idealerweise auch ein Image vom RAM aber das ist halt schwerer wenn es nicht gerade eine VM ist).
Danach kann man nämlich zwei Dinge tun:
1) Die kompromittierte Kiste clean aufsetzen
2) Vom Diskimage her in Ruhe schauen was passiert ist.

Zum aktuellen Zeitpunkt ist alles nur Rätselraten. Evt haben die Angreifer eine php remote shell installiert. Evt haben sie sogar ihren Zugang erweitert und noch einen weiteren User angelegt oder sogar schon root Rechte...
Vor vielen Jahren wurde ich mal zu Rate gerufen: Auf dem Webserver lief eine ungepatchte Version eines CMS. Darüber haben die Angreifer eine PHP remote shell hochgeladen. Über diese Shell hatten sie dann Zugang zum Hosting Rechner und konnten beliebige Dateien (mit Rechten des PHP Nuzters) ändern und hochladen. Sie haben es zwar nicht geschafft einen Systemuser zu kapern, aber dennoch Schaden angerichtet.

[MementoX]

XMRIG ist keine Malware an sich, korrekt.
Wird aber gern dafür missbraucht, um die Serverleistung fürs Mining zu nutzen.

Ja, ist ein Multi-User System.
Es kam von kompromittierten Dateien in der Userumgebung, die legten ein Cron an und damit wurde das Script geladen und gestartet.

Nein, es gibt weder einen anderen Hack zu verzeichnen, noch ist das System sonst kontaminiert.
Kann das eigentlich denke mal ausschließen - sonst auch keinerlei Fremdzugriffe od. Root-Access etc.

Bzgl. PHP Version, falls die Lücke in 7.4. dann wäre es möglich - da diese auf dem Account lief.
Aber sieht einfach nach "Phishing" bzw. Fremdzugriff auf den User FTP aus u. da wurde das abgelegt u. von dort aus der Cron angelegt.

Es ist wieder alles ruhig und nicht mehr auffällig.


btw:
Neu aufsetzen ist immer die 0815 Antwort, das ist kein korrekter Lösungsansatz.
Wie gesagt, wenn man Gegebenheiten nicht kennt bzw. den Aufwand sonst dahinter etc. kann man solch Aussagen leicht tätigen und spekulieren.

Das ist eine Worstcase Lösung, wenn wirklich das System kontaminiert wäre - das muss man dann Abschätzen.
Und auch dann wäre kein Neuaufsetzen sondern in erster Linie Backup-Restore der erste Ansatz.

[uname]

Aber sieht einfach nach "Phishing" bzw. Fremdzugriff auf den User FTP aus u. da wurde das abgelegt u. von dort aus der Cron angelegt.

Ja das ist sehr wahrscheinlich. Über den Webservices des Anwenders wird wohl niemand den Cron-Befehl anlegen können und auch die Tmp-Dateien nicht ablegen können. Ich gehe davon aus, dass du die Benutzer auf dem System zusätzlich ordentlich gegenseitig absicherst.

Neu aufsetzen ist immer die 0815 Antwort, das ist kein korrekter Lösungsansatz.

Bei Schadcode ist es meistens der einzige Weg. Bei Windows ist das erste was Schadcode manipuliert der Virenscanner. Beim größten Schadcode Emotet war ein sehr großes Problem, dass selbst große Virenscanner ihn ein paar Tage lang nicht erkannt haben und danach dann auch nicht mehr.

bzw. den Aufwand sonst dahinter etc. kann man solch Aussagen leicht tätigen und spekulieren.

Stell dir vor die Hardware und/oder Software raucht vollständig ab. Bewerte für diesen Fall, ob der Aufwand auch zu hoch ist bzw. dein SLA gegenüber deinen Kunden eingehalten werden kann. Das ist nur eine theretische Überlegung, die dir nicht viel Aufwand kostet. Die Überlegung, nicht der Restore.

Und auch dann wäre kein Neuaufsetzen sondern in erster Linie Backup-Restore der erste Ansatz.

Ja. Restore des Backups von vor dem Vorfall. Nutz den Vorfall um auch gleich deine Backup-Strategie zu prüfen. Wären ausreichende Backups verfügbar?

[MementoX]

Ja, alles soweit logisch.

Dennoch, ich bin auch bei Windows derjenige u. da bin ich Sattelfester, der nicht immer gleich neu aufgesetzt hat, sondern manuell die Malware/Trojaner/Viren entfernt hat.
Natürlich kann der Aufwand hoch werden. Wenn's wirklich komplett verseucht ist u. sinnlos, wird natürlich das System frisch aufgesetzt.

Wie gesagt, muss man abschätzen.
Hier wäre das in dem Fall übertrieben gewesen, bin mir relativ sicher das alles in Ordnung und mehrmals geprüft soweit ich das konnte.

Die User an sich sind natürlich auch eingeschränkt, keiner hat Shell etc.
Aber wenn ein Cronjob für diesen Nutzer läuft, spielen die PHP Beschränkungen keine Rolle mehr, da zählen dann nur die System-Benutzer Beschränkungen, und /tmp/ ist natürlich offen für alles.

Klar gibts verschlüsselte Backups regelmäßig vom Full-System + User Umgebungen.

Aber das sind wieder alles andere Thematiken.

Ging mir hier wirklich nur um schnelle Aushilfe, wer mag und kann.
Das Problem wird sich aber wohl erledigt haben. Thx.

[uname]

Dennoch, ich bin auch bei Windows derjenige u. da bin ich Sattelfester, der nicht immer gleich neu aufgesetzt hat, sondern manuell die Malware/Trojaner/Viren entfernt hat.

Vor einigen Jahren habe ich eine Zeit lang im https://www.trojaner-board.de gelesen. Ich habe mich aber immer gefragt, ob eine Software zum Finden von Schadcode auf einem verseuchten System wirklich alles finden kann. Hat mich ein wenig an den Film Die Truman Show erinnert. Kann man in einer Simulation erkennen, dass man in einer Simulation ist oder muss man auf den Scheinwerfer hoffen, der von der Decke fällt (Auszug Film)?

[reox]

Wie gesagt, wenn man Gegebenheiten nicht kennt bzw. den Aufwand sonst dahinter etc. kann man solch Aussagen leicht tätigen und spekulieren.

Das sowieso. Und der einzige der in diesem Thread alle Karten sieht bist auch nun mal du. Ich kann nur in die Glaskugel schauen...

Ich denke mir halt, dass ohne den genauen "Tathergang" rekonstruieren zu können, dein System einfach maximal kompromittiert sein könnte - eben genau wegen:

Kann man in einer Simulation erkennen, dass man in einer Simulation ist

[GregorS]

Wenn man das forensisch sauber aufklären wollen würde, hätte man, direkt nachdem man den Einbruch entdeckt hat die Kiste runtergefahren

Nein, man hätte den Stecker gezogen.

Gruß

Gregor