Обнаружение и исправление использования RC4 в Kerberos

Проверка подлинности Kerberos в средах Active Directory (AD) исторически зависит от алгоритма шифрования RC4. RC4 — это шифр потока, который полезен из-за его совместимости с устаревшими системами. Тем не менее, RC4 в настоящее время считается небезопасным и постепенно выходит из строя.

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

На высоком уровне ИТ-администраторы должны выполнить следующие действия, чтобы подготовиться к изменениям по умолчанию в поддержке Kerberos для RC4:

1. Аудит текущего использования RC4: используйте средства аудита и журналы событий, описанные в этой статье, для идентификации учетных записей, служб или устройств, которые по-прежнему используют RC4.

2. Обработка устаревших устройств: переносите или заменяйте неподдерживаемые устройства, особенно те, которые работают на Windows Server 2003 или более ранних версиях, так как они не имеют поддержки AES-SHA1.

3. Отключите RC4: если это возможно, явным образом отключите RC4.

Использование RC4 в Windows и его рисках

RC4 обычно используется в средах Windows, если учетные записи или устройства не поддерживают более строгие типы шифрования, такие как AES-SHA1. Использование RC4 может происходить с устаревшими системами, учетными записями, созданными до появления поддержки AES-SHA1, или когда параметры шифрования настроены неявно. RC4 — это тип шифрования по умолчанию, который является общим выбором для совместимости со старой инфраструктурой. Однако зависимость от RC4 подвергает среды рискам безопасности, и его использование активно прекращается в пользу более безопасных алгоритмов.

В ответ на CVE-2022-37966, обновления Windows, выпущенные 8 ноября 2022 года, изменили тип шифрования по умолчанию в Kerberos, чтобы использовать advanced Encryption Standard (AES)-SHA1 вместо RC4 для учетных записей, в которых тип шифрования не был явно задан. Это изменение привело к значительному сокращению использования RC4, но RC4 по-прежнему используется по умолчанию для учетных записей, которые не поддерживают AES-SHA1. Дополнительные сведения см. в KB5021131.

Это обновление добавляет возможность задать значение реестра для управления поддерживаемым типом шифрования по умолчанию в Kerberos. Если этот параметр реестра не задан, поддерживаемые по умолчанию типы шифрования — DES, RC4 и AES.

Тип шифрования Kerberos RC4 по умолчанию можно использовать для выполнения метода атаки, известного как Kerberoasting, который предназначен для запросов на обслуживание в Майкрософт Active Directory. В Kerberoasting злоумышленники захватывают эти билеты и взломают шифрование в автономном режиме, чтобы украсть учетные данные пользователя, потенциально компрометируя безопасность всей сети. Изменение типа шифрования Kerberos для использования AES-SHA1 по умолчанию вместо RC4 помогает защитить клиентов от этой атаки.

Предпосылки

Перед началом работы необходимо выполнить следующие предварительные требования:

• Вам нужны разрешения для доступа к журналам событий безопасности на контроллерах домена, таких как член группы администраторов домена или эквивалент.

• Если вы хотите запустить команды и сценарии PowerShell в этой статье, необходимо установить модуль ActiveDirectory на устройстве, где выполняются команды.

Аудит использования RC4

Сведения об использовании RC4 хранятся в журналах событий безопасности в Центрах распространения Kerberos Key Distribution Centers (KDCs) для Windows Server 2019 и более поздних версий. Использование RC4 в журналах событий также было добавлено в Windows Server 2016 в накопительном обновлении за январь 2025 г. Следующие идентификаторы событий определяют использование RC4 и учетные записи, которые имеют возможность использовать только RC4.

• Идентификатор события 4768, который предназначен для запрошенного билета проверки подлинности Kerberos (TGT).
• Идентификатор события 4769, который предназначен для запрошенного билета службы Kerberos.

Поля журнала событий для использования RC4

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

• Разделы "Сведения об учетной записи" и "Сведения о службе":

  • MSDS-SupportedEncryptionTypes: является атрибутом Active Directory, который обозначает типы шифрования, поддерживаемые учетной записью. Если msDS-SupportedEncryptionTypes для учетной записи не определено, KDC применяет значение из DefaultSupportedEncryptionTypes. Это поле иногда называется msds-SET.

    Это обработанное значение, то есть некоторые учетные записи имеют дополнительные условия, указанные вне msDS-SupportedEncryptionTypes набора значений в базе данных AD. Например, на Windows Server 2022 и более ранних версиях msDS-SupportedEncryptionTypes всегда отображается стандарт шифрования данных (DES) и RC4, чтобы обеспечить совместимость со старыми контроллерами домена независимо от ваших параметров. Начиная с Windows Server 2025 года отображаются только AES-SHA1 и более сильные алгоритмы. Это нормально, если обработанное значение для этих субъектов безопасности не соответствует точно тому, что находится в атрибуте Active Directory.

    Это поле заполняется только во время поиска учетной записи. Подстановка учетной записи заполняет это поле для сведений об учетной записи и сведениях о службе во время события с идентификатором 4768 и выводит его в сведения о службе во время события с идентификатором 4769. Дополнительные сведения см. в разделе Поддерживаемые флаги типов шифрования.

  • Доступные ключи: ключи, доступные для учетной записи в AD. Пароль хэшируется с отображаемыми алгоритмами. Население этого поля находится под теми же ограничениями, что и msDS-SupportedEncryptionTypes. RC4 отображается независимо от использования.

• Раздел сведений о контроллере домена. В этом разделе также используются обработанные значения и приведены те же инструкции, описанные ранее.

  • MSDS-SupportedEncryptionTypes: включает msDS-SupportedEncryptionTypes для контроллера домена.

  • Ключи учетной записи. Включает ключи учетной записи для контроллера домена.

• Раздел "Сведения о сети":

  • Рекламируемые Etypes: перечисление типов шифрования, которые клиентский компьютер рекламирует как поддерживаемые для текущей операции.

• Дополнительные сведения :

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

Вы можете использовать msDS-SupportedEncryptionTypes поля или Advertized Etypes поля, чтобы определить, не поддерживает ли клиент или целевой компьютер AES-SHA1 или поддерживает только RC4.

Подробную информацию о msDS-SupportedEncryptionTypes и типах шифрования можно найти в нашей статье в блоге «Расшифровка выбора поддерживаемых типов шифрования Kerberos».

Использование PowerShell для аудита использования RC4

Просмотр журналов событий вручную для определения использования RC4 является сложной задачей. Для повышения эффективности аудита можно скачать два скрипта PowerShell:

• List-AccountKeys.ps1 для запроса журналов событий, чтобы перечислить доступные ключи шифрования для учетных записей.
• Get-KerbEncryptionUsage.ps1 для идентификации используемых типов шифрования Kerberos с параметрами фильтрации для определенных алгоритмов, таких как RC4.

Майкрософт опубликовал эти скрипты как открытый код и они доступны в репозитории Майкрософт Kerberos-Crypto GitHub. Кроме того, вы можете определить использование RC4 с помощью решения для управления сведениями о безопасности и событиями (SIEM), например Microsoft Sentinel, или встроенной в Windows пересылки, как описано в нашем блоге So, вы считаете, что готовы к применению AES для Kerberos?.

1. Скачайте два скрипта PowerShell, перечисленные в репозитории Майкрософт Kerberos-Crypto GitHub.

2. Откройте сеанс PowerShell от имени администратора контроллера домена или удаленно подключитесь с помощью командлета ВВОД-PSSession на устройстве, используемом для управления контроллерами домена.

3. Запустите скрипт List-AccountKeys.ps1 с помощью следующей команды. Этот скрипт запрашивает журнал событий безопасности и перечисляет ключи, доступные для найденных учетных записей.

   .\List-AccountKeys.ps1
   

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

   Time                  Name         Type  Keys
   ----                  ----         ----  ----
   1/21/2025 2:00:10 PM  VM01$      Machine {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}
   1/21/2025 2:00:10 PM  AdminUser     User {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}
   1/21/2025 6:50:34 PM  VM01$      Machine {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}
   1/21/2025 6:50:34 PM  AdminUser     User {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}
   1/21/2025 6:50:34 PM  VM01$      Machine {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}
   

4. Запустите скрипт Get-KerbEncryptionUsage.ps1 с помощью следующей команды. Этот скрипт запрашивает те же события, чтобы увидеть использование Kerberos, обнаруженное в среде.

   .\Get-KerbEncryptionUsage.ps1
   

   Time       : 1/21/2025 2:00:10 PM
   Requestor  : ::1
   Source     : AdminUser@CONTOSO.COM
   Target     : VM01$
   Type       : TGS
   Ticket     : AES256-SHA96
   SessionKey : AES256-SHA96
   
   Time       : 1/21/2025 2:00:10 PM
   Requestor  : 192.168.1.1
   Source     : AdminUser
   Target     : krbtgt
   Type       : AS
   Ticket     : AES256-SHA96
   SessionKey : AES256-SHA96
   

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

   .\Get-KerbEncryptionUsage.ps1 -Encryption RC4
   

Варианты обработки RC4

Если вы обнаружите, что вы по-прежнему используете RC4, существует несколько действий, которые можно сделать в зависимости от того, почему использовался RC4.

Учетная запись пользователя использует RC4, так как у нее нет ключей AES-SHA1

Если учетная запись пользователя была создана до добавления поддержки ключей AES-SHA1 в Windows Kerberos, и после этого пароль никогда не сбрасывался, в учетной записи будут отсутствовать ключи AES-SHA1. Поддержка AES-SHA1 в Windows Kerberos была добавлена в Windows Server 2003. Изменение пароля учетной записи создает эти ключи.

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

Обработанное значение msDS-SupportedEncryptionTypes не включает AES-SHA1 биты

Если обработанное msDS-SupportedEncryptionTypes значение не включает AES-SHA1, это может быть результатом горстки условий.

1. Случай: поддерживаемые типы шифрования исходного и /или целевого компьютера не включают AES-SHA1. В этом случае подтвердите конфигурацию политики и обновите ее таким образом, чтобы она включает AES-SHA1. Настройки msDS-SupportedEncryptionTypes можно просмотреть в консоли Пользователи и компьютеры Active Directory в свойствах учетной записи или с помощью PowerShell.

   • Для Пользователи и компьютеры Active Directory убедитесь, что включено представление Advanced Features, а затем откройте свойства учетной записи компьютера и перейдите к вкладке Attribute Editor. Найдите атрибут msDS-SupportedEncryptionTypes:

     Скриншот вкладки "Редактор атрибутов" в Пользователи и компьютеры Active Directory, показывающий атрибут msDS-SupportedEncryptionTypes.

   • Для PowerShell выполните следующую команду, чтобы получить msDS-SupportedEncryptionTypes атрибут. Обязательно замените <computer account name> на фактическое имя учетной записи, которую вы хотите проверить.

     $accountName = "<computer account name>"
     $parameters = @{
          Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
          Properties = "msDS-SupportedEncryptionTypes"
     }
     
     Get-ADObject @parameters | FL "DistinguishedName","msDS-SupportedEncryptionTypes","Name","ObjectClass"
     

     Ниже приведен пример выходных данных. Значение msDS-SupportedEncryptionTypes представлено в десятичной форме вместо шестнадцатеричной, что можно преобразовать с помощью таблицы, предоставленной в разделе Поля журнала событий для использования RC4.

     DistinguishedName             : CN=vm01,CN=Computers,DC=contoso,DC=com
     msDS-SupportedEncryptionTypes : 28
     Name                          : vm01
     ObjectClass                   : computer
     

   msDS-SupportedEncryptionTypes Если значение в AD для исходного и /или целевого компьютера не определено, KDC возвращается к DefaultDomainSupportedEncTypes значению, как описано во втором случае.

   Чтобы определить, какие значения лучше всего подходят для вашей среды, рекомендуется прочитать серия "Укрепление безопасности Active Directory" - Часть 4: Применение AES для Kerberos | Майкрософт Community Hub. После нахождения подходящего сочетания для вашей среды перезапустите компьютер, чтобы автоматически обновить его msDS-SupportedEncryptionTypes атрибуты в базе данных AD.

2. Случай: значение msDS-SupportedEncryptionTypes в AD для исходного компьютера не определено, и KDC переходит к значению DefaultDomainSupportedEncTypes. Этот случай более сложный и требует целостного понимания среды для решения. Значение DefaultDomainSupportedEncTypes используется для определения предполагаемых поддерживаемых типов шифрования для устройств, для которых нет значения msDS-SupportedEncryptionTypes. Существует два подхода к решению этой ситуации:

   • Определите конкретное msDS-SupportedEncryptionTypes значение в свойствах учетной записи, чтобы убедиться, что он не возвращается к значению DefaultDomainSupportedEncTypes .

   • Кроме того, задайте DefaultDomainSupportedEncTypes значение для включения AES-SHA1.

   Правильный метод зависит от вашей индивидуальной допустимости риска, так как обновление DefaultDomainSupportedEncTypes значения изменяет поведение всех учетных записей, которые не имеют значения.

Устройство не поддерживает AES-SHA1

Для устройств Windows, последней из версий Windows, которая не поддерживала AES-SHA1, была Windows Server 2003, которую больше не поддерживают. Необходимо перейти на версию Windows, поддерживающую AES-SHA1. Для учетных записей, созданных до поддержки AES-SHA1, сбросьте пароли для создания ключей шифрования более современного формата, таких как AES-SHA1. Для учетных записей, которые не поддерживают SHA-1, вручную настройте поддерживаемые типы шифрования для включения RC4.

Ограничение или отключение использования RC4

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

Чтобы ограничить или отключить использование RC4:

1. Создайте объект групповой политики (GPO) с помощью консоли управления групповыми политиками. Дополнительные сведения см. в разделе "Управление групповыми политиками".

2. Измените объект групповой политики и перейдите к Конфигурация компьютера>Политики>Параметры Windows>Параметры безопасности>Локальные политики>Параметры безопасности.

3. Найдите параметр безопасности сети политики: настройте типы шифрования, разрешенные для Kerberos. Дважды щелкните политику, чтобы открыть её свойства.

4. Укажите типы шифрования, которые требуется разрешить. Ниже приведены некоторые примеры.

   • Чтобы разрешить только AES-SHA1, установите флажки для AES128_HMAC_SHA1 и AES256_HMAC_SHA1.

   • Чтобы разрешить AES-SHA1 и RC4, установите флажки для AES128_HMAC_SHA1, AES256_HMAC_SHA1 и RC4_HMAC_MD5.

     

5. Определите область применения объекта групповой политики для соответствующих подразделений или групп, содержащих устройства, к которым нужно применить политику. Убедитесь, что он распространяется на целевые устройства, а затем перезапустите устройства, чтобы применить новые параметры.

6. После применения политики отслеживайте события проверки подлинности, чтобы не произошло непредвиденных сбоев проверки подлинности. Скрипты PowerShell, упомянутые в разделе "Использование PowerShell", можно использовать для аудита использования RC4 , чтобы убедиться, что RC4 больше не используется.

Кроме того, вы можете отключить RC4 на контроллерах домена, задав следующее значение реестра, которое разрешает только AES128_HMAC_SHA1 и AES256_HMAC_SHA1.

• Ключ: HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC.
• Имя значения: DefaultDomainSupportedEncTypes
• Тип: REG_DWORD
• Данные о значении: 0x18

Определение сбоев проверки подлинности после отключения RC4

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

• Блок сообщений сервера (SMB): когда вы пытаетесь получить доступ к общей папке с помощью SMB и RC4 является единственным значением для msDS-SupportedEncryptionTypes, сбой проверки подлинности приводит к сетевой ошибке, как показано на следующем снимке экрана.

  

• Windows инструментирование управления (WMI): при попытке создать удаленный сеанс PowerShell с помощью командлета New-PSSession, который использует WMI, и RC4 является единственным значением для msDS-SupportedEncryptionTypes, сбой проверки подлинности создает сообщение об ошибке, как показано в следующем примере.

  New-PSSession : [vm01.contoso.com] Connecting to remote server vm01.contoso.com failed with the following
  error message : WinRM cannot process the request. The following error with errorcode 0x80090342 occurred
  while using Kerberos authentication: An unknown security error occurred.
  
  Possible causes are:
     -The user name or password specified are invalid.
     -Kerberos is used when no authentication method and no user name are specified.
     -Kerberos accepts domain user names, but not local user names.
     -The Service Principal Name (SPN) for the remote computer name and port does not exist.
     -The client and remote computers are in different domains and there is no trust between the two domains.
  After checking for the above issues, try the following:
     -Check the Event Viewer for events related to authentication.
     -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration
  setting or use HTTPS transport.
  Note that computers in the TrustedHosts list might not be authenticated.
  -For more information about WinRM configuration, run the following command: winrm help config. For more
  information, see the about_Remote_Troubleshooting Help topic.
  At line:1 char:6
  + $s = New-PSSession vm01.contoso.com
  +      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession],
       PSRemotingTransportException
       + FullyQualifiedErrorId : err ,PSSessionOpenFailed
  

Чтобы выполнить любой из этих сценариев, выполните следующие действия.

1. Попытайтесь выполнить прямой запрос на получение служебного билета к этой конечной точке с помощью команды klist Windows, которая предоставляет более подробную информацию об ошибке при сбое. В следующем примере показан запрос на получение сервисного билета для сервиса HOST на vm01.contoso.com.

   Откройте сеанс PowerShell и выполните следующую команду с устройства, пытающегося пройти проверку подлинности на целевом устройстве:

   klist get HOST/vm01.contoso.com
   

   Ниже приведен пример выходных данных, показывающий, что KDC не поддерживает запрошенный тип шифрования:

   Current LogonId is 0:0xd6ed18
   Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x80090342
   
   klist failed with 0xc00002fd/-1073741059: The encryption type requested is not supported by the KDC.
   

2. Открытие идентификатора события 4769 в KDC для того же запроса позволяет увидеть код ошибки 0xE, который сопоставляется с именем KDC_ERR_ETYPE_NOTSUPP. Эта ошибка означает, что KDC не поддерживает тип шифрования. Дополнительные ошибки можно сопоставить в приложении C: Kerberos и сообщения об ошибках LDAP.

   A Kerberos service ticket was requested.
   
   Account Information:
       Account Name:       adele@CONTOSO.COM
       Account Domain:     CONTOSO.COM
       Logon GUID:     {00000000-0000-0000-0000-000000000000}
       MSDS-SupportedEncryptionTypes:  -
       Available Keys: -
   
   Service Information:
       Service Name:       HOST/vm01.contoso.com
       Service ID:     NULL SID
       MSDS-SupportedEncryptionTypes:  -
       Available Keys: -
   
   Domain Controller Information:
       MSDS-SupportedEncryptionTypes:  -
       Available Keys: -
   
   Network Information:
       Client Address:     ::ffff:192.168.1.112
       Client Port:        60090
       Advertized Etypes:  -
   
   Additional Information:
       Ticket Options:     0x40810000
       Ticket Encryption Type: 0xFFFFFFFF
       Session Encryption Type:    0x2D
       Failure Code:       0xE
       Transited Services: -
   

3. Выполните действия, описанные в разделе «Обработанное значение msDS-SupportedEncryptionTypes не содержит биты AES-SHA1», чтобы определить поддерживаемый тип шифрования для целевого устройства. В этом примере используется msDS-SupportedEncryptionTypesзначение vm01.contoso.com , указывающее, 0x4 что для учетной записи настроено только RC4.