Итоговый проект • Урок 15

Проект: Расследование инцидента

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

1. Жизненный цикл реагирования на инциденты

Реагирование на инциденты (Incident Response, IR) — это не хаотичные действия, а четко структурированный процесс. Мы будем следовать стандарту NIST SP 800-61, который определяет 4 основных фазы (плюс подготовка и пост-анализ):

        +------------------+
        |   1. Preparation | -> Подготовка до инцидента
        +------------------+
                  |
+-------------------------------------------------------------+
|                 ЦИКЛ РЕАГИРОВАНИЯ                           |
|                                                             |
|   +------------------+      +------------------+            |
|   | 2. Detection &   |----->| 3. Containment,  |            |
|   |    Analysis      |      |    Eradication,  |            |
|   +------------------+      |    & Recovery    |            |
|           ^                 +------------------+            |
|           |                           |                     |
+-------------------------------------------------------------+
                  |
        +------------------+
        | 4. Post-Incident | -> Анализ после инцидента
        |     Activity     |
        +------------------+

Наша задача — пройти через весь этот цикл на примере реалистичного сценария.

2. Идентификация: Выстраивание картины с нуля

Сценарий: В техподдержку поступает заявка от бухгалтера Анны Ивановой: "Мой компьютер работает очень медленно, и антивирус выдает какие-то странные предупреждения". У вас нет никаких других исходных данных.

Шаг 1: Первичный сбор информации (Triage)

Первые вопросы, которые вы задаете:

  • ФИО пользователя: Анна Иванова
  • Имя компьютера (hostname): `ACC-WKS-05`
  • IP-адрес: `10.1.5.25`
  • Время возникновения проблемы: "Примерно час назад"

Шаг 2: Использование системы мониторинга (SIEM)

Это ваш главный инструмент на этом этапе. Вы открываете SIEM (например, ELK Stack или Splunk) и начинаете "копать":

// Псевдо-запрос в SIEM (hostname:"ACC-WKS-05" OR source_ip:"10.1.5.25") AND timestamp > "now-2h"

На что вы обращаете внимание:

  • События EDR/Антивируса: Вы видите алерт: `"powershell.exe spawned a suspicious process cmd.exe which attempted to connect to 185.141.25.142"`. Это наш первый Индикатор Компрометации (IoC).
  • Сетевые логи (Firewall/Proxy): Фильтруете по IP `185.141.25.142`. Видите, что соединение было установлено по порту 443, но WAF/IPS помечает его как "Anomalous C2 Traffic". Это подтверждает, что IP — вредоносный (Command & Control сервер).
  • Логи аутентификации: За 10 минут до алерта EDR вы видите успешный вход пользователя `a.ivanova` с IP-адреса, который ей не свойственен.

Картина начинает проясняться: Учетная запись Анны была скомпрометирована, злоумышленник залогинился и запустил вредоносный PowerShell-скрипт, который установил соединение с C2-сервером.

3. Сдерживание: Остановить распространение огня

Цель этого этапа — не дать атаке распространиться дальше. Скорость имеет решающее значение.

Краткосрочные меры (немедленные действия):

  1. Изоляция хоста: С помощью EDR или сетевых средств (NAC) изолируем хост `ACC-WKS-05` от остальной сети. Он может "говорить" только с серверами ИБ-команды. Важно: не выключайте компьютер! Это уничтожит все улики в оперативной памяти.
  2. Блокировка IoC: Немедленно добавляем IP-адрес C2-сервера (`185.141.25.142`) в черный список на пограничном файрволе.
  3. Блокировка учетной записи: Отключаем учетную запись `a.ivanova` в Active Directory и сбрасываем ее пароль, чтобы злоумышленник не мог использовать ее для бокового перемещения.

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

4. Искоренение: Исследование атакуемой инфраструктуры

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

Шаг 1: Сбор доказательств (Форензика)

Мы работаем с изолированным хостом `ACC-WKS-05`.

  • Снятие дампа оперативной памяти: Используем утилиты вроде FTK Imager Lite или WinPmem для создания полной копии RAM. Это самый ценный артефакт.
  • Создание образа диска: С помощью `dd` (в Linux) или того же FTK Imager создаем побитную копию диска. Всегда работаем только с копией!

Шаг 2: Анализ

Анализ памяти (с помощью Volatility Framework):

  • pstree: Посмотреть дерево процессов. Мы видим, что `explorer.exe` запустил `OUTLOOK.EXE`, тот запустил `WINWORD.EXE`, а тот — `powershell.exe`. Это указывает на фишинговую атаку через вложение в письме.
  • netscan: Посмотреть сетевые соединения, которые были активны в момент снятия дампа. Мы видим то самое соединение с `185.141.25.142`.
  • malfind: Поиск скрытого или внедренного в память другого процесса кода (code injection).

Анализ диска (с помощью Autopsy или SIFT Workstation):

  • Поиск вредоносного файла: Находим PowerShell-скрипт, который был запущен.
  • Анализ механизмов закрепления (Persistence): Проверяем ключи автозагрузки в реестре, планировщик задач, WMI-подписки на наличие следов вредоноса.
  • Восстановление удаленных файлов: Ищем файлы, которые злоумышленник мог удалить, чтобы скрыть следы.

5. Восстановление: Безопасный возврат в строй

После того как мы уверены, что полностью удалили вредонос и поняли вектор атаки, мы можем приступать к восстановлению.

  • Переустановка ОС: Самый надежный способ — не "лечить" систему, а полностью переустановить ее из заведомо чистого "золотого образа".
  • Восстановление данных: Данные пользователя восстанавливаются из бэкапа, сделанного до инцидента.
  • Сброс паролей: Все пароли, которые могли быть скомпрометированы (не только Анны, но и других пользователей, чьи хэши могли быть украдены с машины), должны быть сброшены.
  • Мониторинг: После возвращения машины в строй мы устанавливаем для нее режим усиленного мониторинга на несколько дней, чтобы убедиться, что злоумышленник не вернется.

6. Пост-инцидентный анализ (Lessons Learned)

Это самый важный этап для стратегического улучшения безопасности. Мы собираем всех участников и анализируем инцидент.

Цель — не найти виновного ("Почему Анна открыла этот файл?"), а найти недостатки в системе ("Почему наши технические средства пропустили этот фишинг и почему у Анны были избыточные права?").

Результаты анализа:

  • Корневая причина (Root Cause): Фишинговое письмо с вредоносным макросом.
  • Что сработало хорошо: EDR обнаружил аномальную активность, команда IR быстро среагировала.
  • Что можно улучшить:
    • Технически: Улучшить правила на почтовом шлюзе для блокировки макросов. Внедрить более строгие правила AppLocker, запрещающие запуск PowerShell из офисных приложений.
    • Организационно: Провести внеплановый тренинг по фишингу для отдела бухгалтерии. Пересмотреть права доступа для бухгалтеров по принципу наименьших привилегий.

7. Визуализация данных и отчёты

Как и в пентесте, финальный отчет — ключевой документ.

Отчет об инциденте должен содержать:

  • Резюме для руководства: Краткое описание инцидента, его влияния на бизнес и принятых мер.
  • Детальная хронология событий (Timeline): Поминутное восстановление всей цепочки атаки, от получения фишингового письма до полного восстановления.
  • Анализ корневых причин (Root Cause Analysis).
  • Собранные доказательства и IoC.
  • План действий по улучшению (Action Plan) с конкретными задачами, ответственными и сроками.

Дашборды в SIEM и EDR помогают визуализировать атаку и представить ее руководству в наглядном виде.

8. Ваше итоговое задание: План реагирования

Вы — аналитик SOC. В 03:00 ночи SIEM генерирует алерт: "Multiple failed login attempts for user 'admin' on server 'WEB-PROD-01' from IP 203.0.113.50, followed by a successful login." (Множественные неудачные попытки входа для пользователя 'admin' на сервере 'WEB-PROD-01' с IP 203.0.113.50, за которыми последовал успешный вход).

Ваша задача: Написать краткий, но четкий план действий (Playbook) для дежурного аналитика.

  1. Идентификация (2-3 шага): Какие первые проверки вы сделаете в SIEM и других системах, чтобы подтвердить или опровергнуть инцидент?
  2. Сдерживание (2 немедленных действия): Какие две вещи вы сделаете в первую очередь, если инцидент подтвердится?
  3. Искоренение (1 ключевой артефакт): Какой самый важный артефакт вы должны собрать с сервера `WEB-PROD-01` для расследования?
  4. Пост-инцидентный анализ (1 главный вопрос): Какой главный вопрос вы зададите на разборе полетов, чтобы предотвратить повторение этого инцидента?

Этот кейс проверяет вашу способность быстро принимать решения в стрессовой ситуации и применять на практике весь жизненный цикл реагирования на инциденты.