Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

VM auf Anzeichen von Manipulationen am Kernel-Speicher prüfen

Auf dieser Seite werden Aufgaben beschrieben, die Sie ausführen können, um die Gültigkeit eines Ergebnisses zu einem Rootkit im Kernel-Modus zu bestätigen von Virtual Machine Threat Detection. Ergebnisse zu Rootkits im Kernel-Modus weisen darauf hin, dass der Kernelspeicher einer VM möglicherweise durch Malware manipuliert wurde.

Wenn Sie ein Ergebnis zu einem Rootkit im Kernel-Modus von VM Threat Detection erhalten, empfehlen wir Ihnen, diese Linux-Befehle auf der betroffenen Compute Engine-Instanz auszuführen, um Ihr System nach Datenpunkten zu durchsuchen, die auf Anomalien hinweisen könnten, z. B. entführte Systemaufrufe oder verborgene Kernelmodule.

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

Sofern nicht anders angegeben, ist jede Prüfaufgabe auf dieser Seite für alle Ergebnisse zu Rootkits im Kernel-Modus relevant.

In diesem Dokument wird Folgendes vorausgesetzt:

Sie führen die Aufgaben in diesem Dokument aus, nachdem Sie ein Ergebnis zu einem Rootkit im Kernel-Modus von VM Threat Detection erhalten haben. Eine Liste der relevanten Ergebnis kategorien finden Sie unter Ergebnisse zu Bedrohungen durch Rootkits im Kernel-Modus finden.
Sie haben Kenntnisse über Linux-Befehlszeilentools und den Linux-Kernel.

Informationen zu VM Threat Detection

Virtual Machine Threat Detection ist ein integrierter Dienst von Security Command Center. Dieser Dienst scannt virtuelle Maschinen, um potenziell schädliche Anwendungen wie Kryptowährung-Mining-Software, Rootkits im Kernel-Modus und Malware zu erkennen, die in kompromittierten 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 zu VM Threat Detection finden Sie unter Virtual Machine Threat Detection Übersicht. Informationen zum Aufrufen der Details eines VM Threat Detection-Ergebnisses finden Sie unter Ergebnisse in der Google Cloud Console prüfen.

Hinweis

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:

Sicherheitscenter-Admin-Betrachter (roles/securitycenter.adminViewer) für die Organisation
Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) für die Compute Engine-Instanz

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 identifizieren

Rufen Sie die Details des Ergebnisses auf.
Klicken Sie im Abschnitt Betroffene Ressource im Feld Vollständiger Ressourcenname auf den Link. Die Detailansicht der betroffenen Compute Engine-Instanz wird auf einem neuen Tab geöffnet.
Stellen Sie eine Verbindung zur Instanz her. 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 hindeuten, dass der Kernelspeicher der VM möglicherweise kompromittiert ist.

So finden Sie unerwartete Kernelmodule:

Listen Sie alle geladenen Kernelmodule in der VM auf:
```
lsmod
cat /proc/modules
```
Listen Sie die sysfs-Einträge für die geladenen und nicht geladenen Module auf:
```
ls -l /sys/module/
```
Vergleichen Sie die Ergebnisse dieser Listen mit Listen von anderen VMs im Projekt. Suchen Sie nach Modulen, die in der betroffenen VM, aber nicht in den anderen VMs vorhanden sind.

`syslog` nach externen Modulen durchsuchen

Anzeichen dafür, dass ein externes Modul in eine VM geladen wurde, können darauf hindeuten, dass untypische Kernelmodule geladen wurden. Sie können den Kernel-Logpuffer und syslog-Nachrichten durchsuchen, um festzustellen, ob ein externes Modul geladen wurde. In den Logeinträgen wird ein externes Modul als „tainted load“ (verunreinigte Last) markiert.

Suchen Sie im Kernel-Logpuffer und in den syslog-Nachrichten nach Logeinträgen, die den folgenden ähneln:

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

Suchen Sie im Kernel-Logpuffer nach Logeinträgen, die auf das Vorhandensein externer Module hinweisen:
```
sudo dmesg | grep out-of-tree
```
Suchen Sie in allen syslog-Nachrichten nach Logeinträgen, die auf das Vorhandensein externer Module hinweisen:
```
grep "out-of-tree" /var/log/syslog*
```

Auf Livepatching prüfen

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

So prüfen Sie, ob Livepatching verwendet wird:

Prüfen Sie syslog auf die Installation und Protokollierung von Livepatching-Modulen. Beim Livepatching wird der Kernelcode in der Regel durch die Installation von ftrace-Punkten im Kernel geändert.
```
sudo grep livepatch /var/log/syslog*
```
Suchen Sie nach neuen Kernelmodulen, die für Livepatching installiert wurden (in der Regel mit dem Präfix livepatch):
```
sudo lsmod | grep livepatch
```
Suchen Sie nach Patchdateien:
```
sudo ls -l /sys/kernel/livepatch
```

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

Auf andere potenziell schädliche Aktivitäten prüfen, die in der VM erkannt wurden

Rufen Sie in Security Command Center die Details des VM Threat Detection Ergebnisses auf, das Sie untersuchen.
Klicken Sie im Abschnitt Betroffene Ressource im Feld Vollständiger Ressourcenname auf den Drop-down-Pfeil und dann auf Alle Ergebnisse mit diesem vollständigen Ressourcennamen anzeigen. Die Ergebnisabfrage wird aktualisiert, sodass nur Ergebnisse für diese VM angezeigt werden.
Suchen Sie nach Ergebnissen, die auf potenzielle Kryptomining-Aktivitäten, Malware, ungewöhnliche IAM-Berechtigungen und andere Sicherheitsbedrohungen hinweisen.

Prüfen, ob Antivirensoftware ein falsch-positives Ergebnis 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 hindeuten, dass das VM Threat Detection-Ergebnis gültig ist und die VM kompromittiert wurde.

Listen Sie alle Prozesse auf, die auf der VM ausgeführt werden:
```
ps -eAf
```
Suchen Sie nach Debuggerprozessen wie gdb, strace und pstack, die Sie normalerweise nicht auf dieser VM ausführen. Debuggerprozesse können andere Prozesse ausspionieren.
Suchen Sie nach anderen verdächtigen Prozessen auf der VM.

Gestarteten Kernel prüfen

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

cat /proc/version

Wenn der zurückgegebene Wert nicht die erwartete Kernelversion ist, kann dies auf einen Hijacking-Angriff hindeuten, der durch Ausnutzen des kexec-Tools im Kernel erfolgt ist. Mit dem kexec-Tool kann das System neu gestartet werden, um einen anderen Kernel zu verwenden.

Zusätzliche Aufgabe für `Unexpected system call handler`

Führen Sie diese Aufgabe aus, wenn Sie ein Ergebnis zu Defense Evasion: Unexpected system call handler erhalten.

Prüfen Sie Systemaufrufe und suchen Sie nach Anomalien in ihrer Verwendung und ihren Aufrufern. Die Audit-Logs enthalten Informationen zum aufrufenden Prozess und zu den Argumenten für die Systemaufrufe. Sie können auch Prüfaufgaben 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 ein Ergebnis zu Defense Evasion: Unexpected interrupt handler erhalten.

Listen Sie die aktiven Interrupt-Handler im System auf und vergleichen Sie die Ergebnisse mit Informationen von anderen ähnlichen VMs im Projekt. Unerwartete Interrupt-Handler können darauf hindeuten, dass die VM kompromittiert ist.

Führen Sie den folgenden Befehl aus, um die aktiven Interrupt-Handler 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 diese Schritte aus, wenn Sie ein Ergebnis zu Defense Evasion: Unexpected processes in runqueue 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 prüfen Sie die Scheduler-Warteschlange pro CPU. Obwohl einige Prozesse kurzlebig sein können, können Sie das Verhalten der Scheduler-Warteschlange anhand der laufenden Prozesse pro CPU auswerten, um nach anomalem Verhalten zu suchen.

Zeigen Sie Details zur Zeit an, die jeder laufende Prozess pro CPU benötigt. So können Sie feststellen, ob eine bestimmte CPU extrem ausgelastet ist. Sie können die Ergebnisse mit den Interrupts korrelieren, die an die CPU angepinnt sind, aus /proc/interrupts.
```
cat /proc/schedstat
```
Weitere Informationen zu diesem Befehl finden Sie in der Linux-Kernel-Dokumentation unter Scheduler Statistics.

Listen Sie alle aktuellen 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 /

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

Beispielprüfung mit dem Diamorphine-Rootkit

In diesem Abschnitt wird eine Prüfung einer VM mit installiertem Diamorphine-Rootkit veranschaulicht. Diamorphine ist ein beliebtes ladbares Kernelmodul (Loadable Kernel Module, LKM). Dieses Rootkit löst die folgenden Ergebniskategorien 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 zu Bedrohungen durch Rootkits im Kernel-Modus.

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

Suchen Sie in syslog nach allen externen Kernelmodulen, die geladen sind.

Suchen Sie im Kernel-Logpuffer:

sudo dmesg | grep out-of-tree

Ausgabe:

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

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.

Suchen Sie in syslog nach Fehlern bei der Modulprüfung (nicht in allen Linux-Distributionen verfügbar).

Suchen Sie im Kernel-Logpuffer:

sudo dmesg | grep "module verification failed"

Ausgabe:

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

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

Prüfen Sie, ob das Modul mit den Befehlen /proc/modules und lsmod ausgeblendet ist.
```
sudo grep diamorphine /proc/modules
sudo lsmod | grep diamorphine
```
Es wurden keine Ergebnisse angezeigt.
Prüfen Sie, ob das Modul einen Eintrag in sysfs hat.
```
sudo cat /sys/module/diamorphine/coresize
```
Ausgabe:
```
16384
```
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.

Um zu prüfen, ob der Systemaufruf-Handler manipuliert wurde, prüfen Sie die Systemaufrufe und suchen Sie nach anomalem Verhalten. Dieses Verhalten variiert je nach Systemaufruf.

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

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. In den nächsten Schritten wird das Verhalten der VM nach der Installation des Rootkits gezeigt.

Prüfen Sie, ob nach der Installation des Diamorphine-Rootkits kein Audit-Logeintrag für das Signal mehr vorhanden ist:
```
$ sudo ausearch -k audit_kill | grep -A 3 "pid=1158"
$ sleep 600 &
[2] 1167
```

Prüfen Sie die Details im Audit-Logeintrag für das Signal. In diesem Beispiel wurde dieses bestimmte Signal zwar nicht vollständig vom Rootkit entführt, aber Informationen zum aufrufenden Prozess sind 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"

Datenerhebungsskript debuggen

Das folgende Skript führt viele der auf dieser Seite beschriebenen Debugging-Aufgaben aus. Sie können dieses Skript im sudo- oder root-Modus ausführen. Das Skript liest nur Debugging-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 "=================================================="

VM auf Anzeichen von Manipulationen am Kernel-Speicher prüfen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Informationen zu VM Threat Detection

Hinweis

Betroffene VM identifizieren

Unerwartete Kernelmodule finden

syslog nach externen Modulen durchsuchen

Auf Livepatching prüfen

Auf andere potenziell schädliche Aktivitäten prüfen, die in der VM erkannt wurden

Prüfen, ob Antivirensoftware ein falsch-positives Ergebnis verursacht

Alle laufenden Prozesse im System prüfen

Gestarteten Kernel prüfen

Zusätzliche Aufgabe für Unexpected system call handler

Zusätzliche Aufgabe für Unexpected interrupt handler

Zusätzliche Aufgabe für Unexpected processes in runqueue

Beispielprüfung mit dem Diamorphine-Rootkit

Datenerhebungsskript debuggen

Nächste Schritte

VM auf Anzeichen von Manipulationen am Kernel-Speicher prüfen

`syslog` nach externen Modulen durchsuchen

Zusätzliche Aufgabe für `Unexpected system call handler`

Zusätzliche Aufgabe für `Unexpected interrupt handler`

Zusätzliche Aufgabe für `Unexpected processes in runqueue`