Inspecionar uma VM para verificar se há sinais de adulteração da memória do kernel

Esta página descreve as tarefas que você pode realizar para confirmar a validade de uma encontrabilidade de rootkit em modo kernel da Detecção de ameaças a máquinas virtuais. As descobertas de rootkit no modo kernel indicam que a memória do kernel de uma VM pode ter sido adulterada por malware.

Quando você recebe uma descoberta de rootkit no modo kernel da VM Threat Detection, recomendamos que você execute estes comandos do Linux na instância do Compute Engine afetada para verificar se há pontos de dados no sistema que possam indicar anomalias, como chamadas de sistema invadidas ou módulos de kernel ocultos.

Como alternativa, é possível executar o script de coleta de dados fornecido na VM afetada. O script executa os comandos descritos nesta página.

A menos que indicado de outra forma, cada tarefa de inspeção nesta página é relevante para todas as descobertas de rootkit no modo kernel.

Neste documento, partimos do princípio que você:

  • Você está realizando as tarefas neste documento depois de receber uma descoberta de rootkit no modo kernel da VM Threat Detection. Para conferir uma lista das categorias de descoberta relevantes, consulte Descobertas de ameaças de rootkit no modo kernel.

  • Você entende as ferramentas de linha de comando do Linux e o kernel do Linux.

Sobre a VM Threat Detection

A Detecção de ameaças a máquinas virtuais é um serviço integrado do Security Command Center disponível nos níveis Enterprise e Premium. Esse serviço verifica instâncias do Compute Engine para detectar aplicativos potencialmente maliciosos, como softwares de mineração de criptomoedas, rootkits no modo kernel e malwares em execução em ambientes de nuvem comprometidos.

A VM Threat Detection faz parte do pacote de detecção de ameaças do Security Command Center e foi projetada para complementar os recursos atuais do Event Threat Detection e do Container Threat Detection.

Para informações sobre a VM Threat Detection, consulte Visão geral da Detecção de ameaças a máquinas virtuais. Para saber como acessar os detalhes de uma descoberta da detecção de ameaças à VM, consulte Analisar descobertas no console do Google Cloud.

Antes de começar

Para ter as permissões necessárias para visualizar todos os recursos e resultados no Security Command Center e gerenciar a instância do Compute Engine afetada, peça ao administrador para conceder a você os seguintes papéis do IAM:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias por meio de papéis personalizados ou de outros papéis predefinidos.

Identificar a VM afetada

  1. Confira os detalhes da descoberta.
  2. Na seção Recurso afetado, no campo Nome completo do recurso, clique no link. A visualização detalhada da instância do Compute Engine afetada é aberta em uma nova guia.
  3. Conecte-se à instância. Para mais informações, consulte Conectar-se a VMs do Linux na documentação do Compute Engine.

Encontrar módulos do kernel inesperados

A presença de módulos inesperados em uma VM pode indicar que a memória do kernel da VM está potencialmente comprometida.

Para encontrar módulos do kernel inesperados, siga estas etapas:

  1. Liste todos os módulos do kernel carregados na VM:

    lsmod
cat /proc/modules

  2. Liste as entradas sysfs dos módulos carregados e removidos:

    ls -l /sys/module/

  3. Compare os resultados dessas listas com as listas de outras VMs no projeto. Procure módulos que aparecem na VM afetada, mas não nas outras VMs.

Pesquisar syslog para módulos fora da árvore

Sinais de que um módulo fora da árvore foi carregado em uma VM podem indicar que módulos de kernel atípicos foram carregados. É possível pesquisar o buffer de registro do kernel e as mensagens syslog para determinar se um módulo fora da árvore foi carregado. Nas entradas de registro, um módulo fora da árvore é marcado como carga corrompida.

No buffer de registro do kernel e nas mensagens syslog, procure entradas de registro que se pareçam com esta:

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

  • Pesquise no buffer de registro do kernel entradas de registro que indicam a presença de módulos fora da árvore:

    sudo dmesg | grep out-of-tree

  • Pesquise todas as mensagens syslog para encontrar entradas de registro que indiquem a presença de módulos fora da árvore:

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

Verificar o livepatching

O Livepatching em uma VM pode interferir nas detecções da VM Threat Detection e acionar descobertas de falsos positivos.

Para verificar se o livepatching está ativado, siga estas etapas:

  1. Consulte syslog para instalação e geração de registros do módulo de livepatching. O patch em tempo real normalmente modifica o código do kernel instalando pontos ftrace do kernel.

    sudo grep livepatch /var/log/syslog*

  2. Procure novos módulos do kernel instalados para o livepatching (normalmente com o prefixo livepatch):

    sudo lsmod | grep livepatch

  3. Pesquise arquivos de patch:

    sudo ls -l /sys/kernel/livepatch

Para informações sobre o livepatching, consulte Livepatch na documentação do kernel do Linux.

Verificar outras atividades potencialmente maliciosas detectadas na VM

  1. No Security Command Center, confira os detalhes da descoberta da VM Threat Detection que você está investigando.
  2. Na seção Recurso afetado, no campo Nome completo do recurso, clique na seta para baixo e selecione Mostrar todas as descobertas com este nome completo do recurso. A consulta de descobertas é atualizada para mostrar apenas as descobertas dessa VM.
  3. Verifique se há descobertas que apontam para possíveis atividades de criptomineração, malware, concessões de IAM incomuns e outras ameaças à segurança.

Verificar se o software antivírus está causando um falso positivo

O software antivírus pode interferir nas detecções da VM Threat Detection e acionar descobertas de falsos positivos.

Verificar todos os processos em execução no sistema

A presença de processos inesperados pode indicar que a descoberta da VM Threat Detection é válida e que a VM foi comprometida.

  1. Liste todos os processos em execução na VM:

    ps -eAf

  2. Procure processos de depurador, como gdb, strace e pstack, que normalmente não são executados nessa VM. Os processos do depurador podem espionar outros processos.

  3. Procure outros processos suspeitos na VM.

Verificar o kernel inicializado

Verifique o kernel inicializado para identificar o kernel do Linux:

cat /proc/version

Se o valor retornado não for a versão esperada do kernel, isso poderá indicar um ataque de sequestro de controle feito com a ferramenta kexec no kernel. A ferramenta kexec pode inicializar o sistema para usar um kernel diferente.

Outras tarefas para as descobertas de Unexpected kernel code modification

As tarefas desta seção são específicas para a categoria de descoberta Defense Evasion: Unexpected kernel code modification. Realize as tarefas nas seções a seguir para verificar a validade de uma descoberta nessa categoria.

Essas seções ajudam a determinar se a VM está usando uma API de depuração. As APIs do depurador podem acionar descobertas de falsos positivos, porque podem modificar as regiões do código do kernel em execução.

Em geral, o VM Threat Detection não gera uma descoberta se detectar o uso de uma API de depurador. No entanto, se a VM estiver usando uma API de depuração desconhecida para a Detecção de ameaças da VM, ainda será possível receber um resultado falso positivo.

Verificar se os rastreadores de depuração estão ativados

Os rastreadores, exceto o rastreador nop, podem causar modificações no código do kernel. Eles podem interferir nas detecções da VM Threat Detection e acionar descobertas de falsos positivos. Em geral, se a Detecção de ameaças da VM detectar a presença de tracers, ela não vai enviar uma descoberta Defense Evasion: Unexpected kernel code modification.

Para verificar se há rastreadores de depuração ativados, siga estas etapas:

  1. Confira os rastreadores disponíveis:

    cat /sys/kernel/debug/tracing/available_tracers

    A saída será assim:

    hwlat blk mmiotrace function_graph wakeup_dl wakeup_rt wakeup function nop

  2. Verifique o rastreador atual:

    cat /sys/kernel/debug/tracing/current_tracer

    O resultado é um dos rastreadores disponíveis que foram retornados no comando anterior.

  3. Confirme se o rastreamento está ativado no sistema:

    cat /sys/kernel/debug/tracing/tracing_on

    Um valor de 1 indica que o rastreamento está ativado no sistema.

  4. Liste as CPUs em que o rastreamento está ativado:

    cat /sys/kernel/debug/tracing/tracing_cpumask

  5. Confira os detalhes do rastreamento:

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

    A saída será assim:

    Function       Hit    Time            Avg             s^2

Verificar eventos de rastreador de depuração

O monitoramento de eventos no kernel pode causar modificações no código do kernel e resultar em resultados falsos positivos da VM Threat Detection. Muitas ferramentas de depuração e monitoramento de desempenho podem ativar automaticamente o monitoramento de eventos.

Para verificar se o monitoramento de eventos está ativado, execute os seguintes comandos:

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

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

Uma saída de 0 significa que o monitoramento de eventos está desativado. Uma saída de 1 significa que o monitoramento de eventos está ativado.

Considere desativar o monitoramento de eventos para verificar se a VM Threat Detection emite as mesmas descobertas. Se as descobertas forem reduzidas, isso pode indicar que algumas das descobertas iniciais foram falsos positivos.

Verificar kprobes, regras eBPF e netfilters

Netfilters, kprobes e regras de eBPF podem acionar modificações de código porque acionam transferências de chamada para callbacks personalizados. A VM Threat Detection detecta a presença dessas sondas e as mapeia para páginas de código modificadas, sem considerar quais podem acionar falsos positivos.

Para verificar kprobes, regras eBPF e netfilters, execute o seguinte 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

Verificar se há rastreadores de depuração

A presença de rastreadores de depuração iniciais que são ativados na inicialização pode interferir nas detecções da detecção de ameaças da VM e acionar descobertas falso-positivas.

Para verificar se há rastreadores de depuração iniciais, execute o seguinte comando:

cat /proc/cmdline

Para uma lista de possíveis rastreadores de depuração iniciais, consulte Rastreamento no momento da inicialização na documentação do kernel do Linux.

Tarefa adicional para Unexpected system call handler

Execute esta tarefa se você receber uma descoberta Defense Evasion: Unexpected system call handler.

Audite as chamadas do sistema e procure anomalias no uso e nos invocadores. Os registros de auditoria fornecem informações sobre o processo de invocação e os argumentos para as chamadas do sistema. Também é possível realizar tarefas de verificação para verificar comportamentos esperados de chamadas de sistema comuns. Para mais informações, consulte Exemplo de inspeção com o rootkit Diamorphine nesta página.

Tarefa adicional para Unexpected interrupt handler

Execute esta tarefa se você receber uma descoberta Defense Evasion: Unexpected interrupt handler.

Liste os manipuladores de interrupção ao vivo no sistema e compare os resultados com informações de outras VMs semelhantes no projeto. Manipuladores de interrupção inesperados podem indicar que a VM está comprometida.

Para listar os gerenciadores de interrupção em tempo real, execute o seguinte comando:

cat /proc/interrupts

A saída será assim:

           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

Tarefa adicional para Unexpected processes in runqueue

Siga estas etapas se você receber uma descoberta Defense Evasion: Unexpected processes in runqueue. Esta seção ajuda a coletar outros pontos de dados para investigar suas descobertas. Esses pontos de dados podem não indicar diretamente um problema de malware.

Nesta tarefa, você vai analisar a fila do programador por CPU. Embora alguns processos possam ter vida curta, ainda é possível avaliar o comportamento da fila do programador com os processos em execução por CPU para procurar comportamentos anormais.

  1. Mostra detalhes sobre a quantidade de tempo que cada processo em execução passa por CPU. Isso ajuda a saber se uma CPU específica está extremamente ocupada. É possível correlacionar os resultados às interrupções fixadas na CPU em /proc/interrupts.

    cat /proc/schedstat

    Para mais informações sobre esse comando, consulte Estatísticas do Programador na documentação do kernel do Linux.

  2. Lista todas as tarefas executáveis atuais e detalhes sobre as mudanças de contexto para cada CPU.

    cat /proc/sched_debug

    A saída será assim:

    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. Procure o seguinte:

    • Nomes de processos em execução.
    • Número de trocas de contexto por CPU. Verifique se um processo está gerando poucas ou muitas mudanças na CPU.
    • Tempo de CPU gasto (tempo não ocioso).

Exemplo de inspeção com o rootkit Diamorphine

Esta seção demonstra uma inspeção de uma VM com o rootkit Diamorphine instalado. A diamorfina é um módulo de kernel carregável (LKM) muito conhecido. Esse rootkit aciona as seguintes categorias de descoberta:

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

Para mais informações sobre essas categorias de descoberta, consulte Descobertas de ameaças de rootkit no modo kernel.

As etapas de inspeção realizadas e os sintomas observados na VM são os seguintes:

  1. Pesquise syslog para todos os módulos do kernel fora da árvore que são carregados.

    1. Pesquise o buffer de registro do kernel:

      sudo dmesg | grep out-of-tree

      Saída:

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

    2. Pesquise as mensagens syslog:

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

      Saída:

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

  2. Pesquise syslog para encontrar falhas de verificação de módulo (não disponível em todas as distribuições do Linux).

    1. Pesquise o buffer de registro do kernel:

      sudo dmesg | grep "module verification failed"

      Saída:

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

    2. Pesquise as mensagens syslog:

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

      Saída:

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

  3. Confirme se o módulo está oculto dos comandos /proc/modules e lsmod.

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

    Nenhum resultado foi mostrado.

  4. Confirme se o módulo tem uma entrada em sysfs.

    sudo cat /sys/module/diamorphine/coresize

    Saída:

    16384

  5. Receba a tabela de chamadas do sistema para a arquitetura:

    sudo ausyscall --dump

    Saída:

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

    Fazer auditorias para detectar anomalias em chamadas de sistema, como kill e getdents, que normalmente são adulteradas por rootkits.

  6. Para verificar se há adulteração do gerenciador de chamadas do sistema, audite as chamadas do sistema e verifique comportamentos anormais. Esses comportamentos variam de acordo com cada chamada de sistema.

    Uma chamada de sistema que geralmente é invadida é a kill. É possível verificar se a chamada de sistema kill foi ignorada. No exemplo abaixo, a chamada de sistema kill foi auditada.

    1. Instale auditd e observe o comportamento da VM sem o 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"

      Nesse ponto da inspeção, o rootkit Diamorphine foi instalado. As próximas etapas mostram o comportamento da VM após a instalação do rootkit.

    2. Confirme que uma entrada de registro de auditoria para o sinal está ausente após a instalação do rootkit Diamorphine:

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

    3. Verifique os detalhes na entrada de registro de auditoria para conferir o indicador. Neste exemplo, embora esse sinal específico não tenha sido completamente sequestrado pelo rootkit, as informações sobre o processo de invocação estão disponíveis.

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

Depurar o script de coleta de dados

O script a seguir executa muitas das tarefas de depuração descritas nesta página. É possível executar esse script no modo sudo ou root. O script só lê informações de depuração do 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 "=================================================="

A seguir