Вводная: почему стандартные логи часто оказываются неполными
В инцидентах, связанных с целевыми атаками или продвинутым вредоносным ПО, злоумышленники активно чистят следы. Папка Downloads пуста, события Security (в частности, 4688 — создание процесса) отсутствуют либо потому что аудит не был включён, либо логи были целенаправленно затёрты. Однако EDR может сработать спустя несколько часов после первоначального заражения — например, при активации C2-канала или попытке повышения привилегий. В таком случае мы имеем лишь сигнал тревоги, но не видим, что именно запускалось.
И тут нам требуется быстрый сбор ключевых артефактов для подтверждения или опровержения гипотезы. Ниже разберём реальный сценарий, где удалось восстановить факт запуска вредоносного файла, даже когда он уже был стёрт с диска.
Сценарий: «Исчезнувший след»
Исходные данные
- Сработал EDR — получен алерт о подозрительной сетевой активности (или эвристике) на хосте WS-015.
- Пользователь утверждает, что ничего не запускал, папка C:\Users\User\Downloads пуста.
- Логи Security не содержат событий 4688 (Process Creation) — скорее всего, аудит не настроен, либо записи удалены.
- Временной разрыв: EDR сработал сейчас, но, как выяснится позже, первичный запуск вредоноса произошёл тремя часами ранее (возможно, через запланированную задачу или легитимный процесс-загрузчик).
Действие (быстрый триаж на живой системе)
Важное предостережение: Запуск любого инструмента на потенциально заражённом хосте изменяет артефакты файловой системы (обновляются $MFT, $UsnJrnl, реестр). Если вы работаете в рамках судебной форензики (Forensics) — сначала сделайте полную копию диска и дамп памяти, а затем анализируйте их офлайн. В нашем случае мы проводим оперативный триаж (Incident Response), где скорость важнее, и мы готовы к незначительным изменениям. Это компромисс, о котором нужно знать.
Дополнительный совет: если позволяет время, перед сбором дисковых артефактов сделайте дамп оперативной памяти. Для сбора используйте WinPmem (читает память напрямую с оборудования, не полагаясь на API ОС). Полученный RAW-файл можно впоследствии проанализировать с помощью Volatility — это может дать информацию о процессах, которые уже удалили себя с диска, а также о сетевых соединениях и внедрённых драйверах.
Теперь переходим к сбору дисковых артефактов. Используем KAPE (Kroll Artifact Parser and Extractor) с целевым набором !SANS_Triage, который собирает только самые критичные артефакты, игнорируя кэш браузеров и прочий «мусор».
kape.exe --tsource C: --tdest D:\collection --target !SANS_Triage --module !SANS_Triage --vssПочему --vss следует включать по умолчанию? Без этого флага KAPE не извлечёт данные из теневых копий тома (Volume Shadow Copies). Именно в VSS часто сохраняются предыдущие версии файлов и реестра, даже если оригинал удалён. В нашем случае это стало решающим фактором. Однако в полевых условиях иногда приходится отключать VSS ради скорости или из-за нехватки места — тогда вы рискуете потерять исторические следы.
Результат
Через 3 минуты после запуска мы получили CSV-файлы с парсингом артефактов. В ShimCache обнаружена запись о файле invoice.exe из папки C:\Users\User\AppData\Local\Temp с таймстемпом, совпадающим с временем подозрительной активности (с учётом задержки). В Amcache нашёлся хеш этого бинарника, что позволило проверить его по VT (если политика безопасности разрешает).
Сам файл был удалён, папка Temp пуста, но реестр (ShimCache и Amcache) содержит следы, согласующиеся с присутствием и возможным запуском файла. Мы получили согласованный набор артефактов, который с высокой вероятностью указывает на запуск вредоносного файла, несмотря на отсутствие физического файла.
Инженерный чек-лист: что собирать в первую очередь
Если нужно быстро понять, что произошло «прямо сейчас», не копируйте весь диск. Используйте этот список артефактов — каждый из них закрывает конкретный сценарий:
| Артефакт | Зачем собирать (сценарий использования) |
|---|---|
| MFT + $UsnJrnl | MFT даёт карту всех файлов, а $UsnJrnl (журнал изменений) показывает историю создания, переименования и удаления. Без них вы не узнаете, когда и какой файл исчез. |
| Event Logs (Security, System, Application) | Даже если события 4688 нет, можно найти другие косвенные признаки: входы в систему, остановки служб, ошибки приложений. |
| ShimCache / Amcache | ShimCache — важный вспомогательный артефакт, он свидетельствует о факте упоминания/загрузки файла в систему, но не является прямым доказательством запуска. Amcache хранит хеши и версии (с оговорками о полноте), помогает идентифицировать бинарники. |
| Prefetch | Один из наиболее сильных артефактов для подтверждения запуска .exe, если он присутствует (может быть отключён или очищен). Содержит данные о последних запусках и счётчиках обращений — точное поведение зависит от версии ОС. |
| ShellBags | Показывают, в какие папки заходил пользователь через проводник (Explorer). Актуально при краже данных — можно понять, что он открывал и смотрел. |
| SRUM (System Resource Usage Monitor) | Фиксирует потребление сети, CPU и диска по процессам за достаточно длительный период (зависит от конфигурации и объёма данных). Не разделяет входящий/исходящий трафик, но позволяет увидеть аномальный расход сети (например, процесс отправил несколько гигабайт), что косвенно указывает на эксфильтрацию. |
Дополнительно: если есть подозрение на сохранность удалённых данных, обязательно забирайте $LogFile (транзакционный журнал NTFS) — он помогает восстановить таймлайн даже при повреждении MFT.
Важно: перед запуском сбора убедитесь, что у вас есть права локального администратора, а также изолируйте хост от сети, чтобы вредонос не успел среагировать на ваши действия и не подчистил следы.
Честный вывод (без маркетинга)
KAPE — мощная утилита сбора данных DFIR, но он не анализатор. Он выдаёт горы CSV, которые нужно уметь читать и интерпретировать. Если вы не знаете, как устроены ShimCache или Prefetch, вы не станете экспертом, просто запустив утилиту. Вы лишь получите больше данных для возможных ошибок.
Перед каждым запуском задавайте себе один вопрос: «Какую гипотезу я проверяю сейчас?». Если ответа нет — не собирайте ничего. Вы просто увеличите энтропию в папке с уликами, затруднив последующий анализ.
И помните: триаж на живой системе — это осознанный риск. Для судебного разбирательства всегда используйте только образы дисков и памяти, полученные по правилам chain of custody.
Статья подготовлена на основе реальных инцидентов и доработана с учётом замечаний DFIR-сообщества.
Читайте продолжение тут