Расследование Golden Ticket по логам Event ID 4768 и 4769: собираем таймлайн для отчёта об инциденте

Три Event ID 4769 за восемь секунд с одной рабочей станции — запросы сервисных билетов к четырём разным SPN. Ни одного Event ID 4768 за предшествующие два часа для той же учётной записи. Шифрование в тикетах — RC4, хотя вся доменная политика давно переведена на AES256. На разборе этого лабораторного кейса я впервые руками собрал полный таймлайн атаки Golden Ticket — от момента предполагаемого извлечения krbtgt-хэша до последнего бокового перемещения. Ниже — пошаговый разбор: какие события собирать, на какие поля смотреть, как отсечь ложные срабатывания и оформить результат в отчёт об инциденте.

Бизнес-логика атаки: зачем злоумышленнику Golden Ticket

Прежде чем нырять в логи, разберёмся с мотивацией атакующего — без этого вы будете смотреть на события и не понимать, что они означают. Golden Ticket — не начало компрометации, а её кульминация. Злоумышленник уже получил максимальные привилегии в домене, обычно через DCSync (техника T1003.006 в MITRE ATT&CK — открытой базе тактик и техник атак; T-коды вроде T1003.006 — идентификаторы конкретных техник, по ним удобно искать описания и детекты). DCSync — имитация контроллера домена: атакующий запрашивает у настоящего DC репликацию учётных данных через протокол MS-DRSR и получает NTLM-хэши всех учётных записей.

Главный трофей — хэш учётной записи krbtgt. Это системная учётная запись Active Directory, ключом которой KDC (Key Distribution Center — центр распределения ключей, работает на контроллере домена) подписывает все TGT (Ticket Granting Ticket — билет, подтверждающий личность пользователя в домене). Украв этот ключ, атакующий подделывает TGT от имени любого пользователя, включая Domain Admin, и пользуется им месяцами.

Зачем? Закрепление. Даже если IR-команда (Incident Response — группа реагирования на инциденты) сменит пароли всех учётных записей, Golden Ticket продолжит работать. Пароль krbtgt по умолчанию не ротируется, и в большинстве организаций он не менялся с момента создания домена. Финальный импакт — полный контроль над доменом на неопределённый срок: файловые серверы, почта, базы данных, бэкапы.

По данным IBM X-Force Threat Intelligence Index 2025, атаки с использованием действительных учётных данных выросли на 71% год к году. Golden Ticket — одна из самых эффективных техник превращения украденных кредов в устойчивый доступ к AD-инфраструктуре. MITRE ATT&CK классифицирует её как T1558.001 (Golden Ticket) в тактике Credential Access. CISA документирует Kerberos-атаки в кампаниях государственных APT-групп и ransomware-операциях — ряд группировок используют Kerberos-инфраструктуру для извлечения учётных данных.

Что происходит на уровне протокола Kerberos при обнаружении Golden Ticket в логах Windows

Kerberos — протокол аутентификации в Active Directory. Вместо передачи пароля каждому сервису пользователь получает временные билеты от KDC на контроллере домена. Нормальная аутентификация генерирует цепочку событий:

1. Пользователь вводит логин и пароль — KDC проверяет и выдаёт TGT. На контроллере домена записывается Event ID 4768.
2. Пользователь предъявляет TGT — KDC выдаёт сервисный билет TGS (Ticket Granting Service) для конкретного ресурса. Записывается Event ID 4769.
3. Пользователь предъявляет TGS целевому серверу — получает доступ. На целевом хосте записывается Event ID 4624 (логон), при привилегированном доступе — ещё и Event ID 4672 (назначение специальных привилегий).

Golden Ticket ломает эту цепочку: атакующий создаёт TGT офлайн, минуя шаг 1. Контроллер домена не выдавал этот билет — Event ID 4768 не записывается. Но когда атакующий использует поддельный TGT для запроса сервисных билетов — Event ID 4769 фиксируется. На этом разрыве строится ключевой паттерн детектирования: TGS-запросы без предшествующего TGT.

Запомните эту логику — она будет основой всего расследования.

Предусловия: политики аудита для расследования Kerberos атак

Без включённого аудита Event ID 4768 и 4769 не попадают в журнал Security контроллера домена — расследование невозможно. Это первое, что SOC-аналитик (аналитик центра мониторинга безопасности) проверяет при подключении к инциденту.

Минимальный набор Advanced Audit Policy (настраивается через GPO или auditpol.exe):

Если аудит не включён — вы слепы. По данным OWASP (A09:2021 — Security Logging and Monitoring Failures), отсутствие логирования остаётся одной из причин, по которым компрометацию обнаруживают спустя недели и месяцы.

Зафиксируйте baseline — параметры Kerberos-политики домена, которые станут «физикой» вашего расследования:

• Maximum lifetime for user ticket — по умолчанию 10 часов
• Maximum lifetime for service ticket — по умолчанию 10 часов
• Используемые типы шифрования — AES256 (0x12), AES128 (0x11) или RC4 (0x17)

Без baseline вы не отличите аномалию от нормы. Многие детекты Golden Ticket опираются именно на отклонение: «этот тикет прожил дольше, чем позволяет политика» или «этот тип шифрования нетипичен для среды».

Event ID 4768 расследование: разбор ключевых полей TGT-запроса

Event ID 4768 фиксируется на контроллере домена при каждом выданном TGT. При расследовании Golden Ticket обращайте внимание на эти поля:

При нормальной аутентификации 4768 предшествует 4769: сначала пользователь получает TGT, затем запрашивает сервисные билеты. Если вы видите серию 4769 для учётной записи, а 4768 за предшествующий период отсутствует — это первый признак поддельного TGT.

Event ID 4769 анализ логов: аномалии и маркеры Golden Ticket

Event ID 4769 — основной источник артефактов при расследовании Golden Ticket. Каждый запрос TGS оставляет запись, по которой можно восстановить действия атакующего:

Паттерны аномалий в событиях 4769

Серия запросов к разным SPN за короткий период. Обычный пользователь обращается к 2-3 сервисам в минуту. Десять и более TGS-запросов к разным SPN за 30 секунд — признак разведки или lateral movement (бокового перемещения по сети). По данным Sycope, такие «TGS-пачки» (TGS bursts) — один из самых надёжных сетевых индикаторов Kerberos-атак.

Encryption downgrade при обнаружении Golden Ticket. Если домен настроен на AES256 (0x12), а в Ticket Encryption Type стоит RC4 (0x17) — скорее всего, перед вами Mimikatz. По умолчанию он генерирует Golden Ticket с RC4. Microsoft Defender for Identity и SentinelOne документируют этот сигнал как высокоприоритетный.

Когда техника НЕ работает: если атакующий явно указал AES256 при генерации Golden Ticket (параметр /enctype:aes256 в Mimikatz), encryption downgrade не произойдёт. Опытные операторы подбирают шифрование под baseline домена — и тогда этот детект бесполезен.

Несуществующие учётные записи. Golden Ticket позволяет сгенерировать TGT от имени пользователя, которого нет в AD. Account Name в 4769, не соответствующий ни одному объекту Active Directory — практически стопроцентный маркер подделки.

Когда техника НЕ работает: после установки патчей для CVE-2021-42287/CVE-2021-42278 (KB5008380 и связанные обновления; обе уязвимости — CVSS 7.5 HIGH, в каталоге CISA KEV с 2022-04-11, эксплуатируются в ransomware-кампаниях) контроллеры домена усиливают валидацию PAC (Privilege Attribute Certificate — структура данных в тикете, содержащая информацию о привилегиях пользователя). Уточнение: эти CVE относятся к атаке noPac (эскалация привилегий через sAMAccountName spoofing) — отдельный вектор, не связанный напрямую с Golden Ticket. Но побочный эффект патчей — ужесточение проверки PAC — может приводить к отклонению некоторых поддельных тикетов с несуществующими именами. Полнота блокировки зависит от версии DC и уровня enforcement. На непропатченных DC ограничений нет.

Собираем таймлайн атаки по журналам событий: делай раз, делай два

Переходим к практике. Каждый шаг — конкретное действие с ожидаемым результатом.

Требования к окружению: — Доступ к Security-логу контроллера домена (права Event Log Reader или локальный администратор DC) — PowerShell 5.1+ или SIEM (Splunk, ELK, MaxPatrol SIEM) — Включённые политики аудита (описаны выше)

Шаг 1: выгрузка и корреляция 4768/4769 — поиск «осиротевших» TGS

Цель: найти запросы сервисных билетов (4769), для которых нет предшествующего запроса TGT (4768) от того же пользователя и хоста.

Запускаем на контроллере домена (нужны права администратора):

$start = (Get-Date).AddHours(-24)
# Используем XML-парсинг — числовые индексы Properties[] зависят от версии ОС
$ev4768 = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768; StartTime=$start} | ForEach-Object {
  $xml = [xml]$_.ToXml()
  $ip = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'IpAddress'} | Select -Expand '#text') -replace '^::ffff:',''
  [PSCustomObject]@{TimeCreated=$_.TimeCreated; User=$xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'} | Select -Expand '#text'; ClientIP=$ip}
}
$ev4769 = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=$start} | ForEach-Object {
  $xml = [xml]$_.ToXml()
  $ip = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'IpAddress'} | Select -Expand '#text') -replace '^::ffff:',''
  [PSCustomObject]@{TimeCreated=$_.TimeCreated; User=$xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'} | Select -Expand '#text'; SPN=$xml.Event.EventData.Data | Where-Object {$_.Name -eq 'ServiceName'} | Select -Expand '#text'; ClientIP=$ip}
}
$orphanTGS = $ev4769 | Where-Object {
  $u = $_.User; $c = $_.ClientIP
  -not ($ev4768 | Where-Object { $_.User -eq $u -and $_.ClientIP -eq $c })
}
$orphanTGS | Sort TimeCreated | Format-Table -AutoSize

Что произойдёт: скрипт выгрузит все события 4768 и 4769 за последние 24 часа и выведет «осиротевшие» TGS — те, для которых не нашлось соответствующего TGT от того же пользователя и IP.

Как читать результат: пустая таблица — все TGS-запросы имеют предшествующие TGT, это нормальная ситуация. Строки в таблице — каждая строка потенциально указывает на Golden Ticket. Фокусируйтесь на полях User и ClientIP.

Ограничение: корреляция «4769 без 4768» несовершенна. Ложные срабатывания возможны из-за ротации логов (4768 уже перезаписан), проблем с синхронизацией времени между DC или gap’ов в пересылке логов. Для повышения точности ищите не единичные «осиротевшие» TGS, а серии — несколько 4769 к разным SPN с одного хоста за короткий период.

Шаг 2: проверка Ticket Encryption Type — encryption downgrade

Цель: выявить использование RC4 вместо AES256 в тикетах.

В SIEM (пример для Splunk):

index=wineventlog EventCode=4769 Ticket_Encryption_Type=0x17
| stats count by Account_Name, Client_Address, Service_Name
| where count > 1
| sort -count

Что произойдёт: запрос покажет все TGS-запросы с шифрованием RC4 (0x17), сгруппированные по учётной записи, IP источника и запрошенному SPN.

Как читать результат: если домен использует AES256 — любая строка в выводе заслуживает расследования. Ложные срабатывания дают legacy-системы: старые принтеры, промышленные контроллеры, приложения без поддержки AES. Их нужно внести в whitelist и исключить из правила. Я обычно начинаю с того, что прошу админов дать список таких систем — и каждый раз удивляюсь, сколько «временных» исключений живут годами.

[Применимо: внутренний пентест / IR, любая инфраструктура AD от Windows Server 2008 R2 и выше]

Шаг 3: сопоставление с учётными записями AD

Цель: обнаружить TGS-запросы от имени несуществующих или отключённых учётных записей.

Получите полный список учётных записей командой Get-ADUser -Filter * | Select SamAccountName (нужен модуль ActiveDirectory). Сравните с Account Name из «осиротевших» TGS, найденных на шаге 1. Учётная запись, отсутствующая в AD или помеченная как Disabled — сигнал максимальной серьёзности. Microsoft Defender for Identity выделяет это в отдельный алерт: «Suspected Golden Ticket usage (nonexistent account)».

Шаг 4: анализ длительности сессий

Цель: обнаружить тикеты с аномальным сроком жизни.

Mimikatz позволяет задать произвольный срок действия Golden Ticket (параметры /endin и /renewmax), значительно превышающий стандартные 10 часов — на практике встречаются тикеты со сроком действия в годы. Прямое значение lifetime не записывается в Event ID 4768/4769, но его можно вычислить косвенно: если один и тот же TGT используется для запроса TGS на протяжении дней (серия 4769 с одним Account Name и Client Address, растянутая во времени) — это аномалия. Нормальный TGT обновляется каждые 10 часов. Увидели один и тот же аккаунт с одного IP, который запрашивает TGS третьи сутки подряд без единого 4768? Вот ваш Golden Ticket.

Шаг 5: собираем хронологию

На этом шаге у вас четыре набора данных: «осиротевшие» TGS, маркеры encryption downgrade, флаги несуществующих учёток, аномалии длительности. Расположите события в хронологическом порядке. Типичный таймлайн атаки Golden Ticket:

Для визуализации используйте Timeline Explorer (бесплатный инструмент Эрика Циммермана): экспортируйте данные в CSV, загрузите — он покажет события на шкале с цветовой маркировкой по Event ID. SIEM-системы (Splunk, ELK, MaxPatrol SIEM) предоставляют встроенные дашборды для визуализации таймлайнов.

SIEM-корреляция и Sigma-правила для детектирования TGT подделки

В репозитории SigmaHQ (стандартизированные правила детектирования, не привязанные к конкретному SIEM — что-то вроде «Snort-правил, но для логов») есть правило win_security_dc_machine_accoutn_tgt_non_dc_ip.yml для T1558.001 — оно срабатывает при запросе TGT для учётной записи контроллера домена с IP, не принадлежащего DC. Правило находится в директории rules-placeholder (категория SigmaHQ для правил на стадии валидации сообществом, ещё не в production-ready). Перед использованием проверьте его текущий статус в репозитории. Это покрывает один из сценариев Golden Ticket — когда атакующий генерирует TGT от имени machine account.

Для полного покрытия добавьте собственные корреляционные правила:

1. 4769 без 4768 — корреляция из шага 1. Окно: 2-4 часа (учитывайте retention и clock skew между контроллерами).
2. Encryption downgrade — EventCode=4769 И Ticket_Encryption_Type=0x17 И Source_Host НЕ В whitelist’е legacy-систем.
3. TGS burst — более 10 запросов 4769 с одного Client Address за 60 секунд к разным SPN.

Единичное срабатывание одного правила — повод посмотреть. Два и более одновременно — полноценный инцидент, требующий эскалации.

Для валидации правил в лабораторной среде используйте тесты из Atomic Red Team: «Crafting Active Directory golden tickets with mimikatz» и «Crafting Active Directory golden tickets with Rubeus» (T1558.001). Они воспроизводят создание Golden Ticket и позволяют убедиться, что ваш SIEM ловит нужные события. Рекомендую прогнать их до того, как выкатите правила в прод — иначе первый же реальный инцидент покажет, что правила молчат.

Оформление таймлайна для отчёта при реагировании на инциденты Active Directory

Таймлайн собран — теперь его нужно оформить так, чтобы его понял руководитель отдела ИБ, CISO и юрист. Структура раздела отчёта:

Executive Summary (1-2 абзаца). Что произошло, когда, масштаб. Пример: «Обнаружена атака Golden Ticket (MITRE ATT&CK T1558.001). Злоумышленник использовал поддельный TGT для доступа к N серверам в период с [дата] по [дата]. Подделка стала возможна благодаря компрометации хэша krbtgt через DCSync (T1003.006).»

Хронологическая таблица. Таймлайн с Event ID, временными метками (UTC), IP-адресами, учётными записями и описанием каждого действия — формат из шага 5.

Indicators of Compromise. IP-адреса источника, Account Name из аномальных событий, перечень SPN, к которым обращался атакующий, тип шифрования аномальных тикетов.

Рекомендации по устранению. Для Golden Ticket единственный способ аннулировать поддельный TGT — дважды сменить пароль учётной записи krbtgt. Это соответствует защитной мере D3-RIC (Reissue Credential) по классификации MITRE D3FEND. Почему дважды: AD хранит текущий и предыдущий пароль krbtgt для обратной совместимости при репликации. Одна смена оставляет старый хэш рабочим — тикеты, подписанные им, продолжают приниматься.

Корневая причина. Как атакующий получил хэш krbtgt: DCSync, дамп NTDS.dit или прямая компрометация DC. Это определяет дальнейшие меры: ограничение прав на репликацию (DS-Replication-Get-Changes и DS-Replication-Get-Changes-All), усиление защиты контроллеров домена, внедрение PAM/PIM (Privileged Access Management / Privileged Identity Management — системы управления привилегированным доступом).

Golden Ticket часто считают экзотикой: мол, если дошло до krbtgt, домен уже потерян, зачем расследовать. На практике всё наоборот. Расследование — это не про «найти и обезвредить», а про восстановление полной картины: что атакующий успел сделать, пока владел мастер-ключом домена. Без таймлайна вы не знаете, какие данные утекли, какие бэкдоры остались и достаточно ли двойной ротации krbtgt. Самая частая ошибка IR-команд, которую я наблюдал на разборах — ротировать krbtgt и считать инцидент закрытым, не проверив, сколько сервисных аккаунтов скомпрометировано параллельно. Silver Ticket (T1558.002) использует те же 4769-логи, но другой вектор — хэш сервисной учётки вместо krbtgt. При этом Silver Ticket не генерирует никаких событий на DC, только на целевом сервисе. Golden Ticket-расследование без проверки Silver Ticket — неполное. Если вы только начинаете разбираться в форензике Active Directory и хотите пройти базу системно — на IB Basics показывают, как делать первые задачи в SOC и работать с логами на реальных кейсах.