Анализ скрытых MITM в Wireshark: часть 2
👋 Приветствую в мире цифровой безопасности!
В прошлой части смотрели на сертификаты и сетевые параметры. Теперь копнём глубже: разберём признаки, которые по отдельности ещё ничего не доказывают, но вместе могут вывести на след прокси или перехватывающего узла.
⏺Начнём с TLS Alert. Если посредник не может нормально обработать соединение, он может оборвать сессию прямо во время handshake:
tls.alert_message
Смотрим, какие соединения заканчиваются Alert, и сравниваем их с успешными сессиями того же клиента. Один случай - ещё не сенсация. Повторяющийся сценарий - уже повод насторожиться.
⏺Следующий фильтр ловит неожиданные сбросы TCP:
tcp.flags.reset == 1
Особенно интересно, если RST прилетает сразу после Client Hello или Server Hello. Сам по себе сброс не означает MITM, но если он регулярно появляется в одном и том же месте handshake, картина становится подозрительной.
⏺Теперь проверим, куда клиент вообще пытается установить TLS-соединение:
tls.handshake.extensions_server_name
Сверяем SNI, DNS-ответ и фактический IP назначения. Например, клиент запрашивает api.example.com, DNS отдаёт один адрес, а соединение снова и снова уходит на другой. Это может быть CDN, балансировщик или корпоративная инфраструктура, но такое расхождение точно стоит проверить.
⏺Отдельно смотрим ALPN:
tls.handshake.extensions_alpn_str
Сравниваем несколько соединений одного клиента. Если обычно используется h2, а часть сессий внезапно переключается на http/1.1, возможны промежуточный прокси, TLS inspection или другая прослойка между клиентом и сервером.
⏺Ищем повторные handshake через Client Hello:
tls.handshake.type == 1
Добавляем к просмотру:
tcp.stream
Теперь сравниваем потоки. Сценарий Client Hello → несколько пакетов → FIN/RST → новый Client Hello, который повторяется снова и снова, выглядит гораздо интереснее, чем единичный разрыв соединения.
⏺Ещё один полезный фильтр:
tcp.analysis.retransmission || tcp.analysis.out_of_order
Здесь важно не просто посчитать retransmission, а найти закономерность. Например, повторные передачи начинаются только после TLS handshake или возникают исключительно при обращении к конкретному IP.
⏺Чтобы быстро собрать всё в одну картину, открываем:
Statistics → Conversations → TCP
Сортируем соединения по количеству пакетов и смотрим пары IP:port. Затем открываем подозрительный поток через Follow → TCP Stream и проверяем всю цепочку: TCP handshake, TLS handshake, Alert, retransmission и завершение соединения.
MITM редко оставляет один очевидный след. Гораздо интереснее, когда DNS, SNI, TLS, TCP и поведение нескольких сессий начинают противоречить друг другу. Вот тогда уже есть за что зацепиться.
ZeroDay | Белый Хакер | #MITM
