NTA-платформа генерирует алерт средней критичности: рабочая станция из бухгалтерского сегмента отправила 847 DNS-запросов к одному поддомену за 30 минут. EDR молчит - процесс выглядит как легитимный системный сервис, антивирусная база свежая, сигнатур нет. Через четыре часа расследования стало ясно: это DNS-туннель, через который данные уходили наружу уже 11 дней. Без анализа сетевого трафика канал жил бы ещё месяцы - и никто бы не почесался.
Ниже - два разбора расследования сетевых атак с NTA, как они выглядят в реальной работе аналитика: от первого алерта до containment, с командами и detection-правилами.
Бизнес-логика сетевых атак: зачем SOC-аналитику NTA
Каждая целевая атака проходит через сеть. Initial access, lateral movement, эксфильтрация - всё это генерирует трафик. Атакующий может вычистить логи с хоста, отключить EDR-агент, удалить артефакты с диска. Но сетевой трафик, если он записывается, никуда не денется - это неизменное свидетельство. Подробнее - в нашем руководстве по обнаружение apt атак.NTA (Network Traffic Analysis) - метод мониторинга и анализа сетевой активности для выявления аномалий, включая обнаружение атак по трафику. По данным CyberDefenders, NTA закрывает конкретные слепые зоны, которые endpoint-решения и SIEM в принципе не видят:
East-west трафик невидим для периметровых СЗИ. IDS/IPS и межсетевые экраны стоят на границе. Когда атакующий уже внутри - lateral movement между хостами через SMB, RDP, WinRM для них просто не существует.
Шифрование создаёт слепые зоны. TLS-трафик скрывает payload от legacy-инструментов. Но метаданные - JA3/JA3S-отпечатки, размеры пакетов, интервалы - остаются доступны для поведенческого анализа. Содержимое не видно, а "конверт" - вполне.
Фрагментированная телеметрия скрывает картину. Отдельный алерт SIEM не покажет, что три разных хоста общались с одним внешним IP в течение 72 часов. NTA-платформа видит это как единый паттерн.
Финансовый контекст: с учётом оборотных штрафов за утечки персональных данных время обнаружения (dwell time) напрямую бьёт по кошельку. По данным Softline, рекорд нахождения атакующих в инфраструктуре без обнаружения, зафиксированный PT Expert Security Center, - более 8 лет. NTA-платформа в связке с SIEM сжимает этот промежуток с месяцев до часов.
Кейс 1 - DNS-туннель как C2-канал: расследование шаг за шагом
Требования к окружению
Для воспроизведения аналогичного расследования:- NTA-платформа с DNS-аналитикой: Zeek/Corelight, PT NAD, ExtraHop или Stamus Networks - любая с записью DNS-логов
- Wireshark или tshark версии 4.x для анализа PCAP
- SIEM с корреляцией DNS-событий (Splunk, Elastic, MaxPatrol SIEM)
- RAM: от 16 ГБ на аналитической станции при работе с PCAP объёмом до 2 ГБ
- Доступ к DNS-логам или raw PCAP за минимум 7 дней ретроспективы
Расследование: от алерта до containment
Шаг 1: Триаж алерта. NTA-платформа зафиксировала аномалию - соотношение входящего и исходящего DNS-трафика для одного хоста резко отклонилось от baseline. В терминологии MITRE D3FEND это D3-PHDURA (Per Host Download-Upload Ratio Analysis). Нормальные DNS-запросы порождают компактные ответы; здесь объём TXT-записей в ответах превышал запросы в 8 раз. Классика обратного канала передачи данных - запрашиваешь мало, получаешь подозрительно много.Шаг 2: Проверка запросов. Фильтрация DNS-логов по хосту показала запросы вида
aGVsbG8gd29ybGQ.data.update-srv[.]xyz - поддомены содержат Base64-кодированные строки. Паттерн DNS-туннелирования, соответствующий технике T1071 (Application Layer Protocol). Для верификации в PCAP:
Bash:
tshark -r capture.pcap -Y "dns.qry.name contains '.data.'" -T fields -e frame.time -e ip.src -e dns.qry.name | head -20Шаг 4: Корреляция с endpoint. Процесс, генерировавший запросы - легитимный
svchost.exe, запущенный с нестандартными параметрами командной строки. EDR не сработал: поведение процесса не нарушало локальные политики. Сетевой уровень дал первый и единственный сигнал.Шаг 5: Containment. Домен заблокирован на DNS-резолвере, хост изолирован для forensics. Начато расследование с анализом памяти и дискового образа.
Ключевой вывод: NTA обнаружила C2-канал, работавший 11 дней. EDR и антивирус не зафиксировали ничего. Без записи DNS-трафика канал оставался бы активным неопределённо долго.
Кейс 2 - lateral movement через SMB: аномалия в east-west трафике
Второй разбор - другое расследование, другая инфраструктура. NTA-платформа зафиксировала нетипичную SMB-активность: рабочая станция из сегмента разработки начала устанавливать сессии к четырём серверам, с которыми раньше никогда не общалась. Время - 2:40 ночи, суббота. Разработчики в субботу ночью SMB-шары не монтируют (ну, обычно).Платформа применила D3-PMAD (Protocol Metadata Anomaly Detection) - анализ метаданных протоколов на предмет отклонений от baseline. Нормальный профиль этого хоста: 2-3 SMB-подключения к файловому серверу в рабочие часы. Четыре новых назначения ночью в выходной - явная аномалия.
Трафик показал интересную картину: SMB-сессии содержали обращения к
C$ share с попытками доступа к системным файлам (SAM, SYSTEM) - вероятно, через remote registry или Volume Shadow Copy, что характерно для impacket secretsdump в режиме RemoteOperations. Паузы между сессиями ровно по 90 секунд - sleep-интервал автоматизированного инструмента (живой человек так ровно не работает). Аутентификация через NTLM вместо Kerberos - при обращении по IP-адресу это штатный fallback Windows, но характерно для инструментов lateral movement (impacket, CrackMapExec), которые работают напрямую с IP.Таймлайн: сетевые артефакты плюс события SIEM
Сопоставление алерта NTA с событиями SIEM дало полную цепочку атаки:- 23:10 - VPN-аутентификация скомпрометированной учётной записи (событие VPN-шлюза)
- 23:15 - RDP-вход на рабочую станцию разработчика (Event ID 4624 на контроллере домена)
- 02:40 - начало SMB-перебора по серверному сегменту (алерт NTA)
- 02:55 - попытка создания сервиса через
sc.exeна одном из серверов (Event ID 7045 в SIEM) - 03:10 - NTA фиксирует HTTPS-сессию к внешнему IP с нестандартным JA3-отпечатком - потенциальный C2
От компрометации VPN-учётки до lateral movement - менее четырёх часов. Без анализа сетевого трафика первый алерт возник бы только на шаге 4, когда атакующий уже добрался до серверного сегмента. Разница между "заблокировали на подступах" и "расследуем полный breach".
И вот что здесь показательно: скомпрометированный хост - легитимная рабочая станция с актуальным EDR-агентом. Атакующий не обходил endpoint-защиту - он использовал штатные учётные данные через штатный VPN. NTA увидела аномалию именно потому, что поведенческий профиль хоста резко изменился.
Архитектура NTA для расследований: что собирать и где хранить
Flow Data vs Packet Data
Зрелые инсталляции NTA, по данным CyberDefenders, используют комбинацию двух типов данных. Выбор определяется задачей и бюджетом:| Критерий | Flow Data (NetFlow/IPFIX) | Packet Data (PCAP) |
|---|---|---|
| Объём хранения | ~1% от сырого трафика | Полная копия, терабайты/день |
| Глубина анализа | Метаданные: кто, куда, порт, объём | Полный payload, реконструкция файлов |
| Forensic-ценность | Ограниченная (нет содержимого) | Полная (воспроизведение сессий) |
| Ретроспектива | Месяцы (компактный формат) | Дни-недели (зависит от storage) |
| Нагрузка на инфраструктуру | Минимальная | Значительная |
| Когда использовать | Baseline всей сети, аномалии объёмов | Критичные сегменты: DC, DMZ, серверная |
| Когда НЕ использовать | Нужен payload или реконструкция файлов | Storage ограничен, канал >10 Гбит/с без агрегации |
На практике: flow data - на всех коммутаторах distribution и core. Packet capture - через SPAN/TAP у контроллеров домена, серверов с критичными данными и на выходе из DMZ. Это соответствует NIST CSF DE.AE-01: формирование baseline сетевых операций и ожидаемых потоков данных.
Ориентир по ресурсам: при средней нагрузке 340 Мбит/с (показатель из реального проекта внедрения NTA на промышленном предприятии, описанного интегратором isibi.ru) PCAP-запись на 5 дней потребует ~18 ТБ дискового пространства. Flow-данные за тот же период - около 200 ГБ. Для индексированного трафика на 7 дней закладывайте ещё 5-8 ТБ сверху. Да, хранение - это больно, но без него расследовать нечего.
Detection-чеклист: Sigma-правила и правила корреляции для SOC
Чеклист привязан к сценариям из кейсов выше. Sigma-правила ссылаются на публичный репозиторий SigmaHQ, маппинг - на T1071 (Application Layer Protocol, Command and Control).DNS-туннелирование и C2:
- Подозрительные Base64-строки в DNS-запросах - Sigma-правило
net_dns_susp_b64_queries.yml. Детектирует DNS-запросы с Base64-паттернами в поддоменах - Cloudflared-туннели - Sigma-правило
dns_query_win_cloudflared_communication.yml. Выявляет DNS-запросы, характерные для Cloudflare Tunnel, который атакующие используют для обхода периметра finger.exeкак сетевой канал - Sigma-правилаnet_connection_win_finger.ymlиdns_query_win_finger.yml. Утилитаfinger.exeэксплуатируется для загрузки payload (T1105 - Ingress Tool Transfer, согласно LOLBAS)- Аномальный объём DNS TXT-ответов - кастомное правило: если для хоста объём TXT-ответов превышает объём запросов более чем в 3 раза за 30-минутное окно - алерт
YAML:
# Концепт Sigma-правила: аномальный DNS upload
title: Suspicious DNS TXT Response Volume
status: experimental
logsource:
category: dns
detection:
selection:
dns.record_type: "TXT"
condition: selection | count() by src_ip > 100
timeframe: 30m
level: medium
tags:
- attack.command_and_control
- attack.t1071- Новые SMB-подключения в ночное время - правило корреляции SIEM:
source_host NOT IN baseline_smb_peers AND time NOT IN business_hours. Срабатывает при SMB-сессиях к хостам, отсутствующим в историческом профиле, за пределами рабочего времени - Аномальное соотношение upload/download (D3-PHDURA) - если для хоста исходящий трафик превышает входящий более чем в 3 раза за скользящее окно в 1 час - алерт на потенциальную эксфильтрацию
- JA3-отпечатки вне корпоративного whitelist - формирование whitelist JA3-хешей для легитимных приложений (Chrome, Edge, корпоративные агенты). HTTPS-трафик с JA3-хешем вне списка - кандидат на проверку
- Ретроспективный прогон по новым IOC - при получении свежих индикаторов (IP, домены, JA3-хеши) запуск поиска по сохранённому трафику за максимально доступный период. Именно здесь окупается каждый терабайт хранилища
Ограничения NTA: когда трафик не расскажет всю историю
Расследование сетевых атак NTA - это работа в связке: NTA показывает "что произошло в сети", SIEM - "что зафиксировали логи", EDR - "что случилось на хосте". Ни один из этих источников в одиночку не даёт полную картину. Но именно NTA чаще всего становится первым сигналом при целевых атаках, потому что сетевой трафик нельзя подчистить задним числом.
За последние пару лет вижу устойчивую закономерность: SOC-команды, которые вложились в NTA и - что критично - настроили baseline под свою инфраструктуру, обнаруживают lateral movement заметно раньше тех, кто полагается только на endpoint-телеметрию. Это не вопрос вендора - Zeek с Corelight, PT NAD, ExtraHop или Stamus Networks решают одну задачу разными способами. Вопрос в том, записываете ли вы трафик вообще. Без записи расследовать нечего: остаётся гадать, что атакующий делал между двумя алертами SIEM.
И вот момент, о котором редко говорят вслух: многие инсталляции NTA работают вхолостую. Платформа развёрнута, трафик пишется, но аналитики не описали нормальное поведение сети. Результат - либо шквал ложных алертов (и NTA тихо отключают из рабочего процесса), либо пороги настроены так мягко, что реальная атака проходит мимо. Формирование baseline - одна-две недели ручной работы, и эта работа определяет, станет ли NTA инструментом расследования инцидентов или дорогим украшением серверной. Если Sigma-правила для сетевого детекта в вашем SOC ещё не адаптированы под конкретный стек - на codeby.net есть тред по настройке NTA-detection pipeline с примерами маппинга правил на T1071 под Splunk и Elastic.
Последнее редактирование модератором:
