Разбор PCAP-файлов в Wireshark: находим флаги в сетевом трафике на CTF

Разбор PCAP-файлов в Wireshark: находим флаги в сетевом трафике на CTF

На последнем CyberDefenders-челлендже по network forensics из 200 участников только 38 нашли второй флаг. Он был спрятан в поле данных ICMP-пакетов — побайтово раскиданный по echo-request'ам между двумя хостами. Остальные 162 человека остановились после strings evidence.pcap | grep flag и решили, что задание сломано. Wireshark стоял у всех. Проблема не в инструментах — проблема в методологии: без системного подхода к разбору PCAP файлов в Wireshark даже опытные CTF-игроки пропускают флаги, лежащие на расстоянии двух кликов.

Дальше — пошаговая методология анализа PCAP на CTF forensics, от первого открытия файла до извлечения флага из нестандартных каналов. Каждый приём — с конкретными фильтрами, командами и указанием, где он работает, а где бесполезен.

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

Прежде чем лезть в разбор сетевого трафика на CTF, проверьте минимальный стек:

• Wireshark 4.0+ (версии 3.x не поддерживают ряд современных диссекторов)
• tshark — ставится вместе с Wireshark, проверяется через tshark -v
• ОС: Linux (Kali/Parrot — всё предустановлено), macOS или Windows 10+
• RAM: минимум 4 ГБ свободной памяти — Wireshark грузит весь PCAP в оперативку. Файл на 500 МБ съест ~1.5 ГБ RAM
• Дополнительно: binwalk для поиска встроенных файлов, xxd или hex-редактор для ручного карвинга, CyberChef (веб или локальная версия) для декодирования цепочек кодировок

Если PCAP содержит TLS-трафик без сессионных ключей (SSLKEYLOGFILE) или RSA private key — расшифровать payload средствами Wireshark невозможно. На CTF это частая ситуация: ищите ключи в самом дампе или в условии задания.

Методология первичного анализа PCAP на CTF-задачах по forensics

Типичная ошибка новичков — открыть PCAP и начать листать пакеты сверху вниз. В дампе на 50 000 пакетов это гарантированная потеря времени. Начинать нужно с макро-анализа: понять, что вообще происходит в захвате, прежде чем копаться в деталях.

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

Первое действие после открытия файла: Statistics → Protocol Hierarchy. Таблица покажет процентное распределение протоколов по количеству пакетов и объёму данных.

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

• HTTP при доминировании TLS — если 95% трафика зашифровано, но есть 0.3% HTTP, именно туда автор задания спрятал что-то интересное. Незащищённые протоколы на фоне шифрованного трафика — первый приоритет
• DNS с аномально высоким процентом — нормальный DNS занимает 1-3% трафика. Видите 10%+ — высокая вероятность DNS-эксфильтрации (T1071.004 по MITRE ATT&CK)
• ICMP заметного объёма — ping-пакеты обычно минимальны. Если ICMP занимает существенную долю байт — данные могут быть спрятаны в payload (T1027.003, Steganography)
• Нестандартные протоколы — Wireshark показывает «Data» для нераспознанных протоколов. Это могут быть кастомные C2-каналы или сервисы на нестандартных портах (T1571, Non-Standard Port)

Работает если: PCAP не повреждён, содержит полные пакеты (snaplen достаточный). Не работает если: трафик захвачен с обрезкой (tcpdump -s 96) — Protocol Hierarchy покажет протоколы, но payload будет неполным.

Conversations и Endpoints — находим подозрительные узлы

Следующий шаг: Statistics → Conversations, вкладка TCP. Здесь видны все пары хостов и объём переданных данных между ними.

Ищите аномалии:

• Один хост общается со всеми — вероятный атакующий или C2-сервер
• Большой объём данных на нетипичном порту — 5 МБ на порту 4444 (стандартный Metasploit handler) или 8080
• Короткие сессии к множеству хостов — сканирование или разведка

Параллельно откройте Statistics → I/O Graphs — временная шкала покажет, когда была пиковая активность. На CTF авторы часто упаковывают «интересное» в короткий временной промежуток посреди фонового шума.

Фильтры Wireshark для форензики: от базовых к продвинутым

Display-фильтры — основной инструмент навигации по дампу. В отличие от capture-фильтров (BPF-синтаксис), display-фильтры работают постфактум и позволяют гибко комбинировать условия.

Protocol и field-based фильтры

Базовые фильтры, которые стоит вводить первыми на любом CTF:

• http — весь HTTP-трафик, включая запросы и ответы
• dns — DNS-запросы и ответы
• ftp || ftp-data — FTP-управление и файловые потоки
• smtp || pop || imap — почтовые протоколы
• tcp.port == 4444 — конкретный порт (подставляйте подозрительные из Conversations)
• ip.addr == 10.0.2.15 — фильтр по конкретному IP

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

Field-based фильтры для точечного поиска:

• http.request.method == "POST" — только POST-запросы (формы логина, загрузка файлов)
• http.response.code == 200 — успешные ответы
• dns.qry.name contains "evil" — DNS-запросы к доменам с подстрокой
• tcp.flags.syn == 1 && tcp.flags.ack == 0 — SYN без ACK (начало соединений, полезно для обнаружения сканирования)

Поиск по содержимому: contains и matches

Когда формат флага известен (например, CTF{...} или flag{...}), прямой поиск по payload экономит часы:

• frame contains "flag" — поиск строки «flag» в любом месте любого пакета
• tcp contains "CTF{" — поиск в TCP-сегментах
• http contains "password" — пароли в HTTP-трафике

Для регулярных выражений — matches: фильтр frame matches "flag\{[a-zA-Z0-9_]+\}" найдёт строки вида flag{any_content} в любом протоколе.

contains и matches работают по сырым байтам пакета. Если флаг закодирован в Base64 или XOR — фильтр его не найдёт. Тут придётся декодировать руками (об этом ниже).

Работает если: данные передаются в открытом виде — HTTP, FTP, Telnet, SMTP без STARTTLS. Не работает если: payload зашифрован (TLS, SSH) или закодирован (Base64, hex, кастомный XOR).

Follow TCP Stream в Wireshark — восстановление сессий

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

Plaintext-протоколы: FTP, HTTP, SMTP

В CTF-тасках по forensics авторы часто закладывают флаги в сессиях plaintext-протоколов:

FTP — Follow TCP Stream на порту 21 покажет логин/пароль в открытом виде (команды USER и PASS). Но файлы передаются по отдельному data-соединению (порт 20 или пассивный порт). Нужно отследить оба потока: управляющий (порт 21) расскажет, какой файл запрашивался, а data-поток (ищите через Conversations по паре хостов на нестандартном порту) содержит сам файл.

HTTP — POST-запросы с формами логина, загрузка файлов через multipart/form-data, ответы с cookies. Фильтр http.request.method == "POST" → Follow TCP Stream покажет отправленные данные, включая пароли и токены.

SMTP — электронная почта в открытом виде. Follow TCP Stream покажет заголовки From/To/Subject и тело письма. Вложения передаются в Base64 — Wireshark декодирует их при экспорте объектов, но в Follow Stream они видны в кодированном виде.

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

Внизу окна Follow TCP Stream есть выпадающий список формата отображения: ASCII, EBCDIC, Hex Dump, C Arrays, Raw, UTF-8. Переключение на Hex Dump полезно, когда ASCII-представление показывает «мусор» — это может быть бинарный файл или закодированные данные.

Если в ASCII-потоке видна строка типа Q1RGe3cxcjNzaDRya19tNHN0M3J9 — это Base64. Декодируется прямо в терминале:

echo "Q1RGe3cxcjNzaDRya19tNHN0M3J9" | base64 -d

Стандартное кодирование (T1132.001 по MITRE ATT&CK) — одна из самых частых техник на CTF forensics.

Более сложный случай — нестандартное кодирование (T1132.002): hex-строки, ROT13, XOR с однобайтовым ключом. CyberChef с функцией Magic автоматически определяет тип кодировки и предлагает цепочку декодирования. На практике Magic справляется с 3-4 вложенными слоями без проблем, дальше — уже руками.

Извлечение файлов из PCAP в Wireshark

Передача файлов через сеть — стандартный сценарий CTF-тасков. Wireshark умеет извлекать файлы из нескольких протоколов автоматически.

Export Objects для HTTP, SMB, TFTP

File → Export Objects → HTTP — покажет все файлы, переданные через HTTP: изображения, документы, скрипты, архивы. Каждый объект можно сохранить отдельно или все сразу через «Save All».

Аналогично работает экспорт для SMB (файлы по Windows-шарам), TFTP (часто встречается в сетевом оборудовании) и IMF (Internet Message Format — вложения из email).

Работает если: файл передан целиком в рамках захвата, протокол поддерживается диссектором Wireshark. Не работает если: передача прервана (неполный захват), файл передан через нестандартный протокол или разбит на фрагменты в кастомном формате.

Ручное извлечение через raw data

Когда Export Objects не находит ничего — переключаемся на ручной карвинг:

1. Найдите подозрительный поток через Follow TCP Stream
2. Переключите формат на Raw и сохраните в файл (кнопка «Save as...»)
3. Проверьте через file extracted_data — утилита определит тип по magic bytes
4. Если file показывает «data» — запустите binwalk extracted_data для поиска вложенных файлов (ZIP-архивы, изображения, ELF-бинарники внутри потока)

Типичный CTF-сценарий: в HTTP-ответе передаётся PNG-изображение, внутри которого через binwalk обнаруживается ZIP-архив с текстовым файлом, содержащим флаг. Матрёшка — характерный приём авторов заданий.

Анализ DNS-эксфильтрации в сетевом трафике CTF

DNS-эксфильтрация (T1071.004, T1041 по MITRE ATT&CK) — один из самых популярных скрытых каналов в CTF-тасках. Данные кодируются в поддоменах DNS-запросов, а ответы могут содержать полезную нагрузку в TXT-записях.

Подозрительные DNS-запросы

Фильтр dns в Wireshark покажет все запросы. Признаки эксфильтрации:

• Длинные поддомены — запросы вида 6162636465666768.evil.com, где поддомен — hex-кодированные данные
• Высокая частота — десятки запросов к одному домену за секунды
• TXT-записи — запросы типа TXT нетипичны для обычного веб-сёрфинга. Фильтр: dns.qry.type == 16
• Необычные домены — рандомные строки в именах

Для быстрого обзора всех запрашиваемых доменов — Statistics → DNS. Таблица покажет все уникальные имена и количество запросов к каждому.

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

Когда подозрительные запросы найдены, данные нужно собрать и декодировать. Тут tshark незаменим — извлечёт все имена запросов одной командой:

tshark -r evidence.pcap -Y "dns.qry.name contains evil.com" \
  -T fields -e dns.qry.name | \
  cut -d'.' -f1 | tr -d '\n' | xxd -r -p

Цепочка извлекает поддомены, обрезает базовый домен, склеивает части и декодирует hex в ASCII. Если данные закодированы в Base64 вместо hex — замените xxd -r -p на base64 -d.

Если DNS-запросы идут через DNS-over-HTTPS (DoH) или DNS-over-TLS (DoT), Wireshark покажет их как обычный HTTPS/TLS-трафик. Без сессионных ключей содержимое запросов недоступно. На CTF это пока редкость, но в заданиях повышенной сложности уже встречается.

Стеганография в протоколах: ICMP, HTTP-заголовки, нестандартные порты

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

ICMP data field — стандартный ping (echo-request/echo-reply) содержит поле данных, куда по RFC можно записать произвольные байты. В Wireshark: фильтр icmp, затем в панели деталей разверните Internet Control Message Protocol → Data. Если вместо стандартного паттерна (алфавит или нули) видите осмысленные ASCII-символы или Base64 — данные спрятаны побайтово в последовательных пакетах. Что-то подобное делает, кстати, обычный PING — достаёт клиентов своими ICMP-эхо-запросами, только тут payload с сюрпризом.

Извлечение через tshark: tshark -r file.pcap -Y "icmp.type == 8" -T fields -e data.data выведет hex-содержимое data-поля всех echo-request. Склейте и декодируйте через xxd -r -p.

HTTP-заголовки — кастомные заголовки вроде X-Flag, X-Secret или данные, спрятанные в Cookie, User-Agent, Referer. Фильтр http.request → просмотрите заголовки каждого запроса в панели деталей. Нетипично длинный User-Agent со случайными символами — повод для проверки.

Нестандартные порты — сервис на порту 31337, 1337 или любом другом «элитном» порту. Wireshark может не распознать протокол и покажет «TCP» или «Data». Follow TCP Stream на таком потоке часто раскрывает кастомный plaintext-протокол с командами и ответами, где спрятан флаг.

Работает если: авторы не применили дополнительное шифрование поверх стеганографии. Не работает если: данные в ICMP/заголовках зашифрованы XOR с ключом, который нужно найти в другом месте дампа — это многоступенчатые задания, требующие полного анализа всего трафика.

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

GUI Wireshark удобен для ручного анализа, но на CTF время ограничено. tshark позволяет автоматизировать рутину и обрабатывать большие дампы за секунды. Я пришёл к тому, что без tshark и скриптовой обвязки на соревновании с ограниченным временем вы проиграете тому, кто автоматизировал.

Быстрый поиск строки во всём дампе (аналог strings | grep, но с контекстом пакета):

tshark -r evidence.pcap -Y 'frame contains "flag"' \
  -T fields -e frame.number -e ip.src -e ip.dst -e tcp.port

Покажет номер пакета, источник, назначение и порт для каждого пакета со строкой «flag». Дальше открываете этот пакет в Wireshark по номеру: Go → Go to Packet.

Извлечение всех URL из HTTP-трафика: tshark -r file.pcap -Y "http.request" -T fields -e http.host -e http.request.uri. Подозрительные пути (/upload, /admin, /shell.php) сразу бросаются в глаза.

Извлечение credentials из FTP: tshark -r file.pcap -Y "ftp.request.command == USER || ftp.request.command == PASS" -T fields -e ftp.request.arg. Все логины и пароли из FTP-сессий — одной строкой.

tshark использует те же диссекторы, что и Wireshark. Если протокол нестандартный и не распознан — tshark не сможет извлечь поля. Тогда работайте с raw-данными: tshark -r file.pcap -Y "tcp.port == 31337" -T fields -e tcp.payload выведет hex-payload, который далее декодируется через xxd -r -p.

Типичные ловушки в CTF-тасках по network forensics

За несколько сотен разобранных CTF-тасков по network forensics выкристаллизовались паттерны, на которые попадаются даже опытные игроки:

Red herrings — авторы намеренно оставляют «очевидные» находки, чтобы отвлечь от реального флага. Классика: в HTTP-трафике лежит файл flag.txt с текстом «Not so easy!», а настоящий флаг — в DNS TXT-записях. Если флаг нашёлся слишком быстро на задании средней или высокой сложности — не расслабляйтесь, продолжайте копать.

Множественные слои кодирования — флаг закодирован Base64, результат закодирован в hex, результат вставлен в Cookie-заголовок HTTP-запроса. CyberChef с режимом Magic раскрывает до 10 вложенных уровней автоматически. Руками — декодируйте послойно, проверяя результат каждого шага на читаемость.

Фрагментированные данные — флаг разбит на части, каждая часть в отдельном пакете (часто ICMP) или в отдельном DNS-запросе. Без tshark-автоматизации собрать 50 фрагментов вручную — мучительно.

Ключи шифрования внутри дампа — если значительная часть трафика зашифрована TLS, проверьте: нет ли в HTTP-трафике файла с расширением .key, .pem или sslkeylog.txt. Авторы CTF-заданий иногда «случайно» оставляют ключи в незашифрованной сессии. Импортируйте найденный ключ через Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename — и зашифрованный трафик станет читаемым.

Ложная атрибуция протоколов — HTTP-сервер на порту 53 (стандартный DNS) или DNS-туннель на порту 80. Wireshark привязывает диссектор к порту по умолчанию и может неправильно интерпретировать трафик. Если содержимое выглядит некорректно для заявленного протокола — правый клик → Decode As... → выберите правильный диссектор вручную.

Методология, которая стабильно работает на forensics CTF любого уровня, укладывается в четыре этапа: макро-анализ (Protocol Hierarchy, Conversations, I/O Graphs) → фильтрация подозрительного (display filters по протоколам и содержимому) → глубокий разбор потоков (Follow TCP/UDP Stream, Export Objects) → декодирование и сборка (tshark, CyberChef, binwalk). Пропуск любого этапа — потеря флагов.

80% тасков по network forensics решаются одними и теми же пятью приёмами: Protocol Hierarchy → frame contains → Follow TCP Stream → Export Objects → tshark-скриптинг. Оставшиеся 20% — задания, где авторы комбинируют стеганографию в ICMP с DNS-эксфильтрацией и многослойным кодированием, и именно на них отсеиваются участники. Главная ошибка тех, кто застревает — они ищут флаг, а не историю. PCAP — это запись инцидента с началом, серединой и концом. Восстановите цепочку действий атакующего целиком (разведка → эксплуатация → эксфильтрация), и флаг обычно обнаруживается на этапе эксфильтрации как естественный артефакт, а не как «пасхалка». Вкладывайте время в изучение tshark-фильтров — это окупается на каждом следующем CTF. На WAPT эту связку сетевого анализа и практических лаб проходят в рамках модулей по сетевой разведке — если идёте к OSCP, это закрывает именно ту часть, которая на экзамене проверяется через пакетный анализ.

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