[Help]QNAP hijack - Bitcoin Miner

Sers,

hab grad folgende News online gelesen

klick

und bin natürlich prompt davon betroffen.
Wie ich mir den eingefangen habe ist mir ein Rätsel (kenn mich scheinbar doch nicht so aus, wie es sein sollte).
Punkt ist, dass ich es nicht schaffe den Prozess zu killen. (sudo kill 588)
Die Anleitung im Link hilft genau nix. Neustart bringt nix. Malware checker sagt - alles leiwand.

System immer alles up2date
443 hatte ich in Verwendung - nun geändert
admin account deaktiviert (war aktiv aber nicht in Verwendung)
der oom_reaper Prozess läuft als admin

any Tipps?

Falls möglich die Platten raus (Achtung bei Hersteller spezifischen raid configs), NAS reset und Platten wieder einbinden. Birgt halt ein Risiko. Wenn es heikel ist mal abschalten und neues NAS aufbauen und dann gezielt übersiedeln.
Ansonsten vipers Vorschlag wenn ein Backup der Daten existiert.

Backup erstellen?
Das ist jetzt zu spät.

ich würd mir halt rein die Daten ziehen.
nas ist ein 672N. also nix kleines.

edit: der qnap ressourcenmonitor sagt, dass der task im Ruhemodus ist und 0% CPU verwendet
edit2: am backup nas ist exakt dasselbe

Unter Linux kann sich jeder Prozess den Namen geben, den er (bzw. der Programmierer der Anwendung, aus der der Prozess enstanden ist) moechte. Es gibt typischerweise einen Kernel-Thread, der "oom_reaper" benannt ist, und dafuer zustaendig ist, in Low Memory Conditions so lange andere Prozesse zu erschieszen, bis es dem System wieder besser geht. Falls ihr also nur so in die Prozesstabelle schaut, und dort was mit diesem Namen seht, ist das nicht unbedingt ein Hinweis auf Kompromittierung.

Afaik haben alle Kernel-Threads eine Parent Process ID (PPID) von 2, weil sie von kthreadd erzeugt werden. So sollte man also zweifelsfrei feststellen koennen, ob man es mit dem Kernel Thread oom_reaper, oder der Malware, die diesen Namen traegt (du hast ab dieser Zeile DJ Oetzi im Ohr!), zu tun hat.

Kann man z. B. so rausfinden:

Code:

pgrep oom_reaper | xargs ps -fp
UID          PID    PPID  C STIME TTY          TIME CMD
root          27       2  0 Oct09 ?        00:00:00 [oom_reaper]

Nachdem hier in der PPID-Column 2 zu lesen ist (und `ps` den Namen in eckige Klammern setzt - aber das ist nur ein visueller Hint, auf den man sich hier nicht verlassen kann!) handelt es sich mit an Sicherheit grenzender Wahrscheinlichkeit nicht um diese fiese Malware auf meinem Debian-Host

Also ein guter Zeitpunkt, um ein wertiges Backup zu erstellen .

Zitat aus einem Post von Captain Kirk

@Zaro: du hast Recht. Ich hab zwar das mit PID größer 1000 hab ich zwar gelesen aber das "usually" war da mE nicht eindeutig.

Ist es auch nicht - ob die PID ueber oder unter 1000 liegt ist sicher kein eindeutiger Indikator fuer Malware oder nicht Malware. PIDs haben auf vielen Konfigurationen keinen atemberauben groszen Wertebereich, die rotieren auf Systemen mit langer Uptime und/oder starker Fork-Aktivitaet auch mal komplett durch, und Schwupps hat dein Malware-faux-oom_killer eine PID < 1000.


Die CLI-Wurscht versucht festzustellen, ob ein Prozess namens oom_reaper offen Netzwerkverbindungen hat, such sich dann die Executable zur verantwortlichen PID aus/via profcs und schiebt die an einen anderen Ort, iteriert dann ueber alle Prozesse in der Prozesstabelle, die INET-Sockets offen/ESTABLISHED haben und versucht fuer diese PIDs/Executables quasi-heuristisch festzustellen, ob sie auch die Malware sind (die wurde evtl. mit UPX gepackt?). Diese Prozesse werden dann auch gekillt und ihre Executables verschoben. Am Ende verwurstet man noch die Crontab des Systems, um (vmtl.) den Vektor im System zu erschlagen, mit dem sich die Malware selbst wieder deployed/startet.

Ich find's uebrigens generell keine gute Idee, so eine Wurscht in seine Shell zu pappen, ohne halbwegs zu verstehen, was man da EIGENTLICH tut.

Colo glänzt wieder mit ausgezeichneten Erklärungen. Besten Dank, ich habe etwas gelernt!