Сканер уязвимостей Tenable и Nessus

Что такое DCShadow. Техническое погружение в атаку на Active Directory

На конференции по безопасности BlueHat IL 2018 два исследователя Бенджамин Делпи и Винсент Ле Ту представили новую технику атаки на инфраструктуру Active Directory. Эта атака, получившая название «DCShadow», позволяет злоумышленнику, имеющему соответствующие права, создать поддельный контроллер домена, способный реплицировать вредоносные объекты в работающую инфраструктуру Active Directory.

В этой статье мы объясним технические основы атаки и обсудим последствия для безопасности работающей инфраструктуры Active Directory. Наконец, мы расскажем, как blue team могут обнаруживать такие атаки.

Если вы заинтересованы в защите от DCShadow и других атак на Active Directory, обратите внимание на решение Tenable.ad.

Что такое атака DCShadow и в чем ее новизна?

Святой Грааль для red team-ов или злоумышленников, желающих скомпрометировать инфраструктуру Active Directory, — это возможность получить учетные данные пользователей и компьютеров, не будучи замеченными СЗИ.

Для этой цели было разработано несколько методов атаки: LSASS-инъекции, злоупотребление теневым копированием, парсинг NTFS-тома, операции ESE NT, манипуляции с конфиденциальными атрибутами и т.д. Более подробную информацию можно найти в отличной статье на ADSecurity.org.

Среди всех этих шумных атак одна связана с атакой «DCShadow». Представленная в 2015 году атака «DCSync» основана на возможности членов групп «Администраторы домена» или «Контроллеры домена» запрашивать у контроллера домена (DC) репликацию данных (для выполнения этой задачи необходимо право GetChangesAll, предоставленное по умолчанию административным учетным записям и контроллерам домена). Фактически, как описано в спецификации MS-DRSR для репликации контроллера домена, эти группы могут запрашивать контроллер домена реплицировать объекты AD (включая учетные данные пользователя) через GetNCChanges RPC. Более подробная техническая информация об атаках доступна в блоге ADSecurity.org.

Атака DCSync с помощью mimikatz

Одним из основных ограничений атаки «DCSync» является невозможность для злоумышленника внедрить новые объекты в целевой домен AD. Конечно, этот злоумышленник может завладеть административной учетной записью, используя старую добрую технику Pass-The-Hash, а затем внедрить объекты, но это требует больше усилий, больше шагов, а это означает большую вероятность быть обнаруженным blue team. Атака «DCShadow» снимает это ограничение, переворачивая парадигму атаки «DCSync» с ног на голову.

С помощью «DCShadow» злоумышленники больше не пытаются реплицировать данные, а регистрируют новые контроллеры домена в целевой инфраструктуре для внедрения объектов Active Directory или изменения существующих (путем замены содержимого атрибутов). Идея фальшивого контроллера домена не нова и неоднократно упоминалась в предыдущих публикациях по безопасности, но требовала инвазивных методов (например, установки виртуальной машины с Windows Server) и входа на обычный контроллер домена для добавления виртуальной машины в качестве контроллера для целевого домена. Не очень скрытно.

Событие, создаваемое во время обычного добавления DC

Чтобы понять гениальность идеи, лежащей в основе «DCShadow», важно четко понимать, что такое контроллер домена и как он регистрируется в инфраструктуре Active Directory.

Что такое контроллер домена

Как описано в MS-ADTS (Техническая спецификация Active Directory), Active Directory — это архитектура с несколькими ведущими машинами, основанная на выделенных службах. Контроллер домена — это сервис (или сервер, на котором размещается этот сервис, в зависимости от вашей точки зрения), который содержит хранилище данных для объектов AD и взаимодействует с другими контроллерами домена, гарантируя, что локальное изменение объекта правильно реплицируется на всех контроллерах домена.

Когда контроллер домена работает как контроллер домена с правом записи (RW), он содержит полные реплики контекста именования (NC) конфигурации, схему и один контекст именования домена своего леса. Таким образом, каждый RW DC хранит все объекты домена, включая учетные данные и любые секреты (например, приватные или сеансовые ключи). Соответственно, нет необходимости напоминать, что контроллеры домена — это единственный элемент, на защите которого должны быть сосредоточены усилия blue team (административные УЗ или права доступа — это лишь два из множества способов доступа к контроллеру домена).

Сервисы, предоставляемые контроллером домена

Подробное описание технических способов и средств DC может быть сложным и не поможет понять цель атаки «DCShadow». Чтобы быть кратким, сервер можно назвать контроллером домена, если он предлагает следующие 4 ключевых компонента:

  • движок базы данных, способный реплицировать свою информацию (это означает, что он должен быть доступен через протоколы LDAP и реализовывать несколько RPC в соответствии со спецификациями MS-DRSR и MS-ADTS),
  • провайдер аутентификации, доступный через протоколы Kerberos, NTLM, Netlogon или WDigest,
  • система управления конфигурациями под названием GPO, основанная на протоколах SMB и LDAP,
  • (опциональный) DNS-провайдер, используемый клиентами для поиска ресурсов и поддержки аутентификации.
Список сервисов, предоставляемых контроллером домена

Репликация Active Directory

Помимо размещения указанных сервисов, новый контроллер домена должен быть зарегистрирован в инфраструктуре каталогов, чтобы его принял другой DC в качестве источника данных для репликации. Репликация данных управляется встроенным процессом (работающим на основе службы NTDS), который называется «Проверка согласованности знаний» (Knowledge Consistency Checker, KCC).

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

Два типа процесса репликации

По умолчанию KCC инициирует репликацию AD каждые 15 минут, что обеспечивает согласованное и регулярное распространение данных. Используя USN, связанный с каждым объектом AD, KCC распознает изменения, происходящие в среде, и гарантирует, что контроллеры домена не остаются забытыми при репликации. Интересный факт: исторически процесс репликации Active Directory мог осуществляться через RPC (например, DrsAddEntry), но также и через SMTP (только для раздела Схема и Конфигурация)!

Ключ реестра, определяющий период времени репликации

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

Как на самом деле работает DCShadow

Как объясняется в следующем разделе этой статьи, атака «DCShadow» направлена ​​на регистрацию новых контроллеров домена для внедрения вредоносных объектов AD и, таким образом, создания бэкдоров или любого незаконного доступа или права. Для достижения этой цели атака «DCShadow» должна изменить базу данных целевой инфраструктуры AD, чтобы авторизовать несанкционированный сервер для участия в процессе репликации.

Регистрация нового контроллер домена

Как упоминается в спецификации MS-ADTS, контроллер домена представлен в базе данных AD объектом класса nTDSDSA, который всегда находится в контексте именования конфигурации домена. Если быть более точным, каждый DC хранится в контейнере сайта (объектный класс sitesContainer) как дочерний элемент серверного объекта.

Синим цветом обозначены контейнеры, в которых хранится объект NTDS-DSA. Красным цветом обозначен сам объект

Беглый взгляд на схему показывает, что объекты NTDS-DSA могут быть созданы только как дочерние объекты серверных объектов, которые, в свою очередь, могут быть только частью организации или серверного объекта:

  • серверные объекты могут храниться только в объектах serverContainer, которые находятся только в Configuration NC.
  • объекты организации могут храниться только в объектах locality, country или domainDNS, которые могут быть найдены в NC домена.
Схема указывает, где могут быть созданы объекты ntds-dsa

Таким образом, контроллеры домена (объекты nTDSDSA) могут быть созданы только в конфигурации или NC домена. На практике кажется, что во внимание принимаются только объекты nTDSDSA, хранящиеся в контейнере сайта (объект sitesContainer). Поскольку KCC полагается на информацию о сайте для вычисления своей топологии репликации, кажется логичным, что используются только эти объекты. Обратите внимание, что создание объекта nTDSDSA невозможно с использованием протокола LDAP.

Основное действие атаки «DCShadow» — это создание нового сервера и объектов nTDSDSA в разделе «Конфигурация» схемы. Это дает возможность создавать злонамеренные данные репликации и внедрять их в другие контроллеры домена.

Теперь, когда мы понимаем, что делает атака «DCShadow», нам нужно понять, какие привилегии требуются для создания объектов nTDSDSA в разделе Configuration. Быстрый анализ прав показывает, что только BUILTIN\Administrators, DOMAIN\Domain Admins, DOMAIN\Enterprise Admins и NT AUTHORITY\SYSTEM имеют права контроля над целевыми контейнерами.

Права доступа по умолчанию для объекта Server

Этот быстрый анализ позволяет нам сделать вывод, что атака «DCShadow» — это не уязвимость повышения привилегий, а злонамеренное использование механизма Active Directory. Это не позволяет red team получить привилегии, но дает альтернативный способ получения персистентности или совершения злонамеренных действия в инфраструктуре каталогов. Таким образом, ее следует отнести к категории еще одной хитрости для обеспечения персистентности в AD, а не как уязвимость, которую можно исправить.

Доверять новому контроллеру домена

Как описано в предыдущем абзаце, атака «DCShadow» основана на добавлении нового объекта nTDSDSA в раздел конфигурации для регистрации себя в качестве нового участника процесса репликации. Однако добавления этого единственного объекта недостаточно, чтобы позволить нашему злонамеренному серверу инициировать репликацию. Фактически, чтобы участвовать в процессе репликации, мы должны соблюдать два требования:

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

Если использовать реальную учетную запись компьютера, мошеннический сервер будет рассматриваться как доверяемый сервер AD. Атрибуты Kerberos SPN обеспечат поддержку аутентификации для других контроллеров домена. Следовательно, каждый объект nTDSDSA связан с объектом компьютера через атрибут serverReference.

Атрибут serverReference действует как связь между объектом nTDSDSA и связанным с ним компьютерным объектом

Несмотря на теоретическую возможность достичь этого с помощью учетной записи пользователя, гораздо проще и незаметнее использовать учетную запись компьютера. В реальности она будет автоматически зарегистрирована в инфраструктуре DNS (что позволит другим DC определять местонахождение нашего ресурса), изначально будет иметь необходимые атрибуты, и его аутентификационный секрет будет автоматически управляться.

Таким образом, атака «DCShadow» будет использовать легитимную учетную запись компьютера для аутентификации на других контроллерах домена. Хотя компьютерный объект и объект nTDSDSA предоставят возможность аутентификации на других контроллеров домена, атака «DCShadow» по-прежнему должна дать возможность другим контроллерам домена подключиться к несанкционированному серверу для репликации незаконной информации с него.

Это последнее требование выполняется с использованием имени участника-службы Kerberos (Kerberos Service Principal Name, SPN). Как подробно объясняется в нескольких публикациях, SPN используются службой Kerberos (KDC) для шифрования тикета Kerberos учетной записи, связанной с SPN. В нашем случае атака «DCShadow» добавит SPN объекта компьютера, используемого для аутентификации.

Одним из ключевых открытий Бенджамина Делпи и Винсента Ле Ту было выделение минимального набора SPN, необходимых для выполнения процесса репликации. Результаты их исследований показывают, что требуется два SPN, чтобы другой DC мог подключиться к злонамеренному серверу:

  • класс обслуживания DRS (который имеет известный GUID E3514235–4B06–11D1-AB04–00C04FC2DCD2),
  • класс обслуживания Global Catalog (со строкой «GC»).

Например, нашему мошенническому серверу нужны следующие два SPN (с названием «roguedc» и GUID DSA 8515DDE8–1CE8–44E5–9C34–8A187C454208 в домене alsid.corp):

E3514235–4B06–11D1-AB04–00C04FC2DCD2/8515DDE8–1CE8–44E5–9C34–8A187C454208/alsid.corp
GC/roguedc.alsid.corp/alsid.corp
Злонамеренная УЗ компьютера с SPN контроллера домена

При запуске атаки «DCShadow» устанавливает эти два имени участника-службы для своей целевой учетной записи компьютера. Если говорить точнее, имена участников-служб будут установлены с помощью функции DRSAddEntry RPC, как описано в документации функции CreateNtdsDsa (более подробная информация о MS-DRSR RPC представлена ​​в следующем разделе).

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

Внедрение нелегитимных объектов

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

Чтобы отдавать незаконные данные, мошеннический контроллер домена должен будет реализовать минимальный набор функций RPC, требуемых спецификациями MS-DRSR: IDL_DRSBind, IDL_DRSUnbind, IDL_DRSGetNCChanges, IDL_DRSUpdateRefs. IDL этой функции предоставляется Microsoft в ее открытых спецификациях и теперь реализован в инструменте Mimikatz Бенджамина Делпи.

Последний шаг атаки «DCShadow» — запустить процесс репликации. Для этого можно использовать две стратегии:

  • Подождите, пока процесс KCC другого контроллера домена не запустит процесс репликации (требуется 15-минутная задержка)
  • Принудительно выполните репликацию, вызвав функцию DRSReplicaAdd RPC. Это изменит содержимое атрибута repsTo, что запустит немедленную репликацию данных.
Выдержка из спецификации MS-DRSR, описывающая DRSReplicaAdd IDL

Принудительная репликация с помощью IDL_DRSReplicaAdd RPC — последний шаг, выполняемый во время атаки «DCShadow». Он позволяет добавлять произвольные данные в целевую инфраструктуру AD. При этом становится тривиальным добавить любой бэкдор в домен (например, добавив нового члена в административную группу или установив историю SID для контролируемой учетной записи пользователя).

Краткое описание процесса

На этой схеме приведены различные операции, выполняемые во время атаки DCShadow.

Высокоуровневый процесс атаки DCShadow

Последствия DCShadow для стратегий blue team

Как объясняется в исследовательском документе, blue team, отвечающие за мониторинг безопасности AD, обычно полагаются на сбор журналов событий. Компьютеры, являющиеся членами домена, настроены на отправку своих журналов в SIEM для анализа.

Упрощенная архитектура SIEM с передачей событий через протокол WinRM Event Forwarding

Первая проблема с этим подходом заключается в том, что только легитимные машины отправляют свои логи сборщику журналов. Во время атаки «DCShadow» журналы событий, связанные с внедрением новых данных, создаются только на компьютере злоумышленника, который, очевидно, не будет сигнализировать о себе, отправляя события в SIEM. Таким образом, атака DCShadow может быть незаметной, поскольку только небольшое число событий будут созданы легитимными компьютерами.

В этой статье объясняется, что перед внедрением нелегитимных данных в целевую AD необходимо выполнить несколько предварительных действий. К сожалению, логирование событий модификации AD, связанных с настройкой мошеннического контроллера домена, редко включаются в политики ведения журналов. Например, изменения Configuration NC почти никогда не принимаются во внимание. Хотя о таких изменениях можно получить алерт, определение того, вызвано ли такое событие злонамеренными действиями или нормальной работой операциями AD, отнимает много времени и непрактично.

Blue team должны полностью изменить свою стратегию и сместить акцент с анализа журналов на анализ конфигурации AD. Наивный подход — отслеживать репликации (изменения RPC DrsGetNCChanges). На самом деле, по умолчанию, запись SACL, установленная для корневого объекта домена, регистрирует использование расширенных прав, за исключением контроллеров домена. Таким образом, репликацию с учетной записью пользователя или недоменной машиной должно быть довольно легко идентифицировать. Однако мы не считаем этот метод наиболее эффективным. С нашей точки зрения, для обнаружения атак DCShadow необходимо реализовать три стратегии:

  1. Следует внимательно изучить раздел Configuration схемы. Объекты nTDSDSA в контейнере сайтов должны быть сопоставлены с контроллерами домена в OU «Контроллеры домена» (или лучше: список известных контроллеров домена, поддерживаемый вручную группой администрирования). Любой объект, обнаруживаемый в первом, но не во втором списке, должен быть исследован. Обратите внимание, что мошеннический объект nTDSDSA удаляется сразу после публикации нелегитимных объектов. Чтобы быть эффективной, этот способ обнаружения должен выявлять создание объекта.
  2. Как показано в предыдущих абзацах, контроллерам домена необходим провайдер аутентификации. Чтобы иметь возможность отправлять изменения, у несанкционированного контроллера домена должен быть провайдер, доступный через Kerberos, с определенной службой. На практике это означает Service Principal Name (SPN), которое начинается со строки «GC/». Также можно использовать широко известный GUID интерфейса RPC «E3514235–4B06–11D1-AB04–00C04FC2DCD2». Компьютеры, имеющие эту службу, но не присутствующие в подразделении DC, также должны быть тщательно исследованы.
  3. Использование «DCShadow» требует от злоумышленника повышенных привилегий. Анализ и мониторинг прав, представленных в разделе Configuration, позволит red team убедиться, что никто не может изменить его, кроме законных администраторов. Любой DACL, предоставляющий доступ непривилегированному объекту, также может быть признаком возможного бэкдора.

Выявляем DCShadow

Несмотря на отсутствие журналов событий, есть несколько способов обнаружить DCShadow.

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

Сетевой парттерн DCShadow (предоставлен dcshadow.com)

Однако следует учитывать некоторые ограничения:

  • Это требует мониторинга каждого контроллера домена, даже если у вас их десятки. Пропустив даже один из них, вы пропустите атаку.
  • Есть несколько хитрых способов добавить незаконные данные без вызова DRSReplicaAdd.
  • Вам нужно завести на TAP / дублировать весь трафик очень чувствительной инфраструктуры.

Более комплексный подход заключался бы в отслеживании репликации объектов Active Directory для выявления подозрительных паттернов.

Действительно, DCShadow требует создания нескольких объектов в инфраструктуре каталогов, а Active Directory предлагает несколько способов получения информации о возникновении такого события (без каких-либо административных прав).

Основная идея состоит в том, чтобы обнаружить создание объекта nTDSDSA и набора SPN E3514235–4B06–11D1-AB04–00C04FC2DCD2 на нелегитимной машине с помощью процесса репликации или уведомления.

Чтобы проиллюстрировать этот подход, разработчики Tenable.ad выпустили серию проверок под названием UncoverDCShadow, чтобы помочь blue team обнаружить попытки DCShadow. Проверки разработаны на PowerShell и могут быть легко подключены к SIEM, чтобы помочь ей обнаружить такую ​​атаку.

UncoverDCShadow использует возможность выполнять асинхронные вызовы базы данных AD с помощью LDAP. Используя хорошо известный (или не очень) элемент управления LDAP-сервером LDAP_SERVER_NOTIFICATION_OID (1.2.840.113556.1.4.528), любой пользователь может получить информацию о любом созданном, измененном или удаленном объекте всей базы данных Active Directory. Как показано в следующем видео, становится довольно легко обнаружить активность DCShadow.

Более подробная информация о том, как работает UncoverDCShadow, доступна ЗДЕСЬ.

Заключение

Ключевая мысль этого анализа состоит в том, что «DCShadow» — это не уязвимость, а инновационный способ внедрения незаконных данных в инфраструктуру AD.

Ни один непривилегированный злоумышленник никогда не сможет использовать его для повышения своих привилегий и получения административного доступа к вашей AD с помощью «DCShadow». Итог: если ваш AD правильно настроен и защищен, вам не нужно предпринимать никаких срочных действий.

Для защиты от «DCShadow» не требуется установка каких-либо срочных патчей или применения специальных конфигураций, в отличие, например, от реагирования на инциденты типа WannaCry / NotPetya.

Не являясь уязвимостью, «DCShadow» не будет исправлен обновлением Microsoft. Попытка противодействовать этому потребовала бы изменения способа работы AD и, следовательно, сломало бы систему. Авторы исследования ранее опубликовали атаку «DCSync», и Microsoft не выпустил никаких патчей, поскольку в ней используются только легитимные API. «Исправление» означало бы запрет репликации DC. Если оно не сломано, не чините. AD не сломана.

Однако необходимо учитывать тот факт, что новый метод атаки общедоступен для всех. Он дает чрезвычайно скрытый способ выполнения действий привилегированными злоумышленниками, поэтому ваши стратегии обнаружения следует обновить, чтобы отражать эту новую угрозу. Традиционные методы анализа журнала событий, вероятно, не смогут обнаружить использование «DCShadow». Чтобы эффективно обнаруживать эту технику атаки, требуется возможность непрерывного мониторинга базы данных AD для выявления незаконных изменений. Это то, что реализует решение Tenable.ad, и его пользователи защищены от этой атаки. Вы можете получить дополнительную информацию в обзоре Tenable.ad или заказать демо по этой ссылке.

Автор статьи — Люк Делсалл, Tenable (Alsid), исследователь безопасности, специализирующийся на инфраструктурах MS Active Directory, бывший специалист по редактированию и системный инженер по безопасности. Дата оригинальной публикации — 29 января 2018 года. Оригинал на английском языке.

Об авторе

Тайгер Оптикс является специализированным дистрибьютором инновационных решений по кибербезопасности.

Мы помогаем партнерам и заказчикам повышать защищенность на всем протяжении корпоративной ИТ-инфраструктуры – от гибридного ЦОДа до конечных точек – рабочих станций и мобильных устройств.

Веб-сайт: https://www.tiger-optics.ru/