Wireshark CTF анализ трафика: как читать pcap-файлы и находить флаги

Wireshark CTF анализ трафика: как читать pcap-файлы и находить флаги

На последних пяти CTF-соревнованиях, где я играл в forensics-категории, pcap-задания составляли больше половины тасков. Формула каждого одинаковая: скачиваешь файл, открываешь в Wireshark, видишь тысячи пакетов — и ни одной подсказки, где спрятан флаг. Новичок тратит полчаса на бессистемное листание. Опытный игрок находит ответ за пять минут — не потому что знает Wireshark лучше, а потому что работает по алгоритму: что открыть первым, какой фильтр набрать, куда смотреть в hex dump. Дальше — тот самый алгоритм, собранный из десятков решённых тасков.

Первые 60 секунд с pcap: что смотреть до фильтров

Самая частая ошибка на forensics CTF заданиях — сразу фильтровать пакеты по протоколу или IP. Без общей картины вы не знаете, что фильтровать. Первые действия после открытия pcap задают направление всего разбора.

Требования к окружению: - Wireshark 4.x или 3.x (активно поддерживается, open-source, стабильная ветка обновляется регулярно) - tshark — входит в дистрибутив Wireshark, отдельная установка не нужна - ОС: Windows 10+, Linux (в Kali стоит по умолчанию), macOS - RAM: 4 ГБ минимум для pcap до 50 МБ, 8 ГБ рекомендуется для крупных дампов - Опционально: NetworkMiner (альтернатива для автоматического извлечения файлов и учётных данных, бесплатная версия на netresec.com)

Protocol Hierarchy — карта территории

Первое окно, которое открываем: Statistics → Protocol Hierarchy. Оно показывает процентное распределение протоколов в дампе по объёму данных и количеству пакетов. В CTF организаторы обычно прячут флаг в нешифрованном трафике — HTTP, FTP, DNS, SMTP, Telnet. Если 95% трафика составляет TLS, а 0.3% — HTTP, именно эти 0.3% и есть ваша цель.

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

• HTTP без TLS — открытый веб-трафик, первый кандидат для анализа pcap файлов
• FTP и FTP-DATA — передача файлов открытым текстом, часто содержит credentials или сам флаг
• DNS выше 15-20% — аномально высокий процент DNS может указывать на DNS exfiltration (MITRE ATT&CK T1071.004, command-and-control)
• ICMP непропорционально много — вероятен ICMP-туннель с полезной нагрузкой в payload
• «Data» или неизвестный протокол — Wireshark не распознал формат, а организаторы CTF любят маскировать данные именно так

В реальных расследованиях это соответствует задаче NIST CSF DE.AE-01 — построение базовой картины трафика и выявление отклонений. В CTF базовую картину вы строите именно здесь, и она задаёт весь дальнейший Wireshark pcap разбор.

Conversations — действующие лица

Второе окно: Statistics → Conversations → вкладка TCP (или IPv4). Сортируем по количеству переданных байтов. Нужно ответить на два вопроса: какие пары хостов обменялись наибольшим объёмом данных и есть ли соединения на нестандартных портах (не 80, 443, 53).

Если в pcap один внутренний IP (10.0.x.x или 192.168.x.x) обращается к нескольким внешним — это машина «жертвы». Трафик от неё к подозрительным адресам на нестандартных портах — первый кандидат для глубокого анализа сетевых пакетов. Практический приём: выделяете интересующую conversation и жмёте «Follow Stream» прямо из этого окна — не надо руками искать нужные пакеты.

Фильтры Wireshark для CTF: шпаргалка с примерами

Фильтры Wireshark — основной рабочий инструмент для pcap forensics. В CTF важна скорость: нужно сузить тысячи пакетов до десятков релевантных за минимальное время.

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

Набор, который покрывает 80% задач:

• http — весь HTTP-трафик (GET, POST, ответы)
• dns — все DNS-запросы и ответы
• ftp || ftp-data — FTP-сессии с передаваемыми файлами
• tcp.port == 4444 — трафик на конкретный порт (4444 — частый порт reverse shell)
• ip.addr == 192.168.1.100 — весь трафик конкретного хоста
• http.request.method == "POST" — только POST-запросы (формы логина, отправка данных)
• dns.qry.name contains "flag" — DNS-запросы, содержащие слово «flag»

Комбинации через логические операторы: http && ip.src == 10.0.2.15 покажет HTTP-запросы от конкретного хоста. Оператор ! для исключения фонового шума: !arp && !dns && !mdns уберёт служебный трафик и оставит то, что стоит изучать.

Поиск строк: contains и matches

Когда формат флага известен (а на CTF он обычно объявлен — CTF{, flag{, FLAG_), поиск по содержимому пакета решает задачу за секунды:

• frame contains "flag{" — ищет строку в любом месте пакета, включая payload
• http contains "password" — поиск паролей в HTTP
• tcp contains "CTF" — поиск формата флага в TCP-сегментах

Для регулярных выражений — оператор matches: фильтр http.request.uri matches ".*\.(php|asp)" найдёт обращения к серверным скриптам. А frame matches "(?i)secret" выполнит регистронезависимый поиск слова «secret» по всему дампу.

Ограничение: contains и matches работают только по нешифрованному payload. Против TLS фильтр по содержимому бесполезен без предварительной расшифровки — об этом отдельный раздел ниже.

Follow TCP Stream: главный приём при анализе pcap файлов

Follow TCP Stream (правый клик на пакете → Follow → TCP Stream) — техника, которая в одиночку решает больше CTF-задач, чем все остальные приёмы вместе взятые. Она реконструирует полный диалог между двумя хостами в хронологическом порядке: запросы клиента одним цветом, ответы сервера — другим. Вместо десятков разрозненных пакетов вы видите цельную сессию.

Credential hunting в открытых протоколах

Флаг в CTF часто спрятан в учётных данных, переданных по незашифрованным протоколам. Это моделирует реальную технику Network Sniffing (T1040, credential-access) по MITRE ATT&CK.

FTP — фильтр ftp покажет команды USER и PASS открытым текстом. В Follow Stream видна полная сессия: логин, пароль, содержимое каталогов (LIST), скачивание файлов (RETR). Если присутствует ftp-data, флагом может быть содержимое переданного файла — его можно вытянуть через Follow Stream → Show data as: Raw → Save as.

HTTP Basic Auth — заголовок Authorization: Basic <base64> декодируется Wireshark автоматически, значение видно прямо в дереве пакетов. POST-данные форм логина (username=admin&password=s3cretfl4g) тоже отображаются в чистом виде.

SMTP — почтовые сессии на порту 25 передают всё открытым текстом: отправитель, получатель, тело письма, вложения в base64. Follow Stream на SMTP-соединении часто раскрывает флаг прямо в теле сообщения.

Telnet — каждый символ летит отдельным пакетом, но Follow Stream собирает их в читаемую последовательность команд. Ищите введённые пользователем данные.

Decode As: когда Wireshark не распознаёт протокол

Трафик на нестандартном порту иногда отображается как «TCP» или «Data» без разбора структуры. Wireshark привязывает диссекторы к стандартным портам, и если HTTP работает на порту 1337 — автоматическое распознавание не срабатывает.

Решение: правый клик → Decode As → выбрать нужный протокол для этого порта. После этого Wireshark переанализирует все пакеты с правильным диссектором. Я на одном CTF потерял минут двадцать, пялясь в сырые hex-данные на порту 8888, пока не догадался сделать Decode As → HTTP. Там лежал флаг прямо в GET-параметре.

Приём работает и для аудиопотоков: если в pcap спрятано голосовое сообщение, трафик может идти по UDP на нестандартном порту. После Decode As → RTP появляется возможность перейти в Telephony → RTP → RTP Streams → Analyze → Play для воспроизведения записи. Согласно walkthrough THM Wireshark CTF, именно так решаются задачи с аудиофлагами, где RTP-поток замаскирован под обычный UDP.

Ограничение Decode As: если протокол действительно кастомный (не стандартный HTTP/FTP/RTP), диссектор не поможет. Тогда остаётся ручной разбор payload в hex dump.

Извлечение файлов из захвата трафика CTF

Флаг может быть не строкой в пакете, а файлом, переданным по сети: изображением, PDF, архивом, скриптом.

Export Objects и ручная сборка

File → Export Objects → HTTP (или SMB, TFTP, FTP-DATA). Wireshark покажет список всех файлов, переданных через выбранный протокол. Сохраняем подозрительные объекты и проверяем каждый.

Типичные находки при анализе pcap файлов на CTF:

• JPEG/PNG — проверьте через strings <файл> | grep -i flag на наличие текста, спрятанного в метаданных или после маркера конца изображения. binwalk покажет встроенные архивы
• ZIP/RAR — пароль часто лежит где-то в том же pcap, в другом потоке или DNS-запросе
• Текстовые файлы, скрипты — прогоните cat и ищите флаг в открытом виде или в закодированной форме

Если Export Objects недоступен (файл передавался по нестандартному протоколу), используем Follow TCP Stream → Show data as: Raw → Save as. Получаем бинарный поток, из которого вырезаем файл, ориентируясь на magic bytes: FF D8 FF для JPEG, 50 4B 03 04 для ZIP, 89 50 4E 47 для PNG.

NetworkMiner — альтернатива Wireshark для массового извлечения артефактов. Инструмент автоматически реконструирует файлы, изображения и учётные данные из pcap без ручной работы. Ограничение: NetworkMiner не работает с трафиком, захваченным на loopback-интерфейсе, и хуже справляется с нестандартными протоколами. Для типовых CTF-задач с HTTP/FTP — рабочий вариант, когда нужно сэкономить время.

Скрытые каналы: DNS, ICMP и стеганография в network forensics CTF

Задачи повышенной сложности прячут данные в скрытых каналах — протоколах, которые на первый взгляд не несут полезной нагрузки. В реальном мире это техника Steganography (T1001.002, command-and-control) по MITRE ATT&CK, и CTF-организаторы активно её моделируют.

DNS exfiltration: TXT-записи и длинные поддомены

DNS — самый популярный скрытый канал и в CTF, и в боевых атаках. Данные кодируются двумя основными способами.

Через поддомены: запрос вида ZmxhZ3t0ZXN0fQ.evil.com содержит base64-кодированный текст прямо в имени хоста. В Wireshark фильтр dns.qry.name.len > 30 отсечёт нормальные запросы и покажет аномально длинные имена. Каждый запрос несёт фрагмент данных — собрав все поддомены по порядку и декодировав, получаете флаг.

Через TXT-записи: ответы DNS-сервера с типом TXT содержат произвольный текст. Фильтр dns.txt покажет все такие ответы. Флаг может лежать прямо в TXT-поле или быть закодирован в hex/base64.

Для массового извлечения данных из DNS exfiltration GUI неудобен — десятки или сотни запросов быстрее обработать через tshark и скрипт.

ICMP-туннели: данные в payload пинга

Стандартный ICMP echo request содержит padding-данные — обычно повторяющийся паттерн или нули. В CTF payload заменяется полезными данными: по одному символу флага на пакет или целыми фрагментами в base64.

Обнаружение: фильтр icmp → смотрим hex dump трафика в нижней панели Wireshark. Если в поле Data видите ASCII-символы вместо стандартного abcdefgh... или 00 00 00... — это данные. Обращайте внимание на ICMP type 8 (echo request) — именно в запросах обычно прячут payload.

Аналогичный принцип применим к любому протоколу с необязательными полями: нестандартные HTTP-заголовки (X-Secret-Data: ...), TCP options, даже IPv4 options. Организаторы используют любое поле, которое не влияет на доставку пакета, но способно нести данные. В терминах MITRE ATT&CK это Standard Encoding (T1132.001) — кодирование данных через base64, hex или ROT13 для передачи через легитимные протоколы.

Расшифровка TLS в pcap: когда трафик зашифрован, а ключ рядом

В CTF с TLS-трафиком организаторы всегда дают средство для расшифровки — иначе задача нерешаема. Ключ может быть:

Pre-Master Secret log — файл с записями формата CLIENT_RANDOM <hex> <hex>. Часто спрятан в другом потоке того же дампа: в email-вложении, FTP-передаче или даже в DNS TXT-записи. В Wireshark: Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename.

Приватный RSA-ключ сервера — PEM-файл. Работает только если сессия не использует Perfect Forward Secrecy (ECDHE/DHE). Подключается через Protocols → TLS → RSA keys list.

После подключения ключа Wireshark расшифрует сессии автоматически — появятся HTTP-запросы внутри бывшего TLS-потока. Дальше стандартный анализ: Follow HTTP Stream, Export Objects. Согласно разбору из THM Wireshark CTF, в одной из задач ключ CLIENT_RANDOM был отправлен по email в том же pcap — нужно было сначала найти его в SMTP-сессии, сохранить в файл и подключить к TLS-диссектору. Красивая матрёшка.

Ограничение: TLS 1.3 с ECDHE не расшифровывается приватным RSA-ключом — нужен именно session-level pre-master secret. Без ключа доступны только метаданные: SNI (имя сервера в ClientHello), размеры пакетов, тайминги. Иногда SNI содержит подсказку или часть ответа.

tshark: быстрые однострочники для поиска флагов в трафике

tshark — консольная версия Wireshark для автоматизации. Когда pcap содержит десятки тысяч пакетов, GUI начинает тормозить, а tshark в терминале отрабатывает за секунды. Набор однострочников, которые я запускаю первыми на каждом forensics-таске:

# Поиск строки "flag" во всём дампе (с выводом hex)
tshark -r capture.pcap -Y 'frame contains "flag"' -x
# Извлечь уникальные DNS-запросы (имена доменов)
tshark -r capture.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | sort -u
# HTTP-запросы с хостом и URI
tshark -r capture.pcap -Y "http.request" -T fields -e http.host -e http.request.uri
# Payload ICMP echo request в hex
tshark -r capture.pcap -Y "icmp.type==8" -T fields -e data.data

Результат второй команды — список всех запрошенных доменов. Если среди них ZmxhZ3t...evil.com — вы нашли DNS exfiltration. Четвёртая команда выводит hex из ICMP-запросов, который конвертируется в текст через xxd -r -p или однострочник на Python.

tshark позволяет экспортировать произвольные поля в CSV для обработки скриптом: добавьте -E header=y -E separator=, к любой команде с -T fields. Полученную таблицу можно скормить pandas или даже Excel.

Ограничение: визуальные аномалии (всплески на I/O Graph, нетипичная структура пакетов) проще заметить глазами в GUI Wireshark. tshark — инструмент массового извлечения, GUI — инструмент точечного глубокого анализа. На CTF нужны оба.

Алгоритм разбора pcap на CTF: чеклист для поиска флагов

Пошаговый алгоритм, который работает на большинстве forensics CTF заданий:

1. Protocol Hierarchy — Statistics → Protocol Hierarchy. Определить незашифрованные протоколы. Записать проценты HTTP, DNS, FTP, SMTP, ICMP, нестандартных протоколов.

2. Conversations — Statistics → Conversations → TCP. Найти пары с наибольшим объёмом данных и соединения на нестандартных портах.

3. Поиск по формату флага — frame contains "flag{" (подставить формат конкретного CTF). Нашли — задача решена, переходите дальше.

4. HTTP-анализ — фильтр http, просмотр POST-запросов на предмет credentials и данных форм. Export Objects → HTTP для извлечения файлов.

5. FTP / Telnet / SMTP — Follow TCP Stream на каждый поток. Ищите логины, пароли, тела писем, передаваемые файлы.

6. DNS-проверка — фильтр dns, поиск аномально длинных имён (dns.qry.name.len > 30), TXT-записей, нетипичных поддоменов. При подозрении на exfiltration — массовое извлечение через tshark.

7. ICMP-проверка — фильтр icmp, просмотр payload в hex. Нестандартное содержимое — извлечь и декодировать.

8. Decode As — для трафика на нестандартных портах пробовать HTTP, FTP, RTP и другие протоколы. Проверить Telephony → RTP Streams после декодирования UDP как RTP.

9. TLS-расшифровка — если доминирует TLS, искать ключ в незашифрованных потоках (email, FTP, DNS). Подключить через Preferences → Protocols → TLS.

10. Стеганография в файлах — извлечённые изображения проверить через strings, exiftool, binwalk. Архивы — попробовать пароли из других потоков.

Этот чеклист покрывает подавляющее большинство CTF-задач с pcap. Оставшаяся часть — экзотика: кастомные протоколы, многоуровневое кодирование (ROT13 внутри base64 внутри hex — как в разборе THM Wireshark CTF, где для решения нужно было реверсить Python-скрипт с тремя слоями шифрования). Для таких задач база остаётся той же — сначала общая картина, потом точечный анализ — но добавляется скриптовая обработка.

Каждый пункт чеклиста моделирует реальную технику из MITRE ATT&CK: HTTP-передача credentials — Exfiltration Over Unencrypted Non-C2 Protocol (T1048.003). DNS tunneling — DNS (T1071.004). FTP-передача файлов — File Transfer Protocols (T1071.002). Web Protocols (T1071.001) — для HTTP-based C2. Знание этих паттернов ускоряет поиск: вы понимаете, что искать, потому что понимаете, как атакующие действуют.

Среди тех, кто регулярно решает forensics-задачи, я замечаю один разрыв: навыки Wireshark растут, а понимание контекста атаки — нет. Можно идеально фильтровать трафик, вытаскивать файлы из pcap и декодировать base64 за секунды. Но если не понимаешь, зачем атакующий использовал DNS-туннель вместо прямого HTTP-канала, задачи решаются механически, а не через анализ инцидента. CTF-организаторы это видят и усложняют не кодирование, а сценарии: всё чаще pcap моделирует полную цепочку компрометации — от фишингового письма в SMTP-сессии до lateral movement через SMB и exfiltration данных через DNS. Кто видит цепочку целиком, решает быстрее того, кто ищет строку flag grep'ом по hex dump. Именно этот навык — мыслить атакующими цепочками, а не отдельными фильтрами — отделяет CTF-игрока, набирающего очки, от специалиста, способного разобрать реальный инцидент. И тут forensics-навыки конвертируются напрямую: тот же tshark, те же Protocol Hierarchy и Follow Stream, только вместо искусственного флага — реальный IoC в продакшн-трафике. Если хочешь не просто writeup, а пройти полную атаку от разведки до exfiltration самому — на WAPT есть лабы именно с этим вектором и ментор в чате при затыке.