Pass-the-Hash умер. Да здравствует долгоиграющий Pass-the-Hash

Автор: harmj0y

Возможно, вы уже слышали о недавнем патче от компании Microsoft, которая якобы оставила нас, пентестеров, «без работы». Атаки типа «pass-the-hash» больше не актуальны, а злоумышленники больше не могут «зайти с фланга». В Microsoft, наконец, защитили механизмы аутентификации. Хотя, подождите:

Рисунок 1: Получение удаленного доступа при помощи утилиты pth-winexe

Вышеупомянутый трюк проведен на полностью пропатченной системе Windows 7, находящейся в полностью пропатченном домене на Windows 2012. Итак, что же на самом деле произошло? О каких изменениях заявляет Microsoft, что на самом деле сделано, и какие выводы из всего этого следуют? KB2871997 – бюллетень безопасности и соответствующая статья из базы знаний, имеющие непосредственное отношение к нашему вопросу.

Помимо портирования некоторых защитных механизмов из Windows 8.1, которые слегка затрудняют извлечение учетных записей в чистом виде из LSASS, бюллетень содержит это «угрожающее» (как минимум для пентестеров) заявление: «Изменение включает в себя: предотвращения сетевого и удаленного соединения с машиной, подключенной к домену, при помощи локальных учетных записей…». На первый взгляд, все схемы атак, используемых нами столь долгое время, теперь работать не будут. Изначально в Microsoft выпустили бюллетень с заголовком «Обновление, устраняющее уязвимость Pass-The-Hash». Однако столько громкое заявление было быстро изменено на «Обновление, улучшающее защиту и управление учетными данными».

Рисунок 2: Первоначальная и последующая версии заголовка бюллетеня безопасности от Microsoft (источник)

Действительно, Microsoft усложнила нам жизнь: теперь из-под аккаунта локального администратора больше нельзя запускать код при помощи WMI или PSEXEC, нельзя использовать schtasks или at, и даже просматривать открытые общие ресурсы (shares) на целевой машине. Исключение тому - административный аккаунт RID 500, даже если он был переименован. Несмотря на то, что во время установки Windows 7 по умолчанию эта учетная запись деактивирована и пользователю предлагается завести другую учетную запись, ранее многие компании использовали другой подход, в результате чего можно найти множество машин с этой учетной записью. Некоторые организации используют RID 500 по причинам обратной совместимости, некоторые при помощи нее сканируют уязвимости без использования учетных записей администратора домена.

Если домен развернут только на основе современных ОС семейства Windows и готовых коммерческих продуктов (которые способны давать результаты с учетом современных реалий) и сконфигурирован правильно (без использования «быстрых» методов), то это уже огромный шаг вперед. В компании Microsoft, наконец, начали задумываться о внутренних проблемах, связанных с безопасностью, и за это они заслуживают бурных аплодисментов. Однако подавляющее большинство организаций представляют собой адскую смесь, состоящую из некомпетентности в вопросах безопасности, старых серверов, разнородных клиентов, ленивых админов, специалистов, сосредоточенных на обратной совместимости, и бизнес единиц, сфокусированных на юзабилити.

Короче говоря, подобные административные аккаунты используются везде и всюду. Кроме того, изменения не коснулись Windows 2003 (которая, несомненно, будет использоваться значительно дольше, чем Windows XP). Как итог, хеши аккаунтов домена, имеющих административный доступ к какой-либо машине, вполне могут использоваться для кражи важной информации. Также аккаунты локальных администраторов все еще используются для работы со службой Windows Remote Management (если она включена). Некоторые организации оставляют WinRM работающей «в качестве артефакта» после развертывания всех необходимых компонент. Кроме того, для создания удаленной сессии PowerShell, могут использовать как учетные записи в чистом виде, так и хеши посредством некоторых модулей Metasploit.

Однако допустим, что все настроено правильно. Стандартный административный аккаунта деактивирован, и вы смогли лишь достать хеш другого локального администратора. Рассмотрим, какие возможности у нас остались для использования полученного хеша. Допустим, ваш любимый сканнер нашел несколько хостов, где используется один и тот же аккаунт, как показано в примере ниже.

Рисунок 3: Поиск учетной записи и хеша

Рисунок 4: Поиск машин, где используется найденная учетная запись

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

Рисунок 5: Попытка воспользоваться psexec

Рисунок 6: Попытка удаленно выполнить команду

Рисунок 7: Попытка посмотреть содержимое общего ресурса

На Рисунке 6 в примере с «pth-winexe» показывается различие между использованием некорректной учетной записи (NT_STATUS_LOGON_FAILURE) и результатами работы нового патча. Если вдруг у вас получилось достать пароли в чистом виде через Group Policy Preferences, получилось использовать Mimikatz или удалось взломать NTLM-хеши, вы можете подключиться к удаленной машине при помощи следующей команды: rdesktop -u mike -p password 192.168.52.151. Однако будьте осторожны, поскольку если вы попытаетесь подсоединиться к системе с Windows 7, а в домене уже залогинен пользователь, система тактично спросит, желает ли он разрешить удаленную сессию. Так что лучше выполнять эти процедуры в послерабочее время. Интересное примечание: если у вас есть хеши для пользователя домена, и вы имеете дело с пропатченной системой, то, возможно, у вас получится выполнить атаку «pass-the-hash» при помощи rdp. Фанаты Kali linux написали отличную статью на эту тему.

Полученные учетные административные учетные записий (RID 500 или любой другой аккаунт домена, наделенный правами администратора) все еще можно использовать для установки агентов и выполнения кода, используя Metasploit или passing-the-hash toolkit. К сожалению, даже при том, что вы получили доступ к учетным записям целевой машины и Active Directory, вы не можете получить список локальных администраторов при помощи WMI.

Рисунок 8: Попытка получить список локальных администраторов

Однако еще не все потеряно. Средства совместимости с предыдущими версиями (вечная проблема компании Microsoft) вновь приходят нам на помощь. Используя Active Directory Service Interfaces [ADSI] WinNT provider, можно получить информацию с машин, прикрепленных к домену, даже при помощи непривилегированной учетной записи, включая информацию о локальных группах и их членах (с SID’ами и прочим). Если у нас налажена сессия Powershell с целевой машиной в Windows-домене, можно попытаться получить список локальных групп примерно так:

• $computer = [ADSI]“WinNT://WINDOWS2,computer”
• $computer.psbase.children | where { $_.psbase.schemaClassName -eq ‘group’ } | foreach { ($_.name)[0]}

Рисунок 9: Перечень локальных групп

Не сильно сложно получить содержимое конкретной группы:

• $members = @($([ADSI]“WinNT://WINDOWS2/Administrators”).psbase.Invoke(“Members”))
• $members | foreach { $_.GetType().InvokeMember(“ADspath”, ‘GetProperty’, $null, $_, $null) }

Рисунок 10: Содержимое группы Administrators

Эти функции интегрированы в Veil-PowerView (Get-NetLocalGroups и Get-NetLocalGroup соответственно):

Рисунок 11: Перечень групп, полученное при помощи функции Get-NetLocalGroups

Рисунок 12: Содержимое группы, полученное при помощи функции Get-NetLocalGroup

Еще одна полезная функция - Invoke-EnumerateLocalAdmins, получающая список хостов внутри домена, а затем выводящая членов определенной группы (по умолчанию из группы ‘Administrators’) для каждого хоста. Можно задать перечень хостов и задержку между запросами к каждому хосту (при необходимости результаты работы можно выгрузить в csv файл):

Рисунок 13: Информация о членах определенной группы по каждому хосту

На выходе получается удобно отсортированная информация с именем сервера, учетной записью, информаций о том, является ли имя группой или нет, деактивирован ли аккаунт, и полный SID, связанный с учетной записью. SID встроенной учетной записи администратора оканчивается на *-500:

Рисунок 14: Информация об учетных записях в разрезе по хостам

Повторимся еще раз, вся эта информация достается из-под непривилегированной учетной записи домена. Если у вас есть хеш, и вы хотите получить ту же самую информацию без использования PowerShell, при помощи скриптов smb-enum-groups.nse и smb-enum-users.nse под Nmap можно добиться тех же самых результатов, используя валидную учетную запись (даже содержимое группы локальных администраторов) вместе с паролем или хешем.

• nmap -p U:137,T:139 –script-args ‘smbuser=mike,smbhash=8846f7eaee8fb117ad06bdd830b7586c’ –script=smb-enum-groups –script=smb-enum-users 192.168.52.151

Рисунок 15: Получение информации и группах и членах при помощи скриптов под Nmap

Если захотите использовать учетную запись домена, установите соответствующие флаги: –script-args ‘smbdomain=DOMAIN,smbuser=USER,smbpass/smbhash=X’. При этом вы сможете получить перечень аккаунтов типа RID 500, информацию об их доступности и содержимое группы локальных администраторов. Если в результате выполнения команды какой-то пользователь не появился в списке smb-enum-users (в данном случае ‘Jason’), скорее всего это учетная запись домена. Эта информация может помочь вам сориентироваться, какие учетные записи окажутся полезными, и на какие системы/аккаунты необходимо обратить внимание в первую очередь.

Если у вас появились какие-либо вопросы относительно PowerView, вы можете задать вопросы на официальной странице на Github, найти меня в Твиттере, написать на почту или пообщаться со мной в сети Freenode на каналах #veil, #armitage, или #pssec (там я присутствую под ником harmj0y).