Авторы
Групповые политики в операционных системах Windows представляют собой мощный инструмент управления, с помощью которого администраторы централизованно задают и контролируют настройки пользователей и компьютеров в доменной среде. Однако, несмотря на свою функциональность и удобство, групповые политики также являются одной из самых привлекательных мишеней для атакующих. В частности, злоумышленники все чаще используют их для распространения вредоносного ПО, выполнения скрытых скриптов и внедрения шифровальщиков.
Эти атаки могут происходить на разных уровнях — от простого изменения конфигурации, которое может привести к утечке данных, до более сложных сценариев, когда атакующие получают полный контроль над корпоративной сетью. Понимание уязвимостей групповых политик и методов, которые используют злоумышленники, критически важно для обеспечения безопасности IT-инфраструктуры. В этой статье мы рассмотрим, как групповые политики могут стать вектором атак, какие риски они представляют и какие меры можно принять для защиты от потенциальных угроз.
Объект групповой политики
Объект групповой политики (GPO) состоит из двух ключевых компонентов: контейнера групповой политики (Group Policy Container, GPC) и шаблона групповой политики (Group Policy Template, GPT). GPC представляет собой контейнер Active Directory, который содержит информацию о версии GPO, его статусе и т. д.
Пример содержания Group Policy Container
GPT — это набор файлов и папок, хранящихся на системном томе (SYSVOL) каждого контроллера домена. В нем содержатся различные настройки, скрипты и пресеты для пользователей и компьютеров.
Шаблоны групповой политики на SYSVOL
Путь до каждого шаблона указан в атрибуте контейнера групповой политики под названием gPCFileSysPath.
Содержание атрибута gPCFileSysPath
Другими важными атрибутами групповой политики являются gPCMachineExtensionNames и gPCUserExtensionNames. Каждый из них содержит GUID для клиентских расширений (Client Side Extension, CSE), которые будут распространятся на настройки пользователя и/или компьютера. Сами расширения чаще всего реализуются при помощи библиотек, которые содержат набор функций, необходимых для применения настроек расширения к пользователям или компьютерам. Соответственно, GUID содержит информацию о том, какую именно библиотеку нужно подгрузить. Список всех CSE GUID можно найти в следующем ключе реестра:
|
1 |
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\ |
Содержание одного из GUID в GPExtensions
Чтобы определить, какие политики применять, клиент делает LDAP-запрос к контроллеру домена, который возвращает совокупность политик для определенного пользователя и/или компьютера. Эта совокупность называется SOM (Scope of Management). Важным атрибутом SOM является gpLink: он связывает подразделения (Organization Unit, OU) с GPO, которые к ним применимы.
Процесс применения политики
Как атакующие используют групповые политики
В этой статье мы не будем разбирать, как именно атакующие получают доступ к групповым политикам. Отметим только, что, чтобы изменять политики, злоумышленникам достаточно иметь права WriteProperty на атрибут gPCFileSysPath в GPO. Подробнее об этом написано в исследовании SpecterOps An ACE Up The Sleeve: Designing Active Directory DACL Backdoors. Мы же остановимся на примерах того, как именно атакующие используют эти самые политики в своих целях.
Наиболее распространенным сценарием злоупотребления политиками является запуск шифровальщика на множестве хостов. Наша глобальная команда экстренного реагирования на киберинциденты (GERT) регулярно сталкивается с его последствиями в своей работе. Однако также групповые политики могут использоваться для скрытого закрепления в домене. В этом случае атакующие могут делать практически все, что пожелают, например:
- создавать новых локальных пользователей/администраторов;
- создавать вредоносные задачи в планировщике;
- создавать различные сервисы;
- запускать задачи от имени системы и/или пользователя;
- менять конфигурацию реестра и делать многое другое.
Изменение атрибутов gPCMachineExtensionNames и gPCUserExtensionNames
Существует несколько инструментов, которые нацелены на компрометацию GPO. По функциональности все они так или иначе похожи, поэтому мы остановимся на наиболее популярном (после встроенного инструмента Windows MMC) — SharpGPOAbuse. Эта утилита пошагово описывает процесс модификации GPO, поэтому ее удобно использовать для анализа того, какие именно изменения он подразумевает. В качестве примера создадим пользовательскую задачу в планировщике, которая будет запускаться от имени пользователя labdomain.local\admin.
Добавление в планировщик задачи на запуск cmd.exe от имени определенного пользователя
Как можно видеть на скриншоте выше, сначала в ходе модификации GPO происходит добавление новой задачи в GPT на SYSVOL в виде XML-файла, после чего меняется атрибут versionNumber и повышается номер версии в файле GPT.ini. Это нужно, чтобы при проверке обновлений GPO клиент обнаружил более свежую версию, чем та, что содержится в кэше, и скачал измененную политику. Отследить подобные преобразования можно с помощью события 5136, которое создается при каждом изменении объекта AD.
Событие 5136, отражающее изменение атрибутов GPO
Так как мы создавали пользовательскую политику, изменялось и значение атрибута gPCUserExtensionNames. Теперь в нем появились следующие значения CSE GUID:
- {00000000-0000-0000-0000-000000000000} — Core GPO Engine;
- {CAB54552-DEEA-4691-817E-ED4A4D1AFC72} — Preference Tool CSE GUID Scheduled Tasks;
- {AADCED64-746C-4633-A97C-D61349046527} — Preference CSE GUID Scheduled Tasks.
После применения политики запускается пользовательская задача:
События запуска запланированной задачи
Для каждой функции инструмента SharpGPOAbuse (создание задачи планировщика, добавление пользователей и привилегий и т. д.) существует свой набор CSE, которые будут записываться в атрибуты пользователя или компьютера.
Набор CSE для добавления локального администратора, новых привилегий и скрипта автозапуска в коде SharpGPOAbuse
На основе этих CSE можно разработать правила обнаружения подобных политик:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
title: Adding new privilege via GPO description: Detects events of adding specific attributes for gPCMachineExtensionNames tags: - attack.privilege_escalation - attack.defense_evasion - attack.t1484 - attack.t1484.001 logsource: product: windows service: security detection: selectionEvent: EventID: 5136 OperationType: 'Value Added' AttributeLDAPDisplayName: 'gPCMachineExtensionNames' selectionAttribute: AttributeValue|all: - '{827D319E-6EAC-11D2-A4EA-00C04F79F83A}' - '{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}' condition: selectionEvent and selectionAttribute falsepositives: - Legitimate execution by system administrators. level: medium |
Детектирование добавления новых привилегий через GPO
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
title: Adding startup/logon script via GPO description: Detects events of adding specific attributes for gPCMachineExtensionNames or gPCUserExtensionNames tags: - attack.privilege_escalation - attack.defense_evasion - attack.persistence - attack.t1484 - attack.t1484.001 - attack.t1547 logsource: product: windows service: security detection: selectionEvent: EventID: 5136 OperationType: 'Value Added' AttributeLDAPDisplayName: - 'gPCMachineExtensionNames' - 'gPCUserExtensionNames' selectionAttribute: AttributeValue|all: - '{42B5FAAE-6536-11D2-AE5A-0000F87571E3}' - '{40B6664F-4972-11D1-A7CA-0000F87571E3}' condition: selectionEvent and selectionAttribute falsepositives: - Legitimate activity by system administrators. level: medium |
Детектирование добавления скриптов автозапуска через GPO
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
title: Adding sheduled task via gpo description: Detects events of adding specific attributes for gPCMachineExtensionNames or gPCUserExtensionNames tags: - attack.privilege_escalation - attack.defense_evasion - attack.persistence - attack.t1484 - attack.t1484.001 - attack.t1053 - attack.t1053.005 logsource: product: windows service: security detection: selectionEvent: EventID: 5136 OperationType: 'Value Added' AttributeLDAPDisplayName: - 'gPCMachineExtensionNames' - 'gPCUserExtensionNames' selectionAttribute: AttributeValue|all: - '{AADCED64-746C-4633-A97C-D61349046527}' - '{CAB54552-DEEA-4691-817E-ED4A4D1AFC72}' condition: selectionEvent and selectionAttribute falsepositives: - Legitimate activity by system administrators. level: medium |
Детектирование добавления новой задачи планировщика через GPO
Изменение атрибута gPCFileSysPath
В некоторых сценариях атакующий может модифицировать GPC, но при этом не имеет доступа к каталогу, где расположены GPT. Такая ситуация возникает, потому что для работы с разными сущностями GPO используются разные методы: GPC хранится в LDAP-каталогах Active Directory, а GPT — в системной папке на контроллере домена SYSVOL. Соответственно, пользователь может обладать правами на изменения контейнера LDAP GPC, но не иметь прав на изменение/добавление файлов в SYSVOL. В таком случае при попытке изменить политику он увидит следующую ошибку:
Несоответствие прав между разрешениями LDAP и SMB
Злоумышленник без доступа к SYSVOL может изменить атрибут GPC — gPCFileSysPath, указав в нем путь до сетевого ресурса, подконтрольного атакующим. В результате все клиенты, на которых распространяется политика, будут обращаться к нему за шаблонами. Рассмотрим этот сценарий на примере атаки с применением инструмента GPOddity. Он поднимает собственный SMB-сервер, где создает вредоносные политики, после чего изменяет путь до GPT, а после применения модифицированных политик восстанавливает их исходное состояние из своего бэкапа.
Пример использования инструмента GPOddity
Технику изменения атрибута gPCFileSysPath еще в 2020 году подсвечивал в своем блоге исследователь Марк Гамачи (Mark Gamache), на тот момент работавший в Microsoft. Однако в самой компании считают, что то, что GPT может храниться вне системной папки SYSVOL, — не баг, а особенность. При этом Microsoft не рекомендует хранить GPT на сторонних ресурсах, потому что это может поломать некоторые механизмы Windows.
Упоминание возможности хранить данные политик на сторонних ресурсах в документации Microsoft
Чтобы детектировать подобную технику, мы можем снова воспользоваться событием 5136, где будем отслеживать модификацию нужного нам атрибута.
Пример изменения атрибута gPCFileSysPath в журнале событий Windows
Автоматически обнаруживать в логах событие 5136, связанное с изменением gPCFileSysPath, можно при помощи следующего правила:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
title: Setting the gPCFileSysPath attribute description: Detects changing the gPCFileSysPath attribute. tags: - attack.privilege_escalation - attack.defence_evasion - attack.t1484 - attack.t1484.001 logsource: product: windows service: security detection: selection: EventID: 5136 AttributeLDAPDisplayName: 'gPCFileSysPath' OperationType: 'Value Added' filter: AttributeValue|re: '(?i)\\\\(?<domain>[\w.-]+)\\sysvol\\\k<domain>\\' condition: selection and not filter falsepositives: - Unlikely level: high |
Чтобы устранить риск ложноположительного срабатывания, мы добавили в исключения события, которые генерируются при создании нового GPO, где в атрибуте указан нормальный путь до GPT:
|
1 |
\\<domain>\SysVol\<domain>\Policies\<GPO GUID> |
Изменение атрибута gPCFileSysPath при создании нового GPO
Как мы ищем «плохие» политики в проектах Compromise Assessment
Одним из пунктов в чеклисте каждого нашего проекта Compromise Assessment является поиск компрометации через групповые политики, так как злоумышленники активно используют этот способ как для распространения вредоносного ПО, скриптов, уязвимых настроек и т. д., так и для скрытого закрепления в домене. Чтобы проанализировать большой объем политик, мы используем инструмент Group3r. С его помощью мы можем быстро найти все политики и прогнать их по нашим детектирующим правилам, чтобы выявить подозрительные, а также обнаружить различные уязвимости, которыми может воспользоваться атакующий.
Пример найденной подозрительной политики
Пример уязвимой политики
Так как Group3r ищет только политики, расположенные на доменном томе SYSVOL, важно определить, у каких из них изменен атрибут gPCFileSysPath. Для этого можно воспользоваться следующим скриптом:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
$GPOs = Get-GPO -All $domain = (Get-ADDomain).DNSRoot $correctPathPattern = "\\$domain\SysVol\$domain\Policies\" $correctPathPatternLower = $correctPathPattern.ToLower() $incorrectGPOs = @() foreach ($gpo in $GPOs) { $ldapPath = "LDAP://" + $gpo.Path [ADSI]$GPC = $ldapPath $gpcFileSysPath = $GPC.Properties["gPCFileSysPath"].Value $gpcFileSysPathLower = $gpcFileSysPath.ToLower() if (-not $gpcFileSysPathLower.StartsWith($correctPathPatternLower)) { $result = [PSCustomObject]@{ GPOName = $gpo.DisplayName GPOId = $gpo.Id GPFileSysPath = $gpcFileSysPath } $incorrectGPOs += $result } } if ($incorrectGPOs.Count -gt 0) { $incorrectGPOs | Format-Table -AutoSize } else { Write-Host "gPCFileSysPath is correct" } |
Пример работы скрипта
Помимо Group3r отличным инструментом поиска различных ошибок конфигурации групповых политик может выступать SharpHound, позволяющий найти потенциальные векторы атак на GPO.
Пример ошибки конфигурации, предоставляющей право модифицировать политики пользователям, которым оно не нужно
Как мы мониторим групповые политики в MDR
Зачастую организации логируют далеко не все события на хостах. Чтобы обеспечить безопасность и проактивный мониторинг групповых политик в сервисе MDR, мы разработали несколько улучшений для нашей телеметрии. Во-первых, поскольку на некоторых хостах отключен расширенный аудит Windows, мы стараемся по возможности использовать ETW-провайдеры (Event Tracing for Windows), чтобы заменить события, необходимые для понимания того, что произошло в системе. А там, где не получается обойтись одним ETW, улучшаем наши технологии и расширяем покрытие телеметрии. К примеру, чтобы отвязаться от события 5136, для отслеживания которого необходимо настроить аудит «Изменения в службе каталогов», наша команда из группы исследования и развития SOC разработала инструмент GCNet на основе PoC по мониторингу изменения служб каталогов, описанного Microsoft. Инструмент подключается к базе LDAP, в которой мы указываем поиск по определенному значению атрибута distinguishedName (в нашем случае это CN=Policies) и подписываемся на любые его изменения. Получив уведомление об изменении политики, мы запрашиваем подробную информацию о соответствующем GPO, включая данные GPC и GPT.
Пример события с выводимой информацией по GPO
Обнаруженные события прогоняются по нашим детектирующим правилам, что позволяет выявлять различные вредоносные политики. Важными атрибутами здесь являются опции gpLink и флаги политики. Так, политики с флагом Enforced имеют приоритет перед остальными и будут применены в первую очередь. При этом они не могут быть переписаны другой политикой. Также у GPO существует еще несколько флагов, зная которые, мы можем понять, включена политика или нет. Совокупность всех атрибутов дает дополнительную информацию о том, сколько времени у нас есть, чтобы отреагировать на инцидент до следующего применения групповой политики (по умолчанию политики обновляются каждые 90 ±30 минут на клиентских машинах и каждые 5 минут на контроллере домена), а также узнать, где и как она применяется, что значительно дополняет картину расследования.
Заключение
Групповые политики (GPO) представляют собой многофункциональный инструмент, который в руках злоумышленников может стать серьезной угрозой для корпоративной сети. Их компрометация позволяет атакующим выполнять скрытые действия, изменять конфигурации и распространять вредоносное ПО на множество хостов одновременно. Именно поэтому групповым политикам необходимо уделять пристальное внимание и обеспечивать их постоянный мониторинг. Отслеживание изменений в групповых политиках, а также реагирование на обнаруженные угрозы входят в сервис Managed Detection and Response (MDR).
Авторы
В той же категории
Одна групповая политика, чтоб править всеми