Security Operations Center

Анализ сетевого трафика

Справочное руководство SOC-аналитика по обнаружению вредоносной активности в сетевом трафике — от базовых Wireshark-фильтров до TLS-фингерпринтинга и написания IDS-правил

🌊

Основы Network ForensicsЧто, зачем и как анализировать в сетевом трафике

Network Forensics — это захват, запись и анализ сетевого трафика для обнаружения вторжений, расследования инцидентов и извлечения доказательств. Для SOC-аналитика сетевой трафик — один из главных источников информации: именно в трафике видны обращения к C2-серверам, эксфильтрация данных, lateral movement, загрузка вредоносных пейлоадов и DNS-резолвинг вредоносных доменов. Даже если endpoint скомпрометирован и логи стёрты — сетевые артефакты остаются на SIEM, NDR и PCAP-записях.

Что анализировать

Типы сетевых артефактов

PCAP / PCAPNGПолный захват пакетов — содержит все данные трафика. Основной формат для глубокого анализа в Wireshark. Генерируется через tcpdump, Wireshark, Zeek, сетевые TAP'ы.

NetFlow / IPFIXМетаданные о соединениях: IP-адреса, порты, протоколы, объём трафика, длительность. Без содержимого пакетов, но охватывает весь трафик организации. Идеален для обнаружения аномалий.

DNS-логиЗаписи DNS-запросов и ответов. Источник: DNS-сервер, Sysmon (Event ID 22), Zeek (dns.log), Pi-hole. Критичны для обнаружения DGA, tunneling, C2.

Proxy / Firewall логиHTTP-запросы через корпоративный прокси, accept/deny записи файрвола. Содержат URL, User-Agent, категории сайтов, объём трафика.

Инструменты

Основной стек

Wireshark / tshark — захват и интерактивный анализ PCAP. Де-факто стандарт.
tcpdump — CLI-захват пакетов на Linux. Быстр, не требует GUI.
Zeek (бывш. Bro) — сетевой мониторинг, генерирует структурированные логи (conn.log, dns.log, http.log, ssl.log).
NetworkMiner — пассивный анализ PCAP: извлечение файлов, изображений, credentials, OS fingerprinting.
Arkime (бывш. Moloch) — полнопакетный захват и индексация в масштабе предприятия.
Suricata / Snort — IDS/IPS с сигнатурными правилами для обнаружения атак в трафике.

Первый шаг: Получив PCAP для анализа, начните с Statistics → Conversations и Statistics → Protocol Hierarchy в Wireshark — это даст общую картину: кто с кем общается, какие протоколы, какой объём. Не погружайтесь в отдельные пакеты, пока не видите картину целиком.

🦈

Wireshark — фильтры и приёмыDisplay filters, capture filters, ключевые приёмы для SOC-аналитика

Display Filters vs Capture Filters

Capture filters (BPF-синтаксис) применяются при захвате — пакеты, не прошедшие фильтр, не сохраняются вовсе. Display filters (Wireshark-синтаксис) применяются к уже захваченным данным — они фильтруют отображение, не удаляя пакеты. В SOC чаще всего работают с display filters при анализе готового PCAP.

Шпаргалка по Display Filters

Базовые фильтры

Wireshark Display Filtersip.addr == 192.168.1.100             # Трафик от/к конкретному IP
ip.src == 10.0.0.5                    # Только исходящий трафик с IP
ip.dst == 8.8.8.8                     # Только входящий на IP
tcp.port == 443                       # TCP порт 443 (HTTPS)
udp.port == 53                        # UDP порт 53 (DNS)
tcp.flags.syn == 1 && tcp.flags.ack == 0   # SYN-пакеты (новые соединения)
frame.time >= "2026-01-15 10:00:00"   # Временной диапазон

Протокольные фильтры

Протоколыdns                                   # Весь DNS-трафик
http                                  # Весь HTTP-трафик (не HTTPS!)
http.request.method == "POST"         # Только HTTP POST-запросы
http.request.uri contains "login"     # URL содержит "login"
http.host contains "evil"             # Хост содержит "evil"
tls.handshake.type == 1               # TLS Client Hello (начало соединения)
tls.handshake.extensions.server_name  # SNI — имя целевого хоста
smtp                                  # Email-трафик (SMTP)
ftp                                   # FTP-трафик (логины, файлы)

Фильтры для Threat Hunting

Threat Hunting# Подозрительные DNS-запросы (длинные домены — возможный tunneling)
dns.qry.name.len > 50

# HTTP к IP-адресу (без домена) — признак C2
http.host matches "^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$"

# Нестандартные порты для HTTP
http && !(tcp.port == 80 || tcp.port == 443 || tcp.port == 8080)

# Большие DNS-ответы (возможный DNS tunneling)
dns.resp.len > 512

# Исходящий трафик на нестандартные порты
tcp.dstport > 1024 && !(tcp.dstport == 8080 || tcp.dstport == 8443 || tcp.dstport == 3389)

# TLS без SNI (подозрительно — легитимные браузеры отправляют SNI)
tls.handshake.type == 1 && !tls.handshake.extensions.server_name

# Пакеты с данными после TCP handshake (PSH,ACK) к одному IP
ip.dst == SUSPECT_IP && tcp.flags.push == 1

Ключевые приёмы

Follow Stream

Правый клик на пакете → Follow → TCP Stream (или HTTP, TLS, UDP). Показывает полное содержимое диалога между клиентом и сервером в читаемом виде. Незаменимо для чтения HTTP-запросов/ответов, извлечения передаваемых данных, просмотра командного интерфейса C2.

Statistics — ключевые пункты

Conversations: таблица всех IP-пар с объёмом трафика. Сортируйте по Bytes — крупнейшие потоки могут быть эксфильтрацией.
Protocol Hierarchy: дерево протоколов. Необычный процент трафика на DNS или ICMP — признак tunneling.
Endpoints: все IP-адреса с количеством пакетов и байт. Быстро находит «шумных» хостов.
DNS: статистика DNS-запросов. Много запросов к одному домену — возможный beaconing.
I/O Graphs: временная шкала трафика. Пики совпадают с инцидентом? Периодические всплески = beaconing.

tshark для автоматизации: tshark -r traffic.pcap -T fields -e ip.src -e ip.dst -e dns.qry.name -Y "dns" | sort | uniq -c | sort -rn — извлечение всех DNS-запросов с подсчётом частоты, прямо из командной строки.

🔤

DNS-аномалииОбнаружение вредоносной активности через DNS-трафик

Почему DNS критичен

DNS — «ахиллесова пята» большинства малвари: даже если C2-трафик зашифрован, DNS-запросы к вредоносным доменам остаются видимыми (если не используется DoH/DoT — см. секцию 11). Более того, DNS используется для tunneling (передачи данных через DNS-запросы), DGA (генерации доменов для уклонения от блокировок) и как канал эксфильтрации.

Что искать

DGA-домены (Domain Generation Algorithms)

Малварь генерирует псевдослучайные доменные имена для связи с C2, затрудняя блокировку. Признаки DGA:

Высокая энтропия имени домена: x7kd9mq2p.com, ahjf83hd.net — выглядят как случайные символы.
Большое количество NXDOMAIN-ответов (домен не существует) — малварь перебирает сгенерированные домены, пока не найдёт активный.
Однообразная структура: одинаковая длина, один TLD, одинаковый паттерн.

Wireshark# NXDOMAIN-ответы (домен не найден)
dns.flags.rcode == 3

# Запросы к длинным доменам
dns.qry.name.len > 30

# Подсчёт NXDOMAIN (tshark)
tshark -r traffic.pcap -Y "dns.flags.rcode == 3" -T fields -e dns.qry.name | sort | uniq -c | sort -rn | head -20

DNS Tunneling

Передача данных (C2-команд, эксфильтрации) через DNS-запросы и ответы. Данные кодируются в поддоменах (aGVsbG8=.evil.com) или в TXT-записях ответа.

Аномально длинные поддомены (base64/hex-кодированные данные).
Большой объём TXT-записей от одного домена.
Высокая частота DNS-запросов к одному домену (десятки/сотни в минуту).
DNS-запросы типа TXT, NULL, CNAME — нетипичные для обычной работы.

Wireshark# TXT-запросы (частый тип для tunneling)
dns.qry.type == 16

# DNS-запросы с длинными поддоменами
dns.qry.name.len > 50

# Конкретный домен
dns.qry.name contains "suspicious-domain.com"

Свежезарегистрированные домены (Newly Registered Domains)

Домены, зарегистрированные менее 30 дней назад — частый признак фишинга и C2. Обнаружение: TI-фиды с NRD-списками, интеграция с Passive DNS (Farsight DNSDB, VirusTotal), корреляция DNS-логов с WHOIS-данными.

Инструменты: Zeek (dns.log с полным разбором DNS), PassiveDNS (историческая база DNS-резолвов), dnstwist (обнаружение тайпсквоттинга — доменов, похожих на легитимные), freq.py (оценка энтропии доменных имён для обнаружения DGA).

📡

Анализ HTTP/HTTPSОбнаружение вредоносных запросов, веб-шеллов и загрузки пейлоадов

HTTP — открытый текст

Нешифрованный HTTP-трафик полностью читаем в PCAP: URL-адреса, заголовки, тела запросов и ответов, загружаемые файлы. Хотя в 2026 году большинство трафика зашифровано (HTTPS), HTTP всё ещё используется малварью (особенно на ранних стадиях), внутри корпоративных сетей и для C2 на нестандартных портах.

Что искать в HTTP

Подозрительные User-Agent

Wireshark# Все User-Agent'ы в PCAP (tshark)
tshark -r traffic.pcap -Y "http.request" -T fields -e http.user_agent | sort | uniq -c | sort -rn

# Подозрительные User-Agent'ы
http.user_agent contains "python"          # Python-скрипты
http.user_agent contains "curl"            # curl
http.user_agent contains "wget"            # wget
http.user_agent contains "PowerShell"      # PowerShell
http.user_agent == ""                      # Пустой User-Agent

Легитимные браузеры имеют длинный и характерный User-Agent. Короткие, нестандартные или отсутствующие — признак малвари или скриптов.

Загрузка вредоносных файлов

Wireshark# Загрузка исполняемых файлов
http.response.content_type contains "application/x-msdownload"
http.response.content_type contains "application/octet-stream"

# Скрипты
http.response.content_type contains "application/javascript"
http.response.content_type contains "application/hta"

# Архивы
http.response.content_type contains "application/zip"

# PE-файлы по magic bytes в теле ответа (MZ заголовок)
http.file_data contains "MZ"

POST-запросы с данными

POST-запросы часто используются для отправки украденных данных (credentials, keylog), получения команд от C2, загрузки файлов на сервер атакующего.

Wireshark# Все POST-запросы
http.request.method == "POST"

# POST с данными формы
http.request.method == "POST" && http.content_type contains "form"

# POST с JSON (часто C2-протоколы)
http.request.method == "POST" && http.content_type contains "json"

# POST на IP-адрес (без домена)
http.request.method == "POST" && http.host matches "^[0-9]"

HTTPS — что видно, что нет

Анализ зашифрованного трафика

В HTTPS содержимое зашифровано, но метаданные доступны:

SNI (Server Name Indication): имя целевого хоста в TLS Client Hello — видно в открытом виде, пока не включён Encrypted Client Hello — см. секцию 13. Фильтр: tls.handshake.extensions.server_name.
Сертификат сервера: Subject, Issuer, дата выдачи, SAN (альтернативные имена). Самоподписанный сертификат = подозрительно.
JA3/JA4-фингерпринты: уникальная «подпись» TLS-клиента (см. секцию 06).
Размер и тайминги: объём данных и частота пакетов — видны даже в зашифрованном трафике.

Расшифровка HTTPS: Если у вас есть SSLKEYLOGFILE (pre-master secrets из браузера) или приватный ключ сервера — Wireshark может расшифровать TLS-трафик. В Wireshark: Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename.

📶

Обнаружение C2 и BeaconingИдентификация Command and Control коммуникаций

Что такое beaconing

Beaconing — периодические обращения заражённого хоста к C2-серверу для получения команд. Это характерный сетевой паттерн большинства RAT, ботнетов и пост-эксплуатационных фреймворков (Cobalt Strike, Sliver, Havoc). Beaconing может быть точным (каждые 60 секунд) или с jitter (случайный разброс ±10–50% от интервала для маскировки).

Методы обнаружения

Временной анализ (Timing Analysis)

Постройте график запросов от подозрительного хоста к внешнему IP во времени (I/O Graphs в Wireshark или Excel).
Вычислите интервалы между запросами. Если они стабильны (±jitter) — это beaconing.
Типичный интервал Cobalt Strike по умолчанию — 60 секунд (настраивается через sleep/jitter в Malleable-профиле). Meterpreter и кастомные RAT — от единиц секунд до произвольных значений. Точные числа зависят от версии и конфигурации, поэтому опирайтесь на регулярность, а не на «магическую» константу.
Формула: стандартное отклонение интервалов / средний интервал. Если результат <0.5 — высокая регулярность, вероятный beaconing.

tshark — извлечение таймингов# Извлечь временные метки подключений к подозрительному IP
tshark -r traffic.pcap -Y "ip.dst == SUSPECT_IP && tcp.flags.syn == 1 && tcp.flags.ack == 0" -T fields -e frame.time_epoch

# Подсчёт интервалов между подключениями (bash)
... | awk 'NR>1 {print $1 - prev} {prev=$1}'

Объёмный анализ (Data Size Analysis)

C2-beaconing часто имеет характерный размер пакетов: маленькие запросы (check-in) и маленькие ответы (no task).
Когда оператор отправляет команду — размер ответа увеличивается.
Стабильно одинаковый размер пакетов при каждом обращении — дополнительный индикатор.

Характерные признаки известных C2-фреймворков

Cobalt StrikeDefault URI: /submit.php, /__utm.gif, /pixel.gif. Malleable C2 позволяет кастомизировать профиль. JA3: 72a589da586844d7f0818ce684948eea — но этот же хэш делят Metasploit и кампании Emotet (классическая коллизия JA3), так что он не уникален для CS.

Metasploit MeterpreterHTTP: URI содержит 4-символьные чексуммы. HTTPS: самоподписанный сертификат с Issuer: CN=localhost.

SlivermTLS, WireGuard, HTTP/HTTPS. HTTP-профиль по умолчанию имитирует jQuery-загрузку. Уникальные паттерны в TLS.

Cobalt Strike DNSDNS-beaconing через A/AAAA/TXT-записи. Поддомен содержит закодированные данные. Характерный паттерн: [a-f0-9]{12}.c2domain.com.

Инструменты: RITA (Real Intelligence Threat Analytics) — open-source, автоматически обнаруживает beaconing в Zeek-логах. flare-fakenet-ng — для анализа C2 в изолированной среде. Beacon Hunter (ELK-дашборд) — визуализация beaconing-паттернов.

🔏

TLS-фингерпринтинг (JA3/JA4)Идентификация вредоносных клиентов по параметрам TLS-рукопожатия

Принцип

Каждый TLS-клиент (браузер, малварь, скрипт) формирует уникальный набор параметров в сообщении Client Hello: версия TLS, поддерживаемые шифронаборы (cipher suites), расширения (extensions), эллиптические кривые, point formats. Из этих параметров вычисляется хэш — TLS-фингерпринт, уникальный для конкретного ПО.

JA3 / JA3S

Как работает

JA3 — MD5-хэш параметров Client Hello: TLSVersion + Ciphers + Extensions + EllipticCurves + EllipticCurvePointFormats. Идентифицирует клиента.
JA3S — MD5-хэш параметров Server Hello. Идентифицирует сервер.
Пара (JA3 + JA3S) — ещё более уникальная подпись, так как один сервер может отвечать по-разному разным клиентам.
Один и тот же Cobalt Strike Beacon будет иметь одинаковый JA3 на разных хостах, даже если IP и домен C2 меняются.

Wireshark# Wireshark считает JA3/JA4 нативно — плагин в актуальных версиях не нужен
# tls.handshake.ja3       — исходная строка JA3
# tls.handshake.ja3_hash  — собственно MD5-хэш JA3
# tls.handshake.ja4       — JA4-фингерпринт

# Поиск по известному JA3-хэшу (именно поле _hash, а не строка)
tls.handshake.ja3_hash == "72a589da586844d7f0818ce684948eea"

# JA3 из Zeek (ssl.log) — поле ja3 присутствует по умолчанию

JA4+ (следующее поколение)

Улучшения JA4

JA4 (TLS-клиент) — замена JA3 с модульным читаемым форматом a_b_c: например t13d1516h2_8daaf6152771_e5627efa2ab1 кодирует протокол (t=TCP/q=QUIC), версию TLS, число cipher suites и extensions, ALPN, затем хэши шифронаборов и расширений.
Ключевое отличие от JA3: JA4 сортирует TLS-расширения по типу, а не по порядку появления. Поэтому банальная рандомизация порядка extensions (которой малварь уходит от JA3) на JA4 не действует — фингерпринт остаётся стабильным.
Частичный матчинг: благодаря структуре a_b_c можно искать по фрагментам — ab (клиент+шифры), ac (клиент+extensions) или c только. Пример: паттерн t13d190900_*_97f8aa674fd9 ловит любой GoLang-TLS-стек, включая агенты Sliver, независимо от промежуточной части.
Семейство JA4+: JA4S (сервер), JA4H (HTTP-клиент: метод, заголовки, их порядок, cookies), JA4X (X.509-сертификат), JA4T/JA4TS (TCP), JA4SSH (SSH), JA4L (тайминги/latency).
Лицензирование: алгоритм JA4 (TLS) открыт под BSD-3-Clause; остальные методы JA4+ распространяются под FoxIO License (свободны для внутреннего использования, отдельные условия для коммерческих продуктов).
JA4+ решает проблемы коллизий JA3 и добавляет контекст (читаемые параметры вместо «голого» MD5).

Практическое применение

Поиск по базам: sslbl.abuse.ch — актуальная и поддерживаемая база вредоносных JA3 (C2/ботнеты, есть готовый Suricata-рулсет); ja4db.com — официальная база JA4+ от FoxIO (в активной разработке, ~десятки тысяч записей, ежедневное обновление), её уже используют Cloudflare, AWS WAF, VirusTotal и NetWitness.
Устаревшее: ja3er.com закрыта, а репозиторий Salesforce JA3 архивирован 1 мая 2025 (read-only). Вектор развития — JA4+ от FoxIO; для нового ханта предпочитайте JA4.
Где считать фингерпринты: Wireshark и Suricata 8 считают JA3/JA4 нативно; в Zeek ставится пакет zkg install zeek/foxio/ja4; Arkime индексирует их для поиска в масштабе.
Обнаружение малвари: если JA3/JA4 хоста не совпадает ни с одним известным браузером — это скрипт или малварь.
Hunting: найдите все соединения с одинаковым JA4 → определите, какое ПО их генерирует.
Детекция Cobalt Strike / Sliver: дефолтные фингерпринты известны и задокументированы (у Sliver — характерный GoLang-паттерн JA4).

Подводные камни: JA3 не является серебряной пулей. Malleable C2-профили Cobalt Strike позволяют менять TLS-параметры. Один JA3-хэш может соответствовать нескольким программам. Используйте JA3 как один из индикаторов, а не единственный.

📦

Извлечение файлов и артефактовИзвлечение файлов, credentials и IoC из сетевого трафика

Извлечение файлов

Wireshark — Export Objects

File → Export Objects → HTTP — извлекает все файлы, переданные по HTTP: исполняемые файлы, скрипты, документы, изображения. Аналогично для SMB, TFTP, IMF (email). Для каждого файла показывается хост, Content-Type, имя файла и размер.

NetworkMiner — пассивное извлечение

NetworkMiner автоматически извлекает из PCAP: файлы (по всем протоколам), изображения, credentials (HTTP Basic, FTP, SMTP), сертификаты, DNS-запросы, параметры ОС (OS fingerprinting по TTL и TCP window size). Удобнее Wireshark для массового извлечения.

Извлечение из зашифрованного трафика

Если TLS-трафик не может быть расшифрован — файлы извлечь невозможно. Однако можно извлечь:

Сертификаты сервера (Subject, Issuer, SAN, serial number).
SNI (Server Name Indication) — домен, к которому обращается клиент.
JA3/JA4-фингерпринты.
Размеры передаваемых данных (для оценки объёма эксфильтрации).

Извлечение credentials

Что искать

Wireshark# HTTP Basic Authentication (base64-кодированные credentials)
http.authorization

# FTP логины
ftp.request.command == "USER" || ftp.request.command == "PASS"

# SMTP авторизация
smtp.auth.password

# NTLM-аутентификация (в SMB, HTTP)
ntlmssp.auth.username

# Kerberos-тикеты
kerberos.CNameString

После извлечения файлов: вычислите SHA-256 каждого файла → проверьте в VirusTotal → при необходимости передайте на статический / динамический анализ. Никогда не открывайте извлечённые файлы на рабочей машине.

🔀

Lateral Movement в трафикеОбнаружение горизонтального перемещения атакующего по сети

Контекст

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

Протоколы и паттерны

SMB (порт 445)

Массовые подключения по SMB от одного хоста к множеству других — сканирование/распространение.
Доступ к ADMIN$, C$, IPC$ — признак PsExec или аналогичных инструментов.
Передача исполняемых файлов через SMB-шары.

Wireshark# SMB-трафик
smb2 || smb

# Доступ к административным шарам
smb2.tree contains "ADMIN$" || smb2.tree contains "C$" || smb2.tree contains "IPC$"

# SMB-подключения к множеству хостов от одного IP
smb2 && ip.src == SUSPECT_IP

Другие протоколы lateral movement

WMI (порт 135 + динамические)Удалённое выполнение команд через WMI. Фильтр: dcerpc. Признак: DCOM-вызовы к IWbemServices.

WinRM / PSRemoting (порт 5985/5986)PowerShell Remoting. Фильтр: tcp.port == 5985 || tcp.port == 5986. HTTP SOAP-запросы к /wsman.

RDP (порт 3389)Интерактивный удалённый рабочий стол. Фильтр: tcp.port == 3389. Массовые RDP-подключения от одного IP — подозрительно.

SSH (порт 22)В Linux-средах. Фильтр: tcp.port == 22. Подбор паролей: множество коротких сессий к одному хосту.

Kerberos-аномалии

Kerberoasting: массовые запросы TGS-REQ (msg-type 12) к сервисным аккаунтам от одного пользователя, часто со слабым шифрованием RC4 (etype 23). Фильтр: kerberos.msg.type == 12. (msg-type 13 — это ответ TGS-REP, а не запрос.)
Golden/Silver Ticket: аномальные TGT/TGS с нестандартными параметрами: необычно долгий срок действия, несовпадение доменов.
AS-REP Roasting: AS-REP без предварительной аутентификации — kerberos.msg.type == 11 к аккаунтам с отключённой preauth.
Pass-the-Ticket: использование TGT с одной машины на другой — в трафике это выглядит как TGS-запрос от IP, отличного от IP, получившего TGT.

Baseline: Для обнаружения lateral movement критично иметь baseline «нормального» внутреннего трафика. Если рабочая станция бухгалтера внезапно подключается по SMB к контроллеру домена — это аномалия, которую невозможно обнаружить без понимания нормы.

📤

Обнаружение эксфильтрации данныхКак атакующий выводит данные и как это обнаружить

Каналы эксфильтрации

HTTPS / HTTP Наиболее частый канал: данные загружаются на облачные хранилища (Mega, Dropbox, Google Drive), pastebin-сервисы или C2-сервер через POST-запросы. Маскируется под обычный веб-трафик.

DNS Tunneling Данные кодируются в DNS-запросах (поддомены) и ответах (TXT-записи). Медленно, но часто обходит файрволы, так как DNS обычно не блокируется.

ICMP Tunneling Данные встраиваются в payload ICMP Echo Request/Reply. Фильтр: icmp && data.len > 64 — ICMP-пакеты с аномально большим телом данных.

Шифрованные каналы TLS к нестандартным портам, Tor (.onion), SSH-туннели, VPN. Обнаружение: по JA3-фингерпринтам, объёму исходящего трафика, обращениям к Tor-узлам.

Индикаторы эксфильтрации

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

Аномальный объём исходящего трафика: рабочая станция, обычно генерирующая 100 MB/день, внезапно отправляет 10 GB — явный индикатор.
Трафик в нерабочее время: массовая передача данных в 3:00 ночи.
Обращения к облачным хранилищам: mega.nz, gofile.io, file.io, pixeldrain.com, catbox.moe — часто используются для эксфильтрации. (anonfiles закрылся в августе 2023 — устаревший IoC, убирайте из старых блок-листов.)
ZIP/RAR-архивы в исходящем трафике: атакующие архивируют данные перед выгрузкой.
DNS-запросы с base64 в поддоменах: dGhpcyBpcyBhIHRlc3Q=.c2.evil.com.
Обратная асимметрия трафика: обычно входящий трафик > исходящего (загрузка контента). Если наоборот — возможна эксфильтрация.

Wireshark-фильтры для обнаружения

Wireshark / tshark# Большие DNS TXT-ответы (tunneling)
dns.resp.type == 16 && dns.resp.len > 200

# ICMP с аномально большим телом
icmp && data.len > 100

# Исходящий трафик к облачным хранилищам (по SNI)
tls.handshake.extensions.server_name contains "mega.nz"
tls.handshake.extensions.server_name contains "gofile.io"
tls.handshake.extensions.server_name contains "pixeldrain.com"
# Примечание: публичный transfer.sh больше не работает (остался только
# self-hosted); держите список актуальным — сервисы приходят и уходят.

# Большие POST-запросы (эксфильтрация через HTTP)
http.request.method == "POST" && http.content_length > 1000000

# Исходящий трафик на Tor (guard/entry nodes)
# Предварительно загрузите список Tor-узлов и фильтруйте по IP

Инструменты: Zeek (conn.log: orig_bytes / resp_bytes для анализа асимметрии), RITA (автоматическое обнаружение beaconing + long connections), NetFlow-анализаторы (nfdump, SiLK) для масштабного анализа объёмов трафика.

🛡️

IDS/IPS — Suricata и SnortНаписание и применение правил для обнаружения угроз в трафике

IDS vs IPS

IDS (Intrusion Detection System) — обнаруживает и алертит о подозрительном трафике. IPS (Intrusion Prevention System) — обнаруживает и блокирует. Suricata и Snort работают в обоих режимах. Suricata — более современный, многопоточный, поддерживает JA3/JA4 и TLS-анализ нативно. Текущая стабильная ветка — Suricata 8.0 (вышла в ноябре 2025); 7.0.x сопровождается как LTS (до 2028). Обе разбирают QUIC и извлекают SNI, 8.0 углубляет разбор HTTP/3 поверх QUIC.

Структура правила Suricata

Синтаксис

Suricata Rulealert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"MALWARE Cobalt Strike Beacon HTTP POST";
    flow:established,to_server;
    http.method; content:"POST";
    http.uri; content:"/submit.php";
    http.header; content:"Cookie:";
    pcre:"/Cookie:\s[a-zA-Z0-9+\/]{40,}={0,2}/";
    classtype:trojan-activity;
    sid:2026001; rev:1;
)

Разбор: alert — действие, http — протокол, $HOME_NET any -> $EXTERNAL_NET any — направление, msg — название правила, content — искомые строки, pcre — регулярное выражение, sid — уникальный идентификатор.

Примеры правил

Suricata Rules# Обнаружение PowerShell download cradle
alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"SUSPICIOUS PowerShell Download Cradle";
    flow:established,to_server;
    http.user_agent; content:"PowerShell";
    classtype:policy-violation;
    sid:2026002; rev:1;
)

# DNS-запрос к длинному домену (DGA / tunneling)
alert dns $HOME_NET any -> any 53 (
    msg:"SUSPICIOUS Long DNS Query - Possible Tunneling";
    dns.query; content:"."; offset:50;
    classtype:bad-unknown;
    sid:2026003; rev:1;
)

# Обнаружение Metasploit Meterpreter HTTP
alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"MALWARE Meterpreter HTTP Beacon";
    flow:established,to_server;
    urilen:5;
    http.uri; pcre:"/^\/[A-Za-z0-9_-]{4}$/";
    classtype:trojan-activity;
    sid:2026004; rev:1;
)

# Подозрительный самоподписанный сертификат
# ВАЖНО: настоящую самоподписанность (Issuer == Subject) одним content-match
# не выявить — почти у ВСЕХ сертификатов CN= есть и в issuer, и в subject.
# Нужны Lua-скрипт Suricata либо поведенческая детекция (JA3/JA4, аномалии).
# Поэтому здесь матчим конкретные известные строки сертификата (пример Emotet C2):
alert tls $HOME_NET any -> $EXTERNAL_NET any (
    msg:"MALWARE Suspicious Self-Signed Cert (Emotet-like)";
    flow:established,to_server;
    tls.cert_subject; content:"CN=example.com"; nocase;
    tls.cert_subject; content:"O=Global Security";
    classtype:trojan-activity;
    sid:2026005; rev:1;
)

Готовые наборы правил

ET Open (Emerging Threats) — бесплатный набор, обновляется ежедневно. Покрывает малварь, C2, эксплойты, сканирование.
ET Pro — платная версия с расширенным покрытием и более быстрыми обновлениями.
Suricata-рулсеты от Abuse.ch — фокус на IoC: SSLBL (вредоносные сертификаты), URLhaus (вредоносные URL), Feodo Tracker (C2 ботнетов).
OISF Traffic ID — правила для идентификации приложений и протоколов.

Офлайн-анализ PCAP с Suricata

Применение правил к захваченному трафику

Suricata CLI# Прогнать PCAP через Suricata с правилами
suricata -r traffic.pcap -l /tmp/suricata-output/ -S custom.rules

# Результат:
# /tmp/suricata-output/fast.log    — сработавшие правила (текст)
# /tmp/suricata-output/eve.json    — полный лог в JSON (для SIEM)

# Просмотр сработавших правил
cat /tmp/suricata-output/fast.log

# Фильтрация JSON по severity
jq 'select(.alert.severity == 1)' /tmp/suricata-output/eve.json

Практика: Скачайте тренировочные PCAP-файлы с malware-traffic-analysis.net (Brad Duncan) — коллекция реальных PCAP с малварь-трафиком. Прогоните их через Suricata с ET Open правилами, затем откройте в Wireshark и верифицируйте каждый алерт. Это лучший способ научиться читать трафик.

🔒

Encrypted DNS — DoH / DoT / DoQЗашифрованный DNS «ослепляет» классический мониторинг — как с этим жить

Почему это важно

Анализ DNS из секции 03 работает, пока запросы идут открыто по UDP/53. Зашифрованный DNS прячет содержимое запросов от средств мониторинга, и малварь всё чаще резолвит C2-домены через DoH, чтобы обойти DNS-детекты и блок-листы. Для SOC это слепая зона: факт соединения виден, а запрашиваемые домены — нет.

Варианты зашифрованного DNS

DoT — DNS over TLSDNS внутри TLS на отдельном порту 853/TCP. Легко детектируется по порту: содержимое скрыто, но сам факт DoT очевиден.

DoH — DNS over HTTPSDNS внутри обычного HTTPS на 443/TCP. Сливается с веб-трафиком — самый трудный для обнаружения. Запросы несут Content-Type application/dns-message (не виден под TLS).

DoQ — DNS over QUICDNS поверх QUIC, порт 853/UDP (RFC 9250). Новый транспорт, многие средства его ещё не разбирают (см. секцию 12).

DNSCryptБолее старый протокол шифрования DNS, обычно порты 443/5443. Реже, но всё ещё встречается у отдельных клиентов.

Как обнаруживать

Подходы и фильтры

DoT и DoQ ловятся по портам. DoH требует сопоставления с известными провайдерами (по SNI/IP) — держите актуальный список DoH-эндпоинтов.

Wireshark / Suricata# DoT — DNS over TLS (отдельный порт)
tcp.port == 853

# DoQ — DNS over QUIC
udp.port == 853

# DoH по SNI известных публичных резолверов
tls.handshake.extensions.server_name contains "dns.google"
tls.handshake.extensions.server_name contains "cloudflare-dns.com"
tls.handshake.extensions.server_name contains "mozilla.cloudflare-dns.com"
tls.handshake.extensions.server_name contains "dns.quad9.net"
tls.handshake.extensions.server_name matches "doh|dns-query"

Корпоративная политика: в управляемой сети DoH с рабочих станций — почти всегда аномалия. Браузеры (Firefox, Chrome) умеют включать DoH автоматически, обходя корпоративный резолвер. Best practice: блокировать исходящий DNS (53, 853) ко всему, кроме внутренних резолверов; использовать canary-домен use-application-dns.net (Firefox отключает DoH, если он не резолвится); алертить на обращения к известным DoH-провайдерам с не-браузерных хостов.

Списки DoH-серверов: поддерживайте блок-/вотч-лист из публичных источников (dnscrypt-proxy public-resolvers, dibdot DoH-IP-blocklists, фиды oisd). Сопоставляйте SNI и destination-IP TLS-соединений с этим списком.

🌐

QUIC и HTTP/3Анализ трафика поверх QUIC и связанные слепые зоны

Что такое QUIC

QUIC (RFC 9000) — транспортный протокол поверх UDP (обычно порт 443), на котором работает HTTP/3 (RFC 9114). Шифрование TLS 1.3 встроено в сам протокол: зашифрованы не только данные, но и большая часть заголовков транспортного уровня. К 2026 году значительная доля трафика к Google, Cloudflare, Meta и CDN идёт по QUIC.

Слепая зона: многие легаси-IDS, прокси и DLP не разбирают QUIC и просто пропускают UDP/443. Атакующие могут использовать HTTP/3 именно для обхода инспекции. Если ваши средства не понимают QUIC — рассмотрите блокировку UDP/443 на периметре, чтобы принудить клиентов к TCP+TLS, который вы умеете анализировать (fallback в браузерах работает автоматически).

Что всё-таки видно

Наблюдаемые артефакты

SNI в Initial-пакете: первый QUIC-пакет (Initial) содержит TLS Client Hello с SNI — он наблюдаем (если не используется ECH). Главный источник для атрибуции назначения.
Метаданные потока: IP, порт, объём, тайминги доступны как для любого UDP-трафика. Beaconing- и объёмный анализ (секции 05 и 09) применимы.
Connection ID и версия QUIC: видны в long-header пакетах, помогают связать пакеты в один поток несмотря на смену IP (connection migration).
JA4 для QUIC: JA4-фингерпринтинг поддерживает QUIC Client Hello — позволяет отличать браузеры от библиотек/малвари даже в QUIC.

Wireshark# Весь QUIC-трафик
quic

# Только Initial-пакеты (содержат Client Hello / SNI)
quic.long.packet_type == 0

# SNI внутри QUIC
quic && tls.handshake.extensions.server_name

# QUIC к нестандартному порту (не 443) — подозрительно
quic && !(udp.port == 443)

# Подсчёт SNI в QUIC-трафике (tshark)
tshark -r traffic.pcap -Y "quic && tls.handshake.extensions.server_name" -T fields -e tls.handshake.extensions.server_name | sort | uniq -c | sort -rn

Практика: убедитесь, что ваш сенсор (Zeek с QUIC-парсером / Suricata 7+, актуально 8.0 / Arkime) разбирает QUIC и логирует SNI. Suricata парсит QUIC и извлекает SNI начиная с версии 7 (в 8.0 — глубже, вместе с HTTP/3); Zeek имеет поддержку QUIC. Без этого UDP/443 будет «чёрной дырой» в логах.

🕶️

Encrypted Client Hello (ECH)Как шифрование ClientHello «ослепляет» инспекцию SNI — и что с этим делать

Почти весь этот гайд опирается на один открытый артефакт TLS — SNI в ClientHello: по нему строятся фильтры (секции 04, 09), детект DoH (секция 11) и атрибуция QUIC (секция 12). Encrypted Client Hello (ECH, RFC 9849) закрывает эту последнюю щель: SNI и другие поля ClientHello шифруются, и пассивный наблюдатель больше не видит целевой домен. Для SOC это стратегический сдвиг слепой зоны.

Как работает ECH

Механика в двух словах

Клиент шифрует «внутренний» ClientHello (вместе с реальным SNI и списком ALPN) публичным ключом сервера и кладёт его в extension encrypted_client_hello «внешнего» ClientHello.
Публичный ключ (ECHConfig) публикуется в DNS — в записях HTTPS/SVCB (RFC 9460), которые клиент обычно забирает по DoH.
Во «внешнем» ClientHello виден только public name — общий домен-прикрытие фронтящего провайдера (например cloudflare-ech.com), а не реальный хост. Расшифровать внутренний SNI может лишь сервер с приватным ключом.
Со-размещённые за одним провайдером сайты образуют один «anonymity set» — по внешним признакам их не различить.

Что это ломает для SOC

Пассивная инспекция «слепнет». Если детекты завязаны на чтение SNI из зеркала/TAP, ECH их обходит: во «внешнем» SNI будет домен-прикрытие, а не назначение. Ключевое различие — пассивный сенсор (tap/mirror) ослеплён полностью, тогда как явный L7-прокси, который сам терминирует TLS, на плече «прокси → origin» не затронут (там он и есть та сторона, что расшифровывает). Проверьте у вендора инспекции наличие ECH-aware обновлений.

Что всё-таки остаётся видимым

Назначение по IP: destination IP и ASN видны как для любого трафика; связка с Passive DNS помогает восстановить домен.
JA3/JA4 клиента: фингерпринт TLS-клиента (секция 06) считается по параметрам ClientHello и под ECH продолжает работать — вы по-прежнему отличаете браузер от малвари/скрипта, даже не зная домена.
Метаданные потока: объём, тайминги, длительность — доступны; beaconing- и объёмный анализ (секции 05 и 09) применимы.
Сам факт ECH: расширение encrypted_client_hello в ClientHello наблюдаемо — по нему видно, что клиент вообще использует ECH.
DNS-подсказки: запрос HTTPS/SVCB-записи предшествует ECH-соединению — если DNS не зашифрован, он выдаёт домен; если по DoH — прячется вместе с ним (снова связка ECH + DoH из секции 11).

Как обнаруживать и жить с ECH

Подходы и фильтры

ECH деградирует «мягко»: если сервер/сеть не поддерживают ECH, соединение просто откатывается к обычному рукопожатию с видимым SNI. Это по замыслу — и это же даёт рычаг: политикой можно вынуждать fallback (не отдавать/блокировать ECHConfig в DNS), сохраняя видимость там, где это разрешено регламентом.

Wireshark# ClientHello с расширением ECH (тип 0xfe0d = 65037)
# В свежих версиях Wireshark поле называется encrypted_client_hello
tls.handshake.type == 1 && tls.handshake.extension.type == 65037

# «Внешний» SNI-прикрытие (пример Cloudflare)
tls.handshake.extensions.server_name == "cloudflare-ech.com"

# Клиенты, использующие ECH, но с не-браузерным JA4 — приоритет на разбор
tls.handshake.extension.type == 65037 && tls.handshake.ja4

Статус развёртывания: Cloudflare включил ECH по умолчанию для своих зон ещё в конце 2023; Chrome и Firefox добавили поддержку в октябре 2023 (в Chrome — по умолчанию с версии 122, февраль 2024), Safari 17+ — при активном DoH/DoT. Самостоятельный хостинг ECH к 2026 всё ещё ограничен (нужны свежие OpenSSL 3.5+/BoringSSL, nginx 1.27+). Практический вывод: доля ECH-трафика будет расти — переносите детекты с «SNI любой ценой» на связку IP + JA3/JA4 + метаданные потока и терминацию TLS на управляемом L7-прокси.

🎯

Маппинг детектов на MITRE ATT&CKОбщий язык для покрытия: какие техники ловятся в трафике и где искать в гайде

Привязка сетевых детектов к MITRE ATT&CK даёт две вещи: единый язык с остальной командой (детект-инженеры, TI, IR) и честную картину покрытия — где есть детекты, а где «дыры». Ниже — карта техник, которые видны именно в сетевом трафике, со ссылкой на соответствующую секцию руководства.

Техника ATT&CK	Сетевой индикатор	Секция
Command & Control
`T1071.001` App Layer Protocol: Web	C2 поверх HTTP/HTTPS; подозрительные User-Agent, POST на bare-IP	04, 05
`T1071.004` App Layer Protocol: DNS	C2 через DNS-запросы/ответы, аномальная частота к одному домену	03, 05
`T1568.002` Dynamic Resolution: DGA	Псевдослучайные домены, всплеск NXDOMAIN, высокая энтропия	03
`T1572` Protocol Tunneling	Туннель C2/данных внутри DNS или ICMP	03, 09
`T1573` Encrypted Channel	Зашифрованный C2; атрибуция клиента через JA3/JA4 (даже под ECH)	06, 13
`T1090.003` Proxy: Multi-hop	Выход в Tor / многоузловые прокси	09
`T1105` Ingress Tool Transfer	Загрузка пейлоада по HTTP/SMB (PE по magic bytes)	04, 07
Exfiltration
`T1041` Exfil Over C2 Channel	Вывод данных по тому же C2-каналу; рост размера ответов	05, 09
`T1048` Exfil Over Alternative Protocol	Вывод через сторонний протокол/облачный сервис, асимметрия трафика	09
Lateral Movement
`T1021.002` Remote Services: SMB/Admin Shares	Доступ к ADMIN$/C$/IPC$, паттерн PsExec	08
`T1021.001` Remote Services: RDP	Массовые RDP-подключения от одного хоста	08
`T1021.006` Remote Services: WinRM	SOAP к `/wsman` на 5985/5986	08
`T1021.004` Remote Services: SSH	Брутфорс/множество коротких SSH-сессий	08
`T1570` Lateral Tool Transfer	Передача исполняемых файлов между хостами через SMB	08
`T1550.003` Pass the Ticket	TGS-запрос с IP, отличного от получившего TGT	08
Credential Access
`T1558.003` Kerberoasting	Массовые TGS-REQ (msg-type 12) к сервисным аккаунтам, RC4 (etype 23)	08
`T1558.004` AS-REP Roasting	AS-REP (msg-type 11) к аккаунтам с отключённой preauth	08

Как применять: используйте карту для gap-анализа — отметьте, по каким техникам у вас есть работающие правила Suricata/Zeek, а по каким только «ручной» ханат, и закройте пробелы. Идентификаторы техник иногда меняются между версиями ATT&CK (появляются/переезжают сабтехники), поэтому сверяйтесь с актуальной матрицей на attack.mitre.org.

🧭

Методология триажа PCAPПошаговый порядок действий при разборе захваченного трафика

Получив PCAP, легко утонуть в пакетах. Этот чек-лист задаёт порядок «от общего к частному» и связывает воедино все предыдущие секции. Идите сверху вниз — каждый шаг сужает область поиска.

Шаг 0 — Подготовка и сохранность

Работайте с копией; зафиксируйте SHA-256 исходного PCAP для целостности доказательств.
Отметьте границы захвата: длительность, число пакетов, временной диапазон.
Зафиксируйте контекст: какой хост/сегмент, какое время инцидента, что уже известно.

CLIsha256sum traffic.pcap
capinfos traffic.pcap        # сводка: длительность, пакеты, временной диапазон

Шаг 1 — Картина целиком

Statistics → Protocol Hierarchy — необычная доля DNS / ICMP / QUIC = повод копать (tunneling, слепые зоны).
Statistics → Conversations, сортировка по Bytes — крупнейшие потоки = кандидаты на эксфильтрацию (секция 09).
Statistics → Endpoints — самые «шумные» хосты и внешние IP.
Statistics → I/O Graph — периодические всплески = возможный beaconing (секция 05).

Шаг 2 — По протоколам

DNS: всплески NXDOMAIN, длинные/высокоэнтропийные домены, редкие домены, TXT-аномалии (секция 03). Не забудьте про зашифрованный DNS (секция 11).
HTTP: подозрительные User-Agent, POST на bare-IP, загрузки исполняемых файлов (секция 04).
TLS: SNI, самоподписанные/странные сертификаты, JA3/JA4 против известных C2 (секция 06).
Внутренний трафик: SMB к админ-шарам, RDP/WinRM/Kerberos-аномалии = lateral movement (секция 08).

Шаг 3 — Углубление и подтверждение

Follow Stream по подозрительным потокам — прочитайте диалог целиком.
Извлеките файлы (Export Objects / NetworkMiner), посчитайте SHA-256, проверьте в TI (секция 07). Никогда не запускайте образцы на рабочей машине.
Прогоните через сигнатуры: Suricata + ET Open и Zeek для автоматических алертов и структурированных логов (секция 10).
Тайминг-анализ подозрительных соединений на регулярность (beaconing).

Шаг 4 — Корреляция и вывод

Сопоставьте сетевые находки с endpoint-логами и SIEM: сеть отвечает на «что и куда», endpoint — на «кто и как».
Соберите IoC: IP, домены, хэши, JA3/JA4, URI — для блокировок и threat hunting.
Постройте таймлайн и зафиксируйте выводы; сохраните доказательства с хэшами.

Главный принцип: всё держится на baseline. Без понимания «нормы» для конкретной сети аномалию не отличить от легитимного всплеска. Стройте baseline заранее — в разгар инцидента это делать поздно.