Источник: https://github.com/AnaktaCTF/CTF/blob/main — Misc/AS_REP_Roasting.md

1

Атака AS-REP Roasting - это один из излюбленных методов злоумышленников для получения учетных данных в инфраструктуре, использующей протокол Kerberos, например в домене Active Directory. Эта техника позволяет извлечь зашифрованные хэши паролей пользователей, не требуя их предварительной аутентификации. После этого хэши можно подвергнуть офлайн-атаке перебора паролей, не вызывая подозрительной активности в сети.

Особенность этой атаки заключается в её незаметности и эффективности, особенно в случаях, когда в домене присутствуют учетные записи, у которых отключена проверка подлинности на этапе запроса билета (pre-authentication). Такие учетные записи могут появляться по ошибке или быть специально настроены для автоматических задач, что делает их уязвимыми.

Понимание принципов работы этой атаки и способов защиты от неё крайне важно для системных администраторов и специалистов по информационной безопасности. В этой статье мы разберёмся, как работает AS-REP Roasting, как она реализуется на практике, и какие меры следует принять для минимизации рисков.

2. Как работает Kerberos

Для того чтобы понять атаку AS-REP Roasting, необходимо разобраться в базовых принципах работы протокола Kerberos, который является основным механизмом аутентификации в средах Active Directory.

2.1 Что такое Kerberos

2

Kerberos - это сетевой протокол аутентификации, основанный на симметричном шифровании и концепции "билетов". Его задача - безопасно удостоверять пользователей и сервисы в незащищённой сети, минимизируя передачу паролей. Он разработан таким образом, чтобы:

  • Не передавать пароли в открытом виде;

  • Обеспечить взаимную аутентификацию между клиентом и сервером;

  • Использовать централизованную службу проверки - KDC (Key Distribution Center).

2.2 Основные компоненты Kerberos

  • KDC (Key Distribution Center) - контроллер домена, который отвечает за выдачу билетов и состоит из двух логических компонентов:

    • AS (Authentication Server) - начальный этап проверки подлинности;

    • TGS (Ticket Granting Server) - выдает доступ к сервисам на основании ранее полученного билета.

  • TGT (Ticket Granting Ticket) - билет, удостоверяющий личность пользователя. Используется для получения доступа к конкретным сервисам без повторной аутентификации.

  • Client - пользователь или система, которая хочет получить доступ к ресурсу.

  • Service - целевой сервис, к которому клиент хочет подключиться (например, файл-сервер).

2.3 Этапы аутентификации в Kerberos

Аутентификация в Kerberos проходит в несколько этапов. Основное внимание стоит уделить первому этапу, связанному с AS-REQ и AS-REP - именно его эксплуатирует атака AS-REP Roasting.

3

Этап 1: Аутентификация (AS-REQ / AS-REP)

  1. Клиент отправляет AS-REQ (Authentication Service Request) на KDC с просьбой о получении TGT.

  2. Если у пользователя включена предварительная аутентификация (pre-authentication), то клиент сначала шифрует текущую метку времени своим хешем пароля и прикладывает к запросу.

  3. KDC проверяет это "доказательство знания пароля" и, если оно успешно, высылает AS-REP - зашифрованный TGT и сессионный ключ.

Этап 2: Запрос TGS (TGS-REQ / TGS-REP)

  1. Получив TGT, клиент может обращаться к TGS с TGS-REQ, чтобы получить доступ к нужному сервису.

  2. KDC проверяет билет и выдает сервисный билет в TGS-REP.

2.4 Pre-authentication: почему это важно

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

Однако в некоторых случаях pre-auth отключается:

  • Учетная запись используется для автоматизации и скриптов;

  • Администратор вручную снимает флаг "требовать pre-authentication";

  • Устаревшие системы или совместимость с legacy-приложениями.

3. Что такое AS-REP Roasting

AS-REP Roasting - это атака, использующая слабость в протоколе Kerberos, а точнее - в его реализации в средах, где у некоторых пользователей отключена опция pre-authentication. Такая уязвимость позволяет злоумышленнику получить зашифрованный хэш пароля без необходимости прохождения полноценной аутентификации.

3.1 Уязвимость

4

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

У таких учетных записей злоумышленник может запросить билет на этапе AS-REQ, и контроллер домена без дополнительных проверок вернет ответ AS-REP, который уже содержит данные, зашифрованные с использованием ключа на основе пароля пользователя (обычно RC4 или AES-хэш пароля).

3.2 Как злоумышленник использует эту особенность

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

  1. Определить учетные записи с отключённой предварительной аутентификацией.

    • Это можно сделать с помощью PowerShell, утилит вроде PowerView или специальных сканеров Active Directory.

  2. Отправить AS-REQ от имени уязвимого пользователя.

    • Поскольку pre-auth отключена, KDC не требует подтверждения личности.

  3. Получить AS-REP, содержащий:

    • Сессионный ключ, зашифрованный хешем пароля пользователя.

  4. Произвести офлайн-взлом:

    • С помощью утилит вроде Hashcat или John the Ripper можно перебрать пароли, сравнивая их хэши с полученными данными.

Преимущество этого метода - полное отсутствие необходимости взаимодействовать с целевой машиной после получения AS-REP: весь перебор выполняется на машине атакующего, что делает атаку очень скрытной.

3.3 Пример зашифрованного AS-REP-хэша

Хеш AS-REP выглядит примерно так:

$krb5asrep$23$user@domain.com:3e156ada591263b8aab0965f5aebd837$007497cb51b6c8116d6407a782ea0e1c5402b17db7afa6b05a6d30ed164a9933c754d720e279c6c573679bd27128fe77e5fea1f72334c1193c8ff0b370fadc6368bf2d49bbfdba4c5dccab95e8c8ebfdc75f438a0797dbfb2f8a1a5f4c423f9bfc1fea483342a11bd56a216f4d5158ccc4b224b52894fadfba3957dfe4b6b8f5f9f9fe422811a314768673e0c924340b8ccb84775ce9defaa3baa0910b676ad0036d13032b0dd94e3b13903cc738a7b6d00b0b3c210d1f972a6c7cae9bd3c959acf7565be528fc179118f28c679f6deeee1456f0781eb8154e18e49cb27b64bf74cd7112a0ebae2102ac

3.4 Почему это опасно

  • Беззвучность: атака не вызывает срабатываний, если не настроено логирование.

  • Низкий порог входа: можно использовать готовые инструменты и словари.

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

В случае успеха злоумышленник получает пароль в открытом виде, что открывает доступ к различным ресурсам домена, вплоть до дальнейшего повышения привилегий.

4. Пошаговое описание атаки

Рассмотрим, как проводится атака AS-REP Roasting на практике. Покажем, как выявить уязвимые учетные записи и получить AS-REP-хэши, которые можно затем использовать для офлайн-взлома. Примеры будут приведены как для Windows, так и для Linux.

4.1 Этап 1: Поиск уязвимых пользователей

Вариант 1: Windows (PowerShell + PowerView)

Сначала загружаем PowerView (часть PowerSploit), затем выполняем:

Import-Module .\PowerView.ps1

# Найти пользователей без pre-auth
Get-DomainUser -PreauthNotRequired

Это выдаст список пользователей, у которых отключена опция "Do not require Kerberos preauthentication", и которые уязвимы к AS-REP Roasting.

5

Вариант 2: Linux (Kerbrute)

Kerbrute - лёгкий и быстрый инструмент для сбора информации о Kerberos.

Команда для поиска уязвимых учеток:

./kerbrute_linux_amd64 userenum -domain example.local --dc 10.10.10.10 users.txt

users.txt - список возможных имён пользователей. Kerbrute проверит, у кого отключена pre-auth, и выведет AS-REP-хэши.

6

4.2 Этап 2: Запрос AS-REP и получение хэша

Вариант 1: Windows (Rubeus)

Rubeus - один из самых популярных инструментов для работы с Kerberos.

Сначала получаем список уязвимых учеток:

Rubeus.exe asreproast

Rubeus сам выполнит AS-REQ и выведет хэши в формате, пригодном для Hashcat.

7

Вариант 2: Linux (Impacket)

Impacket - набор Python-утилит для взаимодействия с сетевыми протоколами.

Утилита GetNPUsers.py:

python3 GetNPUsers.py example.local/ -dc-ip 10.10.10.10 -usersfile users.txt -format hashcat -outputfile asrep-hashes.txt

8

Пример с конкретным пользователем:

python3 GetNPUsers.py example.local/username -no-pass

Если пользователь уязвим, в консоли появится $krb5asrep$23$... - это и есть хэш.

4.3 Этап 3: Офлайн-взлом пароля

Теперь, имея AS-REP хэши, можно начать подбор пароля офлайн:

Hashcat (Linux/Windows)

hashcat -m 18200 asrep-hashes.txt rockyou.txt

  • -m 18200 - режим для AS-REP RC4-HMAC

  • rockyou.txt - словарь паролей

9

John the Ripper

Поддерживает AS-REP Roasting из коробки:

john --wordlist=/usr/share/wordlists/rockyou.txt asrep-hashes.txt

10

4.4 Сценарий атаки (вкратце)

  1. Злоумышленник получает доступ в домен как обычный пользователь (или просто подключён к сети).

  2. Сканирует Active Directory на предмет учеток без pre-auth.

  3. Получает AS-REP-хеши от имени уязвимых пользователей.

  4. Выполняет перебор хешей на своей машине.

  5. В случае успеха получает пароль и может аутентифицироваться как данный пользователь.

5. Методы защиты от AS-REP Roasting

Атака AS-REP Roasting возможна только при наличии в домене пользователей с отключенной pre-authentication. Поэтому основные меры защиты сводятся к обнаружению, ограничению и контролю таких учетных записей. Вот подробный разбор, как можно эффективно защититься.

5.1 Включение pre-authentication для всех пользователей

Самый надёжный способ предотвратить AS-REP Roasting - обеспечить, чтобы у всех учетных записей была включена pre-authentication.

Как проверить?

Через PowerShell:

Get-ADUser -Filter * -Properties DoesNotRequirePreAuth | Where-Object { $_.DoesNotRequirePreAuth -eq $true }

В Active Directory Users and Computers:

  • Открой свойства пользователя.

  • Перейди во вкладку "Account".

  • Убедись, что опция "Do not require Kerberos preauthentication" НЕ установлена.

11

Что делать?

  • Если галочка стоит без необходимости — снять её.

  • Использовать отдельные сервисные аккаунты только при крайней необходимости, и с жестким контролем (см. ниже).

5.2 Минимизация использования сервисных учёток без pre-auth

Иногда pre-auth отключается осознанно - для сервисных или устаревших приложений. В этом случае:

  • Изолируйте такие учётки, ограничив:

    • Время входа в систему;

    • Доступ к сетевым ресурсам;

    • Область действия (через AllowedToAuthenticateTo, LogonWorkstations, и т.д.).

  • При возможности замените устаревшие решения на поддерживающие pre-authentication.

5.3 Повышение сложности и уникальности паролей

AS-REP атака эффективна только при слабых паролях. Поэтому:

  • Внедрите политику сложности паролей:

    • Длина: не менее 12–16 символов;

    • Использование букв, цифр, спецсимволов;

    • Запрет распространённых паролей (можно через сторонние фильтры).

  • Обновляйте пароли регулярно.

  • Рассмотрите внедрение хранилища паролей и Kerberos Managed Service Accounts (gMSA) для автоматического управления сервисными учётками.

5.4 Мониторинг и логирование

Встроенные средства Windows позволяют отслеживать попытки получения AS-REP.

Включение логирования событий Kerberos

  • Журнал: Security

  • Ивент-ID: 4768 (Authentication Ticket Request)

12

Для AS-REP Roasting характерны события, где:

  • Тип учетной записи - User;

  • Имя аккаунта - сервисная/автоматическая учетка;

  • Pre-authentication not required - Yes.

Пример фильтра в SIEM

(EventID=4768) AND (PreAuthType=0)

Также можно настроить алерты в SIEM, когда:

  • В течение короткого времени запрошено много AS-REP билетов;

  • Необычный пользователь пытается аутентифицироваться от имени разных аккаунтов.

5.5 Использование инструментов аудита безопасности

Используйте утилиты и сканеры для регулярного аудита AD:

  • PingCastle, BloodHound - анализ рисков и выявление слабых конфигураций;

  • ADRecon, Purple Knight - аудит параметров безопасности;

  • Script-based (например, PowerShell-скрипты от Microsoft или GitHub-сообщества).

Регулярный аудит позволит оперативно выявить слабые места, до того как их найдёт злоумышленник.

Заключение

Атака AS-REP Roasting демонстрирует, насколько критически важно правильно настраивать параметры безопасности в инфраструктуре Active Directory. Изучив работу протокола Kerberos, мы поняли, что отключение предварительной аутентификации у учетных записей может превратить их в уязвимый узел, который злоумышленники будут использовать для получения зашифрованных хэшей паролей. Эти данные позволяют провести офлайн-взлом, что делает атаку тихой и эффективной.

В статье мы рассмотрели основные этапы атаки:

  • Выявление уязвимых учетных записей,

  • Получение AS-REP-хэша через специализированные инструменты,

  • Оффлайн-перебор паролей с использованием Hashcat или John the Ripper.

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

  • минимизировать использование сервисных учетных записей с отключенной предварительной аутентификацией,

  • внедрять строгие политики сложности паролей,

  • регулярно проводить аудит Active Directory,

  • настраивать мониторинг и логирование запросов аутентификации.

В результате системного подхода к защите можно существенно снизить риски, связанные с AS-REP Roasting, и повысить общую устойчивость сети к атакам.