🦈 Смотрим «под капот» защищенных соединений в Wireshark. Часть 2: протоколы Windows

В первой части мы разбирали декрипт TLS-соединений, которые часто используются в интернете. Но если переместиться внутрь корпоративной среды, там будут преобладать другие протоколы — SMB, LDAP и DCERPC, — и все они имеют функцию шифрования содержимого своих запросов.

Например, эта функция появилась в протоколе SMB версии 3, для большинства DCERPC-соединений используется уровень аутентификации Packet Privacy, а сообщения протокола LDAP шифруются при включенной подписи (LDAP Signing).

У них есть кое-что общее: ключ шифрования Session Key в конечном счете генерируется на основе пароля учетной записи пользователя или ключа учетной записи устройства. Правда, сам алгоритм дешифрования сильно отличается в зависимости от протокола (NTLM или Kerberos).

1️⃣ NTLM-аутентификация

Самый простой случай: для расшифрования нам понадобится только пароль пользователя. Чтобы указать его в Wireshark, необходимо открыть Edit → Preferences, затем в параметрах протокола NTLMSSP вписать пароль в поле NT Password. Теперь рядом с зашифрованными блоками появятся расшифрованные (скриншот 1).

2️⃣ Kerberos

Для расшифрования сессий с аутентификацией Kerberos необходим пароль либо учетной записи пользователя, либо сервисной учетной записи, поскольку оба эти пароля участвуют в формировании сессионного ключа. По сути, нам сначала необходимо расшифровать значение сессионного ключа внутри Kerberos, а затем использовать его для декрипта SMB или других протоколов. Сначала необходимо сгенерировать keytab-файл.

Генерация keytab-файла по паролю пользователя

Из Kerberos-ответа AS-REP узнаем алгоритм шифрования и значение соли по формуле <REALM> + <cname>. В нашем случае они будут равны aes256-cts-hmac-sha1-96 и ATTDETT.STFo_walsh соответственно, причем важно обратить внимание на регистр (скр. 2).

С помощью Linux-утилиты kutils добавляем запись для нужного пользователя, используя команду addent с параметром -password. Параметры указываем как в команде ниже, причем параметр -k (Key Version Number, kvno) может быть любым числом. Сохраняем keytab при помощи команды wkt (скр. 3).

ktutil: addent -password -p o_walsh@ATTDETT.STF -k 2 -e aes256-cts-hmac-sha1-96

Генерация keytab-файла по ключу сервисной УЗ

Сессионный ключ в билете TGS может быть расшифрован также при помощи ключа сервисной учетной записи. Это полезно, если мы хотим расшифровывать соединение с сервисом любых пользователей. Пароль сервисных учетных записей, как правило, совпадает с паролем учетной записи устройства — он очень сложный и генерируется автоматически каждые 30 дней.

Из TGS-ответа так же достаем алгоритм шифрования и с помощью той же утилиты kutils добавляем запись. Разница лишь в том, что вместо пароля используем параметр -key с ключом сервисной учетной записи, получить который можно, например, с помощью скрипта secretsdump из фреймворка Impacket. Параметр -p (principal) для Wireshark неважен, можем указать любые значения -p и -k (скр. 4).

ktutil: addent -key -p something@RANDOM.RND -k 666 -e aes256-cts-hmac-sha1-96

Как использовать полученный keytab-файл?

В Wireshark включаем параметр Try to decrypt Kerberos blobs:

Edit → Preferences → Protocols → KRB5 → Try to decrypt Kerberos blobs

Чтобы указать keytab-файл в Wireshark, необходимо открыть Edit → Preferences, затем в параметрах протокола KRB5 выбрать файл Kerberos keytab file. Часть полей будут отображаться нерасшифрованными — это нормально. Затем приступаем к дешифровке SMB3.

SMB3

Нам понадобится тот самый сессионный ключ. Найти его можно в поле keyvalue в пакетах TGS-REP или AP-REQ. Затем берем один из интересующих нас пакетов SMB3 и копируем из хедера Session ID (как на скр. 5, 6).

Указываем сессионный ключ и Session ID в поле Secret session key в Wireshark в параметрах протокола SMB2:

Edit → Preferences → Protocols → SMB2 → Secret session key for decryption

Бинго! Получаем расшифрованный SMB3 (скр. 7). Тот же самый алгоритм работает и для дешифрования других протоколов (DCERPC, LDAP и т. д.).

#dfir #tip #network
@ptescalator

🦈 Смотрим под капот защищенных соединений в Wireshark. Часть 3: MITM-атака на SSL/TLS-соединения

MITM-атака — достаточно популярный функционал различных песочниц и систем анализа приложений. Обычно инструменты, которые позволяют осуществлять MITM-атаки, представляют из себя прокси-сервер, который позволяет гибко обрабатывать входящий в него трафик и перехватывать SSL/TLS-сессии, извлекать мастер-ключи и многое другое. В таком случае нам требуется указать этот прокси-сервер в приложении или сервисе, на который планируется MITM-атака. В зависимости от гибкости инструмента, в нем также может быть встроен режим прозрачного проксирования (transparent proxy), который в отличие от классического прокси обычно требует, чтобы трафик был перенаправлен сетевыми правилами (например, с помощью iptables) в конкретную машину.

👀 Рассмотрим sslsplit — инструмент с открытым исходным кодом, который позволяет расшифровывать SSL/TLS-соединения прозрачно.
Сконфигурируем шлюз на базе Debian на примере скрипта make_gateway.sh.

Предварительно сгенерируем сертификаты для последующей работы прозрачного прокси.

openssl genrsa -out ca.key 2048
openssl req -new -x509 -days 365 -key ca.key -out ca.crt

Запустим sslsplit с указанными параметрами.

sslsplit -M keys.log -D -l connections.log -j sslsplit/ -S logdir/ -k ca.key -c ca.crt ssl 0.0.0.0 8443 tcp 0.0.0.0 8080

С другой машины сделаем запрос, при этом не указывая никакие параметры прокси, так как тут прокси у нас прозрачен и трафик перенаправляется в шлюз с клиентской машины, а дальше SSL/TLS с порта 443 перенаправляется в запущенный прозрачный прокси в порт 8443, при этом на клиенте нет никаких правил перенаправления трафика.

curl --cacert ca.crt --tlsv1.3 https://www.ptsecurity.com/

Лог инструмента выводит информацию о том, что запрос прошел через прокси, хотя мы не указывали его напрямую (скриншот 1). В директории logdir, которую мы указали в инструменте, появляется файл, который содержит в себе расшифрованный поток (скриншот 2). При этом в файл keys.log записываются мастер-ключи SSL/TLS, и в дальнейшем эти ключи можно использовать, например, в Wireshark, если предварительно захватим весь трафик, который нужно расшифровать. Об этом мы рассказывали в первой части постов про Wireshark. Стоит отметить недочет данного инструмента — SSLKEYLOGFILE для сессий TLSv1.3 формируется некорректно, как следствие при открытии PCAP-файла в Wireshark не будет доступа к расшифрованным данным.

Но что, если мы хотим сформировать PCAP-файл с расшифрованными данными?

🐻 PolarProxy — в отличие от указанного выше инструмента, PolarProxy позволяет сформировать PCAP-файл с расшифрованными данными, но его главный недостаток: он проприетарный.

Запустим SOCKS в PolarProxy и укажем запись напрямую в PCAP-файл.
При этом PolarProxy имеет встроенный веб-хост сертификата, запустим его на порту 10080.

sudo ./PolarProxy -v --certhttp 10080 --socks 1080 -w polarproxy.pcap

Загрузим сертификат

wget http://127.0.0.1:10080/polarproxy.crt

Сформируем запрос через запущенный прокси.
Предварительно укажем сертификат в опции --cacert.

curl --cacert polarproxy.crt --proxy socks5://127.0.0.1:1080 https://ptsecurity.com/

После завершения работы PolarProxy получаем записанный PCAP-файл polarproxy.pcap. В нем данный расшифрованный запрос можем посмотреть через Wireshark (скриншот 3). В отличие от предыдущих описанных инструментов, здесь формируется расшифрованный PCAP-файл в чистом виде, поэтому данный файл можно парсить с помощью Zeek, Suricata и других DPI.

У инструмента есть возможность применения опции прозрачного прокси, например:

sudo ./PolarProxy -v -p 0.0.0.0,10443,80,443 -w polarproxy.pcap

Тогда PolarProxy будет запущен прозрачно на порту 10443 и будет обрабатывать трафик с клиентской машины от портов 80, 443 на всех интерфейсах.

Продолжение в посте ниже 👇

#dfir #tip #mitm #ssl #tls
@ptescalator

🦈 Смотрим под капот защищенных соединений в Wireshark. Часть 3.1: MITM-атака на SSL/TLS-соединения

В дополнение к предыдущему посту рассматриваем дополнительные инструменты для расшифровки сетевого трафика.

Рассмотрим альтернативу PolarProxy, которая не является проприетарной. SSLproxy — инструмент, который по сути является продолжением sslsplit, но обладает рядом других преимуществ, в частности — запись расшифрованных данных в PCAP-файл. Данный проект применяется в UTMFW. Предварительно настроим хост, как в случае sslsplit, только тут трафик будет перенаправляться в один единственный порт 8443.

sslproxy -k ca.key -c ca.crt -P https 0.0.0.0 8443 -X sslproxy.pcap

Сформируем запрос с указанием предварительно сгенерированного сертификата в опции --cacert.

curl --cacert ca.crt --tlsv1.3 https://ptsecurity.com/

В отличие от предыдущих описанных инструментов, здесь формируется PCAP-файл с расшифрованными данными, поэтому его можно парсить с помощью Zeek, Suricata и других DPI. Но инструмент имеет аналогичный sslsplit недостаток — файл с мастер-ключами формируется неправильно для TLSv1.3.

Подводя итог по инструментам PolarProxy и SSLProxy: они являются отличными аналогами sslsplit, которые также могут быть применены в том или ином автоматизированном сервисе, например в системе анализа приложений или NGFW.

Все указанные выше инструменты имеют один ключевой недостаток — у них нет возможности формировать, либо полноценно формировать файл с мастер-ключами SSL/TLS-сессий. Рассмотрим инструмент, который решает конкретно эту проблему.

❕ mitmproxy — интерактивный инструмент с открытым исходным кодом. Имеет возможность использования web UI (mitmweb). В отличие от предыдущих аналогов, данный инструмент не имеет возможности записи расшифрованных данных в PCAP-файл, но зато способен наиболее эффективно работать с мастер-ключами. Данный инструмент содержится во многих репозиториях, в том числе PyPI.

Для захвата сетевого трафика в реальном времени с помощью mitmproxy можно использовать следующую команду:

SSLKEYLOGFILE="$PWD/.mitmproxy/sslkeylogfile.txt" mitmproxy --set confdir=.mitmproxy/ --listen-host 0.0.0.0 -p 8080

В рабочей директории, где был запущен mitmproxy, будет создана директория с файлами конфигурации .mitmproxy, которая будет содержать эти сертификаты. В последующем их можно применять при реализации MITM-атаки на SSL/TLS.

Попробуем осуществить HTTP/2-запрос через запущенный прокси, при этом указав CA (центр сертификации).

curl --proxy 127.0.0.1:8080 --cacert ~/.mitmproxy/mitmproxy-ca-cert.pem https://www.ptsecurity.com/

Так как данные поступают в расшифрованном виде, можем интерактивно наблюдать заголовки запроса (скриншот 4) и ответа (скриншот 5). Полученные ключи sslkeylogfile.txt, которые мы указали в переменной среде SSLKEYLOGFILE мы можем применять в дальнейшем для наших целей, в том числе в Wireshark. При этом ключи TLSv1.3 сессий будут иметь правильный формат, в отличии от предыдущих инструментов. У mitmproxy также есть функционал прозрачного прокси, в случае добавления опции --mode transparent.

Таким образом, из плюсов mitmproxy можно отметить быстроту развертывания, интерактивность (в том числе web UI), актуальность (тула регулярно обновляется и дорабатывается), а также возможность формирования рабочих мастер-ключей для TLSv1.3.

💬 Подводя итог, хочется отметить, что существует множество инструментов для осуществления MITM-атак на SSL/TLS-соединения. Каждый из этих инструментов имеет свои плюсы и минусы и подходит под разные задачи.

#dfir #tip #mitm #ssl #tls
@ptescalator

«Я буду *** твоих рыб» 🐟

В середине октября группа киберразведки засекла фишинговую активность в адрес HR-подразделений строительного сектора.

Злоумышленники рассылали письма якобы от HeadHunter с требованием верифицировать аккаунт на стороннем сайте. Введенные на этой странице email и одноразовый код использовались для перехвата учетной записи, после чего жертва теряла к ней доступ (скриншот 1).

Ссылка ведет на фишинговый домен hhcasa.xyz, который закрыт за Cloudflare и зарегистрирован с помощью главного регистратора доменов Украины nic.ua (скриншот 2).

Страница имеет два состояния интерфейса. При наличии auth=1 показывается основная сцена «успешного шага», при отсутствии — альтернатива (скриншоты 3–4).

Такое разделение используется для сокрытия страницы от лиц, не попавших в список рассылки.

🪞 Верстка и статика копируют hh.ru: в <head> тянутся Google Fonts и favicon с i.hh.ru, логотип и шапка повторяют стиль, а пункты навигации кликабельны и направляют пользователя на легитимный домен simferopol.hh.ru, что создает впечатление «чистого» сайта. Однако в навигации присутствует пункт «Зарегестрироваться» с орфографической ошибкой, что выступает индикатором подмены сайта.

На фишинговой странице имитируется связка «почта → код подтверждения». Пользователь вводит email, скрипт проверяет формат регулярным выражением и делает POST-запрос, в тело которого кладут еще и токен формата Base64, который генерируется прямо в браузере из User-Agent, текущего времени и случайной строки.

❗️ Отметим, что в марте этого года нами уже фиксировалась аналогичная фишинговая кампания от имени HeadHunter. Тогда в навигации тоже присутствовал пункт «Зарегестрироваться» с той же характерной ошибкой, и с тем же принципом компрометации аккаунта: связка «почта → одноразовый код → перехват учетной записи» с последующей потерей доступа.

Злоумышленники также собирают телеметрию. Она реализована через создание объекта Image и присвоение ему src, чтобы браузер отправил GET на внешний адрес с параметрами домена и меткой времени (скриншот 5).

Задача сбора телеметрии утилитарная: оператор видит реальный IP посетителя и время захода на конкретный домен, что может говорить о наличии у операторов дополнительных фишинговых доменов.

IP-адрес 185.162.10.35, на который отправляется телеметрия, находится в ASN 59729 (GREEN FLOID LLC). По результатам анализа и pDNS-наблюдений, на этом IP также размещаются и ранее размещались другие фишинговые домены, которые, так же как и hhcasa.xyz, были зарегистрированы с помощью nic.ua.

hhrunaх.xyz;
hscac.xyz;
hmnsc.xyz.

🖕 Фишинговый домен имеет антиотладку. Скрипт перехватывает контекстное меню, выделение и копирование, горячие сочетания клавиш, которыми обычно открывают исходники и DevTools: Ctrl+U, Ctrl+S, Ctrl+Shift+I/J/C и F12. При срабатывании «запрещенной» клавиши страница стирает содержимое body и накладывает поверх черный полноэкранный блок с сообщением (скриншоты 6–7).

В защите нет ничего сложного: она не умеет обнаруживать открытые DevTools и никак не прячет исходники вне текущего документа. Самый простой способ обойти ее — открыть DevTools через меню браузера до загрузки страницы или отключить выполнение JavaScript для этого домена и перезагрузить вкладку, чтобы снять HTML и статические ресурсы.

Помимо комментариев на русском языке в коде, в разметке оставлена украинская раскладка: в теге <html> задан lang="ua", вероятно, этот атрибут проставился автоматически при генерации шаблона и его просто забыли поменять.

📝 В самом фишинговом письме группировка использовала логотип HH, который подгружался из GitHub-репозитория (скриншот 8). Репозиторий (скриншот 9) создан в октябре 2022 года и содержит проекты фишинговых сайтов, в одном из которых находился самописный стилер, накрытый протектором. Вредоносное ПО при запуске ворует куки и пары «логин — пароль», отправляя все в телеграм-канал злоумышленника.

Телеграм-аккаунт, куда бот отправляет украденные данные, также мимикрирует под сотрудника компании HeadHunter (скриншот 10).

#TI #Phishing
@ptescalator