В домене редко бывает одна «фатальная» настройка, которая сама по себе объясняет будущий инцидент. Гораздо чаще риск складывается из обычных сущностей: сервисной учётной записи, старого исключения для совместимости, привилегии, выданной когда-то под конкретную задачу.
Поэтому аудит Active Directory полезно начинать не с бесконечного списка настроек, а с учётных записей, которые могут стать началом цепочки. 2 сентября в 19:00 МСК на открытом практикуме «Как атакуют Active Directory» этот подход разберут через путь от первоначальной информации о домене до слабой конфигурации и получения учётных данных.
Сервисные учётные записи с SPN
Сервисные учётные записи обычно существуют ради конкретной службы: базы данных, веб-приложения, файлового ресурса. Для них в домене могут быть заданы Service Principal Name — SPN. Это нормальный механизм Kerberos: пользователь запрашивает билет для сервиса, а контроллер домена возвращает ответ, связанный с учётной записью, от имени которой работает служба.
Проблема начинается не от самого SPN. Риск появляется, когда сервисная учётная запись живёт годами, её пароль редко меняется или когда пароль оказывается простым и предсказуемым. В такой ситуации легитимные запросы билетов могут использоваться для получения данных, пригодных для офлайн-подбора пароля. Это сценарий Kerberoasting.
При проверке важно не просто получить список SPN, а задать к каждой записи несколько вопросов: кто владелец сервиса, действительно ли он ещё работает, когда менялся пароль, есть ли у учётной записи избыточные привилегии, можно ли заменить её на управляемую сервисную учётную запись.
Посмотреть, как слабости ищет атакующий.
Пользователи с отключённой предварительной аутентификацией
Для Kerberos предварительная аутентификация — обычное поведение. Перед выдачей TGT пользователь доказывает, что располагает секретом, связанным с его паролем. Но для отдельных учётных записей эту проверку иногда отключают ради совместимости или старого технического требования.
Именно такие записи стоят в верхней части приоритета. Для атаки AS-REP Roasting достаточно знать валидное имя пользователя и обнаружить, что предварительная аутентификация выключена. Контроллер домена в этом случае может вернуть ответ, часть которого связана с пользовательским секретом. Дальше попытка подобрать пароль происходит автономно — за пределами инфраструктуры.
Это не повод включать настройки вслепую. Сначала нужно выяснить, почему исключение существует и не сломает ли его отмена работу устаревшего сервиса. Но оставить исключение без владельца, срока пересмотра и компенсационных мер — почти всегда плохая идея. Полезная цель аудита — добиться, чтобы каждая такая учётная запись была либо обоснована и контролируема, либо возвращена к стандартной схеме аутентификации.
Привилегированные учётные записи и их следы
Отдельный список — записи с административными правами: администраторы домена, операторы, владельцы критичных систем и технические пользователи с расширенными разрешениями. Здесь важно смотреть не только на состав групп. В Active Directory права могут задаваться через ACL, делегирование и наследование, поэтому «обычный» пользователь иногда получает возможность менять объект или группу, от которых зависит значительно более важная часть инфраструктуры.
Проверьте, кто имеет право изменять привилегированные группы, сервисные учётные записи и объекты, связанные с делегированием. Затем отделите постоянные права от временных и исторических.
Учётная запись бывшего подрядчика, старое исключение для внедрения или технический пользователь без понятного владельца — не мелкая административная неточность, а потенциальная точка для развития атаки.
Учётные записи, которые «никому не принадлежат»
В аудитах особенно опасны не самые заметные записи, а те, про которые никто не может уверенно сказать: кто использует их сейчас и что произойдёт при отключении. Это могут быть старые сервисные пользователи, тестовые учётные записи, временные администраторы или записи, созданные для миграции.
Для них стоит зафиксировать минимум: владельца, назначение, используемые сервисы, уровень привилегий, дату последнего пересмотра и понятный план отключения. Если на эти вопросы нет ответа, технически «нужная» учётная запись становится управленческим риском. Сначала собирайте доказательства зависимости, затем сокращайте права и только после этого выводите запись из эксплуатации.
С чего начать проверку
Не пытайтесь за один проход исправить всё. Сформируйте короткую очередь: сервисные учётные записи с SPN, пользователи без предварительной аутентификации, привилегированные записи и объекты без владельца. Для каждой находки оцените два фактора: насколько легко ею воспользоваться и к каким системам приведёт успешный доступ.
Такой подход помогает не просто закрыть одну известную технику, а увидеть связи между аутентификацией, правами и сервисами.
Практикум «Как атакуют Active Directory»
2 сентября в 19:00 МСК эксперт CyberED покажет путь от первоначальной информации о домене к слабой конфигурации и получению учётных данных.
Вы сможете увидеть, как Kerberos, конфигурация учётных записей и найденные права связываются в единый сценарий.
Записаться на практикум
