Атаки на службы сертификатов Active Directory

В сегодняшней статье мы рас­смот­рим нес­коль­ко видов атак на на службы сертификатов Active Directory (ADCS — Active Directory Certification Services) и выяс­ним, каким обра­зом с исполь­зовани­ем этой роли мож­но повысить при­виле­гии в сис­теме. В конце статьи, традиционно рассмотрим способы  защиты от атак на Active Directory Certification Services.

Еще по теме: Защита от обнаружения при атаке на Active Directory

Атаки на службы сертификатов Active Directory

Для про­веде­ния тес­тов на проникновение пот­ребу­ется лабора­тор­ный стенд, который будет состоять из двух вир­туаль­ных машин:

• Windows Server 2016 (жертва)
• Kali Linux (атакующий)

Вот общие тре­бова­ния для всех атак:

• сер­тификат может быть выпущен груп­пой, в которую вхо­дит ваш поль­зователь;
• Manager Approval дол­жен быть отклю­чен;
• под­пись CSR не тре­бует­ся.

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

Сбор информации

Пер­вый этап тес­тирова­ния на про­ник­новение — сбор полезной информа­ции о цели. Для этой цели можно юзать Certipy + BloodHound. Перед этим необходимо заг­рузить под­готов­ленные раз­работ­чиками Certipy зап­росы на свой хост.

По­лучить информа­цию из цен­тра сер­тифика­ции может модуль find:

BloodHound предлагает визу­али­зацию информа­ции по объ­ектам AD CS и пра­вам на них, а так­же опре­деляет векторы повыше­ния при­виле­гий.

Modifiable SAN. ESC1

Данная ата­ка осно­вана на изме­нении сер­тифика­та SAN (циф­ровой сер­тифика­т безопас­ности,) который может защищать нес­коль­ко имен хос­тов одним сер­тифика­том. Это поз­волит нам выпус­тить сер­тификат на дру­гого поль­зовате­ля, даже адми­нис­тра­тора домена.

Что­бы ата­ка прош­ла успешно, шаб­лон сер­тифика­та дол­жен иметь уста­нов­ленный флаг:

Вы­ведем все такие шаб­лоны с исполь­зовани­ем BloodHound.

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

В этой коман­де уста­нав­лива­ется параметр alt, который ука­зыва­ет SAN в зап­рашива­емом сер­тифика­те.

Из лога Certipy вид­но, что мы получи­ли сер­тификат на поль­зовате­ля Administrator.

Те­перь все, что нам оста­ется, — это прой­ти аутен­тифика­цию с выпущен­ным сер­тифика­том и получить NTLM-хеш адми­нис­тра­тора домена.

В Windows мы можем это сде­лать при помощи mmc, исполь­зуя оснас­тку Certificates. При попыт­ке выпус­тить сер­тификат от нас пот­ребу­ется допол­нитель­ная информа­ция, в которой мы и ука­жем любого поль­зовате­ля.

В Subject Name выбира­ем Type: Common Name, а в Alternative Name — User principal name: administrator@contoso.com.

Ес­ли все прош­ло успешно, нуж­но экспор­тировать сер­тификат с ука­зани­ем пароля и зап­росить TGT-билет для поль­зовате­ля:

Для перево­да сер­тифика­та в Base64 мож­но исполь­зовать сле­дующие коман­ды:

Any or None Purpose Attack. ESC2

Ес­ли в шаб­лоне сер­тифика­та ука­зан EKU любого наз­начения или вооб­ще отсутс­тву­ет EKU, сер­тификат мож­но исполь­зовать для чего угод­но. Им мож­но зло­упот­реблять, как ESC3, нап­ример, исполь­зовать сер­тификат в качес­тве тре­бова­ния для зап­роса дру­гого сер­тифика­та от име­ни любого поль­зовате­ля.

Enrollment Agent. ESC3

В до­кумен­тации Microsoft ука­зано, что EKU Certificate Request Agent может исполь­зовать­ся, что­бы выдать себя за дру­гого поль­зовате­ля, и поз­воля­ет выпус­тить сер­тификат, который может быть исполь­зован для сов­мес­тной под­писи зап­росов от име­ни любого поль­зовате­ля для любого шаб­лона.

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

Certificate ACL Abuse. ESC4

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

При помощи инс­тру­мен­та PowerView мы можем кра­сиво вывес­ти все ACE на шаб­лоны:

Од­нако BloodHound покажет то же самое еще удоб­нее и кра­сивее. Мож­но уви­деть, что груп­па с SID = 513 (Domain Users) име­ет пра­ва GenericAll на шаб­лон ACL. Подоб­ное неред­ко встре­чает­ся в «живой при­роде», поэто­му не сто­ит счи­тать этот при­мер пол­ностью искусс­твен­ным.

Сле­дующим дей­стви­ем будет сох­ранение текуще­го сос­тояния сер­тифика­та, что­бы вер­нуть его в исходное сос­тояние пос­ле экс­плу­ата­ции (мы ведь этич­ные хакеры). Заод­но мы изме­ним кон­фигура­цию под ата­ку ESC1.

Для выпол­нения этих дей­ствий certipy име­ет спе­циаль­ный флаг -save-old:

Те­перь шаб­лон уяз­вим к ESC1, и мы можем получить сер­тификат на адми­нис­тра­тора домена.

Everything and for everyone (EDITF_ATTRIBUTESUBJECTALTNAME2). ESC6

Ата­ку ESC5 мы раз­бирать не будем, так как она нацеле­на не на службы сертификатов Active Directory, а на объ­екты, которые могут при­нес­ти какой‑то импакт в AD CS. А вот ESC6 — это самая опас­ная и по сво­ей сути лег­кая ата­ка. Если сис­темный адми­нис­тра­тор (видимо, не в сво­ем уме) уста­новил флаг EDITF_ATTRIBUTESUBJECTALTNAME2 в цен­тре сер­тифика­ции, то это прос­тей­ший век­тор для повыше­ния при­виле­гий в сис­теме.

Этот флаг поз­воля­ет хакеру ука­зать про­изволь­ный SAN (Subject Alternative Name) для всех сер­тифика­тов, нес­мотря на кон­фигура­цию шаб­лона сер­тифика­та.

Manage CA & Manage Certificate. ESC7

В службы сертификатов Active Directory, есть шаб­лон, который по умол­чанию уяз­вим к ESC1, — SubCA, но выпус­кать его могут лишь поль­зовате­ли, вхо­дящие в груп­пу Domain Admins.

ESC7 осно­ван на том фак­те, что зап­росы, которые завер­шились неуда­чей, сох­раня­ются и могут быть зап­рошены еще раз. Поль­зовате­ли, име­ющие пра­ва Manage CA и Manage Certificates на центр сер­тифика­ции, могут перевы­пол­нять неудач­ные зап­росы на выпуск сер­тифика­та и выпус­кать SubCA на любого поль­зовате­ля.

Сох­ранив ID зап­роса и при­ват­ный ключ, выпус­тим сер­тификат:

Те­перь зап­росим перевы­пущен­ный сер­тификат.

В оче­ред­ной раз мы ста­ли адми­нис­тра­тором домена.

Relay на AD CS Web Enrollment. ESC8

Вы навер­няка слы­шали про PetitPotam. Ес­ли крат­ко, то мы можем реле­ить хеш в центр сер­тифика­ции, получая сер­тификат в фор­мате PKCS12 на поль­зовате­ля, чей хеш мы рет­ран­сли­рова­ли.

От­личный док­лад про Relay-ата­ки: Coercions and Relays — The First Cred is the Deepest with Gabriel Prud’homme.

dNSHostName Spoofing

В мае 2022 года в Active Directory была най­дена уяз­вимость, которой был прис­воен иден­тифика­тор CVE-2022-26923. Ког­да поль­зователь зап­рашива­ет сер­тификат на осно­ве шаб­лона Users, UPN (UserPrincipalName) учет­ной записи поль­зовате­ля встав­ляет­ся в параметр SAN (Subject Alternative Name) сер­тифика­та.

Од­нако учет­ные записи компь­юте­ров не име­ют UPN, вмес­то это­го исполь­зует­ся dNSHostName компь­юте­ра, который и встав­ляет­ся в параметр SAN. В этом и зак­люча­ется суть ата­ки: изме­нив dNSHostName на кон­трол­лер домена, мы выпус­тим сер­тификат на машин­ную учет­ную запись это­го кон­трол­лера.

По умол­чанию обыч­ные поль­зовате­ли могут добав­лять компь­юте­ры в домен, и учет­ная запись компь­юте­ра будет иметь такую инте­рес­ную при­виле­гию, как Validate write to DNS host name, что поз­воля­ет изме­нять параметр dNSHostName на про­изволь­ную стро­ку.

Соот­ветс­твен­но, мы можем поменять dNSHostName на DNS-имя кон­трол­лера домена, а затем аутен­тифици­ровать­ся, получив сер­тификат на машин­ную учет­ную запись кон­трол­лера домена! Одна­ко не все так прос­то. Ког­да мы меня­ем dNSHostName на компь­юте­ре, меня­ются зна­чения servicePrincipalName, а они дол­жны быть уни­каль­ными.

Вот тут в игру всту­пает еще одна инте­рес­ная при­виле­гия на объ­ект компь­юте­ра — Validate write to Service Principal Name (SPN), поз­воля­ющая изме­нять, добав­лять и уда­лять параметр SPN, и обой­ти огра­ниче­ние уни­каль­нос­ти, прос­то уда­лив SPN, где ука­зыва­ется пол­ный dNSHostName, а не sAMAccountName компь­юте­ра.

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

Пол­ный флоу ата­ки выг­лядит сле­дующим обра­зом:

1. Соз­дание компь­юте­ра в домене с dNSHostName, соот­ветс­тву­ющим DNS-име­ни кон­трол­лера домена.
2. За­мена SPN.
3. Зап­рос сер­тифика­та для компь­юте­ра.

Соз­дадим компь­ютер через Certipy, ука­зав в параметр -dns FQDN кон­трол­лера домена:

Зап­рашива­ем сер­тификат, исполь­зуя стан­дар­тный шаб­лон Machine.

Об­ратите вни­мание: мы выпус­тили сер­тификат на машин­ную учет­ку кон­трол­лера домена, пос­ле чего ста­ли этим кон­трол­лером.

В темати­чес­ких чатах я замечал сле­дующий воп­рос: а как про­верить, уяз­вим ли кон­трол­лер домена к CVE-2022-26923? Глав­ным приз­наком уяз­вимос­ти слу­жит наличие SID в отве­те на зап­рос сер­тифика­та. Если он есть — патч в сис­теме при­сутс­тву­ет, если нет, то пат­ча тоже нет.

Golden Certificate

Это прос­той ана­лог для Golden или Diamond Ticket.

Пер­вый этап ата­ки — соз­дание бэкапа цен­тра сер­тифика­ции и получе­ние сер­тифика­та это­го цен­тра.

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

Сопоставление сертификатов

В пат­че CVE-2022-26923 в реестр были добав­лены два зна­чения:

• StrongCertificateBindingEnforcement
• CertificateMappingMethods

Они пред­назна­чен­ные для сопос­тавле­ния сер­тифика­тов.

StrongCertificateBindingEnforcement. Kerberos

Пос­ле появ­ления исправ­лений параметр StrongCertificateBindingEnforcement по умол­чанию име­ет зна­чение 1. Теперь KDC про­веря­ет, выпол­няет­ся ли явное сопос­тавле­ние сер­тифика­тов. Если да, то аутен­тифика­ция раз­решена. В про­тив­ном слу­чае KDC про­верит, име­ет ли сер­тификат SID, и под­твер­дит его. Если SID отсутс­тву­ет, аутен­тифика­ция раз­решена.

Зна­чение 0 не озна­чает никаких дей­ствий, что оставля­ет век­тор ата­ки откры­тым.

Ес­ли параметр име­ет зна­чение 2, KDC про­веря­ет, выпол­няет­ся ли надеж­ное сопос­тавле­ние сер­тифика­тов. Если да, то аутен­тифика­ция раз­решена. В про­тив­ном слу­чае KDC про­верит, име­ет ли сер­тификат SID, и под­твер­дит его. Если этот SID отсутс­тву­ет, аутен­тифика­ция откло­няет­ся.

Зна­чение 2 будет уста­нов­лено по умол­чанию с 9 мая 2023 года.

CertificateMappingMethods. Schannel

В дан­ном методе исполь­зует­ся аутен­тифика­ция через про­токол Schannel. Этот про­токол сопос­тавля­ет сер­тифика­ты нем­ного ина­че. Параметр CertificateMappingMethods может при­нимать пять зна­чений:

• 0x0001 — сопос­тавле­ние сер­тифика­тов субъ­ект/объ­ект;
• 0x0002 — сопос­тавле­ние сер­тифика­тов ЦА;
• 0x0004 — сопос­тавле­ние сер­тифика­тов по SAN;
• 0x0008 — сопос­тавле­ние сер­тифика­тов S4U2Self;
• 0x0010 — явное сопос­тавле­ние сер­тифика­тов S4U2Self.

По умол­чанию уста­нов­лено зна­чение 0x18 (0x8 и 0x10). S4U2Self исполь­зует­ся из‑за того, что Schannel не под­держи­вает новые парамет­ры, которые прив­нес оче­ред­ной патч, и сопос­тавле­ние идет через Kerberos.

ESC9. Jump to DA

Для этой ата­ки нуж­но, что­бы параметр StrongCertificateBindingEnforcement имел зна­чение 1 или . Еще пот­ребу­ется сер­тификат с уста­нов­ленным фла­гом CT_FLAG_NO_SECURITY_EXTENSION в парамет­ре msPKI-Enrollment-Flag, а так­же GenericWrite любого поль­зовате­ля в домене. BloodHound 4.2.0 име­ет встро­енные зап­росы для вывода подоб­ных шаб­лонов.

Пер­вым делом сле­дует получить хеш учет­ной записи B от учет­ной записи A, которая име­ет GenericWrite на B, нап­ример через Shadow Credentials:

Пос­ле получе­ния хеша нуж­но изме­нить UPN учет­ной записи B на UPN адми­нис­тра­тора:

За­метьте, не на Administrator@contoso.com, а на Administrator.

Даль­ше зап­росим сер­тификат от учет­ной записи Max (она же учет­ная запись B), хеш которой мы получи­ли на пер­вом эта­пе:

Пос­коль­ку мы изме­нили UPN на Administrator, сер­тификат будет выпущен на имя адми­на. Что­бы вер­нуть все как было, мы уста­нав­лива­ем UPN обратно, но уже с ука­зани­ем домена:

ESC10. Nameless accounts

Для успешно­го выпол­нения этой ата­ки нуж­но, что­бы парамет­ры име­ли сле­дующие зна­чения:

Так­же нам понадо­бит­ся раз­решение GenericWrite на учет­ную запись А.

Дан­ная ата­ка пред­полага­ет ком­про­мета­цию учет­ных записей, у которых отсутс­тву­ет UPN. К таковым отно­сит­ся, в час­тнос­ти, машин­ная учет­ка или встро­енная учет­ка Administrator.

Сна­чала мы получа­ем хеш учет­ной записи B, так­же через ShadowCredentials или любым дру­гим спо­собом:

За­тем меня­ем UPN учет­ной записи на, нап­ример, кон­трол­лер домена:

Да­лее зап­рашива­ем сер­тификат от Max и… сами ста­новим­ся кон­трол­лером домена:

Защита от атак на службы сертификатов Active Directory

Защитить­ся от таких атак отно­ситель­но нес­ложно: нуж­ны пра­виль­ные нас­трой­ки сер­вера и, конеч­но же, не сле­дует забывать о сво­евре­мен­ной уста­нов­ке обновле­ний безопас­ности.

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

Про­вер­ку кор­рек­тнос­ти нас­тро­ек шаб­лонов мож­но выпол­нить с помощью замеча­тель­ного инс­тру­мен­та PSPKIAudit.

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

РЕКОМЕНДУЕМ:

• Пентест Active Directory на машине HTB Intelligence
• Уклонение от Honeytoken при атаке Active Directory
• Как обойти PowerShell AMSI при атаке на Active Directory