Einführung
In diesem Lab lernen Sie, wie Angreifer dauerhaften Zugriff aufrechterhalten und grundlegende Erkennungsmechanismen umgehen. Während automatisierte Frameworks wie Metasploit Meterpreter verwenden, um Payloads nahtlos in stabile Windows-Prozesse (wie explorer.exe oder svchost) zu migrieren, erfordern Linux-Umgebungen einen anderen Ansatz.
Das allgemeine Prinzip ist plattformunabhängig: Angreifer ziehen es vor, sich in langlebigen, unauffälligen Ausführungskontexten zu verstecken, anstatt in instabilen oder offensichtlich verdächtigen Prozessen.
Unter Linux erreichen Angreifer dieselben Evasionsziele, indem sie stabile Systemprozesse identifizieren und „Prozessnamen-Spoofing“ nutzen, um ihre Schadsoftware zu tarnen. Sie lernen, wie man laufende Prozesse analysiert, vertrauenswürdige Systemkomponenten identifiziert und eine Payload ausführt, die sich als legitimer Kernel-Thread ausgibt, um einer Entdeckung zu entgehen.
Dabei geht es sowohl um Stabilität als auch um die menschliche Wahrnehmung. Verteidiger, die große Prozesslisten durchsuchen, übersehen eher Namen, die sich in das erwartete Systemrauschen einfügen.
Laufende Prozesse anzeigen (ps)
In diesem Schritt lernen Sie, wie man laufende Prozesse auf einem Linux-System auflistet und analysiert. Angreifer nutzen diese Aufklärungsphase, um die Umgebung zu verstehen und legitime Prozesse zu finden, die sie imitieren können.
Auch hier steht die Aufzählung an erster Stelle. Sie können keinen glaubwürdigen Tarnprozess wählen, wenn Sie nicht wissen, wie „Normalität“ auf dem Host aussieht.
Der Befehl ps (process status) ist das Standardwerkzeug zur Anzeige aktiver Prozesse. Um einen umfassenden Überblick über alle auf dem System laufenden Prozesse zu erhalten, können Sie die aux-Flags verwenden.
Führen Sie den folgenden Befehl in Ihrem Terminal aus, um die laufenden Prozesse anzuzeigen:
ps aux | head -n 15
Das a-Flag zeigt Prozesse aller Benutzer an, u stellt das benutzerorientierte Format dar (einschließlich CPU- und Speicherauslastung), und x zeigt Prozesse an, die nicht an ein Terminal gebunden sind. Wir leiten die Ausgabe an head -n 15 weiter, um nur die ersten 15 Zeilen anzuzeigen und die Ausgabe übersichtlich zu halten.
Sie sollten eine Ausgabe sehen, die in etwa so aussieht:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 167008 11468 ? Ss 10:00 0:01 /sbin/init
root 2 0.0 0.0 0 0 ? S 10:00 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? I< 10:00 0:00 [rcu_gp]
root 4 0.0 0.0 0 0 ? I< 10:00 0:00 [rcu_par_gp]
root 5 0.0 0.0 0 0 ? I< 10:00 0:00 [slub_flushwq]
root 6 0.0 0.0 0 0 ? I< 10:00 0:00 [netns]
root 8 0.0 0.0 0 0 ? I< 10:00 0:00 [kworker/0:0H-events_highpri]
root 10 0.0 0.0 0 0 ? I< 10:00 0:00 [mm_percpu_wq]
root 11 0.0 0.0 0 0 ? S 10:00 0:00 [rcu_tasks_rude_]
root 12 0.0 0.0 0 0 ? S 10:00 0:00 [rcu_tasks_trace]
root 13 0.0 0.0 0 0 ? S 10:00 0:00 [ksoftirqd/0]
root 14 0.0 0.0 0 0 ? I 10:00 0:00 [rcu_sched]
root 15 0.0 0.0 0 0 ? S 10:00 0:00 [migration/0]
root 16 0.0 0.0 0 0 ? S 10:00 0:00 [idle_inject/0]
Beachten Sie die in eckigen Klammern eingeschlossenen Prozesse, wie [kthreadd] oder [kworker/0:0H-events_highpri]. Dies sind Kernel-Threads. Sie sind hochstabil, laufen kontinuierlich und werden von Systemadministratoren selten überprüft, was sie zu perfekten Kandidaten für eine Evasion macht.
Stabile Zielprozesse identifizieren
In diesem Schritt identifizieren Sie spezifische Prozesse, die sich ideal für die Evasion eignen. Ein stabiler Prozess ist in der Regel ein System-Daemon oder ein Desktop-Dienst, der automatisch startet und über lange Zeit läuft.
Wenn die Payload eines Angreifers abstürzt, verliert er den Zugriff. Indem er seine Payload als stabilen Prozess tarnt, vermeidet er Verdachtsmomente. In einigen Linux-Umgebungen sind kworker-Einträge leicht zu beobachten und bieten ein praktisches Namensmodell, da ihre Namen technisch klingen und sich gut in lange Prozesslisten einfügen.
Lassen Sie uns prüfen, ob diese Umgebung Namen im kworker-Stil anzeigt. Führen Sie den folgenden Befehl aus:
ps -ef | grep kworker | head -n 5
Das -e-Flag wählt alle Prozesse aus, und -f sorgt für eine vollständige Auflistung. Wir verwenden grep, um nur die Zeilen zu filtern, die „kworker“ enthalten.
Wenn die Umgebung Kernel-Worker-Einträge anzeigt, sehen Sie möglicherweise eine Ausgabe wie diese:
root 8 2 0 10:00 ? 00:00:00 [kworker/0:0H-events_highpri]
root 25 2 0 10:00 ? 00:00:00 [kworker/1:0H-events_highpri]
root 31 2 0 10:00 ? 00:00:00 [kworker/2:0H-events_highpri]
root 37 2 0 10:00 ? 00:00:00 [kworker/3:0H-events_highpri]
root 43 2 0 10:00 ? 00:00:00 [kworker/0:1-events]
Falls Sie nur den grep-Befehl sehen und keine echten kworker-Einträge, ist das für dieses Lab in Ordnung. Wir werden im nächsten Schritt dennoch das bekannte Namensschema [kworker/X:Y] verwenden, da das Ziel darin besteht, die Funktionsweise des Prozessnamen-Spoofings zu erlernen, und nicht davon abhängig zu sein, dass ein spezifischer Kernel-Thread sichtbar ist.
Migration zu einem stabilen Prozess
In diesem Schritt simulieren Sie eine Prozessmigration, indem Sie einen langlebigen Prozess starten und dessen Prozessnamen fälschen.
Eine Dummy-Payload namens malicious_payload.sh wurde für Sie in ~/project vorbereitet, aber es gibt ein wichtiges Linux-Detail: Wenn Sie ein Shell-Skript ausführen, zeigt die Prozessliste normalerweise den Interpreter an, wie etwa /bin/bash /home/labex/project/malicious_payload.sh. Dieses Verhalten macht es schwierig, den gefälschten Namen in dieser Umgebung klar zu beobachten.
Um das Spoofing leicht überprüfbar zu machen, verwenden wir stattdessen einen einfachen, langlebigen Befehl. Das Sicherheitskonzept bleibt dasselbe: Wir geben einem Prozess einen irreführenden, sichtbaren Namen, damit er sich in die Prozessliste einfügt.
Führen Sie den folgenden Befehl aus, um einen getarnten Hintergrundprozess zu starten:
bash -c 'exec -a "[kworker/u4:2]" sleep 600' &
Der Teil bash -c startet einen neuen Bash-Prozess und führt die darauf folgende Befehlszeichenfolge aus. exec -a "[kworker/u4:2]" ersetzt diesen Bash-Prozess durch sleep 600, weist das Betriebssystem jedoch an, den Prozessnamen als [kworker/u4:2] anzuzeigen. Der Befehl sleep 600 hält den Prozess lange genug am Leben, damit Sie ihn untersuchen können. Das abschließende & führt den Prozess im Hintergrund aus.
Sie erhalten eine kurze Ausgabe mit der Jobnummer und der Prozess-ID (PID), ähnlich wie:
[1] 1337
Ihr getarnter Prozess läuft nun im Hintergrund und sollte mit dem gefälschten Namen erscheinen.
Persistenz und Zugriff überprüfen
In diesem letzten Schritt überprüfen Sie, ob Ihr getarnter Prozess unter seiner gefälschten Identität sichtbar ist, und bereinigen ihn anschließend.
Suchen Sie nach dem gefälschten Namen, den Sie im vorherigen Schritt zugewiesen haben:
ps aux | grep "kworker/u4:2"
Sie sollten eine Ausgabe sehen, die in etwa so aussieht:
labex 1337 0.0 0.0 7008 1536 pts/0 S 10:15 0:00 [kworker/u4:2]
labex 1345 0.0 0.0 6480 2272 pts/0 S+ 10:16 0:00 grep --color=auto kworker/u4:2
In dieser Umgebung ist der getarnte Prozess nur eine Demonstration, die mit sleep erstellt wurde, kein echter Kernel-Worker. Der wichtige Punkt ist, dass der sichtbare Name in der Prozessliste nun wie eine vertrauenswürdige Systemkomponente aussieht.
Bereinigen Sie abschließend den Demonstrationsprozess, indem Sie die Befehlszeile beenden, die den gefälschten Namen enthält. Führen Sie dazu folgenden Befehl aus:
pkill -f "kworker/u4:2"
Sie können ps aux | grep "kworker/u4:2" noch einmal ausführen, um zu bestätigen, dass der getarnte Prozess erfolgreich beendet wurde.
Zusammenfassung
Herzlichen Glückwunsch! Sie haben das Lab zur Prozessmigration und Evasion erfolgreich abgeschlossen.
Sie haben gelernt, wie Angreifer laufende Prozesse analysieren, um stabile, vertrauenswürdige Systemkomponenten zu identifizieren. Sie haben zudem gelernt, wie man durch Prozessnamen-Spoofing (exec -a) eine Schadsoftware als legitimen Kernel-Thread tarnt und damit die Evasion-Techniken simuliert, die von fortgeschrittenen Frameworks wie Meterpreter verwendet werden. Abschließend haben Sie die Unauffälligkeit des gefälschten Prozesses überprüft und gelernt, wie man ihn ordnungsgemäß beendet. Diese Fähigkeiten sind entscheidend, um zu verstehen, wie sich persistente Bedrohungen in einer Linux-Umgebung verbergen.
