Active Directory Bloodhound Windows Атака Взлом Кибератаки

BloodHound 4.0.1 — твоя ищейка в Active Directory и Azure

BloodHound 4.0.1 — твоя ищейка в Active Directory и Azure

Если кто не знает, 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:\BloodHound\BloodHound-master\Ingestors:

Собранные данные сохраняются в 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:

В качестве сборщиков информации выступают SharpHound.exe (требуется установленный .NET v3.5) и написанный на powershell скрипт SharpHound.ps1. Также есть сборщик, написанный сторонним разработчиком на Python, — Bloodhound-python.

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

Из коробки доступны 12 запросов:

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

Neo4j имеет REST API. Существуют различные утилиты, которые могут подключаться к базе и использовать полученные данные:

Рассмотрим некоторые из них.

CypherDog

CypherDog — оболочка BloodHound, написанная на powershell. Включает в себя 27 командлетов.

Список командлетов
Примеры использования
По умолчанию для доступа к базе neo4j требуется аутентификация. Отключить аутентификацию можно, отредактировав файл neo4j.conf. В нем необходимо раскомментировать строку dbms.security.auth_enabled=false. Но так делать не рекомендуется, поскольку любой пользователь сможет подключиться к базе по адресу 127.0.0.1:7474 (конфигурация по умолчанию). Более подробно об аутентификации и авторизации в neo4j можно прочитать тут.

GoFetch

GoFetch использует граф, созданный в bloodhound для планирования и выполнения атаки.

Пример графа в Bloodhound
Логика работы GoFetch
Запуск атаки

.\Invoke-GoFetch.ps1 -PathToGraph .\pathFromBloodHound.json

gt-generator

gt-generator, используя данные BloodHound, упрощает создание golden-тикетов. Для получения golden-тикета необходимы только имя пользователя и хеш пароля пользователя KRBTGT.

python gt-generator.py -s 127.0.0.1 -u user -p pass administrator <KRBTGT_HASH>

PowerView

PowerView — Powershell-фреймворк, входящий в состав PowerSploit. Ниже приведен список некоторых командлетов, которые помогут при сборе информации о домене.

Список командлетов

Adidnsdump

При использовании интегрированного DNS в Active Directory любой пользователь домена может запросить все DNS-записи, установленные по умолчанию.

Используемый инструмент: Adidnsdump.

Атаки на домен

Теперь, имея информацию о домене, мы переходим к следующей фазе тестирования на проникновение — непосредственно к атаке. Рассмотрим 4 потенциальных вектора:

  1. Roasting
  2. Атака через ACL
  3. Делегирование Kerberos
  4. Abusing GPO Permissions

Roasting

Этот вид атаки нацелен на протокол Kerberos. Можно выделить 2 вида атаки типа Roasting:

Kerberoast

Впервые атака была продемонстрирована пользователем timmedin на DerbyCon в 2014 году (video). При успешном проведении атаки мы сможем перебрать пароль сервисной УЗ в офлайн-режиме, не боясь блокировки пользователя. Довольно часто у сервисных учетных записей бывают избыточные права и бессрочный пароль, что может позволить нам получить права администратора домена.
Чтобы понять суть атаки, рассмотрим, как работает Kerberos.

1. Пароль преобразуется в NTLM-хеш, временная метка шифруется хешем и отправляется на KDC в качестве аутентификатора в запросе TGT-тикета (AS-REQ). Контроллер домена (KDC) проверяет информацию пользователя и создает TGT-тикет.

2. TGT-тикет шифруется, подписывается и отправляется пользователю (AS-REP). Только служба Kerberos (KRBTGT) может открыть и прочитать данные из TGT-тикета.

3. Пользователь представляет TGT-тикет контроллеру домена при запросе TGS-тикета (TGS-REQ). Контроллер домена открывает TGT-тикет и проверяет контрольную сумму PAC.

4. TGS-тикет шифруется NTLM-хешем пароля сервисной учетной записи и отправляется пользователю (TGS-REP).

5. Пользователь предоставляет TGS-тикет компьютеру, на котором запущена служба (AP-REQ). Служба открывает TGS-тикет с помощью своего NTLM-хеша.

6. Доступ к сервису предоставлен (AS-REP).

Получив TGS-тикет (TGS-REP), мы можем подобрать пароль сервисной учетной записи в офлайн-режиме. Например, с помощью hashcat.

Согласно RFC396, для протокола Kerberos зарезервировано 20 типов шифрования. Типы шифрования, которые используются сейчас, в порядке приоритета:

В последних версиях Windows по умолчанию используется шифрование AES. Но для совместимости с системами ниже Windows Vista и Windows 2008 server необходима поддержка алгоритма RC4. При проведении атаки всегда сначала производится попытка получения TGS-тикета с шифрованием RC4_HMAC_MD5, который позволяет быстрее перебирать пароли, а затем с остальными. Harmj0y провел интересное исследование и выяснил, что если в свойствах пользователя указать поддержку шифрования только Kerberos AES128 и AES256, Kerberos-тикет все равно выдается с шифрованием RC4_HMAC_MD5.

Отключать RC4_HMAC_MD5 необходимо на уровне домена.

Атака Kerberoasting имеет 2 подхода.

1. Старый метод. TGS-тикеты запрашиваются через setspn.exe или .NET System.IdentityModel.Tokens.KerberosRequestorSecurityToken класса Powershell, извлекаются из памяти с помощью mimikatz, далее конвертируются в нужный формат (John, Hashcat) и перебираются.

2. Новый метод. machosec заметил, что класс KerberosRequestorSecurityToken имеет метод GetRequest, который извлекает зашифрованную часть с паролем из TGS-тикета.

Инструменты для проведения атаки:

1) Поиск SPN-записей

2) Запрос TGS-тикета

Посмотреть текущие закешированные тикеты можно командой klist.

Распространенные SPN-записи
3) Экспорт тикетов:

Пример автоматизированного выполнения всех 3-ех пунктов:

BloodHound 4.0.1 – что нового?

С появлением новой версии пришла поддержка Azure.

Всего было добавлено 10 новых типов узлов:

Image for post
Новые типы узлов в BloodHound 4

Подробнее о новшествах можно посмотреть в этом видео:

С полным списком нововведений можно ознакомится в официальной документации: https://bloodhound.readthedocs.io/en/latest

Помимо этого обновлению подвергся и графический интерфейс:

Image for post
Image for post

Добавился и новый сборщик данных AzureHound.

AzureHound – это новый сборщик данных для BloodHound, который специально собирает данные от клиента Azure и подписчиков, доверяющих этому клиенту. AzureHound и SharpHound собирают данные из различных источников, но их выходные данные полностью совместимы друг с другом: вы можете импортировать данные AzureHound и SharpHound из одной базы данных в другую.

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

Image for post

Использовать AzureHound очень просто. Сначала откройте новое приглашение PowerShell от имени администратора, установите модули Microsoft Azure и выполните аутентификацию для целевого клиента:

Image for post
Image for post

Заключение от разработчиков

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

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

Я покажу и расскажу вам то о чём не пишет журнал “Хакер” и не рассказывают или просто не знают другие каналы. На канале @cybersecs ты найдешь подборку лучших статей и видеоматериалов на тему кибербезопасности. Все, от аудита Wi-Fi до вскрытия автомобилей (если вы потеряли ключи). А также культура, креатив и горячие новости с авторскими коментариями.

Очень злой админ
Очень злой админ Автор статьи

Админ сайта. Публикует интересные статьи с других ресурсов, либо их переводы. Если есть настроение, бывает, что пишет и что-то своё.