Inspecciona una VM para detectar signos de manipulación de la memoria del kernel

En esta página, se describen las tareas que puedes realizar para confirmar la validez de un hallazgo de rootkit en modo kernel de Virtual Machine Threat Detection. Los hallazgos de rootkits en modo kernel indican que el software malicioso pudo haber manipulado la memoria del kernel de una VM.

Cuando recibas un hallazgo de rootkit en modo kernel de Virtual Machine Threat Detection, te recomendamos que ejecutes estos comandos de Linux en la instancia de Compute Engine afectada para sondear tu sistema en busca de datos que puedan indicar anomalías, como llamadas al sistema usurpadas o módulos de kernel ocultos.

Como alternativa, puedes ejecutar la secuencia de comandos de recopilación de datos proporcionada en la VM afectada. La secuencia de comandos ejecuta los comandos que se describen en esta página.

A menos que se indique lo contrario, cada tarea de inspección de esta página es relevante para todos los hallazgos de rootkits en modo de kernel.

En este documento, se da por sentado lo siguiente:

  • Realizas las tareas de este documento después de recibir un hallazgo de rootkit en modo kernel de VM Threat Detection. Para obtener una lista de las categorías de resultados relevantes, consulta Resultados de amenazas de rootkit en modo kernel.

  • Comprendes las herramientas de línea de comandos y el kernel de Linux.

Información acerca de VM Threat Detection

Virtual Machine Threat Detection es un servicio integrado de Security Command Center que está disponible en los niveles Enterprise y Premium. Este servicio analiza las instancias de Compute Engine para detectar aplicaciones potencialmente maliciosas, como software de minería de criptomonedas, rootkits en modo kernel y software malicioso que se ejecuta en entornos de nube vulnerados.

VM Threat Detection forma parte del paquete de detección de amenazas de Security Command Center y está diseñada para complementar las capacidades existentes de Event Threat Detection y Container Threat Detection.

Para obtener información sobre VM Threat Detection, consulta la descripción general de Virtual Machine Threat Detection. Para obtener información sobre cómo ver los detalles de un resultado de VM Threat Detection, consulta Revisa los resultados en la consola de Google Cloud.

Antes de comenzar

Para obtener los permisos que necesitas para ver todos los recursos y hallazgos en Security Command Center y administrar la instancia de Compute Engine afectada, pídele a tu administrador que te otorgue los siguientes roles de IAM:

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios mediante roles personalizados o cualquier otro rol predefinido.

Identifica la VM afectada

  1. Consulta los detalles del hallazgo.
  2. En la sección Recurso afectado, en el campo Nombre completo del recurso, haz clic en el vínculo. La vista de detalles de la instancia de Compute Engine afectada se abre en una pestaña nueva.
  3. Conéctate a la instancia. Para obtener más información, consulta Cómo conectarse a VMs de Linux en la documentación de Compute Engine.

Cómo encontrar módulos de kernel inesperados

La presencia de módulos inesperados en una VM puede indicar que la memoria del kernel de la VM está potencialmente comprometida.

Para encontrar módulos de kernel inesperados, sigue estos pasos:

  1. Enumera todos los módulos de kernel cargados en la VM:

    lsmod
cat /proc/modules

  2. Enumera las entradas sysfs para los módulos cargados y descargados:

    ls -l /sys/module/

  3. Compara los resultados de estas listas con las de otras VMs del proyecto. Busca módulos que aparezcan en la VM afectada, pero no en las otras.

Busca módulos fuera del árbol en syslog

Los indicadores de que se cargó un módulo fuera del árbol en una VM pueden indicar que se cargaron módulos de kernel atípicos. Puedes buscar en el búfer de registro del kernel y en los mensajes syslog para determinar si se cargó un módulo fuera del árbol. En las entradas de registro, un módulo fuera del árbol se marca como carga contaminada.

En el búfer de registro del kernel y los mensajes syslog, busca entradas de registro que se asemejen a lo siguiente:

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

  • Busca en el búfer de registro del kernel entradas de registro que indiquen la presencia de módulos fuera del árbol:

    sudo dmesg | grep out-of-tree

  • Busca en todos los mensajes syslog entradas de registro que indiquen la presencia de módulos fuera del árbol:

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

Cómo verificar si hay parches en vivo

La aplicación de parches en vivo en una VM puede interferir con las detecciones de VM Threat Detection y activar resultados falsos positivos.

Para verificar si hay parches en vivo, sigue estos pasos:

  1. Consulta syslog para ver la instalación y el registro del módulo de parcheo en vivo. Por lo general, los parches en vivo modifican el código del kernel instalando puntos ftrace del kernel.

    sudo grep livepatch /var/log/syslog*

  2. Busca módulos de kernel nuevos instalados para la aplicación de parches en vivo (por lo general, con el prefijo livepatch):

    sudo lsmod | grep livepatch

  3. Busca archivos de parche:

    sudo ls -l /sys/kernel/livepatch

Para obtener información sobre los parches en vivo, consulta Livepatch en la documentación del kernel de Linux.

Verifica si hay otras actividades potencialmente maliciosas detectadas en la VM

  1. En Security Command Center, consulta los detalles del resultado de VM Threat Detection que estás investigando.
  2. En la sección Recurso afectado, en el campo Nombre completo del recurso, haz clic en la flecha desplegable y, luego, en Mostrar todos los resultados con este nombre completo del recurso. La búsqueda de resultados se actualiza para mostrar solo los resultados de esta VM.
  3. Busca hallazgos que indiquen posibles actividades de criptominería, software malicioso, otorgamientos de IAM inusuales y otras amenazas de seguridad.

Comprueba si el software antivirus está causando un resultado falso positivo

El software antivirus puede interferir en las detecciones de VM Threat Detection y activar resultados falsos positivos.

Cómo verificar todos los procesos en ejecución del sistema

La presencia de procesos inesperados puede indicar que el hallazgo de VM Threat Detection es válido y que la VM se vio comprometida.

  1. Enumera todos los procesos que se ejecutan en la VM:

    ps -eAf

  2. Busca procesos de depurador, como gdb, strace y pstack, que no sueles ejecutar en esta VM. Los procesos del Debugger pueden espiar otros procesos.

  3. Busca otros procesos sospechosos en la VM.

Verifica el kernel iniciado

Verifica el kernel iniciado para identificar el kernel de Linux:

cat /proc/version

Si el valor que se muestra no es la versión del kernel esperada, es posible que se trate de un ataque de secuestro que se realiza explotando la herramienta kexec en el kernel. La herramienta kexec puede iniciar el sistema de forma suave para usar un kernel diferente.

Tareas adicionales para los resultados de Unexpected kernel code modification

Las tareas de esta sección son específicas de la categoría de búsqueda Defense Evasion: Unexpected kernel code modification. Realiza las tareas de las siguientes secciones para verificar la validez de un hallazgo en esta categoría.

Estas secciones te ayudan a determinar si tu VM usa una API de depurador. Las APIs del Debugger pueden activar resultados falsos positivos, ya que pueden modificar las regiones de código del kernel en ejecución.

En general, VM Threat Detection no genera un resultado si detecta el uso de una API de depurador. Sin embargo, si tu VM usa una API de depurador que VM Threat Detection no conoce, es posible que obtengas un resultado falso positivo.

Cómo verificar si hay generadores de seguimiento de depuración habilitados

Los generadores de registros, excepto el generador de registros nop, pueden causar modificaciones en el código del kernel. Estos pueden interferir en las detecciones de VM Threat Detection y activar resultados falsos positivos. En general, si VM Threat Detection detecta la presencia de generadores de trazas, no envía un resultado Defense Evasion: Unexpected kernel code modification.

Para verificar si hay generadores de seguimiento de depuración habilitados, sigue estos pasos:

  1. Revisa los trazadores disponibles:

    cat /sys/kernel/debug/tracing/available_tracers

    El resultado se ve de la manera siguiente:

    hwlat blk mmiotrace function_graph wakeup_dl wakeup_rt wakeup function nop

  2. Verifica el trazador actual:

    cat /sys/kernel/debug/tracing/current_tracer

    El resultado es uno de los generadores de registros disponibles que se mostraron en el comando anterior.

  3. Confirma si el seguimiento está habilitado en el sistema:

    cat /sys/kernel/debug/tracing/tracing_on

    Un valor de 1 indica que el seguimiento está habilitado en el sistema.

  4. Haz una lista de las CPUs en las que se habilitó el seguimiento:

    cat /sys/kernel/debug/tracing/tracing_cpumask

  5. Consulta los detalles del seguimiento:

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

    El resultado se ve de la manera siguiente:

    Function       Hit    Time            Avg             s^2

Cómo verificar los eventos del generador de registros de depuración

La supervisión de eventos en el kernel puede causar modificaciones en el código del kernel y generar resultados falsos positivos de VM Threat Detection. Muchas herramientas de depuración y supervisión de rendimiento pueden habilitar automáticamente la supervisión de eventos.

Para verificar si la supervisión de eventos está habilitada, ejecuta los siguientes comandos:

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

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

Un resultado de 0 significa que la supervisión de eventos está inhabilitada. Un resultado de 1 significa que la supervisión de eventos está habilitada.

Considera inhabilitar la supervisión de eventos para verificar si VM Threat Detection emite los mismos resultados. Si se reducen los resultados, eso puede indicar que algunos de los resultados iniciales fueron falsos positivos.

Verifica si hay kprobes, reglas de eBPF y netfilters

Los netfilters, los kprobes y las reglas de eBPF pueden activar modificaciones de código porque activan transferencias de llamadas a devoluciones de llamada personalizadas. VM Threat Detection detecta la presencia de estas sondas y las asigna a páginas de código modificadas, sin tener en cuenta cuáles pueden activar falsos positivos.

Para verificar si hay kprobes, reglas de eBPF y netfilters, ejecuta el siguiente 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

Cómo verificar si hay generadores de seguimiento de depuración anticipados

La presencia de generadores de registros de depuración anticipados que se habilitan en el momento del inicio puede interferir con las detecciones de la detección de amenazas de VM y activar resultados falsos positivos.

Para verificar si hay generadores de registros de depuración anticipados, ejecuta el siguiente comando:

cat /proc/cmdline

Para obtener una lista de posibles generadores de seguimiento de depuración anticipada, consulta Registro del tiempo de inicio en la documentación del kernel de Linux.

Tarea adicional para Unexpected system call handler

Realiza esta tarea si obtienes un resultado Defense Evasion: Unexpected system call handler.

Audita las llamadas del sistema y busca anomalías en su uso y en los invocadores. Los registros de auditoría proporcionan información sobre el proceso de invocación y los argumentos de las llamadas al sistema. También puedes realizar tareas de verificación para verificar los comportamientos esperados de las llamadas comunes al sistema. Para obtener más información, consulta Ejemplo de inspección con el rootkit Diamorphine en esta página.

Tarea adicional para Unexpected interrupt handler

Realiza esta tarea si obtienes un resultado Defense Evasion: Unexpected interrupt handler.

Haz una lista de los controladores de interrupción en vivo del sistema y compara los resultados con la información de otras VMs similares del proyecto. Los controladores de interrupción inesperados pueden indicar que la VM está comprometida.

Para enumerar los controladores de interrupción activos, ejecuta el siguiente comando:

cat /proc/interrupts

El resultado se ve de la manera siguiente:

           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

Tarea adicional para Unexpected processes in runqueue

Sigue estos pasos si obtienes un resultado Defense Evasion: Unexpected processes in runqueue. Esta sección te ayuda a recopilar datos adicionales para investigar tus conclusiones. Es posible que estos datos no indiquen directamente un problema de software malicioso.

En esta tarea, revisarás la cola del programador por CPU. Aunque algunos procesos pueden ser de corta duración, puedes evaluar el comportamiento de la cola del programador con los procesos en ejecución por CPU para buscar comportamientos anómalos.

  1. Muestra detalles sobre la cantidad de tiempo que cada proceso en ejecución pasa por CPU. Esto te permite ver si una CPU en particular está muy ocupada. Puedes correlacionar los resultados con las interrupciones fijadas en la CPU desde /proc/interrupts.

    cat /proc/schedstat

    Para obtener más información sobre este comando, consulta Estadísticas del programador en la documentación del kernel de Linux.

  2. Enumera todas las tareas ejecutables actuales y los detalles sobre los cambios de contexto para cada CPU.

    cat /proc/sched_debug

    El resultado se ve de la manera siguiente:

    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. Busca lo siguiente:

    • Nombres de procesos en ejecución
    • Cantidad de conmutaciones de contexto por CPU. Comprueba si un proceso genera muy pocos o demasiados conmutadores en la CPU.
    • Tiempo de CPU empleado (tiempo no inactivo).

Ejemplo de inspección con el rootkit Diamorphine

En esta sección, se muestra una inspección de una VM que tiene instalado el rootkit Diamorphine. Diamorphine es un módulo de kernel (LKM) cargable popular. Este rootkit activa las siguientes categorías de hallazgos:

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

Para obtener más información sobre estas categorías de resultados, consulta Resultados de amenazas de rootkit en modo kernel.

Los pasos de inspección que se realizaron y los síntomas que se observaron en la VM son los siguientes:

  1. Busca en syslog todos los módulos de kernel fuera del árbol que se cargaron.

    1. Busca en el búfer de registro del kernel:

      sudo dmesg | grep out-of-tree

      Resultado:

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

    2. Busca los mensajes de syslog:

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

      Resultado:

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

  2. Busca syslog para detectar fallas de verificación de módulos (no disponible en todas las distribuciones de Linux).

    1. Busca en el búfer de registro del kernel:

      sudo dmesg | grep "module verification failed"

      Resultado:

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

    2. Busca los mensajes de syslog:

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

      Resultado:

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

  3. Confirma que el módulo esté oculto de los comandos /proc/modules y lsmod.

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

    No se mostraron resultados.

  4. Confirma que el módulo tenga una entrada en sysfs.

    sudo cat /sys/module/diamorphine/coresize

    Resultado:

    16384

  5. Obtén la tabla de llamadas del sistema para la arquitectura:

    sudo ausyscall --dump

    Resultado:

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

    Audita si hay anomalías en las llamadas al sistema, como kill y getdents, que suelen manipular los rootkits.

  6. Para verificar si se manipuló el controlador de llamadas del sistema, audita las llamadas del sistema y busca comportamientos anómalos. Estos comportamientos varían para cada llamada al sistema.

    Una llamada al sistema que suele hackearse es la llamada kill. Puedes verificar si se omitió la llamada al sistema kill. En el siguiente ejemplo, se auditó la llamada al sistema kill.

    1. Instala auditd y observa el comportamiento de la VM sin el 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"

      En este punto de la inspección, se instaló el rootkit Diamorphine. En los siguientes pasos, se muestra el comportamiento de la VM después de la instalación del rootkit.

    2. Confirma que no haya una entrada de registro de auditoría para el indicador después de que se haya instalado el rootkit de Diamorphine:

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

    3. Verifica los detalles en la entrada de registro de auditoría para encontrar el indicador. En este ejemplo, aunque el rootkit no usurpó por completo este indicador en particular, hay información disponible sobre el proceso de llamador.

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

Cómo depurar la secuencia de comandos de recopilación de datos

La siguiente secuencia de comandos realiza muchas de las tareas de depuración que se describen en esta página. Puedes ejecutar esta secuencia de comandos en el modo sudo o root. La secuencia de comandos solo lee información de depuración del 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 "=================================================="

¿Qué sigue?