Форензика памяти ядра Windows, снятие образа оперативной памяти и извлечение ключей при расследовании

Когда система скомпрометирована, диск врёт чаще, чем признаётся: злоумышленник давно научился подчищать журналы и маскировать файлы. Память - другое дело. В момент снятия образа оперативной памяти там честно лежат расшифрованные ключи, открытые сессии, загруженные драйверы и кусочки паролей, которые вредоносный код просто не успел выбросить. Разберём, как устроена экспертиза оперативной памяти уровня ядра, чем реально извлекаются криптографические ключи из живого дампа и как делать это легально и методично.

Что такое форензика памяти и чем она отличается от анализа диска

Криминалистика памяти оперирует слепком ОЗУ, снятым в момент, когда инцидент ещё горяч. В отличие от образа диска, где данные терпеливо ждут, память хранит исполняющееся состояние: таблицы процессов ядра, списки драйверов, сетевые соединения вместе с их ключами сессии, кэши учётных данных, содержимое криптографических провайдеров. Именно поэтому золотое правило реагирования звучит жёстко: сначала память, потом диск. Порядок обратный - и самые ценные доказательства растворились при перезагрузке или выключении.

Снять образ помогают несколько семейств средств. Встроенный механизм аварийного дампа ядра пишет полный дамп физической памяти по событию остановки системы, и заранее настроенный полный дамп - добрая половина готовности к расследованию. Включается он одной командой от администратора:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl" `
    -Name CrashDumpEnabled -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl" `
    -Name AlwaysKeepMemoryDump -Value 1 -Type DWord
Get-CimInstance Win32_OSRecoveryConfiguration | Select-Object DebugInfoType,MiniDumpDirectory

Значение DebugInfoType равное единице соответствует полному дампу. Место под файл размером с физическую память закладывают заранее, иначе в нужный момент система соберёт урезанный слепок. Специализированные инструменты на базе драйверов чтения физической памяти (исторически это семейство решений, среди которых широко известен WinPmem и его преемники) снимают память на живой машине без остановки. В виртуализационных средах картина проще: гипервизор ставит гостя на паузу и возвращает файл снабдившего снимка памяти, что считается самым чистым способом, потому что память не "бежит" во время снятия.

Дальше образ уходит к аналитику. С этого момента начинается работа, ради которой всё затевалось.

Как построен анализ образа памяти

Инструментарий анализа держится на открытых рамках: главным стандартом де-факто является Volatility - среда с плагинами, знающая внутренние структуры ядра разных версий Windows. Типовой прогон выглядит как последовательность коротких команд:

vol -f mem.raw windows.info
vol -f mem.raw windows.pslist
vol -f mem.raw windows.psscan
vol -f mem.raw windows.modules
vol -f mem.raw windows.driverscan
vol -f mem.raw windows.netscan
vol -f mem.raw windows.callbacks
vol -f mem.raw windows.malfind

Первым делом среда определяет версию системы, построившей дамп, по сигнатурам начальной настройки, и команда windows.info печатает её вместе с адресом структуры отладки. Дальше плагины обходят связанные списки ядра: процессы через pslist и её сканирующий аналог psscan, драйверы через modules и driverscan, затем открытые дескрипторы, сетевые подключения, зарегистрированные обратные вызовы и таймеры.

Наблюдательный читатель заметит принцип: все эти объекты соединены указателями, и анализатор ходит по ним как по расческе. Вредоносное ПО, активно отцепляющее свои структуры от списков (классика DKOM), ломает простой обход, и потому настоящий инструментарий всегда содержит пару методик: прямую по спискам и сканирующую по сигнатурам, а расхождение между ними - само по себе находка, кричащая о присутствии чего-то, что прячется. Флажки этого типа на практике нехитрые: процесс есть в скане, но отсутствует в списке; драйвер найден по сигнатуре, но не загружен в перечне модулей.

Подготовительный этап включает и описания структур. Старшие ветки анализатора требуют точного профиля исследуемой версии системы, актуальные работают с наборами символов, которые выбирают автоматически по сигнатуре сборки. В обоих случаях расхождение описания и дампа остаётся причиной номер один пустых результатов у новичков, и прежде чем поднимать панику о странном образе, стоит убедиться, что версия определена правильно. Символы берут из официального хранилища поставщика системы, что требует доступа в сеть в момент подготовки.

Извлечение криптографических ключей и секретов

Теперь о самом чувствительном. Ключи живут в памяти тогда, когда они работают: расшифрованный мастер-ключ дискового шифрования находится в памяти постоянно, пока том подключён; ключи TLS-сессий лежат в структурах соответствующих библиотек на время соединения; кэш доменных учётных данных хранится в процессе подсистемы безопасности.

Ключи дискового шифрования исторически извлекаются сигнатурным поиском: структуры ключа AES имеют характерную форму (заголовок пула с конкретным тегом, внутри - развёрнутое расписание ключей строго определённого размера), и инструменты сигнатурного поиска перебирают определённые участки памяти, проверяя кандидатов расписанием ключа и пробной расшифровкой. Тепло снятия образа здесь решает всё: машина, снятая при заблокированном, но не выключенном состоянии, с высокой вероятностью отдаёт мастер-ключ; машина после выключения - уже нет, потому что современные модули ОЗУ теряют данные за секунды.

Кэши учётных данных извлекаются из процесса подсистемы локальной безопасности по известным смещениям структур пакетов аутентификации. Инструменты этой категории общеизвестны, и правильный тон разговора про них - не инструкция по злоупотреблению, а понимание: если защитник может прочитать секрет из памяти, то и атакующий может. Отсюда выросли приоритетные меры защиты: запуск процесса безопасности в защищённом режиме, механизм Credential Guard, где секреты выносятся в изолированную виртуализацией среду, и отключение устаревших пакетов аутентификации, которые хранят пароли в обратимой форме. Состояние обеих защит проверяется из реестра:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard" /v Enabled

Значение RunAsPPL равное единице означает, что процесс подсистемы безопасности запускается как защищённый, и обычный образ памяти уже не отдаёт его содержимое.

Методика извлечения ключей сессий строится похоже: структурированная проходка по памяти процесса TLS-стека с известными сигнатурами. Исследования в этой области регулярно показывают: ключи сохраняют жизнеспособность дольше, чем принято думать, потому что библиотеки редко затирают буферы после использования - это тоже инженерный урок для разработчиков собственных защищённых систем.

Правовая рамка и процессуальная дисциплина

Всё описанное - легальный инструмент в трёх ситуациях: расследование инцидента на собственной инфраструктуре, согласованный аудит заказчика, экспертиза, заказанная уполномоченной стороной. За пределами этой рамки извлечение чужих секретов - уже уголовная история, и статью нужно читать строго в ключе защиты: знать приёмы, чтобы понимать риски и закрывать дыры.

Процессуальная дисциплина одинаково важна: образ памяти снабжается хэшами сразу при снятии, цепочка хранения документируется, любые промежуточные копии учитываются. Хэш считают штатными средствами, ничего ставить не нужно:

certutil -hashfile D:\Evidence\mem-01.raw SHA256

Get-FileHash D:\Evidence\mem-01.raw -Algorithm SHA256 | Format-List

На твердотельном накопителе образ в шестнадцать гигабайт проходит за десятки секунд, и эта строка в протоколе стоит дешевле, чем любой спор о подмене доказательства. Рабочий порядок выглядит так:

1. Зафиксировать состояние системы и время, снять образ памяти штатным средством, посчитать хэш образа;
2. Заполнить журнал снятия: кто, каким инструментом, с какой машины, при каких обстоятельствах;
3. Работать только с копией образа, оригинал оставить нетронутым;
4. Каждую извлечённую находку (ключ, секрет, строка) привязать к смещению в образе и зафиксировать в протоколе;
5. Секреты, добытые при анализе, хранить с тем ранжированием, которого они заслуживают, а не в текстовых файлах на рабочем столе.

Эти пункты выглядят бюрократией до первого судебного спора или до первого внутреннего разбирательства, где обоснованность выводов решается цепочкой хранения, а не красноречием аналитика.

Организация готовности к форензике на предприятии

Поразительно, сколько организаций впервые задумываются о памяти в день инцидента. Готовность строится заранее и недорого: на серверах настраивается полный дамп памяти (место на разделе под него закладывается заранее), создаётся комплект съёмников памяти на изолированном носителе, который лежит в ожидании у дежурной смены, прописывается план "сначала память" в инструкциях реагирования. Отдельным пунктом - обучение: снятие образа с живого сервера, которое действительно используется продуктивом, требует холодной головы, и первый раз это лучше делать на учениях, а не в три ночи под давлением.

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

VOID WipeSecret(PVOID buffer, SIZE_T length)
{
    if (buffer == NULL || length == 0) {
        return;
    }
    // memset здесь может быть выброшен оптимизатором как запись
    // в память, которая больше не читается
    SecureZeroMemory(buffer, length);
}

PVOID key = ExAllocatePool2(POOL_FLAG_PAGED, KEY_LENGTH, 'yeKt');
// ... ключ поработал ...
WipeSecret(key, KEY_LENGTH);
ExFreePoolWithTag(key, 'yeKt');

SecureZeroMemory гарантированно выполняет запись, поэтому след ключа не остаётся ни в освобождённом блоке пула, ни в образе памяти, снятом через минуту. Система, спроектированная с мыслью "что увидит эксперт, если нас скомпрометируют", снижает и ущерб, и горечь расследования.

Отдельно о полезной привычке: готовый шаблон протокола извлечения, привязка каждой находки к смещению и уверенное владение связкой Volatility плюс системный отладчик позволяют воспроизвести результат независимым экспертом до бита, а воспроизводимость - главная валюта форензики.

Инструменты повседневного анализа и их связка

Помимо самого анализатора Volatility, рабочее место эксперта обрастает проверенными помощниками. Снимок процессов и их цифровых подписей проверяется по справочникам целостности; строки из образа извлекаются пакетно и фильтруются по словарям сетевых артефактов, адресов и характерных заголовков; системный отладчик полезен там, где дамп получен именно как аварийный и нужно пройтись по стекам потоков ядра обычными средствами:

CODE6 Полезен и принцип перекрёстной проверки: любое наблюдение, найденное одним инструментом, подтверждается другим, и расхождение трактуется как отдельная находка, ведь корректная интерпретация внутренних структур - штука капризная, а смещения полей меняются от версии к версии.

Отдельной строкой идёт подготовка рабочего профиля версии ОС под задачу: заранее скачанный набор символов, проверенный на контрольном дампе с тестовой машины той же сборки, готовый сценарий типового прогона плагинов с сохранением результатов в протокол. При реальном инциденте время драгоценно, и команда, у которой каждый шаг уже отрепетирован, выигрывает часы у той, что начинает с установки зависимостей. Именно здесь и проявляется разница между знанием инструментов и владением методикой: инструмент скачивается за пять минут, а методика приобретается только регулярной практикой на учебных инцидентах. Опыт подсказывает устраивать такие учения ежеквартально, с нарастающей сложностью сценария: сегодня - простой образ с известной находкой, завтра - образ со срезанными списками и спрятанными драйверами, послезавтра - полноценная игра красной и синей команд, где результатом считается не только найденный артефакт, но и безупречно оформленная цепочка хранения. Команды, выстроившие такой ритм, в день настоящего инцидента действуют тихо, слаженно и быстро - и это спокойствие дорогого стоит.

Что меняется в анализе памяти после появления виртуализационной безопасности и аппаратных модулей доверия

За последние годы ландшафт заметно сдвинулся. Массовое внедрение виртуализационной безопасности вынесло целый слой секретов за пределы досягаемости классического образа памяти: в снятом ОЗУ их просто нет, это уже владения защищённого гипервизора, и инструментарий анализа адаптируется к новой реальности медленнее железа. Растёт и роль памяти оборудования: контроллеры с дешифровкой на борту, аппаратные модули доверия, TPM, - там, где ключ никогда не покидал чип, никакой анализ ОЗУ его не достанет, и модель угроз перестраивается на боковые каналы уже чисто аппаратного свойства.

Напоследок - профессиональное наблюдение. Среди экспертов по реагированию дамп памяти давно имеет репутацию самого честного свидетеля: журналы подчищают, файлы подделывают, а терабайт физической памяти подделать за разумное время невозможно. Тому, кто научился читать этот документ, расследование перестаёт быть гаданием и становится техникой - медленной, методичной и удивительно результативной.

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