ANTICHAT - Обнаружение руткитов на практике: GMER, chkrootkit, rkhunter и Volatility

https://forum.antichat.xyz/attachmen...c01f51d6d4.png

Диспетчер задач показывает 47 процессов, а дамп памяти - 49. Два «лишних» процесса, невидимых для ОС. Причины бывают разные: завершающиеся процессы, системные артефакты, мусор от снятия дампа. Но если расхождение устойчиво и скрытые процессы ведут себя подозрительно - это классика DKOM (Direct Kernel Object Manipulation). Стандартные средства тут бесполезны, и реальное обнаружение руткитов начинается с инструментов, которые смотрят на систему «снаружи».

Четыре инструмента - GMER, rkhunter, chkrootkit и Volatility - не на уровне man-страниц, а на уровне конкретных артефактов: что запускать, какие флаги передавать и как отличить настоящий руткит от ложного срабатывания.
Почему стандартные средства ОС не видят руткиты
Прежде чем лезть в инструменты, стоит разобраться с фундаментальной проблемой. Когда вы вызываете

Код:

ps aux

на Linux или открываете Task Manager на Windows, ОС обращается к своим внутренним структурам - списку процессов в ядре. Руткит уровня ядра (kernel rootkit, техника T1014 по MITRE ATT&CK, тактика Defense Evasion; описана для Linux и Windows, хотя автоматизированные тесты Atomic Red Team пока доступны только для Linux) правит именно эти структуры. ОС честно говорит «всё чисто» - потому что из её точки зрения так и есть. Её просто обманули.

Kernel-руткиты - самые опасные (полная классификация по типам и векторам атаки - в обзоре техник руткитов с матрицей обнаружения): они перехватывают через SSDT hooking (System Service Descriptor Table), подменяют указатели в IDT (Interrupt Descriptor Table) или манипулируют DKOM напрямую.

Ключевой принцип обнаружения - кросс-обзор (cross-view detection). Идея простая как лом: сравниваем то, что видит ОС, с тем, что видит инструмент, работающий на другом уровне. Расхождения - следы руткита.
Маппинг на MITRE ATT&CK
Руткиты задействуют целый кластер техник, и понимание маппинга критично для threat hunting:

Техника MITRE ATT&CKТактикаКак проявляетсяRootkit (T1014)Defense EvasionСкрытие процессов, файлов, сетевых соединенийCredential API Hooking (T1056.004)Collection, Credential AccessНекоторые руткиты (банковские, например) совмещают скрытие с перехватом API (LogonUser, CredRead) для кражи учётокHijack Execution Flow (T1574)Persistence, Privilege Escalation, Defense EvasionSSDT, IDT, inline hooksKernel Modules and Extensions (T1547.006)Persistence, Privilege EscalationЗагрузка вредоносных LKM/драйверовProcess Injection (T1055)Defense Evasion, Privilege EscalationВнедрение кода в легитимные процессыHidden File System (T1564.005)Defense EvasionСкрытые FS для хранения payloadDisable or Modify Tools (T1562.001)Defense EvasionПодавление работы антируткитов

GMER - обнаружение руткитов Windows через анализ ядра
GMER - бесплатный антируткит для Windows, работающий по принципу кросс-обзора. Важно: последнее обновление - около 2014 года, и на Windows 10/11 с включённым Secure Boot, HVCI или Credential Guard он может устроить BSOD. Для современных Windows лучше взять Windows Defender Offline, YARA-сканирование или Volatility с дампом памяти. А вот для legacy-систем (Windows 7/XP) GMER по-прежнему хорош. Он сканирует SSDT, IDT, таблицу дескрипторов, IRP-хуки драйверов и сравнивает с эталоном. Это не сигнатурный сканер - GMER ищет аномалии в поведении ядра.
Что именно проверяет GMER
При запуске выполняется несколько категорий проверок:

SSDT hooks - модифицированные записи в System Service Descriptor Table. Если вместо адреса

Код:

ntoskrnl.exe

стоит адрес неизвестного драйвера - это hook
IDT hooks - перехваты в Interrupt Descriptor Table
IRP hooks - перехваты в стеке драйверов (часто используются руткитами типа TDSS)
Inline hooks - подмена первых байт функций ядра на JMP к вредоносному коду
Hidden processes - процессы, отсутствующие в PsActiveProcessList, но с выделенными ресурсами
Hidden services/drivers - зарегистрированные, но невидимые для

Код:

sc query

драйверы

Практика работы с GMER
Запускаем с правами администратора. При старте GMER автоматически делает быстрое сканирование. Вкладка Rootkit/Malware - сюда смотрим в первую очередь.

Критический момент: GMER нужно запускать до установки антивируса или параллельно. Многие антивирусы сами ставят легитимные хуки ядра, и GMER их покажет как аномалии. Это не ложное срабатывание в привычном смысле - hook реальный, но легитимный. Отличить один от другого можно по адресу: если hook ведёт в модуль известного антивируса - всё нормально.

На что обращать внимание в выводе:

Код:

Код:

.text  ntkrnlpa.exe!ZwCallbackReturn + 2C08  804E26C8  5 Bytes  JMP 00643F5A

# Пример с 32-битной Windows XP (PAE). На других версиях адреса и имя ядра будут отличаться (например, ntoskrnl.exe).

Inline hook в ядре - первые 5 байт функции заменены на безусловный переход. Адрес назначения

Код:

00643F5A

- ключевой: если он не принадлежит ни одному легитимному драйверу (проверяем через вкладку Modules), перед вами артефакт руткита.

Красные строки в GMER - не приговор. Лично я неоднократно видел, как GMER подсвечивал хуки от Kaspersky, ESET и даже от драйверов VirtualBox. Алгоритм простой: красная строка → смотрим адрес → определяем модуль → если модуль легитимный, игнорируем.
rkhunter - проверка системы Linux на руткиты
rkhunter (Rootkit Hunter) - стандартный инструмент для обнаружения руткитов Linux, работающий по двум принципам: сигнатурная проверка (известные файлы/директории руткитов) и integrity checking (сравнение контрольных сумм системных бинарей с эталоном).
Установка и первичная настройка

Bash:

Код:

sudo

apt-get

update

sudo

apt-get

install

-y rkhunter

rkhunter --version

Сразу после установки на заведомо чистую систему:

Bash:

Код:

# Обновляем базу сигнатур руткитов

sudo

rkhunter --update

# Фиксируем текущее состояние бинарей как эталон

sudo

rkhunter --propupd

Код:

--propupd

записывает контрольные суммы системных файлов как baseline. Правило номер один: никогда не запускайте

Код:

--propupd

на потенциально скомпрометированной системе. Зафиксируете модифицированные бинари как «нормальные» - и rkhunter потеряет способность их обнаружить. Считайте, что вы отравили собственный эталон.
Конфигурация для Ubuntu/Debian
На Ubuntu не редактируйте

Код:

/etc/rkhunter.conf

напрямую - используйте файл переопределений:

Bash:

Код:

sudo

tee

/etc/rkhunter.conf.local



pslist.txt

python3 vol.py -f memdump.raw windows.psscan

>

psscan.txt

# diff pslist.txt psscan.txt

Ключевой приём: pslist vs psscan vs psxview
Здесь кроется суть кросс-обзорного обнаружения:

pslist обходит двусвязный список

Код:

PsActiveProcessList

в ядре - именно его правит DKOM-руткит, удаляя свой процесс из цепочки
psscan сканирует всю физическую память, ищет структуры

Код:

_EPROCESS

по сигнатуре пула (

Код:

Proc

). Найдёт процесс, даже если тот вырезан из списка
psxview (только Volatility 2) объединяет несколько методов и показывает расхождения. В Volatility 3 аналогичный результат - ручное сравнение

Код:

windows.pslist

и

Код:

windows.psscan

Процесс виден в psscan, но отсутствует в pslist? Классический артефакт DKOM-руткита. Именно так ловились руткиты семейства Necurs и TDSS - они прятали свои драйверы, удаляя записи из ядерных списков, но физическую память-то не затирали.
Поиск вредоносного кода в памяти процессов

Bash:

Код:

# malfind - ищет инъецированный код (PAGE_EXECUTE_READWRITE без mapped file)

python3 vol.py -f memdump.raw windows.malfind

malfind ищет регионы памяти с правами на исполнение, не имеющие соответствующего файла на диске. Прямой индикатор техники Process Injection (T1055) - код записан в адресное пространство процесса динамически.

Типичный вывод:

Код:

Код:

Process: svchost.exe  PID: 1284

  VAD: 0x7f0000 - 0x7f1000  Protection: PAGE_EXECUTE_READWRITE

  Flags: CommitCharge

  Hexdump:

    4d 5a 90 00 03 00 00 00  MZ......

Видите

Код:

MZ

(PE-заголовок) внутри памяти svchost.exe без mapped файла? Это внедрённая DLL. Руткит (или его компонент) загрузил исполняемый код прямо в память легитимного процесса. svchost.exe - излюбленная мишень, потому что его экземпляров в системе десятки, и лишний не бросается в глаза.
Анализ SSDT hooks через Volatility

Bash:

Код:

# Проверка модификаций SSDT

python3 vol.py -f memdump.raw windows.ssdt

Нормальная запись SSDT указывает на функции в

Код:

ntoskrnl.exe

или

Код:

win32k.sys

. Адрес, принадлежащий неизвестному модулю - перехват (Hijack Execution Flow, T1574). Прямая модификация SSDT актуальна преимущественно для 32-битных систем и Windows до Vista SP1; на 64-битных Windows 7+ Kernel Patch Protection (PatchGuard) защищает SSDT, и современные руткиты используют другие методы: callback-объекты, filter drivers, hypervisor-based подходы. Для определения модуля-владельца каждого адреса сопоставляйте вывод

Код:

windows.ssdt

с диапазонами из

Код:

windows.modules

. Записи, указывающие не на

Код:

ntoskrnl.exe

и не на

Код:

win32k.sys

, требуют расследования.
Анализ загруженных модулей ядра

Bash:

Код:

# Список драйверов/модулей ядра

python3 vol.py -f memdump.raw windows.modules

# Для Linux-дампов

python3 vol.py -f memdump.lime linux.lsmod

Ищем модули без цифровой подписи, с подозрительными именами или загруженные из нестандартных путей. Руткит, использующий технику Kernel Modules and Extensions (T1547.006), будет виден здесь как загруженный модуль - даже если

Код:

lsmod

на живой системе его не показывает.
Методология обнаружения руткитов: пошаговый алгоритм
Одиночный инструмент полной картины не даст. Ниже - алгоритм, который я использую при incident response, когда есть подозрение на руткит.
Шаг 1. Сбор volatile-данных (до перезагрузки)
Работаем с доверенными инструментами, запущенными с USB-накопителя. Бинари на скомпрометированной системе могут быть подменены - доверять им нельзя.

Bash:

Код:

# Снимаем дамп памяти

# Windows: winpmem / Linux: LiME

# Фиксируем сетевые соединения

netstat

-anob

>

connections.txt

# Windows

ss -tunap

>

connections.txt

# Linux

# Список процессов

tasklist /v

>

processes.txt

# Windows

ps

auxf

>

processes.txt

# Linux

# Загруженные модули ядра

lsmod

>

modules.txt

# Linux

driverquery /v

>

drivers.txt

# Windows

Шаг 2. Живое сканирование (на подозрительной системе)

Bash:

Код:

# Windows

# Запуск GMER - анализ хуков, скрытых процессов, драйверов

# Linux

sudo

rkhunter --check --skip-keypress --report-warnings-only

sudo

chkrootkit -q

Запускаем оба Linux-сканера - они дополняют друг друга. rkhunter лучше работает с integrity checking, chkrootkit - с сигнатурным обнаружением LKM-руткитов.
Шаг 3. Офлайн-анализ дампа памяти

Bash:

Код:

# Кросс-обзорный анализ процессов (psxview недоступен в Vol3, сравниваем вручную)

python3 vol.py -f memdump.raw windows.pslist

python3 vol.py -f memdump.raw windows.psscan

# Поиск инъекций

python3 vol.py -f memdump.raw windows.malfind

# Анализ SSDT

python3 vol.py -f memdump.raw windows.ssdt

# Сетевые соединения из памяти

python3 vol.py -f memdump.raw windows.netscan

Шаг 4. Сравнение результатов

Что сравниваемИнструмент 1Инструмент 2Расхождение = подозрениеЧисло процессовpslist (Volatility)psscan (Volatility)Скрытые процессы (DKOM)Процессы ОС vs дампTask Manager / pspslist vs psscan (Volatility)Руткит скрывает от ОССетевые соединенияnetstat / ssnetscan (Volatility)Скрытые C2-каналыМодули ядраlsmod / driverquerymodules (Volatility)Скрытые драйверы

Автоматизация сканирования и интеграция в IR-процесс
Для серверов с непрерывным контролем - rkhunter и chkrootkit в одном скрипте с почтовыми уведомлениями:

Bash:

Код:

#!/bin/bash

# rootkit-scan.sh - ежедневный скан с отчётом

HOSTNAME

=

$(hostname)

DATE

=

$(date '+%Y-%m-%d %H:%M:%S')

EMAIL

=

"security@company.local"

RKHUNTER_LOG

=

"/var/log/rkhunter.log"

CHKROOTKIT_LOG

=

"/var/log/chkrootkit.log"

echo

"=== Rootkit Scan: $HOSTNAME - $DATE ==="

>

/tmp/scan_report.txt

# rkhunter

sudo

rkhunter --check --skip-keypress --logfile

"$RKHUNTER_LOG"

2>

&1

RKHUNTER_WARNINGS

=

$(grep -ci '^Warning:' "$RKHUNTER_LOG" 2>/dev/null || echo 0)

echo

"rkhunter warnings: $RKHUNTER_WARNINGS"

>>

/tmp/scan_report.txt

grep

-i

'^Warning:'

"$RKHUNTER_LOG"

>>

/tmp/scan_report.txt

2>

/dev/null

# chkrootkit

sudo

chkrootkit -q

2>

&1

|

tee

"$CHKROOTKIT_LOG"

>>

/tmp/scan_report.txt

INFECTED

=

$(grep -c "INFECTED" "$CHKROOTKIT_LOG" 2>/dev/null || echo 0)

echo

"chkrootkit infected: $INFECTED"

>>

/tmp/scan_report.txt

# Отправляем отчёт

if

[

"$RKHUNTER_WARNINGS"

-gt

0

]

||

[

"$INFECTED"

-gt

0

]

;

then

SUBJECT

=

"[ALERT] Rootkit warnings on $HOSTNAME"

else

SUBJECT

=

"[OK] Rootkit scan clean - $HOSTNAME"

fi

mail -s

"$SUBJECT"

"$EMAIL"

<

/tmp/scan_report.txt

rm

-f /tmp/scan_report.txt

Активация через cron:

Bash:

Код:

sudo

chmod

+x /usr/local/bin/rootkit-scan.sh

echo

"0 4 * * * root /usr/local/bin/rootkit-scan.sh"

|

sudo

tee

/etc/cron.d/rootkit-scan

Напомню: после каждого

Код:

apt upgrade

запускайте

Код:

sudo rkhunter --propupd

, чтобы обновить baseline. Без этого следующий скан выдаст десятки ложных warnings на обновлённые бинари, и реальное предупреждение утонет в шуме. На одном проекте мы именно так чуть не пропустили подменённый

Код:

ss

- потому что весь отчёт был забит предупреждениями после обновления glibc.
Сравнение инструментов: что, когда и зачем

КритерийGMERrkhunterchkrootkitVolatilityО СWindowsLinuxLinuxWindows/Linux/macOSТип анализаКросс-обзор ядраСигнатуры + integrityСигнатуры + LKMФорензика памятиKernel rootkitsДаЧастичноЧастичноДаUs erland rootkitsЧастичноДаДаДаНужен дамп памятиНетНетНетДаОфлайн-анализНетНетДа (-r флаг)ДаЛожноположительные� �реднеВысокоСреднеНизкоСл� �жность интерпретацииСредняяНизка яНизкаяВысокая

Ни один инструмент не самодостаточен. GMER и chkrootkit/rkhunter работают на живой системе и зависят от её состояния - если руткит перехватил достаточно низкоуровневые функции, он обманет и антируткит. Volatility анализирует «снимок» памяти и после снятия дампа его не обмануть - но для работы с ним нужны навыки форензики и чистая forensics-станция.

Оптимальная комбинация: живое сканирование GMER (Windows) или rkhunter + chkrootkit (Linux) для быстрой оценки, затем дамп памяти и Volatility для подтверждения. Этот подход закрывает и обнаружение руткитов на уровне пользователя, и kernel-level угрозы, которые прячутся от стандартных средств ОС.

Снимите дамп памяти с любого своего сервера и прогоните через

Код:

windows.psscan

Код:

linux.pslist

. Если pslist и psscan показывают одинаковое число процессов - спите спокойно. Если нет - у вас есть чем заняться на выходных.