Как создать правила для сетевого трафика под будущую угрозу 🤨

Об этом на этой неделе в Китае во время третьего саммита по кибербезопасности, в рамках которого прошла шестая международная антивирусная конференция, рассказала Ксения Наумова, старший специалист отдела сетевой экспертизы антивирусной лаборатории PT ESC. В канале делимся подробностями из доклада 🍸

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

Экзактовые сигнатуры обладают одним несомненным преимуществом — они ловят ровно те вредоносные образцы, на которые были написаны, но это же является их главной слабостью: при даже небольшом изменении какого-либо компонента сетевого взаимодействия правила перестают срабатывать.

Мы решили, что этот недуг можно смело обернуть в преимущество: сигнатуры могут ловить не только экзактовые вредоносы, но и аномальное поведение, которое эти образцы порождают.

Что может являться интересующей нас аномалией?

➡️ Необычные размеры пакетов;
➡️ неизвестные протоколы;
➡️ подозрительные DNS-запросы / подозрительные TLD в DNS;
➡️ скачки трафика / задержки;
➡️ нарушения RFC;
➡️ применение обфускации, кодирования, шифрования;
➡️ и многое другое…

Мы провели небольшой анализ существующих правил на детектирование аномалий в наборе опенсорсных сигнатур Emerging Threats — HUNTING (скриншот 1):

➡️ ~510 правил на XOR-шифрование HTTP-запросов;
➡️ ~50 правил на кодированные в Base64 данные;
➡️ ~50 правил на подозрительные TLD в DNS;
➡️ правила на содержимое в ZIP, эксфильтрацию и т. п.

Показательный пример удачного hunting-правила:

alert http $HOME_NET any -> $EXTERNAL_NET any (sid: 2027117; msg:"ET HUNTING Suspicious POST with Common Windows Process Names - Possible Process List Exfiltration"; flow:established,to_server; http.method; content:"POST"; http.request_body; content:"csrss.exe"; content:"explorer.exe"; fast_pattern; content:"svchost.exe"; content:"lsass.exe"; ...)

А на скриншоте 2 — пример такого подозрительного трафика.

Однако искать аномалии можно не только с помощью открытых правил, но и самостоятельно — например, нарушения RFC, конкретно RFC 2616, определяющего протокол HTTP (скриншот 3). Можно поискать HTTP-запросы, у которых заголовок Referer не содержит схему:

alert http any any -> any any (msg: "SUSPICIOUS [PTsecurity] HTTP header Referer RFC2616 violation"; flow: established, to_server; content: "Referer|3a|"; http_header; content: !"Referer|3a 20|http"; http_header; ...)

В наши сети попадал бэкдор EAGERBEE и другие интересные образцы (скриншот 4).

Или, например, можно поискать простую команду PING внутри GZIP (скриншот 5):

alert tcp any any -> any any (msg: "SUSPICIOUS [PTsecurity] Generic Ping command inside Gzip"; flow: established, to_server; content: "|1f 8b 08 00 00 00 00 00 04 00 0b c8 cc 4b 07 00 c3 92 e7 85 04 00 00 00|"; ...)

По итогам срабатываний и дальнейших исследований к нам попадали SheetRAT и zgRAT (скриншот 6).

Но основная мысль, зафиксированная в докладе, — в использовании корреляции их сработок. Корреляция сработок — понятие не новое, но в контексте сетевого трафика его пока применяют крайне редко; иногда уходят в более сложные реализации защиты и забывают о простых, но действенных подходах.

🫵 Выводы простые: generic-правила, особенно в корреляции друг с другом, могут значительно помогать в детектировании как давно известных, так и абсолютно новых угроз, о которых пока никто не знает. Можно пользоваться открытыми наборами сетевых сигнатур — ET Open, PT Open, а можно смело писать свои.

Happy hunting!

#suricata #network #signature #rules #hunt #detect
@ptescalator

🦈 Смотрим под капот защищенных соединений в Wireshark. Часть 1: TLS

Нашим сетевым экспертам часто бывает нужно расшифровывать трафик TLS-соединений и проанализировать защищенное содержимое. Современные алгоритмы TLS уже очень давно используют схему Ephemeral Diffie–Hellman (EDH), которая не позволяет расшифровывать TLS-сессии закрытым ключом RSA.

Теперь для расшифровки необходимо собирать так называемые сессионные ключи (session keys) средствами самого TLS-клиента или сервера. И за много лет мы собрали несколько лайфхаков, которые работают для большинства анализируемых приложений. Поехали!

1️⃣ Браузеры и консольные утилиты

Для расшифровки браузерных TLS-сессий или консольных утилит, например curl, необходимо установить переменную окружения SSLKEYLOG. Это делается при помощи команды export SSLKEYLOGFILE=/path/to/keylog.log для Linux-систем или через переменные среды (скриншоты 1 и 2) в системах Windows. Теперь браузеры и утилиты будут сохранять сессионные ключи в указанном файле.

2️⃣ Приложения на Go

Настройка дампа ключей в подобных приложениях потребует небольшого патча. Необходимо либо добавить эти строки в код самого приложения (пример).

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

Либо, если в файле явно не определяется tls config, но в самой программе или в библиотеке используется стандартная библиотека crypto/go, можно задать sslkeylog-файл прямо в ней. Мы привели пример diff-файла (common_go.diff) для go version go1.24.4 linux/amd64. После этого достаточно задать путь к keylog-файлу в переменной окружения SSLKEYLOGFILE:

export SSLKEYLOGFILE=/path/to/keylog.log

3️⃣ Приложения на Python

Настройка дампа ключей также работает через установку переменной окружения SSLKEYLOGFILE:

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

4️⃣ Приложения на Node.js

Необходимо просто запустить приложение с ключом tls-keylog

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

Либо задать переменную окружения NODE_OPTIONS и запустить программу в той же консоли:

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

5️⃣ Xray Core

Другие проприетарные приложения могут использовать свои собственные параметры для дампа сессионных ключей. Особенно те, которые реализуют TLS-соединения по-своему. Xray — это целый фреймворк, который поддерживает множество VPN-протоколов, включая VMess, VLESS и XTLS. Благодаря разработчикам ядра Xray собрать сессионные ключи не составит труда. Нужно всего лишь добавить ключ masterKeyLog в конфигурацию исходящего (outbound) подключения.

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

Большинство конфигураций Xray задается при помощи URL, для добавления ключа необходимо поправить JSON-конфигурацию внутри клиента или сервера уже после добавления ключа.

Как использовать полученные session keys

Чтобы расшифровать TLS-сессию в Wireshark, необходимо открыть Edit → Preferences, затем в настройках протокола TLS выбрать файл Master-Secret log filename (скриншот 3, результат на скриншоте 4).

☠️ Ну а в следующей части мы расскажем о расшифровке зашифрованного содержимого протоколов SMB/LDAP/DCERPC с NTLM- и Kerberos-аутентификацией.

Делитесь вашими собственными лайфхаками в комментариях ⬇️

#dfir #tip #tls #network
@ptescalator

🦈 Смотрим «под капот» защищенных соединений в 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