Rubeus — это инструмент, совместимый с С# версии 3.0 (.NET 3.5), предназначенный для проведения атак на компоненты Kerberos на уровне трафика и хоста. Может успешно работать как с внешней машины (хостовой), так и внутри доменной сети (клиентского доменного хоста).
С помощью данного инструмента можно реализовать следующие атаки:
- Kerberos User Enumeration and Brute Force
- Kerberoast
- AS-REP Roasting
- Silver Ticket
- Golden Ticket
- Overpass The Hash/Pass The Key (PTK)
- Pass-The-Ticket / Ticket Dump
- Unconstrained Delegation
- Constrained Delegation
О том, почему возможны эти атаки, а также о механизмах их реализации и принципах работы Kerberos написано уже достаточное количество публикаций (например, коллеги из “Инфосистемы Джет” писали хороший материал с разбором), поэтому в данной статье я сделаю упор на то, как реализовать первые пять атак из списка выше с помощью Rubeus (остальные четыре — в следующей части).
А пока немного терминологии:
Kerberos — сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними.
Клиентский компьютер — компьютер, которому требуется доступ к службе, поддерживающей аутентификацию Kerberos.
Сервисный компьютер — сервер/компьютер, на котором размещается «Сервис», поддерживающий аутентификацию Kerberos KDC (Центр распространения ключей).
SPN (имя участника службы) — это имя службы, связанной с учетной записью пользователя, в которой будет работать служба. Эта привязка выполняется в LDAP путем установки значения для атрибута «servicePrincipalName». SPN имеет формат вида SERVICE/hostname
Ticket (билет) — зашифрованный пакет данных, который выдается доверенным центром аутентификации KDC.
Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности, KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT).
В дальнейшем, при обращении к отдельным ресурсам сети пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS).
Итак, смоделируем ситуацию, когда нам удалось получить доступ к домену AD, но по каким-либо причинам нет возможности для тестирования использовать собственную хостовую ОС (Kali, BackTrack и т.п.), поэтому тестировать наш домен MEOW.LOCAL мы будем изнутри — с доменной клиентской машины Windows 10. Использовать будем уже скомпилированную версию Rubeus из состава Ghostpack-CompiledBinaries.
С помощью 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
В результате мы получили существующих пользователей и пароли, так же Rubeus любезно получил тикеты (TGT) и сохранил их на нашем компьютере. Перейдём к более продвинутым техникам атак на протокол Kerberos.
KERBEROASTING
Для проведения данной атаки необходимо создать учётную запись — у нас это будет
iis_svc, отвечающая за взаимодействие с IIS-сервисом на сервере DC-16.meow.local (наш КД). Ей нужно присвоить ей атрибут SPN. ?- Cоздаём сервисную учетную запись IIS:
New-ADUser -Name "IIS Service Account” ` -SamAccountName iis_svc -UserPrincipalName iis_svc@meow.local ` -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’ов в домене:
Как видно из скриншота, пользователь iis_svc (IIS Service Account) имеет SPN HTTP/dc-16.meow.local.
Продолжаем наш эксперимент. Что же происходит, когда пользователь со своей доменной машины обращается к вебсайту IIS сервиса:
- на доменной машине Barscomp запустим захват пакетов в Wireshark и через любой бразуер обратимся по адресу dc-16.meow.local;
- так как мы включили проверку подлинности Windows, то появится такое окно, где требуется ввести данные доменной учётной записи пользователя:
- проходим аутентификацию, попадаем на вебсайт, но это нас не интересует, посмотрим, что за это время успел поймать Wireshark:
- первые два пакета AS-REQ и AS-REP являются способом, которым пользователь аутентифицируется с помощью KDC и извлекает TGT. Наибольший интерес представляют пакеты TGS-REQ и TGS-REP.
Рассмотрим содержимое пакета TGS-REQ:
Здесь мы видим, что посылается запрос для имени участника службы (SPN) HTTP/dc-16.meow.local, связанного с учетной записью iis_svc.
В пакете TGS-REP возвращается билет TGS, который зашифрован с использованием пароля учетной записи meow.local\iis_svc. Соответственно, расшифровав данный билет, мы получим пароль сервисной учетной записи. Попробуем на практике.
Давайте воспользуемся инструментом, которому посвящена данная статья (если кто забыл — это Rubeus).
Итак, для проведения этой атаки используется «экшн» kerberoast, добавив флаг /stats, мы можем выполнить проверку на наличие пользователей с установленным SPN, уязвимых к атаке данного типа.
Теперь произведем атаку на учётную запись, использующую RC4 шифрование, а затем установим для неё AES-128/AES-256 шифрование и попробуем ещё раз.??
Итак, под учетной записью meow.local/Barsik (шифрование RC4) запускаем рубеус командой
Rubeus.exe kerberoast:
В результате мы получили хэш TGS (зашифрованный по алгоритму RC4) для учетной записи
iis_svc.Включим AES шифрование:
Повторим:
Мы также получили TGS, только зашифрованный по алгоритму
AES-128/AES-256
Оба эти хэша ломаются одинаково хорошо утилитами hashcat и JohnTheRipper.
Обратите внимание на тип хэша в данной атаке — Kerberos 5 TGS-REP etype 23.
ASREPRoast
Для начала немного поговорим о предварительной аутентификации Kerberos. При обычных операциях в среде Windows Kerberos клиент отправляет в KDC запрос (пакет AS-REQ), содержащий временную метку (timestamp), зашифрованную хэшем пароля пользователя. Эта структура в пакете называется PA-ENC-TIMESTAMP и встроена в PA-DATA (данные предварительной авторизации), более подробно описано на странице 60 RFC4120 и используется в Kerberos версии 5. Затем KDC расшифровывает временную метку, что бы проверить валидность пользователя, отправившего AS-REQ, а затем возвращает AS-REP и продолжает обычные процедуры аутентификации.
В AS-REP сам билет зашифрован сервисным ключом (в данном случае хэшем krbtgt), «зашифрованная часть» подписывается паролем пользователя, для которого мы отправляем AS-REQ.
В современных средах Windows все учетные записи пользователей требуют предварительной проверки подлинности Kerberos, но, что интересно, по умолчанию, Windows сначала пытается выполнить обмен AS-REQ/AS-REP без предварительной проверки подлинности (не отправляя зашифрованную метку времени):
Это происходит из-за того, что клиент заранее не знает поддерживаемые типы шифрования (etypes), подробно описано в разделе 2.2 RFC6113.
Данная атака возможна, если учетной записи пользователя разрешена аутентификация без предварительной проверки подлинности Kerberos. Мы можем отправить AS-REQ для пользователя, у которого отключена предварительная проверка подлинности, и сразу получить AS-REP хэш, расшифровав который получим пароль пользователя.
Здесь важно то, что атакующему для проведения данной атаки, в отличии от Kerberoasting, пароль учетной записи не требуется, только валидные имена пользователей домена.
Пользователи без предварительной аутентификации не найдены, поставим соответствующую галочку в настройках учетной записи пользователя и повторим атаку:
Есть! Мы получили AS-REP хэш, сломаем его через hashcat и JTR.
Обратите внимание, здесь я указываю хэшкату тип хэша 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). Атакующий знает только секрет учетной записи службы, поэтому вторую подпись он подделать не может. Однако когда сервис получает этот билет, он обычно проверяет только первую подпись. Это связано с тем, что некоторым учетным записям служб предоставлена привилегия действовать как часть операционной системы (подробнее тут ). Для таких служб Silver Ticket будет работать, даже если пароль krbtgt будет изменен, но пока не изменится пароль учетной записи самой службы.
Непосредственно с помощью Rubeus создать Silver Ticket не получится, но это можно сделать с помощью Mimikatz.
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.
Авторизация прошла успешно и мы получили двухсотый ответ, заглянем в логи на dc-16.
Видим, что был произведен вход в систему под учетной записью BadCat (в домене такой учетки нет) с привилегиями доменного администратора Adadmin, о чем свидетельствует ИД безопасности, а точнее последние 4 цифры – 1001.
GOLDEN TICKET
Эта атака напоминает «серебряный билет», только атакующий создает TGT с использованием NTLM-хэша учетной записи krbtgt. Преимущества «золотого билета» в том, что он даёт возможность получения доступа к любому сервису или любому хосту внутри домена.
NTLM-хэш учетной записи krbtgt можно получить из процесса lsass, файла NTDS.dit или через атаку DCSync, но потребуются административные права.
С помощью Mimikatz создадим Golden ticket:
Здесь я использовал идентификатор безопасности (id) 500, чтобы получить права администратора системы (можно указать любой другой), NTLM-хэш (rc4) учетной записи krbtgt и пользователя VeryBadCat.
Проверим список действующих тикетов в сессии, добавим «золотой», проверим и подключимся к КД, используя PsExec.
С таким билетом открыты любые доменные «двери».
На этом заканчиваю первую часть статьи, посвященную инструменту Rubeus. В целом, инструмент с большинством задач справляется и определенно найдет своих поклонников, но лично мне всё-таки удобнее использовать утилиты из состава Impacket, хотя пополнить свой «арсенал» и уметь им грамотно работать никогда лишним не будет.
А в следующей части разберем ещё несколько техник захвата и продвижения по AD с помощью Rubeus.
Всем добра, не болейте!