Диспетчер задач показывает 47 процессов, а дамп памяти - 49. Два «лишних» процесса, невидимых для ОС. Причины бывают разные: завершающиеся процессы, системные артефакты, мусор от снятия дампа. Но если расхождение устойчиво и скрытые процессы ведут себя подозрительно - это классика DKOM (Direct Kernel Object Manipulation). Стандартные средства тут бесполезны, и реальное
обнаружение руткитов начинается с инструментов, которые смотрят на систему «снаружи».
Четыре инструмента - GMER, rkhunter, chkrootkit и Volatility - не на уровне man-страниц, а на уровне конкретных артефактов: что запускать, какие флаги передавать и как отличить настоящий руткит от ложного срабатывания.
Почему стандартные средства ОС не видят руткиты
Прежде чем лезть в инструменты, стоит разобраться с фундаментальной проблемой. Когда вы вызываете
на 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. Если вместо адреса
стоит адрес неизвестного драйвера - это hook
- IDT hooks - перехваты в Interrupt Descriptor Table
- IRP hooks - перехваты в стеке драйверов (часто используются руткитами типа TDSS)
- Inline hooks - подмена первых байт функций ядра на JMP к вредоносному коду
- Hidden processes - процессы, отсутствующие в PsActiveProcessList, но с выделенными ресурсами
- Hidden services/drivers - зарегистрированные, но невидимые для
драйверы
Практика работы с 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 байт функции заменены на безусловный переход. Адрес назначения
- ключевой: если он не принадлежит ни одному легитимному драйверу (проверяем через вкладку 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
записывает контрольные суммы системных файлов как baseline. Правило номер один:
никогда не запускайте
на потенциально скомпрометированной системе. Зафиксируете модифицированные бинари как «нормальные» - и rkhunter потеряет способность их обнаружить. Считайте, что вы отравили собственный эталон.
Конфигурация для Ubuntu/Debian
На Ubuntu не редактируйте
напрямую - используйте файл переопределений:
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 обходит двусвязный список
в ядре - именно его правит DKOM-руткит, удаляя свой процесс из цепочки
- psscan сканирует всю физическую память, ищет структуры
по сигнатуре пула (
). Найдёт процесс, даже если тот вырезан из списка
- psxview (только Volatility 2) объединяет несколько методов и показывает расхождения. В Volatility 3 аналогичный результат - ручное сравнение
и
Процесс виден в 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......
Видите
(PE-заголовок) внутри памяти svchost.exe без mapped файла? Это внедрённая DLL. Руткит (или его компонент) загрузил исполняемый код прямо в память легитимного процесса. svchost.exe - излюбленная мишень, потому что его экземпляров в системе десятки, и лишний не бросается в глаза.
Анализ SSDT hooks через Volatility
Bash:
Код:
# Проверка модификаций SSDT
python3 vol.py -f memdump.raw windows.ssdt
Нормальная запись SSDT указывает на функции в
или
. Адрес, принадлежащий неизвестному модулю - перехват (Hijack Execution Flow, T1574). Прямая модификация SSDT актуальна преимущественно для 32-битных систем и Windows до Vista SP1; на 64-битных Windows 7+ Kernel Patch Protection (PatchGuard) защищает SSDT, и современные руткиты используют другие методы: callback-объекты, filter drivers, hypervisor-based подходы. Для определения модуля-владельца каждого адреса сопоставляйте вывод
с диапазонами из
. Записи, указывающие не на
и не на
, требуют расследования.
Анализ загруженных модулей ядра
Bash:
Код:
# Список драйверов/модулей ядра
python3 vol.py -f memdump.raw windows.modules
# Для Linux-дампов
python3 vol.py -f memdump.lime linux.lsmod
Ищем модули без цифровой подписи, с подозрительными именами или загруженные из нестандартных путей. Руткит, использующий технику Kernel Modules and Extensions (T1547.006), будет виден здесь как загруженный модуль - даже если
на живой системе его не показывает.
Методология обнаружения руткитов: пошаговый алгоритм
Одиночный инструмент полной картины не даст. Ниже - алгоритм, который я использую при 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
Напомню: после каждого
запускайте
Код:
sudo rkhunter --propupd
, чтобы обновить baseline. Без этого следующий скан выдаст десятки ложных warnings на обновлённые бинари, и реальное предупреждение утонет в шуме. На одном проекте мы именно так чуть не пропустили подменённый
- потому что весь отчёт был забит предупреждениями после обновления 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 угрозы, которые прячутся от стандартных средств ОС.
Снимите дамп памяти с любого своего сервера и прогоните через
/
. Если pslist и psscan показывают одинаковое число процессов - спите спокойно. Если нет - у вас есть чем заняться на выходных.
Древовидный вид