В предыдущих статьях (Часть 1, Часть 2) мы поговорили о том, как может действовать Внешний нарушитель (пентестер за пределами организации) и Гость (пентестер имеет только доступ в сеть) при проведении пентеста. Также начали рассматривать действия Внутреннего нарушителя (пентестер имеет доступ с правами доменного пользователя) в контексте анализа трафика. Сегодня мы продолжим рассмотрение векторов атак для данной роли и также поговорим о том как можно использовать социальную инженерию при пентесте и совмещать ее с техническими методами.
Итак, мы проводим пентест от имени Внутреннего нарушителя. Это значит, что нам предоставили штатный компьютер, входящий в домен, с правами доменного пользователя, без локального админа, с установленными штатными средствами защиты и необходимым ПО. Конечно возможна ситуация, когда на этом компьютере будут права локального админа для данного пользователя, но как мы увидим дальше это может стать довольно серьезной дырой в безопасности.
Также иногда предоставляют типовой АРМ в виде виртуальной машины, что может немного упростить получения прав админа. Во времена пандемийных ограничений также иногда предоставляли удаленный доступ по VPN для внутреннего пентеста. По сути это тоже внутренний нарушитель, получивший доступ во внутреннюю сеть извне.
А точно ли все закрыто...
Начать стоит с проверки возможностей загрузки ОС с внешних дисков DVD/USB. Подключаем флешку с загружаемой ОС и перезагружаемся. Если админы не совсем лентяи, у вас загрузится штатная винда. Если совсем, то вы уже практически локальный админ.
Нам необходимо поменять последовательность загрузки устройств.
Для этого надо прервать загрузку (нужные клавиши можно легко нагуглить для конкретных моделей оборудования) и войти в BIOS/UEFI или в меню загрузки (Boot Menu). Вполне возможно вам повезет и доступ будет не запаролен. Если повезло, то находим последовательность загрузки и выставляем DVD или USB носитель перед жестким диском.
Если пароль есть, то можно попытаться погуглить заводские пароли для данного оборудования. Может админы все-таки лентяи.
Также возможна ситуация, когда вы поменяли последовательность загрузки, а с альтернативного источника загрузиться все-равно не получается. В таком случае в BIOS/UEFI необходимо посмотреть параметр Secure Boot или его аналог. Эта опция определяет, какие ОС можно загружать на данной машине. Так например, мне пришлось бороться с ноутбуком HP на котором можно было загружать только подписанные Майкрософт или HP операционные системы. То есть Windows загрузить можно было, а вот Kali Linux уже нет. Необходимо указать Secure Boot загружать любые ОС.
Вариант, когда все плохо, и мы не смогли загрузиться со своего носителя, будет рассмотрен чуть дальше, а сейчас рассмотрим хороший вариант – мы можем загрузиться со своего носителя.
Конечно, на вкус и цвет все фломастеры разные (с) но при работе с виндой я бы рекомендовал использовать портативную сборку WinPE 10-8 Sergei Strelec (https://sergeistrelec.name/).
Это та же Windows, но в формате Live CD/USB и имеющая на борту много полезных утилит, например встроенный редактор реестра и несколько утилит для сброса пароля в хостовой ОС. После загрузки образ автоматически монтирует хостовую ОС и нам становится доступен для правки реестр ОС. Можно править ветки связанные с автозагрузкой, запуском и отключением сервисов и многим другим.
Самый простой путь для получения прав локального админа это смена пароля. Однако, можно немного усложнить задачу, экспортировав хэши для последующей расшифровки.
Для этого в том же Windows PE запустим Сброс паролей -> PCUnlocker, далее выбираем Backup Windows Registry.
На выходе мы получим файлы SAM и SYSTEM, которые затем уже можно подвергнуть расшифровке, например с помощью утилиты ophtcrack (https://ophcrack.sourceforge.io/download.php). Версия 3.8.0 поддерживает Windows 10.
Зачем вообще пытаться расшифровать пароль, который и так можно сбросить? Есть ненулевая вероятность, что на других машинах пароль локального админа будет либо такой же, либо будет строиться по какому-то простому правилу, например несколько фиксированных символов и два последних символа в имени узла.
Так или иначе, но результатом всех наших действий должно стать получение локального админа на предоставленной пентестеру машине.
Ну а если все плохо...
Итак, с загрузкой у нас ничего не получилось (тему с выпаиванием батарейки оставим теоретикам) и захватить права локального админа мы пока не смогли. Но у нас есть штатная учетка. Зайдем в систему под ней.
Настоящий ИТ-шник все-таки должен быть ленив, иначе он не будет ничего успевать. В частности, админам необходимо практически постоянно разворачивать ОС на компьютерах новых сотрудников. Утомительная и продолжительная работа. Корпорация Майкрософт предлагает использовать функцию Sysprep для подготовки образа ОС к установке и автоматического развертывания. Удобный инструмент но после установки Sysprep оставляет некоторые файлы.
Например, вот эти:
c:\sysprep.inf
c:\sysprep\sysprep.xml
%WINDIR%\Panther\Unattend\Unattended.xml
%WINDIR%\Panther\Unattended.xml
В этих файлах содержатся ответы на вопросы, которые задает мастер установки при развертывании винды. Как вы можете догадаться в числе прочего там будет и пароль локального админа. Он может выглядеть как-то так:
Дальше уже можно прибегнуть к расшифровке с помощью того же ophtcrack, John The Ripper и т.д.
Групповые политики и сбежавший пароль
Каждый сисадмин сети под управление Active Directory хорошо знаком с Групповыми политиками (Group Policy). С помощью этого инструмента можно автоматизировать многие рутинные действия. Например, автоматически менять пароли все того же локального админа на большом количестве узлов. Инструмент GPP (Group Policy Preferences) позволяет создавать локальных пользователей, настраивать и изменять их учетки, а также сохранять учетные данные в нескольких файлах сценариев:
· Groups.xml
· Services.xml
· Printers.xml
· Drives.xml
· DataSources.xml.
Эти файлы отвечают за работу с дисками, принтерами, сервисами и т.д. При создании GPP файлы могут храниться в SYSVOL и если в них содержатся пароли пользователей, они будут зашифрованы AES 256. Казалось бы, все защищенно. Но еще в 2012 году Майкрософт опубликовала этот пароль https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gppref/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be?redirectedfrom=MSDN
Так что достаточно поискать в папке SYSVOL эти XML файлы и в них строку cpassword.
Далее в Kali Linux запускаем утилиту gpp-decrypt и передаем ей значение cpassword:
Поднимаем привилегии
Если с SYSVOL тоже по тем или иным причинам не повезло, то помимо расшифровки пароля админа можно еще попробовать поднять привилегии текущего пользователя.
Для этого необходимо проверить наличие в реестре следующих веток:
HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated
HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated
Значение AlwaysInstallElevated должно быть равно 1. Параметр „AlwaysInstallElevated“ разрешает непривилегированным пользователям устанавливать .msi файлы из-под NT AUTHORITY\SYSTEM. По сути, это некий аналог SUID бита в Linux. Установочный пакет будучи запущен под непривилегированным пользователем выполняет установочные действия под системной учеткой.
Для эксплуатации нам потребуется Kali Linux и Metasploit. С помощью msfvenom готовим специальный MSI файл который извлекается и выполняется установщиком с привилегиями системы.
В качестве начинки можно использовать команду для добавления пользователя в локальные админы:
А можно прокинуть реверсивный шел, хотя это уже относится больше к внешнему нарушителю:
Для бесшумного запуска наших установочных файлов на целевой машине воспользуемся опцией /quiet
msiexec /quiet /qn /i setup.msi
msiexec /quiet /qn /i reverse.msi
И мы снова получили админа.
Пентестер тоже ленив
Завершая тему получения локального админа предлагаю рассмотреть скрипт, который поищет различные уязвимости в системе, позволяющие поднять привилегии. Windows-privesc-check (https://github.com/pentestmonkey/windows-privesc-check). Скрипт имеется в виде Powershell, Python или exe-файла, вероятно, на случай если двумя предыдущими интерпретаторами воспользоваться нельзя.
В процессе своей работы Privesc соберет информацию о системе:
Тот самый Mimikatz
На этом шаге считаем, что мы уже получили локального админа. При этом, можно вспомнить материалы предыдущей статьи, связанные с перехватом передаваемого трафика. Возможно, удалось расшифровать какие-то хэши и получить учетные данные. Если среди них оказались учетки с правами админов это тоже хорошо. Ну и сканирование файловых шар на наличие каких-либо учетных данных тоже могло дать результат.
В общем, теперь у нас уже должен некоторый набор учетных данных, под которыми мы можем заходить на разные узлы, в том числе серваки по RDP. Если у этих учеток нет админских прав, то можно попробовать выполнить действия приведенные выше. Если есть, то мы можем добыть еще больше учеток с помощью Mimikatz.
Mimikatz — это приложение с открытым исходным кодом, которое позволяет пользователям просматривать и сохранять учетные данные аутентификации. В отсутствии антивируса (такое бывает и не так редко, особенно на серваках) Mimikatz можно просто запустить с правами локального админа:
С помощью пары команд получаем хэши все пользователей, которые логинились в данной ОС с момента последней перезагрузки.
Но если на машине стоит антивирь/EDR/что-то еще такой фокус либо вообще не получится, либо будет быстро обнаружен, так как мы производим инъекцию кода в процесс lsass.exe, а это очень подозрительная активность.
Тогда можно пойти другим путем – сделать дамп памяти процесса lsass.exe с интересующей машины и затем на своем компе уже спокойно извлечь из файла хэши. Для этого в Task Manager выбираем Create Dump File для нужного процесса.
Далее в Mimikatz подключаем этот файл:
Получив еще больше хэшей мы можем попробовать их расшифровать, тем самым завладев еще некоторым количеством учетных данных. И вполне возможно, что среди них окажется аккаунт с правами доменного админа. Если же нет, можно попытаться с помощью новых учеток получить доступ на другие узлы, где, проделав приведенные выше действия также получить локального админа и собрать новые хэши.
Для ускорения процесса сбора аккаунтов можно воспользоваться методами социальной инженерии, о которых речь пойдет далее.
Обманываем пользователей
Тема социальной инженерии за последнее время несколько перегрета, ее используют все кому не лень от спамеров, предлагающих перейти по подозрительным ссылкам, до звонящих из “служб безопасности” с целью узнать данные вашей карты. Поэтому рассчитывать на излишнее доверие пользователей не стоит.
При заключении договора о проведении тестирования на проникновение всегда отдельно оговаривается часть, касающаяся социнженерии, а именно, составляется список тех сотрудников, которые будут подвергнуты проверке. Как правило это специалисты и начальники отделов, из разных подразделений, от бухгалтеров, до АСУшников и админов.
Типовой сценарий проверки: создается копия легального веб ресурса компании, например Outlook Web Access на котором логируются все учетные данные, введеные пользователями. Имя этого ресурса максимально похоже на легальный ресурс. Отличаться может похожей буквой (l вместо I, 0 вместо O И т.д.), доменом (com, net вместо ru). Затем юзерам рассылается письмо с адреса внутри компании, с подписью в формате, принятом в компании, с просьбой помочь потестировать новый веб ресурс, перейти по ссылке и ввести свои учетные данные. В среднем половина участников рассылке поддастся на провокацию.
В качестве инструмента, позволяющего реализовать подобную атаку можно использовать Social-Engineer Toolkit (SET) из состава Kali Linux. SET имеет ряд векторов атак по запросу, которые позволяют вам быстро сделать правдоподобную атаку.
Для клонирования сайта выбираем пункт 1.
Далее указываем Website Attack Vectors.
Далее выбираем пункт 3.
И для клонирования сайта нам нужен пункт 2, Site Cloner.
После этого необходимо указать, где будет располагаться клонированный сайт:
И какой собственно сайт клонировать:
Немного о не совсем стандартном применении социальной инженерии совместно с Mimikatz. Можно расшарить папку на узле, где у нас есть локальный админ и средствами социнженерии заманить в эту папку других пользователей, желательно админов (например "у меня что-то не работает, логи я выложил на шаре"). А потом с помощью Mimikatz посмотреть сохранившиеся в памяти хэши паролей. Возможно, вам повезет перехватить пароль доменного админа.
Заключение
В этом цикле статей мы рассмотрели лишь малую часть
возможных векторов атак при проведении пентеста. Для каждой из моделей
нарушителя возможны десятки различных сценариев развития атак и если хакеру
достаточно для взлома успешно проэксплуатировать один вектор, то пентестеру
недостаточно “как-то взломать” ему надо указать все уязвимые места в
тестируемой сети для того, чтобы впоследствии построенная система защиты была
наиболее эффективна.
В конце статьи напомню о том, что 19 января в OTUS пройдет бесплатный урок, где рассмотрим один из базовых инструментов для обеспечения безопасности Kubernetes-кластеров - сервисная сетка (service mesh) на базе opensource инструмента Istio. Рассмотрим, из каких компонентов состоит сервисная сетка, как устроен инструмент Istio (control и data plane, sidecar, envoy), как осуществляется и внедряется термин наблюдаемости (observability). Во время технического демо мы продемонстрируем как развернуть k3d-кластер, проинсталировать Istio и добавить в сервисную сетку свое первое приложение, развернутое в Kubernetes-кластере.