l0ss/grouperСкрипт PowerShell, помогающий находить уязвимые настройки в групповых политиках AD. (устарел, используйте Grouper2 вместо него!)
НЕ ИСПОЛЬЗУЙТЕ GROUPER БОЛЬШЕ. ИСПОЛЬЗУЙТЕ GROUPER2! https://github.com/l0ss/Grouper2
Скрипт PowerShell для поиска уязвимых настроек в групповых политиках Active Directory.
Grouper — это модуль PowerShell, предназначенный для пентестеров и редтимеров (хотя, вероятно, также полезен для сисадминов). Он просеивает (обычно очень шумный) XML-вывод командлета Get-GPOReport (часть модуля групповых политик Microsoft) и выявляет все настройки, определённые в объектах групповой политики (GPO), которые могут оказаться полезными для того, кто пытается сделать что-то весёлое/зловредное.
Примеры того, что он находит в GPO:
Да, это довольно грубо, но это экономит мне огромное количество времени, которое я тратил на чтение тех ужасных 150-мегабайтных HTML-отчётов GPO, и если это работает для меня, может сработать и для вас.
Примечание: Хотя некоторые имена функций могут содержать слово «audit», Groper НЕ предназначен для исчерпывающего аудита на соответствие лучшим практикам и т.д. Если вам нужно это, используйте Microsoft SCT и LGPO.exe или что-то подобное.
Создайте отчёт GPO на машине Windows с установленными командлетами групповых политик. Они установлены на контроллерах домена по умолчанию, могут быть установлены на клиентах Windows через RSAT или включены через мастер «Добавление компонентов» на серверах Windows.
Get-GPOReport -All -ReportType xml -Path C:\temp\gporeport.xml
Импортируйте модуль Grouper.
Import-Module .\grouper.psm1
Запустите Grouper.
Invoke-AuditGPOReport -Path C:\temp\gporeport.xml
Также есть несколько параметров, которые можно менять, чтобы изменить, какие настройки политик будет показывать Grouper:
-showDisabled
По умолчанию Grouper показывает только GPO, которые в данный момент включены и привязаны к подразделению в AD. Этот параметр переключает это поведение.
-Online
По умолчанию Grouper работает только с фактическим XML-выводом из Get-GPOReport и не выполняет никаких сетевых взаимодействий, что делает его довольно «безопасным с точки зрения OPSEC», хотя я ненавижу этот термин.
Если запустить его с параметром -Online, Grouper включит проверки, требующие связи (как минимум) с доменом AD, из которого был создан отчёт, но, вероятно, также потребуется связь с, например, файловыми серверами. Это позволит Grouper выполнять полезные действия, такие как отчёт о ACL для файлов, на которые ссылаются GPO, и проверка, может ли текущий пользователь записывать в этот файл.
-Level
Grouper имеет 3 уровня фильтрации, которые можно применить к его выводу.
Использование простое. -Level 3, -Level 2 и т.д.
Get-GPOReport отлично работает на машинах, не входящих в домен, через runas /netonly. Вам понадобятся учётные данные с низкими привилегиями, но это ожидаемо.
Сделайте так:
runas /netonly /user:domain\user powershell.exe
на машине, не входящей в домен, но имеющей связь с контроллером домена.
Затем в полученном сеансе PowerShell сделайте так:
Get-GpoReport -Domain example.com -All -ReportType xml -Path C:\temp\gporeport.xml
Легко.
Для работы Grouper нужен только PowerShell 2.0 и xml-файл, выводимый из Get-GPOReport. Вы можете запустить его на виртуальной машине без сетевой карты, если беспокоитесь, и он всё равно будет работать.
Тем не менее, это довольно простой код, поэтому не составит труда убедиться, что он не делает ничего подозрительного.
Короткий ответ: Ага.
Длинный ответ: Да, сделать что-то из этого было бы лучше, но есть пара вещей, которые пока мешают мне это сделать.
В идеале я хотел бы разбирать файлы политик прямо из SYSVOL, но они хранятся в множестве разных форматов, некоторые из них проприетарные, их очень трудно читать, и у меня нет ни времени, ни желания писать с нуля наборы парсеров для них, когда Microsoft уже предоставляет командлеты, которые отлично справляются с этой задачей.
В не столь отдалённом будущем я хотел бы встроить Get-GPOReport от Microsoft в Grouper, чтобы вам вообще не понадобился RSAT, но нужно выяснить, не будет ли это нарушением авторских прав. Также нужно разобраться, как реализовать то, что я только что сказал.
Grouper — это не сканер уязвимостей. Grouper просто фильтрует огромное количество мусора и шума в отчётах групповых политик, показывая только те настройки, которые МОГУТ быть сконфигурированы эксплуатируемым образом.
Насколько это возможно, я работаю над каждой категорией проверок, добавляя дополнительную фильтрацию для удаления очевидно не уязвимых конфигураций и ещё больше снижая уровень шума, но групповые политики чрезвычайно гибки, и довольно трудно предугадать каждую возможную ошибку администратора.
Отлично, вы только что нашли способ улучшить Grouper! Прокрутите вниз, и вы увидите небольшое руководство по добавлению новых проверок в Grouper.
Я прикрою тебя, парень. В репозитории есть файл test_report.xml, с которым можно попробовать. Он содержит кучу плохих настроек, так что вы сможете увидеть, как это выглядит.
Вам нужно будет запустить его с флагом -showDisabled, потому что в нём так много действительно ужасных конфигураций, что я даже не стал включать этот GPO в лабораторной среде.
ОК.
Короткий ответ: PowerView неплохо справится с этим.
Более длинный ответ: Я попытаюсь добавить эту функциональность когда-нибудь, а пока заткнитесь и используйте PowerView.
Отлично, легко исправить.
Откройте grouper.ps1, найдите массив "$polchecks" и просто закомментируйте строку, где эта проверка добавляется в массив.
Готово.
Конечно, звучит хорошо.
Получите XML-вывод GPOReport, включающий тип политики/настройки, которую вы хотите, чтобы Grouper умел находить. Для этого может потребоваться создать соответствующую политику в лабораторной среде.
Найдите XML-объект <GPO>, соответствующий вашей целевой политике.
Найдите подраздел XML, соответствующий информации, которую вы хотите извлечь из политики. Настройки политик делятся на политики пользователя и компьютера, поэтому это обычно будет либо:
GPO.Computer.ExtensionData.Extension
или
GPO.User.ExtensionData.Extension
Теперь самая раздражающая часть — причина, по которой этот код такой запутанный, в том, что каждый раздел настроек политики структурирован по-разному, и в них используются совершенно разные соглашения об именах, так что вам нужно разобраться, как структурирована ваша целевая политика. Удачи!
Вот скелет функции проверки, который вы можете использовать для начала. Убедитесь, что она либо ничего не возвращает, либо возвращает $null, если ничего интересного не найдено.
Function Get-GPOThing {
[cmdletbinding()]
Param (
[Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [System.Xml.XmlElement]$polXML,
[Parameter(Mandatory=$true)][ValidateSet(1,2,3)][int]$level
)
######
# Description: Checks for Things.
# Vulnerable: Description of what it shows if Level -eq 3
# Interesting: Description of what it shows if Level -eq 2
# Boring: All Things.
######
$settingsThings = ($polXml.Thing.ExtensionData.Extension.Thing | Sort-Object GPOSettingOrder)
if ($settingsThings) {
foreach ($setting in $settingsThings) {
if ($level -eq 1) {
$output = @{}
$output.Add("Name", $setting.Name)
if ($setting.SettingBoolean) {
$output.Add("SettingBoolean", $setting.SettingBoolean)
}
if ($setting.SettingNumber) {
$output.Add("SettingNumber", $setting.SettingNumber)
}
$output.Add("Type", $setting.Type.InnerText)
Write-Output $output
""
}
}
}
}
Большое спасибо:
Говоря об ужасном коде, да, я знаю, что это немного бардак. Я постарался сделать его как можно более модульным, чтобы другие могли добавлять дополнительные проверки без особых хлопот, но ему всё ещё нужно много доработок. Если вы заметили ошибку, которую я сделал и которая отчаянно нуждается в исправлении, пожалуйста, дайте мне знать.
Нажмите Ctrl-F, чтобы добраться до "$polchecks", и добавьте его в массив проверок вместе с остальными.
Протестируйте.
Если работает, отправьте pull request!
Если застрянете, пишите мне. Постараюсь помочь, если выкрою несколько минут.