Побег из песочницы и захват леса — реальный сценарий взлома корпоративной сети
Пришло время рассказать о еще одном векторе атак на внутренние сети компаний. На этот раз речь пойдет о ситуации, в которой у меня не было прямого доступа к компьютеру, а хосты оказались неуязвимы к популярным атакам. И все же несколько мелких ошибок администраторов привели к тому, что защита рассыпалась. Итак, читайте под катом пошаговый разбор взлома корпоративной сети и кое-какие рекомендации по защите.
Начну с диспозиции. В Бастион обратилась одна известная компания. Вы знаете это название, но мне даже вспоминать его нежелательно, не то, что упоминать здесь. Юристы запретили, так что обойдемся без конкретики. Помимо прочего, у нас заказали пентест внутренней инфраструктуры, приближенный к реальной атаке, то есть с минимумом информации и без содействия со стороны заказчика.
Перед стартом проекта детально оговариваются условия: гарантии, ограничения, пределы и объем работ. В этот раз заказчик поручил проверить три домена и выдал учетную запись с типовыми, популярными и распространенными правами. Админы компании выбрали для доступа к инфраструктуре терминальную ферму от Citrix. Это довольно популярное решение для создания виртуальных рабочих мест — фактически Remote Desktop-сервис, работающий через браузер. Заходишь на адрес на корпоративном домене, вводишь логин и пароль, и открывается интерфейс для запуска неких заранее выбранных приложений.
Мне достался удаленный доступ к 1С, консоли Active Directory, паре CRM-систем и приложению ServiceDesk. Не все эти приложения работали одинаково быстро и стабильно, но это проблемы пользователей. Для хакера важно другое: три из них работали через Internet Explorer.
Виртуальный рабочий стол и доступные мне терминальные приложения
Браузер внутри браузера, сон во сне, матрешка — как ни назови, суть в том, что эти приложения представляют собой трансляцию окна Internet Explorer, открытого где-то внутри инфраструктуры компании. Это отличный шанс сбежать из песочницы Citrix в полноценную операционную систему.
Сделать это совсем несложно, но было время, когда подобные трюки срабатывали даже с банкоматами. Подошло бы любое из приложений на базе Internet Explorer, но я выбрал сеанс, создаваемый при запуске ServiceDesk. Он просто открывался быстрее других.
Если вызвать окно браузера «File→Save as…», появится стандартное окно сохранения, где отображается путь к внутренней директории. Думаю, вы уже догадались, что если вписать туда имя исполняемого файла, то он запустится. Таким образом я запустил powershell.exe и explorer.exe на терминальном сервере где-то в инфраструктуре компании. Теперь нужно было понять, куда я попал.
Изучаю инфраструктуру и считаю учетки
Со временем выяснилось, что при каждом входе в Citrix пользователя случайным образом забрасывает на один из шести терминальных серверов. Впрочем, исследованию это не мешало. Разработчики Citrix сконфигурировали все так, чтобы пользовательские данные сохранялись и подгружались вне зависимости от того, какой сервер обслуживает сессию на этот раз.
Что касается сетевой инфраструктуры, то она оказалась довольно обычной — три взаимосвязанных домена с практически 100% доверительными отношениями. Инвентаризация показала следующую картину:
в первом домене — около 3000 активных учетных записей пользователей и 2500 активных учетных записей компьютеров,
во втором — 2900 активных записей пользователей и 800 компьютеров,
третий включал всего 60 пользовательских и 30 компьютерных записей.
Доверительные отношения между доменами
Вместе домены образовывали лес, где были и отдельные администраторы для каждого из доменов, и администратор леса, обладающий полными правами в каждом из них. Так что программа-максимум в этом пентесте — завладеть его учетной записью и скомпрометировать весь лес.
Провожу разведку и ищу уязвимости
В пентестах мы, как правило, проверяем инфраструктуру на уязвимость к AS-REP Roasting и Kerberoasting. Учетные записи, уязвимые перед AS-REP Roasting, в сети отсутствовали, и с Kerberoasting тоже не повезло. Я получил N-ное число сервисных билетов Kerberos (TGS) для учетных записей, обладающих SPN, сумел восстановить десяток паролей при помощи брутфорса, но все взломанные учетки были непривилегированными.
Восстановление пароля от одной из учетных записей
Spraying-атака паролями от этих учетных записей позволила скомпрометировать еще несколько пользователей, но администраторов среди них не было.
Результат атаки Password-spraying
Следующим шагом стала проверка хостов в сети на популярные уязвимости, типичные для служб, работающих на портах TCP/445 и TCP/3389: CVE-2009–3103, CVE-2019–0708 (Bluekeep), ms06–025, ms07–029 и тому подобным. Я не мог установить на терминальный сервер полноценный сканер уязвимостей, так что пришлось использовать NMAP с предустановленными скриптами проверок.
Сканирование хостов на предмет наличия уязвимости CVE-2019–0708 (Bluekeep)
Уязвимостей не нашлось, но теперь у меня был список серверов с 445 портом и там стоило поискать общедоступные файлы.
Атакую первый домен
Через несколько дней в одной из сетевых папок нашлась резервная копия системы nw-dc01 в формате WindowsImageBackup.
Та самая шара с бекапом
Буфер обмена в песочнице работал только в одну сторону — из моей системы в виртуальную, так что пришлось выгружать бекап в наше облако. Для этого подошло бы любое другое облачное хранилище, но в рамках пентеста не хотелось отправлять данные клиента на чужие сервера.
Так в мои руки попала резервная копия контроллера домена. Понимаете, к чему идет? Это основной сервер аутентификации Active Directory, там хранятся учетные записи всех пользователей домена и выполняется их аутентификация. Нужно было только смонтировать образ как виртуальный диск и извлечь файлы NTDS.dit (хранилище учетных данных ActiveDirectory) и SYSTEM (этот файл необходим для расшифровки ntds.dit).
Расшифровка файла NTDS.dit
Резервная копия была сделана больше года назад, но кто вообще меняет пароли? Вот и администратор первого домена давно этого не делал, и хэш его пароля из хранилища оказался вполне рабочим. Чтобы воспользоваться этим, проще всего подключиться в режиме отладки к процессу LSASS и провести атаку Pass-the-hash, но, для этого требуются привилегии локального администратора на терминальном сервере, которых у меня до сих пор не было.
В то же время, зная хеш пароля учетной записи, любой пользователь может запросить для нее TGT-билет у контроллера домена и в дальнейшем использовать для авторизации не хеш, а билет. На этом строится другая атака — Over-pass-the-hash.
Для реализации этой техники используется утилита Rubeus, но просто взять и скопировать на терминал не получалось. Этот инструмент распознается большинством антивирусов, а на сервере был установлен клиент Касперского. С ним пришлось повозиться.
Rubeus написан на C# и имеет открытый исходный код, так что утилиту можно пересобирать раз за разом, до тех пор пока антивирус не перестанет ее узнавать. Потребовалось с десяток попыток, Rubeus пришлось урезать и облегчить, но с радаров он пропал и запустился на терминале, несмотря на активную защиту.
Успешная атака Over-pass-the-hash — импорт запрошенного TGT-битета для учетной записи администратора первого домена
В результате я получил доступ к учетной записи администратора первого домена, выполнил атаку DCSync и получил актуальные доменные учетные данные (логин и хеш пароля) всех членов первого домена.
Реализация атаки DCSync в первом домене
На части скомпрометированных компьютеров работал LAPS (Local Administrator Password Solution) — механизм управления локальными администраторами на уровне доменов.
Парольная политика первого домена
Чтобы закрепить успех, я выполнил дамп значений атрибута ms-Mcs-AdmPwd, содержащий значение пароля встроенной локальной административной учетной записи хоста для всех компьютерных учетных записей первого домена. Так я получил пароли еще для 300 учеток.
Атакую второй домен
Среди захваченных машин был хост с активной сессией пользователя из группы Domain Admins второго домена. Чтобы скомпрометировать эту сессию, нужно было сделать дамп памяти системного процесса lsass.exe, но этому снова мешал антивирус.
Здесь стоит объяснить, что корпоративные инсталляции Касперского состоят из трех компонентов: выделенного центра управления, установленных на каждом компьютере клиентских приложений и спаренных с ними агентов администрирования. К каждому агенту прилагается служебная утилита klnagchk. Она нужна для проверки соединения с центром администрирования и без затей сообщает его адрес любому пользователю. С ее помощью я нашел хост, где располагался центр управления антивирусом. Пароль локального администратора от него хранился в LAPS и попал в дамп, сделанный на предыдущем этапе пентеста. Так что я авторизовался, создал локальную учетную запись pentest, добавил ее в локальную группу, члены которой имеют доступ к управлению антивирусной защитой.
Назначение прав локальной учетной записи pentest
Затем я подключился к центру администрирования и на время остановил антивирус на хосте, где залогинился админ второго домена.
Приостановка антивируса с помощью веб-интерфейса KSC
Теперь у меня были развязаны руки, но попытка сделать дамп процесса lsass.exe с помощью инструмента mimikatz закончилась ошибкой.
Ошибка при попытке сделать дамп памяти защищенного процесса lsass.exe
При использовании этого эксплоита следует держать в голове одну тонкость. Начиная с Windows Server 2012 lsass.exe может работать в двух режимах: обычном и защищенном — Protected Process Light (PPL).
Проверка наличия защиты процесса lsass.exe. На ее наличие указывает значение 1 для параметра RunAsPPL
PPL активируется через реестр. Там же защита снимается, но, чтобы изменения вступили в силу, потребуется перезагрузка. В результате обнулятся открытые на сервере сессии, и кто-нибудь это заметит. Поэтому лучше задействовать через библиотеку mimilib, которая обходит защиту на уровне драйвера ядра.
Обход защиты процесса lsass.exe и получение содержимого его памяти
Тогда это было еще непонятно, но в этот момент набрался критический объем информации и успешное завершение пентеста стало вопросом времени. Защита посыпалась, как домино. Получив NTLM-хеш доменной административной учетной записи, я повторил атаки Over-pass-the-hash и DCSync по аналогии с первым доменом. В результате были получены значения NTLM-хешей для всех учетных записей второго домена и полный контроль над ним.
Атакую третий домен
Третий домен был корневым доменом леса, и административные привилегии в нем имели члены групп Enterprise Admins и Domain admins. При этом, одна из учетных записей второго домена входила в состав группы Enterprise Admins третьего домена, и у меня уже был ее NTLM-хеш. Поэтому взлом третьего домена прошел по накатанной.
Реализация атаки Over-pass-the-hash в третьем домене
Повторение атак Over-pass-the-hash и DCSync в третьем домене обеспечило полный контроль над ним и всем лесом.
Реализация атаки DCSync в третьем домене
Разбор полетов
Ни в одном из проверенных доменов не было уязвимых операционных систем или сервисов, а маленький и хорошо защищенный корневой домен вряд ли бы удалось взломать, если бы не проблемы с безопасностью в связанных с ним подсетях.
Неправильное назначение прав на общие файловые ресурсы позволило овладеть резервной копией одного из контроллеров домена. В ней нашелся старый, но все еще рабочий пароль от административной учетной записи. Членство в группах Domain и Enterprise Admins администраторов первого и второго доменов позволило развить атаку и выстроить вектор, который привел к полной компрометации корпоративной сети. Как это часто бывает, выводы по итогу очевидны. Админам компании следовало:
отключить делегирование для доменных административных учетных записей, если в этом нет необходимости;
настроить аудит изменения членства в административных группах;
отключать неактивные (неиспользуемые более 6 месяцев) учетные записи;
время от времени пересматривать права на доступ к общим файловым ресурсам. По крайней мере, тем, где хранится чувствительная информация.
Впрочем, основным недостатком защиты всех трех доменов стало либо отсутствие, либо частичное внедрение технологии управления паролями встроенных административных учетных записей, LAPS. Она обеспечивает достойную защиту, но только если установлена на максимально возможном количестве серверов и рабочих станций. Политики LAPS позволяют запретить использование «слабых» паролей и настроить частоту их изменения. Эти меры значительно повысили бы защищенность инфраструктуры нашего заказчика, да и любой другой сети. Так что берите на вооружение.
