Что вас ждёт в статье:
1. Введение: Network Forensics
1.1. Описание Challenge
1.2. Инструменты: Wireshark, tshark, NetworkMiner
2. Первичный анализ
2.1. Protocol Hierarchy
2.2. Conversations и Endpoints
2.3. I/O Graphs
3. Display Filters
3.1. Protocol filters
3.2. Field-based filters
3.3. Regex и contains
4. HTTP Analysis
4.1. Request/Response pairs
4.2. POST data extraction
4.3. Cookie и session analysis
5. DNS Analysis
5.1. Query logging
5.2. DNS exfiltration: TXT records
5.3. Suspicious domains
6. TCP Stream Follow
6.1. Восстановление сессий
6.2. Plaintext protocol analysis
7. File Extraction
7.1. HTTP Export Objects
7.2. SMB и TFTP transfers
8. Credential Hunting
8.1. FTP, HTTP Basic, SMTP
8.2. Извлечение флага
1. Введение: Network Forensics
Когда мы говорим о цифровой криминалистике, многие представляют себе восстановление удаленных файлов с жестких дисков или подбор паролей к зашифрованным архивам. Люди, более погружённые в правовой контекст, подразумевают под этим словом определенное должностное лицо, занимающее своё место в государственной машине.На деле же всё куда интереснее!
Форензика - это крайне разносторонняя дисциплина, азы которой должен понимать каждый специалист в ИБ.
В этой статье мы разберём особое, наиболее понятное сетевикам направление этой науки, имя которому - Network Forensics.
В отличие от анализа статических данных, сетевой DFIR работает с цифровым эхом. Каждый пакет, пролетающий через интерфейс, оставляет след. И если злоумышленник может почистить логи на сервере или удалить вредоносный файл после выполнения задачи, то изменить уже записанный сетевой трафик (pcap-файл) он не в силах.
В целом, можно сказать, что это попытка восстановить историю преступления по косвенным признакам.
Это работа для скурпулёзных энтузиастов, кто любит детали и готов часами копаться в байтах, чтобы понять, как именно крепость была взята изнутри, реконструируя само время, шаг за шагом восстанавливая цепочку событий, которые привели к инциденту.
В статье я постарался подать материал по обзору инструментария специалиста в наиболее привычном CTF формате, документируя каждое действие.
1.1. Описание Challenge
Нам в распоряжение передан некий evidence.pcap, который нам, как специалистам, предстоит препарировать.Задача стоит следующая:
Найти главный флаг, который станет доказательством компрометации системы в формате CTF{w1r3sh4rk}.
Ну да в хорошем испытании всегда есть второе дно. Помимо основной цели, в дампе имеется скрытый пасхальный флаг. Это может быть секретная строка, переданная через нестандартные протоколы или скрытые каналы связи. Найти его будет сложнее и интереснее.
Нам предстоит выяснить, как атакующий проводил атаку, какие файлы пытался вытащить и удалось ли ему в итоге закрепиться в системе. Весь интерес в том, что трафик был записан на локальном интерфейсе, а значит, что мы увидим взаимодействие внутренних сервисов системы без лишних сетевых помех.
1.2. Инструменты: Wireshark, tshark, NetworkMiner
Центральным элементом нашей лаборатории является Wireshark - стандарт индустрии в области анализа сетевых протоколов. Его основное преимущество заключается в глубокой инспекции пакетов, которая позволяет детально разобрать каждый уровень модели OSI.В контексте форензики Wireshark незаменим для ручной верификации аномалий, анализа временных меток и восстановления логики взаимодействия между узлами. Он способен интерпретировать сотни протоколов, предоставляя аналитику структурированный вид данных, которые в сыром виде представляли бы собой лишь нечитаемую последовательность байтов.
В дополнение к графическому интерфейсу используется tshark - консольный анализатор, входящий в состав дистрибутива Wireshark. В профессиональной среде tshark применяется для задач, требующих высокой скорости обработки и автоматизации. Он позволяет извлекать конкретные поля данных (например, только значения DNS-запросов или параметры HTTP-заголовков) напрямую из pcap-файла, минуя ресурсозатратную отрисовку GUI. Через tshark в рамках рассматриваемой лабы я и делал сам сетевой дамп evidence.pcap.
Завершает инструментальный стек NetworkMiner - специализированное средство для сетевой криминалистики. В отличие от Wireshark, который ориентирован на пакеты, NetworkMiner фокусируется на хостах и передаваемом контенте. Инструмент в автоматическом режиме реконструирует файлы, изображения и учетные данные, передаваемые в открытом виде.
В нашем случае, при работе с трафиком, перехваченным на интерфейсе loopback он будет бесполезен, тем более, что в рамках статьи, рассматриваем в большей степени сам Wireshark.
Ну что-же, с основами разобрались, берёмся за практику!
2. Первичный анализ
После того как файл evidence.pcap был открыт в анализаторе, первым делом необходимо отойти от микроскопического изучения отдельных пакетов и взглянуть на ситуацию в целом на главной странице WireShark:
Первичный анализ важен, потому что именно здесь мы определяем, на какие участки дампа стоит потратить время, а какие можно классифицировать как фоновый шум. Мы начинаем с построения общей картины сетевой активности, чтобы выявить аномалии в структуре протоколов, составе участников и временных интервалах активности.
2.1. Protocol Hierarchy
Первым на что обращаем внимание в нашем расследовании становится окно иерархии протоколов, которое позволяет мгновенно оценить распределение трафика. На представленном ниже скриншоте видно, что весь захваченный трафик базируется на протоколе IPv4, инкапсулированном через специфический для Linux интерфейсов механизм Linux cooked-mode capture. Общий объем данных составляет примерно 1.77 МБ.
Изображение показывает, что подавляющую часть трафика (около 88.4% по количеству пакетов и 93.3% по объему данных) составляет протокол TCP. Внутри него доминирует TLS (Transport Layer Security), на долю которого приходится 91.1% всех переданных байт. Это говорит о том, что большая часть коммуникаций зашифрована, что является стандартом для современного веба, но значительно усложняет задачу криминалиста. Тем не менее, наше внимание привлекает присутствие протокола DNS (11.6% пакетов) и небольшого, но критически важного сегмента HTTP трафика (0.3%). Именно эти незащищенные или служебные протоколы зачастую становятся ахиллесовой пятой атакующего, так как именно в них могут скрываться незашифрованные команды управления или утечки конфиденциальных данных в открытом виде, таких как формы логина или текстовые данные.
2.2. Conversations и Endpoints
Определив, какие протоколы использовались, мы переходим к анализу действующих лиц. Окно Conversations позволяет визуализировать все активные сессии между узлами. На скриншоте ниже представлена вкладка отсортированных TCP-соединений, где зафиксировано 26 уникальных сетевых разговоров:
Центральной фигурой расследования становится внутренний IP-адрес 10.0.2.15, который инициирует большинство соединений. Мы видим его активное взаимодействие с внешними адресами, такими как 149.154.167.99 (telegram если память не изменяет) и 104.18.26.120 (Cloudflare). Последний адрес особенно интересен, так как именно с ним установлена сессия на 80-й порт (HTTP), в то время как большинство остальных соединений используют стандартный защищенный порт 443. Анализ эндпоинтов помогает нам сузить круг подозреваемых. ведь если большая часть трафика идет на известные доверенные ресурсы, то редкие обращения к специфическим внешним IP по незащищенным протоколам мгновенно попадают в категорию высокого риска.
2.3. I/O Graphs
Финальным штрихом первичного анализа является визуализация интенсивности трафика на временной шкале. Использование графиков ввода-вывода (I/O Graphs) позволяет нам увидеть динамику инцидента. На графике четко прослеживается хронология событий на протяжении минуты записи:
Большую часть времени сетевая активность остается умеренной, не превышая 100–200 пакетов в секунду, однако на отметке в 35 секунд мы наблюдаем колоссальный всплеск, достигающий почти 1000 пакетов в секунду. В контексте сетевой безопасности такие резкие пики редко бывают случайными. Это может быть моментом активной фазы эксфильтрации данных, загрузкой крупного вредоносного модуля или результатом работы автоматизированного сканера. Сопоставляя этот временной интервал с нашими данными из анализа протоколов, мы можем с высокой долей уверенности предположить, что именно в этот период произошли ключевые события нашего Challenge. Наличие нескольких более мелких всплесков (на 3-й, 30-й и 48-й секундах) также требует внимания, так как они могут представлять собой фазы подготовки или закрепления атакующего в системе. В целом, нужно исследовать каждый из заметных всплесков активности.
Далее мы перейдем к активному использованию поискового движка Wireshark, чтобы отсеять лишнее и сфокусироваться исключительно на подозрительных пакетах.
3. Display Filters
Работа с сырым дампом трафика напоминает поиск иголки в стоге сена.Система фильтров отображения Wireshark позволяет радикально изменить подход к анализу, превращая хаотичный поток байтов в структурированную последовательность событий.
На этом этапе мы переходим от пассивного наблюдения к активному поиску, используя логические операторы и специфические поля протоколов для сужения области расследования.
3.1. Protocol filters
Самый простой метод - фильтрация по протоколу. Вводя имя протокола в строку фильтра, мы мгновенно изолируем весь связанный с ним трафик. В нашем случае критически важными оказались два протокола: HTTP и DNS:
Применение фильтра dns открывает перед нами массив из 298 пакетов. На скриншоте отчетливо видны следы заражения малварём, ведь помимо стандартных запросов к google.com, фиксируются обращения к доменам update-malware-server.net и attacker-c2.com. Обратили на это внимание, зафиксировали, двигаемся дальше, этот материал нам понадобится в далее.
На этом же скриншоте видно применение фильтра http. Несмотря на то, что иерархия протоколов показывала ничтожно малый процент этого трафика, после фильтрации перед нами открывается четкая последовательность - POST-запрос на /api/login, за которым следуют переходы на /dashboard и поисковые запросы. Аналогично, использование фильтра dns позволяет изолировать огромный массив запросов, среди которых сразу выделяются аномально длинные доменные имена, не характерные для обычного веб-серфинга. Это первый уровень очистки данных, который позволяет подтвердить или опровергнуть первоначальные гипотезы.
3.2. Field-based filters
Когда мы определили интересующий нас протокол, следующим шагом становится фильтрация по конкретным полям внутри него. Это позволяет искать не просто какой-то HTTP, а конкретные действия. Одним из наиболее информативных фильтров в нашем случае является http.request.method == "POST".
Этот фильтр оставляет в окне пакетов только те сообщения, в которых клиент передает данные на сервер. В нашем дампе такой пакет всего один - №20. Он становится «точкой невозврата в расследовании, именно в нем зафиксирована попытка авторизации на ресурсе 104.18.26.120. Использование операторов сравнения (==, !=, >, <) в сочетании с именами полей (например, tcp.port == 80 или ip.src == 10.0.2.15) превращает Wireshark в мощный поисковый движок, способный мгновенно находить искомые строки записи.
3.3. Regex и contains
Иногда аналитику заранее известно, что именно он ищет, например, часть флага или специфическое ключевое слово. В таких ситуациях на помощь приходит оператор contains, который ищет заданную последовательность байтов или символов во всем теле пакета.
Применение фильтра frame contains "CTF" мгновенно приводит нас к пакету №20, который мы уже идентифицировали ранее. В окне деталей пакета, в секции HTML Form URL Encoded, мы видим результат: значение поля session_token содержит искомую строку CTF{w1r3sh4rk_d3t3ct1v3}. Это классический пример того, как знание паттерна позволяет заметно сократить время анализа!
Однако современные угрозы часто требуют более гибкого подхода. Для этого Wireshark поддерживает оператор matches, позволяющий использовать регулярные выражения (Regex). Например, фильтр «frame matches "CTF\{.*\}"» найдет любую строку, подходящую под формат флага, даже если мы не знаем его точного содержимого. Это позволяет находить замаскированные данные (номера карт, пароли или токены) по их структуре.
4. HTTP Analysis
Анализ HTTP-трафика - это фактически чтение своеобразной переписки между узлами. В нашем дампе evidence.pcap на этот протокол приходится всего 0.3% пакетов, однако их информационная плотность критически высока. Мы переходим от анализа сетевых узлов к восстановлению логики работы веб-приложения и выявлению попыток манипуляции данными.4.1. Request/Response pairs
Wireshark обладает мощным механизмом отслеживания состояний, который позволяет связывать запросы (Requests) с соответствующими им ответами (Responses). Это превращает разрозненный поток пакетов в связный диалог.
На скриншоте мы видим исходящий POST-запрос от узла 10.0.2.15 к серверу на эндпоинт /api/login. Сразу за ним следует кадр, содержащий ответ сервера: HTTP/1.1 405 Not Allowed. В форензике статус 405 является важным индикатором, он означает, что запрашиваемый метод (в данном случае POST) запрещен для этого ресурса. Это может указывать на то, что атакующий использует автоматизированные инструменты подбора (fuzzing) или пытается применить метод к API-эндпоинту, который ожидает только GET-запросы. Такая неудача атакующего дает нам ценный контекст: злоумышленник прощупывает почву, пытаясь найти рабочие точки входа.
4.2. POST data extraction
В отличие от GET-запросов, где параметры передаются прямо в URL, POST-запросы скрывают полезную нагрузку в теле пакета. Wireshark автоматически парсит структуру данных, если они переданы в стандартных форматах, таких как application/x-www-form-urlencoded.
Здесь мы проводим анализ тела запроса. Раскрыв секцию HTML Form URL Encoded, мы обнаруживаем следующие параметры:
- user=admin: подтверждает попытку компрометации именно привилегированной учетной записи.
- action=upload: указывает на намерение злоумышленника загрузить файл (возможно, веб-шелл) на сервер.
- session_token=CTF{w1r3sh4rk_d3t3ct1v3}: ключевая улика, представляющая собой флаг.
4.3. Cookie и session analysis
После неудачной попытки на /api/login атакующий меняет тактику и переходит к исследованию других разделов сайта.
На этом снимке мы фиксируем GET-запрос к странице /dashboard. Здесь в игру вступают HTTP Cookies - основной механизм поддержания состояния сессии в вебе.
При изучении заголовка Cookie мы видим две пары ключ-значение:
- session_id=987654321ABCDEF: уникальный идентификатор сессии.
- user_role=superuser: критическая аномалия.
Однако само наличие таких куки в дампе для нас является важными, ведь оно указывает на вектор атаки через манипуляцию сессиями.
5. DNS Analysis
Анализ DNS-трафика в рамках сетевой форензики - это полноценное исследование инфраструктуры, которую атакующий использует для управления скомпрометированным узлом. DNS аналитика это один из самых опасных и, к сожалению, часто недооцененных векторов атаки. Основная проблема заключается в том, что трафик по 53 порту UDP почти всегда разрешен в корпоративных сетях по умолчанию для обеспечения нормальной работы веб-браузеров. Злоумышленники прекрасно об этом знают и превращают служебные запросы в идеальный скрытый транспорт для обхода систем обнаружения вторжений (IDS/IPS). В нашем дампе evidence.pcap на долю DNS-пакетов приходится аномально высокая часть - 11.6% от общего объема трафика. Для короткой сессии, записанной на локальном интерфейсе, такая плотность запросов является кричащим индикатором, где либо система поражена вредоносным ПО с агрессивным поиском командного сервера, либо мы столкнулись с использованием специализированных инструментов для скрытной передачи данных.5.1. Query logging
Процесс полноценного расследования всегда начинается с детального логирования и изучения хронологии запросов, что позволяет нам буквально по секундам восстановить цифровой след злоумышленника.Изолировав DNS-пакеты с помощью фильтров отображения, мы получаем возможность увидеть эволюцию инцидента. В начальной фазе дампа (пакеты №9–16) активность узла не вызывает подозрений. Фиксируются стандартные запросы к google.com и легитимным сервисам обновлений. Однако ситуация кардинально меняется:
С этой отметки начинаются цикличные, методичные обращения к домену attacker-c2.com. В индустрии ИБ такой паттерн называют Beaconing (подача сигналов маяка). Вредоносная программа с жестко заданным интервалом простукивает свой управляющий сервер, проверяя, не поступило ли новых команд. Это ключевой момент для DFIR специалиста. Зафиксировав время первого такого запроса, мы можем точно определить момент перехода атаки из стадии разведки в стадию активного управления и контроля.
5.2. DNS exfiltration: TXT records
Этот этап анализа оказался наиболее результативным, раскрыв основной метод похищения информации, использованный в данном Challenge. В то время как обычные пользователи запрашивают IP-адреса (тип A), атакующий обратился к гораздо более гибкому инструменту - типу TXT. Особенность TXT-записей в том, что они позволяют передавать произвольные текстовые строки, и именно этим воспользовался злоумышленник для организации скрытого канала.
Здесь наше внимание приковывает запрос к поддомену 746f705f7365637265745f666c6167.attacker-c2.com. На первый взгляд это выглядит как случайный набор символов, но опытный криминалист сразу определит, что это классическая шестнадцатеричная Hex строка.
Атакующему вовсе не нужно, чтобы этот домен существовал на самом деле. Ему достаточно того, что запрос пройдет через всю цепочку мировых DNS-серверов и в конечном итоге попадет на его собственный авторитетный сервер, который просто сохранит имя запрашиваемого поддомена в свои логи. Таким образом, данные покидают периметр сети, не устанавливая прямого соединения с сервером злоумышленника.
Рассмотрим более детально эту подозрительную строку:
Бинго!
Декодировав её в терминале с помощью команды xxd -r -p, мы мгновенно получили скрытый текст: top_secret_flag. Вот мы и нашли пасхальный флаг!
Пример наглядно демонстрирует, как критически важные секреты могут утекать из сети прямо под носом аналитиков, замаскированные под рутинный служебный шум, который большинство систем мониторинга просто игнорирует.
5.3. Suspicious domains
Завершая разбор DNS-сегмента, мы провели анализ доменов, которые не удалось успешно разрешить, что дало нам дополнительные зацепки относительно природы угрозы. Используя фильтры по содержимому, мы обнаружили серию безуспешных попыток узла связаться с ресурсами, названия которых не оставляют сомнений в их предназначении, например, malware-update-server.net.
На скриншоте (пакеты №88–99) отчетливо видны ответы сервера с кодом ошибки "No such name" . В контексте безопасности это часто свидетельствует о работе алгоритмов генерации доменов. Вредонос по заранее заложенной формуле генерирует сотни имен в день, надеясь, что хотя бы одно из них в данный момент зарегистрировано атакующим. Кроме того, зафиксированные запросы с суффиксом .lan (например, malware-update-server.net.lan) прямо указывают на попытки поиска ресурсов внутри локальной сети. Это подтверждает худшие опасения о том, что злоумышленник планировал не ограничиваться одним узлом, а проводил разведку для дальнейшего горизонтального перемещения по инфраструктуре.
6. TCP Stream Follow
Работа с отдельными пакетами в Wireshark дает глубокое понимание структуры данных, но зачастую скрывает общую логику взаимодействия между клиентом и сервером. Для того чтобы увидеть картину целиком и понять контекст атаки, криминалисты используют механизм Follow TCP Stream. Этот инструмент позволяет склеить разрозненные TCP-сегменты и представить сырой трафик в виде непрерывного и читаемого текстового потока, что критически важно для восстановления последовательности действий злоумышленника.6.1. Восстановление сессий
Для восстановления логической цепочки обмена данными мы используем контекстное меню: достаточно нажать правой кнопкой мыши на интересующий нас POST-пакет и выбрать пункт Follow =>TCP Stream. В открывшемся окне Wireshark автоматически собирает все пакеты, принадлежащие данной сессии, и отсеивает служебную информацию транспортного уровня.
Механизм Follow TCP Stream позволяет восстановить логическую последовательность обмена данными, представляя сырые пакеты в виде читаемого текстового потока. Это превращает набор технических набор записей в понятный диалог. Вместо того чтобы вручную сопоставлять номера подтверждений и последовательностей , мы сразу видим, какие команды отправлял атакующий и как на них реагировала система. В нашем случае это позволило мгновенно идентифицировать попытку авторизации и последующие действия в рамках одной сессии.
6.2. Plaintext protocol analysis
При анализе открытых протоколов Wireshark применяет интуитивно понятную цветовую маркировку, которая помогает мгновенно ориентироваться в направлении трафика. Цветовая маркировка в Wireshark разделяет направления трафика: красный цвет соответствует исходящим запросам клиента, а синий ответам сервера. В данном потоке мы видим полную структуру HTTP-транзакции, включая заголовки и передаваемые параметры.
В этом же окне мы можем без труда найти глазами строки User-Agent, Host и самое главное - тело запроса. В исследуемом потоке четко прослеживается передача чувствительных данных в открытом виде, что является серьезной уязвимостью конфигурации веб-приложения. Мы видим, как в красной части потока передаются логин admin и session_token, содержащий наш CTF флаг.
Использование такого метода визуализации делает очевидным отсутствие шифрования, ведь любые данные видны как на ладони, что позволяет нам восстановить детали инцидента без необходимости проводить сложную дешифровку трафика.
Последние два скриншота показывают, что даже оставаясь в режиме ASCII, можно получить разное представление данных, просто протыкав настройки отображения или сменив направление потока.
Здесь же мы видим всё тот же текстовый формат, но за счет другого ракурса структуры данных становятся видны детали, которые могли быть скрыты при беглом просмотре.
Зачем это нужно цифровому криминалисту?
Иногда автоматический парсинг Wireshark может проглотить часть строки или некорректно отобразить символы переноса. Переключение режимов (ASCII, Raw или работа с разными направлениями трафика в выпадающем списке) позволяет убедиться, что мы видим чистый запрос без искажений.
В форензике важно перепроверять данные, и если в одном виде строка кажется обрезаной, стоит сменить тип представления, чтобы вытащить флаг или пароль целиком.
7. File Extraction
Завершающим и самым наглядным этапом сетевой форензики является извлечение объектов. Одно дело - видеть в дампе передачу байтов, и совсем другое - восстановить полноценный файл, который злоумышленник пытался внедрить в систему или, наоборот, похитить.Когда мы анализируем трафик, мы часто сталкиваемся с тем, что вредоносная нагрузка передается по частям в сотнях разных пакетов. Инструментарий Wireshark позволяет автоматизировать процесс сборки этих фрагментов, избавляя аналитика от рутинного ручного сопоставления полезной нагрузки. Это превращает теоретические догадки в осязаемые доказательства.
7.1. HTTP Export Objects
Для восстановления данных, переданных по незащищенному протоколу HTTP, мы используем один из самых мощных встроенных инструментов - экспорт объектов. Чтобы получить доступ к этому функционалу, в верхнем меню необходимо перейти по пути: File => Export Objects => HTTP.... Перед нами откроется специализированное окно, консолидирующее все файлы, которые пролетали через сеть в ходе захваченной сессии.
Функция Export Objects позволяет восстановить файлы, переданные по протоколу HTTP. В открывшемся списке мы видим все медиафайлы, скрипты и документы, которые были загружены в ходе сессии. Интерфейс отображает не только имена файлов, но и их типы, размеры и хосты, с которых они были получены. Это крайне удобно для быстрой фильтрации, ведь мы можно сразу отсечь безобидные изображения и сфокусироваться на исполняемых файлах или текстовых сценариях.
В нашем конкретном случае, помимо стандартных элементов веб-страницы, анализ объектов позволил извлечь текстовый скрипт, зафиксированный в Packet 109.
Сохранение и последующий анализ кода позволяют определить намерения атакующего и механизмы закрепления в системе. Тот факт, что скрипт был передан в открытом виде, дает нам возможность изучить его логику без предварительной деобфускации. Часто такие файлы содержат жестко прописанные пути к директориям, команды на скачивание дополнительного софта или даже учетные данные от других сервисов. Обнаружение подобного артефакта в списке экспорта - это джекпот для специалиста.
7.2. SMB и TFTP transfers
Несмотря на то, что в данном сценарии ключевым вектором стал HTTP, специалист по форензике должен владеть методами извлечения данных из других популярных протоколов, таких как SMB и TFTP.Протокол SMB (Server Message Block) является стандартом де-факто в корпоративных сетях на базе Windows для обмена файлами и доступа к принтерам. Wireshark поддерживает экспорт объектов SMB аналогично HTTP-трафику. Это позволяет аналитику перехватывать документы, базы данных или исполняемые файлы, которые атакующий может перемещать между серверами внутри периметра. Особая ценность этого метода заключается в возможности восстановить файлы, которые были удалены злоумышленником с целевой машины сразу после использования, ведь их копия навсегда останется в дампе трафика.
В свою очередь, TFTP (Trivial File Transfer Protocol) - это максимально упрощенный протокол, лишенный механизмов аутентификации и шифрования. Он часто встречается при анализе трафика сетевого оборудования или при загрузке бездисковых станций через PXE.
Поскольку TFTP работает поверх UDP и не имеет сложного контроля состояний, Wireshark использует свои алгоритмы для сборки датаграмм в единый поток. Извлечение конфигурационных файлов через TFTP может раскрыть пароли от сетевого оборудования или параметры доступа к критическим узлам инфраструктуры. Важно понимать, что любой незашифрованный протокол передачи данных оставляет возможность для полной реконструкции файлов, на этом часто строится доказательная база в сетевой форензике.
8. Credential Hunting
Завершающий этап любого расследования - это поиск и фиксация учетных данных, которые могли быть скомпрометированы.Зачастую новички слишком полагаются на автоматику, но реальная практика показывает, что ручной анализ в Wireshark остается самым надежным методом. При попытке использования автоматизированного анализатора NetworkMiner было обнаружено, что вкладка Credentials пуста.
Так получилось из-за захвата трафика на интерфейсе loopback в среде Linux через tshark. В подобных сценариях автоматизированные парсеры часто демонстрируют некорректную работу, что накладывает на DFIR-специалиста обязательство владеть методами ручной реконструкции данных. Глубокое понимание структуры сетевых протоколов становится единственным надежным инструментом восстановления информации при отказе специализированного ПО.
8.1. FTP, HTTP Basic, SMTP
Когда автоматика пасует, приходится возвращаться к основам, а именно, к ручному разбору текстовых протоколов, которые передают данные в открытом виде. Проблема многих современных утилит в том, что они настроены на поиск стандартных паттернов в стандартных условиях.В реальности картина представляется куда хаотичнее. Например, при захвате трафика на интерфейсе loopback в Linux структура кадров может слегка отличаться от привычного Ethernet, из-за чего умные анализаторы просто «не видят» учетные данные там, где они лежат на поверхности. В таких ситуациях ваше знание того, как именно протокол запрашивает пароль, становится решающим преимуществом.
Взять, к примеру, HTTP Basic Authentication. Это один из старейших способов защиты, который до сих пор встречается во внутренних сетях или админках роутеров. Здесь всё предельно просто. Браузер отправляет заголовок Authorization: Basic, после которого идет длинная строка из букв и цифр. Это не шифрование, а всего лишь кодировка Base64. Любой DFIR знает что достаточно скопировать эту строку в любой декодер, и перед вами мгновенно появится пара логин:пароль. В Wireshark даже не нужно искать сторонние сайты, ведь он сам расшифровывает такие строки в окне деталей пакета, если вы знаете, куда смотреть.
Аналогичная ситуация наблюдается при анализе трафика FTP. Этот протокол создавался в эпоху, когда о безопасности думали в последнюю очередь. Весь процесс авторизации здесь открытый: клиент шлет команду USER, а затем команду PASS. В потоке трафика эти слова светятся как маяки. Вам даже не нужно собирать поток, достаточно вбить в фильтр ftp и пролистать список. Если злоумышленник подключался к серверу, его пароль будет виден в поле Info абсолютно незащищенным. Это классика сетевой форензики, которая наглядно показывает, почему использование старых протоколов в современной инфраструктуре - это огромный риск.
Даже в почтовом трафике SMTP при попытке авторизации через метод AUTH LOGIN данные почтового ящика перехватываются без особого труда. Процесс выглядит как диалог: сервер спрашивает «Username?», клиент отвечает кодом в Base64, сервер спрашивает «Password?», клиент снова шлет код. Перехват таких данных позволяет подтвердить факт несанкционированного доступа к корпоративной почте или почтовым серверам. Важно быстро распознавать такие паттерны в сыром потоке данных. Это позволяет аналитику сохранять эффективность даже в условиях, когда под рукой нет тяжелого и дорогого софта, а есть только дамп трафика и понимание того, как работают сетевые технологии под капотом.
8.2. Извлечение флага
Подведём итоги:Основной целью расследования была идентификация переданных данных и поиск доказательств утечки. В исследуемом дампе evidence.pcap основная передача данных происходила через метод HTTP POST. С помощью фильтра http.request.method == "POST" был успешно идентифицирован пакет №20.
В секции HTML Form URL Encoded обнаружился логин пользователя: admin. При этом поле пароля отсутствовало, что при наличии session_token прямо указывает на использование механизмов сессионной авторизации, а также что злоумышленник закрепился бы в системе, будь это реальный сценарий.
В теле запроса пакета №20 был обнаружен и извлечен финальный флаг: CTF{w1r3sh4rk_d3t3ct1v3}. Это подтверждает факт успешной утечки конфиденциальной информации через незашифрованный канал связи. Использование открытого HTTP сделало перехват этого секрета элементарной задачей для любого наблюдателя в сети. Именно эта улика становится неопровержимым доказательством в ходе расследования инцидента.
Таки да! В ходе этого разбора мы не только освоили базовый инструментарий Wireshark, но и значительно продвинулись в понимании сетевой форензики. Мы научились видеть реальные действия атакующего среди несвязного полотна записей, и этот опыт показал, что даже при отказе автоматических анализаторов, знание структуры протоколов позволяет вручную восстановить цепочку событий и извлечь ключевые улики.
Удачи, цифровые криминалисты!
Вложения
Последнее редактирование модератором:
