spn что это такое

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

Никогда не создавайте имя участника-службы (SPN) с помощью IP-адреса. Протокол Kerberos использует возможности домена по разрешению DNS. Задание IP-адреса приводит к неиспользованию этих возможностей.

Перед именем экземпляра добавляется символ двоеточия ( : ). Например, если есть главный компьютер с именем SRV01 и именованный экземпляр SSAS-Tabular, то имя участника-службы выглядит как SRV01:SSAS-Tabular.

Регистрация имени участника-службы для виртуальной учетной записи

Как следует из имен, эти учетные записи не присутствуют в Active Directory. Виртуальная учетная запись существует только на локальном компьютере. При подключении ко внешним службам, приложениям и устройствам подключение осуществляется от имени учетной записи локальной машины. Поэтому регистрация имени участника-службы для служб Analysis Services, выполняющихся от имени виртуальной учетной записи, фактически является регистрацией SPN для учетной записи машины.

Пример синтаксиса для экземпляра по умолчанию, запущенного как NT Service\MSOLAPService.

Этот пример демонстрирует синтаксис setspn для стандартного экземпляра служб Analysis Services, запущенного под стандартной виртуальной учетной записью. В данном примере имя хост-компьютера — AW-SRV01. Как было сказано ранее, регистрация имени участника-службы должна содержать учетную запись машины вместо виртуальной учетной записи NT Service\MSOLAPService.

Помните, что нужно добавить две регистрации имени участника-службы: одно для имени NetBIOS, а другое для полного доменного имени хост-компьютера (узла). Разные клиентские приложения используют разные соглашения об именовании узлов при подключении к службам Analysis Services. Наличие двух регистраций имени участника-службы гарантирует учет обеих версий имени узла.

Пример синтаксиса для именованного экземпляра, запущенного как NT Service\MSOLAP$

Регистрация имени участника-службы для учетной записи домена

Использование учетной записи домена для запуска экземпляра служб Analysis Services — это распространенная практика.

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

Пример синтаксиса для экземпляра по умолчанию, запущенного от имени пользователя домена.

Этот пример демонстрирует синтаксис setspn для стандартного экземпляра служб Analysis Services, запущенного от имени учетной записи пользователя домена SSAS-Service в домене AdventureWorks.

Регистрация имени участника-службы для встроенной учетной записи

Хотя подобный метод не рекомендуется, предыдущие установки служб Analysis Service иногда настраиваются для запуска от имени встроенной учетной записи, такой как Network Service, Local Service или Local System.

Пример синтаксиса для экземпляра по умолчанию, запущенного от имени встроенной учетной записи

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

Регистрация имени участника-службы для именованного экземпляра

Именованные экземпляры служб Analysis Services используют динамическое назначение портов, которые определяются службой обозревателя SQL Server. Если используется именованный экземпляр, зарегистрируйте имя участника-службы для службы обозревателя SQL Server и именованного экземпляра служб Analysis Services. Дополнительные сведения см. в документе Имя участника-службы для обозревателя SQL Server требуется, когда устанавливается соединение с именованным экземпляром служб SQL Server Analysis Services или SQL Server.

Пример синтаксиса имени участника-службы для службы обозревателя SQL, запущенной как LocalService.

Класс службы MSOLAPDisco.3. По умолчанию эта служба запускается как NT AUTHORITY\LocalService, а это означает, что регистрация имени участника-службы задается для учетной записи компьютера. В данном примере учетная запись машины — AW-SRV01, что соответствует имени компьютера.

Регистрация имени участника-службы для кластера SSAS

Для кластеров отработки отказа служб Analysis Services имя узла должно быть виртуальным именем, назначенным кластеру. Это сетевое имя SQL Server, указанное во время установки SQL Server при установке служб Analysis Services на основе существующих WSFC. Это имя можно найти в Active Directory. Его также можно найти на | | вкладке ресурсы Диспетчер отказоустойчивости кластеров роли. Имя сервера на вкладке ресурсы должно использоваться в качестве «виртуального имени» в команде SPN.

Синтаксис имени участника-службы для кластера служб Analysis Services

Регистрация имени участника-службы для экземпляров SSAS, настроенных для доступа по протоколу HTTP

В зависимости от требований к решению можно настроить службы Analysis Services для доступа по протоколу HTTP. Если решение содержит IIS как компонент среднего уровня и требуется проверять подлинность с помощью Kerberos, для сервера IIS может потребоваться ручная регистрация имени участника-службы. дополнительные сведения см. в разделе «настройка параметров на компьютере с IIS» в статье настройка SQL Server 2008 Analysis Services и SQL Server 2005 Analysis Services для использования проверки подлинности Kerberos.

С точки зрения регистрации имени участника-службы для экземпляра служб Analysis Services нет разницы между экземплярами, настроенными на использование протокола TCP или HTTP. Подключение к службам Analysis Services из IIS с помощью расширения MSMDPUMP ISAPI всегда производится через TCP-протокол.

Это значит, что можно использовать инструкции по регистрации имени участника-службы из предыдущих разделов, касающихся стандартного или именованного экземпляра. При указании имени узла используйте имя, которое было задано в файле msmdpump.ini при настройке службы для доступа по протоколу HTTP.

Регистрация имени участника-службы для экземпляров SSAS, прослушивающих фиксированные порты

При регистрации имени участника-службы Analysis Services нельзя указать номер порта. Если службы Analysis Services установлены как экземпляр по умолчанию и этот экземпляр настроен на прослушивание фиксированного порта, то теперь нужно настроить его для прослушивания порта (TCP 2383) по умолчанию. Для именованных экземпляров необходимо использовать службу обозревателя SQL Server с динамически назначаемыми портами.

Экземпляр служб Analysis Services может прослушивать только один порт. Использование нескольких портов не поддерживается. Дополнительные сведения о настройке порта см. в разделе Configure the Windows Firewall to Allow Analysis Services Access.

Источник

От учетной записи к полному компрометированию домена

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

Введение

В статье будут продемонстрированы техники, используемые пентестерами, для первоначального проникновения в сеть и последующего полного компрометирования домена без запуска сторонних приложений или повторного применения учетных записей в открытом виде. Мы рассмотрим, как работает среда на базе Windows, когда включен IPv6 (что есть по умолчанию), с целью получения контроля над DNS (при помощи утилиты MITM6) и ретранслирования учетных записей в LDAPS (LDAP поверх TLS), используя инструмент Ntlmrelayx, для создания новых машинных аккаунтов.

При помощи нового машинного аккаунта мы сможем пройти аутентификацию в LDAP и изменить некоторые свойства системы для доступа к целевой машине от имени практически любого пользователя (и даже администратора домена). Технология, которую мы рассмотрим в деталях, представляет собой ограниченное ресурсное делегирование. Впоследствии, чтобы полностью скомпрометировать сеть, мы воспользуемся уязвимостью SpoolService (PrinterBug) с целью принудительной аутентификации из контроллера домена к хосту, находящимся под нашим контролем, где включено неограниченное делегирование. Используя эту технику, мы сможем извлечь билет krbtgt для выгрузки базы данных контроллера домена.

Ресурсное и неограниченное делегирование

Если упростить концепцию делегирования в Kerberos, то можно сказать, что эта технология, позволяющая приложению повторно использовать учетные записи конечного пользователя для доступа к ресурсам, расположенным на другом сервере.

Ограниченное ресурсное делегирование

В документации от Microsoft говорится следующее: «Ограниченное делегирование в Kerberos используется в тех случаях, когда служба фронт-энда и ресурсная служба находятся в разных доменах. Администраторы службы могут настроить новое делегирование, указав аккаунты домена для служб фронт-энда, которые могут олицетворять пользователей в объектах учетных записей служб, связанных с ресурсами». Сей факт означает, что ограниченное ресурсное делегирование может быть сконфигурировано для ресурса или машинной учетной записи и управляется атрибутом (msDSAllowedToActOnBehalfOfOtherIdentity).

Насчет неограниченного делегирования Олег Александров сказал следующее: «Серверу, которому доверяют неограниченное делегирование, позволено олицетворять (практически) любого пользователя любой службы внутри сети. Когда пользователь запрашивает Билет службы (Service Ticket; ST) у контроллера домена для какой-либо службы, что разрешено при делегации, контроллер домена копирует клиентский TGT (Ticket Granting Ticket; Билет на выдачу билетов) и прикрепляет этот билет к билету службы, который впоследствии презентуется соответствующей службе. Когда пользователь получает доступ к службе при помощи билета, пользовательский TGT извлекается и сохраняется в службе сервера LSASS для последующих нужд».

Соответственно, если мы контролируем хост, где включено неограниченное делегирование, то можем извлекать TGT и повторно использовать в любой службе из процесса LSASS. Более подробно о делегации в Kerberos рассказывается в статье Wagging the Dog.

Что такое SPN

SPN (Service Principal Name; Первичное имя сервиса) представляет собой уникальный идентификатор экземпляра службы. SPN’ы используются во время аутентификации в Kerberos для связи экземпляра службы с аккаунтом авторизации в службе, что позволяет клиентскому приложений запрашивать у службы аутентификацию учетной записи, даже если у клиента нет имени аккаунта.

Более подробно эта тема рассматривается в следующих статьях:

IPV6 в Windows и WPAD

Протокол IPv6 активирован по умолчанию во всех версиях Windows, начиная с Vista. Во время загрузки Windows сначала ищется конфигурация для DHCP, а затем для WPAD. При реализации атаки мы получим контроль над DNS при помощи утилиты MITM6 с целью перенаправления всего трафика на наш DNS сервер, и когда хост начнет искать конфигурацию для WPAD через DNS, целевые машины будут подключаться к нашему прокси-серверу с целью аутентификации на нашем сервере, где используется скрипт ntlmrelax. Кроме того, учетные записи будут ретранслироваться в LDAPS для создания новых машинных аккаунтов.

Полная схема атаки

Чтобы применить вышеуказанные концепции и техники на практике, была создана тестовая среда, состоящая из Windows Server 2012R2 (контроллер домена), клиентского хоста с Windows 10 (Mark-pc), AppServer с Windows 10 и нашей машины с Kali Linux, откуда будет осуществляться атака. Предполагается, что наша рабочая система находится в той же подсети вместе с целевыми машинами.

Рисунок 1: Полная схема атаки

Демонстрация атаки

Как было упомянуто выше, предполагается, что наша рабочая система (с Kali Linux) находится в одной подсети с целевыми машинами. Реализация атаки начинается с проверки подписывания в SMB при помощи утилиты CrackMapExec, поскольку в нашем случае требуется, чтобы эта функция была отключена.

CrackMapExec можно загрузить из официального репозитория или установить, используя следующую команду:

apt-get install crackmapexec

Начинаем с проверки IP-конфигурации нашей машины:

Рисунок 2: IP-конфигурация рабочей системы

Затем запускаем CrackMapExec с целью проверки подписывания и детектирования живых хостов:

Рисунок 3: Сканирование сети при помощи CrackMapExec

Теперь мы знаем, что имя внутреннего домена – «contoso». Кроме того, было обнаружено три живых хоста, на двух из которых подпись в SMB отключена (в контроллере домена подпись в SMB включена по умолчанию). Далее проверяем, включено ли разрешение имен LLMNR и NBT-NS. Для решения этой задачи я буду запускать ответчик в течение короткого промежутка времени и проверять, смогу ли поймать какие-либо запросы.

Рисунок 4: Ответчик

Как видно на рисунке выше, ответчик начал ловить запросы и отвечать на разрешения имен LLMNR и NBT-NS, из чего мы делаем вывод, что эта функция работает.

Также, поскольку мы создаем новый машинный аккаунт, нужно проверить, настроен ли LDAP поверх TLS (LDAPS). Запускаем nmap и сканируем контроллер домена на предмет присутствия открытого порта 636:

Рисунок 5: Сканирование на предмет присутствия LDAPS

Теперь, когда все требования для реализации атаки выполняются, переходим к использованию фреймворка MITM6 и скрипта ntlmrelayx для ретранслирования перехваченных учетных записей в LDAPS и создание нового машинного аккаунта на основе перехваченных данных. Чтобы успешно осуществить запланированный сценарий, нужно добавить цели в белый список, которые будут перезагружены (клиентские машины). Наш же сервер с MITM6 используется для перенаправления трафика от целевых систем на подконтрольный нам DNS сервер.

Для упрощения задачи я добавил в белый список машину Mark-pc, которая будет перезагружаться из моей рабочей среды.

Рисунок 6: Конфигурация MITM6

Далее запускаем скрипт ntlmrelayx с указанием протокола LDAPS и контроллера домена, как показано на рисунке ниже.

Рисунок 7: Подключаем ретранслирование в LDAPS

После перезагрузки Mark-pc этой машине был назначен IP адрес с нашего DNS сервера. Как видно на скриншоте ниже, IPv6 DNS обладает более высоким приоритетом, чем IPv4 DNS.

Рисунок 8: У IPv6 DNS выше приоритет

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

Рисунок 9: Результаты работы ntlmrelayx

Как только ntlmrelayx успешно пройдет аутентификацию в LDAPS при помощи ретранслируемых аккаунтов, то далее будет пытаться создать новую машинную учетную запись на базе тех аккаунтов и модифицировать атрибут «msDS-AllowedToActOnBehalfOfOtherIdentity» на машине Mark-pc, чтобы была возможность выступать от имени любого пользователя этой системы.

Рисунок 10: Успешная аутентификация и создание новой машинной учетной записи

Сразу же возникает вопрос: «Почему возможно создание новой учетной записи в домене на базе перенаправляемых аккаунтов?». Судя по скриншоту ниже, любой пользователь в Active Directory может создать до 10 машинных учетных записей.

Рисунок 11: Квота на создание машинных аккаунтов

При просмотре пользователей контроллера домена и компьютеров видно, что атака завершена успешно и ntlmrelayx добавил новую машину.

Рисунок 12: Машинные аккаунты контроллера домена

Кроме того, ntlmrelayx будет выгружать информацию о домене, если мы подключимся к LDAPS, используя ретранслируемую учетную запись (ldapdomaindump).

Рисунок 13: Выгрузка информации о домене

Поскольку у нас появился машинный аккаунт и модифицировано свойство «msDS-AllowedToActOnBehalfOfOtherIdentity», то теперь можно воспользоваться скриптом getST.py из проекта Impacket для запроса билета службы и получения привилегий администратора домена (contoso\Administrator) на машине Mark-pc.

Рисунок 14: Запрос билета службы

Как видно на рисунке выше, мы успешно запросили билет службы при помощи машинного аккаунта от имени учетной записи «Administrator» и сохранили полученные данные в файл CCACHE.

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

Рисунок 15: Пользователи домена

Теперь добавляем Kerberos-билет из файла CCACHE в переменную окружения «KRB5CCNAME» при помощи команды «export»:

Далее при помощи скрипта Impacket Wmiexec будем запускать команды с привилегиями администратора домена. Обратите внимание, что CIFS SPN пригоден только для доступа к общим файловым ресурсам (например, при помощи Smbclient), однако Wmiexec осуществит попытку автоматической смены на HOST SPN, чтобы мы могли выполнять WMI-запросы и команды.

Рисунок 16: Запуск скрипта wmiexec на машине Mark-pc

После успешного завершения откроется полуинтерактивный шелл с привилегиями «contoso\Administrator».

Рисунок 17: На машине Mark-pc появился шелл

При помощи билета Kerberos-службы и скрипта Impackеt SecretsDump выгружаем локальные хэши.

Рисунок 18: Выгрузка локальных хэшей на машине Mark-pc

Далее при помощи утилиты lsassy удаленно выгружаем учетные записи в открытом виде, используя локальные административные хэши.

Рисунок 19: Выгрузка учетных записей в открытом виде на машине Mark-pc

После первоначального закрепления внутри сети попробуем выполнить полное компрометирование домена. Начинаем с изучения ранее выгруженной информации при помощи ntlmrelayx.

Сразу же замечаем, что AppServer настроен на неограниченное делегирование, и в случае компрометирования мы сможем экспортировать и повторно использовать билеты из памяти или при помощи уязвимости SpoolService заставить контроллер домена подключиться к AppServer, а затем выгрузить базу данных, используя TGT.

Рисунок 20: Компьютеры домена

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

Снова возвращаемся к выгруженной информации и находим интересную группу домена с именем «Servers Admins».

Рисунок 21: Группы домена

Для нахождения членов этой группы воспользуемся скриптом bloodhound.py, учетной записью mark и данными, импортированными в приложение BloodHound.

Рисунок 22: Выполнение скрипта Bloodhound.py

Используя запросы в Bloodhound, мы обнаружили, что аккаунт машины Mark-pc$ является частью группы «Servers Admins».

Рисунок 23: Члены группы Servers Admins

Попробуем воспользоваться аккаунтом машины Mark-pc$, полученным при помощи скрипта Secretsdump, и, используя CrackMapExec проверим, какие у нас будут привилегии на AppServer.

Рисунок 24: Проверка доступа при помощи CrackMapExec

Как видно нас скриншоте выше, мы успешно прошли аутентификацию в AppServer, и теперь при помощи скрипта Impacket Wmiexec передадим хэши аккаунтов машины с целью получения шелла и выполнения команд на AppServer.

Рисунок 25: Запуск скрипта wmiexec на AppServer

Поскольку мы запускаем команды с локальными административными привилегиями, то воспользуемся скриптом Secretsdump для выгрузки локальных хэшей, так как нам нужны Kerberos-ключи машинного аккаунта для эксплуатации уязвимости SpoolService.

Рисунок 26: Запуск скрипта secretsdump на AppServer

Теперь добавляем новый SPN в AppServer при помощи скрипта addspn из проекта krbrelayx, который нужен, чтобы наша жертва (в данном случае – контроллер домена) искала этот SPN и перенаправляла трафик на подконтрольный нам сервер.

При помощи машинного аккаунта в AppServer добавляем новый SPN (HOST/attacker1.contoso.local) в AppServer$.

Рисунок 27: Добавление SPN при помощи скрипта addspn

Затем при помощи скрипта dnstool.py (тоже из проекта krbrelayx) в контроллере домена добавляем новую DNS-запись для только что созданного SPN (attacker1.contoso.local), которая будет указывать на нашу машину с Kali Linux.

Рисунок 28: Добавление новой DNS-записи

После обновления DNS запускаем Nslookup вместе с именем attacker1.contoso.local с целью проверки, что резолвинг происходит на IP-адрес нашей машины с Kali Linux.

Рисунок 29: Проверка DNS

Теперь настраиваем сервер на перехват krbtgt TGT при помощи скрипта krbrelayx и AES265-ключа от машины AppServer.

Рисунок 30: Настройка перехвата при помощи скрипта krbrelayx

Затем при помощи скрипта printerbug.py (который можно найти там же в проекте krbrelayx) принуждаем контроллер домена на поиск SPN HOST/Attacker1.contoso.local, который инициирует обратный вызов к нашей рабочей системе с Kali Linux, поскольку ранее мы настроили DNS-записи соответствующим образом. Во время аутентификации мы использовали аккаунт машины AppServer$.

Рисунок 31: Запуск скрипта printerbug.py

По результатам успешной отработки скрипта мы получим перехваченный билет krbtgt TGT на нашем сервере, который впоследствии будет расшифрован при помощи AES256-ключа машинного аккаунта для AppServer$ и сохранен в формате CCACHE.

Рисунок 32: Перехват TGT

Теперь добавляем в файл CCACHE в наши переменные окружения при помощи команды export и при помощи скрипта Impackets-secretsdump выгружаем базу данных контроллера домена.

Рисунок 33: Выгрузка базы данных контроллера домена

Теперь у нас есть все NTLM-хэши для аккаунтов домена contoso, и мы можем воспользоваться утилитой Impacket wmiexec для передачи этих хэшей и получения шелла в домене contoso.

Рисунок 34: Получение шелла

Меры по предотвращению угрозы

Вышеуказанные техники, касательно ретранслирования учетных записей и получения контроля над DNS-сервером, были использованы при стандартной конфигурации, которая есть сразу же после установки Windows. Защита от подобного рода атака – отключение преобразование имен LLMNR и NBT-NS, использование подписи в LDAP и привязка канала для LDAP поверх TLS. Что касается printerbug, старайтесь избегать неограниченного делегирования везде, где возможно, и отключите службу принтеров Spooler или заблокируйте исходящее подключение к порту 445 в критически важных системах.

Источник

• анудеск что это за программа →