TLS в сети: как быть

TLS в сети: как быть 🤷‍♂️

Ты — мощный движок разбора сетевого трафика.

Ты работаешь на благо системы защиты информации, перемалывая терабайты проходящих через тебя данных.

В твоих недрах крутятся десятки тысяч нефолзящих экспертных правил, тебе не страшны любые протоколы L7 — HTTP, SMTP, FTP, DNS.

Но внезапно в тебя подают какую-то невнятную мешанину из байтиков сетевого соединения по 443-му порту, которая начинается с магических |1603| 🧙

«О нет!». Это же TLS, декрипт которого никто не удосужился сделать, и его инкапсулированное содержимое теперь скрыто от тебя. Но ведь внутри может быть что-то плохое, что-то вредоносное. Как же быть?

Не расстраивайся! TLS-трафик в целом поддается анализу, хоть и не контентному. Можно выделить два основных метода:

1. Анализ информации из заголовков и сертификатов.
2. Анализ характеристик TCP-сессий.

Анализ информации из заголовков и сертификатов (актуально для версии TLS ниже 1.3)

Основные параметры заголовков, которые можно проанализировать:

• Версия протокола. Например, SSL 3.0 или TLS 1.0.

• Наборы шифров (cipher suites) — указывают на алгоритмы, которые будут использоваться для шифрования данных и создания MAC (Message Authentication Code).

• Алгоритмы сжатия.

• Порядок и типы поддерживаемых расширений. Например, расширение ALPN (Application-Layer Protocol Negotiation) используется для согласования протокола прикладного уровня (например, HTTP/2 или HTTP/3).

Аспекты анализа сертификатов:

• Цепочка сертификации: кто выдал сертификат (центр сертификации, CA), является ли цепочка валидной и корректно ли настроена.

• Срок действия сертификата: просроченные или неправильно настроенные сертификаты свидетельствуют о небезопасной конфигурации сервера или атаке, например о MITM (man in the middle).

• Подозрительные имена серверов (Common Name): они могут сигнализировать о поддельных или скомпрометированных сертификатах. Например, С2-сервер VenomRAT по умолчанию предоставляет интересную информацию о себе (скриншот 1).

🫵 Дополнительно можно анализировать цифровые отпечатки — уникальные идентификаторы клиентов, устанавливающих TLS-соединения, или серверов, принимающих такие соединения.

В основе работы JA3 и JA3s лежат сбор характеристик во время TLS-рукопожатия и генерация отпечатка. JA3 — это хеш-функция, которая вычисляется с помощью алгоритма MD5 на основе параметров, передаваемых клиентом при установке TLS-соединения. В результате формируется уникальный идентификатор клиента — JA3-отпечаток (WARNING — может фолзить!).

Например, JA3 a85be79f7b569f1df5e6087b69deb493 однозначно указывает на соединение ВПО Remcos с С2-сервером (скриншот 2).

Детектирование на основании JA3 и JA3s поддерживают практически все сетевые СЗИ, в том числе и продукты Positive Technologies — PT NAD и PT Sandbox. Анализ TLS 1.3 — более сложная задача, но об этом в другой раз.

Анализ характеристик TCP-сессий

Анализатор может смотреть на характеристики TCP-сессий, инкапсулирующих зашифрованный трафик: на размер пакетов, их частоту и временные интервалы между ними. Даже не видя содержимого пакетов, DPI-система способна сделать выводы о типе трафика или возможной аномалии.

В качестве примера можно привести бэкдор, который все делал правильно: «притащил» библиотеку для работы с SSL, пытаясь скрыть свои очень важные данные. Однако в сети он вел себя весьма интересно: клиент (то есть бэкдор) всегда отправлял на С2-сервер полезную нагрузку TCP размером 163 байта, а сервер отвечал ему полезной нагрузкой размером 166 байт (скриншот 3). Это или какой-то Heartbeat, или волшебный padding.

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

Вывод: увидел TLS — не расстраивайся.
Happy hunting! 🎯

#detect #malware #network #hunt #tips
@ptescalator