l0ss/grouperUm script PowerShell para ajudar a encontrar configurações vulneráveis na Política de Grupo do AD. (descontinuado, use Grouper2 em vez disso!)
NÃO USE MAIS O GROUPER. USE O GROUPER2! https://github.com/l0ss/Grouper2
Um script PowerShell para ajudar a encontrar configurações vulneráveis na Política de Grupo do AD.
O Grouper é um módulo PowerShell projetado para pentesters e redteamers (embora provavelmente também útil para sysadmins) que filtra a saída XML geralmente muito ruidosa do cmdlet Get-GPOReport (parte do módulo de Política de Grupo da Microsoft) e identifica todas as configurações definidas nos Objetos de Política de Grupo (GPOs) que podem ser úteis para alguém tentando fazer algo divertido/maligno.
Exemplos dos tipos de coisas que ele encontra nas GPOs:
Sim, é bem cru, mas me economiza um tempo enorme lendo aqueles terríveis relatórios de GPO em HTML de 150MB, e se funciona para mim, pode funcionar para você.
Nota: Embora alguns nomes de funções possam incluir a palavra audit, o Grouper NÃO é explicitamente destinado a ser uma auditoria exaustiva de configurações de melhores práticas, etc. Se você quer isso, deve usar o Microsoft SCT e o LGPO.exe ou algo assim.
Gere um Relatório de GPO em uma máquina Windows com os cmdlets de Política de Grupo instalados. Eles são instalados por padrão nos Controladores de Domínio, podem ser instalados em clientes Windows usando RSAT, ou podem ser habilitados através do assistente "Adicionar Recurso" em servidores Windows.
Get-GPOReport -All -ReportType xml -Path C:\temp\gporeport.xml
Importe o módulo Grouper.
Import-Module .\grouper.psm1
Execute o Grouper.
Invoke-AuditGPOReport -Path C:\temp\gporeport.xml
Há também alguns parâmetros que você pode ajustar que alteram quais configurações de política o Grouper irá mostrar:
-showDisabled
Por padrão, o Grouper mostrará apenas as GPOs que estão atualmente habilitadas e vinculadas a uma OU no AD. Isso alterna esse comportamento.
-Online
Por padrão, o Grouper trabalha apenas com a saída XML real do Get-GPOReport e não faz nenhuma comunicação de rede, tornando-o bastante "seguro para opsec", embora eu odeie esse termo.
Se você o invocar com -Online, o Grouper ativará verificações que exigem comunicação com (pelo menos) o domínio AD do qual o relatório foi gerado, mas também provavelmente envolverá comunicação com, por exemplo, servidores de arquivos. Isso permitirá que o Grouper faça coisas úteis como relatar as ACLs em arquivos visados pelas GPOs e verificar se, por exemplo, o usuário atual pode escrever no arquivo em questão.
-Level
O Grouper tem 3 níveis de filtragem que você pode aplicar à sua saída.
O uso é direto. -Level 3, -Level 2, etc.
O Get-GPOReport funciona perfeitamente em máquinas não associadas ao domínio via runas /netonly. Você precisará de algumas credenciais de baixo privilégio, mas isso é esperado.
Faça assim:
runas /netonly /user:dominio\usuario powershell.exe
em uma máquina não associada ao domínio que possa se comunicar com um controlador de domínio.
Em seguida, na sessão PowerShell resultante, faça assim:
Get-GpoReport -Domain exemplo.com -All -ReportType xml -Path C:\temp\gporeport.xml
Fácil.
Tudo o que o Grouper precisa para funcionar é PowerShell 2.0 e o arquivo XML de saída do Get-GPOReport. Você pode executá-lo em uma VM sem placa de rede se estiver preocupado e ainda funcionará.
Dito isso, o código é bem básico, então não deve ser difícil ver que não está fazendo nada remotamente suspeito.
Resposta curta: Sim.
Resposta longa: Sim, fazer uma dessas coisas seria melhor, mas há algumas coisas que me impediram de fazê-las AINDA.
Idealmente, eu gostaria de analisar os arquivos de política diretamente do SYSVOL, mas eles são armazenados em vários formatos de arquivo diferentes, alguns são proprietários, são um verdadeiro pesadelo para ler, e não tenho nem tempo nem vontade de escrever vários parsers para eles do zero quando a Microsoft já fornece cmdlets que fazem o trabalho muito bem.
Num futuro próximo, gostaria de incorporar o Get-GPOReport da Microsoft no Grouper, para que você não precisasse do RSAT, mas preciso descobrir se isso será algum tipo de violação de direitos autorais. Também preciso descobrir como realmente fazer essa coisa que acabei de dizer.
O Grouper não é um scanner de vulnerabilidades. O Grouper meramente filtra a enorme quantidade de lixo e ruído nos relatórios de Política de Grupo para mostrar apenas as configurações de política que PORDERIAM ser configuradas de maneiras exploráveis.
Na medida do possível, estou trabalhando em cada uma das categorias de verificações para adicionar filtragem extra para remover configurações obviamente não vulneráveis e reduzir ainda mais os níveis de ruído, mas a Política de Grupo é extremamente flexível e é bastante difícil antecipar todos os possíveis erros que um admin pode cometer.
Legal, você acabou de encontrar uma maneira de melhorar o Grouper! Role para baixo e você verá onde forneci um pequeno guia para adicionar novas verificações ao Grouper.
Eu cuido de você, garoto. Há um test_report.xml no repositório que você pode testar. Ele tem um monte de configurações ruins para que você veja como é.
Você precisará executá-lo com a flag -showDisabled porque está tão cheio de configurações realmente horríveis que nem quis ativar a GPO em um ambiente de laboratório.
OK.
Resposta curta: O PowerView fará um bom trabalho nisso.
Resposta mais longa: Tentarei adicionar essa funcionalidade em algum momento, mas por enquanto, cale a boca e use o PowerView.
Certo, facilmente resolvido.
Abra o grouper.ps1, encontre o array "$polchecks" e simplesmente comente a linha onde essa verificação é adicionada ao array.
Pronto.
Claro, parece bom.
Obtenha alguma saída XML do GPOReport que inclua o tipo de política/configuração que você deseja que o Grouper seja capaz de encontrar. Isso pode exigir a criação de uma política adequada em um ambiente de laboratório.
Encontre o objeto XML <GPO> que corresponde à sua política alvo.
Encontre a subseção do xml que corresponde às informações que você deseja extrair da política. As configurações de política são divididas em política de Usuário ou de Computador, então isso geralmente estará em:
GPO.Computer.ExtensionData.Extension
ou
GPO.User.ExtensionData.Extension
Agora a parte chata - a razão pela qual esse código é tão bagunçado é que cada seção de configuração de política é estruturada de forma diferente e elas usam convenções de nomenclatura amplamente variadas, então você precisará descobrir como sua política alvo é estruturada. Boa sorte?
Aqui está um esqueleto de uma função de verificação que você pode usar para começar. Certifique-se de que ela ou não retorna nada ou retorna $null se nada interessante for encontrado.
Function Get-GPOThing {
[cmdletbinding()]
Param (
[Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [System.Xml.XmlElement]$polXML,
[Parameter(Mandatory=$true)][ValidateSet(1,2,3)][int]$level
)
######
# Descrição: Verifica por Coisas.
# Vulnerável: Descrição do que mostra se Level -eq 3
# Interessante: Descrição do que mostra se Level -eq 2
# Chato: Todas as Coisas.
######
$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
""
}
}
}
}
Muito obrigado a:
Falando em código ruim, sim, eu sei que isso é uma bagunça. Tentei torná-lo o mais modular possível para que outros possam adicionar verificações adicionais sem muita dificuldade, mas ainda precisa de muito carinho. Se você vir um erro que fiz que precisa desesperadamente ser corrigido, por favor, me avise.
Use Ctrl-f para ir até "$polchecks" e adicione-a ao array de verificações junto com as outras.
Teste.
Se funcionar, envie um pull request!
Se ficar preso, me chame. Tentarei ajudar se conseguir arranjar alguns minutos.