Хакинг без метаданных Глубокий дайвинг в трафик без DPI. Расширенные методы анализа сетевого трафика для обнаружения сложных угроз.

Вступление — контекст проблемы

Современные угрозы всё чаще используют полноценное шифрование (TLS, QUIC), зашифрованные DNS-запросы, VPN и приватные каналы. DPI теряет эффективность: полезной полезной информации в пакетах либо нет, либо её нельзя расшифровать без вмешательства. При этом злоумышленники используют обфускацию поведения, туннелирование и «living off the land» приёмы, чтобы слиться с нормальным трафиком сети.

Это ставит задачу: как обнаруживать сложные угрозы, когда у нас нет метаданных DPI и нет возможности смотреть внутрь пакетов? Ответ — переход от блоков контента к анализу телеметрии, поведения и статистики на уровне потоков, TLS-фингерпринтов, таймингов и корреляции с endpoint-данными. Наука и индустрия активно развивают такой подход.

1. Что у нас остаётся, когда DPI недоступен

Без расшифровки у нас остаётся четыре класса данных, и каждый даёт сигналы:

Даже если пейлоад закрыт — паттерны поведения выдают злоумышленника.

2. Аналитическая парадигма: от пакета к поведению

Современный SOC больше не ловит «подозрительные строки».
Он ловит аномальные паттерны жизни устройства.
Ключевые принципы:

1. Контекст важнее сигнатуры.
   Один и тот же TLS-фингерпринт может быть нормой для сервера, но аномалией для принтера.
2. Baseline — твой лучший друг.
   Каждое подразделение живёт своим ритмом. Модель поведения должна учитывать локальные нормы.
3. Сигналы нужно совмещать.
   Flow + DNS + Endpoint = «магия трёх глаз». Только совместная корреляция даёт достоверность

3. Методы продвинутого анализа

JA3 / JA3S — детально (что, почему, как читать)

Что такое JA3 (в одном предложении)

JA3 — метод пассивного TLS-фингерпринга: он извлекает из ClientHello набор полей (версии, cipher suites, extensions, эллиптические кривые и форматы точек), конкатенирует их в стандартизированную строку и берёт MD5-хэш. Результат — 32-символьный хеш (JA3).

Github: https://github.com/salesforce/ja3.git

Поля JA3 (порядок и смысл)

Строка JA3 составляется из пяти компонентов, разделённых запятыми, в порядке:

SSLVersion,CipherSuites,SSLExtensions,EllipticCurves,EllipticCurvePointFormats

Пример строки (псевдо):
771,4865-4866-4867,0-11-10,29-23,0 → MD5 → d41d8cd98f00b204e9800998ecf8427e (пример).

• SSLVersion — версия TLS, заявленная клиентом (например 771 → TLS 1.2).
• CipherSuites — перечисление идентификаторов cipher suites в порядке объявления.
• SSLExtensions — список extensions (SNI, ALPN, supported_versions, etc.) в порядке.
• EllipticCurves — список кривых (x25519, secp256r1 и т.д.).
• PointFormats — форматы точек (обычно 0 — uncompressed).

Важно: порядок и набор полей — именно то, что даёт устойчивый «отпечаток», поскольку разные реализации (curl, Go stdlib, OpenSSL разных версий, browsers) формируют ClientHello по-разному.

JA3S — серверный отпечаток

JA3S делает аналогичную операцию для ServerHello, но поле набора отличается (чаще: SSLVersion,Cipher,SSLExtension). Комбинация JA3+JA3S даёт более полное представление о криптопереговорах и часто помогает отличить легитимный API от самописного C2.

Почему MD5? (и почему это — не значит «опасно»)

MD5 здесь — просто короткий идентификатор; криптографическая стойкость MD5 не нужна, нужна компактность и скорость хеширования для больших потоков логов. Но при аналитике храните и исходные строки (или отдельные поля) для диагностики и будущих feature-engineering.

Как JA3 используется на практике в SOC (конкретика)

3.1. База нормальных JA3

• Сначала собираете JA3 хэши по подсетям/роли (бухгалтерия, dev, prod) в течение 2–4 недель.
• Для каждого хоста храните частотную карту JA3 (топ-10).
• Аналитика: если хост вдруг использует JA3, которого нет в его карте — повышение приоритета тикета.

(Подчеркиваю: это контекстно-зависимая эвристика; ложноположительные бывают, поэтому нужна корреляция с DNS/EDR).

3.2. Корреляция JA3 ↔ Process

Zeek (или NTA) логирует JA3 для соединения; связывайте с EDR: какой PID/EXE открыл сокет? Если JA3 нетипичен и процесс — powershell.exe или python.exe в нетипичном контексте → повышаем приоритет. docs.zeek.org

3.3. Частые прикладные сценарии

• Детекция самописных агентов (нестандартные cipher suites и extension order).
• Разделение legitimate API-clients и бот-клиентов для снижения шума в анализе.
• Источник меток для ML-фич: JA3 как категориальная/one-hot фича в моделях.

Почему JA4 и чем он лучше JA3

• Современные браузеры и TLS-стеки начали перемешивать порядок расширений (extensions), что подорвало устойчивость JA3 (который сильно зависел от упорядоченного списка).
• JA4 намеренно сортирует/нормализует списки cipher suites и extensions, делая фингерпринт устойчивым к случайным перестановкам.
• JA4 предоставляет читаемый и модульный формат, а не просто MD5-хеш строк, что облегчает аналитику, группировку и поиск по сегментам a, b или c отдельно.
• Расширяемость: JA4+ охватывает не только TLS-ClientHello (JA4), но и такие методы как JA4S (TLS Server response), JA4H (HTTP Client), JA4X (X509 сертификаты) и др.
• Индустриальная поддержка: например, AWS WAF добавила поддержку JA4-фингерпринтов и их агрегацию в правилах rate-based.

Как JA4 можно использовать на практике в SOC (конкретика)

3.1. База нормальных JA4

• В течение 2–4 недель собирайте JA4-строки (или a_b, или b_c) с исходящих TLS/QUIC соединений по ролям/подсетям (бухгалтерия, dev, prod).
• Для каждого хоста храните частотную карту JA4 (топ-10 шаблонов a_b_c).
• Если хост начинает использовать JA4, которого нет в его карте, либо если сегмент a и c совпадают с привычным браузером, но сегмент b резко отличается (например другой набор cipher suites) — это сигнал для повышения приоритета тикета.
• Например: известный Chrome-профиль показывает t13d1516h2_…_…, а вдруг появляется t13d1516h2_9e…_… — совпадают a, меняется b → может быть malware, маскирующийся под браузер.
• Аналогично, если сегмент a (транспорт/версия) вдруг меняется: например с t13 → q13 (если QUIC) — обращать внимание.

3.2. Корреляция JA4 ↔ Process

• Как и с JA3: инструмент вроде Zeek, NTA/EDR логирует JA4 для соединения; связывайте с EDR: какой PID/EXE открыл сокет, с каким JA4?
• Если процесс нетипичен (powershell.exe, python.exe, другое не браузерное приложение) + JA4 выглядит как браузер-одиночка (или наоборот) — повышаем приоритет.

3.3. Частые прикладные сценарии

• Детекция самописных агентов: нестандартные наборы cipher suites или ALPN, которые меняют только сегмент b, тогда как a и c как у браузера — признак маскировки.
• Разделение легитимного клиент-трафика и бот-клиентов или C2-агентов: фиксируйте и разрешайте JA4 профиль приложения, остальные — проверка/блокировка.
• Источник фич для ML-моделей: JA4 как категориальная фича; либо сегмент a и c как базовая категория, b как вариации; помогает выявлять аномалии поведений.
• Корреляция инфраструктуры злоумышленников: если множество исходящих клиентов или серверов используют одинаковый a_c (т.е. один и тот же клиентский стек, но меняют b) — можно группировать под одну кампанию.

4) Техническая реализация (Zeek + Python — примеры)

Zeek (вкратце)

• Пакет JA3/JA3S добавляет поля в ssl.log (или tls.log в новых версиях): ja3, ja3_digest, ja3s, ja3s_digest.
• Zeek-лог пример: ts uid id.orig_h id.resp_h ja3 ja3s ... — используйте для агрегаций по host/role.

Python — как посчитать JA3 (псевдо/образец)

Ниже — упрощенная иллюстрация последовательности (не предназначена для прямого обхода мониторинга):

ssl_version = "771" ciphers = "-".join([str(x) for x in cipher_list]) extensions = "-".join([str(x) for x in extension_list]) curves = "-".join([str(x) for x in curve_list]) point_formats = "-".join([str(x) for x in point_format_list])

ja3_string = f"{ssl_version},{ciphers},{extensions},{curves},{point_formats}" ja3_hash = md5(ja3_string.encode()).hexdigest()

Практически: используйте готовые библиотеки / Zeek-пакеты / репозиторий salesforce/ja3 для извлечения из pcap/стрима.

3.2. Поведенческая статистика потоков

Из потока можно вытащить десятки признаков без DPI:

• длительность, байты, пакеты, направление;
• дисперсия размеров пакетов;
• коэффициент burstiness (насколько всплесками передаются данные);
• интервалы keep-alive;
• соотношение uplink/downlink.

Затем эти признаки подаются в unsupervised-модель: Isolation Forest, DBSCAN или Autoencoder.
Задача не в том, чтобы «опознать вирус», а чтобы заметить жизнь, непохожую на жизнь других.

3.3. Корреляция через временные окна

Потоковые аномалии часто бессмысленны вне контекста времени.
Реальные детекторы строят «окна» по 5–10 минут и анализируют:

• сколько сессий инициировал хост;
• сколько уникальных ASN/IP он тронул;
• насколько сместился профиль объёма.

Если средний ноут делал 10 соединений в минуту, а внезапно 400 — это сигнал exfiltration или сканирования.

3.4. DNS как отражение психологии атаки

Почему DNS — зеркало намерений злоумышленника

DNS — это первое, что «трогает» злоумышленник при выстраивании инфраструктуры.
Психология атаки такова: атакующий всегда стремится к контролю связи, а DNS — первый слой управления.

Любая фаза атаки (от initial access до C2 и exfiltration) так или иначе проходит через DNS:

• На стадии разведки — сканирование поддоменов, dig и массовые PTR-запросы.

• На стадии доставки — загрузка payload’а с временного хоста или домена.

• На стадии закрепления / C2 — запросы для поддержания обратной связи.

• На стадии эксфильтрации — DNS-туннели, TXT-поля, DGA-боты.

  Поэтому DNS остаётся последним «просвечиваемым» слоем — даже при полном HTTPS шифровании и DoH злоумышленнику нужен резолв, и его паттерн неизбежно выдаёт поведение.

Что именно искать — конкретные признаки и почему они возникают

2.1. Высокая энтропия доменов

Пример:

xyzkdoqjaf.com lqzpjsue.net
dbnccjxj.top

Причина:
Это следствие DGA (Domain Generation Algorithm) — алгоритма, который генерирует псевдослучайные доменные имена на основе даты, seed и ключа.
Таким образом, каждый день ботнет/агент пытается связаться с одним из сотен случайных доменов.
Так атака маскирует свой C2, усложняя блокировки по статическому IOC.

2.2. Одинаковая длина субдоменов (TXT-туннели, C2)

Пример:

ahsd82js7sd9j1s.attacker.com kslq29js8dj10sd.attacker.com sjd93kd81ksd01l.attacker.com

Причина:
В DNS-туннелях данные часто кодируются в поддоменах (Base32/Base64). Чтобы шифрованные куски выглядели «естественно» и проходили через резолверы, злоумышленники поддерживают фиксированную длину блока.

Психология: злоумышленник мыслит как инженер — «должно быть надёжно и работать». Он делает всё «по шаблону», чтобы не ломалось → и этот шаблон легко детектировать.

Признак в телеметрии:

• Равномерная длина субдоменов.
• Частота запросов к одному домену с различными субдоменами (но одинаковой длиной).
• Отсутствие реальных ответов (NXDOMAIN или TXT-ответы с данными).

Сложные кампании (APT, CDN-маскировка)

В продвинутых атаках (APT, Cobalt Strike, CloudFront abuse, AzureCDN misuse) DNS становится каналом камуфляжа.

Пример поведения

• Каждый запрос выглядит как «нормальный» к CDN-домену (*.cloudfront.net, *.azureedge.net).
• Но частота — ровно через N секунд.
• IP-ответы — «скачут» по диапазону, хотя легитимные CDN-клиенты так себя не ведут (они используют caching).

Психология:
APT-группы мыслят как шпионы — «раствориться в шуме». Но их ошибка — избыточная регулярность.
Человек, имитирующий случайность, часто создаёт слишком ровные интервалы.

Признак в телеметрии:

• TTL всегда одинаковый (например, 60 сек).
• Частота опроса стабильная ±1 сек.
• ALIAS/IP-ответы не соответствуют реальному распределению CDN (постоянно новые IP).
• Один клиент опрашивает десятки новых поддоменов за короткий промежуток времени.

Дополнительно:
Можно рассчитать coherence-index — отношение стандартного отклонения интервалов к среднему значению. У живых пользователей оно хаотично (>0.5), у ботов/скриптов — низкое (<0.1).

Практический сценарий расследования

1. Фиксируем всплеск DNS-запросов от хоста к редкому TLD (.xyz).
2. Смотрим NXDOMAIN rate → 98 %.
3. Проверяем энтропию доменных имён → 4.3.
4. Фиксируем равномерные длины поддоменов → 15 символов.
5. Коррелируем с Zeek/flow-логами → 1 DNS-запрос каждые 60 сек.
6. EDR-данные: инициатор powershell.exe → вывод: DNS-туннель для C2.

4. Fusion-архитектура: сетевой и хостовый интеллект

Современная модель Threat Hunting = NTA (Network Traffic Analysis) + EDR Telemetry.
Пример цепочки расследования:

Так строятся охоты уровня Tier 3–4, где аналитика опирается не на «сигнатуры», а на сетевую идентичность поведения.

5. Практические фишки уровня SOC

• Dynamic Flow Baselines: обучай норму для каждой подсети. Используй экспоненциальное сглаживание, чтобы учесть суточные циклы.
• TLS Outlier Detection: хост внезапно начал использовать TLS с редкими cipher suites → 90% случаев — кастомный агент.
• Long-lived Connections: постоянные 24/7 соединения без DNS-апдейтов → индикатор туннеля или прокси.
• Entropy Checks: длины доменов с Shannon Entropy >4.5 — подозрение на алгоритмически сгенерированные домены (DGA).
• Cross-layer Correlation: нет ничего мощнее, чем поймать несовпадение между JA3 и User-Agent.

6. Мини-чеклист для охоты без DPI

✅ Собери полную сетевую телеметрию (NetFlow, Zeek, DNS).
✅ Построй базовую модель нормального поведения (по ролям и подсетям).
✅ Добавь фингерпринтинг TLS (JA3, JA3S).
✅ Привяжи данные EDR (PID, процесс, путь).
✅ Введи корреляцию Flow ↔ Endpoint ↔ DNS.
✅ Подключи ML-анализ аномалий по потокам.
✅ Веди playbook расследования для повторных кейсов.
✅ Вноси сигнатуры JA3/доменов в MISP/ThreatFeed.

Итог (конкретно и емко)

• JA3/JA3S — один из сильнейших пассивных сигналов при анализе зашифрованного трафика. Используйте его как часть многоуровневой аналитики — flow, DNS, endpoint.
• Не полагайтесь на один сигнал: делайте базелайнинг, корреляцию и держите механизмы для быстрой проверки контекста.
• Документируйте и обновляйте JA3-базу вашей организации: апдейты TLS-стеков легитимных приложений будут менять «нормы»