Add SeMachineAccountPrivilege to maq module

[serwiz]

Description

I recently spent some time working on SeMachineAccountPrivilege enumeration, following the discussion and initial work introduced in PR #1029 by @Blatzy.
Based on that, I’m proposing this PR, which integrates the check directly into the MAQ module and makes it especially useful during internal penetration tests.

The idea is to keep everything dynamic and reliable, by:

• retrieving the gPLink values applied to the Domain Controllers OU
• parsing the corresponding GptTmpl.inf files to locate SeMachineAccountPrivilege
• extracting the associated SIDs and resolving them via LSA LookupSid

This avoids hardcoded assumptions and provides a clearer picture of how the privilege is actually configured on Domain Controllers.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Deprecation of feature or functionality
• This change requires a documentation update
• This requires a third party update (such as Impacket, Dploot, lsassy, etc)

Setup guide for the review

• OS: Debian (Linux)
• Python: 3.11 (running NetExec from source)
• Installed dependencies: standard NetExec dependencies (no extra third-party required)
• Domain Controller: Windows Server 2022
• No special configuration

The feature relies on:

• LDAP access to query the Domain Controllers OU gPLink
• SMB access to SYSVOL to read GPO files (GptTmpl.inf)
• LSA/RPC access (\pipe\lsarpc) to resolve SIDs to names via LookupSid

Screenshots:

Debug

Checklist:

• I have ran Ruff against my changes (via poetry: poetry run python -m ruff check . --preview, use --fix to automatically fix what it can)
• I have added or updated the tests/e2e_commands.txt file if necessary (new modules or features are required to be added to the e2e tests)
• New and existing e2e tests pass locally with my changes
• If reliant on changes of third party dependencies, such as Impacket, dploot, lsassy, etc, I have linked the relevant PRs in those projects
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (PR here: https://github.com/Pennyw0rth/NetExec-Wiki)

[mpgn]

Nice addition

[NeffIsBack]

Looks cool, thanks for the PR! Probably the better way to integrate the GPO parsing.

[Blatzy]

Hey ! Really nice, good trick to enumerate which GPO is relevant, I will close my PR since yours looks perfect.

[NeffIsBack]

This looks like it breaks on the first GPO it found with the privilege. We should probably iterate through all existing GPOs and check if there are multiple occurrences, so we don't miss any.

[serwiz]

You're right. Now it can support multiple GPO.

I'm also investigating to improve the permission check based on the microsoft documentation:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/add-workstations-to-domain

Suggestion: It could also be useful to retrieve the nTSecurityDescriptor on container and OU, to determine who is allowed to create computer objects. This can bypass both the SeMachineAccountPrivilege user right ("Add workstations to domain") and MachineAccountQuota.

[mpgn]

Interesting, could be usefull to get the level of the GPO

(GPO) domain.lab > Domain Controller > "Default Domain Controller POlicy"
(GPO) domain.lab > Custom XXX
(GPO) domain.lab > Servers > Custom 2 xxx

[serwiz]

Since the current scope only includes GPOs linked to the Domain Controllers OU,
I'm wondering whether this information would still be relevant.

Interesting, could be usefull to get the level of the GPO

(GPO) domain.lab > Domain Controller > "Default Domain Controller POlicy"
(GPO) domain.lab > Custom XXX
(GPO) domain.lab > Servers > Custom 2 xxx