Как обнаружить memory-resident вирусы в ядре операционной системы

Когда антивирус ничего не находит, а система ведёт себя странно — тормозит, подозрительно грузит процессор, блокирует доступ к своим же файлам, — скорее всего, вы имеете дело с вирусом, который живёт в памяти и внедрился на уровень ядра. Это один из самых неприятных типов вредоносного кода: он загружается вместе с системой, прячется от стандартных средств проверки и сохраняет контроль над машиной даже после перезагрузки. Разберёмся, как такие вещи обнаружить и что с ними делать.

Почему memory-resident вирусы в ядре — это отдельная проблема

Обычный вирус живёт на диске — в файле, в загрузочном секторе, в макросе. Его легко найти сигнатурным или эвристическим сканированием. Другое дело — код, который загружается в оперативную память и работает в контексте ядра ОС (ring 0). Он:

• Получает полный контроль над системой, включая доступ к аппаратному обеспечению.
• Может подменять системные функции — под system calls в Windows или syscalls в Linux.
• Перехватывает вызовы файловой системы, сети и драйверов, скрывая свои файлы и трафик.
• Не существует как отдельный файл на диске, поэтому обычный антивирус его не видит.
• Если это руткит уровня ядра — он загружается раньше безопасности и может её отключить.

Поиск таких вещей требует подхода, при котором вы смотрите не на файлы, а на то, что система делает в реальном времени — на аномалии в памяти, поведении, структурах данных ядра.

Косвенные признаки: когда стоит заподозрить неладное

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

• Система загружается значительно дольше, чем раньше, без видимых причин.
• В автозагрузке появились неизвестные службы или драйверы, особенно с неразборчивыми именами или под видом системных.
• Диспетчер задач или системные мониторы не показывают подозрительный процесс, но нагрузка на CPU или диск держится на высоком уровне при простое.
• Антивирус или средства защиты не запускаются, не обновляются или отключаются без вашего вмешательства.
• Сетевой трафик есть, но вы не можете определить, какая программа его генерирует — соединения привязаны к системным процессам.
• Файлы или папки не удаляются, выдавая ошибку «доступ запрещён», даже если вы администратор.

Если вы наблюдаете несколько признаков одновременно — это серьёзный повод для детального анализа.

Метод 1: анализ загруженных модулей ядра

Любой вирус, работающий в пространстве ядра, зарегистрирован как модуль или драйвер. Ваша задача — найти то, что там быть не должно.

На Linux

Команда lsmod покажет список загруженных модулей. Для каждого из них проверьте:

1. Название — оно должно соответствовать известному драйверу или модулю. Подозрительны модули с буквально сгенерированными именами вроде drv_hid, sys_core_temp или kernel_mod_2024.
2. Использующие процессы — если модуль никем не используется, но при этом загружен, это аномалия.
3. Путь к файлу — modinfo <имя_модуля> покажет путь к файлу .ko. Сверьте его с каталогом /lib/modules/$(uname -r)/. Модуль вне стандартного каталога — красный флаг.

Для глубокой проверки загрузите утилиту rkhunter или chkrootkit. Они проверяют известные сигнатуры руткитов и аномалии в системных бинарниках:

rkhunter --check --skip-keypress

На Windows

В Windows kernel-mode драйверы можно посмотреть через:

• Autoruns от Sysinternals — фильтруйте вкладку «Drivers» и ищите неподписанные или подозрительные записи.
• DriverQuery — встроенная утилита командной строки: driverquery /v /fo csv. Анализируйте список на предмет неизвестных драйверов.
• Sigcheck (тоже Sysinternals): sigcheck -c -h -u покажет драйверы без валидной цифровой подписи.

Особое внимание — на драйверы без подписи Microsoft или известного производителя. В современной системе их быть не должно, если вы не ставили что-то специфическое (например, драйверы виртуализации).

Метод 2: поведенческий анализ через системные вызовы

Memory-resident вирусы в ядре часто перехватывают системные вызовы — это называется hooking. Вы не увидите сам код, но можете заметить аномалии в работе системы.

Проверка на subgroup hooks (Windows)

Утилита GMER (хотя и старая, до сих пор работает) сканирует SSDT (System Service Dispatch Table), IDT (Interrupt Descriptor Table) и другие ключевые структуры ядра. Если адреса обработчиков системных вызовов не указывают на стандартные модули ntoskrnl.exe или win32k.sys — внедрение есть.

Альтернатива — современный System Informer (бывший Process Hacker): вкладка «Services» показывает драйверы, а раздел «Hooks» позволяет увидеть подмены.

Проверка на syscall hooks (Linux)

Прямой доступ к таблице системных вызовов можно получить через:

sudo cat /proc/kallsyms | grep sys_call_table

Сравните текущие адреса обработчиков с теми, что были при чистой загрузке. Если адрес syscall_open или syscall_write указывает не на модуль ядра, а на подозрительный адрес в памяти — у вас проблему с руткитом.

Более удобный вариант — использовать bpftrace:

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%s %d\n", comm, pid); }'

Вы увидите, какие процессы вызывают тот или иной syscall. Если системный вызов используется процессом, которого вы не запускали, — разберитесь, кто это.

Метод 3: проверка целостности ядра

Этот подход основан на сравнении текущего состояния системы с эталонным или проверке цифровых подписей критических компонентов.

Linux: IMA/EVM и AIDE

IMA (Integrity Measurement Architecture) — встроенный в ядро механизм проверки целостности файлов. Если он настроен, любое изменение системных бинарников или конфигураций будет зафиксировано.

Если IMA не настроен — используйте AIDE (Advanced Intrusion Detection Environment):

1. Установите и инициализируйте базу данных на чистой системе: aide --init.
2. После подозрительного инцидента запустите: aide --check.
3. Результат покажет, какие файлы были изменены, добавлены или удалены.

Ключевой момент: база данных AIDE должна храниться вне исследуемой системы (на внешнем носителе или удалённом сервере), иначе вирус может её подменить.

Windows: проверка подписей и целостности

• System File Checker: sfc /scannow проверяет целостность системных файлов Windows. Если обнаружены изменения, и система не может восстановить оригиналы — это тревожный сигнал.
• Windows Defender Offline: запускайте его через «Безопасность Windows» → «Защита от вирусов и угроз». Выберите «Проверка автономного Защитника Windows». Этот режим перезагрузит систему и проверит её до загрузки основной ОС — что важно, потому что memory-resident вирус в ядре может прятаться, пока система работает.
• Device Guard / VBS: если включены, они не дают загрузиться неподписанному коду в ядро. Проверить состояние: msinfo32 → «Virtualization-based Security».

Метод 4: дамп памяти и офлайн-анализ

Если вирус глубоко в ядре, он может перехватывать запросы на чтение собственных структур — и вы ничего не увидите, анализируя работающую систему. Выход — снять дамп памяти и анализировать его отдельно.

Снятие дампa

• Linux: используйте LiME (Linux Memory Extractor): sudo insmod lime.ko "path=/tmp/dump.lime format=lime". Дампируется вся физическая память в формате, пригодном для анализа в Volatility.
• Windows: утилита WinPmem (часть Rekall), или встроенный механизм через «Система» → «Дополнительные параметры системы» → «Загрузка и восстановление» → настройки дампа памяти. Для полного дампа выберите «Полный дамп памяти».

Анализ дампa

Для анализа используйте Volatility 3:

1. Определите профиль системы: python3 vol.py -f dump.raw windows.info.
2. Список процессов: python3 vol.py -f dump.raw windows.pslist.PsList. Сверьте с тем, что видит система сейчас — некоторые процессы могут быть «скрыты», но присутствовать в дампе.
3. Загруженные модули: python3 vol.py -f dump.raw windows.modules.Modules. Ищите модули, которых вам не знакомы.
4. Проверка на наличие руткитов: python3 vol.py -f dump.raw windows.ldrmodules.LdrModules — покажет расхождения между видимыми и невидимыми модулями.

Преимущество офлайн-анализа в том, что вирус не может мешать исследованию — вы смотрите «мёртвый» снимок памяти.

Метод 5: мониторинг в реальном времени

Если вы подозрезаете kernel-level заражение, но хотите отследить его динамически — подходит мониторинг с использованием eBPF на Linux или ETW на Windows.

Linux: eBPF и bpftrace

eBPF позволяет безопасно отслеживать события ядра без модификации его кода. Примеры того, что можно отследить:

• Необычные execve-вызовы — запуск процессов из неожиданных мест (например, из /tmp или /dev/shm).
• Подозрительные обращения к сетевым сокетам — исходящие соединения от процессов, которые не должны работать с сетью.
• Изменения прав доступа через chmod или setuid.

Установите bpftrace и смотрите в реальном времени:

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s: %s\n", comm, str(args->filename)); }'

Windows: Event Tracing for Windows

Встроенный механизм ETW фиксирует системные события на уровне ядра. Для записи трассировок используйте logman или инструменты вроде Windows Performance Recorder. Анализировать результаты удобно в Windows Performance Analyzer или TraceView.

В ETW обращайте внимание на:

• Image Load — загрузка неподписанных DLL или SYS-файлов в системных процессах.
• Network — подозрительные соединения от ntoskrnl.exe или других ядерных модулей.
• Process Start — новые процессы, которые запускаются из неожиданных путей или с необычными родительскими процессами.

Метод 6: сравнение с чистой системой

Один из самых действенных способов — не искать вирус, а найти отличия между заражённой и заведомо чистой системой.

1. Сделайте список загруженных модулей ядра на чистой машине с аналогичной конфигурацией (lsmod или driverquery).
2. Сравните списки на заражённой машине.
3. Также сравните содержимое файлов /proc/modules (Linux) или ключей реестра HKLM\SYSTEM\CurrentControlSet\Services (Windows).

Любое расхождение — повод для детального изучения нового модуля. Найдите его файл на диске и проверьте:

• Есть ли у него цифровая подпись.
• Кто разработчик (для Windows — смотрите свойства файла → «Цифровые подписи»).
• Что он делает — загуглите имя файла, название компании, путь расположения.
• Совпадает ли хеш-сумма с официальными версиями от производителя.

Сравнение подходов: когда какой метод применять

Метод	Чувствительность	Требует чистой системы	Сложность	Когда использовать
Анализ модулей ядра	Средняя	Нет	Низкая	Первичная диагностика
Поведенческий анализ через системные вызовы	Высокая для руткитов с хуками	Нет	Средняя	Если есть подозрение на перехват syscall
Проверка целостности ядра	Средняя-высокая	Для AIDE — да	Средняя	Периодический аудит
Дамп памяти и офлайн-анализ	Очень высокая	Нет	Высокая	При подозрении на сложный руткит
Мониторинг в реальном времени	Высокая	Нет	Средняя-высокая	Для отслеживания активности вируса
Сравнение с чистой системой	Средняя (зависит от полноты сравнения)	Да	Низкая	Когда есть эталонная система

Частые ошибки при обнаружении

• Полагаться только на антивирус. Большинство бытовых антивирусов не видят kernel-mode руткитов. Это не значит, что антивирус бесполезен — но его «чисто» не является доказательством отсутствия заражения.
• Сканировать работающую систему и доверять результату. Глубоко сидящий в ядре код может перехватывать запросы антивируса и показывать «чистоту». Используйте офлайн-проверки.
• Игнорировать неподписанные драйверы. Если вы не устанавливали софт без подписи (а в большинстве случаев не должны были) — любой неподписанный драйвер подозрителен.
• Не обновлять базы для проверки целостности. AIDE, rkhunter и подобные инструменты должны быть настроены на подключённой к интернету системе или иметь актуальные базы вне её.
• Удалять файл, не разобравшись. Kernel-модуль может быть критически важен для работы оборудования или сервисов. Убедитесь, что файл действительно вредоносный, перед удалением.

Что делать в зависимости от вашей ситуации

Если вы сисадмин и подозрезаете заражение сервера: снимите дамп памяти (LiME + Volatility на Linux, WinPmem на Windows), запустите rkhunter/chkrootkit, проверьте все загруженные модули. Перед началnм машину лучше отключить от сети, чтобы остановить возможный трафик управления.

Если это домашний компьютер: воспользуйтесь автономной проверкой Windows Defender Offline или загрузочным антивирусом (Kaspersky Rescue Disk, ESET SysRescue). Они работают вне основной ОС и могут обнаружить kernel-руткиты.

Если нужно быстро оценить масштаб: запустите Autoruns или lsmod, сверьте с результатами на чистой машине или поищите незнакомые модули в интернете. Если найдены подозрительные элементы — переходите к глубокому анализу с дампом памяти.

Если система сильно повреждена и не загружается: загрузитесь с внешнего носителя (Live USB) и проанализируйте файловую систему. Проверьте каталоги автозагрузки, наличие подозрительных .ko или .sys файлов, целостность системных библиотек.

Практические рекомендации

1. Всегда используйте несколько методов. Один способ может не обнаружить вирус, а комбинация — с высокой вероятностью выявит даже сложный руткит.
2. Делайте эталонные снимки. После установки системы зафиксируйте список модулей ядра, загружаемых драйверов и служб. Это сэкономит время при будущем расследовании.
3. Включите защиту загрузчика. Secure Boot на UEFI не даст загрузиться неподписанному ядру или модулям. GRUB password на Linux — аналогично. Это не панацея (существуют bootkits), но значительно повышает порог входа для атакующего.
4. Ограничьте загрузку модулей. На Linux можно запретить загрузку модулей после загрузки системы: sysctl kernel.modules_disabled=1 (необратимо до перезагрузки). На Windows — включить Driver Signature Enforcement.
5. Анализируйте в изолированной среде. Если нашли подозрительный файл или модуль — не исследуйте его на заражённой машине. Перенесите в виртуальный стенд и анализируйте там.

Итог

Memory-resident вирусы в ядре ОС — редкие, но крайне опасные. Они требуют комбинированного подхода: анализ модулей ядра, проверка поведения системы, при необходимости — дамп памяти и офлайн-анализ. Не надейтесь на один антивирус. Используйте автономные инструменты, сверяйте с эталонами и не игнорируйте косвенные признаки. Если не уверены в своих силах — привлеките специалиста по информационной безопасности, а не пытайтесь лечить систему «на удачу» — с ядерным руткитом это не работает.