Grouper - A PowerShell script for helping to find vulnerable

项目说明

Grouper

DONT USE GROUPER ANY MORE. USE GROUPER2!

A PowerShell script for helping to find settings in AD Group Policy.

!A picture of a fish
###### *Photo by Jon Hanson* - < - <

Summary

Grouper is a PowerShell module designed for pentesters and redteamers (although probably also useful for sysadmins) which sifts through the (usually very noisy) XML output from the Get-GPOReport cmdlet (part of Microsoft's Group Policy module) and identifies all the settings defined in Group Policy Objects (GPOs) that might pro to someone trying to do something fun/evil.

Examples of the kinds of stuff it finds in GPOs:
* GPOs which grant modify permissions on the GPO itself to non-default users.
* Startup and shutdown scripts
* arguments and script themsel include creds.
* scripts are often stored with permissions that allow you to modify them.
* MSI installers being automatically deployed
* again, often stored somewhere that will grant you modify permissions.
* Good old fashioned Group Policy Preferences passwords.
* Autologon registry entries containing credentials.
* Other creds being stored in the registry for fun stuff like VNC.
* Scheduled tasks with stored credentials.
* Also often run stuff from poorly secured file shares.
* User Rights
* Handy to spot where admins accidentally granted 'Domain Users' RDP access or those fun rights that let you run mimikatz e full admin privs.
* Tweaks to local file permissions
* Good for finding those machines where the admins just stamped "Full Control" for "E" on "C:\Program Files".
* File Shares
* INI Files
* En
* ... and much more! (well, not very much, but some)

Yes it's pretty rough, but it saves me an enormous amount of time reading through those awful 150MB HTML GPO reports, and if it works for me it might work for you.

Note: While some function names might include the word audit, Groper is explicitly NOT meant to be an exhausti for best practice configurations etc. If you want that, you should be using Microsoft SCT and LGPO.exe or something.

Usage

Generate a GPO Report on a Windows machine with the Group Policy cmdlets installed.
These are installed on Domain Controllers by default, can be installed on Windows clients using RSAT, or can be enabled through the "Add Feature" wizard on Windows servers.

Import the Grouper module.

Run Grouper.

Parameters

There's also a couple of parameters you can mess with that alter which policy settings Grouper will show you:

By default, Grouper will only show you GPOs that are currently enabled and linked to an OU in AD. This toggles that behaviour.

By default Grouper only works with the actual XML output from Get-GPOReport, and does no network comms at all, making it quite "opsec safe", though I do hate that term.

If you invoke it with -Online, Grouper will turn on checks that require talking to (at least) the AD domain from which the report was generated, but will also likely invol to e.g. file servers. This will allow Grouper to do handy things like report the ACLs on files targeted by GPOs, and check if e.g. the current user can write to the file in question.

Grouper has 3 levels of filtering you can apply to its output.

1. Show me all the settings you can.
2. (Default) Show me only settings that seem 'interesting' but may or may not be .
3. Show me only settings that are definitely a super bad idea and will probably ha in them or are going to otherwise grant me admin on a host.

Usage is straightforward. -Level 3, -Level 2, etc.

___

Frequently Asked Questions

I'm on a gig and can't find a domain-joined machine that I ha to with the Group Policy cmdlets installed and I don't want to install them because that's noisy and messy!

Get-GPOReport works just fine on non-domain-joined machines /netonly. You'll need some low-pri but that's to be expected.

Do like this:

on a non-domain-joined machine that can communicate with a domain controller.

Then in the resulting PowerShell session do like this:

Easy.

I don't trust you so I don't want to run your skee script on a domain-joined machine, but I want to try Grouper.

All Grouper needs to work is PowerShell 2.0 and the xml file output from Get-GPOReport. You can run it on a VM with no network card if you're worried and it'll still work fine.

That said, it's pretty basic code so it shouldn't be hard to see that it's not doing anything remotely sketchy.

I think it's dumb that you are relying on the MS Group Policy cmdlets/RSAT for Grouper. You should just write it to directly query the domain or parse the policy files straight out of SYSVOL.

Short answer: Yep.

Long answer: Yep, doing one of those things would be better, but there are a couple of things that pre me from doing them YET.

Ideally I'd like to parse the policy files straight off SYSVOL, but they are stored in a bunch of different file formats, some are proprietary, they're a real pain to read, and I ha the time nor the inclination to write a bunch of parsers for them from scratch when Microsoft already provide cmdlets that do the job very nicely.

In the not-too-distant future I'd like to bake Microsoft's Get-GPOReport into Grouper, so you wouldn't need RSAT at all, but I need to figure out if that's going to be some kind of copyright . I also need to figure out how to actually do that thing I just said.
___

Questions that I am anticipating

Grouper is showing me all these settings that aren't . WTF BRO FALSE POSITIVE MUCH?

Grouper is not a scanner. Grouper merely filters the enormous amount of fluff and noise in Group Policy reports to show you only the policy settings that COULD be configured in exploitable ways.

To the extent possible I am working through each of the categories of checks to add in some extra filtering to remo non- configurations and reduce the noise levels e, but Group Policy is extremely flexible and it's pretty difficult to anticipate every possible mistake an admin might make.

Grouper didn't show me a thing that I know is totally in Group Policy. WTF BRO FALSE NEGATIVE MUCH?

Cool, you just found a way to make Grouper better! Scroll down and you'll see where I' a little guide to adding new checks to Grouper.

I don't have a lab en and I don't have a GPO report file handy! I'm also very impatient!

I got your back, kid. There's a test_report.xml in the repo that you can try it out with. It's got a bunch of bad settings in it so you can see what that looks like.

You'll need to run it with the -showDisabled flag because it's so full of really awful configurations I didn't even want to enable the GPO in a lab en.

I'm even more impatient than that last guy and I demand pretty pictures immediately!

OK.

!Screenshot of test output

But wait, how do I figure out which users/computers these policies apply to? Your thing is useless!

Short Answer: PowerView will do a decent job of this.

Longer Answer: I'll be trying to add this functionality at some point but in the meantime, shut up and use PowerView.

I hate one of the checks Grouper does and I never want to see it again.

Cool, easily fixed.

Pop open grouper.ps1, find the "$polchecks" array and just comment out the line where that check gets added to the array.

Done.

I want to make Grouper better but I can't make sense of your awful spaghetti-code. Help me help you.

Sure thing, sounds good.

1. Get some GPOReport xml output that includes the type of policy/setting you want Grouper to be able to find. This may require knocking up a suitable policy in a lab en.

2. Find the \<GPO\> xml object that matches your target policy.

3. Find the subsection of the xml that matches the info you want to pull out of the policy. Policy settings are divided into either User or Computer policy, so this will usually be in either:

4. Now's the annoying part - the reason this code is such a mess is that each policy setting section is structured differently and they use wildly differing naming con, so you're going to need to figure out how your target policy is structured. Good luck?

6. Here's a skeleton of a check function you can use to get started. Make sure it either doesn't return at all or returns $null if nothing interesting is found.

7. Ctrl-f your way down to "$polchecks" and add it to the array of checks with the others.

8. Test it out.

9. If it works, submit a pull request!

10. If you get stuck, hit me up. I'll try to help if I can scrounge a few minutes together.

___

Credits, complaints, comments, death threats, errata

Thank you very much to:
* for his GPP password decryption helper function.
* and for their assistance and encouragement. I belie is probably still a line or two stolen from still in this thing but I'm really not sure where and I would hate to blame him for my shitty code.

Speaking of shitty code, yes I know this is a bit of a mess. I' to make it as modular as possible so others should be able to add additional checks without too much hassle, but it still needs a lot of love. If you see a mistake I've made that desperately needs fixing, please let me know.

项目信息

开发语言：PowerShell

Star 数：731

技术要点

该项目属于漏洞知识库方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕A PowerShell script for helping to find vulnerable settings in AD Group Policy. (deprecated, use Grouper2 instead!)展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。