NexaCorp DFIR: INC-2026-001 - Компрометация Linux-инфраструктуры

Расследование DFIR и разработка средств обнаружения по результатам симулированного вторжения в инфраструктуру NexaCorp. Проведено как сольное участие в течение 4 дней (BeCode Brussels Blue & Red Team bootcamp, Mission 01). Результат — отчёт о выводах на 54 страницах (PDF) плюс 7 проверенных правил Suricata, которые обнаруживают зафиксированный инцидент при повторном воспроизведении захвата трафика (PCAP).

Этот репозиторий документирует расследование, проведённое аналитиком SOC в рамках учебной программы BeCode Cybersecurity Bootcamp (набор 2025–2026). Он восстанавливает полное вторжение на основе сетевых данных и журналов, а затем предоставляет проверенный набор правил обнаружения Suricata. Это первый инцидент в серии NexaCorp DFIR.

Содержание

• Оперативное уведомление
• Краткий обзор
• Контекст расследования
• Исполнительное резюме
• Сводка цепочки атаки
• Как читать этот отчёт
• Методология
• Используемые инструменты
• Сводка выводов
• Разработка средств обнаружения
• Структура репозитория
• Воспроизводимость
• Известные ограничения
• Серия NexaCorp DFIR
• Благодарности
• Об авторе
• Лицензия

Оперативное уведомление

Это лабораторное расследование на фиктивной инфраструктуре. NexaCorp — вымышленный клиент, используемый в сценарии для BeCode Brussels Mission 01. Скомпрометированный хост — виртуальная машина Metasploitable 2, намеренно уязвимая для учебных целей по безопасности, а имплант Caldera Sandcat является частью лабораторной работы, обучающей аналитика тому, как выглядит трафик реального злоумышленника. Ни одна реальная организация, сеть или человек не пострадали.

Все IP-адреса, имена хостов и индикаторы компрометации, опубликованные в этом отчёте (172.16.50.10, 192.168.10.10, 10.40.0.200, blue11, mesdec и т.д.), являются лабораторными артефактами, а не реальными угрозами. Не добавляйте их в SIEM в качестве IOCs.

Публикация разрешена тренером лаборатории BeCode (Thomas B.) 17.05.2026. Полное заявление о конфиденциальности содержится в отчёте о выводах (раздел «Распространение и классификация»).

Краткий обзор

Контекст расследования

Сценарий (вымышленный). NexaCorp, клиент среднего размера, обратился в команду синих BeCode Corp после того, как внутренний мониторинг выявил неожиданный исходящий трафик с одного из внутренних Linux-серверов. Межсетевой экран зафиксировал трафик, но не вызвал никаких применимых оповещений. Совету директоров требовалось решение до того, как обратиться к регулирующим органам и предпринять действия по раскрытию информации.

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

Набор доказательств, полученный от клиента:

Учебный контекст. Это расследование было проведено во время BeCode Brussels Blue & Red Team bootcamp (ноябрь 2025 – сентябрь 2026) как Mission 01: одиночное, ограниченное по времени расследование, моделирующее реальное консалтинговое взаимодействие DFIR. Лабораторная инфраструктура, личность NexaCorp и значения IOCs намеренно вымышлены. Методология, инструменты и формат отчёта соответствуют реальным стандартам (NIST SP 800-61r2, SANS PICERL, MITRE ATT&CK).

Исполнительное резюме

📄 Полный отчёт о выводах на 54 страницах является каноническим результатом. Скачать PDF (215 КБ) или просмотреть исходник Markdown для поиска/цитирования.

Вечером 09.05.2026 в 22:53 UTC внешний злоумышленник (172.16.50.10) скомпрометировал внутренний сервер NexaCorp (192.168.10.10), используя CVE-2011-2523 — бэкдор, присутствующий в vsftpd 2.3.4 (сборка, которая публично документирована как скомпрометированная с июля 2011 года). Один запрос FTP USER, оканчивающийся на :), вызвал неаутентифицированную корневую привязную оболочку (bind shell) на TCP/6200. Злоумышленник выполнил 8 команд разведки в течение 20-секундной сессии (без сохранения доступа, без эксфильтрации, без бокового перемещения через этот вектор доступа) и отключился.

Независимо, на том же хосте был обнаружен ранее установленный агент MITRE Caldera "Sandcat" (находится в /opt/caldera/sandcat, root, демонизированный), отправляющий сигналы (beacon) каждые 40–50 секунд в открытом виде по HTTP на 10.40.0.200:8888 на протяжении всего захваченного окна. Это и есть «необычное исходящее соединение», первоначально отмеченное клиентом, и указывает на предыдущую компрометацию, не представленную в наборе доказательств (имплант уже был активен в первом кадре PCAP).

Существующий SIEM Wazuh обработал 397 событий с целевого хоста, но вызвал только 4 оповещения высокой степени серьезности (1.0% от общего числа), все классифицированные как общие атаки методом перебора (MITRE T1110). Ни одно из них не идентифицировало эксплойт CVE-2011-2523, привязную оболочку на TCP/6200 или канал C2 Caldera: байт эксплойта (USER baduser:)) никогда не регистрируется самим vsftpd, а SIEM не имел сетевой телеметрии для остального. 7 правил Suricata, поставленных в Фазе 2, закрывают все три пробела.

Основные IOCs (лабораторные, не вносить в реальный SIEM):

Сводка цепочки атаки

Зафиксированный инцидент имеет две отдельные ветки, восстановленные из PCAP:

1. Открытая служба: vsftpd 2.3.4 — сборка с публично документированным бэкдором (CVE-2011-2523), была доступна во внутренней сети (Вывод I1).
2. Эксплойт: один запрос FTP USER, оканчивающийся на :), активировал бэкдор (Вывод I3).
3. Корневая привязная оболочка: неаутентифицированная корневая оболочка открылась на TCP/6200; злоумышленник выполнил 8 команд разведки в течение 20-секундной сессии, затем отключился — без сохранения доступа или эксфильтрации через этот вектор (Вывод I4).
4. Параллельный C2 (существовавший ранее): независимо, имплант MITRE Caldera Sandcat уже отправлял сигналы в открытом виде по HTTP на 10.40.0.200:8888 на протяжении всего окна, что является доказательством предыдущей компрометации, не представленной в наборе доказательств (Вывод I5).

Как читать этот отчёт

Репозиторий организован так, чтобы вы могли погрузиться на нужную глубину в зависимости от вашей роли:

Канонический результат: PDF в reports/. Исходник Markdown содержит идентичное содержимое и хранится в репозитории для удобства поиска и управления версиями.

Журнал расследования: notes/journal.md — это рабочая тетрадь аналитика (проверенные и опровергнутые гипотезы, инвентаризация доказательств, статус плана). Он дополняет формальный отчёт, показывая как были получены выводы, а не только сами выводы.

Набор правил обнаружения: detection/lab.rules содержит 7 правил Suricata с полным обоснованием каждого ключевого слова в встроенных комментариях. detection/README.md документирует рабочий процесс развёртывания и проверки воспроизведением, используемый для подтверждения того, что каждое правило срабатывает на зафиксированном инциденте.

Методология

Расследование следует трём отраслевым стандартным фреймворкам, наложенным друг на друга.

NIST SP 800-61r2: Руководство по обработке инцидентов компьютерной безопасности

Четырёхфазная модель NIST (Подготовка, Обнаружение и анализ, Сдерживание/Устранение/Восстановление, Действия после инцидента) обеспечивает общую структуру. В этом расследовании Фаза 1 результата соответствует NIST «Обнаружение и анализ» (криминалистический анализ PCAP, корреляция SIEM, восстановление временной шкалы действий злоумышленника). Фаза 2 соответствует NIST «Извлечённые уроки», переведённые в превентивные меры (7 правил Suricata и приоритетный список рекомендаций в разделе 7 отчёта).

SANS PICERL: тактический поток расследования

PICERL (Подготовка, Идентификация, Сдерживание, Устранение, Восстановление, Извлечённые уроки) — это процесс реагирования на инциденты SANS. Применено в этом расследовании:

MITRE ATT&CK: сопоставление техник

Каждый вывод сопоставлен с одной или несколькими техниками MITRE ATT&CK, чтобы позволить клиенту соотнести этот инцидент с существующей моделью угроз. 14 различных техник используются в 10 выводах:

• Разведка: T1595.002, T1592.002, T1589
• Начальный доступ: T1190 (Эксплойт общедоступного приложения через CVE-2011-2523)
• Выполнение: T1059.004 (Оболочка Unix)
• Обнаружение: T1033, T1082, T1087.001, T1083, T1016, T1049, T1046
• Доступ к учётным данным: T1110 (Перебор)
• Командно-контрольный канал: T1071.001, T1102 (Сигнал Caldera Sandcat)
• Повышение привилегий: T1078.003, T1548.003 (предполагаемая активность sudo)

Полная таблица техник по выводам находится в разделе 4 отчёта (IOCs) и в углублённых анализах каждого вывода в разделах 3 и 5.

Воспроизводимость

Каждое утверждение в отчёте связано с артефактом в наборе доказательств, с указанием точного фильтра tshark, запроса Wazuh или команды воспроизведения Suricata, необходимой для его повторения. См. Приложение A (Команды воспроизведения) в отчёте и раздел Воспроизводимость ниже для быстрого старта.

Используемые инструменты

Сетевая криминалистика

• tshark: CLI Wireshark для триажа PCAP, восстановления TCP-потоков (-z follow,tcp,ascii), фильтрации протоколов и извлечения полей
• tcpreplay и tcprewrite: воспроизведение PCAP на живом интерфейсе мониторинга для проверки правил Suricata, с корректировкой MTU для соответствия лабораторному ens19 (1450 байт)
• Декодеры Base64: восстановление полезных нагрузок C2 Caldera Sandcat (тело сигнала и ответ оператора)

Сетевая IDS / разработка средств обнаружения

• Suricata 6.0.4 (режим afpacket, однопоточный, Hyperscan отключён в лаборатории): созданы, проверены и настроены 7 правил в этом результате
• suricata -T: проверка конфигурации и правил при развёртывании и настройке
• kill -USR2 $(pgrep suricata): перезагрузка правил на лету во время итеративной настройки

SIEM и хостовая телеметрия

• Wazuh (менеджер + панель управления): корреляция событий, анализ распределения по степени серьёзности, поиск правил (rule.id 11452, 5551 и т.д.), экспорт CSV 397 событий
• Стандартные текстовые утилиты Linux (grep, awk, jq): анализ журналов и разбор JSON

Контекст эмуляции противника (упоминается, не эксплуатируется)

• MITRE Caldera (агент Sandcat): присутствует на целевом хосте как симулированный ранее установленный C2-имплант, который характеризуется

Эталонные фреймворки

• NIST SP 800-61r2: Руководство по обработке инцидентов компьютерной безопасности
• SANS PICERL: тактический поток расследования
• MITRE ATT&CK: атрибуция техник
• Консультация по CVE-2011-2523: справочник по бэкдору vsftpd 2.3.4

Сводка выводов

10 выводов (I1–I10) подробно описаны в отчёте о выводах. Каждая запись включает доказательства, команды воспроизведения, сопоставление с MITRE ATT&CK и рекомендации по устранению.

Распределение по степени серьёзности: 3 КРИТИЧЕСКИЕ / 3 ВЫСОКИЕ / 2 СРЕДНИЕ / 2 НИЗКИЕ

Рекомендуемый порядок чтения: начните с I1 (уязвимая служба), затем I3 и I4 (фактическая цепочка эксплуатации), затем I5 (параллельный, несвязанный C2-имплант). I2 и I6 дают контекст разведки. I7–I10 — это выводы об оборонительной позиции (что мониторинг видел и что пропустил).

Разработка средств обнаружения

Фаза 2 расследования создала 7 правил Suricata (SID 9000001–9000007), покрывающих зафиксированный инцидент с трёх сторон: сигнатура эксплойта, оболочка после эксплойта и параллельный канал C2. Каждое правило проверено автономным воспроизведением PCAP на экземпляре Suricata 6.0.4 на рабочей станции SOC.

7 правил

Сводка проверки

Разница 40 против 314 отражает намеренное ограничение для правил 9000003, 9000004, 9000005, 9000006, чтобы предоставить аналитикам SOC чистый оперативный вид, сохраняя при этом сырой поток предупреждений в eve.json для углублённого криминалистического анализа.

Заметные проектные решения

Четыре итеративных исправления во время развёртывания задокументированы в detection/README.md. Ключевые уроки:1. Обнаружение HTTP независимо от порта. Правила 9000004 и 9000005 (Caldera) изначально были написаны с использованием ключевых слов alert http и http.uri, которые задействуют HTTP-парсер Suricata только на порту 80. C2-сервер Caldera работает на порту 8888, поэтому парсер оказывался не задействован, и правила никогда не срабатывали. Исправление: переписать в режиме TCP+content (alert tcp ... content:"POST /beacon"; content:"Go-http-client/1.1";), который сопоставляет сырые байты HTTP независимо от порта. 2. flow:established ненадёжен при воспроизведении PCAP. Захваченное TCP-рукопожатие за пределами окна воспроизведения оставляет конечный автомат потока в неопределённом состоянии. Удаление flow:established из правил Caldera обеспечивает их срабатывание как в живом режиме, так и при воспроизведении. 3. Явное направление потока для правил только с SYN. Правило 9000003 (порт 6200) выдавало SC_WARN_POOR_RULE: SYN-only ... w/o direction specified. Исправлено добавлением flow:to_server,not_established. 4. HOME_NET vs в лабораториях только с RFC1918. Когда атакующий, цель и C2 находятся в частном пространстве, становится пустым, и правила вида никогда не срабатывают. Исправление для лаборатории: использовать в обоих. Исправление для продакшена: сузить только до защищённого сегмента.

Соображения о ложных срабатываниях

Анализ ложных срабатываний для каждого правила задокументирован в отчёте, раздел 8.5. Большинство правил несут незначительный риск в правильно спроектированной среде; правила 9000005 (заголовок Server aiohttp) и 9000006 (curl/Wget на административных путях) требуют настройки, если присутствуют безвредные внутренние Python-сервисы или административные скрипты.

Структура репозитория```text

NexaCorp-DFIR-INC-2026-001/ ├── README.md (this file) ├── LICENSE (MIT) ├── .gitignore ├── .github/ │ └── workflows/ │ └── ci.yml markdownlint + typography + Suricata rule check ├── reports/ │ ├── INC-2026-001_Findings_Report.pdf canonical 54-page deliverable │ └── INC-2026-001_Findings_Report.md same content, Markdown source ├── detection/ │ ├── lab.rules 7 Suricata rules (SID 9000001-9000007) │ └── README.md deploy + replay validation workflow ├── evidence-summary/ │ └── ioc-summary.md indicators of compromise (SIEM-ingestible) ├── methodology/ │ ├── attack-timeline.md incident timeline (UTC) │ └── attck-mapping.md MITRE ATT&CK mapping table └── notes/ └── journal.md analyst investigation journal (hypotheses, plan, IOCs, timeline)

**Классификация файлов:**

| Путь | Роль | Аудитория |
|---|---|---|
| `reports/*.pdf` | Основной результат, формальный отчет | Клиент, рекрутер, аудитор |
| `reports/*.md` | То же содержимое, удобный для grep источник | Любой, кто цитирует или сравнивает |
| `detection/lab.rules` | Готовый к использованию набор правил Suricata | SOC / инженер по обнаружению |
| `detection/README.md` | Руководство по развертыванию и проверке воспроизведения | Введение для инженера по обнаружению |
| `evidence-summary/ioc-summary.md` | Индикаторы компрометации, по категориям | SOC / охота за угрозами |
| `methodology/attack-timeline.md` | Временная шкала инцидента (UTC) | Специалист по DFIR |
| `methodology/attck-mapping.md` | Таблица соответствия MITRE ATT&CK | DFIR / инженер по обнаружению |
| `notes/journal.md` | Рабочая тетрадь расследования | Специалист по DFIR, изучающий метод |
| `.github/workflows/ci.yml` | Автоматическая проверка markdownlint, типографики и правил Suricata (`suricata -T`, запускается при наличии `detection/*.rules`) при push | CI |

## Воспроизводимость

Каждое утверждение в отчете о результатах можно проследить до артефакта в пакете доказательств. Сам PCAP-файл не распространяется (собственность лаборатории BeCode), но команды и запросы задокументированы, чтобы любой, у кого есть своя копия, мог воспроизвести анализ.

### Воспроизведение основных результатов (анализ PCAP)

Требуется `tshark` (CLI Wireshark) и оригинальный `attack.pcap`:```bash
# 1. PCAP overview
tshark -r attack.pcap -q -z io,stat,0

# 2. TCP conversations (reveals attacker, target, C2)
tshark -r attack.pcap -q -z conv,tcp | head -30

# 3. Confirm vsftpd 2.3.4 banner exposure (Finding I1)
tshark -r attack.pcap -Y "ftp && ip.src == 192.168.10.10" \
  -T fields -e frame.time -e ftp.response.code -e ftp.response.arg | head -5

# 4. Find the CVE-2011-2523 exploit payload (Finding I3)
tshark -r attack.pcap -Y 'ftp.request.command == "USER"' \
  -T fields -e frame.time -e ftp.request.arg

# 5. Reconstruct the root shell session on TCP/6200 (Finding I4)
tshark -r attack.pcap -q -z follow,tcp,ascii,70

# 6. Reconstruct the Caldera C2 beacon (Finding I5)
tshark -r attack.pcap -q -z follow,tcp,ascii,6 | head -50

Воспроизвести проверку правил (Suricata replay)

Требуется Suricata 6.0.x, tcpreplay, и контролируемый интерфейс (ens19 в лаборатории; замените на свой):```bash

1. Install the ruleset

sudo cp detection/lab.rules /etc/suricata/rules/learner/lab.rules

2. Hot-reload Suricata without restart

sudo kill -USR2 $(pgrep -f suricata) sleep 5

3. Clear the alert log for a clean baseline

sudo truncate -s 0 /var/log/suricata/fast.log

4. Replay the PCAP at top speed

sudo tcpreplay --intf1=ens19 --topspeed attack_mtu.pcap

5. Count alerts per rule (expect 7 distinct SIDs)

sudo grep -oE '[1:[0-9]+:' /var/log/suricata/fast.log | sort | uniq -c | sort -rn

Ожидаемый вывод (после одного полного повтора):```text
     30 [1:9000002:    (vsftpd banner repeated per session)
      3 [1:9000007:    (FTP USER enumeration threshold)
      3 [1:9000006:    (HTTP admin path enumeration)
      1 [1:9000005:    (Caldera C2 response)
      1 [1:9000004:    (Caldera Sandcat beacon, throttled)
      1 [1:9000003:    (Backdoor port 6200 SYN)
      1 [1:9000001:    (vsftpd USER smiley exploit)

7/7 правил срабатывают корректно. Полный пакет доказательств (fast.log, eve.json, конфигурация троттлинга, снимок версии Suricata) перечислен в Приложении E отчета о результатах.

Known limits

• Пакет доказательств начинается в середине инцидента. PCAP начинается в 2026-05-09 20:08 UTC, но агент Caldera Sandcat уже активно отправляет маячки в кадре 1. Первоначальная компрометация, установившая имплант, произошла раньше и не представлена в данных. Выводы о действиях до имплантации экстраполированы из полей full_log Wazuh, а не из прямых наблюдений.
• Журналы аудита хоста не перекрывают окно атаки. Локальные auth.log и syslog начинаются примерно через 5 часов после завершения PCAP, причем первой записью является syslogd restart (вероятно, перезагрузка ВМ). Ротированные файлы журналов не были предоставлены. Это задокументировано как Находка I10.
• Объем включал криминалистику и разработку детектирования, а не реагирование в реальном времени. Сдерживание, устранение, криминалистическое копирование (образ памяти, образ диска) и перечисление механизмов постоянства задокументированы как рекомендации P0 в отчете, но не были выполнены: в рамках задания не было доступа к работающему хосту. Для закрытия этих вопросов потребуется дополнительное задание.
• 7 правил Suricata обнаруживают подпись этого конкретного инцидента. Искушенный злоумышленник может обойти их, изменив байтовый шаблон эксплойта (альтернативные нулевые терминаторы в аргументе USER), перекомпилировав Caldera с другим User-Agent или переведя C2 на зашифрованный HTTPS (запасным вариантом стал бы анализ метаданных TLS, такой как JA3/JA4). Правила подходят для зафиксированного сценария угрозы; долгосрочная стратегия обнаружения должна добавить поведенческие детектирования и детектирования на основе метаданных.
• Пробел в приеме данных Wazuh во время расследования. Конвейер приема журналов SIEM был временно недоступен до 2026-05-11 11:39 UTC (в середине расследования, восстановлен лабораторным коучем). Таким образом, 4 оповещения высокой степени серьезности отображаются на панели управления с временными метками приема (May 11 13:17-13:28), а не с фактическими временными метками инцидента (May 9 21:00-22:53), что искажает видимое время событий корреляции.

NexaCorp DFIR series

• INC-2026-001: этот репозиторий
• INC-2026-002: повышение привилегий и постоянство (Tor SSH, SUID, бэкдор-аккаунт)
• INC-2026-003: оценка перекрестных инцидентов за месяц 1
• INC-2026-004: SQL-инъекция (веб-портал)
• INC-2026-005: инъекция команд ОС и веб-шелл (веб-портал)
• INC-2026-006: сохраненный XSS и перехват сессии (веб-портал)
• INC-2026-007: IDOR и нарушенный контроль доступа (NexaPortal); итоговый проект месяца 2
• INC-2026-008: разведка AD и Kerberoasting (первый инцидент месяца 3)

Acknowledgments

• Thomas B. (лабораторный коуч BeCode): разработка сценария, исправление приема данных Wazuh в середине расследования, разрешение на публикацию для портфолио.
• MITRE за фреймворк Caldera, который обеспечил работу симулированного C2-импланта, и за базу знаний ATT&CK, использованную для картирования каждой находки.
• Проект Suricata за движок, который позволил развернуть 7 правил менее чем за 30 минут.

About

Индивидуальное задание по DFIR, выполненное в рамках буткемпа Blue & Red Team BeCode Brussels (ноябрь 2025 – сентябрь 2026), Миссия 01, 2026-05-15.

Автор: Johan-Emmanuel Hatchi (LinkedIn).

Открыт для возможностей стажировки в области кибербезопасности с сентября 2026 года в Бельгии. Ищу роли в SOC / DFIR / разработке детектирования, где будет востребована такая работа по сквозному расследованию (криминалистика PCAP, корреляция SIEM, написание правил IDS, формальная отчетность для клиентов).

License

MIT, 2026 Johan-Emmanuel Hatchi.

Правила Suricata в detection/lab.rules и текст отчета выпущены под одной лицензией MIT: свободно копировать, адаптировать и повторно развертывать с указанием авторства. PCAP, лабораторная инфраструктура и брифинги задания остаются собственностью BeCode Brussels и не распространяются.