Diamond Ticket или ещё одна атака на Kerberos
Требования
Перед тем, как начинать читать данный топик, автор рекомендует разобраться в следующих темах:
- Kerberos - что это такое, как работает, чем отличается TGT от TGS
- Silver Ticket - в чем заключается данная атака и как её реализовать, её преимущества и недостатки
- Golden Ticket - в чем заключается данная атака и как её реализовать, её преимущества и недостатки
Если вам неизвестно что-либо из вышеперечисленного, то, боюсь, что вы не сможете понять описанное ниже.
Предисловие
Не так давно, зайдя на страницу Rubeus'а на github, я обнаружил следующую команду:
diamond. Даже звучит красиво. Пора разобраться с тем, что это такое и как применять.
Для чего нужен данный тикет?
Смотрите, задайте себе вопрос, что вы указываете при создании голден тикета? Прямо вот самое основное. Да, это хеш УЗ krbtgt, который можно получить DCSync'ом, сдампив LSASS, либо, украв ntds.dit. Данная учетная запись, а точнее её пароль, используется для вычисления специального ключа, применяемого для шифрования и расшифровки билетов TGT. Возможно вы помните, что TGT шифруется паролем krbtgt, а TGS - паролем службы, что и порождает атаки Golden и Silver Ticket соответственно. В чем же заключается Diamond Ticket?
В TGT билете есть особая секция - PAC (Privileged Attribute Certificate). Она содержит информацию о привилегиях пользователя. Эта информация добавляется в билеты Kerberos контроллером домена, когда пользователь проходит аутентификацию в домене.
Если у нас есть NTLM хеш, либо AES128/AES256 ключ krbtgt, мы будем в состоянии расшифровать TGT билет, записать свою информацию в PAC и вновь зашифровать билет. В результате чего получим билет на низкопривилегированного пользователя, но с доступом, допустим, ДА. Фактически, это самый настоящий волк в овечьей шкуре. Мы можем запросить TGT билет уборщицы, занести туда информацию о ДА и ходить от имени уборщицы куда угодно, на любой сервис или на любой хост.
Эксплуатация
В примерах ниже мы будем использовать Rubeus, а также я полагаю, что вы имеете AES256 ключ от УЗ krbtgt. Резонный вопрос - почему AES? Смотрите, по умолчанию внутри домена для билетов используется шифрование AES. Между доменами и лесами - RC4. В связи с этим, если мы будем использовать RC4, то скорее всего можем получить алерт от какой-либо блю тимовской системы. Вы также могли получить этот алерт, если применяли атаку Kerberoasting без флага /rc4opsec . Мы ведь не хотим лишнего шума? Поэтому, делаем с AES.
Теперь все достаточно просто. Запрос данного билета осуществляется следующим образом:
- /krbkey - AES256 ключ Krbtgt
- /user: низкопривилегированный пользователь, на имя которого выписывается билет
- /password: пароль низкопривилегированного пользователя (можно также указать /rc4: , /aes128: , /aes256: для атаки Overpass the hash / Pass the key)
- /enctype: тип шифрования билета
- /domain: домен, в котором создается билет
- /dc: имя KDC
- /ticketuser: высокопривилегированный пользователь, доступ от лица которого мы хотим получить
- /ticketuserid: RID пользователя (админский - 500)
- /groups: - группы для добавления
- /ptt: атака pass the ticket
Пример
Думаю, что лучше будет рассмотреть на примере для большей наглядности.
Вот мы не можем получить доступ к ДК от юзера loki:
Запрашиваем бриллиантовый билет:
Далее запрашиваем TGS на CIFS с помощью полученного билета:
Пробуем получить доступ:
Все успешно!
Скрытность
Данная атака считается чуть более скрытной, чем обычный голден тикет потому, что могут вешать детект также на запрос TGS-REQ без предварительного AS-REQ. Diamond Ticket обойдёт этот тип обнаружения, запросив действительный TGT перед использованием полученного билета. Кроме того, поскольку билет сначала создается контроллером домена, некоторые значения (например, время жизни билета) будут правильными по умолчанию
Требования
Перед тем, как начинать читать данный топик, автор рекомендует разобраться в следующих темах:
- Kerberos - что это такое, как работает, чем отличается TGT от TGS
- Silver Ticket - в чем заключается данная атака и как её реализовать, её преимущества и недостатки
- Golden Ticket - в чем заключается данная атака и как её реализовать, её преимущества и недостатки
Если вам неизвестно что-либо из вышеперечисленного, то, боюсь, что вы не сможете понять описанное ниже.
Предисловие
Не так давно, зайдя на страницу Rubeus'а на github, я обнаружил следующую команду:
diamond. Даже звучит красиво. Пора разобраться с тем, что это такое и как применять.
Для чего нужен данный тикет?
Смотрите, задайте себе вопрос, что вы указываете при создании голден тикета? Прямо вот самое основное. Да, это хеш УЗ krbtgt, который можно получить DCSync'ом, сдампив LSASS, либо, украв ntds.dit. Данная учетная запись, а точнее её пароль, используется для вычисления специального ключа, применяемого для шифрования и расшифровки билетов TGT. Возможно вы помните, что TGT шифруется паролем krbtgt, а TGS - паролем службы, что и порождает атаки Golden и Silver Ticket соответственно. В чем же заключается Diamond Ticket?
В TGT билете есть особая секция - PAC (Privileged Attribute Certificate). Она содержит информацию о привилегиях пользователя. Эта информация добавляется в билеты Kerberos контроллером домена, когда пользователь проходит аутентификацию в домене.
Если у нас есть NTLM хеш, либо AES128/AES256 ключ krbtgt, мы будем в состоянии расшифровать TGT билет, записать свою информацию в PAC и вновь зашифровать билет. В результате чего получим билет на низкопривилегированного пользователя, но с доступом, допустим, ДА. Фактически, это самый настоящий волк в овечьей шкуре. Мы можем запросить TGT билет уборщицы, занести туда информацию о ДА и ходить от имени уборщицы куда угодно, на любой сервис или на любой хост.
Эксплуатация
В примерах ниже мы будем использовать Rubeus, а также я полагаю, что вы имеете AES256 ключ от УЗ krbtgt. Резонный вопрос - почему AES? Смотрите, по умолчанию внутри домена для билетов используется шифрование AES. Между доменами и лесами - RC4. В связи с этим, если мы будем использовать RC4, то скорее всего можем получить алерт от какой-либо блю тимовской системы. Вы также могли получить этот алерт, если применяли атаку Kerberoasting без флага /rc4opsec . Мы ведь не хотим лишнего шума? Поэтому, делаем с AES.
Теперь все достаточно просто. Запрос данного билета осуществляется следующим образом:
Код:
Rubeus.exe diamond /krbkey:3111b43b220d2f4eb8e68fe7be1179ce69328c9071cba14bef4dbb02b1cfeb9c /user:loki /password:Mischief$ /enctype:aes /domain:marvel.local /dc:earth-dc.marvel.local /ticketuser:thor /ticketuserid:1104 /groups:512 /ptt- /user: низкопривилегированный пользователь, на имя которого выписывается билет
- /password: пароль низкопривилегированного пользователя (можно также указать /rc4: , /aes128: , /aes256: для атаки Overpass the hash / Pass the key)
- /enctype: тип шифрования билета
- /domain: домен, в котором создается билет
- /dc: имя KDC
- /ticketuser: высокопривилегированный пользователь, доступ от лица которого мы хотим получить
- /ticketuserid: RID пользователя (админский - 500)
- /groups: - группы для добавления
- /ptt: атака pass the ticket
Пример
Думаю, что лучше будет рассмотреть на примере для большей наглядности.
Вот мы не можем получить доступ к ДК от юзера loki:
Запрашиваем бриллиантовый билет:
Далее запрашиваем TGS на CIFS с помощью полученного билета:
Пробуем получить доступ:
Все успешно!
Скрытность
Данная атака считается чуть более скрытной, чем обычный голден тикет потому, что могут вешать детект также на запрос TGS-REQ без предварительного AS-REQ. Diamond Ticket обойдёт этот тип обнаружения, запросив действительный TGT перед использованием полученного билета. Кроме того, поскольку билет сначала создается контроллером домена, некоторые значения (например, время жизни билета) будут правильными по умолчанию