Data/Locales/checks/ru/ADTradecraftChecks.json

{
  "_family": "ADTradecraftChecks.json",
  "ADTRADE-001": {
    "name": { "value": "Остатки cpassword из Group Policy Preferences в SYSVOL", "status": "machine-draft" },
    "description": { "value": "С 2008 по май 2014 года Group Policy Preferences позволяли администраторам распространять запланированные задачи, локальные пароли пользователей, подключённые диски и службы с помощью поля 'cpassword', зашифрованного ключом AES-256, который Microsoft публично задокументировала. Исправление в MS14-025 отключило поле cpassword в НОВЫХ настройках, но оставило существующие в SYSVOL нетронутыми. Каждое задание red-team по-прежнему находит их. Любой аутентифицированный пользователь домена может прочитать SYSVOL, взять cpassword и расшифровать его в автономном режиме. Если вы что-либо здесь обнаружите, считайте каждую раскрытую учётную запись скомпрометированной и смените её пароль", "status": "machine-draft" },
    "recommendedValue": { "value": "Ноль атрибутов cpassword в любом месте под \\\\domain\\SYSVOL\\domain\\Policies\\**\\*.xml", "status": "machine-draft" },
    "remediationSteps": { "value": "Просканируйте SYSVOL: Get-ChildItem -Path \\\\<domain>\\SYSVOL\\<domain>\\Policies -Recurse -Include *.xml | Select-String 'cpassword'. Для каждого совпадения: (1) смените пароль учётной записи, чьи учётные данные раскрыты (имя пользователя находится в том же XML), (2) проверьте журналы на предмет использования этих учётных данных с момента создания настройки, (3) удалите настройку GPP после того, как новые учётные данные установлены. В KB2962486 Microsoft приведено руководство по очистке", "status": "machine-draft" }
  },
  "ADTRADE-002": {
    "name": { "value": "Индикатор DCShadow (несанкционированные серверы раздела Configuration)", "status": "machine-draft" },
    "description": { "value": "DCShadow (Vincent LE TOUX / Benjamin Delpy, BlueHat IL 2018) регистрирует контролируемый злоумышленником узел как контроллер домена, записывая объекты nTDSDSA плюс server под CN=Sites,CN=Configuration. Поддельный контроллер домена затем используется для внедрения вредоносных данных репликации (SID history, хеши паролей), никогда не будучи настоящим контроллером домена. ПРИМЕЧАНИЕ: в давно существующих доменах несоответствующий объект server гораздо чаще является ОСТАТОЧНЫМИ МЕТАДАННЫМИ КОНТРОЛЛЕРА ДОМЕНА (контроллер домена, удалённый без 'ntdsutil metadata cleanup'), чем реальной атакой DCShadow, поэтому этому присвоен уровень High, а не Critical: изучите отметку времени whenCreated, чтобы отличить недавно созданный (подозрительный) объект от старых устаревших метаданных", "status": "machine-draft" },
    "recommendedValue": { "value": "Все объекты server под CN=Sites,CN=Configuration соответствуют реальным, проинвентаризированным контроллерам домена. Нет недавно созданных объектов server, не соответствующих известному контроллеру домена", "status": "machine-draft" },
    "remediationSteps": { "value": "Перечислите: Get-ADObject -Filter {objectClass -eq 'server'} -SearchBase \"CN=Sites,$((Get-ADRootDSE).configurationNamingContext)\" -Properties whenCreated, dNSHostName | Sort whenCreated. Сопоставьте с вашей инвентаризацией контроллеров домена (Get-ADDomainController -Filter *). Любой объект server, не соответствующий реальному контроллеру домена, особенно недавно созданный, требует немедленного реагирования на инцидент: DCShadow является примитивом уровня захвата домена. Отслеживайте события 5137 / 5141 на контейнере schema как сигнал обнаружения", "status": "machine-draft" }
  },
  "ADTRADE-003": {
    "name": { "value": "Устаревшие ключи восстановления BitLocker", "status": "machine-draft" },
    "description": { "value": "Ключи восстановления BitLocker хранятся в AD как дочерние объекты msFVE-RecoveryInformation того компьютера, который выполнил их резервное копирование. Когда компьютер выводится из эксплуатации, но объект AD остаётся висящим, ключи восстановления остаются доступными для запроса любому, у кого есть права восстановления BitLocker, обычно более широкой группе, чем 'Tier-0'. Устаревшие ключи означают, что утилизированные диски можно расшифровать, если их восстановить у переработчика или из мусорного бака", "status": "machine-draft" },
    "recommendedValue": { "value": "Все объекты msFVE-RecoveryInformation принадлежат компьютерам, активным в последние 90 дней. Нет ключей, осиротевших к отключённым или недавно изменённым, а затем ставшим устаревшими учётным записям компьютеров", "status": "machine-draft" },
    "remediationSteps": { "value": "Перечислите информацию о восстановлении: Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} -Properties whenCreated. Для каждого объекта поднимитесь к родительскому объекту компьютера и проверьте его lastLogonTimestamp / Enabled. Для компьютеров, неактивных более 90 дней: подтвердите, что диск был очищен или уничтожен, затем удалите объект компьютера AD (что каскадно удалит информацию о восстановлении). Для компьютеров, активно используемых, но с очень старыми ключами восстановления: выполните ротацию через Backup-BitLockerKeyProtector. Убедитесь, что членство в группе восстановления BitLocker строго ограничено", "status": "machine-draft" }
  },
  "ADTRADE-004": {
    "name": { "value": "Гигиена политики репликации паролей RODC", "status": "machine-draft" },
    "description": { "value": "Контроллеры домена только для чтения (RODC) кэшируют пароли субъектов, перечисленных в их политике репликации паролей (PRP). Если учётная запись Tier-0 (Domain Admin, Enterprise Admin, krbtgt) достижима через PRP RODC, напрямую или через вложенность групп, компрометация RODC компрометирует эти учётные записи. Стандартная группа 'Denied RODC Password Replication Group' должна явно содержать DA / EA / SA / Schema Admins / krbtgt; некоторые среды настраивают политику и случайно удаляют эти запреты", "status": "machine-draft" },
    "recommendedValue": { "value": "Все RODC в домене имеют политику репликации паролей, где Domain Admins, Enterprise Admins, Schema Admins, krbtgt и Account Operators являются членами стороны Deny. Ни одна высокопривилегированная учётная запись не является членом стороны Allow", "status": "machine-draft" },
    "remediationSteps": { "value": "Для каждого RODC: Get-ADDomainController -Filter {IsReadOnly -eq $true} | ForEach-Object { Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Allowed; Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Denied }. Убедитесь, что список Denied содержит встроенную группу 'Denied RODC Password Replication Group'. Если в вашей среде нет RODC, эта проверка неприменима, PASS. В руководстве Microsoft по планированию RODC есть каноничный шаблон PRP", "status": "machine-draft" }
  },
  "ADTRADE-005": {
    "name": { "value": "Ротация ключа учётной записи компьютера Entra Seamless SSO (AZUREADSSOACC$)", "status": "machine-draft" },
    "description": { "value": "Когда для гибридной идентификации включён Entra (Azure AD) Seamless Single Sign-On, AD создаёт учётную запись компьютера с именем AZUREADSSOACC$. Её пароль представляет собой общий ключ Kerberos, который Entra использует для проверки билетов SSO. Microsoft документирует, что этот ключ НЕ меняется автоматически: администраторы должны выполнять его ротацию. Если злоумышленник извлечёт ключ AZUREADSSOACC$ (это обычный хеш NT, читаемый через DCSync или с контроллера домена), он может подделывать серебряные билеты Kerberos для службы Azure AD и аутентифицироваться как ЛЮБОЙ синхронизированный гибридный пользователь без дальнейшего взаимодействия, пока ключ остаётся действительным. Ключ, не менявшийся более 90 дней, значительно расширяет это окно", "status": "machine-draft" },
    "recommendedValue": { "value": "Ключ Kerberos AZUREADSSOACC$ меняется не реже чем каждые 90 дней (выполняйте ротацию дважды за раз, чтобы аннулировать предыдущий ключ)", "status": "machine-draft" },
    "remediationSteps": { "value": "Выполните ротацию ключа Seamless SSO на машине с модулем Entra Connect / Azure AD: Import-Module 'C:\\Program Files\\Microsoft Azure Active Directory Connect\\AzureADSSO.psd1'; New-AzureADSSOAuthenticationContext; Update-AzureADSSOForest. Выполните ротацию дважды (учётная запись хранит текущий плюс предыдущий ключ) и планируйте её на регулярной основе. Если Seamless SSO больше не используется, отключите его и удалите объект AZUREADSSOACC$", "status": "machine-draft" }
  },
  "ADTRADE-006": {
    "name": { "value": "Теневые учётные данные (msDS-KeyCredentialLink) на привилегированных субъектах", "status": "machine-draft" },
    "description": { "value": "Атрибут msDS-KeyCredentialLink содержит открытые ключи, используемые для входа через Windows Hello for Business / беспарольный PKINIT. Злоумышленник с доступом на запись к этому атрибуту на цели может добавить СВОЮ ПАРУ ключей (Whisker / pyWhisker) и затем запросить TGT Kerberos как эта учётная запись, используя соответствующий закрытый ключ: скрытная техника закрепления и подделки, известная как 'теневые учётные данные'. Любые неожиданные учётные данные ключа на объекте Tier-0 (администратор домена, контроллер домена или любая учётная запись с adminCount=1) следует рассматривать как потенциальный бэкдор, пока не доказано, что это законная регистрация WHfB", "status": "machine-draft" },
    "recommendedValue": { "value": "Нет неопознанных значений msDS-KeyCredentialLink на привилегированных субъектах / субъектах Tier-0; каждый ключ соответствует известной регистрации WHfB/беспарольного входа", "status": "machine-draft" },
    "remediationSteps": { "value": "Для каждого отмеченного субъекта проверьте учётные данные ключей (Get-ADObject -Properties msDS-KeyCredentialLink или командлет DSInternals Get-ADKeyCredential) и сопоставьте каждый ключ устройства с законной регистрацией Windows Hello for Business. Удалите любую запись, которую вы не можете отнести к санкционированной регистрации. Ограничьте круг тех, кто может записывать msDS-KeyCredentialLink (проведите аудит Key Admins / Enterprise Key Admins и DACL подразделений/объектов, предоставляющих это право на запись). Сбросьте затронутые учётные записи при подозрении на компрометацию", "status": "machine-draft" }
  },
  "ADTRADE-007": {
    "name": { "value": "Поверхность повышения привилегий миграции dMSA BadSuccessor", "status": "machine-draft" },
    "description": { "value": "В Windows Server 2025 появились делегированные управляемые учётные записи служб (dMSA, класс объекта msDS-DelegatedManagedServiceAccount) с функцией миграции: dMSA можно пометить как замещающую существующую учётную запись, после чего она наследует привилегии и ключи Kerberos этой учётной записи. Раскрытая в 2024 году техника 'BadSuccessor' злоупотребляет этим: субъект, который может лишь СОЗДАТЬ dMSA в подразделении (CreateChild на классе dMSA или широкие права записи/GenericAll над подразделением), может создать её, указать на привилегированную учётную запись и унаследовать её ключи, повышая привилегии до этой учётной записи, никогда не обладая правами над ней напрямую. Эта проверка инвентаризирует подразделения, где субъект не уровня Tier-0 обладает такой возможностью", "status": "machine-draft" },
    "recommendedValue": { "value": "Ни один субъект не уровня Tier-0 не может создавать или записывать делегированную MSA (msDS-DelegatedManagedServiceAccount) ни в одном подразделении", "status": "machine-draft" },
    "remediationSteps": { "value": "На каждом отмеченном подразделении удалите CreateChild (для класса msDS-DelegatedManagedServiceAccount), GenericAll, WriteDacl и WriteOwner у неадминистративных субъектов. Проведите широкий аудит делегированных разрешений подразделений: те же записи ACE, что делают возможным BadSuccessor, также позволяют другие злоупотребления созданием объектов. До установки исправления/смягчения отслеживайте создание объектов msDS-DelegatedManagedServiceAccount (события 4662/5137). Эта проверка ПРОПУСКАЕТСЯ на лесах, схема которых предшествует Server 2025", "status": "machine-draft" }
  },
  "ADTRADE-008": {
    "name": { "value": "Членство в группах Key Admins / Enterprise Key Admins", "status": "machine-draft" },
    "description": { "value": "Группам Key Admins (доменный RID 526) и Enterprise Key Admins (RID 527) предоставлено право записывать атрибут msDS-KeyCredentialLink в масштабах домена/леса. Это делает любого члена доменным примитивом теневых учётных данных: член может подсаживать учётные данные ключей на любую учётную запись и аутентифицироваться как она через PKINIT. Эти группы поставляются ПУСТЫМИ и должны оставаться пустыми, если только конкретный рабочий процесс подготовки ключей Windows Hello for Business явно их не требует. Любой член является путём повышения привилегий, который должен быть обоснован", "status": "machine-draft" },
    "recommendedValue": { "value": "Группы Key Admins и Enterprise Key Admins пусты (нет постоянных членов)", "status": "machine-draft" },
    "remediationSteps": { "value": "Проверьте каждого члена Key Admins и Enterprise Key Admins. Удалите любую учётную запись, не имеющую задокументированной постоянной потребности в подготовке ключей Windows Hello for Business. Если подготовка ключей WHfB требует делегированных прав, ограничьте их выделенной учётной записью службы с максимально узкими разрешениями, а не членством в этих доменных группах. Рассматривайте неожиданных членов как потенциальный механизм закрепления", "status": "machine-draft" }
  },
  "ADTRADE-009": {
    "name": { "value": "Членство в группе Cert Publishers", "status": "machine-draft" },
    "description": { "value": "Члены группы Cert Publishers (доменный RID 517) имеют право публиковать сертификаты в хранилище NTAuth и в объекты пользователей/компьютеров. По умолчанию группа содержит только учётные записи компьютеров Enterprise CA. Пользовательская учётная запись или учётная запись службы, помещённая в эту группу, получает возможность влиять на то, какие сертификаты доверяются для аутентификации, что является ступенькой в нескольких путях повышения привилегий AD CS (атаки класса ESC) и может обеспечить подделку на основе сертификатов. Членство учётных записей компьютеров (сами узлы CA) ожидаемо; любой член, не являющийся компьютером, является находкой", "status": "machine-draft" },
    "recommendedValue": { "value": "Cert Publishers содержит только учётные записи компьютеров Enterprise CA, никаких пользовательских учётных записей или учётных записей служб", "status": "machine-draft" },
    "remediationSteps": { "value": "Удалите любую пользовательскую учётную запись или учётную запись службы из группы Cert Publishers; там должны находиться только учётные записи компьютеров Enterprise CA. Проверьте содержимое хранилища NTAuth (certutil -viewstore -enterprise NTAuth) на предмет неожиданных сертификатов CA. Проведите широкую защиту AD CS: аудит разрешений на регистрацию шаблонов сертификатов и поверхности неправильных настроек ESC1-ESC8", "status": "machine-draft" }
  },
  "ADTRADE-010": {
    "name": { "value": "Состояние gMSA и раскрытие пароля групповых управляемых учётных записей служб", "status": "machine-draft" },
    "description": { "value": "Групповые управляемые учётные записи служб (gMSA) содержат 240-битные пароли, которые AD генерирует и меняет автоматически, устраняя Kerberoasting слабых паролей учётных записей служб и ручной труд по ротации. Две задачи по состоянию: (1) используются ли gMSA вообще для идентификаторов служб и (2) кто уполномочен извлекать управляемый пароль, что контролируется дескриптором безопасности msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword). Если этот дескриптор предоставляет доступ широкому субъекту (Everyone, Authenticated Users, Domain Users) или непривилегированному субъекту, этот субъект может восстановить пароль gMSA в открытом виде (например, GMSAPasswordReader) и полностью выдать себя за службу", "status": "machine-draft" },
    "recommendedValue": { "value": "Идентификаторы служб работают как gMSA; msDS-GroupMSAMembership ограничен только конкретными узлами, которые должны выполнять службу (нет широких или непривилегированных субъектов)", "status": "machine-draft" },
    "remediationSteps": { "value": "Для каждой gMSA задайте PrincipalsAllowedToRetrieveManagedPassword точным учётным записям компьютеров (или строго ограниченной группе), которые выполняют службу: Set-ADServiceAccount -Identity <gmsa> -PrincipalsAllowedToRetrieveManagedPassword <hosts>. Удалите Everyone / Authenticated Users / Domain Users из этого списка. Там, где учётные записи служб по-прежнему используют статические пароли пользовательских учётных записей, переведите их на gMSA для получения автоматической ротации и устойчивости к Kerberoasting", "status": "machine-draft" }
  }
}