Алмазный билет. Как использовать доверие Kerberos в своих целях

Для начала раз­берем­ся с осно­вами: в ата­ке на Domain PAC (Privilege Attribute Certificate) зло­умыш­ленник под­делыва­ет или изме­няет PAC внут­ри билета Kerberos. В резуль­тате зло­дей получа­ет несан­кци­они­рован­ный дос­туп или повыша­ет свои при­виле­гии в домен­ной сре­де. Это работа­ет из‑за того, что мно­гие сер­висы по умол­чанию доверя­ют PAC, час­то не про­веряя его под­линность и не сопос­тавляя с дан­ными Key Distribution Center (KDC).

Ата­ка Diamond Ticket — более прод­винутый вари­ант. Здесь зло­умыш­ленник внаг­лую лезет в сами билеты Kerberos — в пер­вую оче­редь Ticket Granting Tickets (TGTs) и PAC. Под­делан­ные билеты исполь­зуют, что­бы повысить при­виле­гии в домене Active Directory (AD).

Механизм атаки

Для начала ата­ки зло­умыш­ленник под­делыва­ет PAC, что­бы добавить туда повышен­ные при­виле­гии или фаль­шивые груп­пы (нап­ример, «Адми­нис­тра­торы домена»).

Пос­ле это­го под­дель­ный билет с изме­нен­ным PAC отправ­ляет­ся на целевой сер­вис.

В клас­сичес­кой «брил­лиан­товой» ата­ке зло­умыш­ленник спер­ва исполь­зует хеш KRBTGT AES, что­бы рас­шифро­вать рабочий билет TGT (Ticket Granting Ticket). Далее он меня­ет PAC (Privilege Attribute Certificate) внут­ри TGT и, наконец, сно­ва шиф­рует изме­нен­ный TGT с тем же хешем KRBTGT AES, так, что­бы тот выг­лядел легитим­ным.

По сути, это ата­ка на модифи­кацию TGT. Хакер не будет замора­чивать­ся кра­жей исходно­го TGT или соз­дани­ем нового с нуля. Ему дос­таточ­но прос­то поковы­рять­ся в PAC внут­ри уже сущес­тву­юще­го TGT и изме­нить его под свои нуж­ды.

Атака по шагам

Вот шаги, которые пред­при­нима­ются при про­веде­нии ата­ки Diamond Ticket:

• По­луче­ние AES-хеша учет­ной записи KRBTGT. Для начала зло­умыш­ленник ком­про­мети­рует учет­ную запись KRBTGT — обыч­но это дела­ется через дамп хешей с кон­трол­лера домена или получе­ние дос­тупа к важ­ной информа­ции кон­трол­лера.
• Де­шиф­ровка TGT с помощью AES-хеша KRBTGT. Ата­кующий исполь­зует AES-хеш акка­унта KRBTGT, что­бы дешиф­ровать валид­ный TGT. Ког­да TGT успешно рас­шифро­ван, в нем обна­ружи­вает­ся PAC — он несет информа­цию о при­виле­гиях поль­зовате­ля, членс­тве в груп­пах и дру­гую важ­ную инфу.
• Из­менение PAC. Рас­шифро­вав TGT, зло­умыш­ленник может покол­довать над PAC, что­бы впи­сать себе новые атри­буты или при­виле­гии. В ито­ге он может добавить себя в такие элит­ные груп­пы, как Domain Admins, или сме­нить членс­тво в груп­пах, что­бы про­качать свои пра­ва до небес.
• Пе­решиф­ровка изме­нен­ного TGT с исполь­зовани­ем AES-хеша KRBTGT. Как толь­ко зло­умыш­ленник поменя­ет PAC по сво­ему вку­су, он перешиф­ровыва­ет TGT с помощью хеша KRBTGT AES, что­бы получить новый валид­ный TGT. Эта перешиф­ровка зас­тавля­ет изме­нен­ный TGT выг­лядеть легитим­ным для сис­темы Kerberos.
• При­мене­ние модифи­циро­ван­ного TGT. Ата­кующий теперь может предъ­явить модифи­циро­ван­ный TGT, что­бы получить дос­туп к ресур­сам, как буд­то он при­виле­гиро­ван­ный поль­зователь, обхо­дя обыч­ные механиз­мы кон­тро­ля дос­тупа.
• TGS (Service Ticket). Тикеты TGS выда­ются на осно­ве TGT. Они сами по себе PAC не хра­нят, а исполь­зуют PAC из TGT, что­бы про­верить твою лич­ность и пра­ва.

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

Структура тикетов

TGT (Ticket Granting Ticket)

TGT — это шту­ка, которую тебе выда­ет Authentication Server (AS). Она нуж­на, что­бы потом штур­мовать Ticket Granting Service (TGS) для получе­ния сер­висных билетов. Обыч­но у нее внут­ри лежит сле­дующее:

• За­голо­вок — вер­сия и тип тикета.
• Ин­форма­ция о кли­енте — имя поль­зовате­ля и область (нап­ример, user@DOMAIN.LOCAL).
• Session Key — клю­чик, который делят меж­ду собой кли­ент и KDC. Он нужен, что­бы шиф­ровать обще­ние.
• PAC (Privilege Attribute Certificate) вклю­чает в себя все дан­ные о поль­зовате­ле:
  • про­пис­ка в груп­пах;
  • при­виле­гии (типа админ­ских прав);
  • SID акка­унта (Security Identifier) — уни­каль­ный иден­тифика­тор безопас­ности.
• Вре­мен­ная мет­ка и срок дей­ствия — пери­од валид­ности билета (вре­мя начала, вре­мя исте­чения).
• Шиф­рование KRBTGT — TGT зашиф­рован и под­писан с исполь­зовани­ем хеша KRBTGT (AES или RC4), что­бы толь­ко KDC мог его читать и про­верять.

TGS (сервисный тикет)

Да­вай раз­берем­ся, как устро­ен сер­висный тикет TGS. Он выда­ется сер­вером Ticket Granting Service на осно­ве TGT и исполь­зует­ся для дос­тупа к кон­крет­ным сер­висам. В его струк­туру вхо­дит:

• Ин­форма­ция о заголов­ке — вер­сия тикета и его тип.
• Ин­форма­ция о кли­енте — имя поль­зовате­ля и область.
• Session Key — уни­каль­ный ключ для безопас­ного обще­ния меж­ду кли­ентом и целевой служ­бой.
• Ин­форма­ция о сер­висе — Service Principal Name (SPN), который опре­деля­ет целевой сер­вис (нап­ример, HTTP/WEBSERVER.DOMAIN.LOCAL).
• PAC (Privilege Attribute Certificate) — берет­ся из TGT и при­меня­ется сер­висом, что­бы удос­товерить­ся, что поль­зователь — это тот, за кого он себя выда­ет, и про­верить, какие у него есть пра­ва.
• Вре­мен­ная мет­ка и срок дей­ствия — пери­од, в течение которо­го сер­висный тикет счи­тает­ся валид­ным.
• За­шиф­рован­ный сер­висный ключ — шиф­рование про­исхо­дит при помощи клю­ча сер­висно­го акка­унта (хеш пароля или клю­чевой матери­ал SPN).

Валидация PAC

Про­вер­ка PAC (Privilege Attribute Certificate) в Kerberos обес­печива­ет легитим­ность лич­ности и при­виле­гий поль­зовате­ля, который аутен­тифици­ровал­ся через Kerberos. PAC содер­жит инфу о при­над­лежнос­ти юзе­ра к груп­пам, его SID (Security Identifier) и дру­гие дан­ные для авто­риза­ции.

AS-REQ и AS-REP

• Кли­ент отправ­ляет AS-REQ в центр рас­пре­деле­ния клю­чей (KDC), что­бы получить билет‑допуск (TGT).
• KDC выда­ет TGT в AS-REP, вкла­дывая PAC в зашиф­рован­ную часть тикета.

TGS-REQ и TGS-REP

• Кли­ент отправ­ляет TGS-REQ на KDC, исполь­зуя свой TGT для зап­роса тикета на дос­туп к кон­крет­ному ресур­су.
• KDC отве­чает пакетом TGS-REP, в который вло­жен PAC.

AP-REQ (запрос приложения)

• Кли­ент отправ­ляет TGS (вклю­чая PAC) на целевой сер­вис.

Валидация PAC на стороне сервиса

• Ес­ли сер­вис доверя­ет KDC, он может нап­рямую исполь­зовать PAC без про­вер­ки.
• Ес­ли нуж­но про­верить PAC, сер­вис отправ­ляет его на кон­трол­лер домена для верифи­кации.

Подробности проверки PAC

• Сер­вис отсы­лает PAC кон­трол­леру домена, исполь­зуя про­вер­ку под­писи Kerberos.
• Кон­трол­лер домена (DC) про­веря­ет циф­ровую под­пись PAC (выпол­ненной с помощью при­ват­ного клю­ча KDC), что­бы убе­дить­ся в ее целос­тнос­ти и под­линнос­ти.
• Ес­ли всё окей, то DC шлет под­твержде­ние сер­вису.

AP-REP (ответ приложения)

• Пос­ле про­вер­ки PAC служ­ба либо дает дос­туп, либо отка­зыва­ет, осно­выва­ясь на пра­вах юзе­ра.

Ограничения PAC-валидации

Глав­ный косяк в аутен­тифика­ции с Kerberos PAC — от­сутс­твие про­вер­ки PAC сер­висами. Час­то слу­чает­ся так, что сер­висы без­думно доверя­ют PAC, встро­енно­му в билеты Kerberos, не све­ряясь с под­писью KDC или кон­трол­лера домена (DC). Как резуль­тат, зло­умыш­ленни­ки могут:

• соз­давать PAC офлайн, взло­мав учет­ные дан­ные (нап­ример, хеш NTLM или клю­чи Kerberos);
• соз­давать фей­ковый TGS-билет (Ticket Granting Service), не свя­зыва­ясь с KDC;
• ис­поль­зовать уяз­вимость в модели доверия, где сер­вис сле­по при­нима­ет тикет, пре­дос­тавляя несан­кци­они­рован­ный дос­туп.

Проб­лемы, к которым это может при­вес­ти:

• Ма­нипу­ляция моделью доверия Kerberos — сер­висы счи­тают PAC под­линным и про­пус­кают валида­цию.
• Оф­лайн‑под­делка — ата­ки совер­шают­ся в обход KDC, и отсле­дить их край­не слож­но.
• За­виси­мость — укра­ден­ные клю­чи или хеши учет­ных записей сер­висов поз­воля­ют генери­ровать тикеты.

Что нужно для атаки

• Хеш акка­унта KRBTGT — игра­ет клю­чевую роль при дешиф­ровке и решиф­ровке TGT.
• Ключ AES256 — час­тень­ко тре­бует­ся, что­бы ковырять­ся в PAC внут­ри TGT.
• Ад­минис­тра­тив­ный дос­туп — нужен дос­туп к акка­унту с высоки­ми при­виле­гиями, что­бы стя­нуть отту­да крип­тогра­фичес­кий матери­ал.

Да­вай теперь под­готовим стенд, на котором смо­жем вос­про­извести ата­ку.

В домен­ном кон­трол­лере соз­даем двух поль­зовате­лей: Raaz с пра­вами домен­ного адми­на и Sanjeet — обыч­ный поль­зователь.

Эта коман­да добав­ляет поль­зовате­ля Raaz к груп­пе Domain Admins на уров­не домена. Теперь у Raaz есть пол­ный кон­троль над доменом, как у нас­тояще­го хакера.

Будь осто­рожен с такими коман­дами — они выда­ют боль­шие пол­номочия и могут при­вес­ти к серь­езным пос­ледс­тви­ям, если попадут не в те руки.

Удаленная Атака Diamond на Linux

Как мы уже обсу­дили, что­бы про­вер­нуть эту ата­ку, зло­умыш­ленни­ку нуж­но зав­ладеть хешем KRBTGT. Пред­ста­вим, что в нашей гипоте­тичес­кой ситу­ации он сумел ском­про­мети­ровать учет­ку с высоки­ми при­виле­гиями, ска­жем RAAZ-User. Исполь­зуя этот дос­туп, ата­кующий реша­ет про­вер­нуть ата­ку DCSync, что­бы вытянуть хеш акка­унта KRBTGT.

Извлекаем хеш KRBTGT и SID домена

Вот как будет выг­лядеть коман­да:

На сле­дующей кар­тинке выделе­ны хеши NTLM и AES слу­жеб­ной учет­ной записи KRBTGT.

Те­перь узна­ем SID для поль­зовате­ля Raaz.

Создаем поддельный TGS и PAC

Зло­умыш­ленник под­делыва­ет сер­висный тикет для поль­зовате­ля Sanjeet, повысив его при­виле­гии и снаб­див валид­ной под­писью. При этом он хит­ро обхо­дит валида­цию PAC на кон­трол­лере домена.

Здесь

• -domain 'ignite.local' опре­деля­ет целевое домен­ное имя для ата­ки;
• -user 'sanjeet' — имя поль­зовате­ля, для которо­го соз­дает­ся под­дель­ный тикет;
• -password 'Password@1' — пароль поль­зовате­ля, нуж­ный, что­бы вытащить крип­тогра­фичес­кие клю­чи для генера­ции PAC или тикета (эта часть обыч­но не так важ­на в ата­ках типа «Сереб­ряный билет»);
• -nthash и -aesKey отно­сят­ся к учет­ной записи KRBTGT, нуж­ны для ата­ки типа Diamond Ticket. Они исполь­зуют­ся для крип­тогра­фичес­кой под­писи и про­вер­ки под­дель­ного сер­висно­го тикета;
• -domain-sid 'S-1-5-21-79...03' — уни­каль­ный иден­тифика­тор домена. Нужен при конс­тру­иро­вании PAC;
• sanjeet ука­зыва­ет на SPN (Service Principal Name) или имя поль­зовате­ля, которое ата­кующий исполь­зует, что­бы прит­ворить­ся Сан­житом и получить дос­туп к раз­ным сер­висам.

Pass the Ticket

В этом слу­чае перемен­ная окру­жения ука­зыва­ет сис­теме исполь­зовать кон­крет­ный файл кеша учет­ных дан­ных Kerberos (sanjeet.ccache) для аутен­тифика­ции.

В фай­ле sanjeet.ccache хра­нят­ся билеты Kerberos для поль­зовате­ля Sanjeet, и, ско­рее все­го, там мож­но най­ти билет дос­тупа к нуж­ному сер­вису (TGS) для выб­ранной цели.

Раз­берем парамет­ры:

• impacket-psexec — инс­тру­мент из биб­лиоте­ки Impacket, который по SMB дает тебе воз­можность уда­лен­но запус­кать коман­ды на Windows-машинах;
• ignite.local/sanjeet@dc.ignite.local — имя глав­ного объ­екта Kerberos (user@realm), которое исполь­зует­ся для аутен­тифика­ции. Здесь local — это домен, sanjeet — имя поль­зовате­ля, ignite.local — хос­тнейм нашего кон­трол­лера домена;
• -dc-ip 192.168.1.48 — этот параметр ука­зыва­ет IP-адрес кон­трол­лера домена, с которым ты хочешь вза­имо­дей­ство­вать;
• -target-ip 192.168.1.48 — IP-адрес целевой сис­темы, где будет выпол­нять­ся коман­да. В дан­ном слу­чае это тот же адрес, что и у кон­трол­лера домена;
• -k — ука­зыва­ет, что будет при­мене­на аутен­тифика­ция Kerberos вмес­то уста­рев­шего NTLM. Ути­лита заберет Kerberos-билеты из ука­зан­ного кеша учет­ных дан­ных (KRB5CCNAME);
• no-pass — сооб­щает инс­тру­мен­ту не зап­рашивать пароль, потому что аутен­тифика­ция будет выпол­нена с помощью Kerberos-билетов, которые уже лежат в кеше.

Локальная атака на Windows

Ес­ли зло­умыш­ленник про­ник на локаль­ный компь­ютер с Windows, то он может при­бег­нуть к таким инс­тру­мен­там, как Mimikatz и Rubeus.

Извлечение хеша KRBTGT

Ко­ман­да, которую я при­веду ниже, вытяги­вает NTLM-хеш и клю­чи шиф­рования AES учет­ной записи KRBTGT из целево­го домена. Эти хеши исполь­зуют­ся в ата­ках Golden Ticket и Diamond Ticket для под­делки билетов Kerberos.

Что­бы было наг­ляднее, вот при­мер коман­ды, демонс­три­рующей исполь­зование Rubeus (это ути­лита для опе­риро­вания с билета­ми Kerberos в Active Directory). Эта кон­крет­ная коман­да про­водит ата­ку Diamond Ticket, которая поз­воля­ет зло­умыш­ленни­ку при­кинуть­ся нуж­ным юзе­ром.

В этой ата­ке про­исхо­дит под­делка сер­висных билетов при помощи клю­чей шиф­рования KRBTGT. Раз­берем парамет­ры:

• krbkey:8e5...dbb — этот опе­ратор ука­зыва­ет AES-ключ KRBTGT, который нужен для шиф­рования и под­писи билета Kerberos. Это самый важ­ный параметр для соз­дания валид­ного сер­висно­го тикета;
• /user:sanjeet — имя поль­зовате­ля, от которо­го будет про­изво­дить­ся работа во вре­мя опе­рации;
• /password:Password@1 — пароль для ука­зан­ного поль­зовате­ля. Сис­тема исполь­зует этот пароль для аутен­тифика­ции и, воз­можно, получе­ния клю­чей шиф­рования или TGT;
• /enctype:aes — тип шиф­рования для билета Kerberos. В этом слу­чае исполь­зует­ся шиф­рование AES — популяр­ный вари­ант в сов­ремен­ных реали­заци­ях Kerberos для уси­ления защиты;
• /domain:ignite.local — целевой домен (ignite.local), для которо­го пред­назна­чен под­дель­ный билет;
• /dc:dc.ignite.local — сис­тема кон­нектит­ся к Domain Controller (dc.ignite.local) в про­цес­се соз­дания тикета;
• /ticketuser:sanjeet — фаль­шивый билет Kerberos сде­лан так, что­бы выдать себя за юзе­ра Sanjeet;
• /ptt — ата­ка Pass the Ticket. Сге­нери­рован­ный билет авто­мати­чес­ки встра­ивает­ся в текущую сес­сию, что­бы момен­таль­но сра­ботать при аутен­тифика­ции;
• /nowrap — эта нас­трой­ка не поз­воля­ет выводу в кон­соли перено­сить­ся на новую стро­ку. Улуч­шает чита­емость.

От TGT к TGS

Те­перь прог­рамма соль­ет TGT-билет, который при­годит­ся для зап­роса TGS.

klist

Эта коман­да выведет на экран все закеши­рован­ные на дан­ный момент билеты Kerberos.

В этом сце­нарии ата­кующий запус­кает коман­ду на Windows, что­бы получить спи­сок содер­жимого дис­ка C: уда­лен­ной машины. Что­бы ука­зать ее, нуж­но задать имя хос­та или IP-адрес.

Методы обнаружения

Вот спи­сок ID клю­чевых событий:

• 4769 (зап­рос сер­висно­го билета) — мож­но детек­тировать исполь­зование под­дель­ных TGT. Приз­наки: стран­ные име­на акка­унтов, высокие пра­ва (нап­ример, адми­нис­тра­торы домена) и зап­росы с неожи­дан­ных IP.
• 4624 (успешный вход в сис­тему) — ищи события с Logon Type 3 (сетевые вхо­ды) с неожи­дан­ных хос­тов или с повышен­ными при­виле­гиями у уче­ток, которые не тянут на адми­на.
• 4678 (при­виле­гии, наз­начен­ные при вхо­де) — поз­воля­ет отсле­живать момент, ког­да обыч­ным юзе­рам вдруг при­лета­ют спец­при­виле­гии (нап­ример, SeDebugPrivilege).
• 4713 (изме­нение полити­ки Kerberos) — изме­нены фла­ги вре­мени жиз­ни тикетов или дру­гие парамет­ры полити­ки Kerberos.
• 4625 (неудач­ная авто­риза­ция) — пов­торя­ющиеся фей­лы вхо­да от име­ни при­виле­гиро­ван­ных уче­ток или с подоз­ритель­ных IP-адре­сов.

Стра­тегии обна­руже­ния:

• Вре­мя жиз­ни тикета: срав­ни вре­мя жиз­ни тикета в событии с ID 4769 с нор­мами полити­ки, что­бы выловить ано­малии.
• При­вяз­ка при­виле­гий: отсле­живай повышен­ные при­виле­гии или дос­туп к чувс­тви­тель­ным SPN у обыч­ных юзе­ров.
• Не­типич­ное шиф­рование: обра­щай вни­мание на ред­кое шиф­рование, вро­де RC4, в событи­ях с ID 4769.
• Ис­поль­зование TGT: сле­ди за оди­нако­выми TGT, которые при­меня­ются на раз­ных IP или с раз­ных мест.

Про­активные при­емы:

• Вклю­чи логиро­вание Kerberos, что­бы уви­деть все в под­робнос­тях.
• Про­верь изме­нения в груп­пах с высоки­ми при­виле­гиями (ID событий 4728, 4732).
• Ре­гуляр­но меняй пароли учет­ной записи KRBTGT.

При­мер зап­роса для SIEM:

Как защититься?

Пре­вен­тивные меры:

• Ме­няй пароль учет­ной записи KRBTGT. Пос­тоян­но обновляй пароль у KRBTGT дваж­ды, что­бы анну­лиро­вать закеши­рован­ные тикеты.
• Внед­ряй сов­ремен­ное шиф­рование. Забудь про ста­рые про­токо­лы типа RC4-HMAC и исполь­зуй AES256.
• Ог­раничь эска­лацию при­виле­гий. Исполь­зуй прин­ципы минималь­ных при­виле­гий, что­бы умень­шить уяз­вимость.

Ре­аги­рова­ние на инци­дент:

• Об­нуление активных тикетов: мгно­вен­но меняй клю­чи KRBTGT и выкиды­вай всех поль­зовате­лей из сис­темы.
• Фо­рен­зика: исполь­зуй такие инс­тру­мен­ты, как BloodHound, что­бы пос­тро­ить тра­екто­рию повыше­ния при­виле­гий и выявить взло­ман­ные акка­унты.

Выводы

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