Добрый день. Пытаюсь разобратся с атакой 'shadow credentials'. Подскажите, пожалуйста, правильно ли я понимаю последовательность действий и то, что происходит в процессе?
1)Атакующий генерирует пару открытый-закрытый ключ.
2)Атакующий находит учетную запись, в атрибут msDS-KeyCredentialLink которой у него есть права на запись, или делает relay на ldap c целью записи в этот атрибут. В итоге атакующий записывает свой открытый ключ в атрибут msDS-KeyCredentialLink атакуемой учетной записи.
3)AS_REQ. Атакующий отправляет серверу аутентификации текущую метку времени, подписанную сгенерированным на шаге1 закрытым ключом, а также сгенерированный на шаге1 открытый ключ и принципал атакуемой учетной записи.
4)Сервер аутентификации сверяет присланный атакующим открытый ключ с атрибутом msDS-KeyCredentialLink учетной записи, принципал которой прислал атакующий.
5)AS_REP. Сервер аутентификации проверяет подпись метки времени, присланной атакующим, за счет присланного им открытого ключа. Если метка времени совпадает, то сервер аутентификации выдает атакующему ответ, который условно можно разделить на две части:
-TGT на имя атакуемой учетной записи, зашифрованный с использованием секрета kdc. При этом PAC в tgt на этот раз содержит NT хэш атакуемой учетной записи, зашифрованный на промежуточный симметричный ключ(далее as-rep ключ). NT хэш включается в PAC для совместимости с протоколом NTLM. Атакующий не может расшифровать TGT, так как он зашифрован с использованием секрета kdc.
-Вторую часть ответа сервер аутентификации шифрует уже с использованием открытого ключа атакующего(того, что он ранее записал в атрибут msDS-KeyCredentialLink). Эта часть ответа состоит из: Сессионного ключа для общения с контроллером домена, зашифрованного на as-rep ключ, метки времени, срока жизни TGT, открытого ключа сервера аутентификации и сертификата для его проверки, as-rep ключа, подписанного закрытым ключом сервера аутентификации.
6)Получив ответ, атакующий с использованием закрытого ключа(который является парой к открытому ключу ранее записанному атакующим в атрибут msDS-KeyCredentialLink атакуемой учетной записи) расшифровывает вторую часть принятого ответа. В расшифрованной части атакующий проверяет сертификат открытого ключа сервера аутентификации(за счет открытого ключа центра сертификации). Далее при помощи полученного открытого ключа сервера аутентификации атакующий проверяет подпись AS-REP ключа. С использованием AS-REP ключа атакующий расшифровывает сессионный ключ для общения с контроллером домена.
7)Финальной частью атаки shadow credentials является атака unPACtheHash. Смысл атаки в том, что атакующий может осуществить PKINIT + U2U запрос на аутентификацию к самому себе(в данном случае от имени атакуемой учетной записи) и таким образом получить NT-хеш атакуемой учетной записи, на имя которой он уже ранее получил TGT. Как уже было описано выше, в PKINIT, для совместимости с ntlm сервер аутентификации включает в PAC NT-хэш пароля клиента, а при получени запроса на TGS копирует PAC, извлеченный из TGT, в TGS билет. Атака построена на том, что при U2U аутентификации для шифрования TGS-билета вместо секрета сервиса применяется кратковременный сессионный ключ(ключ для общения с kdc) пользователя, от имени которого работает сервис. Но так как при этой атаке мы запрашиваем аутентификацию к самому себе(правда от имени атакуемой учетной записи), то нам уже известен сессионный ключ, а значит мы можем расшифровать этим ключом TGS. Расшифровав TGS, мы можем извлечь содержащийся в нем PAC и расшифровать его с использованием также известного нам AS_REP ключа. Расшифровав PAC, мы получаем доступ к NT хэшу атакуемой учетной записи.
1)Атакующий генерирует пару открытый-закрытый ключ.
2)Атакующий находит учетную запись, в атрибут msDS-KeyCredentialLink которой у него есть права на запись, или делает relay на ldap c целью записи в этот атрибут. В итоге атакующий записывает свой открытый ключ в атрибут msDS-KeyCredentialLink атакуемой учетной записи.
3)AS_REQ. Атакующий отправляет серверу аутентификации текущую метку времени, подписанную сгенерированным на шаге1 закрытым ключом, а также сгенерированный на шаге1 открытый ключ и принципал атакуемой учетной записи.
4)Сервер аутентификации сверяет присланный атакующим открытый ключ с атрибутом msDS-KeyCredentialLink учетной записи, принципал которой прислал атакующий.
5)AS_REP. Сервер аутентификации проверяет подпись метки времени, присланной атакующим, за счет присланного им открытого ключа. Если метка времени совпадает, то сервер аутентификации выдает атакующему ответ, который условно можно разделить на две части:
-TGT на имя атакуемой учетной записи, зашифрованный с использованием секрета kdc. При этом PAC в tgt на этот раз содержит NT хэш атакуемой учетной записи, зашифрованный на промежуточный симметричный ключ(далее as-rep ключ). NT хэш включается в PAC для совместимости с протоколом NTLM. Атакующий не может расшифровать TGT, так как он зашифрован с использованием секрета kdc.
-Вторую часть ответа сервер аутентификации шифрует уже с использованием открытого ключа атакующего(того, что он ранее записал в атрибут msDS-KeyCredentialLink). Эта часть ответа состоит из: Сессионного ключа для общения с контроллером домена, зашифрованного на as-rep ключ, метки времени, срока жизни TGT, открытого ключа сервера аутентификации и сертификата для его проверки, as-rep ключа, подписанного закрытым ключом сервера аутентификации.
6)Получив ответ, атакующий с использованием закрытого ключа(который является парой к открытому ключу ранее записанному атакующим в атрибут msDS-KeyCredentialLink атакуемой учетной записи) расшифровывает вторую часть принятого ответа. В расшифрованной части атакующий проверяет сертификат открытого ключа сервера аутентификации(за счет открытого ключа центра сертификации). Далее при помощи полученного открытого ключа сервера аутентификации атакующий проверяет подпись AS-REP ключа. С использованием AS-REP ключа атакующий расшифровывает сессионный ключ для общения с контроллером домена.
7)Финальной частью атаки shadow credentials является атака unPACtheHash. Смысл атаки в том, что атакующий может осуществить PKINIT + U2U запрос на аутентификацию к самому себе(в данном случае от имени атакуемой учетной записи) и таким образом получить NT-хеш атакуемой учетной записи, на имя которой он уже ранее получил TGT. Как уже было описано выше, в PKINIT, для совместимости с ntlm сервер аутентификации включает в PAC NT-хэш пароля клиента, а при получени запроса на TGS копирует PAC, извлеченный из TGT, в TGS билет. Атака построена на том, что при U2U аутентификации для шифрования TGS-билета вместо секрета сервиса применяется кратковременный сессионный ключ(ключ для общения с kdc) пользователя, от имени которого работает сервис. Но так как при этой атаке мы запрашиваем аутентификацию к самому себе(правда от имени атакуемой учетной записи), то нам уже известен сессионный ключ, а значит мы можем расшифровать этим ключом TGS. Расшифровав TGS, мы можем извлечь содержащийся в нем PAC и расшифровать его с использованием также известного нам AS_REP ключа. Расшифровав PAC, мы получаем доступ к NT хэшу атакуемой учетной записи.
