Защита от основных типов атак в среде Active Directory

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

Credential dumping

Credential dumping — метод, при котором хакеры извлекают учетные данные из памяти системы или из файловой системы. Он часто используется для получения хеш-сумм паролей, токенов аутентификации и других учетных данных, которые могут быть применены в ходе дальнейших атак, таких как pass-the-hash, pass-the-ticket и др. Как правило, credential dumping выполняется с использованием специальных инструментов (например, mimikatz), которые позволяют извлекать учетные данные из памяти LSASS, ветвей реестра и других источников. Примеры источников получения учетных данных:

1. LSASS (Local Security Authority Subsystem Service). Это процесс в Windows, который управляет политиками безопасности и хранит в памяти различные аутентификационные данные.
2. SAM и SYSTEM. В Windows учетные данные могут храниться в ветках реестра SAM (Security Account Manager) и SYSTEM. Получив доступ к этим веткам, хакер может извлечь хеш-суммы паролей и подобрать их.
3. Cached credentials. Windows хранит кэшированные учетные данные, которые хакер также может извлечь. Учетные данные кэшируются для того, чтобы мы имели доступ к нашим компьютерам даже без постоянного подключения к сети.

Рекомендации:

• Минимизируйте права доступа учетных записей, имеющих доступ к процессу LSASS, предоставляя административные права только тем сотрудникам, которым это действительно необходимо для выполнения рабочих задач.
• Внедрите политику использования сложных паролей и требуйте их регулярной смены, уделяя особое внимание административным учетным записям.
• Защитите ветки реестра SAM и SYSTEM, ограничив доступ к ним только доверенными учетными записями. Это поможет предотвратить извлечение хеш-сумм паролей и их подбор.
• Отключите сохранение паролей пользователей в системе LSA. Для этого параметру реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\disabledomaincreds присвойте значение 1.
• Рассмотрите возможность запрета использования кэшированных данных для доступа к узлам домена. Для этого параметру реестра HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount присвойте значение 0.
• Осуществляйте мониторинг обращений к следующим разделам реестра: HKEY_LOCAL_MACHINE\SAM, HKEY_LOCAL_MACHINE\SECURITY, HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets (включая подразделы) и HKEY_LOCAL_MACHINE\SYSTEM. При настройке мониторинга через групповые политики Active Directory, при обращении к ветви реестра на контроллере домена будут регистрироваться события 4656 (A handle to an object was requested).
• Отслеживайте запуск процессов и использование аргументов командной строки для выполнения утилит, которые могут указывать на извлечение учетных данных.

Kerberoasting

Kerberos — это протокол, который используется для безопасной аутентификации пользователей и служб в Active Directory (AD). Он основан на использовании секретных ключей и билетной системе. Когда пользователь хочет получить доступ к какому-либо ресурсу, он сначала проходит аутентификацию на сервере, который выдает ему билет. Затем этот билет используется для доступа к ресурсу без необходимости повторной аутентификации. Kerberoasting — это атака на протокол аутентификации Kerberos, которая позволяет получить пароли доменных пользователей. Она состоит из нескольких шагов:

1. Сбор информации об учетных записях, обладающих доступом к целевому ресурсу. Это могут быть учетные записи сервисов, приложений и т. д.
2. Запрос билетов для сервисных учетных записей. Хакер отправляет запрос на выдачу билета для сервисной учетной записи. В ответ он получает билет, который зашифрован с использованием хеш-суммы пароля этой учетной записи.
3. Локальный взлом хеш-суммы и получение пароля. Хакер экспортирует полученный билет на локальный компьютер, взламывает хеш-сумму и получает пароль.

Рекомендации:

• Реализуйте строгую парольную политику и смените используемые словарные пароли. Используйте двухфакторную аутентификацию для привилегированных пользователей домена Active Directory. Для сервисных учетных записей применяйте сложные и длинные пароли (не менее 25 символов) и регулярно меняйте их.
• Внедрите механизм «Групповых управляемых учетных записей служб» (group managed service accounts, gMSA). Этот механизм поддерживает основные сервисы и службы, используемые в корпоративной инфраструктуре, такие как IIS, AD LDS, SQL Server, MS Exchange. gMSA автоматически меняет пароли, генерируя сложные случайные пароли длиной до 240 символов, что значительно затрудняет их подбор. Пароли меняются по умолчанию каждые 30 дней — их подбор практически невозможен.
• Используйте механизм flexible authentication secure tunneling (FAST, Kerberos armoring) для усиления защиты аутентификации и обмена TGS-билетами. Этот механизм обеспечивает защищенный канал связи между клиентом Kerberos и центром распространения ключей (key distribution center, KDC).
• Придерживайтесь принципа минимальных привилегий для сервисных учетных записей, включая привилегии, получаемые в результате членства в группах (таких, как группа администраторов домена).
• Настройте использование алгоритма шифрования AES (или другого надежного алгоритма) для протокола Kerberos вместо RC4.
• Для обнаружения атак в инфраструктуре включите в Active Directory мониторинг запрашиваемых билетов Kerberos (Audit Kerberos Service Ticket Operations) и ищите пользователей с избыточными событиями 4769 (A Kerberos service ticket was requested). Используйте метод SPN honeypot, который заключается в создании учетной записи и SPN, которые никогда не будут использоваться (SPN не связан ни с одним реальным приложением). Появление в журнале безопасности контроллера домена события 4769 будет свидетельствовать о попытке проведения атаки типа Kerberoasting.
• Проводите регулярный аудит безопасности домена с помощью ПО PingCastle.

DCSync

DCSync — это атака, которая применяется хакерами для получения учетных данных из базы данных домена Active Directory. Она использует возможности протокола репликации AD, который предназначен для синхронизации данных между контроллерами домена. Хакеры могут имитировать контроллер домена и запросить у настоящего контроллера домена информацию об учетных записях. Основные этапы атаки:

1. Получение привилегированного доступа. Для проведения атаки хакеру нужно получить привилегированную учетную запись.
2. Имитация контроллера домена. Могут использоваться инструменты типа mimikatz, чтобы отправить команды репликации на контроллер домена.
3. Получение учетных данных. Контроллер домена отправляет учетные данные (включая хеш-суммы паролей) хакеру.

Таким образом, DCSync позволяет атакующему получить доступ к хеш-суммам паролей всех пользователей домена, включая учетные записи с высокими привилегиями. Злоумышленник может использовать эти хеш-суммы для проведения других атак, таких как pass-the-hash или golden ticket, чтобы обеспечить себе неограниченный доступ к ресурсам домена. Рекомендации:

• Осуществляйте мониторинг запросов протокола DRSUAPI с операцией DsGetNCChanges (opcode 3) от серверов, не являющихся легитимными участниками процесса репликации. В журнале Security на контроллерах домена и в событиях аудита 4662 (An operation was performed on an object) необходимо отслеживать использование привилегий Replicating Directory Changes, Replicating Directory Changes All и Replicating Directory Changes In Filtered Set. Для обнаружения источника атаки следует коррелировать события 4662 и 4624 (An account was successfully logged on) с одинаковыми идентификаторами входа.
• Вы можете включить в Active Directory мониторинг событий 4932 (Synchronization of a replica of an Active Directory naming context has begun) и 4937 (Replication failure begins) для обнаружения атак типа DCSync.
• Дополнительно вы можете проводить аудит безопасности домена с помощью ПО PingCastle.

DCShadow

Атака DCShadow позволяет злоумышленникам регистрировать новый контроллер домена в AD и использовать его для внесения скрытых изменений в конфигурацию AD. В обычных условиях только легитимные контроллеры домена могут вносить изменения в конфигурацию AD, но DCShadow позволяет обойти этот механизм. Хакеры могут зарегистрировать свой собственный контроллер домена и использовать его для изменения данных в AD (например, для изменения атрибутов учетных записей пользователей или групп). Основные этапы атаки:

1. Получение привилегированного доступа. Для проведения атаки хакеру нужно получить привилегированную учетную запись.
2. Имитация контроллера домена. Хакер создает и регистрирует в инфраструктуре AD поддельный контроллер домена.
3. Внесение и синхронизация изменений в AD. Хакер, используя поддельный контроллер домена, вносит изменения в AD, которые затем распространяются на остальные контроллеры домена. Эти изменения могут включать в себя добавление новых пользователей, повышение привилегий существующих пользователей, создание новых групп или изменение политик безопасности. Поскольку механизм репликации AD доверяет всем зарегистрированным контроллерам домена, то изменения, внесенные поддельным контроллером домена, быстро распространятся по всей инфраструктуре.

Рекомендации:

• Отслеживайте события регистрации новых контроллеров домена — 5137 (A directory service object was created) и 5141 (A directory service object was deleted).
• В журнале Security на контроллерах домена и в событиях аудита 4662 (An operation was performed on an object) отслеживайте операции с привилегиями Domain Admin или Enterprise Admin, а также изменения в конфигурации домена. Для выявления источника атаки необходимо коррелировать события 5137 и 4662 с одинаковыми идентификаторами входа и временем.
• Дополнительно рекомендуется включить мониторинг событий 4929 (An Active Directory replica source naming context was established) и 4930 (An Active Directory replica source naming context was removed) для отслеживания изменений в конфигурации репликации.
• Также рекомендуется регулярно проводить аудит безопасности домена с помощью ПО PingCastle.

Pass-the-hash, overpass-the-hash (pass-the-key) и pass-the-ticket

Pass-the-hash (PtH) — это техника, используемая хакерами для получения несанкционированного доступа к сетевым ресурсам. Основа техники заключается в том, что вместо пароля злоумышленник использует для аутентификации хеш-сумму этого пароля. Когда пользователь входит в систему, его пароль преобразуется в хеш-сумму. Эта хеш-сумма используется для аутентификации, чтобы доказать, что пользователь знает пароль, не передавая его напрямую. Если хакер получает доступ к этим хеш-суммам, он может использовать их для аутентификации без необходимости вводить исходный пароль. Overpass-the-hash (pass-the-key) — атака, при которой хакер использует хеш-сумму пароля для создания билета Kerberos и последующей аутентификации по нему. Если overpass-the-hash (pass-the-key) использует хеш-сумму пароля для создания новых билетов Kerberos, то pass-the-ticket использует для аутентификации ранее сгенерированные Kerberos билеты.

Рекомендации:

• Включите мониторинг событий аутентификации. В журнале Security на контроллерах домена и серверах следует отслеживать события 4624 (An account was successfully logged on) и 4625 (An account failed to log on) с целью выявления подозрительных попыток входа. Особое внимание следует уделять событиям, связанным с использованием NTLM и Kerberos.
• Отслеживайте события 4768 (A Kerberos authentication ticket was requested), 4769 (A Kerberos service ticket was requested) и 4770 (A Kerberos service ticket was renewed) для выявления аномалий в запросах билетов Kerberos. Корреляция этих событий с одинаковыми идентификаторами входа и IP-адресами может помочь обнаружить источник атаки.
• Ограничьте использование NTLM, по возможности отключите его и используйте Kerberos для аутентификации.
• Используйте двухфакторную аутентификацию для доступа к критически важным системам.
• Регулярно проводите аудит безопасности домена с помощью ПО PingCastle.

Golden ticket

Golden ticket — это атака, при которой злоумышленник создает поддельный билет Kerberos (TGT) с целью получения неограниченного доступа к ресурсам домена. Проведение атаки возможно благодаря получению хеш-суммы пароля учетной записи krbtgt, которая является учетной записью службы Kerberos ticket-granting service. Основные этапы атаки:

1. Получение хеш-суммы пароля учетной записи krbtgt. Это специальная учетная запись в Active Directory, которая отвечает за выдачу и проверку билетов Kerberos.
2. Создание поддельного билета Kerberos. Для этого хакер использует хеш-сумму пароля krbtgt.
3. Получение доступа ко всем ресурсам домена с использованием TGT.

Golden ticket — одна из самых мощных атак на Active Directory: она предоставляет злоумышленнику практически неограниченный доступ к ресурсам домена. Хакер может аутентифицироваться от имени любой учетной записи, включая учетные записи с самыми высокими привилегиями.

Рекомендации:

• Настройте для протокола Kerberos использование алгоритма шифрования AES (или другого надежного алгоритма) вместо RC4.
• Ограничьте привилегии администратора домена, предоставив их только контроллерам домена и отдельным серверам. Для остальных административных функций создайте отдельные учетные записи.
• Осуществляйте мониторинг подозрительной активности, такой как использование шифрования RC4 внутри TGT (ticket-granting ticket), а также запросы TGS (ticket-granting service) без предшествующего запроса TGT.
• Отслеживайте время жизни билетов TGT для выявления отклонений от значений, установленных по умолчанию в домене.
• Осуществляйте мониторинг аномальных событий Kerberos-аутентификации, содержащих вредоносные или пустые поля. Для этого рекомендуется отслеживать события 4624 (An account was successfully logged on), 4634 (An account was logged off) и 4672 (Special privileges assigned to new logon).
• В случае если атака golden ticket была осуществлена, для предотвращения ее последствий рекомендуется дважды сбросить пароль служебной учетной записи krbtgt. Это приведет к аннулированию всех существующих «золотых билетов», полученных с использованием хеш-суммы NT учетной записи krbtgt, а также остальных билетов, полученных на ее основе. Кроме того, следует установить максимально возможную частоту смены пароля для учетной записи krbtgt.

Silver ticket

Silver ticket — это атака, при которой злоумышленник создает поддельный билет на конкретную службу, а не на весь домен. В отличие от golden ticket, который предоставляет доступ ко всему домену, silver ticket позволяет атакующему получить доступ только к конкретным сервисам, например к файловым серверам или веб-приложениям. Эта атака менее заметна, чем golden ticket, так как нацелена на конкретные службы и может оставаться незамеченной стандартными средствами мониторинга. Основные этапы атаки:

1. Получение хеш-суммы пароля учетной записи службы. Сначала хакер получает хеш-сумму пароля учетной записи службы (service account).
2. Создание поддельного service ticket. Используя полученную хеш-сумму, злоумышленник создает поддельный service ticket. Он содержит имя пользователя, список групп и другие атрибуты, которые определяют уровень доступа к ресурсу. Поддельный билет подписывается хеш-суммой пароля учетной записи службы.
3. Получение доступа к целевой службе. Злоумышленник отправляет поддельный service ticket на сервер службы, который считает этот билет легитимным и предоставляет хакеру доступ к запрашиваемому ресурсу.

Рекомендации:

• Использование сервисных билетов является легитимным действием в системе, поэтому в первую очередь необходимо выполнить действия, рекомендованные для предотвращения или усложнения получения учетных данных пользователей доменов, от имени которых возможен запрос сервисных билетов к значимым узлам и ресурсам.
• Не применяйте в инфраструктуре устаревшие версии операционных систем и программного обеспечения, не поддерживающие современные методы аутентификации.
• Настройте для протокола Kerberos использование алгоритма шифрования AES вместо RC4.
• Осуществляйте проверку подлинности сертификата атрибутов привилегий (Privilege Attribute Certificate, PAC) для билетов TGS.
• Используйте сложные и длинные (не менее 25 символов) пароли для сервисных учетных записей для защиты от подбора, а также регулярно производите их смену.
• Используйте механизм «Управляемых учетных записей служб» (Managed Service Accounts). MSA поддерживает основные сервисы и службы, применяемые в корпоративной инфраструктуре (например, IIS, AD LDS, SQL Server, MS Exchange). Этот механизм автоматически производит смену паролей, генерирует комплексный случайный пароль из 240 символов, что значительно повышает сложность подбора пароля, а с учетом смены пароля по умолчанию раз в 30 дней — делает подбор практически невозможным.
• Придерживайтесь принципа минимальных привилегий для сервисных учетных записей, включая привилегии, получаемые в результате членства в группах, например в группе администраторов домена.
• Осуществляйте мониторинг аномальных событий Kerberos-аутентификации, содержащих вредоносные или пустые поля. Для этого рекомендуется отслеживать события 4624 (An account was successfully logged on), 4634 (An account was logged off) и 4672 (Special privileges assigned to new logon).
• Осуществляйте мониторинг аномальных обращений к процессу lsass.exe на рабочих станциях и серверах. Общедоступные инструменты, предназначенные для снятия дампа учетных записей (например, ПО mimikatz), позволяют злоумышленнику, получившему доступ к процессу LSASS (Local Security Authority Subsystem Service), узнать секретный ключ LSA и расшифровать разделы памяти, где хранится информация об учетных записях, в том числе билеты Kerberos.

AS-REP roasting

AS-REP roasting представляет собой атаку на протокол аутентификации Kerberos, направленную на получение хеш-сумм паролей учетных записей, которые не защищены предварительной аутентификацией (pre-authentication). Этот тип атаки позволяет злоумышленникам извлекать хеш-суммы паролей учетных записей и использовать их для дальнейших атак на систему. Центральным компонентом в Kerberos является центр распространения ключей (key distribution center, KDC), который состоит из двух основных служб — authentication service (AS) и ticket-granting service (TGS). Процесс аутентификации пользователя включает следующие этапы:

1. Authentication service request (AS-REQ). Пользователь отправляет запрос на аутентификацию, содержащий его имя и метку времени, зашифрованную с использованием его пароля.
2. Authentication service response (AS-REP). KDC проверяет учетные данные пользователя и возвращает зашифрованный ticket-granting ticket (TGT), который пользователь может использовать для получения доступа к другим ресурсам.

В обычных условиях процесс предварительной аутентификации (pre-authentication) требует, чтобы пользователь предоставил доказательства своей «подлинности» перед выдачей TGT. Однако, если предварительная аутентификация отключена, KDC сразу и без дополнительной проверки отправляет AS-REP, содержащий зашифрованный TGT. Основные этапы атаки:

1. Поиск уязвимых учетных записей. Для этого хакер отправляет LDAP-запросы к контроллерам домена, чтобы выявить учетные записи, не защищенные предварительной аутентификацией.
2. Отправка запроса AS-REQ. Злоумышленник отправляет AS-REQ к KDC от имени уязвимой учетной записи.
3. Получение AS-REP. KDC отвечает сообщением AS-REP, содержащим зашифрованный TGT.
4. Взлом хеш-суммы. Хакер извлекает зашифрованную часть AS-REP, взламывает хеш-сумму и получает пароль.

Рекомендации:

• Используйте двухфакторную аутентификацию для привилегированных пользователей домена Active Directory. Для сервисных учетных записей используйте сложные и длинные пароли (не менее 25 символов), а также регулярно меняйте их.
• Применяйте механизм «Управляемых учетных записей служб» (managed service accounts, MSA). MSA поддерживает ряд основных сервисов и служб, используемых в корпоративной инфраструктуре (например, IIS, AD LDS, SQL Server, MS Exchange). Этот механизм автоматически меняет пароли, генерируя сложные случайные пароли длиной до 240 символов, что значительно усложняет подбор пароля. Смена пароля по умолчанию раз в 30 дней делает подбор практически невозможным.
• Определите учетные записи, для которых отключена предварительная аутентификация, и, если возможно, активируйте ее.
• Настройте для протокола Kerberos использование алгоритма шифрования AES (или другого надежного алгоритма) вместо RC4.
• Осуществляйте мониторинг событий изменения значения UAC, которые отражают отключение предварительной аутентификации. Для этого следует отслеживать события 4738 (A user account was changed) и 5136 (A directory service object was modified).
• Проводите мониторинг запрашиваемых билетов Kerberos (Audit Kerberos Service Ticket Operations) и определяйте учетные записи с избыточными событиями 4768 (A Kerberos authentication ticket (TGT) was requested) и 4769 (A Kerberos service ticket was requested), в дополнительных параметрах которых указан тип шифрования RC4 (ticket encryption type — 0x17) и не требуется предварительная аутентификация (pre-authentication type — 0x0).
• Проводите аудит безопасности домена с помощью ПО PingCastle.

NTLM relay

NTLM relay — это атака, при которой злоумышленник перехватывает и перенаправляет учетные данные для аутентификации на другом сервере. Эта атака эксплуатирует уязвимости в протоколе NTLM, который позволяет передавать учетные данные на другой сервер без их расшифрования. Когда пользователь пытается получить доступ к ресурсу (например, файлу или принтеру) в сети, NTLM использует серию сообщений между клиентом (устройством пользователя) и сервером для проверки подлинности. Этот процесс включает в себя три основные шага:

1. Negotiate. Клиент отправляет запрос на сервер на установление соединения по протоколу NTLM.
2. Challenge. Сервер отвечает случайным числом.
3. Authenticate. Клиент хеширует это случайное число вместе с хешированным паролем пользователя и отправляет обратно серверу.

Основные этапы атаки:

1. Перехват трафика. Хакер перехватывает сетевой трафик, содержащий учетные данные.
2. Передача аутентификационных данных. Вместо взлома аутентификационных данных злоумышленник просто перенаправляет их на целевой сервер. Таким образом, он использует легитимные аутентификационные данные для получения доступа к другому ресурсу.
3. Доступ к целевому ресурсу. Если атака прошла успешно, то хакер получает доступ к целевому ресурсу.

Рекомендации:

• Отключите протокол WPAD. Для этого измените значение параметра Start с 3 на 4 в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc. Если необходима автоматическая настройка параметров прокси, укажите полный путь к конфигурационному PAC-файлу.
• Обеспечьте подпись SMB-пакетов как со стороны серверов, так и со стороны клиентов во всей доменной инфраструктуре.
• Обеспечьте подпись LDAP-пакетов и настройте безопасную аутентификацию протокола LDAP.
• Заблокируйте протоколы LAN Manager и NTLMv1 на уровне групповых политик.
• Используйте механизм Extended Protection for Authentication (EPA).
• Для уменьшения площади атаки добавьте пользователей с правами администратора в группу Protected Users и (или) установите для них атрибут Account is sensitive and cannot be delegated, что предотвратит делегирование полномочий. Также рекомендуется рассмотреть возможность перехода с NTLM-аутентификации на Kerberos-аутентификацию на всех узлах инфраструктуры.

sAMAccountName spoofing

Атрибут sAMAccountName — это имя учетной записи пользователя или компьютера в Active Directory. Оно должно быть уникальным в пределах домена и служит для идентификации пользователя при входе в систему. Однако злоумышленник может провести атаку sAMAccountName spoofing, во время которой создаст учетную запись с таким же именем. В результате он сможет использовать эту учетную запись для получения несанкционированного доступа к ресурсу. Рекомендации:

• Установите последние обновления безопасности KB5008380 и KB5008102.
• Для выявления атак включите мониторинг ошибок objectClass и UserAccountControl, а также ошибок проверки имени учетной записи SAM. Важно отслеживать событие 4741 (a computer account was created) и проверять наличие символа "$" в атрибуте sAMAccountName, а также событие 4742 (a computer account was changed) с аналогичной проверкой. Также следует мониторить событие 4743 (a computer account was deleted).
• Следует включить мониторинг запрашиваемых билетов Kerberos (Audit Kerberos Service Ticket Operations). Отслеживайте события, указывающие на то, что служба KDC обнаружила сервисный билет, не содержащий PAC, или билет с противоречивой информацией об учетной записи.
• Проводите аудит безопасности домена с помощью ПО PingCastle.

Shadow credentials

Shadow credentials — это атака, которая позволяет хакеру изменить значения атрибута msDS-KeyCredentialLink атакуемой учетной записи. В результате проведения атаки хакер может добавить свой ключ в этот атрибут и использовать его для выпуска сертификата или запроса TGT, что обеспечит злоумышленнику легитимный доступ к целевым ресурсам. Основные этапы атаки: хакер получает административный доступ к системе, после чего модифицирует атрибут msDS-KeyCredentialLink атакуемой учетной записи, добавляя свои ключи или сертификаты для дальнейшей аутентификации под этой учетной записью.

Рекомендации:

• Запретите участникам группы Everyone изменять атрибут msDS-KeyCredentialLink для любой учетной записи в домене. Если по какой-либо причине это невозможно, необходимо организовать такой запрет для привилегированных учетных записей.
• Настройте аудит всех операций с объектами для учетных записей с высоким уровнем привилегий.
• Дополнительно проводите аудит безопасности домена с помощью ПО PingCastle.
• Если в инфраструктуре (или для определенных пользователей) не используется механизм аутентификации PKINIT, следует осуществлять мониторинг события 4768 (A Kerberos authentication ticket was requested) для выявления инцидентов, когда в атрибуты сертификата была внесена информация.
• Если список управления доступом к объектам (system access control list, SACL) настроен на аудит изменений объектов Active Directory для целевой учетной записи, событие 5136 (A directory service object was modified) позволяет выявлять изменение атрибута msDS-KeyCredentialLink. Важно отметить, что если это действие будет выполняться от имени учетной записи Azure AD Connect synchronization или службы AD FS, то оно не будет зафиксировано как инцидент, поскольку данные типы пользователей имеют легитимные права на изменение этого атрибута.

Атаки на службы сертификатов

Сертификаты в AD используются для различных целей, например для аутентификации пользователей, шифрования данных и построения безопасных соединений. Шаблоны сертификатов в AD — это наборы параметров, определяющих, как, кому и на что могут быть выданы сертификаты. Недостатки конфигурации шаблонов сертификатов могут использоваться хакерами для повышения привилегий.

Существует несколько типов атак:

• Modifiable SAN (ESC1). Хакер использует возможность изменения параметра SAN в шаблоне сертификата для создания сертификата с правами другого пользователя, включая администраторов.
• Any or none purpose attack (ESC2). Злоумышленник использует шаблон с универсальными правами для получения сертификатов, которые могут аутентифицировать любого пользователя. Эти шаблоны не требуют специфической цели использования (extended key usage), что позволяет использовать их для аутентификации любых пользователей, включая администраторов.
• Enrollment agent (ESC3). Атака через шаблон, который позволяет выпускать сертификаты от имени других пользователей. Злоумышленник получает сертификат Request Agent и затем использует его для создания сертификатов от имени учетных записей с высокими привилегиями.
• Certificate ACL abuse (ESC4). Хакер использует слабую настройку ACL (списков контроля доступа) для захвата прав на шаблоны сертификатов. Они позволяют изменять параметры шаблона, чтобы сделать его уязвимым для других атак, таких как ESC1, что позволит получить привилегированные сертификаты.
• Vulnerable PKI object access control (ESC5). Атака на другие объекты в инфраструктуре AD CS с уязвимыми параметрами доступа, которые могут позволить злоумышленнику компрометировать систему. Например, недостатки в конфигурации доступа к серверу CA могут быть использованы для выполнения операций с повышенными привилегиями.
• Everything and for everyone (EDITF_ATTRIBUTESUBJECTALTNAME2). Хакеры используют флаг EDITF_ATTRIBUTESUBJECTALTNAME2 для добавления произвольных значений в поле SAN, чтобы аутентифицироваться от имени любого пользователя, включая администраторов домена.
• ManageCA & managecertificate (ESC7). Злоумышленник может использовать права ManageCA для изменения параметров CA, что может включать активацию флага EDITF_ATTRIBUTESUBJECTALTNAME2 или других параметров, создающих уязвимости.
• Relay на AD CS Web Enrollment (ESC8). Хакер может перенаправить NTLM-аутентификацию на уязвимый HTTP-эндпойнт, чтобы получить сертификат для клиентской аутентификации и использовать его для получения TGT (ticket-granting ticket) доменного контроллера.
• No Security Extension (ESC9). Хакер использует значение CT_FLAG_NO_SECURITY_EXTENSION (0x80000) в атрибуте msPKI-Enrollment-Flag, чтобы предотвратить добавление расширения безопасности szOID_NTDS_CA_SECURITY_EXT в сертификат. Это позволяет обойти ограничения маппинга сертификатов, заданные значением 1 ключа реестра StrongCertificateBindingEnforcement, и использовать userPrincipalName (UPN) при аутентификации.
• Weak Certificate Mappings (ESC10). Эта атака использует небезопасную конфигурацию маппинга сертификатов на контроллере домена, которая связана с параметрами CertificateMappingMethods со значением 0x18 (или содержащим флаг UPN) и StrongCertificateBindingEnforcement со значением 0. Эти настройки позволяют злоумышленнику, обладающему правом GenericWrite, получать сертификаты от имени других учетных записей.
• Relaying NTLM to ICPR (ESC11). Хакер использует отсутствие атрибута IF_ENFORCEENCRYPTICERTREQUEST на сервере CA для выполнения ретрансляции NTLM (NTML relay) без подписи через службу RPC. Это позволяет запрашивать сертификаты через уязвимый сервер CA, используя учетные данные администратора домена.
• Shell Access to ADCS CA with YubiHSM (ESC12). Эта атака предполагает, что частный ключ CA хранится на внешнем устройстве YubiHSM2, подключенном к серверу CA. Если злоумышленник получает доступ к реестру, где хранится пароль к YubiHSM, он может использовать этот пароль для доступа к закрытому ключу и подделки сертификатов через CA.
• OID Group Link Abuse (ESC13). Шаблон сертификата может содержать политику выдачи, которая является OID в атрибуте msPKI-Certificate-Policy. Политика выдачи содержит атрибут msDS-OIDToGroupLink, который позволяет привязать политику к группе AD для того, чтобы пользователь мог авторизоваться в системе в качестве ее члена. Если злоумышленник обладает правами на выпуск сертификата по уязвимому шаблону, он может получить привилегии группы, связанной с этой политикой, и таким образом получить доступ к целевым ресурсам.
• Weak Explicit Mapping (ESC14). Эта атака основана на небезопасной конфигурации явного маппинга сертификатов. Злоумышленник, скомпрометировавший атакуемую учетную запись и обладающий возможностью запрашивать сертификаты, может использовать небезопасную конфигурацию сопоставления для аутентификации от имени целевой учетной записи.

Рекомендации (зависят от типа атаки на службы сертификатов):

• Отслеживайте события 4899 (A Certificate Services template was updated), в котором отображаются измененные атрибуты, и 4900 (Certificate Services template security was updated), в котором отображаются изменения разрешений безопасности. Стоит отметить, что эти события срабатывают не в момент внесения изменений в шаблон, а только при запросе сертификата с новыми свойствами.
• Для выявления подозрительных запросов на получение сертификата следует отслеживать событие 4898 (Certificate Services loaded a template), в котором содержатся свойства шаблона выпускаемого сертификата. Наличие в этом событии флага ct_flag_enrollee_supplies_subject указывает на то, что пользователю разрешено указывать альтернативное имя субъекта в запросе. Также нужно отслеживать события 4886 (Certificate Services received a certificate request), 4887 (Certificate Services approved a certificate request and issued a certificate) и 4888 (Certificate Services denied a certificate request), в которых содержатся сведения о пользователе, запросившем сертификат, и узле, с которого запрос получен, а также время создания запроса.
• Выполняйте мониторинг события 4768 (A Kerberos authentication ticket was requested) для выявления использования нелегитимных сертификатов по их серийному номеру при аутентификации.

ShadowCoerce

В системе Windows есть служба Volume Shadow Copy Service (VSS), предназначенная для создания теневых копий файлов и томов. VSS позволяет выполнять резервное копирование системных файлов, не прерывая работу приложений и пользователей. Атака ShadowCoerce использует уязвимости протокола MS-FSRVP службы VSS и позволяет принудить учетную запись контроллера домена Active Directory авторизоваться на узле, подконтрольном злоумышленнику. В результате проведения атаки он сможет получить учетную запись контроллера домена.

Рекомендации:

• Отключите на контроллерах домена службу теневого копирования (VSS) с помощью консоли управления.
• Используйте механизм Extended Protection for Authentication (EPA).
• Настройте обязательную подпись SMB-пакетов как на серверах, так и на клиентах.
• Вы можете проводить регулярный аудит безопасности домена с помощью ПО PingCastle.