O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Inspecionar uma VM em busca de 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 descoberta de rootkit no 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 foi potencialmente adulterada por malware.

Quando você recebe uma descoberta de rootkit no modo kernel da Detecção de ameaças a máquinas virtuais, recomendamos que você execute esses comandos do Linux na instância afetada do Compute Engine para investigar seu sistema em busca de pontos de dados que possam indicar anomalias, como chamadas de sistema sequestradas ou módulos de kernel ocultos.

Como alternativa, você pode executar o script de coleta de dados fornecido na VM afetada. O script executa os comandos descritos nesta página.

Salvo indicação em contrário, 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ê:

está realizando as tarefas neste documento depois de receber uma descoberta de rootkit no modo kernel da Detecção de ameaças a máquinas virtuais. Para conferir uma lista das categorias de descobertas relevantes, consulte Descobertas de ameaças do rootkit no modo kernel.
tem conhecimento das ferramentas de linha de comando do Linux e do kernel do Linux.

Sobre a Detecção de ameaças a máquinas virtuais

A Detecção de ameaças a máquinas virtuais é um serviço integrado do Security Command Center. Esse serviço verifica máquinas virtuais para detectar aplicativos potencialmente mal-intencionados, como software de mineração de criptomoedas, rootkits no modo kernel e malware em execução em ambientes de nuvem comprometidos.

A Detecção de ameaças a VMs faz parte do pacote de detecção de ameaças do Security Command Center e foi projetada para complementar os recursos atuais da Event Threat Detection e da Detecção de Ameaças em Contêiner.

Para mais informações sobre a Detecção de ameaças a máquinas virtuais, consulte Visão geral da Detecção de ameaças a máquinas virtuais. Para saber como conferir os detalhes de uma descoberta da Detecção de ameaças a máquinas virtuais, consulte Analisar descobertas no console.Google Cloud

Antes de começar

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

Leitor administrador da Central de segurança (roles/securitycenter.adminViewer) na organização
Administrador da instância do Compute (v1) (roles/compute.instanceAdmin.v1) na instância do Compute Engine

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 com papéis personalizados ou outros papéis predefinidos.

Identificar a VM afetada

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

Encontrar módulos de 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 de kernel inesperados, siga estas etapas:

Liste todos os módulos de kernel carregados na VM:
```
lsmod
cat /proc/modules
```
Liste as entradas sysfs para os módulos carregados e descarregados:
```
ls -l /sys/module/
```
Compare os resultados dessas listas com as de outras VMs no projeto. Procure módulos que aparecem na VM afetada, mas não nas outras.

Pesquisar `syslog` para módulos externos

Os sinais de que um módulo externo foi carregado em uma VM podem indicar que módulos de kernel atípicos foram carregados. Você pode pesquisar o buffer de registro do kernel e as mensagens syslog para determinar se um módulo externo foi carregado. Nas entradas de registro, um módulo externo é marcado como carga contaminada.

No buffer de registro do kernel e nas mensagens syslog, procure entradas de registro semelhantes a estas:

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

Pesquise no buffer de registro do kernel entradas de registro que indiquem a presença de módulos externos:
```
sudo dmesg | grep out-of-tree
```
Pesquise todas as mensagens syslog para entradas de registro que indiquem a presença de módulos externos:
```
grep "out-of-tree" /var/log/syslog*
```

Verificar se há livepatching

O livepatching em uma VM pode interferir nas detecções da Detecção de ameaças a máquinas virtuais e acionar descobertas de falsos positivos.

Para verificar se há livepatching, siga estas etapas:

Verifique syslog para instalação e registro do módulo de livepatching. O livepatching normalmente modifica o código do kernel instalando pontos ftrace do kernel.
```
sudo grep livepatch /var/log/syslog*
```
Pesquise novos módulos de kernel instalados para livepatching (normalmente prefixados com livepatch):
```
sudo lsmod | grep livepatch
```
Pesquise arquivos de patch:
```
sudo ls -l /sys/kernel/livepatch
```

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

Verificar outras atividades potencialmente mal-intencionadas detectadas na VM

No Security Command Center, confira os detalhes da descoberta da Detecção de ameaças a máquinas virtuais que você está investigando.
Na seção Recurso afetado, no campo Nome completo do recurso , clique na seta suspensa e em Mostrar todas as descobertas com esse nome completo do recurso. A consulta de descobertas é atualizada para mostrar apenas as descobertas dessa VM.
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 uma descoberta de falso positivo

O software antivírus pode interferir nas detecções da Detecção de ameaças a máquinas virtuais 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 Detecção de ameaças a máquinas virtuais é válida e que a VM foi comprometida.

Liste todos os processos em execução na VM:
```
ps -eAf
```
Procure processos de depurador, como gdb, strace e pstack, que você normalmente não executa nessa VM. Os processos de depurador podem espionar outros processos.
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 feito explorando a ferramenta kexec no kernel. A ferramenta kexec pode fazer um softboot do sistema para usar um kernel diferente.

Tarefa adicional para `Unexpected system call handler`

Realize essa tarefa se você receber uma descoberta Defense Evasion: Unexpected system call handler.

Audite as chamadas de 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 de sistema. Você também pode realizar tarefas de verificação para conferir os 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`

Realize essa tarefa se você receber uma descoberta Defense Evasion: Unexpected interrupt handler.

Liste os manipuladores de interrupção ativos 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 manipuladores de interrupção ativos, 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 você 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 ser de curta duração, ainda é possível avaliar o comportamento da fila do programador com os processos em execução por CPU para procurar comportamentos anômalos.

Mostre detalhes sobre a quantidade de tempo que cada processo em execução gasta por CPU. Isso ajuda a verificar se uma CPU específica está extremamente ocupada. É possível correlacionar os resultados com interrupções fixadas na CPU de /proc/interrupts.
```
cat /proc/schedstat
```
Para mais informações sobre esse comando, consulte Estatísticas do programador na documentação do kernel do Linux.

Liste 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 /

Procure o seguinte:
- Nomes de processos em execução.
- Número de mudanças de contexto por CPU. Verifique se um processo está causando 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 que tem o Diamorphine rootkit instalado. O Diamorphine é um módulo de kernel carregável (LKM) popular. Esse rootkit aciona as seguintes categorias de descobertas:

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 descobertas, consulte Descobertas de ameaças do rootkit no modo kernel threat findings.

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

Pesquise syslog para todos os módulos de kernel externos carregados.

Pesquise o buffer de registro do kernel:

sudo dmesg | grep out-of-tree

Saída:

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

Pesquise as mensagens syslog:

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

Saída:

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

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

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

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

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 exibido.
Confirme se o módulo tem uma entrada em sysfs.
```
sudo cat /sys/module/diamorphine/coresize
```
Saída:
```
16384
```
Receba a tabela de chamadas de sistema para a arquitetura:
```
sudo ausyscall --dump
```
Saída:
```
Using x86_64 syscall table:
0       read
1       write
2       open
3       close
```
Audite anomalias em chamadas de sistema, como kill e getdents, que normalmente são adulteradas por rootkits.

Para verificar a adulteração do manipulador de chamadas de sistema, audite as chamadas de sistema e verifique se há comportamentos anômalos. Esses comportamentos variam para cada chamada de sistema.

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

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"

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

Confirme se 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
```

Confira os detalhes na entrada de registro de auditoria do sinal. Neste exemplo, embora esse sinal específico não tenha sido completamente sequestrado pelo rootkit, as informações sobre o processo de invocador 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"

Script de coleta de dados de depuração

O script a seguir realiza 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 "=================================================="

Inspecionar uma VM em busca de sinais de adulteração da memória do kernel Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Sobre a Detecção de ameaças a máquinas virtuais

Antes de começar

Identificar a VM afetada

Encontrar módulos de kernel inesperados

Pesquisar syslog para módulos externos

Verificar se há livepatching

Verificar outras atividades potencialmente mal-intencionadas detectadas na VM

Verificar se o software antivírus está causando uma descoberta de falso positivo

Verificar todos os processos em execução no sistema

Verificar o kernel inicializado

Tarefa adicional para Unexpected system call handler

Tarefa adicional para Unexpected interrupt handler

Tarefa adicional para Unexpected processes in runqueue

Exemplo de inspeção com o rootkit Diamorphine

Script de coleta de dados de depuração

A seguir

Inspecionar uma VM em busca de sinais de adulteração da memória do kernel

Pesquisar `syslog` para módulos externos

Tarefa adicional para `Unexpected system call handler`

Tarefa adicional para `Unexpected interrupt handler`

Tarefa adicional para `Unexpected processes in runqueue`