как настроить доверительные отношения между доменами

Атаки на трасты между доменами

Рано или поздно в ходе пентеста встает задача компрометации всего леса — при условии, что есть какие-либо права в одном из доменов. В такие моменты возникает куча вопросов о трастах, их свойствах и самих атаках. Попробуем во всем этом разобраться.

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

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

Более наглядно типы доверий между доменами проиллюстрированы на картинке ниже.

Транзитивность (Transitivity)

Транзитивность нужна для определения доверия за пределами двух доменов, между которыми оно было сформировано, и используется для расширения отношений доверия с другими доменами. Если мы добавляем к домену дочерний домен, между родительским и дочерним доменами устанавливаются двусторонние доверительные отношения. Эти отношения транзитивны, т.е. если домен A доверяет домену D и домен D доверяет домену E, то домен A доверяет и домену E.

Нетранзитивное доверие можно использовать для отказа доверия с другими доменами.

Направление (Direction)

Путь доверительных отношений — это ряд доверительных отношений между доменами, к которому должны поступать запросы на проверку подлинности. Иными словами, прежде чем аутентифицировать пользователя, определяется доверие между доменами. Чтобы пользователи домена A могли получить доступ к ресурсам домена D, домен D должен доверять домену A.

Направление доверия бывает двух типов:

Двустороннее доверие — это комбинация двух однонаправленных доверительных отношений. В двунаправленном доверии между доменами A и B их пользователи имеют доступ к ресурсам обоих доменов. Такой тип доверия транзитивен.

Направление доверия всегда противоположно направлению доступа. Показательная схема от Microsoft ниже:

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

Kerberos между доверенными доменами

Рассмотрим пример. Client пытается получить доступ к Server.

Изменения начинаются с пункта 4: появляется inter-realm TGT-тикет, так называемый реферальный тикет, который шифруется/подписывается inter-realm ключом, создаваемым из доверенного пароля. Доверенный пароль задается при установке доверительных отношений и известен обоим контроллерам домена. Используя inter-realm TGT-тикет, пользователь домена 1 может запросить TGS-тикет для доступа к ресурсам домена 2.

NTLM между доверенными доменами

Атаки на трасты между доменами

Итак, для проведения атаки нам потребуется информация о доверительных отношениях в нашем домене.

Перечисление трастов

Существует 3 основных метода для перечисления трастов в домене:

Перечисление осуществляется с помощью вызова функции DsEnumerateDomainTrusts, которая возвращает структуру DS_DOMAIN_TRUSTSA. При использовании данного метода возвращается SID и GUID целевого домена, флаги и атрибуты, характеризующие текущие доверительные отношения в домене.

BloodHound собирает информацию с помощью метода Win32 API.

Используется метод GetCurrentDomainиз пространства имен [System.DirectoryServices.ActiveDirectory.Domain], который возвращает экземпляр класса System.DirectoryServices.ActiveDirectory.Domain. В этом классе реализован метод GetAllTrustRelationships, который возвращает все доверительные отношения для текущего домена.

Использование данного метода реализовано в модуле Get-DomainTrust в PowerView.

Одним из преимуществ этого метода является его простота. Информацию легко читать и понимать, но ее объем значительно меньше, чем при выполнении перечисления другими методами.

Информация о доверительных отношениях домена хранится в Active Directory как objectClass класса trustedDomain.

PowerView по умолчанию использует данный метод.

Имея информацию о доменах и типах доверия, можно переходить непосредственно к самой атаке. Рассмотрим 2 варианта:

С правами администратора одного из доменов

В зависимости от домена, который был скомпрометирован, можно выделить несколько векторов атак:

Стоит отметить, что для успешной реализации всех векторов необходимо двустороннее доверие между доменами.

1. Эксплуатация SID History

SID History был введен для облегчения миграции пользователей из одного домена в другой. Атрибут cодержит в себе предыдущие SID объекты. Каждый раз, когда объект перемещается из одного домена в другой, создается новый SID, который становится objectSID. Предыдущий SID добавляется в свойство sIDHistory.

В каждом лесу есть группа пользователей Enterprise Admins, которая существует только в root-домене и имеет права локального администратора на контроллерах домена всех Child-доменов леса. Впервые данная атака был продемонстрирована Sean Metcalf на BlackHat USA 2015. Суть атаки в том, что мы выпускаем Golden-тикет с добавлением дополнительного SID группы Enterprise Admins. Это выполняется путем добавления ExtraSids в структуре KERB_SID_AND_ATTRIBUTES, которая отправляется в структуре KERB_VALIDATION_INFO.

В impacket есть скрипт, который все это автоматизирует.

2. Golden Ticket + Enterprise Admin Group

Имея права администратора в Root-домене, мы можем создать Golden Ticket с добавлением пользователя в группу Enterprise Admins (519).

Как было написано выше, Enterprise Admin имеет права локального администратора на DC Child-доменов. Таким образом нам удастся скомпрометировать в лесу все Child-домены.

3. Эксплуатация билетов доверия

Атака особенно актуальна, когда служба ИБ заметила угрозу и сменила пароль krbtgt 2 раза. В этом случае мы сможем создавать golden-тикеты, используя доверенный пароль между доменами.

4. Printer Bug

В Windows Print System Remote Protocol (MS-RPRN) есть метод RpcRemoteFindFirstPrinterChangeNotification(Ex), включенный по умолчанию, который позволяет принудительно выполнить аутентификацию на любом компьютере с запущенной службой Spooler на указанном хосте по протоколу Kerberos либо NTLM. В случае c NTLM мы можем выполнить NTLM-relay, либо начать брутить пароль компьютера (никогда не сбрутите). В случае с Kerberos необходима скомпрометированная машина с неограниченным делегированием. Тогда мы сможем забрать TGT-тикет и развить атаку.

Рисунок ниже демонстрирует этапы, показанные на видео.

У нас нет прав администратора домена

Немного теории. Carlos Garsia в своем докладе привел отличную таблицу, которая иллюстрирует свойства разных типов групп.

Because of the way that groups are enumerated by the Global Catalog, the results of a back-link [i.e. memb search can vary, depending on whether you search the Global Catalog (port 3268) or the domain (port 389), the kind of groups the user belongs to (global groups vs. domain local groups).

1. Пользователи другого домена, которые имеют права локального администратора на машинах в нашем домене

Поиск пользователей из другого домена, являющихся локальными администраторами на хостах в нашем домене в BloodHound:

2. Пользователи из других доменов, состоящие в группах домена пользователя. Группы, содержащие пользователей из другого домена

Как уже говорилось выше, в глобальный каталог реплицируются пользователи, состоящие только в группах типа Universal. Для демонстрации этой особенности выполним запрос групп в глобальном каталоге, содержащих хотя бы одного пользователя и прямой ldap-запрос к контроллеру домена.

При выполнении запроса к глобальному каталогу, мы видим только одну группу Universal Group c типом AD Universal из домена one.jet.lab.

Если мы выполним прямой LDAP-запрос к домену one.jet.lab, то увидим другие группы с типом AD Domain local и AD Global.

Это важно учитывать при выполнении перечисления пользователей и групп.

Источник

Руководство по Создание исходящего доверия леса для локального домена в доменных службах Azure Active Directory

В средах, где нельзя синхронизировать хэши паролей или где пользователи используют только смарт-карты для входа в систему, поскольку они не знают своего пароля, в доменных службах Azure Active Directory (Azure AD DS) можно использовать лес ресурсов. Лес ресурсов использует одностороннее исходящее отношение доверия между Azure AD DS и одной или несколькими локальными средами AD DS. Это отношение доверия позволяет пользователям, приложениям и компьютерам проходить проверку подлинности в локальном домене из управляемого домена Azure AD DS. В лесе ресурсов локальные хэши паролей не синхронизируются.

В этом руководстве описано следующее:

Если у вас еще нет подписки Azure, создайте учетную запись Azure, прежде чем начинать работу.

Предварительные требования

Для работы с этим учебником требуются следующие ресурсы и разрешения:

Активная подписка Azure.

Связанный с вашей подпиской клиент Azure Active Directory, синхронизированный с локальным или облачным каталогом.

Управляемый домен Azure AD DS, созданный с использованием леса ресурсов и настроенный в клиенте Azure AD.

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

Для управляемого домена также необходимо использовать как минимум SKU уровня Корпоративный. При необходимости измените номер SKU для управляемого домена.

Вход на портал Azure

В этом учебнике вы создадите и настроите исходящее доверие леса из Azure AD DS с помощью портала Azure. Чтобы начать работу, войдите на портал Azure. Для изменения экземпляра Azure AD DS требуются разрешения глобального администратора.

Рекомендации по работе с сетями

Для виртуальной сети, в которой размещен лес ресурсов Azure AD DS, требуется сетевое подключение к локальным доменным службам Active Directory. Для приложений и служб также требуется подключение к виртуальной сети, в которой размещается лес ресурсов Azure AD DS. Сетевое подключение к лесу ресурсов Azure AD DS должно быть непрерывным и работать стабильно. В противном случае пользователи могут не пройти проверку подлинности или не получить доступ к ресурсам.

Перед настройкой доверия леса в Azure AD DS убедитесь, что сеть между Azure и локальной средой соответствует следующим требованиям:

Настройка DNS в локальном домене

Чтобы правильно разрешить управляемый домен из локальной среды, может потребоваться добавить серверы пересылки к существующим DNS-серверам. Если в локальной среде не настроено взаимодействие с управляемым доменом, выполните следующие действия на рабочей станции управления для локального домена AD DS.

Выберите Пуск > Администрирование > DNS.

Выберите зону DNS, например aaddscontoso.com.

Выберите Серверы условной пересылки, щелкните правой кнопкой мыши и нажмите Создать сервер условной пересылки.

Укажите другой DNS-домен, например contoso.com, а затем введите IP-адреса DNS-серверов для этого пространства имен, как показано в следующем примере:

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

Чтобы создать сервер условной пересылки, нажмите кнопку ОК.

Создание входящего доверия леса в локальном домене

Для локального домена AD DS требуется входящее доверие леса для управляемого домена. Это доверие необходимо настроить вручную в локальном домене AD DS. Его нельзя создать на портале Azure.

Чтобы настроить входящее доверие в локальном домене AD DS, выполните на рабочей станции управления следующие действия с локальным доменом AD DS:

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

Создание исходящего доверия леса в Azure AD DS

Теперь, когда в локальном домене AD DS настроено разрешение управляемого домена и создано входящее доверие леса, создайте исходящее доверие леса. Это последний шаг для создания отношения доверия между локальным доменом AD DS и управляемым доменом.

Чтобы создать исходящее доверие для управляемого домена на портале Azure, выполните следующие действия.

На портале Azure найдите и выберите Доменные службы Azure AD, а затем выберите управляемый домен, например aaddscontoso.com.

В меню в левой части управляемого домена выберите Отношения доверия, а затем нажмите кнопку + Добавить, чтобы добавить доверие.

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

Введите отображаемое имя, идентифицирующее доверие, а затем локальное DNS-имя доверенного леса, например onprem.contoso.com.

Укажите тот же пароль отношения доверия, который использовался для настройки входящего доверия леса для локального домена AD DS в предыдущем разделе.

Укажите по крайней мере два DNS-сервера для локального домена AD DS, например 10.1.1.4 и 10.1.1.5.

Сохраните исходящее доверие леса, когда оно будет готово, нажав кнопку Сохранить.

Если доверие леса больше не требуется для среды, выполните следующие действия, чтобы удалить его из Azure AD DS.

Проверка подлинности ресурсов

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

Локальная проверка подлинности пользователя в лесу ресурсов Azure AD DS

У вас должна быть виртуальная машина Windows Server, присоединенная к управляемому домену. Используйте эту виртуальную машину для тестирования того, что локальный пользователь может пройти проверку подлинности на виртуальной машине. При необходимости создайте виртуальную машину Windows и присоедините ее к управляемому домену.

Подключитесь к виртуальной машине Windows Server, присоединенной к лесу ресурсов Azure AD DS, используя Бастион Azure и учетные данные администратора Azure AD DS.

Используйте команду runas для проверки подлинности в качестве пользователя из локального домена. В следующей команде замените userUpn@trusteddomain.com именем участника-пользователя из доверенного локального домена: Команда запрашивает пароль пользователя:

Используйте whoami /fqdn в новой командной строке, чтобы просмотреть различающееся имя пользователя, прошедшего проверку подлинности из локальной службы Active Directory.

Доступ локального пользователя к ресурсам в лесу ресурсов Azure AD DS

Используя виртуальную машину Windows Server, присоединенную к лесу ресурсов Azure AD DS, можно протестировать сценарий, в котором пользователи могут получать доступ к ресурсам, размещенным в лесу ресурсов, при проверке подлинности на компьютерах в локальном домене с использованием данных пользователей из локального домена. В следующих примерах показано, как создавать и тестировать различные распространенные сценарии.

Предоставление совместного доступа к файлам и принтерам

Подключитесь к виртуальной машине Windows Server, присоединенной к лесу ресурсов Azure AD DS, используя Бастион Azure и учетные данные администратора Azure AD DS.

Откройте Параметры Windows, затем найдите и откройте страницу Центр управления сетями и общим доступом.

Щелкните Изменить дополнительные параметры общего доступа.

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

Закройте Центр управления сетями и общим доступом.

Создание группы безопасности и добавление участников

Откройте оснастку Пользователи и компьютеры Active Directory.

Щелкните правой кнопкой мыши имя домена, выберите команду Создать, а затем — пункт Organizational Unit (Подразделение).

В поле имени введите LocalObjects, а затем нажмите кнопку ОК.

Выберите и щелкните правой кнопкой мыши LocalObjects в области навигации. Выберите команду Создать, а затем — пункт Группа.

Введите FileServerAccess в поле Имя группы. Для параметра Области действия группы выберите значение Локальная в домене, а затем нажмите кнопку ОК.

В области содержимого дважды щелкните FileServerAccess. Выберите Члены, Добавить, а затем — Расположения.

Выберите локальные доменные службы Active Directory в представлении Расположение, а затем нажмите кнопку ОК.

Введите Пользователи домена в поле Enter the object names to select (Введите имена объектов для выбора). Щелкните Проверить имена, укажите учетные данные для локальных пользователей Active Directory, а затем нажмите кнопку ОК.

Необходимо указать учетные данные, так как отношение доверия является только односторонним. Это означает, что пользователи из управляемого домена AD DS не могут обращаться к ресурсам либо искать пользователей или группы в доверенном (локальном) домене.

Группа Пользователи домена из локальной среды Active Directory должна быть членом группы FileServerAccess. Нажмите кнопку ОК, чтобы сохранить группу и закрыть окно.

Создание общей папки для доступа между лесами

Проверка аутентификации между лесами для ресурса

Войдите в систему на компьютере Windows, присоединенном к локальному домену Active Directory, используя учетную запись пользователя из локальной среды Active Directory.

Чтобы проверить разрешение на запись, щелкните правой кнопкой мыши в папке, выберите команду Создать, а затем — пункт Текстовый документ. Используйте имя по умолчанию Новый текстовый документ.

Если разрешения на запись заданы правильно, будет создан текстовый документ. Следующие шаги открывают, изменяют и удаляют файл соответствующим образом.

Чтобы проверить разрешение на чтение, откройте Новый текстовый документ.

Чтобы проверить разрешение на изменение, добавьте текст в файл и закройте Блокнот. При появлении запроса на сохранение изменений нажмите кнопку Сохранить.

Чтобы проверить разрешение на удаление, щелкните правой кнопкой мыши Новый текстовый документ и выберите команду Удалить. Нажмите кнопку Да для подтверждения удаления файла.

Дальнейшие действия

В этом руководстве вы узнали, как выполнять следующие задачи:

Дополнительные сведения о типах лесов в Azure AD DS см. в статьях о лесах ресурсов и о том, как работают доверия леса в Azure AD DS.

Источник