Wireshark для CTF: анализируем pcap-файл и находим флаг в сетевом трафике

Wireshark для CTF: анализируем pcap-файл и находим флаг в сетевом трафике

Последние два года я собираю pcap-задания для CTF и на каждом разборе наблюдаю одну картину: участники открывают файл и листают пакеты сверху вниз. На дампе в 50 тысяч пакетов это занимает полчаса и даёт ноль результата. А ведь Statistics → Protocol Hierarchy за десять секунд покажет, что 90% трафика — TLS, а флаг спрятан в оставшихся двух-трёх процентах открытого HTTP или DNS. Вся разница между нулём баллов и решённым таском — в порядке действий. Ниже — пошаговый алгоритм анализа pcap-файла в Wireshark, который работает на PicoCTF, CyberDefenders, HackTheBox и любой другой площадке.

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

Прежде чем разбирать pcap — убедитесь, что рабочее место собрано.

Минимальный набор:

• Wireshark 4.x — последняя стабильная версия с GUI, скачивается с wireshark.org. Windows, Linux, macOS. На Ubuntu/Debian ставится командой sudo apt install wireshark.
• tshark — консольный анализатор из того же дистрибутива, ставится автоматически вместе с GUI. На файле в 500 МБ GUI будет задыхаться, tshark отработает в потоке — для больших дампов и автоматизации он незаменим.
• CyberChef — веб-приложение для декодирования (Base64, hex, ROT13, XOR и ещё полсотни операций). Работает прямо в браузере, ставить ничего не нужно. Требуется на каждом втором CTF-задании.
• file, strings, grep — стандартные утилиты Linux. Для Windows — WSL или Cygwin. file определяет тип извлечённого файла по magic bytes (даже если расширение врёт), strings вытаскивает текстовые строки из бинарей, grep фильтрует результат.

Опционально:

• NetworkMiner — автоматически реконструирует файлы и учётные данные из pcap. Но на трафике с loopback-интерфейса работает криво — имейте в виду.
• tcpdump — перехват и грубая фильтрация в консоли. Для CTF нужен редко (файл уже записан), но иногда задания требуют снять собственный дамп.

RAM: для файлов до 100 МБ хватит 4 ГБ. Для дампов 500 МБ+ нужно 8–16 ГБ — Wireshark грузит pcap целиком в память. На машине с 4 ГБ переходите на tshark, он работает в потоковом режиме.

Первичная разведка pcap: Protocol Hierarchy и Conversations

Открыли файл — не трогайте список пакетов. Первые пять минут отдайте разведке. Цель: понять, какие протоколы использовались, кто с кем общался и где искать аномалии.

Protocol Hierarchy — карта трафика за 10 секунд

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

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

• Доля TLS/SSL. Если больше 80–90% — основная масса содержимого недоступна без ключа дешифрации. Копать нужно в оставшемся незашифрованном трафике.
• Присутствие HTTP. Даже 0.3% HTTP в дампе могут содержать флаг. Авторы CTF обожают прятать данные в единственном HTTP-запросе среди тонн TLS. В реальном разборе evidence.pcap с CyberDefenders-челленджа EscapeRoom именно 0.3% HTTP содержали всё интересное: User-Agent, POST-параметры, загруженные файлы.
• DNS. Если доля DNS-пакетов аномально велика (15–20% и выше) — это звоночек: DNS exfiltration, техника C2-канала (T1071.004), которая на практике используется и для вывода данных (T1048, Exfiltration Over Alternative Protocol). На CTF этот вектор эксплуатируют постоянно.
• Нестандартные протоколы. FTP, SMTP, Telnet — учётные данные летят в открытом виде. Классический случай OWASP A02:2021 (Cryptographic Failures): нет шифрования — credentials компрометируются.
• Data или Unknown. Трафик, который Wireshark не смог опознать. Часто за этим скрываются кастомные протоколы или данные на нестандартных портах — разбирать руками через Decode As.

Conversations и Endpoints — кто с кем разговаривает

Statistics → Conversations (вкладка TCP, сортировка по bytes) показывает все пары взаимодействующих хостов. Второй шаг разведки.

Что искать:

• Аномально «толстые» сессии. Одна TCP-сессия передала на порядок больше данных, чем остальные — берите её первой.
• Нестандартные порты. 4444 (Metasploit reverse shell), 8080 (прокси/отладочный сервер), 666, 1337 — классические CTF-маркеры. В разборе THM Wireshark CTF один из флагов прятался именно в TCP-потоке на порту 666.
• Множество коротких сессий от одного IP. Признак brute-force или сканирования портов. В EscapeRoom-разборе 52 коротких TCP-сессии с малым объёмом данных от сервера оказались неудачными попытками SSH-аутентификации (категория #22 SSH по AbuseIPDB), а две «толстых» сессии — успешными.
• Один внешний IP, инициирующий сотни соединений внутрь. Аномалия, которую стоит разобрать.

Statistics → Endpoints дополняет картину: по объёму трафика сразу выделяется «центральный» хост, вокруг которого строится сценарий задания.

Ещё полезная штука: Statistics → I/O Graphs визуализирует интенсивность трафика на временной шкале. Всплеск активности в конкретный момент — часто точка начала атаки или передачи данных. На CTF это помогает сузить временное окно для ручного анализа.

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

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

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

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

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

Фильтр	Что показывает
http	Весь HTTP-трафик
dns	DNS-запросы и ответы
ftp	FTP-сессии (credentials в открытом виде)
smtp	Электронная почта
tcp.port == 4444	Трафик на конкретном порту
ip.addr == 10.0.2.15	Все пакеты от/к конкретному IP
http.request.method == "POST"	POST-запросы (формы, credentials)
http.response.code == 200	Успешные HTTP-ответы
!dns && !arp	Убирает фоновый шум DNS/ARP

Фильтры комбинируются операторами: && (И), || (ИЛИ), ! (НЕ). Пример: http && ip.src == 10.0.2.15 покажет HTTP-трафик от конкретного хоста. Комбинация tcp.flags.syn == 1 && tcp.flags.ack == 0 отфильтрует только инициирующие SYN-пакеты — удобно, чтобы увидеть все попытки установления соединений и быстро найти интересный поток. В разборе see-through.pcapng четвёртый SYN-пакет привёл к потоку с флагом.

Поиск флага по содержимому пакетов

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

• frame contains "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]{10,}\\." выявит DNS-запросы с длинными hex-строками в поддоменах — типичный признак DNS exfiltration.

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

Ограничение: фильтры по содержимому работают только с незашифрованным трафиком. Если HTTP обёрнут в TLS, frame contains покажет нечитаемый мусор. Нужен ключ дешифрации — об этом ниже.

Follow Stream: восстанавливаем диалог между хостами

Follow TCP Stream — штука, без которой на CTF делать нечего. Она собирает все пакеты одной TCP-сессии в единый читаемый поток: красный текст — данные от клиента, синий — от сервера.

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

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

• FTP-сессии — команды USER и PASS лежат в plain text. В терминах MITRE ATT&CK — Network Sniffing (T1040, Credential Access): перехват учётных данных из незашифрованного трафика. По оценке IBM X-Force (2025), ежедневно в дарквебе появляется свыше 6 000 новых учётных записей — и сниффинг незашифрованных протоколов вроде FTP тут один из источников.
• HTTP POST — содержимое форм, credentials, загруженные файлы.
• Plaintext-команды — если атакующий использовал reverse shell без шифрования, в потоке видны все команды. Как на ладони.
• Закодированные строки — Base64-последовательности, hex, URL-encoding.

Про UDP — момент, который новички стабильно пропускают. Follow → UDP Stream — обязательный шаг. Авторы CTF этим пользуются: флаг или аудиоданные передаются по UDP на нестандартных портах. В разборе THM Wireshark CTF RTP-аудиопоток был замаскирован под неизвестный UDP-протокол на порту 1313. Решение: правый клик на пакете → Decode As → выбор протокола RTP — после чего Telephony → RTP → RTP Streams позволил проиграть аудио и услышать флаг.

Decode As вообще стоит держать в голове как спасательный круг: если Wireshark не распознаёт протокол на нестандартном порту — попробуйте принудительно назначить HTTP, FTP, RTP или другой ожидаемый протокол. Без этого приёма часть данных останется невидимой.

Декодирование payload: Base64, hex, ROT13 через CyberChef

Увидели в потоке строку вроде Q1RGe3cxcjNzaDRya30=? Base64. Копируете в CyberChef, рецепт From Base64 — результат: CTF{w1r3sh4rk}.

Основные кодировки на CTF:

Кодировка	Признаки	Пример
Base64	Символы A-Z, a-z, 0-9, +, /, завершается = или ==	Q1RGe30= → CTF{}
Hex	Символы 0-9, a-f, пары через пробел или без	43 54 46 7b → CTF{
ROT13	Визуально — обычный текст, но нечитаемый	PGS{synt} → CTF{flag}
URL-encoding	Символы %XX	%43%54%46 → CTF

Авторы CTF любят комбинировать кодировки: Base64 поверх ROT13 поверх Caesar с шифтом 3. CyberChef решает это элегантно — перетащите операции последовательно в цепочку рецептов, результат обновится автоматически.

Пример из THM Wireshark CTF. В первом задании Follow TCP Stream показывает Python-скрипт с тройной кодировкой (ROT13, Base64, Caesar cipher с шифтом 3). Переменная cnt в коде установлена в ? — замените на 50. Чтобы получить флаг, нужно реверсировать функции кодирования: b64encode заменить на b64decode, в Caesar-функции поменять шифт с 3 на -3, ROT13 оставить как есть (он симметричен). Без понимания порядка операций задание выглядит нерешаемым — с CyberChef и пониманием структуры скрипта решается за пять минут.

Извлечение файлов из pcap через Export Objects

Один из самых частых CTF-сценариев: флаг спрятан внутри изображения, PDF, архива или исполняемого файла, переданного по сети. По ATT&CK это пересечение Data from Local System (T1005) и Exfiltration Over C2 Channel (T1041) — атакующий собрал данные и передал по сети, а нам нужно их восстановить.

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

Алгоритм после извлечения:

1. Определить тип файла: file <filename>. Команда читает magic bytes — даже если расширение неправильное или отсутствует, реальный тип будет определён. В разборе EscapeRoom через Export Objects → HTTP были извлечены три файла — два ELF-бинарника и shell-скрипт, опознанных именно по magic bytes.
2. Поискать текстовые строки: strings <filename> | grep -i flag. Часто флаг валяется внутри бинарного файла как обычная строка.
3. Если файл — изображение, проверить метаданные через exiftool и стеганографию через steghide (для JPEG) или zsteg (для PNG). Пароль для стеганографии может быть найден в другом потоке того же pcap.
4. Если файл — архив, попробовать распаковать. Пароль к архиву — часто отдельный элемент CTF-задачи, спрятанный в HTTP-заголовке, DNS-запросе или FTP-сессии.

Когда Export Objects не работает. Если файл передан по нестандартному протоколу или фрагментирован нетипично — используйте Follow TCP Stream, переключите отображение на Raw, сохраните поток в файл и обрежьте заголовки протокола вручную. Метод грубый, но на CTF иногда единственный рабочий.

DNS exfiltration: как найти флаг в DNS-запросах

DNS exfiltration — техника, при которой данные кодируются в поддоменах DNS-запросов. Вместо обычного google.com запрос выглядит как 4354467b646e735f.evil.com, где hex-строка в поддомене — закодированный payload. По MITRE ATT&CK это DNS C2-канал (T1071.004) с эксфильтрацией через него (T1041), либо — если DNS используется как отдельный канал вывода — Exfiltration Over Alternative Protocol (T1048). Авторы CTF эксплуатируют этот вектор постоянно: DNS-трафик редко блокируется и почти никогда не шифруется в учебных сценариях.

Признаки DNS exfiltration в pcap:

• Аномально высокая доля DNS-пакетов в Protocol Hierarchy (15–20% и выше при отсутствии других объяснений)
• DNS-запросы с длинными поддоменами, содержащими hex или Base64-символы
• Множество TXT-записей — тип TXT часто используется для передачи данных обратно клиенту
• Запросы к одному и тому же домену с постоянно меняющимися поддоменами

Фильтры для обнаружения:

• dns.qry.name matches "^[a-f0-9]{10,}\\." — DNS-запросы с длинными hex-строками в поддоменах
• dns.qry.type == 16 — только TXT-записи
• dns.flags.response == 0 — только запросы, без ответов

После обнаружения подозрительных DNS-запросов нужно извлечь поддомены и склеить. Тут tshark эффективнее GUI:

tshark -r evidence.pcap -Y "dns.qry.name contains evil.com" \
  -T fields -e frame.number -e dns.qry.name | \
  sort -n | cut -f2 | awk -F. '{print $1}' | tr -d '\n'
# NB: sort -n по frame.number обязателен — без него порядок фрагментов
# может нарушиться из-за ретрансляций. Работает, только если payload
# помещается в первую метку поддомена.
# Для многометочных схем: awk -F. '{for(i=1;i<NF-1;i++) printf $i}'

Команда извлекает все DNS-запросы к домену, вырезает первый поддомен из каждого и склеивает результат. Полученную строку — в CyberChef: From Hex или From Base64 в зависимости от кодировки.

Предусловия: техника обнаружения работает, только если DNS-трафик не зашифрован (нет DoH/DoT). На CTF — почти всегда так. В реальных инцидентах DNS over HTTPS сделает этот подход бесполезным — потребуется перехват на уровне DNS-резолвера.

Расшифровка TLS-трафика в Wireshark

Если 90% трафика — TLS, а флаг передан по HTTPS — без ключа дешифрации не обойтись. На CTF авторы иногда дают ключ отдельным файлом.

Два формата ключей:

• Pre-master secret log — файл с записями CLIENT_RANDOM <hex> <hex>. Подключается через Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename. Работает с любым типом key exchange.
• Серверный приватный ключ — RSA private key в PEM. Подключается через Edit → Preferences → Protocols → TLS → RSA keys list. Работает только с RSA key exchange — не с ECDHE. Это важный момент.

После загрузки ключа Wireshark расшифровывает TLS-сессии автоматически. В Protocol Hierarchy появляются HTTP/2 или HTTP/1.1 внутри бывшего TLS — дальше стандартный разбор через фильтры и Follow Stream.

Где искать ключ в задании:

• Отдельный файл .key или .log в архиве с pcap
• Внутри самого pcap — ключ передан по SMTP или FTP (в THM Wireshark CTF CLIENT_RANDOM ключ лежал в email на порту 25)
• В описании задания — CLIENT_RANDOM строка вставлена прямо в текст условия

Ограничение: если использовался Ephemeral Diffie-Hellman (DHE/ECDHE) без pre-master secret log — серверный RSA-ключ бесполезен. Perfect Forward Secrecy делает ретроспективную расшифровку невозможной без логов сессии. На CTF это редкость, но в реальной сетевой криминалистике — стандартная головная боль.

Автоматизация анализа pcap с tshark

GUI Wireshark удобен для ручного разбора, но на больших дампах и при серийном решении задач tshark экономит десятки минут. Набор команд ниже покрывает 90% типовых сценариев network forensics CTF:

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

Каждая из этих команд заменяет несколько кликов в GUI и легко вставляется в bash-скрипт для пакетной обработки.

Когда tshark незаменим:

• Файл больше 200 МБ — GUI тормозит, tshark работает в потоке
• Нужно обработать серию pcap-файлов подряд (бывает на Jeopardy-CTF с цепочкой связанных заданий)
• Извлечение конкретных полей для дальнейшей обработки скриптом
• CI/CD-подобный workflow: скрипт, который прогоняет набор tshark-команд по свежему pcap и выдаёт сводку аномалий за секунды

Чеклист: алгоритм решения network forensics задач на CTF

Универсальный порядок действий, который покрывает абсолютное большинство заданий по поиску флага в pcap:

1. Прочитать условие задания. Формат флага, подсказки про протокол, количество флагов. Иногда условие прямо указывает: «данные exfiltrated через DNS» — это сэкономит двадцать минут.
2. Protocol Hierarchy. Определить, какие протоколы используются. Если 95% TLS — искать ключ или переключиться на оставшиеся 5%.
3. Conversations. Выделить ключевые пары хостов. Сортировка по bytes — «толстые» сессии первыми.
4. Грубый поиск. frame contains "flag", frame contains "CTF{", frame contains "key". На простых заданиях этого хватает.
5. Протокольные фильтры. http, dns, ftp, smtp — проверить каждый незашифрованный протокол.
6. Follow Stream. Для каждой подозрительной сессии. Проверять TCP и UDP — флаги в UDP-payload пропускают чаще всего.
7. Export Objects. Извлечь все переданные файлы. Проверить file + strings | grep -i flag.
8. DNS exfiltration. Если DNS-трафик аномален — извлечь поддомены через tshark, декодировать через CyberChef.
9. TLS-дешифрация. Если есть ключ — подключить и повторить шаги 4–7 для расшифрованного трафика.
10. Decode As. Для трафика на нестандартных портах — попробовать принудительно назначить протокол (HTTP, RTP, FTP).

Если после всех десяти шагов флаг не найден — возвращайтесь к Protocol Hierarchy и ищите протоколы, которые пропустили. На сложных CTF авторы используют Obfuscated Files or Information (T1027, Defense Evasion) и прячут данные в нестандартных местах: ICMP payload, TCP options, HTTP-заголовки с кастомными именами (X-Secret-Data), Cookie с Base64-значением. Отдельное внимание — пакетам с аномальным размером: если средний DNS-ответ 100 байт, а один — 1500, его стоит вскрыть первым.

Из опыта составления задач: половина участников застревает не на декодировании, а на этапе «куда смотреть». Protocol Hierarchy и Conversations — не просто полезные фичи Wireshark. Это разница между решённым заданием и пустым сабмитом. На отборочных я видел, как команды тратили 40 минут на прокрутку пакетов вручную, хотя три клика в меню Statistics показали бы, что весь интересный трафик сосредоточен в дюжине HTTP-пакетов.

Вторая типичная проблема — игнорирование UDP. На каждом третьем CTF, где я участвовал или готовил задания, флаг или его часть лежит в UDP-payload. Участники проверяют TCP, смотрят HTTP, разбирают DNS — и забывают, что Follow UDP Stream существует. Для RTP-потоков, замаскированных под «неизвестный протокол», без Decode As их вообще не увидеть.

Третий момент — tshark. GUI создаёт ложное чувство контроля: вот пакетики, вот фильтр, вот результат. На реальных соревнованиях, где дампы по 300–500 МБ и на решение отводится час, консольный tshark с правильными однострочниками работает в разы быстрее. Отработайте команды из этой статьи до автоматизма — на следующем CTF скажете спасибо. Если хочешь не просто читать writeup, а отрабатывать такие цепочки от pcap до эксплуатации — на WAPT эти техники разбирают в модулях с лабами.

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