Windows IR: системный подход. Часть 4 — артефакты, таймлайн, IOC, восстановление

Это четвёртая, заключительная часть материала, посвящённого Windows IR. Третья часть была посвящена задачам планировщика, автозапуску, учётным записям и восстановлению хронологии по журналам событий. В этой части — готовим коллекцию для офлайн-анализа, разбираем артефакты пользовательской активности, включая историю браузера, собираем итоговый таймлайн, превращаем находки в IOC и проходим по шагам восстановления системы после инцидента. 

Шаг 11. Подготовка коллекции

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

Prefetch

На RDS01 Prefetch был отключён, поэтому соответствующие .pf-файлы отсутствовали и в коллекцию не вошли. Отсутствие Prefetch не доказывает отсутствия запуска: этот пробел компенсируют Security 4688, UserAssist, Amcache и пользовательские LNK.

NTUser.dat скомпрометированного пользователя

reg.exe save "HKU\$sid" "C:\IR-Collection\a.sokolova_NTUSER.DAT" /y

SYSTEM и SOFTWARE ветки реестра

reg.exe save HKLM\SYSTEM C:\IR-Collection\SYSTEM.hive /y
reg.exe save HKLM\SOFTWARE C:\IR-Collection\SOFTWARE.hive /y

LNK

Copy-Item `
    "C:\Users\a.sokolova\AppData\Roaming\Microsoft\Windows\Recent\*.lnk" `
    C:\IR-Collection\LNK `
    -Force

Jump Lists

Copy-Item `
    "C:\Users\a.sokolova\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\*.automaticDestinations-ms" `
    C:\IR-Collection\JumpLists\AutomaticDestinations `
    -Force

Copy-Item ` "C:\Users\a.sokolova\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations\*.customDestinations-ms" ` C:\IR-Collection\JumpLists\CustomDestinations ` -Force 

История браузеров

В нашем случае необходима история Edge, но я приведу список команд на поиск артефактов самых популярных браузеров: 

Firefox -            

C:\Users\пользователь\AppData\Roaming\Mozilla\Firefox\Profiles (файл Places.sqlite)

Chrome -

C:\Users\пользователь\AppData\Local\Google\Chrome\User Data\Default (Файл History.sqlite)

Egde -

C:\Users\пользователь\AppData\Local\Microsoft\Edge\User Data\Default (Файл History.sqlite)

И благополучно дёргаем файл истории

Copy-Item "C:\Users\a.sokolova\AppData\Local\Microsoft\Edge\User Data\Default\History" `

    C:\IR-Collection\Edge\Default\History -Force

Журналы

wevtutil epl Security C:\IR-Collection\EVTX\Security.evtx /ow:true
wevtutil epl System C:\IR-Collection\EVTX\System.evtx /ow:true
wevtutil epl Application C:\IR-Collection\EVTX\Application.evtx /ow:true
wevtutil epl "Windows PowerShell" C:\IR-Collection\EVTX\Windows-PowerShell.evtx /ow:true
wevtutil epl "Microsoft-Windows-PowerShell/Operational" C:\IR-Collection\EVTX\PowerShell-Operational.evtx /ow:true
wevtutil epl "Microsoft-Windows-TaskScheduler/Operational" C:\IR-Collection\EVTX\TaskScheduler-Operational.evtx /ow:true
wevtutil epl "Microsoft-Windows-Windows Defender/Operational" C:\IR-Collection\EVTX\Defender-Operational.evtx /ow:true
wevtutil epl "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" C:\IR-Collection\EVTX\RemoteConnectionManager-Operational.evtx /ow:true
wevtutil epl "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" C:\IR-Collection\EVTX\LocalSessionManager-Operational.evtx /ow:true

Найденные вредоносные файлы

Copy-Item `
    'C:\Users\a.sokolova\AppData\Roaming\SecureDocumentViewer' `
    C:\IR-Collection\Files\UserPersistence `
    -Recurse -Force

Copy-Item `
    'C:\ProgramData\WindowsHealthMonitor' `
    C:\IR-Collection\Files\SystemStage `
    -Recurse -Force

И .zip из Downloads

Get-ChildItem 'C:\Users\a.sokolova\AppData\Local\Temp' `
    -Recurse -Force -File -Filter *.zip |
    Where-Object {
        $_.LastWriteTime -ge $from -and
        $_.LastWriteTime -le $to
    } |
    Select-Object FullName,Length,CreationTime,LastWriteTime

Copy-Item 'ПОЛНЫЙ_ПУТЬ_К_НАЙДЕННОМУ_ZIP' `
    C:\IR-Collection\Files\Staging `
    -Force

Amcache

esentutl.exe /y /vss "C:\Windows\AppCompat\Programs\Amcache.hve" /d "C:\IR-Collection\Amcache.hve" /o

Остановка транскрипта

Если на машине работа закончена.

Get-Date
Stop-Transcript

Итоговая папка, которую аналитик забирает с собой, содержит все результаты его работы.

Шаг 12. Артефакты запуска и пользовательской активности

Артефакты, собранные в папку на предыдущем шаге, будут использованы для перепроверки выводов, сделанных во время live response. Они перемещаются на машину аналитика и исследуются там. Ниже будет продемонстрирована важность некоторых их них.

Анализ NTUser.dat

NTUSER.DAT содержит персональные настройки и следы активности конкретного пользователя. Фактически, это кусок реестра HKU для конкретного пользователя. С помощью инструмента Registry Explorer мы можем исследовать активность пользователя в удобном формате, чтобы добыть дополнительные доказательства выполнения вредоносных программ.

Первое место, куда здесь стоит посмотреть – UserAssist. В этом артефакте сохраняются данные о выполнении программ с графическим интерфейсом.

Подробнее о нюансах анализа этого артефакта можно почитать на Securelist, а здесь обратим внимание на следующие данные:

UserAssist показывает, что файл .cmd, сведения о котором уже встречались в логах 4688, был запущен пользователем в 21:12:54. Время здесь приведено в UTC, так что прибавляем +3 часа и получаем идеальное совпадение с таймлайном инцидента. В случае, если бы логи были очищены атакующим, мы смогли бы установить время запуска и точный файл через UserAssist.

Еще одно полезное место – RecentDocs. Этот ключ отслеживает файлы и папки, которые пользователь открывал или просматривал через проводник.

Разберем данные здесь более подробно.

21:12:23 UTC — Пользователь открывает архив SecureDocumentViewer.zip.

21:12:42 UTC — Спустя 19 секунд, пользователь переходит в распакованную папку SecureDocumentViewer (это видно по строке Folder), открывает текстовый файл README.txt.

Обратите внимание на колонку Lnk Name. При открытии любого документа Windows автоматически создает скрытый ярлык в профиле пользователя (в папке AppData\Roaming\Microsoft\Windows\Recent). Эти файлы и их метаданные мы тоже выгрузили на предыдущем шаге. При необходимости они доступны для исследования.

Через исследования UserAssist и RecentDocs мы можем доказать взаимодействия с конкретными файлами.

Другие артефакты

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

Amcache. Этот файл содержит информацию об установленных, запущенных программах, их хешах (SHA-1). Для его исследования удобно использовать AmcacheParser. Был извлечен с системы на шаге 12.

Prefetch. Windows использует этот файл для ускорения запуска программ. Здесь можно найти имена, пути и время запуска различных исполняемых файлов. Во многих системах Prefetch отключен по умолчанию, так что извлечь его получается не всегда. В нашей лабе произошло именно так. Исследуется с помощью PECmd.

LNK-файлы. Операционная система создает их в AppData\Roaming\Microsoft\Windows\Recent при открытии файлов. Эти файлы содержат полезные метаданные, в первую очередь, полные пути к файлам и временные метки. Эта информация парсится через инструмент LECmd. В нашем случае исследование этого артефакта проводилось, но не дало новой информации.

Джамп-листы. Хранят информацию, какие файлы были открыты теми или иными программами. Анализируются через JLECmd.

Реестры SYSTEM и SOFTWARE. Частично анализировались нами на живой системе, но целесообразно забрать их с собой целиком для перепроверки и глубокого анализа. Хранят массу интересных данных. Как и NTUSER.dat, анализируются с помощью Registry Explorer.

История браузера

Остановимся подробнее на этом артефакте. Мы установили, что заражение началось с запуска файла SecureDocumentViewer, который находился в архиве SecureDocumentViewer.zip. Анализ событий показал нам, что этот архив был получен от процесса браузера Edge. Нам осталось установить, с какого ресурса в браузере архив был загружен. Пока что из сетевых ресурсов мы располагаем адресом сервера С2 — и мы точно уверены, что это С2, так как адрес засветился и в логах, и в скриптах, и в строках исполняемых файлов.

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

Мы уже изъяли с машины sqlite БД с историей. Для ее просмотра нам потребуется DB Browser for SQLite. Запускаем программу, нажимаем Open database, далее переходим на вкладку Browse data и выбираем таблицу Downloads. Мы же загрузку ищем?

Переключаемся на столбец Current_path внутри этой таблицы и начинаем просматривать ячейки. В правой части интерфейса отображается текст с полным путем той или иной загрузки.

Находим архив, который уже видели в предыдущих артефактах. Изучим эту строку. В столбцах referrer и tab_url видим адрес, откуда произошло скачивание.

Адрес «серый» и совпадает с адресом С2 — все-таки это учебная лаба. В реальных сценариях здесь будет, конечно, менее очевидный адрес. Но подход к поиску тот же. Финальное, что нас интересует здесь в данный момент – ячейки Opened и end_time. Первая хранит флаг, свидетельствующий, был ли файл запущен из браузера. Вторая хранит время окончания загрузки.

Opened=1 означает, что пользователь успешно открыл файл (кликнул по нему в интерфейсе загрузок Edge сразу после скачивания или запустил встроенными средствами браузера). Теперь отмазки пользователя «оно само открылось» не прокатят – мы видим, что архив был открыт целенаправленно.

Время окончания загрузки можно привести к человеческому виду, используя CyberChef. Для этого скопируем значение, добавим в конец ноль и вставим в CyberChef с рецептом, заданным на скриншоте. Chromium хранит время в микросекундах с 1 января 1601 года UTC, а операция CyberChef Windows Filetime to UNIX Timestamp ожидает интервалы по 100 наносекунд. Поэтому исходное число умножается на 10 — для целого положительного значения это эквивалентно добавлению одного нуля. Полученное время остаётся в UTC и затем переводится в часовой пояс сервера.

Как видите, время окончания загрузки отлично вписывается в таймлайн расследования.

Анализ первопричины анализа заражения это важная вещь, и для этих целей в большинстве случаев придется работать либо с историей браузеров, либо с мессенджерами, либо с почтой, потому что 90% Initial Access приходятся на эти каналы. Это просто и дешево.

Популярные браузеры хранят историю в SQLite БД, поэтому описанный выше подход будет работать и для них, с незначительной поправкой на названия таблиц. Для анализа мессенджеров и почты потребуются другие инструменты. Для парсинга писем Outlook, например, можно использовать XstReader.

Шаг 13. Сборка таймлайна

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

Здесь я понял, что за все время ни разу не удосужился подробно просмотреть директорию C:\Users\a.sokolova\AppData\Roaming\SecureDocumentViewer, которая всплывала кучу раз и даже была скопирована в коллекцию.

Внутри обнаружились результаты выполнения команд разведки в файлах с датой изменения 25 августа 2026 0:13, а также скопированные из каталогов пользователя a.sokolova документы.

Итоговый таймлайн получился таким:

В принципе, получилось неплохо. По таймлайну непонятны две главные вещи:

-       каким образом произошло повышение привилегий с пользователя до SYSTEM-задачи. Для этого ему бы потребовались права админа.

-       была ли реальная эксфильтрация собранных данных на С2, или они были просто подготовлены к передаче.

Еще раз – стенд учебный, поэтому реальной эксфильтрации, конечно, не было, и реального повышения привилегий тоже. Никто никого не эксплуатировал, а задача и таск с правами системы были созданы от админа через скрипт в 00:20:59. В реальных условиях эксфильтрацию можно было бы засечь по аномальному объему outbound-трафика (если повезет), а технику повышения привилегий изучать предметно.

Получается история: пользователь вошёл по RDP, открыл портал в Edge, загрузил архив, распаковал его и запустил CMD. Через секунду начался PowerShell, затем разведка, сбор документов, архивирование и закрепление.

Шаг 14. IOC

Поскольку подтверждена компрометация RDS01, выполнение кода в сеансе a.sokolova, нам нужен список индикаторов, по которым можно быстро обнаружить атаку такого типа в будущем.

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

Шаг 15. Восстановление и устранение последствий

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

Если бэкапов нет – перезаливка ОС/развертывание новой машины, особенно если подтверждено выполнение кода от SYSTEM. Сильно круто? Вообще нет. Вот занимательная цитата из западных рекомендаций по восстановлению:

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

NIST.SP.800-61r3 стр. 33

Восстановленная машина сканируется с использованием собранных в ходе расследования IOC перед вводом в эксплуатацию.

Машина ставится под усиленное наблюдение SOC.

Пароли всех пользователей, которые пользовались скомпрометированным сервером, сбрасываются.

Проверяются все системы, имеющие сетевую связность с скомпрометированной, с использованием собранных IOC. При необходимости, используйте локальные IOC/YARA сканеры наподобие Loki.

Проводится ретроспективный поиск на других хостах с использованием собранных IOC.

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

Заключение

Мы прошли весь путь live response. В частности, в этой части от подготовки коллекции для офлайн-анализа (реестровые кусты, LNK, Jump Lists, история браузера, журналы) до восстановления по этим артефактам недостающих деталей — в том числе источника заражения через историю загрузок браузера, — а затем от сборки таймлайна до перевода находок в IOC и практических шагов восстановления системы. Инцидент в демонстрационной лабе разобран полностью.

Часть 1, часть 2, часть 3.

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ нового VDS — HABRFIRSTVDS.