spn что это такое
Имена субъектов-служб
Имя участника-службы (SPN) — это уникальный идентификатор экземпляра службы. Имена участников-служб используются при проверке подлинности Kerberos для связывания экземпляра службы с учетной записью входа службы. Это позволяет клиентскому приложению запросить проверку подлинности учетной записи службы, даже если у клиента нет имени учетной записи.
Если на компьютерах в лесу установлено несколько экземпляров службы, то каждый экземпляр должен иметь свое имя участника-службы. Каждый экземпляр службы может иметь несколько имен участников-служб при наличии нескольких имен, которые могут использоваться клиентами для проверки подлинности. Например, SPN всегда включает имя главного компьютера, на котором выполняется экземпляр службы, поэтому экземпляр службы может зарегистрировать имя участника-службы для каждого имени или псевдонима узла. Дополнительные сведения о формате SPN и создании уникального имени субъекта-службы см. в разделе форматы имен для уникальных имен участников-служб.
Прежде чем служба проверки подлинности Kerberos сможет использовать имена участников-служб для проверки подлинности службы, имя участника-службы должно быть зарегистрировано в объекте учетной записи, используемом экземпляром службы для входа в систему. Данное имя субъекта-службы может быть зарегистрировано только в одной учетной записи. Для служб Win32 установщик службы задает учетную запись входа при установке экземпляра службы. Затем установщик формирует имена участников-служб и записывает их в качестве свойства объекта Account в домен Active Directory Services. При изменении учетной записи входа в экземпляр службы имена участников-служб должны быть повторно зарегистрированы в новой учетной записи. Дополнительные сведения см. в разделе как служба регистрирует свои имена участников-служб.
Когда клиент хочет подключиться к службе, он определяет местонахождение экземпляра службы, составляет для него основное имя, подключается к службе и представляет ей это имя для проверки подлинности. Дополнительные сведения см. в разделе как клиенты составлять имена участников-служб Службы.
Spn что это такое
Всем привет, сегодня хочу вам рассказать как настраивать SPN в Active Directory, на примере SPN для MS SQL Server 2012. В процессе загрузки свежее установленного экземпляра SQL Server в его логе можно обнаружить ошибку регистрации SPN, в случае если службы SQL Server запускаются от имени пользовательской доменной учетной записи. Необходимо зарегистрировать имя участника-службы (SPN — Service Principal Name) для учетной записи службы SQL Server, чтобы в работе службы могла использоваться проверка подлинности с помощью протокола Kerberos.
Для того чтобы получить информацию о том, что на доменной учетной записи, от имени которой производится запуск SQL Server действительно не зарегистрировано SPN связанных с SQL с помощью утилиты SetSPN выполним команду:
В нашем примере KOM-AD01-DB03 — это имя сервера SQL, а s-KOM-AD01-DB03-SQL01 — это имя пользовательской доменной учетной записи, из под которой запускаются службы SQL Server на этом сервере.
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-02
Как мы видим, ни на учетной записи компьютера ни на учетной записи пользователя нет SPN содержащих указатели MSSQLSvc. Помимо утилиты SetSPN мы можем воспользоваться оснасткой “AD Users and Computers” (dsa.msc) с включенным режимом отображения дополнительных компонент…
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-03
открыв свойства соответствующей учётной записи и перейдя на вкладку редактирования атрибутов можно посмотреть и изменить значение атрибута servicePrincipalName
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-04
Особенности работы с Kerberos аутентификацией в SQL Server (и в частности управление SPN) рассмотрены в статье KB319723 — How to use Kerberos authentication in SQL Server
Для того чтобы обеспечить нужное для корректной работы Kerberos содержание атрибута servicePrincipalName можно пойти двумя путями:
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-05
В диалоговом окне «Дополнительные параметры безопасности» (Advanced Security Settings) нажмём кнопку «Добавить» (Add)
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-06
введём SELF и в открывшемся окне перейдём на закладку «Свойства» (Properties). В окне выбора области применения выберем пункт «Только этот объект» (This object only) и в списке разрешений отметим два пункта:
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-07
Сохраним внесённые изменения и затем, при запуске службы SQL Server, сможем убедиться в том, что в журнале регистрации событий появилась запись об успешном создании SPN
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-08
а так же увидим что вывод утилиты SetSPN изменился
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-09
Как удалить SPN
Вот пример ситуации когда нужно удаление. Был раньше сервер virt105 и использовался под одни нужды, сервер удален. После по этому же имени virt105 подняли другой сервер, и столкнулись с тем, что SPN уже был занят. Вот запрос на проверку SPN у virt105
Далее попытка его зарегистрировать, и видим, что он уже есть на учетную запись Семина Ивана
После удаления старого SPN, по новому все зарегистрировалось.
От учетной записи к полному компрометированию домена
В статье будут продемонстрированы техники, используемые пентестерами, для первоначального проникновения в сеть и последующего полного компрометирования домена
Введение
В статье будут продемонстрированы техники, используемые пентестерами, для первоначального проникновения в сеть и последующего полного компрометирования домена без запуска сторонних приложений или повторного применения учетных записей в открытом виде. Мы рассмотрим, как работает среда на базе 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 в критически важных системах.