VM auf Anzeichen von Manipulationen am Kernelspeicher prüfen

Dienststufen für Premium und Enterprise

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

Wenn Sie von VM Threat Detection einen Befund zu einem Rootkit im Kernelmodus erhalten, empfehlen wir, die folgenden Linux-Befehle auf der betroffenen Compute Engine-Instanz auszuführen, um Ihr System nach Datenpunkten zu durchsuchen, die auf Anomalien wie gekaperte Systemaufrufe oder verborgene Kernelmodule hinweisen könnten.

Alternativ können Sie das bereitgestellte Datenerfassungsskript 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 Rootkit-Ergebnisse im Kernelmodus relevant.

In diesem Dokument wird Folgendes vorausgesetzt:

• Sie führen die Aufgaben in diesem Dokument aus, nachdem Sie von VM Threat Detection ein Ergebnis zu einem Kernel-Mode-Rootkit erhalten haben. Eine Liste der relevanten Kategorien von Ergebnissen finden Sie unter Ergebnisse zur Bedrohung durch Kernel-Mode-Rootkits.

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

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, Kernel-Mode-Rootkits 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.

Informationen zu VM Threat Detection finden Sie unter Übersicht: VM Threat Detection. Informationen zum Aufrufen der Details eines VM Threat Detection-Ergebnisses finden Sie unter Ergebnisse in derGoogle Cloud -Konsole ansehen.

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:

• Sicherheitscenter-Admin-Betrachter (roles/securitycenter.adminViewer) für die Organisation
• Compute-Instanzadministrator (Version 1) (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

1. Details des Ergebnisses ansehen
2. Klicken Sie im Abschnitt Betroffene Ressource im Feld Vollständiger Ressourcennamen auf den Link. Die Detailansicht der betroffenen Compute Engine-Instanz wird auf 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 hindeuten, dass der Kernelspeicher der VM möglicherweise manipuliert wurde.

So finden Sie unerwartete Kernelmodule:

1. Alle geladenen Kernelmodule in der VM auflisten:

   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 von anderen VMs im Projekt. Suchen Sie nach Modulen, die in der betroffenen VM, aber nicht in den anderen VMs vorhanden sind.

Suche in syslog nach Out-of-Tree-Modulen

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

Suchen Sie im Kernelprotokoll-Zwischenspeicher und in den syslog-Meldungen nach Logeinträgen, die den folgenden ähneln:

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

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

  sudo dmesg | grep out-of-tree
  

• Suchen Sie in allen syslog-Nachrichten nach Logeinträgen, die auf Out-of-Tree-Module hinweisen:

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

Auf Live-Patching prüfen

Livepatching in einer VM kann die Erkennungen von VM Threat Detection beeinträchtigen und Falschmeldungen auslösen.

So prüfen Sie, ob Livepatching verfügbar ist:

1. Weitere Informationen zur Installation und zum Logging von Livepatching-Modulen finden Sie unter syslog. Beim Live-Patching wird der Kernelcode in der Regel durch die Installation von Kernel-ftrace-Punkten geändert.

   sudo grep livepatch /var/log/syslog*
   

2. Suchen Sie nach neuen Kernelmodulen, die für 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 zu Livepatching finden Sie in der Linux-Kernel-Dokumentation unter Livepatch.

Nach anderen potenziell schädlichen Aktivitäten suchen, die in der VM erkannt wurden

1. Sehen Sie sich im Security Command Center die Details des VM Threat Detection-Ergebnisses an, das Sie untersuchen.
2. Klicken Sie im Abschnitt Betroffene Ressource im Feld Vollständiger Name der Ressource auf den Drop-down-Pfeil 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. Suchen Sie nach Ergebnissen, die auf potenzielle Kryptomining-Aktivitäten, Malware, ungewöhnliche IAM-Berechtigungen und andere Sicherheitsbedrohungen hinweisen.

Prüfen, ob Antivirensoftware einen Fehlalarm auslöst

Antivirensoftware kann die Erkennungen von VM Threat Detection beeinträchtigen und Falsch-Positiv-Ergebnisse auslösen.

Alle laufenden Prozesse auf dem System prüfen

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

1. Alle Prozesse auflisten, 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.

Gestarteten Kernel prüfen

So ermitteln Sie Ihren Linux-Kernel:

cat /proc/version

Wenn die zurückgegebene Version nicht der erwarteten Kernelversion entspricht, kann das auf einen Hijacking-Angriff hinweisen, 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 Aufgabe für Unexpected system call handler

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

Prüfen Sie Systemaufrufe und suchen Sie nach Anomalien bei 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 Beispiel für die Überprüfung mit dem Diamorphine-Rootkit.

Zusätzliche Aufgabe für Unexpected interrupt handler

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

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

Führen Sie den folgenden Befehl aus, um die Live-Unterbrechungshandler 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 vom Typ Defense Evasion: Unexpected processes in runqueue erhalten. In diesem Abschnitt erfahren Sie, wie Sie zusätzliche Datenpunkte erfassen, um Ihre Ergebnisse zu analysieren. Diese Datenpunkte weisen möglicherweise nicht direkt auf ein Malware-Problem hin.

In dieser Aufgabe sehen Sie sich die Planerwarteschlange pro CPU an. Auch wenn einige Prozesse nur kurz ausgeführt werden, können Sie das Verhalten der Scheduler-Warteschlange anhand der laufenden Prozesse pro CPU untersuchen, um nach ungewöhnlichem Verhalten zu suchen.

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

   cat /proc/schedstat
   

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

2. Listet alle aktuell 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 der laufenden Prozesse
   • Anzahl der Kontextwechsel pro CPU. Prüfen Sie, ob ein Prozess zu wenige oder zu viele Switches auf der CPU verursacht.
   • Aufgewendete CPU-Zeit (Zeit, in der die CPU nicht im Leerlauf war).

Beispiel für eine Prüfung mit dem Diamorphine-Rootkit

In diesem Abschnitt wird die Untersuchung einer VM mit dem Rootkit Diamorphine beschrieben. Diamorphine ist ein beliebtes ladbares Kernelmodul (Loadable Kernel Module, LKM). Dieses Rootkit löst die folgenden Fundkategorien 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 Kernel-Mode-Rootkit-Bedrohungen.

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

1. Suchen Sie in syslog nach allen Out-of-Tree-Kernelmodulen, die geladen sind.

   1. Kernelprotokoll-Zwischenspeicher durchsuchen:

      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. Suchen Sie in syslog nach Fehlern bei der Modulüberprüfung (nicht auf allen Linux-Distributionen verfügbar).

   1. Kernelprotokoll-Zwischenspeicher durchsuchen:

      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 mit den Befehlen /proc/modules und lsmod ausgeblendet wird.

   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 Systemaufrufe wie kill und getdents auf Anomalien, da diese in der Regel von Rootkits manipuliert werden.

6. Um zu prüfen, ob Systemaufruf-Handler manipuliert wurden, prüfen Sie die Systemaufrufe und suchen Sie nach ungewöhnlichem Verhalten. Diese Verhaltensweisen variieren für jeden 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"
      

      Zu diesem Zeitpunkt der Prüfung war das Diamorphine-Rootkit installiert. In den nächsten Schritten wird das Verhalten der VM nach der Installation des Rootkits beschrieben.

      Warnung :Für diese Beispielprüfung wurde das Diamorphine-Rootkit in einer kontrollierten Umgebung installiert. Installieren Sie das Diamorphine-Rootkit nicht in Ihrer eigenen Cloud-Umgebung.

   2. 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
      

   3. Sehen Sie sich die Details im Audit-Logeintrag für das Signal an. In diesem Beispiel wurde das Signal zwar nicht vollständig vom Rootkit manipuliert, 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"
      

Skript zur Datenerhebung debuggen

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

Nächste Schritte

• Weitere Informationen zu Virtual Machine Threat Detection
• Informationen zur Verwendung von Virtual Machine Threat Detection