Wireshark для CTF: фильтруем трафик, собираем файлы из потоков и достаём флаг за 10 шагов

Wireshark для CTF: фильтруем трафик, собираем файлы из потоков и достаём флаг за 10 шагов

На последнем командном CTF наша тройка потеряла 40 минут на forensics-задание с pcap-файлом в 180 МБ. Открыли Wireshark, уткнулись в 147 тысяч пакетов и начали скроллить вручную. Как обезьяны. Соседняя команда сдала флаг через 9 минут — у них был чёткий алгоритм: статистика → фильтр → поток → файл → флаг. Разница не в знании инструмента, а в последовательности действий. Ниже — те самые 10 шагов, которые превращают хаотичное листание пакетов в системный анализ pcap файлов с предсказуемым результатом. Каждый шаг привязан к конкретной задаче из реального CTF forensics задания, с командами, которые можно скопировать и запустить прямо сейчас.

Требования к окружению

Перед тем как открывать pcap, убедитесь, что рабочее место готово:

• ОС: Linux (Kali / Parrot / Ubuntu 22.04+), Windows 10+, macOS — Wireshark кросс-платформенный
• RAM: минимум 4 ГБ для pcap до 100 МБ; от 8 ГБ для файлов свыше 200 МБ (сниффер трафика загружает весь дамп в оперативную память)
• Wireshark: версия 4.0+ (последний стабильный релиз — ветка 4.4.x, коммиты в master идут ежедневно)
• tshark: входит в дистрибутив Wireshark, отдельная установка не нужна
• NetworkMiner: опционально, версия Free 2.8+ (автоматическая реконструкция файлов и учётных данных)
• Дополнительно: file, strings, xxd, base64, exiftool — стандартные утилиты Linux для пост-обработки извлечённых артефактов
• Сеть: не требуется — вся работа ведётся локально с готовым pcap-файлом

Шаг 1 — Первичная разведка: Protocol Hierarchy и Conversations

Открыли pcap — не трогайте список пакетов. Первые 60 секунд уходят на статистику, и именно они определяют, куда копать дальше.

Statistics → Protocol Hierarchy показывает распределение протоколов по объёму и количеству пакетов. Ищите аномалии: если 95% трафика — TLS, а 0.3% — HTTP, именно этот HTTP станет вектором поиска. Незашифрованный протокол посреди массы зашифрованного — первое, на что смотрит сетевой криминалист. В разборе на Codeby отмечалось, как в учебном pcap HTTP составлял менее процента трафика, но именно там прятались критичные артефакты.

Statistics → Conversations (вкладка TCP) показывает все пары IP-адресов с объёмом переданных данных. Сортируйте по колонке Bytes — аномально большие или аномально малые сессии заслуживают внимания. Одиночное соединение с внешним IP на нестандартный порт при десятках соединений на 443 — красный флаг. В типичном CTF-дампе с loopback-интерфейса (как описано в анализе на Codeby) центральной фигурой оказывался хост 10.0.2.15, инициировавший соединения с внешними адресами.

Statistics → Endpoints даёт список уникальных адресов. В CTF-формате pcap обычно содержит 2–5 хостов: жертва, атакующий, DNS-резолвер, иногда C2-сервер. Если эндпоинтов больше 20 — задание включает шумовой трафик для маскировки, и фильтрация из шага 2 становится критичной.

Шаг 2 — Wireshark фильтры для CTF: от протокола до конкретного байта

Wireshark display filters — основной инструмент навигации по дампу. Без фильтров анализ pcap на 50+ тысяч пакетов превращается в лотерею. Три уровня точности, от грубого к хирургическому.

Протокольные фильтры — самый быстрый первый шаг: http, dns, ftp, smtp, telnet, icmp. Начинайте с протокола, который выглядел аномально на шаге 1.

Фильтры по полям сужают результат до конкретных событий. Наиболее полезные для network forensics CTF:

• http.request.method == "POST" — формы логина, загрузка файлов, отправка данных
• dns.qry.type == 16 — только TXT-записи DNS (классический канал эксфильтрации)
• tcp.port == 4444 — трафик на порту reverse shell
• ip.addr == 10.0.2.15 — весь трафик от/к конкретному хосту
• frame.len > 1000 — только крупные пакеты (могут содержать передаваемые файлы)

Фильтры содержимого ищут строки прямо внутри пакетов: tcp contains "CTF{" — прямой поиск формата флага, http contains "flag" — по HTTP-телу и заголовкам, frame contains "password" — по всему фрейму любого протокола.

Комбинации через && и ||: фильтр http.request.method == "POST" && ip.src == 10.0.2.15 покажет POST-запросы только от конкретного хоста. Оператор matches поддерживает регулярные выражения: http.request.uri matches ".*\.(php|asp|jsp)" найдёт обращения к серверным скриптам.

Типичная ошибка новичков — путать display filters с capture filters. Capture filters (BPF-синтаксис, вроде host 10.0.2.15) применяются при захвате пакетов. При работе с готовым pcap — только display filters в строке фильтрации с зелёной/красной подсветкой валидности.

Шаг 3 — Анализ HTTP: POST-данные, User-Agent и скрытые параметры

HTTP-трафик в CTF — низко висящий фрукт. Если Protocol Hierarchy показал хоть долю процента незашифрованного HTTP, начинайте с него.

Фильтр http.request выведет список всех запросов с методом, URI и хостом. Что искать:

POST-данные. Клик по пакету с POST → развернуть «HTML Form URL Encoded» в панели деталей → пары name=value в открытом виде. Если сайт работал по HTTP без TLS — логин и пароль лежат как на ладони. По MITRE ATT&CK это классический Network Sniffing (T1040, Credential Access / Discovery) — перехват учётных данных в незашифрованном канале.

User-Agent. Нестандартные строки User-Agent мгновенно выдают инструмент атакующего. В разборе KnightCTF 2024 (selectel.ru) участники обнаруживали атаку через фильтр http contains "sql", находя User-Agent вида sqlmap/1.7.10#stable. Фильтр http.user_agent contains "sqlmap" или http.user_agent contains "nikto" изолирует такие запросы за секунду.

Wireshark экспорт объектов для HTTP. File → Export Objects → HTTP — быстрейший способ вытащить все переданные файлы. На том же KnightCTF 2024 участники извлекали архив maybeconfidential.zip именно так, а внутри .docx (который тоже ZIP) нашли флаг в word/document.xml. Матрёшка — любимый приём задачников.

Cookies и заголовки. Фильтр http.cookie contains "session" покажет пакеты с сессионными куками. В заданиях на session hijacking флаг бывает спрятан в значении cookie или кастомного HTTP-заголовка. Данные передаются в открытом виде — Web Protocols (T1071.001) как канал управления.

Шаг 4 — DNS-анализ и обнаружение DNS-туннелей

DNS-трафик есть практически в каждом дампе. В CTF forensics заданиях DNS используется двумя способами: для обычного резолвинга имён и как канал эксфильтрации (Application Layer Protocol: DNS, T1071.004, Command and Control).

Базовый анализ: фильтр dns покажет все запросы и ответы. Обращайте внимание на домены с длинными поддоменами, hex-строками или base64-подобным содержимым.

TXT-записи: фильтр dns.qry.type == 16 выделяет запросы TXT-записей. В легитимном трафике TXT встречается редко (SPF, DKIM). Массовые TXT-запросы к одному домену — почти гарантированный DNS-туннель.

Детекция эксфильтрации по длине. Нормальный DNS-запрос содержит домен до 50–60 символов. Запросы длиной 100+ символов с поддоменами вида aGVsbG8gd29ybGQ=.evil.com — это данные, закодированные в base64 и передаваемые через DNS (Exfiltration Over Unencrypted Non-C2 Protocol, T1048.003). В tshark проверяется одной командой:

tshark -r evidence.pcap -Y "dns.qry.name" \
  -T fields -e dns.qry.name | \
  awk -F'.' '{print length($0), $0}' | \
  sort -rn | head -20

Вывод — 20 самых длинных DNS-запросов. Аномалии видны мгновенно. Поддомены с base64 декодируются стандартно: echo "aGVsbG8gd29ybGQ=" | base64 -d.

Подозрительные домены: если в дампе 500 запросов к google.com и 3 запроса к x7kf2.xyz, начинайте с редких. Атакующий обращается к собственному серверу, и его домен всегда будет белой вороной в общей массе.

Шаг 5 — Follow TCP Stream: восстановление сессий целиком

Follow TCP Stream — пожалуй, самая полезная функция Wireshark для CTF. Она реконструирует полный диалог между двумя хостами в рамках одного TCP-соединения: запросы клиента (красный текст) и ответы сервера (синий).

Использование: правый клик по любому TCP-пакету → Follow → TCP Stream. Для UDP — Follow → UDP Stream.

Plaintext-протоколы раскрываются полностью. FTP-сессия покажет команды USER, PASS, RETR, STOR с именами файлов и паролями в чистом виде (File Transfer Protocols, T1071.002). Telnet — полную bash-историю с командами атакующего. SMTP (Mail Protocols, T1071.003) — содержимое писем и аутентификацию. На KnightCTF 2024 участники через Follow TCP Stream восстановили bash_history из telnet-сессии обратной оболочки на порту 6200, где нашли закодированную строку Twin-Hex.

Навигация между потоками. В окне Follow TCP Stream есть счётчик «Stream N of M» и стрелки переключения. На соревновании пролистывайте потоки последовательно — флаг нередко лежит не в первом потоке. Я обычно начинаю с потоков, у которых аномальный размер (шаг 1 подсказывает, какие).

Сохранение бинарных данных. Если поток содержит бинарный файл (картинку, архив, исполняемый файл), переключите формат с ASCII на Raw и нажмите «Save as…». Результат — чистый файл без протокольных заголовков. Далее file extracted_data определит тип.

Ограничение: Follow TCP Stream работает только для полностью захваченных сессий. Если pcap записан с потерей пакетов, реконструкция будет неполной — в таких случаях переходите к ручному извлечению через Hex Dump.

Шаг 6 — Извлечение файлов из трафика через Export Objects

Извлечение файлов из трафика — ключевой навык для CTF forensics. Флаг часто спрятан внутри переданного объекта: в картинке (стеганография), в архиве, в .docx, в PDF.

Автоматическое извлечение. File → Export Objects → выбираете протокол: HTTP, SMB, TFTP, DICOM, IMF. Для HTTP — список файлов с именами, content-type и размером появляется мгновенно. Фильтр в окне Export Objects сужает результат: вбиваете zip или flag — и видите только релевантное.

Ручное извлечение через Follow TCP Stream. Когда Export Objects не справляется — файл шёл по нестандартному протоколу или был фрагментирован — используйте Follow TCP Stream → Show as Raw → Save as. Метод работает для любого TCP-трафика, но требует ручной идентификации границ файла.

Пост-обработка. После извлечения обязательно запускайте file имя_файла для определения типа. Частые находки в CTF:

• ZIP/7z-архивы (иногда запароленные — пароль ищите в соседней сессии того же pcap)
• PNG/JPEG с флагом в метаданных (exiftool image.png) или стеганографией (steghide extract -sf image.jpg, zsteg image.png)
• .docx — это ZIP-архив, внутри XML; флаг бывает скрыт в word/document.xml
• Исполняемые файлы для реверс-инжиниринга (Archive via Utility, T1560.001 — если атакующий запаковал данные перед передачей)

Wireshark vs NetworkMiner для извлечения. NetworkMiner автоматически реконструирует все файлы при открытии pcap, без ручных действий — вкладки Images, Files, Credentials заполняются сами. Но для loopback-трафика (дампы с интерфейса lo) NetworkMiner бесполезен: он не умеет парсить Linux cooked-mode capture. Для обычного Ethernet-трафика NetworkMiner быстрее Wireshark именно в задачах чистого извлечения.

Шаг 7 — Credential Hunting: пароли в открытом виде

Поиск учётных данных — и отдельная категория CTF-заданий, и частый побочный результат разбора сетевого трафика. Незашифрованный протокол = открытые пароли. Без вариантов.

FTP: фильтр ftp.request.command == "USER" || ftp.request.command == "PASS" выведет имена пользователей и пароли в чистом виде. FTP передаёт аутентификацию открыто — классический Network Sniffing (T1040).

HTTP Basic Auth: заголовок Authorization: Basic dXNlcjpwYXNz содержит логин:пароль в base64. Фильтр http.authorization находит такие запросы. Декодирование — одна команда: echo "dXNlcjpwYXNz" | base64 -d выведет user:pass.

HTTP-формы: POST-запросы с полями username и password в теле. Фильтр http.request.method == "POST" && http contains "password" отсеивает всё лишнее.

SMTP: Follow TCP Stream для SMTP-сессии покажет AUTH-команды и содержимое писем. Пароли SMTP AUTH тоже base64.

Telnet: весь ввод передаётся посимвольно. Follow TCP Stream восстановит логин, пароль и все набранные команды.

Ограничение: все эти методы работают исключительно для незашифрованного трафика. Если обмен идёт через TLS — переходите к шагу 8.

Шаг 8 — Расшифровка TLS при наличии pre-master secret

В продвинутых CTF forensics заданиях часть флага или весь флаг скрыт внутри TLS-трафика. Без ключа дешифровка невозможна, но задание всегда предоставляет ключ — вопрос в том, где его искать.

Где искать ключ в CTF: - В том же pcap — ключ передан по другому протоколу (email через SMTP, файл через FTP, вложение в HTTP) - В отдельном файле задания — sslkey.log, pre-master.txt - В артефакте, извлечённом на шаге 6

Формат ключа: файл со строками CLIENT_RANDOM — это pre-master secret log. Каждая строка содержит Client Random и Master Secret для расшифровки конкретной TLS-сессии.

Применение: Edit → Preferences → Protocols → TLS → поле «(Pre)-Master-Secret log filename» → путь к файлу. Wireshark автоматически расшифрует все сессии с подходящими ключами. Пакеты «TLSv1.2 Application Data» превратятся в читаемый HTTP. Магия.

После расшифровки применяйте стандартные техники из шагов 3–7: Export Objects для файлов, tcp contains "flag" для прямого поиска, фильтры по HTTP-полям для анализа запросов.

На TryHackMe Wireshark CTF room (по данным разбора на cyber-99.co.uk) одно из заданий требовало найти CLIENT_RANDOM в SMTP-переписке (порт 25), скопировать строку в файл и подключить через настройки TLS — после чего в расшифрованном HTTPS-трафике обнаруживался файл с искомым артефактом. Типичный паттерн CTF: ключ в одном месте, зашифрованные данные — в другом.

Ограничение: pre-master secret работает только если лог был записан во время TLS-сессии. Если задание предоставляет RSA-ключ сервера, его подключают в том же разделе Preferences → TLS → RSA keys list. Для TLS 1.3 с ephemeral ключами RSA-ключ сервера бесполезен — нужен именно pre-master secret log.

Шаг 9 — Нестандартные протоколы и скрытые каналы передачи данных

Если шаги 3–8 не дали результата — задание использует нестандартный канал. По MITRE ATT&CK это Application Layer Protocol (T1071) и Exfiltration Over C2 Channel (T1041). Самое интересное начинается тут.

Кастомные TCP/UDP-порты. На шаге 1 вы видели в Conversations нестандартные порты? Фильтруйте по порту (tcp.port == 1337 или tcp.port == 666) и делайте Follow TCP Stream. В TryHackMe Wireshark CTF задание с ASCII-артом на порту 666 решалось именно так: фильтр tcp.port == 666 → Follow TCP Stream → в потоке визуальный арт-объект.

Decode As. Если Wireshark не распознал протокол, правый клик по пакету → Decode As → выбираете протокол вручную. Это критично для RTP-потоков, замаскированных под обычный UDP: без Decode As → RTP Wireshark не увидит аудио.

ICMP-эксфильтрация. Данные прячутся в payload ICMP-пакетов. Фильтр icmp → Data-секция каждого пакета. Нормальный ping содержит padding из букв алфавита. Если data содержит base64, hex или читаемый текст — это скрытый канал. Я на одном CTF потерял 20 минут, потому что не догадался заглянуть в ICMP-payload — а там побайтово лежал флаг.

RTP и VoIP. Telephony → RTP → RTP Streams покажет аудио-потоки. Analyze → Play Streams воспроизведёт запись. Флаг может быть произнесён голосом или закодирован DTMF-тонами. Если RTP не определяется — ищите UDP-потоки с периодичностью пакетов 20–30 мс и применяйте Decode As.

DNS-ответы. Помимо запросов (шаг 4), проверяйте содержимое ответов. Фильтр dns.txt покажет все TXT-ответы — в них может лежать base64-фрагмент флага, собираемый из нескольких ответов.

Шаг 10 — tshark: автоматизация анализа pcap из командной строки

Wireshark GUI удобен для ручного исследования. Но когда pcap весит 500+ МБ или нужно обработать десять файлов за час соревнования — tshark командная строка решает.

Базовый принцип: tshark -r файл.pcap -Y "фильтр" -T fields -e поле1 -e поле2. Флаг -Y принимает те же Wireshark display filters, что и GUI. Флаг -T fields выводит только указанные поля.

# Все HTTP-хосты и URI
tshark -r ctf.pcap -Y "http.request" -T fields -e http.host -e http.request.uri

# DNS-запросы длиннее 60 символов (подозрение на туннель)
tshark -r ctf.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | awk 'length>60'

# Прямой поиск формата флага
tshark -r ctf.pcap -Y 'frame contains "CTF{"'

# FTP-логины и пароли
tshark -r ctf.pcap -Y "ftp.request.command==USER || ftp.request.command==PASS" \
  -T fields -e ftp.request.arg

Пайплайн с grep/sort/uniq. tshark выводит текст — пропускайте через стандартные утилиты. Команда tshark -r ctf.pcap -Y "dns" -T fields -e dns.qry.name | sort | uniq -c | sort -rn | head покажет топ-10 запрашиваемых доменов — аномалия видна мгновенно.

Когда tshark критически быстрее GUI. На pcap от 200 МБ Wireshark может загружаться минуту и подтормаживать при каждом фильтре. tshark обрабатывает тот же файл в потоковом режиме за секунды. Утилита editcap -c 10000 huge.pcap chunk.pcap нарежет гигантский дамп на куски по 10 000 пакетов — анализируйте каждый отдельно.

Ограничение: tshark не умеет извлекать файлы из потоков так же удобно, как Export Objects в GUI. Для массового извлечения файлов есть tshark --export-objects http,output_dir — но GUI остаётся удобнее для визуальной фильтрации результатов.

Когда Wireshark недостаточен: сравнение инструментов network forensics CTF

Wireshark — не единственный инструмент для разбора сетевого трафика, и на CTF полезно знать границы каждого.

Критерий	Wireshark	tshark	NetworkMiner Free
Интерфейс	GUI	Командная строка	GUI
Скорость на pcap свыше 200 МБ	Медленно (загрузка целиком в RAM)	Быстро (потоковая обработка)	Средне
Автоизвлечение файлов	Export Objects, ручной выбор	Частично (--export-objects)	Полностью автоматически
Сбор учётных данных	Ручной, через фильтры	Ручной, через поля	Автоматический (вкладка Credentials)
Loopback-трафик (Linux lo)	Да	Да	Нет
Скриптование	Lua-плагины	Shell-пайпы, Python	Нет
Когда использовать	Глубокий ручной анализ, Follow Stream	Автоматизация, массовый поиск	Быстрый обзор хостов, файлов, кредов

Decision tree для CTF: открывайте pcap в Wireshark для первичной разведки (шаги 1–9). Параллельно загружайте тот же файл в NetworkMiner — за секунды увидите все извлечённые файлы и учётные данные без ручной работы. Если pcap большой или нужна массовая фильтрация — переключайтесь на tshark.

Общее ограничение всех трёх инструментов: ни один не расшифрует TLS без ключа и ни один не проведёт автоматический анализ вредоносных артефактов. Извлечённые файлы анализируются отдельно — file, strings, exiftool, специализированные инструменты стеганографии и реверса.

За два года участия в CTF я вижу устойчивый паттерн: команды проигрывают forensics-задания не из-за незнания Wireshark, а из-за отсутствия методики. Девяносто процентов участников знают про Follow TCP Stream. Но перед pcap на 200 тысяч пакетов это знание бесполезно без системного подхода — прыгаешь между случайными пакетами, теряешь контекст, тратишь 40 минут на то, что алгоритм закрывает за 10.

Главная ошибка — начинать с содержимого пакетов вместо статистики. Protocol Hierarchy и Conversations занимают 30 секунд и сужают область поиска в десятки раз. Без этого шага всё остальное — перебор наугад. Вторая ошибка — игнорирование tshark. Одна строка tshark -r ctf.pcap -Y 'frame contains "flag"' находит то, на что при ручном поиске уходит четверть часа. Третья — непонимание того, как атаки выглядят в трафике. Когда видишь SQL-injection в pcap, нужно понимать, что за вектор перед тобой и зачем он тут. Иначе не отличишь payload от шума. Разбирать чужие атаки в дампе полезно — формула на бумаге понятна, но до настоящего понимания нужно дойти руками. Если хочешь не просто writeup, а пройти всю атаку самому — на WAPT каждый такой вектор разбирают с лабой на каждый кейс.

🚀 Хочешь закрепить на практике? Реши задачи по теме на HackerLab — категория «forensics».