Атаки на Active Directory (AD) могут происходить быстро. Вы должны быть быстрее. Как только злоумышленник использует учетную запись пользователя AD, ваши шансы найти его уменьшаются. Они могут получить повсеместный доступ – даже доступ администратора. Они могут перемещаться по системам незамеченными и выполнять код, как если бы они были предполагаемым пользователем. Когда вы понимаете, что что-то не так, часто бывает уже слишком поздно: ущерб нанесен. Злоумышленник вывел данные, заразил системы или запустил программу-вымогатель. Вам остается только разгребать последствия.
В этом блоге рассматривается, как с помощью мониторинга сети можно поймать злоумышленников, атакующих среды Active Directory. Лучшие методы обнаружения выявляют злоумышленников на самых ранних стадиях, сокращая при этом количество ложных срабатываний. По этой причине нужно сосредоточится на поимке злоумышленников на стадии разведки, которая является ранней частью любой атаки.
Разведка LDAP
По умолчанию любой обычный пользователь AD в домене имеет разрешения на чтение LDAP для этого домена. Таким образом, злоумышленник, скомпрометировавший пользователя домена (пользователя, не входящего в группу с высокими привилегиями, такую как администраторы домена), сможет выполнить разведку домена для сопоставления объектов домена. Разведка является ключевой частью любой атаки на AD, поскольку она позволяет злоумышленнику составить карту среды жертвы. Затем они могут использовать эти данные для латерального перемещения и повышения привилегий. Сосредоточимся на следующих атрибутах LDAP, чтобы поймать злоумышленника на этапе разведки:
UserAccountControl
Атрибут UserAccountControl в AD определяет конфигурацию определенных параметров учетной записи. Например: UserAccountControl может указывать на отключенные учетные записи или учетные записи, которые не требуют предварительной аутентификации Kerberos при входе в систему.
Следующий список содержит все возможные опции для UserAccountControl:
Image Source: Microsoft
Сосредоточимся на LDAP-запросах, в которых злоумышленники ищут следующие флаги свойств UserAccountControl:
PASSWD_NOTREQD, DONT_REQ_PREAUTH, TRUSTED_FOR_DELEGATION, ENCRYPTED_TEXT_PWD_ALLOWED.
PASSWD_NOTREQD
Когда учетная запись пользователя AD имеет флажок PASSWD_NOTREQD, это значит, что для входа в нее не требуется пароль. Злоумышленники будут искать такие учетные записи без пароля. Цель злоумышленника – продвинуться по домену и скомпрометировать учетные записи домена. Чем быстрее они достигнут этой цели, тем меньше вероятность того, что их обнаружат на этой ранней стадии атаки. Вход в эти типы учетных записей AD ускоряет время проникновения, поскольку отпадает необходимость в поиске пароля учетной записи.
Отметим следующий LDAP-запрос как подозрительный:
DONT_REQ_PREAUTH
Когда учетная запись пользователя AD имеет флажок DONT_REQ_PREAUTH, злоумышленник может запросить зашифрованный Ticket Granting Ticket (TGT) для пользователя без предоставления пароля. TGT подписывается паролем целевого пользователя, что позволяет злоумышленнику попытаться перебрать пароль в автономном режиме. Этот тип атаки известен как «As-Rep Roasting» (MITRE T1558.004).
Отметим следующий LDAP-запрос как подозрительный:
TRUSTED_FOR_DELEGATION
Если для учетной записи компьютера AD установлен флаг TRUSTED_FOR_DELEGATION, компьютер сохраняет билет Ticket Granting Ticket. Злоумышленник, которому удастся скомпрометировать учетную запись компьютера, сможет сбросить билеты KERBEROS TGT для всех вошедших в систему пользователей. Кроме того, злоумышленники могут использовать различные техники для принудительной проверки подлинности учетной записи компьютера-жертвы с целью последующего сброса билетов KERBEROS TGT.
Отметим следующий LDAP-запрос как подозрительный:
ENCRYPTED_TEXT_PWD_ALLOWED
Когда для учетной записи пользователя AD установлен флаг ENCRYPTED_TEXT_PWD_ALLOWED, злоумышленник, скомпрометировавший базу данных AD, получает доступ к паролю учетной записи пользователя в виде открытого текста. Обычно такие пароли хранятся в формате хэша NTLM. Доступ к открытому тексту ускоряет атаку, поскольку отпадает необходимость в переборе пароля.
Отметим следующий LDAP-запрос как подозрительный:
Service Principal Name
Учетная запись службы
Учетная запись службы – это учетная запись пользователя AD, созданная для запуска определенной службы или приложения.
Например, если службе SQL нужен доступ к ресурсам в домене, можно создать учетную запись службы с правом доступа к ресурсам и использовать ее.
В AD используется атрибут service principal name (SPN) для того, чтобы различать различные службы.
Для каждой учетной записи службы будет определен SPN, представляющий конкретную службу, для которой он был создан.
KERBEROS Service Tickets
После аутентификации Kerberos любой вошедший в систему пользователь может запросить у контроллера домена Kerberos (KDC) доступ к любой службе в домене. Служба идентифицируется с помощью SPN.
Когда учетная запись запрашивает доступ к службе в домене, KDC возвращает клиенту билет службы. Билет службы шифруется с помощью хэша пароля запрошенного объекта домена, на котором размещена служба. Например, при подключении с помощью SSH к компьютеру домена билет службы шифруется хэшем компьютера домена, на котором расположена служба SSH. Злоумышленник, получивший билет на услугу, может попытаться перебрать хэшированный пароль в автономном режиме.
Пароль машинной учетной записи задается случайным образом и имеет длину 120 символов, в то время как пароли пользовательских учетных записей обычно короче и часто следуют предсказуемым шаблонам. Это делает попытку взлома пароля пользователя быстрее и проще, чем попытку взлома пароля учетной записи машины.
KERBEROASTING ATTACK
Тот факт, что в учетной записи сервиса настроен SPN, а также то, что любой вошедший в систему пользователь может запросить билет на сервис в домене, позволяет злоумышленнику, скомпрометировавшему низкопривилегированного пользователя домена, найти пользователей сервиса, запросить для них билет на сервис и перебрать их пароль в автономном режиме. Эта атака известна как «KERBEROASTING» (MITRE T1558.003).
Пример подозрительного LDAP-запроса:
Пароли в открытом тексте
Следующие атрибуты LDAP могут содержать пароли в виде открытого текста:
UnixUserPassword
UnixUserPassword – это атрибут LDAP для систем на базе UNIX. Злоумышленник может перечислить домен для пользователей с настроенным UnixUserPassword, так как он может быть сохранен в формате открытого текста.
Пример подозрительного LDAP-запроса:
Описание
Плохо конфигурированная среда Active Directory может содержать пароль в описании:
Будем отмечать запросы LDAP, которые ищут пароль в описании, например:
NT-Security-Descriptor
Active Directory использует список управления доступом (ACL) для авторизации учетных записей.
Знание ACL учетных записей в AD позволит злоумышленникам планировать свои атаки для латерального перемещения и повышения привилегий в домене. Этот инструмент с открытым исходным кодом использует анализ ACL для составления карты возможных атак на данный домен:
AD сохраняет ACL объекта в LDAP-атрибуте ‘nTSecurityDescriptor’.
‘nTSecurityDescriptor’ делится на 4 части:
- Владелец – владелец объекта
- Group SID (Security identifier) – группа, связанная с объектом.
- DACL – список разрешений/запретов для объекта:
- SACL – аудит разрешений для объекта:
— Злоумышленник, скомпрометировавший низкопривилегированного пользователя AD, не будет иметь разрешения на часть SACL дескриптора безопасности. DACL является наиболее важной частью дескриптора с точки зрения злоумышленника, поскольку она определяет разрешенные действия, которые объект может выполнять в домене. Чтобы получить часть DACL в дескрипторе безопасности с помощью LDAP, злоумышленник должен указать, какая часть дескриптора его интересует. LDAP использует элемент управления под названием ‘LDAP_SERVER_SD_FLAGS_OID’, который контролирует, какую часть дескриптора можно получить.
Следующие флаги описывают различные возможные дескрипторы:
Image Source: Microsoft
Чтобы поймать злоумышленника, выполняющего анализ ACL с помощью LDAP, будем отслеживать запросы на объект nTSecurityDescriptor с одним из LDAP_SERVER_SD_FLAGS_OID. Например, можно выявить злоумышленника, который запрашивает только DACL:
Заключение
Субъекты угроз постоянно совершенствуются, создавая все новые и новые методы получения доступа к конфиденциальной информации. Разведка является ключевой частью любой атаки на AD. Без отображения объектов AD и их соединений злоумышленникам будет сложно скомпрометировать домен. Применение правил обнаружения помогает поймать злоумышленников на ранней стадии, пока ущерб еще не нанесен. Чтобы обезопасить свою организацию, убедитесь, что ваши системы находятся в актуальном состоянии и что вы установили автоматизированную систему обнаружения, такую как Fidelis Elevate, для проактивной защиты от киберугроз и активных атак.
Узнать больше о платформе Fidelis Elevate.
Источник: How to Spot and Stop Active Directory Attacks Faster
