[ << ALL_FEED ]

Как пройти в интернет

Ещё в группе «Индикаторы и C2»

  • Этот ваш Siemens…

    Недавно наши коллеги из Центра промышленной экспертизы Позитива обнаружили на MalwareBazaar один любопытный Windows-образец. Вот его…

  • Операция Chewbacca

    В конце июня команда PT ESC в ходе расследования инцидентов обнаружила новую группу, нацеленную как минимум…

  • Ваш сервер Zimbra под угрозой

    Недавно наша команда PT ESC IR столкнулась с новой атакой ransomware-группировок на почтовые серверы Zimbra с…

  • Он вам не gsocket

    Он вам не gsocket 😑 В ходе расследования одного из инцидентов специалисты PT ESC IR наткнулись…

  • Ищем RAT’ов по их же сертификатам 🕵️

    Коллеги из Censys выкатили разбор семейства AsyncRAT, описав целое генеалогическое древо: AsyncRAT → DCRAT (DarkCrystal RAT)…

Как пройти в интернет 🚶‍♂️

Что делают хакеры, когда интересующий их сегмент сети не имеет доступа в интернет, а подключиться к C2 очень хочется? Правильно: ищут хосты, которые смотрят в разные подсети, и пытаются пробросить каналы управления через них. Если атакуемая инфраструктура сильно сегментирована, такой канал может проходить через много узлов и принимать причудливые формы.

В одном из недавних кейсов хакеры использовали два метода для проброса канала, условно назовем их «простой» и «сложный».

🤯 Начнем со «сложного»

Злоумышленники обнаружили хост, через который был возможен доступ из одной подсети в другую. Но был нюанс: попасть на этот хост можно было только через RDP (remote desktop — удаленный рабочий стол).

Хакеры нашли решение. На прослушивание порта 3389 они повесили своеобразный сплиттер трафика: настоящий трафик RDP перенаправлялся на порт 33389, а весь остальной трафик на порт 3389 проксировался дальше внутрь соседней подсети. Принадлежность пакета к RDP определялась по первым трем байтам — они должны быть равны 03 00 00.

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

Присутствие такой утилиты на хосте выдают (помимо, собственно, наличия исполняемого файла на файловой системе) следующие признаки:

1️⃣ Изменение порта RDP на нестандартный (проверить порт можно в свойствах системы или с помощью команды Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name "PortNumber").

2️⃣ Какой-то «левый» процесс слушает порт 3389.

3️⃣ Подключения пользователей по RDP в такой схеме отображаются как исходящие от localhost. На практике мы видели только IP-адрес 127.0.0.1, но не стоит забывать о том, что вообще-то таких адресов целая подсеть, а еще есть варианты вроде ::1 или даже ::%16777216.

Но имейте в виду, что поменять порт RDP мог админ, а подключения с локалхоста могут говорить и о других вещах, например о наличии туннелей 🙂

💆‍♂️ В чем тогда заключался «простой» способ?

В этом варианте злоумышленники для проксирования трафика использовали функциональность Windows под названием Port Proxy.

В самом простом варианте этот инструмент позволяет создать простой маппинг «откуда пришел пакет — куда его отправить». Проще всего показать это на примере:


netsh interface portproxy add v4tov4 listenport=7000 connectaddress=example.com connectport=443 protocol=tcp

После выполнения этой команды хост начинает слушать порт 7000, а входящие TCP-соединения перенаправляет на example.com:443. Более подробно про эти функции можно почитать в документации Microsoft.

Этот метод хорош тем, что не нужно использовать стороннее ПО. Основное ограничение метода заключается в том, что маппинг статичен, то есть позволяет организовать только жестко заданное перенаправление пакетов.

🕵️‍♀️ Как обнаружить использование такого способа

1️⃣ Детектировать запуск команды netsh interface portproxy add (например, в событиях Sysmon 1 или Security 4688).

Детект в MaxPatrol SIEM: Execute_Malicious_Command

2️⃣ По наличию в реестре ключей в ветке [HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\].

Детект в MaxPatrol SIEM: Port_Forwarding_or_Tunneling

3️⃣ По появлению подозрительных слушающих портов или сетевых подключений у службы IpHelper (процесс C:\Windows\System32\svchost.exe -k NetSvcs -p -s iphlpsvc).

👉 Кстати, в том кейсе злоумышленники умудрились с помощью portproxy построить цепочку длиной в четыре хопа, причем на каждом этапе в проксируемый порт также перенаправлялся трафик от «закладок» на хостах внутри сегмента. Получилось целое «дерево», «корни» которого уходили на сервер C2 в интернете.

Happy hunting!

#Hunt #C2 #Detect #DFIR #SIEM
@ptescalator

Ещё от oUth0R

Ещё от oUth0R

Ещё в группе «Индикаторы и C2»

  • Этот ваш Siemens…

    Недавно наши коллеги из Центра промышленной экспертизы Позитива обнаружили на MalwareBazaar один любопытный Windows-образец. Вот его…

  • Операция Chewbacca

    В конце июня команда PT ESC в ходе расследования инцидентов обнаружила новую группу, нацеленную как минимум…

  • Ваш сервер Zimbra под угрозой

    Недавно наша команда PT ESC IR столкнулась с новой атакой ransomware-группировок на почтовые серверы Zimbra с…

  • Он вам не gsocket

    Он вам не gsocket 😑 В ходе расследования одного из инцидентов специалисты PT ESC IR наткнулись…

  • Ищем RAT’ов по их же сертификатам 🕵️

    Коллеги из Censys выкатили разбор семейства AsyncRAT, описав целое генеалогическое древо: AsyncRAT → DCRAT (DarkCrystal RAT)…