BloodHound 4.0.1 — твоя ищейка в Active Directory и Azure. Часть 1

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

Это один из самых важных инструментов, который используется практически во всех внутренних тестированиях на проникновение. Проект активно развивается и дополняется новыми фичами.

Этот инструмент представляет интерес как для сотрудников ИБ, изучающих риски в инфраструктуре Active Directory, так и для атакующих, поскольку даёт наглядное графовое представление связей и сущностей в Active Directory. Инструмент позволяет быстро найти всех доменных администраторов; найти все хосты, на которых залогинены доменные администраторы; выстроить цепочку от компьютера атакующего до компьютера на котором есть сессия доменного администратора и много другой полезной информации. BloodHound представляет собой одностраничное Javascript веб приложение. Для сбора данных используется сценарий PowerShell PowerView.

Детально ознакомиться с этим удобным фреймворком можно в официальном репозитории на Github.

Совсем недавно вышла новая версия BloodHound.

В третьей версии добавились три новых типа атак, была улучшена
производительность графического интерфейса, добавлена поддержка Neo4j 4.0.

Новые типы атак

В BloodHound добавлено три новых типа атак: управление GMSA, управление OU и SIDHistory. Конфиги, связанные с этими атаками, по умолчанию доступны любому пользователю, прошедшему проверку в домене, и каждый тип атаки может использоваться с практическими инструментами.

Управление GMSA

Group Managed Service Accounts (GMSA) — это специальные учетные записи служб в Active Directory, решающие многие проблемы. Пароли для GMSA состоят из 128 символов, управляются контроллерами домена и по умолчанию автоматически меняются каждые 30 дней.

Суть GMSA заключается в том, что администраторам необходимо указать, кому разрешено читать плэинтекстовые пароли для GMSA. Предположим, что наш пользователь Dwight Hohnstein может прочитать пароль для SQL GMSA. В графическом интерфейсе BloodHound вы можете увидеть это как путь атаки с компа Dwight до компьютера SQL:

Если мы можем войти в контекст пользователя DHOHNSTEIN, то мы можем получить плеинтекстовый пароль для GMSA-SQL01, а затем в перейти и к SQL01.CONTOSO.LOCAL. На данный момент уже существует несколько инструментов для извлечения паролей GMSA, но ни один из них не работает исколючительно из памяти компьютера. Именно поэтому на C# был разработан GMSAPasswordReader, делающий именно то, что должен: чтение паролей GMSA. Вот пример использования GMSAPassword.exe с функцией execute-assembly тулкита Cobalt Strike для получения NT-хэша для GMSA-SQL01:

Теперь, с NT-хэшем пароля учетной записи GMSA, вы можете выдать себя за пользователя (используя, например, overpass-the-hash) и перейти к SQL01.CONTOSO.LOCAL.

Для дальнейшего чтения о GMSA, (см. рецензию Michael Grafnetter здесь)

Контроль OU

Иногда админы AD задают ACEs на OU (организационные подразделения) применимые к OU, или OU и его наследственные OU, но не наследственные объекты пользователя, компьютера или группы. Мы видели контроль OU через свзку групповых политик с OU, и возможность связи нежелательных GPO с OU, которыми вы управляете. С этим есть несколько проблем, наиболее критическая из которых то, что вы должны иметь возможность не дать нежелательному серверу GP корректно размещать ваши файлы групповой политики. Делать это через коммандную строку очень непросто. Контролируя OU, вы можете задать ACE на OU будет унаследован вложенными объектами!

Например, представим, что Justin Bui имеет полный доступ к Workstation Admins OU, пользовательский объект Josh Prager:

Далее следует очень простая атака: из контекста JBUI мы можем добавить новый ACE к OU администратора рабочей станции, который унаследует JPRAGER. Это возможно благодаря мощному командлету в PowerView New-ADObjectAccessControlEntry.

Как только этот новый ACE будет создан, мы можем получить доступ к пользователю JPRAGER из контекста JBUI точно так же, как мы могли это делать после обновления ACL BloodHound 1.3: сбросить его пароль или выполнить целевую атаку.

Когда вы применяете ACE к OU и устанавливаете его для наследования дочерних объектов, вы можете выбрать его применение ко всем объектам, объектам определенного класса и даже контролировать, применяется ли он к прямым дочерним элементам OU и их наследникам.

SIDHistory

SIDHistory включен в качестве вектора атаки в BloodHound. Как ред тимер, вы можете сначала подумать о золотых тикетах, нарушающих функциональность истории SID, но на самом деле мы рассматриваем пользователей, компьютеры и группы, у которых уже есть SID, указанный в параметре SIDHistory их объекта в AD. Эти параметры могут быть заполнены при миграции объекта из одного домена Active Directory в другой. Для сохранения прав и привилегий, которыми обладает участник, объект в новом домене будет содержать идентификаторы безопасности для любой группы, которой принадлежит участник в старом домене.

Допустим, пользовательский объект Josiah Massari был перенесен в домен CONTOSO из домена FABRIKAM. В домене FABRIKAM юзер Josiah принадлежал к группе администраторов рабочей станции, которая имеюзую права локального администратора на всех рабочих станциях в FABRIKAM. В домене CONTOSO пользовательский объект для Josiah будет содержать SID для группы администраторов рабочей станции в FABRIKAM. Теперь, всякий раз, когда Josiah проходит аутентификацию, его тикет Kerberos будет содержать SID для этой группы в части ExtraSID в PAC тикета, предоставляя ему те же права и привилегии, которыми обладает эта группа.

Итог: Josiah Massari фактически остается членом группы администраторов рабочей станции в FABRIKAM, даже если его пользовательский объект больше не принадлежит этой группе. Дополнительные сведения об этом см. в блоге Шона Меткалфа: Скрытая стойкость Active Directory # 14: SID.

В графическом интерфейсе BloodHound описанная ситуация будет выглядеть так:

Фактически, вы можете представить «HasSIDHistory» так же, как вы уже представляете свойство «MemberOf». В контексте JMASSARI вы получите права администратора на обеих рабочих станциях в домене FABRIKAM.

Предостерегаем: если доверие между доменами CONTOSO и FABRIKAM обеспечивает фильтрацию SID, эта атака не будет работать, поскольку идентификаторы SID в части ExtraSID PAC тикета kerberos JMASSARI будут игнорироваться доменом FABRIKAM. Для получения дополнительной информации о фильтрации SID см. пост в блоге Уилла Шредера «Руководство по атаке на трасты в домейне».

Улучшения производительности

Ощущаются улучшения производительности по сравнению со старыми версиями в двух основных областях: сбор данных с помощью SharpHound и импорт данных с помощью BloodHound GUI. В SharpHound вы ощутите увеличение скорости сбора LDAP примерно на 25-30%. Сбор хостов происходит немного медленнее, но с гораздо большей точностью. Количество проб при распознавания хостов значительно увеличилось по сравнению с предыдущей версией.

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

Дополнительные удобства

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

Всякий раз, когда вы щелкаете по узлу в графическом интерфейсе BloodHound, вкладка информации для этого узла заполняется и начинает отображать все виды информации об этом объекте:

Некоторые из этих запросов очень легко обрабатываются базой данных, например получение даты и времени «последнего пароля» от пользовательского узла или даже получение количества компьютеров, на которых у пользователя есть делегированные права администратора группы.

Некоторые из этих запросов на самом деле довольно тяжелые, особенно когда вы начинаете работать с базами данных выше определенного размера, скажем, более 30 000 узлов. В частности, любое использование shorttestPath (), где начальным или конечным узлом может быть любой другой узел (в отличие от определенного узла) в графе, приведет к огромному нагрузке на БД.

Выполняется 3 таких запроса каждый раз, когда вы щелкали по пользовательскому узлу: права локального администратора, управление переходными объектами и контроллеры переходных объектов. Мы изменили поведение по умолчанию. Теперь вместо тех запросов, которые выполняются каждый раз, когда вы нажимаете на пользовательский узел (и тем самым нагружают БД), появилась кнопка «play», которую вы можете нажать, чтобы выполнить запрос:

Большой проблемой в графическом интерфейсе BloodHound являлась визуализация больших графиков, состоящих из сотен узлов. Это связано с тем, что фреймворк полагаетсся на библиотеки визуализации графиков с открытым исходным кодом — которые используют проц, а не GPU для визуализации.

Решение состояло в том, чтобы перехватить данные, возвращаемые из neo4j, определить, может ли такой объем данных привести к зависанию графического интерфейса в течение длительного времени, а затем предоставить пользователю возможность выбора действий:

“Cancel” отменит ваши. «Save Data» покажет диалоговое окно, в котором вы можете сохранить необработанные данные графика в формате JSON. «Draw Graph» будет продолжать пытаться визуализировать узлы в обычном режиме.

Для работы BloodHound требуется три набора данных из Active Directory:1. Кто и где залогинен2. Кто имеет административные права и где3. Какие пользователи и группы в какие группы входят. Для сбора этих данных в большинстве случаев не требуется какой-либо привилегированный доступ или выполнение кода на удалённых системах. Сбор данных может быть проводится с помощью PowerShell сценария PowerView, либо с помощью утилиты SharpHound.exe, которая находится в папке Ingestors. Я рассмотрю вариант сбора данных с помощью SharpHound.exe.

В моём примере SharpHound.exe находится в папке C:BloodHoundBloodHound-masterIngestors:

Собранные данные сохраняются в CSV файлы в эту же папку.

Документация по работе с утилитой здесь: https://github.com/BloodHoundAD/SharpHound

Для работы требуется .Net 3.5. Запускаться должна из контекста доменного пользователя.При запуске без параметров выполняется сбор членов групп AD, доверительных отношений, локальных администраторов и текущих сессий. Результат работы выводится в CMD:

Запускаем BloodHound.exe и подключаемся к базе данных.

Данные, которые были загружены для примера можно удалить, нажав кнопку Clear Database.

Затем загружаем полученные CSV файлы в чистую базу данных. Для этого в меню инструментов справа нажимаем кнопку Upload Data:

На этом загрузка данных завершена и можно приступать к анализу полученной информации.

BloodHound 4.0.1 — мощнейший инструмент для аудита AD стал еще мощнее с новыми векторами атаки и общими улучшениями. BloodHound – это мощнейший фреймворк, позволяющий изучать и эксплутировать AD, незаменимый для уважающего себя редтимера.

Bloodhound сразу предоставляет такие возможности:

• найти аккаунты всех доменных администраторов;
• найти хосты, на которых залогинены доменные администраторы;
• построить кратчайший путь от хоста атакующего до хоста с сессией доменного админа.

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

Информация, собираемая bloodhound:

• Group — Performs group membership collection
• LocalAdmin — Performs local admin collection
• RDP — Performs Remote Desktop Users collection
• DCOM — Performs Distributed COM Users collection
• GPOLocalGroup — Performs local admin collection using Group Policy Objects
• Session — Performs session collection
• ComputerOnly — Performs local admin, RDP, DCOM and session collection
• LoggedOn — Performs privileged session collection (requires admin rights on target systems)
• Trusts — Performs domain trust enumeration
• ACL — Performs collection of ACLs
• Container — Performs collection of Containers;
• DcOnly — Performs collection using LDAP only. Includes Group, Trusts, ACL, ObjectProps, Container, and GPOLocalGroup
• All — Performs all Collection Methods except GPOLocalGroup and LoggedOn
• SearchForest — Search all the domains in the forest instead of just your current one
• Domain — Search a particular domain. Uses your current domain if null (Default: null)
• Stealth — Performs stealth collection methods. All stealth options are single threaded
• SkipGCDeconfliction — Skip Global Catalog deconfliction during session enumeration. This can speed up enumeration, but will result in possible inaccuracies in data
• ExcludeDc — Excludes domain controllers from enumeration (avoids Microsoft ATA flags)
• ComputerFile — Specify a file to load computer names/IPs from
• OU — Specify which OU to enumerate

Продолжение следует...

Источник: m.vk.com

Комментарии: