Сапфировый билет. Подделываем TGT с чужими привилегиями

Итак, Sapphire Ticket работа­ет по тому же прин­ципу, что и Diamond: ата­кующий получа­ет легаль­ный TGT и копиру­ет дан­ные из его PAC в под­дель­ный тикет. Но тут есть одна хит­рость: вмес­то того что­бы полагать­ся на PAC из пер­вично­го аутен­тифика­тора, зло­умыш­ленник про­водит отдель­ную опе­рацию для получе­ния PAC дру­гого поль­зовате­ля — чаще все­го с повышен­ными при­виле­гиями.

Ал­горитм сле­дующий:

• Аутен­тифика­ция через KDC (центр рас­пре­деле­ния клю­чей). Исполь­зуя рас­ширения S4U2Self и U2U, ата­кующий зап­рашива­ет TGS для поль­зовате­ля с высоки­ми при­виле­гиями. Так сис­тема соз­дает PAC, который отоб­ража­ет реаль­ные дан­ные авто­риза­ции поль­зовате­ля. Одна­ко этот билет нель­зя нап­рямую исполь­зовать в при­виле­гиро­ван­ных кон­тек­стах.
• Рас­шифров­ка дан­ных PAC.
• Из­менение PAC таким обра­зом, что­бы он соот­ветс­тво­вал атри­бутам нас­тояще­го TGT.
• Шиф­рование под­дель­ного билета с хешем KRBTGT.

Как и в слу­чае с золоты­ми и алмазны­ми билета­ми, что­бы соз­дать сап­фировый билет, ата­кующе­му нужен хеш домена KRBTGT. Но здесь есть одна осо­бен­ность: в отли­чие от осталь­ных подоб­ных атак, здесь не тре­буют­ся DOMAIN_SID и DOMAIN_RID. Вмес­то это­го всю нуж­ную инфу мож­но вытащить пря­мо из дей­стви­тель­ного TGT.

Важные термины

S4U2Self

Рас­ширение S4U2Self (бук­валь­но — «служ­ба от поль­зовате­ля к себе») для Kerberos поз­воля­ет сер­вису от име­ни поль­зовате­ля зап­росить для себя сер­висный билет. В нем содер­жатся дан­ные, удос­товеря­ющие пра­ва поль­зовате­ля, в час­тнос­ти Privilege Attribute Certificate (PAC). Имен­но на осно­ве этой инфы сис­тема потом реша­ет, какой дос­туп давать.

Что­бы вос­поль­зовать­ся S4U2Self, нуж­но, что­бы у поль­зовате­ля, который зап­рашива­ет, был зарегис­три­рован хотя бы один Service Principal Name (SPN). Этот SPN поз­воля­ет кон­трол­леру домена (DC) зашиф­ровать сге­нери­рован­ный сер­висный тикет с помощью сек­ретно­го клю­ча самого сер­виса.

Процесс запроса токена S4U2Self

1. Сер­вис соз­дает струк­туру дан­ных PA_FOR_USER, где ука­зыва­ет поль­зовате­ля, от име­ни которо­го хочет вой­ти.
2. От­прав­ляет сооб­щение KRB_TGS_REQ на сер­вер выдачи билетов (TGS).
3. TGS (Ticket Granting Service) отве­чает сер­висным билетом, в котором лежит PAC поль­зовате­ля, зашиф­рован­ный для зап­рашива­емо­го сер­виса.

U2U

Аутен­тифика­ция User-to-User (U2U), или «аутен­тифика­ция поль­зовате­лей меж­ду собой», — это фиш­ка Kerberos, которая поз­воля­ет кли­енту зап­росить билет, зашиф­рован­ный сес­сией дру­гого поль­зовате­ля. Это обыч­но про­исхо­дит, ког­да сер­вером выс­тупа­ет юзер и у него нет дол­госроч­ного клю­ча, как на дес­кто­пе.

Вот что нуж­но для зап­роса тикетов в U2U:

• additional-tickets — содер­жит TGT поль­зовате­ля, выс­тупа­юще­го в роли сер­вера;
• ENC-TKT-IN-SKEY — говорит KDC шиф­ровать сер­висный тикет с исполь­зовани­ем сес­сион­ного клю­ча из допол­нитель­ного тикета;
• sname (имя сер­виса) может ука­зывать на поль­зователь­ский акка­унт, а не на тра­дици­онный сер­вис с SPN.

Это поз­воля­ет одно­му поль­зовате­лю (поль­зователь Б) надеж­но аутен­тифици­ровать­ся у дру­гого поль­зовате­ля (поль­зователь А), даже если у поль­зовате­ля А нет сох­ранен­ного сек­ретно­го клю­ча.

При­мер работы U2U:

• поль­зователь А (в роли сер­вера) выкаты­вает свой TGT поль­зовате­лю Б;
• поль­зователь Б отправ­ляет KRB_TGS_REQ на KDC, вклю­чая TGT как от поль­зовате­ля A, так и свой собс­твен­ный;
• KDC генерит новый сеан­совый ключ и зашиф­ровыва­ет его два раза: пер­вый раз — под сеан­совый ключ поль­зовате­ля A, вто­рой — под ключ поль­зовате­ля Б.

Оба поль­зовате­ля рас­шифро­вали свои час­ти, и теперь у них есть общий сес­сион­ный ключ для безопас­ного обще­ния.

Это избавля­ет поль­зовате­ля А от необ­ходимос­ти хра­нить пос­тоян­ный мас­тер‑ключ, что дела­ет запуск сер­висов с менее защищен­ных конеч­ных точек вро­де дес­кто­пов безопас­нее.

Технические подробности

Sapphire Tickets исполь­зует связ­ку S4U2Self и U2U, что­бы обой­ти клас­сичес­кие тре­бова­ния к SPN.

Вот как это работа­ет. Обыч­но для S4U2Self тре­бует­ся дей­стви­тель­ный SPN. Но если под­клю­чить U2U, мож­но зап­росить тикеты S4U2Self вооб­ще без нуж­ды в SPN.

Пред­положим, у тебя есть сер­вис, нас­тро­енный для работы с Kerberos Constrained Delegation (KCD). На него при­лета­ет сес­сия от юзе­ра, про­шед­шего аутен­тифика­цию через NTLM. И тут заг­воз­дка: если у юзе­ра нет билета Kerberos (ST), то этот сер­вис даль­ше делеги­ровать пра­ва уже не смо­жет.

В этом слу­чае сер­вис отправ­ляет зап­рос KRB_TGS_REQ, что­бы получить сер­вис‑токен (ST) для поль­зовате­ля — самому себе — через S4U2Self.

По­лучен­ный тикет вклю­чает в себя PAC поль­зовате­ля, который сер­вис может рас­шифро­вать с помощью клю­ча KRBTGT.

Как толь­ко у сер­виса появит­ся PAC (Privilege Attribute Certificate), он смо­жет добавить его в уже име­ющий­ся TGT (Ticket Granting Ticket), перешиф­ровать и сно­ва под­писать с исполь­зовани­ем клю­ча KRBTGT.

Ко­рот­ко: S4U2Self поз­воля­ет сер­вису получить тикет от име­ни поль­зовате­ля. U2U не тре­бует клю­ча сер­виса, что­бы это про­вер­нуть. Вмес­те они прев­раща­ются в мощ­ное средс­тво для мас­киров­ки под поль­зовате­лей и манипу­ляции токена­ми Kerberos.

Подготовка лаборатории

Что­бы про­вер­нуть эту ата­ку, мы соз­дадим двух поль­зовате­лей: admin1 — домен­ный адми­нис­тра­тор, rudra — обыч­ный поль­зователь на кон­трол­лере домена. Залогинь­ся на кон­трол­лере домена, открой коман­дную стро­ку и вво­ди коман­ды по нашему рецеп­ту.

Соз­даем нового поль­зовате­ля admin1 в домене и выда­ем ему пароль Password@1. Затем добав­ляем поль­зовате­ля admin1 в груп­пу Domain Admins в домене.

Пос­ле выпол­нения коман­ды про­верим, дей­стви­тель­но ли admin1 про­писан в груп­пе домен­ных адми­нов. Для это­го заходим в «Поль­зовате­ли и компь­юте­ры Active Directory → Поль­зовате­ли» и дваж­ды кли­каем на выб­ранно­го поль­зовате­ля (у нас это admin1). Затем перехо­дим на вклад­ку «Членс­тво». В спис­ке дол­жен быть Domain Admins, как на скрин­шоте ниже.

Атака на сапфировый билет

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

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

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

На сле­дующем эта­пе извле­ки SID для поль­зовате­ля admin1.

Генерация поддельного TGS и PAC

Ата­кующий под­делыва­ет сер­висный билет для поль­зовате­ля admin1, воз­можно с завышен­ными при­виле­гиями и валид­ной под­писью, тем самым обхо­дя механиз­мы обна­руже­ния типа PAC-про­вер­ки на кон­трол­лере домена.

Здесь

• -domain ignite.local ука­зыва­ет целевой домен для ата­ки;
• -user rudra — имя поль­зовате­ля, для которо­го генери­рует­ся под­дель­ный билет;
• -password Password@1 — пароль поль­зовате­ля для получе­ния крип­тогра­фичес­ких клю­чей при генера­ции PAC или билета. Обыч­но не встре­чает­ся в ата­ках с исполь­зовани­ем Silver Ticket;
• -nthash и -aesKey при­над­лежат акка­унту KRBTGT, как и нуж­но для ата­ки с исполь­зовани­ем Diamond Ticket.

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

• -domain-sid S-1-5-21-79...03 — эта стро­ка опи­сыва­ет иден­тифика­тор безопас­ности (SID) для домена (SID нужен, что­бы сфор­мировать PAC);
• admin1 — показы­вает, какой SPN (имя глав­ного сер­виса) или логин зло­умыш­ленник исполь­зует, что­бы прит­ворить­ся дру­гим и вык­роить дос­туп к услу­гам как baduser.

Pass the Ticket

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

Файл baduser.ccache хра­нит билеты Kerberos для поль­зовате­ля baduser, и, ско­рее все­го, там ока­жет­ся и сер­висный билет (TGS) для выб­ранной цели. Это зна­чит, что ты можешь вос­поль­зовать­ся этим фай­лом, что­бы авто­ризо­вать­ся и зай­ти на сер­вис под видом baduser.

Да­вай раз­берем эту коман­ду по час­тям:

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

Metasploit

Эта тех­ника поз­воля­ет стя­нуть хеши SAM и сек­реты LSA (вклю­чая кеширо­ван­ные кре­ды) с уда­лен­ной машины на Windows без раз­верты­вания аген­та на мес­те. Хит­рость в том, что­бы уда­лен­но обно­вить дес­крип­тор безопас­ности клю­ча реес­тра, вос­поль­зовав­шись при­виле­гиями WriteDACL локаль­ных адми­нов, что­бы вре­мен­но выс­тавить пра­ва на чте­ние.

Да­вай пос­мотрим, что нуж­но, что­бы это про­вер­нуть.

Атака с сапфировым билетом

Вот как выг­лядит про­цесс ата­ки.

Да­вай раз­берем, что про­исхо­дит на этом скрин­шоте.

• RHOSTS = 192.168.1.48 — целевая машина, домен‑кон­трол­лер;
• SMBDOMAIN = ignite.local — домен;
• SMBUSER = admin1 — юзер;
• SMBPASS = Password@1 — пароль;
• KRB_USERS = krbtgt — поль­зователь для выдачи билетов в Kerberos;
• ACTION = DOMAIN — показы­вает, что про­исхо­дит слив сек­ретов домена.

Мо­дуль запус­кает­ся, и сек­реты сли­вают­ся с помощью метода DRSUAPI (он час­то исполь­зует­ся для выделе­ния дан­ных из NTDS.DIT).

Крас­ным обве­дены:

• NTLM-хеш для krbtgt: 76...c7;
• ключ Kerberos AES для krbtgt: 8e...bb.

Эти дан­ные необ­ходимы для под­делки билетов, потому что клю­чи KRBTGT исполь­зуют­ся для под­писи дей­стви­тель­ных билетов Kerberos.

Этот модуль уме­ло кует Kerberos-билеты, при­меняя четыре хит­рых метода. В методе «сереб­ряный билет» ата­кующий берет хеш учет­ной записи сер­виса и кле­пает билет, который выда­ет себя за любого поль­зовате­ля и дает это­му акка­унту нуж­ные при­виле­гии.

Ме­тод «золотой билет» — это ког­да зло­умыш­ленник исполь­зует хеш krbtgt, что­бы смас­терить билет, изоб­ражая любого поль­зовате­ля с любыми при­виле­гиями.

Да­лее идет «алмазный билет»: тут добав­ляет­ся аутен­тифика­ция на кон­трол­лере домена и затем при­меня­ется тот же хеш krbtgt, что­бы ско­пиро­вать PAC аутен­тифици­рован­ного поль­зовате­ля в под­дель­ный билет.

И зак­рыва­ет всю эту эпо­пею «сап­фировый билет», где исполь­зуют улов­ку S4U2Self и U2U, что­бы добыть PAC дру­гого поль­зовате­ля, а затем на базе хеша krbtgt соз­дает­ся под­дель­ный билет.

Мы исполь­зуем модуль Metasploit forge_ticket, что­бы соз­дать под­дель­ный билет Kerberos.

Основные шаги

Сна­чала нас­тра­иваем парамет­ры для под­делки:

• AES_KEY = ключ — берем его из пре­дыду­щего шага;
• USER = admin1 — поль­зователь, которо­го мы изоб­ража­ем;
• REQUEST_USER = rudra — поль­зователь, соз­дающий обра­щение;
• REQUEST_PASSWORD = Password@1 — исполь­зует­ся в про­цес­се U2U;
• DOMAIN = ignite.local — уста­нав­лива­ем домен;
• RHOSTS = 192.168.1.48 — целевая машина.

За­тем запус­каем модуль и получа­ем в виде отве­та TGT (Ticket Granting Ticket) и TGS (Ticket Granting Service).

Би­лет сох­ранен по сле­дующе­му пути:

За­пус­каем коман­ду ls, что­бы показать все фай­лы. Затем исполь­зуем mv, что­бы пере­име­новать файл в 1.bin, — так будет про­ще ори­енти­ровать­ся в будущем.

Сле­дующий модуль исполь­зует валид­ные админ­ские логин и пароль (или их хеш), что­бы выпол­нить про­изволь­ный пей­лоад. В общем, он чем‑то похож на ути­литу psexec из SysInternals. Модуль хорош тем, что уме­ет уби­рать за собой. А еще он соз­дает сер­вис с ран­домно выб­ранны­ми име­нем и опи­сани­ем.

Нас­трой­ки:

• SET RHOST 192.168.1.48 — IP целевой машины;
• SMBDOMAIN: ignite.local — имя домена SMB-сети;
• USERNAME: admin1;
• SMB::AUTH: — уста­нови как Kerberos;
• SMB::KRB5CCNAME — кеш билетов Kerberos заг­ружен из /root/.msf4/loot/1.bin;
• SMB::RHOSTNAME:dc.ignite.local — имя хос­та кон­трол­лера домена;
• DOMAINCONTOLLERHOST явно задан как 192.168.1.48;
• LHOST — машина ата­кующе­го, 192.168.1.60.

Те­перь вве­ди run и жми Enter, что­бы запус­тить наг­рузку и открыть сеанс Meterpreter.

Выводы

Сап­фировый билет — это мощ­ный спо­соб манипу­ляции аутен­тифика­цией Kerberos, объ­еди­няющий рас­ширения про­токо­лов S4U2Self и User-to-User (U2U). Эта тех­ника поз­воля­ет зло­умыш­ленни­ку или сер­вису выдать себя за поль­зовате­ля и вытащить его дан­ные авто­риза­ции (PAC), не замора­чива­ясь с Service Principal Name (SPN) или дол­госроч­ным клю­чом сер­виса.

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

Эта тех­ника наг­лядно демонс­три­рует, как зло­умыш­ленни­ки могут исполь­зовать закон­ные фун­кции Kerberos — изна­чаль­но соз­данные для гиб­кой делега­ции и безопас­ной аутен­тифика­ции меж­ду узла­ми, если в безопас­ности домена есть про­белы в кон­фигура­ции и кон­тро­ле.

Что­бы пре­дот­вра­тить такие ата­ки:

• мо­ниторь активность заявок и нес­тандар­тных зап­росов на делеги­рова­ние;
• об­рати вни­мание на защиту и аудит нас­тро­ек KCD;
• ми­ними­зируй исполь­зование NTLM и сле­ди за хорошей гиги­еной сер­висных прин­ципалов.

Сап­фировые билеты прев­раща­ют механизм доверия Kerberos в потен­циаль­ный инс­тру­мент для незамет­ных атак. Поэто­му осве­дом­ленность и уме­ние выяв­лять такие угро­зы ста­новят­ся жиз­ненно важ­ными навыка­ми при защите Active Directory.