Analysis users

The analysis script of users outputs the list of group members that are capable of accessing hosts remotely, and offers to filter on specific principals if desired. This essentially yields a map of which users must be compromised in order to gain access to the host, or if you are able to leverage previously-compromised users.

These groups will be refered to as "Remote Access Groups".

Execution

• Script: analysis/users/analyze.py
• Filter: analysis/users/principals_filter.txt

By default, the script requires only the path to the users.json results file to analyze, and will output all members of the remote access groups:

$ python3 analyze.py ../../results/2022-01-07-17-48-31/json/users.json 
{
    "192.168.56.8": [
        {
            "rid": 544,
            "name": "BUILTIN\\Administrators",
            "members": [
                {
                    "name": "SRV2\\Administrator",
                    "sid": "S-1-5-21-3844595960-2616373705-533209831-500",
                    "type": "SidTypeUser"
                },
                {
                    "name": "AD\\Domain Admins",
                    "sid": "S-1-5-21-642930740-2278254436-1623907929-512",
                    "type": "SidTypeGroup"
                }
            ],
            "access_certainty": "certain"
        },
        {
            "rid": 562,
            "name": "BUILTIN\\Distributed COM Users",
            "members": [
                {
                    "name": "AD\\user1",
                    "sid": "S-1-5-21-642930740-2278254436-1623907929-1121",
                    "type": "SidTypeUser"
                },
                {
                    "name": "AD\\user2",
                    "sid": "S-1-5-21-642930740-2278254436-1623907929-1122",
                    "type": "SidTypeUser"
                }
            ],
            "access_certainty": "potential"
        }
    ]
}

The -f or --filter argument can be given to display only the remote access groups that the principals specified in the principals_filter.txt file are part of:

$ cat principals_filter.txt 
ad\user1

$ python3 analyze.py -f ../../results/2022-01-07-17-48-31/json/users.json
{
    "192.168.56.8": [
        {
            "rid": 562,
            "name": "BUILTIN\\Distributed COM Users",
            "members": [
                {
                    "name": "AD\\user1",
                    "sid": "S-1-5-21-642930740-2278254436-1623907929-1121",
                    "type": "SidTypeUser"
                }
            ],
            "access_certainty": "potential"
        }
    ]
}

principals_filter.txt can also contain groups.

Certainty

In the output of the script, groups contain an attribute named access_certainty, either set to the value certain or potential. certain implies that being a member of the group itself is enough to get remote access to the host (in a out-of-the-box configuration, that is), while potential needs further configuration. For instance, BUILTIN\Remote Desktop Users alone will allow the user to remote desktop on the host, as opposed to BUILTIN\Distributed COM Users which requires more privileges.

This certainty flag does not take into account network segregation, meaning that the access can be labeled as certain even if you cannot reach the service that would provide remote access. This needs to be determined by the user.

Leveraging Remote Access Groups

BUILTIN\Remote Management Users

This group provides access to Windows Remote Management (WinRM).

On Windows, PowerShell Remoting allows to leverage this easily by using Enter-PSSession or Invoke-Command.

On Linux, CrackMapExec includes a nice implementation, which can be used like so:

./cme winrm $HOST -u $USER -p $PASSWORD -d $DOMAIN -x $COMMAND

BUILTIN\Remote Desktop Users

If the Remote Desktop Services are started on the host, simply fire up your favorite Remote Desktop client, and authenticate on the host to gain access.

BUILTIN\Distributed COM Users and BUILTIN\Performance Log Users

When running the analysis script, these groups are listed as "potential" since they do not grant access to the host out-of-the-box, as opposed to the other groups.

If you wish to learn about these groups and the additional privileges required, you can read about it in the blog post Non-administrative DCOM Execution: Exploring BloodHound's ExecuteDCOM, or note that you will need Remote Launch and Remote Activation over the DCOM object that you want to instantiate.

impacket's dcomexec.py can be used to perform the object instantiation:

python3 dcomexec.py -object MMC20 -silentcommand $DOMAIN/$USER:$PASSWORD\$@$HOST $COMMAND

BUILTIN\Administrators

This is evidently the Holy Grail of groups, allowing to gain privileged access to the host using the aforementioned techniques, or a multitude of different ones. For instance, impacket additionally offers atexec.py, psexec.py, smbexec.py, and wmiexec.py.

If you require to execute commands as the user instead of NT AUTHORITY\SYSTEM, use dcomexec.py (ensure to supply the -object MMC20 parameter), or wmiexec.py.