Ключевая мысль их исследования: форки почти никогда не переписывают TLS-сертификат сервера, доставшийся от родителя. DCRAT принес в семью структуру O=<Name> By <author>, L=SH, C=CN, и это наследуется вплоть до самых мелких потомков — даже если сам билд больше никак не забрендирован. Именно этот паттерн Censys называет самым надежным сигналом для всей линейки, независимо от конкретного варианта.

У нас, отдела сетевой экспертизы антивирусной лаборатории, уже был опыт детектирования VenomRAT по его дефолтовому сертификату, и мы даже отдали в сообщество сигнатуру для Suricata в рамках проекта PT Rules.

Именно поэтому нас это исследование, само собой, зацепило — и мы решили прогнать похожую логику не по интернет-скану, а по трафику из собственных песочниц: а вдруг мы что-то упустили?

Взяли любимый NTA и сделали в нем следующий запрос (аналогичный хант можно сделать где угодно, хоть в базе данных):

tls.server_cert.subject.value ~ "*RAT*" 
&& !tls.server_cert.subject.value ~ "*CORPORAT*" 
&& !tls.server_cert.subject.value ~ "*INTEGRAT*"

(исключения нужны, потому что corporated, corporation или integrator тоже с радостью матчатся на *RAT* — привет, ложные срабатывания)

Результат — реально интересный: помимо вышеупомянутого VenomRAT куча других C2-серверов буквально сами себя подписывают.

Вот например прародитель AsyncRAT не стесняется подписываться как AsyncRAT Server:

PureRAT притворяется PureRAT Agent:

LiberiumRAT подписал сам себе сертификат под именем Liberium RAT Authority:

Еще ряд менее известных семплов — все радостно светят своим назначением прямо в сертификате.

Как детектить в Suricata?

Аналогично нашему правилу на VenomRAT можно зацепиться за байты |3082| — встречаются в начале сертификата, далее |550403| — это закодированный ASN.1 Object ID 2.5.4.3 (id-at-commonName), и в завершение — искомая строка, например:

alert tls any any -> any any (msg: "REMOTE [PTsecurity] LiberiumRAT SSL certificate"; flow: established, from_server; content: "|3082|"; depth: 300; content: "|550403|"; depth: 600; content: "Liberium RAT"; distance: 2; within: 12; classtype: trojan-activity; sid: 1; rev: 1;)

А как хантить, на что смотреть:

• Issuer/Subject вида CN=.*RAT.* — как видно выше, срабатывает идеально.
• Комбинация L=SH, C=CN + O=* By * на нестандартном порту.
• Самоподписанные сертификаты в целом — malware-C2, в отличие от фишинговых сайтов, не боится браузерных ошибок, поэтому самоподпись используется массово.
• Признаки дефолтной генерации — пустые O/L/ST, CN продублирован в SAN или Issuer — CN=example.com, O=Acme.

Из истории вопроса — похожий трюк еще в 2023 году проворачивали с Quasar RAT: там дефолтный сертификат CN=Quasar Server CA через Shodan/Censys вывел исследователей сразу на 60+ живых серверов. Nuff said.

Мораль: TLS-сертификат, при наличии, конечно, — это метаданные, которые остаются в открытом виде, даже когда весь остальной трафик зашифрован. Авторы билдеров RAT'ов почему-то регулярно об этом забывают 🙂

Happy hunting!

#TI #malware #RAT #C2 #tls #detect #suricata
@ptescalator

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

Рассмотрим альтернативу 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

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

w, err := os.OpenFile("/path/to/SSLKEYLOGFILE", os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0600)
config := &tls.Config{KeyLogWriter: w}

export SSLKEYLOGFILE=/path/to/keylog.log

export SSLKEYLOGFILE=/path/to/keylog.log
python main.py

node --tls-keylog=/path/to/keylog.log program.js

export NODE_OPTIONS=--tls-keylog=/path/to/keylog.log

"realitySettings": {
  "serverName": "yahoo.com",
  "publicKey": "publicKey",
  "shortId": "shortId",
  "fingerprint": "chrome",
  "spiderX": "/",
  "masterKeyLog": "/path/to/keylog"
}