Анализ вредоносного ПО и IOC в расследовании

Этот урок связывает форензику с анализом вредоносного ПО: как из находки извлечь индикаторы и найти всё заражение.

IOC (Indicator of Compromise) — наблюдаемый признак компрометации: хеш файла, IP/домен, путь, ключ реестра, имя процесса, по которому можно обнаружить заражение на других системах.

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

Безопасное обращение с образцом

Вредоносный файл нельзя запускать на рабочей или своей машине. Его анализируют в изолированной песочнице (отдельная ВМ без доступа в сеть или с контролируемой сетью), а саму копию хранят как улику с хешем и в цепочке хранения. Песочница строится по принципу «ничего наружу»: снимок ВМ для быстрого отката, отдельная виртуальная сеть, фейковые DNS/сервисы (например, INetSim), чтобы вредонос «думал», что вышел в интернет, и раскрыл поведение, не дотягиваясь до реальной инфраструктуры. Анализ образцов делают только так — это требование и безопасности, и закона: распространение вредоносных программ (ст. 273 УК) недопустимо, а ответственный исследователь не должен случайно заразить чужие системы.

Уровни анализа

Статический (без запуска). Хеш, тип файла, строки (strings), импорты, сигнатуры. Быстро и безопасно.
Динамический (запуск в песочнице). Что создаёт, куда подключается, как закрепляется — даёт сетевые и файловые IOC.
Реверс-инжиниринг (глубоко). Дизассемблирование/декомпиляция логики — отдельная дисциплина (есть курс по реверсу), к ней прибегают, когда нужны детали.

# Быстрый статический обзор образца
sha256sum sample.bin                 # хеш -> IOC, проверка по базам
file sample.bin                      # тип файла
strings -n 6 sample.bin | grep -Ei "http|\.exe|cmd|powershell"

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

Извлечение и применение IOC

Из анализа собирают набор индикаторов и оформляют их, например, в формате YARA-правил или списков, чтобы массово искать по инфраструктуре.

Типы IOC:
  файловые : SHA-256, имя, путь
  сетевые  : IP, домен, URL, JA3
  хостовые : ключ реестра, имя службы, mutex
Применение:
  поиск по EDR/SIEM, проверка других машин, блокировка

Отдельно ценны поведенческие индикаторы, выраженные в терминах техник MITRE ATT&CK: «процесс Office порождает PowerShell», «создаётся служба с автозапуском из Temp». Их сложнее обойти, чем статический хеш, и они переносимы между вариантами одного семейства. На практике IOC оформляют машиночитаемо (YARA для файлов, Sigma для логов, фиды для EDR/SIEM), чтобы поиск по парку машин был автоматическим, а не ручным.

Как работает под капотом

IOC — это «отпечатки» конкретной угрозы. Зная хеш вредоноса, EDR/SIEM проверяют, нет ли такого файла где-то ещё; зная C2-домен — нет ли к нему обращений в логах прокси. Так от одной заражённой машины выходят на все остальные. Важно, что IOC бывают хрупкими (хеш меняется при пересборке) и устойчивыми (поведение, инфраструктура) — модель «пирамиды боли» подсказывает опираться на более устойчивые индикаторы.

«Пирамида боли» ранжирует индикаторы по тому, насколько атакующему больно их менять. Хеш — внизу: достаточно перекомпилировать файл, и он другой. IP-адреса и домены — посередине: их меняют, но это уже расходы. На вершине — инструменты и TTP (тактики, техники, процедуры): чтобы обойти детект поведения, злоумышленнику приходится перестраивать саму методику атаки, а это дорого. Поэтому зрелое расследование стремится подняться по пирамиде: от «этот конкретный файл» к «этот способ действовать», и тогда обнаружение остаётся рабочим даже против новых сборок того же актора.

Как анализ малвари замыкает расследование

Стоит увидеть, как этот урок соединяется с предыдущими. Подозрительный файл нашли через артефакты диска (prefetch, ShimCache, /tmp) или восстановили из дампа памяти и сетевого трафика. Из его динамического прогона в песочнице вышли сетевые IOC — C2-домены и адреса. С этими доменами возвращаются к сетевой форензике и логам прокси и проверяют, какие ещё хосты к ним обращались. С файловыми и хостовыми IOC (хеш, мьютекс, ключ автозапуска) идут по парку машин через EDR. Так анализ малвари не отдельный этап, а узел, который замыкает цепочку «диск → память → сеть» в единую картину инцидента и отвечает на главный вопрос: каков масштаб и где границы заражения.

Наконец, важна контекстная атрибуция без перегиба. Совпадение TTP с известной группировкой — повод для гипотезы, а не приговор: техники переиспользуются, инструменты публикуются, ложный флаг возможен. Поэтому в отчёте честно разделяют факты («наблюдали такой-то домен, такое-то поведение») и интерпретации («это согласуется с почерком такой-то кампании»). Образцы при этом анализируют только в изоляции, хранят как улики с хешем и цепочкой хранения и не распространяют — и техническая аккуратность, и закон (273 УК о вредоносных программах) здесь идут рука об руку.

Частые ошибки

Запустить образец на рабочей машине. Риск распространения; только изолированная песочница.
Ограничиться одной машиной. Без поиска по IOC масштаб заражения останется неизвестным.
Опираться только на хеш. Его легко изменить; учитывают и поведенческие/сетевые IOC.
Не сохранить образец как улику. Файл — доказательство, ему нужны хеш и цепочка хранения.
Не оформить IOC машиночитаемо. Без YARA/Sigma/фидов поиск по парку остаётся ручным и неполным.

Итоги

Из находки извлекают IOC (файловые, сетевые, хостовые, поведенческие), чтобы оценить масштаб заражения.
Анализ — в изолированной песочнице: статический, динамический, при необходимости реверс; запуск вредоноса вне изоляции недопустим (273 УК).
Опираются на устойчивые индикаторы (поведение, инфраструктура, TTP по «пирамиде боли»), а не только на легко меняемый хеш, и оформляют их машиночитаемо.