Group3r v1.0.59 releases: Find vulnerabilities in AD Group Policy

by do son · Published April 6, 2022 · Updated August 3, 2023

Group3r

Like its ancestors, Group3r is a tool for pentesters and red teamers to rapidly enumerate relevant settings in AD Group Policy and to identify exploitable misconfigurations in the same. It does this by talking LDAP to Domain Controllers, parsing GPO config files of the domain SYSVOL share, and also by looking at other files (usually on file shares) that are referenced within GPOs, like scripts, MSI packages, exes, etc.

It might also be useful for other people doing other stuff, but it is explicitly NOT meant to be an audit tool. If you want to check your policy configs against some particular standard, you probably want Microsoft’s Security and Compliance Toolkit, not Group3r.

A lot of offensive tradecraft around Group Policy has historically focused on two main things: finding passwords (in GPP passwords etc), and abusing weak ACLs to modify GPOs. This stuff is super useful, but if you ignore the rest of Group Policy you’re leaving a huge amount of really useful information on the table, never mind some really fun attack paths.

Here’s an example:

The bit highlighted in red is a Group Policy Object (GPO). The top bar of that section tells you it’s a GPO, the display name of the GPO (testgpo123), the unique identifier of the GPO (the bit in braces), and whether the GPO is current or “Morphed”. Under that, you’ve got some basic info on the GPO itself, including which OUs (if any) it’s linked to.

The bit highlighted in magenta is a setting. The indent and little ASCII “tail” off the side of the block is meant to make it easier to see that it’s associated with the GPO above. The top bar tells you that it’s a setting, and what type of setting it is. In this instance, it’s an MSI package being pushed to computers to install PuTTY.

The bit highlighted in green is a finding. The colour (Red in this instance) in the top bar is the triage level, using the same levels as Snaffler – Green, Yellow, Red, and Black. Below that, it’s got a reason that a finding was raised, and some detail about this specific misconfiguration and maybe some abuse guidance if I was feeling nice when I wrote it.

Here’s another example of a setting with a finding:

This one is morphed, which means it might not be current, but it would have been applied at some point in the past. In this instance, we can see that a finding has been raised because Domain Users is being added to BUILTIN\Administrators on the target computers.

Here’s yet another example, this time of a Startup Script setting:

This setting isn’t morphed and has two findings – one because the arguments for the script look like a hard-coded password, and one because Group3r has spotted that the script in question is modifiable by the current user, which should allow for some very entertaining shenanigans if you put something saucy in the script.