Учетная запись службы kdc

Содержание
  1. Проверка подлинности kerberos в Active Directory
  2. Проверка подлинности kerberos в Active Directory
  3. Идентификация и доступ в Active Directory
  4. Протокол аутентификации kerberos
  5. Детальная проверка kerberos от начала логирования
  6. Компоненты Kerberos в Windows 2000
  7. Центр распределения ключей KDC
  8. База данных учетных записей
  9. Политика Kerberos
  10. Делегирование аутентификации
  11. Предварительная аутентификация
  12. Поставщик поддержки безопасности Kerberos
  13. Кэш-память удостоверений
  14. Разрешение имен DNS
  15. Транспорт IP
  16. Шесть атак на AD, которые нельзя не заметить
  17. Pass-the-Hash
  18. Mimikatz
  19. Brute Force
  20. net user /domain
  21. Kerberoasting
  22. PsExec
  23. Семь заклинаний атакующих для захвата Active Directory
  24. Стадия 1. Разведка
  25. PowerView
  26. SPN Scan
  27. Remote Sessions Enumeration
  28. Стадия 2. Продвижение по AD
  29. Overpass-the-Hash
  30. Как детектить
  31. Golden Ticket
  32. Как детектить по событиям
  33. WMI Remote Execution
  34. Как детектить
  35. Детект по трафику
  36. Рекомендации к стадиям 1-3
  37. Стадия 4. Захват домена
  38. DCShadow
  39. Схема атаки
  40. Как детектить
  41. Заключение

Проверка подлинности kerberos в Active Directory

Проверка подлинности kerberos в Active Directory

Добрый день уважаемые читатели, не так давно у меня на работе была задача по настройке групп доступности SQL на Windows кластере, там клиентам сделали красивый веб-инструментарий, все замечательно, теперь клиент ждет следующего развития ситуации, а именно настройка и внедрение механизма Single Sign-On (SSO) или по русски единая точка аутентификация, мы с вами уже с ней знакомились при настройке Vmware vCenter Server. Данный механизм работает на протоколе шифрования kerberos, о котором мы и поговорим. Мы рассмотрим как происходит проверка подлинности kerberos в Active Directory, так как понимание принципов работы, поможет вам в реализации единой точки аутентификации.

Идентификация и доступ в Active Directory

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:

  • Она должна хранить информацию, о всех объектах Active Directory, среди которых: пользователи, группы безопасности, компьютеры, принтеры и другие объекты идентификации. Под объектом идентификации (identity) подразумевается, некое представление сущности, в задачи которой входит выполнение каких-либо действий в корпоративной сети. Простой пример, есть пользователь Вася и он работает с документами в общей папке на сервере. Эти документы имеют защиту на доступ, который определяет список контроля доступа (Access Contro l List, ACL). Доступом у нужным файлам, управляет подсистема безопасности сервера, где лежит папка, и при обращении к ней он производит сравнение объекта идентификации пользователя с теми объектами, которые присутствуют в его списке ACL, и уже на основании этого, он принимает решение предоставить или запретить пользователю доступ. Так как службы, компьютеры, группы и другие объекты выполняют определенные вещи в локальной сети, то у каждого из них есть свой объект идентификации. Данный объект содержит много информации, уникальной для каждого из них, например, имя пользователя, его идентификатор безопасности (Security Identifier, SID), пароль. Так, что хранилище объектов идентификации, является неотъемлемой частью Identity and Access. Все данные в Active Directory, располагаются в каталоге AD, которым управляет контроллер домена.
  • Проверка подлинности объекта идентификации. Тут общий принцип такой, когда пользователь обращается к документу, то сервер его ему не покажет, пока тот, не подтвердит подлинность объекта идентификации, который фигурирует в запросе. Чтобы все это сделать, у пользователя есть некая секретная информация, которая известна ему и инфраструктуре IDA, вот эти данные как раз и сравниваются с теми, что есть в хранилище объектов идентификации в момент проверки подлинности.

Протокол аутентификации kerberos

Чем хороша операционная система Windows, так это тем, что она очень унифицированная, за счет интерфейса SSPI (Security Support Provider Interface). SSPI – это механизм операционной системы Windows в задачи которого идет, предоставление приложениям не зависеть от различных решений протоколов аутентификации, позволяя работать абсолютно с любыми из них, если перефразировать, то любое приложение может использовать любой протокол аутентификации. Еще очень большой плюс интерфейса SSPI, то что он позволяет изолировать сетевой транспорт от протоколов аутентификации, если по простому, то эти протоколы становятся независимыми от протоколов передачи данных по сети, и приложению вообще до лампочки, какой из них использовать.

Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI

Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.

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

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

Ключ службы (service key) – тут все просто, очень часто системные администраторы для запуска службы создают отдельного доменного пользователя, в следствии чего служба получит его ключ, но если она запускается под учетной записью системы (LocalSystem), то получит ключ компьютера.

Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.

  • Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.

  • Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.

Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.

Еще очень важным моментом, является тот фактор, что служба KDC, должна точно знать к какому именно сервису идет обращение и каким ключом шифрования производить обработку. Для этого есть такой механизм, как Service Principal Names, по сути это уникальный идентификатор службы, который будет прописан в вашей базе Active Directory. Из требований к нему, он должен быть уникален в рамках леса. Каждая служба, которая будет использовать Kerberos, должна иметь зарегистрированный SPN. Без правильно настроенного идентификатора протокол для этой службы или сервера работать не будет.

Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.

Как производится настройка SPN мною уже была описана в одной из статей.

Детальная проверка kerberos от начала логирования

Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:

  • Человек видит поля ввода логина и пароля у себя на компьютере
  • Компьютер получив от пользователя первичные данные делает запрос к контроллеру домена, а точнее к службе Key Distribution Center, где передает KDC имя пользователя в открытом виде, имя домена и текущее время на рабочей станции, еще раз напоминаю, что оно не должно отличаться от времени на контроллере домена более ,чем на 5 минут. Значение текущего времени передается в зашифрованном виде, и будет выступать аутентификатором. Напоминаю, что ключ шифрования (пользовательский ключ) формируется из пароля пользователя, как результат хеширования.

  • Служба KDC видит обращение с компьютера и начинает поиск пользователя в Active Directory, проверяет его пользовательский ключ и расшифровывает аутентификатор, если по русски она получает время отправления запроса. После чего Key Distribution Center создает два тикета. Первый это сессионный ключ, он нужен для шифрования данных между клиентом и KDC. Второй тикет, это билет на получение билета (Ticket-Granting Ticket (TGT)), как только он появился у пользователя, тот сможет запрашивать тикеты для сервисов и серверов. Сам TGT билет состоит из таких частей: копия ключа сессии, время окончания жизни билета и имя пользователя. TGT шифруется с использованием мастер ключа самой службы Key Distribution Center, поэтому пользователь не может его расшифровать.
  • Как только эти билеты сформированы Key Distribution Center шифрует аутентификатор пользователя (time stamp) и сессионный ключ, с помощью пользовательского ключа и спокойно передает их пользователю.
Читайте также:  Чай ахмад отзывы экспертов

  • Так как у пользователя есть его, пользовательский ключ, он спокойно расшифровывает билеты от Key Distribution Center и проверяет аутентификатор. В итоге он теперь обладает и ключем сессии и TGT ключом, теперь первый этап Kerberos закончен и пользователю больше не нужно в этой сессии заказывать эти билеты.
  • Далее клиент хочет получить доступ на сервис, так как у него уже есть ключ на получение других ключей (TGT), для доступа к сервису он предоставляет KDC, свой Ticket-Granting Ticket и штамп времени, которые шифрует сессионным ключом.
  • KDC получает этот запрос и билеты, расшифровывает их используя свой ключ. Контроллер домена подтверждает, что запрос поступил именно от нужного пользователя.

  • Следующим шагом Key Distribution Center, генерирует два тикета (Service Ticket (TGS)), один для обратившегося клиента, а второй для сервиса, к которому клиент обращается. Каждый из тикетов, будет содержать имя пользователя, кто просит доступ, кто должен получить запрос, штамп времени, рассказывающий, когда создан тикет, и срок его жизни, а так же новый ключ Kcs. Kcs – это ключ для сервиса и клиента, в задачи которого входит обеспечение безопасного взаимодействия между ними. Далее KDC шифрует билет сервиса, используя для этого системный ключ сервера и вкладывает этот билет внутрь билета клиента, у которого так же есть свой Kcs ключ.
  • Теперь все это дело шифруется сессионным ключом и передается клиенту.

  • Клиент получает билет, расшифровывает его с помощью сессионного ключа и видит свой TGS тикет, и Kcs сервиса, клиент не может прочитать Kcs предназначенный для сервиса

  • Теперь клиент формирует штамп времени и шифрует его Kcs ключом, отправляет его вместе с билетом, TGS предназначенным для него.

  • Когда сервер с сервисом, получает эту информацию, он сразу видит пакет от KDC предназначенный для него с ключом TGS (Kcs). Он расшифровывает им штамп времени от клиента.
  • Так как у обоих участников есть TGS ключ, они могут быть обо уверены, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован Kcs . В случае необходимости ответа сервера клиенту, сервер воспользуется ключом Kcs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить Kcs.

Посетителей: 41595 | Просмотров: 70715 (сегодня 0) Шрифт:

Компоненты Kerberos в Windows 2000

Центр распределения ключей KDC

В операционной системе Windows 2000 Центр распределения ключей (Key Distribution Center, KDC) реализован как служба домена. В качестве базы данных учетных записей он использует Active Directory. Кроме того, некоторые данные о пользователях поступают в него из глобального каталога (Global Catalog).

Как и в других реализациях протокола Kerberos, центр KDC Windows 2000 представляет собой единый процесс, объединяющий две службы:

  • Служба аутентификации Authentication Service (AS). Эта служба выдает билеты на выдачу билетов (билеты TGT). Прежде, чем получить билет на обслуживание, сетевой клиент должен запросить первоначальный билет TGT, обратившись для этого к службе аутентификации того домена, где находится учетная запись пользователя.
  • Служба выдачи билетов Ticket-Granting Service (TGS). Эта служба выдает билеты на доступ к другим службам своего домена или к службе выдачи билетов доверяемого домена. Чтобы обратиться в службу TGS, клиенту нужно сначала войти в контакт со службой выдачи билетов того домена, где находится учетная запись службы, представить свой билет TGT и запросить нужный билет. Если у клиента нет билета TGT, который открывает доступ к данной службе выдачи билетов, он может воспользоваться процессом переадресации (referral process). Начальной точкой этого процесса является служба того домена, где находится учетная запись пользователя, а конечной – служба выдачи билетов домена, где находится учетная запись требуемой службы.
  • Центр KDC, как и служба каталогов Active Directory, имеется в каждом домене. Обе службы автоматически запускаются подсистемой LSA (Local Security Authority – распорядитель локальной безопасности), которая установлена на контроллере домена. Они работают в пространстве процессов этого распорядителя. Ни одну из этих служб остановить невозможно. Чтобы гарантировать постоянный доступ к KDC и Active Directory, в Windows 2000 предусмотрена возможность развертывания в каждом домене нескольких равноправных контроллеров домена. При этом запросы на аутентификацию и на выдачу билета, адресованные службе KDC данного домена, может принимать любой контроллер домена.

    В доменах Windows 2000 служба KDC является абонентом безопасности. Как и предусмотрено документом RFC 1510, в этом качестве она выступает под именем krbtgt. Учетная запись абонента безопасности для нее создается автоматически при организации нового домена; эту запись нельзя ни изменить, ни переименовать. Пароль учетной записи KDC также присваивается автоматически, а затем регулярно меняется на плановой основе вместе с паролями доверенных учетных записей домена (domain trust account). Пароль учетной записи KDC используется при вычислении секретного ключа, необходимого для шифрования и расшифрования генерируемых этой службой билетов TGT. Пароль же доверенной учетной записи домена необходим для расчета междоменных (межобластных) ключей, которые используются для шифрования билетов переадресации.

    Все экземпляры службы KDC одного домена используют единую учетную запись абонента безопасности с именем krbtgt. При обращении к центру распределения ключей домена клиент должен указать как имя абонента безопасности krbtgt, так и имя домена. Эти сведения приводятся и в билетах, где идентифицируют службу, выдавшую данный билет. Подробная информация о формах имен и адресных конвенциях приведена в документе RFC 1510.

    База данных учетных записей

    База данных, которая необходима службе KDC для получения информации относительно абонентов безопасности, хранится в каталоге Active Directory. Каждый абонент здесь представлен в виде учетной записи. Криптографические ключи, применяемые для связи с пользователем, компьютером или службой, хранятся в виде атрибутов объекта учетной записи конкретного абонента безопасности.

    Серверами службы каталога Active Directory являются только контроллеры доменов. На каждом из них хранится копия каталога, в которую можно вносить изменения. Это позволяет создавать новые учетные записи, изменять пароли и корректировать состав групп, обратившись на любой контроллер домена. Изменения, внесенные в одну реплику каталога, автоматически переносятся на все другие его реплики. Правда, Windows 2000 не использует для этой цели протокол репликации Kerberos. Копирование и распространение информации, хранящейся в Active Directory, производится посредством собственного протокола децентрализованной репликации (multi-master replication protocol), разработанного корпорацией Microsoft , причем пересылка ее осуществляется по защищенным каналам между контроллерами доменов.

    Физическим хранением информации об учетных записях управляет агент DSA (Directory System Agent – агент системы каталога). Этот защищенный процесс интегрирован с подсистемой LSA, работающей на контроллере домена. Клиенты службы каталога никогда не получают прямого доступа к хранилищу с данными об учетных записях. Любой клиент, которому нужна информация из каталога, должен воспользоваться для подключения к DSA интерфейсом ADSI (Active Directory Service Interface – интерфейс служб Active Directory). Лишь после этого он может искать, читать и записывать объекты и их атрибуты.

    Запросы на доступ к объектам или атрибутам каталога подлежат проверке в системе управления доступом Windows 2000. Подобно объектам файлов и папок в файловой системе NTFS, объекты Active Directory защищаются посредством ACL (Access Control List – список контроля доступа), где содержится информация о том, кто и каким способом имеет право обращаться к объектам. Правда, в объектах Active Directory, в отличие от файлов и папок, список контроля доступа имеется для каждого атрибута. Самым секретным элементом любой учетной записи, конечно же, является пароль. В объекте учетной записи атрибут пароля хранит не сам пароль, а криптографический ключ, полученный на его основе, однако этот ключ представляет для взломщика не меньшую ценность. По этой причине доступ к атрибуту пароля предоставляется исключительно владельцу учетной записи. Такого права не имеет никто другой, даже администратор. Прочесть информацию о пароле или изменить ее могут только процессы с привилегией Trusted Computer Base, которые работают в контексте безопасности LSA.

    В Windows 2000 приняты меры и против возможного взлома учетной записи изнутри, то есть, злоумышленником с доступом к резервным копиям доменного контроллера. Чтобы помешать этому, атрибут пароля в объекте учетной записи подвергается второму шифрованию с использованием системного ключа. Этот криптографический ключ может храниться на сменном носителе, для которого нетрудно предусмотреть дополнительные меры защиты, либо на контроллере домена, но под защитой механизма дисперсии. Где хранить системный ключ, – выбирает администратор, одновременно определяя алгоритм шифрования атрибутов пароля.

    Политика Kerberos

    В среде Windows 2000 политика Kerberos определяется на уровне домена и реализуется службой KDC домена. Она сохраняется в каталоге Active Directory как подмножество атрибутов политики безопасности домена. По умолчанию вносить изменения в политику Kerberos имеют право только члены группы администраторов домена.

    В политике Kerberos предусматриваются:

  • Максимальный срок действия пользовательского билета (Maximum user ticket lifetime). Под «пользовательским билетом» здесь имеется в виду билет на выдачу билетов (билет TGT). Значение задается в часах и по умолчанию равно 10 час.
  • Максимальное время, в течение которого допускается обновление пользовательского билета (Maximum lifetime that a user ticket can be renewed). Задается в сутках; по умолчанию составляет 7 суток.
  • Максимальный срок действия служебного билета (Maximum service ticket lifetime). Под «служебным билетом» здесь имеется в виду сеансовый билет. Значение этого параметра должно быть более 10 минут, но менее значения Maximum user ticket lifetime. По умолчанию оно равно 10 час.
  • Максимально допустимое отклонение в синхронизации компьютерных часов (Maximum tolerance for synchronization of computer clocks). Указывается в минутах; по умолчанию равно 5 мин.
  • Проверка ограничений при входе пользователя в систему (Enforce user logon restrictions). Если этот пункт помечен флажком, служба KDC анализирует каждый запрос на сеансовый билет и проверяет, имеет ли данный пользователь право на локальный вход в систему (привилегия Log on Locally) или на доступ к запрашиваемому компьютеру через сеть (привилегия Access this computer from network). Такая проверка занимает дополнительное время и может замедлить предоставление сетевых услуг, поэтому администратору предоставляется право ее отключения. По умолчанию она включена.
  • Делегирование аутентификации

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

    Читайте также:  Советский аудио разъем 5 контактов

    Предварительная аутентификация

    По умолчанию служба KDC требует проведения предварительной аутентификации всех учетных записей, что предельно затрудняет атаки с подбором паролей. Однако такая функция может вызвать проблемы совместимости с другими реализациями протокола Kerberos, поэтому предусмотрена возможность ее отключения в отдельных учетных записях.

    Поставщик поддержки безопасности Kerberos

    Протокол аутентификации Kerberos реализован в форме поставщика поддержки безопасности (security support provider, сокращенно SSP) – динамически подключаемой библиотеки, входящей в состав операционной системы. В Windows 2000 предусмотрен также поставщик SSP для протокола NTLM. По умолчанию оба эти компонента загружаются подсистемой LSA на компьютер Windows 2000 одновременно с загрузкой операционной системы. Каждый из этих поставщиков позволяет производить аутентификацию как входа в сеть, так и клиент-серверных подключений. Какой поставщик будет использован в том или ином конкретном случае, зависит от возможностей компьютера, с которым устанавливается связь, однако в первую очередь система всегда пытается воспользоваться поставщиком Kerberos SSP.

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

    Системные службы и приложения транспортного уровня обращаются к SSP через интерфейс SSPI (Security Support Provider Interface – интерфейс поставщика поддержки безопасности). Он представляет собой интерфейс Win32®, позволяющий просмотреть список доступных на системе поставщиков, выбрать один из них и использовать его для организации аутентифицированного подключения. Выполнение всех этих функций производится в SSPI стандартизированными методами, своего рода подпрограммами «черного ящика», которыми разработчик может пользоваться, даже не разбираясь в тонкостях самого протокола. К примеру, при аутентификации клиент-серверного подключения пересылка удостоверения клиентского приложения на сервер производится с помощью метода InitializeSecurityContext. Если выбран поставщик Kerberos SSP, этот метод генерирует на клиентском компьютере сообщение KRB_AP_REQ. В ответ серверное приложение, используя метод AcceptSecurityContext, направляет клиенту сообщение KRB_AP_REP. Когда аутентификация подключения завершена, серверная подсистема LSA генерирует маркер доступа, основанный на информации из клиентского билета. После этого сервер обращается к методу SSPI под названием ImpersonateSecurityContext и с его помощью прикрепляет маркер доступа к потоку.

    Кэш-память удостоверений

    На компьютерах под управлением Windows 2000 билеты и ключи, полученные из службы KDC, сохраняются в кэш-памяти удостоверений – области оперативной памяти, защищенной подсистемой LSA. Содержимое кэш-памяти удостоверений никогда не сбрасывается в файл подкачки. Выход абонента безопасности из системы и отключение самой системы приводят к уничтожению всех хранящихся здесь объектов.

    Управление кэш-памятью удостоверений возложено на Kerberos SSP, который работает в контексте безопасности подсистемы LSA. Каждый раз, когда возникает необходимость в получении билета или ключа, либо в их обновлении, LSA обращается к Kerberos SSP, который и выполняет эту задачу.

    В подсистеме LSA сохраняются также копии хешей паролей интерактивных пользователей. Если в ходе сеанса истекает срок действия пользовательского билета TGT, Kerberos SSP использует эту копию для получения нового билета. Это делается в фоновом режиме, без прекращения сеанса. Пароль здесь находится во временном хранении, его локальная копия уничтожается после прекращения сеанса работы пользователя.

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

    Разрешение имен DNS

    Согласно документу RFC 1510, для пересылки сообщений между клиентами и службой KDC должен использоваться протокол IP. Чтобы послать первоначальный запрос аутентификации, Kerberos SSP, установленному на клиентском компьютере, нужно найти адрес центра распределения ключей того домена, где находится учетная запись пользователя. Другими словами, необходимо знать имя сервера со службой KDC в доменной системе имен DNS. Если это имя может быть преобразовано в IP-адрес, Kerberos SSP направляет на него свое сообщение, если же нет, – выдается сигнал ошибки, указывающий на то, что домен не найден.

    Служба KDC устанавливается на всех контроллерах домена Windows 2000. Кроме функций серверов KDC эти контроллеры выполняют еще и функции серверов LDAP (Lightweight Directory Access Protocol – облегченный протокол доступа к каталогам). Обе эти службы регистрируются в записях указателя служб системы DNS (записях ресурсов SRV). Чтобы найти контроллер домена, клиенту достаточно запросить на сервере DNS запись ресурса SRV с именем _ldap._tcp.dc._msdcs.ИмяДоменаDNS. А запросив запись ресурса SRV с именем _kerberos._udp.ИмяДоменаDNS, клиент получит в ответ адрес службы KDC. Компьютеры под управлением Windows 2000 могут обращаться и в те области Kerberos, которые не входят в домены Windows 2000. Здесь служба KDC размещается на доменных контроллерах, работающих под управлением других операционных систем, поэтому имена DNS для таких серверов KDC приходится сохранять в реестре клиентского компьютера. В этом случае Kerberos SSP сначала находит в реестре доменное имя DNS области пользователя, а затем запрашивает соответствующий сервер DNS и преобразует это имя в IP-адрес.

    В Windows 2000 имеется специальная инструментальная программа, помогающая настраивать клиентов для работы с областями Kerberos, которые не входят в домены Windows 2000. Она запускается файлом ksetup.exe из каталога Support на установочном компакт-диске Windows 2000.

    Транспорт IP

    В соответствии с документом RFC 1510, для подключения к службе KDC клиент должен послать дейтаграмму UDP на порт 88 соответствующего IP-адреса. Служба KDC отвечает дейтаграммой на тот порт IP-адреса отправителя, откуда поступил запрос.

    UDP относится к транспортным протоколам, не устанавливающим логического соединения, поэтому его применение вполне оправданно в тех случаях, когда организация подключения предусматривает предварительный обмен служебными сообщениями. Этот протокол хорошо подходит и там, где обмен ограничивается единственным запросом и единственным ответом на него, как это имеет место в сеансах связи между клиентом и службой KDC. Важно только, чтобы каждое такое сообщение полностью умещалось в одну дейтаграмму. Но наилучшие результаты применение протокола UDP дает в тех случаях, когда дейтаграммы передаются как единое целое, то есть, каждая из них полностью вписывается в один кадр. Емкость же кадра зависит от передающей среды. В кадре Ethernet, например, максимальный размер передаваемого блока данных (MTU) равен 1 500 октетов. Следовательно, в физических сетях Ethernet сообщения Kerberos, отправляемые в виде дейтаграмм, могут содержать до 1 500 октетов данных.

    Сообщения с билетами для компьютеров Windows 2000 часто превышают предел в 1 500 байт, поэтому для их передачи используется протокол ТСР. Применение транспорта ТСР полностью согласуется с требованиями недавно опубликованного обновления спецификации RFC 1510[4].

    За последние четыре года ни один Black Hat или DEF CON не обошелся без докладов на тему атак на Microsoft Active Directory. Участники рассказывают о новых векторах и своих изобретениях, но не забывают и о советах, как можно их обнаружить и предотвратить. В этой статье мы рассмотрим популярные способы атак на AD и приведем рекомендации, которые помогут от них защититься.

    Шесть атак на AD, которые нельзя не заметить

    Многие производители программного обеспечения для мониторинга ИБ уже поддерживают в своих продуктах разнообразные техники атак злоумышленников. Рассмотрим некоторые из них.

    Pass-the-Hash

    Эта техника возможна благодаря архитектурным особенностям протокола аутентификации NTLM, разработанного Microsoft в девяностых годах прошлого века. Для того чтобы залогиниться на удаленном хосте, используется хеш пароля, хранящийся в памяти компьютера, с которого происходит аутентификация. Соответственно, его оттуда можно извлечь.

    Mimikatz

    Для удобной эксплуатации Pass-the-Hash французский исследователь Бенжамен Делпи (Benjamin Delpy) в 2014 году разработал утилиту mimikatz. Она позволяет дампить из памяти clear-text-пароли и NTLM-хеши.

    Brute Force

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

    net user /domain

    Откуда взять словарик имен пользователей для того, чтобы провести Brute Force? Любому члену домена доступно выполнение команды net user /domain, которая возвращает полный список имён пользователей из AD.

    Kerberoasting

    Если же домене в качестве протокола аутентификации используется Kerberos, то злоумышленник может прибегнуть к атаке Kerberoasting. Любой аутентифицированный в домене пользователь может запросить Kerberos-билет для доступа к сервису (Ticket Granting Service). TGS зашифрован хешем пароля учетной записи, от которой запущен целевой сервис. Злоумышленник, получив таким образом TGS, теперь может расшифровать его, подбирая пароль и не боясь блокировки, поскольку делает это на оффлайн. При успешном исходе, он получает пароль от ассоциированной с сервисом учетной записи, которая зачастую является привилегированной.

    PsExec

    После того как злоумышленник получил нужные учетные данные, перед ним встает задача удаленного исполнения команд. Для этого хорошо подходит утилита PsExec из набора Sysinternals. Она хорошо себя зарекомендовала как среди IT-администраторов, так и среди атакующих.

    Семь заклинаний атакующих для захвата Active Directory

    Сейчас мы переходим к семи заклинаниям, благодаря которым атакующие могут получить полный контроль над Active Directory. Разделим их на четыре стадии:

    1. Разведка.
    2. Продвижение по AD.
    3. Эксплуатация.
    4. Захват домена.

    На схеме можно увидеть все четыре, а также техники, которые на них при- меняются. Рассмотрим каждую детально.

    Стадия 1. Разведка

    Начнем со стадии разведки.

    PowerView

    Этот инструмент входит в популярный PowerShell-фреймворк для проведения тестирований на проникновение — PowerSploit. Также на него опирается инструмент BloodHound, строящий граф связей объектов внутри AD.

    Графовое представление связей объектов Active Directory

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

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

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

    PowerView отличает от встроенных утилит для получения данных об объектах AD (например, net.exe) то, что он работает по протоколу LDAP, а не SAMR. Для обнаружения данной активности подойдет событие 1644 с контроллера домена. Логирование данного события включается добавлением соответствующего значения в реестре:

    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSDiagnostic\15 Field Engineering = 5

    Включение логирования LDAP Event 1644

    Событие 1644 с параметрами LDAP-запроса

    Стоит обратить внимание на то, что таких событий может быть довольно много, и хорошей альтернативой детекту по событию является детект по трафику, поскольку LDAP – это clear-text протокол, соответственно, все запросы в трафике отлично видны.

    LDAP SearchRequest (по клику картинка откроется в полном размере)

    Читайте также:  Удаленное подключение к андроид устройству

    Еще одна важная особенность этого фреймворка — он написан на чистом PowerShell и не имеет зависимостей. И здесь для детектирования нам поможет появившаяся в PowerShell версии 5 возможность расширенного аудита. Событие 4104 показывает тело скрипта, в котором мы можем поискать характерные для PowerView названия функций.

    SPN Scan

    Она может заменить атакующему запуск nmap. После того, как атакующий разобрался, какие пользователи и группы есть внутри AD, для полноты картины ему понадобится информация, какие есть сервисы.

    Обычно это решается сканированием портов утилитой nmap. Но теперь эту информацию можно получить и из AD – она там уже хранится. Посмотреть на результат выполнения такого запроса можно так: возвращаются так называемые SPN (Service Principal Names). SPN состоит из serviceclass, он уникален для каждого типа сервиса, затем идет hostname в форме FQDN и для некоторых сервисов – port.

    Для того, чтобы обнаруживать SPN Scan на помощь также приходит аудит событий LDAP.
    Важно отметить, что SPN scan имеет явное преимущество перед сканом nmap: он менее шумный. При использовании nmap вам нужно подключаться к каждому узлу и отправлять пакеты на тот диапазон портов, который вы указали. А для получения списка SPN, нужно отправить всего один запрос.

    Remote Sessions Enumeration

    Важной задачей перед атакующим на этапе lateral movement становится определение, какой пользователь на какой машине залогинен. Либо у него уже есть учетные данные пользователя (хеш или Kerberos-тикет), и он ищет хосты, куда можно беспрепятственно залогиниться. Либо он в поисках хоста, где есть живая сессия доменного администратора.

    Тогда срабатывает сценарий: охота –> компрометация любого хоста –> залив Mimikatz – > профит.

    Для обнаружения данной техники можно использовать 2 события. 4624 – это успешный логон на удаленной системе с логон тайпом 3, а также события доступа к сетевой шаре IPC$, и нюанс – название пайпа – srvsvc. Почему пайп так называется, можно понять из трафика.

    По клику картинку откроется в полном размере

    В левой части в красных рамках обращения к SMB, затем обращения к пайпу – srvsvc. Вот этот пайп позволяет взаимодействовать по специальному протоколу Server Service Remote Protocol. Конечным хостам он позволяет получать от него различную административную информацию, в т.ч. среди запросов есть такой, который называется NetSessEnum. В результате этого запроса возвращается полный список залогиненных на удаленной системе пользователей с IP и именами пользователей.

    В MaxPatrol SIEM мы сделали детект на основе связки этих двух событий с учётом srvsvc. И аналогичный детект по трафику в PT Network Attack Discovery.

    Стадия 2. Продвижение по AD

    Overpass-the-Hash

    Реинкарнация Pass-the-Hash. Продолжая тему lateral movement. Что атакующий может сделать, если у него есть NTLM-хеш? Он может провести атаку Pass-the-Hash – но на нее уже есть детекты. Поэтому был найден новый вектор — атака Overpass-the-Hash.

    Протокол Kerberos был разработан специально для того, чтобы пароли пользователей в том или ином виде не передавались по сети. Для этого на своей машине пользователь хешом своего пароля шифрует запрос на аутентификацию. В ответ Key Distribution Center (специальная служба, которая хостится на контроллере домена) выдает ему билет на получение других билетов. Так называемый Ticket-Granting Ticket (TGT). Теперь клиент считается аутентифицированным, и в течение 10 часов он может обращаться за билетами для доступа к другим сервисам. Соответственно, если атакующий сдампил хеш пользователя, который входит в доверенную группу интересующего его сервиса, например, ERP-системы или базы данных, атакующий может выпустить пропуск для себя и успешно авторизоваться на интересующем его сервисе.

    Как детектить

    Если атакующий использует PowerShell версию mimikatz для этой атаки, то здесь на помощь приходит логирование тела скрипта. Потому что «Invoke-Mimikatz» весьма характерная строчка.

    Или же 4688 – событие запуска процесса с расширенным аудитом командной строки. Даже если бинарь будет переименован, то по командной строке мы обнаружим очень характерную для mimikatz команду.

    По трафику Overpass-the-Hash можно детектить на основе аномалии, которая возникает в результате того, что Microsoft рекомендует для текущих доменов использовать для шифрования authentication request AES256. А mimikatz когда отправляет данные authentication request, он шифрует данные с помощью устаревшего ARCFOUR.

    В трафике наблюдается еще одно отличие в силу особенностей mimikatz. Оно основано на разнице набора шифров в легитимном домене и том, что отправляет mimikatz.

    Golden Ticket

    Что атакующий может сделать, если у него есть хеш пароля специальной учетной записи, которая называется krbtgt? Ранее мы рассматривали случай, когда пользователь мог быть непривилегированным. Сейчас мы рассматриваем пользователя, хешем пароля которого подписываются абсолютно все билеты на получение других билетов (TGT). Соответственно, злоумышленник больше не обращается к Key Distribution Center, он сам у себя генерирует этот билет, поскольку Golden Ticket, по сути, и есть TGT. Затем он уже может отправлять запросы на аутентификацию на любом сервисе внутри AD, причем на неограниченное время. В итоге он беспрепятственно обращается к этому ресурсу — Golden Ticket неспроста называется золотым.

    Как детектить по событиям

    Существует событие 4768, говорящее о том, что был выдан TGT, и событие 4769, говорящее о том, что был выдан сер- висный билет, который необходим для аутентификации на каком-то сервисе внутри AD.

    Здесь мы можем играть на разнице: т.к. при атаке Golden Ticket не запрашивает TGT у контроллера домена (он генерирует его самостоятельно), а TGS ему запрашивать необходимо, то если мы обнаруживаем разницу в полученных TGT и TGS, то можем предположить, что происходит атака Golden Ticket.

    В MaxPatrol SIEM с использованием табличных списков, в который мы логируем все выданные TGT и TGS, нам удалось реализовать такой детект.

    WMI Remote Execution

    После того, как задача аутентификации и авторизации на желаемым хостах решена, атакующий может приступить к выполнению задач удаленно. WMI как встроенный и предназначенный для этого механизм подходит отлично. Последние несколько лет “living off the land” (пер. жить с земли) означает пользоваться встроенными в Windows механизмами в тренде. В первую очередь потому, что позволяет маскироваться под легитимную активность.

    На скриншоте использование встроенной утилиты wmic. Ей указывается адрес хоста, к которому нужно подключиться, учетные данные, оператор process call create и команда, которую необходимо выполнить на удаленном хосте.

    Как детектить

    По связке событий удаленного логона 4624 (обрати вни-
    мание на Logon ID) и событию 4688, говорящему о запуске процесса с command line. 4688 — можно увидеть, что родитель запускаемого процесса — WmiPrvSE.exe, специальный сервисный процесс WMI, который используется для удаленного администрирования. Видна команда, которую мы отправляли net user /add, и Logon ID совпадает с событием 4624. Соответственно, мы можем совершенно точно сказать, с какого хоста запущена данная команда.

    Детект по трафику

    Здесь мы явно видим характерные слова Win32 process create, а также command line, которая отправляется на запуск. На скриншоте недавно встреченная нами малварь, которая распространялась в виртуальных сетях по принципу, схожему с WannaCry, только вместо шифрования она устанавливала майнер. Малварь несла с собой mimikatz и EthernalBlue, она дампила учетки, с их помощью логинилась на все те хосты, до которых могла дотянуться по сети. С помощью WMI она запускала на них PowerShell, скачивала PowerShell payload, который опять же содержал в себе mimikatz, EthernalBlue и майнер. Таким образом получалась цепная реакция.

    Рекомендации к стадиям 1-3

    1. Cложные и длинные (>25 символов) пароли для сервисных учетных записей. Это не оставит шансу злоумышленнику провести атаку Kerberoasting, т.к. брутить придется очень долго.

    2. Логирование PowerShell. Поможет обнаружить использование многих современных инструментов для атак на AD

    3. Переезд на Windows 10, Windows Server 2016. Microsoft создал Credential Guard: больше не удастся сдампить из памяти NTLM-хеши и билеты Kerberos

    4. Строгое разграничение ролей. Опасно сочетать в одной роли администратора AD, DC, всех серверов и рабочих машин

    5. Двойная смена пароля krbtgt (эта та самая учетная запись, которой подписываются TGT билеты). Каждый год. И после ухода AD администратора AD:

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

    6. Средства защиты с непрерывно обновляющейся экспертной базой знаний. Необходимо для обнаружения реальных актуальных атак.

    Стадия 4. Захват домена

    DCShadow

    24 января 2018 года на конференции Microsoft BlueHat в Израиле Benjamin Delpy и Vincent Le Toux представили новый модуль mimikatz, которая реализует атаку DCShadow. Суть атаки в том, что создается поддельный контроллер домена, чтобы изменять и создавать новые объекты в AD через репликацию. Исследователям удалось выделить минимальный набор SPN Kerberos, необходимых для прохождения процесса репликации, — их требуется всего лишь 2. Кроме того, они представили специальную функцию, которую можно запускать репликацию контроллеров принудительно. Авторы атаки позиционируют ее как атаку, которая сделает ваш SIEM слепым. Т.к. поддельный контроллер домена не отправляет события в SIEM, а это значит, что злоумышленники могут делать различные темные дела с AD и SIEM об этом не узнает.

    Схема атаки

    На той системе, с которой производится атака, необходимо добавить 2 SPN, которые нужны, чтобы другие домен-контроллеры могли аутентифицироваться по kerberos для репликации. Т.к. согласно спецификации контроллер домена представлен в базе AD объектом класса nTDSDSA, необходимо такой объект создать. И в завершении вызвать репликацию с помощью функции DRSReplicaAdd.

    Как детектить

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

    Благодаря тому что наша корреляция знает список легитимных домен-контроллеров, она будет срабатывать, когда произойдет репликация с домен-контроллера, не входящего в этот белый список. Соответственно, подразделение ИБ может провести расследование и уже понять, это легитимный домен-контроллер, который добавила ИТ-служба, или атака DCShadow.

    Заключение

    Пример DCShadow показывает, что появляются новые векторы атак на enterprise. В этом океане ИБ событий очень важно оставаться на гребне волны: смотреть дальше и двигаться быстро. Каждый день мы в PT Expert Security Center исследуем новые угрозы и разрабатываем для них способы и инструменты обнаружения. И готовы делиться этой информацией и дальше.

    Автор: Антон Тюрин, руководитель Attack Detection Team, Positive Technologies

    Оцените статью
    Добавить комментарий

    Adblock
    detector