Захватываем сеть через сервер централизованного управления и защищаемся от таких атак

Привет, меня зовут Дмитрий, в команде Бастион я отвечаю за этап внутреннего тестирования на проникновение.

Сегодня я на конкретном примере покажу, как антивирус может подставить под удар всю корпоративную сеть. Разберемся, почему средства централизованного управления необходимо охранять как зеницу ока, а затем сформулируем рекомендации по защите таких систем.

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

Крупная промышленная компания заказала у нас пентест. Для внутреннего тестирования выбрали сценарий, в котором злоумышленник подключил свой ПК к локальной сети организации.

Я развернул на машине Kali Linux и начал изучать сеть. Nmap показал около двух с половиной тысяч активных IP-адресов. Пришлось перебрать ряд потенциальных векторов атак. В сети не нашлось ни одного контроллера домена, который можно было скомпрометировать при помощи ZeroLogon (CVE-2020-1472 ^[1]), Bluekeep (CVE-2019-0708 ^[2]) или атаки LLMNR-poisoning (кстати, Responder, входящий в состав Kali, ― удобный инструмент для ее проведения).

Прорыв случился, только когда Metasploit засек три хоста с подозрением на наличие уязвимости EternalBlue (CVE-2017-0147 ^[3]).

В первом действительно была уязвимость, но использовать ее помешало СЗИ. Тогда я еще не знал, какая защитная система была развернута в сети. Во втором случае наличие уязвимости не подтвердилось, а вот третий хост поддался атаке, и я получил удаленный доступ к системе с максимальными привилегиями.

Эксплуатация уязвимости EternalBlue

Существует много сценариев постэксплуатации такой дыры. Я остановился на создании новой учетной записи с административными привилегиями. Вошел под этой учетной записью по протоколу RDP, снял дамп памяти процесса lsass.exe, а затем при помощи Mimikatz извлек валидные учетные данные в виде логинов и NTLM-хешей паролей пользовательских учетных записей.

Затем вытащил файлы из локального хранилища учетных записей: SAM, SYSTEM, SECURITY. Внутри нашелся NTLM-хеш учетной записи локального администратора.

Извлечение учетных данных из дампа локального хранилища учетных записей

Этого вполне достаточно для горизонтального продвижения по инфраструктуре, ведь существует атака Pass-the-hash. Она подразумевает использование хеша пароля и позволяет получить доступ ко всем хостам, которые доступны этому локальному администратору.

Аутентификация при помощи атаки Pass-the-hash

Среди хостов, доступных администратору, нашлась машина, защищенная антивирусом Касперского. В его настройках был указан IP-адрес сервера управления антивирусной защитой. Оказалось, что одна из пользовательских учетных записей, извлеченных из lsass.exe на предыдущем этапе пентеста, имеет доступ к этому серверу.

Используя хеш, я получил сессию на сервере администрирования и создал вспомогательную локальную учетную запись pentest. Затем добавил pentest в локальную группу Administrators (чтобы получить право на подключение по протоколу RDP) и локальную группу KLAdmins, в которой находятся учетки администраторов антивирусной защиты.

Антивирусная защита компании оказалась под моим управлением.

Административная сессия на сервере управления антивирусной защитой

Теперь оставалось только развернуть консоль управления и аутентифицироваться на центральном сервере антивирусной защиты. Центр управления дал исчерпывающую информацию об устройстве сети: где расположены рабочие станции, сервера и базы данных, где сидят бухгалтеры, а где программисты, какие ОС установлены на машинах.

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

Обычно так раскатывают прикладное программное обеспечение, а я собрал установочный пакет, который делает только одну вещь — создает локальную учетную запись с административными привилегиями.

Параметры запуска утилиты в составе инсталляционного пакета. Исполняемые команды видны в параметрах запуска

Затем я нашел хост с сессиями учетных записей, входящих в группу Domain Admins, и накатил туда пакет через центр управления антивирусной защитой.

Свежесозданный инсталляционный пакет PsExec в списке программ для удаленной установки

Основной пакета послужила утилита PsExec ^[4]. Она имеет цифровую подпись Microsoft, не вызывает срабатывание антивирусных решений и позволяет выполнять любые команды операционной системы. Так что все успешно установилось.

Доступ к скомпрометированному хосту по протоколу RDP

После этого я подключился к хосту по протоколу RDP, снял еще один дамп памяти процесса lsass.exe и на этот раз извлек NTLM-хеши паролей учетных записей доменных администраторов.

Извлечение NTLM-хеша пароля учетной записи доменного администратора на скомпрометированном хосте

Атакующий может внедрить NTLM-хеш учетной записи администратора домена в процесс lsass.exe на подконтрольном хосте и выполнить атаку DCSync. Ведь по умолчанию все члены группы Domain admins обладают привилегией выполнения синхронизации.

Таким образом, на подконтрольный хост заливается все содержимое хранилища доменных учетных записей NTDS с любого контроллера домена в сети. Это NTLM-хеши всех компьютерных и пользовательских учетных записей, включая служебные.

Фрагмент дампа хранилища учетных записей

С этими данными можно легко закрепиться в домене при помощи атак Golden Ticket и Silver Ticket, а также найти учетные записи, обладающие правами DCSync в других доменах леса и скомпрометировать их.

Разбор полетов

Подобную атаку возможно реализовать при помощи практически любой системы централизованного управления. СЗИ, DLP, центры управления обновлениями, системы резервного копирования, системы удаленной техподдержки и контроля работы сотрудников — все это потенциальный источник проблем и заманчивая цель для хакерских атак.

Скомпрометировать центр управления даже стратегически выгоднее, чем администратора домена. Полномочия администратора, как правило, дают доступ только к определенным сегментам сети, а с сервера управления обычно видна вся сеть организации. Не говоря о том, что его можно использовать для распространения вредоносного ПО.

Меры защиты

Когда система централизованного управления скомпрометирована, защита сети разваливается на глазах, даже если она хорошо продумана в других аспектах.

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

Чтобы минимизировать риски, необходимо грамотно выстраивать защиту всей сети. И здесь можно дать несколько советов. Это простые рекомендации, но они сделают мою работу интереснее, а жизнь злодеев — сложнее.

Замаскируйте центр управления

Первое, что стоит сделать, — переименовать хост. И пентестеры, и злоумышленники часто идентифицируют цели по названиям. Если хост обозначен, например, как kis.domain.local или ksc.domain.local, считайте, что на нем нарисована мишень.

Создайте отдельную учетную запись

Еще один простой шаг, заметно усложняющий атаки, — отдельная локальная учетная запись для работы с сервером, на котором развернут центр управления. Не стоит использовать ее где-то еще.

Зачастую происходит так, что злодей компрометирует систему уровнем ниже и обнаруживает в ней учетные данные, которые подходят и к серверу администрирования. И, кстати, не стоит надеяться на системы управления паролями, хранящие данные в Active Directory. Это не панацея.

Настройте антивирусную защиту

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

Настройте мониторинг и оповещения об инцидентах

На практике попадаются сети, где развернуто два — три сервера администрирования под разные контролируемые зоны: для рабочих станций, серверов, критических систем. Это может задержать злодеев, но не поможет, если администратор проспит атаку. Так что, хорошая практика — использование систем оповещения, рассылающих уведомления об аутентификации учетных записей администраторов домена, изменениях настроек и других потенциальных инцидентах.

Относитесь к управляющим серверам, как к критической инфраструктуре

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