Привет, Хабр! На связи Дмитрий Неверов, технический консультант направления тестирования внутренней инфраструктуры команды Бастиона и автор книги «Идём по киберследу».
Пентестер зачастую воспринимается как «белый маг хакер», которому дай только возможность запустить пару эксплойтов и поэксплуатировать zero-day. Однако наш опыт подсказывает, что самые неприметные и «безобидные» настройки Active Directory могут нести не меньшую опасность в руках умелого взломщика.
В этой статье я расскажу о трех интересных пентестах, выполненных нашей командой. Во всех этих кейсах использовалась моя базовая методология пентеста, которая несколько отличается от классического подхода, и применялись только этичные приемы. Итак, поехали!
Начнем с базы
В большинстве случаев пентест раскладывается на пять глобальных этапов:
разведка и сбор информации;
сканирование портов;
поиск уязвимостей;
их эксплуатация;
постэксплуатация.
Это своего рода классика, как Моцарт или Шекспир. Только к чему все усложнять, если модельным злоумышленником выступает нечистоплотный инсайдер?
В таких случаях мы просим предоставить нам доменную учетную запись без каких-либо привилегий и рабочую станцию — то, что наверняка есть у нелояльного сотрудника или подрядчика. Соответственно, нам не нужно тратить время на поиск такой учетки: сканировать порты, вычислять уязвимые сервисы и т. д. Вместо этого мы сразу начинаем рассматривать окна возможностей внутри инфраструктуры и продумывать цепочки атак.
Вкратце методологию можно описать следующей последовательностью.
Сбор и анализ информации о домене и системах. Перефразируя известную поговорку, тяжело в разведке — легко в атаке.
Расширение прав. Другими словами, это поиск и эксплуатация «низко висящих фруктов», к которым можно применить простые техники вроде Kerberoasting. Такие незамысловатые подходы открывают быстрый доступ к другим учетным данным или ресурсам. Если повезет, уже на этой стадии получается скомпрометировать домен. Например, в результате того же Kerberosting удается подобрать пароль к сервисной учетной записи, которая оказывается членом группы доменных администраторов.
Изучение и эксплуатация новых возможностей. Эта стадия наступает, если вышеописанного «блицкрига» во время расширения прав не вышло. Зато на предыдущем этапе часто удается получить доступ к хостам, права над другими объектами домена и прочее — теперь все это необходимо использовать по максимуму.
Составление плана дальнейших действий и подготовка инструментария. В некоторых случаях сначала стоит проверить цепочку атаки в лаборатории, чтобы избежать неприятных сюрпризов в боевых условиях.
Выполнение поставленных целей. План сработал, и мы можем более или менее свободно перемещаться по сети с повышенными привилегиями.
По моему опыту, возможны два пути реализации проекта.
Путь 1. Мы не видим картины целиком и передвигаемся
на ощупьот точки к точке, постепенно расширяя свои возможности. Такая «позиционная война» продолжается до захвата домена. Это связано с отсутствием исчерпывающей информации об инфраструктуре.Путь 2. Получив привилегии через «низко висящие фрукты», мы видим полный маршрут до цели и составляем пошаговый план, по которому и идем.
Конечно, это крайне упрощенная и верхнеуровневая картина. Чтобы изложить методологию в деталях, пришлось написать целую книгу, так что здесь ограничимся общим взглядом.
Три вектора атаки на Active Directory
Теперь взглянем на описанную методологию в действии на примере трех реализованных нашей командой пентестов.
Мы не станем раскрывать имена и детали — не позволяет NDA. Скажем лишь, что все три компании — крупные организации из энергетики, финансов и тяжелой промышленности. Они обладают масштабной, сложной и хорошо защищенной цифровой инфраструктурой. Да и к общению с нашим братом-пентестером и латанию дыр по итогам тестирований им не привыкать. Ну а нам, в свою очередь, не привыкать решать сложные задачи.
Вектор 1: дамп Kerberos и Pass-the-ticket вам в помощь
Итак, крупная компания, большая сеть. Из всех «плюшек» у меня на руках лишь доменная учетная запись без привилегий, доступ в корпоративную сеть через VPN и удаленное рабочее место. Модельный нарушитель — гипотетический штатный сотрудник. Обычная диспозиция. Цель — захват домена с правами администратора.
Для начала я провел разведку Active Directory и анализ собранной информации. Первый же заброс принес ценный улов — групповую политику «Безопасность и службы», которая предоставляет доменной группе AUTHENTICATED USERS полные права на службу BITS и применяется к OU MSK COMPUTERS.
В свою очередь, в OU MSK COMPUTERS мое внимание привлек компьютер SYSTEM-11, где всплыла сессия администратора домена I.IVANOV. Попался!
Все доменные компьютеры и пользователи являются членами группы AUTHENTICATED USERS. Захватив права на службу, я изменил ее таким образом, чтобы при запуске она добавила мою мастерски законспирированную УЗ PENTESTER в группу локальных администраторов. Повысив свои привилегии, я получил доступ к компьютеру SYSTEM-11 и сдампил TGT-билет Kerberos от учетки вышеупомянутого доменного администратора.
Дальше — дело техники. Точнее говоря, техники Pass-the-Ticket, при помощи которой я импортировал этот билет на своей машине и в итоге получил привилегии доменного администратора. Победа!
К слову, связка дампа билета Kerberos и техники Pass-the-Ticket — это один из моих коронных приемов для быстрого захвата учетной записи. Конечно, такое комбо работает только при условии, что билет Kerberos всё еще действителен.
Отследить и защититься от этих техник непросто, но возможно. Для этого достаточно или удалить политику, или отозвать полные права на службу, оставив только самые необходимые, например, перезапуск.
Вектор 2: пробиваемся через компьютеры со слабыми паролями
Диспозиция и цели проекта были такие же, как и в первом кейсе. Только на этот раз в инфраструктуре использовался SCCM и отсутствовала возможность создавать объекты «компьютер», так что пришлось поломать голову.
Прощупываем почву и ищем обходные пути
Я попытался построить короткий путь от стандартных доменных групп и обнаружил кое-что интересное. У группы доменных компьютеров имелись права WriteAccountRestrictions над машиной HV-01.
На ней можно было изменить атрибут msDS-AllowedToActOnBehalfOfOtherIdentity и настроить ограниченное делегирование Kerberos, что давало доступ к HV-01 с привилегиями администратора. Только вот незадача: для эксплуатации требовалась учетная запись компьютера, а возможность создавать такие объекты, как уже упоминалось, в инфраструктуре отсутствовала.
Пришлось искать обходной путь — через имеющиеся машины со слабыми паролями. Например, при создании объектов «компьютер» иногда устанавливается флаг совместимости с WindowsNT. Тогда пароль объекта совпадает с его именем, только пишется прописными буквами. Еще такое приятное совпадение случается при сбросе пароля машины в оснастке ADUC.
Здесь пригодилась испытанная временем техника поиска слабых паролей под названием Pre2k. В результате такой проверки удалось выйти на компьютер WS-543 с предсказуемым паролем и заполучить его учетные данные.
Итак, первый плацдарм был отвоеван. С помощью полученных учетных данных я настроил ограниченное делегирование Kerberos на основе ресурсов уже знакомого нам HV-01 и — бинго! — получил административный доступ к нему.
Как показало изучение информации на хосте, компьютер использовал учетную запись Network Access Account (NAA). Подобные учетки применяются на клиентских компьютерах для доступа к сетевым ресурсам SCCM, когда родная УЗ туда по каким-то причинам не пускает. Network Access Account позволяет клиентам загружать приложения и скрипты, обновлять программное обеспечение из SCCM.
Выстраиваем цепочку атаки
Дальнейшая цепочка атаки была разыграна как по нотам.
С правами локального администратора на хосте HV-01 я получил пароль от учетной записи SCCMNAA.
УЗ SCCMNAA является членом группы SERVER-ADMINS, которая, в свою очередь, имеет права локального администратора на SERVER-03.
Учетная запись SERVER-03 имеет права на репликацию учетных данных в домене.
В домене есть учетная запись SVC, которая входит в группу доменных администраторов.
С помощью учетных данных SCCMNAA из LSA я получил NTLM hash пароля компьютера SERVER-03.
Выполнив технику DCSync, я получил учетные данные для доменного администратора SVC. Домен взят!
Чтобы предотвратить такую цепочку атаки, нужно отозвать права WriteAccountRestrictions у группы доменных компьютеров и удалить объект WS-543. Или же, если хост живой, можно поменять пароль через него. Также необходимо удалить учетную запись SCCMNAA из группы SERVER-ADMINS, так как эти права избыточны и дают лазейку злоумышленникам.
Вектор 3: от погони за сессиями к подделке сертификатов
Пожалуй, эта организация оказалась самой крепкой из трех описанных. Неиспользуемые протоколы для бокового перемещения отключены, доступ по RDP ограничен через сегментацию сети. Функциональный уровень домена — 2012R2, что накладывает ограничения на возможные техники эксплуатации. Но, как говорится, защиты бояться – в пентест не ходить.
Я засучил рукава и начал изучать информацию об инфраструктуре. На общих ресурсах сервера SRV-SERVER-02 всплыл файл «Установка служб.txt», который содержал пароль от доменной учетной записи SRV-ARCHIVE. Вот и первый успех: эта УЗ имела привилегии локального администратора на сервере SRV-SERVER-02.
Здесь стоит остановиться и сделать важную ремарку: на графе этот момент не виден, так как доступ по протоколу RDP ограничен на сетевом уровне. Из клиентской сети есть доступ на некоторые терминальные серверы. Из серверного же сегмента доступны все машины.
Охота за сессиями
Я как следует прочесал групповые политики я обнаружил RDP-файл, который запускает сеанс в режиме приложения на одном из серверов. Итак, след был взят, и охота началась.
Я использовал следующий алгоритм:
Изменил содержимое этого файла таким образом, чтобы запускалось другое приложение, но при попытке запуска возникала ошибка и включался проводник.
В проводнике прописал путь до powershe_ise.exe и получил возможность выполнять команды на удаленном сервере. Теперь я мог запустить клиента удаленных рабочих столов.
Получив доступ на сервер SRV-SERVER-02 по протоколу RDP, я обнаружил сессию учетной записи DBA-ADMIN. Данная УЗ имела привилегии локального администратора на сервере SRV-SERVER-03.
Я выполнил дамп TGT-билета Kerberos для учетной записи DBA-ADMIN. Затем использовал технику Pass-the-Ticket, чтобы выполнять команды в контексте пользователя DBA-ADMIN. Напомню, что есть ограничения на применение протоколов для бокового перемещения с билетами Kerberos.
Как было сказано ранее, DBA-ADMIN имеет привилегии локального администратора на SRV-SERVER-03. Я удаленно нашел незапущенную службу и поменял параметр binaryPath на добавление своей учетной записи PENTESTER в группу локальных администраторов. После этого запустил службу.
Затем я использовал протокол RDP для получения доступа к серверу SRV-SERVER-03 с использованием своей учетной записи PENTESTER.
На сервере SRV-SERVER-03 я обнаружил сессию учетки SYS-ADMIN, которая является членом группы EXCHANGE ADMINS, входящей в группу ORGANIZATION MANAGEMENT. Она имеет привилегии GenericAll на доменную группу EXCHANGE WINDOWS PERMISSIONS. Права GenericAll позволяют добавлять членов в группу.
EXCHANGE WINDOWS PERMISSIONS имеет права на добавление пользователей в группу LAPS-RO. Уже из самого названия понятно, что последняя позволяет читать атрибут LAPS на компьютерах и серверах, где он используется. LAPS — это технология, которая устанавливает пароль от локальной учетной записи администратора на хостах. Таким образом, пресекается возможность повторного использования пароля администратора при компрометации одного из хостов.
С правами локального администратора я выполнил дамп TGT-билета Kerberos для учетной записи SYS-ADMIN. Использовав этот билет, я добавил себя в EXCHANGE WINDOWS PERMISSIONS, а затем и в LAPS-RO. Теперь я мог свободно перемещаться по серверам, где установлен LAPS. Я начал искать сессии администраторов домена там, где на них указывал BloodHound. Вот только этих сессий уже и след простыл. Охота зашла в тупик.
Эта большая печаль для пентестера: если на этапе анализа путей вы получили информацию о сессиях администраторов на хостах, не спешите праздновать победу. Когда вы доберетесь до этих хостов с необходимыми правами, сессии, скорее всего, растают, как мираж. Они появятся вновь только когда вы найдете другой маршрут.
Корневое решение проблемы
Погоня за сессиями оказалась пустой тратой времени, и я нашел альтернативное решение: нашел центр сертификации и сделал резервную копию корневого сертификата CA. Это позволило мне создавать поддельные сертификаты. Напомню, что уровень домена 2012R2, а значит, в нем нельзя получать TGT-билеты с помощью сертификатов.
Не беда! Я создал поддельный сертификат для доменного администратора ADMIN и использовал его в технике Pass-the-Cert. Это позволило мне получить доступ к контроллеру домена по протоколу LDAP от имени учетной записи ADMIN.
Следующим шагом я просто добавил себя в группу доменных администраторов и таким образом захватил домен. Задача была выполнена, и никакой охоты за сессиями не понадобилось.
Для нейтрализации такой длинной цепочки достаточно удалить файл «Установка служб.txt».
Какой можно сделать вывод из описанных сценариев? Не буду оригинален: даже самые безобидные на первый взгляд настройки — лишний файлик с паролем на шаре, предсказуемый пароль машины, чуть более широкие права на службу, чем нужно — складываются в цепочку, которая приводит к полной компрометации домена.
PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад
t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона
