VM auf Anzeichen von Manipulationen am Kernelspeicher prüfen

Auf dieser Seite werden Aufgaben beschrieben, mit denen Sie die Gültigkeit eines Rootkits im Kernelmodus aus Virtual Machine Threat Detection prüfen können. Rootkit-Ergebnisse im Kernelmodus weisen darauf hin, dass der Kernelspeicher einer VM möglicherweise durch Malware manipuliert wurde.

Wenn Sie von VM Threat Detection einen Rootkit-Befund im Kernel-Modus erhalten, empfehlen wir Ihnen, diese Linux-Befehle auf der betroffenen Compute Engine-Instanz auszuführen, um Ihr System auf Datenpunkte zu prüfen, die auf Anomalien hinweisen könnten, z. B. auf gehackte Systemaufrufe oder ausgeblendete Kernelmodule.

Alternativ können Sie das bereitgestellte Skript zur Datenerfassung auf der betroffenen VM ausführen. Das Script führt die auf dieser Seite beschriebenen Befehle aus.

Sofern nicht anders angegeben, bezieht sich jede Prüfaufgabe auf dieser Seite auf alle Rootkits im Kernelmodus.

In diesem Dokument wird Folgendes vorausgesetzt:

  • Sie führen die Aufgaben in diesem Dokument aus, nachdem Sie von VM Threat Detection eine Rootkit-Ergebnismeldung im Kernelmodus erhalten haben. Eine Liste der relevanten Kategorien von Ergebnissen finden Sie unter Ergebnisse zur Rootkit-Bedrohung im Kernelmodus.

  • Sie haben Grundkenntnisse zu Linux-Befehlszeilentools und dem Linux-Kernel.

VM Threat Detection

Virtual Machine Threat Detection ist ein integrierter Dienst von Security Command Center, der in den Enterprise- und Premium-Stufen verfügbar ist. Dieser Dienst scannt Compute Engine-Instanzen, um potenziell schädliche Anwendungen wie Kryptowährung-Mining-Software, Rootkits im Kernelmodus und Malware zu erkennen, die in manipulierten Cloud-Umgebungen ausgeführt werden.

VM Threat Detection ist Teil der Bedrohungserkennungs-Suite von Security Command Center und ergänzt die vorhandenen Funktionen von Event Threat Detection und Container Threat Detection.

Weitere Informationen zur VM Threat Detection finden Sie unter Virtual Machine Threat Detection – Übersicht. Informationen zum Ansehen der Details eines VM Threat Detection-Ergebnisses

Hinweise

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Aufrufen aller Ressourcen und Ergebnisse in Security Command Center und zum Verwalten der betroffenen Compute Engine-Instanz benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Betroffene VM ermitteln

  1. Details zum Ergebnis ansehen
  2. Klicken Sie im Abschnitt Betroffene Ressource im Feld Vollständiger Ressourcenname auf den Link. Die Detailansicht der betroffenen Compute Engine-Instanz wird in einem neuen Tab geöffnet.
  3. eine Verbindung zur Instanz herstellen Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Mit Linux-VMs verbinden.

Unerwartete Kernelmodule finden

Das Vorhandensein unerwarteter Module in einer VM kann darauf hinweisen, dass der Kernelspeicher der VM möglicherweise manipuliert wurde.

So finden Sie unerwartete Kernelmodule:

  1. Listet alle geladenen Kernelmodule in der VM auf:

    lsmod
cat /proc/modules

  2. Listen Sie die sysfs-Einträge für die geladenen und entladenen Module auf:

    ls -l /sys/module/

  3. Vergleichen Sie die Ergebnisse dieser Listen mit Listen anderer VMs im Projekt. Suchen Sie nach Modulen, die auf der betroffenen VM, aber nicht auf den anderen VMs angezeigt werden.

In syslog nach nicht im Stammbaum enthaltenen Modulen suchen

Anzeichen dafür, dass ein Out-of-Tree-Modul in einer VM geladen wurde, können darauf hinweisen, dass atypische Kernelmodule geladen wurden. Sie können im Kernel-Log-Puffer und in syslog-Nachrichten nachsehen, ob ein externes Modul geladen wurde. In den Logeinträgen wird ein Out-of-Tree-Modul als schädliche Auslastung gekennzeichnet.

Suchen Sie im Kernelprotokoll-Zwischenspeicher und in den syslog-Nachrichten nach Logeinträgen, die ungefähr so aussehen:

MODULE_NAME: loading out-of-tree module taints kernel.

  • Suchen Sie im Kernelprotokoll-Zwischenspeicher nach Logeinträgen, die auf die Anwesenheit von Out-of-Tree-Modulen hinweisen:

    sudo dmesg | grep out-of-tree

  • Suchen Sie in allen syslog-Nachrichten nach Logeinträgen, die auf die Anwesenheit von nicht zum Stamm gehörenden Modulen hinweisen:

    grep "out-of-tree" /var/log/syslog*

Livepatching prüfen

Livepatching in einer VM kann die Erkennung von VM Threat Detection beeinträchtigen und zu falsch positiven Ergebnissen führen.

So prüfen Sie, ob Livepatching aktiviert ist:

  1. Prüfen Sie syslog auf die Installation und Protokollierung des Livepatching-Moduls. Beim Live-Patching wird in der Regel der Kernelcode durch das Installieren von Kernelftrace-Patches geändert.

    sudo grep livepatch /var/log/syslog*

  2. Suchen Sie nach neuen Kernelmodulen, die für das Live-Patching installiert wurden (in der Regel mit dem Präfix livepatch):

    sudo lsmod | grep livepatch

  3. So suchen Sie nach Patchdateien:

    sudo ls -l /sys/kernel/livepatch

Informationen zum Livepatching finden Sie unter Livepatch in der Linux-Kernel-Dokumentation.

Prüfen Sie, ob in der VM weitere potenziell schädliche Aktivitäten erkannt wurden.

  1. Rufen Sie im Security Command Center die Details des VM Threat Detection-Ergebnisses auf, das Sie untersuchen.
  2. Klicken Sie im Bereich Betroffene Ressource im Feld Vollständiger Name der Ressource auf das Drop-down-Menü und dann auf Alle Ergebnisse mit diesem vollständigen Namen der Ressource einblenden. Die Ergebnisabfrage wird aktualisiert, sodass nur Ergebnisse für diese VM angezeigt werden.
  3. Prüfen Sie, ob es Hinweise auf potenzielle Kryptomining-Aktivitäten, Malware, ungewöhnliche IAM-Berechtigungen und andere Sicherheitsbedrohungen gibt.

Prüfen, ob Antivirensoftware einen False Positive verursacht

Antivirensoftware kann die Erkennung durch VM Threat Detection beeinträchtigen und zu falsch positiven Ergebnissen führen.

Alle laufenden Prozesse im System prüfen

Das Vorhandensein unerwarteter Prozesse kann darauf hinweisen, dass das Ergebnis der VM Threat Detection gültig ist und die VM manipuliert wurde.

  1. Listen Sie alle Prozesse auf, die auf der VM ausgeführt werden:

    ps -eAf

  2. Suchen Sie nach Debuggerprozessen wie gdb, strace und pstack, die Sie normalerweise nicht auf dieser VM ausführen. Debugger-Prozesse können andere Prozesse ausspionieren.

  3. Suchen Sie nach anderen verdächtigen Prozessen auf der VM.

Gebooteten Kernel prüfen

Prüfen Sie den gestarteten Kernel, um Ihren Linux-Kernel zu identifizieren:

cat /proc/version

Wenn der zurückgegebene Wert nicht der erwarteten Kernelversion entspricht, kann dies auf einen Hijacking-Angriff hindeuten, bei dem das kexec-Tool im Kernel ausgenutzt wird. Mit dem Tool kexec kann das System neu gestartet werden, um einen anderen Kernel zu verwenden.

Zusätzliche Aufgaben für Unexpected kernel code modification-Ergebnisse

Die Aufgaben in diesem Abschnitt beziehen sich auf die Suchkategorie Defense Evasion: Unexpected kernel code modification. Führen Sie die Aufgaben in den folgenden Abschnitten aus, um die Gültigkeit eines Ergebnisses in dieser Kategorie zu überprüfen.

In diesen Abschnitten können Sie feststellen, ob Ihre VM eine Debugger-API verwendet. Debugger-APIs können zu falsch-positiven Ergebnissen führen, da sie die Codebereiche des laufenden Kernels ändern können.

Im Allgemeinen generiert VM Threat Detection kein Ergebnis, wenn die Verwendung einer Debugger-API erkannt wird. Wenn Ihre VM jedoch eine Debugger-API verwendet, die VM Threat Detection nicht bekannt ist, kann es dennoch zu einem falsch positiven Ergebnis kommen.

Nach aktivierten Debug-Tracern suchen

Tracer – mit Ausnahme des nop-Tracers – können zu Änderungen am Kernelcode führen. Sie können die Erkennung durch VM Threat Detection beeinträchtigen und zu falsch-positiven Ergebnissen führen. Wenn VM Threat Detection Tracer erkennt, sendet es in der Regel kein Defense Evasion: Unexpected kernel code modification-Ergebnis.

So prüfen Sie, ob Debug-Tracer aktiviert sind:

  1. Verfügbare Tracer prüfen:

    cat /sys/kernel/debug/tracing/available_tracers

    Die Ausgabe sollte so aussehen:

    hwlat blk mmiotrace function_graph wakeup_dl wakeup_rt wakeup function nop

  2. Prüfen Sie den aktuellen Tracer:

    cat /sys/kernel/debug/tracing/current_tracer

    Das Ergebnis ist einer der verfügbaren Tracer, die im vorherigen Befehl zurückgegeben wurden.

  3. Prüfen Sie, ob die Verfolgung auf dem System aktiviert ist:

    cat /sys/kernel/debug/tracing/tracing_on

    Ein Wert von 1 gibt an, dass die Tracing-Funktion auf dem System aktiviert ist.

  4. Liste der CPUs, auf denen die Aufzeichnung aktiviert ist:

    cat /sys/kernel/debug/tracing/tracing_cpumask

  5. So rufen Sie die Trace-Details auf:

    cat /sys/kernel/debug/tracing/trace_stat/function*

    Die Ausgabe sollte so aussehen:

    Function       Hit    Time            Avg             s^2

Nach Debug-Tracer-Ereignissen suchen

Die Ereignisüberwachung im Kernel kann zu Änderungen am Kernelcode und zu falsch positiven Ergebnissen von VM Threat Detection führen. Viele Tools zur Fehlerbehebung und Leistungsüberwachung können das Ereignismonitoring automatisch aktivieren.

Führen Sie die folgenden Befehle aus, um zu prüfen, ob die Ereignisüberwachung aktiviert ist:

cat /sys/kernel/debug/tracing/events/enable

cat /sys/kernel/debug/tracing/events/*/enable

Wenn die Ausgabe 0 lautet, ist die Ereignisüberwachung deaktiviert. Wenn 1 ausgegeben wird, ist das Ereignismonitoring aktiviert.

Sie können die Ereignisüberwachung deaktivieren, um zu prüfen, ob VM Threat Detection dieselben Ergebnisse liefert. Wenn die Anzahl der Ergebnisse sinkt, kann das darauf hindeuten, dass einige der ursprünglichen Ergebnisse falsch-positiv waren.

Kprobes, eBPF-Regeln und Netfilter prüfen

Netfilter, kprobes und eBPF-Regeln können Codeänderungen auslösen, da sie Aufrufe an benutzerdefinierte Rückrufe auslösen. VM Threat Detection erkennt das Vorhandensein dieser Proben und ordnet sie geänderten Codeseiten zu, ohne zu berücksichtigen, welche davon zu Falschmeldungen führen können.

Führen Sie den folgenden Befehl aus, um nach Kprobes, eBPF-Regeln und Netfiltern zu suchen:

iptable -L
cat /sys/kernel/debug/kprobes/enabled
cat /sys/kernel/debug/kprobes/list
cat /sys/kernel/debug/kprobes/blacklist
cat /sys/kernel/debug/tracing/enabled_functions
sudo apt-get update && sudo apt-get install bpftrace
bpftrace -l
sudo apt install linux-tools-`uname -r`
bpftool prog

Frühzeitige Debug-Tracer prüfen

Frühe Debug-Tracer, die beim Starten aktiviert werden, können die Erkennung von VM-Bedrohungen beeinträchtigen und zu falsch positiven Ergebnissen führen.

Führen Sie den folgenden Befehl aus, um nach frühen Debug-Tracern zu suchen:

cat /proc/cmdline

Eine Liste möglicher Debugger-Tracer für den frühen Start finden Sie in der Linux-Kernel-Dokumentation unter Boot-Tracing.

Zusätzliche Aufgabe für Unexpected system call handler

Führen Sie diese Aufgabe aus, wenn Sie eine Defense Evasion: Unexpected system call handler-Ergebnismeldung erhalten.

Prüfen Sie Systemaufrufe und suchen Sie nach Anomalien bei ihrer Verwendung und bei den Aufrufern. Die Prüfprotokolle enthalten Informationen zum Aufrufprozess und zu den Argumenten für die Systemaufrufe. Sie können auch Überprüfungsaufgaben ausführen, um das erwartete Verhalten häufiger Systemaufrufe zu prüfen. Weitere Informationen finden Sie auf dieser Seite unter Beispielprüfung mit dem Diamorphine-Rootkit.

Zusätzliche Aufgabe für Unexpected interrupt handler

Führen Sie diese Aufgabe aus, wenn Sie eine Defense Evasion: Unexpected interrupt handler-Ergebnismeldung erhalten.

Listen Sie die Live-Unterbrechungsabarbeiter auf dem System auf und vergleichen Sie die Ergebnisse mit Informationen aus anderen ähnlichen VMs im Projekt. Unerwartete Unterbrechungs-Handler können darauf hinweisen, dass die VM manipuliert wurde.

Führen Sie den folgenden Befehl aus, um die laufenden Unterbrechungsabarbeiter aufzulisten:

cat /proc/interrupts

Die Ausgabe sollte so aussehen:

           CPU0       CPU1
  0:         44          0   IO-APIC   0-edge      timer
  1:          9          0   IO-APIC   1-edge      i8042
  4:      17493          0   IO-APIC   4-edge      ttyS0
  8:          0          0   IO-APIC   8-edge      rtc0
  9:          0          0   IO-APIC   9-fasteoi   acpi
 12:          0        152   IO-APIC  12-edge      i8042
 24:         16          0   PCI-MSI 81920-edge      virtio2-config
 25:          0      40194   PCI-MSI 81921-edge      virtio2-inflate
 26:      58528          0   PCI-MSI 81922-edge      virtio2-deflate
 27:          0     966356   PCI-MSI 81923-edge      virtio2-stats
 28:          0          0   PCI-MSI 49152-edge      virtio0-config
 29:          0          0   PCI-MSI 49153-edge      virtio0-control
 30:          0          0   PCI-MSI 49154-edge      virtio0-event
 31:          0     555807   PCI-MSI 49155-edge      virtio0-request
 32:          0          0   PCI-MSI 98304-edge      virtio3-config
 33:        184          0   PCI-MSI 98305-edge      virtio3-input
 34:          0          0   PCI-MSI 65536-edge      virtio1-config
 35:     556203          0   PCI-MSI 65537-edge      virtio1-input.0
 36:     552746          1   PCI-MSI 65538-edge      virtio1-output.0
 37:          1     426036   PCI-MSI 65539-edge      virtio1-input.1
 38:          0     408475   PCI-MSI 65540-edge      virtio1-output.1

Zusätzliche Aufgabe für Unexpected processes in runqueue

Führen Sie die folgenden Schritte aus, wenn Sie eine Defense Evasion: Unexpected processes in runqueue-Ergebnis erhalten. In diesem Abschnitt erfahren Sie, wie Sie zusätzliche Datenpunkte erfassen, um Ihre Ergebnisse zu untersuchen. Diese Datenpunkte weisen möglicherweise nicht direkt auf ein Malware-Problem hin.

In dieser Aufgabe sehen Sie sich die CPU-spezifische Scheduler-Warteschlange an. Auch wenn einige Prozesse nur kurzzeitig aktiv sind, können Sie das Verhalten der Planungswarteschlange mit den laufenden Prozessen pro CPU bewerten, um nach anormalem Verhalten zu suchen.

  1. Zeigt Details zur Zeit an, die jeder laufende Prozess pro CPU benötigt. So können Sie sehen, ob eine bestimmte CPU extrem ausgelastet ist. Sie können die Ergebnisse mit Unterbrechungen korrelieren, die von /proc/interrupts an die CPU angepinnt wurden.

    cat /proc/schedstat

    Weitere Informationen zu diesem Befehl finden Sie in der Linux-Kernel-Dokumentation unter Scheduler-Statistiken.

  2. Listet alle derzeit ausführbaren Aufgaben und Details zu Kontextwechseln für jede CPU auf.

    cat /proc/sched_debug

    Die Ausgabe sollte so aussehen:

    Sched Debug Version: v0.11, 5.4.0-1081-gke #87-Ubuntu
ktime                                   : 976187427.733850
sched_clk                               : 976101974.761097
cpu_clk                                 : 976101973.335113
jiffies                                 : 4538939132
sched_clock_stable()                    : 1

sysctl_sched
  .sysctl_sched_latency                    : 12.000000
  .sysctl_sched_min_granularity            : 1.500000
  .sysctl_sched_wakeup_granularity         : 2.000000
  .sysctl_sched_child_runs_first           : 0
  .sysctl_sched_features                   : 2059067
  .sysctl_sched_tunable_scaling            : 1 (logarithmic)

cpu#0, 2199.998 MHz
  .nr_running                    : 0
  .nr_switches                   : 16250401
  .nr_load_updates               : 0
  .nr_uninterruptible            : 12692
  .next_balance                  : 4538.939133
  .curr->pid                     : 0
  .clock                         : 976101971.732857
  .clock_task                    : 976101971.732857
  .avg_idle                      : 880408
  .max_idle_balance_cost         : 500000

runnable tasks:
 S           task   PID         tree-key  switches  prio     wait-time             sum-exec        sum-sleep
-----------------------------------------------------------------------------------------------------------
 S        systemd     1     51740.602172    326778   120         0.000000    165741.786097         0.000000 0 0 /init.scope
 S       kthreadd     2   1482297.917240      1361   120         0.000000       112.028205         0.000000 0 0 /
 I      rcu_sched    11   1482642.606136   1090339   120         0.000000     17958.156471         0.000000 0 0 /
 S        cpuhp/1    15       537.058588         8   120         0.000000         2.275927         0.000000 0 0 /
 S  idle_inject/1    16        -2.994953         3    49         0.000000         0.012780         0.000000 0 0 /
 S    migration/1    17         0.000000    245774     0         0.000000      5566.508869         0.000000 0 0 /
 S    ksoftirqd/1    18   1482595.656315     47766   120         0.000000      1235.099147         0.000000 0 0 /
 I   kworker/1:0H    20       536.961474         5   100         0.000000         0.043908         0.000000 0 0 /
 S      kdevtmpfs    21     11301.343465       177   120         0.000000         3.195291         0.000000 0 0 /
 I          netns    22         6.983329         2   100         0.000000         0.021870         0.000000 0 0 /
 Srcu_tasks_kthre    23        10.993528         2   120         0.000000         0.010200         0.000000 0 0 /
 S        kauditd    24   1482525.828948       319   120         0.000000        14.489652         0.000000 0 0 /

  3. Achten Sie auf Folgendes:

    • Namen laufender Prozesse.
    • Anzahl der Kontextwechsel pro CPU. Prüfen Sie, ob ein Prozess zu wenige oder zu viele CPU-Wechsel verursacht.
    • Aufgewendete CPU-Zeit (Zeit, in der die CPU nicht im Leerlauf war).

Beispielprüfung mit dem Diamorphine-Rootkit

In diesem Abschnitt wird die Prüfung einer VM mit dem Rootkit Diamorphine veranschaulicht. Diamorphine ist ein beliebtes ladbares Kernelmodul (LKM). Dieses Rootkit löst die folgenden Kategorien aus:

  • Defense Evasion: Unexpected system call handler
  • Defense Evasion: Unexpected kernel modules
  • Defense Evasion: Unexpected kernel read-only data modification

Weitere Informationen zu diesen Ergebniskategorien finden Sie unter Ergebnisse zur Bedrohung durch Rootkits im Kernelmodus.

Die durchgeführten Prüfschritte und die auf der VM beobachteten Symptome sind:

  1. In syslog nach allen geladenen Kernelmodulen suchen, die nicht zum Baum gehören.

    1. Suchen Sie im Kernelprotokoll-Zwischenspeicher:

      sudo dmesg | grep out-of-tree

      Ausgabe:

      diamorphine: loading out-of-tree module taints kernel.

    2. So suchen Sie in den syslog-Nachrichten:

      grep "out-of-tree" /var/log/syslog*

      Ausgabe:

      /var/log/syslog: diamorphine: loading out-of-tree module taints kernel.

  2. In syslog nach Fehlern bei der Modulüberprüfung suchen (nicht auf allen Linux-Distributionen verfügbar)

    1. Suchen Sie im Kernelprotokoll-Zwischenspeicher:

      sudo dmesg | grep "module verification failed"

      Ausgabe:

      diamorphine: module verification failed: signature and/or required key missing - tainting kernel

    2. So suchen Sie in den syslog-Nachrichten:

      sudo grep "module verification failed" /var/log/syslog*

      Ausgabe:

      /var/log/syslog: diamorphine: module verification failed: signature and/or required key missing - tainting kernel

  3. Prüfen Sie, ob das Modul für die Befehle /proc/modules und lsmod ausgeblendet ist.

    sudo grep diamorphine /proc/modules
sudo lsmod | grep diamorphine

    Es wurden keine Ergebnisse angezeigt.

  4. Prüfen Sie, ob das Modul einen Eintrag in sysfs hat.

    sudo cat /sys/module/diamorphine/coresize

    Ausgabe:

    16384

  5. Rufen Sie die Systemaufruftabelle für die Architektur ab:

    sudo ausyscall --dump

    Ausgabe:

    Using x86_64 syscall table:
0       read
1       write
2       open
3       close

    Prüfen Sie auf Anomalien bei Systemaufrufen wie kill und getdents, die in der Regel von Rootkits manipuliert werden.

  6. Prüfen Sie die Systemaufrufe und achten Sie auf ungewöhnliches Verhalten, um Manipulationen am Systemaufruf-Handler zu erkennen. Dieses Verhalten variiert je nach Systemaufruf.

    Ein Systemaufruf, der häufig gehackt wird, ist der kill-Aufruf. Sie können prüfen, ob der Systemaufruf kill umgangen wurde. Im folgenden Beispiel wurde der Systemaufruf kill geprüft.

    1. Installieren Sie auditd und beobachten Sie das Verhalten der VM ohne das Diamorphine-Rootkit:

      $ sudo apt-get update && sudo apt-get install auditd
$ # Add audit rules for specific system calls
$ sudo echo "-a exit,always -F arch=b64 -S kill -k audit_kill" >> /etc/audit/rules.d/audit.rules
$  sudo /etc/init.d/auditd restart
Restarting auditd (via systemctl): auditd.service.

$ # Behavior observed without rootkit
$ sleep 600 &
[1] 1119
$ sudo kill -9 1119
$ sudo ausearch -k audit_kill | grep -A 3 "pid=1119"
type=OBJ_PID msg=audit(1677517839.523:198): opid=1119 oauid=1001 ouid=0 oses=1 obj=unconfined ocomm="sleep"
type=SYSCALL msg=audit(1677517839.523:198): arch=c000003e syscall=62 success=yes exit=0 a0=45f a1=9 a2=0 a3=7f61c64b2ac0 items=0 ppid=1034 pid=1035 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts0 ses=1 comm="bash" exe="/usr/bin/bash" subj=unconfined key="audit_kill"
$ sleep 600 &
[1] 1087
$ sudo kill -31 1087
$ sudo ausearch -k audit_kill | grep -A 3 "pid=1087"
type=OBJ_PID msg=audit(1677517760.844:168): opid=1087 oauid=1001 ouid=0 oses=1 obj=unconfined ocomm="sleep"
type=SYSCALL msg=audit(1677517760.844:168): arch=c000003e syscall=62 success=yes exit=0 a0=43f a1=1f a2=0 a3=7f61c64b2ac0 items=0 ppid=1034 pid=1035 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0        ses=1 comm="bash" exe="/usr/bin/bash" subj=unconfined key="audit_kill"

      An diesem Punkt der Prüfung wurde das Diamorphine-Rootkit installiert. Die folgenden Schritte zeigen das Verhalten der VM nach der Installation des Rootkits.

    2. Prüfen Sie, ob nach der Installation des Diamorphine-Rootkits kein Eintrag im Audit-Log für das Signal mehr vorhanden ist:

      $ sudo ausearch -k audit_kill | grep -A 3 "pid=1158"
$ sleep 600 &
[2] 1167

    3. Prüfen Sie die Details im Audit-Logeintrag für das Signal. In diesem Beispiel wurde dieses Signal zwar nicht vollständig vom Rootkit manipuliert, aber es sind Informationen zum Aufrufprozess verfügbar.

      $ sudo kill -9 1167
$ sudo ausearch -k audit_kill | grep -A 3 "pid=1167"
type=OBJ_PID msg=audit(1677518008.586:237): opid=1167 oauid=1001 ouid=0 oses=1 obj=unconfined ocomm="sleep"
type=SYSCALL msg=audit(1677518008.586:237): arch=c000003e syscall=62 success=yes exit=0 a0=48f a1=9 a2=0 a3=7f61c64b2ac0 items=0 ppid=1034 pid=1035 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts0 ses=1 comm="bash" exe="/usr/bin/bash" subj=unconfined key="audit_kill"

Skript für die Datenerhebung debuggen

Das folgende Script führt viele der auf dieser Seite beschriebenen Aufgaben zur Fehlerbehebung aus. Sie können dieses Script im Modus sudo oder root ausführen. Das Script liest nur Debug-Informationen aus dem System.

$ cat kprot.sh
#!/bin/bash

echo "Boot command line"
cat /proc/cmdline
echo "=================================================="
echo "Loaded modules"
cat /proc/modules
echo "=================================================="
echo "Current tracer"
cat /sys/kernel/debug/tracing/current_tracer
echo "=================================================="
echo "Tracing event enable"
cat /sys/kernel/debug/tracing/events/enable
echo "=================================================="
echo "Tracing sub events enable"
for en in `find /sys/kernel/debug/tracing/events/*/enable`; do printf "\b$en\n"; cat $en; done
echo "=================================================="
echo "IP table rules"
iptables -L
echo "=================================================="
echo "Ftrace list"
cat /sys/kernel/debug/tracing/enabled_functions
echo "=================================================="
echo "Kprobes enabled"
cat /sys/kernel/debug/kprobes/enabled
echo "=================================================="
echo "Kprobes list"
cat /sys/kernel/debug/kprobes/list
echo "=================================================="
echo "Kprobes blocklist"
cat /sys/kernel/debug/kprobes/blacklist
echo "=================================================="
echo "BPF trace"
sudo apt update && sudo apt-get update && sudo apt-get install bpftrace
bpftrace -l
echo "=================================================="
echo "BPF prog list"
sudo apt update && sudo apt install linux-tools-`uname -r`
bpftool prog
echo "=================================================="

Nächste Schritte