Questa pagina è stata tradotta dall'API Cloud Translation.

Ispeziona una VM per rilevare segni di manomissione della memoria del kernel

Questa pagina descrive le attività che puoi eseguire per confermare la validità di un rilevamento di un rootkit in modalità kernel da Virtual Machine Threat Detection. I risultati relativi ai rootkit in modalità kernel indicano che la memoria del kernel di una VM potrebbe essere stata manomessa da malware.

Quando ricevi un rilevamento di rootkit in modalità kernel da VM Threat Detection, ti consigliamo di eseguire questi comandi Linux sull'istanza Compute Engine interessata per verificare la presenza di punti dati che potrebbero indicare anomalie, come chiamate di sistema compromesse o moduli del kernel nascosti.

In alternativa, puoi eseguire lo script di raccolta dei dati fornito sulla VM interessata. Lo script esegue i comandi descritti in questa pagina.

Salvo diversa indicazione, ogni attività di ispezione in questa pagina è pertinente a tutti i risultati relativi ai rootkit in modalità kernel.

Questo documento presuppone quanto segue:

Stai eseguendo le attività descritte in questo documento dopo aver ricevuto un rilevamento di un rootkit in modalità kernel da VM Threat Detection. Per un elenco delle categorie di risultati pertinenti, consulta Risultati relativi alle minacce di rootkit in modalità kernel.
Conoscere gli strumenti a riga di comando Linux e il kernel Linux.

Informazioni su Virtual Machine Threat Detection

Virtual Machine Threat Detection è un servizio integrato di Security Command Center disponibile nei livelli Enterprise e Premium. Questo servizio esegue la scansione delle istanze Compute Engine per rilevare applicazioni potenzialmente dannose, come software di cryptomining, rootkit in modalità kernel e malware in esecuzione in ambienti cloud compromessi.

Virtual Machine Threat Detection fa parte della suite di rilevamento delle minacce di Security Command Center ed è progettata per integrare le funzionalità esistenti di Event Threat Detection e Container Threat Detection.

Per informazioni su Virtual Machine Threat Detection, consulta la panoramica di Virtual Machine Threat Detection. Per scoprire come visualizzare i dettagli di un risultato di rilevamento delle minacce per le VM, consulta Esaminare i risultati nella console Google Cloud.

Prima di iniziare

Per ottenere le autorizzazioni necessarie per visualizzare tutte le risorse e i risultati in Security Command Center e gestire l'istanza Compute Engine interessata, chiedi all'amministratore di concederti i seguenti ruoli IAM:

Visualizzatore amministratore Centro sicurezza (roles/securitycenter.adminViewer) nell'organizzazione
Amministratore istanze Compute (v1) (roles/compute.instanceAdmin.v1) nell'istanza Compute Engine

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Identifica la VM interessata

Visualizza i dettagli del risultato.
Nella sezione Risorsa interessata, nel campo Nome completo della risorsa, fai clic sul link. La visualizzazione dei dettagli dell'istanza Compute Engine interessata si apre in una nuova scheda.
Connettersi all'istanza. Per ulteriori informazioni, consulta Connettersi alle VM Linux nella documentazione di Compute Engine.

Trovare moduli kernel inaspettati

La presenza di moduli inaspettati in una VM può indicare che la memoria del kernel della VM è potenzialmente compromessa.

Per trovare i moduli del kernel inaspettati:

Elenca tutti i moduli del kernel caricati nella VM:
```
lsmod
cat /proc/modules
```
Elenca le voci sysfs per i moduli caricati e non caricati:
```
ls -l /sys/module/
```
Confronta i risultati di questi elenchi con quelli di altre VM del progetto. Cerca i moduli che compaiono nella VM interessata, ma non nelle altre VM.

Cerca `syslog` per i moduli esterni all'albero

Gli indicatori che indicano che un modulo out-of-tree è stato caricato in una VM possono indicare che sono stati caricati moduli kernel atipici. Puoi cercare nel buffer dei log del kernel e nei messaggi syslog per determinare se è stato caricato un modulo esterno all'albero. Nelle voci di log, un modulo esterno all'albero è contrassegnato come caricamento compromesso.

Nel buffer dei log del kernel e nei messaggi syslog, cerca le voci di log simili alle seguenti:

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

Cerca nel buffer dei log del kernel le voci di log che indicano la presenza di moduli out-of-tree:
```
sudo dmesg | grep out-of-tree
```
Cerca in tutti i messaggi syslog le voci di log che indicano la presenza di moduli out-of-tree:
```
grep "out-of-tree" /var/log/syslog*
```

Controlla la presenza di live patching

Il live patching in una VM può interferire con i rilevamenti di VM Threat Detection e attivare risultati di falsi positivi.

Per verificare la presenza del live patching:

Consulta syslog per informazioni sull'installazione e sul logging dei moduli di live patching. L'applicazione di patch live in genere modifica il codice del kernel installando i punti ftrace del kernel.
```
sudo grep livepatch /var/log/syslog*
```
Cerca i nuovi moduli del kernel installati per il live patching (in genere con prefisso livepatch):
```
sudo lsmod | grep livepatch
```
Cerca i file patch:
```
sudo ls -l /sys/kernel/livepatch
```

Per informazioni sul live patching, consulta Livepatch nella documentazione del kernel Linux.

Controlla se sono state rilevate altre attività potenzialmente dannose nella VM

In Security Command Center, visualizza i dettagli del risultato del rilevamento delle minacce VM che stai esaminando.
Nella sezione Risorsa interessata, nel campo Nome completo della risorsa, fai clic sulla freccia menu a discesa e poi su Mostra tutti i risultati con questo nome completo della risorsa. La query sui risultati viene aggiornata in modo da mostrare solo i risultati per questa VM.
Controlla se sono presenti risultati che indicano potenziali attività di cryptomining, malware, assegnazioni IAM insolite e altre minacce alla sicurezza.

Verificare se il software antivirus causa un falso positivo

Il software antivirus può interferire con i rilevamenti di VM Threat Detection e attivare risultati falsi positivi.

Controlla tutti i processi in esecuzione sul sistema

La presenza di processi imprevisti può indicare che il rilevamento di minacce VM è valido e che la VM è stata compromessa.

Elenca tutti i processi in esecuzione sulla VM:
```
ps -eAf
```
Cerca i processi di debugger, come gdb, strace e pstack, che in genere non esegui su questa VM. I processi di debugger possono eseguire attività di snooping su altri processi.
Cerca altri processi sospetti sulla VM.

Controlla il kernel avviato

Controlla il kernel avviato per identificare il kernel Linux:

cat /proc/version

Se il valore restituito non è la versione del kernel prevista, potrebbe indicare un attacco di pirateria informatica che viene eseguito sfruttando lo strumento kexec nel kernel. Lo strumentokexec può eseguire il softboot del sistema per utilizzare un kernel diverso.

Attività aggiuntive per i risultati di `Unexpected kernel code modification`

Le attività in questa sezione sono specifiche per la categoria di risultati Defense Evasion: Unexpected kernel code modification. Per verificare la validità di un rilevamento in questa categoria, svolgi le attività nelle seguenti sezioni.

Queste sezioni ti aiutano a determinare se la VM utilizza un'API di debugger. Le API debugger possono attivare risultati falsi positivi, perché possono modificare le regioni di codice del kernel in esecuzione.

In genere, il rilevamento delle minacce alla VM non genera un rilevamento se rileva l'utilizzo di un'API di debugger. Tuttavia, se la VM utilizza un'API di debugger non nota a Rilevamento minacce VM, puoi comunque ottenere un risultato falso positivo.

Controlla se sono abilitati i tracer di debug

I tracer, ad eccezione del tracer nop, possono causare modifiche al codice del kernel. Questi possono interferire con i rilevamenti di VM Threat Detection e attivare risultati di falsi positivi. In genere, se il rilevamento delle minacce alla VM rileva la presenza di tracer, non invia un rilevamento Defense Evasion: Unexpected kernel code modification.

Per verificare la presenza di traccianti di debug abilitati:

Controlla i tracker disponibili:

cat /sys/kernel/debug/tracing/available_tracers

L'output è simile al seguente:

hwlat blk mmiotrace function_graph wakeup_dl wakeup_rt wakeup function nop

Controlla il tracker corrente:
```
cat /sys/kernel/debug/tracing/current_tracer
```
Il risultato è uno dei tracer disponibili restituiti nel comando precedente.
Verifica se il monitoraggio è attivo sul sistema:
```
cat /sys/kernel/debug/tracing/tracing_on
```
Un valore 1 indica che il monitoraggio è abilitato sul sistema.
Elenca le CPU su cui è abilitato il monitoraggio:
```
cat /sys/kernel/debug/tracing/tracing_cpumask
```

Visualizza i dettagli del monitoraggio:

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

L'output è simile al seguente:

Function       Hit    Time            Avg             s^2

Controllare gli eventi del tracer di debug

Il monitoraggio degli eventi nel kernel può causare modifiche al codice del kernel e può portare a risultati di Virtual Machine Threat Detection con falsi positivi. Molti strumenti di debugging e monitoraggio delle prestazioni possono attivare automaticamente il monitoraggio degli eventi.

Per verificare se il monitoraggio degli eventi è abilitato, esegui i seguenti comandi:

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

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

Un output di 0 indica che il monitoraggio degli eventi è disattivato. Un output di 1 indica che il monitoraggio degli eventi è abilitato.

Valuta la possibilità di disattivare il monitoraggio degli eventi per verificare se VM Threat Detection genera gli stessi risultati. Se i risultati sono ridotti, ciò può indicare che alcuni dei risultati iniziali erano falsi positivi.

Controlla la presenza di kprobe, regole eBPF e netfilter

I netfilter, i kprobe e le regole eBPF possono attivare modifiche al codice perché attivano i trasferimenti di chiamata ai callback personalizzati. Il rilevamento delle minacce VM rileva la presenza di questi controlli e li mappa alle pagine di codice modificate, senza tenere conto di quali possono attivare falsi positivi.

Per verificare la presenza di kprobe, regole eBPF e netfilter, esegui il seguente comando:

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

Controllare la presenza di tracer di debug iniziali

La presenza di tracer di debug iniziali abilitati all'avvio può interferire con i rilevamenti di VM Threat Detection e attivare risultati di falsi positivi.

Per verificare la presenza di tracer di debug iniziali, esegui il seguente comando:

cat /proc/cmdline

Per un elenco dei possibili tracer di debug iniziale, consulta Monitoraggio al momento dell'avvio nella documentazione del kernel Linux.

Attività aggiuntiva per `Unexpected system call handler`

Esegui questa operazione se ricevi un Defense Evasion: Unexpected system call handler risultato.

Controlla le chiamate di sistema e cerca anomalie nel loro utilizzo e negli invocanti. I log di controllo forniscono informazioni sulla procedura di chiamata e sugli argomenti per le chiamate di sistema. Puoi anche eseguire attività di verifica per verificare i comportamenti previsti delle chiamate di sistema comuni. Per ulteriori informazioni, consulta Esempio di ispezione con il rootkit Diamorphine in questa pagina.

Attività aggiuntiva per `Unexpected interrupt handler`

Esegui questa operazione se ricevi un Defense Evasion: Unexpected interrupt handler risultato.

Elenca i gestori di interruzioni in tempo reale sul sistema e confronta i risultati con le informazioni di altre VM simili nel progetto. Gestori di interruzioni impreviste possono indicare che la VM è compromessa.

Per elencare i gestori di interruzioni attivi, esegui il comando seguente:

cat /proc/interrupts

L'output è simile al seguente:

           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

Attività aggiuntiva per `Unexpected processes in runqueue`

Se ricevi un risultato Defense Evasion: Unexpected processes in runqueue, svolgi questi passaggi. Questa sezione ti aiuta a raccogliere ulteriori punti dati per esaminare i risultati. Questi punti dati potrebbero non indicare direttamente un problema di malware.

In questa attività esamini la coda dello scheduler per CPU. Anche se alcuni processi potrebbero essere di breve durata, puoi comunque valutare il comportamento della coda dello scheduler con i processi in esecuzione per CPU per cercare comportamenti anomali.

Mostra i dettagli sulla quantità di tempo che ogni processo in esecuzione spende per CPU. In questo modo puoi vedere se una determinata CPU è estremamente occupata. Puoi correlare i risultati alle interruzioni bloccate sulla CPU da /proc/interrupts.
```
cat /proc/schedstat
```
Per ulteriori informazioni su questo comando, consulta Statistiche pianificatore nella documentazione del kernel Linux.

Elenca tutte le attività eseguibili correnti e i dettagli sugli switch di contesto per ogni CPU.

cat /proc/sched_debug

L'output è simile al seguente:

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 /

Cerca quanto segue:
- Nomi dei processi in esecuzione.
- Numero di switch di contesto per CPU. Controlla se un processo presenta un numero troppo ridotto o eccessivo di switch sulla CPU.
- Tempo di CPU impiegato (tempo non inattivo).

Esempio di ispezione con il rootkit Diamorphine

Questa sezione mostra un'ispezione di una VM su cui è installato il rootkit Diamorphine. Diamorphine è un modulo del kernel caricabile (LKM) molto utilizzato. Questo rootkit attiva le seguenti categorie di risultati:

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

Per ulteriori informazioni su queste categorie di risultati, consulta Risultati relativi alle minacce di rootkit in modalità kernel.

I passaggi di ispezione eseguiti e i sintomi osservati sulla VM sono i seguenti:

Cerca syslog per tutti i moduli del kernel out-of-tree caricati.

Cerca nel buffer dei log del kernel:

sudo dmesg | grep out-of-tree

Output:

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

Cerca nei messaggi syslog:

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

Output:

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

Cerca syslog per eventuali errori di verifica del modulo (non disponibile su tutte le distribuzioni Linux).

Cerca nel buffer dei log del kernel:

sudo dmesg | grep "module verification failed"

Output:

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

Cerca nei messaggi syslog:

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

Output:

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

Verifica che il modulo sia nascosto dai comandi /proc/modules e lsmod.
```
sudo grep diamorphine /proc/modules
sudo lsmod | grep diamorphine
```
Nessun risultato è stato visualizzato.
Verifica che il modulo abbia una voce in sysfs.
```
sudo cat /sys/module/diamorphine/coresize
```
Output:
```
16384
```
Recupera la tabella delle chiamate di sistema per l'architettura:
```
sudo ausyscall --dump
```
Output:
```
Using x86_64 syscall table:
0       read
1       write
2       open
3       close
```
Controlla la presenza di anomalie nelle chiamate di sistema, come kill e getdents, che in genere vengono manomesse dai rootkit.

Per verificare la presenza di manipolazioni del gestore chiamate di sistema, controlla le chiamate di sistema e cerca comportamenti anomali. Questi comportamenti variano per ogni chiamata di sistema.

Una chiamata di sistema che viene solitamente compromessa è la chiamata kill. Puoi verificare se la chiamata di sistema kill è stata aggirata. Nell'esempio seguente, è stata controllata la chiamata di sistema kill.

Installa auditd e osserva il comportamento della VM senza il rootkit Diamorphine:

$ 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"

A questo punto dell'ispezione, il rootkit Diamorphine è stato installato. I passaggi successivi mostrano il comportamento della VM dopo l'installazione del rootkit.

Verifica che una voce di log di controllo per l'indicatore non sia più presente dopo l'installazione del rootkit Diamorphine:
```
$ sudo ausearch -k audit_kill | grep -A 3 "pid=1158"
$ sleep 600 &
[2] 1167
```

Controlla i dettagli nella voce di log di controllo per l'indicatore. In questo esempio, anche se questo particolare indicatore non è stato completamente compromesso dal rootkit, sono disponibili informazioni sul processo di richiamo.

$ 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"

Debug dello script di raccolta dei dati

Lo script seguente esegue molte delle attività di debug descritte in questa pagina. Puoi eseguire questo script in modalità sudo o root. Lo script legge solo le informazioni di debug dal sistema.

$ 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 "=================================================="

Ispeziona una VM per rilevare segni di manomissione della memoria del kernel

Informazioni su Virtual Machine Threat Detection

Prima di iniziare

Identifica la VM interessata

Trovare moduli kernel inaspettati

Cerca syslog per i moduli esterni all'albero

Controlla la presenza di live patching

Controlla se sono state rilevate altre attività potenzialmente dannose nella VM

Verificare se il software antivirus causa un falso positivo

Controlla tutti i processi in esecuzione sul sistema

Controlla il kernel avviato

Attività aggiuntive per i risultati di Unexpected kernel code modification

Controlla se sono abilitati i tracer di debug

Controllare gli eventi del tracer di debug

Controlla la presenza di kprobe, regole eBPF e netfilter

Controllare la presenza di tracer di debug iniziali

Attività aggiuntiva per Unexpected system call handler

Attività aggiuntiva per Unexpected interrupt handler

Attività aggiuntiva per Unexpected processes in runqueue

Esempio di ispezione con il rootkit Diamorphine

Debug dello script di raccolta dei dati

Passaggi successivi

Cerca `syslog` per i moduli esterni all'albero

Attività aggiuntive per i risultati di `Unexpected kernel code modification`

Attività aggiuntiva per `Unexpected system call handler`

Attività aggiuntiva per `Unexpected interrupt handler`

Attività aggiuntiva per `Unexpected processes in runqueue`