4 атаки на сервисные аккаунты и способы защиты от них

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

Поскольку сервисные аккаунты не привязаны непосредственно к человеку, к ним нужно относиться иначе, чем к другим учетным записям. Одним из важных примеров является политика паролей. Можно использовать очень длинные и сложные пароли для сервисных аккаунтов, поскольку не нужно беспокоиться о том, что человек их забудет.

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

С помощью LDAP-разведки злоумышленники могут обнаружить служебные учетные записи в ИТ-среде и избежать при этом обнаружения.

Active Directory предоставляет множество преимуществ в области безопасности и управления, но также может заметно упростить задачу по взлому для злоумышленника.

Благодаря архитектуре AD, проникнув на любой компьютер, подключенный к домену, злоумышленник получает возможность запрашивать каталог и его объекты. А поскольку по умолчанию в Active Directory не предусмотрен механизм аудита и оповещения о подозрительной активности, злоумышленникам часто удается избежать обнаружения.

После того как злоумышленник получил список сервисных аккаунтов, его следующим шагом будет их использование в своих интересах.

Техника Kerberoasting особенно страшна тем, что не требует привилегий администратора домена, очень проста в исполнении и ее практически невозможно обнаружить.

Kerberoasting — это атака, использующая функцию протокола Kerberos для сбора хэшей паролей учетных записей пользователей Active Directory. Любой аутентифицированный пользователь домена может запросить сервисные билеты для учетной записи, указав ее Service Principal Name (SPN), и сервер выдачи билетов (Ticket Granting Service, TGS) на контроллере домена вернет билет, зашифрованный с помощью NTLM-хэша пароля учетной записи.

Поэтому, обнаружив SPN учетных записей служб с помощью тактики LDAP-разведки, злоумышленник может собрать билеты для всех этих учетных записей. Выведя эти данные в автономный режим, он может методом подбора brute force взломать пароль каждого сервисного аккаунта в открытом тексте — без риска обнаружения или блокировки учетной записи.

Злоумышленнику потребуется всего несколько минут для получения доступа к домену, сбора билетов и начала процесса взлома. После этого остается только ждать, пока не будет взломана один или несколько сервисных аккаунтов, которые можно будет использовать для кражи или шифрования конфиденциальных данных и нанесения другого ущерба.

Серебряные билеты (Silver Tickets) — это поддельные билеты Ticket Granting Service (сервер выдачи билетов), созданные злоумышленником на основе хэша пароля взломанного сервисного аккаунта.

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

• Злоумышленнику не требуется аутентифицировать учетную запись на контроллере домена для получения поддельного TGS, поэтому он может действовать без создания сетевого трафика и журналов событий, чтобы избежать обнаружения.
• Серебряный билет может быть создан для любой учетной записи пользователя, даже фиктивной. Это позволяет злоумышленнику использовать сервисный аккаунт без риска его обнаружения, что может привести к сбросу пароля и потере доступа.
• Сертификат привилегированного атрибута (Privileged Attribute Certificate) в билете TGS также может быть использован для повышения уровня доступа учетной записи к домену. В большинстве случаев PAC не проверяется на контроллере домена при предоставлении TGS.

Например, злоумышленник может скомпрометировать сервисный аккаунт SQL. Но эта учетная запись не имеет доступа к базам данных и не может войти в компьютер в интерактивном режиме, поэтому злоумышленник мало что может с ней сделать. Silver Tickets позволяет повысить ее привилегии и получить с ее помощью полный контроль над всеми базами данных, размещенными на взломанном SQL Server. Что еще лучше для злоумышленников, они могут делать это, оставаясь очень трудно обнаруживаемыми.

Самый мощный сервисный аккаунт в любой среде Active Directory — это учетная запись KRBTGT, которая используется для выдачи билетов Kerberos, необходимых для доступа к ИТ-системам и данным. Получив хэш пароля этой учетной записи из центра распределения ключей (Key Distribution Center, KDC), злоумышленник может скомпрометировать любую учетную запись в Active Directory, получив неограниченный и практически не обнаруживаемый доступ к любой системе, подключенной к сети AD.

Обнаружить атаки на Active Directory с использованием золотых билетов очень сложно, поскольку они выглядят как вполне корректные Ticket-Granting Ticket (билеты, удостоверяющие личность пользователя). Однако в большинстве случаев они создаются со сроком жизни 10 лет и более, что значительно превышает значения, установленные в Active Directory по умолчанию для продолжительности действия билета.

Хотя временные метки TGT не записываются в журналы аутентификации Kerberos, подходящие решения по безопасности Active Directory способны их отслеживать. Если вы обнаружили, что в вашей организации используются золотые билеты, необходимо дважды сбросить учетную запись KRBTGT; это может иметь далеко идущие последствия, поэтому действуйте с осторожностью.

Существуют меры, которые можно предпринять для предотвращения неправомерного использования и сервисных аккаунтов. К ним относятся ограничение интерактивного входа в систему и автоматизация управления паролями.

Обнаружить атаку на сервисный аккаунт очень сложно, но решение Makves DCAP Domain Audit обеспечивает всестороннюю видимость, необходимую для комплексной защиты среды Active Directory. С его помощью вы сможете:

• Обнаружить риски безопасности в Active Directory и определить приоритетность усилий по их снижению.
• Исправить риски «на месте»: управлять учетными записями в интерфейсе системы, создавать, настраивать и редактировать правила автоматического реагирования.
• Следить за текущим состоянием пользователей и групп, правами доступа, групповыми политиками и их настройками.
• Укрепить конфигурации безопасности во всей ИТ-инфраструктуре.