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

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

• Двухфакторная аутентификация в домене.

• Доработка защиты SMB — подпись против шифрования.

• Процесс выпуска сертификатов (PKI). 

• События Windows для Threat Hunting и корреляции в SIEM.

• Защита процесса LSASS. 

Двухфакторная аутентификация в домене

Основная задача 2FA — защита учётной записи в случае утечки пароля. Для входа злоумышленнику понадобится второй фактор — код TOTP, пуш на телефон, сообщение в Телеграме или СМС и др. Идея простая, но как её правильно реализовать в корпоративном домене — вопрос далеко не тривиальный.

Решение без сторонних агентов — установка Windows Hello for Business (WHfB) на интерактивный вход в Windows. Это не ещё один пароль, а связка «ключ на устройстве» + PIN/биометрия. Если 2FA требуется не для входа в систему, а для других ресурсов, роль поставщика 2FA остаётся за ADFS. Это служба федерации Active Directory: она позволяет раздавать пользователям доступ к порталам, SaaS-приложениям или VPN, сохраняя контроль на стороне компании. Если кратко — ADFS в целом даёт много гибкости и в том числе может «навешивать» условия на аутентификацию. Один из вариантов такой схемы приведён на картинке ниже. 

Подробнее об MFA в ADFS можно прочитать здесь. Важно, что второй фактор — стороннее решение, которое предоставляет и проверяет не Microsoft. В данном случае это делает miniOrange Authentication Server, но вариантов много. Очевидно, что это уже не совсем «без сторонних агентов».

Решения на основе агентов — Indeed, Aladdin, Cisco Duo MFA и других. Их используют, если внедрение WHfB невозможно или просто нежелательно. Сторонний агент добавляет второй фактор на логоне. Из зарубежных решений — Cisco Duo добавляет второй фактор на локальный вход и RDP, а также интегрируется как провайдер 2FA для ADFS. После ввода доменных учётных данных система инициирует push/OTP/пасскод — и без подтверждения на рабочий стол не попасть.

В российском поле ту же роль выполняют Aladdin (JaCarta Authentication Server), Indeed AM и MFASoft. Они добавляют второй фактор и к интерактивному входу, и к RDP, и при подключении через VPN для удалённых сотрудников.
 
В случае 2FA нерационально «бить по площадям» и внедрять её для всех во всей инфраструктуре. Как показывает моя практика, 2FA по схеме «пароль + TOTP» на вход в компьютер раздражает всех пользователей. Но для отдельных привилегированных учётных записей или в средах, обрабатывающих чувствительную информацию — хороший шаг. 

SMB: подпись против шифрования

Когда в компании говорят «У нас включена подпись SMB», — это часто подаётся как точка в обсуждении — как будто это предел защиты в этом месте. Это не всегда достаточная мера, на мой взгляд. Подпись гарантирует целостность пакета и защищает от атак «человек посередине», но она не скрывает содержимое. Если злоумышленник устанавливает сниффер и получает возможность перехватывать трафик, он увидит имена файлов, структуру каталогов и многое другое.

Здесь на сцену выходит шифрование SMB, появившееся в третьей версии протокола. В отличие от подписи, шифрование обеспечивает конфиденциальность передаваемых данных и делает содержимое пакетов нечитаемым.

Подпись и шифрование решают разные задачи. Подпись защищает от подмены пакетов, шифрование — от чтения. Но эти два параметра не включаются вместе. Нет необходимости настраивать и подписывание SMB, и шифрование, поскольку шифрование — более сильная мера защиты и неявно включает подписи.

Звучит неплохо, но есть нюанс — производительность. Подпись тоже требует ресурсов, но относительно немного. А вот шифрование может сильно нагружать CPU, особенно если файловый сервер работает с большими объёмами данных. Поэтому включать его надо точечно: на серверах, где проходят чувствительные данные. 

Отдельно скажу про SMBv1, так как упустил этот пункт в первой части. Если он ещё живёт в вашей сети — это не вопрос подписи или шифрования (которого там и нет). Это уязвимый протокол, и SMBv1 нужно отключать, если в вашем оборудовании он ещё не отключен по умолчанию.

LSASS и как взломщик расшифрует SMB

Зашифрованный SMB-трафик действительно защищает от пассивного перехвата, но шифрование не поможет, если атакующий имеет доступ в систему и может прочитать память процесса LSASS. В этом материале (уже упомянутом выше) приведён метод расшифровки трафика SMB с помощью извлекаемого из LSASS пароля. 

Справедливости ради, процесс LSASS требует внимания не только из-за атак на SMB. Если атакующие получат дамп процесса и сумеют извлечь из него данные — расшифровка трафика SMB будет наименьшей из ваших проблем. LSASS — отличный источник аутентификационных данных, и извлечённую из него информацию можно применить множеством вредоносных способов. 

Чтобы избежать извлечения аутентификационной информации, нужно защитить процесс LSASS, содержащий учётные данные пользователей машины. У меня есть подробная статья на эту тему, но если у читателя произошёл TL;DR, скажем коротко — для защиты процесса LSASS нужно включить LSA Protection / RunAsPPL и по возможности — Credential Guard. 

При включении LSA Protection LSASS становится защищенным «Protected Process Light», и обычные методы дампа (через procdump, Task Manager, Mimikatz) не работают напрямую. Это не абсолютная гарантия защиты, но серьёзное затруднение для атакующего. Credential Guard обеспечивает ещё более надёжную защиту, изолируя секреты в защищённой виртуальной среде. 

Сертификаты в домене: зачем нужны и где опасности

Службы сертификации Active Directory (AD CS) — это роль сервера Windows, управляющая инфраструктурой открытых ключей (PKI). Проще говоря, AD CS отвечает за выпуск сертификатов, которые используются для трёх целей: шифрования данных, цифровых подписей и аутентификации пользователей и устройств.

Работает это так: 

1. Пользователь или компьютер отправляет запрос на сертификат в центр сертификации (CA).

2. Центр проверяет права и применяет выбранный шаблон — набор правил, какой именно сертификат можно выдать, кому и для чего. 

3. Если всё в порядке, CA выпускает сертификат, подписывает его своим ключом и отдаёт обратно. 

4. После этого сертификат можно использовать.

Классическая модель построения инфраструктуры открытых ключей в организации предполагает наличие корневого центра сертификации (Root CA). Его используют исключительно для выпуска сертификатов промежуточных центров сертификации (Issuing CA). После этого корневой CA выводят из эксплуатации: отключают или изолируют в защищённом хранилище. Его использование допускается только в исключительных случаях — для выпуска сертификата нового промежуточного центра или формирования списка отзыва сертификатов (CRL). Все рабочие операции, включая выпуск сертификатов для пользователей, компьютеров и сервисов, выполняются промежуточными центрами сертификации.

Зачем такая сложность? Всё просто: если злоумышленник скомпрометирует промежуточный CA, то можно отозвать его сертификат, при этом не обрушив всю PKI. А вот если скомпрометирован корневой CA, игра окончена — доверие к корню теряется, и вся инфраструктура рушится. Поэтому в нормальной практике Root держат офлайн, а Issuing — онлайн. Это называется двухуровневой PKI и считается хорошей практикой.

Тем не менее в инфраструктурах именно PKI чаще всего становится ахиллесовой пятой. Причина — в шаблонах сертификатов. Атаки на инфраструктуру сертификатов в AD имеют собственное имя и классификацию — ESC (Enterprise Certificate Services escalations). Классический сценарий — ESC1: неправильно настроенный шаблон позволяет обычному пользователю указать в заявке произвольный SAN (Subject Alternative Name) и получить сертификат, который система воспримет как «админский». И домен этому поверит.

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

Как защищаться: 

1. Проверьте все существующие шаблоны сертификатов. 

Начните с разрешения на регистрацию: кто может запрашивать сертификат, не предоставлено ли право Enroll слишком широким группам (например, «Authenticated Users» или «Domain Users») для шаблонов сертификатов с повышенными правами.

2. Включите «CA certificate manager approval» в разделе «Issuance Requirements». Тогда каждый запрос по этому шаблону будет требовать ручного одобрения оператора. Такой подход сильно снижает риск злоупотреблений: даже если злоумышленник получил доступ к учётной записи с правом Enroll, без подтверждения от ответственного лица сертификат он не получит.

3. Проверьте и сами свойства шаблонов. В параметрах «Subject Name» уберите возможность указывать произвольный SAN — именно эта опция лежит в основе классической атаки ESC1. Если оставить её включённой, любой пользователь с правом Enroll сможет вписать себе SAN=Domain Admin и получить сертификат с привилегиями администратора.

4. Обратите внимание на EKU (Enhanced Key Usage). Сертификат для веб-сервера должен иметь только Server Authentication, а не одновременно Code Signing, Client Authentication и ещё десяток EKU. Чем шире назначение — тем больше ущерб, который злоумышленник сможет нанести, завладев таким сертификатом. Строго говоря, требование адекватных EKU — очередное следование «принципу минимальных привилегий». 

5. Проверьте, кто управляет шаблонами. Нередко в реальных инфраструктурах доступ к изменению свойств шаблонов остаётся у Domain Admins. По-хорошему, этими правами должна обладать только узкая группа администраторов центра сертификации.

Для быстрой автоматизированной проверки шаблонов и настроек PKI полезно применять специализированные инструменты аудита — Certify или PSPKIAudit. 

Логирование и детектирование

Многие компании включают аудит «по максимуму», собирают все события и гордо говорят: «У нас всё логируется». А потом сталкиваются с тем, что SIEM засыпает ложными срабатываниями, а нужное тонет в море шума. Идея собирать в SIEM максимум логов c конечных точек, периметровых файрволов, контроллеров домена и CA — действительно неплохая. С условием, что на выходе аналитик SOC получает не сырые данные, а что-то более удобочитаемое.

Поэтому следующий шаг после настройки логирования — перевод сырых событий в понятные «сигналы» с помощью нормализации и корреляции. Это не про массовую фильтрацию, а про построение связей: кто, откуда и с каким инструментом выполнил действие; какие события предшествовали и какие последовали. В практической работе SOC не всегда один-единственный ивент создаёт алерт. Как правило, это определённая цепочка или последовательность.

Однако здесь мы не будем приводить конкретных корреляционных правил. У любого вендора в коробке уже есть целый набор: от простых сигнатурных до достаточно сложных сценариев, закрывающих базовые техники из MITRE ATT&CK. И это логично: никто не ждёт от инженера, что он начнёт с нуля придумывать детекты для Kerberoasting или Pass-the-Hash. На старте вполне достаточно включить и протестировать предустановленный пакет, а задача команды — понять, как эти правила «ложатся» именно на их сеть.

Потом начинается более рутинная, но важная работа: 

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

• Создание кастомных правил, которые отражают специфику конкретной инфраструктуры. У каждой компании есть свои уникальные процессы: нестандартные сервисные аккаунты, кастомные системы, административные процедуры. Всё это со временем требует «доточки» — либо через новые правила, либо через адаптацию старых.

Поэтому рекомендация простая: не переусложняйте внедрение, начинайте с того, что уже есть в коробке у вашего SIEM, смотрите, какие из правил реально приносят пользу, а какие — создают бесполезный шум. Отключайте лишнее, добавляйте исключения, адаптируйте под ваши процессы. И лишь затем переходите к написанию собственных, «заточенных» под ваш бизнес. Именно так ваша SIEM эволюционирует из «чёрного ящика с логами» в инструмент защиты инфраструктуры.

Вместо заключения

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

Резюмируя: 

• 2FA уменьшит риски, возникающие от компрометации пароля.

• Подпись SMB защищает от перенаправления и внедрения фальшивых PDU, а шифрование SMB — от перехвата и анализа трафика.

• Защита процесса LSASS с помощью RunAsPPL/Credential Guard усложняет для атакующих получение аутентификационных данных.

• Защита от атак на сертификаты типа ESC — богатая тема и отличный повод «перетряхнуть» шаблоны сертификатов.

• К анализу и мониторингу надо подходить с умом. В том числе, не переусложнять логику работы, стараясь избегать «шумных» или малоинформативных корреляционных правил. Стараться в начале внедрения «дотачивать» правила из комплекта поставки, а потом уже писать свои. 

Тем не менее не покидает ощущение, что тема до конца не исчерпана. Не зря по теме защиты AD пишутся книги и защищаются дипломные работы. 

Главное же правило «бойцовского клуба» остаётся неизменным: не ждать атаки, а учиться её обнаруживать и пресекать до наступления последствий. 

НЛО прилетело и оставило здесь промокод для читателей нашего блога:

-15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS