Форум АНТИЧАТ - Форензика Windows: пошаговый разбор артефактов при расследовании инцидента

https://forum.antichat.xyz/attachmen...4ba71e5b94.png

Когда SOC-аналитику прилетает алерт о компрометации хоста, начинается гонка со временем. Атакующий мог закрепиться через реестр, запустить разведку, прыгнуть латерально на соседний хост - и всё это оставило следы в десятках системных артефактов. Загвоздка в том, что ни один артефакт сам по себе полной картины не даёт. Event Log покажет факт логона, но промолчит про запущенный бинарник. Prefetch подтвердит запуск, но не скажет, откуда файл вообще взялся на диске. MFT хранит временные метки, но без контекста из реестра они - просто цифры.

Здесь я разберу пять категорий артефактов Windows - Event Logs, MFT, реестр, Prefetch и Amcache - и покажу, как их анализировать на практике: конкретные команды, инструменты Эрика Циммермана, интерпретация вывода. Не абстрактные списки «что бывает», а пошаговый процесс расследования инцидента с корреляцией данных между артефактами и построением единого таймлайна.
Зачем нужна корреляция артефактов Windows
Типичный сценарий: на рабочей станции сработал EDR на подозрительный процесс. Аналитик SOC уровня L1 зафиксировал алерт, но процесс уже завершился. Что произошло? Как атакующий попал на хост? Есть ли persistence? Куда он двинулся дальше?

Каждый из пяти основных артефактов Windows forensics отвечает на свою часть вопроса:

АртефактЧто показываетГде лежитEvent LogsЛогоны, создание процессов, установка служб

Код:

C:\Windows\System32\winevt\Logs\

$MFTСоздание, изменение, удаление файлов с временными меткамиКорень тома NTFSРеестрPersistence, конфигурация системы, история USB

Код:

C:\Windows\System32\config\

Код:

NTUSER.DAT

PrefetchФакт и время запуска исполняемых файлов

Код:

C:\Windows\Prefetch\

Amcache / ShimCacheИстория выполнения программ, метаданные бинарников

Код:

C:\Windows\appcompat\Programs\Amcache.hve

, реестр SYSTEM

Сила DFIR-расследования - в перекрёстной валидации. Prefetch показывает запуск

Код:

mimikatz.exe

в 14:32, Event Log фиксирует Event ID 4624 типа 3 (сетевой логон) в 14:30 с нетипичного хоста, MFT подтверждает создание файла

Код:

mimikatz.exe

в 14:31 - картина складывается. Без корреляции каждый из этих фактов по отдельности мог быть пропущен или неверно интерпретирован.
Анализ Event Logs Windows: первый рубеж расследования
Журналы событий Windows - первое, куда лезет DFIR-аналитик. Файлы

Код:

.evtx

лежат в

Код:

C:\Windows\System32\winevt\Logs\

и содержат структурированные записи обо всём - от логонов до создания процессов. По данным INCIBE, Event Logs позволяют реконструировать хронологию событий, идентифицировать активность пользователей и атакующих, обнаружить вредоносную деятельность.
Ключевые Event ID для DFIR-аналитика
Не все журналы одинаково полезны. Вот набор Event ID, которые я проверяю первыми при каждом расследовании:

Security.evtx - аутентификация и доступ:

Event IDОписаниеНа что смотреть4624Успешный логонПоле Logon Type: 2 = интерактивный, 3 = сетевой, 10 = RDP. Источник (Workstation Name, Source Network Address)4625Неудачный логонМассовые попытки = брутфорс. Код ошибки: 0xC000006D = неверный пароль4672Назначение специальных привилегийЛюбой логон с привилегиями SeDebugPrivilege - подозрителен4688Создание процессаКомандная строка процесса (если включён аудит). Родительский процесс4720Создание учётной записиАтакующий создал бэкдор-аккаунт

System.evtx - службы и драйверы:

Event IDОписаниеЗначение для расследования7045Установка новой службыPSExec, Cobalt Strike - все создают службы. Поле Service File Name критично7036Изменение состояния службыСтарт/стоп подозрительных служб

Microsoft-Windows-PowerShell/Operational.evtx:

Event IDОписаниеЗначение для расследования4104Script Block LoggingПолный текст выполненных PowerShell-скриптов, включая деобфусцированный код

Практика: извлечение и парсинг Event Logs
На живой системе можно быстро отфильтровать интересные события через PowerShell. Для поиска неудачных логонов (рекомендация INCIBE):

Код:

Код:

Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 4625} | Select-Object TimeCreated, Message

Но при работе с образом диска нужны другие инструменты. Для офлайн-анализа я использую EvtxECmd из набора Eric Zimmerman Tools:

Bash:

Код:

# Парсим все evtx-файлы в CSV для дальнейшего анализа

EvtxECmd.exe -d

"E:\C\Windows\System32\winevt\Logs"

--csv

"C:\Output"

--csvf timeline_events.csv

Результат - CSV-файл, который загружаем в Timeline Explorer (тоже EZ Tools) и фильтруем по Event ID, времени, пользователю. Искать нужно аномалии: логоны в нерабочее время, сетевые логоны (Type 3) от неизвестных хостов, установку служб с подозрительными путями к бинарникам.

Ещё один приём, который лично у меня срабатывает чаще, чем хотелось бы: если в Security.evtx вы видите Event ID 4624 с Logon Type 3 и тут же Event ID 7045 в System.evtx с установкой службы - это классический паттерн PSExec или аналогичного инструмента для lateral movement. Две записи с разницей в пару секунд - и вектор перемещения как на ладони.
MFT анализ NTFS: файловая система как свидетель
Master File Table ($MFT) - сердце файловой системы NTFS. Каждый файл и каталог на томе имеет запись в MFT с четырьмя временными метками (MACE): Modified, Accessed, Changed ($MFT entry), Entry created (birth). Нюанс: начиная с Windows Vista, метка Last Access по умолчанию не обновляется при чтении файла (параметр

Код:

NtfsDisableLastAccessUpdate

), так что Access time может врать. Даже если файл удалён, его запись в MFT может сохраняться до тех пор, пока не будет перезаписана новой.
Что хранит запись MFT и почему это важно
Каждая MFT-запись содержит два набора временных меток:

$STANDARD_INFORMATION ($SI) - стандартные метки, которые обновляет ОС и которые легко подделывает атакующий (timestomping)
$FILE_NAME ($FN) - метки, обновляемые только при определённых операциях с файлом, подделать их значительно сложнее

Расхождение между $SI и $FN - классический индикатор timestomping. $SI показывает дату создания в 2019 году, а $FN - в 2024? Файл однозначно подкрутили для маскировки.
Практика: анализ MFT через MFTECmd
Для извлечения $MFT из образа - FTK Imager: открываем образ, переходим в корень тома, правой кнопкой на

Код:

$MFT

→ Export Files. Дальше парсим:

Bash:

Код:

# Парсинг $MFT в формат CSV

MFTECmd.exe -f

"C:\Evidence\$MFT"

--csv

"C:\Output"

--csvf mft_parsed.csv

Что искать в выводе MFTECmd:

Подозрительные пути - исполняемые файлы в

Код:

C:\Windows\Temp\

,

Код:

C:\Users\Public\

,

Код:

C:\ProgramData\

(любимые директории атакующих - туда пишется без лишних привилегий)
Расхождение SI и FN timestamps - признак timestomping. В CSV-выводе MFTECmd есть отдельные колонки для обоих наборов меток
Удалённые файлы - записи с флагом

Код:

InUse: false

. Файл удалён, но метаданные на месте
ADS (Alternate Data Streams) - атакующие прячут payload в альтернативных потоках данных. MFTECmd их покажет

Пример: нашли запись для

Код:

C:\Windows\Temp\svchost.exe

с датой создания 2024-03-15 14:31:02. Легитимный svchost.exe живёт в

Код:

System32

, а не в

Код:

Temp

. Фиксируем временную метку и идём в Prefetch - был ли этот самозванец запущен?
Форензика реестра Windows: карта закрепления атакующего
Реестр Windows - иерархическая база данных с конфигурациями ОС, программ и пользовательских настроек. Для атакующего реестр - основной механизм persistence. Для аналитика - карта того, как именно злоумышленник закрепился в системе.

Системные кусты (

Код:

SAM

Код:

SECURITY

Код:

SOFTWARE

Код:

SYSTEM

) лежат в

Код:

C:\Windows\System32\config\

. Пользовательские (

Код:

NTUSER.DAT

Код:

UsrClass.dat

) - в профиле каждого пользователя.
Ключи автозагрузки и закрепления
Основные ветки реестра, через которые атакующие обеспечивают persistence, с привязкой к техникам MITRE ATT&CK:

Registry Run Keys / Startup Folder (T1547.001, persistence, privilege-escalation):

В кусте

Код:

SOFTWARE

(закрепление с правами системы/администратора):

Код:

Microsoft\Windows\CurrentVersion\Run
Код:

Microsoft\Windows\CurrentVersion\RunOnce
Код:

Microsoft\Windows\CurrentVersion\RunServices
Код:

Microsoft\Windows\CurrentVersion\RunServicesOnce

В кусте

Код:

NTUSER.DAT

(закрепление с правами пользователя):

Те же ключи

Код:

Run

,

Код:

RunOnce

- но для конкретного пользователя

Дополнительно в

Код:

SOFTWARE

Код:

Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

- подмена процесса инициализации при логоне
Код:

Microsoft\Windows NT\CurrentVersion\Winlogon\Shell

- подмена оболочки

Logon Script - Windows (T1037.001, persistence, privilege-escalation):

Скрипты входа, привязанные к профилю пользователя через

Код:

NTUSER.DAT

Код:

Environment\UserInitMprLogonScript

- путь к скрипту, выполняемому при логоне

Scheduled Task (T1053.005, execution, persistence, privilege-escalation):

Задачи хранятся как XML в

Код:

C:\Windows\System32\Tasks\

и регистрируются в реестре. Ищите нестандартные задачи с подозрительными путями к исполняемым файлам.

Create or Modify System Process: Windows Service (T1543.003, persistence, privilege-escalation):

Службы описаны в

Код:

SYSTEM\CurrentControlSet\Services\

. Каждый подключ - отдельная служба. Поле

Код:

ImagePath

указывает на исполняемый файл. Атакующий может создать собственную вредоносную службу или подменить существующую.

Services Registry Permissions Weakness (T1574.011, persistence, privilege-escalation, defense-evasion):

Если ACL на ключах реестра служб настроены криво, атакующий может подменить

Код:

ImagePath

легитимной службы - даже новую создавать не надо.

BITS Jobs (T1197, defense-evasion, persistence):

Background Intelligent Transfer Service используется для скачивания файлов. Злоумышленники применяют

Код:

bitsadmin

для загрузки payload и закрепления через задания BITS.
Практика: разбор реестра через Registry Explorer и RegRipper
Для визуального анализа реестра из образа диска - Registry Explorer (EZ Tools). Загружаете куст (например,

Код:

SOFTWARE

из

Код:

C:\Windows\System32\config\

), переходите к нужному ключу и видите значения с Last Write Time.

Для автоматизации - RegRipper:

Bash:

Код:

# Вытаскиваем persistence из куста SOFTWARE

rip.exe -r

"E:\C\Windows\System32\config\SOFTWARE"

-p soft_run

Плагин

Код:

soft_run

покажет все значения в ключах

Код:

Run

Код:

RunOnce

. На что смотреть:

Пути к исполняемым файлам за пределами

Код:

Program Files

и

Код:

Windows
Base64-encoded команды PowerShell в значениях (классика жанра)
Timestamp последнего изменения ключа - когда именно было создано закрепление

Для системной информации перед анализом:

Bash:

Код:

# Имя компьютера, версия ОС, временная зона

rip.exe -r

"E:\C\Windows\System32\config\SYSTEM"

-p compname

rip.exe -r

"E:\C\Windows\System32\config\SOFTWARE"

-p winver

rip.exe -r

"E:\C\Windows\System32\config\SYSTEM"

-p timezone

Знание временной зоны критично - все дальнейшие временные метки нужно приводить к единому формату UTC. Забудете про это - потом будете час искать «пропавшие» два часа в таймлайне.
Prefetch файлы: доказательство запуска программ
Prefetch - механизм Windows для ускорения повторного запуска приложений. С точки зрения форензики - доказательство того, что конкретный бинарник был выполнен на системе. По данным INCIBE, даже если исполняемый файл удалён, его след может остаться в Prefetch с именем, расположением и датой запуска.

Файлы

Код:

.pf

лежат в

Код:

C:\Windows\Prefetch\

. Имя файла формируется по схеме:

Код:

ИМЯПРОЦЕССА-ХЕШПУТИ.pf

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

Код:

cmd.exe

, запущенный из

Код:

System32

, от

Код:

cmd.exe

из

Код:

Temp

- а разница, сами понимаете, принципиальная.
Эволюция Prefetch по версиям Windows
Поведение Prefetch различается в зависимости от версии ОС:

Версия WindowsЛимит файловОсобенностиXP - Windows 7128Базовый PrefetchWindows 8+1024Интеграция с SuperFetch/SysMain, сжатие MAMWindows 10/111024Сохраняет до 8 последних временных меток запускаWindows ServerОтключён по умолчаниюТребует ручного включения через реестр

На серверных ОС Prefetch по умолчанию отключён. Если расследуете инцидент на сервере и Prefetch пуст - это не значит, что ничего не запускалось. Идите в Amcache и ShimCache.
Практика: парсинг Prefetch через PECmd

Bash:

Код:

# Парсинг всех Prefetch-файлов в директории

PECmd.exe -d

"E:\C\Windows\Prefetch"

--csv

"C:\Output"

--csvf prefetch_all.csv

# Парсинг конкретного файла с детальным выводом

PECmd.exe -f

"E:\C\Windows\Prefetch\MIMIKATZ.EXE-12F4A52B.pf"

Что покажет PECmd в детальном режиме:

Executable Name - имя запущенного процесса
Run Count - сколько раз запускался
Last Run - до 8 последних временных меток запуска (Windows 10/11)
Volume information - буква тома и серийный номер
Directories referenced - директории, к которым обращался процесс
Files referenced - файлы, которые процесс загрузил (DLL, конфигурации)

Обнаружили

Код:

PSEXESVC.EXE-.pf

? След PsExec на целевом хосте - подтверждение lateral movement. Видите

Код:

POWERSHELL.EXE-

Код:

.pf

с Run Count = 47 на машине бухгалтера? Это как минимум повод залезть в логи PowerShell (Event ID 4104). Бухгалтеры PowerShell не запускают 47 раз. Никогда.

Для быстрого списка Prefetch-файлов на живой системе:

Код:

Код:

Get-ChildItem -Path C:\Windows\Prefetch -Filter *.pf | Select-Object Name, LastWriteTime | Sort-Object LastWriteTime -Descending

Amcache и ShimCache: артефакты расследования выполнения программ
Amcache и ShimCache (AppCompatCache) - два родственных, но разных артефакта, которые фиксируют информацию о программах в системе. По данным Magnet Forensics, оба предоставляют ценные данные о выполнении программ на Windows-системах. Понимание различий между ними критично для корректной интерпретации - путать их между собой на расследовании чревато ложными выводами.
Amcache.hve: что внутри

Код:

Amcache.hve

- отдельный куст реестра в

Код:

C:\Windows\appcompat\Programs\Amcache.hve

. Хранит:

Полный путь к исполняемому файлу
SHA1-хеш файла (можно тут же проверить по базам IOC)
Размер файла
Временные метки (компиляции, модификации)
Информацию об издателе (Publisher)
Данные об установленных программах и драйверах

Ключевое свойство Amcache - наличие SHA1-хеша. Получили хеш подозрительного бинарника - тут же на VirusTotal или по внутренним IOC-спискам. Лично я начинаю именно с хешей из Amcache: это самый быстрый способ отсеять известную малварь от легитимного софта.
ShimCache (AppCompatCache): разница с Amcache
ShimCache хранится в кусте реестра

Код:

SYSTEM

по пути

Код:

CurrentControlSet\Control\Session Manager\AppCompatCache

. Различия существенные:

ХарактеристикаAmcacheShimCacheХра нилищеОтдельный куст

Код:

Amcache.hve

Внутри куста

Код:

SYSTEM

SHA1-хешДаНетПодтверждает запускНе абсолютное доказательство - записи могут появляться при установке ПО. Подтверждайте через Prefetch или Event ID 4688Не всегда (может фиксировать и незапущенные файлы)Запись в реестрВ реальном времениПри выключении/перезагрузке системыПорядок записейХронологическийСте к (LIFO - последний вошёл, первый вышел)

Критический нюанс: ShimCache не гарантирует, что файл был запущен. Он фиксирует факт обращения к файлу подсистемой совместимости приложений - а это может произойти и при простом просмотре директории в Explorer. Поэтому данные ShimCache нужно подтверждать через Prefetch или Amcache. Без перекрёстной проверки рискуете написать в отчёте «запускался», когда на самом деле «просто лежал».
Практика: AmcacheParser и AppCompatCacheParser

Bash:

Код:

# Парсинг Amcache

AmcacheParser.exe -f

"E:\C\Windows\appcompat\Programs\Amcache.hve"

--csv

"C:\Output"

--csvf amcache.csv

# Парсинг ShimCache из куста SYSTEM

AppCompatCacheParser.exe -f

"E:\C\Windows\System32\config\SYSTEM"

--csv

"C:\Output"

--csvf shimcache.csv

В выводе AmcacheParser ищите:

Бинарники с подозрительными путями (

Код:

Temp

,

Код:

Public

,

Код:

AppData

)
Файлы без цифровой подписи (Publisher = пусто) в системных директориях
SHA1-хеши - проверяйте через threat intelligence платформы

В выводе AppCompatCacheParser обратите внимание на поле Executed (True/False, если определено) и Last Modified Time - сопоставляйте с данными из MFT и Prefetch.
Собираем пазл: корреляция артефактов и построение таймлайна
Отдельные артефакты - фрагменты. Реальная картина инцидента появляется, когда выстраиваешь единую временную шкалу.
Сценарий: реконструкция lateral movement
Допустим, в ходе анализа обнаружилось следующее:

Event Log (Security.evtx): Event ID 4624, Logon Type 3, Source: 10.0.1.15, User: admin, Time: 2024-03-15 14:30:05 UTC
Event Log (System.evtx): Event ID 7045, Service Name: PSEXESVC, Service File Name:

Код:

%SystemRoot%\PSEXESVC.exe

, Time: 14:30:07
MFT: Запись для

Код:

C:\Windows\PSEXESVC.exe

, Created ($SI): 14:30:06, Created ($FN): 14:30:06 - метки совпадают, timestomping отсутствует
Prefetch:

Код:

PSEXESVC.EXE-AD70946C.pf

, Run Count: 1, Last Run: 14:30:07
ShimCache: Запись для

Код:

C:\Windows\PSEXESVC.exe

, Last Modified: 14:30:06

Читаем: в 14:30 с хоста 10.0.1.15 - сетевой логон (Type 3) под учёткой admin. Через 2 секунды на диске появился PSEXESVC.exe (MFT), тут же зарегистрирован как служба (Event ID 7045) и запущен (Prefetch фиксирует один запуск). Классический PsExec для lateral movement - пять артефактов, одна история.
Super timeline через Plaso
Для масштабного расследования, где нужно скоррелировать тысячи артефактов, есть log2timeline/Plaso - парсит десятки типов артефактов и собирает единую временную шкалу:

Bash:

Код:

# Создание super timeline из образа диска (долгий процесс, можно идти за кофе)

log2timeline.py --storage-file timeline.plaso /path/to/disk/image.E01

# Фильтрация и экспорт в CSV

psort.py -o l2tcsv timeline.plaso

"date > '2024-03-15 00:00:00' AND date < '2024-03-16 00:00:00'"

-w filtered_timeline.csv

Plaso автоматически парсит Event Logs, MFT, Prefetch, Amcache, реестр, LNK-файлы, журналы браузеров и десятки других источников. Результат - единый CSV, где события из разных артефактов выстроены хронологически. Загружаете в Timeline Explorer и видите полную последовательность действий атакующего.
Чек-лист DFIR-аналитика: порядок анализа артефактов
Практический порядок действий при расследовании инцидента на Windows-хосте:

Шаг 1 - подготовка:

Снять побитовую копию диска (dd, FTK Imager, R-Studio)
Примонтировать образ в режиме «только чтение»
Зафиксировать временную зону из реестра (

Код:

SYSTEM\CurrentControlSet\Control\TimeZoneInformation

)
Получить базовую информацию о системе: имя хоста, версия ОС, список пользователей

Шаг 2 - быстрый скан:

Прогнать файловую систему через YARA-правила (Loki Scanner, Spyre)
Проверить каталоги

Код:

Temp

,

Код:

Public

,

Код:

AppData

на нетипичные исполняемые файлы

Шаг 3 - Event Logs:

Экспортировать через EvtxECmd в CSV
Отфильтровать критичные Event ID (4624, 4625, 4688, 7045, 4104)
Зафиксировать временные рамки подозрительной активности

Шаг 4 - Prefetch и выполнение:

Парсинг через PECmd
Сопоставить запуски подозрительных бинарников с Event Logs
Проверить Run Count и все временные метки Last Run

Шаг 5 - Amcache и ShimCache:

Извлечь SHA1-хеши через AmcacheParser
Проверить хеши по IOC-базам и VirusTotal
Подтвердить выполнение через перекрёстную проверку с Prefetch

Шаг 6 - MFT:

Парсинг через MFTECmd
Поиск timestomping (расхождение $SI и $FN)
Восстановление метаданных удалённых файлов

Шаг 7 - реестр:

Проверить все ключи persistence через Autoruns на примонтированном образе
Детальный разбор подозрительных ключей через Registry Explorer
Автоматический сбор через RegRipper

Шаг 8 - корреляция:

Построить super timeline (Plaso или ручная корреляция CSV в Timeline Explorer)
Восстановить полную хронологию инцидента
Задокументировать цепочку: initial access → execution → persistence → lateral movement

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

SRUM (System Resource Usage Monitor) - база данных

Код:

C:\Windows\System32\sru\SRUDB.dat

хранит 30-дневную историю использования ресурсов приложениями: сетевую активность, время CPU, дисковые операции. По данным Elcomsoft, SRUM часто сохраняется даже после зачистки других артефактов. Причина банальна: про SRUM мало кто знает - в том числе атакующие. Они вычищают Event Logs, удаляют Prefetch, а SRUM тихо лежит себе и всё помнит.

PCA (Program Compatibility Assistant) - начиная с Windows 11 22H2, файл

Код:

C:\Windows\appcompat\pca\PcaAppLaunchDic.txt

фиксирует запуски приложений в текстовом формате. Новый артефакт, который большинство гайдов не покрывает, а он содержит те же данные о выполнении, что и Prefetch, но в другом формате.

WDI StartupInfo - XML-журналы в

Код:

C:\Windows\System32\WDI\LogFiles\StartupInfo\

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

Эти артефакты дополняют классическую пятёрку и могут дать информацию, которую атакующий не позаботился уничтожить.
Обратная перспектива: что видит пентестер
Для пентестеров и red team операторов понимание форензик-артефактов - вопрос OPSEC. Каждая техника MITRE ATT&CK оставляет определённый след, и знать его - значит контролировать свой шум:

PsExec → Event ID 7045 + 4624 (Type 3) + Prefetch

Код:

PSEXESVC.EXE

+ MFT-запись + ShimCache
Создание службы (T1543.003) → Event ID 7045 + реестр

Код:

SYSTEM\CurrentControlSet\Services\

+ ShimCache бинарника
Scheduled Task (T1053.005) → Event ID 4698 (создание задачи) + XML в

Код:

C:\Windows\System32\Tasks\

+ MFT-запись
Registry Run Keys (T1547.001) → Timestamp последнего изменения ключа Run + Prefetch для запускаемого бинарника
BITS Jobs (T1197) → Event ID 59/60 в

Код:

Microsoft-Windows-Bits-Client/Operational.evtx

+ Prefetch для загруженного файла

Знание этих цепочек позволяет или грамотно зачистить следы (red team), или целенаправленно искать их (blue team). Две стороны одной медали - и чем лучше знаешь обе, тем сильнее как специалист.

Попробуйте на своём тестовом стенде запустить PsExec и пройтись по всем пяти артефактам. Увидите, сколько следов остаётся от одного-единственного lateral movement. После этого вопрос «зачем мне форензика, я же пентестер» отпадёт сам собой.