Wireshark для CTF: как читать PCAP, фильтровать трафик и вытаскивать флаги

Wireshark для CTF: как читать PCAP, фильтровать трафик и вытаскивать флаги

На CyberDefenders-челлендже EscapeRoom я потратил 40 минут, прокручивая тысячи пакетов колесом мыши — и нашёл ровно ноль зацепок. Потом открыл Statistics → Protocol Hierarchy, увидел, что 91% трафика — TLS, а незашифрованный HTTP составляет 0.3%, — и флаг нашёлся за три минуты в User-Agent заголовке wget-запроса. Разница между «крутить пакеты час» и «решить за пять минут» — не талант, а методика. В сетевой форензике на CTF побеждает тот, кто знает, куда смотреть первым. Здесь — пошаговый алгоритм анализа PCAP-файлов в Wireshark, который работает на PicoCTF, CyberDefenders, HackTheBox и любой другой площадке. От открытия файла до извлечения флага.

Требования к окружению и инструменты

Прежде чем открыть первый PCAP — убедитесь, что рабочее место не подведёт.

Параметр	Минимум	Рекомендуется
RAM	4 ГБ	8 ГБ (для дампов > 100 МБ)
ОС	Windows 10 / Ubuntu 20.04 / macOS 11+	Любая из перечисленных
Wireshark	3.x и выше	Последняя стабильная (релизы каждые 2-3 месяца)
tshark	Ставится вместе с Wireshark	Та же версия
CyberChef	Веб-версия на gchq.github.io/CyberChef	Локальная копия для offline-работы
Сеть	Не нужна — анализ offline-файлов	Онлайн для CyberChef в браузере

Wireshark — стандарт индустрии для протокольного анализа. tshark — его консольная версия из того же дистрибутива, без которой не обойтись при обработке больших дампов и автоматизации. CyberChef — веб-тулза для декодирования (Base64, hex, ROT13 и десятки других операций), которая нужна практически на каждом CTF.

Что мы ищем в PCAP: место анализа в цепочке атаки

PCAP — запись сетевого трафика, в которой остаются следы действий атакующего. В терминах MITRE ATT&CK типичные CTF-задания моделируют конкретные техники:

• Network Sniffing (T1040) — сам факт перехвата трафика, из которого получен дамп
• Web Protocols (T1071.001) — управляющие команды или данные через HTTP
• DNS (T1071.004) — C2-коммуникации или эксфильтрация через DNS-запросы
• Standard Encoding (T1132.001) — данные закодированы Base64, hex или другими способами
• Exfiltration Over Unencrypted Non-C2 Protocol (T1048.003) — утечка данных через FTP, SMTP, HTTP в открытом виде

Эти техники напрямую подсказывают, на какие протоколы обращать внимание. Если в задании говорится про «утечку данных» — ищите DNS exfiltration или незашифрованный HTTP. Если про «скомпрометированные учётные данные» — проверяйте FTP и SMTP.

Разведка PCAP: первые пять минут решают всё

Открыли файл — не начинайте читать пакеты сверху вниз. Это ловушка, в которую попадают все новички. Первые пять минут — разведка: определить, куда стоит потратить время, а что смело классифицировать как фоновый шум.

Protocol Hierarchy — карта протоколов

Меню Statistics → Protocol Hierarchy показывает процентное распределение протоколов по количеству пакетов и объёму данных. Это первое, куда нужно смотреть после открытия файла.

В разборе evidence.pcap из CTF-задания Protocol Hierarchy сразу показал картину: 88.4% пакетов — TCP, внутри доминирует TLS (91.1% по объёму), но присутствуют DNS (11.6% пакетов) и HTTP (0.3%). Именно эти незашифрованные 0.3% содержали ключевые данные. Без Protocol Hierarchy вы бы копались в зашифрованном TLS-трафике часами — и ни к чему бы не пришли.

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

• HTTP без HTTPS — открытый текст, первый кандидат на анализ
• DNS — аномально большой процент DNS указывает на DNS-эксфильтрацию
• FTP / SMTP — передача файлов и credentials в plaintext
• Нестандартные протоколы — UDP на высоких портах, IRC, RTP, данные на портах вроде 4444 или 1337

Conversations и Endpoints — кто с кем общался

Statistics → Conversations показывает все пары взаимодействующих хостов. Вкладка TCP, отсортированная по объёму переданных байтов, мгновенно выделяет «толстые» сессии.

В разборе EscapeRoom на CyberDefenders именно Conversations позволил отделить успешные SSH-сессии от неудачных brute-force попыток: 52 коротких TCP-сессии с малым объёмом данных от сервера — неудачные попытки аутентификации, две сессии с большим объёмом — успешные. Без этого пришлось бы вручную просматривать каждую из 54 сессий. Жизнь слишком коротка.

Statistics → Endpoints дополняет картину: один внутренний IP, общающийся с десятком внешних — нормально. Один внешний IP, инициирующий сотни соединений — аномалия, которая заслуживает пристального внимания.

Ограничение: Protocol Hierarchy и Conversations показывают только статистику, не содержимое пакетов. Это инструмент для решения «куда копать», а не для поиска флага напрямую. После разведки — переходите к фильтрации.

Display-фильтры Wireshark для CTF-задач

Display-фильтры — основной инструмент навигации по дампу. Без них анализ файла с тысячами пакетов превращается в лотерею. Фильтры вводятся в строку в верхней части окна Wireshark и применяются нажатием Enter.

Фильтрация по протоколу и полям

Фильтры, которые стоит знать наизусть:

• http — весь HTTP-трафик
• dns — все DNS-запросы и ответы
• ftp — FTP-сессии с credentials в открытом виде
• smtp — электронная почта
• tcp.port == 4444 — трафик на конкретном порту (4444 — классика для reverse shell)
• ip.addr == 10.0.2.15 — все пакеты от/к конкретному IP
• http.request.method == "POST" — только POST-запросы (формы, загрузка файлов, отправка credentials)
• http.response.code == 200 — успешные HTTP-ответы

Фильтры комбинируются: && — логическое И, || — логическое ИЛИ, ! — отрицание. Например, http && ip.src == 10.0.2.15 покажет HTTP-трафик от конкретного хоста. А !dns && !arp уберёт фоновый шум DNS-резолвинга и ARP-запросов — сразу станет чище.

Поиск строк и регулярные выражения

Когда формат флага известен (например, CTF{...} или flag{...}), поиск по содержимому — самый быстрый путь к решению:

• frame contains "flag" — ищет строку «flag» во всём фрейме, включая payload и заголовки
• http contains "CTF{" — ищет только в HTTP-пакетах
• tcp contains "password" — пароли в TCP-потоке
• dns.qry.name contains "suspicious" — подстроки в DNS-запросах

Для регулярных выражений — оператор matches: фильтр http.request.uri matches ".*\\.php" покажет все запросы к PHP-скриптам, а dns.qry.name matches "^[a-f0-9]+\\." выявит DNS-запросы с hex-строками в поддоменах — типичный признак DNS exfiltration.

Если формат флага неизвестен — начните с серии запросов: frame contains "flag", затем frame contains "key", затем frame contains "secret", затем frame contains "pass". На CTF начального уровня флаг передаётся в открытом виде примерно в половине заданий. Да, вот так просто.

Когда display-фильтры не помогут: если трафик зашифрован (TLS/SSL) и у вас нет ключа дешифрации, фильтры по содержимому покажут только мусор. Нужен pre-master secret log или серверный приватный ключ — иногда их дают в задании отдельным файлом (формат: CLIENT_RANDOM ...). Ключ подключается через Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename.

Follow TCP Stream: восстановление диалогов

Follow TCP Stream собирает все пакеты одной TCP-сессии в единый читаемый поток. По сути, это перехваченный диалог между клиентом и сервером, склеенный из фрагментов. Красный текст — данные от клиента, синий — от сервера.

Как открыть и что искать

Правый клик на любом пакете интересующей сессии → Follow → TCP Stream. Wireshark покажет полный текст обмена. В нижней части окна кнопки навигации между потоками — Stream 0, Stream 1, Stream 2 и далее. На CTF начального уровня потоков обычно немного, и стоит просмотреть каждый.

Типичные находки в TCP Stream на CTF:

• HTTP-запросы и ответы целиком — включая заголовки User-Agent (часто содержит подсказку или название инструмента) и тело ответа
• FTP-сессии — логин и пароль передаются командами USER и PASS в открытом виде. Просто лежат, бери и копируй
• SMTP-переписка — содержимое писем, вложения в Base64
• Кастомные текстовые протоколы — чаты, команды управления, скрипты
• Код, переданный по сети — в одном из разборов THM Wireshark CTF в потоке обнаружился Python-скрипт, который многоступенчато кодировал флаг через ROT13, Base64 и Caesar cipher со сдвигом 3. Матрёшка, одним словом

Работа с кодировками в потоке

Видите в потоке строку вроде Q1RGe3cxcjNzaDRya30=? Это Base64. Копируйте в CyberChef, рецепт From Base64 — и готово. Основные кодировки на CTF:

• Base64 — строки из букв, цифр, + и /, часто заканчиваются на = или ==
• Hex — парные символы 0-9a-f (пример: 43 54 46 7b декодируется в CTF{)
• ROT13 — буквы смещены на 13 позиций, в CyberChef рецепт ROT13
• URL-encoding — %43%54%46%7B расшифровывается в CTF{
• Многоступенчатое кодирование — несколько слоёв подряд, где выход одного становится входом другого

Для многоступенчатого декодирования CyberChef позволяет собрать цепочку рецептов: перетащите From Base64, затем ROT13, затем другие операции — результат обновится автоматически. Это на порядок быстрее, чем декодировать каждый слой руками.

Ограничение: Follow TCP Stream работает только с незашифрованным трафиком. Для TLS-сессий поток покажет нечитаемые бинарные данные, если не загружен ключ дешифрации.

Извлечение файлов из сетевого дампа

Файлы, переданные по сети, можно восстановить из PCAP целиком. Один из самых частых CTF-сценариев: флаг спрятан внутри изображения, PDF, архива или исполняемого файла.

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

В разборе EscapeRoom через Export Objects → HTTP были извлечены три файла — два ELF-бинарника и shell-скрипт. Тип файла определяется командой file в терминале — она читает magic bytes: даже если расширение файла неправильное или отсутствует, file покажет реальный тип. Дальше strings <filename> | grep -i flag ищет текстовые строки в бинарных файлах — часто флаг или его часть хранятся именно так.

В разборе THM Wireshark CTF один из вопросов требовал извлечь изображение jack-o-lantern.jpg через Export Objects → HTTP. Другой предполагал извлечение RTP-аудиопотока через Telephony → RTP → RTP Streams, но поток был замаскирован под неизвестный UDP-протокол. Решение: правый клик на пакете → Decode As → выбор протокола RTP — после чего Wireshark распознал аудио и позволил его проиграть. Хитро, но если знаешь про Decode As — решается за минуту.

Когда автоматическое извлечение не работает: если файл передан по нестандартному протоколу, используйте Follow TCP Stream: откройте нужный поток, в выпадающем меню Show data as выберите Raw, нажмите Save As и сохраните бинарные данные. Затем проверьте результат командой file.

Ограничение: если захват трафика был остановлен раньше, чем передача файла завершилась — восстановить полный файл невозможно. Wireshark покажет частичные данные. Обращайте внимание на пометку [TCP segment of a reassembled PDU] без финального ACK.

DNS в CTF: эксфильтрация через запросы

DNS-эксфильтрация — техника, при которой данные передаются через DNS-запросы, обычно в поддоменах или TXT-записях. В терминах MITRE ATT&CK это DNS (T1071.004) для C2-коммуникаций и Exfiltration Over Unencrypted Non-C2 Protocol (T1048.003) для выгрузки данных. На CTF встречается регулярно: DNS-трафик часто проходит через межсетевые экраны без глубокой инспекции, и авторы заданий этим пользуются.

Признаки DNS exfiltration

Сравните два DNS-запроса:

• Нормальный: www.google.com
• Подозрительный: 4354467b64336e735f337866316c7d.evil.com

Второй — это hex-закодированная строка в поддомене. Разница видна невооружённым глазом, но нужно знать, куда смотреть.

Признаки, на которые стоит обращать внимание:

• Поддомены длиной 30+ символов
• Поддомены из hex-символов (0-9, a-f) или символов Base64
• Серия запросов к одному домену с разными поддоменами, идущих подряд
• TXT-записи с необычно длинным содержимым
• DNS-запросы на нетипичные порты (не 53)

Фильтры для обнаружения: dns.qry.type == 16 покажет TXT-записи, dns.qry.name matches "^[a-f0-9]{20,}\\." — запросы с длинными hex-строками в поддоменах.

Декодирование данных из поддоменов

Алгоритм извлечения данных из DNS exfiltration:

1. Отфильтруйте DNS-запросы к подозрительному домену: dns.qry.name contains "evil.com"
2. Из каждого запроса выделите поддомен — часть до первой точки основного домена
3. Соберите поддомены в порядке временных меток (Wireshark уже сортирует по времени)
4. Объедините в одну строку и декодируйте через CyberChef: From Hex или From Base64

В разборе evidence.pcap упоминается скрытый пасхальный флаг, переданный через нестандартные протоколы или скрытые каналы связи. DNS TXT-записи — один из самых распространённых вариантов таких каналов.

Ограничение: если атакующий использует DNS over HTTPS (DoH) или DNS over TLS (DoT), стандартный фильтр dns бесполезен — запросы зашифрованы внутри HTTPS/TLS-потока. На CTF начального и среднего уровня DoH встречается редко, но на продвинутых соревнованиях стоит проверять HTTPS-соединения к известным DoH-провайдерам (8.8.8.8:443, 1.1.1.1:443).

Credential Hunting: пароли в PCAP-файлах

Учётные данные в открытом виде — частая находка в CTF-дампах. Протоколы FTP, HTTP Basic Auth, SMTP без TLS передают логины и пароли без шифрования. Это моделирует реальную ситуацию: по данным OWASP, Cryptographic Failures (A02:2021) входят в тройку критичных рисков веб-приложений, и передача credentials без шифрования — классический пример.

FTP, HTTP Basic, SMTP — где искать

FTP: фильтр ftp.request.command == "USER" || ftp.request.command == "PASS" покажет все попытки аутентификации. Логин и пароль передаются отдельными командами в plaintext — копируй и вставляй.

HTTP Basic Auth: фильтр http.authorization выделит запросы с заголовком Authorization, который содержит Base64-строку формата user:password. Одна операция From Base64 в CyberChef — и credentials у вас.

HTTP POST-формы: фильтр http.request.method == "POST", далее в теле запроса ищите параметры login, username, password, passwd. Данные формы видны в нижней панели Wireshark при выборе пакета.

SMTP: фильтр smtp, команды AUTH LOGIN или AUTH PLAIN содержат Base64-закодированные credentials. Follow TCP Stream покажет полную сессию аутентификации с логином и паролем.

Распознавание brute-force в дампе

В разборе EscapeRoom на CyberDefenders для определения SSH brute-force использовался анализ Conversations: 52 коротких TCP-сессии к порту 22 с малым объёмом данных от сервера — неудачные попытки аутентификации. Две сессии с существенно большим объёмом — успешная авторизация. Зная это, можно сфокусироваться на двух успешных сессиях и разобраться, что делал атакующий после входа.

Аналогичный паттерн работает для HTTP brute-force: множество POST-запросов к /login с ответами 401 или 403, и один-два ответа 200 или 302 (редирект) — подбор пароля. Фильтр http.request.method == "POST" && http.request.uri contains "login" покажет все попытки.

tshark для автоматизации анализа PCAP

Когда нужно обработать большой PCAP или извлечь конкретные поля из тысяч пакетов, GUI становится неудобен. tshark решает эту задачу из командной строки.

# Все HTTP-запросы с хостом и URI
tshark -r capture.pcap -Y "http.request" -T fields -e http.host -e http.request.uri
# Все DNS-запросы (только имена)
tshark -r capture.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | sort -u
# Поиск строки во всём дампе
tshark -r capture.pcap -Y 'frame contains "flag"'
# FTP credentials
tshark -r capture.pcap -Y "ftp.request.command==USER || ftp.request.command==PASS" -T fields -e ftp.request.arg
# Статистика протоколов (аналог Protocol Hierarchy)
tshark -r capture.pcap -q -z io,phs

Результат tshark — текст, который можно передать в grep, sort, uniq, awk и другие стандартные Unix-утилиты. Для DNS exfiltration это критически полезно: вместо ручного копирования поддоменов из сотен пакетов — одна команда с пайпом в awk для извлечения нужной части. Экономия — десятки минут на одном задании.

Когда tshark предпочтительнее GUI: PCAP больше 500 МБ (Wireshark GUI может намертво зависнуть на загрузке), нужно извлечь одно поле из всех пакетов, автоматическая обработка нескольких файлов скриптом, работа на сервере без графической оболочки.

Ограничение: tshark использует те же протокольные диссекторы, что и Wireshark, но не все функции GUI доступны из командной строки. Export Objects через tshark менее удобен — для извлечения файлов проще использовать GUI или NetworkMiner, который автоматически реконструирует файлы из трафика.

Чеклист: алгоритм разбора PCAP за 10 шагов

Этот чеклист — последовательность действий, которую можно использовать на любом CTF. Порядок важен: каждый следующий шаг опирается на результаты предыдущего.

1. Protocol Hierarchy — Statistics → Protocol Hierarchy. Определите, какие протоколы есть в дампе. Незашифрованные (HTTP, FTP, DNS, SMTP) — приоритет номер один.
2. Conversations — Statistics → Conversations → TCP. Отсортируйте по байтам. Найдите аномалии: необычно большой объём, много коротких соединений, нестандартные порты.
3. Быстрый поиск флага — frame contains "flag", frame contains "CTF{", frame contains "key". Если формат флага дан в условии — используйте его.
4. HTTP-анализ — фильтр http. Проверьте POST-запросы, заголовки, параметры URL. Затем File → Export Objects → HTTP для извлечения файлов.
5. DNS-анализ — фильтр dns. Ищите длинные поддомены, TXT-записи с hex/Base64.
6. Follow TCP Stream — пройдите по потокам (Stream 0, 1, 2...). Ищите plaintext-данные, credentials, закодированные строки, фрагменты кода.
7. Credential Hunting — ftp.request.command == "USER", http.authorization, smtp. Соберите все учётные данные.
8. Извлечение файлов — Export Objects для HTTP / SMB / TFTP / IMF. Каждый файл проверьте через file и strings | grep -i flag.
9. Декодирование — всё подозрительное через CyberChef: Base64, hex, ROT13, URL-decode. Попробуйте цепочки из нескольких рецептов.
10. Нестандартные протоколы — UDP на высоких портах, данные на портах 666, 1337, 31337. Попробуйте Decode As для переназначения протокольного диссектора (как в THM CTF, где UDP-поток на порту 1313 оказался RTP-аудио).

Если после всех десяти шагов флаг не найден — вернитесь к Protocol Hierarchy и проверьте, не пропустили ли менее очевидный протокол. Иногда данные прячут в ICMP-пакетах (пинг с payload), в поле Options TCP-заголовка или в padding Ethernet-фреймов. Авторы CTF-заданий — люди с фантазией.

---

Большинство новичков на CTF делают одну и ту же ошибку — пытаются понять каждый пакет в дампе. Открывают файл на 50 000 пакетов и начинают читать сверху вниз, разворачивая каждый фрейм до уровня байтов. Через полчаса — сдаются. А те, кто проходят Protocol Hierarchy → Conversations → быстрый поиск строки — решают задачу за 10 минут.

В реальном дампе 95% трафика — фоновый шум: DNS-резолвинг стандартных доменов, TLS-рукопожатия, TCP keepalive, ARP-запросы. Вся ценность сосредоточена в оставшихся 5%, и задача — быстро отфильтровать шум. Protocol Hierarchy даёт эту возможность за один клик, без чтения ни одного пакета.

Второй момент, который упускают: после нахождения основного флага стоит покопаться в дампе ещё. В CTF-задании evidence.pcap помимо основного флага был скрытый пасхальный флаг, спрятанный в DNS TXT-записях через нестандартные каналы. Многие задания содержат бонусные флаги, и именно они отличают того, кто «решил» задачу, от того, кто её разобрал.

Навык анализа PCAP переносится напрямую в работу: сетевая форензика — основа incident response, threat hunting, анализа вредоносного ПО. Кто научился вытаскивать флаги из CTF-дампов — тот не растеряется перед реальным инцидентом, когда SOC-аналитик передаёт PCAP с вопросом «что здесь произошло». На курсе IB Basics эту связку CTF → реальные задачи разбирают на конкретных кейсах — для тех, кому мало Hack The Box без объяснений «зачем».

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