Перейти к содержимому
AD Academy
Атаки на AD
Продвинутый18 мин.Обновлено: Тема 3 из 7

Shadow Credentials (msDS-KeyCredentialLink)

Запись ключевого сертификата на учётную запись жертвы — TGT через PKINIT без пароля.

Не прочитано

Что вы узнаете

  • Что такое атрибут msDS-KeyCredentialLink и зачем он существует
  • Как атакующий получает TGT через PKINIT без пароля
  • Какие Event IDs раскрывают атаку

Перед этой темой стоит прочитать:Pass-the-Hash и Pass-the-Ticket

Теория

Shadow Credentials — это техника атаки, при которой злоумышленник не крадёт пароль и не меняет его. Вместо этого он записывает в учётную запись жертвы одно значение: ключевой сертификат (Key Credential) в атрибут .

Предыстория: атрибут предназначен для Windows Hello for Business и FIDO2 — он связывает учётную запись с криптографическим ключом. Когда значение существует, можно запросить через протокол с помощью ключа — без знания пароля жертвы.

Злоумышленник записывает Key Credential в атрибут msDS-KeyCredentialLink жертвы, затем запрашивает TGT через PKINIT без пароля. Слева вертикальная цепочка атаки, справа — события обнаружения (5136, 4768) и шаги защиты.

Коротко и понятно

  • Злоумышленник не трогает пароль — записывает только Key Credential в атрибут msDS-KeyCredentialLink.
  • PKINIT позволяет получить TGT по сертификату без пароля.
  • Обнаружение: 5136 (изменение атрибута) и сразу 4768 (TGT по сертификату).
  • Без Windows Hello for Business любое изменение атрибута подозрительно.

Пример из практикиУчётная запись компьютера SRV-BACKUP$ получила новое значение в msDS-KeyCredentialLink. Через минуту — запрос 4768 с сертификатом для SRV-BACKUP$: верный признак Shadow Credentials.

Почему это опасно

  • Тихо: пароль не меняется, блокировки нет, жертва ничего не замечает.
  • Устойчиво: действителен как любой обычный TGT и может продлеваться снова и снова.
  • Цели: пользователи и компьютеры — особенно компьютеры с , где захват компьютера равен захвату домена.

Требуемое право: разрешение на запись в атрибут учётной записи/компьютера (WriteProperty или специальный ACE). В соответствующая связь называется AddKeyCredentialLink.

Практика — только в лаборатории

# 1. Добавление Key Credential с pywhisker (Linux)
pywhisker.py -d "corp.local" -u "attacker" -p "Password123" \
  --target "SRV-BACKUP$" \
  --action "add" \
  --filename backup_srv
# Вывод: backup_srv.pfx с приватным ключом
bash
# 2. То же самое из Windows с Whisker
Whisker.exe add /target:SRV-BACKUP$ /domain:corp.local /dc:dc01.corp.local
powershell
# 3. Использование PFX для получения TGT для компьютера с Rubeus
Rubeus.exe asktgt /user:SRV-BACKUP$ /certificate:backup_srv.pfx /password:pass /ptt
powershell

Теперь есть от имени SRV-BACKUP$ — и если у компьютера была , домен пал.

Обнаружение (Detection)

  • Event ID 5136 — изменение атрибута (GUID атрибута: 5b47d60f-6090-40b2-9f37-2a4de88f3063).
  • Event ID 4768 — запрос с аутентификацией по сертификату, особенно для учётных записей, не зарегистрированных в Windows Hello for Business.
  • Корреляция: новое значение в и сразу после него 4768 с сертификатом для той же учётки — сильный признак Shadow Credentials.
  • Существуют специализированные Sigma-правила — найдите «Shadow Credentials» в каталоге.

Митигация

  • Аудит: кто может писать в — в : MATCH p=()-[r:AddKeyCredentialLink]->() RETURN p.
  • Уберите лишние WriteProperty у сервисных учёток и групп.
  • Защитите Tier 0 через PAW и правила Tiering — главная цель атаки.
  • Если организация не использует Windows Hello for Business — любое изменение атрибута должно быть нулевым; полный мониторинг — лёгкая проверка.
  • Defender for Identity: есть встроенное оповещение для Shadow Credentials — включите его.

Проверь себя

Что злоумышленник фактически записывает жертве при атаке Shadow Credentials?

Какой протокол используется для запроса TGT после добавления ключа?

Какой Event ID указывает на изменение атрибута msDS-KeyCredentialLink?

Почему атака считается «тихой»?

Эта страница вам помогла?