Wireshark для CTF: ищем флаги в PCAP

Первый PCAP-челлендж я ковырял полтора часа: 15 000 пакетов, прокрутка колесом мыши, попытки читать hex-дампы глазами. Флаг лежал в единственном HTTP POST-запросе, который утонул среди тысяч зашифрованных TLS-пакетов. Один фильтр http.request.method == "POST" закрыл бы задачу за минуту. С тех пор у меня есть алгоритм работы с PCAP, который стабильно решает forensics-категорию на CTF любого уровня — от picoCTF до CyberDefenders. Ниже — алгоритм целиком, с фильтрами, tshark-однострочниками и типовыми ловушками.

Разведка: первые 5 минут анализа PCAP-файлов

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

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

Сценарий на CTF	MITRE ATT&CK	Что искать в Wireshark
Перехваченные учётные данные	Network Sniffing (T1040)	FTP, Telnet, SMTP в открытом виде
Пароли в HTTP-формах	Adversary-in-the-Middle (T1557)	POST-запросы с полями login/password
C2-коммуникации через HTTP	Web Protocols (T1071.001)	Подозрительные User-Agent, нестандартные URI
C2 через файловые протоколы	File Transfer Protocols (T1071.002)	FTP/TFTP-потоки к C2-серверу
DNS-эксфильтрация	DNS (T1071.004)	Длинные hex-поддомены, массовые TXT-запросы
Кодирование C2-трафика	Standard Encoding (T1132.001)	Base64-строки в C2-коммуникациях
Стеганография	Steganography (T1027.003)	Вложенные файлы в извлечённых объектах
Утечка данных через C2	Exfiltration Over C2 Channel (T1041)	Аномальный объём исходящих данных

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

Protocol Hierarchy — карта трафика

Меню Statistics → Protocol Hierarchy — первое окно после загрузки PCAP. Здесь видно процентное распределение протоколов по числу пакетов и объёму данных.

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

На что обращать внимание в иерархии: - HTTP, FTP, Telnet, SMTP — протоколы, которые гоняют данные (включая пароли) открытым текстом. Приоритет номер один. - DNS — если доля DNS аномально высока, возможна эксфильтрация через поддомены. - IRC, TFTP, нестандартные протоколы — редкие звери в дампе почти всегда заслуживают внимания.

Conversations и Endpoints

Statistics → Conversations (вкладка TCP, сортировка по объёму) показывает все пары взаимодействующих хостов. Мгновенно отделяет фоновый шум от целевого трафика.

Ключевые аномалии: - Одно соединение с аномально большим объёмом данных — вероятная эксфильтрация или передача файла. - Десятки коротких TCP-сессий к одному порту — brute-force или сканирование. - Соединение на порт 4444, 1337, 31337, 9001 — классические порты reverse shell. На CTF они встречаются постоянно. - HTTP-соединение (порт 80) при доминировании TLS — аномалия, которую стоит исследовать первой.

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

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

Фильтры Wireshark для задач network forensics CTF

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

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

Набор фильтров, которые нужно знать наизусть: - http — весь HTTP-трафик - dns — DNS-запросы и ответы - ftp — FTP-сессии - smtp — электронная почта - telnet — Telnet-сессии - tcp.port == 4444 — трафик на конкретном порту - ip.addr == 10.0.2.15 — пакеты от/к определённому IP - http.request.method == "POST" — POST-запросы (формы, загрузка файлов, отправка паролей)

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

Как найти флаг в PCAP: frame contains

Когда формат флага известен (а на CTF он указан в описании задачи почти всегда) — поиск по содержимому самый быстрый путь: - frame contains "flag" — строка «flag» во всём фрейме, включая payload - frame contains "CTF{" — конкретный формат флага - tcp contains "password" — пароли в TCP-потоке - http contains "secret" — секретные данные в HTTP

На CTF начального уровня флаг передаётся в открытом виде примерно в половине заданий. Не шучу — frame contains плюс формат флага решают задачу за 30 секунд. Проверяйте самый тупой способ первым, прежде чем нырять в глубокий анализ протоколов.

Если формат неизвестен — пробуйте серию: frame contains "flag", затем frame contains "key", затем frame contains "secret", затем frame contains "pass". Хотя бы одна из этих строк даёт зацепку в большинстве случаев.

Регулярные выражения: matches

Оператор matches поддерживает regex и решает задачи, которые contains не вытянет: - http.request.uri matches ".*\\.php" — все запросы к PHP-скриптам - dns.qry.name matches "^[a-f0-9]{10,}\." — DNS-запросы с длинными hex-строками в поддоменах (типичный признак DNS exfiltration) - http.user_agent matches "(?i)sqlmap|nikto|nmap" — следы сканеров в User-Agent

Для охоты за кредами — отдельная группа фильтров: - http.authorization — HTTP Basic/Digest аутентификация (Base64-закодированные креды) - ftp.request.command == "PASS" — FTP-пароли открытым текстом - smtp.auth.password — SMTP-пароли

Ограничение display-фильтров: если трафик зашифрован TLS и ключа дешифрации нет — фильтры по содержимому покажут мусор. Об этом ниже в разделе про TLS-дешифрование.

Wireshark Follow TCP Stream: вытаскиваем пароли из трафика

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

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

Типичные находки в TCP Stream на CTF: - FTP-сессия: команды USER и PASS открытым текстом. Пароль часто и есть флаг или содержит его часть. - Telnet-сессия: символы вводятся по одному, но Wireshark собирает их в читаемый текст. Ищите вводимые команды и ответы сервера. - HTTP-обмен: заголовки запросов и ответов целиком — User-Agent, Cookie, Set-Cookie, Authorization. - Reverse shell: если в потоке видны команды whoami, id, cat /etc/passwd — перед вами сессия reverse shell. Флаг обычно в выводе одной из команд.

220 FTP Server Ready
USER admin
331 Password required for admin
PASS CTF{ftp_cr3ds_1n_pl41n}
230 User admin logged in

Всё, что после PASS, — флаг. На CTF среднего уровня пароль может быть закодирован (Base64, hex), но принцип тот же.

Декодирование: Base64, Hex, URL-encoding

Если в потоке встречается строка вроде Q1RGe3cxcjNzaDRya30= — это Base64. Standard Encoding (T1132.001) — кодирование данных в C2-коммуникациях — один из самых частых приёмов маскировки на CTF. На практике Base64/hex встречаются и вне C2-контекста, но T1132.001 формально описывает именно кодирование внутри C2-канала.

Кодировка	Признаки	Пример	Инструмент
Base64	A-Za-z0-9+/, = на конце	Q1RGe3cxcjNzaDRya30=	CyberChef: From Base64
Hex	0-9a-f, часто через пробел	43 54 46 7b	CyberChef: From Hex
URL-encoding	%XX	%43%54%46%7B	CyberChef: URL Decode
ROT13	Латиница, визуально «сдвинута»	PGS{synt}	CyberChef: ROT13

CyberChef (gchq.github.io/CyberChef) — стандартный инструмент для таких вещей. Перетаскиваете рецепты в цепочку: From Base64 → ROT13 → результат обновляется автоматически. Многоступенчатое декодирование — норма на CTF среднего уровня.

Экспорт объектов Wireshark: файлы из PCAP

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

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

После извлечения каждый файл проверяем: - file имя_файла — определяет реальный тип по magic bytes. Расширение может врать — file не врёт. - strings имя_файла | grep -i flag — ищет текстовые строки в бинарных файлах. Флаг часто зашит строковой константой внутри ELF-бинарника или PDF. - binwalk имя_файла — находит вложенные файлы. Стеганография (T1027.003): в PNG зашит ZIP-архив, внутри которого текстовый файл с флагом. binwalk -e извлечёт вложения автоматически.

Когда Export Objects не срабатывает

Если файл передан по нестандартному протоколу или фрагментирован — используйте Follow TCP Stream. В нижней части окна потока переключите Show data as на Raw и нажмите Save as.... Это сохранит сырой поток байтов, который затем разбирается через file и binwalk.

На одном из челленджей CyberDefenders я полчаса пытался достать файл через Export Objects, пока не догадался сохранить raw-поток вручную — binwalk нашёл в нём ELF-бинарник со вшитым флагом. Такие вещи не написаны ни в каком мануале, набиваешь руку на практике.

DNS Exfiltration: когда флаг спрятан в поддоменах

DNS-эксфильтрация (DNS, T1071.004) — один из самых хитрых приёмов в CTF среднего и продвинутого уровня. Данные кодируются и передаются как поддомены DNS-запросов: 68656c6c6f.evil.com, где 68656c6c6f — hex-строка слова «hello».

Признаки DNS-туннелирования в Wireshark: - Аномально длинные DNS-запросы (поддомены длиннее 30 символов) - Множество запросов типа TXT к одному домену - Поддомены из hex-символов (0-9a-f) или символов Base64 - Большое число DNS-запросов к одному нестандартному домену за короткий промежуток

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

Для извлечения данных tshark удобнее GUI:

tshark -r challenge.pcap -Y "dns.qry.type == 1" \
  -T fields -e dns.qry.name | sort -u

Результат — список всех DNS A-запросов. Если видите паттерн вроде 4354467b.evil.com, 646e735f.evil.com, 337866316c.evil.com, 7d.evil.com — склейте поддомены (без .evil.com) и декодируйте из hex. CyberChef, рецепт From Hex: 4354467b646e735f337866316c7d → CTF{dns_3xf1l} (пример для демонстрации концепции).

Для TXT-записей замените тип запроса на dns.qry.type == 16 и добавьте поле ответа -e dns.txt. TXT-записи вмещают больше данных и используются чаще в сложных заданиях.

TLS-дешифрование в CTF-заданиях

Если Protocol Hierarchy показывает 90%+ TLS и ни один из предыдущих методов не дал результата — перечитайте условие задачи внимательно. Иногда вместе с PCAP дают файл ключа: серверный RSA-ключ (.pem) или pre-master secret log. Файл может лежать в архиве задания или упоминаться в описании. Я пару раз терял на этом по 40 минут — ключ валялся в архиве, а я его не заметил.

Подключение pre-master secret log: Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename. Формат записей в файле: CLIENT_RANDOM <hex> <hex>. После подключения Wireshark расшифрует TLS-сессии, и вы увидите HTTP внутри — дальше работайте стандартными фильтрами.

Подключение серверного RSA-ключа: в том же разделе TLS, поле RSA keys list. Указываете IP сервера, порт (обычно 443), протокол (http) и путь к .pem-файлу.

А теперь ловушка, на которую попадаются многие. Серверный RSA-ключ работает, только если обмен ключами использует RSA без Perfect Forward Secrecy и версия протокола — TLS 1.2 или ниже. В TLS 1.3 RSA key exchange полностью исключён (RFC 8446), поэтому расшифровка серверным ключом невозможна в принципе. Если в TLS-handshake видите ECDHE или DHE — нужен pre-master secret log, серверный ключ не поможет. На CTF это частая ловушка: дают .pem, а handshake — ECDHE или TLS 1.3. Проверяйте версию TLS и поле Cipher Suite в Client Hello / Server Hello.

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

tshark — консольная версия Wireshark из того же дистрибутива. Незаменима в двух сценариях на CTF: обработка больших дампов (GUI тормозит на файлах >100 МБ) и быстрый поиск паттернов без запуска графического интерфейса.

# Все HTTP-запросы: метод, хост, URI
tshark -r file.pcap -Y "http.request" \
  -T fields -e http.request.method -e http.host -e http.request.uri

# Поиск строки "flag" во всём дампе (hex+ASCII дамп найденных пакетов)
# -x удобен для точечного просмотра одного-двух пакетов;
# при массовом поиске используйте -T fields -e frame.number
tshark -r file.pcap -Y 'frame contains "flag"' -x

# FTP-пароли
tshark -r file.pcap -Y 'ftp.request.command == "PASS"' \
  -T fields -e ftp.request.arg

# Статистика протоколов (аналог Protocol Hierarchy в консоли)
tshark -r file.pcap -q -z io,phs

Флаг -T fields -e поле извлекает конкретные значения — удобно для скриптования и пайпов. Результат можно передать в grep, sort -u, awk для дальнейшей обработки. Флаг -x показывает hex-дамп каждого пакета — полезно для ручного просмотра одного-двух найденных пакетов. При большом числе совпадений вывод становится избыточным; тогда лучше -T fields -e frame.number.

Decode As: нестандартные протоколы в дампе трафика

Иногда трафик идёт на нестандартном порту, и Wireshark не распознаёт протокол автоматически. HTTP-сервер на порту 8080, RTP-поток, замаскированный под неизвестный UDP, — типичная задача CTF среднего уровня.

Решение: правый клик на пакете → Decode As... → выбор протокола. После этого Wireshark пересобирает dissection и показывает данные структурированно. Организаторы CTF специально убирают стандартные порты, чтобы Export Objects и автоматические фильтры не работали из коробки.

Характерный сценарий: UDP-трафик с равномерной периодичностью и небольшими пакетами. Попробуйте Decode As → RTP. Если угадали — Telephony → RTP → RTP Streams покажет аудиопоток, который можно проиграть прямо в Wireshark. Флаг может быть произнесён голосом или закодирован в аудиосигнале (DTMF-тоны). Звучит безумно, но мне такое попадалось дважды.

Другой сценарий: TCP на нестандартном порту. Decode As → HTTP — и Export Objects → HTTP покажет файлы, которые до этого были невидимы.

Пошаговый алгоритм решения PCAP-задач на CTF

Всё описанное выше собирается в алгоритм, который работает на большинстве forensics-задач:

1. Быстрая проверка. frame contains "flag" или формат флага из задания. Закрывает 30-40% задач начального уровня.
2. Protocol Hierarchy. Statistics → Protocol Hierarchy. Какие незашифрованные протоколы есть?
3. Conversations. Statistics → Conversations. Аномалии по объёму, портам, количеству сессий.
4. Фильтрация по протоколам. В порядке: http → ftp → dns → smtp → telnet.
5. Follow TCP Stream. Для каждого подозрительного потока. Пароли, флаги, закодированные строки.
6. Export Objects. File → Export Objects → HTTP/SMB/TFTP. Извлечённые файлы → file, strings, binwalk.
7. DNS-анализ. Если Protocol Hierarchy показывает много DNS — проверяйте на exfiltration через поддомены.
8. TLS-дешифрование. Если в задании есть ключ — подключайте и повторяйте шаги 4-6.
9. Decode As. Нераспознанные потоки → ручное декодирование.

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

За несколько лет решения forensics-тасков на разных площадках у меня сложилось наблюдение (многим покажется спорным): 90% провалов на PCAP-задачах — не нехватка знаний о протоколах. Это пропуск первых пяти минут разведки. Человек открывает файл и ныряет в пакеты. Через полчаса — каша в голове и ноль результата. Protocol Hierarchy и Conversations — два окна, которые превращают хаотичный дамп в карту с пометкой «копать здесь». Но их игнорируют, потому что кажется, будто «настоящий анализ» — это hex-дампы и сложные regex-фильтры. На деле сложный фильтр нужен в одном случае из десяти. В остальных девяти — frame contains и Follow TCP Stream закрывают задачу.

Ещё одна проблема: люди заучивают фильтры, но не понимают, почему техника работает. FTP передаёт пароли открытым текстом — это не баг CTF, это архитектура протокола 1985 года. DNS-exfiltration эффективна, потому что DNS-трафик редко инспектируют — и на соревнованиях, и в реальной инфраструктуре. По данным CrowdStrike Global Threat Report 2025, 75% вторжений используют действительные учётные данные, и значительная часть этих кредов перехватывается именно через незашифрованные протоколы. Когда понимаешь «почему» — фильтры запоминаются сами, а на новых задачах не впадаешь в ступор.

Forensics на CTF — наименее «игровая» категория. Всё, что вы отрабатываете на PCAP-челленджах, один в один переносится в реальный incident response. Если хотите прокачать этот навык на практике — на HackerLab есть лабы с готовыми PCAP-дампами, где можно отработать полную цепочку от разведки до извлечения флага.

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