Привет! Это продолжение краткого перевода публикации "The Complete Active Directory Security Handbook. Exploitation, Detection, and Mitigation Strategies" от Picus Security. Первую часть можно почитать здесь.
!!! Данный текст предназначен для усиления мер безопасности Active Directory, а все описанные техники приводятся в качестве примера для понимания направления атак и способов их детектирования !!!
Структура хэндбука от Picus Security включает описание самых распространенных типов атак на Active Directory и методов их обнаружения.
DCShadow Attack
Атака теневого DC включает в себя компрометацию среды Active Directory путем внедрения в сеть нового вредоносного контроллера домена (DC) с последующей репликацией изменений с легитимными контроллерами домена.
Инструменты и методы для проведения атак типа DCShadow Attack
Злоумышленники часто используют Mimikatz для реализации DCShadow Attack. Шаги, описанные далее, предполагают, что злоумышленник уже скомпрометировал учетную запись в Active Directory с правами администратора, используя методы, описанные в предыдущей части.
Шаг 1. Повышение до системных привилегий и внесение изменений в реплицируемый объект
Mimikatz предоставляет возможность использовать функции режима ядра через включенный в его состав драйвер Mimidrv. Первый шаг предполагает запуск mimidrv, который предоставляет необходимые привилегии для выполнения роли поддельного контроллера домена. После чего, командой /object указывается целевой объект (на изображении ниже, этот объект "Alica" и для целевого объекта заменяется атрибут "SidHistory" на новое значение "S-5-1-5-21-2049251289-867822404-1193079966".
В контексте атаки DCShadow эта команда используется для указания поддельного сервера и нацеливания на пользовательский объект для изменения его атрибут "SidHistory" с новым указанным значением. Измененный атрибут можно использовать для предоставления злоумышленнику несанкционированного доступа к целевой системе и конфиденциальной информации.
Шаг 2. Отправка изменений обратно на реальный контроллер домена
На втором этапе злоумышленник должен снова запустить Mimikatz со скомпроментированной учетной записью и командой /push зарегистрировать поддельный контроллер домена (shadow DC) и запушить репликацию данных. Целью этой атаки является изменение содержимого базы данных Active Directory с помощью фейкового контроллера домена.
Методы обнаружения атаки DCShadow
Единственный надежный способ детектирования атаки DCShadow — это мониторинг сети на наличие DRSUAPI Remote Procedure Call (RPC) запросов для DRSUAPI_REPLICA_ADD операции от хостов, которые не являются контроллерами домена.
Другой метод обнаружения DCShadow — анализ журналов событий Windows, но этот подход выявляет только признаки атаки, а не точные изменения, внесенные злоумышленником. Чтобы имитировать контроллер домена, DCShadow должен внести изменения в Active Directory, например добавить новый объект NTDSDSA и глобальный каталог (GC/<host>) ServicePrincipalName к объекту компьютер, который не является известным легитимным контроллером домена. После завершения атаки оба этих изменения будут удалены.
Изучая события, приведенные ниже, в подкатегории "Audit Directory Service Changes subcategory" можно обнаружить признаки изменений:
Event ID 5136 - The Windows Filtering Platform has allowed a connection.
Event ID 5141 - A directory service object was deleted.
Методы митигации атаки DCShadow
Атака DCShadow — это разновидность advanced persistent threat (APT), которая использует функции и привилегии Active Directory для вредоносного изменения данных. Поскольку полностью исключить риск этой атаки невозможно, важно принять многоуровневый подход к обеспечению безопасности для его снижения. Вот несколько советов, которые помогут снизить риск успешной атаки DCShadow.
Использование host-based firewall
Используйте межсетевые экраны на уровне хоста, чтобы ограничить потенциальное горизонтальное перемещение злоумышленника. Убедитесь, что протоколы удаленного управления, такие как RDP, разрешены только из ограниченного и контролируемого перечня систем.
Ограничение прав пользователей
Крайне важно ограничить количество пользователей с административными привилегиями за пределами контролируемой зоны.
Контроль доступа к объектам типа "Компьютер" в AD
Необходимо ограничить количество пользователей с разрешением на добавление объектов типа "Компьютер" в Active Directory. Это помогает предотвратить несанкционированные изменения в инфраструктуре AD.
Сокращение делегированных административных прав
Аккуратно управляйте встроенными привилегированными группами и делегированными административными разрешениями.
Поддерживайте хорошую гигиену Active Directory
Регулярное удаление неиспользуемых объектов помогает поддерживать хорошую гигиену Active Directory и уменьшает поверхность атаки.
Атака AS-REP Roasting
AS-REP Roasting это техника, которая позволяет злоумышленникам получить хэши паролей учетных записей пользователей, для которых деактивирована предварительная аутентификация Kerberos. Эта техника влечет за собой использование Authentication Server Request (AS-REQ) запроса на контроллер домена. Если предварительная аутентификация отключена, контроллер домена вернет ответ AS-REP, содержащий зашифрованные данные, включая зашифрованный сегмент с хэшем пароля пользователя. Впоследствии злоумышленник может использовать эту информацию, чтобы попытаться взломать пароль пользователя в оффлайн режиме.
Инструменты и методы для проведения атак типа AS-REP Roasting
Злоумышленники могут использовать различные сторонние инструменты для выполнения атаки, такие как Rubeus и Empire, Kerbrute и Impacket.
На примере использования тулзы Rubeus.
Чтобы найти все учетные записи, которые не требуют предварительной аутентификации и извлечь их хэши AS-REP для оффлайн взлома, злоумышленник выполняет команду "Rubeus.exe asreproast". После извлечения данных, злоумышленник использует Hashcat, указывая код алгоритма хэширования для хэшей AS-REP (18200), хэш-файл и словарь, который будет использоваться для подбора пароля методом перебора. Подроднее про атаку AS-REP Roasting можно почитать здесь.
Методы обнаружения атаки AS-REP Roasting
Обнаружение атак AS-REP Roasting имеет решающее значение для снижения риска кражи пароля. Одним из способов обнаружения таких атак является отслеживание изменений параметра, определяющего, включена ли предварительная аутентификация Kerberos.
Event ID 4738 - A user account was changed.
Event ID 5136 - A directory service object was modified.
Событие 4738 означает запрос билета службы аутентификации Kerberos и включает в себя такие параметры, как Ticket Encryption Type (0x17), Ticket Options (0x40800010) и Service Name (krbtgt). Наличие этих параметров в журналах событий может указывать на продолжающуюся атаку AS-REP Roasting, поскольку это событие генерируется, когда злоумышленник манипулирует объектами домена.
Другой вариант — следить за событиями 5136, которое предоставляет информацию об изменениях, внесенных в учетные записи пользователей в среде Windows. Анализируя данные этого события, можно определить любые учетные записи пользователей, для которых были изменены настройки предварительной аутентификации Kerberos.
Методы митигации атаки AS-REP Roasting
Существует несколько методов, которые можно использовать для митигации атаки AS-REP.
Поиск всех учетных записей пользователей без предварительной аутентификации Kerberos
Самый эффективный способ предотвратить атаки AS-REP Roasting — найти все учетные записи пользователей, настроенные без предварительной аутентификации Kerberos, и включить этот параметр. Это можно сделать с помощью следующего скрипта PowerShell
Включение предварительной аутентификации Kerberos для этих учетных записей пользователей гарантирует, что контроллер домена будет расшифровывать временную метку, зашифрованную с помощью хэша пароля пользователя. Это значительно усложняет злоумышленнику получение доступа к хэшу пароля пользователя.
Внедрение строгой парольной политики
Для защиты от атак AS-REP Roasting рекомендуется реализовать строгую парольную политику, особенно для привилегированных учетных записей, которая требует использования длинных и сложных паролей. Это затрудняет взлом паролей злоумышленнику, даже если они успешно украдены.
Аудит привилегий в Active Directory
Важно определить, кто имеет право изменять настройки предварительной аутентификации, поскольку эти пользователи могут временно отключить ее, чтобы украсть хэш AS-REP, а затем снова включить ее. Следующий запрос PowerShell покажет всех лиц, имеющих права доступа к учетным записям без предварительной аутентификации
Атака LDAP Injection
LDAP это аббревиатура от Lightweight Directory Access Control Protocol - это протокол с открытым исходным кодом, используемый для аутентификации служб каталогов. Другими словами, LDAP это кросс-платформа, поддерживающая язык коммуникации для приложений, которые взаимодействуют со службами каталогов, хранящих информацию об объектах и предоставляющих эту информацию другим объектами в сети. Следует отметить, что LDAP и Active Directory — это не одно и то же: по сути, LDAP — это язык, который Microsoft Active Directory понимает. Если вам когда-нибудь понадобится получить доступ к каким-либо данным, хранящимся в AD, или аутентифицировать себя, вы используете LDAP протокол для связи с целевым сервером. По умолчанию, активная непривилегированная учетная запись в AD, можете использовать LDAP-запросы для получения различной информации из AD.
LDAP-injection это тип уязвимости, позволяющий злоумышленнику внедрить вредоносный код в запрос LDAP. Это может привести к несанкционированному доступу к конфиденциальной информации, хранящейся в каталоге LDAP, или манипулированию данными, хранящимися в каталоге. Злоумышленники могут воспользоваться этой уязвимостью, вводя в запрос специальные символы, что меняет его предполагаемое значение и позволяет злоумышленнику обойти средства аутентификации или получить конфиденциальную информацию.
Инструменты и методы для проведения атак типа LDAP-injection
Атаки с внедрением LDAP имеют множество форм, и некоторые из них описаны в этом тексте. Если вы хотите углубиться в тему и узнать о дополнительных типах атак с внедрением LDAP, которые здесь не упомянуты, перейдите по этой ссылке.
Тип 1. Повышение привилегий
Кейс повышения привилегий описывает ситуацию, когда пользователи с низким уровнем безопасности могут получить доступ к информации с высоким уровнем безопасности. Это достигается за счет использования инъекции в виде фильтра, который обрабатывает LDAP-сервер.
Например, злоумышленник может нацелиться на каталог с документами низкого уровня безопасности такими, как "Information/Reports" и "Information/UpcomingProjects". В этом случае инъекция будет выглядеть следующим образом:
Фильтр, полученный в результате этой инъекции, будет следующим:
Поскольку сервер LDAP обрабатывает только первый фильтр, второй фильтр игнорируется, и выполняется запрос "(&(directory=Information)security level=*)". Это позволяет злоумышленнику получить доступ к списку документов, который в противном случае был бы доступен только пользователям с высоким уровнем безопасности, даже если злоумышленник не имеет соответствующих привилегий.
Тип 2. Обход контроля доступа.
Все страницы входа в систему содержат два поля для ввода пользователем: одно для имени пользователя, а другое для пароля. Поля помечены как USER (имя пользователя) и PASSWORD (пароль). Клиент предоставляет пару имя пользователя/пароль, и LDAP подтверждает существование этой пары, создавая фильтры поиска и отправляя их на LDAP-сервер.
Фильтр записывается как (&(USER=Alice)(PASSWORD=PaSsW0rd!+). Однако злоумышленник может манипулировать этими данными, введя действительное имя пользователя и вставив после него последовательность и обойти проверку пароля. Зная имя пользователя, злоумышленник может ввести любую строку в качестве значения пароля, в результате чего на сервер будет отправлен следующий запрос: (&(USER=Alice)(PASSWORD=PaSsW0rd!+).
LDAP-сервер обрабатывает только первый фильтр, игнорируя второй, что позволяет злоумышленнику войти в систему без правильного пароля в качестве запроса.
Тип 3. Раскрытие данных
Обозреватель ресурсов позволяет пользователю увидеть, какие ресурсы доступны в системе, например веб-сайт, на котором продается одежда. Пользователь может выполнить поиск определенного предмета (например, блокнотов или наклеек), чтобы узнать, доступны ли они для продажи. Это делается с помощью запроса LDAP (|(type=Notebooks)(type=Stickers)).
Однако злоумышленник может воспользоваться этим, вставив в запрос строку "uid=*", в результате чего получится следующий запрос: (|(type=Notebooks)(uid=*))(type=Stickers)).
Этот запрос будет обработан LDAP-сервером, отображающим не только все доступные джинсы, но и все пользовательские объекты в системе.
Методы митигации атаки типа LDAP-injection
Маскирование всех переменных с использованием правильной кодировки LDAP
Маскирование всех переменных с использованием правильной кодировки LDAP — один из ключевых методов защиты от атак типа LDAP-injection. Этот метод предполагает кодирование всех вводимых пользователем данных таким образом, чтобы злоумышленникам было сложно внедрить вредоносные данные в запросы LDAP.
Маскирование distinguished name
LDAP использует DN или distinguished name для хранения и идентификации имен в своей базе данных. DN действует как уникальный идентификатор, аналогичный имени пользователя, и может использоваться для доступа к ресурсам. DN состоит из нескольких частей, разделенных запятыми. Например, DN может выглядеть так:
Существуют «специальные» символы, которые разрешены в distinguished name. К ним относятся* ( ) . & - _ [ ] ` ~ | @ $ % ^ ? : { } ! '. Важно правильно обрабатывать специальные символы в DN, чтобы гарантировать правильную работу DN и избежать каких-либо проблем или непредвиденных последствий при использовании DN.
Маскирование поискового фильтра
В базе данных LDAP каждое DN однозначно указывает на одну запись, которую можно рассматривать как строку в реляционной базе данных. Каждая запись содержит один или несколько атрибутов, аналогичных столбцам в БД. Фильтры поиска можно использовать для поиска в базе данных LDAP и поиска записей с определенными атрибутами.
Поисковые фильтры используют польскую нотацию, также известную как префиксная нотация, для указания условий поиска. Например, следующий фильтр поиска вернет все записи в OU Physics и менеджерами которого являются Freeman Dyson или Albert Einstein
При построении запросов LDAP в коде приложения крайне важно избегать любых ненадежных данных, добавляемых в запрос, чтобы предотвратить проблемы безопасности. Существует две формы маскирования LDAP: кодирование для поиска LDAP и кодирование для LDAP DN. Правильная форма маскирования зависит от того, используются ли данные в фильтре поиска или в качестве DN для доступа к ресурсу. Специальные символы, такие как "(" , ")" , и "" должно быть правильно экранировано при использовании в фильтре поиска, чтобы обеспечить выполнение запроса должным образом.
Дополнительная защита
Чтобы обеспечить дополнительный уровень защиты от атак LDAP-injection, можно реализовать следующие меры защиты:
Минимизация привилегий: Ограничьте привилегии, назначенные учетной записи LDAP binding, которая используется для доступа к каталогу LDAP, чтобы минимизировать потенциальный ущерб в случае успешной атаки.
Включите Bind аутентификацию: Настройте протокол LDAP так, чтобы он требовал bind-аутентификации, которая проверяет и авторизует действительные учетные данные, передаваемые пользователем. Тем не менее, злоумышленники по-прежнему могут обойти bind-аутентификацию с помощью Anonymous Bind и Unauthenticated Bind. Следовательно, эти параметры также следует отключить.
Валидация вводимых даных по разрешенному списку (white list): Внедрите методы проверки входных данных для обнаружения и предотвращения передачи несанкционированных входных данных в запрос LDAP. Это может помочь гарантировать, что при построении запросов LDAP используются только разрешенные значения, что снижает риск успешной атаки LDAP-injection.
Атака PetitPotam NTLM Relay на Active Directory Certificate Services (AD CS)
PetitPotam NTLM - это тип атаки, которая использует недостатки устаревшего протокола Windows NTLM и МС-EFSRPC протокол. Эта атака использует небезопасную дефолтовую конфигурацию служб сертификации Active Directory (AD-CS), которая не применяет расширенную защиту для аутентификации - Extended Protection for Authentication (EPA).
В ходе этой атаки злоумышленник может активировать аутентификацию контроллера домена, воспользовавшись уязвимостью PetitPotam и передав ее на сервер AD-CS для запроса сертификата для учетной записи контроллера домена. Используя этот сертификат, злоумышленник может получить Ticket Granting Ticket (TGT) для ретранслируемой учетной записи контроллера домена и выполнить любые дальнейшие операции, используя повышенные привилегии. Это может привести к полной компрометации домена за несколько шагов и потенциально позволит злоумышленнику сдампить хэши администраторов домена.
Важно отметить, что эта уязвимость была частично устранена обновлением безопасности, выпущенным Microsoft 10 мая 2022 г., но атака по-прежнему возможна, если у злоумышленника есть какие-либо учетные данные Active Directory.
Инструменты и методы для проведения атак PetitPotam NTLM Relay
В следующем сценарии будет продемонстрированно, как злоумышленник может использовать уязвимость PetitPotam, позволяющаю получить полные права администратора домена без необходимости предварительной аутентификации. Типичная атака PetitPotam NTLM Relay состоит из пяти шагов .
Шаг 1. Ретрансляция веб-страницы регистрации AD CS
На первом этапе злоумышленник должен убедиться, что ntlmrelay.px настроен для ретрансляции на страницу веб-регистрации AD CS.
Обратите внимание, что флаг "--target" указывает целевой URL-адрес для атаки. В данном случае целью является хост сервера сертификатов. Флаги "--adcs" и "--template KerberosAuthentication" указывают, что целью является сервер службы сертификации Active Directory (AD CS) и что инструмент будет использовать определенный шаблон аутентификации.
Шаг 2. Эксплуатация уязвимости PetitPotam
Чтобы воспользоваться уязвимостью PetitPotam, необходимо указать адрес DC и IP-адрес злоумышленника.
Обратите внимание, что "listener-ip" — это IP-адрес ретранслятора злоумышленника, а "target-ip" — это IP-адрес контроллера домена, на который нацелен злоумышленник. Как только злоумышленник воспользуется уязвимостью PetitPotam, реквизиты для входа будет переданы на AD CS, где будет зарегистрирован сертификат.
Шаг 3. Получение Ticket Granting Ticket (TGT)
Теперь, когда сертификат зарегистрирован, злоумышленник может использовать его для получения TGT. На этом этапе злоумышленник может использовать kekeo или Rubeus.
Эта команда успешно аутентифицирует злоумышленника в домене.
Шаг 4. DCSyncing целевого пользователя
На этом этапе злоумышленник может использовать Mimikatz и выполнить атаку DCSync на krbtgt аккаунт.
Обратите внимание, что с помощью этой команды злоумышленник указывает целевой домен («EXAMPLE.local») и krbtgt аккаунт, который представляет собой привилегированную учетную запись в Active Directory, используемую для выполнения различных административных задач, включая выдачу Билетов Kerberos.
"lsadump::dcsync" - функция, которая используется для выполнения атаки «DCSync», представляет собой тип атаки, позволяющей злоумышленнику имитировать поведение контроллера домена и получать хеши паролей, билеты Kerberos и другую конфиденциальную информацию из базы данных Active Directory. Следовательно, после запуска этой команды злоумышленник получает хеш пароля krbtgt (в примере - 186c026974e59a14040dbc63aa8fb8c4).
Шаг 5. Передача хэша
На этом этапе злоумышленник может использовать инструмент wmiexec.py для передачи хэша, полученного на пятом этапе и получения интерактивной оболочки на контроллере домена.
Проще говоря, эти два бага используются вместе, чтобы быстро позволить кому-то с ограниченным доступом получить полный контроль над сетью или системой. Даже если сеть или система полностью обновлены с использованием последних обновлений безопасности, эти баги все равно могут быть использованы для причинения серьезного вреда всего за несколько минут.
Методы митигации атаки PetitPotam NTLM Relay
Чтобы защитить сети от атак PetitPotam NTLM Relay, администраторы домена должны принять меры для защиты служб с поддержкой аутентификации NTLM. Уязвимость PetitPotam использует серверы, на которых отсутствуют средства защиты от атак NTLM Relay в службах сертификации Active Directory (AD CS).
Если вы используете AD CS со следующими службами, ваша сеть может быть уязвима:
Certificate Authority Web Enrollment.
Certificate Enrollment Web Service.
Microsoft предлагает следующие шаги для смягчения потенциальных атак на серверы AD CS:
Включите расширенную защиту аутентификации Extended Protection for Authentication (EPA) для веб-регистрации центра сертификации и веб-службы регистрации сертификатов. Это можно сделать с помощью Internet Information Services (IIS) Manager, при этом «Required» является рекомендуемым и наиболее безопасным вариантом.
Обновите файл Web.config, созданный ролью Certificate Enrollment Web Service, расположенный по адресу чтобы изменить настройки EPA
<%windir%>\systemdata\CES<CA Name>_CES_Kerberos\web.config
Добавьте <extendedProtectionPolicy> с значением "WhenSupported" или "Always" в зависимости от настройки EPA в пользовательском интерфейсе IIS. "Always" должно использоваться, когда для настройки EPA установлено значение "Required".
Включите использование только защищенного SSL соединения выбрав параметр "Require SSL" в диспетчере IIS.
После выполнения этих шагов важно перезапустить IIS, чтобы применились изменения.
Заключение
Рост частоты и сложности атак, нацеленных на Active Directory, очевиден. Распространенные атаки, такие как Pass the Hash, Pass the Ticket, Kerberoasting, Golden Ticket, DC Shadow, AS-REP Roasting, LDAP Injection и PetitPotam NTLM Relay Attack, иллюстрируют множество способов, которыми злоумышленники могут использовать уязвимости в инфраструктуре Active Directory.
Учитывая значительную роль, которую Active Directory играет в управлении и контроле доступа к конфиденциальным данным и ресурсам организации, крайне важно принимать превентивные меры для защиты от атак такого типа. Это требует многоуровневого подхода, включающего регулярные проверки безопасности, оценку уязвимостей и непрерывный мониторинг событий безопасности для обнаружения и устранения угроз в режиме реального времени.
Крайне важно признать, что злоумышленники постоянно адаптируют свою тактику, требуя от организаций сохранять бдительность и постоянно обновлять свои меры безопасности, чтобы опережать возникающие угрозы. Инвестируя в комплексные меры безопасности и внимательно отслеживая развивающуюся картину угроз, организации могут снизить риск стать жертвой атаки Active Directory.
Всем счастья, здоровья! Берегите себя и вашу Actvie Directory.
