HimeraSearchDB
Carding_EbayThief
triada
CrackerTuch
BMIX
issn24

НОВОСТИ Разбираем атаки на Kerberos с помощью Rubeus. Часть 1

Alvaros
Онлайн

Alvaros

.
Регистрация
14.05.16
Сообщения
21.452
Реакции
101
Репутация
204
pfkm2fgsvrwvp3sqor3uvth_icu.png


You must be registered for see links
— это инструмент, совместимый с С# версии 3.0 (.NET 3.5), предназначенный для проведения атак на компоненты Kerberos на уровне трафика и хоста. Может успешно работать как с внешней машины (хостовой), так и внутри доменной сети (клиентского доменного хоста).

С помощью данного инструмента можно реализовать следующие атаки:

  1. Kerberos User Enumeration and Brute Force
  2. Kerberoast
  3. AS-REP Roasting
  4. Silver Ticket
  5. Golden Ticket
  6. Overpass The Hash/Pass The Key (PTK)
  7. Pass-The-Ticket / Ticket Dump
  8. Unconstrained Delegation
  9. Constrained Delegation

О том, почему возможны эти атаки, а также о механизмах их реализации и принципах работы Kerberos написано уже достаточное количество публикаций (например, коллеги из “Инфосистемы Джет” писали
You must be registered for see links
), поэтому в данной статье я сделаю упор на то, как реализовать первые пять атак из списка выше с помощью Rubeus (остальные четыре — в следующей части).

А пока немного терминологии:

Kerberos — сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними.
Клиентский компьютер — компьютер, которому требуется доступ к службе, поддерживающей аутентификацию Kerberos.
Сервисный компьютер — сервер/компьютер, на котором размещается «Сервис», поддерживающий аутентификацию Kerberos KDC (Центр распространения ключей).
SPN (имя участника службы) — это имя службы, связанной с учетной записью пользователя, в которой будет работать служба. Эта привязка выполняется в LDAP путем установки значения для атрибута «servicePrincipalName». SPN имеет формат вида SERVICE/hostname
Ticket (билет) — зашифрованный пакет данных, который выдается доверенным центром аутентификации KDC.

Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности, KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT).

fowxdwifnsgzwkpttx-1-vwfwuy.png


В дальнейшем, при обращении к отдельным ресурсам сети пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS).

vmpdbsidtign-yhqlt23cleigru.png

i0xiol2itzyngglfrvmtsvopale.png

Итак, смоделируем ситуацию, когда нам удалось получить доступ к домену AD, но по каким-либо причинам нет возможности для тестирования использовать собственную хостовую ОС (Kali, BackTrack и т.п.), поэтому тестировать наш домен MEOW.LOCAL мы будем изнутри — с доменной клиентской машины Windows 10. Использовать будем уже скомпилированную версию Rubeus из состава
You must be registered for see links
.

С помощью VMware создадим виртуальные машины на операционных системах Windows Server 2016 (контроллер домена), Windows 10 (доменная машина), развернем домен meow.local и присвоим статичные IP-адреса машинам:

— контроллер домена DC-16 (192.168.0.201);
— доменная машина Barscomp (192.168.0.202).

В Active Directory создадим доменных пользователей ADadmin, Barsik, User1, User2.

В принципе, на этом пока всё, давайте проверим.

KERBEROS BRUTE-FORCE


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

Следующая команда выполнит перебор пользователей по словарю users.txt и выполнит брутфорс паролей по словарю pass.txt

_hulmqybmusinhiyfrsxo27lafs.jpeg


В результате мы получили существующих пользователей и пароли, так же Rubeus любезно получил тикеты (TGT) и сохранил их на нашем компьютере. Перейдём к более продвинутым техникам атак на протокол Kerberos.

KERBEROASTING


Для проведения данной атаки необходимо создать учётную запись — у нас это будет iis_svc, отвечающая за взаимодействие с IIS-сервисом на сервере DC-16.meow.local (наш КД). Ей нужно присвоить ей атрибут SPN. 


  • Cоздаём сервисную учетную запись IIS
    New-ADUser -Name "IIS Service Account” `
    -SamAccountName iis_svc -UserPrincipalName [email protected] `
    -ServicePrincipalNames "HTTP/dc-16.meow.local” `
    -AccountPassword (convertto-securestring "S3rv1ce!" -asplaintext -force) `
    -PasswordNeverExpires $True `
    -PassThru | Enable-ADAccount
  • Hастроим конфигурацию IIS сервера
    Import-Module WebAdministration
  • Удаляем дефолтный вебсайт
    Remove-Item 'IIS:\Sites\Default Web Site' -Confirm:$false -Recurse
  • Cоздаём новый пул приложений с использованием учётной записи IIS
    $appPool = New-WebAppPool -Name dc-16.meow.local
    $appPool.processModel.identityType = 3
    $appPool.processModel.userName = “MEOW\iis_svc”
    $appPool.processModel.password = “S3rv1ce!”
    $appPool | Set-Item

  • Создаём новый вебсайт и включаем проверку подлинности Windows
    $WebSite = New-Website -Name dc-16.meow.local -PhysicalPath “C:\InetPub\WWWRoot” -ApplicationPool ($appPool.Name) -HostHeader dc-16.meow.local

    Set-WebConfigurationProperty -Filter /system.WebServer/security/authentication/anonymousAuthentication `
    -Name enabled -Value $false -Location $Fqdn

    Set-WebConfigurationProperty -Filter /system.WebServer/security/authentication/windowsAuthentication `
    -Name enabled -Value $true -Location $Fqdn

    Set-WebConfigurationProperty -Filter /system.webServer/security/authentication/windowsAuthentication `
    -Name useAppPoolCredentials -Value $true -Location $Fqdn


Следующая команда выведет список всех SPN’ов в домене
uwvzozgym8xxbyg-qakskfdxpam.jpeg


Как видно из скриншота, пользователь iis_svc (IIS Service Account) имеет SPN HTTP/dc-16.meow.local.

Продолжаем наш эксперимент. Что же происходит, когда пользователь со своей доменной машины обращается к вебсайту IIS сервиса:
— на доменной машине Barscomp запустим захват пакетов в Wireshark и через любой бразуер обратимся по адресу dc-16.meow.local;
— так как мы включили проверку подлинности Windows, то появится такое окно, где требуется ввести данные доменной учётной записи пользователя:

azesonfejfp9hfkxw_1yxhsferm.jpeg


— проходим аутентификацию, попадаем на вебсайт, но это нас не интересует, посмотрим, что за это время успел поймать Wireshark:

qgjgyvk9fxfatgwnbxehid6cf-8.jpeg


— первые два пакета AS-REQ и AS-REP являются способом, которым пользователь аутентифицируется с помощью KDC и извлекает TGT. Наибольший интерес представляют пакеты TGS-REQ и TGS-REP.

Рассмотрим содержимое пакета TGS-REQ:

ukq80vijqp6as0yfcyihgwllzey.jpeg


Здесь мы видим, что посылается запрос для имени участника службы (SPN) HTTP/dc-16.meow.local, связанного с учетной записью iis_svc.

В пакете TGS-REP возвращается билет TGS, который зашифрован с использованием пароля учетной записи meow.local\iis_svc. Соответственно, расшифровав данный билет, мы получим пароль сервисной учетной записи. Попробуем на практике.

jf3enrjrbhe8wyraeujyusuwikw.jpeg


Давайте воспользуемся инструментом, которому посвящена данная статья (если кто забыл — это Rubeus).

Итак, для проведения этой атаки используется «экшн» kerberoast, добавив флаг /stats, мы можем выполнить проверку на наличие пользователей с установленным SPN, уязвимых к атаке данного типа.

ntzdzcprbcmsqfs8miabdolinni.jpeg


Теперь произведем атаку на учётную запись, использующую RC4 шифрование, а затем установим для неё AES-128/AES-256 шифрование и попробуем ещё раз.



Итак, под учетной записью meow.local/Barsik (шифрование RC4) запускаем рубеус командой Rubeus.exe kerberoast:

1s-nqsr8qz--mmbi5iqfk8sjfve.jpeg


В результате мы получили хэш TGS (зашифрованный по алгоритму RC4) для учетной записи iis_svc.

Включим AES шифрование:

dqgzcenkq6p0hvw6wydjfycntsq.jpeg


Повторим:

bmanb95duxz0vrvp14mgssgxrpe.jpeg


Мы также получили TGS, только зашифрованный по алгоритму AES-128/AES-256

Оба эти хэша ломаются одинаково хорошо утилитами hashcat и JohnTheRipper

0ud8xoox4d8_ff7dnoalnb2v8b0.jpeg


0l4oh2gyw0t45uuuis2v8hs4jt4.jpeg


wem9kzug-8l53z4iiczaopkoxps.jpeg


Обратите внимание на тип хэша в данной атаке — Kerberos 5 TGS-REP etype 23

ASREPRoast


Для начала немного поговорим о предварительной аутентификации Kerberos. При обычных операциях в среде Windows Kerberos клиент отправляет в KDC запрос (пакет AS-REQ), содержащий временную метку (timestamp), зашифрованную хэшем пароля пользователя. Эта структура в пакете называется PA-ENC-TIMESTAMP и встроена в PA-DATA (данные предварительной авторизации), более подробно описано на странице
You must be registered for see links
и используется в Kerberos версии 5. Затем KDC расшифровывает временную метку, что бы проверить валидность пользователя, отправившего AS-REQ, а затем возвращает AS-REP и продолжает обычные процедуры аутентификации.

В AS-REP сам билет зашифрован сервисным ключом (в данном случае хэшем krbtgt), «зашифрованная часть» подписывается паролем пользователя, для которого мы отправляем AS-REQ.

В современных средах Windows все учетные записи пользователей требуют предварительной проверки подлинности Kerberos, но, что интересно, по умолчанию, Windows сначала пытается выполнить обмен AS-REQ/AS-REP без предварительной проверки подлинности (не отправляя зашифрованную метку времени):

wsc22xub9mp16cyum52to1hrgz8.jpeg


Это происходит из-за того, что клиент заранее не знает поддерживаемые типы шифрования (etypes), подробно описано в разделе
You must be registered for see links
.

Данная атака возможна, если учетной записи пользователя разрешена аутентификация без предварительной проверки подлинности Kerberos. Мы можем отправить AS-REQ для пользователя, у которого отключена предварительная проверка подлинности, и сразу получить AS-REP хэш, расшифровав который получим пароль пользователя.

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

xub8atdtwdi3s03kjpxq-w_lhwo.jpeg


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

yzph8l-sv7ruwqbirsmkespq1zk.jpeg


ctq0en2mkios84xhbo96vwgb9am.jpeg


Есть! Мы получили AS-REP хэш, сломаем его через hashcat и JTR.

eo5j3sfwxpdlxbbvprp-doayopa.jpeg


3cwis602ejvxehuemdyasr1spes.jpeg


so-dtwweegupqmizryk2730q59e.jpeg


Обратите внимание, здесь я указываю хэшкату тип хэша 18200 (в Kerberoast был 13100), который означает что ломать надо хэш Kerberos 5 AS-REP etype 23.

SILVER TICKET


Суть данной атаки в том, чтобы подделать TGS для скомпрометированной службы и получить максимальные права на этом сервисе, при этом KDC здесь не принимает никакого участия. Для реализации данной атаки необходимо знать NTLM-хэш пароля учетной службы (в нашем примере meow.local\iis_svc из примера с Kerberoasting). Атакующий может создать блок данных, соответствующий TGT-REP, вот упрощенный пример поддельного билета:

realm : meow.local
sname : http\dc-16.meow.local
enc-part : Зашифровано скомпрометированным NTLM-хэшем
key : 0x379DC4FA152BA1C Произвольный ключ сеанса
crealm : meow.local
cname : BadCat
authtime : 2050/01/01 00:00:00 Срок действия билета
authorization-data : «поддельный PAC, с необходимыми правами доступа к сервису»​

Стоит учитывать, что PAC имеет двойную подпись: первая подпись использует секрет учетной записи службы, а вторая использует секрет контроллера домена (секрет учетной записи krbtgt). Атакующий знает только секрет учетной записи службы, поэтому вторую подпись он подделать не может. Однако когда сервис получает этот билет, он обычно проверяет только первую подпись. Это связано с тем, что некоторым учетным записям служб предоставлена привилегия действовать как часть операционной системы (подробнее
You must be registered for see links
). Для таких служб Silver Ticket будет работать, даже если пароль krbtgt будет изменен, но пока не изменится пароль учетной записи самой службы.

Непосредственно с помощью Rubeus создать Silver Ticket не получится, но это можно сделать с помощью
You must be registered for see links
.

7zhxav_mb_hdomxand1fbyal8mc.jpeg


SID — идентификатор пользователя (получен командой «whoami /user»);
Domain — наш домен meow.local;
ID — желаемый идентификатор безопасности (1001 в нашем случае соответствует для учетной записи Adadmin, имеющей права администратора);
Target — атакуемый хост с запущенным скомпрометированным сервисом;
Service — атакуемый сервис (у нас HTTP);
RC4 — NTLM-хэш пароля учётной записи meow.local\iis_svc (учетная запись службы);
User — имя пользователя (может быть любым).
Mimikatz сохранит поддельный TGS в файл. Далее, командой klist.exe проверим наличие действующих билетов, с помощью Rubeus подгрузим поддельный билет (в примере файл silver.kirbi) в текущую сессию пользователя, ещё раз проверим klist и наконец отправим веб-запрос на dc-16.meow.local.

ssvyftp6kewq-a1ply0ubfk9yhg.jpeg


Авторизация прошла успешно и мы получили двухсотый ответ, заглянем в логи на dc-16.

sfoligwzkv4zhnsd-irbminviao.jpeg


Видим, что был произведен вход в систему под учетной записью BadCat (в домене такой учетки нет) с привилегиями доменного администратора Adadmin, о чем свидетельствует ИД безопасности, а точнее последние 4 цифры – 1001.

GOLDEN TICKET


Эта атака напоминает «серебряный билет», только атакующий создает TGT с использованием NTLM-хэша учетной записи krbtgt. Преимущества «золотого билета» в том, что он даёт возможность получения доступа к любому сервису или любому хосту внутри домена.

NTLM-хэш учетной записи krbtgt можно получить из процесса lsass, файла NTDS.dit или через атаку DCSync, но потребуются административные права.

С помощью Mimikatz создадим Golden ticket:

tzh5rhwcwxm-jq2_e0izzrg_tci.jpeg


Здесь я использовал идентификатор безопасности (id) 500, чтобы получить права администратора системы (можно указать любой другой), NTLM-хэш (rc4) учетной записи krbtgt и пользователя VeryBadCat.

Проверим список действующих тикетов в сессии, добавим «золотой», проверим и подключимся к КД, используя
You must be registered for see links
.

tqacjmpvk4bhsqzc1oztoubffqc.jpeg


yzxws2y96agtt2ewcgr-seutj08.jpeg


gzythavrcl-trjrq7s1wsr6lnno.jpeg


С таким билетом открыты любые доменные «двери» =)

На этом заканчиваю первую часть статьи, посвященную инструменту Rubeus. В целом, инструмент с большинством задач справляется и определенно найдет своих поклонников, но лично мне всё-таки удобнее использовать утилиты из состава Impacket, хотя пополнить свой «арсенал» и уметь им грамотно работать никогда лишним не будет =).

А в следующей части разберем ещё несколько техник захвата и продвижения по AD с помощью Rubeus.

Всем добра, не болейте)
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу