Привет, Хабр! На связи команда UserGate uFactor. В наших публикациях мы уже не раз разбирали примеры вредоносного ПО и способы его маскировки в системе. В одной из статей мы рассмотрели вредонос, имеющий возможность очищать журналы событий в Windows, столь важные для анализа инцидентов. В новом материале покажем, как можно восстановить удаленные журналы событий из дампа оперативной памяти и разберем типичные проблемы, возникающие при работе с поврежденными структурами.

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

Журналы событий хранятся в файлах с расширением .evtx и имеют одноименный формат. Извлечь их мы попробуем двумя способами. На наш взгляд, наиболее продуктивным будет извлечь EVTX-файлы при помощи фреймворка Volatility — он дает возможность получить имена журналов, в отличие, например, от Bulk Extractor, который при карвинге присваивает имена следующего вида.

Для извлечения EVTX-файлов при помощи Volatility понадобится применить следующую стратегию: поскольку мы знаем, что регистрацией журналов событий занимается служба EventLogs в контексте процесса svchost, нам нужно найти PID этого процесса и сохранить EVTX-файлы, содержащиеся в его памяти. Самый простой способ поиска нужного нам процесса — это поиск хэндлов к файлам, в именах директорий которых содержится строка winevt.

Теперь, когда мы нашли нужный PID, сохраним файлы из памяти этого процесса.

Есть небольшой минус: у нас сохраняются, помимо EVTX-файлов, и другие файлы, но это не критично, если далее мы восстанавливаем их при помощи CQEVTXRecovery. Копируем все файлы из директории /home/forensic/dump/ (в нашем случае) в директорию C:\test\evtxrec\reca. Поскольку структура EVTX-файлов, извлеченных из процесса, повреждена, необходимо восстановить ее. В первом случае попробуем сделать это при помощи утилиты CQEVTXRecovery. Саму утилиту можно найти в сборке на GitHub.

Давайте посмотрим, удалось ли что-то восстановить.

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

Теперь попробуем найти и сохранить EVTX-файлы при помощи Bulk Extractor. Для этого мы используем GUI-версию. Метод поиска данных в Bulk Extractor построен на карвинге. Карвинг данных — это метод восстановления файлов на основе структуры их данных. Поиск файлов при помощи Bulk Extractor производить проще: указываем файл, в котором нужно искать, директорию, в которой необходимо сохранить найденные данные, и непосредственно формат данных, которые необходимо найти.

Теперь, когда карвинг-данные сохранены, попробуем восстановить журналы при помощи EvtxECmd. Эту утилиту можно скачать на Eric Zimmerman’s tools. Стоит отметить, что утилита не сможет проанализировать директорию, в которой будут не только EVTX-файлы, как, например, в случае, когда мы извлекали файлы при помощи фреймворка Volatility. Выходным результатом будет CSV-файл.

После окончания процесса посмотрим результат при помощи Timeline Explorer.

Как видно по рисунку 8, нужного результата мы опять не получили. Казалось бы — ну вот и все, ключевые сведения в журналах не сохранились. Но не тут-то было. Давайте вернемся к журналам, которые мы сохранили при помощи Volatility, но перед этим вспомним немного структуру EVTX-файлов.

В этой таблице нас наиболее интересуют сигнатура вхождения (начало события) и время записи. Детально рассмотреть структуру можно на GitHub.

Просмотрев содержимое файлов, находим интересную информацию в файле 0xfa8002737aa0.SharedCacheMap.Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx.vacb.

Посмотрим, сохранились ли записи в файле file.0xfa80025b4e20.0xfa80025b34e0.SharedCacheMap.Security.evtx.vacb.

Конечно, та же самая информация будет и в файлах журналов, извлеченных при помощи Bulk Extractor, но более удобно, когда имена файлов практически соответствуют оригинальным названиям.

Как видно по рисункам 9, 10 и 11, у нас уже есть информация для дальнейших действий по реагированию на инцидент (напомним, что нам не удалось восстановить ее с помощью утилит EvtxECmd и CQEVTXRecovery). Все указанные события соответствуют действиям, совершенными нами для эксперимента. Далее можно написать парсер, который извлечет все события, связанные с TerminalServices-RemoteConnectionManager и Security, невзирая на поврежденные EVTX-файлы. Стоит отметить, что очистка журналов не влияет на данные, содержащиеся в оперативной памяти: журналы событий будут повреждены и при обычных условиях.

Заключение

Как показал наш эксперимент, извлечение журналов событий из дампа памяти — задача не самая тривиальная. Несмотря на обилие специализированных утилит, некоторые из них не гарантируют стопроцентного результата, особенно если структура файлов повреждена. Автоматические средства вроде CQEVTXRecovery и EvtxECmd не всегда справляются, и именно здесь на первый план выходит ручной анализ и понимание внутренней структуры EVTX-файлов.

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

Карвинг с помощью Bulk Extractor также может успешно применяться, особенно если цель — быстрое извлечение без привязки к процессам. Но итоговая эффективность, как видно из сравнительного анализа, зависит от множества факторов, в том числе от формата и состояния извлекаемых фрагментов.

Подводя итоги, дадим несколько рекомендаций:

·        Если компьютерная система скомпрометирована или есть подозрение о ее компрометации — не выключайте ее и не перезагружайте, пока не создадите дамп оперативной памяти. То же самое касается и отключения от интернета. Сейчас достаточно информации и инструментов, чтобы быстро создать дамп.

·        Не стоит слепо доверять утилитам — дополнительно проводите визуальный анализ сырых данных.

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